What Is the security-audit-static Command? Mapping Trust Boundaries in AI-Built Code

The security-audit-static command is a static analysis tool that audits repositories for security risks by mapping entry points to trust boundaries and dangerous sinks, then verifying that documented security intent matches actual code implementation.

The security-audit-static command is a built-in security tool in the phuryn/pm-skills repository designed to analyze AI-generated codebases. It performs exhaustive static analysis to identify vulnerable data flows before they reach production, ensuring that trust boundaries are properly enforced between user-controlled input and privileged operations.

How the security-audit-static Command Works

Command Invocation and Scope

Run the command with no arguments to audit the entire repository, or pass a specific path to narrow the scope to a particular directory.

/security-audit-static

/security-audit-static supabase/functions

According to the source code in pm-ai-shipping/commands/security-audit-static.md, this invocation triggers a comprehensive analysis that reads every file in the chosen scope before applying pattern matching.

Mapping Entry Points to Trust Boundaries

The audit implements a "recall-first" strategy that processes full files, then greps for handler, route, or shared-helper names to ensure no hidden path is overlooked.

Entry points are any public-facing interfaces where external data enters the system:

• HTTP/RPC handlers
• Edge/serverless functions
• Webhooks and queue consumers
• Upload handlers
• Authentication callbacks
• Cron-triggered endpoints

Trust boundaries are the logical validation points where user-controlled data crosses from an untrusted environment into the application's secure core. The audit traces every path from each entry point to every sink (see lines 28-33 in pm-ai-shipping/commands/security-audit-static.md).

Identifying Security Sinks

Sinks are operations that can cause security violations when fed uncontrolled data. The command specifically checks for:

• Raw SQL queries
• Shell execution
• eval / new Function calls
• HTML/template rendering
• Outbound network calls
• Filesystem writes
• IAM/role modifications
• Logging of sensitive data
• Deserializers (YAML/XML, archives)
• Response headers
• LLM prompts and tool calls (to guard against prompt injection)

Intent vs. Implementation Verification

The command cross-references code against documentation in /documentation/*.md. Any documented security rule not enforced in the actual implementation is flagged as a finding. This verification ensures that stated security policies match operational reality (see lines 38-41 in the source file).

Self-Refutation and Evidence-Based Findings

For each candidate issue, the audit attempts to disprove it by searching for concrete mitigations. Valid counter-evidence includes:

• Input sanitizers and validators
• Hard-coded security values
• Configuration flags
• Explicit authorization checks

Only findings that survive this evidence-based challenge appear in the final report (see lines 42-46 in pm-ai-shipping/commands/security-audit-static.md).

Understanding Trust Boundary Mapping

The core methodology traces every path from an entry point across the trust boundary to a sink. This reveals exactly where an attacker could influence privileged resources, such as database queries executed without row-level security, unauthenticated webhook processing, or LLM prompt injection.

The audit focuses on four critical security domains:

• Authorization – Verifying access controls are enforced
• Data access – Ensuring proper query filtering and tenant isolation
• Session/identity handling – Validating authentication state
• Input→output encoding – Preventing injection attacks

By comparing sibling handlers, the tool spots inconsistencies where one endpoint enforces a security check while another omits it (see lines 34-37 in the source file).

Interpreting Audit Reports

Surviving findings are grouped by file, severity, and category in a structured markdown report. Each entry includes the risk level, attack scenario, impact assessment, and concrete remediation steps. The report concludes with root-cause themes, confirmation of well-built components, and open questions for developers (see lines 66-71 in pm-ai-shipping/commands/security-audit-static.md).

Example finding:

Security Audit: supabase/functions

src/api/auth.js:
  1. [HIGH] Authorization Missing org filter
     Risk Level: High
     Attack Scenario: attacker → HTTP handler → DB query without org filter → all rows exposed
     Impact: Data leakage across tenants
     Solution: Add `where(org_id = $request.user.orgId)` to all queries

Self-refutation example:

Refuted: The query includes a hard‑coded org filter, so no privilege escalation is possible.

Summary

• The security-audit-static command in phuryn/pm-skills performs static analysis on AI-built code to identify security vulnerabilities before deployment.
• It maps entry points → trust boundaries → sinks using a recall-first approach that reads entire files before pattern matching to ensure comprehensive coverage.
• The audit cross-references implementation against documentation/*.md to verify that documented security intent matches code reality.
• Each finding undergoes self-refutation to eliminate false positives by seeking concrete mitigations such as validators or hard-coded filters.
• Reports are structured markdown documents grouped by severity, with specific attack scenarios, impact assessments, and remediation steps.

Frequently Asked Questions

What entry points does the security-audit-static command detect?

The command identifies HTTP/RPC handlers, edge/serverless functions, webhooks, queue consumers, upload handlers, authentication callbacks, and cron-triggered endpoints as entry points where external input first enters the system.

How does the security-audit-static command prevent false positives?

For each potential vulnerability, the command attempts self-refutation by searching for concrete mitigations such as input sanitizers, validators, hard-coded security values, or configuration flags. Only risks that survive this evidence-based challenge appear in the final report.

Can I run the security-audit-static command on specific directories only?

Yes. While running /security-audit-static with no arguments audits the entire repository, you can pass a subdirectory path such as /security-audit-static supabase/functions to limit the scope to specific code paths.

Why does the security-audit-static command check LLM prompts and tool calls?

Modern AI-built applications often construct dynamic prompts or invoke tools with user-influenced data. The command treats these as security sinks to prevent prompt injection attacks where malicious input could manipulate AI behavior, override instructions, or leak sensitive context through tool parameters.

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