feat(scanner): identify vendored open source in C/C++ sources via SCANOSS

[haksungjang]

Why

C/C++ embedded source with no package manager (raw CMake/Make) yields an almost-empty SBOM — cdxgen lists each file as an unidentified pkg:generic entry. The open source actually lives in files copied (vendored) into the tree (openssl, liblfds, djbdns, …). This adds an opt-in step that identifies those and feeds them into the existing license/CVE pipeline. Motivated by C/C++ supplier scans (e.g. tRelay 26.4.0) where the submitted SBOM identified zero open source.

What

• Identification — identify-vendored.sh fingerprints sources against the public OSSKB (SCANOSS), file-match only (snippets off), with dependency/build folders excluded. Emits CycloneDX components tagged bomlens:layer=vendored / identifiedBy=scanoss.
• Identify → CVE chain — normalize-sbom.sh + vendored-purl-map.json map SCANOSS pkg:github/* matches to a CPE, since Trivy ignores pkg:github/pkg:generic. Libraries with an NVD record (e.g. openssl, djbdns) then surface CVEs; niche ones (liblfds, libaes) are identified without CVEs (a data limit, not a tool one).
• No over-detection — reconcile-vendored.sh drops matches a package-manager component already covers, so enabling this on a normal managed project does not duplicate known deps or inflate the CVE count. Generic merge-sbom.sh unchanged.
• Off-by-default discovery — suggest-vendored.sh nudges (one line + web banner) only for C/C++ with no manifest and a near-empty scan. The user is never required to know the feature up front.
• Surfaces — CLI --identify-vendored (+ SCANOSS_API_URL/SCANOSS_API_KEY); Dockerfile SBOM_SCANOSS opt-in (scanoss.py is MIT; the GPL engine is not bundled); web UI Advanced toggle, result banner, and a vendored badge showing read-only match confidence. A stateful accept/reject match-audit workflow is intentionally out of scope (that is TRUSCA's role).

Testing

• bash tests/test-postprocess.sh → 40 passed (No-Docker), including the identify→merge→CPE chain, snippet exclusion, the suggestion logic, and the reconciliation/over-detection guard.
• bash -n + shellcheck on new/changed scripts; frontend tsc --noEmit + vite build clean.
• Integration checks in tests/test-e2e.sh are gated behind SCANOSS_E2E=1 (network + opt-in image), including a managed-project over-detection comparison (baseline vs --identify-vendored).

Before merge

• Run the OSSKB spike once on a network-connected host: scan an openssl-vendored sample with scanoss-py scan --format cyclonedx and confirm whether matches carry a CPE. The code handles both cases (CPE present → kept; absent → map lookup); this just confirms which path dominates and tunes vendored-purl-map.json coverage.

Notes

OSSKB is free, rate-limited, and identification-only; for high-volume or air-gapped use point SCANOSS_API_URL at a SCANOSS commercial/self-hosted endpoint. Terms and license notes are in THIRD_PARTY_LICENSES.md.

[haksungjang]

OSSKB CPE spike — done ✅

Ran the pre-merge spike against the real api.osskb.org (scanoss-py 1.53.1, five openssl-3.0.0 source files, --skip-snippets).

Findings:

• All 5 files returned full-file (id: file) matches.
• No cpe field in the result → vendored-purl-map.json is the required path to CVEs, not a fallback. Design confirmed.
• PURL is pkg:github/openssl/openssl (also conan/conda/maven/npm/nuget) → Trivy can't match it directly → the map's CPE synthesis is needed. Map key matches.
• Version arrives as a git tag (openssl-3.0.0-beta2, openssl-3.0.0, …). Fed raw, that produced a malformed CPE and broke the chain on real data. Fixed in 5d3d8f8 (strip <component>-/v prefix → 3.0.0), now pinned by a test using a git-tag fixture.
• Per-file matches resolved to different pre-release tags of the same release → file-match version precision is inherently approximate (now documented in the guide; status: pending on each match reinforces the review-first posture).

No remaining blockers from the spike.