Analysis types

TRUSCA runs several distinct kinds of analysis over your code and its dependencies. Each kind consumes a different input, runs a different tool, and produces a different result — a set of findings, a quality score, or a pass/fail build verdict. This page is the entry-point matrix for deciding what to run: pick the analysis that answers your question, then follow the cross-link to the page that documents it in depth.

Audience

New adopters and platform owners choosing which analysis to run, and reviewers mapping TRUSCA's capabilities to an internal checklist. Familiarity with SBOMs (Software Bill of Materials — the dependency inventory of a build), CVEs (Common Vulnerabilities and Exposures), and CI build gates helps. For term definitions see the glossary.

This is a matrix of pipelines, not data signals

This page lists the analysis pipelines — source scan, container scan, build gate, reachability. Its companion, Data sources → Per-finding data signals, is a matrix of the data signals each finding carries (NVD · OSV · GHSA · EPSS · KEV, plus CVSS, CWE, fixed version, and so on). Read the two together: this page is which analysis runs; that page is what data each vulnerability finding carries.

The matrix

Analysis	Consumes (input)	Tool	Produces	When to use	Details
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, SBOM
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, Container OS end-of-life
Build 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, License policies, GitHub Actions
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

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

A source scan is the default analysis. cdxgen (a CycloneDX SBOM generator covering 30+ ecosystems) walks the repository and emits an SBOM of the dependency tree with declared licenses read from each package's metadata. scancode then reads your own first-party source for detected licenses (best-effort). Finally trivy sbom matches the SBOM against the local Trivy DB to produce CVE findings, and the built-in classifier assigns each license a legal tier (permissive / conditional / forbidden / unknown).

The result feeds every project tab — Components, Licenses, Vulnerabilities, SBOM. See Architecture → Scan pipeline for the stage-by-stage flow and Scans for how to trigger one.

An uploaded SBOM (an SBOM your own build already produced) is a variant of this kind: TRUSCA scores its conformance, persists its components, and runs the same trivy sbom matching, without cloning or building your source. See SBOM upload.

Container image scan

A container scan targets a built image rather than source. Trivy inspects the image's OS packages (Alpine apk, Debian deb, RHEL rpm, and so on) for known CVEs — complementary to a source scan, which covers your application's dependency tree. It also reports whether the image's base OS release is past its end-of-service-life: a release that no longer receives upstream security fixes will never be patched for CVEs disclosed after it retired, so the recommendation is to rebuild on a supported release.

See Scan a container image and Base-image OS end-of-life.

Build gate

The build gate is not a scanner — it evaluates the output of a completed scan against your rules to reach a build verdict. It counts components whose license resolves to forbidden and vulnerabilities over the configured thresholds, then returns a pass/fail result. In CI, a failing gate exits with code 1 to block the build. Thresholds and posture are set through GATE_* environment variables (see Environment variables) and, per team or organization, through a license policy that re-classifies licenses dynamically before counting.

See Approvals for the human workflow around conditional licenses and GitHub Actions for the CI wiring.

Reachability analysis

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".

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: some commercial tools run proprietary multi-language reachability, whereas TRUSCA ships Go-only reachability via govulncheck.

Track the multi-language roadmap on the comparison page and the roadmap.

Verify it worked

The three shipped analysis kinds on this page (source, container, build gate) match the scan kinds and gate documented in Scans → Scan kinds and License policies → Dynamic gate evaluation — no pipeline appears here that is not documented there.

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 ("Go only", reachability prioritization ships for Go) and Data sources (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 build 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 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.

The matrix​

Source SBOM scan​

Container image scan​

Build gate​

Reachability analysis​

Verify it worked​

Troubleshooting​

See also​