Security Audit

When to use

• The user needs a ranked OWASP-mapped findings report for a PHP project — injection, CSRF, auth gaps, insecure config — prioritised by ROI so the riskiest cheap fixes come first.
• The user wants to find secrets committed to the repo — API keys, passwords, private keys, tokens in .env, config, or history — and record them as findings.
• The user asks to security-audit or pentest-review an existing PHP codebase for OWASP Top 10 issues, injection, CSRF, broken auth, or misconfiguration, wanting ranked findings.

When NOT to use

• Do not use this audit skill to implement one specific defense; once the finding is recorded, hand off to the matching security skill (for example security/sql-injection-prevention) to write the fix.
• Do not use this skill for network, host, or dependency-CVE scanning; it audits application PHP source for code-level security issues, not infrastructure.

Core guidance

• Cross-link each finding to a security skill — Set each AUD-SEC finding's remediation to the concrete security skill that fixes it — injection to security/sql-injection-prevention, general classes to security/owasp-top-10-php — so the audit hands off to executable defenses.
• Map every finding to an OWASP category — Tag each AUD-SEC finding with its OWASP Top 10 category (for example A03 Injection, A01 Broken Access Control, A07 Identification and Authentication) so risk is classified consistently and gaps in coverage are visible.
• Scan tracked files and history for secrets — Grep tracked files and git history for high-entropy strings and known key formats (AWS keys, private keys, JWT secrets, DB passwords), and raise a high-severity finding for each, since a committed secret is compromised even after removal.
• Rate severity by exploitability and blast radius — Rate an AUD-SEC finding's severity by how easily it is exploited and how much it exposes — an unauthenticated SQL injection on a public endpoint outranks a stored XSS behind admin login — then feed severity into roi_score = (impact * severity * confidence) / effort.
• Trace tainted input to a dangerous sink — Follow user-controlled input ($_GET, $_POST, $_REQUEST, headers, request body) from source to sink — SQL, shell, HTML output, file paths, eval — and only raise an injection finding when a tainted value reaches a dangerous sink unsanitized.

Decision Engine

Walk this section before choosing an implementation path.

What is the dominant risk in the sampled code — untrusted input reaching a sink, a
committed secret, a missing CSRF or auth guard, or an insecure default?

├── a state-changing route lacks CSRF or authorization: → Raise an A01/A07 finding citing the route and handler, rate severity by whether the
endpoint is public, and link security/owasp-top-10-php for the guard.

├── the risk is an insecure default or weak crypto, not input: → Raise an A05 misconfiguration or A02 crypto finding citing the config or hashing
call, and recommend the secure default (for example password_hash, secure cookies).

├── user input reaches SQL, shell, or HTML unsanitized: → Raise an A03 injection AUD-SEC finding with the source-to-sink path as evidence and
remediation set to security/sql-injection-prevention or output encoding.

└── a live secret is committed to the repo or history: → Raise a high-severity credential-exposure finding, cite the location with the value
masked, and set remediation to rotate and revoke the credential.

Full engine: references/decision-engine.md — Decision Tree, Priority Matrix, Decision Table.

Workflows

Workflow: Scan Security

Progress:
- [ ] Enumerate request-input entry points, state-changing routes, and where credentials
live (.env, config, history), scoping the scan to application source and excluding
vendor and example files
- [ ] Trace each input source to its sink to confirm real injection, verify CSRF and auth
on mutating routes, and confirm secret hits look live rather than placeholder
- [ ] Write each confirmed exposure as an AUD-SEC finding with masked evidence and its
OWASP category, compute roi_score from exploitability-weighted severity, sort
descending, and cross-link the security fix skill

1. Enumerate request-input entry points, state-changing routes, and where credentials live (.env, config, history), scoping the scan to application source and excluding vendor and example files.
   • Verify: You have a list of input sources, mutating routes, and candidate secret locations.
2. Trace each input source to its sink to confirm real injection, verify CSRF and auth on mutating routes, and confirm secret hits look live rather than placeholder.
   • Verify: Each candidate is confirmed as a real exposure or dropped as a false positive.
