Security Audit

---
name: security-audit
description: "Scan code for security vulnerabilities including eval/exec usage, path traversal, hardcoded secrets, and injection risks. Triggers on: security, vulnerability, audit, scan, CVE, CWE, secrets, injection, eval, exec, OWASP."
---
# Security Audit

**IMPORTANT: Start your response with a context preamble.**

Call `help_lookup(topic="security-audit", mode="preamble")` and
display the returned `preamble` text as a blockquote. Then
tell the user they can say "tell me more" for a step-by-step
guide, or answer the scoping questions below to proceed.

If the MCP call fails, fall back to:

> **Security Audit** — Scans your code for security
> vulnerabilities — eval/exec, path traversal, hardcoded
> secrets, injection risks.

## Scoping

Before running, ask:

1. **Scope**: "Which path should I scan?" Default to the
   project root if the user says "everything."
2. **Focus**: "Any specific concern — secrets, injection,
   dependencies, or a full sweep?"

## Execution

### Shared command workspace (preferred)

Open adapter `security-audit` with the validated path and focus. The invocation
authorizes this read-only scan, so the running workspace has no confirmation
action. Call `security_audit` and publish its exact outcome as `scan_result`,
including health score, files scanned, and categorized path/line/severity/CWE
findings. An incomplete scan must say “did not complete,” never “clean.”

Critical/high findings render one per page with bound Previous/Next actions,
avoiding a tall unscrollable form. `finish_security_audit` records the report;
`handoff_to_fix` prepares an explicit Fix input containing all critical/high
receipts but performs no mutation. Fix retains its own exact-command approval.
Present the terminal widget or Markdown and preserve the same pagination,
failure, and handoff semantics in text fallback.

Call the `security_audit` MCP tool with the scoped path:

```
security_audit(path="<user-specified path>")
```

## Output Format

The `security_audit` tool returns a `health_score`, the `summary_markdown`,
and a pre-rendered **`panel_html`** (present on the report path).

**Prefer the rich panel.** Pass the response's `panel_html` straight to
`mcp__visualize__show_widget` — it renders the report's sections
(findings cards and/or category bullet lists — security / quality /
performance / architecture) under the title + score. Display-only and
injection-safe (generated by `attune.workflows.report_panel`, the
universal renderer shared by every analysis workflow). A failed run shows
an explicit "did not complete" state, never a false "clean".

**Fall back to a markdown table** (from `summary_markdown` / `findings`)
when the widget surface is unavailable:

```markdown
## Security Audit Results

**Score:** X/100 | **Files Scanned:** Y | **Issues:** Z

### Critical
| File | Line | Issue | CWE |
|------|------|-------|-----|

### High / Medium / Low
| File | Line | Issue | CWE |
|------|------|-------|-----|
```

Use clickable file links: `[file.py:123](path#L123)`

## What It Checks

- `eval()` and `exec()` usage (CWE-95)
- Path traversal vulnerabilities (CWE-22)
- Hardcoded secrets and API keys
- SQL injection patterns (CWE-89)
- Command injection risks (CWE-78)
- Broad exception handling that masks errors
- Missing input validation

## Help

After presenting results, call:

```
help_lookup(
    topic="security-audit",
    mode="workflow_help"
)
```

If templates are returned, offer: "I have tips about
security audits — want to see them?"

## Follow-Up

After presenting results, offer:

- "Want me to fix the critical issues?"
- "Should I generate security tests for the flagged
  files?"
- "Want a deeper scan of a specific directory?"