OWASP SCVS: the Software Component Verification Standard, explained

OWASP's Software Component Verification Standard (SCVS) is a framework of 87 numbered controls, grouped into six families, for assessing and maturing how an organisation inventories, builds, analyses and tracks the provenance of the third-party and open-source components inside its software. Version 1.0, released 25 June 2020 under project lead Steve Springett, describes itself as "a community-driven effort to establish a framework for identifying activities, controls, and best practices, which can help in identifying and reducing risk in a software supply chain," and is explicitly "inspired by the OWASP Application Security Verification Standard." Unlike ASVS, which verifies a specific application's own security controls, SCVS verifies the process that produced the components that application depends on.

Three cumulative verification levels

SCVS's "Using the SCVS" chapter defines three levels of increasing rigor, where "higher levels include additional controls":

• Level 1 — "for low-assurance requirements where basic forms of analysis would suffice," covering baseline practices like producing a complete component inventory and using CI for repeatable builds. The standard notes "adoption of level 1 can be achieved with modern software engineering practices."
• Level 2 — "for moderately sensitive software where additional analysis or due diligence is required," aimed at "software intensive enterprises and organizations with existing risk management frameworks and regulatory and/or contractual requirements," and may need "additional resources and domain expertise to achieve."
• Level 3 — "for high-assurance requirements due to the sensitivity of data or use of the software," naming "critical infrastructure and systems with safety requirements" specifically, where "auditability and end-to-end transparency in the supply chain is required to maintain a high security posture."

Counted directly from OWASP's own machine-readable release data (OWASP_SCVS-1.0.json): 36 of the 87 total requirements apply at Level 1, 62 at Level 2, and all 87 at Level 3 — confirming the standard's own description of each level as a strict superset of the one below it.

Six control families

Family	Requirements	Control objective (standard's own wording)
V1: Inventory	10	An accurate inventory of all components, "a foundational requirement for further analysis"
V2: Software Bill of Materials	18	"Automatically creating accurate... SBOM in the build pipeline is one indicator of mature development processes"
V3: Build Environment	21	Hardening source, package, CI/CD and test infrastructure, since "every system in the pipeline may provide an entry-point" for compromise
V4: Package Management	19	Securing the package managers and repositories that "are often targets for adversaries"
V5: Component Analysis	12	Identifying risk from third-party/open-source components via known-vulnerability and version-currency checks
V6: Pedigree and Provenance	7	"Identify point of origin and chain of custody in order to manage system risk" if either is compromised

Example Level-1 controls, quoted directly from their chapters: V1.1 "All direct and transitive components and their versions are known at completion of a build"; V2.1 "A structured, machine readable software bill of materials (SBOM) format is present"; V3.1 "Application uses a repeatable build"; V6.3 "Provenance of modified components is known and documented." Higher-level-only examples include V2.4/V2.5 (SBOM signing and signature verification, Level 2+) and V6.2 ("Chain of custody if auditable for source code and binary components," Level 3 only).

No official certification — by OWASP's own design

The standard's "Assessment and Certification" chapter is unusually direct: "OWASP, as a vendor-neutral not-for-profit organization, does not certify any vendors, verifiers or software," and "all such assurance assertions, trust marks, or certifications are not officially vetted, registered, or certified by OWASP." Organisations may still offer SCVS-based assessment services, but "should not claim official OWASP certification." The recommended verification method is an "open book" review — auditors given access to legal, procurement, build-engineering, development, repository and build-environment resources — with any resulting report required to disclose its scope and the specific control levels assessed, so a "SCVS certified" claim from a third party is always a self-declared assessment against a disclosed scope, not an OWASP-issued credential.

The NIST SSDF crosswalk

NIST's own Secure Software Development Framework, SP 800-218, lists "OWASP Software Component Verification Standard (2020)" in its references and cites specific numbered SCVS requirements directly inside its practice-to-reference mapping tables — not as a general "see also," but attached to individual SSDF tasks. Examples pulled directly from the SSDF text: task PW.4.1 (acquiring and maintaining well-secured software components from commercial, open-source, and other third-party developers) references "OWASPSCVS: 1.4, 2"; PW.4.4 (verifying that acquired commercial, open-source, and all other third-party software components comply with the requirements) references "OWASPSCVS: 1, 3.18, 3.19, 6.3"; and PO.1.3-adjacent provenance guidance references "OWASPSCVS: 3, 5." This means a team already producing SCVS evidence at a given control ID can point directly to the SSDF task it supports, rather than re-deriving the mapping.

A workable adoption order

1. Start with V1 Inventory and V2 SBOM at Level 1 — an accurate, machine-readable component list is the prerequisite every other family builds on.
2. Harden V3 Build Environment next — repeatable, documented CI builds are both a Level-1 requirement in their own right and what makes an accurate SBOM possible to regenerate.
3. Add V4 Package Management and V5 Component Analysis once the build is stable — trusted-repository sourcing and known-vulnerability checks assume there's already a reliable inventory to check against.
4. Treat V6 Pedigree and Provenance as the Level-3 tier — chain-of-custody auditability is realistic mainly for organisations already operating at the first five families' Level 2.
5. Use the SSDF crosswalk to avoid duplicate evidence — if an SSDF assessment is already underway, map produced SCVS evidence to the specific SSDF tasks above instead of running two unrelated assessments.

SoftWSP's firmware and component assessments produce the kind of evidence SCVS's Inventory, SBOM and Component Analysis families ask for — a machine-readable component list with known vulnerabilities attached, derived from binary analysis rather than self-attestation: see device & firmware security.

This guide summarises the public OWASP SCVS v1.0 standard and the related NIST SP 800-218 publication; it is not a substitute for the full text and does not constitute compliance or legal advice.