Which teams in my organization can help reduce risk using SBOMs

We recently shared the basics of SBOMs and their value in reducing risk. In this post we would like to share thoughts on the different stakeholders in the organization that can take advantage of SBOMs to reduce risk. We will address options for six groups or functions in large enterprises: Application Security, Threat Intelligence, the Security Operations Center (SOC), Supplier Security, Developers and Internal Audit teams.

1. Application Security: Given the chief responsibility of this team is reducing risk in applications, an SBOM is a critical tool to enable this team to understand its components to track and those that are vulnerable to then apply fixes. Think of the Application Security Team - which may be referred to by other names such as the DevSecOps Team – as the “quarterback” that responsible for driving the risk reduction opportunities of SBOMs across the organization.
2. Threat Intelligence: Threat Intelligence teams help protect an organization by understanding and sharing the best and latest information about cyber threats with other teams. SBOMs are in perfect alignment with these ideas. When a Threat Intelligence has access to an inventory of the organization’s SBOMs, it can utilize the knowledge of existing software components to prioritize the identification of public threats known to affect those libraries.
3. Security Operations Center (SOC): Security Operations Centers monitor for potentially malicious activity that cannot be prevented with other controls. In the event of a zero-day vulnerability or a vulnerability identified via a bug bounty program, if the SOC is armed with access to an index of SBOMs, the SOC can quickly identify which applications are leveraging the vulnerable component, notify the impacted teams for remediation, and potentially implement temporary controls such as a web application firewall that might mitigate the zero-day until the application itself is repaired. In any case the SOC will closely monitor those applications until a patch is released and implemented.
4. Supplier Security: Supplier security teams aim to reduce the risk of applications introduced into the enterprise via third parties. Many large organizations have separate teams dedicated to supplier security, but the benefits of using an SBOM are the same regardless of who is performing the task. Whether the supplier is providing an SBOM of their own or the organization scans the new product with an SCA tool, the SBOM helps the organization make informed decisions about procurement armed with enhanced knowledge of supplier risk. Modern supplier security teams, should consider requiring SBOMs from their software vendors as a contractual requirement. Legal departments can assist with such language and are often the consumers of an “open source license report”.
5. Developers: Developers build applications. As with all other application security activities, one of our chief goals as security professionals should be reducing friction with our partners in development. SBOM generation only relies on static files created by package managers, and it can be seamlessly integrated into Continuous Integration / Continuous Development (CI/CD) pipelines. Each time a developer pushes code and generates a new build, an SBOM can be sent to the central repository for consumption by other stakeholders. But in addition to the low friction in addressing security use cases, SBOMs save developer time as well. Developers often times face difficulties in managing dependencies and ensuring the packages they utilize are in-line with code standards. Utilizing an organizational SBOM, developers can ensure their libraries are approved and eliminate rework caused by having a feature flagged for sourcing from restricted libraries. Moreover, during early SDLC stages architects can help developers by reviewing SBOMs to identify components the organization is moving away from.
6. Internal Audit: Audit teams may be tasked with confirming that the organization is complying with regulatory or internal directives to use open source software that is free of vulnerabilities or does not violate licenses. Having SBOMs saves significant work both for the teams being audited as well as the auditors who seek evidence of what software components were used when, and by whom.

More groups across an organization can make use of SBOMs to reduce risk than listed above, but the list above is plenty to start with. With so many stakeholders that might be involved, who kicks off such an initiative? As alluded to above, the Application Security teams will drive initial effort by developing the broader SBOM program and prioritizing when these other groups may become involved over time. As with most things, the skills required are not just technical but include people and process, and Leadership should expect reporting on an appropriate schedule that justifies return on investment.