A lockfile tells your package manager exactly which versions to install, so every build matches. An SBOM (software bill of materials) tells other people what is inside your finished software, in a standard format. A lockfile helps you build. An SBOM helps everyone else check. Most teams need both.
TL;DR
- A lockfile is a build tool's memory. It is written for one package manager and one project.
- An SBOM is a shareable inventory. It is written in a common format so customers, auditors and tools can read it.
- You can often make an SBOM from a lockfile, but the lockfile alone leaves gaps.
- Keep the lockfile in your repository. Generate a fresh SBOM for every release.
Definition. An SBOM is a nested inventory, a list of the ingredients that make up software, as CISA describes it. A lockfile is a file your package manager writes to record the exact tree of packages it installed.
What does a lockfile actually do?
Think of a recipe card that says "two cups of flour." That is vague. A lockfile is closer to a shopping receipt that says "this brand, this bag, this batch." It removes guesswork.
The npm documentation describes its lockfile, called package-lock.json, as a file that "describes the exact tree that was generated, such that subsequent installs are able to generate identical trees, regardless of intermediate dependency updates." In other words, if you installed version 4.17.20 of a package today, the lockfile makes sure your teammate and your build server get 4.17.20 too, even if 4.17.21 came out yesterday.
Per the same npm page, each package entry in the lockfile can record:
- the version that was found,
- where the package was fetched from (a field called resolved),
- an integrity string, which is a fingerprint (a hash) of the downloaded file,
- flags such as whether it is a development only package.
The npm page also says this file is meant to be committed into source repositories. So the lockfile's audience is your own team and your own pipeline.
Other ecosystems have their own lockfiles with their own layouts. That matters later, because a customer should not have to learn the layout of every tool you use.
What does an SBOM do that a lockfile does not?
An SBOM is a document for readers outside your build. The 2026 minimum elements guidance from CISA and partner agencies lists what an SBOM should carry. Some of it describes the document itself. Some of it describes each component.
For each component, the guidance names a producer (who made it), a name, a version, identifiers, a hash value, a license, and the dependency relationships between components. For the document, it names the author, the tool that made it, a timestamp, a version, the data format, and the generation context, such as before build or after build.
A lockfile can hold some of this by accident. An SBOM holds it by design, in a layout that every SPDX or CycloneDX reader understands. The same guidance says the two data formats widely used today are SPDX and CycloneDX, and that organizations should accept any widely used, interoperable, machine processable format.
Here is how the two compare.
| Question | Lockfile | SBOM |
|---|---|---|
| Main job | Repeat the same install | Describe what is in the software |
| Main reader | Your package manager | Customers, auditors, security tools |
| Format | Tool specific | Standard (SPDX or CycloneDX) |
| Who it is shared with | Usually your own team | Anyone who needs it, at your discretion |
| Covers operating system packages | Usually not | Can, if the tool looks there |
| Records who authored the document | No | Yes, as a minimum element |
| Records the license and producer | Not its purpose | Yes, as minimum elements |
| Updated | When dependencies change | With each release |
The words "usually" and "can" in that table are deliberate. A specific tool may do more or less. The point is the purpose, not a single product.
Why is a lockfile not enough for a customer?
Imagine a customer asks, "What is in the application you sent us?" If you hand over your lockfile, three problems show up.
1. It stops at the edge of one tool. Your web app may have a JavaScript lockfile for the front end, a Python lockfile for a data job, and a container image with operating system packages underneath. Three files, three formats, and none of them describes the whole thing.
2. It may not match what you shipped. CISA's paper on SBOM types separates SBOMs made from source files from SBOMs made during the build and SBOMs made by analyzing the finished artifact. It notes that a source based SBOM "can highlight components (which might have vulnerabilities) that never run or are compiled out in deployed code." A lockfile has the same blind spot. It describes what the package manager resolved, not what ended up in the final box.
3. It is missing context a reader expects. A buyer wants to know who made each component and under what license. They also want to know who wrote the inventory and when. CISA's 2026 guidance treats those as basics.
None of this makes lockfiles bad. They are the right tool for repeatable builds. They are just a different tool.
Can I make an SBOM from a lockfile?
Yes, and it is a common starting point. A lockfile is a precise list of packages and versions, so an SBOM tool can read it and turn it into a standard document. The 2026 guidance expects the SBOM to include transitive dependencies, which are the packages your packages need. A lockfile usually already lists those, which is one reason it is such a good input.
Here are the steps most teams follow.
- Commit your lockfiles. If the lockfile is not in the repository, your SBOM will vary from run to run. The npm documentation recommends committing it.
- Pick one SBOM format. SPDX or CycloneDX are both fine. Choose the one your customers or tools prefer.
- Generate the SBOM during the build. CISA's types paper says a build time SBOM increases confidence that the SBOM matches the product artifact, because it uses information available during the build.
- Add what the lockfile cannot know. That includes operating system packages in your container image and code you copied in by hand.
- Record when and how it was made. The tool name, tool version, timestamp and generation context are all minimum elements in the 2026 guidance.
- Create a new SBOM for every release. The guidance says each software version or update should have an associated SBOM.
- Store and share it on purpose. You do not have to make it public. NTIA's myths and facts sheet says making an SBOM is separate from sharing it.
Worked example: one small service
The numbers below are invented to show the idea. They are not from a real project.
A team ships a small web service. Its JavaScript lockfile lists 410 packages. The service runs in a container image whose base operating system adds 95 more packages. The team also pasted two small helper files from another project straight into their code.
| What you count | Invented count |
|---|---|
| Packages in the JavaScript lockfile | 410 |
| Operating system packages in the image | 95 |
| Copied code tracked as components | 2 |
| Total a customer should see | 507 |
If the team shares only the lockfile, the customer sees 410 items, about 81 percent of the real total (410 divided by 507). The missing 97 items are exactly the ones a vulnerability alert about the operating system could hit. An SBOM made from the finished image, plus the lockfile data, reaches all 507.
CISA's 2026 guidance has a note on copied code too. It says copied and pasted code is effectively a dependency that is better tracked as a fork with a dependency relationship, which "improves vulnerability management."
Try it yourself
Open the demo below and look at how a dependency inventory lists packages that the developer never typed by hand. Notice how much longer the full list is than the short list a person would write.
Click through it at your own pace, or open it full screen.
How can Safeguard help?
Safeguard's SBOM and dependency scanning reads your project's dependencies, including the transitive ones, and produces an SBOM you can export in SPDX or CycloneDX. Reachability analysis then helps you see which of the listed packages your code actually uses, so a long list does not turn into a long to do list.
You can run a free scan at gold.safeguard.sh/scan to see what a dependency inventory looks like for a real project. For day to day work, the Safeguard CLI, IDE extensions and CI integrations bring the same scanning into the places developers already work. The Safeguard CLI can also write code, which is useful when a fix needs a small change. Fix pull requests from autonomous remediation are off by default, and you choose when to turn them on.
For related reading, see what is a software bill of materials, how to create your first SBOM, and SBOM file formats explained.
Quick check
Is a lockfile an SBOM?
No. A lockfile is a tool specific record that repeats an install. An SBOM is a standard format document made to be read by others. A lockfile is a good input to an SBOM, but it is not the same thing.
Should I commit my lockfile and also keep SBOMs?
Yes. Commit the lockfile so builds are repeatable. Generate an SBOM for each release so you can answer customer and audit questions about that exact version.
Does an SBOM replace a vulnerability scan?
No. An SBOM is a list. A scan compares that list with known vulnerabilities. CISA's 2026 guidance says an SBOM alone is data about components and that analysis turns the data into insight.
Sources
- npm Docs, package-lock.json: https://docs.npmjs.com/cli/v10/configuring-npm/package-lock-json
- CISA and partners, 2026 Minimum Elements for a Software Bill of Materials (SBOM): https://www.cisa.gov/resources-tools/resources/2026-minimum-elements-software-bill-materials-sbom
- CISA, Types of Software Bill of Materials (SBOM): https://www.cisa.gov/resources-tools/resources/types-software-bill-materials-sbom
- NTIA, SBOM Myths vs. Facts: https://www.ntia.gov/page/software-bill-materials
Last reviewed: 19 October 2026.
