supply-chain-attack-recon

Maps external software supply-chain attack surface across GitHub orgs, package registries, and CI/CD pipelines.

Updated May 29, 2026
One-click install
npx skills add https://github.com/hhjkjkjk/Claude-skills --skill supply-chain-attack-recon-hhjkjkjk
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: supply-chain-attack-recon
Source: https://github.com/hhjkjkjk/Claude-skills/tree/main/skills/supply-chain-attack-recon
Command: npx skills add https://github.com/hhjkjkjk/Claude-skills --skill supply-chain-attack-recon-hhjkjkjk

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Security teams struggle to systematically identify supply-chain weaknesses—dependency confusion candidates, typosquat openings, GitHub Actions injection flaws, and leaked internal package names—across a target's public footprint before attackers find them. ## Core Features & Use Cases - Dependency-Confusion Detection: Discovers internal package names in JS bundles, package.json, and requirements.txt, then checks whether those names are unclaimed on npm, PyPI, RubyGems, or Go modules. - GitHub Actions Injection Scanning: Flags pull_request_target workflows, untrusted context interpolation, mutable action tags, and self-hosted runner exposure in public repositories. - Registry & SBOM Mining: Enumerates Docker Hub/GHCR images, extracts secrets from image layers, and parses published SBOMs to map exact dependency versions against OSV/NVD known vulnerabilities. - Use Case: During an authorized external red-team engagement, point the workflow at a target's public GitHub org to produce a calibrated list of supply-chain findings—each with concrete package names, exploitability evidence, and severity ratings. ## Quick Start Run external supply-chain reconnaissance against the target's public GitHub organization and report any unclaimed internal package names, injectable workflows, and leaked registry credentials.

Frequently Asked Questions about supply-chain-attack-recon

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I check for dependency confusion vulnerabilities?▼

Extract internal package names from JS bundles, package.json, or requirements.txt, then query npm, PyPI, RubyGems, and Go module registries for 404 responses. A name is only exploitable if the target's build system resolves packages from public registries without scope-mapping.

How to find GitHub Actions workflow injection vulnerabilities?▼

Scan .github/workflows files for pull_request_target triggers, untrusted github.event context interpolated into run blocks, mutable action tags instead of pinned SHAs, and self-hosted runners on public repos. The pull_request_target plus checkout of PR head pattern is critical severity.

What tools scan Docker images for leaked secrets?▼

trufflehog and gitleaks scan extracted image layer filesystems for credentials. Pull the image, export it with docker save, extract the layer tarballs, then run trufflehog filesystem against the extracted directory.

Can I publish a typosquat package to test dependency confusion?▼

No, not without explicit written scope-clarified authorization. Publishing to public registries affects the entire npm/PyPI ecosystem beyond the engagement and may be illegal. Reconnaissance and identification of unclaimed names is the deliverable.

Why is an unclaimed package name not automatically exploitable?▼

Exploitability requires evidence the target's build system resolves names from public registries, such as missing @scope:registry mapping in .npmrc or the package actually appearing in build dependencies. A 404 on the registry alone is informational only.

What supply-chain findings are out of scope for external recon?▼

Internal artifact registries like private Nexus, JFrog, or Sonatype instances are internal infrastructure and out of scope. Report leaked internal registry URLs as findings but do not enumerate or access them.