Recent high-profile cybersecurity incidents such as the SolarWinds attack and the Apache Log4j vulnerability have exposed the threats associated with the software supply chain. These can range from fairly simple exploits of known vulnerabilities to very sophisticated attacks, sponsored by nation-state actors.
The annual spending on enterprise software — also known as commercial off-the-shelf or COTS software — is now approaching $600 billion with a growth rate of 11.5%. Yet, given the magnitude of this investment, enterprises are spending a pittance on securing their software supply chain. This is what makes COTS software so dangerous — vulnerabilities can be “hidden” in open source components. However, there is a fix for this in a software bill of materials (SBOM).
Improving COTS Security Posture
Traditionally, enterprises have trusted that software vendors are performing the necessary security due diligence, following accepted software engineering best practices, and disclosing the security practices for supporting their software. Customers, on the other hand, are left to investigate the security of the products they use through associations or user groups to share information about vendor risk and software security.
These approaches are clearly not enough as shown by the Apache Log4j vulnerability. Despite the best intentions of software vendors, too many security vulnerabilities are lurking in open source components used to build COTS software. This represents a software security blind spot that the vendors themselves may not even know about. The key artifact needed to shed light on this blind spot is the SBOM.
The SBOM is an inventory report of the software components that make up a software product — just like the labels on food products have a list of ingredients and nutritional information.
SBOMs and Vulnerability Detection
Automating software supply chain security requires deep visibility into COTS applications. This includes having access to a BOM as well as detailed vulnerability information to truly understand the security risks to the organization.
In addition, an SBOM often will include licensing information to help ensure compliance and reduce the risk that the software is released or consumed with unlicensed components. This license information can also help with forensics when investigating which version of an open source component is vulnerable to a security threat, as is the case with multiple releases of Apache Log4j.
Reducing Risk with SBOM Outputs
There are several ways to use the data provided by an SBOM once a vulnerability is discovered. First, evaluate the results in terms of likelihood and impact. Likelihood is a determination of the probability of an attack succeeding using the discovered vulnerability. Impact should consider both the immediate damage and long-term impact to the company brand, bottom line, and customer experience.
The quadrant approach below is one effective way to evaluate open source vulnerabilities found in COTS software. For example, software with some vulnerabilities, deemed unlikely to be exploited with low impact, could be approved for purchase, renewal, or maintenance contract by simply accepting the low risk level. Obviously, software with a high impact, high likelihood of attack vulnerabilities may need to be rejected.
However, it is often not possible to simply reject software that is critical to the business. While using SBOM data in the COTS procurement process is a relatively new discipline, the assumption here is that both the customer and the vendor will act in good faith to improve the security of the product and reduce security risk over time. This assessment process can also be applied to currently deployed software. The illustration below shows a more nuanced decision workflow to follow once SBOM results are in-hand.
Approve/Reject
If the SBOM and vulnerability report indicate an unacceptable number of high severity vulnerabilities and the risk is too high, then the product should be rejected (top left above). Similarly, if the product exhibits only minor risk, then it can be accepted.
Conditionally Approve
In cases where a product introduces security issues (top right above) but the business needs for the software outweigh the risks, the product can be conditionally approved. In these cases, the security team can implement compensating security controls before deployment and monitor for potential threat activity targeting known vulnerabilities. Additionally, working with the vendor to remediate the risk is essential as they may be unaware of these vulnerabilities. Disclosure and cooperation are key.
Conditionally Reject
If the software product is business-critical but the security risk is just too high (bottom quadrants above), the product can be conditionally rejected. In such cases, the decision to proceed with deployment will depend on just how critical the software is to the business. In cases where security risk is too high, the organization can insist the issues be fixed before deployment or wait for a new version of the software that addresses the vulnerability.
In the extreme case where the software is critical to the business and required for daily operations, the organization can negotiate financial, legal, and liability terms for its use with the vendor.
The data provided by SBOMs can be used to improve software supply chain security from new product procurement to protecting deployed applications. In the case of COTS software, applying SBOM outputs to the risk quadrant model presented above can help organizations proactively reduce risk and eliminate threats in the software that runs their business.
