41–50 of 64 posts
> 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...
Earlier quoted context omitted.
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.
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.
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…
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 on earth is an SBOM?
Earlier quoted context omitted.
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…
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…
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.
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.
There's a great rule for UK Gov websites that an acronyms must be defined on first use. What on earth is an SBOM?
What is a "UK" ? ;-)
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…
So it basically is an SBOM then but just sometimes has extra dependencies?
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…
So the lockfile is a superset, but never a subset? So it basically is an SBOM then but just sometimes has extra dependencies?
Earlier quoted context omitted.
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.