@intentsolutionsio/penetration-tester 2.0.0 → 3.0.4

package/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "penetration-tester",
-  "version": "2.0.0",
-  "description": "Security testing toolkit with HTTP header analysis, dependency auditing, and static code scanning",
+  "version": "3.0.0",
+  "description": "25-skill pentest pack with engagement governance, network/code/dependency scans, OWASP Top 10 mapping, and exec-readable reporting. Heavy-hitter compliant; chain-of-custody attestable.",
   "author": {
     "name": "Jeremy Longshore",
     "email": "[email protected]"
@@ -13,7 +13,12 @@
     "penetration-testing",
     "pentesting",
     "owasp",
-    "exploitation",
+    "owasp-top-10",
+    "vulnerability-scanning",
+    "dependency-audit",
+    "license-compliance",
+    "engagement-governance",
+    "chain-of-custody",
     "agent-skills"
   ]
 }

package/README.md

@@ -38,21 +38,25 @@ Requires Python 3.9+. The setup script installs `requests`, `bandit`, and
 ## Quick Start
 
 **Check security headers on a URL:**
+
 ```
 > Check the security headers on https://example.com
 ```
 
 **Audit project dependencies:**
+
 ```
 > Audit the dependencies in this project for vulnerabilities
 ```
 
 **Scan code for security issues:**
+
 ```
 > Scan this codebase for hardcoded secrets and security issues
 ```
 
 **Full security audit:**
+
 ```
 > Run a full security audit on this project
 ```
@@ -70,6 +74,7 @@ python3 scripts/security_scanner.py https://example.com --output report.json
 ```
 
 **Checks:**
+
 - Security headers (CSP, HSTS, X-Frame-Options, X-Content-Type-Options,
   Referrer-Policy, Permissions-Policy)
 - SSL/TLS certificate validity and expiry
@@ -88,6 +93,7 @@ python3 scripts/dependency_auditor.py . --scanners npm,pip --output findings.jso
 ```
 
 **Supports:**
+
 - npm projects (via `npm audit`)
 - Python projects (via `pip-audit`)
 - Auto-detects project type from manifest files
