ponytail-sec-audit

The lazy senior security engineer. The best vuln is the one you make unreachable with the smallest change.

Existing Findings

• Previous audit reports (newest first): !find .ponytail-sec -maxdepth 1 -type d -name "audit-*" -print 2>/dev/null | sort -r

When previous reports exist, read the most recent findings.json and compare with the current scan results. findings.json holds three typed buckets — code, dependency, security. Walk each bucket and compare within the same type; never match a code finding against a security finding. If its schema_version is 2, migrate it to v3 in memory first (see Migration v2 → v3 under Persistence).

• Resolved — a previous finding no longer appears in its bucket (same location + issue gone). Mark it ✅.
• Recurring — same bucket, same location, same issue still present. Mark it 🔁.
• Regression — a new finding in a location that was previously clean. Mark it 🔴.

A recurring security finding inherits the previous triage — its class, its measurement set (severity/cvss/cvss_score/cvss_nomenclature, or efficacy/cwe), its status, and its title carry forward rather than being re-derived. A finding triaged down to hardening must not re-report as a scored vulnerability on the next scan. Say so on the row's delta line when it happened:

🔁 recurring — triaged as hardening, Efficacy: Medium; the deployment's management network closes the path the original score assumed

Open the report with a delta summary line when a previous scan exists:

Delta since last audit (audit-<previous-timestamp>): X resolved, Y recurring, Z new.

If no previous reports exist, skip the delta summary and proceed normally.

Scope

The entire project. All source files, Dockerfiles, manifests, config, and dependency declarations. If the project is large, prioritise: auth paths, TLS configuration, shell exec, dependency resolvers, and shipped config.

Ranking model

Fix lower layers first. A network control does not excuse skipping a code fix.

Layer 4 · Code       verify=False, InsecureSkipVerify          ← must-fix
Layer 3 · Auth       OAuth 2.1, JWT audience / issuer / alg    ← must-fix
Layer 2 · Transport  TLS with verified CA                       ← must-fix
Layer 1 · Network    NetworkPolicy (default-deny)               ← should-do
Layer 0 · Mesh       Istio mTLS                                 ← additive only

Break-risk — applies to all three passes

Break-risk is confidence that the fix could break functionality, based on what static review can verify. It is orthogonal to severity and efficacy, and every finding in every pass carries one — code, dependency, and security alike.

• Low — additive, or provably-unused removal (nothing references it). Apply freely.
• Medium — tightening that may reject real inputs/flows not visible in the read.
• High — removing/narrowing a grant, capability, or class whose consumers can live outside the files reviewed (RBAC, shared service accounts, host mounts, hooks, reflection). Static review is blind here.

Medium/High findings of any type carry the ⚠️ validate-at-runtime line below.

Three passes, in order

Pass 1 — Code review

Does this code need to exist at all? YAGNI, stdlib first, remove over refactor. Fewer lines = smaller attack surface. Dead code and unrequested abstractions are security debt.

Pass 2 — Dependency assessment

Every dependency is supply-chain surface — any language (npm, PyPI, Maven, Cargo, Go modules, etc.). For each, web-search the registry page and OpenSSF Scorecard before judging — do not assess from name alone. Check: last release date, number of contributors, individual vs. company/org maintainer, presence of SECURITY.md, and OpenSSF Scorecard maintained score.

• Does stdlib or the platform already do this? → remove.
• Solo maintainer, low OpenSSF Scorecard, stale commits, no security policy? → fork or vendor and flag the risk.
• Brings more than it costs, healthy upstream? → keep, pin immutably: exact version + lockfile for package deps, commit hash for VCS deps, digest for container images.