No. A lockfile records the exact dependency tree so later installs produce the same result. An SBOM is a standard format inventory meant to be read by other people and tools. A lockfile can be an input to an SBOM, but it is not a substitute for one.
Definitions
Lockfile. The npm documentation says package-lock.json describes the exact tree that was generated, so that later installs are able to generate identical trees. It records versions, where each package was resolved from, and an integrity hash. It is meant to be committed so teammates and CI install the same thing.
SBOM. A software bill of materials lists the components in a piece of software in a standard format such as CycloneDX or SPDX. It is designed to be handed to someone else: a customer, an auditor, a scanner.
Side by side
| Lockfile | SBOM | |
|---|---|---|
| Main purpose | Repeatable installs | Transparency and analysis |
| Format | Tool specific | Standard (CycloneDX, SPDX) |
| Audience | Your build | Customers, auditors, scanners |
| Covers other ecosystems | One package manager only | Can describe a whole product |
| Licences and supplier data | Not the goal | Part of the format |
| Can describe containers or binaries | No | Yes, depending on the generator |
Why the difference matters
- A product often mixes ecosystems. A web service may have npm packages, Python tooling and a base image. Each has its own lockfile. An SBOM can describe all of it in one document.
- A lockfile is not something you can safely send to a customer. Formats differ per tool and nothing standardises how components are identified.
- Lockfiles describe what a build would install, not necessarily what was shipped. A container may add system packages that no lockfile lists.
When each is the right tool
- Committing a lockfile is a build hygiene step. Do it for applications.
- Generating an SBOM from the lockfile on each release gives you the shareable inventory.
- Scanning either one finds known vulnerabilities, but the SBOM travels better between teams.
A worked example
A service written in Python ships in a container. The Python lockfile lists the pinned libraries. The container also holds an operating system layer with its own packages, and maybe a binary downloaded during the build. None of those appear in the Python lockfile. An SBOM generated from the built image can list all three groups in one file, which is why the two are used together, not instead of each other.
Quick check
If I commit a lockfile, do I already have an SBOM?
No. You have the input. Run a generator to produce a standard format document and check that it includes identifiers and transitive components.
Can I scan a lockfile for vulnerabilities?
Yes. Many scanners read lockfiles directly. Scanning the SBOM gives the same finding for the same versions.
Where Safeguard fits
Safeguard's SBOM and dependency scanning reads manifests and lockfiles and produces an inventory you can scan and share. The free scan accepts a project so you can compare the two views.
Sources
- npm Docs, package-lock.json (purpose and recorded fields).
- CycloneDX specification overview, cyclonedx.org (BOM types and current version 1.7).
Last reviewed: 19 October 2026.
