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

> Discover how the pm-ai-shipping plugin performs static security audits on AI-built code mapping entry points to trust boundaries and validating findings to surface real security risks.

- Repository: [Pawel Huryn/pm-skills](https://github.com/phuryn/pm-skills)
- Tags: how-to-guide
- Published: 2026-06-24

---

**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](https://github.com/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`](https://github.com/phuryn/pm-skills/blob/main/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`](https://github.com/phuryn/pm-skills/blob/main/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`](https://github.com/phuryn/pm-skills/blob/main/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`](https://github.com/phuryn/pm-skills/blob/main/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`](https://github.com/phuryn/pm-skills/blob/main/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`](https://github.com/phuryn/pm-skills/blob/main/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:

```bash

# 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:

```text
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`](https://github.com/phuryn/pm-skills/blob/main//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`](https://github.com/phuryn/pm-skills/blob/main/architecture.md), [`flows.md`](https://github.com/phuryn/pm-skills/blob/main/flows.md), and [`permissions.md`](https://github.com/phuryn/pm-skills/blob/main/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).