Reading cross-walks: how the framework chips work

Vulnerability frameworks talk past each other. OWASP describes risk categories; NIST 800-53 describes controls; CSF describes outcomes; CWE describes weaknesses; DISA STIGs describe per-OS configuration rules. They're useful for different audiences — but the moment you need to answer “does this NIST control address OWASP A01?” or “which ASVS requirements protect against CWE-79?” you need a cross-walk. This page explains where the chips you see on framework pages come from and how to read them.

What a cross-walk is

A cross-walk is a curated mapping between two security frameworks. Each row says “entry A in framework X relates to entry B in framework Y” with a coverage qualifier: partial, mostly, or full. We don't write rows for the absence — if you don't see a chip, the LLM and the reviewer both think there's no meaningful connection.

Some mappings are authoritative

A few framework pairs come with official cross-walks that we ingest verbatim:

• NIST CSF 2.0 → 800-53 r5. NIST publishes the mapping in the Cybersecurity & Privacy Reference Tool (CPRT). 738 directed edges across the 106 CSF subcategories; every line is reviewed by NIST itself.
• DISA STIG → NIST 800-53. Each STIG rule references one or more CCIs (Common Control Identifiers). DISA publishes the CCI→800-53 mapping; we compose rule→CCI→800-53 deterministically. 4,652 edges, no LLM.
• OWASP Top 10 for Web 2025 → CWE. Each OWASP category is a CWE meta-category in MITRE's catalog; membership is published by MITRE.

These show up as chips with no “reviewed by us” caveat — they're as reliable as the publishing authority.

The rest needs interpretation

Most useful cross-walks don't exist as official data: OWASP→NIST, ASVS→CWE, ASVS→NIST, CSF→CWE, CWE→STIG. The relationships are real and load-bearing for practitioners, but no organisation publishes them. We fill the gap with a two-pass process:

• LLM authoring. For each source entry, we narrow the target framework to the top 8–10 most-likely candidates by family seed + text overlap, then ask a frontier model to evaluate each pair in both directions: how much does implementing the target cover the source? and the inverse. Coverage levels are none / partial / mostly / full. The LLM also returns a one-sentence rationale.
• Human QA. Every LLM-authored row sits in a review queue until a person promotes it. Confident rows (mostly/full in both directions) can be batch-promoted; the rest get per-pair review. Rejected rows are deleted; the absence is the answer.

Why both directions matter

The convention we use throughout the site, in every chip tooltip and in every author prompt, is: “X covers Y” means “if you implement X, how much of Y do you address?” Under this convention, a narrow control that fits inside a broad one covers the broad one only partially — you've done one slice of what the broad control asks for. The broad control, when fully implemented, covers the narrow one fully — you've done everything the narrow check asks for and more.

Worked example. Implementing OWASP A01 Broken Access Control addresses one focused failure pattern that’s a slice of what NIST 800-53 PL-8 (Security and Privacy Architectures) requires, so A01 covers PL-8 = partial. Implementing PL-8 properly mandates a comprehensive security architecture that subsumes the access-control failure pattern A01 describes, so PL-8 covers A01 = full. Both directions are stored as separate rows.

A chip on a category page renders like this: AC-3 ←F →P The arrow marks read: ← the other side covers this (full); → this covers the other side (partial). Letters: F = full, M = mostly, P = partial. Hover any chip for the tooltip that narrates both directions in plain English.

Coverage levels in plain words

• full — doing X eliminates the relevant risk Y entirely. Rare; treat with mild suspicion unless you've reviewed the row yourself.
• mostly — doing X covers the substantive risk in Y, but a residual concern remains (configuration, monitoring, an edge case).
• partial — X helps but is not sufficient on its own; you'll need other controls to close the gap. The vast majority of edges land here.
• (none) — no chip rendered. The LLM and reviewer agreed there's no meaningful relationship.

Honest caveats

A “full” rating in the broad→narrow direction is conditional. When a pair reads “broad covers narrow = full” and the reverse is partial or none, the chip is signalling the logical-containment case: a narrow item that sits inside a broader one. That relationship is useful, but it’s a dangerous one to read uncritically. The broad standard typically subsumes many specific requirements similar to the narrow one, and the full rating assumes the broad standard’s implementation actually reaches every detailed design or code-level vulnerability it could in principle address. In practice, that reach is hard to guarantee. Even mature secure-development programs work mostly at architecture and process layers; tracing program effectiveness all the way down to each individual specific weakness is a serious engineering and review effort. A team meaningfully invested in a broad outcome can still ship instances of any individual narrow flaw because no broad program can exhaustively chase every specific weakness without dedicated mechanism. Read full in the broad→narrow direction as “this should be covered when the broader work reaches the relevant level of detail,” not as “this is automatically handled.”

One we caught and fixed: a careful reader noticed that early in the project two different conventions for directional coverage were in play across our LLM author scripts. Some authors stored a row (source=A, target=B, coverage=X) as “B covers A by X”; others, as “A covers B by X.” The LLM was internally consistent within each author run, but the convention varied between authors because the JSON field names (x_to_y) read naturally as math arrows while the question wording asked the opposite. We audited every framework pair, committed site-wide to the intuitive math reading (“A→B means A covers B”), swapped the affected stored rows to match, renamed the JSON fields in the author prompts to a_covers_b so the labels reinforce the convention rather than fighting it, and updated the chip renderer to read under the unified convention. If you were here before the fix landed, some chips were rendering backwards on a subset of framework pairs — that’s no longer the case.

Two specific limitations to keep in mind:

• Coverage gap on edges we haven't authored yet. Phase B (the LLM authoring pass) runs incrementally. A blank chip area doesn't always mean “no relationship” — sometimes it just means “we haven't gotten to that pair yet.” The publication date on each framework page is the relevant cut-off.
• Asymmetric framework abstraction levels. CSF Govern subcategories (“establish risk strategy”) rarely map to specific CWEs or STIG rules. That's expected: they're policy outcomes, not implementation details. If a Govern subcategory has no CWE chips, that's correct, not a gap.

How we keep this current

Framework releases (annual for OWASP, quarterly for STIGs, irregular for CSF/ASVS) trigger a re-ingest. New rows go through the same LLM + QA pipeline. Older rows stay valid until the underlying control text changes; when it does, we either re-run the LLM for the affected rows or accept the previous mapping with a note on the page.

Generated 29 May 2026 12:36 UTC . Last LLM authoring pass: see dbadmin/phase_b_status.py for current counts.