Every Code Bug Is an Attack Path: How We Connect Vulnerabilities to Real Threats

Your threat model says "Attacker exploits authentication bypass to access patient records." Your SAST tool says "CWE-306: Missing Authentication for Critical Function in AuthController.java:87." These are the same problem described in two different languages — and nobody in your organization is connecting them.

Two Languages, One Problem

Security engineering has a translation problem. Threat modelers think in architectures, trust boundaries, and attack trees. Code reviewers think in CWEs, code paths, and remediation patterns. These two disciplines produce artifacts that live in different tools, use different vocabularies, and are maintained by different teams.

The result is a persistent gap between what we know could go wrong (the threat model) and what is actually wrong (the code findings). Threat models predict vulnerabilities. Code scans find them. But no one systematically checks whether the things we found match the things we predicted — or whether the things we predicted have been addressed in code.

This gap has real consequences:

• Threat models without code validation become theoretical exercises — impressive documents that don't change how software is built.
• Code findings without threat context are just items in a backlog — prioritized by CVSS score instead of actual business risk.
• Compliance audits require demonstrating that identified threats have mitigating controls. Without threat-to-code mapping, this evidence must be assembled manually for every audit.

Every code vulnerability mapped to architectural threats and attack paths

Closing the Loop: Architecture as the Bridge

The missing link between threat models and code findings is the application architecture. The architecture defines the components, their relationships, the data flows, and the trust boundaries. It's the Rosetta Stone that translates between threat language and code language.

When you map a code finding to its architectural component, you automatically inherit the threat context for that component. A SQL injection in the user-facing API gateway is a different threat than the same SQL injection in an internal batch processing service — because the attack surface, the data sensitivity, and the threat actors are different.

We use the architecture as a bidirectional mapping layer:

• Top-down: Threats identified in the architecture review generate expected vulnerability patterns. "This component handles authentication, so we expect to find (or not find) CWE-287, CWE-306, CWE-384."
• Bottom-up: Code findings are traced to their architectural component and inherit the threat context. "This CWE-89 finding is in the payment processing component, which handles PCI data and is internet-facing."

From CWE-306 to Attack Path Entry Point

Let's walk through how a single code finding becomes a fully contextualized attack path in four steps:

Step 1: Code Finding

The scanner identifies CWE-306 (Missing Authentication for Critical Function) in the PatientRecordsController:

// PatientRecordsController.java
@GetMapping("/api/v2/patients/{id}/records")
public ResponseEntity<List<MedicalRecord>> getRecords(
    @PathVariable String id) {
    // No authentication check — endpoint is publicly accessible
    return ResponseEntity.ok(recordService.getRecords(id));
}

Step 2: Architectural Mapping

The finding is mapped to the Patient Records APIcomponent in the architecture model. This component is classified as:

• Exposure: Internet-facing (behind API gateway, no WAF)
• Data classification: PHI (Protected Health Information)
• Regulatory scope: HIPAA, SOC 2 Type II
• Trust boundary: External → Internal (crosses the primary trust boundary)

Step 3: Threat Correlation

The architectural mapping triggers a lookup against the threat model. Three threats are linked to the Patient Records API component:

1. T-4: Unauthorized access to patient records — Threat actor: external attacker. Impact: PHI breach, HIPAA violation.
2. T-7: Privilege escalation via API — Threat actor: authenticated low-privilege user. Impact: Access to other patients' records.
3. T-12: Data exfiltration through bulk API calls — Threat actor: compromised insider. Impact: Mass PHI extraction.

CWE-306 directly enables T-4 and amplifies T-12. The finding is now connected to specific, named threats with defined impact.

Step 4: Attack Path Construction

The system constructs the complete attack path:

Attack Path: T-4 → CWE-306 → PHI Breach
─────────────────────────────────────────
1. Attacker discovers /api/v2/patients/{id}/records endpoint
   (enumerable via sequential IDs)
2. No authentication required — endpoint returns data for any valid ID
3. Attacker iterates through patient IDs, extracting medical records
4. PHI for all patients is exfiltrated

Impact: HIPAA breach notification required for all affected patients
        OCR fine: $100–$50,000 per record (max $1.5M per violation category)
        Reputational damage: material

Controls required:
  - Authentication (OAuth 2.0 / JWT validation)
  - Authorization (patient-level access control)
  - Rate limiting (prevent bulk enumeration)
  - Audit logging (detect unauthorized access attempts)

Attack path visualization showing threat-to-code correlation

