Best Practices for Integrating SBOMs into DevSecOps

When your organization is selling software in a regulated industry, you need to provide your customers with a software bill of materials (SBOM).

An SBOM is essential; it provides visibility into the components that make up your application and your customers need that visibility when they’re completing their due diligence.

Unfortunately, SBOMs aren’t always completely correct. Sometimes an SBOM is outdated, sometimes a manual SBOM includes mistakes, and sometimes component code has been modified by developers. 

Because a reliable SBOM is so important, it’s critical to integrate SBOM directly into your DevSecOps process.

Over the last several years, developers have increasingly reused code from open-source software (OSS) projects.

Using OSS code is generally a win-win; development is sped up because engineers don’t have to reinvent the wheel, and  because OSS is publicly scrutinized by multiple parties, the resulting code is usually more reliable. 

However, problems can arise. Our research shows that although developers copy and paste code, they often don’t leave it as is - 95% of the time developers modify code in order to make it fit their project’s needs.

‍Most scanners only identify those changes 10 percent of the time.An incorrect SBOM is a problem for both you and for your clients: it can give customers a false sense of security or compliance, leading to missed vulnerabilities. It can also damage your customers’ trust in you and slow down the sales cycle.

Best practices for building SBOMs into your DevOps

Building SBOMs into your DevOps process is essential for creating secure, compliant, and resilient software without slowing down delivery.

Doing so lets you catch vulnerabilities early, keep documentation up to date, and keep on top of compliance. Here are some best practices for integrating SBOMs into your development process: 
1. Leverage automation: Manual SBOMs are likely to introduce errors. By automating the generation of SBOMs in your CI/CD pipelines for every build, you can create complete, accurate SBOMs.

2. Standardize: Consistency is key. Make sure everyone in your organization is using the same format, and choose a widely supported SBOM format like CycloneDX or SPDX.

3. Keep everything together: Store SBOMs with artifacts; attach SBOMs directly to container images, binaries, or packages. Everything should be versioned and easy to trace. 

4. Enforce your policies: If you have policies in place, make sure you’re abiding by them. This means blocking a build or deployment if there’s no SBOM or an SBOM fails validation.

5. SBOMs should be accessible but secure: Store SBOMs in a centralized, searchable, access-controlled location where they can be accessed by stakeholders. 

6. Keep up with regulatory requirements: Track SBOM-related mandates and make sure your documentation is aligned with any updates.

7. Use an accurate scanner: It’s important to find a scanner that detects the slightest discrepancies. Apona scans code across file, component, and function, detecting partially changed or completely structurally changed components and identifying OSS with 91% precision.

Accurate SBOMs give customers the transparency they need when engaging in due diligence as part of third-party vendor risk management. Apona’s high-fidelity SBOMs enable software companies to build customer trust and loyalty during the due diligence process by providing advanced visibility into and documentation over ecosystem security. Ready to see it in action? Give it a try today.