I try to spend as much time as I can talking to software engineers – some I work with, others I meet through meetups or conferences. Over time, I’ve started to notice something curious.
Most are absolute experts at their craft. I am constantly amazed by the mountain of information and acronyms we carry in our minds without even realising it. But almost all of it revolves around things we find interesting, immediate problems we need to solve, or the “new shiny thing”. Rarely, when talking with engineers, do compliance or governance come up.
I totally get it. Compliance is universally perceived as less fun. But despite that reputation, regulatory shifts are happening right now that will directly affect how we build software, and we need to be aware of them.
Many engineers can elegantly explain Raft consensus, debate the merits of eBPF, or spend hours discussing the subtleties of eventual consistency. But mention a CVE, and while most engineers will recognise the term, usually because they encounter it through scanner reports, Dependabot alerts, Renovate PRs, or Jira tickets, go a step further and mention a CWE or a CRE, and familiarity drops dramatically even with experienced developers.
For many engineers, vulnerability identifiers belong to security teams, auditors, or compliance departments. They are things that appear in scanner reports, Jira tickets, Dependabot alerts, or Renovate PRs. They are somebody else’s problem.
That perception is becoming increasingly difficult to sustain.
Modern software development is inseparable from security. Every application is built atop layers of frameworks, libraries, containers, operating systems, and cloud services. Vulnerabilities emerge continuously throughout that supply chain. More importantly, governments and regulators have started treating vulnerability management not as a polite recommendation, but as a legal obligation.
In Europe, the Cyber Resilience Act (CRA) marks a massive shift in thinking. Beginning in September 2026, manufacturers of digital products face mandatory reporting obligations for actively exploited vulnerabilities and severe incidents. In the years that follow, broader security requirements will become legally enforceable, with penalties reaching millions of euros or a significant percentage of global turnover.
We can no longer live in a restricted world where our sole purpose is to resolve problems in clever, performant ways. Understanding vulnerabilities is no longer exclusively the domain of security specialists – it is becoming a core part of software engineering itself.
After years of reading literature around shift-left, DevOps, DevSecOps, and SRE, I used to assume everyone was on the same page. I’ve since realised that was just my personal bias as a cybersecurity hobbyist.
Before we can dive into the legislation that will soon affect us, we need to understand the vocabulary that underpins modern vulnerability management.
Common Vulnerabilities and Exposures (CVE)
Imagine trying to coordinate a fix for a defect without a common naming system. One security researcher publishes a blog post describing a flaw in OpenSSL, a cloud provider releases an advisory using a different title, vulnerability scanners invent their own proprietary identifiers, and operating system vendors create yet another naming scheme. Chaos follows.
The CVE program exists to prevent precisely that. A CVE identifier answers a simple question: “Which specific vulnerability are we talking about?”. For example, Heartbleed became CVE-2014-0160, and Log4Shell became CVE-2021-44228.
These identifiers create a shared language used by researchers, vendors, scanners, incident response teams, and governments. Once a vulnerability receives a CVE number, everyone can refer to exactly the same issue. However, CVEs describe symptoms, not causes. They tell us what is broken, but they don’t explain why.
Common Weakness Enumeration (CWE)
The CWE represents a category of software weakness rather than a specific instance of a bug. For example, CWE-89 refers to SQL Injection, or CWE-79 represents Cross-Site Scripting.
Individual CVEs always map, not without controversy sometimes, back to one or more CWEs. Log4Shell, for example, was ultimately traced back to unsafe lookup behaviour and improper handling of untrusted input. The specific vulnerability was unique, but the underlying engineering weakness had been known for decades.
Unfortunately, this is where the gap between vulnerability management and daily engineering lives. Software engineers rarely think in numeric identifiers; they think in architectural practices: input validation, output encoding, authentication, authorisation, and dependency management.
Common Requirements Enumeration (CRE)
The CRE attempts to close that exact gap. Where CVEs answer “what happened” and CWEs explain “why it happened”, CREs focus on the most practical question of all: “What should engineers do to prevent it from happening again?“
When you put the three frameworks together, they form a complete defensive picture:
- A CVE describes an incident
- A CWE describes the underlying weakness.
- A CRE describes the engineering practices that reduce the probability of that weakness appearing in the first place.
Organisations trapped entirely at the CVE layer spend their lives reactively patching. Organisations that understand CWEs start eliminating recurring technical debt. But organisations that embrace CREs and secure engineering requirements begin preventing vulnerabilities before they ever exist – which is exactly what regulators are now expecting.
For decades, security failures were primarily treated as business risks. Companies suffered reputational damage, customers temporarily lost trust, and major breaches led to lawsuits or expensive remediation. But general regulatory intervention remained light.
That world is gone. The European Union’s Cyber Resilience Act is one of the most ambitious pieces of software legislation ever written. Its premise is straightforward: products containing digital components must be secure by design and maintained throughout their entire lifecycle.
Under this framework, non-compliance penalties can reach up to €15 million or 2.5% of global annual turnover. While these numbers inevitably grab the attention of executives and legal departments, compliance needs to be solved by software engineers:
- Lawyers cannot produce a Software Bill of Materials (SBOM).
- Finance departments cannot determine if an exposed container image contains a vulnerable dependency.
- Executives cannot decide whether a newly reported exploit affects production infrastructure.
Only engineering organisations possess that knowledge. Because of that, engineers must understand the language used by scanners, advisories, regulators, and vulnerability databases.
Additionally, with the arrival of advanced AI tools, discovering vulnerabilities is no longer the hard part. Automated scanners can identify thousands of CVEs in minutes. The actual challenges moving forward are entirely context-driven:
- Which vulnerabilities actually matter to our architecture?
- Which systems are genuinely exposed?
- Which structural weaknesses keep recurring in our codebase?
- Which engineering practices need to change?
- Which incidents legally require regulatory reporting?
Organisations are no longer overwhelmed by an absence of information; they are overwhelmed by an abundance of it. A single application may depend on thousands of open-source packages, each potentially introducing risk. Security has transformed from a periodic, pre-release gate into a continuous operational discipline.
As engineers, we have to evolve with it. Understanding a CVE is no longer just a task for a security researcher. Vulnerability management is becoming a core part of everyday software engineering, and for many organisations operating in Europe, it will soon become a legal obligation.
Top comments (0)