MAESTRO Mapping: Automatic Threat-to-Finding Links

Manually connecting every code finding to every threat would be impractical at scale. We use the MAESTRO framework to automate threat-to-finding mapping based on four signals:

Signal 1: Component Affinity

Code findings and threats that belong to the same architectural component are automatically linked. If Threat T-4 is associated with the Patient Records API and a CWE-306 finding is in the Patient Records API code, they're connected.

Signal 2: CWE-to-Threat Taxonomy

We maintain a mapping between CWE categories and common threat patterns. CWE-306 (Missing Authentication) maps to authentication bypass threats. CWE-89 (SQL Injection) maps to data exfiltration and data manipulation threats. These mappings are refined continuously based on real-world attack data.

Signal 3: Data Flow Analysis

Threats often involve data moving across trust boundaries. When a code finding is on a data flow path that a threat describes, the link is strengthened. A finding in a function that processes data crossing the external-to-internal trust boundary is more likely to relate to external-facing threats.

Signal 4: Control Requirement Gaps

When a threat requires a specific control (e.g., "encryption at rest for PHI") and a code finding indicates that control is missing or misconfigured, the mapping is direct and high-confidence.

Coverage Metrics That Actually Mean Something

With threat-to-code mapping in place, you can answer questions that were previously unanswerable:

• Threat coverage — What percentage of identified threats have been verified in code? A threat model with 40 threats where only 12 have been validated in code is 30% covered — and 70% unverified.
• Finding relevance — What percentage of code findings map to identified threats? Findings with no threat mapping may represent threats the model missed — or findings that don't represent real risk.
• Control effectiveness — For each threat, are the required controls present in code and correctly implemented? Not "do we have an auth library" but "does the specific endpoint that handles PHI enforce authentication?"
• Residual risk — Which threats have no mitigating code controls? These are your highest-priority items — identified risks with zero defense.

Changing the Conversation

Threat-to-code mapping changes how security teams communicate with leadership and developers. Here's the before and after:

Before: The CVSS Conversation

"We have 847 findings. 23 are critical, 156 are high. We need to fix them by priority order."

This conversation fails because CVSS scores are context-free. A "Critical" finding in an internal dev tool is less urgent than a "High" finding in a production payment endpoint. Leadership nods, developers groan, and the backlog grows.

After: The Threat Conversation

"Threat T-4 — unauthorized access to patient records — has three unmitigated code paths. The missing authentication in the Patient Records API is the primary entry point. If exploited, it's a HIPAA breach notification event affecting 240,000 patients. The fix is a two-day engineering task using our existing OAuth middleware."

This conversation works because it connects code findings to business impact. Leadership understands the risk. Developers understand the scope. The two-day fix gets prioritized over 200 low-context CVSS "Critical" findings that nobody can explain.

Security Requirements as Code Review Criteria

When threats map to code, security requirements become testable assertions. Instead of vague requirements like "the application must implement proper authentication," you get specific, verifiable criteria:

• Requirement SR-4.1: All endpoints in the Patient Records API must validate a JWT token with the records:readscope before returning data. (Derived from Threat T-4.)
• Requirement SR-4.2: Patient record access must enforce patient-level authorization — the authenticated user must be the patient or an authorized provider. (Derived from Threat T-7.)
• Requirement SR-4.3: The Patient Records API must rate-limit requests to 100 per minute per authenticated user and log all access attempts to the SIEM. (Derived from Threat T-12.)

These requirements can be checked in code review, enforced in CI/CD, and verified in penetration testing. They trace directly to threats, which trace to business risks, which trace to regulatory obligations. Full traceability, no gaps.

The Feedback Loop

The most powerful aspect of threat-to-code mapping is the feedback loop it creates. Each cycle improves both the threat model and the code review:

1. Threat model → Code findings: Threats predict vulnerability patterns. Code review validates or refutes them.
2. Code findings → Threat model: Unexpected findings reveal threats the model missed. The threat model is updated.
3. Remediation → Coverage: Fixed findings improve threat coverage. Regression tests prevent recurrence.
4. Coverage → Risk posture: The CISO gets a real-time view of which threats are mitigated, which are partially addressed, and which are wide open.

Over time, the threat model becomes a living document — not because someone remembers to update it quarterly, but because the code review process automatically identifies when the model is incomplete or outdated.

This is what "security by design" actually looks like in practice. Not a one-time architecture review. Not a static document. A continuous loop from threats to code to findings to fixes to updated threats.