repo-security-posture
Repository Security Posture
Audit a repository's configuration and CI/CD against a set of concrete attacker scenarios, then hand the maintainer a ranked list of hardening todos. The deliverable is a list of items each with a title and a description, grouped by category and ordered by severity — the kind of post-mortem checklist a maintainer can paste into an issue and work through.
The job is not to dump every theoretical best practice. It is to look at this repo, find the gaps an attacker would actually use, and write todos that are specific to what was found (or specific about what couldn't be verified).
Threat model
Every finding should trace back to at least one of these scenarios. Naming the scenario in the description is what makes a todo land — it tells the maintainer why it matters, not just what to toggle.
- Compromised contributor — a trusted contributor's account, laptop, or token is taken over (phishing, malware, leaked PAT). What stops them from merging or publishing malicious code alone?
- Attacker with repo write access — an outside attacker gains push or admin rights. What limits blast radius, what can they exfiltrate, and how fast can the maintainer rotate and recover?
- CI/CD compromise — a malicious PR, poisoned cache, or injected workflow turns the build pipeline into the attack. GitHub Actions is the most common modern repo-takeover path.
- Registry / publish supply chain — the repo is fine but a bad version ships to npm/PyPI/etc. via a stolen publish token or an unreviewed release job. This is the @mastra / dotenvx / TeamPCP class of incident.