OWASP SCVS: Reducing Risks in the Software Supply Chain

OWASP SCVS is a useful methodology for preventing supply chain attacks throughout the software lifecycle

At the end of January, the LockBit ransomware successfully impacted ION Trading UK. This company supplies financial software to some of the leading companies in the City of London and other banks and financial institutions in the United States and Europe. The cyber-attack meant that several ION applications could not be used and had to operate manually in the financial market. This incident checked the operation of one of the most important financial markets in the world and made visible how serious a supply chain attack can be.

This security incident adds to a growing list of attacks that highlight the importance of reducing risks in the software supply chain by using cybersecurity services and the knowledge and experience accumulated in this field.

The OWASP Foundation, a world reference in generating knowledge on cybersecurity, has launched SVCS, a standard that seeks to reduce risks in the software supply chain.

The Software Component Verification Standard (OWASP SCVS) aims to compile and systematize the best practices carried out globally in securing software throughout its life cycle, as well as in the detection of vulnerabilities in any of the components that make it up.

In this article, we will explain the keys to this standard and its usefulness for software development companies to reduce risks in the supply chain.

1. What is OWASP SCVS?

SCVS is a standard that follows the path set by an OWASP project widely accepted in the cybersecurity sector: Application Security Verification Standard (ASVS), focused on application security.

In this sense, OWASP SCVS is an extension of this guide that focuses on the securitization of the components that make up the software to reduce risks in the software supply chain.

This standard is designed to serve as a starting point for companies and public administrations that decide to place cybersecurity and the protection of the software supply chain at the heart of their strategy.

In this regard, the OWASP Foundation argues that companies and institutions that undertake cybersecurity efforts to protect the software supply chain can:

1. Protect their brand and reputation
2. Increase the confidence of users who employ their solutions
3. Reduce time-to-market or the time it takes to bring software to market securely
4. Manage the economic, legal and reputational costs of a security incident caused by a supply chain attack.

As with other OWASP methodologies, SCVS is designed to be implemented in levels. In such a way that the execution of the verification controls can be gradual and adjusted to the resources and needs of each organization to help it mitigate risks in the software supply chain.

2. Verification levels of software components

As we have just pointed out, SCVS operates like other OWASP standards, such as ASVS or MASVS (Mobile Application Security Verification Standard). The SCVS guide proposes three levels of implementation of the standard. They work cumulatively. In other words, the security requirements indicated for level 1 must also be implemented at levels 2 and 3.

Thus, companies that opt for level 1 must meet the basic security requirements to mitigate the software supply chain risks. While organizations opting for level 3 must ensure that they meet all verification requirements for each control.

• Level 1. It is focused on applying best practices in software development and monitoring. For example, having a detailed catalog of the software components and materials used.
• Level 2. This level is designed for companies with a security risk management framework. They also have to comply with more stringent regulatory requirements and guarantee their software’s security to their customers. This level not only focuses on technical aspects but also includes the role played by other departments such as legal.
• Level 3. The highest level of SCVS verification is the most suitable for critical infrastructures and more advanced security systems. In addition, this level seeks to achieve end-to-end auditability of the supply chain.

2.1. Designing a strategy tailored to the needs of each company

It should be noted that the combined action of verification levels and controls allows companies to design their software supply chain protection strategy à la carte using the OWASP SCVS standard.

Thus, a company can implement a control by opting for security level 2 because it addresses an area of vital technical and business importance. But, on the other hand, the same company can implement only level 1 in another, less relevant control.

After all, all companies and administrations have limited resources. The SCVS standard, like other OWASP standards, considers this issue. As a result, it is very useful for laying the foundations of a cybersecurity strategy that effectively secures the software supply chain, considering both the source components and processes and third-party software and open-source components.

3. Verification controls

As mentioned when addressing the verification levels, the controls are articulated around a series of requirements that must be checked. For example, Control 1 (Inventory) comprises ten requirements. Companies opting for SCVS level 1 will have to implement five of these requirements. Companies opting for level 2 will have to implement six. And finally, the most advanced organizations should ensure compliance with all ten requirements.

3.1. Inventory

When implementing a strategy for securing software throughout its lifecycle, it is essential to start with an inventory.

