Analyzing TLS Configuration

Overview

This skill audits a target's TLS posture against current best practice (NIST SP 800-52r2, Mozilla TLS Configuration Guidelines, PCI DSS v4.0 Req 4.2.1.1). It reports specific findings — not "your TLS is weak" but "your server negotiated TLSv1.0 with RC4-SHA — see remediation".

When the skill produces findings

Specific failure thresholds, in order of severity:

Prerequisites

• Python 3.9+
• openssl CLI (used for cipher enumeration the Python ssl module can't introspect directly)
• Authorization to test the target (active scan — see references/AUTHORIZATION.md)

Instructions

Step 1 — Confirm Authorization

Active scan. Before invoking the scanner, ask the user verbatim:

> "Do you have authorization to perform TLS testing on this target? > I need confirmation before proceeding."

If the user says yes, proceed. If unsure, ask them to obtain written authorization. See references/AUTHORIZATION.md for the attestation pattern. Never run the scanner against a target the user does not own or have written permission to test.

Step 2 — Run the scanner

python3 ${CLAUDE_PLUGIN_ROOT}/skills/analyzing-tls-config/scripts/analyze_tls.py \
    https://target.ex…

Auditing CORS Policy

Overview

CORS misconfiguration is one of the most common middle-severity findings in web bug bounties. The browser-enforced rules are subtle, the failure modes are silent (the wrong cors response just works until an attacker weaponizes it), and the "fix" engineers reach for — Access-Control-Allow-Origin: * — opens the very class of attacks CORS was meant to prevent when paired with credentials.

This skill probes each common CORS misconfiguration with synthetic Origin headers and grades the response.

When the skill produces findings

Prerequisites

• Python 3.9+ (requests library)
• Authorization for non-local targets (../analyzing-tls-config/references/AUTHORIZATION.md)

Instructions

Step 1 — Confirm Authorization

"Do you have authorization to perform CORS testing on this target?
 I need confirmation before proceeding."

Step 2 — Run the scanner

python3 ${CLAUDE_PLUGIN_ROOT}/skills/auditing-cors-policy/scripts/audit_cors.py \
    https://api.example.com/endpoint \
    --authorized

Options:

Usage: audit_cors.py URL [OPTIONS]

Options:
  --authorized     …

Auditing npm Dependencies

Overview

Modern Node.js applications pull in hundreds of transitive packages through a single npm install. The ratio of direct-to-transitive dependencies on a typical app is around 1:50 — install 30 packages, end up with 1,500. Every one of those packages can ship a CVE, get maintainer-takeover-attacked, or contain a typosquatted near-name package that someone slipped into your lockfile.

The published-CVE feed for npm is among the busiest in the ecosystem because the registry is shared, public, and trivially installable. npm audit queries the same advisory database GitHub's Dependabot uses, returning per-package vulnerability records with CVE ID, severity, affected version range, and fix-available version. Running it is free and fast; the friction is interpreting the output and deciding which findings actually block your release.

This skill standardizes that interpretation. It wraps npm audit --json, parses both the v1 (npm 6) and v2 (npm 7+) output shapes, maps npm's severity vocabulary to the shared Severity enum, and emits Findings in the canonical penetration-tester JSON shape so downstream tooling (CI gates, security dashboards, SOC2 evidence collection) gets uniform records regardless of which package manager surfaced them.

When the skill produces findings

Auditing Python Dependencies

Overview

PyPI hosts north of 500,000 packages, with several thousand new releases every day. The package-install model is identical to npm in the relevant ways: a pip install resolves a transitive graph, runs each package's setup.py (which executes arbitrary Python at install time), and writes the result to your site-packages. The CVE attack surface is therefore the same shape: known vulnerabilities, maintainer-account takeovers, typosquats, and protestware.

The PyPA-blessed auditor is pip-audit. It queries the Open Source Vulnerabilities (OSV) database (which mirrors PyPA's advisory feed plus aggregated CVE / GHSA records) and reports per-package vulnerable versions. pip-audit integrates with requirements.txt, pyproject.toml, Pipfile.lock, and poetry.lock, so most Python project layouts are first-class.

This skill wraps pip-audit, normalizes its severity vocabulary to the shared Severity enum, and emits Findings in the canonical penetration-tester schema. If pip-audit isn't installed on the host, the skill falls back to pip list --outdated and emits INFO-level findings recommending the operator install pip-audit for accurate vulnerability detection.

When the skill produces findings

OSV is the upstream of record. pip-audit also consults the PyPA advisory database for Python-specific records that may not yet have a CVE assigned.

Pr…

Checking HTTP Security Headers

Overview

HTTP response headers are the cheapest defense-in-depth layer most web apps ship. Each header closes one specific attack class — HSTS forces HTTPS, CSP blocks script injection, X-Frame-Options blocks clickjacking, etc. Missing headers don't break the app; they just leave the attack class open. This skill probes for the presence + value correctness of the canonical security-relevant headers.

When the skill produces findings

Prerequisites

• Python 3.9+
• Authorization for non-local targets

Instructions

Step 1 — Confirm authorization

"Do you have authorization to perform header testing on this target?
 I need confirmation before proceeding."

Step 2 — Run the scanner

python3 ${CLAUDE_PLUGIN_ROOT}/skills/checking-http-security-headers/scripts/check_headers.py \
    ht…

Checking License Compliance

Overview

License compliance is a security concern only in the indirect sense that an unintended license obligation can force you to release proprietary source code, retroactively invalidate a customer contract, or render an M&A transaction infeasible. The cost is legal and contractual rather than exploitative — but the consequence ladder is real.

The most-stepped-on landmine is copyleft contamination: unintentionally including a GPL or AGPL-licensed package in a codebase the rest of which is permissively licensed (MIT, Apache-2.0, BSD). The terms of the GPL family say that any project distributing GPL code MUST itself release source under a GPL-compatible license. If your package.json says MIT and one of your transitive deps is GPL-2.0, you may be obligated to either re-license your code or remove the dep.

This skill audits the resolved dependency tree against an explicit policy file and emits findings for:

• Direct deps with deny-listed licenses
• Transitive deps with deny-listed licenses
• Packages with UNKNOWN license metadata (no SPDX identifier)
• License conflicts between metadata and source headers
• Combinations of licenses that are mutually incompatible (e.g. GPL-2.0 + Apache-2.0 without a patent grant)

When the skill produces findings

Composing Vulnerability Report

Overview

After cluster 1-4 scan skills run, each one produces a Findings file. A typical engagement ends up with eight to twenty such files across the different skill categories. The customer wants ONE vulnerability report — comprehensive, deduplicated, organized by severity, with each finding cross-referenced to its source skill and target.

This skill consumes one or more findings files (JSONL preferred, JSON list also accepted), deduplicates entries by the canonical fingerprint defined in lib/finding.py, enriches each finding with a CVSS v3.1 vector when one isn't present (using a deterministic heuristic based on severity + category — explicitly noted as "derived, not assigned by NVD" in the output), and emits a single markdown report with per-finding sections plus a top-level summary table.

The report has a defined structure that downstream tools (next two skills in cluster 6) consume:

1. Header — engagement ID, generation timestamp, source files
2. Summary table — finding count by severity
3. Per-severity sections — CRITICAL first, then HIGH, MEDIUM, LOW, INFO
4. Per-finding subsections — title, severity, target, detail, remediation, evidence, references

When the skill produces findings

Prerequisites

• Python 3.9+
• One or more findings files in JSON or JSONL format produced by any cluster 1-4 scan skill (which all share lib/finding.py schema)

Instructions

Step 1 — Gather findings sources

By default the skill reads every file matching engagement/findings/*.json and engagement/findings/*.jsonl. Override with --source FILE (repeatable).

Step 2 — Run the composer

python3 ./scripts/compose_report.py engagements/acme-2026-q2/

Options:

Confirming Pentest Authorization

Overview

Penetration testing is computer access. Without explicit authorization from the owner of the system under test, that access is a crime — Computer Fraud and Abuse Act in the US, Computer Misuse Act in the UK, equivalent laws everywhere else. The line between an authorized pentester and an unauthorized attacker is one signature on one document.

The penetration-tester pack's other skills (TLS analysis, CORS audit, dependency CVE scan, etc.) all assume that line has been crossed correctly. This skill is the first gate the orchestrator routes to. It refuses to declare an engagement authorized until a Rules of Engagement (ROE) attestation file exists, is signed, and contains the fields any real-world legal review will look for.

This is not paranoia or paperwork theater. Engagements DO go sideways: scope creeps mid-test, a tester probes an out-of-scope adjacent system, an SOC team escalates a "real" attack to legal, and the question "show us the ROE" comes up. If the ROE is in order, the answer is "here it is." If not, the conversation gets expensive fast.

When the skill produces findings

Prerequisites

Defining Pentest Scope

Overview

A pentest scope is a list of permission boundaries. Get it wrong and you either (a) miss real exposure by failing to test something the customer expected covered, or (b) probe something you weren't allowed to touch and turn the engagement into a liability event. Both failure modes share a root cause: the scope list was a vague narrative ("test the marketing site and the API") rather than a machine-readable, syntactically-validated, conflict-checked artifact.

This skill takes the in-scope and out-of-scope sections from a ROE and produces three deliverables:

1. Normalized target list — every entry parsed into a structured form (host vs CIDR vs URL path vs cloud account vs SaaS tenant), with explicit type tagging. Downstream cluster 1-4 skills consume this list rather than raw strings.
2. IP allowlist — flat list of IPv4 and IPv6 addresses / CIDRs ready to paste into scanner configurations (nmap target list, Burp scope file, AWS WAF allowlist, etc.).
3. Conflict report — Findings flagging syntactically-malformed entries, overlap between in-scope and out-of-scope, inclusion of reserved ranges (RFC1918, link-local, multicast), and known third-party SaaS infrastructure that needs separate authz.

The skill does NOT perform DNS resolution or network probing — that would itself be a "first probe" of the target, which by the governance model must happen AFTER scope is locked.

When the skill produces findings

Prerequisites

• Python 3.9+
• ROE file at …

Detecting Command Injection Patterns

Overview

Command injection (CWE-78, OWASP A03:2021) shows up wherever an application shells out to a binary. Image conversion (convert), archive extraction (tar, unzip), video processing (ffmpeg), DNS lookup (dig), and "we just need to call this CLI tool once" are the common origins.

The vulnerability shape is universal: a string is built including user input, then handed to a shell interpreter. The shell parses the string with normal shell semantics — including ;, |, &, $(), backticks. Any of those in the user-controlled portion becomes shell-executable.

When the skill produces findings

Prerequisites

• Python 3.9+
• Target source tree on local filesystem

Instructions

Step 1 — Run the scanner

python3 ${CLAUDE_PLUGIN_ROOT}/skills/detecting-command-injection-patterns/scripts/scan_cmdi.py /path/to/repo

Options:

Detecting Debug Endpoints

Overview

Modern web stacks ship rich introspection by default. Spring Boot Actuator exposes /actuator/env (every environment variable), /actuator/heapdump (a live heap snapshot that contains credentials), /actuator/jolokia (JMX bean invocation = pre-auth RCE in some configurations). Apache mod_status exposes /server-status with internal IPs, request counts, and the URL of every active request. Prometheus /metrics exposes operational telemetry that often includes connection-string-bearing labels by accident. phpMyAdmin exposes the entire database if unauthenticated.

These are not bugs in the frameworks. They're features that ship enabled-by-default for development convenience and stay enabled in production because nobody disabled them at install time. The probe set covers the canonical 40+ paths and grades each by the response fingerprint specific to that framework.

When the skill produces findings

Detecting Directory Listing

Overview

Web servers can be configured to auto-generate an HTML index page when a request hits a directory without a matching default file (no index.html / index.php / etc.). The auto-generated page lists every file in the directory. This is by design for static- file servers and FTP-style file-sharing setups; it's a misconfiguration on application servers where the file tree was never meant to be public.

The risk compounds in two ways:

1. File enumeration without prior knowledge. Attackers find files you didn't link to (backup files, log files, old uploads).
2. Chaining with exposed-files (#6). A /.git/ request that returns an autoindex listing reveals every object file under .git/objects/ and confirms the entire repo is reachable for GitDumper-style reconstruction.

This skill probes commonly-vulnerable directory paths and grades each based on the framework-specific autoindex fingerprint.

When the skill produces findings

Prerequisites

• Python 3.9+ with requests
• Authorization for non-local targets

Instructions

Step 1 — Confirm Authorization

"Do you have authorization to perform directory-listing discovery on
 this target? I need confirmation before proceeding."

Step 2 — Run the scanner

python3 ${CLAUDE_PLUGIN_ROOT}/skills/detecting-directory-listing/scripts/probe_directory_listing.py \
    https://target.example.com \
    --a…

Detecting eval / exec Usage

Overview

Dynamic-code-execution APIs (CWE-95 Eval Injection) let an application interpret a string as code at runtime. If the string contains anything user-controllable, the application has handed the attacker arbitrary code execution.

The defensive posture: don't use these APIs. The exceptions are narrow: rule engines, formula evaluators (spreadsheet = formulas), plugin systems with explicit sandboxing. For everything else, there's almost always a safer alternative.

When the skill produces findings

Prerequisites

• Python 3.9+
• Source tree on local filesystem

Instructions

Run

python3 ${CLAUDE_PLUGIN_ROOT}/skills/detecting-eval-exec-usage/scripts/scan_eval.py /path/to/repo

Options: --output FILE, --format json|jsonl|markdown, --min-severity, --inc…

Detecting Exposed Secrets Files

Overview

The single highest-value pentest probe per HTTP request. A .git/config disclosure leaks repo URL + credentials embedded in remote URLs. A .env disclosure leaks every API key the app has. A backup.sql disclosure leaks the entire database. These are not "weak crypto" findings that need a chained exploit. They are direct, immediate compromise.

The probe set is the canonical 40+ paths web servers commonly expose by accident: VCS directories (.git/, .svn/, .hg/), dotenv files, OS metadata (.DS_Store), database dumps, archive files, IDE configs, CI configs, and key files. Each is fingerprinted to distinguish a true positive (server returns the file's expected content) from a 200 OK that's actually the application's SPA index page catching the route.

When the skill produces findings

Prerequisites

…

Detecting Insecure Deserialization

Overview

Insecure deserialization (CWE-502, OWASP A08:2021) is the highest- severity injection class in many language stacks because it directly maps to RCE. Pickle, Java serialization, PHP unserialize, and BinaryFormatter all execute object-construction code during deserialization. If that code includes __reduce__ / readObject / __wakeup / OnDeserialization callbacks that the attacker controls, the deserialization step IS code execution.

Most legitimate use cases have safer alternatives (JSON for data, YAML with safe-load, Protocol Buffers, Avro). The remaining cases need explicit type allow-lists and HMAC-signed payloads.

When the skill produces findings

Detecting SQL Injection Patterns

Overview

SQL injection (CWE-89, OWASP A03:2021) remains one of the highest- impact and most-easily-introduced vulnerability classes. The fix is near-universal: use parameterized queries. The cause when introduced: an engineer concatenates user input into a SQL string because the ORM's parameterization mechanism wasn't obvious, or because they "just need to add a quick condition."

The scanner reads source files and grades each apparent SQL-string construction against the threshold table.

When the skill produces findings

Prerequisites

• Python 3.9+
• Target source tree on local filesystem

Instructions

Step 1 — Run…

Detecting SSL Certificate Issues

Overview

This skill is the second-level cert audit, run after analyzing-tls-config clears the protocol+cipher+expiry+hostname basics. It surfaces issues that don't break the handshake today but make the cert fragile or open to soft-bypass attacks: missing OCSP stapling forces clients to phone home to the CA (privacy + latency hit), missing Certificate Transparency SCTs are rejected by Chrome since 2018, an out-of-order chain confuses older clients, and over-broad wildcards expand the blast radius of any future key compromise.

When the skill produces findings

Prerequisites

• Python 3.9+ with cryptography library
• openssl CLI 1.1.1+ (for OCSP query + chain enumeration)
• Authorization for non-local targets (see references/AUTHORIZATION.md in skill #1 analyzing-tls-config for the canonical pattern)

Instructions

Step 1 — Confirm Authorization

Active scan; ask the user verbatim:

> "Do you have authorization to perform TLS testing on this target? > I need confirmation before proceeding."

Step 2 — Run the scanner

python3 ${CLAUDE_PLUGIN_ROOT}/skills/detecting-ssl-cert-issues/scripts/check_cert_chain.py \
    https://target.example.com \
    --authorized

Options:

Usage: …

Detecting Weak Cryptography

Overview

Weak cryptography (CWE-327 Use of a Broken or Risky Cryptographic Algorithm, CWE-330 Use of Insufficiently Random Values) shows up when engineers use the convenient API instead of the cryptographic one. hashlib.md5(password) is faster to type than the correct bcrypt/argon2 invocation; Math.random() returns a number quickly without needing to know about crypto.randomBytes().

The fix is universal: use the modern primitive. SHA-256 for general hashing, bcrypt/argon2/scrypt for passwords, AES-GCM for encryption, HMAC-SHA256 for signing, secrets / crypto.randomBytes / SecureRandom for randomness.

When the skill produces findings

Prerequisites

• Python 3.9+
• Source tree on local filesystem

Instructions

Run

python3 ${CLAUDE_PLUGIN_ROOT}/skills/detecting-weak-cryptography/scripts/scan_weak_crypto.py /path/to/repo

Options: --output, --format, --min-severity, --include-tests, --langu…

Fingerprinting Server Software

Overview

Version disclosure is the cheapest recon an attacker buys. A single GET request returns the Server: header, the X-Powered-By: header, and any framework-default cookies. From those three signals the attacker derives: web server family + exact version, app-framework + version, language runtime + version. That maps directly to a CVE catalog query: every published CVE affecting any of those components, filtered to ones an unauthenticated attacker can trigger.

The fix is operationally trivial (one line in nginx, one line in Apache, one line in IIS) but the discipline isn't universal. This skill enumerates the signals + reports each disclosure with the severity matching how much it enables follow-on attack.

When the skill produces findings

Prerequisites

• Python 3.9+ with requests
• Authorization for non-local targets

Instructions

Step 1 — Confirm Authoriz…

Generating Executive Summary

Overview

The vulnerability report is comprehensive — every finding, full detail, every reference. The C-level reader doesn't open it. They ask their security lead "what should I tell the board?" The security lead needs a one-page answer.

That one-page answer is the executive summary. It states the engagement's bottom line:

• A single risk score (0-100)
• Headline counts by severity
• Top-3 remediation priorities, each with rough effort + impact
• OWASP Top 10 coverage (where the work landed)
• Engagement scope and authorization summary (what was tested, under what authority, in what window)
• Next steps the customer's organization should take

The summary doesn't omit anything important; it just compresses. The vulnerability report remains the deep artifact for anyone who needs the technical detail.

This skill consumes the enriched findings JSONL (after OWASP mapping) + the OWASP coverage report + the ROE, computes the risk score, picks the top remediation priorities deterministically, and renders the document.

When the skill produces findings

Risk score (0-100) composition

The single risk score is the headline number on the exec summary. The composition is deterministic and documented:

risk = clamp(0, 100,
    20 * count(CRITICAL)
  + 10 * count(HIGH)
  +  3 * count(MEDIUM)
  +  1 * count(LOW)
  +  0 * count(INFO)
  +  5 * (count(distinct OWASP categories touched) - 5 if >5 else 0)
  - 10 * 1 if engagement was authorized cleanly and in-scope (governance bonus)
)

The first five terms weight by severity. The OWASP-coverage term adds 5 points per category beyond 5 (a broader-finding engagement implies broader risk surface). The governance bonus is a -10 adjustment when ROE was clean — explicit recognition that f…

Mapping Findings to OWASP Top 10

Overview

OWASP Top 10 is the canonical taxonomy of web-application risk categories. Every customer-facing pentest report has an "OWASP coverage" section because customers, auditors, and insurers expect to see findings mapped against the Top 10. Without the mapping, a long list of CVEs and misconfigurations reads as noise; with the mapping, it reads as a structured assessment.

This skill applies a deterministic rule table to annotate each finding with its OWASP category. Rules are keyed on:

1. Source skill ID (a finding from auditing-npm-dependencies is almost always A06 — Vulnerable and Outdated Components).
2. Finding category (the per-skill category tag, e.g. dependency-vulnerability, engagement-scope).
3. CWE identifier if present (CWE → OWASP is a well-trodden mapping; OWASP themselves publish the cross-walk).
4. Detail keywords as a fallback when the above don't determine a category.

Output is an enriched JSONL (each finding gets an owasp_category field) plus a coverage report showing how the engagement's findings distribute across A01-A10. UNMAPPED findings are surfaced for human review — extend the rule table or accept the finding as cross-cutting (some findings genuinely don't fit a single A0X bucket).

When the skill produces findings

OWASP Top 10 (2021) reference

Performing Penetration Testing

Overview

v3.0.0 of penetration-tester is a 25-skill pack. Each skill is narrow and heavy-hitter compliant (≥250 LOC scripts, ≥2 reference docs, 8-field SKILL.md frontmatter). This orchestrator routes user intent to the right combination of narrow skills.

The 25 skills group into 7 clusters:

• Cluster 0 — this orchestrator
• Cluster 1 (5 skills) — Network / transport
• Cluster 2 (4 skills) — Information disclosure
• Cluster 3 (6 skills) — Source-code static analysis
• Cluster 4 (4 skills) — Dependency analysis
• Cluster 5 (3 skills) — Engagement governance
• Cluster 6 (3 skills) — Reporting

Cluster 5 + 6 are the v3 additions versus v2. Cluster 5 runs BEFORE any scan and refuses to proceed if authorization is missing or scope is malformed. Cluster 6 runs AFTER scans and produces the deliverable artifacts (vulnerability report, OWASP coverage report, executive summary, chain-of-custody archive).

Instructions

The orchestrator's job is intent routing — given a user utterance, decide which of the 25 narrow skills to invoke and in what order. Four steps:

Step 1 — Parse the user intent

Match the utterance against the intent-routing table below. The leftmost matching row determines the routing. If no exact match, default to the cluster-1-4 governance-first sequence and pare back based on context.

Step 2 — Run authorization-first

Before any cluster 1-4 scan invocation, run confirming-pentest-authorization. If it emits any CRITICAL finding, HALT — do not invoke any scan skill. The user must resolve the authorization issue before proceeding.

Step 3 — Run the matched skills in order

Invoke each skill from the routing-table row, in the listed order. Each skill emits its findings as JSON/JSONL/markdown via lib/report.py. Persist per-skill output into engagement/findings/<skill>-<date>.jsonl so the cluster 6 skills can consume them.

Step 4 — Compose deliverables

After scan skills complete, run cluster 6 in sequence: mapping-findings-to-owasp-top10, then composing-vulnerability-report, then generating-executive-summary, then recording-pentest-engagement for the chain-of-custody archive.

Intent routing (the table)

Probing Dangerous HTTP Methods

Overview

Most HTTP methods beyond GET/POST/HEAD are vestigial — leftover from WebDAV authoring stacks of the early 2000s, debugging features in legacy servers, or default-enabled methods nobody disabled at install time. Each enabled method that the application doesn't use is an attack surface: TRACE enables Cross-Site Tracing (XST), PUT enables arbitrary file upload to unprotected paths, CONNECT enables proxy abuse against internal services, WebDAV enables directory manipulation.

This skill probes the canonical method set and grades each based on its presence and response.

When the skill produces findings

Prerequisites

• Python 3.9+
• Authorization for non-local targets

Instructions

Step 1 — Confirm authorization

"Do you have authorization to perform HTTP method probing on this
 target? I need confirmation before proceeding."

Step 2 — Run the scanner

python3 ${CLAUDE_PLUGIN_ROOT}/skills/probing-dangerous-http-methods/scripts/probe_methods.py \
    https://example.com \
    --authorized

Options:

Usage: probe_methods.py URL [OPTIONS]

Options:
  --authorized      Attest authorization (required)
  --output FILE
  --format FMT      json | jsonl | markdown (default: markdown)
  --min-severity SEV (default: info)
  --timeout SECS
  --is-api          Treat URL as API endpoint (relaxes PUT/DELETE checks)

By default the scanner treats the URL as a non-API endpoint where PUT/…

Recording Pentest Engagement

Overview

A penetration test produces a lot of artifacts: scan outputs in multiple formats, screenshots showing the state of vulnerable pages, raw tool logs (nmap, Burp, custom scripts), the ROE and any amendments, exec-summary docs, and the findings themselves. Six months after the engagement closes, a question arises — sometimes benign ("can you remind me what we found?"), sometimes adversarial ("the customer claims we accessed an out-of-scope system; show us the logs"). The answer needs to be: "yes, here's the archive, and here's cryptographic proof it hasn't been touched since the engagement closed."

This skill packages the engagement directory into a single timestamped archive with a SHA-256 manifest covering every file. Optionally signs the manifest with GPG. The result is a portable, self-verifying record of what the engagement produced.

The skill also surfaces inconsistencies that would weaken the chain-of-custody claim: out-of-tree paths referenced in findings (meaning the finding refers to a file not actually in the archive), files in the directory not listed in the manifest, manifest entries whose hashes don't match. These are HIGH findings — they mean the archive is incomplete or has been modified after the fact, neither of which is acceptable for evidence purposes.

When the skill produces findings

Prerequisites

• Python 3.9+
• An engagement directory laid out as recommended (see structure below)
…

Scanning for Hardcoded Secrets

Overview

The single most common cause of credential breach in 2026 remains hardcoded secrets in source code. Engineers paste an API key into a config file "just for testing," forget to remove it, commit the file. The credential is now in the repository's history forever (git rebase doesn't help if anyone cloned in between) and extractable by anyone who reaches the repo: contractors, ex-employees, attackers via .git/ directory exposure (see skill six), GitHub bot scrapers crawling public repos.

The cost of detection-after-commit is near-zero (free tools exist: gitleaks, trufflehog, this skill). The cost of detection-before-commit is also near-zero (pre-commit hooks). The cost of remediation after the fact is rotating every credential exposed + auditing for exploitation + potentially notifying customers of breach. The asymmetry is severe, the discipline is the only constraint.

This skill scans a filesystem tree, matching against a canonical regex library covering the credential shapes attackers and bots search for first.

When the skill produces findings

Tracing Transitive Vulnerabilities

Overview

The auditing-npm-dependencies and auditing-python-dependencies skills each surface CVEs, but they don't answer the question that actually decides remediation order: which of these findings can I clear by bumping ONE direct dep, and which require deeper intervention?

That question is the core of supply-chain triage. A high-CVSS CVE in lodash@4.17.4 is alarming on first read. If it's pulled in by five different direct deps, the right fix may not be to bump any of them — it may be a single root-level overrides entry pinning lodash@^4.17.21. The triage discussion goes very differently when you can quote: "this CVE is reachable via 5 paths, all of which flow through webpack, which has a fixed version available." That shifts a project-wide panic to a one-line PR.

This skill walks the project's dependency graph (via npm ls, pipdeptree, or equivalent), intersects it with the CVE findings already produced by the per-language audit skills, and emits a trace report that includes:

• For each CVE: the full path(s) from direct dep → ... → vulnerable package
• For each direct dep: the count of CVEs reachable through it
• "Highest-leverage upgrade" recommendation — the single direct-dep bump that clears the most findings at once
• "Unreachable" findings — CVEs whose vulnerable version range is forced by EVERY parent in the path, requiring overrides or vendor-patch
• "Deep transitive" findings (≥3 levels from a direct dep) — these are highest-risk for hidden surprises because the relationship to your code is most opaque

When the skill produces findings

Prerequisites

…