SBOM Problems and Inaccuracies Can Hamper Usability
Overcoming SBOM problems can be challenging. But the value of an SBOM – also known as a Software Bill of Materials – is generally undisputed: They provide much-needed visibility into the details of open source and proprietary software components and the supply chain. Their intent is to give developers, buyers, and operators a better understanding of the supply chain so organizations can better track known or emerging vulnerabilities and risks.
Armed with this information, they can also enable the appropriate level of security and make informed choices about supply chain logistics and acquisition issues. This is key because supply chains are more frequently being targeted by sophisticated threat actors for malicious cyberattacks. But drafting an SBOM can be challenging, and if not done correctly, can limit their usefulness.
How Inaccuracies Arise in SBOMs
Like many technologies, the human element comes into play with implementing an SBOM. The onus is on the developer to incorporate information and if they only add certain files, functions or lines of code from third-party software, that will not only make it difficult to draft an SBOM but render it incomplete and inaccurate.
Software components are not vulnerable in and of themselves; they’re only vulnerable based on how they’re being used within the software. For that reason, it’s not ideal for a user to rely on an SBOM to trace vulnerabilities because the component being examined may only be vulnerable if it’s used in a particular way. That is why context pertaining to its use absolutely must be included in the SBOM; otherwise, users will be misguided and that could raise a false red flag.
It is not only a challenge to trace components to incorporate into an SBOM, but it is also a time-consuming process. Further, training staff on using a tool to create an SBOM that follows the guidelines also takes time. It is not a good idea to skimp on these steps.
Detractors say that SBOMs attempt to solve the problem of not being able to rely on vendors to provide accurate vulnerability information about components. “And we are solving this by requiring those same software providers to supply low-precision, high-noise intermediate data that can be used by consumers to later request the information that they needed in the first place — third-party component vulnerability assessments — from the very same providers that could not be relied upon to produce it in the first place,’’ observes security engineer Alex Gantman of semi-conductor company Qualcomm.
How to Make Your SBOM Better
What’s the solution? If you want to rely on an SBOM as the authoritative source of truth, it must be made more accurate through diligence in incorporating information.
The bottom line is, there can be no complete view of the software an organization is using unless accurate provenance data is entered into whatever SBOM format it opts for. This includes including information about the identities of all authors, the tools developers use, the security posture of the development team and attestation about the artifacts.
Perhaps the most significant way SBOMs can be inaccurate comes down to the fact that they are generally static and don’t provide ongoing truth, if you will. Throughout the SDLC, versions change, new components are added and some are removed.
For an SBOM to be truly useful, it should be dynamic with the ability to be continuously updated in an automated way. Without these considerations, you cannot be sure the SBOM will adequately secure your software supply chain.
Let Us Help You See it All Clearly
We can help you make your SBOM better. Create an instant inventory of all the software components in your environment with Rezilion’s SCA and Dynamic SBOM. Book a demo and learn more today.
