Know What Ingredients Are in Your Software: How SBOMs Protect Your Code
The best way to ensure safety is to maintain a current software bill of materials.
Know your software’s ingredients – components, parts, and interdependencies – to protect yourself, your customers, and your software supply chain. Alex Rybak, director of product management at Revenera, shares how an optimized software bill of materials (SBOM) with cloud-based inventory management supports monitoring and alerts for specific areas of concern.
These days, there’s growing awareness of the ingredients in our food and the damage they can cause. Collectively, we’re cautious about what we’re using and serving. We’re looking for allergens that are components of recipes, being careful to avoid things like the gluten hiding in many prepared foods, as it sends a friend with the Celiac disease into gastrointestinal distress. We read labels to see if a protein bar contains peanuts, which many young children are sensitive to.
Similarly, there’s growing awareness of the ingredients in our software. We wouldn’t knowingly use components that put our customers and our software supply chain at risk. But if we aren’t mindful of and don’t know what ingredients are in our software, protecting against the damages they can cause is enormously difficult.
Software contains a large and wide-ranging number of components, parts, and interdependencies. The security risks related to using software need to be mitigated effectively; the licenses associated with the components need to be honored. Knowing the provenance of all the items in a product is critical, whether those elements originate with your team or outside of it, through third-party code, including open source software (OSS)
You wouldn’t serve food if you have reason to believe it will harm those consuming it. And you shouldn’t release software that isn’t secure. The best way to ensure safety is to maintain a current “ingredient list” list of all components in your software—a software bill of materials (SBOM).
The Role of SBOMs
A software bill of materials is a formal and queryable record containing the details and relationships of various components used in building software, including open source software and all inbound third-party software. The inventory that an SBOM provides is a crucial element of a secure software development framework, helping to detect vulnerabilities during software development, then playing an ongoing role during the life of the software.
Software parts are brought into applications from various unregulated sources: supplier code, partner code, open source projects, and in-house development. Developers often use code (open source and third-party code) from a wide range of places, which don’t have the same inbound controls and scrutiny as is applied to commercial off-the-shelf (COTS) software. Open source and third-party code come from well-known ecosystems (such as Apache Software Foundation and Eclipse Foundation) and respected artifact repositories, including Maven Central (Java), NuGet (.NET), npm (JS), PyPI (Python), RubyGems (Ruby), and many others. Sometimes code can also make its way into your organization via individual developers around the globe who host their code on popular sources code repositories, such as GitHub or GitLab.
Being able to access the innovation and knowledge reflected in this code is often beneficial for users. It also presents an important question that must be addressed: what’s in your code? This is where the SBOM shines.
With an SBOM, software companies can identify:
- The components—ingredients—in your software,
- Where those components came from (their provenance),
- License information for each component,
- The security vulnerability state of your software (and the devices in which it runs),
- Which parts require assessment and remediation (and where you are in the process), and
- You must deliver the compliance artifacts (beyond SBOMs) to your customers and partners.
The National Telecommunications and Information Administration (NTIA) has outlined the minimum elements of an SBOM, such as data fields (name, license, and version). Industry-wide initiatives (such as CycloneDX, OpenChain, and SPDX) are working to standardize a format for SBOMs; currently, SBOMs are created and maintained in a variety of formats, sometimes presenting challenges when comparing or compiling SBOMs.
See More: 4 Questions To Evaluate Your Organization’s Open Source Preparedness
Optimize Your SBOM
As SBOMs move into the mainstream, one of the keys to using an SBOM effectively is to have full visibility across multiple sources of information. A SaaS-based SBOM provides a unified approach to inventory management, ingesting and aggregating data from across sources, offering clarity into security issues and the legal risks associated with licenses and non-compliant parts.
An optimized SBOM, with cloud-based inventory management, becomes an ongoing source of truth and business intelligence, delivering an actionable view that supports monitoring and alerts for specific areas of concern. By ingesting data from wide-ranging sources (internal and/or from partners, vendors, and suppliers) to identify and record all third-party intellectual property (IP), it unifies and reconciles internal and external SBOMs from multiple sources and in various formats from across your organization into a single, normalized view. The resulting insights – about a component or license usage and regarding security and vulnerability exposures – mean that if a license turns out to be problematic on non-compliant or if a vulnerability is discovered, you can take steps to remedy the issue.
This approach to your SBOM helps more than just your organization. It provides robust compliance artifacts that you may provide to your customers and downstream supply chain partners. This not only illustrates the safety of your software, but this type of transparency into your products can also help strengthen your business relationships.
Centralized, cloud-based SBOM management, as part of a comprehensive software composition analysis (SCA) program, allows your organization to do far more than identify the ingredients used in your software. It facilitates ongoing policy management, risk management initiatives, and license compliance programs. With this information, you’re better equipped for resource management, knowing where and how to align your staff resources for development and/or the remediation required when a newly reported security vulnerability is identified as an ingredient in your applications.
Don’t Allow One Ingredient to Spoil Your Software
With a catalog of all the parts in your entire enterprise, you’ll have the unified data to identify your exposure – whether from code you developed or from software components brought in from outside your organization. You’ll have the requisite information to help you fix issues in a timely manner rather than wasting precious time trying to identify if a vulnerability applies to you. Proactively identifying your software license and security risk helps ensure that one compromised ingredient won’t spoil your software or jeopardize your role in the software supply chain.
How are you maintaining and optimizing your SBOM? Has it improved your security stance? Share with us on Facebook, Twitter, and LinkedIn.
MORE ON SBOMs:
