Your vulnerability must be not my vulnerability
An overview of the OWASP Software Component Verification Standard for the prevention of software supply chain attacks.
Attackers' strategies and tactics have for several years shifted toward attacks on the supply chain instead of targeting directly the intended victim. The strategy appears immediately very well motivated and justified as soon as we consider that 97% of applications use open-source third-party libraries and that open-source software typically accounts for 70% to 90% of code in Web and cloud applications (according to a Synopsis study). As a rough yet still valid general conclusion, we might say that the attack surface that is directly under the control of the dev team is significantly smaller than the portion depending on third parties. Additionally, attacking third parties makes the attack model much more scalable, as compromising a widely adopted software library can easily make it possible to target a huge number of potential victims (the Solarwinds and Kaseya attacks are even too easy examples of this). As a general trend, we see that attacks on third-party libraries are generally on the rise.
A good example is provided in a recent report from Reversing Labs, which shows the increasing number of malicious payloads uploaded on NPM between 2020 and 2022. In 2023, the PyPI, NPNJS, and Packagist repositories were all attacked and violated (please check references below).
What an attack on a software supply chain can do?
Software supply chain attacks weave through the stages of software production and delivery, compromising the integrity of the software by exploiting vulnerabilities in the development, distribution, or update process. Unlike direct attacks, these cyber-attacks target not the end user but the very means through which software is developed, delivered, and updated.
Strategic exploitation points mostly include:
Development Environments: by infiltrating development ecosystems, attackers can embed malicious code into the software right from its genesis.
Third-Party Components: leveraging vulnerabilities in third-party libraries and components, attackers pave the way for systemic exploitation, as these elements are widely integrated into various software applications.
Update Mechanisms: by compromising update mechanisms, adversaries ensure the propagation of malicious payloads to all systems that utilize the compromised software, often under the guise of legitimate updates.
The consequences, scale, and impact of software supply chain attacks depend on several factors, including primarily the nature of the vulnerability, the applications where the third-party components are used, and how widely the exploited component is adopted. We might thus assist in unauthorized data access and theft as well as the disruption of critical services. It is not rare for such attacks to remain undetected until they are activated, providing attackers with ample time to entrench themselves within the compromised systems.
Protecting against software supply chain attacks demands a holistic approach that encompasses stringent security practices throughout the software development lifecycle (SDLC).
How the OWASP SCVS can help in preventing supply chain attacks?
The OWASP Software Component Verification Standard (SCVS) is an open project from the OWASP foundation that aims to support mitigating supply chain attacks. It guides the mechanisms and practices to adopt to mitigate such attacks. Led by Steve Springett and currently in version 1.0, the project is meant to enable both the assessment of the capabilities of a first party, identifying areas of improvement, and being used as a reference to drive the process, as well as evaluation criteria for the third party suppliers. It can be used in whole or in part to evaluate proposals for procurement, given that SCVS controls at different levels can be used to qualify eligibility for procurement or as an element of scoring proposals.
Similarly to other OWASP initiatives (like for instance the Application Security Verification Standard), OWASP SCVS provides a set of controls that can be progressively implemented over time, offering an incremental approach to the adoption of the framework. The framework develops along two different directions, which are, respectively, the Software Component Verification Levels and the Control Families.
The verification levels help organizations set a target for implementation based on the purposes and domain where the application is used. The standard is organized into three levels, being the first (L1) regarding the adoption of basic best practices and recommended for any application, whilst level 3 (L3)
is recommended for critical infrastructure and systems with safety requirements. L2, which is the intermediate level, is appropriate for software-intensive enterprises and organizations with existing risk management frameworks and regulatory and/or contractual requirements. Compared with L1, L2 also expands the number of stakeholders including those with non-technical roles. 40% of the 87 controls belongs to L1, whilst L2 and L3 are assigned approximately 30% of the controls each.
The other direction where the standard develops is that of the control families, each one of which contains multiple controls that apply to different aspects of component verification or processes where component verification occurs. Families are six in total and organised as follows:
V1: Inventory Requirements
V2: Software Bill of Materials (SBOM)
V3: Build Environment
V4: Package Management
V5: Component Analysis
V6: Pedigree and Provenance
Let's quickly dive into them.
V1: Inventory.
The cornerstone of each risk mitigation strategy is to have an exhaustive list of the assets that are within the perimeter of the strategy. This set of requirements is actually meant to achieve this goal. L1 controls require among others that all the third-party libraries are managed using package managers (no libraries collected in the wild), that they are all identified in a uniquely and consistent, machine-readable format, and that software bill of materials are generated for publicly or commercially available applications. Advanced controls in L3 require for instance to know who is the supplier of the component and for what the component is used.
V2: Software Bill of Materials (SBOM).
Whilst the V1 control families set the need for an SBOM, this family of requirements sets the requirements regarding how the SBOM should be prepared. Besides basic requirements (the SBOM should be present, timestamped, have a unique identifier, and include license information), advanced controls are included which allow for ensuring the integrity of the components (at least one hash should be present) and for the components which have been modified detailed information on the provenance and pedigree should be included.
V3: Build Environment.
With this family of controls, we move to control the "build environment", which may consist of source code repositories, package repositories, continuous integration and delivery processes, and test procedures, along with the network infrastructure and services that enable these capabilities. The rationale is that we need to ensure the integrity of all the environments that are used to produce the software if we want the outcome to be not affected by security issues. Basic steps include having a repeatable and documented build pipeline, which may build only code that is maintained through repositories. The highest levels of security require that no changes are allowed during the building process, and that, whenever a modification to the environment is applied, such change is tracked and properly logged.
V4: Package Management.
We mentioned above the fact that remote package repositories have been seriously targeted by a broad range of attacks in the last few years. Thus, this control family foresees a set of controls useful to prevent issues connected with package management. Package repositories should enforce and validate the use of TLS for any interaction, should ensure the integrity of packages, and support auditability when components are updated. Advanced control requires strong authentication to access them, multi-factor authentication before publishing them, but also support for the management of security issues, including automated notification and reporting,
V5: Component Analysis.
This family of controls is meant to enable the automated analysis of the software components within the build scope. It is not only about using static scanners to identify coding bad practices, but more broadly to inspect automatically the software components to check that all the information useful to qualify them and to prevent/manage security issues are there. This means performing automated verifications for existing vulnerabilities, identifying non-specified or out-of-date components, keeping control of the licenses, and understanding where and how many times each component is used. More advanced controls require to identify end-of-life/end-of-support components or the function of each component.
V6: Pedigree and Provenance.
This family of controls introduces the concepts of points of origin and chain of custody so that 1) we know who has produced a piece of software and 2) we are sure the software is not altered before and during the building process. Thus, modifications, if allowed, should be tracked, analyzed, and evaluated.
Conclusions
In this post we illustrated a practical tool to prevent supply chain attacks, the OWASP Software Component Verification Standard. Key point about the framework:
It consists of up to 87 controls that can be progressively implemented to improve both internal verification processes as well as to evaluate third-party suppliers;
Controls cover six different areas, concerning the inventory of the components and the SBOM preparation, assessing the building environment and proper package management, and finally analyzing the components and ensuring their provenance.
It can be adopted incrementally and includes controls that are not specific to a single development team. They represent stakeholders across an organization, including software developers, security and risk managers, and procurement departments.
References
OWASP – Software Component Verification Standard - https://scvs.owasp.org
https://thehackernews.com/2023/05/packagist-repository-hacked-over-dozen.html
https://blog.phylum.io/sophisticated-highly-targeted-attacks-continue-to-plague-npm/
Reversing Labs – The State of Software Supply Chain Security