Your dependencies have known vulnerabilities.
Most never reach your code.
Twira finds the ones that do, in seconds.

In your editor

Your inbox fills up with PRs from your dependency-update bot for every CVE in your dependency tree. `npm audit` and `cargo audit` print the same lists in your terminal. Your auditor reads the same data. You triage manually, *does this CVE actually affect us?* Mostly the answer is no. Mostly it’s noise.

What Dependency Vulnerabilities (SCA) does

Dependency Vulnerabilities, known in industry as Software Composition Analysis (SCA), scans your lockfiles against the OSV vulnerability database and filters by reachability before showing anything. Two-tier filter: is the affected package even installed, AND does any of your code actually import it? Only vulnerabilities that pass both tiers surface. OSV-backed (the canonical multi-ecosystem feed, aggregates GHSA, RustSec, PYSEC, the Go vulnerability database, and more). Structured JSON or SARIF 2.1.0 output. Local cache (24h TTL) so air-gapped runs work. Nine ecosystems shipping today: npm, Cargo, PyPI (pip, poetry, Pipfile, uv), Go, Maven (pom.xml + Gradle), RubyGems, Packagist (Composer), NuGet, and Swift Package Manager.

How it actually works

Software Composition Analysis, SCA, is the part of security scanning that asks *"are any of my dependencies known to be vulnerable?"* Twira’s answer is built around one principle: **only show the developer CVEs their code can actually reach.** A vulnerability in a function nobody calls is noise; a vulnerability in a function on the critical path is a release-blocker. Most tools hand you the noise. SCA filters it out.

**A note before reading.** This page describes technical capabilities relevant to ISO 27001, the EU NIS 2 Directive, the EU AI Act, the EU Cyber Resilience Act, SOC 2, PCI-DSS, DORA, and adjacent security frameworks. Twira does not provide audit or legal advice, your security team and your auditor decide whether your specific use case requires further measures. The compliance section below names the controls Twira contributes to; it does not claim, and you should not represent, that Twira alone makes any organisation compliant. SCA is one technical detection layer in a defence-in-depth posture you will design holistically.

Ecosystems today: nine, the same set the cohort covers. SCA parses package-lock.json (npm v1, v2, v3), Cargo.lock (v3, v4, the format every modern Rust project uses), the four PyPI manifest formats (requirements.txt, poetry.lock, Pipfile.lock, uv.lock), go.sum (Go), pom.xml plus gradle.lockfile (Maven / Gradle), Gemfile.lock (RubyGems / Bundler), composer.lock (Packagist / PHP), packages.lock.json plus legacy packages.config (NuGet / .NET), and Package.resolved v1 and v2 (Swift Package Manager). Every lockfile is matched against OSV, the canonical multi-ecosystem feed, so the vulnerability data is the same shape regardless of which ecosystem produced it. The parser layer is ecosystem-agnostic by design, and Tier 2 reachability runs against the existing per-language code extractors (the same 26-language indexer the rest of Twira uses), so an OSV advisory for a PyPI package is filtered by your actual Python imports, a Swift advisory by your Swift imports, and so on. Less common ecosystems, Dart Pub, Hex (Elixir), Conan (C++), CocoaPods, are not yet wired in; if you depend on one of those, treat zero findings on that part of your stack as silence, not safety.

**Backed by OSV.** All vulnerability data comes from the Open Source Vulnerabilities database (`api.osv.dev`). OSV is the canonical aggregator, it ingests GitHub Security Advisories (GHSA), the RustSec Advisory Database, the Python PYSEC feed, the Go vulnerability database, and ecosystem-specific sources, then normalises them into one queryable surface with consistent affected-version ranges. Using OSV directly means we get every upstream feed automatically without having to chase each one individually, and the data is the same shape regardless of which ecosystem produced it.

**Two-tier reachability filtering.** This is the difference between a useful SCA scan and the typical noise dump. **Tier 1 (Package):** is the package installed in your lockfile? Is the installed version inside the advisory’s affected-version range? If no, the vulnerability is `confirmed unreachable`, eliminated, never shown. **Tier 2 (Module):** does any of your code actually `import` or `require` the affected package? If no, again `confirmed unreachable`, even when the dependency is installed, transitive imports nobody invokes don’t earn an alert. Only vulnerabilities that pass both tiers surface to the developer. Confidence ladder: `unknown → likely → confirmed`. Dev-only dependencies are excluded by default; optional dependencies are included (you can flip either).

CVSS severity classification. Every surfaced finding carries the CVSS score from the advisory. The score is the OSV-provided value, not a re-derivation, what your auditors see in the SCA report matches what they would see in NVD or any vendor advisory. The structured output (JSON or SARIF 2.1.0) preserves the score, so any downstream tool you have can filter or rank by it.

**Local cache, offline-safe.** The vulnerability database is cached locally with a 24-hour TTL. Online: a stale entry triggers a fresh OSV query; the result is cached and the scan proceeds. Offline: the scan falls back to whatever is in the cache (flagged as `from_cache: true` so you know). Air-gapped CI runs work, they just need an initial sync to populate the cache. No continuous phone-home; no provider-side telemetry on which packages you’re scanning.

Structured output, JSON or SARIF 2.1.0. Findings come back as structured JSON by default; SARIF 2.1.0 is also available if you need the OASIS-standard format for downstream tooling. Same shape as the Diagnose output, so anything you build to consume Diagnose findings works on SCA findings too.

