Docker added support for build-time attestations and software bills of materials (SBOM) in its BuildKit tool earlier this year, and that gives development teams a way to maintain a complete record of the build process for each image — and the software components within it.
BuildKit, Docker's build engine for building container images, is an improvement over the company's legacy, script-based Dockerfile build engine. Docker claims that the tool improves build performance and the reusability of Dockerfiles.
While these features are vital to software supply chain security, how much your organization can benefit depends on the quality of the data in your SBOMs, your ability to manage the SBOM inventory and the visibility you have into it.
Here's what you need to know about BuildKit, how to leverage its SBOM capabilities, and its limitations in providing a comprehensive view of your software supply chain security.
[ Key takeaways: Supply chain security risks addressed in new Gartner report | Get the Gartner report: Mitigate Enterprise Software Supply Chain Security Risks ]
Build-time attestation is a key step forward
The new SBOM feature, introduced in the January release of BuildKit v0.11, lets developers generate a list of all of the components in an image, including the package name, version number and associated metadata, such as license type and author.
The build-time attestation feature gives developers a way to answer questions related to Supply Chain Levels for Software Artifacts (SLSA) provenance. This includes data on the files, URLs and parameters used during the image build process and source maps for mapping an image back to the Dockerfile that created it.
Security experts consider such capabilities crucial from a software supply chain security standpoint. An SBOM enumerates all the components in a software product, much as an ingredient list does on food packages. SBOMs make it easier for developers to identify images that are vulnerable to a specific CVE, whether they're the correct version or in need of updating.
Vulnerabilities such as Log4Shell in the Apache Log4j logging framework highlighted in dramatic fashion show just how useful an SBOM can be in quickly identifying and mitigating threats. SLSA provenance is useful in analyzing how an image was built and whether the sources used during the build process were legitimate. Developers can use the build parameters in the provenance to rebuild an image so they can verify that it matches the attestation.
The importance of SBOMs and SLSA continues to grow
Both SBOMs and SLSA provenance have risen in importance over the last two years. A May 2021 Executive Order requires all federal civilian executive agencies to ask for and maintain detailed SBOMs from their external software providers. The order stemmed from growing concerns over threats to the software supply chain in the wake of attacks on SolarWinds, Colonial Pipeline and others.
Richard Stiennon, chief research analyst at IT-Harvest, says Docker's Buildkit update helps developers track and attest to the components in a container.
"Because containers tend to be more ephemeral than, say, delivered software packages, record keeping is even more important. An SBOM attached to each build will be valuable for record keeping and understanding the state of a container if it is identified as having an issue."
—Richard Stiennon
SBOMs are an important component in improving supply chain security that allow consumers of software to quickly identify what vulnerable components they may have deployed when a new common vulnerabilities and exposures (CVE) alert is issued. "This capability within Docker adds depth of granularity," Stiennon says.
The challenge: How to derive real value from SBOMs
The real value that an organization derives from the new features depends on how they use it, says Mike Parkin, technical marketing engineer at Vulcan Cyber.
"If the new features work as intended and produce an accurate and complete software bill of materials (SBOM), then it can be quite useful, at least conceptually. It’s like an ingredients label, letting you know if there’s anything in there that you’re allergic to."
—Mike Parkin
But a lot depends on whether an SBOM is used for its intended purpose or merely to maintain a component list. "It’s like log files. Collecting them is great if they’re ever reviewed," Parkin says. "But if the answer to 'when was the last time you looked at the logs?' is something akin to 'June 2019', it won't do you much good."
An empirical study that university researchers in Australia released in February 2023 identified other challenges associated with SBOM use that organizations must overcome if they want to derive full value from them. The study, based on data gathered from 65 respondents in 15 countries, found that SBOMs enable greater traceability, accountability and security. But they're often difficult to track, use, and manage due to non-standard formats and a lack of interoperability.
The tools for SBOM consumption also need to mature considerably and be more user friendly. Other limiting factors include a lack of consensus on the minimum number of data fields an SBOM must include, and a lack of standards around how to regenerate or enrich SBOM information as a software product evolves.
The Australian study identified SBOM validation as yet another issue. Currently, there are few mechanisms for determining whether an SBOM has been tampered with or to validate the tooling that generated it. The authors wrote:
"SBOM data tampering can come from outside and inside an organization. External tampering is more straightforward, as an SBOM can be easy to tamper [with] and easy to fake without reliable validation methods."
Walter H. Haydock, a non-resident fellow at the Center for Security and Emerging Technology and an author at Deploy Securely, and Chris Hughes, co-founder and CISO at Aquia, wrote in an article on CSO Online that with nearly ubiquitous move to Software as a Service (SaaS), the ambiguity with what's in an SBOM at one point in time to the next "presents a hurdle toward the effective use of SBOMs as a risk management tool."
"In addition to a lack of answers as to what consumers will do with SBOMs once they receive them, it is even less clear as to how to develop them for vendor-managed deployment models such as software as a service (SaaS)."
—Walter H. Haydock and Chris Hughes
A call for SBOM automation, standards, focus
A key problem with most SBOMs is that they represent just a snapshot in time if they are static, said Matt Rose, Field CISO for ReversingLabs. The speed of DevOps pipelines are in direct contrast to static SBOMs. Just like any security solution, SBOMs need to represent the current risk, "or they are just noise."
"If you are releasing application or software updates 10 times a day, then you need to generate new SBOMs 10 times a day in an automated way."
—Matt Rose
Rose worries that static SBOMs could lead to a false sense of security. Additionally, some SBOMs focus on only part of the package. For example, software composition analysis (SCA) tools only look at the open source packages.
"SBOM's have become a hot topic of discussion, but we are still missing a key piece of the equation. What is the format and how are SBOMs being shared? Currently the whole conversation about SBOMs is a bit nebulous, and needs a standard format like Cyclone DX."
—Matt Rose
Richard Hill, director of IAM Research at the analyst firm KuppingerCole, emphasizes in in a recent research post that a comprehensive security approach demands an end-to-end focus on software's development, engineering, release and full lifecycle.
"[When] securing the software supply chain, the journey starts at the security and privacy by design-phase when creating the software system architecture and coding of the design begins, and continues throughout software deployment and lifecycle."
—Richard Hill
[ Related: SBOM: What it is — and why it matters for software supply chain security ]