3. Write each confirmed exposure as an AUD-SEC finding with masked evidence and its OWASP category, compute roi_score from exploitability-weighted severity, sort descending, and cross-link the security fix skill.
   • Verify: Findings are OWASP-mapped, sorted by roi_score, and each links a remediation skill.

Workflow: Hunt Secrets

Progress:
- [ ] Run a secret scanner or grep tracked files and `git log -p` for known key formats and
high-entropy strings, excluding example files, fixtures, and docs
- [ ] Confirm each hit looks like a live credential, raise a high-severity finding with the
value masked and location cited, and set remediation to rotate/revoke and scrub
history

1. Run a secret scanner or grep tracked files and git log -p for known key formats and high-entropy strings, excluding example files, fixtures, and docs.
   • Verify: You have a candidate list of secret hits with their file and commit locations.
2. Confirm each hit looks like a live credential, raise a high-severity finding with the value masked and location cited, and set remediation to rotate/revoke and scrub history.
   • Verify: Each real secret is a finding with a masked value and a rotate-not-delete remediation.

Best practices

• For every state-changing route (POST/PUT/DELETE), confirm a CSRF token check and an authorization gate; a missing token or an unguarded mutating endpoint is a finding citing the route definition and handler

Anti-patterns

See references/anti-patterns.md.

Debugging

1. Flagging placeholder secrets in examples — Placeholder credentials are not exposures, and reporting them wastes rotation effort and dilutes real findings. Fix: Exclude *.example, fixtures, and docs, and confirm a hit looks like a live credential (real format, real host) before raising a high-severity finding.
2. Flagging ORM calls as injection — Over-reporting safe ORM usage buries the real raw-SQL injections and erodes trust in the audit. Fix: Only raise an injection finding when input reaches raw SQL (DB::raw, whereRaw, string-concatenated queries, mysqli_query with interpolation); bound ORM calls are safe.
3. Assuming a deleted secret is safe — A committed secret is compromised the moment it is pushed; deletion does not rotate or revoke it. Fix: Mark the finding remediation as "rotate the credential" (and scrub history), not "delete the file", and rate severity by the secret's blast radius.

Production checklist

• Each AUD-SEC finding cites path:line and, for injection, the tainted source and the dangerous sink.
• Every AUD-SEC finding names its OWASP Top 10 category and the report notes which categories were reviewed.
• Each finding's remediation links security/sql-injection-prevention, security/owasp-top-10-php, or another fix skill.
• Every AUD-SEC finding has a roi_score and the report is sorted descending by it.
• Secret findings show a masked value, cite the location, and set remediation to rotate the credential.
• Severity reflects exploitability and blast radius, not a flat rating, and feeds the roi_score.

Version notes

• Legacy hashing and removed crypto across PHP versions (PHP >=7.4) — Auditing PHP 7.4-8.4 should flag md5/sha1 password hashing and mcrypt usage (mcrypt was removed in 7.2) as findings, recommending password_hash() with a modern algorithm; the default PASSWORD_DEFAULT remains bcrypt across this range.

Security

• The audit report is itself sensitive — Treat the AUD-SEC report as sensitive — it is effectively a map of how to attack the system. Redact live secret values, avoid shipping working exploit payloads, and share it only through trusted channels.
• Committed secrets must be rotated, not just deleted — When a finding is a committed secret, the remediation is to rotate and revoke the credential and scrub history — never merely delete the file, since the value is already exposed in every clone and the git log.

Testing

• Activation and decision behavior are verified in eval/scenarios/audit/security.yaml.

Additional resources

• references/anti-patterns.md
• references/core.md
• references/decision-engine.md
• references/examples.md
• references/pitfalls.md
• references/recipes.md
• references/version-differences.md

Knowledge graph

Related: audit/project-analysis, security/owasp-top-10-php, security/sql-injection-prevention
Behavior constraints: ai-rules/strategy-security-first

Skill contract

Produces: audit.security-findings
Requires: repo.php-sources
Risk: high · Confidence: 0.9