[IDEA] Threat-Informed Security Validation: Closing the Gap Between Threat Models and Real Exploitability

[maorkuriel]

The Gap This Addresses

Tachi is excellent at answering where threats exist in an architecture. What it cannot
yet answer is the question every security team asks immediately after reading a threat
model:

"Is this actually vulnerable — and should we fix it now or next quarter?"

Today, that answer requires a separate SCA scan, a manual CVE lookup, and often a
red team engagement to confirm exploitability. These are disconnected workflows. The
threat model informs discussion but rarely drives prioritized action on its own.

This proposal describes a direction that closes that gap.

---

The Opportunity

There is a natural pipeline that Tachi is positioned to anchor:

WHERE (Tachi) → WHAT EXISTS → HOW REAL
Architectural threat Known vulnerabilities Exploitability
surface identified matched to that surface confirmed

Each stage focuses and strengthens the next. Without architectural context (Stage 1),
SCA tools produce undifferentiated CVE dumps — hundreds of findings with no signal on
which ones are reachable or exposed. Without CVE enrichment (Stage 2), threat models
stay theoretical. Without exploitability validation (Stage 3), security teams still
can't confidently prioritize.

Tachi is the natural anchor for Stage 1. This idea proposes extending it through
Stages 2 and 3.

---

Stage 2 — SCA/CVE Enrichment

What it does

For each threat finding Tachi produces, a new enrichment layer would:

• Match the affected component to known CVEs (via NVD, OSV.dev, GitHub Advisory Database)
• Surface whether a public proof-of-concept exploit exists
• Pull EPSS scores (Exploit Prediction Scoring System — the probability a CVE will be
  exploited in the wild within 30 days)
• Flag whether a patched version is available

What it produces

A composite exploitability score per threat finding that combines:

• CVSS severity
• Architectural exposure (how exposed is this component based on Tachi's trust boundary
  analysis)
• Real-world exploit availability
• EPSS probability

This produces something currently missing from most threat models: a Prioritized
Attack Surface — a ranked list that tells a security team where to focus first,
grounded in both architectural context and real-world vulnerability data.

Why this matters for users

Security teams today choose between two bad options: treat every threat model finding
as critical (expensive, unsustainable) or wait for an incident to validate priority
(reactive, dangerous). A composite exploitability score grounded in CVE data and
architectural exposure gives teams a defensible, evidence-based triage framework.

---

Stage 3 — AI-Powered Exploitability Validation

The context

Anthropic recently published a preview of
Mythos, a model that demonstrates
autonomous vulnerability discovery and exploit development at a level significantly
beyond prior AI capabilities. Relevant findings:

• Identified zero-day vulnerabilities across OS kernels, browsers, and media libraries
• Developed working exploits chaining multiple vulnerability primitives
• Achieved 181 working Firefox exploits vs. 2 for the prior generation model

The critical product insight here is not "AI can find exploits." It is: AI-powered
vulnerability discovery is dramatically more effective when given a focused target
surface rather than scanning blindly.

Tachi's threat model is exactly that focusing mechanism.

What Stage 3 would look like

A gated validation mode — opt-in, sandboxed, with explicit authorization controls —
that uses AI reasoning to actively probe the highest-priority surfaces identified by
Stages 1 and 2. The output is not a weaponized exploit. It is a confidence signal:

• Confirmed exploitable: the threat is real in this implementation
• Not exploitable as architected: the threat model finding is valid but mitigated
  by an existing control Tachi didn't detect
• Inconclusive: requires human red team follow-up

Why the responsible use framing matters

This capability belongs in a red team / authorized pentest workflow, not as a
general-availability feature. Any implementation should require explicit authorization
gates — analogous to the Cyber Verification Program Anthropic describes for Mythos
access. Getting this right is a product design challenge as much as a technical one.

---

Why This Is a New Category

This pipeline sits in a gap between existing tool types:

