ponytail-sec
Ponytail security companion and audit: diff-scoped hardening for active development, plus full-project security scans.
Open source Open in the app JSON README (API)
About
Ponytail security companion and audit: diff-scoped hardening for active development, plus full-project security scans.
Details
- Kind
- Plugins
- Topic
- Security & identity
- Publisher
- andypitcher
- Origin
- gemini
- Category
- ferramentas
- Version
- 0.2.3
- Stars
- 8
- Forks
- 1
- Last push
- 2026-08-31T15:49:21Z
- Repository state
- ativo
- License
- MIT
- Added
- 2026-08-30 14:13:39
- Updated
- 2026-08-30 14:13:39
- Origin id
andypitcher/ponytail-sec
README
<p align="center">
<img src="assets/logo.png" width="220" alt="ponytail-sec, the lazy senior security engineer">
</p>
<h1 align="center">ponytail-sec</h1>
<p align="center">
<em>The smallest change that ruins an attacker's day.</em>
</p>
<p align="center">
<a href="https://securityscorecards.dev/viewer/?uri=github.com/andypitcher/ponytail-sec">
<img src="https://api.securityscorecards.dev/projects/github.com/andypitcher/ponytail-sec/badge" alt="OpenSSF Scorecard">
</a>
</p>
---
ponytail's security sibling. Instead of flooding you with findings, it hunts
the one dropped capability, the one `readOnlyRootFilesystem: true`, the one
narrowed RBAC verb that kills a link in the attack chain. Butterfly effect
for defense: tiny diffs, outsized reduction in attacker leverage.
A Claude Code plugin for focused security review: `/ponytail-sec` for your
current diff, `/ponytail-sec-audit` for the whole repo.
Same dependency lens as [ponytail](https://github.com/DietrichGebert/ponytail):
"Do I actually need this dep?" Fewer dependencies = smaller supply-chain
attack surface. Prefer remove over keep.
## Before / After
```yaml
# before — process runs as root, can write anywhere, keeps default capabilities
containers:
- name: controller
image: ghcr.io/example/controller:latest
```
```yaml
# after — pin the image, remove root, confine runtime behavior
containers:
- name: controller
image: ghcr.io/example/controller:v1.2.3@sha256:3b7c4e9a1f2d8c6b5a0e9d4c3b2a1908f7e6d5c4b3a2918070605040302010aa
securityContext:
runAsNonRoot: true
readOnlyRootFilesystem: true
seccompProfile:
type: RuntimeDefault
seLinuxOptions:
type: container_t
capabilities:
drop: ["ALL"]
```
One diff. One closed kill-chain link.
## Install
### Claude Code
Latest:
```
/plugin marketplace add andypitcher/ponytail-sec
/plugin install ponytail-sec@ponytail-sec
```
Pinned to a version:
```
/plugin marketplace add andypitcher/ponytail-sec@0.2.3
/plugin install ponytail-sec@ponytail-sec
```
### Gemini CLI
Latest:
```bash
gemini extensions install https://github.com/andypitcher/ponytail-sec
```
For development/local testing:
```bash
gemini extensions link .
```
## How it works
Three passes, in order:
```
1. Code review Does this code need to exist at all?
Apply the ponytail lens first: YAGNI, stdlib first,
remove over refactor. Fewer lines = smaller attack surface.
2. Dependency Does this dependency need to exist?
Every dep is supply-chain surface. For each one, ask:
a. Does stdlib or the platform already do this? → remove the dep
b. Is it maintained by a single person, or has a
low OpenSSF Scorecard / no recent commits? → fork or vendor
c. Does it bring more than it costs? → keep, pin immutably
Prefer: remove > stdlib > vendor > immutable pin > keep floating.
3. Hardening Four stages, top-to-bottom. Stage 1 break voids all below.
Rank within each stage by attacker leverage removed ÷ lines changed.
The smallest change that ruins an attacker's day wins.
Default output: up to 3 material findings total; no padding. More only on request.
```
Report only what breaks an attack path. Security theater goes unreported.
## Kill-chain stages
```
Stage 1 · Trust Can the attacker forge or bypass identity?
· Trust-anchor material (JWKS, CA certs, OAuth) over verified TLS?
· Token validation complete — issuer, audience, algorithm, scope, expiry?
· Auth bypass modes guarded to non-production?
Stage 2 · Authz If they're in, can they escalate?
· RBAC narrowed to minimum verbs/resources?
· Claims validated server-side, not just checked for presence?
· Write paths gated from read paths?
Stage 3 · Exec If they execute, can they escape?
· Container: non-root, readOnlyRootFilesystem, capabilities.drop: [ALL]
· Supply chain: base images pinned to digest, deps verified
· Injection: no shell=True, no unsafe deserialization
Stage 4 · Data If they're in, what do they reach?
· Secrets hardcoded, in env, in manifests?
· Unnecessary ports, debug endpoints?
· TLS on all in-transit paths?
```
## Safe by design
Lists findings, fixes nothing. The agent reads the skill and reports; it never
applies changes, runs untrusted code, or touches production.
⚠️ 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.
ponytail-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.
## Usage
**`/ponytail-sec`** — The security engineer sitting next to you while you
code. Scopes to your current diff. Three passes, up to 3 material findings,
lean output. Ends with Ship or Ship blocked — nothing in between. Invoke
directly or say "harden this", "security review", "is this dep safe",
"reduce attack surface".
**`/ponytail-sec-audit`** — Full project scan. All findings, CVSS 4.0 scored,
with blast-radius narrative and a frank "if I were you" prioritisation that
may differ from the score order. Invoke directly or say "full security audit",
"audit the project", "security scan".
## Relation
Part of the [ponytail](https://github.com/DietrichGebert/ponytail) skill
family. Same voice, security lens.
MIT license.