How the pm-ai-shipping Plugin Performs Static Security Audits on AI-Built Code

The pm-ai-shipping plugin provides a deterministic, evidence-driven static analysis command that maps entry points to trust boundaries, cross-references documented intent against implementation, and validates findings through self-refutation to surface only real, unmitigated security risks.

The pm-ai-shipping plugin in the phuryn/pm-skills repository adds deterministic security auditing capabilities to AI-assisted development workflows. Its static analysis engine inspects AI-built code for security gaps without executing the program, combining deep source code traversal with documentation verification to identify vulnerabilities that automated generators often overlook.

The /security-audit-static Command Architecture

At the core of the plugin’s security capabilities lies the /security-audit-static command, implemented in pm-ai-shipping/commands/security-audit-static.md. Unlike traditional linting tools that rely solely on pattern matching, this command executes a five-stage deterministic pipeline that treats the audit as a recall-first evidence collection process. The command accepts an optional path argument to limit scope and produces a structured report citing specific files, line numbers, and attack scenarios.

Five-Stage Security Audit Pipeline

The audit follows a logical progression from scope definition to evidence-backed reporting, ensuring that no offending line is missed while filtering out false positives.

Stage 1: Scope Discovery

The command begins by defining its analytical boundaries. If a path argument is supplied, analysis limits itself to that directory; otherwise, it scans the entire repository. The engine prioritizes code that renders, fetches, executes, or stores user-controlled data, including request handlers, authentication logic, data-access layers, and background jobs. This scope definition logic resides in lines 22-25 of security-audit-static.md.

Stage 2: Entry Point Mapping and Sink Detection

After reading all files within scope, the engine greps for typical entry-point identifiers such as HTTP routes, RPC handlers, and webhook consumers. It constructs a mapping of entry points → trust boundaries → sinks, cataloging destinations like raw SQL queries, shell execution, template rendering, outbound fetches, logging mechanisms, and LLM prompts. This mapping ensures the audit traces data flow from user input to potential vulnerability points.

Stage 3: High-Value Path Inspection

The engine concentrates on four critical data flows that account for the majority of security defects in AI-generated code:

• Authorization – verifying who can call what
• Data access – examining how data is filtered or scoped
• Session/identity – validating token verification and refresh mechanisms
• Input → output encoding – confirming user-supplied data is safely encoded before reaching sinks

Any discrepancy between a protected path in one handler and an unprotected counterpart in another is flagged as a potential security gap.

Stage 4: Intent vs. Implementation Cross-Reference

This stage invokes the intended-vs-implemented skill defined in pm-ai-shipping/skills/intended-vs-implemented.md (lines 18-25). The audit compares documented security intent—stored under documentation/*.md and produced by the shipping-artifacts skill (see pm-ai-shipping/skills/shipping-artifacts.md, lines 24-30)—against actual code enforcement.

• If a security rule is documented but lacks a matching enforcement point in code, the audit flags a gap.
• If documentation is missing, the audit recommends running /document-app first to generate the required architecture and permissions documents.

Stage 5: Self-Refutation and Evidence Validation

For each candidate finding, the engine attempts to disprove its validity by searching for concrete mitigations such as sanitizers, hard-coded safe values, or pre-flight gateways. Only findings that survive this rigorous refutation—those with cited evidence (file + line) demonstrating an unmitigated risk—are retained in the final report. This methodology, detailed in lines 42-78 of security-audit-static.md, ensures the output contains zero false positives.

The High-Miss Security Checklist

The audit specifically targets the most common security defects that AI-generated applications tend to overlook. According to lines 50-64 of security-audit-static.md, the high-miss checklist includes:

• Service-role boundary violations
• Auth-provider drift
• Forgeable request signals
• Missing output encoding
• Server-side request forgery (SSRF)
• Parser differentials
• Fail-open paths
• Secret leakage
• Public-data violations

Running the Security Audit

Execute the audit from your repository root using the following syntax:

# Run a full-repo static security audit

/ security-audit-static

# Limit the audit to a specific subsystem (e.g., Supabase functions)

/ security-audit-static supabase/functions

The command produces a concise, structured report grouping findings by file and severity:

Security Audit: supabase/functions

supabase/functions/auth.ts:
  1. [HIGH] Authorization  src/auth.ts:42
     Risk Level: High
     Attack Scenario: attacker crafts JWT → bypasses role check → reads other users' rows
     Impact: Confidential user data exposure
     Solution: enforce row‑level security filter on every query; verify JWT signature

Upon completion, the audit suggests optional next steps: writing findings to a markdown report (e.g., /reports/security_audit_20240624.md), running /performance-audit-static for complementary checks, or executing /ship-check to generate the full shipping packet with documentation updates.

Summary

• The pm-ai-shipping plugin adds deterministic static security auditing to AI development workflows through the /security-audit-static command.
• The audit maps entry points to trust boundaries and sinks using a recall-first approach that ensures comprehensive coverage.
• Cross-referencing documented intent against code implementation catches security rules that exist in documentation but not in enforcement logic.
• A self-refutation stage eliminates false positives by requiring concrete evidence (file + line) of unmitigated risk.
• The high-miss checklist targets AI-specific vulnerabilities including auth drift, SSRF, and fail-open paths.

Frequently Asked Questions

What documentation is required for the intent vs. implementation comparison?

The audit requires security intent documents stored under documentation/*.md, including architecture.md, flows.md, and permissions.md, which are generated by the shipping-artifacts skill. If these files are missing, the audit recommends running /document-app before proceeding with the security check.

How does the audit handle false positives?

Through its self-refutation stage, the engine actively attempts to disprove each candidate finding by searching for mitigating controls like sanitizers, hard-coded safe values, or pre-flight gateways. Only findings that survive this challenge and present concrete evidence of unmitigated risk are included in the final report.

Can I run the security audit on specific subdirectories?

Yes, by providing a path argument to /security-audit-static, you can restrict analysis to a specific directory or subsystem. For example, /security-audit-static supabase/functions limits the scan to the Supabase functions directory while maintaining the same rigorous five-stage pipeline.

What makes this different from traditional static analysis tools?

Traditional tools often rely on pattern matching alone, whereas the pm-ai-shipping audit employs a documentation-driven intent model that compares specified security requirements against actual implementation. This combination of static code analysis and cross-referencing ensures findings are both real (evidence-backed) and relevant (cross a trust boundary).

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}