Why vulnerability management is the engine of a secure-by-design product

I stopped trusting "secure by design" on its own

Early on I took the phrases at face value. A product was secure by design when security had been a first-class input to its architecture — threat modelling, least privilege, a small attack surface, memory-safe choices where they mattered. It was secure by default when the out-of-the-box configuration was the safe one, so a customer who changed nothing was still protected. I still think both are worth every hour they cost, and both are genuinely design-time decisions.

What I kept running into was that neither claim survives contact with time on its own. The dependency a team audited last year shipped a critical CVE this year. A protocol chosen because it was sound turned out to have an implementation flaw. I watched the same lesson land in team after team: a design that was secure when you shipped it is only secure now if someone is watching what the world learns about it and acting on that. That watching-and-acting loop has a name, and it is vulnerability management.

Where I keep finding it in the lifecycle

A secure software development lifecycle (Secure SDLC) is the process that turns "we care about security" into repeatable, evidenced activity at every stage — requirements, design, implementation, verification, release, and maintenance. In every engagement, vulnerability management turned out to be the practice that spans the last two stages and feeds back into all the others. It is never really finished, which is exactly why it gets neglected.

This is also how IEC 62443-4-1 frames it, and reading the standard closely was what made me take the practice more seriously. It defines eight practices for a secure development lifecycle, and two of them — Practice 6, management of security-related issues, and Practice 7, security update management — are vulnerability management in all but name. They require a defined way to receive reports, assess and prioritise them, remediate, and get fixes to operators. The standard does not treat this as an afterthought bolted onto development; it treats it as load-bearing. The teams that read it the same way built the loop deliberately.

• Receive — a monitored channel for internally found and externally reported weaknesses, including a coordinated disclosure route.
• Assess — triage against an accurate inventory of what you actually ship, so "are we affected?" has a fast, defensible answer.
• Remediate — a path from a confirmed vulnerability to a released fix, with the timeline driven by severity.
• Inform — telling operators what changed and why, which is itself a CRA obligation, not a courtesy.

Then the CRA made it non-negotiable

The Cyber Resilience Act took what IEC 62443-4-1 recommends and made the core of it mandatory for products with digital elements placed on the EU market. Annex I sets out the essential requirements, and its second part is specifically about vulnerability handling: manufacturers must identify and document vulnerabilities (including maintaining a software bill of materials), address them without delay through security updates, apply effective and regular testing, and share information about fixed vulnerabilities once they are available.

The part that concentrated minds in every room I have been in is the reporting clock. An actively exploited vulnerability, and a severe incident, each trigger an early-warning notification to the relevant CSIRT and ENISA within 24 hours. You cannot meet a 24-hour clock with a process you improvise on the day — I have never once seen it work. It presumes a vulnerability-management function that is already running, already knows the product, and already has the channels open.

What the teams that got it right actually had

In practice, keeping these promises at product scale is a tooling problem as much as a process one — and the teams that stayed calm during a CVE storm were the ones that had built the plumbing in advance. The parts that had to exist and stay current: an accurate inventory of components and dependencies (the SBOM), continuous scanning of code and its dependencies, a way to match new CVEs against what you actually ship, a prioritisation model that reflects real exploitability rather than raw CVSS, and an audit trail that can show an assessor when each issue was found, judged, and fixed.

You do not have to build all of that from scratch, and the teams I saw move fastest usually did not. Consolidated application-security platforms such as Aikido Security bring dependency and code scanning, SBOM generation, and vulnerability triage into one place, which was often the fastest way I saw a team get from an ad-hoc spreadsheet to a defensible, evidenced process. The tool was never the point, though — the process was. A platform makes the loop cheap to run; it does not decide your severity thresholds, your remediation SLAs, or your disclosure policy for you. The teams that expected the tool to make those judgements for them were the ones that struggled.

What I take from it

Secure by design and secure by default get a product to a strong starting position. Vulnerability management is what keeps it there — and in my experience it is the thread that ties an IEC 62443-4-1 process to the CRA obligations you will be measured against. The teams that treated it as core product infrastructure rather than a compliance chore were the ones where compliance ended up following from the engineering instead of fighting it. That, more than any single control, is the difference I learned to look for.