Did you miss the Chainguard Twitter Spaces yesterday? Have no fear, we have curated the top questions asked with answers from our Chainguard experts. You can also listen to the full recording here.
Thank you to everyone that tuned in and asked these great questions. If you missed the event or didn’t know about it, we encourage you to follow us on Twitter @chainguard_dev. We will regularly post details about upcoming Chainguard Spaces and virtual events.
With Log4J fading into history, what keeps companies (beyond the CISO) continuing to have interest (and funding) in this space?
Is log4j fading into history? Recent research found that 72% of organizations are still vulnerable to log4j. Log4j is endemic and it's going to be around ~forever. It will remain in every attacker's toolbox and continue to be used to gain access or for lateral movement for the foreseeable future.
It is this reality alone that keeps companies continuing to have interest in this space. Open source software is ubiquitous – it is found in 98% of code used today.
Another reason they need to care is because governments around the world have started to pay attention and identify this as a critical area for focus and support. From the White House Executive Order to the EU Cyber Resilience Act, we are seeing an unprecedented amount of attention on securing the open source software ecosystem. There is a lot of work that still needs to be done but I am hopeful we will see even more progress towards securing open source software in the coming year. - Dan Lorenc, CEO and Co Founder (@lorenc_dan)
Does build time SBOM mean SBOMs as part of the package format? What ecosystem do you think has this? Maybe Maven?
Yes, a true “build-time” SBOM means the build tooling itself is responsible for producing an SBOM as an output containing the builder’s view of the code, either as part of or adjacent to the package. I’m not aware of an ecosystem that produces true SBOMs this way, but Go is probably the closest at this time. Since Go 1.18, a full list of dependencies (with versions and checksums) is included in the compiled binary by default.
A build-time SBOM also denotes the moment it was generated. Other tools acting in the same context and specializing in finding other kinds of data can enrich the SBOM or produce additional documents containing information only available during that specific step of the software lifecycle. - Dan Luhring, staff software engineer (@danluhring)
Can you talk a bit about VEX and how it can help improve the evaluation of vulnerabilities in apps and images?
A piece of software can contain a component with a vulnerability yet not be vulnerable itself. This can, for instance, be the result of certain configuration settings that render the vulnerability inapplicable or mitigations set in place by the software authors or packagers. This fact is the motivation behind VEX, which is a DHS initiative under CISA. Vulnerability Exploitability eXchange (VEX) is a data format that lets upstream software producers inform downstream software consumers whether a given vulnerability affects the software application in question.
With VEX, a human can let other people (and security scanners) know that a particular vulnerability affects (or not!), a piece of software. VEX can also reverse a previous impact statement when applicable if, for example, mitigations are set in place or vulnerable code is simply not executed. Experts assessing impact can capture their findings, along with their reasoning, in a machine-readable format that tools down the stream can consume to make a more precise, less noisy vulnerability report. More on this here and here. – Adolfo García Veytia, staff software engineer (@puerco)
Do you think there will be more of a move to build time SBOMs next year and fewer “GuessBOMs” (when an SBOM gets built with an SCA tool post-build)?
We hope so! We’ve done some experiments to show that SBOMs generated by trying to reverse-engineer the artifacts have severe limitations. SCA tools have been around for a while and if they worked well enough this would be a solved problem and we wouldn’t need SBOM standards. For an SBOM to be useful it has to have more information than you are able to devise from the final output. Creating SBOMs as part of the build where you have access to source code and more information about the process is pretty critical. The fact that we don’t see a lot of build time SBOMs currently is due to the fact that the use of SBOMs is pretty limited, especially for determining inventory or for vulnerability management. - Tracy Miranda, Head of Open Source (@tracymiranda)
Merging SBOMs: trying to create a whole system SBOM; the goal is full provenance across all software running on IoT devices that run containers. I am using a # of diff tools to generate CycloneDX format SBOMs, is anyone aware of any tools that can merge them together and create a ‘SuperSBOM’ (one gigantic SBOM)?
This is something we are working to solve at Chainguard. In fact, we are building a SBOM Composition Tool that will help us generate complete SBOMs and is format agnostic.
Previous attempts to solve this problem have been focused on merging or adding SBOMs together. But in many cases, especially as software builds flow from stage to stage, elements in an SBOM need not to be added or merged. The need to be selectively chosen and relocated from one SBOM to the next.
Recomposing SBOMs involves semantic understanding of the documents and cross format translation, which are potentially hard problems to solve, but writing open source components and libraries is the way to solve it, merely sitting down to contemplate the complexity will not get us there. Like the problem of recomposition, the endless flow of SBOMs organizations are starting to face will require agility to work with the data, but handling a multitude of SBOMs should not be much harder than wrangling other kinds of massive datasets. - Adolfo García Veytia, staff software engineer (@puerco)
In 2023, how do we see containers being built securely?
Thinking about it from a “CVE Zero” angle, you want to do two things:
1. reduce your dependencies - the amount of software in your containers - as much as possible;
2. keep everything up-to-date - rebuild with new versions constantly.
This is exactly the approach we take with Chainguard Images, which are stripped down as much as possible (many of them don’t have a package manager or shell) and are built using our Wolfi distribution, which is constantly updated with new versions and patches for software. - Adrian Mouat, product manager, Chainguard Image (@adrianmouat)
Did reading this Q&A leave you with a question of your own? Or a comment to a response? Bring your question or comment to Twitter or LinkedIn and we will get it answered for you.
At Chainguard, we are committed to tackling software supply chain problems by providing developers and security leaders with the tools needed to build software securely proactively, not reactively. Interested in learning more, get in touch today!
