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

Check a local Rules of Engagement (ROE) file before handing targets to a scanner. Validate required metadata types, offset-aware timestamps, the current window, an optional signer allowlist, and literal target inclusions and exclusions. A malformed input or blocking finding returns nonzero even when a display filter hides that finding.

This is a structural check, not signature verification, ownership proof or legal authorization. Retain separately confirmed approval and signature verification evidence with the ROE. Active scanners still need to enforce resolved targets and redirects; this checker performs no network requests.

When the skill produces findings

Prerequisites

• Python 3.9+; PyYAML for YAML inputs, or use JSON without PyYAML
• ROE attestation file at ./roe.yaml (or pass --roe FILE).
• Optional .allowed-authorizers file listing email addresses or GPG key fingerprints permitted to sign ROEs.

ROE attestation file schema

Required blocks must be mappings and target sections mus…

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+; PyYAML for YAML inputs, or use JSON without PyYAM…

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

Route an approved engagement across 25 narrow operator skills plus this orchestrator. Each invoked CLI has its own arguments, evidence requirements and exit status.

Prerequisites

Use Read for approved ROE and saved findings, Glob/Grep to select artifacts, and Write only for requested engagement outputs. These routing instructions depend on each CLI's own input and evidence checks; reports do not certify compliance.

Obtain the owner's authorization and approved targets before scanning. The structural authorization checker validates metadata, scope and time windows; a successful check does not verify signing identity or establish legal authority. Keep the approved ROE, target handoffs and requested local repository/environment paths with the engagement evidence. Do not install missing scanners automatically.

Instructions

Step 1 — Select the operator job

Match the requested job in the routing table. Select only the relevant operators; no full scan, write/proxy experiment, signing or service activation follows merely from a broad request to inspect a project. The HTTP-method operator defaults to OPTIONS; each active method has its separate ROE, opt-in and ledger contract.

Step 2 — Complete authorization and scope gates

Run confirming-pentest-authorization and defining-pentest-scope before any cluster 1–4 operator, including ad-hoc work. Require both CLI exit codes to be 0. A HIGH or CRITICAL governance finding, invalid ROE, unsupported target or any other nonzero gate stops the dependent scan; severity filtering cannot grant permission. Verify each network target with the authorization checker's --check-target and use only successfully emitted scope handoffs.

The scope CLI covers supported network identities. Approval of exact local repository and Python-environment paths must be established separately; do not claim it validates arbitrary filesystem paths or that changing cwd selects a Python environment.

Step 3 — Execute selected checks and retain their status

For narrow v3 operators, persist canonical Finding JSON/JSONL with the skill's actual --output/--format arguments. Preserve the unfiltered gate alongside its report. Exit 1 from a completed scan records security findings; it does not invalidate the preceding authorization. Exit 2 or missing completion evidence marks dependent conclusions incomplete. Other approved independent checks may continue only without hiding that incomplete coverage.

The legacy routes retain separate v2 report shapes, with explicit completion and error metadata. Keep those reports separate from canonical Finding streams. Their CLI does not execute this orchestrator's ROE gate. Invoke them only after the governance steps; use narrow v3 operators when canonical report composition i…

Probing Dangerous HTTP Methods

Overview

Compare anonymous HTTP method capabilities with the owner's explicit policy. The default sends only OPTIONS to the exact supplied URL, follows no redirect, and does not read its response body. Allow is advertisement, not proof of a write, an open proxy or exploitation. An API path name does not establish policy.

Active experiments require separate method selection, a structurally valid ROE, an exclusive private ledger and bounded postcondition evidence. The checker does not verify signing identity or establish legal authorization. Obtain the owner's approval independently before executing an experiment.

Prerequisites

• Use the plugin's Python environment and installed dependencies.
• Supply a literal HTTP(S) URL without credentials, query, fragment or ambiguous paths.
• For active probes, obtain an unexpired ROE using the authorization skill's required authorizer, time-window, signature and scope fields.
• Prepare an existing owner-private directory (0700) for a new ledger (0600). Never reuse or overwrite a prior ledger.

Instructions

Step 1 — Discover without mutation

python3 ${CLAUDE_PLUGIN_ROOT}/skills/probing-dangerous-http-methods/scripts/probe_methods.py \
  https://fixture.example.test/app --authorized --format json

The anonymous direct session ignores ambient credentials, cookies and proxies. Missing, malformed, redirected, auth-gated or failed discovery returns exit 2. A valid bounded advertisement is INFO; it does not certify application security.

Step 2 — Review explicit active permission

Use Read to inspect the approved ROE and route policy before selecting methods.

Add this block to a complete owner-approved ROE; it is not a complete ROE itself:

http_method_probe:
  target: https://fixture.example.test/app
  allowed_methods: [PUT, DELETE, COPY, MOVE]
  unexpected_methods: [PUT, COPY, MOVE]
  disposable_base: https://fixture.example.test/probe-fixtures/
  exclusive_disposable_namespace: true
  cleanup_authorized: true

The exact target and the entire dedicated same-origin disposable directory must be in scope, with no overlapping exclusion. Every selected method needs explicit permission. PUT/DELETE/COPY/MOVE require helper PUT and DELETE permission even when only one is selected. MKCOL requires MKCOL, DELETE, PROPFIND and LOCK; LOCK is an internal cleanup helper, not a selectable general-purpose probe. Never approve an existing user-data directory as the disposable namespace.

TRACE and PROPFIND need no disposable directory. DEBUG additionally requires debug_response_sha256, an owner-approved fixture digest. CONNECT requires an explicit HTTP proxy root, a scoped HTTPS proxy_destination, controlled_proxy_destination: tr…

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 hashes supported, non-excluded regular files and optionally packages the engagement directory with a SHA-256 manifest. An existing manifest is a verification baseline: mismatches preserve its bytes and block signing and packaging. Choose a distinct --manifest path to create a deliberate new snapshot; retain the original for investigation. Freeze evidence writers during hashing and packaging: this is not an atomic filesystem snapshot. Review excluded files and symlink findings separately; the tarball may contain entries the manifest does not cover.

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

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

…