A Conan lockfile, usually conan.lock, records the exact versions and revisions your dependency graph resolved to. A firmware build that uses it pulls the same C and C++ libraries every time, even after a newer matching release appears, so what you ship matches what you tested and what your SBOM lists.
The problem it solves
Conan recipes can ask for a version range, for example a library at any release from 1.0 up to but not including 2.0. When 1.1 is published, the next build quietly picks it up. Your own code did not change, but the binary did.
For firmware that is a real risk. A device build that drifts between a release candidate and the factory image makes test results meaningless, and an SBOM written from the first build may not describe the second.
How to create and use one
The Conan documentation describes a short flow:
- Run
conan lock create .in the project folder. This writes conan.lock with the versions and revisions that resolved. - Commit the file next to your recipe.
- Run
conan installas usual. When conan.lock exists, Conan uses it by default. - In CI, pass the lockfile explicitly so nobody relies on a default.
Lockfiles are strict. If a required dependency is missing from the file, the build fails. A partial mode exists, but treat it as a deliberate exception.
Several targets, one lockfile
Firmware often ships for more than one chip or architecture, and some dependencies only appear in certain configurations. The docs say you can lock each configuration separately, and one lockfile can serve several configurations because unused entries do no harm. Merging per-configuration lockfiles is described as mainly a CI task.
What a lockfile does not do
It pins versions. It does not tell you whether a pinned version has a known vulnerability, and it cannot force a version that your recipe's ranges reject. To move a library forward you update the lockfile on purpose, for example by adding a specific version, and review the diff like any other change.
| Question | Lockfile answers it? |
|---|---|
| Which exact versions went into this build? | Yes |
| Will the next build use the same ones? | Yes |
| Is any pinned library vulnerable? | No, needs a scanner or advisory feed |
| Which libraries were copied in by hand? | No, only Conan-managed ones |
Where Safeguard fits
Safeguard provides SBOM and dependency scanning, reachability analysis, and policy gates for the source repositories and manifests it supports, and you can run a free scan at gold.safeguard.sh/scan. Check coverage for your build system before relying on it.
Try it yourself
Click through the inventory and look at how each component carries an exact version, which is what a lockfile gives you to start from.
Click through it at your own pace, or open it full screen.
Quick check
Is a lockfile the same as an SBOM?
No. A lockfile is an input to the build for one tool. An SBOM describes the finished product in a shared format. The lockfile is a good source for the SBOM, but libraries copied into the tree by hand will not be in it.
Should the lockfile be committed?
Yes. The point is that every machine and CI run resolves the same graph, which only works if the file travels with the source.
Sources
Last reviewed: 19 October 2026.
