.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
Key Questions for Your SBOM Program
All the questions (and some of the answers) you need before kicking off your SBOM program.
All the questions (and some of the answers) you need before kicking off your SBOM program.
All the questions (and some of the answers) you need before kicking off your SBOM program.
All the questions (and some of the answers) you need before kicking off your SBOM program.
All the questions (and some of the answers) you need before kicking off your SBOM program.
There has been massive hype surrounding Software Bills of Material (SBOM) of late.
And it’s understandable due to the potential security benefits they can deliver, along with the probable U.S. government regulatory and legislative requirements that have appeared on the horizon.
With that said, there are some key practical considerations organizations will need to address before an SBOM program can deliver value. Whether you are producing or consuming SBOMs - or both - there are some concrete details to be ironed out before you can start using them effectively.
In this post, we’ll go through six questions you should answer before kicking off your program:
- How will we send, receive, and store SBOMs?
- Which vendors will need to provide SBOMs (or which customers will request them)?
- How frequently will vendors (or we) need to provide SBOMs?
- How will we analyze SBOMs?
- What will we do about vulnerabilities identified in SBOMs?
- How do we use SBOMs for incident response?
How will we send, receive, and store SBOMs?
If an information security analyst on your team sends a mass email to all of your vendors asking them to provide SBOMs, you are likely to get some combination of confused replies, refusals to hand over anything, and a few incredibly detailed JSON and XML files.
Unfortunately, an inbox full of attachments is a terrible way to manage information. Even if you store them in Google Drive, Dropbox, or some other information repository, just having them “sitting on the shelf” will do little good.
Thus, having a way to receive and track your vendor’s SBOMs is absolutely vital before you start asking for them. At a minimum, you will need a structured method to track and version control each individual SBOM. Optimally, you will have a platform that ingest, parse, and analyze the information contained within.
Also important to consider is how the vendors are going to transmit the information. Are they going to push SBOMs via API call? If so, how will they generate or get authentication keys or tokens? How will they test their calls to make sure they work?
Are you planning to use email? If so, how can you assure that every file will be uploaded in a timely manner and access-controlled manner?
If you are the one on the receiving end of an SBOM request, these questions are going to be just as important. So if you see requests for SBOMs in contracts during negotiations with prospective customers, make sure you iron out all of these details before signing on the dotted line.
Which vendors will need to provide SBOMs (or which customers will request them)?
Since resources are always limited, you should first conduct a business impact analysis to understand your most critical service providers and commercial off the shelf software solutions. If your operations rely on data maintained by third parties, which is basically everyone these days, you need to determine what would happen if that data suffers a loss of confidentiality, integrity, or availability.
Map out what would happen in a “worst case scenario,” working with your various business departments to determine what the financial costs of each would be. Since you’ll be capturing a lot of data, you’ll want to make sure this is stored in a structured format and is easily accessible by those with a need to know.
Once you’ve established the potential impact of a breach for each vendor, you can rank them in descending order. Based on your resources and organizational risk appetite, you’ll need to draw a line somewhere as to where to focus your analysis.
For some organizations with stringent security needs, it may be that every vendor with any impact on the former’s data will need to provide an SBOM. For others, perhaps only a certain subset of critical providers will need to.
Also important to keep in mind is the sophistication of your vendors themselves. Are they currently capable of providing you with an SBOM? A highly specialized startup might reasonably explain that they are focusing all of their efforts on solving a particular problem rather than providing detailed representations of their software’s composition. A more mature enterprise vendor, however, should be more capable of providing you what you need.
And of course, if you are on the receiving end of an SBOM request, these are all important considerations for your team as well. If providing an SBOM is light lift, then by all means do it. But if it will be a massive distraction from your primary mission, work with the requestor to understand their security concerns and how to mitigate them.
How frequently will vendors (or we) need to provide SBOMs?
Also important to consider is the frequency with which you will need to provide SBOMs. To use them most effectively as part of a risk management program, your customers may want updates every time the software in your stack changes.
For SaaS platforms, this can be a daily or hourly occurrence. Manually transmitting this information will be infeasible, and the only realistic way to do so will be using automation.
Ensuring you (or your vendors) have sufficient continuous integration (CI) and continuous delivery (CD) infrastructure that can generate an SBOM with every production build, and that they have a way to transmit them rapidly for analysis, will be a tall order. Asking for SBOM “snapshots” of their products at given intervals (daily, every release version, etc.) might be the best way to go in some cases.
If you build or use self-managed (i.e. non-SaaS) software, a less frequent SBOM delivery cadence might make sense, such as with every new generally available version. As part of your internal change control procedures, you can then evaluate the new version’s SBOMs against your security and compliance standards.
On top of these considerations, you’ll need to consider how you will specify and enforce your requirements with the vendor (or respond to customer demands). Will there be a formal Service Level Agreement (SLA) for SBOM delivery as part of your contract? What will the terms be? What will the penalties for non-compliance look like?
Since contract negotiations are an elaborate process that must take into consideration many factors, you’ll need to understand the relative priority of your SBOM program when compared with other business terms in the agreement.
How will we analyze SBOMs?
There are many open source tools available that can identify CVEs and other known vulnerabilities in SBOMs, but we’re guessing you probably aren’t lacking for these types of findings. If you simply scan SBOMs and count the issues you find, you are just going to give yourself another headache.
So the real question is, how are you going to determine the exploitability of vulnerabilities represented by them to determine your risk?
On top of reachability analysis (obviously our favorite) there are several other methods to analyze these findings. The key will be describing the outputs in a consistent and easily consumable format. Whether to meet internal security and compliance requirements or those of your customers, a comprehensive approach to scanning SBOMs - and understanding what they mean - will be key.
What will we do about vulnerabilities identified in SBOMs?
Assuming you have a good idea of the risk posed by the vulnerabilities you have now identified in your stack (by analyzing the relevant SBOMs), what do you do about it?
- Do you have a policy that specifies your risk appetite and tolerance?
- Who has the authority to accept incremental risk above that level?
- Who is accountable for resolving the issues identified?
- What do your contracts with your customers say?
- How will you enforce these requirements?
These things are easy to overlook amidst the SBOM hype, but remember, these tools are only a means to an end.
How do we use SBOMs for incident response?
SBOMs are most valuable as a preventative security measure because they help organizations identify known vulnerabilities that could compromise data confidentiality, integrity, and availability.
Nevertheless, SBOMs can also play a vital role in detection and analysis by enabling security operations centers (SOC) to better understand the relevance of malware signatures associated with specific vulnerabilities in their networks.
For organizations with a comprehensive asset inventory, SBOMs can also help in avoiding false positives by ruling out alerts not relevant to their network. Furthermore, SBOMs facilitate swift communication between software customers and vendors in the aftermath of major vulnerability disclosures, such as log4shell, using the Vulnerability Exploitability eXchange (VEX) format.
Learn about SBOM with Endor Labs
At the end of the day, SBOMs need to improve your or your customers’ security posture to be valuable. Having a comprehensive plan for transmitting, managing, and analyzing them will be key for your program to succeed. Endor Labs Open Source includes SBOM and VEX generation. Because Endor Labs uses your source code as the source of truth, you can have confidence your SBOMs contain every direct and transitive dependency - offering no nasty surprises to your customers. Once your dependencies are mapped, you can generate SBOM and VEX documents that automatically include reachability data, and annotate whether or not an application or library is affected.