Know the ingredients of your software—the components, parts, and interdependencies—to protect yourself, your customers, and your software supply chain. Alex Ryback, director of product management at Revenera, shares how software-optimized bill of materials (SBOM) with cloud-based inventory management supports monitoring and alerts for specific problem areas.
There is a growing awareness these days about the ingredients in our food and the harm they can cause. Collectively, we are careful about what we use and offer. We look for allergens that are ingredients in recipes, avoiding things like gluten, which lurks in many ready-to-eat foods because it causes gastrointestinal distress in a friend with celiac disease. We read labels to see if a protein bar contains peanuts, which many young children are sensitive to.
Likewise, awareness of the ingredients in our software is growing. We would not knowingly use components that put our customers and ours software supply chain in the risk group. But if we don’t remember and don’t know what ingredients are in our software, it’s very difficult to protect ourselves from the harm they can cause.
Software contains a large number of components, parts, and interdependencies. It is necessary to effectively reduce the security risks associated with the use of the software; the licenses associated with the components must be complied with. Knowing the provenance of all elements in a product is critical, whether those elements originate from within your team or outside of it through third-party code, including open source software (OSS).
You will not serve food if you have reason to believe that it will harm those who consume it. And you shouldn’t release software that isn’t secure. The best way to ensure security is to keep an up-to-date “ingredients list” of all the components of your software – the software bill of materials (SBOM).
The role of SBOMs
A software bill of materials is a formal and queryable record that details and interrelates the various components used in the creation of software, including open source software and all third-party input software. The inventory provided by SBOM is a critical element of a secure software development frameworkhelping to identify vulnerabilities during software development and then playing an ongoing role throughout the life of the software.
Parts of software are contributed to applications from a variety of unregulated sources: vendor code, partner code, open source projects, and proprietary development. Developers often use code (open source and third-party code) from a wide variety of sources that do not have the same input controls and validations that apply to commercial off-the-shelf (COTS) software. Open source and third-party code comes from well-known ecosystems (such as the Apache Software Foundation and the 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 enter your organization through individual developers around the world who post their code to popular source code repositories like GitHub or GitLab.
Being able to access the innovations and knowledge reflected in this code is often beneficial to users. It also presents an important question to address: What is in your code? Here, SBOM shines.
With SBOM, software companies can identify:
- The components – the ingredients – in your software,
- Where do these components come from (their origin),
- License information for each component,
- The security vulnerability status of your software (and the devices it runs on),
- What parts need to be evaluated and fixed (and where you are in the process), and
- You must deliver compliance artifacts (other than SBOM) to your customers and partners.
The National Telecommunications and Information Administration (NTIA) has outlined a minimum of SBOM items, such as data fields (name, license, and version). Industry-wide initiatives (such as CycloneDX, OpenChain, and SPDX) are working to standardize the format for SBOM; currently, SBOMs are created and maintained in different formats, which sometimes creates problems when comparing or compiling SBOMs.
Optimize your SBOM
As SBOMs become mainstream, one of the keys to using SBOM effectively is complete visibility across multiple sources of information. SaaS-based SBOM provides a unified approach to inventory management, ingesting and aggregating data from multiple sources, providing clarity on security and legal risks associated with licenses and non-conforming parts.
An optimized SBOM with cloud-based inventory management becomes a constant source of truth and business intelligence, providing an actionable view that supports monitoring and alerts for specific problem areas. Obtaining data from multiple sources (internal and/or from partners, vendors, and suppliers) to identify and record all third-party intellectual property (IP), it consolidates and reconciles internal and external SBOMs from multiple sources and formats. from the entire organization into a single normalized view. The information you receive – about component or license usage and security and vulnerabilities – means that if a license proves to be problematic due to incompatibilities or if a vulnerability is discovered, you can take action to fix the problem.
This approach to your SBOM helps more than just your organization. It provides reliable compliance artifacts that you can provide to your customers and supply chain partners. Not only does this demonstrate the security of your software, but the transparency of your products can help strengthen your business relationships.
Centralized cloud-based SBOM management, as part of a comprehensive software composition analysis (SCA) program, enables your organization to do much more than identify the components used in your software. This facilitates ongoing policy management, risk management initiatives and license compliance programs. With this information, you are better equipped to manage resources, knowing where and how to direct staff resources for development and/or necessary remediation when a new security vulnerability is identified as an ingredient in your applications.
Don’t let one ingredient ruin your software
By having a catalog of all the parts of your entire enterprise, you’ll have unified data to identify your exposure—whether it’s from code you’ve developed or software components brought in from outside your organization. You’ll have the information you need to help you fix issues in a timely manner, rather than wasting valuable time trying to determine if a vulnerability applies to you. Proactively identifying software license and security risks helps ensure that one compromised component doesn’t break your software or jeopardize your role in the software supply chain.
MORE ON SBOMs:
https://www.spiceworks.com/tech/devops/guest-article/how-sboms-protect-your-code/ Know what’s in your software: how SBOMs protect your code