Over the last several years, supply chain risk management has evolved into a leading factor for most enterprise security teams. While third-party risk has always been an element of most mature security programs, the evolving state of supply chain risk has put a spin on the myopic, "Who else has my data?" — view of legacy third-party risk management.
In today’s enterprise, understanding the risk associated with third-party applications, IoT devices, and open-source code used by the DevOps teams all fall squarely under the purview of supply chain risk management teams.
Here's a look at the state of Software Bills of Materials (SBOMs) — and why SBOM automation is the next big step in managing software supply chain risk.
[ Key takeaways: Supply chain security risks addressed in new Gartner report | Get the Gartner report: Mitigate Enterprise Software Supply Chain Security Risks ]
SBOM standards are emerging
Back in 2018, the National Telecommunications and Information Administration (NTIA), a division of the U.S. Department of Commerce, undertook an effort to address the transparency of software running the within the critical infrastructure of the country. The goal of this effort was to develop a common means to share information on all the software components which went into developing the application. Commonly associated with the Nutrition Labels found on food packaging, the goal of SBOM was to provide security teams insight into any risks that lie buried within the application's codebase. This work was formally published by NTIA in 2021 as the Software Bill of Materials (SBOM) standards.
Executive Order 14028 and SBOMs
In an effort to expedite the focus on supply chain risks, President Biden signed Executive Order (EO) 14028 in May 2021, mandating the improvement of the security posture of the federal government’s technology infrastructure. This new directive was the result of highly publicized vulnerabilities within the SolarWinds Orion platform (Sunburst) and in the Apache Log4J library (Log4Shell), both of which had a dramatic impact on the federal government's infrastructure.
A key element of the EO was the adoption of secure software development practices, which would be evidenced by the implementation of the new SBOM controls published by the National Institute for Standards and Technology (NIST). As with what typically occurs, the EO elevated the SBOM from a nice-to-have feature to a semi-mandatory solution that is now being evaluated throughout most governmental agencies and large enterprises.
Implementing SBOMs: Manual maintenance issues
Unfortunately, determining the risk of an organization’s supply chain is anything but straightforward. Unwinding large applications, from open-source operating systems, to in-house developed applications, to third-party "shrink-wrapped" stacks is fraught with contextual challenges, inventory methods, and manual verification, all of which are prone to error. While the SBOM standard codified the process of identifying and reporting software issues, it does not address the issue of manually maintaining such an inventory and consistently validating its contents.
While the SBOM standard codified the process of identifying and reporting software issues, it does not address the issue of manually maintaining such an inventory and consistently validating its contents.
If we look at a simple SBOM, there are seven minimum elements required for it to be considered "functional." Presuming the supplier is providing the adequate level of metadata within these fields, the SBOM will detail what software component was used, who the supplier of that component is, a link to the component’s repository, and a component version number.
To effectively use the information provided, someone must consistently evaluate the component's version level vs the release level, identify any potential security issues (vs functional ones) and make determinations on risks that could impact the enterprise. This is challenging enough for just the complete application (i.e. Apache) much less the thousands of libraries included within the Apache code. Additionally, code dependencies and hierarchy are often problematic with ‘basic’ SBOMs included in the generic build, since code that calls other external code is often overlooked.
Because of this, enterprises that are considering leveraging SBOMs as a risk mitigation strategy are faced with a significant challenge when it comes to leveraging the information an SBOM provides. While, conceptually, SBOMs address many risk issues within the AppDev/DevOps/Supply Chain space, implementing it as a full solution is a significant undertaking. Additionally, since many of today’s enterprise security teams are already struggling with tool sprawl, adding more tools to the mix is not very appealing. However, due to the otherwise significant manual effort required to manage an SBOM program, leveraging an automated SBOM evaluation and monitoring tool is critical for successful adoption.
Automating SBOMs is no longer a "nice-to-have"
By automating SBOM evaluation, enterprises can not only leverage the information supplied by the solution provider, but they can also unwind all the hidden risks contained deep within the codebase. Continual evaluation of the code dependencies brings to light risks that were previously unknown, and ones that could not be easily obtained manually. When it comes to leveraging SBOMs in the context of risk management, SBOM automation is not just a nice-to-have, it’s an absolute necessity.
When it comes to leveraging SBOM in the context of risk management, automation is not just a nice-to-have, it’s an absolute necessity.
TAG CYBER SERIES
- Chris Wilder: Modernize your SOC with advanced malware analysis, real supply chain security — and best practices
- David Neuman: Integrate threat hunting into the SOC triage process to mitigate software supply chain risk
- Edward Amoroso: Leverage third-party software validation to bolster your supply chain security
- Chris Wilder: Shift the SOC left: Why your organization should integrate DevOps with Security Operations