It is essential to have an accurate inventory of all the components used in the software. This is the only way to analyze the various components in search of vulnerabilities that cybercriminals can exploit.

The inventory carried out by a company or institution should not only consider the components that belong to the organization because it has created them. Therefore, it is also essential to include components from software vendors and open-source components.

This is the only way to increase the transparency and audibility of the supply chain and to perform audits to detect risks and threats.

3.2. SBOMS

SBOMS are software bills of materials, not only an inventory, as we discussed in the first OWASP SCVS check. They include vitally important information about the software components such as license, version numbers or details of the vendor that created them.

Why is this important? Consider, for example, the well-known Log4Shell cyber-attack that breached the Log4j component used in thousands of software products worldwide. If a company can easily know which applications used a vulnerable component, it can deal with the security incident promptly and effectively.

Given the relevance of SBOMS, OWASP SCVS focuses on the benefits of companies being able to automatically create SBOMS in the build process, thus increasing their level of maturity in the development process. This maturity level makes the SBOM automation requirement (2.2.) only applicable for levels 2 and 3 of software supply chain verification.

Furthermore, SCVS also indicates that it is essential that software BOMs are in a machine-readable format to ensure that SBOM is continuously analyzed for risks in the software supply chain (2.8. applicable to all levels).

Another aspect to highlight is the need for the SBOM to have a complete inventory of all components perfectly described (2.9.) and for these components to have their respective license information (2.14.). Both requirements must also be taken into account at all three verification levels.

3.3. Build an environment

The third OWASP SCVS check is key to securing the software supply chain at one of its most important points: the actual creation of the solutions.

Software creation chains can involve code repositories, package repositories, continuous integration processes, network infrastructure, etc. It is, therefore, essential to secure each of the systems involved in the chain since a vulnerability in any of them can open a gateway for a cyber-attack against the software.

Defects, errors, misconfigurations… All these issues can compromise the security of the software supply chain. Hence, this control seeks to help companies harden the systems involved in software creation.

To this end, OWASP SCVS establishes up to 21 verification requirements. Six of them are designed to be adapted, also, by companies that opt for level 1 of the standard. For example, the application needs to use a continuous integration build pipeline (3.3) or all manipulations of the source code or binaries carried out during the build process are known and well-defined (3.17).

3.4. Package management

Maven, .NET, Python… there are centralized repositories of open-source components for many compilation systems.

This does not detract from the desirability of having internal repositories within a company to facilitate the reuse of source components and to have better access to components from vendors that the company trusts.

Hence, it is relevant to pay special attention to package managers when it comes to reducing supply chain risks.

OWASP SCVS warns that although package managers and centralized repositories bring undoubted economic, technical and security advantages, it is essential to establish a series of best practices to reduce the risks in the software supply chain as much as possible.

This verification control includes up to 19 requirements. Some are of a basic type, applied to all levels of SCVS, such as verifying that the contents of package repositories are consistent with an authorized open-source component point of origin (4.2.). At the same time, others are intended for companies that are more mature in the cybersecurity arena, such as having the package repository automatically report security incidents affecting the components it contains (4.7.).

3.5. Component analysis

As its name suggests, this control consists of analyzing the potential risks associated with using vendor or open-source software components. The SCVS guide summarizes the issue with the following sentence: “every component, direct or transitive, is a candidate for analysis”.

This analysis of components that do not originate in-house is key to detecting vulnerabilities that could give rise to a supply chain attack.

3.5.1. Central Aspects

OWASP SCVS focuses on six main issues to be considered when performing a component analysis to detect vulnerabilities in the software supply chain:

• Known vulnerabilities. It is essential to consider the vulnerabilities detected at a global level.
• Component versions. The components’ versions let us know if they need to be updated or even if they have already reached the end of their life cycle. Components in these circumstances are more likely to present vulnerabilities.
• Types of components. Libraries, frameworks, applications, containers… These typologies are very common in software development and present challenges and risks that must be considered to secure the software supply chain.
• Component functions. Each software component has a function. It’s possible to detect duplicates or components that perform the same function if well-audited. Eliminating unnecessary components reduces risks that are also unnecessary.
• Several components. Maintenance costs increase when a new component is adopted, and the difficulty of performing maintenance tasks also increases.
• Licensing. Vendor and open-source software is released under licenses. These licenses include the types of use, the limitations when distributing these components or how to act if the software is modified. These licenses must be consistent with the company’s objectives.

