agentleFS
metaspartanmetaspartan/cybara/skills/oss-forensics/SKILL.md

oss-forensics

Skill38 starsChanged 5 months agoMITView on GitHub

Investigate open-source repository compromise, deleted commits, force-pushes, suspicious releases, and supply-chain indicators with evidence IDs.

  • Reads credentials

1 other project uses a version of this.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

5 rules. About 0 are common, 4 are distinctive, and 1 is very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈4

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 1

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Use this for defensive supply-chain investigations: suspicious commits, force-pushes, deleted releases, maintainer takeover concerns, …

    line 9
  2. Distinctive:

    Do not run code from the investigated repository.

    line 15
  3. Distinctive:

    Create a working directory outside the target repo:

    line 21
  4. Very specific:

    Use GITHUB_TOKEN if available to avoid low rate limits.

    line 52
  5. Distinctive:

    Create hypotheses, then validate:

    line 63

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

OSS Forensics

Use this for defensive supply-chain investigations: suspicious commits, force-pushes, deleted releases, maintainer takeover concerns, leaked secrets, or package compromise.

Guardrails

  • Evidence first. Every claim needs an evidence ID such as EV-0001.
  • Separate fact from hypothesis. Prefix unverified inferences with [HYPOTHESIS].
  • Do not run code from the investigated repository.
  • Redact secrets in chat and reports.
  • Double-check SHAs, URLs, package versions, and actor names against more than one source when possible.

Evidence Store

Create a working directory outside the target repo:

INVESTIGATION="oss-forensics-$(date +%Y%m%d-%H%M%S)"
mkdir -p "$INVESTIGATION"/{evidence,reports}
cd "$INVESTIGATION"
printf "# Evidence\n\n" > evidence/index.md

Evidence entry shape:

EV-0001
Source: local git log
Time collected: <ISO timestamp>
Claim supported: <short claim>
Artifact: evidence/git-log.txt
Notes: <why it matters>

Collection Plan

  1. Extract targets:
    • repo, package names, SHAs, actors, date range, releases, domains, URLs.
  2. Local git source:
    • git clone --mirror or normal clone.
    • git log --all --full-history --stat --format="%H|%ae|%an|%ai|%s".
    • git fsck --lost-found --unreachable.
    • git branch -a -v, tags, release branches, suspicious binaries.
  3. GitHub/API source:
    • commits, PRs, issues, releases, events, tags.
    • Use GITHUB_TOKEN if available to avoid low rate limits.
  4. Archive sources:
    • Wayback CDX for deleted PRs/issues/releases.
    • GH Archive or public event datasets when date windows matter.
  5. Package registries:
    • npm/PyPI/crates/GitHub Releases metadata, checksums, publish dates.
  6. IOC extraction:
    • domains, IPs, package names, hashes, suspicious scripts, workflow edits.

Analysis

Create hypotheses, then validate:

  • Force-push hide: evidence from local unreachable commits plus public events.
  • Maintainer takeover: unusual actor timing, permissions, workflow changes, signed commit drift.
  • Release/package swap: tag/release/package timestamps disagree or artifacts changed.
  • Secret leak: secret-like material existed in a reachable/dangling commit and was pushed externally.

Report

Include:

  • Scope and timeline.
  • Evidence table.
  • Findings with severity and supporting evidence IDs.
  • Hypotheses ruled out and why.
  • Recommended containment, rotation, and hardening steps.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.