This is the fourth post in our DRIVE Deep Dive series. Over the coming weeks we're examining each pillar of the DRIVE framework in turn. For the complete model, download the full DRIVE framework. Our last post covered Initiatives. Up next: Efficiency.
The bottleneck on writing code is gone, and the industry is responding the way it always does when a constraint disappears: by producing more. Every new service, every new dependency, and every line an agent writes on a developer's behalf is also new surface area for something to go wrong.
According to NIST, CVE submissions to the National Vulnerability Database increased 263% between 2020 and 2025, a trend the agency does not expect to let up. The volume got large enough that NIST announced in April 2026 it would stop trying to fully analyze every incoming CVE, prioritizing only vulnerabilities already confirmed as actively exploited, software used by the federal government, and software defined as critical under Executive Order 14028. Everything else still gets published. It just doesn't get scored.
Code generation is only compounding the problem. A large and stubborn share of AI-generated code samples introduce OWASP Top 10 vulnerabilities, a rate that hasn't meaningfully improved across recent testing cycles.
None of this is because security teams lack data. If anything, they drown in it: scanners, checklists, controls, more signal than any one person can act on in a leadership review. The problem is that raw volume doesn't answer the question leadership actually needs answered: Is risk accumulating, or is it being retired? That's a governance question, not a technical one, close to word-for-word what the National Association of Corporate Directors is now telling boards to ask for: not raw technical detail, but a small set of business-aligned metrics tied to risk acceptance and accountability. This is where DRIVE's Vigilance pillar begins.
Are we actively defending our systems and managing our acceptable risk?
What Vigilance measures
Vigilance is grounded in the assets that actually matter to customers and regulators: the services, repositories, and infrastructure components that hold customer data, process payments, or sit on a critical path. Everything else is noise for the purposes of a leadership review, even if it's worth tracking at the team level.
Three critical metrics cover the pillar from three different angles:
Fixable Critical and High CVEs past SLA: measures exposure that's already known and already actionable, the risk an organization is choosing not to close.
Assets below the compliance baseline: measures whether the org's own minimum bar for security and operational hygiene is actually being met.
Orphaned and unverified assets: measure something neither of the first two can: risk with no human accountable for it at all.
Together, the three answer the pillar question holistically without having to read a raw vulnerability count or a control-by-control audit.
Open Critical/High fixable CVEs
Counted as the sum of open Critical and High severity vulnerabilities with a known upstream fix, rolled up per domain.
The scope is drawn deliberately narrow. Below High severity, prioritization gets too org-specific for a leadership review: a Medium in a payments service isn't the same risk as a Medium in an internal dev tool, and that distinction belongs at the team level, not the OpEx review. The "fixable" qualifier matters just as much. If no fix exists yet, there's no remediation path to hold anyone accountable to, and it belongs on a separate risk-acceptance surface rather than the weekly scorecard.
Just a simple count doesn’t provide a meaningful “red” signal; it's how much of that count has breached SLA (a defensible default is 30 days for Critical, 60 days for High). Say a domain is sitting on 7 open Critical and 21 open High vulnerabilities, 28 total. On its own, that number tells a room of leaders almost nothing: is it bad, is it normal, has it always looked like this? The breakdown is what turns it into a signal. If one of those Criticals has been open 41 days and three of the Highs have been open past 70, that's four SLA breaches out of 28, and it's the four that flag the domain red. The conversation that follows isn't "why do you have 28 vulnerabilities." It's "who owns these four, and why are they still open."
Assets not meeting the compliance baseline
Counted as the number of services failing at least one rule in the org's defined compliance or security baseline, rolled up as passing/failing counts through each reporting level.
Most compliance frameworks run to hundreds of individual controls, and walking through each one in a leadership meeting is neither practical nor useful; nobody's attention span survives a control-by-control readout, and nobody in the room needs that level of detail to decide where to push. DRIVE's objective here is to define a baseline instead: a small, explicit set of requirements every in-scope asset must meet. For a service, that might mean a named owner, a curated SLO, a linked runbook, and a supported package version. Infrastructure assets will have a different baseline entirely. DRIVE doesn't prescribe what belongs in it, it just requires that whatever baseline a scorecard enforces is stated plainly, so everyone reviewing the number knows exactly what "failing" means.
The red signal is a pass rate below threshold, a defensible default being 90% of Tier 1 services passing. Compliance tends to be an easier conversation than the other two Vigilance metrics, mostly because the pain is already felt by the time it reaches the review; teams already know when their audit prep is a scramble. The value from DRIVE isn’t necessarily a simple audit, it's the baseline framing: instead of relitigating which controls matter every cycle, the review just asks whether the assets that are supposed to clear the bar are actually clearing it, and for which tier that's slipping.
Orphaned and unverified assets
Counted as services with no valid owner, plus services whose listed owner hasn't reverified ownership within a defined window (every six months is a reasonable default). For organizations under heavier regulatory scrutiny, unverified should be treated as functionally equivalent to unowned rather than as a lesser category.
This is the risk category with no human accountability attached at all. A repo carrying a Critical CVE and no owner has no one to prioritize it, so it sits untouched until an incident forces the question. Then everyone is scrambling to answer it at once.
The rollup here works differently than the other two metrics. It's counted by domain or by criticality tier only, never rolled up to a team, because an orphaned service has no team to roll up to by definition. The red signal is correspondingly blunt: any count above zero for Tier 0 or critical-path services is a problem, full stop.
This tends to be the metric that delivers the most value the first time an organization actually runs it. Most orgs have more orphaned services than they think they do, and simply surfacing the list is usually the first real step toward repairing the ownership graph, well before any of the fixing starts.
Secondary drag metrics
A longer tail of risk lives below the three critical signals: lower-severity issues that accumulate quietly between cycles, and the process breakdowns that let them pile up in the first place. These belong in team-level drill-downs, not the leadership scorecard.
Open Medium and Low CVEs are worth tracking for team-level trend awareness, for the same reason they're excluded from the critical metrics: prioritization below High severity is too org-specific to mean anything in aggregate at the leadership level.
A single count of SLA breaches across all severities is a useful integrity check on the remediation process as a whole, distinct from whether the top-severity items specifically are closing. If that number is climbing even while Critical and High stay green, it's an early signal that the process is degrading before it shows up where leadership is looking.
Not every organization needs every drag metric running from day one. Start with the three critical signals, and add these once a specific pain point makes the case for going deeper.
Where existing security frameworks fit
Vigilance isn't a replacement for the scanners and compliance programs most security teams already run. Vulnerability scanners, SOC 2 and ISO control audits, and other regulatory frameworks are still doing the measurement work, and they're good at it. What they don't do on their own is force a recurring, resourced decision about what to do with what they find.
That's the layer DRIVE adds. The OpEx review takes what a scanner flags, what an audit fails, and what a control framework requires, and turns it into the same kind of recurring leadership attention and resource reallocation the other DRIVE pillars get. A scanner can tell a team a service has a Critical vulnerability. It can't put that vulnerability in front of the people who decide whether the team gets time to fix it this week or next quarter.
Measuring Vigilance in an OpEx review
The Operational Excellence review is where these three signals actually get read against threshold and turned into redirected attention and resourcing.
In practice, the review is chasing three things:
Which owners are holding the SLA-breaching CVEs and why those specific ones are still open past the deadline the org set for itself.
Where the compliance baseline pass rate is slipping and for which tier, since a dip in Tier 2 coverage is a very different conversation than the same dip in Tier 1.
Whether there's a Tier 0 orphan anywhere in the org treated as a stop-the-line item rather than a line item, the same way a Sev0 incident would.
None of these require the review to relitigate the underlying scanner data or compliance audit itself. The review's job is narrower and more useful: turn a red signal into a named owner and a next action before the meeting ends.
Where the Vigilance signals come together
These three signals rarely come from one place. They're split across a handful of disconnected systems: a scanner tracking CVEs, a separate compliance tool checking controls, a catalog (if one exists) tracking services, and whatever spreadsheet or wiki page is doing double duty as an ownership record. Pulling one domain's Vigilance numbers together for a review often means someone manually reconciling all four before the meeting even starts.
Cortex closes that gap automatically. Scorecards codify whatever compliance baseline an org defines and grade every service against it automatically, rather than requiring a manual audit pass each cycle. The Context Graph, paired with ownership prediction, is what actually surfaces orphaned and unverified assets, since it's built to know which services exist and who's supposed to be accountable for them, not just which ones a team remembered to register. When a new CVE drops, Cortex's Catalog returns the affected-services list immediately and tracks remediation per team as an Initiative, so the fix itself gets the same visibility and follow-through as any other org-wide effort. From there, Engineering Intelligence turns it into the report leadership actually reviews at OpEx..
Rapid7 is a useful illustration of what this looks like once it's running end to end: a security company using Cortex to manage the same ownership and compliance visibility problems Vigilance is meant to solve for engineering orgs generally. In one case, this let Rapid7 migrate 3,000 database instances across regions in under two weeks; work that would otherwise have taken months.
Interested in learning more about DRIVE? Take the DRIVE maturity assessment to see where your organization stands against the Vigilance pillar and the rest of the DRIVE framework.
Next in the series: Efficiency, the pillar that asks how capacity is split between innovation and maintenance.
