Skip to content

feat(mcp): expose the security lens as an audit_attack_surface tool - #75

Merged
Rinkia merged 1 commit into
masterfrom
feat/mcp-audit-tool
Jul 23, 2026
Merged

Rinkia merged 1 commit into
masterfrom
feat/mcp-audit-tool

Conversation

@Rinkia

@Rinkia Rinkia commented Jul 23, 2026

Copy link
Copy Markdown
Owner

What

Closes #64. The MCP server offered only extension-point detection; it now also maps where untrusted code can enter and execute, so an AI client can ask both questions about a local checkout.

Built through the CLI's own renderer

audit_attack_surface returns exactly the payload modscan-audit --json emits — by calling that renderer, not by reassembling it. Deliberate: the two cannot drift, and specifically the non-coverage disclaimer travels with the data.

A client cannot read the result as "no vulnerabilities found", and an empty result still carries the disclaimer — covered by its own test, because that's the case where a false sense of security is most likely.

Separation held

The two tools keep their own vocabulary, as the lenses do everywhere else:

  • moddability → score, signals
  • security → severity, confidence, MS-SEC-* id

A test asserts no moddability score leaks into a security payload.

Test plan

  • tests/test_mcp_server.py: payload shape, MS-SEC-PICKLE + MS-SEC-SUBPROCESS found, ranked most-dangerous-first, literal shell=True elevated to high, limit honoured, no moddability vocabulary in the payload, and the empty-result disclaimer.
  • Suite 25/25; benchmark 9/20 unchanged.
  • Skips cleanly without the mcp extra (unchanged pattern).

🤖 Generated with Claude Code

Closes #64. The MCP server offered only extension-point detection; it now also
maps where untrusted code or data can enter and execute, so an AI client can ask
both questions about a local checkout without leaving the conversation.

The tool returns exactly the payload `modscan-audit --json` emits, built by
calling that same renderer rather than reassembling it. That is deliberate: it
means the two cannot drift, and in particular that the non-coverage disclaimer
travels with the data. A client reading the result cannot mistake it for "no
vulnerabilities found", and an empty result still says so explicitly - covered by
its own test.

The two tools keep separate vocabulary, as the lenses do everywhere else:
moddability answers carry a score and signals, security answers carry severity,
confidence and an MS-SEC id, and neither is phrased in the other's terms. A test
asserts no moddability score leaks into a security payload.

Offline and free, like the detection tool: no LLM, no code execution.

Suite 25/25; benchmark unchanged at 9/20.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
@github-actions

Copy link
Copy Markdown

MODScan attack-surface diff — modscan

No new execution sinks

New attack surface to review — NOT a vulnerability verdict. This compares enumerated execution sinks between two snapshots. It does not trace whether input reaches them (no taint analysis), match CVEs, or detect secrets. An empty diff means no new catalogued sinks — not that the change is safe.

The two snapshots enumerate the same execution sinks.

@github-actions

Copy link
Copy Markdown

MODScan extension-point diff

No breaking changes to extension points

Added (new extension points)

  • mcp_server:audit_attack_surface_tool

@Rinkia
Rinkia merged commit dfb0cc2 into master Jul 23, 2026
7 checks passed
@Rinkia
Rinkia deleted the feat/mcp-audit-tool branch July 23, 2026 14:58
@Rinkia Rinkia mentioned this pull request Jul 23, 2026
3 of 5 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Expose the security lens over MCP

1 participant