supply-chain-attack-recon

Maps external software supply-chain attack surface across public registries, GitHub orgs, and container images.

7|4|Updated Jun 22, 2026
One-click install
npx skills add https://github.com/dbx0/skills --skill supply-chain-attack-recon-dbx0
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: supply-chain-attack-recon
Source: https://github.com/dbx0/skills/tree/main/skills/supply-chain/reconnaissance/supply-chain-attack-recon
Command: npx skills add https://github.com/dbx0/skills --skill supply-chain-attack-recon-dbx0

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Security assessors need a systematic way to identify supply-chain weaknesses—dependency confusion openings, typosquat candidates, CI/CD workflow injection points, and leaked internal package names—using only publicly accessible sources, without crossing into unauthorized offensive action. ## Core Features & Use Cases - Dependency-Confusion Discovery: Extracts internal package names from JS bundles, package.json files, and requirements.txt, then checks npm/PyPI/RubyGems for unclaimed names. - GitHub Actions Injection Scanning: Flags pull_request_target misuse, untrusted context interpolation, and mutable-tag action references across public org workflows. - Registry and SBOM Mining: Enumerates Docker Hub/GHCR images, extracts secrets from layers with trufflehog, and maps SBOM dependency versions to known CVEs via OSV. - Use Case: During an external assessment of a company with a public GitHub org, run the recon steps to find that an internal package referenced in their JS bundle is unclaimed on npm and their workflows use unpinned third-party actions—both reportable findings. ## Quick Start Use the supply-chain-attack-recon skill to enumerate the target organization's public GitHub repos and check their internal package names for dependency-confusion exposure.

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 the target's JS bundles, package.json, or requirements.txt, then query npm, PyPI, and RubyGems for HTTP 404 responses indicating unclaimed names. Confirm exploitability by verifying the build system resolves names from public registries without scope-mapping.

How to find GitHub Actions workflow injection vulnerabilities?

Enumerate .github/workflows files via the GitHub API and grep for pull_request_target triggers, ${{ github.event.* }} interpolation into run blocks, self-hosted runners, and mutable-tag action references. Patterns like unpinned third-party actions or PR-title interpolation into shell commands are high-severity findings.

What tools are used for supply-chain reconnaissance?

The workflow uses trufflehog and gitleaks for secret scanning, osv-scanner for known-CVE matching, actionlint and semgrep for workflow analysis, and packj for package risk scoring. The GitHub CLI handles org and repo enumeration.

Is an unclaimed package name always exploitable?

No. A 404 on a public registry is informational only without evidence the target's build system resolves names from public registries. Proper .npmrc scope-mapping or internal-registry-only configurations prevent dependency confusion even when names are unclaimed.

When should I not use supply-chain recon techniques?

Do not publish typosquat or dependency-confusion packages without explicit written authorization, as this affects the entire public ecosystem. Internal artifact registries like private Nexus or JFrog instances are out of scope for external engagements.