docs: correct reachability (Go ships) + close out C4 re-evaluation

docs-site/docs/comparison.md

@@ -44,7 +44,7 @@ For term definitions (SCA, SBOM, VEX, EPSS, reachability), see the
 | Auto remediation / PRs | Planned | Yes | No | No |
 | EPSS prioritization | **Yes** | Yes | Partial | No |
 | VEX consumption | **Yes** | Yes | Partial | No |
-| Reachability analysis | Planned | Yes (some) | No | No |
+| Reachability analysis | Go only (govulncheck) | Yes (some) | No | No |
 | Signed SBOM / provenance | Planned | Partial | No | No |
 
 ## vs commercial SCA (Black Duck, Snyk)
@@ -64,8 +64,8 @@ covering detection, licenses, SBOM, approvals, and CI gating meets your needs.
   dependency-graph depth but does not yet open upgrade pull requests —
   suggested upgrades are planned.
 - **Prioritization signals.** EPSS prioritization is first-class — column,
-  sort, filter, and a policy-gate threshold. Reachability analysis is
-  planned, not shipped.
+  sort, filter, and a policy-gate threshold. Reachability analysis ships
+  for Go (via `govulncheck`); reachability for other ecosystems is planned.
 
 **Where TRUSCA is competitive:** self-hosting with no seat cost,
 Apache-2.0 licensing, a single portal instead of several consoles, a built-in
@@ -129,8 +129,12 @@ These are real and intentional gaps. Each is on the
 - **Vulnerability data depends on the Trivy DB.** Signals are limited to
   what NVD + OSV + GHSA + EPSS + KEV expose, augmented by first-class EPSS
   prioritization, KEV in-the-wild badges, and imported VEX.
-- **No reachability prioritization.** Findings are listed in full rather than
-  ranked by whether vulnerable code is reachable (planned, best-effort).
+- **Multi-language reachability is limited.** Reachability prioritization
+  ships for **Go** (via `govulncheck`) — a reachable / not-reachable badge,
+  the `?reachable=` filter, `sort=reachable`, and a gate signal. Findings in
+  other ecosystems (Java, JS/TS, Python, and so on) are not yet analysed and
+  are shown in full. Proprietary multi-language reachability is where the
+  commercial tools still lead.
 - **Static license policy.** Classification uses a fixed catalog; per-team /
   per-org editable policy is planned.
 - **No signed SBOMs / provenance.** SBOM signing and SLSA provenance are

docs-site/docs/reference/analysis-types.md

