MITRE CWE Compatibility

The Interlace ESLint ecosystem is CWE-compatible — every security rule maps to one or more MITRE CWE identifiers, and every diagnostic the ecosystem emits surfaces those identifiers in machine-readable form. This page documents how that compatibility works so security teams, auditors, and SARIF consumers can pivot Interlace findings on CWE.

The compatibility design follows the MITRE CWE Compatibility Program — the same review standard met by Coverity, Fortify, Sonar, and Checkmarx.

The four contracts

Current coverage

The live, auto-generated CWE coverage table lives at benchmark-results/cwe-coverage.md. It's regenerated on every rule change by npm run docs:cwe-coverage. Summary fields published in benchmark-results/cwe-coverage.json:

• Distinct CWEs covered
• CWE Top-25 covered (of 25)
• CWE Top-25 gaps (with justification)
• Rules unmapped to any CWE (with justification)

The gap list — CWE Top-25 entries Interlace doesn't cover yet — lives at benchmark-results/cwe-coverage-gaps.md. It also documents the justification for non-coverage per criterion RR-4.

What's emphasized, what's not (RR-4 Coverage Justification)

We cover CWEs that meet all three of:

1. Detectable from a JS/TS Abstract Syntax Tree — pattern-matchable in source without runtime instrumentation.
2. Common in the JavaScript ecosystem — driven by real-world prevalence, not generic SAST checklists.
3. Pre-deployment-actionable — a developer reading the diagnostic should know what to change before merging.

We don't cover:

• C/C++ memory-safety CWEs (CWE-787 buffer overflow, CWE-125 out-of-bounds read, CWE-416 use-after-free, CWE-119 buffer access errors, CWE-476 NULL dereference, CWE-190 integer overflow). These require pointer-level analysis JS/TS source doesn't expose. Use CodeQL or Coverity for those.
• Information-disclosure CWEs requiring full data-flow analysis (CWE-200 in its general form). Interlace covers concrete patterns (secure-coding/no-leaked-error-message, secure-coding/no-stack-trace-exposure), but not arbitrary taint tracking.
• Application-semantics-only CWEs (CWE-862 missing authorization, CWE-863 incorrect authorization, CWE-269 improper privilege management) — these are application-design concerns, not lint-detectable. We cover framework-specific patterns (nestjs-security/no-public-decorator-on-sensitive-route, express-security/no-skipped-auth-middleware) where the framework hooks make detection tractable.

Using CWE in the field

Filter findings by CWE in CI

# Emit SARIF and feed it to GitHub Advanced Security
npx eslint --format @interlace/eslint-formatter-sarif src/ > eslint.sarif

# Now in GitHub UI: Code Scanning → filter by tag → external/cwe/CWE-89

Pull a CWE rollup for an audit report

npm run docs:cwe-coverage         # writes JSON + Markdown
cat benchmark-results/cwe-coverage.json | jq '.byCwe["CWE-798"]'
# → { "rules": ["secure-coding/no-hardcoded-credentials", ...], "top25": true, "owaspTop10": false }

Grep the rule that fired by CWE

# Every rule's source carries `cwe: 'CWE-NNN'` in its meta block
grep -r "cwe.*CWE-89" packages/eslint-plugin-*/src/rules/

Submission status

The Interlace ecosystem's MITRE CWE Compatibility submission readiness review is published at benchmarks/audits/2026-05-09-mitre-cwe-compatibility-readiness.md. Once reviewed and submitted, this page will link to the official MITRE CWE-Compatible Products listing.