Never Miss a Beat: Get a snapshot of the issues affecting the IT industry straight to your inbox.
Why Software Supply Chains Matter
As software continues to become more complex, software bills of material are more important than ever.
6 Min Read
YAY Media AS via Alamy Stock
Software bills of material (SBOMs) aren’t a new phenomenon, but their necessity continues to increase. Software continues to become more complex as developers add more open source and third-party code to their applications than ever before. Meanwhile, greater regulation is increasing, necessitating the need to know where software components came from, who created them, when, for what purpose, and the version number.
Given the constant push to release software ever faster, software versions are constantly changing in ways developers can’t control.
“It can be costly for [many] reasons to not [understand] your software’s composition through something like an SBOM. This includes vulnerabilities, license usage, indicators around complexity, violations of engineering policies or any number of things related to software composition,” says Michael Lieberman, CTO and cofounder at software supply chain transparency Kusari in an email interview. “An important piece is SBOMs don’t need to exist in a vacuum. They are an open standard that lets organizations not just understand risk associated with a single piece of software but can be used to better understand risk across multiple pieces of software.”
Software dependencies are another reason to use SBOMs.
“Given that almost no developer sees every single line of code that each dependency brings into their application, it is more critical than ever to have multiple paths to the discovery of new threats infiltrating our software supply chains,” says Eric Fourrier, CEO at automated secrets detection and remediation platform GitGuardian, in an email interview. “SBOMs, particularly living ones, can help security teams monitor new issues and act swiftly when a new exploit is found and reported.”
Compliance is also a driver.
“One of the primary compliance risks associated with BOMs is ensuring that all components used in the software comply with their respective licenses. Different open-source licenses have different requirements, ranging from permissive licenses, which allow extensive use and modification, to more restrictive licenses, which require derivative works to be released under the same license. Failure to comply with license terms can lead to big legal consequences for organizations, including lawsuits and fines,” says Justin Reock, head of developer relations at internal developer portal provider Cortex IDP, in an email interview. “To mitigate these risks, companies must implement robust processes for creating and maintaining accurate BOMs, conducting regular vulnerability assessments, managing licenses effectively, and ensuring compliance with regulatory and contractual obligations throughout the software development lifecycle.”
AI Helps Understand Software Ingredients, but It’s a Risk
AI is being embedded in all kinds of applications, and SBOMs are no exception. Coupled with automation, AI makes it fast and easy to understand what’s in an SBOM while GenAI makes it easy to interrogate SBOMs, though one should not trust the results blindly.
“Some AI models have shown that they can be good at summarizing data. So, if you have a set of SBOMs, they can potentially help read through that data and provide a human summary of it. However, be careful as they can be prone to inaccuracies, and it’s critical that they are used to supplement other tools and help explain, but not used in making decisions without additional gates,” says Kusari’s Lieberman. “On the other end, AI is an enormous supply chain risk. In the case of both traditional open source and vendor software you can trace back that software in most cases. It is currently difficult to trace back an AI model to the data it was trained on. This leads to both security risks due to being trained on potentially malicious data [and] other liabilities if it turns out the models are trained on biased or illegal data.”
AI-generated code is also a risk to consider.
“We have seen developers come to trust AI-produced code more and more. The fear is they are growing complacent that the results are good enough to ship to production without deep scrutinization,” says GitGuardian’s Fourrier. “Without diligence into every line of code that AI produces, packages that AI simply make up and which bad actors have capitalized on are going to continue to be a growing threat. SBOMs are one more tool we can leverage to maintain vigilance.”
Sage Advice
Organizations that are not using SBOMs are wise to get started, now.
“It’s simple, start recording as much data as you can about the software you pull in. Generate SBOMs, static analysis scans, and software build attestations like in-toto/SLSA to get started. Ask for SBOMs from your vendors and seek them out in open source while also checking if the data in the SBOMs you consume is complete enough to be useful, says Kusari’s Liberman. “Data is the most critical piece of the puzzle. You might be developing and using software securely, but if you don’t have the data, you won’t have the visibility into what you’re missing and what to do when something unavoidable happens like the next log4shell.”
Mike Lyborg, CISO at AI enhanced security automation company Swimlane, warns that organizations should be careful not to overshare their SBOMs because bad actors can use them for nefarious purposes.
“They can very quickly see there’s a critical path. Software A, B, and C are using this, so they could reduce the scope of their reconnaissance activities,” says Lyborg. “Nobody can pick up your SBOM and copy your code base. That’s not the risk. The risk is it potentially being a roadmap for a bad actor, and if you’re not really changing your application stack, it’s just a continuous dissemination of any possible vulnerabilities that may be associated with the dependencies in the supply chain.”
Finally, make sure that the use of SBOMs is not a check-boxing exercise. Otherwise, one may forfeit the benefits.
“If you don’t know what you’re running and you don’t care, you may have bigger problems,” said Ville Aikas, co-founder and software engineer at open-source software supply chain security provider Chainguard. “One of the reasons [to have an SBOM] is to understand whether you’ve been affected by a vulnerability. The other thing is that sometimes there are pieces of software that aren’t being maintained anymore. If the software isn’t being maintained, then I need to find an alternative or start maintaining it myself.”
About the Author
You May Also Like
More Insights
