← All posts

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.

More from the blog

See where your product stands under the CRA.

Run a free CRA Readiness Snapshot; what's in your product, what's actively exploited, in about a minute.

Run a free Snapshot