在我们的 以前的文章, we outlined what a software bill of materials (SBOM) is, how it is created, and what the benefits are of creating and using SBOMs. This is part of our series of blog posts 十大网博靠谱平台 security of the software supply chain.
在这篇文章中, we’re going to look at what to do with an SBOM, and how to establish whether there are any potentially damaging vulnerabilities (security flaws) lurking in the code that it catalogues.
你已经 received an SBOM. 那么?
你已经 received an SBOM alongside a code package, or you’ve received an updated SBOM for a product already in use. You now have more information than you would have had before 十大网博靠谱平台 components of the code you are using (or are planning to use).
Ideally, you will want to check that code package for vulnerabilities. New vulnerabilities arise all the time, so this is likely to be an ongoing process.
You could do it manually, comparing the components listed in the SBOM with publicly available lists of vulnerabilities (例如 at www.cve.org ). This is likely to be both time-consuming and difficult, so you will probably do it automatically, using one of the many tools available; the SBOM is designed to be machine readable.
By doing this, you may discover that there are multiple vulnerabilities. 其中大部分, 然而, are likely to be irrelevant: 例如, though there is an identified vulnerability (X) in component Y, the code package being considered is not affected by X. Unless you are very familiar with the structure of the code, you are unlikely to be able to quickly identify which are irrelevant, and which are problematic—and this could be a very significant task.
You might think at this point that all the SBOM is doing for you is making more work—but there is a way forward.
Vulnerability disclosures
Software suppliers can provide you with information 十大网博靠谱平台 vulnerabilities that their product is known to have, 使用VDR, and about those that it is known not to have, 使用烦恼:
A VDR (vulnerability disclosure report) is a list of known vulnerabilities within the associated code package and is published by the software vendor. There is no specified format, but it should list the vulnerabilities, details 十大网博靠谱平台m, the likely impact—what an attacker might be able to do as a result—and recommended actions to take.
A 烦恼 (vulnerability exploitability exchange), also provided by the software vendor, is intended to reduce the number of irrelevant alerts, so you can quickly identify and focus on those vulnerabilities that could be a problem for you.
Both have their place, but today we will focus on the 烦恼.
什么是烦恼?
Where the SBOM is a list of what is in a package, the 烦恼 indicates which vulnerable components in that package could, 在实践中, be used by an attacker.
比如VDR, it is a security advisory issued by a software creator describing the vulnerability status of their product. 不像VDR, it is machine readable, built for integration into security management tools and vulnerability tracking platforms, and intended to support more effective use of SBOMs by clarifying whether the vulnerability identified by the SBOM is likely to affect your business.
Not every vulnerability in a package can be exploited by an attacker. The 烦恼 shows which vulnerabilities are in the package and—importantly—the status of that vulnerability. This includes whether each vulnerability in that specific package can be exploited by an attacker—and therefore whether it is a risk to your business—and provides information about the actions the supplier is taking, and/or the action they recommend to you.
By removing the false positives from consideration, a 烦恼 helps reduce the vulnerability management workload for your business and helps prioritise the actions needed.
什么是在一个 烦恼?
The 烦恼 issued by the software supplier should contain the following types of information:
The product name and version it applies to, with a product identifier, so that you should know exactly which product is relevant
Vulnerability identifiers, and possibly descriptive information, so you can find out more about each vulnerability
The status of each vulnerability listed: affected / not affected / under investigation / patched. This is so you know whether that vulnerability can be exploited in that product, or whether to expect more information from the supplier once investigation is complete
If the status is ‘affected’, then an explanation of a potential mitigation for the vulnerability. For example, recommendations to upgrade, or where to find a patch.
If the status is ‘not affected’, then an explanation of why the product is not affected. 这可能是, 例如, because the vulnerable code is not executed by the product, cannot be triggered by an attacker, or there are mitigations already in place.
A timestamp for the 烦恼.
There may be other information included, such as the related SBOM details.
What is the point of 烦恼?
The point of the 烦恼 is to speed up the identification of vulnerabilities in reused components in code, to reduce false positives (and therefore reduce the workload).
It provides actionable information to support the management of software supply chain risk.
As you can see from the image below, the SBOM may provide you with more information, but you need more information to be able to do something useful with that information—and that is what the 烦恼 is intended to provide.
The SBOM + 烦恼 together provide a list of exploitable vulnerabilities in your software package. This means you can assess the risks of each vulnerability to your business and decide what action you will take to mitigate each risk.
是什么? benefits of SBOM / 烦恼?
The obvious benefits of implementing SBOM and 烦恼 are:
In general: the standardization of information about the components of software, and therefore also transparency for the consumer of the software.
For the consumer: understanding what exploitable vulnerabilities are in the software you are using, and therefore what the risks are to your business. You can then establish how you will mitigate them.
For the developer: the ability to identify and mitigate vulnerabilities in the code being developed—improving the security of the product.
Additional benefits include the potential for:
Faster incident response (because you have more knowledge of the vulnerabilities)
Improved vulnerability management / patch triage (because you can take a risk-based approach)
Provision of evidence for stakeholders conducting due diligence into your business (because you have more information)
Improvements in customer service
Better completion of software licence tracking and verification
And possibly the reduction of penetration testing required (or at least, the fine-tuning of testing) because you will have more knowledge of the vulnerabilities in the code.
在本系列中, we have discussed SBOMs and 烦恼 to explain what they are and the purpose they are intended to serve in supporting security in your business:
If you’d like more information, or to discuss how CSP could help you with the security of your supply chain—or any other cyber security issues that are worrying you—contact us on 0113 5323763 或者通过 webform.
