I scanned one of our own old codebases. Here's the uncomfortable part.

Before I asked anyone else to check their software for Cyber Resilience Act readiness, I pointed the same check at one of our own older projects. A content management system we built years ago and hadn't thought hard about since.

The result was a useful kind of embarrassing, and I think it's worth sharing, because it's almost certainly true of your codebase too.

What the scan found

Around twenty dependencies. That part was fine. The uncomfortable parts were two.

First, a mail-sending library pinned to a 2020 version with known security vulnerabilities against it. Not exotic. Just a dependency that did its job quietly for years while the world moved on and nobody upgraded it.

Second, and worse: no lockfile committed. Which means that for that project, we could not actually prove which exact versions we had shipped. Not to a customer, not to an auditor, not to ourselves.

Why the second one is the real problem

The outdated library is a normal, fixable thing. You update it, you move on. Every codebase has a few.

The missing lockfile is different. It isn't a vulnerability you can patch. It's the absence of an answer. When the Cyber Resilience Act asks you, from 2027, to produce a bill of materials for what you ship, "we think it was roughly these versions" is not a bill of materials. It's a guess wearing a lab coat.

The point

I don't tell this story to sell you a scan. I tell it because I've now looked at enough small-vendor codebases to know that the forgotten old dependency and the missing lockfile are the rule, not the exception. Including in shops run by careful, competent people. Especially in the projects that have been quietly earning money for years.

If you haven't looked, you don't know what's in there. That's not a criticism. It's just the starting position for almost everyone, and the first thing worth fixing.