security-ownership-map
version: 0.1.0
security-ownership-map
Overview
Static security audits catch what is wrong with the code. They don't tell you who would notice if it broke — and crucially, who would notice if it broke and the original author left. The bus-factor problem in security terms: a sensitive file with one contributor is a single-point-of-failure. When that contributor leaves, the file becomes "abandoned code" — no active review, no security vigilance, no migration path when frameworks upgrade.
This skill turns git history into a people↔file topology and surfaces the security-relevant patterns:
- Orphan sensitive files: high-risk files (auth, crypto, secrets, payment) with no contributor in 12+ months
- Hidden owners: a module whose commit history shows only one author; not officially documented as owner
- Bus-factor hotspots: critical-path files where N=1 contributor holds 100% of expertise
- Maintainer concentration: top-K authors' share of sensitive LOC; if one team owns 80% of sensitive code, the team's departure is a single point of failure
This is security governance — not security code review. Pairs with security-and-hardening (the per-line code audit) and security-devsecops (the supply-chain layer).
Source material adapted from openai's .curated/security-ownership-map; the YAML/Neo4j/Gephi outputs were dropped in favor of CSV/JSON + a Markdown summary, which covers the same questions without the dependency.