@@ -25,9 +25,9 @@ This page lists the **analysis pipelines** — source scan, container scan, poli
 | **Source SBOM scan** | A Git repository (or an uploaded source archive) | `cdxgen` → scancode → `trivy sbom` | A CycloneDX SBOM, declared + detected licenses with legal-tier classification, and matched CVEs | The default. You want the full component inventory, licenses, and vulnerabilities for a project's dependency tree. | [Scans → Scan kinds](../user-guide/scans.md#scan-kinds), [SBOM](../user-guide/sbom.md) |
 | **Container image scan** | A built container image reference (`name:tag`) | Trivy | OS-package CVEs and a base-image OS end-of-life (EOSL) verdict | You ship a container and want to know about vulnerabilities in the OS layer, not just your application dependencies. | [Scans → Scan a container image](../user-guide/scans.md#scan-a-container-image), [Container OS end-of-life](../user-guide/scans.md#container-os-eol) |
 | **Policy gate** | The findings and licenses from a completed scan | Portal gate evaluator | A pass/fail build verdict (CI exit code `0` or `1`) | You want a build to fail automatically on a forbidden license or a vulnerability over threshold — the CI enforcement point. | [Approvals](../user-guide/approvals.md), [License policies](./license-policies.md), [GitHub Actions](../ci-integration/github-actions.md) |
-| **Reachability analysis** | (Planned) analyser output for a finding's call graph | (Planned) `govulncheck` and peers | A per-finding reachability signal — reachable / not reachable / not analysed | You want to prioritise findings whose vulnerable code is actually called. **See the status note below before relying on this.** | [Comparison → reachability](../comparison.md) |
+| **Reachability analysis** | Preserved Go source of a scanned module | `govulncheck` (Go) | A per-finding reachable / not-reachable / not-analysed signal (Go findings only) | You want to prioritise findings whose vulnerable code is actually called. **Go only today — see the status note below.** | [Comparison → reachability](../comparison.md) |
 
-The first three are analysis pipelines that ship and run today. The fourth, reachability, is a planned capability with partial UI plumbing — read the note below so you do not overstate it in an evaluation.
+All four ship and run today. Reachability ships **for Go** via `govulncheck` — read the note below for its scope: it covers Go modules only, and findings in every other ecosystem are not yet analysed.
 
 ## Source SBOM scan {#source-detail}
 
@@ -51,27 +51,29 @@ See [Approvals](../user-guide/approvals.md) for the human workflow around condit
 
 ## Reachability analysis {#reachability-detail}
 
-:::caution Planned — not a shipped analysis pipeline
-Reachability is a **planned, best-effort** capability. The UI surfaces a reachability signal where source data provides it, but **no dedicated reachability scan pipeline ships today**. The backend and worker do not run `govulncheck` (or any call-graph analyser) as a first-class analysis type — there is UI plumbing (a reachability badge, a `?reachable=` filter, a `sort=reachable` ranking, and a `reachability_source` field) that displays a signal *when a finding carries one*, but in this release findings are shown in full rather than ranked by whether vulnerable code is reachable. Every matched CVE is presented as "potentially affected".
+:::note Ships for Go; other ecosystems not yet analysed
+Reachability ships today **for Go**. After every successful source scan, the worker runs `govulncheck` as a best-effort follow-up (`scan_reachability.py`, dispatched from `scan_source`; `govulncheck` is built into the worker image). It is on by default and can be turned off with `REACHABILITY_ENABLED=false` to shed worker load. It never fails the originating scan — if the source is not preserved, the project is not a Go module, or `govulncheck` is missing or times out, findings simply stay "not analysed".
 
-This matches the honest characterization elsewhere in the docs: [Comparison](../comparison.md) lists reachability as **Planned** with *no reachability prioritization*, and [Data sources](./data-sources.md) states the portal does **not** consume reachability analysis. Do not represent TRUSCA as running `govulncheck` as a first-class analysis type.
+For each **Go** finding (a `pkg:golang/` component whose CVE / GHSA / GO id `govulncheck` reported), the analyser stamps a verdict: `reachable = true` (the vulnerable symbol is reachable on the call graph), `reachable = false` (the analyser ran but the symbol is not reachable), or `reachable = null` (not analysed). The signal is surfaced by the reachability badge, the `?reachable=true|false|unknown` filter, and the `sort=reachable` ranking, and it can inform the policy/build gate.
+
+**Findings in other ecosystems (Java, JS/TS, Python, and so on) are not yet analysed** — they stay `reachable = null` and are shown as "potentially affected". Multi-language reachability is the current commercial gap: Black Duck and Snyk run proprietary multi-language reachability, whereas TRUSCA ships Go-only reachability via `govulncheck`.
 :::
 
-When reachability lands, it will layer over the existing finding list as a prioritisation signal — the UI affordances (badge, filter, sort) are already in place to receive it. Track the status on the [comparison page](../comparison.md) and the [roadmap](https://github.com/trustedoss/trusca/blob/main/ROADMAP.md).
+Track the multi-language roadmap on the [comparison page](../comparison.md) and the [roadmap](https://github.com/trustedoss/trusca/blob/main/ROADMAP.md).
 
 ## Verify it worked
 
 <!-- docs-uat: id=analysis-types-pipelines-match-scans kind=manual tier=manual -->
 1. The three shipped analysis kinds on this page (source, container, policy gate) match the scan kinds and gate documented in [Scans → Scan kinds](../user-guide/scans.md#scan-kinds) and [License policies → Dynamic gate evaluation](./license-policies.md#dynamic-gate-evaluation) — no pipeline appears here that is not documented there.
 
-<!-- docs-uat: id=analysis-types-reachability-planned kind=manual tier=manual -->
-2. The reachability row and its status note describe a **planned, best-effort** signal, consistent with [Comparison](../comparison.md) ("Planned", "No reachability prioritization") and [Data sources](./data-sources.md) ("does not consume reachability analysis") — this page does not claim a shipped `govulncheck` pipeline.
+<!-- docs-uat: id=analysis-types-reachability-go kind=manual tier=manual -->
+2. The reachability row and its status note describe a **Go-only, best-effort** signal that ships today: a Go finding can carry a `reachable = true / false / null` verdict from `govulncheck`, while non-Go findings stay "not analysed". This is consistent with [Comparison](../comparison.md) ("Go only", reachability prioritization ships for Go) and [Data sources](./data-sources.md) (reachability is not a Trivy-DB signal but a separate `govulncheck` pipeline for Go).
 
 ## Troubleshooting
 
 - **"Which analysis do I run for licenses and CVEs?"** A source scan — it produces both in one run. The policy gate then turns those results into a build verdict.
 - **"My container scan found no application-dependency CVEs."** Container scans cover OS packages only. Run a source scan for the application dependency tree; the two are complementary.
-- **"The reachability badge is blank on every finding."** Expected in this release: no reachability pipeline runs, so findings carry no reachability signal and the compact list renders nothing for the "not analysed" state. See the [status note](#reachability-detail).
+- **"The reachability badge is blank on every finding."** Expected on non-Go findings, and on Go findings when reachability could not run (source not preserved, `REACHABILITY_ENABLED=false`, or `govulncheck` missing or timed out): the finding stays "not analysed" and the compact list renders nothing for that state. Go findings that were analysed show a reachable / not-reachable badge. See the [status note](#reachability-detail).
 
 ## See also
 
@@ -80,4 +82,4 @@ When reachability lands, it will layer over the existing finding list as a prior
 - [Architecture](./architecture.md) — services, scan pipeline stages, Trivy matching.
 - [Data sources](./data-sources.md) — the per-finding data signals (NVD · OSV · GHSA · EPSS · KEV) behind each vulnerability.
 - [License policies](./license-policies.md) — how the policy gate classifies and gates licenses.
-- [Comparison](../comparison.md) — where reachability and other planned items stand.
+- [Comparison](../comparison.md) — reachability scope (Go today) and where other planned items stand.

docs-site/docs/reference/data-sources.md

@@ -90,7 +90,7 @@ The portal **does not** consume:
 
 - Curated vulnerability research from commercial feeds (Black Duck KnowledgeBase, Snyk DB) — by design, we ship the open feeds only.
 - Vendor-specific advisory feeds (Oracle CPU, Microsoft MSRC) beyond what flows into NVD. These can be added as additional Trivy data sources in a future release.
-- Reachability analysis. The portal does not parse call graphs; every matched CVE is shown as "potentially affected".
+- Reachability as a **Trivy-DB signal** — the Trivy DB does not carry reachability. TRUSCA does run reachability, but as a separate `govulncheck` analyser for **Go**, not from Trivy DB data (see [Analysis types → Reachability](./analysis-types.md#reachability-detail)). It marks Go findings reachable / not-reachable / not-analysed; findings in other ecosystems are not analysed and are shown as "potentially affected".
 
 ## What this means for triage
 

docs-site/i18n/ko/docusaurus-plugin-content-docs/current/comparison.md

@@ -44,7 +44,7 @@ UI로 묶는 것입니다. 아래 비교는 그 아이디어를 세 가지 대
 | 자동 리메디에이션 / PR | 로드맵 | 지원 | 미지원 | 미지원 |
 | EPSS 우선순위화 | **지원** | 지원 | 부분 | 미지원 |
 | VEX 소비 | **지원** | 지원 | 부분 | 미지원 |
-| Reachability 분석 | 로드맵 | 일부 지원 | 미지원 | 미지원 |
+| Reachability 분석 | Go만 지원 (govulncheck) | 일부 지원 | 미지원 | 미지원 |
 | SBOM 서명 / provenance | 로드맵 | 부분 | 미지원 | 미지원 |
 
 ## 상용 SCA(Black Duck, Snyk)와 비교
@@ -62,7 +62,8 @@ UI로 묶는 것입니다. 아래 비교는 그 아이디어를 세 가지 대
   finding별 `fixed_version`과 의존성 그래프 depth는 제공하지만 업그레이드
   PR을 아직 생성하지 않습니다 — 추천 업그레이드는 계획 단계입니다.
 - **우선순위화 신호.** EPSS 우선순위화는 1급 신호로 제공됩니다 — 컬럼·정렬·필터·
-  정책 게이트 임계값. Reachability 분석은 아직 계획 단계입니다.
+  정책 게이트 임계값. Reachability 분석은 `govulncheck`로 Go에 대해 제공되며,
+  다른 생태계의 reachability는 계획 단계입니다.
 
 **TRUSCA가 경쟁력 있는 지점:** 좌석 비용 없는 자체 호스팅, Apache-2.0
 라이선스, 여러 콘솔 대신 하나의 포털, 내장 컴포넌트 승인 워크플로우, 빌드 차단 CI
@@ -120,8 +121,11 @@ SBOM·컴포넌트가 공급되는 것을 전제하며 스캔보다 clearing을
   업그레이드는 계획 단계입니다.
 - **취약점 데이터가 Trivy DB에 의존.** 신호는 NVD + OSV + GHSA + EPSS + KEV
   노출분에 더해 1급 EPSS 우선순위화, KEV 실환경 배지, 임포트된 VEX로 보강됩니다.
-- **Reachability 우선순위화 없음.** 취약 코드의 도달 가능성으로 순위를 매기는 대신
-  전체를 나열합니다(계획, 베스트에포트).
+- **다중 언어 reachability는 제한적.** reachability 우선순위화는 **Go**에 대해
+  `govulncheck`로 제공됩니다 — reachable / not-reachable 배지, `?reachable=` 필터,
+  `sort=reachable`, 게이트 신호. 다른 생태계(Java, JS/TS, Python 등)의 finding은
+  아직 분석되지 않고 전체가 나열됩니다. 독점 다중 언어 reachability는 상용 도구가
+  여전히 앞서는 지점입니다.
 - **정적 라이선스 정책.** 분류는 고정 카탈로그를 사용하며, per-team / per-org 편집
   가능 정책은 계획 단계입니다.
 - **SBOM 서명 / provenance 없음.** SBOM 서명과 SLSA provenance는 계획