Personally, I would prefer that the package managers keep their own lockfiles with all their metadata. A CI process (using the package managers itself) can create the SBOM for every commit in a standardized environment. We get all the same benefits without losing anything (the package managers can keep their own formats and metadata and remove anything unneeded for the SBOM from it).
Second that. It is trivial to add SBOM generator to your pipeline - it is not trivial to make all kind of package managers to switch and each format is used for different audiences.
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.
I do exactly that in my container build pipelines and it is great. And then CI uploads those SBOMs to Dependency Track.
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.
You are building everything in CI from scratch so theoretically, it should be completely possible to not need to scan lockfiles and get all the data from their respective sources (OS, runtime, dynamic libs, static deps, codegen tools, build time deps, etc)
> 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.
SBOM may contain similar info to lockfiles, but the purposes are entirely different.
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.
No because SBOMs are a hot mess and not standardized at all. They're "standardized" in the same sense as HL7 (ask someone in the healthcare industry, make sure to have some sedatives on hand first). A comprehensive SBOM for something like Chromium is many dozens of MBs compressed (I forget exactly, but it's patently ridiculous). Also SBOMs should be build artifacts, so them (also) being build inputs is problematic.
The format is standardized, to the highest level possible: ISO/IEC 5962:2021 defines SPDX v2.2.1. The actual standard text is available for free at the ISO website (and other places, like spdx.org).
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.
Oh sure, the format is standardized. The semantics aren't however, in any practical sense. What happens when you vendor/patch/fork a dependency? What happens to vulnerabilities that are not in code paths not used by your software, or only under certain flags?
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.)
> What happens when you vendor/patch/fork a dependency?
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.
This might not be part of HL7, but I recall working on software for a healthcare product, and simply having a list of components want not enough. Each component had to be accompanied by a risk assessment. It's a really clever way of keeping your dependency count low.
In the case of something like xzutils, you would perhaps have listed it as low risk, as it's shipped with your OS. After the backdoor incident, you'd have adjusted the risk assessment, and utilities like it. Once you hit a certain level you might question if you truly need the entire xzutils package or if you could replace it.
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.
This year I had to create SBOM files for our Unity projects. Of course there is nothing. For all that don’t know: UPM (Unity Package Manager) is a way to easily install packages in Unity. And as a side note, for whatever reason they decided to built on top of npm not nuget for the package infrastructure and metadata format.
Anyways: Most packages we use are simply wrapper packages for other packages. Like a wrapper for a .NET library. There is no clear dependency try but based on the package ID I’m able to see them. So I wrote the SBOM files based manually with an SBOM library and added pedigree statements to the original nuget package being wrapped. Idea was if the nuget package has a security issue the UPM package also gets flagged. Showed that one of the security engineers of the software we use. As wer was cool but that is not a standard. There is also no official package specification for UPM (I also made that up as part of the purl)
So yes SBOM is a standard with a huge array of ways to declare said information. And it seems most companies consuming the files don’t built general parsers but expect specific formats for X.
Oh dear, HL7, I may be suffering from a form of PTSD… my therapist has heard about this “standard” at length.
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
This is a great summary, although I think I'm more bearish on SBOMs than Andrew is: my experience integrating them so far (in both pip-audit and uv) has been that there's much more malleability at the representation level than the presence of a standard might imply, and that consumers have adapted (a la Postel) to this reality by being very permissive with the kinds of broken stuff they permit when ingesting third-party SBOMs.
(Case in point: pip-audit's CycloneDX emission was subtly incorrect for years, and nobody noticed[1].)
In some ecosystems like Rust/Cargo the lock file can list a superset of the dependencies that actually make it into the final executable. Crates may conditionally include or exclude dependencies based on enabled features selected by the parent crate, or on the compilation target itself. As a result, the SBOM is effectively a build artifact, and its contents can legitimately vary across platforms.
Wouldn't lock files require running the thing? People need to be able to verify SBOM without doing that. It's the kind of thing you check against a large fleet of devices. If someone has software installed on their laptop but hasn't run it in a year, you need to be able to measure SBOM for that.
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.
The checksum just tells you what the hash is, nothing more. Supply chain attacks aren't always against the main executable either. With authenticode, the "catalog" can be signed. You're even more opposite of OP than I (OP proposes lockfiles which are at runtime).
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?
> With authenticode, the "catalog" can be signed
You could trivially sign any lockfile, though I've never seen it. I think it could be neat and it might have a chance to catch on if there was more support in tooling for it. The NPM registry does support ECDSA package sigs but I guess signatures for this use should be distributed on other channels given how much of an antipattern uploading lockfiles to registry is considered in the npm community and that's an uphill. In the context of SBOMs I guess there's already a slot for it?
I don't think you've addressed the requirement of having to execute the software, that was my main objection.
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 don't think you've addressed the requirement of having to execute the software, that was my main objection.
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.
> Another matter is that most software I know of doesn't even use lock files.
I don't believe the goal should be to lower the bar until "most software I know" pass. And you don't need all the libraries you depend on to ship lockfiles/SBOMs themselves as long as you take ownership of it wrap it up in your own builds and installations, right? Besides, lockfiles are definitely the norm in js/npm land these days from what I see...
[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 anything 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. If you get to this point I'd say the process is serving its purpose in forcing you to face these.
I concede on all but the last point. For that, I think you're taking a very language or platform specific perspective. And I think I myself am highly biased by security incidents. To give examples:
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.
Ah, but there are actually different types of SBOMs, that describe the software in different parts of its lifecycle. It's a completely different outcome to record the software when looking at its source, at what is being distributed, or at what is being installed, for example.
At some point we realized that we were talking across each other, since everyone was using "SBOM" to describe different contents and use cases.
I haven't had a chance to read that, but do you think it would be impractical to have the different types of SBOMs declared in a standardized format? My impression is that no matter what, authenticity needs to be established, so it will always fall under "cryptographic verification of information about software", it is the standardization of that which I have an issue with.
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.
Yes, TLS for example uses X.509, as do lots of things. The container format, as well as the data-structure. I'm saying not just for SBOM, but for the code-signing cert aspect as well. I wouldn't mind if there was an "SBOM" usage in X.509, and CA's sell SBOM signing certs or whatever, but the sad fact is, I think some mobile platforms, macos and windows are the only place this is used.
We need for data-at-rest, what TLS has been for data-in-motion.
Cargo.lock contains unused dependencies that aren't in the final product.
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.
> Every package manager has its own lockfile format. Gemfile.lock, package-lock.json, yarn.lock, Cargo.lock, poetry.lock, composer.lock, go.sum. They all record roughly the same information: which packages were installed, at what versions, with what checksums, from where.
Isn't one fairly major problem with using lockfiles that there could be packages in the lockfile that aren't used in the application? If I run "npm i package" that doesn't tell you whether or not 'package' is actually used in the app.
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.
You’re right that SBOMs cannot be used to attest that a library is correctly used. I’m not sure if that’s a common use-case of SBOMs though. I normally see people wanting SBOMs for security transparency (customer can see if you’re maintaining your dependencies), vulnerability management (customer can know what vulnerabilities lurk in the dependencies) and license compliance (they can know you didn’t use any dependencies with licenses that cause commercial issues).
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.
Typical software developer fallacy - well it looks the same so we can abstract and merge concept.
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.
In hearing the SBOM term for the first time from that article and the linked Wikipedia page. For the ignorant like me: what is it that SBOM is used for that lockfiles aren’t? Everything in the article is something that I’m used to seeing automated scanners using lockfiles for.
Is it just that the two are used by different communities? What is the SBOM community?
In many cases the lock files are for one part of the stack. Like npm and composer and $other_lang thing. sBOM is when all are together and version-pinned. (I've over simplified).
Edit: for my domain we have Alpine, Debian, PHP, JS, Go in the stack. So our BOM has all that (and dependencies). It's a big list. Some is just necessary base (Alpine, Debian) but some are core stack and other are edge (dependency on python lib when we're mostly Rust (or something)).
Mirror/Vendor all these things for supply-chain integrity (it's what they tell me)
Think of the SBOM as a "table of contents" for the software you are receiving. Another metaphors that has been used is the "nutrition label" that you get in all packaged food.
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.
> what is it that SBOM is used for that lockfiles aren’t?
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.
Thats an important point. You can't tell if the software you use is vulnerable to something like log4j without the vendor telling you, or doing lots of manual investigation.
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.
> the security world has been pushing CycloneDX and SPDX
> CycloneDX supports JSON, XML, and YAML
And SPDX is JSON.
Are there any other examples of government-mandated non-human-readable file formats? I feel like bureaucracies have a natural tendency to water down requirements such as this and instead focuses on getting wet signatures on pen-and-paper.
Another drawback could be that package manager lockfile schemas are optimized for performance[0]. I wouldn't appreciate seeing slower install times by default - especially if the lockfile could be converted with other tooling.
Personally, I would prefer that the package managers keep their own lockfiles with all their metadata. A CI process (using the package managers itself) can create the SBOM for every commit in a standardized environment. We get all the same benefits without losing anything (the package managers can keep their own formats and metadata and remove anything unneeded for the SBOM from it).
Second that. It is trivial to add SBOM generator to your pipeline - it is not trivial to make all kind of package managers to switch and each format is used for different audiences.
Exactly.
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.
I do exactly that in my container build pipelines and it is great. And then CI uploads those SBOMs to Dependency Track.
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.
You are building everything in CI from scratch so theoretically, it should be completely possible to not need to scan lockfiles and get all the data from their respective sources (OS, runtime, dynamic libs, static deps, codegen tools, build time deps, etc)
From https://en.wikipedia.org/wiki/Software_supply_chain:
> 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.
Still not fully helpful. The article could have included some links or a box out.
SBOM may contain similar info to lockfiles, but the purposes are entirely different.
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 the lockfile is a superset, but never a subset?
So it basically is an SBOM then but just sometimes has extra dependencies?
Superset of dependencies, but often a subset of info per depedency.
Ah okay! I know Rust has the transitive dependencies did not think/realise all languages might not, good point!
No because SBOMs are a hot mess and not standardized at all. They're "standardized" in the same sense as HL7 (ask someone in the healthcare industry, make sure to have some sedatives on hand first). A comprehensive SBOM for something like Chromium is many dozens of MBs compressed (I forget exactly, but it's patently ridiculous). Also SBOMs should be build artifacts, so them (also) being build inputs is problematic.
The format is standardized, to the highest level possible: ISO/IEC 5962:2021 defines SPDX v2.2.1. The actual standard text is available for free at the ISO website (and other places, like spdx.org).
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.
Oh sure, the format is standardized. The semantics aren't however, in any practical sense. What happens when you vendor/patch/fork a dependency? What happens to vulnerabilities that are not in code paths not used by your software, or only under certain flags?
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.)
> What happens when you vendor/patch/fork a dependency?
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.
This might not be part of HL7, but I recall working on software for a healthcare product, and simply having a list of components want not enough. Each component had to be accompanied by a risk assessment. It's a really clever way of keeping your dependency count low.
How does that work for high complexity dependencies like compression or cryptography? If HL7 wouldn’t catch xzutils is it really adding anything?
In the case of something like xzutils, you would perhaps have listed it as low risk, as it's shipped with your OS. After the backdoor incident, you'd have adjusted the risk assessment, and utilities like it. Once you hit a certain level you might question if you truly need the entire xzutils package or if you could replace it.
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.
This year I had to create SBOM files for our Unity projects. Of course there is nothing. For all that don’t know: UPM (Unity Package Manager) is a way to easily install packages in Unity. And as a side note, for whatever reason they decided to built on top of npm not nuget for the package infrastructure and metadata format. Anyways: Most packages we use are simply wrapper packages for other packages. Like a wrapper for a .NET library. There is no clear dependency try but based on the package ID I’m able to see them. So I wrote the SBOM files based manually with an SBOM library and added pedigree statements to the original nuget package being wrapped. Idea was if the nuget package has a security issue the UPM package also gets flagged. Showed that one of the security engineers of the software we use. As wer was cool but that is not a standard. There is also no official package specification for UPM (I also made that up as part of the purl) So yes SBOM is a standard with a huge array of ways to declare said information. And it seems most companies consuming the files don’t built general parsers but expect specific formats for X.
Oh dear, HL7, I may be suffering from a form of PTSD… my therapist has heard about this “standard” at length.
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
This is a great summary, although I think I'm more bearish on SBOMs than Andrew is: my experience integrating them so far (in both pip-audit and uv) has been that there's much more malleability at the representation level than the presence of a standard might imply, and that consumers have adapted (a la Postel) to this reality by being very permissive with the kinds of broken stuff they permit when ingesting third-party SBOMs.
(Case in point: pip-audit's CycloneDX emission was subtly incorrect for years, and nobody noticed[1].)
[1]: https://github.com/pypa/pip-audit/pull/981
In some ecosystems like Rust/Cargo the lock file can list a superset of the dependencies that actually make it into the final executable. Crates may conditionally include or exclude dependencies based on enabled features selected by the parent crate, or on the compilation target itself. As a result, the SBOM is effectively a build artifact, and its contents can legitimately vary across platforms.
Wouldn't lock files require running the thing? People need to be able to verify SBOM without doing that. It's the kind of thing you check against a large fleet of devices. If someone has software installed on their laptop but hasn't run it in a year, you need to be able to measure SBOM for that.
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.
Want to verify the installed package, the package should provide checksums you can verify. AFAIK, the SBOM is to documents the build, not the install.
The checksum just tells you what the hash is, nothing more. Supply chain attacks aren't always against the main executable either. With authenticode, the "catalog" can be signed. You're even more opposite of OP than I (OP proposes lockfiles which are at runtime).
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".
I still don't see how lockfiles can't be SBOM.
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?
> With authenticode, the "catalog" can be signed
You could trivially sign any lockfile, though I've never seen it. I think it could be neat and it might have a chance to catch on if there was more support in tooling for it. The NPM registry does support ECDSA package sigs but I guess signatures for this use should be distributed on other channels given how much of an antipattern uploading lockfiles to registry is considered in the npm community and that's an uphill. In the context of SBOMs I guess there's already a slot for it?
I don't think you've addressed the requirement of having to execute the software, that was my main objection.
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 don't think you've addressed the requirement of having to execute the software, that was my main objection.
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.
> Another matter is that most software I know of doesn't even use lock files.
I don't believe the goal should be to lower the bar until "most software I know" pass. And you don't need all the libraries you depend on to ship lockfiles/SBOMs themselves as long as you take ownership of it wrap it up in your own builds and installations, right? Besides, lockfiles are definitely the norm in js/npm land these days from what I see...
[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 anything 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. If you get to this point I'd say the process is serving its purpose in forcing you to face these.
I concede on all but the last point. For that, I think you're taking a very language or platform specific perspective. And I think I myself am highly biased by security incidents. To give examples:
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.
Ah, but there are actually different types of SBOMs, that describe the software in different parts of its lifecycle. It's a completely different outcome to record the software when looking at its source, at what is being distributed, or at what is being installed, for example.
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-...
I haven't had a chance to read that, but do you think it would be impractical to have the different types of SBOMs declared in a standardized format? My impression is that no matter what, authenticity needs to be established, so it will always fall under "cryptographic verification of information about software", it is the standardization of that which I have an issue with.
All types of SBOMs can be described in the same standardized format. SPDX 3.0 has a specific property and a set of values this one can take: https://spdx.github.io/spdx-spec/v3.0.1/model/Software/Vocab...
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.
Yes, TLS for example uses X.509, as do lots of things. The container format, as well as the data-structure. I'm saying not just for SBOM, but for the code-signing cert aspect as well. I wouldn't mind if there was an "SBOM" usage in X.509, and CA's sell SBOM signing certs or whatever, but the sad fact is, I think some mobile platforms, macos and windows are the only place this is used.
We need for data-at-rest, what TLS has been for data-in-motion.
Cargo.lock contains unused dependencies that aren't in the final product.
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.
> Every package manager has its own lockfile format. Gemfile.lock, package-lock.json, yarn.lock, Cargo.lock, poetry.lock, composer.lock, go.sum. They all record roughly the same information: which packages were installed, at what versions, with what checksums, from where.
Nope, Java and .NET ecosystem don't use them.
One can easily opt-in with modern dotnet.
https://devblogs.microsoft.com/dotnet/enable-repeatable-pack...
I know, however as you point out, it isn't used by default.
Isn't one fairly major problem with using lockfiles that there could be packages in the lockfile that aren't used in the application? If I run "npm i package" that doesn't tell you whether or not 'package' is actually used in the app.
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.
You’re right that SBOMs cannot be used to attest that a library is correctly used. I’m not sure if that’s a common use-case of SBOMs though. I normally see people wanting SBOMs for security transparency (customer can see if you’re maintaining your dependencies), vulnerability management (customer can know what vulnerabilities lurk in the dependencies) and license compliance (they can know you didn’t use any dependencies with licenses that cause commercial issues).
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.
Software I built will have the following ingredients.
source from git ~30 go packages ~150 npm packages ~A three layered docker image
There's a great rule for UK Gov websites that an acronyms must be defined on first use.
What on earth is an SBOM?
Software Bill Of Materials (moving to System Bill Of Materials), as lots of comments here explain.
What is a "UK" ? ;-)
Typical software developer fallacy - well it looks the same so we can abstract and merge concept.
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.
In hearing the SBOM term for the first time from that article and the linked Wikipedia page. For the ignorant like me: what is it that SBOM is used for that lockfiles aren’t? Everything in the article is something that I’m used to seeing automated scanners using lockfiles for.
Is it just that the two are used by different communities? What is the SBOM community?
In many cases the lock files are for one part of the stack. Like npm and composer and $other_lang thing. sBOM is when all are together and version-pinned. (I've over simplified).
Edit: for my domain we have Alpine, Debian, PHP, JS, Go in the stack. So our BOM has all that (and dependencies). It's a big list. Some is just necessary base (Alpine, Debian) but some are core stack and other are edge (dependency on python lib when we're mostly Rust (or something)).
Mirror/Vendor all these things for supply-chain integrity (it's what they tell me)
Think of the SBOM as a "table of contents" for the software you are receiving. Another metaphors that has been used is the "nutrition label" that you get in all packaged food.
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.
> what is it that SBOM is used for that lockfiles aren’t?
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.
The FDA also requires SBOMs as of a few years ago for medical device software.
SBOMs are a solution intended to help solve a couple of problems:
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
You forgot about the important one SBOMs are created with thought about sharing them with third parties like your customers - lock files not.
Thats an important point. You can't tell if the software you use is vulnerable to something like log4j without the vendor telling you, or doing lots of manual investigation.
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.
https://www.ntia.gov/sites/default/files/publications/sbom_m...
Depending on who you ask an SBOM might not need a hash. NTIA only recommend a hash.
Software licensing information is the big use case where SPDX originated from.
In CycloneDX you can also express things like attestations/certifications, possibly down to the code review level (although I think nobody does that).
> the security world has been pushing CycloneDX and SPDX
> CycloneDX supports JSON, XML, and YAML
And SPDX is JSON.
Are there any other examples of government-mandated non-human-readable file formats? I feel like bureaucracies have a natural tendency to water down requirements such as this and instead focuses on getting wet signatures on pen-and-paper.
Or tag-value, which is actually preferred by many practitioners. Nesting is implicit in that format, but SBOMs should be mostly flat, anyway.
Unfortunately, T-V hs been dropped in SPDX 3.0.
It was dropped exactly because it was flat and it was becoming completely unmanageable.
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.
But it was the best format for manually creating an SBOM.
Most SBOM use cases don‘t need the ability to put your detailed software architecture in the SBOM.
"manually creating an SBOM" is a much lower priority requirement than "easily, accurately, and completely creating an 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?
I would expect people to do a lot of manual work in SBOM and licensing, yes. Because that‘s we do now.
Another drawback could be that package manager lockfile schemas are optimized for performance[0]. I wouldn't appreciate seeing slower install times by default - especially if the lockfile could be converted with other tooling.
[0]: https://bun.com/blog/behind-the-scenes-of-bun-install#optimi...
https://xkcd.com/927/