Everyone in the public sector—and any organization that works alongside them—needs to keep better track of what goes into their software. Last October, the Army’s acquisition office took a small step that could lead to big changes in how the service builds software and wards off network-based attacks: It sent out a request for information about SBOMs.
What’s an SBOM? In its simplest form, a software bill of materials is comparable to a list of ingredients that make up an application or a system. Most modern software includes parts taken from elsewhere, such as open-source repositories or licensed third-party components. An SBOM explicitly outlines those sources, allowing buyers, operators, and defenders to evaluate the origins, vulnerabilities, and risks of a piece of software or an entire system.
But an SBOM can provide more than just a simple list. They can help organizations uncover critical information, examine the components within a piece of software or learn about its version history. This kind of information, and the rules surrounding it, are crucial to network defense. By illuminating the risks associated with chunks of code pulled in from elsewhere, they can help reduce unplanned and unscheduled work, automatically monitor components for vulnerabilities, and ensure software meets security standards before it is released.
But to be of enduring use, an SBOM must be continually updated as software components are added and as vulnerabilities are discovered. In theory, this can be done manually, but in practice, the only way to do this without delays and prohibitive cost is to automate it.
That means new programs and projects must build in support for automatic updates from the very beginning. SBOMs built without automated generation and management capabilities are simply static documents and run the risk of releases and new components being pushed without corresponding SBOM changes—reducing its effectiveness and adaptability.
SBOMs should be built to produce their output in standardized, easy-to-read form, so humans and computers alike can easily glean insights—a dashboard, for example, that sounds an alarm about a vulnerability and suggests a fix. Developers and operators alike should be trained in what to do next.
There are obstacles to the adoption of SBOMs. Agencies and even departments’ use of various tools and software can affect data-sharing and exchange processes. SBOMs success will highly depend on how standardized processes are—a complicated task for teams with constricted budgets and older systems.
Adopting the proper technology is only one challenge, as training will be required. Organizations are learning how to generate SBOMs, what they contain, and how to effectively use them still to this day. In addition, leaders are still establishing requirements to support the broader adoption of SBOMs best as called for in the defense industry’s chief objections to a Senate proposal for the Pentagon to mandate SBOMs—highlighting agencies can expect a learning curve.
Still, the value of SBOMS cannot be overlooked. SBOM functionality can prompt users to create a vulnerability allow list. This capability reduces security attacks by only accepting trusted files, applications, and processes, limiting noise to addressing critical issues. This can help teams identify unknown vulnerabilities introduced when code is pulled from unvalidated sources, assess the risk, mitigate them, and provide additional transparency for those purchasing or developing these applications.
Recent policy changes and executive orders have heightened the importance of security across the defense community and pushed leaders to evaluate and strengthen their supply chain security critically. When implemented effectively and incorporated into functions and workflows, SBOMs are critical to support the industry-wide shift toward increased security and efficiency.
The Army’s recent request for information shows that its leaders recognize the power of SBOMs to secure its supply chains and raise its defenses against cyber attacks. Other leaders should follow suit. Joel Krooswyk is Federal CTO at GitLab Inc.
Comments are closed.