Structured workflow for investigating public software supply-chain attacks across local repositories, GitHub organizations, and CI/host fleets. Use when asked to assess exposure to compromised packages, malicious releases, package-manager attacks, GitHub Actions/OIDC abuse, or published IOC lists.
Structured workflow for investigating public software supply-chain attacks across local repositories, GitHub organizations, and CI/host fleets. Use when asked to assess exposure to compromised packages, malicious releases, package-manager attacks, GitHub Actions/OIDC abuse, or published IOC lists.
Supply-Chain Attack Investigation
Purpose
This skill guides a repeatable, evidence-preserving investigation for third-party supply-chain incidents. It is designed for incidents like compromised npm/PyPI packages, malicious package releases, poisoned GitHub Actions workflows, CI credential theft, and public IOC advisories.
The core pattern is:
Ingest public reporting and IOC sources.
Build a dedicated investigation folder.
Run a repository-side track.
Run or prepare a separate CI/host-side collector track.
Merge key conclusions into a scoped main report.
Do not modify remote repositories, revoke credentials, delete artifacts, or perform cleanup unless the user explicitly asks for that as a separate remediation task. This skill is for investigation and evidence collection.
First Response: Scope Before Scanning
If the user has not already provided these details, ask for them before beginning substantial work. Do not guess paths, organizations, or credentials.
Ask for:
Incident name or short label.
Links to public reporting, advisories, IOC pages, or vendor posts.
Any affected package lists: CSV, JSON, table, advisory text, SBOM export, lockfile package list, etc.
Desired investigation output folder, or permission to create one using the date and incident name.
Whether to scan local repositories.
If yes: repo root(s), whether to scan recursively or immediate children only, and whether the agent may run git fetch to inspect remote default branch metadata. Never run unless explicitly requested.
git pull
Whether to scan a GitHub organization.
If yes: org name and token source (GITHUB_TOKEN, .env, gh auth, etc.). Use read-only API/code search. Do not clone every repository.
Whether to scan CI/host systems.
If yes: host/IP list or Tailscale CSV, SSH username, SSH key path, and whether the agent should run the fleet collector or only prepare tooling for the user to run.
Explicit out-of-scope repos, systems, paths, or networks.
Audience: internal-only, customer-facing, or both.
If credentials are unavailable, prepare scripts and instructions so the user can execute the relevant collector and return the outputs.
Investigation Folder Structure
Prefer this structure unless the user gives a different one:
Every incident is different. Treat bundled tools as starting points to adapt, not as proof that the exact same checks are sufficient.
Repository-Side Track
Local repositories
If scanning local repos:
Ask the user whether to scan immediate child repos, recursively discovered repos, or a supplied list.
Report repositories by GitHub remote/org names when available, not local machine paths.
Do not run git pull. If current default-branch freshness matters and credentials are available, ask before running git fetch or remote metadata checks.
Start with targeted files for speed and relevance:
package-name references without affected version confirmation
malware-specific IOC hits
generic workflow-risk terms
Be careful with lockfiles: a package name and an affected version string appearing somewhere in the same file is not automatically a package-version hit. Confirm the version belongs to that package.
GitHub organization repositories
If scanning a GitHub org:
Prefer read-only GitHub API/code search. Do not clone every repo.
Enumerate repositories through the API.
Run GitHub code search for strongest IOC strings first.
Fetch only likely default-branch files: manifests, lockfiles, workflows, CI scripts, Dockerfiles, persistence/config paths.
Preserve raw outputs, errors, and truncated tree details.
State clearly that this reviews default-branch contents unless history scanning was explicitly performed.
CI / Host Collector Track
Keep this separate from repository review.
Before running any remote collector, confirm with the user:
target host list / CSV
SSH username
SSH key path or agent availability
parallelism and timeout
output directory
that read-only remote execution is approved
If credentials are not present, prepare the tools and README and ask the user to run them.
Collectors should gather evidence, not secrets. By default, do not collect token values or secret listings. Prefer:
IOC filename hits.
Hashes of matching IOC files.
Text IOC hits in targeted paths.
Persistence/config hits.
Suspicious git-author commits.
Tool versions and host metadata.
Process/network/DNS context when useful.
Do not run cleanup, deletion, revocation, package installs, or system mutation.
Reporting Requirements
Use three layers:
Main report — concise summary and current conclusion.
run_ci_host_collection.py — SSH fleet runner for CSV or host list.
local_host_collector.sh — single-host local evidence package collector.
These scripts are templates. Adapt them for incident-specific IOCs, package ecosystems, and evidence requirements.
Customer/Internal Wording Pattern
For customer-facing or internal assurance notes, use language like:
We reviewed the currently available public reporting and IOC guidance, scanned the in-scope repositories and default-branch GitHub organization contents, and performed a separate host-side IOC sweep across the reviewed CI fleet. We found no evidence of affected package-version usage or malware-specific IOC presence in those reviewed evidence sources. This conclusion is scoped to the repositories, default branches, and hosts reviewed; it does not independently prove that no developer workstation, historical commit, transient build environment, package cache, or centralized log source ever encountered the affected artifacts.
That precision matters. It prevents a useful investigation from becoming an overclaim.
