mr-tbot/bot-code-mods/auto-audit-security

/auto-audit-security

An adversarial security review of this codebase, plus an honest compliance-readiness assessment — findings first, fixes only when you approve them.

The boundary, stated once and never blurred: a code audit produces INPUT EVIDENCE to a compliance program. It never produces the compliance artifact. SOC 2 is an attestation engagement performed under SSAE 18 by an independent licensed CPA firm; ISO 27001 is certified by an accredited body. What this skill produces is a readiness assessment: which technical controls are evidenced in the code, which are missing, and what an auditor will ask for that no repository can answer.

Two facts worth getting right, because vendors routinely get them wrong:

• The Trust Services Criteria comprise 61 criteria, of which 18 are the privacy category.

Higher counts in circulation (64, 80+) come from counting points of focus as criteria — they are explicitly not criteria.

• A SOC 2 report is restricted-use. SOC 3 is the general-use report. If the goal is something

publishable on a marketing site, that is SOC 3, and confusing the two misdirects the whole effort.

Everything this skill generates is IPE — information produced by the entity. A service auditor will test its completeness and accuracy before relying on it, so every artifact must record how it was produced, over what population, and at what time.

Step 1 — Scope And Authorization

Establish before running anything:

1. What is in scope — repo only, or deployed environments too? Which environments?
2. Authorization for active testing, in writing. Static review of code you own needs none. **Any

active scan (ZAP, nuclei, fuzzing, credential testing) requires explicit written authorization naming the specific target, and must never be pointed at production, at shared infrastructure, or at a third party.** Staging, a local instance, or not at all. Third-party-hosted components have their own testing policies and are frequently out of bounds regardless of who owns the account.

1. Which frameworks matter — SOC 2, ISO 27001, HIPAA, PCI DSS, GDPR/CCPA, or none. Ask; do not

assume, since the applicable set drives everything downstream.

1. Where findings may be written. Not a public issue tracker. See Handling below.

Step 1b — Decide Which Seats You Are Sitting In

An audit run from one seat produces one class of finding, and the classes it cannot produce look exactly like an absence of problems. Name the passes before you start, and record which you are not running and why — that list belongs in the report's methodology section, because an unexercised seat is a coverage gap, not a clean result.

The colours are the InfoSec colour wheel (April C. Wright, 2017): red, blue and yellow are primary; purple, orange and green are their combinations. White is the referee — NIST defines a White Team as the group refereeing an engagement between a Red Team of mock attackers and a Blue Team of defenders, and here it is the seat that owns authorization, scope and evidence. Black is not a standard term; it is used here for the surface that is not the application.

Authorization is per pass, not per audit. White grants Red and the active half of Green. Blue, Yellow, Purple and Orange are review passes over code and configuration you already own and need no new permission. Never let a Red objective drift into a Black one — social engineering and physical entry require separate, explicit, written authorization naming the people and premises involved, and their absence is a hard stop, not a judgement call.

Purple and Orange are derived. They consume Red's findings, so they produce nothing before Red has run, and a report claiming them without a Red pass behind them is describing work that did not happen.

The most common real outcome on a first audit is that Blue finds nothing to look at — no authentication logging, no alerting, no retention. Record that as the finding it is. "We would not know" is a more serious result than most of the mediums the scanners produce.

Step 2 — Map The Attack Surface

You cannot audit what you have not enumerated. Produce the inventory first:

• Every route/endpoint, with method, and whether it is authenticated
• Every trust boundary — where untrusted input enters, where privilege changes
• Every authentication path, including recovery, SSO, API keys, and service-to-service
• Every entitlement check — what gates a paid feature, and where that check executes
• All data stores, and what class of data each holds (PII, credentials, payment, health)
• All third-party integrations and what each is trusted with
• The shipped client bundle and any mobile binary, treated as fully readable by an attacker

This inventory is the denominator for everything after it. A review that samples routes will miss the one unprotected endpoint, and that is the one that matters.

Step 3 — Access Control, Route By Route

This is the class scanners systematically miss, and the class most likely to be exploitable. It cannot be sampled and it cannot be delegated to a tool.

For every route in the inventory, answer explicitly:

