MCP Security Compliance

Authoritative compliance reference for AI-assisted development — and tooling to make sure the compliance actually lands in code.

This server addresses two pain points engineers have with compliance:

1. Build-time — Claude consults ISO 27001, NIST 800-53, OWASP ASVS, and NIST SSDF before writing security-touching code, so controls don't get forgotten. Optional pre-edit and pre-commit hooks make consultation deterministic.

2. Audit-time — citations Claude added in code (// Refs: NIST IA-5(1)) become a generated COMPLIANCE.md evidence index when an auditor asks "show me A.8.5".

All cross-framework mappings come from authoritative sources (NIST OLIR, NIST OSCAL, OWASP releases) — never AI-generated.

What You Can Do

Compliance lookups — Look up any control by ID, search by keyword, or list entire control families. Covers ISO 27001:2022 (93 Annex A controls), NIST SP 800-53 Rev 5 (full catalog with enhancements), ISO 27017:2015 (cloud security), and NIST cloud security guidance (SP 800-144, 800-210, 800-146).

Cross-framework translation — ISO 27001 controls resolve their NIST 800-53 mappings inline. NIST SSDF tasks expose official cross-references to 800-53, BSIMM, OWASP ASVS/SAMM, ISO 27034, PCI SSLC, EO 14028, and 23 more. NIST 800-53 sits at the hub.

Build-time guardrails — Code-actionable best practices via OWASP ASVS 5.0 (345 testable requirements across 17 chapters) and NIST SSDF (40 SDLC practices). The controls_for_change tool takes a description of what you're about to build and returns a curated checklist before you write a line of code. Pre-edit and pre-commit hooks enforce that citations land in the diff.

Scanner-to-control bridge — CWE Top 25 (2024) entries map to ASVS chapters and NIST control families, so vulnerability findings (CWE-79 XSS, CWE-89 SQLi) translate directly into the controls that mitigate them.

Audit traceability — bun run evidence walks the repo for // Refs: annotations, resolves NIST → ISO Annex A, and emits a COMPLIANCE.md audit-evidence index — auditor-ready in seconds.

Related MCP server: code-guard-ai

How the Mappings Work

NIST 800-53 is the hub that connects the frameworks:

ISO 27001 ──► NIST 800-53 ◄── OWASP ASVS, NIST SSDF
                   ↕
ISO 27017 ◄─► NIST Cloud Guidance (SP 800-144, 800-210, 800-146)

All cross-framework mappings come from official sources:

Setup

Requires Bun.

git clone <repo-url>
cd mcp-security-compliance
bun install

Claude Code

claude mcp add mcp-security-compliance -- bun run /absolute/path/to/mcp-security-compliance/src/index.ts

Claude Desktop / Cursor

Add to your MCP config (claude_desktop_config.json or .cursor/mcp.json):

{
  "mcpServers": {
    "mcp-security-compliance": {
      "command": "bun",
      "args": ["run", "src/index.ts"],
      "cwd": "/absolute/path/to/mcp-security-compliance"
    }
  }
}

Example Prompts

"Look up ISO 27001 control A.8.24"
"What NIST controls relate to access management?"
"What does ISO 27017 say about virtual machine segregation?"
"What does NIST say about hypervisor access control in the cloud?"
"What ASVS L2 requirements cover OAuth refresh tokens?"
"What SSDF practices map to NIST SR-3?"
"What compliance controls cover encryption?"

How to use this — composition patterns

This server provides primitives (lookup, search, list, map) that compose. You don't need a dedicated tool for every workflow — phrase the request in plain English and Claude will chain the primitives. Five common patterns:

"Our org follows ISO 27001. Implement X properly."

Set this in your project's CLAUDE.md (once):

This project follows ISO 27001:2022. Use the mcp-security-compliance MCP. For any security-touching change, identify relevant ISO Annex A controls, resolve to mapped NIST 800-53 detailed guidance, implement to that spec. Cite NIST IDs in code comments and commit messages (// Refs: NIST IA-5(1)); ISO IDs belong in audit documentation, not source files.

Then ask normally:

"Add password reset with refresh tokens."

Claude chains: iso_search_controls "authentication" → iso_lookup_control A.8.5 → resolves NIST IA-2/IA-5/IA-8 → nist_lookup_control IA-5 detailed=true → implements to that spec → annotates the code with // Refs: NIST IA-5(1), ASVS V6.2.5. The ISO traceability is recovered at audit time via bun run evidence, which walks NIST citations back to ISO Annex A automatically.

"Build me an evidence index for control A.8.24."

Use the audit-evidence prompt or ask plainly:

"What evidence in this repo satisfies ISO A.8.24?"

Claude chains: iso_lookup_control A.8.24 → mapped NIST SC-12, SC-13, SC-17 → nist_lookup_control SC-13 detailed=true for what to look for → greps repo for matching IaC/config/tests/policy → produces a markdown evidence index.

"What SDLC practices does NIST SC-13 satisfy?"

"What SSDF tasks reference NIST SC-13 — what process work backs the implementation?"

Claude chains: ssdf_map_from_nist SC-13 → returns SSDF tasks (e.g. PW.5.1, PW.6.2) → for each, ssdf_external_refs → cross-references to OWASP ASVS, BSIMM, ISO 27034. Useful when an auditor asks not "is the control implemented?" but "is it implemented with sound dev practice?"

"Designing a logging pipeline — make it audit-ready."

Use the secure-by-design-plan prompt:

/mcp__mcp-security-compliance__secure-by-design-plan system="centralized logging pipeline" level="2"

Claude chains: controls_for_change for the system → SSDF practices PO + PW → ISO A.8.15, A.8.16 → mapped NIST AU-* → produces structured plan with controls and evidence requirements.

"What changes when we start handling PII?"

"We're about to start storing user PII. What controls now apply?"

Claude chains: controls_for_change "handling PII" → cross-checks ISO A.5.34 (Privacy and protection of PII) → NIST PT and PII control families → produces a delta checklist of new requirements.

Compliance enforcement (optional)

Two hooks ship in scripts/ to make compliance citations consistent across Claude and human edits. Both opt-in. Both use the same path/keyword detection (src/compliance-detect.ts) and call the MCP's controls_for_change to suggest specific NIST/ASVS IDs in their output.

Defaults are conservative — narrow paths (auth/, crypto/, iam/, secrets/, oauth/, session/, tls/) and high-confidence keywords only (password, bcrypt, JWT, oauth, MFA, csrf, private_key, etc). Citations satisfy the check whether they're inline (// Refs: NIST IA-5(1)) or in the commit message (Refs: NIST IA-5(1)).

Setup

Quickest path — run the init script from this checkout, pointing at your target project:

bun run init /path/to/your/project

It copies .claude/settings.json, .husky/pre-commit, and .github/workflows/compliance-check.yml into the target with the MCP_PATH placeholder substituted automatically. Skip individual layers with --skip-hooks=husky,ci.

If you'd rather wire pieces manually, the templates live in templates/ — replace /MCP_PATH/ with the absolute path to your mcp-security-compliance checkout in each.

What gets cited

The hook treats any of these as a valid citation:

• // Refs: NIST <id> — also accepts #, --, /* */, and * comment leaders (covers Python, Ruby, Shell, SQL, Lua, Haskell, Elm, JS/TS, C, Java, Go, Rust, etc.)

• // Compliance: NIST <id>

• Refs: NIST <id> in the commit message

• // Refs: ASVS V<x.y.z> (or commit equivalent)

ISO Annex A IDs alone don't satisfy the hook — ISO is too coarse to describe an implementation. Cite NIST or ASVS in code, then map to ISO at the audit boundary via iso_lookup_control.

Audit prep

When you're heading into an audit, run the evidence index generator:

bun run evidence /path/to/your/repo --out=COMPLIANCE.md

It walks the repo, finds every // Refs: NIST <id> and // Refs: ASVS <id> annotation, resolves NIST → ISO Annex A via the bundled OLIR mappings, and emits a markdown file grouped by ISO control id with file:line evidence pointers. Hand to the auditor.

Tools

ISO 27001:2022

NIST SP 800-53 Rev 5

ISO 27017:2015 (Cloud)

NIST Cloud Security Guidance

OWASP ASVS 5.0

NIST SSDF (SP 800-218)

CWE (Common Weakness Enumeration)

Curated CWE Top 25 (2024) plus high-frequency additions, mapped to ASVS chapters and NIST 800-53 control families. Use this to bridge security-scanner output (CWE IDs) to the controls that mitigate them.

Build-time guardrail

Prompts

The server also exposes MCP prompts — invoke them in Claude Code as /mcp__mcp-security-compliance__<name>.

Data

All data is bundled locally in src/data/ — no API calls at runtime.

To refresh data from upstream:

bun run update-sources

Pulls latest NIST 800-53 OSCAL, NIST SSDF OSCAL, OWASP ASVS release, and re-verifies ISO 27001 against the snapshotted TOC. ISO 27017, NIST cloud guidance, and CWE mappings are manually curated and not auto-refreshed.

Data Provenance

All guidance text is taken directly from official publications — no AI-generated summaries. Each data file in src/data/ carries its own source (or control_titles_source / nist_mapping_source) field so provenance is self-describing at the file level.

Limitations

Be honest about what this server is and isn't:

• Not a vulnerability scanner. It cites controls; it doesn't detect vulnerabilities. Pair with Claude Code's /security-review, Snyk, Checkov, Semgrep, etc.

• Not a Statement of Applicability author. The SoA is a hand-curated business document. This server gives you control facts, not the applicability decisions or business justifications.

• ISO standard text is not shipped. Only IDs and titles are reproduced (factual references). Implementation guidance comes from the mapped NIST 800-53 controls — that's why citations in code use NIST IDs, not ISO IDs.

• Not a GRC platform. No SSPs, no assessment plans, no evidence collection automation beyond the citation grep. For full OSCAL artifact lifecycle, see awslabs/mcp-server-for-oscal.

• CWE mappings are curated, not from an official crosswalk. Use as starter pointers; confirm with nist_search_controls for specific control IDs.

• OWASP ASVS 5.0 ships with empty CWE/NIST cross-ref columns in OWASP's own data. Cross-mappings between ASVS and other frameworks are not yet available authoritatively.

• No threat modeling. ATT&CK is intentionally not included — pair with one of the dedicated ATT&CK MCPs (imouiche/complete-mitre-attack-mcp-server, Montimage/mitre-mcp) when threat modeling is a recurring workflow.

Development

bun run dev