{ "markdown": "

\n \"ponytail-sec,\n

\n\n

ponytail-sec

\n\n

\n The smallest change that ruins an attacker's day.\n

\n\n

\n \n \"OpenSSF\n \n

\n\n---\n\nponytail's security sibling. Instead of flooding you with findings, it hunts\nthe one dropped capability, the one `readOnlyRootFilesystem: true`, the one\nnarrowed RBAC verb that kills a link in the attack chain. Butterfly effect\nfor defense: tiny diffs, outsized reduction in attacker leverage.\n\nA Claude Code plugin for focused security review: `/ponytail-sec` for your\ncurrent diff, `/ponytail-sec-audit` for the whole repo.\n\nSame dependency lens as [ponytail](https://github.com/DietrichGebert/ponytail):\n\"Do I actually need this dep?\" Fewer dependencies = smaller supply-chain\nattack surface. Prefer remove over keep.\n\n## Before / After\n\n```yaml\n# before — process runs as root, can write anywhere, keeps default capabilities\ncontainers:\n - name: controller\n image: ghcr.io/example/controller:latest\n```\n\n```yaml\n# after — pin the image, remove root, confine runtime behavior\ncontainers:\n - name: controller\n image: ghcr.io/example/controller:v1.2.3@sha256:3b7c4e9a1f2d8c6b5a0e9d4c3b2a1908f7e6d5c4b3a2918070605040302010aa\n securityContext:\n runAsNonRoot: true\n readOnlyRootFilesystem: true\n seccompProfile:\n type: RuntimeDefault\n seLinuxOptions:\n type: container_t\n capabilities:\n drop: [\"ALL\"]\n```\n\nOne diff. One closed kill-chain link.\n\n## Install\n\n### Claude Code\n\nLatest:\n```\n/plugin marketplace add andypitcher/ponytail-sec\n/plugin install ponytail-sec@ponytail-sec\n```\n\nPinned to a version:\n```\n/plugin marketplace add andypitcher/ponytail-sec@0.2.3\n/plugin install ponytail-sec@ponytail-sec\n```\n\n### Gemini CLI\n\nLatest:\n```bash\ngemini extensions install https://github.com/andypitcher/ponytail-sec\n```\n\nFor development/local testing:\n```bash\ngemini extensions link .\n```\n\n## How it works\n\nThree passes, in order:\n\n```\n1. Code review Does this code need to exist at all?\n Apply the ponytail lens first: YAGNI, stdlib first,\n remove over refactor. Fewer lines = smaller attack surface.\n\n2. Dependency Does this dependency need to exist?\n Every dep is supply-chain surface. For each one, ask:\n a. Does stdlib or the platform already do this? → remove the dep\n b. Is it maintained by a single person, or has a\n low OpenSSF Scorecard / no recent commits? → fork or vendor\n c. Does it bring more than it costs? → keep, pin immutably\n Prefer: remove > stdlib > vendor > immutable pin > keep floating.\n\n3. Hardening Four stages, top-to-bottom. Stage 1 break voids all below.\n Rank within each stage by attacker leverage removed ÷ lines changed.\n The smallest change that ruins an attacker's day wins.\n Default output: up to 3 material findings total; no padding. More only on request.\n```\n\nReport only what breaks an attack path. Security theater goes unreported.\n\n## Kill-chain stages\n\n```\nStage 1 · Trust Can the attacker forge or bypass identity?\n · Trust-anchor material (JWKS, CA certs, OAuth) over verified TLS?\n · Token validation complete — issuer, audience, algorithm, scope, expiry?\n · Auth bypass modes guarded to non-production?\n\nStage 2 · Authz If they're in, can they escalate?\n · RBAC narrowed to minimum verbs/resources?\n · Claims validated server-side, not just checked for presence?\n · Write paths gated from read paths?\n\nStage 3 · Exec If they execute, can they escape?\n · Container: non-root, readOnlyRootFilesystem, capabilities.drop: [ALL]\n · Supply chain: base images pinned to digest, deps verified\n · Injection: no shell=True, no unsafe deserialization\n\nStage 4 · Data If they're in, what do they reach?\n · Secrets hardcoded, in env, in manifests?\n · Unnecessary ports, debug endpoints?\n · TLS on all in-transit paths?\n```\n\n## Safe by design\n\nLists findings, fixes nothing. The agent reads the skill and reports; it never\napplies changes, runs untrusted code, or touches production.\n\n⚠️ Findings are static reads of the diff. When one isn't fully validated — especially \"drop this unused grant\" — the agent tells you to prove it at runtime first: build → run → confirm it still works.\n\nponytail-sec optimises for lean + least-privilege, so a finding can occasionally break something. When it does, don't just restore the broad grant — ask ponytail-sec for a safer angle (mount the Secret as a file, scope it to one name, a short-lived token) that keeps the feature. e2e is your friend.\n\n## Usage\n\n**`/ponytail-sec`** — The security engineer sitting next to you while you\ncode. Scopes to your current diff. Three passes, up to 3 material findings,\nlean output. Ends with Ship or Ship blocked — nothing in between. Invoke\ndirectly or say \"harden this\", \"security review\", \"is this dep safe\",\n\"reduce attack surface\".\n\n**`/ponytail-sec-audit`** — Full project scan. All findings, CVSS 4.0 scored,\nwith blast-radius narrative and a frank \"if I were you\" prioritisation that\nmay differ from the score order. Invoke directly or say \"full security audit\",\n\"audit the project\", \"security scan\".\n\n## Relation\n\nPart of the [ponytail](https://github.com/DietrichGebert/ponytail) skill\nfamily. Same voice, security lens.\n\nMIT license.\n", "bytes": 5995, "sha": "23a7094b439e5f7a02829a169b28189c5d365bd0806af879ad187ed0841b9be2", "repo_slug": "andypitcher/ponytail-sec", "fonte": "repo", "truncated": false, "api": "https://agentalog.com/api/listings/plg_andypitcher_ponytail_sec_8683b6d4/readme" }