Security Ownership Map
Use Git history to reveal who really owns sensitive code and where bus-factor risk is concentrated.
The scripts primarily read local Git history and write to a user-selected output directory, so the permission scope is relatively limited. However, they export potentially sensitive names, emails, time zones, and commit records without documenting user confirmation, privacy handling, access control, or rollback; dependency-security guidance for pip-installed networkx is also thin, so points are deducted.
The documented workflow, arguments, and scripts are broadly consistent and include some diagnosable errors and exit codes. However, there is no committed test suite or CI evidence, handling of abnormal inputs and invalid sort fields is limited, large-repository behavior is unverified, and static review cannot reproduce key paths, so the score remains below the static ceiling.
Trigger conditions, target scenarios, input scope, and principal outputs are fairly clear, including an explicit exclusion of general maintainer-list and non-security ownership questions. Boundaries, Chinese-language support, and environment requirements are not documented; Neo4j and pip dependencies may reduce usability on mainland-China networks, so points are deducted.
The skill has clear sections, installation notes, quick-start commands, parameter examples, artifact documentation, query examples, and a Neo4j reference. However, the individual license is unknown, and versioning, changelog, explicit maintenance responsibility, and a stable update path are missing; the repository README also says the repository is deprecated, so points are deducted.
The claimed task is concrete: it produces ownership, bus-factor, sensitive-code, and co-change CSV/JSON graph artifacts, with bounded query helpers. But there is no committed test result or representative artifact verification, and path-based sensitivity rules are only a heuristic requiring human review, so the score is capped by static calibration and reduced.
The source code, argument definitions, and output formats are auditable and broadly traceable to the documentation. There is no test suite, CI coverage, third-party execution evidence, or cross-source corroboration, so the evidence supports only a limited score.
- Outputs include identities, emails, time zones, and commit history; confirm authorization and restrict access to generated files.
- Sensitive-code detection is based on path globs and may miss or overflag files; use project-specific rules and human review.
- Installing networkx and importing into Neo4j may depend on external services or network access and should be validated in the target environment.
- The repository README marks the repository as deprecated, so ongoing maintenance should not be assumed.
What it does & when to use it
This skill analyzes Git repositories to build a bipartite graph connecting people and files. It calculates sensitive-code ownership, bus factor, orphaned sensitive code, and low-bus-factor hotspots, then exports graph artifacts for Neo4j, Gephi, and visualization workflows. It also builds a file co-change graph using Jaccard similarity over shared commits to identify clusters and ownership drift. It should trigger only for explicitly security-oriented ownership or bus-factor analysis grounded in Git history.
It reads a local Git repository and its commit history, with optional time-window filters, and by default uses author identity and author dates while excluding merge commits. run_ownership_map.py applies default or CSV-configured sensitive-path rules and analyzes people, files, touches, and co-change relationships; common glue files and Dependabot commits are excluded by default. It writes people.csv, files.csv, edges.csv, cochange_edges.csv, summary.json, communities.json, and graph JSON, with optional commit JSONL and GraphML outputs. query_ownership.py then returns bounded JSON slices for people, files, sensitive tags, communities, and security summary sections.
- A security team needs to find stale sensitive code with a low bus factor.
- An engineering lead wants to identify the actual maintainers of auth or crypto files and compare them with CODEOWNERS.
- A platform team needs to uncover hidden owners, ownership concentration, and sensitive-code maintenance risk.
- An architecture or security researcher wants to cluster files by co-change behavior and investigate ownership drift.
- A team needs CSV or graph exports for Neo4j or Gephi-based ownership analysis.
Pros & cons
- Focused specifically on security ownership and bus-factor analysis from Git history.
- Supports custom sensitivity rules, time windows, author or committer attribution, and merge-commit controls.
- Produces ownership graphs, co-change graphs, communities, and bounded JSON query results.
- Exports CSV and JSON, with optional GraphML for graph-database and visualization workflows.
- Findings depend on the quality of Git history, identity attribution, and sensitivity rules.
- The source does not provide a test suite, platform compatibility matrix, or performance benchmarks.
- It requires Python 3, networkx, and local shell execution.
- The README says the repository is deprecated and points current examples to the OpenAI Plugins repository; the individual skill license is not supplied.
How to install
The skill is in the curated directory of openai/skills. Install it in Codex with $skill-installer security-ownership-map, then restart Codex so the skill is loaded. The README does not provide the individual skill's license text; it says each skill's license should be checked in its directory's LICENSE.txt. The repository-level license is listed as unknown in the source material.
How to use
Trigger it only for explicit security-oriented Git ownership or bus-factor requests, such as “find orphaned sensitive code” or “check whether CODEOWNERS reflects security ownership risk.” From a repository root, run: python skills/skills/security-ownership-map/scripts/run_ownership_map.py --repo . --out ownership-map-out --since "12 months ago" --emit-commits. Then query the results with python skills/skills/security-ownership-map/scripts/query_ownership.py --data-dir ownership-map-out summary --section orphaned_sensitive_code.