Hello! I am submitting a proposal for the July 30th "CVE in an Era of AI-Enabled Vulnerability Discovery" virtual conference.
Format: Individual talk or facilitated discussion (organizer's choice — the goal is community input on whether to standardize)
Theme alignment: Representing uncertainty and abstraction more clearly. Secondary: helping consumers make dependable prioritization and remediation decisions at higher speed and scale.
Speaker: Matthew Venne, stackArmor
Abstract
Vulnerability scanners score the CVE. Almost none of them score the environment the CVE landed in — even though verified secure configuration systematically neutralizes whole weakness classes. A container running with a read-only root filesystem bounds every CWE-434 upload-to-execute and write-variant path traversal it hosts (CVE-2017-12617 and CVE-2025-24813 are both, concretely, filesystem writes). A distroless image has no shell for CWE-78 command injection to execute. Default-deny egress removes the outbound leg that CWE-917/CWE-94 staged-fetch exploits require. Security teams know this; their tooling has no standard way to say it, so the knowledge lives in tribal deviation memos and per-finding tickets.
This session proposes an open standard for declaring mitigations machine-readably, keyed by what can actually be verified:
- Rows keyed by (verified control × CWE class or ATT&CK technique) — e.g.,
readonly-rootfs counters CWE-434/CWE-73/CWE-22-write; drop-capabilities + default seccomp counters specific privilege-escalation techniques.
- Effects declared as CVSS Modified Base metrics — the row lowers Modified Integrity High→Low, or applies a documented likelihood residual — so the output plugs into scoring machinery consumers already run, rather than inventing a new algebra.
- Verification conditions and disqualifiers as first-class fields — the read-only-rootfs row does not fire if a writable volume is mounted at a path the vulnerable component executes from; the distroless row dies if an interpreter arrives via a mounted volume. A row without its verification evidence grants nothing.
- Conservative defaults — no evidence, no credit; observed exploitation (KEV) governs its own lane regardless of any declared mitigation.
The discovery side of the ecosystem is scaling fast; the consumption side needs environment context to keep pace, and that context should be portable between tools rather than locked inside each vendor's proprietary "risk score." The session's purpose is to test community appetite and find the right home: an extension to VEX/CSAF dispositions, an ADP enrichment container, a standalone schema — and to identify the failure modes (gaming, stale verification, control drift) a standard would need to design against.
A public, illustrative example of the row format: https://github.com/stackArmor/vdr-pain-relief-examples
Takeaway
A concrete strawman schema the community can react to, three worked examples (read-only rootfs vs. the Tomcat upload RCEs; distroless vs. command injection; egress control vs. staged-fetch exploits), and a candid list of open problems — verification freshness, scope of credit, and where such declarations should live in the existing standards landscape.
Contact
Hello! I am submitting a proposal for the July 30th "CVE in an Era of AI-Enabled Vulnerability Discovery" virtual conference.
Format: Individual talk or facilitated discussion (organizer's choice — the goal is community input on whether to standardize)
Theme alignment: Representing uncertainty and abstraction more clearly. Secondary: helping consumers make dependable prioritization and remediation decisions at higher speed and scale.
Speaker: Matthew Venne, stackArmor
Abstract
Vulnerability scanners score the CVE. Almost none of them score the environment the CVE landed in — even though verified secure configuration systematically neutralizes whole weakness classes. A container running with a read-only root filesystem bounds every CWE-434 upload-to-execute and write-variant path traversal it hosts (CVE-2017-12617 and CVE-2025-24813 are both, concretely, filesystem writes). A distroless image has no shell for CWE-78 command injection to execute. Default-deny egress removes the outbound leg that CWE-917/CWE-94 staged-fetch exploits require. Security teams know this; their tooling has no standard way to say it, so the knowledge lives in tribal deviation memos and per-finding tickets.
This session proposes an open standard for declaring mitigations machine-readably, keyed by what can actually be verified:
readonly-rootfscounters CWE-434/CWE-73/CWE-22-write;drop-capabilities + default seccompcounters specific privilege-escalation techniques.The discovery side of the ecosystem is scaling fast; the consumption side needs environment context to keep pace, and that context should be portable between tools rather than locked inside each vendor's proprietary "risk score." The session's purpose is to test community appetite and find the right home: an extension to VEX/CSAF dispositions, an ADP enrichment container, a standalone schema — and to identify the failure modes (gaming, stale verification, control drift) a standard would need to design against.
A public, illustrative example of the row format: https://github.com/stackArmor/vdr-pain-relief-examples
Takeaway
A concrete strawman schema the community can react to, three worked examples (read-only rootfs vs. the Tomcat upload RCEs; distroless vs. command injection; egress control vs. staged-fetch exploits), and a candid list of open problems — verification freshness, scope of credit, and where such declarations should live in the existing standards landscape.
Contact