How Our Business Complies with SBOM Recommendations

Effectively implementing SBOMs can be challenging, but intelligent use of SBOMs should speed up workflow rather than slow it down.

SBOM

The U.S. Executive Order (EO) 14028 on improving the nation’s cybersecurity delivers guidance on software supply chain security and SBOMs (Software Bills of Materials). The guidance includes definitions of what an SBOM is, what information should be contained, and acceptable formats. Organizations use an SBOM to understand the risk of third-party components introduced into their supply chain.

Since our customer base includes numerous federal agencies, when there’s new federal guidance on cybersecurity programs and processes, we always work to implement that guidance internally. We seized the opportunity to re-evaluate how we built our SBOM, where we used it, and what actions we took based on it.

In doing that, we found three key areas of opportunity—and used these to turn the SBOM into a critical driver for security and velocity.

Challenge #1: One vs. Many

We quickly realized that we had two scenarios where understanding supply chain risk was important. First, our core application and the base layers or third-party components it relies on. Second, the instrumentation that supports our SaaS environment, such as backups, observability, performance management, and benchmarking.

It did not make sense to generate a single SBOM with everything because just over half of our customers run Mayhem in their environment, so the second category of dependencies and components is irrelevant.

At the same time, we are hesitant to split our SBOM for our internal team. The supply chain for our SaaS version includes the entire stack, not just the application itself. Having an accurate picture of risk requires a single holistic view.

Accordingly, two SBOMs were generated:

  1. One is generated when our customer-hosted installer packages are cut and appended to that package. This SBOM only includes what is in the installer package—Mayhem and its dependencies.
  2. We continue generating an SBOM for any build targeting a release candidate or branch. This includes Mayhem, its dependencies, and the third-party components supporting our cloud.

We drive security and SOC-2 compliance from #2 and use #1 for customer-facing artifacts. This gives our development and security teams a holistic view of our risk, streamlines customer security reviews, and helps us better prioritize where we focus ongoing security improvements.

Challenge #2: Security Noise

Like most application security tools, scans, or tests, an SBOM is only as good as the action it prompts. So, the next aspect we examined was how we handled the vulnerability data that Grype provided. As with any CVE scanning, we encountered significant noise ranging from false positives to parts we do not use. A majority of the results didn’t impact our actual risk.

The problem was simple: how do we prioritize remediation efforts on the actual reachability of a CVE? Typically, this requires involving developers or architects during triage to prioritize the central issues based on their knowledge of application architecture.

In our case, we built a profiling tool that uses observability data to turn static SBOMs into runtime-aware dynamic SBOMs, but the principle is the same. By focusing on reachability, we reduced remediation tickets by 60% and ensured that remediation had a net positive impact on security posture.

Challenge #3: Technical Debt

SBOMs can be overwhelming, especially when you are building microservices. I mean—“micro” is in the name—how can the supply chain have this many dependencies?

The amount of dependencies in the supply chain is the biggest blessing of the SBOM, not a curse at all. In every architecture review, we open our SBOM and ask hard questions. Can we change the base layers? Should we go “distroless” for this image? Can we use infrastructure features vs an application feature?

There is no definite answer to these questions—it depends on the service, the need, and the tradeoffs. By using the SBOM as a starting point for driving these conversations, we’re staying ahead of technical debt in a better way than before. We are doing forward-looking optimization instead of addressing dependencies reactively.

Wrapping it up

Effectively implementing SBOMs can be challenging, but intelligent use of SBOMs should speed up workflow rather than slow it down. By customizing your SBOMs for different scenarios, you can better manage security noise and have more informed conversations around software components.

In the end, we were able to use SBOMs as a tool that improved our security posture, increased our development and release velocity, and streamlined compliance processes and customer security reviews. For a DevSecOps tool, that is no small feat.

Josh Thorngren

Josh Thorngren is the Security Strategist at Mayhem. In a past life, Josh was a developer turned DevOps engineer. He’s spent the past decade advising and leading marketing teams at Dev(Sec)Ops companies such as Puppet, Twistlock, and Torq.


Zebra Workstation Connect
Josh Thorngren

Josh Thorngren is the Security Strategist at Mayhem. In a past life, Josh was a developer turned DevOps engineer. He’s spent the past decade advising and leading marketing teams at Dev(Sec)Ops companies such as Puppet, Twistlock, and Torq.