• Does it authenticate? Does it authorize, separately?
• Is the authorization check server-side? A check in the UI layer is not a check.
• Does it verify the caller owns the object it operates on, or only that the caller is logged in?

(That gap is IDOR/BOLA, and it is the most common serious finding in real applications.)

• Can a parameter change the identity or scope of the operation (mass assignment, tampered

user_id, tampered price or quantity)?

• Are administrative functions protected by a role check on the server, or only unlinked in the UI?

Produce a table with a row per route and an explicit verdict per column. "Probably fine" is not a verdict — trace the code path to the check, or record it as unverified.

Step 4 — Licensing And Paywall Bypass

Treat the client as fully hostile and fully readable — it is.

• Entitlement evaluated client-side. If the client decides whether the user is premium, the user

decides whether the user is premium. The server must gate the data, not just the UI.

• Feature flags that only hide UI. Hidden is not disabled. Call the endpoint directly and see what

comes back.

• Trial or license state stored on the device — local storage, preferences, a file, a registry key.

All user-writable.

• In-app purchase receipts validated on device. Receipt validation belongs server-side, against the

store's API.

• Secrets in the shipped bundle: API keys, signing keys, admin endpoints, or private hostnames in

JS bundles, source maps, or a mobile binary. Extract and grep the actual artifact rather than the source tree.

• Premium data on unauthenticated endpoints — the paywalled screen calls an API; call it directly

without a session.

• Quota and rate limits enforced only in the client.
• Price, quantity or plan sent from the client and trusted by the server.

For each: the correct design is that the server independently determines entitlement on every request from state the user cannot write.

Step 5 — The Rest Of The Classes

Cover the current OWASP Top 10 and API Security Top 10. Always name the edition — write `A01:2025`, never a bare `A01` or "OWASP Top 10" — and confirm which edition any scanner ruleset actually encodes before citing it as coverage. Supply-chain findings map to A03:2025 Software Supply Chain Failures. Pull the current codes at audit time rather than reciting them.

By class, with the concrete question to answer in this codebase:

• Injection — SQL/NoSQL/command/template/LDAP. Is every query parameterized? Is any shell command

built from input?

• Authentication — session fixation, rotation on privilege change, lifetime, logout invalidation.

JWTs: is the signature actually verified, is alg pinned, are exp/aud/iss checked, is the secret strong? OAuth/OIDC: strict redirect_uri matching, state, PKCE.

• Password storage — a current memory-hard KDF with current parameters. Verify against present-day

guidance rather than a number remembered from years ago.

• Cryptographic failures — legacy algorithms, ECB mode, static or reused IVs, homegrown crypto, keys

in source, missing TLS verification, certificate pinning that was disabled "temporarily".

• SSRF — any server-side fetch of a user-supplied URL, including webhooks, previews and importers.
• XSS and CSP — output encoding by context, dangerouslySetInnerHTML and equivalents, and whether

CSP is real or unsafe-inline.

• CSRF and SameSite, on every state-changing endpoint that accepts cookies.
• Deserialization, XXE, file upload — type and size validation, storage location, execution

prevention.

• Logging — are credentials, tokens or PII being logged? Is there enough logging to reconstruct an

incident? Both failures are findings.

• Error handling — stack traces or internal paths returned to clients.

Step 6 — Run The Scanners, Then Distrust Them

Automation is the floor, not the audit. It is good at known-vulnerable dependencies and hardcoded secrets, and poor at logic and access control. State that in the report: the access-control findings in Step 3 have no tool path at all, so a reader must not read a clean scan section as covering them.

Separate the reporting run from the gating run. They need different flags, and combining them is how a gate silently narrows: a filter that reduces noise in a report also reduces what the gate can fail on.

# SAST — --error is required for gating; semgrep exits 0 with findings without it
semgrep --config=<pinned-local-rules> --sarif -o semgrep.sarif --metrics=off .        # report
semgrep --config=<pinned-local-rules> --error --metrics=off .                          # gate
pipx install 'bandit[toml,sarif]' && bandit -r src/ -f sarif -o bandit.sarif           # exits 1 on findings
gosec -fmt=json -out=gosec.json ./...