fix: Correct speed claim and add infinite vulnerability surface section
Speed Is a Security Control: Replace overconfident '90% solution today' with honest target: 30-60% in 180 days. Real comparison is progress vs. the 0% that stays when waiting for the perfect plan. New section 'When the Vulnerability Surface Is Effectively Infinite': AI-scale vulnerability discovery (e.g. Project Glasswing) does not call for AI-assisted patching. It calls for architecture that makes most vulnerabilities matter less: kill chain prioritisation, blast radius limitation, assume-breach posture, known-good baseline. Architecture beats velocity in the vulnerability race. Co-Authored-By: Tom Kracmar <tom+claude@cat6.cz>
This commit is contained in:
@@ -31,7 +31,9 @@ The Brownhat Diagnostic — a structured [NIST CSF 2.0 baseline assessment](../a
|
|||||||
|
|
||||||
### Speed Is a Security Control
|
### Speed Is a Security Control
|
||||||
|
|
||||||
The organizations that survive are not the ones with the most comprehensive plans. They are the ones that **execute fastest** against the gaps that actually matter. A 90% solution deployed today outperforms a 100% solution that ships in six months—because the attacker does not wait for your roadmap.
|
The organizations that survive are not the ones with the most comprehensive plans. They are the ones that **execute fastest** against the gaps that actually matter. A realistic engagement delivers 30–60% of an ideal posture in 180 days. That is the honest target. It is also, in almost every case, an enormous improvement over what existed before — and infinitely better than the 100% solution that stays in planning and never ships.
|
||||||
|
|
||||||
|
The correct comparison is not "30% today vs. 100% in six months." It is "30% today vs. the 0% that will still be there in two years if you wait for the perfect plan." Momentum beats completeness. Imperfect progress beats perfect paralysis.
|
||||||
|
|
||||||
### Fixing Things Is Strategic
|
### Fixing Things Is Strategic
|
||||||
|
|
||||||
@@ -210,6 +212,43 @@ These are not interesting. They are not cutting-edge. They are the interventions
|
|||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
|
## When the Vulnerability Surface Is Effectively Infinite
|
||||||
|
|
||||||
|
Recent AI-assisted security research — including large-scale automated vulnerability discovery across entire software stacks — has surfaced a reality that was always true but is now undeniable: **the number of exploitable vulnerabilities in any complex environment exceeds any organisation's capacity to patch them.** This is not a new problem. It is a shift in visibility. The vulnerabilities existed before. We can now find them faster than we can fix them.
|
||||||
|
|
||||||
|
The vendor response to this is predictable: "You need AI-assisted patching." Faster discovery paired with faster remediation, AI all the way down.
|
||||||
|
|
||||||
|
This is the wrong frame. It accepts a race you cannot win.
|
||||||
|
|
||||||
|
### The Architectural Response
|
||||||
|
|
||||||
|
The correct response to an effectively infinite vulnerability surface is not to patch faster. It is to **move to a realm where most vulnerabilities matter less** — by designing systems architecturally so that the exploitation of any single vulnerability does not lead to existential compromise.
|
||||||
|
|
||||||
|
This is not a new idea. It is the fundamental premise of defence in depth, blast radius limitation, and kill chain thinking. What has changed is the urgency: when AI can identify thousands of vulnerabilities across your stack in hours, the "patch-first" strategy is exposed as insufficient. The architectural strategy becomes the only viable long-term position.
|
||||||
|
|
||||||
|
The moves:
|
||||||
|
|
||||||
|
**Kill chain awareness** — Not every CVE is existential. The ones that matter are the ones that sit on the path from "nothing bad has happened yet" to "the organisation cannot operate." Concentrate protection there. A critical vulnerability in a segmented, non-privileged system is a low-priority finding. The same vulnerability on a domain controller, a backup server, or an OT control system is P0. The vulnerability is the same; the kill chain position is what changes the priority.
|
||||||
|
|
||||||
|
**Blast radius limitation** — Segmentation, least privilege, and structural decoupling mean that exploiting a vulnerability in one component cannot pivot freely through the environment. A flat network with over-privileged accounts converts every vulnerability into a potential total compromise. A segmented, least-privilege environment converts most vulnerabilities into limited-scope incidents.
|
||||||
|
|
||||||
|
**Assume breach posture** — Design for rapid detection and recovery rather than prevention of every entry. If architectural controls are in place, a compromised component is an isolated incident, not a catastrophe. The question shifts from "how do we keep attackers out?" to "how quickly do we detect, contain, and recover?" This is Pillar 3 (Stress-to-Signal Conversion) applied to the vulnerability layer.
|
||||||
|
|
||||||
|
**Known-good baseline** — Configuration management (ASTRAL) and system state tracking mean that after a compromise, you can restore to a verified baseline. The ability to rebuild rapidly from a known-good state reduces the cost of successful exploitation dramatically.
|
||||||
|
|
||||||
|
### What This Means for Prioritisation
|
||||||
|
|
||||||
|
When clients ask how to respond to the AI vulnerability discovery story, the answer is not a new patching tool. It is a sequenced architectural programme:
|
||||||
|
|
||||||
|
1. Map and close the kill chain — the vulnerabilities that sit on the path to existential compromise get patched first, regardless of CVSS score.
|
||||||
|
2. Reduce blast radius — segmentation and least privilege limit the value of any single exploit.
|
||||||
|
3. Build detection and recovery capability — assume some vulnerabilities will be exploited; make exploitation detectable and recoverable.
|
||||||
|
4. Then consider tooling to accelerate patch velocity for the long tail.
|
||||||
|
|
||||||
|
The correct posture is: **a well-segmented, least-privilege, T0-protected environment with fast recovery capability survives more CVEs than a flat, over-privileged environment with a fast patch programme.** Architecture beats velocity in the vulnerability race. It is the only bet you can actually win.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
## Contrast With "Move Fast and Break Things"
|
## Contrast With "Move Fast and Break Things"
|
||||||
|
|
||||||
The Silicon Valley mantra was an excuse for externalizing harm. "Move fast and fix things" is its responsible successor:
|
The Silicon Valley mantra was an excuse for externalizing harm. "Move fast and fix things" is its responsible successor:
|
||||||
|
|||||||
Reference in New Issue
Block a user