Commit your lockfile, the cheapest CRA-readiness step there is
8 August 2026 · 2 min read · by Admin
If you do one thing this week toward the Cyber Resilience Act, do this: make sure your projects' lockfiles are committed to version control. It costs nothing, takes minutes, and everything else stands on top of it.
What a lockfile is
A lockfile ( composer.lock, package-lock.json, yarn.lock and friends) records the exact version of every dependency your project uses, including the dependencies of your dependencies. A manifest (composer.json, package.json) only says "something in this range". The lockfile says exactly what shipped.
Why it's the foundation
Every CRA obligation that involves knowing what's in your product depends on being able to answer "what exact versions did we ship?" without guessing:
- A reproducible SBOM (the ingredients list the CRA expects by 2027) is only accurate if you know exact versions. From a version range, you're estimating.
- Vulnerability matching is only precise against pinned versions. "Some version between 1.2 and 1.9" can't be checked cleanly.
- When a customer or auditor asks "were you affected by X?", a committed lockfile turns days of investigation into a lookup.
The uncomfortable version
If your lockfile isn't committed, you currently cannot prove what you shipped to anyone, not a customer, not an auditor, not yourself. That's not a vulnerability. It's worse: it's not being able to say. And it's the single cheapest thing on the entire CRA-readiness list to fix.
Ten minutes. Do it before you read the next article about SBOMs.