OWASP Software Component Verification Standard (SCVS)
A look at some of the fundamental controls for each of the SCVS levels
Unlike frameworks such as NIST’s SSDF which is created by Government organizations, OWASP’s SCVS is a community-driven effort focused on the software supply chain. It focuses on reducing risk in the software supply chain by focusing on identifying relevant activities, controls and best-practices that can be implemented throughout the software supply chain lifecycle. OWASP’s SCVS is also referenced throughout the NIST SSDF guidance. Version 1.0 of SCVS was released in 2020 and is led by Steve Springett along with several other contributors and reviewers.
SCVS is broken out into six control families, each of which contains multiple controls to various aspects of software component verification and processes. The control families include Inventory, SBOM, Build Environment, Package Management, Component Analysis, and Pedigree and Provenance.
Much like SLSA, SCVS uses levels. The higher the level the more controls associated with it. SCVS has three levels, with Level 1 being for low assurance requirements and basic controls. Level 2 is moderately sensitive software and situations where additional rigor is warranted. Lastly, Level 3 is for the most high-assurance environments due to data sensitivity or mission criticality. Let’s take a deeper look at each of the levels to understand some of the fundamental controls associated with them.
Levels
As the SCVS guide states, Level 1 lays the groundwork for all subsequent levels and higher levels of assurance. Much like other frameworks, level one includes some fundamental activities, most notably, having an accurate inventory. In the world of software this increasingly involves creating an SBOM to understand the software components involved in your applications. Level 1 also involves using Continuous Integration in pursuit of producing repeatable builds. Popular CI platforms include CircleCI, Jenkins, Gitlab and Github, although others certainly exist as well. Continuous Integration involves developers merging all their working copies of code to the shared main repository. CI involves both technology and practices, such as the CI or build service but also the cultural aspect of developers learning to frequently integrate their code changes. Lastly, Level 1 calls for performing analysis of third-party components with tools and intelligence that is publicly available. There are various tools that can help with analysis and identifying relevant publicly disclosed vulnerabilities associated with the third-party software components, which we will dive into deeper in the following sections. SCVS also includes Levels 2 and 3, each of which adds additional rigor or requirements from the baseline Level 1.
Level 2 of SCVS, as stated by OWASP, focuses on software intensive organizations who have some maturity around risk management frameworks in place. Level 2 builds on the controls identified in Level 1 by bringing in additional stakeholders and parties to the mix, such as non-technical professionals who may be involved in areas such as contracts and procurement.
Level 3 is the most rigorous of the SCVS levels and focuses on both auditability and end-to-end transparency throughout the software supply chain. This level is often reserved for the most high-regulated and sensitive industries as well as the most mature organizations.
OWASP recommends that organizations utilize SCVS in pursuit of incremental improvement around software supply chain security. They also recommend organizations tailor it to fit the security and compliance requirements most relevant to the organizations using the standard. This is a somewhat unique perspective that advocates for flexibility over uniform baselining as is often done by other security standards and frameworks.
With that said, let’s dig into the control families and associated controls as defined by SCVS.
Inventory
Having an accurate inventory has long been a critical security control as cited in sources such as the SANS and subsequent CIS Critical Security Control frameworks. Despite that, it has also long been a challenge that organizations struggle with, so it is no surprise to see Inventory listed as the initial control family listed in the SCVS standard. In the SCVS context, the focus is on having an inventory of all the components used in the creation of software and the controls advocated for reach across single applications, organizational-wide inventories and bolstering software transparency related to software acquisition. SCVS, much like the broader push for software transparency, advocates for having organization-wide software inventories, which includes both first-party and third-party software components, including OSS code.
Level 1 in the Inventory family focuses on key activities such as knowing direct and transitive components at build time as well as utilizing package managers to manage third-party binary components. Level 1 also includes having a comprehensive inventory of third-party components in a machine-readable format and generating SBOM’s for publicly and commercially available applications. Level 2 builds on these controls by also requiring that SBOM’s are required for new software procurements. This is an example of a control that extends beyond the cyber practitioner and begins to involve other non-technical stakeholders, such as acquisition professionals who can begin to ask for these artifacts as part of procurement.
Level 3 within the Inventory family begins to add more rigorous controls such as continuously maintaining SBOMs for all systems and knowing component types throughout the inventory. Not only does it require knowing the component type, but it also requires knowing the component function and more important the point of origin for all components. This is often referred to as provenance as it relates to the software supply chain.
Software Bill of Materials (SBOM)
SBOM is a key component and security control family within the SCVS framework. SCVS states that organizations with mature development practices are creating SBOM’s as part of their build pipeline activities and doing so in a machine-readable format. SCVS recognizes that there are multiple SBOM formats, such as CycloneDX and SPDX and organizations need to align with the format(s) that best fit their use cases, as well as potentially more than one format to meet things such as functional and contractual requirements and be able to work with the diverse vendor ecosystem.
Level 1 of the SBOM family lays out some fundamental controls such as having a structured and machine-readable SBOM present, assigning unique identifiers to SBOM’s, as well as metadata such as timestamps. Building on these controls SCVS calls for having SBOM’s that have complete accurate inventories for all the components the SBOM describes and analyzing the SBOM’s for any relevant vulnerabilities associated with the components. Lastly, there are requirements to ensure component identifiers are derived from native ecosystems where possible and having accurate licensing information for the components contained in the SBOM’s.
Building on the Level 1 requirements, Level 2 in the SBOM family adds additional controls such as having the SBOM’s not only signed by the publisher, supplier or certifying authority but also performing signature verification activities. Level 2 also calls for SBOM’s having accurate inventory of all test components for an application and metadata about the asset or software the SBOM is describing. Lastly, there is a requirement to have components defined in the SBOM to have valid SPDX license ID’s or expressions if applicable.
Level 3 adds even further controls to the SBOM family of activities. These include identifying the component point of origin in a machine-readable format, such as a PURL, as well as having valid copyright statements for the software components defined in the SBOM. Additionally, Level 3 also calls for having detailed provenance and pedigree information for components defined in the SBOM and utilizing file hashes such as SHA-256 for components defined in the SBOM.
Build Environment
SCVS acknowledges the complexity of modern build environments, including source code and package repositories, CI/CD processes, testing activities and the supporting network infrastructure and services that all make software build and delivery possible. As SCVS mentions, each of these entities and activities in the build environment and pipeline present a possible attack vector for malicious actors, as well as opportunity for traditional failures and misconfigurations to occur. This is perhaps best articulated by other frameworks, such as Supply Chain Levels for Software Artifacts (SLSA) and their illustration of the various attack vectors and potential points of compromise in the modern pipeline and build process.
The Build Environment control family is perhaps the most robust of the SCVS standard, having over 20 controls associated with it. Level 1 involves fundamental controls such as having repeatable build processes, documentation associated with build instructions and utilizing CI pipelines. It also involves controls such as ensuring that the application build pipeline can only perform builds from source code in the version control systems and ensuring build time changes to source and binaries are well known and defined. Lastly, Level 1 calls for having checksums of all first and third-party software components that are documented for every build.
Level 2 of the Build Environment controls begins to add additional activities such as build pipelines not allowing for the modification of builds outside of the job performing the build as well as mitigating the alteration of package management settings or executing code outside of the context of a jobs build script. Level 2 also calls for enforcing authentication and authorization and default deny settings on the build pipeline. Given the build pipeline itself can be compromised due to outdated systems and software, Level 2 calls for having an established maintenance cadence for the build pipeline tech stack. Lastly, Level 2 requires having checksums of all components accessible and delivered out of band when components are packages or distributed.
The final requirements in Level 3 include items such as requiring separation of concerns/duties for modifying system settings in the build pipeline, retaining a verifiable audit log of all system changes and build job changes. There are also requirements for monitoring compilers, VCS, development utilities and SDK for tampering and malicious code. The controls call for ensuring that unused direct and transitive components have been both identified and removed from the application, which contributes to attack surface reduction and minimizing the potential attack vectors for malicious actors.
Package Management
SCVS points out that modern day OSS components are often published to ecosystem-specific package repositories such as Maven, .NET and NPM. Organizations are increasingly being directed towards establishing internal repositories of not only first-party components but also trusted third-party components, with guidance such as NIST 800-161 R. 1 and the NSA Secure Guidance for Developers both recommending this approach. SCVS notes that package managers are often invoked during the build process and there are several business and technical benefits for their use, but also security considerations as well.
Level 1 controls for the Package Management family include controls such as ensuring binary components are retrieved from a package repository and that those contents align with an authoritative point of origin for OSS components. The repository must also support auditing/logging when components are updated and verifying the integrity of the packages when they are retrieved from a remote repository or file system. Package managers should also enforce encryption such as TLS for data exchanges and ensure that TLS certificate chains are validated or fail securely when they cannot be. The package manager must also not execute component code and package installation data should be available in machine-readable formats.
Advancing the controls from Level 1, Level 2 in the Package Management family starts to call for strong authentication for the package repository, including using MFA. Organizations may want to specifically focus on phishing resistant MFA, given the recent incidents involved compromised or abused MFA. In addition to strong authentication, Level 2 calls for ensuring the package repositories support the ability to conduct security incident reporting and notify publishers of security issues. There are controls to require the package repositories to be able to verifiably correlate component versions to source code in VCS as well as requiring code signing for published packages to the production repository.
Finally, Level 3 in the Package Management family adds a handful of additional controls to the mix. These include ensuring package repository components have been published with MFA, automated security incident reporting, including the notification of users for security issues. There is also the requirement that the package repository requires and performs SCA prior to publishing components and even makes those results available to software component consumers and analysis and assurance.
Component Analysis
The 5th control family in SCVS is Component Analysis, which is the process of identifying potential areas of risk from using OSS and third-party components. This includes not only direct but also transitive components. Organizations need to understand any inherent risk associated with OSS and third-party components they use in their applications and systems. OSS and third-party software use is pervasive, with a large majority of modern applications being composed of OSS and third-party software components. Organizations need to understand both the components they’re using, and any vulnerabilities and risks associated with those components.
In pursuit of understanding vulnerabilities, organizations most commonly refer to sources such as the NIST National Vulnerability Database (NVD) to look for known vulnerabilities. In addition to known vulnerabilities, there are other data organizations should also be familiar with. These include items such as component version currency, component type, function and quantity. This means understanding if the component is out-of-date or end-of-life and likely to be vulnerable, as well as understanding the component type and any associated implications for upgrades and risk. Organizations should understand the components function to identify duplicative components and narrowing component use to higher quality components to minimize risk. Organizations should understand the component quantity in their inventory, as it gets increasingly difficult to manage component sprawl. Lastly, organizations must understand license types associated with the components they’re using, as there may be distribution requirements and limitations and conflicts that pose business risk.
Level 1 of the Component Analysis family involves activities such as being able to analyze components with linters and static analysis. There is also an emphasis on automation for activities such as identifying publicly disclosed vulnerabilities associated with components, identifying non-specified component versions in use or outdated components. Organizations must also have automated processes of identifying component quantity in use and licensing associated with the components.
Level 2 takes these steps further by ensuring components are analyzed via linting and static analysis, including on every upgrade of a component as well as automating the process of identifying component types in use.
Key distinctions for Level 3 involve automating the process of identifying confirmed exploitability, end-of-life/support for components and component functions.
Pedigree and Provenance
The last of the control families is Pedigree and Provenance. Pedigree and Provenance are critical because it is difficult to trust or understand the risk associated with software consumption without understanding both the quality of what you’re consuming and where it has originated from, and the chain-of-custody involved in its delivery.
Level 1 in the Pedigree and Provenance family involves having provenance of modified components documented, as well as analyzing modified components with the same level of rigor as unmodified components. There is also a control to ensure the organization understands risks unique to the modified components and their associated variants.
Building on Level 1, Level 2 adds controls to ensure organizations have documented verifiable pedigree of component modifications and are uniquely identifying modified components.
The lone control for Level 3 involves having a chain of custody that is auditable for source code and binary components.
Open-Source Policy
While not a formal control family within the SCVS, the guidance lays out recommendations for organizations more broadly around their use of OSS. While organizations use of OSS is rampant and involved in most modern applications that organizations produce and consume, most organizations maturity around governing its use hasn’t matured quite yet.
SCVS recommends organizations establish OSS policy that is supported and enforced by cross-functional stakeholders. These policies should cover critical considerations related to OSS, such as understanding the age of components in use, setting requirements around using old major or minor revisions and guidance on keeping components continuously updated with automation capabilities. Organizations should also establish guidance for excluding components with known vulnerabilities or at least a stance on the level of acceptable risk. At-risk components should have defined mean-time-to-remediate criteria as well as restrictions on using end-of-life components due to their inherit risks. Some organizations may even have a prohibited components list, due to vulnerabilities, national security concerns or other factors.
As mentioned above, while organizations use of OSS is overwhelmingly common, most organizations haven’t taken the time to codify their stance on OSS in formal policy and guidance. We have begun to see some organizations leading the way and going beyond policies and establishing OSS Program Offices to help govern and drive the organizations use of OSS within their software they produce as well as OSS consumers.
If you have any questions, or would like to discuss this topic in more detail, feel free to contact us and we would be happy to schedule some time to chat about how Aquia can help you and your organization.