@@ -103,6 +109,7 @@ python3 scripts/code_security_scanner.py . --exclude "test_*,*_test.py"
 ```
 
 **Detects:**
+
 - Hardcoded secrets (API keys, AWS keys, passwords, tokens)
 - SQL injection (string concatenation in queries)
 - Command injection (os.system, subprocess with shell=True)
@@ -114,6 +121,7 @@ python3 scripts/code_security_scanner.py . --exclude "test_*,*_test.py"
 ## Output
 
 All scanners produce:
+
 - Markdown-formatted reports for terminal display
 - JSON reports via `--output` for programmatic use
 - Risk scoring with severity levels (critical, high, medium, low, info)

package/commands/pentest.md

@@ -32,21 +32,25 @@ Ask the user what they want to test:
 Based on the selected scope, run the appropriate scripts from the plugin:
 
 ### Web Application Scan
+
 ```bash
 python3 ${CLAUDE_PLUGIN_ROOT}/skills/performing-penetration-testing/scripts/security_scanner.py TARGET_URL --verbose
 ```
 
 ### Dependency Audit
+
 ```bash
 python3 ${CLAUDE_PLUGIN_ROOT}/skills/performing-penetration-testing/scripts/dependency_auditor.py TARGET_DIR --verbose
 ```
 
 ### Code Security Scan
+
 ```bash
 python3 ${CLAUDE_PLUGIN_ROOT}/skills/performing-penetration-testing/scripts/code_security_scanner.py TARGET_DIR --verbose
 ```
 
 Save JSON reports for any scan that finds critical or high issues:
+
 ```bash
 python3 SCANNER --output /tmp/security-report-$(date +%Y%m%d).json
 ```
@@ -72,6 +76,7 @@ Offer to apply code fixes directly for code-level findings.
 ## Step 6: Generate Report
 
 If the user wants a saved report, combine all findings into a single JSON file:
+
 ```bash
 # Reports are saved via the --output flag on each scanner
 ```

package/package.json

@@ -1,13 +1,18 @@
 {
   "name": "@intentsolutionsio/penetration-tester",
-  "version": "2.0.0",
-  "description": "Security testing toolkit with HTTP header analysis, dependency auditing, and static code scanning",
+  "version": "3.0.4",
+  "description": "25-skill pentest pack with engagement governance, network/code/dependency scans, OWASP Top 10 mapping, and exec-readable reporting. Heavy-hitter compliant; chain-of-custody attestable.",
   "keywords": [
     "security",
     "penetration-testing",
     "pentesting",
     "owasp",
-    "exploitation",
+    "owasp-top-10",
+    "vulnerability-scanning",
+    "dependency-audit",
+    "license-compliance",
+    "engagement-governance",
+    "chain-of-custody",
     "agent-skills",
     "claude-code",
     "claude-plugin",

package/skills/analyzing-tls-config/SKILL.md

@@ -0,0 +1,221 @@
+---
+name: analyzing-tls-config
+description: |
+  Analyze a target's TLS configuration — negotiated protocol version, cipher
+  suite, certificate chain, expiry, and downgrade vectors.
+  Use when: SOC2 auditor flagged your endpoint for "weak TLS" but you don't
+  know which control failed (TSC CC6.7 transmission integrity vs CC6.6
+  encryption) or which cipher is the problem.
+  Threshold: any negotiated TLSv1.0 or TLSv1.1, OR a cipher with RC4 / 3DES /
+  null / EXPORT, OR a cert with under 30 days to expiry, OR a chain that fails
+  hostname verification.
+  Trigger with: "audit tls", "check ssl config", "weak tls", "analyze tls".
+allowed-tools:
+  - Read
+  - Bash(python3:*)
+  - Bash(openssl:*)
+disallowed-tools:
+  - Bash(rm:*)
+  - Edit(/etc/*)
+  - Write(/etc/*)
+version: 3.0.0-dev
+author: Jeremy Longshore <jeremy@intentsolutions.io>
+license: MIT
+compatibility: Designed for Claude Code
+tags:
+  - security
+  - tls
+  - ssl
+  - pentest
+  - transport-layer
+---
+
+# 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:
+
+| Finding | Severity | Threshold | Affected control |
+|---|---|---|---|
+| TLSv1.0 or TLSv1.1 negotiated | **HIGH** | Any handshake completes at v1.0/v1.1 | NIST 800-52r2 §3.1, PCI DSS Req 4.2.1.1 |
+| Null / EXPORT / anonymous cipher | **CRITICAL** | Any null / EXPORT / aNULL in negotiated suite | NIST 800-52r2 §3.3.1 |
+| RC4 / 3DES cipher | **HIGH** | Sweet32, RC4 biases | NIST 800-52r2 §3.3.1, PCI DSS Req 4.2.1.1 |
+| Cert expires in <7 days | **CRITICAL** | notAfter - now ≤ 7d | NIST 800-52r2 §4.1 |
+| Cert expires in <30 days | **HIGH** | notAfter - now ≤ 30d | NIST 800-52r2 §4.1 |
+| Cert hostname mismatch | **HIGH** | SAN/CN doesn't match target host | RFC 6125 |
+| Self-signed or untrusted CA | **MEDIUM** | Chain doesn't validate to system CA | Mozilla TLS Guidelines |
+| Weak key (RSA < 2048, ECDSA < 256) | **HIGH** | Public key bits below threshold | NIST 800-52r2 §3.4 |
+| Forward secrecy absent | **MEDIUM** | No ECDHE / DHE in negotiated suite | NIST 800-52r2 §3.3.1 |
+
+## 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
+
+```bash
+python3 ${CLAUDE_PLUGIN_ROOT}/skills/analyzing-tls-config/scripts/analyze_tls.py \
+    https://target.example.com \
+    --authorized
+```
+
+The `--authorized` flag is required for any non-loopback / non-RFC1918
+target (gate enforced in `lib/authz_check.py`).
+
+Options:
+
+```
+Usage: analyze_tls.py URL [OPTIONS]
+
+Options:
+  --authorized          Attest authorization for non-local targets (required)
+  --port PORT           Target port (default: 443)
+  --output FILE         Write findings to FILE (default: stdout)
+  --format FMT          json | jsonl | markdown (default: markdown)
+  --min-severity SEV    Floor: critical|high|medium|low|info (default: info)
+  --timeout SECS        Per-probe timeout (default: 10)
+```
+
+### Step 3 — Interpret findings
+
+The scanner emits one `Finding` per detected issue. For each:
+
+1. Read the **severity** band — CRITICAL and HIGH require immediate action.
+2. Read the **affected control** — map to the framework the user is audited against.
+3. Read the **remediation** — copy-paste-ready config snippets for nginx /
+   Caddy / Apache / HAProxy / AWS ALB / GCP LB.
+4. Cross-reference `references/PLAYBOOK.md` for the full template if the
+   inline remediation is just a one-liner.
+
+### Step 4 — Report to user
+
+Group findings by severity. For each, lead with the specific symptom
+("TLSv1.0 negotiated") rather than the category ("transport security
+problem"). Pair every finding with one remediation step the user can
+take in the next 30 minutes.
+
+### Step 5 — Cross-skill chaining (optional)
+
+If the user is doing a broader audit:
+
+- After this skill runs, suggest **`detecting-ssl-cert-issues`** (skill #2)
+  for deeper cert-chain analysis (revocation, CT log presence,
+  intermediate-cert order).
+- For HTTP-layer security headers that complement TLS findings, suggest
+  **`checking-http-security-headers`** (skill #4) to audit HSTS preload
+  status, which is meaningless without proper TLS.
+
+## Examples
+
+### Example 1 — SOC2 audit prep on a production endpoint
+
+User says: "Auditor flagged our checkout endpoint for weak TLS. Help me figure out what's wrong."
+
+```bash
+python3 ${CLAUDE_PLUGIN_ROOT}/skills/analyzing-tls-config/scripts/analyze_tls.py \
+    https://checkout.example.com \
+    --authorized \
+    --min-severity high
+```
+
+Expected output: a Markdown report with each HIGH/CRITICAL finding, the
+specific NIST/PCI control it violates, and a copy-paste remediation
+snippet for the target server type. Pair with `references/PLAYBOOK.md`
+for full templates.
+
+### Example 2 — CI integration on a staging gate
+
+Pin the scan into the deploy pipeline before promotion:
+
+```yaml
+- name: TLS posture check (staging)
+  run: |
+    python3 plugins/security/penetration-tester/skills/analyzing-tls-config/scripts/analyze_tls.py \
+        https://staging.example.com \
+        --authorized \
+        --min-severity high \
+        --format json \
+        --output tls-report.json
+```
+
+Exit code 1 fails the deploy if any HIGH/CRITICAL finding lands. The
+JSON report uploads as a build artifact for the security team to
+triage.
+
+### Example 3 — Quick local check during dev
+
+For local services (carve-out applies — no `--authorized` needed):
+
+```bash
+python3 ${CLAUDE_PLUGIN_ROOT}/skills/analyzing-tls-config/scripts/analyze_tls.py \
+    https://localhost:8443
+```
+
+Useful when prototyping TLS-terminating proxies (Caddy, Traefik) before
+shipping to staging.
+
+## Output
+
+Each finding includes:
+
+- `skill_id`: `analyzing-tls-config`
+- `title`: imperative — e.g. "Server negotiates obsolete TLSv1.0"
+- `severity`: critical / high / medium / low / info
+- `target`: the URL scanned
+- `detail`: technical explanation of WHY this finding triggered
+- `remediation`: specific fix
+- `cvss_score` / `cwe_id`: when applicable
+- `affected_control`: framework + control ID (e.g. `NIST 800-52r2 §3.1`)
+- `references`: source URLs
+
+JSON output is pipeable to `jq` for CI integration. Markdown output is
+human-readable for direct sharing with the engineering team.
+
+Exit codes: `0` clean (no high/critical), `1` findings (high or critical),
+`2` error (auth missing, target unreachable, unparseable input).
+
+## Error Handling
+
+**`--authorized` missing for non-local target** → exit 2 with attestation
+message pointing to `references/AUTHORIZATION.md`. Re-run with the flag
+after confirming authorization.
+
+**Target unreachable** → exit 2 with the underlying socket error. Common
+causes: firewall blocks port 443, DNS resolution failure, server not
+listening on the configured port (try `--port`).
+
+**Certificate chain incomplete** → finding emitted at MEDIUM severity (the
+scanner does not bail; it captures what was sent and reports the gap).
+
+## Resources
+
+- `references/THEORY.md` — How TLS negotiation works, why each finding
+  matters, primary RFC references
+- `references/PLAYBOOK.md` — Copy-paste remediation templates per finding
+  for nginx, Caddy, Apache, HAProxy, AWS ALB, GCP LB
+- `references/AUTHORIZATION.md` — Authorization attestation pattern + ROE
+  example for active scans

package/skills/analyzing-tls-config/references/AUTHORIZATION.md

@@ -0,0 +1,133 @@
+# Authorization Attestation Pattern
+
+Active security scanning against a target you don't own is a federal
+crime in the United States (Computer Fraud and Abuse Act, 18 U.S.C. §
+1030) and similar offenses in most jurisdictions globally. Every
+penetration-tester v3 active-scan skill enforces a two-step attestation
+gate so no scan fires by accident.
+
+## The two-step gate
+
+### Step 1 — Verbal attestation in Claude's conversation
+
+Before invoking the scanner, Claude is instructed (via the skill's
+SKILL.md "Step 1 — Confirm Authorization" section) to ask the user
+verbatim:
+
+> "Do you have authorization to perform security testing on this target?
+> I need confirmation before proceeding."
+
+If the user says no, or is unsure, Claude refuses to proceed and points
+the user at the ROE template below to obtain written authorization
+first.
+
+### Step 2 — `--authorized` flag on the scanner
+
+The Python scanner also requires the `--authorized` flag for any target
+that isn't obviously local (loopback / RFC1918 / link-local). The flag
+must be passed explicitly each invocation — there is no environment-
+variable fallback, because CI environment variables can be set by
+anyone with repo write access and silently authorize scans against
+arbitrary targets.
+
+Carve-outs (no `--authorized` needed):
+
+- `localhost`, `127.0.0.0/8`, `::1`
+- RFC1918 ranges: `10.0.0.0/8`, `172.16.0.0/12`, `192.168.0.0/16`
+- Link-local: `169.254.0.0/16`, `fe80::/10`
+
+Anything else: gate fires; scanner exits with code 2 and instructional
+message.
+
+## Rules of Engagement (ROE) — minimum template
+
+Use this as the starting point for written authorization to test a
+target you don't otherwise own. Adapt to your local legal counsel's
+guidance; this is a working template, not a substitute for legal review.
+
+```
+RULES OF ENGAGEMENT — Security Testing Authorization
+
+Date:                    [YYYY-MM-DD]
+Authorizing party:       [organization name]
+Authorizing signatory:   [name, title, contact email]
+Tester:                  [your name / org]
+Engagement period:       [YYYY-MM-DD] through [YYYY-MM-DD], inclusive.
+
+Targets in scope:
+    [URL or IP range, one per line]
+
+Targets explicitly out of scope:
+    [URL or IP range, one per line]
+
+Permitted test types:
+    [ ] Passive enumeration (no traffic to target)
+    [ ] Active scanning (HTTP probes, TLS handshakes, port scans)
+    [ ] Authentication testing (default credentials, weak password lists)
+    [ ] Application-layer testing (SQL injection, XSS, command injection)
+    [ ] Denial-of-service testing — DEFAULT NO; check only if explicit
+    [ ] Social engineering — DEFAULT NO; check only if explicit
+    [ ] Physical access testing — DEFAULT NO; check only if explicit
+
+Maintenance windows:
+    [Window during which tester may operate without notification]
+
+Notification protocol:
+    Before starting:       [Slack/Email/Phone to whom]
+    On finding any CRITICAL: [Slack/Email/Phone to whom, within how long]
+    On any service outage: [Phone to whom, within how long]
+    Daily status:          [Email to whom, before what time]
+
+Stop conditions:
+    The tester WILL halt all active scanning if:
+    - Target service goes down (regardless of cause)
+    - Authorizing party requests halt
+    - A finding suggests active exploitation by a third party
+    - The engagement period ends
+
+Data handling:
+    All findings, evidence, and reports are confidential and shared only
+    with [list]. Tester will retain copies for [N] days post-engagement,
+    after which all materials are destroyed.
+
+Signatures:
+    Authorizing signatory: _______________  Date: ___________
+    Tester:               _______________  Date: ___________
+```
+
+## What the skill does NOT enforce (you have to)
+
+The `--authorized` flag is an attestation — it does not prove
+authorization, just records that the tester asserts it. The tester
+remains legally responsible for the truth of that assertion.
+
+The skill does not:
+
+- Verify the target is in scope of a real ROE.
+- Verify the tester is who they say.
+- Verify the engagement period is active.
+- Notify the target party.
+
+These are operator responsibilities. The skill provides the
+defense-in-depth gate so a misconfigured CI workflow or a curious
+engineer doesn't accidentally fire active scans at production third-
+party targets.
+
+## When to skip the gate
+
+Never. If you find yourself wanting to bypass the gate, that is the
+signal to stop and obtain authorization first. The gate exists because
+silently disabled attestation has caused real legal exposure for
+penetration testers in the past.
+
+If you are scanning your own loopback / RFC1918 services and the gate
+is misfiring (e.g., your DNS resolves a public hostname to a private
+IP), use the `--port` flag against the IP directly rather than
+disabling the gate.
+
+## References
+
+- [Computer Fraud and Abuse Act (CFAA), 18 U.S.C. § 1030](https://www.law.cornell.edu/uscode/text/18/1030)
+- [Penetration Testing Execution Standard (PTES) — Pre-engagement Interactions](http://www.pentest-standard.org/index.php/Pre-engagement)
+- [OWASP Web Security Testing Guide v4.2 § 2.1 — Set the scope](https://owasp.org/www-project-web-security-testing-guide/v42/)
+- [NIST SP 800-115 — Technical Guide to Information Security Testing](https://csrc.nist.gov/publications/detail/sp/800-115/final)