**Same engine as Diagnose, same audit chain.** SCA is part of the Diagnose detector pipeline, it runs alongside the 12 code-level security detectors, the 4 bug detectors, the 6 health detectors, and everything else when you run `twira diagnose --profile security` or `--profile all`. That means SCA findings get the same drift-resilient suppression handling: suppress a known-accepted CVE once with an `intent` and `trust_level`, and the suppression survives version bumps, dependency tree restructures, and lockfile regeneration. Every detection event is recorded into the same append-only Merkle audit chain, access-controlled via HMAC-signed session cookies, so your auditor can reconstruct exactly which CVE was surfaced on which date and what your team decided.

**How this maps to security and supply-chain regulations, the honest version.** SCA contributions are concentrated in two regulatory areas: supply-chain security and technical vulnerability management. Most modern security standards now name these explicitly. ISO 27001 Annex A.8.8 requires technical vulnerability management; A.5.21 requires managing information security in the ICT supply chain. The EU NIS 2 Directive (Article 21) mandates supply-chain security for essential and important entities, energy, transport, banking, health, digital infrastructure. The EU Cyber Resilience Act mandates vulnerability handling across the product lifecycle. Twira SCA contributes the technical detection layer for all of them, with reachability filtering as the differentiator, fewer false positives means auditors see a real triaged list, not the raw 800-row dependency dump.

The compliance picture, by control. STRONG contribution: ISO 27001 A.8.8 (Technical vulnerability management), SCA is the technical detection layer; reachability filtering supplies the prioritisation the control expects · ISO 27001 A.5.21 (Information security in the ICT supply chain), explicit dependency-graph scanning satisfies the supply-chain visibility requirement · EU NIS 2 Art. 21(2)(d) (Supply chain security), same · OSV, the canonical multi-ecosystem vulnerability database backs every finding, aggregating GHSA / RustSec / PYSEC / Go vuln DB and the rest · OWASP SCVS, covers the dependency-identification and known-vulnerability control families · Structured JSON or SARIF 2.1.0 output, the industry-standard formats your audit and compliance tooling already consume · Append-only Merkle audit chain, provides the tamper-resistant record of every detection event, satisfying audit-trail requirements across all of the above. CONTRIBUTES to (but does not satisfy alone): EU AI Act Art. 15 (Accuracy, robustness, cybersecurity), supply-chain CVE management is one technical control for the cybersecurity duty for high-risk AI systems · EU Cyber Resilience Act (Regulation 2022/0272), mandates manufacturer-side vulnerability handling; SCA supplies the detection, your team supplies the response and disclosure · SOC 2 CC7.1 (System monitoring), SCA findings populate part of the vulnerability-management story · PCI-DSS Requirement 6.3.3 (Manage software vulnerabilities), same · NIST SP 800-218 PW.4 (Review software for vulnerabilities during development), same · DORA Art. 9 (ICT risk management for financial entities), supply-chain dimension · NIST SSDF (Secure Software Development Framework), SCA contributes to the PW.4 and PW.7 practice areas. NOT IN SCOPE: SBOM export (CycloneDX / SPDX), on the roadmap; today SCA detects but does not emit SBOM-format documents · Malware / typosquatting detection, OSV catches known CVEs only; novel-malware and typosquatting are addressed by separate behavioural-analysis tools · Licence compliance, we do not analyse package licences; dedicated licence-scanning tools cover that · Runtime monitoring, SCA is build-time detection only; runtime vulnerability monitoring is outside scope · Container / OS / firmware vulnerabilities, we scan application dependencies, not the infrastructure layer below them; pair with a container scanner for that layer · Fleet-wide central dashboards, each Twira install scans its own project; cross-repo aggregation is not part of the local-first model by design.

The honest gap, what SCA does not catch. Three categories of supply-chain risk are entirely outside today's SCA. (1) Less common ecosystems, Dart Pub, Hex (Elixir), Conan (C++), and CocoaPods are not yet wired into the lockfile parser. The 9 covered ecosystems (npm, Cargo, PyPI, Go, Maven, RubyGems, Packagist, NuGet, Swift) are the ones the cohort competes on, but if you depend on one of the four above, zero findings on that part of your stack does not mean no vulnerabilities; treat the silence as silence, not safety. (2) Non-CVE supply-chain attacks, novel malware, typosquatting, dependency-confusion attacks, malicious-maintainer takeovers, post-install scripts. OSV catches known CVEs; it does not catch the social-engineering / malicious-publish category that has caused several of the high-profile npm and PyPI incidents of recent years. For that vector, pair Twira with a dedicated behavioural-analysis tool. (3) Below-the-application layers, container base images, OS packages, kernel modules, firmware. Twira scans your application dependencies; for the infrastructure stack underneath, pair with a dedicated container scanner.

Setup: install once. SCA runs on every Diagnose scan. The first online run hits OSV; subsequent runs use the local cache and refresh per the TTL.

What it isn’t

• ·This is SCA (dependency vulnerabilities), not SAST (vulnerabilities in your own code). SAST lives on the sibling Diagnose page, same engine, separate scan path.
• ·Nine ecosystems supported: npm, Cargo, PyPI (pip / poetry / Pipfile / uv), Go, Maven (pom.xml + Gradle), RubyGems, Packagist (Composer), NuGet, and Swift Package Manager. Less common ecosystems (Dart Pub, Hex / Elixir, Conan / C++, CocoaPods) are not yet wired in. If your codebase uses a language outside the 9 covered, SCA returns zero findings for that part of your stack, treat the silence as silence, not safety.
• ·OSV catches known vulnerabilities. It does not catch novel malware, typosquatting, dependency confusion, or malicious-maintainer attacks. Pair with a behavioural-analysis tool for that vector.
• ·Application dependencies only. For the infrastructure layer underneath, container base images, OS packages, kernel modules, pair with a container scanner.
• ·Dependency-vulnerability scanning runs as part of Diagnose. Invoke via `twira diagnose --profile security` or `--profile all`. Same engine, same output, same drift-resilient suppression handling.