This control comprises 12 requirements that address the issues we have just discussed. They focus on the automation of multiple risk identification processes. For example, the identification of expired components in use (5.6.).

3.6. Pedigree and provenance

Knowing the provenance of each component precisely is key to taking action if either the point of origin or another element of the chain is compromised. Hence, internal package managers must have information on the imported third-party components.

The software pedigree, according to NIST, consists of validating the composition of open-source and third-party components and their versions. The pedigree provides certainty about the internal composition of each component.

Among the seven verification requirements of this control, there are basic requirements such as having information on the origin of the modified components (6.3.). And more advanced ones, such as verifying that the chain of custody is auditable for source code and binary components.

4. Continuous verification throughout the software lifecycle

The controls described above show that, when it comes to protecting software against cyber-attacks, it is not only important to increase security controls and mechanisms during development. All phases of a software’s life are important. Security problems can arise in any of them.

Hence, the design of the OWASP SCVS controls is intended to serve as a basis for implementing a continuous software supply chain risk assessment system.

Moreover, many of the standard’s requirements focus on automating actions. And the overwhelming majority are themselves automatable. This allows companies to manage their resources better and avoid the task of continuous verification of the entire software lifecycle.

In addition, we must consider the speed at which changes occur both in terms of software development and the emergence of new attack techniques and methodologies.

If the composition of software changes, systems for securing it must be prepared to assess it for new risks or vulnerabilities continuously. On the other hand, one-off checks only assess security at a specific time, not throughout the entire software lifecycle.

5. Standardize the evaluation of IT suppliers

As we have seen throughout the article, the OWASP SCVS standard enables companies to design a comprehensive strategy to reduce software supply chain risks in such a way that they are able to analyze the source components and internal processes and also their suppliers’ software.

One of the central objectives of OWASP SCVS is to standardize how software suppliers are evaluated to prevent supply chain attacks that could jeopardize the company.

Transparency and traceability of contracted software are essential. In this sense, a company that contracts a solution can ask the supplier to provide an SBOM that allows it to visualize the components used by that tool. As well as to discern all the suppliers involved in particular software.

Moreover, OWASP SCVS controls and verification requirements can be used as a yardstick for evaluating the level of protection and assurance offered by a software vendor and making top-level business decisions. From deciding which vendor to contract with to terminating a relationship with a vendor that does not properly secure its solution.

In addition, vendor evaluation should not be limited to the time before software procurement or at a particular point in the software lifecycle. The OWASP SCVS standard makes it possible to monitor the risks of a solution on an ongoing basis, beyond incident notifications or security updates carried out by the vendor. This is crucial to require vendors to correct vulnerabilities in a timely manner, in order to prevent these security holes from being exploited by malicious actors.

6. Open source policy

Although the issue of open source was not incorporated as a control in developing the SCVS controls, this matter is present throughout the standard, being a cross-cutting issue in several controls.

Even so, given its relevance, the guide recommends, in the end, that companies that use open source in their software have an open source policy to systematize its use and verify its security.

This open-source policy should address issues of paramount importance in this matter, such as:

• The age of each component.
• The number of major or minor revisions that are acceptable for a component.
• The continuous updating of components, using automation to optimize this task.
• The exclusion criteria for components with known vulnerabilities.
• The average time it can take to repair a risky component through a component update.
• Restrictions on using components that have reached the end of their life cycle or lack technical support.
• The criteria for selection or exclusion of software suppliers.
• The list of acceptable licenses, according to their use.
• The inventory of prohibited components.
• The mechanisms for passing on modifications to the open-source community that produced the component.

In short, OWASP SCVS is a helpful methodology for companies aiming to secure their software supply chain and protect themselves against cyber-attacks. This standard makes it possible to prioritize an organization’s resources and focus on the most relevant aspects to mitigate the vulnerabilities of software and its components throughout their entire life cycle.