Best Practices for Developing and Using SBOMs

Solutions Review’s Expert Insights Series is a collection of contributed articles written by industry experts in enterprise software categories.  Eilon Elhadad of Aqua Security establishes some best practices for developing and using SBOMs.

With software supply chain attacks up 300 percent year-over-year, security teams have prioritized securing this part of the application development cycle. While CISOs work to develop and deploy better strategies to secure this area of significant risk, the pressure is on for vendors who sell directly and indirectly to the government to comply with the software supply chain security guidelines laid out in the National Cybersecurity Strategy by September of this year.

Over the past few months, there has been renewed interest in the software bill of materials (SBOM) as it provides visibility into software components and software security levels. In fact, Gartner expects the adoption of SBOMs to go from less than 5 percent now to 60 percent in 2025. Software transparency is imminent from both a federal compliance mandate and market demand. In the public and private sectors, with this new sense of transparency over the components within the software (and thus, the overall security of them), vendors that prove higher security will be preferred over others who are not transparent, so organizations need to take steps now to adjust their SBOM strategies to remain competitive in the software market.

SBOMs: Facts and Myths

SBOMs are a key building block in software security and software supply chain risk management, and provide insight into the makeup of software created by open-source and third-party components. Biden’s National Security Strategy shifted the liability for insecure apps to vendors and called for software providers to deploy more secure software development practices, which lit a fire under federal software suppliers to implement and adhere to SBOM minimum requirements quickly. However, based on the National Cybersecurity Strategy, all software vendors should also take notice and expect to comply with the federal guidelines soon.

There is a misconception that SBOMs are security itself, but this is not the case; they are actually only proof of security and software components. They don’t contain information related to the components’ age, vulnerabilities, or functionality. Instead, they are essentially inventory checklists. For companies that develop software, SBOMs could feel like they are “airing their dirty laundry,” which can be daunting. But, if developers are focused on security throughout the full application lifecycle, the SBOMs won’t be tainted with risk and vulnerabilities, and software developers won’t have to worry about cleaning up their code last minute before it’s released.

Developing and Using SBOMs

We are seeing a shift in the software development industry. The process was once focused primarily on code security, but now organizations are looking beyond that and are incorporating secure development processes and zero-trust infrastructure as part of security best practices. This is largely due to the emphasis on transparency and the evolving security risk vectors; which are now targeting much beyond just code. Customers are demanding it, there are federal compliance frameworks being built around it, and it will be a key competitive differentiator for software vendors if they can get it right.

In order for vendors to develop and use and SBOMs correctly, the following should be taken into consideration:

• Create a path to visibility and communicate: It’s important to build a bridge between engineers and security teams in the development process. Ideally, this should be built-in inside of the security technology chosen.
• Secure from the start: Take steps to secure applications from the moment you start developing. You don’t want to delay a software release because your SBOM is full of risk.
• Get the right tools: Find a solution that can generate reliable SBOMs and the rest of the required SSDF artifacts according to industry standards. There are various sets of industry guidelines companies can follow, so be sure to choose the guidelines that are best for security strategy.

Other Tips for Securing the Software Supply Chain

The software supply chain landscape is continuously evolving, and attackers are evolving with it. Incidents such as the SUNBURST attack or Log4J vulnerability shook up the industry and sent organizations scrambling to secure their software development chains.

While the SBOM is a first step to secure the software supply chain, there are three other main areas where organizations should focus to maintain code integrity and minimize attack surfaces:

• Trust your code artifacts: Establish and maintain trust by generating digitally signed SBOMs and implementing integrity gates to validate artifacts throughout your CI/CD pipelines. Ensure only the code you intend makes it to production.
• Secure the dev environment: Secure the systems and processes used to build and deliver your application to production. Monitor the security posture of your DevOps tools to ensure that security controls put in place have not been averted.
• Focus on end-to-end visibility: Scan code and images at every release phase to identify risks wherever they first appear. Shift left to find vulnerabilities, IaC misconfigurations, exposed secrets, and malware and prevent issues from making it to production.

Having an SBOM in place is the first step in transparency. It is an essential element in your security and compliance toolbox to ensure that software is continuously up-to-date and verified, and that the right people are alerted to any vulnerabilities or guideline violations before a problem arises. It is important that vendors get ahead of SBOM requirements and demand now, as the ones who do will be deemed trustworthy and winners in the market.