Q&A highlight
Posted10 days ago
Key Takeaways
Is it just that the two are used by different communities? What is the SBOM community?
Compliance. The article mentions "the EU’s Cyber Resilience Act will push vendors toward providing SBOMs", and having package managers generate SBOMs directly would certainly be convenient for that.
1) help identify and remediate software that has been built with vulnerable packages (think log4j).
2) help protect against supply chain compromise as the SBOM contains hashes that allow packages to be verified
SBOMs are supposed to help with software composition analysis. Basically, you as an enterprise have an inventory of what software you use, and their SBOMs (i.e. dependencies). I can then use this to automatically check which software is impacted by severe vulnerabilities when they are announced.
Depending on who you ask an SBOM might not need a hash. NTIA only recommend a hash.
So, it's a list of the "software components" that are inside a piece of software. And then you add metadata about each of these components: what's its name? its version? its hash? Up to now we're in lockfile territory.
But you want more information: what is the license? who supplied it? what is the security status? does it have known CVEs? are they relevant?
And then you go to special cases, like "AI" software: oh, it's a model? how was it trained? on which data? Or like software that has to be certified, to be used when safety is important.
An SBOM is capable of providing all this information. Take a look at the different parts that SPDX provides, and it's an ever expanding area.
In CycloneDX you can also express things like attestations/certifications, possibly down to the code review level (although I think nobody does that).
> A software bill of materials (SBOM) declares the inventory of components used to build a software artifact, including any open source and proprietary software components. It is the software analogue to the traditional manufacturing BOM, which is used as part of supply chain management.
Unfortunately, T-V hs been dropped in SPDX 3.0.
SPDX v3 is based on a graph model that can represent hierarchies natively. It can then be serialized in a file, for example, in JSON format.
Most SBOM use cases don‘t need the ability to put your detailed software architecture in the SBOM.
The whole idea is to use specific libraries to produce and consume SBOMs.
You wouldn't expect people to "manually create" JPG images, would you?
Depending on the language, scanning just the container is not enough, you for sure want to scan the lockfiles for full dependency list before it is compiled/packed/minified and becomes invisible to trivy/syft.
To understand what an impossible task this is, there is no need to think about different ecosystems (PyPI vs NPM vs Cargo vs ...). Even in the case of different Linux distributions, the package managers are so different that expecting them to support the same formats is a lost cause.
The newer version, SPDX v3.0, will become ISO/IEC 5962:2026, and work is already underway for further versions.
What is not standardized at all are the integration of processes for producing/consuming/maintaining SBOMs in the software development world.
HTML is standardized too, how many documents do you think use the p or i tags properly? Heck, how many documents do you think are HTML5 compliant, even ignoring the semantics?
(And even if it were, it is still much too bulky of a tool to replace lockfiles. Having to add a kilobyte to your file every time a bunch of new vulnerabilities get reported in your deps recursively sounds like a great addition to your commit history.)
You change the supplier property (and most probably the version). This is how you distinguish between OpenSSL 3.1.4 from OpenSSL project and OpenSSL 3.5.4-1~deb13u1 from Debian project.
> What happens to vulnerabilities that are not in code paths not used by your software, or only under certain flags?
You record this information in the SBOM, using structures like "this software has this vulnerability reported, but it's not affected by it in this case" (see, for example, VexNotAffectedVulnAssessmentRelationship in SPDXv3).
I completely agree that its purpose is not to replace lockfiles.
In other cases you might have a library you depend on, but it's no longer maintained, so it might score really high on risk, meaning that you should probably address that dependency in your next development cycle.
So the SBOM and risk assessment wouldn't necessarily catch vulnerabilities, but it makes it simple to check if you're affect and generally help you manage/reduce your attack surface.
But I think SBOMs are better structured. I also feel that if package managers refocus their efforts on that, the standard and its implementations can be evolved. It’s the whole perk of using standards. I think it would be a good thing
SBOM is too similar to things like authenticode and package signing for it to be some unique solution. We're too used to how things have always been done. Too stuck in the "monkey see, monkey do" mindset. How about any piece of software, under any execution environment should not only have an SBOM declaration, but cyptographic authentication of all of its components, including any static data files.
This should be a standardized mechanism. Everyone is doing their own thing and it's creating lots of insecurity and chaos. Why can't I answer all security-related questions about the software I'm running on any device or OS using the same protocol?
Everyone would consider it absurd if we used a different TLS when talking to an Apache server or a Windows server than alternatives.
SBOM, code signing (originator of the code), capability declarations, access requirements (camera, mic, etc...) are not things that are unique to an OS or platform. And for the details that are, those are data values that should be different, not the entire method of verification.
I wonder what it would take to enact this, I'd imagine some sort of regulatory push? But we don't even have a good cross-platform and standardized way of doing this for anyone to enforce it to begin with.
It shouldn't be for "just" any state of the software. We should be able to verify SBOM and take actions at any point. At build time, it is only useful for the developer, I don't get why SBOM is relevant at all. I think you mean at deployment time (when someone installs it - they check SBOM). What I'm saying is, when you fetch the software (download, package manager, appstore,curl|sh), when you "install" it, when you run it, and when it is dormant and unused. At all of those times, SBOM should be checkable. Hashes are useless unless you want people to collect hashes for every executable constantly, including things like software updates.
The problem is, people are looking at it only from their own perspective. People interested in audits and compliance don't care about runtime policy enforcement. People worried about software supplychain compromises, care more about immediate auditability of their environment and ability to take actions.
The recent Shai-Hulud node worm is a good example. Even the best sources were telling people to check specific files at specific locations. There was just one post I found on github issues where someone was suggesting checking the node package cache. Ideally, we would be able to allow-list even js files based on real-time SBOM driven policies. We should be able to easily say "if the software version is published by $developer between dates $start and $end it is disallowed".
They contain for each dependency name, version, (derivable) URL and integrity checksum, plus of course the intra-dependency relationships.
This can all be verified at any point in the lifecycle without running any of the code, provided a network connection and/or the module cache. What's missing?
Another matter is that most software I know of doesn't even use lock files. Furthermore, there are lots and lots of software that would need to be updated to support your scheme, but updating them just isn't practical. It would have to be relegated to the type of software that gets regularly updated and its authors care about this stuff. I mean, we can't even get proper software authors to host a security.txt on their website reliably. It needs to work for "old" software, and "new" software would need to spend time and effort implementing this scheme. How can we get people that won't even sign their executable to sign a lock file and participate in the verification process?
I believe I did:
> This can all be verified at any point in the lifecycle without running any of the code, provided a network connection and/or the module cache.
It does not require a JS runtime[0] - you fetch a tarball and check its integrity. You can extract it and validate the integrity of a module cache or (non-minified) distribution.
[0]: If you have a dependency with a lifecycle script which at runtime say downloads, builds and installs new components into the module tree then all bets are off. If you are doing SBOMs for anuthing more than theatrical checkbox compliance, such (usage of) dependencies should already have been yeeted before you got here and if not, well, I guess you have work to do.
1) The Notepad++ compromise is one, lots of people install it and don't even have auto-update
2) There has been lots of state-sponsored attacks in recent years that abuse software specific to a country, for example "HWP" against south korean users; sometimes this involves code-signing cert theft
3) Things like log4j have traumatized the industry badly, how do I know what software is using log4j, or some other highly depended-upon software under $randomlang
4) It's very important to detect when someone is using some weird/unusual usage of a popular software, for example things like node, nginx, docker, k8s running on windows 10/11.
I admit I too am biased, but that's my point, we need a solution that works for the messy world out there today, not an ideal world some day. Getting people to use it is like 90% of the problem, the technical part isn't a blocker. I don't care if it's a lockfile, an xml catalog, yaml, etc... can it get standardized and widely used in practice? Can it solve the problems we're all facing in this area? That's why "most software I know" is a very important requirement.
The problem at the end of the day is malicious actors abusing software, so they sort of set the requirements.
At some point we realized that we were talking across each other, since everyone was using "SBOM" to describe different contents and use cases.
The consensus was expressed around 3 years ago, and published in https://www.cisa.gov/sites/default/files/2023-04/sbom-types-...
The digital signing of SBOM artifacts, so that one can verify authorship and authenticity, is something external to the SBOM data, on top of them.
If you are asking about a standardized way to check these, across all computing environments, I think this is a tall order. There are obviously environments currently where this check is present, and there are environments where this is rigorously enforced: software will not load and execute unless it's signed by a specific key and the signature is valid. But the environments are so diverse, I doubt a single verification process is possible.
We need for data-at-rest, what TLS has been for data-in-motion.
For most things that unused dependency is just annoying but if your government has mandated that you use a specific package for something (e.g. cryptography) the lockfile isn't enough to give you confidence that the app is actually doing that. You'll still need to audit the application code.
Related to your point though is that just because a dependency is vulnerable doesn’t mean the software using it is affected too. It might not use the functionality that’s vulnerable. Which means a supplier needs to share their assessment of each dependency vulnerability.
Lockfiles tells the package manager what to install. SBOM tells the user what your _built_ project contains. In some cases it could be the same, but in most cases it's not.
It's more complicated than just annotating which dependencies are development versus production dependencies. You may be installing dependencies, but not actually use them in the build (for example optional transitive dependencies). Some build tools can detect this and omit them from the SBOM, but you can't omit these from your lockfile.
Fundamentally, lockfiles are an input to your developement setup process, while SBOM is an output of the build process.
Now, there is still an argument that you can use the same _format_ for both. But there are no significant advantages to that: The SBOM is more verbose, does not diff will, will result in worse performance.
So it basically is an SBOM then but just sometimes has extra dependencies?
Nope, Java and .NET ecosystem don't use them.
https://devblogs.microsoft.com/dotnet/enable-repeatable-pack...
source from git ~30 go packages ~150 npm packages ~A three layered docker image
[0]: https://bun.com/blog/behind-the-scenes-of-bun-install#optimi...
(Case in point: pip-audit's CycloneDX emission was subtly incorrect for years, and nobody noticed[1].)
Well NO lock file and SBOM formats are used for different purposes and are to be consumed by different audiences. They will evolve in different speeds and ways. Ideally SBOM should not evolve and package lock should be able to change on a whim by package manager developers.
SBOMs are meant to be shared by 3’rd parties while lock files not - just because some tooling accidentally started using lock files for ingestion is just because people didn’t knew better or couldn’t explain to their customers why they should do SBOM so they did first easiest thing.
That's because it's a:
• union of all deps for all possible target platforms, • for all libraries and all binaries in the whole workspace, • and includes all optional deps for all optional features, regardless whether these features are currently enabled or not.
This means that Cargo.lock truly locks everything, and works for all platforms and configurations of a project. It's stable enough to commit into source control, as it won't get invalidated/mutated just because somebody used it on another OS or built the project with an extra flag.
But it doesn't represent what actually goes into each binary.
Not affiliated with Hacker News or Y Combinator. We simply enrich the public API with analytics.