SBOM: Unlocking the Power of Software Bill of Materials in DevOps
Solutions Review’s Expert Insights Series is a collection of contributed articles written by industry experts in enterprise software categories. Curtis Yanko of GrammaTech takes a closer look at the next killer app– the software bill of materials, or the SBOM — and unlocking its potential in DevOps.
In the constant struggle against software vulnerabilities and supply chain attacks, the software bill of materials (SBOM) is often touted as a “killer app” that enables all sorts of best practices for secure software development. But even as SBOM use becomes an industry standard, there’s much discussion about why and how they should be used.
Let’s start by agreeing to one basic tenet: a software bill of materials is very useful for development operations. In fact, it’s become a requirement since the federal government issued Executive Order 14028 and the Office of Management and Budget’s memo M-22-18, which made them a must for software developers doing business with the federal government. At its most basic, an SBOM is just like any bill of materials, a list of the components in a finished product— in this case, a software program or app. In case of trouble, software developers can zero in on the cause and remediate the issue.
After large-scale supply chain attacks like the SolarWinds incident, the government was pressed to act, but meeting a government mandate can turn into a box-ticking exercise if users don’t grasp the fine points of the practice. At the recent SBOM-a-Rama meeting held by the government’s Cybersecurity and Infrastructure Security Agency (CISA), industry professionals remarked the development of government standards is slow, and industries will have to step in to develop data naming quality standards that will enable establishing best practices and automate the production of SBOMs. Some attendees at the CISA meeting even pondered forcing the government’s hand by neglecting to meet the SBOM requirements until the authorities issue standards. But SBOMs are already helpful to DevOps in use cases that go far beyond regulatory compliance.
[box style=”3″]
In the market for AppSec solutions? Check out our free Buyer’s Guide!
[/box]
Efficiency And Productivity
Open-source libraries have been a boon to DevOps, allowing greater agility for developers, who are often asked to do more with less and do it faster. At a time when software development still struggles with a talent shortage, it lets teams do their jobs without having to reinvent the wheel every time they must write code.
However, many developers are relying on code copied from libraries that could leave security gaps easy for bad actors to exploit. The Log4J vulnerability was a notable example: the Apache Log4J library — an open-source software that runs everything from serving the “404 error” to logging routine events — had a zero-day vulnerability that lets attackers take over devices.
Even if the code is safe, organizations may still be wary of running into licensing issues by reusing code from libraries. Managers often don’t understand open-source licensing, and fear using open-source code may affect their own intellectual property rights or run into legal issues.
In a way, open-source has been a blessing and a curse; while it speeds up the development process to match the speed of business, it can turn some programs into black boxes of code. An SBOM provides enough information to enable developers to use open-source in a way that the organization can be comfortable with.
Greater Transparency For Customers
We live in an age where customers are demanding more information about the products they use, especially regarding the software they are deploying to run their business. They want updates and want visibility to build trust in the relationship. In the case of partnerships and vendors, that transparency may be integrated into requirements that are part of procurement processes.
SBOMs enable developers to address hidden elective risk, which acknowledges that when users bring in a piece of software into their environment, they understand it may contain vulnerabilities that create an exploitable attack surface. If you are a grocer, you want to know all the ingredients in your salad mix, so if there is a recall on romaine lettuce, you will know if you got some of that bad romaine. In the same way, having an inventory of what open-source components are in the code that you’re shipping to customers shows them you have the discipline to address any issues.
SBOMs help with traceability and efficient recall management. To give another example, it works like recalls in the auto industry, where the automakers don’t need to inform all car owners about a part that needs replacing, because they already know which makes and models, down to the VIN, where the defective part was installed at the factory.
Feedback-Driven Development
DevOps lives by the mantra of “fail fast, fail often,” which only underlines the importance of early and continuous testing throughout the software development life cycle. Fast feedback early in the process drives much of DevOps, because it is cheaper to fix bugs when they’re caught early and becomes much more expensive later in the development cycle. Having an SBOM can help automate efficiency testing and enable rapid feedback, as well as meeting the compliance and legal policy requirements discussed above.
Secure software development is a two-pronged challenge: not only does the DevOps team have to ship defect-free products, but it also needs to keep it secure over time in the wild. It is great to release a product with an attached SBOM, but do you have the ability to see if a new vulnerability affects it year after year? And if such a back door is found, does it need to be updated and the problem be communicated to users? The answer to both questions is yes.
Updates and patches are considered a frontline defense against software vulnerabilities, and luckily, the National Cybersecurity Alliance found nearly two-thirds of users will install them once they’re told they are available. Of course, when security teams are running around with their collective hair on fire dealing with a massive issue like Log4J, it’s not a good time to communicate with users who may be affected or not. That’s when an SBOM comes in handy.
SBOMs help developers address many of the gaps in old-fashioned total quality management (TQM) frameworks for software development. They ensure the process adheres to compliance and legal policies, such as acceptable license use restrictions, and they can meet internal security requirements, including those imposed by new regulations and partner contracts.
Leveraging SBOMs is part of creating a development framework that drives product quality, velocity, and efficiency, but with quality and security built-in. Security-conscious development is a new mantra for DevOps, and SBOMs can be a key enabler. In the end, they allow developers to fail fast, but fail safely.
Curtis Yanko
Curtis Yanko is Principal Solutions Architect for GrammaTech. He has more than 30 years of experience in software security, and is a contributing member of the OWASP SBOM Forum.