Existing Tool	What It Does Well	What's Missing
SAST / DAST	Finds known patterns in code or endpoints	No architectural context — noisy output
SCA	Identifies vulnerable dependencies	No mapping to threat surfaces or exposure
Threat modeling	Models architectural risk	No link to real vulnerabilities or exploitability
Penetration testing	Validates exploitability	Manual, expensive, point-in-time

Tachi anchoring a SCA/CVE → AI validation pipeline automates the chain with
architectural context as the prioritization layer throughout. That is not an
incremental improvement on any of the above — it is a different thing.

---

Key Product Questions (Not Implementation — Thinking Out Loud)

1. Input requirements for Stage 2: Architecture descriptions often don't include
   component versions. Does Stage 2 require a SBOM (CycloneDX/SPDX) as an explicit
   input, or should Tachi attempt to infer components from the description and flag
   confidence gaps?

2. Output audience for the Prioritized Attack Surface: Is this primarily for
   security engineers running red team exercises, or for AppSec managers making
   remediation priority decisions? The format and level of detail differ significantly.

3. Authorization model for Stage 3: What's the right gate for a --validate mode?
   Signed scope documents, integration with pentest authorization platforms, or
   something lighter?

4. MSSP and multi-project use: MSSPs managing many client architectures would
   benefit from this pipeline at scale — aggregate exploitability scores across clients,
   not just per-project. Is multi-project scope in scope for this idea or a separate
   discussion?

---

Related Issues

• Auto-detect architecture drift #126 Architecture Drift Detection
• MAESTRO coverage matrix — show all 7 layers including zero-finding layers #98 Coverage Matrix
• Feature: Security Progression Summary — multi-run trend comparison over time #55 Security Trends

---

I'm a product leader, not a developer — so I'm deliberately leaving implementation
decisions open. Happy to dig deeper on the problem framing, use cases, or user value
with anyone who wants to explore this direction.

[davidmatousek]

Maor - appreciate this, and glad you found the project.

I've been working on something I call the AI Security Assessment Playbook - a 5-step framework (MAP -> MODEL -> ASSESS -> RECOMMEND -> VERIFY) that maps to what tachi automates. I put your 3 stages against it and the alignment is pretty clear:

Your Stage 2 fills the one gap in the pipeline. Right now, tachi's risk scorer works on architectural reasoning alone - it infers CVSS, exploitability, scalability, and reachability from the architecture description. That works, but it's theoretical. Grounding it in real CVE data, EPSS scores, and patch availability makes the scoring evidence-based. That's the part I want to explore.

I see it as an optional step between /tachi.threat-model and /tachi.risk-score - a /tachi.enrich that takes an SBOM, matches against NVD/OSV/EPSS, and annotates findings before scoring. The optional pattern already exists in the pipeline (Gemini infographics work the same way - external API, gated, additive).

The "architectural context layer" framing is interesting. Tachi already knows trust boundaries, data flows, and component exposure. SCA tools don't. Combining them gives you something neither has alone - a prioritized attack surface that's actually grounded. I want to dig into how that integration works in practice.

Want to jump on a call? I think there's something worth building here. Reach out on LinkedIn DM or email and we'll set it up.

[davidmatousek]

A status note, Maor — this is still very much alive on our side.

Since we last talked, the groundwork Stage 2 would build on has landed: tachi's findings now map across OWASP, MITRE ATT&CK/ATLAS, NIST AI RMF, and CWE through a taxonomy crosswalk catalog (~645 edges). That matters here because the "architectural context as the prioritization layer" you describe needs a stable framework spine to hang CVE/EPSS enrichment off of — and that spine now exists.

Your three-stage framing is still the clearest articulation of where this goes, and the /tachi.enrich direction (Stage 2 — SBOM → NVD/OSV/EPSS → annotated findings, gated and additive like the infographic step) remains the most concrete first slice. I'm holding it as a leading candidate for a dedicated validation/exploitability initiative rather than bolting it onto current maintenance work — it deserves its own scope.

Keeping this thread open as the anchor for that. The Stage 3 authorization-model questions are the ones I most want to get right before any code, and I'd still like to pick those up on a call when timing lines up.