OWASP Software Component Verification Standard
Description
The Software Component Verification Standard (SCVS) is 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.
Rationale
Managing risk in the software supply chain is important to reduce the surface area of systems vulnerable to exploits, and to measure technical debt as a barrier to remediation.
Determination of risk acceptance criteria is not a problem that can be solved by enterprise tooling: it is up to risk managers and business decision makers to evaluate the advantages and trade-offs of security measures based on system exposure, regulatory requirements, and constrained financial and human resources. Mandates that are internally unachievable, or that bring development or procurement to a standstill, constitute their own security and institutional risks.
Benefits
Measuring and improving software supply chain assurance is crucial for success. Organizations with supply chain visibility are better equipped to protect their brand, increase trust, reduce time-to-market, and manage costs in the event of a supply chain incident.
OWASP SCVS Unknown Components
ID |
owasp_scvs/known_components |
Severity |
critical |
Category |
Inventory |
Levels |
L1, L2, L3 |
Optional |
false |
Description
All direct and transitive components and their versions are known at completion of a build.
Rationale
If you do not know the components used and their respective versions, then you can miss security vulnerabilities in components, have license issues, or cannot resolve provenance for large parts of your software.
Verification
Although direct dependencies can be read from dependencies specified in project files (often specific for popular package managers), to resolve the full dependencies graph tools either tools like package manager commands, SCA, or a valid SBOM provided by component providers should be used.
Xygeni’s scan-deps command is one of such tools, and it is used for automating verification of the checkpoint.
Remediation
The build process should get all dependencies with package managers, and never add binaries or packages from other sources, with the possible exception of source code "snapshots" compiled at build time. Components involved and their versions should be clearly specified.
Small Print
Please note that the checkpoint does not say anything about whether versions should be open (perhaps using semver requirements for automatic upgrade), or fully fixed.