{"api_version":"2026-06-10","kind":"security-recipes.recipe-library","site":"security-recipes.ai","endpoint":"https://security-recipes.ai/api/recipes.json","legacy_endpoint":"https://security-recipes.ai/recipes-index.json","mcp_endpoint":"https://security-recipes.ai/mcp","generated_at":"2026-10-06T20:23:12.956Z","recipe_count":158,"agent_contract":{"read_only":true,"primary_lookup_fields":["slug","path","source_file","cve","ghsa","aliases"],"search_fields":["recipe_id","title","summary","content_text","tags","facets","ecosystem","agent","severity","framework","framework_version","jurisdiction","industry"],"mcp_tools":["recipes_search","recipes_list","recipes_get","recipes_match_finding"],"download_schema":"https://security-recipes.ai/schemas/recipe-download/v1","recipe_facets":["remediation","risk","audit","compliance","code-hygiene"],"app_store_model":"Recipes are installable context packs: browse by human intent, fetch by API, and select by MCP for one bounded remediation or evidence job.","quality_model":{"world_class":"85-100","strong":"70-84","usable":"50-69","starter":"0-49","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context","multi-facet"]}},"zero_day":{"label":"0-Day","window_days":4,"since":"2026-10-02","reference_date":"2026-10-06","count":0,"description":"CVE recipes whose site-created date falls within the current 0-Day window."},"categories":[{"slug":"classic-defaults","label":"Classic Vulnerable Defaults","count":10},{"slug":"claude","label":"Claude","count":2},{"slug":"code-hygiene","label":"Code Hygiene","count":72},{"slug":"codex","label":"Codex","count":2},{"slug":"compliance-standards","label":"Compliance Standards","count":39},{"slug":"crypto-defi","label":"Crypto/DeFi","count":12},{"slug":"cursor","label":"Cursor","count":2},{"slug":"cve","label":"CVE","count":3},{"slug":"devin","label":"Devin","count":2},{"slug":"general","label":"General","count":12},{"slug":"github-copilot","label":"GitHub Copilot","count":2}],"recipes":[{"slug":"cve-triage-skill","title":"Claude Code CVE and Dependency Remediation Skill","link_title":"CVE triage skill","url":"https://security-recipes.ai/recipes/claude/cve-triage-skill/","path":"/recipes/claude/cve-triage-skill/","source_file":"recipes/claude/cve-triage-skill.md","recipe_id":"","recipe_kind":"","category":{"slug":"claude","label":"Claude"},"agent":"claude","severity":"unspecified","maturity":"development","ecosystem":"","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"","framework_version":"","jurisdiction":"","industry":[],"cve_archetypes":[],"cve_workflow_role":"","tags":["triage","sca","cve","dependabot","skill"],"facets":["remediation","code-hygiene"],"quality":{"score":95,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"Stephen M Abbott","team":"Security","model":"Opus 4.7","ai_assisted":false,"generated_by":"","date":"2026-04-21","zero_day":false,"last_updated":"2026-04-21","summary":"A Claude Code skill that turns a fresh CVE or Dependabot alert into a tested dependency update or a structured note when safe automation must stop.\n","content_text":"A Claude Code skill that turns a fresh CVE or Dependabot alert into either (a) a correctly-bumped dependency with passing tests, or (b) a short report explaining why this alert can't be auto-fixed and what a human needs to do next. What this prompt does Claude reads the CVE number from the issue or alert, looks up the affected package range, finds the vulnerable dep in the repo's lock file, bumps it to the lowest non-vulnerable version, runs the project's tests, and opens a PR. If the fix can't be applied cleanly (transitive dep, major-version bump required, or tests fail), it writes a structured triage note instead and stops — it does not force a patch through. Inputs: CVE id + optional affected package hint.<br/> Outputs: either a PR (happy path) or a triage note (TRIAGE.md in the working branch). When to use it A new Dependabot PR landed and failed CI. Someone pasted a CVE into the #security-triage channel and asked for a first pass. Nightly sweep of open advisories that haven't been looked at in 3+ days. Don't use it for: CVEs affecting your own code (SAST findings) — this skill is for third-party dependencies only. Multi-repo fanouts — invoke it per-repo so the guardrails apply. The prompt Save as .claude/skills/cve-triage/SKILL.md at the repo root: ~~~markdown --- name: cve-triage description: | Triage a CVE or Dependabot advisory against this repo's lockfile. On success, bump the affected dependency to the lowest non-vulnerable version, verify tests pass, and open a PR. On failure, write a TRIAGE.md note and stop. --- CVE triage Inputs All inputs are optional. Infer first from the current session — the chat message / slash-command arguments, a linked GitHub issue body, the Dependabot alert payload, the branch name. When nothing provides a finding id and no scanner MCP is wired in, discover findings yourself using whatever local tooling is available. CVEID — e.g. CVE-2025-12345. Optional. Search the prompt body and any linked issue for a CVE- / GHSA- pattern; otherwise skip to the discovery path in step 0 below. HINT — (optional) affected package name. Use it as a lookup aid only; the lockfile is the source of truth. Discovery path (no CVEID provided) When no id is supplied and no scanner MCP is available: 1. Inventory the repo's lockfiles and manifests. 2. Run the lightest-weight scanner available in the environment, in this order: osv-scanner scan source ., npm audit --json (for Node), pip-audit (for Python), govulncheck ./... (for Go), cargo audit (for Rust), bundle audit (for Ruby), trivy fs --scanners vuln . as a multi-ecosystem fallback. 3. If none are installed, query the GitHub Advisory Database via gh api /repos/{owner}/{repo}/vulnerability-alerts or the public gh api /advisories?affects=... endpoint using the package names you found in step 1. 4. Pick the highest-severity open finding you can remediate under the rules below, and proceed as if its id was passed as CVEID. Note in the PR body that the finding was self-discovered and which scanner produced it. 5. If no tooling is available AND no advisory can be fetched, stop and write a TRIAGE.md explaining what tools the environment is missing. Procedure 1. Identify the affected package. Query the GitHub Advisory Database for $CVEID. If HINT is set, prefer it; otherwise use the advisory's reported package name. If there are multiple matching packages in the lockfile, ask a human and stop — do not guess. 2. Confirm the package appears in the lockfile. For Node: package-lock.json / pnpm-lock.yaml. For Python: poetry.lock / uv.lock / requirements.txt. For Go: go.sum. If not present, write TRIAGE.md with \"not vulnerable: package not in lockfile\" and stop. 3. Determine the fix version. Lowest version ≥ the patched range reported by the advisory. If the only fix crosses a major-version boundary and this is a direct dep, stop and write a triage note. Major-version bumps require a human. If it crosses a major-version boundary but is a transitive dep, follow the project's transitive-dep policy (see docs/security/transitive-deps.md — if absent, stop). 4. Apply the bump. Use the project's package manager — do not hand-edit the lockfile. Commit in one change with message chore(deps): bump <pkg> to <ver> (fixes <CVEID>). 5. Verify. Run make test (or the project's equivalent). If tests fail, do not force through — revert the bump, write TRIAGE.md with the failing test names, and stop. 6. Open a PR. Title: fix(sec): bump <pkg> to <ver> (<CVEID>). Body (template): see .github/PULLREQUESTTEMPLATE/sec-fix.md. Add labels: security, auto-remediation. Guardrails Never edit code outside the lockfile and the PR body. Never bypass CI by adding skip tokens. Never amend commits on branches you didn't create. If any PreToolUse hook blocks a command, record the block in TRIAGE.md and stop — do not retry with different commands. Output contract Success: a pushed branch + opened PR. Failure: a TRIAGE.md on the working branch with: CVE id Affected package + current / patched versions Reason the automation stopped (copy-pasted, not paraphrased) Suggested next owner (team or individual) ~~~ Verification Rechecked 2026-08-21 against the current Claude Code skill layout (.claude/skills/<name>/SKILL.md). Success still opens one advisory-scoped PR; failure still writes TRIAGE.md and stops. The skill still refuses own-code SAST findings and multi-repo fanout. Related recipes SAST finding triage and fix Base image bump CVE intelligence intake gate NIST SSDF repository evidence check Known limitations Monorepos with multiple lockfiles — the skill stops and asks. Future work: extend step 2 to walk every lockfile in the repo. Native deps pinned to a specific ABI (Node node-gyp native modules, Python wheels) — the bump may succeed and tests may still pass on the runner while failing in prod. Guardrail: the PR description template requires the author to confirm the package is pure-Python / pure-JS. Yanked versions — if the patched version is later yanked from the registry, the skill won't detect it. Check the upstream release page in the review step. Changelog 2026-04-21 — v1, first published. Covers Node / Python / Go lockfiles. Monorepo handling d","agent_handoff":{"mcp_lookup_keys":["cve-triage-skill","/recipes/claude/cve-triage-skill/","recipes/claude/cve-triage-skill.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["remediation","code-hygiene"],"source_text_field":"content_text","portable_download":"security-recipe-cve-triage-skill.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-cve-triage-skill.json"}},{"slug":"sensitive-data-remediation-skill","title":"Claude Code Sensitive Data Remediation Skill","link_title":"Sensitive data remediation skill","url":"https://security-recipes.ai/recipes/claude/sensitive-data-remediation-skill/","path":"/recipes/claude/sensitive-data-remediation-skill/","source_file":"recipes/claude/sensitive-data-remediation-skill.md","recipe_id":"","recipe_kind":"","category":{"slug":"claude","label":"Claude"},"agent":"claude","severity":"unspecified","maturity":"development","ecosystem":"","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"","framework_version":"","jurisdiction":"","industry":[],"cve_archetypes":[],"cve_workflow_role":"","tags":["sde","secrets","pii","dlp","skill","claude"],"facets":["remediation","code-hygiene"],"quality":{"score":95,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"Stephen M Abbott","team":"Security","model":"Opus 4.7","ai_assisted":false,"generated_by":"","date":"2026-04-21","zero_day":false,"last_updated":"2026-04-21","summary":"A Claude Code skill that triages a sensitive-data-element (SDE) finding — hard-coded secrets, PII in logs, credentials committed to source — and produces either (a) a PR that removes the SDE and replaces it with a vetted retrieval …","content_text":"A Claude Code skill that triages a sensitive-data-element (SDE) finding — hard-coded secrets, PII in logs, credentials committed to source — and produces either (a) a PR that removes the SDE and replaces it with a vetted retrieval pattern, or (b) a structured triage note explaining why this finding needs a human. What this prompt does Claude reads the finding id, locates the offending occurrence in the current working tree (not in history — history rewriting is out of scope for this skill and handled by a separate runbook), replaces the literal value with a reference to the approved secret-store / config source, adds a regression guard (ignore-rule or unit test depending on class), runs the repo's test + lint commands, and opens a PR. Where the SDE is already-exposed (commit history, public log, vendored artifact), the skill stops and writes a TRIAGE.md with the rotation + disclosure checklist instead of quietly papering over it. Inputs: FINDINGID, optional FILEPATH + LINE hint, SDECLASS (secret / pii / pci / phi / token).<br/> Outputs: either a PR (happy path) plus a rotation ticket referenced in the PR body, or a TRIAGE.md triage note with a rotation + disclosure checklist. When to use it A secret scanner (GitHub push protection, GitLeaks, TruffleHog, Wiz, Snyk) raised a finding on a current-tree file. A PII / DLP scanner flagged a log-line or test fixture shipping real user data. Dependabot-style SDE sweeps where the team already has an approved secret store (Vault, AWS Secrets Manager, GCP Secret Manager, 1Password) the replacement can point at. Don't use it for: Secrets already pushed to a remote branch or public repo — the rotation path is the primary fix; this skill will refuse and create a triage note. Binary artifacts or images with embedded SDEs — use a separate image-sanitization runbook. Cross-repo propagation (the same key appears in ten repos) — run it per-repo, after the rotation ticket is open. The prompt Save as .claude/skills/sde-remediation/SKILL.md at the repo root: ~~~markdown --- name: sde-remediation description: | Remediate a sensitive-data-element (SDE) finding in the current working tree — hard-coded secrets, PII in logs, credentials in source. Replace the literal with a reference to the approved secret store, add a regression guard, and open a PR. If the SDE is already-exposed (in history, a public log, or a shipped artifact), stop and write TRIAGE.md with a rotation + disclosure checklist. --- Sensitive data element remediation Inputs All inputs are optional. Infer first from session context — the chat message / slash-command arguments, a linked GitHub issue or scanner payload, the triggering push-protection block. When nothing provides a finding and no scanner MCP is wired in, discover candidate SDEs yourself using local tooling. FINDINGID — scanner id (e.g. GITLEAKS-AWS-001, WIZ-SECRET-42931). If absent, synthesize a local id after discovery (e.g. LOCAL-GITLEAKS-<rule>-<sha>). FILEPATH — take from the scanner payload or prompt body. Otherwise produced by discovery. LINE — same sources as FILEPATH. SDECLASS — one of secret, pii, pci, phi, token. Take from the prompt body or the scanner's rule id; otherwise classify from the discovery output (AWS-access-key rule → secret; Stripe-live-key → secret; email-in-logs → pii; etc.). Discovery path (no finding provided) When nothing is supplied and no scanner MCP is available: 1. Run the lightest-weight secret/PII scanner installed, in this order: gitleaks detect --source . --no-banner, trufflehog filesystem . --json, detect-secrets scan --all-files, trivy fs --scanners secret . as a multi-scanner fallback. 2. Restrict discovery to the working tree only — do NOT scan commit history. History-resident SDEs are a rotation problem, not a code-edit problem, and require a separate runbook. 3. Pick one high-confidence finding per run and proceed as if it had been supplied. Note in the PR body that it was self-discovered and which scanner produced it. 4. If no scanner is available, stop and write TRIAGE.md listing what to install (with a one-line justification per tool) so a human can wire it up. Never grep for a secret literal yourself — leave pattern matching to the scanner so the literal never enters your reasoning trace. Procedure 1. Confirm the finding is live in the working tree. Read FILEPATH:LINE; if the literal value is not present, the finding may have been fixed already. Write TRIAGE.md with \"not-reproduced\" and stop. Do not grep the commit history — that's the secret-rotation runbook's job. 2. Classify the exposure scope. If the file is in a public repo, or has been pushed to a shared remote branch, OR the secret appears in CI logs: this is an exposed SDE. Skip to step 7. Otherwise, this is a pre-exposure SDE and you may remediate in-place. 3. Pick the replacement pattern from the allowlist. secret / token → read from the repo's approved secret store client. Consult docs/security/secrets.md for the project's chosen store; if absent, stop and triage. pii / pci / phi → replace with a synthetic fixture in tests; in runtime code, route through the project's redaction helper (grep for redact(, Redactor, or maskpii). If none exists, stop and triage — do not invent one. 4. Apply the replacement. Minimal edit: remove the literal, insert the reference / redaction call, update the smallest surrounding context needed to compile. Never rename files, never reformat unrelated code in the same commit. 5. Add a regression guard. If the repo has gitleaks / trufflehog / detect-secrets config, add an allowlist entry only for the synthetic-fixture path, with a comment citing the finding id. For code paths: add a unit test that asserts the offending value is no longer present (string match against the removed literal). 6. Verify and open a PR. Run the project's lint + test commands. Commit message: fix(sec): remove <SDECLASS> <FINDINGID>. PR title: fix(sec): remove <SDECLASS> from <file> (<FINDINGID>). PR body: Finding id. Rotation status: \"N/A — pre-exposure, no rotation required\" (only for pre-exposure fixes; an exposed SDE never reaches this step). Blast radius (files touched, callers changed). Apply labels: security, sde-remediation. 7. Exposed SDE — stop and triage. Write TRIAGE.md on a fresh branch sde-triage/<FINDINGID> with: Finding id, file, line. Rotation checklist (tick each when done): [ ] Revoke the credential at the issuer. [ ] Rotate in the approved secret store. [ ] Re-deploy consumers. [ ] Invalidate any cached sessions / tokens. Disclosure checklist: [ ] File an incident in the IR tracker. [ ] Notify the service owner. [ ] Determine if a customer / regulator notification is required (route to legal). Suggested next owner (team / on-call rotation). Do not edit the offending file yet — rotation happens first. Guardrails Never edit git history from this skill. History rewrites require a documented runbook and a human. Never inline the replacement value you just retrieved from the secret store into a log line, an error message, or a comment. Never bypass a PreToolUse hook that blocks writing to secret-material paths — record the block in TRIAGE.md and stop. Never commit a .env or credentials.json file, even to remove it — those need git filter-repo treatment, not a normal commit. Verification Rechecked 2026-08-21 against the current Claude Code skill layout. Exposed secrets still stop at rotation plus TRIAGE.md; they do not rewrite git history. The skill still refuses to inline retrieved secret values into logs or comments. Output contract Success (pre-exposure): a pushed branch + opened PR, plus a passing regression-guard test. Exposed SDE: a triage branch with TRIAGE.md, zero code edits on the offending file. ~~~ Related recipes Source code secrets and data exposure audit Sensitive data remediation Context egress boundary NIST SSDF repository evidence check Known limitations History rewrites are out of scope. If the SDE was ever committed, rotation is the primary fix; use the separate secret-rotation runbook before cleaning history. Cross-repo propagation isn't detected. The skill only looks at the current working tree. Pair it with an org-wide grep in your SOAR step before closing the finding. Synthetic-fixture quality varies. For PII fixtures, prefer Faker-style libraries over hand-rolled mocks — hand-rolled data tends to leak structural hints (same byte lengths as real data) that defeat the redaction. Detectors with high false-positive rates (e.g. broad regex patterns for \"api_key\") will send the skill to triage more often than needed. Tune scanner rules upstream. Changelog 2026-04-21 — v1, first published. Covers hard-coded secrets, PII in logs, and test fixtures containing real user data. History rewrite path intentionally out of scope.","agent_handoff":{"mcp_lookup_keys":["sensitive-data-remediation-skill","/recipes/claude/sensitive-data-remediation-skill/","recipes/claude/sensitive-data-remediation-skill.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["remediation","code-hygiene"],"source_text_field":"content_text","portable_download":"security-recipe-sensitive-data-remediation-skill.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-sensitive-data-remediation-skill.json"}},{"slug":"sensitive-data-remediation","title":"Codex Sensitive Data Remediation","link_title":"Sensitive data remediation","url":"https://security-recipes.ai/recipes/codex/sensitive-data-remediation/","path":"/recipes/codex/sensitive-data-remediation/","source_file":"recipes/codex/sensitive-data-remediation.md","recipe_id":"","recipe_kind":"","category":{"slug":"codex","label":"Codex"},"agent":"codex","severity":"unspecified","maturity":"development","ecosystem":"","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"","framework_version":"","jurisdiction":"","industry":[],"cve_archetypes":[],"cve_workflow_role":"","tags":["sde","secrets","pii","dlp","codex","noninteractive","ci"],"facets":["remediation","code-hygiene"],"quality":{"score":95,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"Stephen M Abbott","team":"Security","model":"Opus 4.7","ai_assisted":false,"generated_by":"","date":"2026-04-21","zero_day":false,"last_updated":"2026-04-21","summary":"A Codex CLI prompt for headless SDE remediation — hard-coded secrets, PII in logs, credentials committed to source — wired for codex exec --sandbox workspace-write --json so it can be dispatched from a scanner webhook or scheduled CI job. …","content_text":"A Codex CLI prompt for headless SDE remediation — hard-coded secrets, PII in logs, credentials committed to source — wired for codex exec --sandbox workspace-write --json so it can be dispatched from a scanner webhook or scheduled CI job. It remediates only pre-exposure findings; exposed SDEs (anything already pushed to a shared remote, public log, or build artifact) are routed straight to triage + rotation. What this prompt does Codex loads a single SDE finding from env vars, confirms the literal value is present in the working tree, classifies the exposure scope, and — if pre-exposure — replaces the literal with a reference to the approved secret store (or redaction helper for PII). It adds a regression-guard test, runs lint + tests, and opens a PR. If the SDE has already been exposed, Codex refuses to touch the code, writes a TRIAGE.md with a rotation + disclosure checklist, and exits non-zero so the surrounding CI job pages the right team. Inputs: FINDINGID, SDECLASS (one of secret, token, pii, pci, phi), optional FILEPATH + LINE.<br/> Outputs: a PR (pre-exposure path) or a TRIAGE.md on a sde-triage/<FINDINGID> branch (exposed path) plus a machine-readable JSON result for --json consumers. When to use it A scanner (GitHub push protection, GitLeaks, TruffleHog, Wiz, Snyk IaC) fires a webhook and your dispatcher hands the finding to Codex. You want a scripted, reviewable audit trail — the --json output makes the run consumable by downstream notifiers. The team already has an approved secret store and a redaction helper the prompt can reference. Don't use it for: Cleaning committed history — the rotation runbook is the right place. This prompt refuses. Ad-hoc secret scanning across a monorepo — run it per-finding, after your scanner has de-duplicated. Binary artifact sanitization (images, packaged bundles). Inputs Scanner payload or MCP finding context with FINDINGID, SDECLASS, file path, line number, rule id, confidence, first-seen metadata, and whether the finding came from working tree, push protection, CI logs, or artifacts. Repository evidence: current branch, default branch, remote URL, scanner config, .env.example, SECURITY.md, docs/security/secrets.md, redaction-helper locations, and project-specific test/lint commands. Approved replacement patterns for secrets, tokens, PII, PCI, and PHI: secret-store clients, configuration keys, redaction helpers, synthetic test data generators, and scanner allowlist formats. Exposure evidence: git history hits, public/private repository status, shared-remote status, CI/artifact publication, scanner first-seen data, and owner or incident-routing metadata. CI automation settings for codex exec --full-auto --json, branch naming, non-zero triage exits, PR labels, notification routing, and JSON consumers. The prompt Invoke as: codex exec --sandbox workspace-write --json \\ \"$(envsubst < prompts/remediate-sde.md)\" \\ \"/tmp/codex-${FINDINGID}.jsonl\" Where prompts/remediate-sde.md contains: ~~~markdown ROLE You are a senior application-security engineer running headlessly in CI. You remediate one sensitive-data-element finding per invocation, and you never attempt to remediate an already-exposed SDE by editing source — rotation is the primary fix for those. INPUTS (infer from session context first; ask only if ambiguous) Prefer what you can observe in the repo / CI event / prompt body over strictly requiring an environment variable. If an input is genuinely ambiguous AND no documented default applies, stop and summarize what you need — do not guess. FINDINGID Optional. Look in: the prompt body, ${FINDINGID} env, the triggering issue title/body, the branch name, the scanner webhook payload. If nothing surfaces an id AND no scanner MCP is wired in, drop into the discovery path below. SDECLASS Take from the prompt body, the scanner payload (secret | token | pii | pci | phi), or classify from the finding's rule id (e.g. an AWS-access-key rule implies secret). If discovery produced the finding, classify from its rule id. REPO Detect via git config --get remote.origin.url or the GitHub event payload. FILEPATH / LINE Take from the scanner payload or prompt body first. If absent, stop and ask — do NOT grep the repo for the literal. (This prompt never searches for a secret value directly.) BASEBRANCH Detect via git symbolic-ref refs/remotes/origin/HEAD or gh api repos/:owner/:repo .defaultbranch. Fallback: main, then master. WORKINGBRANCH Default: fix/<finding-id>. If it exists, append -N. TESTCMD / LINTCMD Read in this order: the prompt body, AGENTS.md, CONTRIBUTING.md, README \"Development\" section, package.json scripts, Makefile targets. Note the choice in the PR. SECRETSDOC Look for docs/security/secrets.md, SECURITY.md, CONTRIBUTING.md \"Secrets\" section, or a root-level .env.example with a commented store hint. If none found, treat the replacement pattern as unknown and triage with reason \"no-approved-secret-store\". PROCEDURE 0. Discovery (only if FINDINGID + FILEPATH were not provided). Run the lightest-weight secret/PII scanner available, in this order: gitleaks detect --source . --no-banner --report-format json --report-path /tmp/gl.json, trufflehog filesystem . --json, detect-secrets scan --all-files, trivy fs --scanners secret .. Restrict to the WORKING TREE only — do not scan commit history. Exposed SDEs are a rotation problem and handled by step 7. Pick the highest-confidence finding. Synthesize a local id: LOCAL-<scanner>-<rule>-<short-sha> and use it as FINDINGID. Populate FILEPATH / LINE from the scanner output. Classify SDECLASS from the rule id. Note in the PR body that the finding was self-discovered and which scanner produced it. If no scanner is installed, write TRIAGE.md reason \"no-discovery-tooling\" listing the tools that would be needed, and exit 2. 1. Checkout ${BASEBRANCH}. Create ${WORKINGBRANCH}. 2. Confirm the literal is present in the working tree. If FILEPATH + LINE are provided, read that location and verify the SDE literal appears there. If not provided, refuse — ask the dispatcher to include them. Do not grep history. If the literal is NOT present (already fixed, or stale finding), write TRIAGE.md reason \"not-reproduced\" and exit 2. 3. Classify the exposure scope. Run git log --all --source -S '<literal>' -- ${FILEPATH}. (Use a hash of the literal in logs — never echo it.) If any commit other than the current workspace contains the literal, OR the repo is public, OR the finding source says the literal appeared in CI logs or a build artifact: mark as EXPOSED and go to step 7. Otherwise PRE-EXPOSURE; continue to step 4. 4. Pick the replacement pattern. secret / token: Read ${SECRETSDOC} to identify the project's approved secret store client (Vault, AWS Secrets Manager, GCP Secret Manager, 1Password, etc.). If ${SECRETSDOC} does not exist OR names no client, stop and triage with reason \"no-approved-secret-store\". pii / pci / phi: Grep for an existing redaction helper (redact(, Redactor, maskpii, scrubPII). If none found, stop and triage with reason \"no-redaction-helper\". 5. Apply the replacement. Minimal edit: delete the literal, insert the reference / redaction call, and fix any resulting compile / syntax errors in the smallest scope possible. Never rename files. Never reformat unrelated code. If the file is a test fixture containing real user data, replace with a Faker-style synthetic value and add a comment citing FINDINGID. 6. Add a regression guard + verify. Add a unit test or linter rule that fails if the original literal (or a close variant) reappears. For repos using gitleaks / trufflehog / detect-secrets, add a config rule instead (allowlist the synthetic fixture only). Run ${LINTCMD}. Run ${TESTCMD}. If either fails and the failure is attributable to the edit, revert and triage with reason \"test-regression\" or \"lint-regression\". Commit message: fix(sec): remove ${SDECLASS} ${FINDINGID} Open a PR: Title: \"fix(sec): remove ${SDECLASS} from <file> (${FINDINGID})\" Body: finding id, exposure scope (= \"pre-exposure\"), replacement pattern used, test pass evidence, \"Revert: git revert <commit>\". Labels: security, sde-remediation. 7. EXPOSED path — do NOT edit the offending file. Write TRIAGE.md on ${WORKINGBRANCH} with YAML frontmatter: findingid: ${FINDINGID} sdeclass: ${SDECLASS} exposurescope: one of {public-repo, shared-remote, ci-log, artifact} firstseencommit: <sha> firstseendate: <iso date> Body includes: Rotation checklist (markdown checkboxes): [ ] Revoke credential at issuer. [ ] Rotate in approved secret store. [ ] Re-deploy consumers. [ ] Invalidate cached sessions / tokens. Disclosure checklist: [ ] Open incident in IR tracker. [ ] Notify service owner. [ ] Route to legal for notification assessment. Commit, push, exit 2. OUTPUT CONTRACT (for --json consumers) Pre-exposure success: final assistant message starting with RESULT: ok followed by JSON: {prurl, commit, file, sdeclass, patternused} Triage: RESULT: triage followed by the TRIAGE.md frontmatter serialized to JSON. GUARDRAILS NEVER echo the SDE literal into commit messages, logs, or shell output. When you need to refer to it, hash it. NEVER rewrite git history. History cleanup requires the rotation runbook + a human. NEVER disable scanner rules broadly — only allowlist the synthetic-fixture path. NEVER commit .env / credentials.json files, even to delete them; those require git filter-repo and a documented runbook. NEVER merge the PR you opened. ~~~ Verification Rechecked 2026-08-23 against codex exec --sandbox workspace-write --json. Do not pin gpt-5.3-codex or gpt-5.6-sol in the invoke command. Exposed SDEs still stop at rotation plus TRIAGE.md and never rewrite history. The prompt still forbids echoing the SDE literal into commits, logs, or shell output. Output contract Return one of: A reviewer-ready PR/change request for a pre-exposure SDE that removes the literal, replaces it with the approved secret-store or redaction pattern, adds a regression guard, runs lint/tests, and emits the expected JSON result for downstream automation. TRIAGE.md on a sde-triage/<FINDINGID> branch when the SDE is exposed, stale, missing required context, lacks an approved secret store or redaction helper, or cannot be safely remediated by editing source. The output must list finding id, SDE class, exposure scope, file touched or triaged, replacement pattern, tests and lint commands, JSON result fields, rotation/disclosure checklist when exposed, and residual owner actions. It must not echo the literal, rewrite history, commit/delete .env files, broadly disable scanner rules, or merge its own PR. Related recipes Sensitive Data Remediation Source-code secrets and data exposure audit Agentic incident response pack Known limitations History cleanup is out of scope on purpose. An exposed SDE is a rotation problem first; this prompt refuses to paper over it. Redaction-helper detection is grep-shaped. Teams using non-obvious helper names will hit \"no-redaction-helper\" and be forced to triage until they document the helper in ${SECRETSDOC}. False-positive scanners (broad apikey regexes) send the prompt to triage frequently. Tune scanner rules upstream so Codex isn't asked to fix noise. Non-text artifacts (binaries, vendored zips) cannot be inspected safely — the prompt refuses. Changelog 2026-08-23 — Drop the leftover --model gpt-5.3-codex pin. Official invoke form stays codex exec --sandbox workspace-write --json. 2026-04-21 — v1, first published. Handles secret / token / pii / pci / phi classes. History rewrite path deliberately deferred to rotation runbook.","agent_handoff":{"mcp_lookup_keys":["sensitive-data-remediation","/recipes/codex/sensitive-data-remediation/","recipes/codex/sensitive-data-remediation.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["remediation","code-hygiene"],"source_text_field":"content_text","portable_download":"security-recipe-sensitive-data-remediation.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-sensitive-data-remediation.json"}},{"slug":"vulnerable-dep-remediation","title":"Codex Vulnerable Dependency Remediation","link_title":"Vulnerable dep remediation","url":"https://security-recipes.ai/recipes/codex/vulnerable-dep-remediation/","path":"/recipes/codex/vulnerable-dep-remediation/","source_file":"recipes/codex/vulnerable-dep-remediation.md","recipe_id":"","recipe_kind":"","category":{"slug":"codex","label":"Codex"},"agent":"codex","severity":"unspecified","maturity":"development","ecosystem":"","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"","framework_version":"","jurisdiction":"","industry":[],"cve_archetypes":[],"cve_workflow_role":"","tags":["sca","cve","dependencies","codex","noninteractive","ci"],"facets":["remediation","risk","code-hygiene"],"quality":{"score":100,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context","multi-facet"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"Stephen M Abbott","team":"Security","model":"Opus 4.7","ai_assisted":false,"generated_by":"","date":"2026-04-21","zero_day":false,"last_updated":"2026-04-21","summary":"A Codex CLI prompt designed for non-interactive, CI-driven runs (codex exec --sandbox workspace-write --json). It picks up a single CVE / advisory id, locates the affected dependency in the repo's manifest + lockfile, applies the minimum …","content_text":"A Codex CLI prompt designed for non-interactive, CI-driven runs (codex exec --sandbox workspace-write --json). It picks up a single CVE / advisory id, locates the affected dependency in the repo's manifest + lockfile, applies the minimum viable patched version, runs the project's tests, and either opens a PR or writes a structured triage note. It is intentionally narrow: one finding, one commit, one PR — so the output is easy to review and easy to revert. What this prompt does Codex loads the finding from the environment, inspects the repo's manifests (package.json + lockfile, go.mod/go.sum, requirements.txt/uv.lock, Cargo.toml/Cargo.lock, pyproject.toml, Gemfile.lock), picks the smallest safe bump (no major-version changes), regenerates the lockfile with the native package manager, runs the project's standard test command, and if green: opens a PR linked to the finding. If the bump is blocked (major boundary, transitive-only, tests fail, no patch available) Codex writes a machine-readable TRIAGE.md to the working branch and exits non-zero so the surrounding CI job surfaces it. Inputs: FINDINGID, AFFECTEDPACKAGE (optional hint), REPO (auto-detected), BASEBRANCH (default main).<br/> Outputs: one PR (happy path) or a TRIAGE.md on a triage/<FINDINGID> branch plus a non-zero exit code. When to use it You're running Codex from a GitHub Actions / GitLab CI job triggered by dependabotalert, a Snyk webhook, or a nightly schedule. You need --json output so downstream steps (Slack notifier, ticket updater) can parse the run result. Your reviewers want one PR per finding, not a \"bundle of bumps\" — the narrow scope keeps reverts clean. Don't use it for: Major version migrations — the prompt refuses by default. First-party SAST findings — use the SDE remediation recipe instead. Interactive investigations — use codex (not codex exec) for those; this prompt is specifically shaped for headless runs. Inputs Scanner, Dependabot, Snyk, OSV, GitHub Advisory, or MCP finding context with FINDINGID, affected package, severity, ecosystem, affected range, patched range, direct/transitive status, and advisory URL. Repository evidence: manifests, lockfiles, package-manager choice, workspace files, generated dependency reports, SBOMs, CODEOWNERS, default branch, branch naming rules, and PR labeling conventions. Automation settings for codex exec --full-auto --json, severity threshold, maximum allowed major bumps, prerelease policy, dry-run mode, CI event payload, and downstream JSON consumers. Verification commands from AGENTS.md, CONTRIBUTING.md, README, package.json, Makefile, or prompt body, plus available re-scan tools such as OSV Scanner, npm audit, pip-audit, govulncheck, cargo audit, bundle audit, Trivy, or Grype. Triage ownership evidence for missing lockfiles, transitive-only blocks, major-version migrations, unavailable fixes, test regressions, lint regressions, and fix-did-not-resolve cases. The prompt Invoke as: codex exec --sandbox workspace-write --json \\ \"$(envsubst < prompts/remediate-dep.md)\" \\ \"/tmp/codex-${FINDINGID}.jsonl\" Where prompts/remediate-dep.md contains: ~~~markdown ROLE You are a senior application-security engineer + release engineer. You are running headlessly inside CI. Be deterministic, idempotent, and conservative. Produce either a single, revertible pull request or a structured triage note — never both, never partial progress. INPUTS (infer from session context first; ask only if ambiguous) Prefer what you can observe in the repo / CI event / prompt body over strictly requiring an environment variable. If an input is genuinely ambiguous AND no documented default applies, stop and summarize what you need — do not guess. FINDINGID Optional. Look in this order: the prompt body (CVE- / GHSA- pattern), ${FINDINGID} env, the triggering issue title/body, the branch name, the Dependabot alert payload. If nothing surfaces an id AND no scanner MCP is wired in, drop into the discovery path below and self-select a finding. AFFECTEDPACKAGE (optional hint) Infer from the advisory or the scanner payload. Use only as a lookup hint — the lockfile is the source of truth. REPO Detect via git config --get remote.origin.url or the GitHub event payload. Avoid asking. BASEBRANCH Detect via git symbolic-ref refs/remotes/origin/HEAD or gh api repos/:owner/:repo .defaultbranch. Fallback: main, then master. WORKINGBRANCH Default: fix/<finding-id>. If that branch exists, append -N to keep it unique. TESTCMD / LINTCMD Read in this order: the prompt body, AGENTS.md, CONTRIBUTING.md, README's \"Development\" section, package.json scripts, Makefile targets. Proceed with the best match and note the choice in the PR body. SEVERITYTHRESHOLD Default: HIGH (overridden by the prompt). MAXMAJORBUMPS Default: 0. Override only if the prompt explicitly permits majors. ALLOWPRERELEASE Default: false. DRYRUN Default: false; true if the prompt body or branch name contains dry-run. PROCEDURE 0. Discovery (only if FINDINGID was not provided). Run the lightest-weight local scanner available, in this order: osv-scanner scan source ., npm audit --json (Node), pip-audit (Python), govulncheck ./... (Go), cargo audit (Rust), bundle audit (Ruby), trivy fs --scanners vuln . as a multi-ecosystem fallback. If none are installed, query GitHub Advisory Database via gh api /repos/{owner}/{repo}/vulnerability-alerts or the public gh api /advisories?affects=<pkg> endpoint using package names from the manifests. Pick the highest-severity fixable finding that meets the rules below (≥ SEVERITYTHRESHOLD, non-major bump, non-prerelease fix). Use its CVE / GHSA id as FINDINGID and note in the PR body that it was self-discovered by ${discovery-source}. If no scanner is available AND the Advisory-DB query returns nothing, write TRIAGE.md reason \"no-discovery- tooling\" and exit 2. 1. Checkout ${BASEBRANCH}. Create ${WORKINGBRANCH}. 2. Identify the advisory. Query the GitHub Advisory Database for ${FINDINGID} (or the OSV mirror if GHSA is unavailable). Record: advisory title, published date, severity, affected ecosystem, affected version range, patched version range, CWE / CVSS if present. If the advisory's severity is below ${SEVERITYTHRESHOLD}, stop and write TRIAGE.md with reason \"below-threshold\". 3. Inventory the repo. Detect manifest(s): package.json, pnpm-workspace.yaml, go.mod, Cargo.toml, pyproject.toml, requirements.txt, Gemfile, composer.json, etc. Detect package manager by the corresponding lockfile. If no lockfile exists, stop and triage with reason \"missing-lockfile\" — a bump without a lockfile isn't deterministic. 4. Locate the affected package. Use AFFECTEDPACKAGE if provided; otherwise the advisory's reported package. Walk the resolved dependency tree (not the manifest) — the package may be transitive. If not present at any depth, stop and write TRIAGE.md with reason \"not-installed\". The repo is not vulnerable. 5. Determine the fix version. Pick the lowest version in the advisory's patched range. If that version crosses a major boundary from the currently installed version AND MAXMAJORBUMPS == 0: if the package is a DIRECT dep, stop and write TRIAGE.md with reason \"major-bump-required\". if the package is TRANSITIVE, prefer a minimum bump of the direct parent that pulls in a fixed transitive. If that too requires a major bump, stop and triage. If the fix is a pre-release and ALLOWPRERELEASE == false, stop and triage with reason \"prerelease-only\". 6. Apply the bump. Use the native package manager: Node: pnpm / npm / yarn update <pkg> --save-exact (match repo idiom). Go: go get <pkg>@<ver> && go mod tidy. Python: uv add \"<pkg>==<ver>\" OR pip-compile with updated constraint. Rust: cargo update -p <pkg> --precise <ver>. Ruby: bundle update <pkg> --conservative --patch. One commit, message: \"fix(sec): bump <pkg> from <old> to <new> (${FINDINGID})\". Do not touch any file outside the manifest + lockfile except where the package manager rewrites a peer file. 7. Verify. Run ${LINTCMD}. If it fails with changes attributable to the bump, revert and triage with reason \"lint-regression\". Run ${TESTCMD}. If it fails, revert and triage with reason \"test-regression\" and copy-paste (do not paraphrase) the first failing test's output. Re-scan the lockfile (osv-scanner / grype / trivy fs — whichever is available). If the same finding still appears, triage with reason \"fix-did-not-resolve\". 8. Happy path — open a PR. Title: \"fix(sec): bump <pkg> to <ver> (${FINDINGID})\". Body: Finding id + link to advisory. Old → new version; direct vs transitive. Test command + pass / fail. \"Revert: git revert <commit> — no other files touched.\" Labels: security, auto-remediation. DO NOT merge. DO NOT enable auto-merge. 9. Triage path — write TRIAGE.md. Fields (YAML frontmatter): findingid: ${FINDINGID} severity: <from advisory> reason: one of {below-threshold, missing-lockfile, not-installed, major-bump-required, prerelease-only, lint-regression, test-regression, fix-did-not-resolve} package: <name> currentversion: <ver> patchedrange: <range> nextowner: <team or CODEOWNERS group> Body: copy-pasted evidence (command output, test failures). Commit TRIAGE.md on ${WORKINGBRANCH}, push, and exit 2. OUTPUT CONTRACT (for --json consumers) On success: emit a final assistant message whose first line is RESULT: ok followed by a JSON object with keys {prurl, commit, pkg, oldversion, newversion}. On triage: RESULT: triage followed by the same YAML frontmatter as TRIAGE.md, serialized to a single JSON object. GUARDRAILS NEVER disable a test or add skip markers to make CI green. NEVER edit code outside the manifest / lockfile and TRIAGE.md. NEVER push to ${BASEBRANCH}. NEVER merge a PR you opened. NEVER amend commits on branches you did not create. If MAXMAJORBUMPS == 0 and the only fix is a major bump, you must triage. Do not rationalize the bump. ~~~ Verification Rechecked 2026-08-23 against OpenAI's current non-interactive codex exec --sandbox workspace-write --json form. Do not pin gpt-5.3-codex or gpt-5.6-sol in the invoke command. One finding still produces one commit and one PR, or TRIAGE.md. The prompt still refuses major bumps when MAXMAJORBUMPS is zero. Output contract Return one of: A reviewer-ready PR/change request that updates exactly one advisory-driven dependency path, uses the native package manager, touches only manifest and lockfile artifacts, runs lint/tests and a vulnerability re-scan, and emits RESULT: ok JSON for automation. TRIAGE.md on a triage/<FINDINGID> branch when the finding is below-threshold, missing a lockfile, not installed, requires a disallowed major bump, has only prerelease fixes, fails lint/tests, or the re-scan still reports the finding. The output must list finding id, package, ecosystem, old/new version, patched range, direct/transitive status, package manager, files touched, verification commands, re-scan evidence, PR URL or triage reason, and next owner. It must not edit application code, skip tests, push to the base branch, merge its own PR, or rationalize a major bump when MAXMAJORBUMPS is zero. Related recipes Vulnerable Dependency Remediation Source-code supply chain build integrity audit Codex sensitive data remediation Known limitations Monorepos with many lockfiles. The prompt stops at the first manifest. For workspaces, run one invocation per workspace package, or extend step 3 to iterate. Advisory metadata gaps. GHSA entries occasionally lack a precise patched range; the prompt will refuse rather than guess. Keep an advisory-source fallback (OSV, ecosystem security team) ready. Non-SemVer ecosystems. Maven / Go pseudo-versions / CocoaPods require ecosystem-specific bump logic; step 6 is a sketch, not a complete solution for those. Re-scan requires a scanner on the runner.** Step 7's re-scan depends on osv-scanner / grype / trivy being installed; if none are, the prompt will note \"re-scan skipped\" in the PR body and the reviewer should verify manually. Changelog 2026-08-23 — Drop the leftover --model gpt-5.3-codex pin. Official invoke form stays codex exec --sandbox workspace-write --json. 2026-04-21 — v1, first published. Shaped for codex exec --sandbox workspace-write --json. Handles Node / Python / Go / Rust / Ruby; monorepo + Maven handling deferred to v2.","agent_handoff":{"mcp_lookup_keys":["vulnerable-dep-remediation","/recipes/codex/vulnerable-dep-remediation/","recipes/codex/vulnerable-dep-remediation.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["remediation","risk","code-hygiene"],"source_text_field":"content_text","portable_download":"security-recipe-vulnerable-dep-remediation.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-vulnerable-dep-remediation.json"}},{"slug":"sensitive-data-remediation","title":"Cursor Sensitive Data Remediation","link_title":"Sensitive data remediation","url":"https://security-recipes.ai/recipes/cursor/sensitive-data-remediation/","path":"/recipes/cursor/sensitive-data-remediation/","source_file":"recipes/cursor/sensitive-data-remediation.md","recipe_id":"","recipe_kind":"","category":{"slug":"cursor","label":"Cursor"},"agent":"cursor","severity":"unspecified","maturity":"development","ecosystem":"","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"","framework_version":"","jurisdiction":"","industry":[],"cve_archetypes":[],"cve_workflow_role":"","tags":["sde","secrets","pii","dlp","cursor","rules","commands"],"facets":["remediation","code-hygiene"],"quality":{"score":95,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"Stephen M Abbott","team":"Security","model":"Opus 4.7","ai_assisted":false,"generated_by":"","date":"2026-04-21","zero_day":false,"last_updated":"2026-04-21","summary":"A Cursor project rule + custom slash command pair for remediating a sensitive-data-element (SDE) finding — hard-coded secrets, PII in logs, credentials in source. The rule locks in the house posture (\"rotation first for exposed SDEs, no …","content_text":"A Cursor project rule + custom slash command pair for remediating a sensitive-data-element (SDE) finding — hard-coded secrets, PII in logs, credentials in source. The rule locks in the house posture (\"rotation first for exposed SDEs, no history rewrites, one finding per PR\"); the command is the one-liner an engineer or Cursor Automation invokes. What this prompt does When /remediate-sde <finding-id> <class> runs, the Cursor Agent (interactive or Cloud Agent) confirms the literal is in the current working tree, classifies the exposure scope, and — if pre-exposure — replaces the literal with a reference to the approved secret store (or a redaction helper for PII), adds a regression guard, runs tests, and opens a draft PR. For exposed findings, the rule forces the agent to stop, write a triage note with a rotation + disclosure checklist, and not touch code. Inputs: finding id and SDE class (one of secret, token, pii, pci, phi) as command arguments. Optional file-path hint in the chat body.<br/> Outputs: a draft PR (pre-exposure path) or a triage branch + summary in chat (exposed path). When to use it GitHub push protection / GitLeaks / TruffleHog / Wiz fires on a pre-exposure finding and the developer wants to fix it without leaving Cursor. Cursor Automations watches an issue label (security:sde) and needs a consistent command to dispatch. A PII scanner flags a test fixture containing real user data and the replacement is a Faker-style synthetic value. Don't use it for: Any SDE already pushed to a shared remote or published log — the rule forces triage + rotation. This is the correct behavior, not a bug. Cross-repo sweeps — run once per finding after dedup. Binary artifacts — the rule refuses. Inputs Cursor chat arguments, issue context, scanner/MCP finding data, file-path hints, line numbers, rule ids, SDE class, first-seen metadata, and confidence. Project rule and command files: .cursor/rules/remediate-sde.mdc, .cursor/commands/remediate-sde.md, Cursor Automation trigger labels, and repo-local house rules. Repository evidence: default branch, remote URL, scanner config, docs/security/secrets.md, SECURITY.md, .env.example, redaction helpers, test commands, lint commands, and PR conventions. Exposure evidence from working tree, git history, scanner metadata, public repo status, shared remote status, CI logs, and build artifacts. Approved remediation patterns for secret-store references, token rotation handoff, PII/PCI/PHI redaction, synthetic fixture replacement, scanner allowlists, and triage branch creation. The prompt Two files, checked in to the repo. .cursor/rules/remediate-sde.mdc ~~~markdown --- description: > Sensitive-data-element remediation house rules. Applies whenever the agent is asked to remove a hard-coded secret, PII, or credential from source. alwaysApply: true --- SDE remediation — house rules Exposure scope — always classify first PRE-EXPOSURE: literal exists only in the current working tree, never committed to a shared remote, never printed in CI logs. EXPOSED: anything else. If in doubt, it's exposed. Exposed SDEs are rotation problems, not code-edit problems. For any EXPOSED finding: do NOT edit the offending file. Stop, create a triage branch, and write TRIAGE.md per the template below. Rotation happens first; code hygiene second. Pre-exposure remediation Replace the literal with a reference to the project's approved secret store (read docs/security/secrets.md to identify the client). For PII, route through the project's redaction helper (grep for redact(, maskpii, scrubPII). If the project has neither, stop and triage — do not invent one. For test fixtures containing real user data, replace with Faker-style synthetic values and comment the finding id. Minimal edit only. Never rename files, never reformat unrelated code. Regression guard Add a unit test or a scanner-config rule that fails if the literal reappears. Allowlist the synthetic-fixture path specifically (never a broad path allowlist). What you may NEVER do Rewrite git history (filter-repo, force-push, commit amends on anyone else's branch). Echo the SDE literal in commit messages, chat output, PR bodies, or logs. When referring to it, hash it. Commit or delete .env / credentials.json — those require a git filter-repo runbook + human sign-off. Merge your own PR. PR shape (pre-exposure path) Branch: fix/<finding-id>. Commit: fix(sec): remove <class> <finding-id>. Title: fix(sec): remove <class> from <file> (<finding-id>). Body: finding id, exposure scope = \"pre-exposure\", replacement pattern used, test pass evidence, one-line revert. Labels: security, sde-remediation. DRAFT. Never ready-for-review, never auto-merge. Triage template (exposed path) Write TRIAGE.md on a sde-triage/<finding-id> branch with YAML frontmatter including: findingid, sdeclass, exposurescope, firstseencommit, firstseendate; and body sections for: Rotation checklist (revoke, rotate, re-deploy, invalidate cached sessions). Disclosure checklist (IR ticket, service owner, legal routing). ~~~ .cursor/commands/remediate-sde.md Filename is the command name — no frontmatter required. ~~~markdown Remediate a single SDE finding Arguments (both optional): 1. Finding id (e.g. GITLEAKS-AWS-001, WIZ-SECRET-42931). 2. SDE class: secret, token, pii, pci, or phi. Infer everything else from the session: the repo root you're already in, the default branch (from the git remote), the approved secret store (from docs/security/secrets.md or SECURITY.md), the redaction helper (grep for it), and the test and lint commands (from the README, package.json scripts, or Makefile). If no finding id is provided AND no scanner MCP is wired in, discover a target yourself before touching code: Run the lightest-weight secret/PII scanner available, in this order: gitleaks detect --source . --no-banner, trufflehog filesystem . --json, detect-secrets scan --all-files, trivy fs --scanners secret .. Restrict to the WORKING TREE only — never scan commit history. Exposed SDEs are rotation problems, handled by the exposed-path branch of the rule. Pick the highest-confidence finding. Synthesize a local id: LOCAL-<scanner>-<rule>-<short-sha>. Classify the SDE class from the rule id (e.g. AWS-access-key → secret, email-in-logs → pii). Note in the PR body that the finding was self-discovered and which scanner produced it. If no scanner is installed, stop and post a summary in chat naming what to install — do not guess. Never grep for a secret literal yourself — leave pattern matching to the scanner so the literal never enters chat context. Using the house rules in .cursor/rules/remediate-sde.mdc: 1. Confirm the literal appears in the current working tree. If the chat message includes a file path + line, start there. If the literal isn't present, stop and summarize \"not-reproduced\". 2. Classify exposure scope. Run git log --all -S '<literal hash>' -- <file> to detect prior commits. NEVER echo the literal — refer to it by a hash only. Check the finding source: was it seen in CI logs or a public repo? Any of the above → EXPOSED. Otherwise PRE-EXPOSURE. 3. EXPOSED path: do not edit the file. Create sde-triage/<finding-id> branch, write TRIAGE.md per the rule's template, push, and summarize the rotation + disclosure checklist in chat. 4. PRE-EXPOSURE path: a. Pick the replacement pattern per the rule (secret store client for secrets/tokens; redaction helper for PII). b. Apply the minimal edit. Add a regression guard (unit test or scanner-config rule). c. Run lint and tests. If either fails because of the edit, revert and summarize. d. Open a DRAFT PR per the rule's PR shape. Do not mark ready-for-review. Whenever you need to refer to the SDE literal, use a hash or an abstract description. Never echo the value. ~~~ Invoke from chat with /remediate-sde WIZ-SECRET-42931 secret. From Cursor Automations, the same command is wired to the security:sde label trigger. Verification Rechecked 2026-08-21 against Cursor project rules, slash commands, and Automations triggers. Exposed SDEs still stop at rotation plus TRIAGE.md and never rewrite history or echo the literal. The command still opens a draft PR only on the pre-exposure path. Output contract Return one of: A draft PR for a pre-exposure SDE that applies the minimal source edit, references the approved secret store or redaction helper, adds a regression guard, records lint/test evidence, and follows the configured branch, title, body, and label shape. A triage branch and TRIAGE.md for exposed, stale, ambiguous, unsupported, binary, cross-repo, or no-approved-pattern findings. The output must list finding id, SDE class, exposure scope, file path, approved replacement pattern, scanner or MCP evidence source, tests run, PR/triage branch, and rotation/disclosure checklist when exposed. It must not echo the literal in chat, rewrite history, commit/delete secret files, broad-allowlist scanner rules, mark the PR ready for review, or merge the PR. Related recipes Sensitive Data Remediation Source-code secrets and data exposure audit Codex sensitive data remediation Known limitations Exposure detection is git-history-shaped. The git log -S heuristic can miss a secret that was renamed between commits; pair with the scanner's own \"first seen\" metadata when possible. Hashing literals in chat. Cursor's chat surface doesn't natively redact — the agent must remember to hash. Treat any copy-paste of chat transcripts as sensitive until you've verified the agent obeyed the rule. History cleanup is out of scope. That lives in a separate secret-rotation runbook; this prompt refuses to try. Redaction-helper detection relies on a grep list. Teams with non-obvious helper names should record them in docs/security/secrets.md so the rule can cite them. Changelog 2026-04-21 — v1, first published. Covers secret / token / pii / pci / phi. Exposed-SDE path deliberately refuses code edits and routes to rotation.","agent_handoff":{"mcp_lookup_keys":["sensitive-data-remediation","/recipes/cursor/sensitive-data-remediation/","recipes/cursor/sensitive-data-remediation.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["remediation","code-hygiene"],"source_text_field":"content_text","portable_download":"security-recipe-sensitive-data-remediation.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-sensitive-data-remediation.json"}},{"slug":"vulnerable-dep-remediation","title":"Cursor Vulnerable Dependency Remediation","link_title":"Vulnerable dep remediation","url":"https://security-recipes.ai/recipes/cursor/vulnerable-dep-remediation/","path":"/recipes/cursor/vulnerable-dep-remediation/","source_file":"recipes/cursor/vulnerable-dep-remediation.md","recipe_id":"","recipe_kind":"","category":{"slug":"cursor","label":"Cursor"},"agent":"cursor","severity":"unspecified","maturity":"development","ecosystem":"","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"","framework_version":"","jurisdiction":"","industry":[],"cve_archetypes":[],"cve_workflow_role":"","tags":["sca","cve","dependencies","cursor","rules","commands"],"facets":["remediation","risk","code-hygiene"],"quality":{"score":100,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context","multi-facet"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"Stephen M Abbott","team":"Security","model":"Opus 4.7","ai_assisted":false,"generated_by":"","date":"2026-04-21","zero_day":false,"last_updated":"2026-04-21","summary":"A Cursor project rule + custom slash command pair for remediating a vulnerable open-source dependency. The rule encodes the house constraints (conservative bumps only, one PR per finding, no auto-merge). The slash command is the one-line …","content_text":"A Cursor project rule + custom slash command pair for remediating a vulnerable open-source dependency. The rule encodes the house constraints (conservative bumps only, one PR per finding, no auto-merge). The slash command is the one-line trigger engineers invoke interactively — or that Cursor Automations invokes on a schedule / webhook. What this prompt does When an engineer runs /remediate-dep CVE-2026-1234 in Cursor's chat (or Cursor Automations invokes it on a schedule), the underlying Agent / Cloud Agent reads the finding, locates the affected package, applies the lowest-viable bump, runs the project's tests, and opens a PR scoped to that single finding. The rule file guarantees the constraints are applied on every invocation regardless of who typed the command. Inputs: the finding id (as the command argument), optional package hint in the chat body.<br/> Outputs: either a branch + draft PR (happy path), or a summary in chat + no commits (triage path). Cursor Cloud Agents surface the run in the sidebar for review. When to use it A developer already has Cursor open and wants to knock out a Dependabot / Snyk finding without leaving the editor. Cursor Automations is wired to a GitHub issue label (security:remediate) and needs a consistent command to invoke. Nightly Cloud Agent sweeps through the top-N open findings, opening up to 5 PRs per run. Don't use it for: Major version migrations — the rule refuses by default. Cross-repo fanouts — invoke per repo so the rule scope applies. Interactive \"is this CVE real\" triage conversations — those are human work; this command jumps to fix mode. Inputs Cursor chat arguments, issue labels, Dependabot/Snyk/OSV/GitHub Advisory or MCP finding context, affected package hint, advisory ID, severity, patched range, and direct/transitive dependency evidence. Project rule and command files: .cursor/rules/remediate-dep.mdc, .cursor/commands/remediate-dep.md, Cursor Automation triggers, and repo house rules for branches, draft PRs, labels, and reviewers. Repository evidence: manifests, lockfiles, package-manager choice, workspace layout, default branch, CODEOWNERS, generated dependency reports, SBOMs, and package-manager lockfile behavior. Verification evidence: lint/test commands, scanner availability, re-scan output, package-manager update logs, failing test output, and revert command. Triage evidence for no-discovery-tooling, package-not-installed, major bump, prerelease-only, ambiguous patched range, yanked version, lint regression, test regression, and monorepo workspace ownership. The prompt Two files, checked in to the repo. .cursor/rules/remediate-dep.mdc ~~~markdown --- description: > Conservative vulnerable-dep remediation house rules. Applies whenever the agent is asked to bump a dep in response to a CVE or advisory id. globs: \"package.json\" \"pnpm-lock.yaml\" \"package-lock.json\" \"yarn.lock\" \"go.mod\" \"go.sum\" \"requirements.txt\" \"uv.lock\" \"poetry.lock\" \"Cargo.toml\" \"Cargo.lock\" \"Gemfile\" \"Gemfile.lock\" --- Vulnerable dependency remediation — house rules Scope ONE finding per run. One commit. One PR. No bundling. Branch: fix/<finding-id> (use the CVE / GHSA id verbatim). Commit: Conventional Commits: fix(sec): bump <pkg> from <old> to <new> (<finding-id>). Version bump policy Always pick the LOWEST version in the advisory's patched range. NEVER cross a major-version boundary unless the user has explicitly written \"major ok\" in the task brief. For transitive-only fixes, prefer bumping the direct parent to pull in the patched transitive. If both options require a major bump, stop and explain — do not guess. Pre-release / rc / beta versions are off by default. If the advisory only lists a pre-release fix, stop and triage. Verification Use the NATIVE package manager to apply the bump; never hand-edit the lockfile. After the bump: run the repo's lint and test commands. Look for pnpm test, make test, go test ./..., uv run pytest, cargo test, bundle exec rspec — whichever the repo uses. If lint or tests fail because of the bump, REVERT the bump and summarize what failed. Do not try to fix the test. If a scanner (osv-scanner, grype, trivy fs) is available, re-scan to confirm the finding is gone. What you may NOT touch Anything outside the manifest and its lockfile, except where the package manager rewrites a peer file (e.g. go.sum after go mod tidy). Any file under db/migrations/ or infra/terraform/. Generated files (/.generated.). CI workflows, except to change a pinned action version in response to a CVE on that action. PR shape Title: fix(sec): bump <pkg> to <ver> (<finding-id>). Body: finding id + link, old → new version, direct/transitive, test command + pass evidence, one-line revert instructions. Labels: security, auto-remediation. DRAFT PR. Never mark ready-for-review. Never auto-merge. ~~~ .cursor/commands/remediate-dep.md Filename is the command name — no frontmatter required. ~~~markdown Remediate a single vulnerable dependency Argument (optional): a CVE id or GHSA id (e.g. CVE-2026-1234, GHSA-xxxx-xxxx-xxxx). Infer everything else from the session: the repo root you're already in, the default branch (from the git remote), the test and lint commands (from package.json scripts, Makefile targets, or the README). If no finding id is provided AND no scanner MCP is wired in, discover a target yourself before touching code: Run the lightest-weight local scanner available, in this order: osv-scanner scan source ., npm audit --json, pip-audit, govulncheck ./..., cargo audit, bundle audit, trivy fs --scanners vuln .. If none are available, query the GitHub Advisory Database via gh api /repos/{owner}/{repo}/vulnerability-alerts or the public advisories endpoint using package names from the manifests. Pick the highest-severity fixable finding per the rules below. Note in the PR body that the finding was self-discovered and which scanner produced it. If no discovery tooling is available, stop and post a summary in chat naming what to install — do not guess. Using the house rules in .cursor/rules/remediate-dep.mdc: 1. Fetch the advisory details from the GitHub Advisory Database (or OSV if the GHSA isn't available there yet). Record the affected package, affected range, and patched range. 2. Locate the affected package in this repo's resolved dependency tree (direct AND transitive). If not installed, stop and summarize \"not-vulnerable: package not installed\". 3. Pick the lowest version in the patched range. If it crosses a major boundary, refuse per the rule file and summarize why. 4. Apply the bump via the native package manager. Commit once. 5. Run lint and tests. If either fails because of the bump, revert and summarize the failure. 6. Open a DRAFT pull request per the rule file's PR shape. Link the advisory in the PR body. Do not mark ready-for-review. If any of 1–5 require human judgment (ambiguous patched range, major bump required, pre-release only, yanked version), stop and post a structured summary in chat instead of committing. ~~~ Invoke from chat with /remediate-dep CVE-2026-1234. In Cursor Automations, the same command is the entry point for scheduled sweeps and issue-labeled triggers. Output contract Return one of: A draft PR that remediates one advisory-driven dependency path, uses the native package manager, touches only manifest and lockfile artifacts, records tests and re-scan evidence, and follows the configured branch, title, body, labels, and draft-review policy. A structured chat/triage summary when the package is not installed, no discovery tooling exists, the fix requires a disallowed major bump, only a prerelease is available, the range is ambiguous, the version is yanked, or lint/tests fail because of the bump. The output must list finding id, package, ecosystem, old/new version, patched range, direct/transitive status, package manager, files touched, test and scanner evidence, PR URL or triage reason, and next owner. It must not edit application code, skip tests, mark the PR ready for review, auto-merge, or bundle multiple findings. Related recipes Vulnerable Dependency Remediation Codex vulnerable dependency remediation Source-code supply chain build integrity audit Known limitations Rule-scope globs must match the manifests actually touched; if your repo uses an unusual layout (e.g. manifests under tooling//) extend the globs: list so the rule loads. Multi-ecosystem repos. The command is fine for one ecosystem per run. For monorepos with mixed Node/Python/Go, run one invocation per affected workspace. Draft-PR policy is enforced by the rule, not by the PR API. Pair it with a repo-level branch protection that blocks merges from @cursor[bot]-authored PRs until a human reviewer approves. Cloud Agent context budget.** Very large monorepos can push the agent past its retrieval budget. Pin the .cursor/mcp.json allowlist to only the MCP tools this flow needs. Changelog 2026-04-21 — v1, first published. Covers Node / Python / Go / Rust / Ruby. Monorepo fanout handled by invoking per-workspace.","agent_handoff":{"mcp_lookup_keys":["vulnerable-dep-remediation","/recipes/cursor/vulnerable-dep-remediation/","recipes/cursor/vulnerable-dep-remediation.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["remediation","risk","code-hygiene"],"source_text_field":"content_text","portable_download":"security-recipe-vulnerable-dep-remediation.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-vulnerable-dep-remediation.json"}},{"slug":"cve-2014-0160-heartbleed","title":"CVE-2014-0160 — Heartbleed","link_title":"CVE-2014-0160 Heartbleed","url":"https://security-recipes.ai/recipes/cve/cve-2014-0160-heartbleed/","path":"/recipes/cve/cve-2014-0160-heartbleed/","source_file":"recipes/cve/historical/cve-2014-0160-heartbleed.md","recipe_id":"","recipe_kind":"","category":{"slug":"cve","label":"CVE"},"agent":"general","severity":"critical","maturity":"stable","ecosystem":"openssl/system","cve":"CVE-2014-0160","ghsa":"","kev":true,"aliases":["Heartbleed"],"framework":"","framework_version":"","jurisdiction":"","industry":[],"cve_archetypes":[],"cve_workflow_role":"","tags":["cve","openssl","tls","memory-disclosure","key-rotation"],"facets":["remediation","risk"],"quality":{"score":95,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"Stephen M Abbott","team":"Security","model":"Opus 4.7","ai_assisted":false,"generated_by":"","date":"2026-04-25","zero_day":false,"last_updated":"2026-04-25","summary":"OpenSSL heartbeat-extension memory disclosure. Patching is necessary but not sufficient — rotate every key and revoke every cert from the exposure window.","content_text":"A missing length check in OpenSSL's TLS heartbeat extension let an attacker request up to 64KB of process memory per heartbeat — keys, session tokens, decrypted plaintext, anything the OpenSSL process happened to have in its address space. The \"we patched it\" announcement is what most people remember; the durable lesson is that patching wasn't the fix. Rotating every key and revoking every cert that lived through the vulnerable window was the fix. A decade later this is still the most-cited reason post-incident playbooks demand key rotation, not just patching. CISA added CVE-2014-0160 to the Known Exploited Vulnerabilities catalog on 2022-05-04 (required action due 2022-05-25). Rechecked against that CISA KEV JSON entry on 2026-08-21; the OpenSSL 1.0.1–1.0.1f affected range and 1.0.1g+ patch are unchanged. Affected versions OpenSSL 1.0.1 through 1.0.1f — vulnerable. OpenSSL 1.0.1g+ — patched. OpenSSL ≤1.0.0 / ≥1.0.2 — not affected. LibreSSL, BoringSSL, Java's JSSE, Go's crypto/tls, Microsoft Schannel — not affected (different stacks). Indicator-of-exposure The system was exposed if it ran OpenSSL in the affected range and had the heartbeat extension enabled (the default for affected versions). Detection commands: openssl version or, for an installed binary: strings /usr/bin/openssl | grep -i 'OpenSSL 1\\.0\\.1' For services: any TLS-terminating daemon (HTTPS server, mail server, VPN) compiled against affected OpenSSL was exposed. A heartbeat scan (openssl sclient -connect host:443 -tlsextdebug | grep heartbeat) confirms whether the server still negotiated the extension. This CVE is over a decade old. Any system still in the affected range today is also missing a decade of unrelated patches; treat the finding as a tip-of-the-iceberg signal, not just a single-CVE fix. Remediation strategy Upgrade to a current OpenSSL (the 3.x branch by 2026). 1.0.1g was the immediate patch; the durable answer is current. Disable the TLS heartbeat extension in any service that doesn't actively use it (most don't). Defence-in-depth. Rotate every private key, session secret, API token, and password whose plaintext could have been in the process memory of an affected daemon during the exposure window. Revoke every TLS certificate generated using a private key that was on an affected host. Audit for unexplained authentication sessions during the exposure window. For systems running OpenSSL 1.0.1 today: this is not a single-CVE fix. The right shape is a runtime upgrade. Treat this recipe as the trigger; the workflow is broader. When to use it Use this recipe when a host, container image, appliance, embedded service, runtime bundle, or TLS-terminating application may run OpenSSL 1.0.1 through 1.0.1f, statically link affected OpenSSL, or carry a legacy libssl in a language/runtime distribution. It is most important when the service was network-exposed during the vulnerable window or held TLS keys, session secrets, tokens, or plaintext user data in process memory. Use it to separate the package/runtime upgrade from the required incident response work: key rotation, certificate revocation, session invalidation, secret rotation, service restart, and exposure-window audit. Do not use it as a routine dependency bump when exposure is confirmed. Inputs Host inventories, container images, SBOMs, base-image manifests, package locks, runtime bundles, statically linked binaries, TLS service manifests, load balancer/proxy config, VPN/mail/web server config, and deployment runbooks. OpenSSL version evidence from package managers, openssl version, linked libssl, strings output, image scans, SCA/SBOM reports, and appliance or vendor advisories. Exposure evidence: public/internal network reachability, heartbeat-extension scan results, service start/stop history, patch timing, affected daemon list, log retention, certificate/key locations, and session/token lifetimes. Operator-owned secrets reachable by affected processes: TLS private keys, certificates, session signing/encryption keys, API tokens, database passwords, OAuth client secrets, build credentials, and cached sessions. Change-control and IR constraints for service restarts, key rotation, certificate reissue/revocation, CRL/OCSP propagation, global logout, and artifact rebuilds. The prompt ~~~markdown You are remediating CVE-2014-0160 (Heartbleed) on this host or in this system image. Output exactly one of: A PR / change request upgrading the OpenSSL runtime, plus an incident-response checklist for the operator. A TRIAGE.md if the host has been running an affected OpenSSL with public exposure for an extended period. This recipe is not a routine package bump. If exposure is confirmed, do not auto-remediate; produce the incident checklist and stop. Step 0 — Detect 1. Read the OpenSSL version: openssl version. Read every service binary's linked OpenSSL: ldd <binary> | grep ssl, then strings <libssl> | grep -i 'OpenSSL 1\\\\.0\\\\.'. 2. For every TLS-terminating service on the host (HTTPS server, mail, VPN, internal RPC), test for the heartbeat extension: openssl sclient -connect host:port -tlsextdebug 2>&1 | grep -i heartbeat. 3. Determine the host's exposure window (when the affected OpenSSL was first installed; when network-exposed services using it were started). Step 1 — Classify Never network-exposed during exposure window: Upgrade the package, rotate any local keys, document. Network-exposed during exposure window: Treat as compromised. Write the IR checklist; do not auto-remediate the keys; only the package upgrade is in scope for the agent. Step 2 — Upgrade 1. For modern distros, upgrade via the package manager: apt upgrade openssl libssl3 libssl1.1 libssl1.0.0, dnf upgrade openssl openssl-libs, etc. — to the current 3.x branch on systems that support it. 2. Restart every service that links the upgraded OpenSSL. The agent lists the services to restart in the PR body; the operator runs the restart. 3. Re-run the heartbeat detection from Step 0 against every service. The extension should be absent or harmless on patched OpenSSL. Step 3 — Disable the heartbeat extension (defence-in-depth) For any TLS-terminating service that does not use heartbeats: nginx, Apache, HAProxy, etc. — set the OpenSSL ciphers list / disable heartbeats per the service's configuration. Most modern configs already exclude it. Step 4 — IR checklist (for compromised classification) The TRIAGE.md must include: Rotate every TLS private key on the host. Revoke and re-issue every certificate generated from those keys. Confirm CRL / OCSP propagation. Rotate every long-lived secret accessible from the compromised process: DB passwords, API keys, OAuth client secrets, session-encryption keys. Invalidate every session token that pre-dates the rotation. Audit the auth logs for unexplained sessions during the exposure window. Rebuild any artefacts produced on the host during the window if the build process touched secrets. Stop conditions The system runs an OpenSSL old enough to indicate broader patching gaps. Triage with a recommendation for a comprehensive runtime upgrade, not just OpenSSL. A service depends on the heartbeat extension for a real reason (rare). Document and triage. The host's exposure window is unclear from available logs. Triage. Scope Do not rotate keys or revoke certs — those are operator actions on the IR checklist. Do not modify TLS configurations outside the documented defence-in-depth scope. Do not bundle unrelated CVE fixes. ~~~ Rollback and recovery Do not restore an affected OpenSSL release, exposed private key, revoked certificate, invalidated session, or rotated secret. If the selected supported OpenSSL release causes a compatibility failure, keep the affected service contained and move to another vendor-supported, non-vulnerable release or a known-good rebuilt image. A configuration rollback must still load the patched library and retain heartbeat containment. Preserve the exposure timeline, old certificate fingerprints, revocation receipts, rotation receipts, service restart evidence, and audit logs for incident review. Key rotation and certificate revocation are security state transitions, not application changes to reverse during routine rollback. Verification — what the reviewer looks for The OpenSSL runtime version after upgrade is on the current 3.x branch (or the distro's currently-supported branch). Every service listed in the PR was restarted. The heartbeat scan shows the extension absent or harmless on every service. For compromised classification: the IR checklist was followed end-to-end. A package upgrade alone is not sufficient. The PR includes an honest assessment of the exposure window and the artefacts/services that depended on potentially-leaked secrets. Watch for Statically-linked OpenSSL. A package upgrade doesn't fix a service that bakes its own OpenSSL into a static binary. Identify and rebuild every such binary. Bundled OpenSSL in language runtimes. Older Python / Ruby / Node distributions sometimes ship their own OpenSSL. Upgrade the runtime, not just the system package. Long-lived sessions. A web session minted during the exposure window could still be active. Force a global re-login if the application's session lifetime is long. Certificate revocation in practice. CRLs and OCSP can be slow. Many clients ignore revocation entirely. The durable defence is short-lived certs (ACME with renewal), not relying on revocation propagation. Internal services. Heartbleed exposure on an internal service is still exposure. \"Behind the firewall\" is not a control if any compromised internal client could have scanned. Output contract Return one of: A reviewer-ready PR/change request that upgrades the controlled OpenSSL runtime or image, identifies every affected TLS-terminating service, lists restart requirements, verifies heartbeat exposure is absent or harmless after patching, and attaches an operator incident-response checklist. TRIAGE.md when network exposure is confirmed or unclear, an affected statically linked/runtime-bundled OpenSSL cannot be patched in this repository, a broader unsupported-runtime upgrade is required, or key/cert rotation and exposure-window analysis must precede code changes. The output must list affected OpenSSL versions, services, images or binaries, exposure window, network reachability, restart plan, heartbeat validation, keys/certs/secrets requiring rotation, certificates requiring revocation, and sessions/artifacts requiring invalidation or rebuild. It must not claim a package upgrade alone fixes exposed Heartbleed, rotate production keys without operator approval, or bundle unrelated CVE upgrades. References NVD: <https://nvd.nist.gov/vuln/detail/CVE-2014-0160> CVE record: <https://www.cve.org/CVERecord?id=CVE-2014-0160> CISA KEV catalog entry: <https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2014-0160> Related recipes Vulnerable Dependency Remediation — generic CVE workflow. Base Image & Container Layer Remediation — when OpenSSL is in a container base image.","agent_handoff":{"mcp_lookup_keys":["cve-2014-0160-heartbleed","/recipes/cve/cve-2014-0160-heartbleed/","recipes/cve/historical/cve-2014-0160-heartbleed.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["remediation","risk"],"source_text_field":"content_text","portable_download":"security-recipe-cve-2014-0160-heartbleed.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-cve-2014-0160-heartbleed.json"}},{"slug":"cve-2014-6271-shellshock","title":"CVE-2014-6271 — Shellshock","link_title":"CVE-2014-6271 Shellshock","url":"https://security-recipes.ai/recipes/cve/cve-2014-6271-shellshock/","path":"/recipes/cve/cve-2014-6271-shellshock/","source_file":"recipes/cve/historical/cve-2014-6271-shellshock.md","recipe_id":"","recipe_kind":"","category":{"slug":"cve","label":"CVE"},"agent":"general","severity":"critical","maturity":"stable","ecosystem":"bash/system","cve":"CVE-2014-6271","ghsa":"","kev":true,"aliases":["Shellshock","Bashdoor","CVE-2014-7169","CVE-2014-6277","CVE-2014-6278","CVE-2014-7186","CVE-2014-7187"],"framework":"","framework_version":"","jurisdiction":"","industry":[],"cve_archetypes":[],"cve_workflow_role":"","tags":["cve","bash","rce","linux","cgi"],"facets":["remediation","audit","risk"],"quality":{"score":100,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context","multi-facet"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"Stephen M Abbott","team":"Security","model":"Opus 4.7","ai_assisted":false,"generated_by":"","date":"2026-04-25","zero_day":false,"last_updated":"2026-04-25","summary":"Bash function-export parser RCE — and the five sibling CVEs that came with it. Upgrade Bash through every patch level; audit CGI / DHCP / SSH-hook surfaces.","content_text":"Bash supported exporting functions through environment variables. The export syntax — () { …; } — was parsed by any newly-spawned bash process on import. A trailing semicolon let the imported \"function\" body include arbitrary commands. Any process boundary that turned untrusted input into a bash environment variable became RCE. The classic target was modcgi: HTTP headers became env vars; bash was the CGI interpreter; game over. The first patch was incomplete; the durable fix runs through six follow-up CVEs. CISA added CVE-2014-6271 to the Known Exploited Vulnerabilities catalog on 2022-01-28 (required action due 2022-07-28). Rechecked against that CISA KEV JSON entry on 2026-08-21. Affected versions Bash 1.14 through 4.3 (with various patch levels) — vulnerable. The fix shipped in patch levels: bash-3.2.53, bash-4.1.14, bash-4.2.50, bash-4.3.27, plus follow-up patches for the five sibling CVEs. Modern Bash (5.x) — clean. Indicator-of-exposure Detection is simple but the surface is wide: The classic detection one-liner (CVE-2014-6271): env x='() { :; }; echo VULNERABLE' bash -c 'true' The follow-up (CVE-2014-7169): env X='() { (a)=>\\\\' bash -c 'echo date'; cat echo If the first prints VULNERABLE or the second produces a file named echo containing the date, the bash on this host has not been fully patched. The exposure that matters is any process boundary that maps untrusted input into a Bash environment: Apache modcgi / modcgid invoking a #!/bin/bash CGI script. DHCP clients that pass server-supplied options into a Bash hook script. Forced-command SSH configs that run a Bash wrapper. Setuid wrappers that drop into Bash. Container entrypoints that re-exec Bash with attacker- controlled env. Remediation strategy Upgrade Bash to a current 5.x release, or to the patch level that includes the fix for all of the Shellshock-family CVEs (-6271, -7169, -6277, -6278, -7186, -7187). Do not stop at the first one. Audit every CGI / DHCP-hook / setuid wrapper / SSH forced-command surface for use of Bash. Replace #!/bin/bash with #!/bin/dash (or /bin/sh if Debian-family) where the script doesn't need Bash features. Disable modcgi and modcgid in any web server that doesn't need them. Re-audit the system as a whole. Shellshock exposure on a host today implies a multi-year patching gap; the incident response is broader than one CVE. When to use it Use this recipe when a host, container image, appliance, embedded Linux image, CGI stack, DHCP client hook, SSH forced-command wrapper, or shell-based entrypoint may run vulnerable Bash or process untrusted environment variables. It is especially important when the system is old enough that Shellshock still appears in SCA, image, or host scans. Use it to separate Bash patching from exposed-surface review and incident response. Do not use it as a one-line package bump when CGI, DHCP, SSH hooks, or container entrypoints can map untrusted input into Bash. Inputs Host inventories, container images, SBOMs, base-image manifests, package locks, distro advisories, Bash versions, CGI configs, Apache modules, DHCP hook directories, NetworkManager dispatchers, SSH authorized-key commands, setuid wrappers, and Docker entrypoints. Detection evidence for CVE-2014-6271, CVE-2014-7169, CVE-2014-6277, CVE-2014-6278, CVE-2014-7186, and CVE-2014-7187. Exposure evidence: public CGI routes, DHCP trust boundary, SSH wrapper use, setuid scripts, container env sources, web/DHCP/auth logs, affected package timing, and whether the distro is supported. Script compatibility evidence before replacing Bash shebangs: Bashisms, tests, runtime owners, migration complexity, and dependency on modcgi. Operator actions for credential rotation, log review, runtime upgrade, and broader patch-gap remediation. The prompt ~~~markdown You are remediating Shellshock and its sibling CVEs on this host or system image. Output exactly one of: A PR / change request upgrading bash and tightening the exposed CGI / DHCP / SSH-hook surface, plus an IR checklist for the operator. A TRIAGE.md if the host's patching gap is broader than this CVE family. Step 0 — Detect 1. Read bash version: bash --version. 2. Run all six Shellshock detection one-liners (or pull a detection script from a trusted source). Confirm none print the canary string. 3. Identify Bash-using boundaries: find / -name '.cgi' -exec head -1 {} \\\\; | grep bash DHCP hook scripts under /etc/dhcp / /etc/NetworkManager/dispatcher.d. SSH authorizedkeys command= forced commands. Container entrypoints that re-exec Bash. Step 1 — Upgrade Bash 1. apt upgrade bash / dnf upgrade bash to the distro's current packaged version. 2. Re-run all six detection one-liners. None should fire. Step 2 — Tighten exposed surfaces For every Bash-using boundary identified in Step 0: CGI scripts: if the script doesn't need Bash features (associative arrays, [[-tests, process substitution), switch the shebang to /bin/dash or /bin/sh. If it does need Bash, keep Bash but document the exposure. modcgi / modcgid: disable in httpd.conf / apache2.conf if the application can serve via FastCGI, PHP-FPM, or a modern WSGI / ASGI stack instead. DHCP hooks: review for shell injection on server-controlled fields. The agent doesn't auto-rewrite these — flag for triage. SSH forced commands: audit the wrapper script; prefer a non-shell binary or a tightly-controlled allowlist. Step 3 — IR checklist (when patching gap is broader) The TRIAGE.md must include: Confirm host distro is supported and currently patched. Rotate any credentials that ran through the exposed surface (CGI auth tokens, DHCP-distributed secrets). Audit web logs and DHCP logs for known Shellshock exploitation patterns: User-Agent: () { :; };, Referer: () { :; };, etc. Schedule a comprehensive runtime upgrade. Stop conditions Distro is end-of-life and no patched bash is available. Triage with a recommendation to migrate. A CGI script genuinely depends on Bash and the migration to FastCGI/WSGI is non-trivial. Flag and triage. The host's auth log shows unexplained sessions during the exposure window — this is incident response, not routine remediation. Scope Do not rewrite CGI scripts beyond the shebang change. Do not disable modcgi if a legitimate application depends on it; flag for triage instead. Do not bundle unrelated CVE fixes. ~~~ Rollback and recovery Never roll back to a Bash package that fails any Shellshock-family detection check. If a shebang change, CGI-module removal, or wrapper hardening breaks a required workflow, revert only that non-security change while retaining the patched Bash release and the strongest available containment around the exposed boundary. Choose another supported patched package or rebuilt image if the first upgrade is incompatible. Preserve before/after Bash versions, package artifacts, six-CVE test results, surface inventory, logs, and operator actions. Any credentials rotated after suspected exposure remain rotated; recovery must not restore compromised secrets or reopen public CGI, DHCP, or SSH-hook access by default. Verification — what the reviewer looks for All six Shellshock-family detection one-liners pass after the upgrade. The Bash-using boundary list in the PR body is complete and accurate (re-grep to confirm). For surfaces where Bash was replaced with dash / sh, the script's tests still pass — Bashisms ([[, ==, array syntax) are the common breakers. The reviewer does not assume the absence of modcgi is the same as the absence of all Bash-CGI surfaces. Watch for Single-CVE patching. Many vendor advisories shipped a fix for -6271 days before -7169. A host patched against only the first is still exploitable. Test all six. Bash on Alpine. Alpine's default shell is ash, but containers that explicitly install bash inherit the same exposure. Audit Dockerfiles. Container entrypoints. A CMD [\"/bin/bash\"] with attacker-controlled env (e.g., from an upstream input) re-creates the same surface inside a container. The generic remediation is to replace the entrypoint with a non-shell binary. OS images that aren't actively patched. Shellshock exposure on a host in 2026 is a tip-of-the-iceberg signal. The recipe says so; don't treat the bash bump as the end of the conversation. Proxies and load-balancers. Some appliances embed older Bash. The same shape applies; the fix path is the appliance vendor's, not the host's. Output contract Return one of: A reviewer-ready PR/change request that upgrades Bash through all Shellshock sibling fixes, inventories Bash-using exposure boundaries, safely replaces Bash with a smaller shell where tests prove compatibility, disables unused CGI modules where owned, and attaches operator IR actions. TRIAGE.md when the distro is end-of-life, the host has broader patching gaps, a Bash-dependent CGI migration is non-trivial, logs indicate possible compromise, or exposed-surface ownership is outside the repository. The output must list Bash version, six-CVE detection results, exposed boundaries reviewed, shebang or module changes, tests run, log-review queries, credentials or surfaces requiring rotation, and runtime-upgrade owner. It must not rewrite CGI scripts beyond scoped shebang/module changes, disable required CGI functionality, or bundle unrelated CVEs. References NVD: <https://nvd.nist.gov/vuln/detail/CVE-2014-6271> CVE record: <https://www.cve.org/CVERecord?id=CVE-2014-6271> CISA KEV catalog entry: <https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2014-6271> Related recipes Base Image & Container Layer Remediation — for evicting old Bash from container bases. Vulnerable Dependency Remediation — generic CVE workflow.","agent_handoff":{"mcp_lookup_keys":["cve-2014-6271-shellshock","/recipes/cve/cve-2014-6271-shellshock/","recipes/cve/historical/cve-2014-6271-shellshock.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["remediation","audit","risk"],"source_text_field":"content_text","portable_download":"security-recipe-cve-2014-6271-shellshock.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-cve-2014-6271-shellshock.json"}},{"slug":"cve-2017-18342-pyyaml","title":"CVE-2017-18342 — PyYAML default `load` resolves arbitrary tags","link_title":"CVE-2017-18342 PyYAML","url":"https://security-recipes.ai/recipes/cve/cve-2017-18342-pyyaml/","path":"/recipes/cve/cve-2017-18342-pyyaml/","source_file":"recipes/cve/historical/cve-2017-18342-pyyaml.md","recipe_id":"","recipe_kind":"","category":{"slug":"cve","label":"CVE"},"agent":"general","severity":"critical","maturity":"stable","ecosystem":"python/pypi","cve":"CVE-2017-18342","ghsa":"","kev":false,"aliases":["PyYAML default Loader RCE"],"framework":"","framework_version":"","jurisdiction":"","industry":[],"cve_archetypes":[],"cve_workflow_role":"","tags":["cve","pyyaml","deserialization","python"],"facets":["remediation","risk","code-hygiene"],"quality":{"score":100,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context","multi-facet"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"Stephen M Abbott","team":"Security","model":"Opus 4.7","ai_assisted":false,"generated_by":"","date":"2026-04-25","zero_day":false,"last_updated":"2026-04-25","summary":"`yaml.load` resolved arbitrary Python tags by default. Replace with `safe_load` and pin PyYAML ≥ 6.0 where the unsafe default was finally removed.","content_text":"PyYAML's yaml.load() resolved !!python/object and friends without an explicit safe loader, making any attacker-controlled YAML a code-execution primitive. The CVE is the formal advisory; the behaviour predates the CVE by the better part of a decade. PyYAML 5.1 added a deprecation warning when Loader= was omitted; PyYAML 6.0 made the omission a TypeError. Most repos have call sites that predate either change. Rechecked against the CISA KEV JSON on 2026-08-21; CVE-2017-18342 is still not listed. The 5.1 warning and 6.0 TypeError behavior remain the remediation landmarks. Affected versions PyYAML ≤ 3.13 — vulnerable, no warning. PyYAML 4.x — never released widely. PyYAML 5.1+ — emits a YAMLLoadWarning when Loader= is omitted; still resolves unsafe tags by default. PyYAML 6.0+ — yaml.load() raises TypeError without an explicit Loader. The behaviour was made safe by removal. Indicator-of-exposure Any call site of yaml.load(...) (without Loader=), yaml.load(..., Loader=yaml.Loader), yaml.load(..., Loader=yaml.UnsafeLoader), or yaml.fullload(...) on untrusted input. Detection: git grep -n \"yaml\\\\.load\\\\b\\\\|yaml\\\\.fullload\\\\b\\\\|Loader=yaml\\\\.\\\\(Loader\\\\|UnsafeLoader\\\\|FullLoader\\\\)\" Whether the call is exposed depends on the data flow: attacker-controlled YAML (file upload, HTTP body, partner feed) is exposure; a trusted application config file is not — though the safe shape costs nothing on trusted input either. Remediation strategy This CVE has a generic recipe that covers it directly: See Classic Vulnerable Defaults → PyYAML yaml.load for the durable fix pattern. This per-CVE recipe overlays the broader generic recipe with two CVE-specific actions: 1. Pin PyYAML to ≥6.0 (or ≥5.1 with Loader=yaml.SafeLoader on every call) to lock in the safe-default behaviour at the library level. 2. Re-scan with the SCA tool to confirm CVE-2017-18342 is no longer reported against the post-fix lockfile. When to use it Use this recipe when Python code depends on PyYAML and parses YAML from uploads, HTTP bodies, partner feeds, CI config, user-edited files, model/tool output, or other untrusted sources. It is also useful for repositories with older yaml.load, yaml.fullload, custom loaders, or wrappers around PyYAML. Use it to combine code-level deserialization remediation with the CVE-specific dependency pin and SCA proof. Do not use it to silently replace custom YAML tag handling without a behavior-preservation review. Inputs Python manifests, lockfiles, constraints, dependency reports, SBOMs, PyYAML version evidence, SCA findings, and package-manager update commands. Call sites for yaml.load, yaml.loadall, yaml.fullload, yaml.fullloadall, unsafe Loader= values, wrappers, helper functions, and custom constructors or resolvers. Data-flow evidence for YAML sources: uploads, API bodies, partner feeds, config files, CI files, model output, tool output, MCP responses, tests, fixtures, and trusted internal config. Existing tests, custom YAML tag behavior, parser compatibility constraints, transitive dependencies that pin PyYAML, and scanner re-scan evidence. Related deserialization controls for pickle, object tags, import-time shims, and safe loader policies. The prompt ~~~markdown You are remediating CVE-2017-18342 (PyYAML default-loader RCE) in this repository. Output a PR or a TRIAGE.md. Step 0 — Inventory 1. List every yaml.load, yaml.fullload, yaml.load(..., Loader=yaml.Loader), yaml.load(..., Loader=yaml.UnsafeLoader), yaml.load(..., Loader=yaml.FullLoader) call. 2. Read the lockfile and confirm the pinned PyYAML version. Step 1 — Apply the generic fix pattern Follow the recipe at [/recipes/general/classic-vulnerable-defaults/pyyaml-load/] end-to-end. Replace every unsafe call with yaml.safeload, or install the import-time shim, or both. Step 2 — Pin PyYAML 1. Pin PyYAML to ≥6.0 in the lockfile / requirements file. 2. Run the project's test suite to surface any breakage from the 5.x → 6.x bump. 3. If the project depends on a transitive consumer of PyYAML <6 (pip-tools resolves a downgrade), document the constraint in the PR body. The agent does not silently downgrade. Step 3 — Verify 1. Re-run the SCA scanner. CVE-2017-18342 must show as fixed or not present. 2. Add the standard PyYAML safe-load test from the generic recipe (a payload with !!python/object/apply:os.system raises yaml.constructor.ConstructorError). Step 4 — Open the PR Branch: remediate/cve-2017-18342-pyyaml. Title: [Security][CVE-2017-18342] safeload + pin PyYAML ≥6. Body: per-call-site list, lockfile diff, SCA before/after, test addition, any downstream pin notes. Label: sec-auto-remediation. Stop conditions A transitive dependency requires PyYAML <6 and cannot be upgraded without a coordinated cross-repo change. A custom YAML tag the codebase legitimately uses requires a non-Safe loader and the agent cannot determine whether the tag's resolver is itself safe. Scope Do not bundle unrelated CVEs. Do not silently re-pin downstream constraints. ~~~ Rollback and recovery Do not restore an unsafe yaml.load path on untrusted input or downgrade to a PyYAML release below the approved patched line. If SafeLoader or PyYAML 6.x breaks a legitimate custom tag, keep untrusted YAML disabled or isolated and add a narrowly reviewed compatibility adapter or explicit safe constructor. Do not recover compatibility by reinstating Loader, UnsafeLoader, or FullLoader for attacker-controlled data. Preserve the pre-change lockfile, affected call-site inventory, exploit-shaped fixture, SCA output, and parser-compatibility failures. A code rollback may restore unrelated behavior, but it must retain the safe loader boundary and a non-vulnerable dependency resolution. Verification — what the reviewer looks for Every call site touched, or shim installed, with a clear rationale per call. PyYAML pinned to ≥6.0. SCA output shows CVE-2017-18342 cleared. Behaviour-preservation test for any custom YAML tag the codebase uses. Watch for yaml.loadall and yaml.fullloadall. Same problem, same fix. Indirect callers. Some libraries ship their own yaml.load(...) wrapper — fix the library or pin it past the patched version. PyYAML 6.x parser changes. A handful of edge-case documents parse differently in 6.x (octal-number rules, some boolean shortcuts). Run the project's tests. Output contract Return one of: A reviewer-ready PR/change request that inventories every unsafe PyYAML call, replaces it with safeload or a justified safe loader/shim, pins PyYAML to 6.0+ where compatible, adds exploit-shaped tests, runs the suite, and refreshes SCA evidence. TRIAGE.md when a transitive dependency requires PyYAML <6, a custom YAML tag needs a non-Safe loader whose resolver cannot be reviewed safely, or the required fix needs a coordinated cross-repo change. The output must list call sites, data sources, loader choice, PyYAML before/after version, lockfile changes, tests added, SCA before/after, custom tag behavior, and residual owners. It must not silently downgrade constraints, leave unsafe loaders on untrusted input, or bundle unrelated CVEs. References NVD: <https://nvd.nist.gov/vuln/detail/CVE-2017-18342> GitHub Advisory: <https://github.com/advisories/GHSA-rprw-h62v-c2w7> Related recipes Classic Vulnerable Defaults → PyYAML yaml.load — the durable, tool-agnostic recipe this overlays. Vulnerable Dependency Remediation — the generic workflow. Python pickle — sibling Python deserialization risk.","agent_handoff":{"mcp_lookup_keys":["cve-2017-18342-pyyaml","/recipes/cve/cve-2017-18342-pyyaml/","recipes/cve/historical/cve-2017-18342-pyyaml.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["remediation","risk","code-hygiene"],"source_text_field":"content_text","portable_download":"security-recipe-cve-2017-18342-pyyaml.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-cve-2017-18342-pyyaml.json"}},{"slug":"scheduled-sde-remediation","title":"Devin Scheduled Sensitive Data Remediation","link_title":"Scheduled SDE remediation","url":"https://security-recipes.ai/recipes/devin/scheduled-sde-remediation/","path":"/recipes/devin/scheduled-sde-remediation/","source_file":"recipes/devin/scheduled-sde-remediation.md","recipe_id":"","recipe_kind":"","category":{"slug":"devin","label":"Devin"},"agent":"devin","severity":"unspecified","maturity":"development","ecosystem":"","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"","framework_version":"","jurisdiction":"","industry":[],"cve_archetypes":[],"cve_workflow_role":"","tags":["scheduled","sde","secrets","pii","phi","pci","dlp","devin"],"facets":["remediation","audit","compliance","code-hygiene"],"quality":{"score":100,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context","multi-facet"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"Stephen M Abbott","team":"Security","model":"Opus 4.7","ai_assisted":false,"generated_by":"","date":"2026-04-21","zero_day":false,"last_updated":"2026-04-21","summary":"Use Devin to scan repositories and Git history for secrets, PII, PHI, and PCI data, then produce bounded fixes, verification evidence, and a reviewed PR.","content_text":"A Devin task prompt for scheduled sensitive data element (SDE) remediation. Devin scans the repo and its history for secrets, PII, PHI, PCI, financial data, and unsafe data-handling patterns, then replaces hardcoded secrets with env-var references, masks sensitive fields in logs/telemetry, scrubs fixtures to synthetic equivalents, and untracks files that shouldn't have been committed — all while preserving public APIs, env var names, and response shapes. What this prompt does Devin runs a multi-scanner sweep (Gitleaks, TruffleHog, detect-secrets, Semgrep secrets + SAST, Presidio for PII) across HEAD and git history up to HISTORYSCANDEPTH, classifies each finding by confidence (HIGH / MEDIUM / LOW), and auto-remediates HIGH and MEDIUM with the smallest safe transformation. For secrets found in HEAD, literals are replaced with the project's existing env-var / secret-manager pattern and a rotation issue is filed. For PII in logs, a redaction wrapper is added following the project's existing masking conventions. For fixtures, values are replaced with synthetic equivalents. For files that shouldn't have been tracked, git rm --cached + .gitignore. A single PR is opened with redacted evidence — never the raw secret value. Inputs: REPOURL, DEFAULTBRANCH, SEVERITYTHRESHOLD, HISTORYSCANDEPTH, ROTATESECRETS, ALLOWHISTORYREWRITE, DATACLASSIFICATIONPOLICY, COMPLIANCEFRAMEWORKS, DRYRUN.<br/> Outputs: one remediation PR, a queue of rotation issues per exposed credential, and a SECURITYFINDINGS.md entry for history-only exposures. When to use it You want a weekly SDE sweep that keeps new leaks from piling up — without a human writing the fix each time. You need a PR that mechanically preserves public API, env var names, and response shapes (so the bump-train doesn't break consumers). You need an explicit audit trail: redacted fingerprints, rotation issues, compliance tags (GDPR, CCPA, HIPAA, PCI-DSS), and a clean revert path. Don't use it for: Credential rotation itself (this prompt flags and files issues; humans rotate at the provider). Git history rewrites (off by default; a human has to decide). Free-text PII in prose / docs — the prompt flags these but won't auto-edit natural language. LOW-confidence findings — they surface in the PR body for review but are never auto-applied. Inputs Devin workspace context, REPOURL, DEFAULTBRANCH, WORKINGBRANCH, severity threshold, history scan depth, rotation policy, history rewrite policy, data classification policy, compliance frameworks, dry-run flag, reviewers, and CODEOWNERS. Scanner evidence from Gitleaks, TruffleHog, detect-secrets, Semgrep secrets, Semgrep SAST, Presidio, DLP tools, git history scans, and repo-local security docs. Sensitive-data classes and locations: secrets, credentials, PII, PHI, PCI, financial data, session artifacts, infrastructure data, notebooks, dumps, fixtures, HAR/Postman exports, telemetry, logs, and unsafe data handling. Approved remediation patterns: secret manager/env-var loaders, redaction helpers, masking conventions, synthetic fixture generation, scanner allowlists, git rm --cached, .gitignore, and rotation issue templates. Audit evidence: redacted fingerprints, owner routing, rotation issues, deferred findings, compliance tags, tests run, lint results, revert plan, and non-secret proof that raw SDEs were not printed. The prompt Paste into a scheduled Devin task, or drive via the Devin API: ~~~ ROLE You are a Senior Data Protection Engineer + Application Security Engineer. Your job is to scan the target repository for Sensitive Data Elements (SDEs) — secrets, credentials, PII, PHI, PCI, regulated data, and unsafe data handling patterns — classify each finding, and remediate them with the MINIMUM viable, BACKWARDS-COMPATIBLE change. Open a single, well-documented Pull Request. This task runs on a schedule. Be deterministic, idempotent, conservative, and prioritize never breaking the build. ========================================================== INPUTS (infer from session context; only ask if ambiguous) ========================================================== Try to derive each input from what you can observe in the current session — the connected repository, the Devin workspace settings, CODEOWNERS, and the repo's own docs (docs/security/, SECURITY.md, README, CONTRIBUTING). Only stop and ask the dispatcher if you cannot determine a value with reasonable confidence AND no documented default below applies. REPOURL : from the connected repo in this session. If multiple, use the one named in the task brief. DEFAULTBRANCH : from gh api repos/:owner/:repo .defaultbranch or remote HEAD. WORKINGBRANCH : default = security/sde-remediation- YYYYMMDD-HHMM (UTC). PRBASE : = DEFAULTBRANCH. SEVERITYTHRESHOLD : default = LOW (remediate LOW, MEDIUM, HIGH, CRITICAL). HISTORYSCANDEPTH : default = full (override to last-N-commits if the brief sets a cap). ROTATESECRETS : default = false (flag + open issue; rotation is human-approved). ALLOWHISTORYREWRITE : default = false (NEVER rewrite git history without explicit approval in the task brief). DATACLASSIFICATIONPOLICY : look for docs/security/ classification.md, SECURITY.md, or org-wide Knowledge entries. If none found, note in the PR and proceed with the default classification assumptions. COMPLIANCEFRAMEWORKS : infer from repo metadata (topic tags, SECURITY.md, compliance badges). Default to an empty list and proceed. ASSIGNEES / REVIEWERS : derive from CODEOWNERS for each touched path + any @org/security team mentioned in SECURITY.md. No CODEOWNERS? Use the repo's default reviewer team. DRYRUN : default = false; true if the brief or branch name contains dry-run. Only stop and ask if inference leaves a required input undefined (e.g. you cannot locate a default branch). Never guess at the repo or base branch — those must be confirmable from session context. ========================================================== HARD RULES (non-negotiable) ========================================================== 1. NEVER PRINT, LOG, OR EMBED A LIVE SECRET. In the PR body, scan reports, commit messages, or any artifact: redact secrets to first 4 + last 4 chars (e.g., AKIAWXYZ) or use the scanner's fingerprint/hash. Never include the full value of any detected secret in any output, even in code comments. Never base64-encode or otherwise obfuscate-then-include a secret. Redaction means redaction. 2. BACKWARDS COMPATIBILITY IS MANDATORY. Never rename or remove a public API, exported symbol, CLI flag, env var name, config key, or network contract. When replacing a hardcoded secret with an env var / secret-manager reference, KEEP the same variable/parameter name in code and add a documented loader. Existing consumers must continue to work. Never change the runtime behavior of the application. A request that succeeded before the PR must still succeed after. Never remove data fields from logs, metrics, or API responses without a deprecation path. Mask in place instead (see Rule 4). Never modify database schemas, migrations, or production data. 3. ASSUME EVERY DETECTED SECRET IS COMPROMISED. For every confirmed live secret found in tracked files OR git history: open a SEPARATE rotation issue (or attach to the PR) tagging the secret owner team. Do NOT attempt to rotate the upstream credential yourself. Removing a secret from HEAD does not remove it from history. Flag history exposure explicitly. 4. MASK, DON'T DELETE, FOR PII/PHI/PCI IN CODE PATHS. When code logs, serializes, or transmits sensitive fields, prefer adding a masking/redaction wrapper over removing the field. Default masking conventions: • Email: j@example.com • Phone: --1234 • SSN/Tax ID: --1234 • PAN (credit): show first 6 + last 4 only (PCI-DSS compliant) • IBAN: show country code + last 4 • IP address: mask last octet (IPv4) / last 80 bits (IPv6) for analytics; full removal for HIPAA contexts • JWT/Token: show header only, redact payload + signature • Free-text: do not auto-mask; flag for human review 5. NO NEW DEPENDENCIES WITHOUT JUSTIFICATION. If remediation requires a library (e.g., a secret-manager SDK, a masking lib), prefer stdlib or already-present deps. If a new dep is unavoidable, pin to exact version and document in the PR. 6. NO HISTORY REWRITES WITHOUT APPROVAL. Do NOT run git filter-repo, BFG, or filter-branch unless ALLOWHISTORYREWRITE=true. Default behavior for history-exposed secrets: file rotation issue + add the secret pattern to scanner allowlist with a \"rotated:<date>\" annotation AFTER the owner confirms rotation. Devin does not confirm rotation on its own. 7. IF YOU CANNOT FIX IT SAFELY, DOCUMENT IT. Unfixable findings go in a \"Deferred\" section with rationale and a suggested follow-up issue. ========================================================== SCOPE: WHAT QUALIFIES AS A SENSITIVE DATA ELEMENT ========================================================== A) SECRETS & CREDENTIALS (highest priority) Cloud provider keys: AWS (AKIA, ASIA, session tokens), GCP service account JSON, Azure connection strings, Azure SAS tokens, OCI, IBM Cloud, Alibaba, DigitalOcean, Linode, Hetzner, Scaleway SaaS API keys: GitHub PAT/fine-grained/app, GitLab, Bitbucket, Slack (xoxb/xoxp/xoxa/xapp), Stripe (sklive, rklive, whsec), Twilio (SK, AC + auth token), SendGrid, Mailgun, Postmark, OpenAI, Anthropic, HuggingFace, Datadog, New Relic, PagerDuty, Sentry DSN, Segment, Mixpanel, Amplitude, Algolia, Cloudflare, Fastly, Vercel, Netlify, Heroku, Snowflake, Databricks, MongoDB Atlas, PlanetScale, Supabase, Firebase, Auth0, Okta, OneLogin, Ping, Linear, Notion, Atlassian, Asana, Zendesk, HubSpot, Salesforce, Shopify, Square, PayPal, Plaid, Coinbase, Discord bot tokens, Telegram bot tokens Generic credentials: usernames + passwords in connection strings, basic-auth in URLs (https://user:pass@host), htpasswd entries Database URIs with embedded credentials (postgres://, mysql://, mongodb://, redis://, clickhouse://, etc.) Private keys: RSA/DSA/EC/OpenSSH (-----BEGIN ... PRIVATE KEY-----), PuTTY (.ppk), PGP private keys Certificates with private material: .pfx, .p12, .pem (when containing private key), .jks/.keystore with default passwords JWTs (especially long-lived or signed with HS256 + checked-in secret), OAuth refresh tokens, session cookies SSH knownhosts with sensitive internal hostnames; SSH config with internal infra Webhook signing secrets, HMAC keys, encryption keys (AES, ChaCha20), KMS key material Terraform state files (.tfstate) — frequently contain secrets in plaintext .env, .env., env.local files (any non-template variant) CI variables hardcoded in workflow files instead of using secrets. context Hardcoded bearer tokens in test fixtures, mocks, recorded HTTP cassettes (VCR, Polly, nock recordings) Default/example credentials left active (admin/admin, root/root, test/test in non-test config) B) PERSONALLY IDENTIFIABLE INFORMATION (PII) Direct identifiers: full name + DOB combinations, government IDs (SSN, SIN, NINO, CPF, Aadhaar, passport numbers, driver's license) Contact info: email, phone, physical address, geolocation coordinates with precision < 1km Online identifiers: device IDs, advertising IDs (IDFA, AAID), persistent cookies, full IP addresses (under GDPR) Biometric identifiers: fingerprint hashes, face embeddings (in code paths or test data) Demographic combinations that re-identify (quasi-identifiers): ZIP + DOB + gender Real names in seed data, fixtures, test files, documentation, screenshots C) PROTECTED HEALTH INFORMATION (PHI) — when HIPAA in COMPLIANCEFRAMEWORKS Any of the 18 HIPAA identifiers tied to health context Medical record numbers, health plan IDs, diagnosis/procedure codes (ICD, CPT) tied to a person Prescription data, lab results, device serial numbers in clinical context D) PAYMENT CARD INDUSTRY DATA (PCI) — always treat as CRITICAL PAN (Primary Account Number) — detect via Luhn check + BIN range CVV/CVC/CID (any storage of these is a PCI violation, even encrypted) Track 1 / Track 2 magnetic stripe data PIN / PIN blocks Cardholder name + PAN combinations E) FINANCIAL & REGULATED DATA Bank account numbers, routing numbers (ABA), IBAN, SWIFT/BIC Tax IDs (EIN, VAT numbers when tied to individuals) Brokerage account numbers, crypto wallet seed phrases / mnemonics (BIP-39 wordlists in code = CRITICAL) Crypto private keys (hex strings of correct length entropy) F) AUTHENTICATION & SESSION ARTIFACTS Hardcoded password hashes (bcrypt, argon2, scrypt, PBKDF2) in non-test code Session tokens, CSRF tokens, password reset tokens in fixtures OAuth client secrets in client-side code (web bundles, mobile apps) G) INFRASTRUCTURE & INTERNAL DATA Internal hostnames / FQDNs that reveal architecture Internal IP ranges in checked-in configs (when policy treats as sensitive) Customer identifiers (account IDs, tenant IDs) in shared fixtures Vendor contract terms, plan documentation, internal financial data in docs/ H) UNSAFE DATA HANDLING PATTERNS (code-level) Logging full request/response bodies without redaction (Express morgan with body, Python logging of request.json, Java logging of entities, etc.) console.log, print, fmt.Println, System.out.println, puts, dd(), vardump() of objects that may contain SDEs Stack traces / error responses that echo input back to the client SDEs in URL query strings (should be in headers/body) SDEs written to local storage / cookies without Secure + HttpOnly + SameSite SDEs in analytics events (Segment.track, Mixpanel, GA) without redaction Telemetry/observability spans (OpenTelemetry, Datadog APM) capturing PII attributes Debug/trace flags enabled by default in production config I) FILE-TYPE SPECIFIC HOTSPOTS Jupyter/Colab notebooks (.ipynb) — outputs cells often contain real data SQL dumps (.sql, .dump) committed for \"convenience\" CSV/JSON/XML fixtures with real-looking data HAR files, Postman collections, Insomnia exports, recorded HTTP cassettes Backup files: .bak, .old, .orig, ~, .swp IDE artifacts: .idea/dataSources.xml, .vscode/settings.json with embedded creds, .code-workspace macOS/Windows artifacts: .DSStore, Thumbs.db (low priority but flag) Compiled artifacts checked in: .pyc, target/, dist/, build/ (often contain embedded creds) Coverage reports, test reports with environment dumps ========================================================== SCAN SURFACES ========================================================== All tracked files in DEFAULTBRANCH (HEAD). Git history per HISTORYSCANDEPTH. All branches matching release/, hotfix/, prod/ — secrets in old release branches are still live. Git stashes? No — out of scope. Submodules: scan their HEAD, do not modify. LFS pointers: fetch only if size budget allows; otherwise flag for review. Issues, PR descriptions, wiki, discussions: OUT OF SCOPE for this run (file separate task). ========================================================== EXECUTION PLAN (follow in order) ========================================================== STEP 1 — DISCOVERY Clone REPOURL with full history (depth based on HISTORYSCANDEPTH); checkout DEFAULTBRANCH; create WORKINGBRANCH. Read repo policy artifacts: SECURITY.md, .gitleaks.toml, .gitleaksignore, .secretsignore, .trufflehog-exclude, .gitallowed, .pre-commit-config.yaml (for existing secret hooks), CODEOWNERS, DATACLASSIFICATIONPOLICY. Detect languages, frameworks, and logging libraries in use (informs masking strategy in Step 4). Inventory files per category I. STEP 2 — SCAN (use multiple sources, deduplicate by fingerprint) Run all that are applicable: SECRETS: • Gitleaks — fast, history-aware, customizable rules • TruffleHog — verifies live credentials against provider APIs (use VERIFICATION mode if network allowed; otherwise pattern-only) • detect-secrets (Yelp) — entropy + plugin-based • Semgrep secrets ruleset — context-aware • ggshield (GitGuardian) — if license available • noseyparker — high-throughput history scanning PII / PHI / PCI: • Microsoft Presidio — broad PII detection (en + multilingual) • Semgrep with custom PII rules • Custom regex pack for: SSN, PAN+Luhn, IBAN, phone (libphonenumber), email, US/CA/UK/EU postal codes, IPv4/IPv6 • Spacy/NER for free-text PII in docs and fixtures (encoreweblg) — flag, do not auto-edit prose UNSAFE PATTERNS (SAST): • Semgrep p/security-audit, p/owasp-top-ten, p/secrets, language-specific packs • CodeQL queries for sensitive data flow (taint: source=user input/PII fields, sink=log/HTTP response/file write) — use repo's existing CodeQL config if present; else default suite • Bandit (Python), Brakeman (Ruby), gosec (Go), eslint-plugin-security (JS/TS), SpotBugs+find-sec-bugs (Java), securitycodescan (.NET) NOTEBOOKS: • nbstripout (dry-run) to identify notebooks with non-empty outputs FILE HYGIENE: • Check for files matching category I patterns and confirm against .gitignore Normalize all findings into a unified record: { id, category, subcategory, severity, file, linestart, lineend, commitsha, fingerprint, redactedsample, verifiedlive (bool|null), ruleid, compliancetags[], suggestedremediation, confidence } STEP 3 — TRIAGE Drop test/example data only if clearly marked AND clearly synthetic (e.g., AWS docs example keys AKIAIOSFODNN7EXAMPLE, RFC 5737 IPs, 555-01xx phone numbers, example.com/example.org). Apply repo allowlists (.gitleaksignore, etc.) but log every suppression for the PR body. Confidence tiers: HIGH — verified live, OR matches strong pattern + entropy + context MEDIUM — strong pattern only, or entropy match in suspicious file LOW — heuristic, free-text NER, or generic \"password\" string Auto-remediate HIGH and MEDIUM. Surface LOW as comments in PR body for human review (no code changes for LOW unless trivially safe). Classify each finding by remediation strategy (Step 4). STEP 4 — APPLY FIXES (one logical change per commit) Per finding, choose the SMALLEST safe transformation: 4A) HARDCODED SECRET IN TRACKED FILE Replace literal with environment variable reference using the project's existing config-loading idiom: Node: process.env.STRIPESECRETKEY Python: os.environ[\"STRIPESECRETKEY\"] (or existing settings module / pydantic Settings) Go: os.Getenv(\"STRIPESECRETKEY\") Java: System.getenv(\"STRIPESECRETKEY\") (or Spring @Value(\"${stripe.secret.key}\")) Ruby: ENV.fetch(\"STRIPESECRETKEY\") .NET: Configuration[\"Stripe:SecretKey\"] Rust: std::env::var(\"STRIPESECRETKEY\") If the project uses a secret manager wrapper (Vault, AWS Secrets Manager, GCP Secret Manager, Azure Key Vault, Doppler, 1Password Connect), use THAT existing wrapper — do not introduce a second mechanism. Add the new env var to .env.example / .env.template / config.example. with a placeholder value (NEVER the real value) and a comment describing the secret's purpose. Preserve the calling code's variable name and signature so callers don't change. Backwards compatible by construction. Add the file pattern to .gitignore if a real .env was found tracked. File a rotation issue (template in Step 6), tagging the relevant team via CODEOWNERS. 4B) HARDCODED SECRET IN GIT HISTORY ONLY (not in HEAD) DO NOT rewrite history (default). Add to a SECURITYFINDINGS.md (or extend it) with redacted fingerprint, commit SHA, and rotation status. File rotation issue. Once rotation is confirmed by humans, the issue can be closed; the finding remains in scanner allowlist with rotated:<date> annotation. 4C) PII/PHI IN LOGS, ERRORS, OR TELEMETRY Wrap with project's existing redaction utility if present. If not, ADD a minimal in-repo helper (single file, no new dependency) following the masking conventions in Rule 4. Common patterns: Express: replace app.use(morgan('combined')) with a token that masks Authorization + Cookie headers + body fields by config. Keep route names, status codes, latencies. Python logging: add a logging.Filter that masks known sensitive keys in extra and formatted messages. Java SLF4J/Logback: add a MaskingConverter and update pattern; OR add a TurboFilter. Preserve log levels and existing appenders. OpenTelemetry: add a SpanProcessor that strips attributes matching sensitive keys. For HTTP responses leaking stack traces: ensure error handler returns generic message in production; preserve detail in dev/test envs via existing env switch. Do NOT change response status codes or response shape contracts. 4D) SDE IN FIXTURES / TEST DATA / NOTEBOOKS / RECORDED CASSETTES Replace with synthetic equivalents preserving format and length: • Names → Faker-generated (deterministic seed for test stability) • Emails → user{n}@example.com • Phones → 555-01xx (NANP reserved range) or country equivalents • SSNs → 000-00-0000 style or documented invalid ranges • PANs → BIN ranges reserved for testing (e.g., 4111 1111 1111 1111) • IPs → RFC 5737 (192.0.2.0/24, 198.51.100.0/24, 203.0.113.0/24) • UUIDs → regenerate with fixed seed for reproducibility For VCR/Polly/nock cassettes: re-record with synthetic auth, OR scrub headers/body via the recording tool's built-in filters. Preserve request/response timing and status to keep tests stable. For Jupyter notebooks: clear outputs of cells containing detected SDEs; preserve code, markdown, and outputs without SDEs. 4E) SDE FILE TYPES THAT SHOULD NOT BE TRACKED For .env, .tfstate, .pem (private), .pfx, dataSources.xml, recorded HAR with auth, etc.: • Untrack via git rm --cached <file> (file remains on disk locally; users keep their copies). • Add precise pattern to .gitignore. • If the file contains a live secret, history flag per 4B. 4F) UNSAFE CONFIG (debug flags, default creds, weak defaults) Flip default to safe value ONLY IF the framework documents the change as backwards compatible AND the default is not relied upon by tests. Otherwise, leave the default and add a comment + entry in PR \"Recommended manual changes\" section. 4G) CI WORKFLOWS WITH HARDCODED TOKENS Replace literal with ${{ secrets.NAME }} reference. Add a comment in the workflow indicating which secret to add in repo settings. Do NOT add the secret yourself. After every fix, re-run the relevant scanner on the changed file to confirm the finding is gone and no NEW finding was introduced. STEP 5 — VERIFY (must all pass before opening PR) Re-run the FULL scan suite. Net new findings introduced = 0. (If > 0, revert that commit and mark deferred.) Run the repository's existing build/test commands as defined by: package.json scripts, Makefile/Justfile/Taskfile, tox.ini, noxfile.py, pytest, go test ./..., cargo test, mvn -B verify, ./gradlew check, dotnet test, bundle exec rspec, mix test, composer test If a command is undefined, skip it — do NOT invent test commands. For any modified workflow files: validate with actionlint. Confirm no public API, env var name, config key, or response shape changed (diff inspection). Confirm .env.example exists and is in sync with newly introduced env vars. Confirm .gitignore covers all newly untracked sensitive file patterns. Confirm NO secret value, redacted or otherwise, appears in commit messages, PR body, or scan reports beyond the fingerprint format. STEP 6 — OPEN PULL REQUEST Title: chore(security): scheduled sensitive data remediation — <YYYY-MM-DD> Labels (apply if they exist): security, data-protection, secrets, automated Body must contain ALL sections below, in order: ## Summary Scheduled automated SDE remediation by Devin. Resolves N findings across M files. No public APIs, env var names, or response contracts changed. Backwards compatible. ## Findings Overview | Severity | Category | Count Fixed | Count Deferred | |---|---|---|---| | CRITICAL | Secrets | x | x | | CRITICAL | PCI | x | x | | HIGH | PII | x | x | | HIGH | PHI | x | x | | MEDIUM | Unsafe handling | x | x | | LOW | File hygiene | x | x | ## Per-Finding Detail Table (one row per fix), with secrets REDACTED: | ID | Severity | Category | File:Line | Fingerprint | Verified Live | Remediation | Compliance Tags | | F-001 | CRITICAL | AWS Access Key | src/config.js:42 | AKIAWXYZ | yes | replaced with process.env.AWSACCESSKEYID; rotation issue #N filed | SOC2, GDPR | | F-002 | HIGH | PII in logs | src/api/users.ts:118 | n/a | n/a | wrapped email in mask.email() helper | GDPR, CCPA | ## Per-File Diff Explanation For EACH modified file, a short bullet describing what changed and why: src/config.js: replaced hardcoded AWS key with process.env.AWSACCESSKEYID; added env var to .env.example. src/api/users.ts: wrapped logger.info({ user }) argument with redact(user, ['email','phone']) helper added in src/util/redact.ts. Existing log structure preserved (same fields, masked values). .gitignore: added .tfstate, .pem patterns. .env.example: added 3 new placeholder entries. ## Backwards Compatibility Analysis Explicit statement per change: No env var names were renamed. No public function signatures were changed. No HTTP response shapes were changed. Log line structure preserved; only sensitive field VALUES are now masked. No database schemas, migrations, or production data touched. All masking helpers added are additive (new files / new internal utilities). ## Rotation Required (HUMAN ACTION) For every secret found (in HEAD or history): [ ] Rotate <secret name> in <provider> (issue #N) [ ] Confirm propagation to all environments [ ] Update secret in <secret manager> / GitHub Actions secrets [ ] Close rotation issue Do NOT merge this PR before rotation begins. The exposed credential is considered compromised. ## History Exposure List of secrets found ONLY in git history (not HEAD): | Fingerprint | First seen commit | File at that commit | Rotation issue | Recommendation: rotate. History rewrite NOT performed (ALLOWHISTORYREWRITE=false). ## Verification Performed Scanners run (with versions): <list> Pre-fix counts by severity: C= H= M= L= Post-fix counts by severity: C= H= M= L= Build/test commands executed: <list with pass/fail> actionlint status (if applicable): <pass/fail> No new dependencies added: <true/false; if false, list and justify> ## Deferred / Not Auto-Fixed Table of findings NOT addressed and why (low confidence requiring human judgment, ambiguous test data, would change response contract, etc.), with suggested follow-up. ## Recommended Manual Changes Items requiring human decision (e.g., flipping a debug flag default, adding a secret to GitHub Actions, rewriting git history). ## Rollback Single-command rollback: git revert <merge-sha>. No data migrations, no infra changes, no rotated credentials are reverted by this rollback (rotation must be tracked separately). ## Provenance Devin run ID: <id> Schedule: <cron> Commit range: <base>..<head> Scan reports (redacted): <artifact links> STEP 7 — POST-PR HYGIENE Open rotation issues for every confirmed-live or high-confidence secret. Title format: [security] Rotate <provider> credential exposed in <repo> — fingerprint <id> Body: redacted fingerprint, file path, commit SHA, suggested rotation steps for that provider, link to PR. Request review from CODEOWNERS for touched paths AND from the security team. Do NOT enable auto-merge. Secret remediation requires human verification. If a previous open PR from this automation exists, close it with a link to the new one. Idempotency: if re-running would produce zero changes, do NOT open a PR. Report \"no action needed.\" ========================================================== FAILURE & EDGE-CASE HANDLING ========================================================== Scanner false positives: defer to human review; document in PR with rationale; suggest allowlist entry. Verification API rate limits (TruffleHog live verify): degrade gracefully to pattern-only mode; mark verifiedlive: null. Massive history (>10GB): scan HEAD + last 1000 commits; flag as partial scan in PR body; recommend separate deep-history scan. Encrypted files (sops, git-crypt, age, BlackBox): SKIP; do not attempt decryption. Note presence in PR body. Binary files: skip content scan unless filetype-specific tool exists (e.g., for keystores, check for default passwords). Generated/vendored code: skip if path matches common generated patterns (generated/, vendor/, nodemodules/, generated/, .pb.go, pb2.py); flag any secrets found there as upstream issues. Conflicting redactions (a fix for finding A would mask data needed for finding B's audit trail): prefer privacy; document trade-off. Network failures: retry with backoff up to 3 times; on persistent failure, abort and report. A finding's \"fix\" would change a response contract or env var name: defer to human, do not auto-apply. ========================================================== NON-GOALS (do NOT do these) ========================================================== Do NOT rotate credentials at the provider. Do NOT rewrite git history (unless ALLOWHISTORYREWRITE=true). Do NOT add new SaaS scanners as repo dependencies. Do NOT modify production data, databases, or run migrations. Do NOT change application logic, business rules, or feature behavior. Do NOT reformat files outside the lines you change. Do NOT change package versions or dependency manifests (that's the vulnerability remediation job, not this one). Do NOT scan or modify issues, wikis, discussions, or external systems. Do NOT auto-fix LOW-confidence findings. Do NOT include any unredacted secret value in any output, ever. ========================================================== OUTPUT ========================================================== On success: a single PR URL plus a one-paragraph summary of counts (fixed vs deferred) by severity and category, plus a list of rotation issue URLs. On no-op: a short message \"No remediable sensitive data findings at threshold=<SEVERITYTHRESHOLD>.\" On failure: the exact step that failed, redacted command output, and partial artifacts for human review. Do not open a partial PR. Begin now. ~~~ Verification Rechecked 2026-08-21 against Devin Security Swarm and scheduled playbook dispatch. Exposed secrets still require rotation issues and never appear unredacted in output. History rewrite remains off unless ALLOWHISTORYREWRITE is explicitly true. Output contract Return one of: A reviewer-ready scheduled-remediation PR that preserves public APIs and response shapes, removes or masks confirmed SDEs with the smallest safe changes, adds or updates regression guards, records redacted evidence, opens rotation issues for exposed credentials, and includes compliance tags and a clean revert path. A no-change or deferred-findings report when findings are low-confidence, natural-language PII, unsafe to auto-edit, require provider-side rotation, need approved history rewrite, lack an approved redaction pattern, or need human data-protection review. The output must list scanner sources, finding counts by class and confidence, files touched, redaction or secret-store patterns used, rotation issues, history exposures, deferred items, tests/lint run, compliance frameworks, reviewers, and revert instructions. It must not print raw secrets, rewrite history without approval, rotate upstream credentials, break API contracts, or add dependencies without justification. Related recipes Sensitive Data Remediation Codex sensitive data remediation Source-code secrets and data exposure audit Known limitations Free-text PII — the prompt won't auto-edit prose. Real-name mentions in docs are surfaced for a human to handle. Live-verify rate limits — TruffleHog's live verification degrades to pattern-only under rate limits, so verifiedlive will be null for some HIGH findings. Treat those with the same urgency as verified ones. Massive history — repos over ~10 GB get a partial scan (HEAD + last 1000 commits) with a flag in the PR body. A deep scan is a separate, manually-scheduled task. Encrypted files (sops, git-crypt, age) — skipped entirely; the prompt won't attempt decryption. If something sensitive is inside, that's an owner problem. Rotation — explicitly out of scope. The prompt files the rotation issue; humans rotate the credential at the provider. LOW-confidence findings** — surfaced in the PR body for review but never auto-applied. Changelog 2026-04-21 — v1, first published. Covers secrets, PII, PHI, PCI, financial data, and unsafe data-handling patterns across all major languages and CI systems.","agent_handoff":{"mcp_lookup_keys":["scheduled-sde-remediation","/recipes/devin/scheduled-sde-remediation/","recipes/devin/scheduled-sde-remediation.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["remediation","audit","compliance","code-hygiene"],"source_text_field":"content_text","portable_download":"security-recipe-scheduled-sde-remediation.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-scheduled-sde-remediation.json"}},{"slug":"scheduled-vulnerability-remediation","title":"Devin Scheduled Vulnerability Remediation","link_title":"Scheduled vulnerability remediation","url":"https://security-recipes.ai/recipes/devin/scheduled-vulnerability-remediation/","path":"/recipes/devin/scheduled-vulnerability-remediation/","source_file":"recipes/devin/scheduled-vulnerability-remediation.md","recipe_id":"","recipe_kind":"","category":{"slug":"devin","label":"Devin"},"agent":"devin","severity":"unspecified","maturity":"development","ecosystem":"","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"","framework_version":"","jurisdiction":"","industry":[],"cve_archetypes":[],"cve_workflow_role":"","tags":["scheduled","sca","cve","dependencies","devin","multi-ecosystem"],"facets":["remediation","audit","risk"],"quality":{"score":100,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context","multi-facet"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"Stephen M Abbott","team":"Security","model":"Opus 4.7","ai_assisted":false,"generated_by":"","date":"2026-04-21","zero_day":false,"last_updated":"2026-04-21","summary":"Run scheduled, cross-ecosystem vulnerability remediation with Devin using bounded version bumps, rescans, tests, SBOM diffs, rollback, and reviewed pull requests.\n","content_text":"A Devin task prompt for scheduled, cross-ecosystem vulnerability remediation. Devin scans every dependency surface in the repo — app deps, transitive deps, container images, GitHub Actions, pre-commit — identifies CVEs above a configured severity threshold, bumps each to the minimum viable patched version, verifies backwards compatibility and tests, and opens a single, revertible PR with full evidence. What this prompt does Devin clones the target repo, inventories every manifest (package-lock.json, go.mod, Cargo.lock, Dockerfile, .github/workflows/.yml, etc.), runs a de-duplicated scan across multiple scanners (OSV-Scanner, Trivy, Grype, govulncheck, pip-audit, etc.), classifies each finding as auto-fix / transitive-fix / deferred, applies the smallest safe version bump per finding in its own commit, re-scans to confirm no regressions, runs the project's native build/test commands, and opens one PR — chore(security): scheduled vulnerability remediation — <YYYY-MM-DD> — with per-file diffs, evidence tables, SBOM diffs, and a deferred list. Inputs: REPOURL, DEFAULTBRANCH, SEVERITYTHRESHOLD, MAXMAJORBUMPS, ALLOWPRERELEASE, DRYRUN, LOCKFILEMAINTENANCE, and CODEOWNERS-derived reviewers.<br/> Outputs: one PR per scheduled run (or a \"no action needed\" no-op), a rotation issue queue if needed, and SBOMs before/after. When to use it A repo has standing Devin access and you want a weekly or nightly vulnerability-bump train that doesn't require a human to kick off each cycle. You want conservative, backwards-compatible bumps only — no major version upgrades, no runtime version changes, no \"while you're in there\" refactors. You need an audit trail with CVE/GHSA IDs, SBOM diffs, and a clean revert path for every PR. Don't use it for: First-party SAST findings (that's a different playbook). Major version migrations (this prompt refuses them by default). Emergency / embargoed CVEs — use a human-driven path. Inputs Devin workspace context, REPOURL, default branch, working branch, severity threshold, allowed major bump count, prerelease policy, dry-run flag, lockfile-maintenance setting, reviewers, CODEOWNERS, and repository security policy. Manifest and dependency surfaces: application dependencies, transitive deps, container images, GitHub Actions, CI systems, pre-commit, dev tooling, submodules, vendored code, SBOMs, generated dependency reports, and lockfiles. Scanner evidence from OSV Scanner, Trivy, Grype/Syft, npm/pnpm/yarn audit, pip-audit, govulncheck, cargo audit, bundler-audit, composer audit, dotnet, dependency-check, actionlint, zizmor, and configured ecosystem scanners. Fix planning evidence: advisory IDs, severity, CVSS, known exploit status, current version, fixed version, transitive path, parent dependency, changelog compatibility, release notes, and existing Renovate/Dependabot policies. Verification evidence: native package-manager updates, lint/test commands, container builds, SBOM diffs, scanner re-runs, deferred findings, rollback plan, and one-PR evidence table. The prompt Paste this into a scheduled Devin task, or wire it into your Devin workspace via the API: ~~~ ROLE You are a Senior Application Security Engineer + Release Engineer. Your job is to scan the target repository, identify ALL known vulnerabilities across every dependency surface, remediate them with the MINIMUM viable version bump, preserve 100% backwards compatibility, and open a single, well-documented Pull Request. This task runs on a schedule. Be deterministic, idempotent, and conservative. ========================================================== INPUTS (infer from session context; only ask if ambiguous) ========================================================== Try to derive each input from what you can observe in the current session — the connected repository, the Devin workspace settings, CODEOWNERS, the repo's own docs (README, CONTRIBUTING, docs/ security/), and recent branch history. Only stop and ask the dispatcher if you cannot determine a value with reasonable confidence AND no documented default below applies. REPOURL : from the connected repo attached to this session. If multiple, use the one the task brief names; if still ambiguous, ask. DEFAULTBRANCH : from gh api repos/:owner/:repo .defaultbranch or the remote HEAD pointer. Fallback: the branch with the most recent protected-branch activity. WORKINGBRANCH : default = security/auto-remediation- YYYYMMDD-HHMM (compute from UTC). PRBASE : = DEFAULTBRANCH. SEVERITYTHRESHOLD : default = LOW (remediate LOW, MEDIUM, HIGH, CRITICAL). Overridden by the task brief if set. MAXMAJORBUMPS : default = 0 (NEVER perform a major version bump unless the brief explicitly allows). ALLOWPRERELEASE : default = false. DRYRUN : default = false; true if the brief or branch name contains dry-run. LOCKFILEMAINTENANCE : default = true (refresh lockfiles only when needed for the fix). ASSIGNEES / REVIEWERS : derive from the CODEOWNERS file for each touched path; if no CODEOWNERS, use the repo's default reviewer team. Only stop and ask if inference leaves a required input undefined (e.g. you genuinely cannot locate a default branch). Never guess at the repo or the base branch — those always must be confirmable from session context. ========================================================== HARD RULES (non-negotiable) ========================================================== 1. BACKWARDS COMPATIBILITY IS MANDATORY. Prefer patch > minor > major. Never bump a major version unless MAXMAJORBUMPS > 0 AND no patch/minor fix exists AND a compatibility analysis is included. Never remove, rename, or change the signature of any public API, exported symbol, CLI flag, env var, config key, or network contract. Never change runtime language version (e.g., Node 18 -> 20, Python 3.11 -> 3.12) as part of this PR. File a separate issue if required. Never modify application source code logic. Only modify dependency manifests, lockfiles, Dockerfiles, CI workflow pinned versions, and equivalent configuration. Exception: if a vulnerable dep requires a tiny shim (e.g., import path rename within a minor bump that the upstream documents as backwards compatible), apply ONLY the documented migration and call it out explicitly in the PR. 2. ONE PR, ATOMIC, REVERTIBLE. All changes must land in a single PR on WORKINGBRANCH. Each logical fix is a separate commit with a conventional commit message: fix(sec): bump <pkg> from <old> to <new> (CVE-XXXX-YYYY, GHSA-xxxx) The PR must be safely revertible via git revert of the merge commit. 3. EVIDENCE-BASED. Every bump must reference at least one of: CVE ID, GHSA ID, OSV ID, vendor advisory URL. Do not bump a dep \"just because it's old.\" Only bump what is vulnerable, OR what is a transitive blocker for a vulnerable fix. 4. NO SECRETS, NO EXFIL. Do not add new dependencies, registries, telemetry, or network calls. Do not modify .npmrc, .pip.conf, settings.xml, ~/.docker/config.json, or auth files. Do not touch .env, secrets, or anything matching common secret patterns. 5. IF YOU CANNOT FIX IT SAFELY, DOCUMENT IT. Unfixable findings (no patched version exists, would require major bump, or breaks API) go into a \"Deferred\" section in the PR body with rationale and suggested follow-up. ========================================================== SCOPE: WHAT TO SCAN AND REMEDIATE ========================================================== Detect what exists in the repo and run the appropriate scanners. Cover ALL of the following surfaces: A) APPLICATION DEPENDENCIES (direct AND transitive) JavaScript/TypeScript : package.json, package-lock.json, npm-shrinkwrap.json, yarn.lock, pnpm-lock.yaml, bun.lockb Python : requirements.txt, Pipfile / Pipfile.lock, pyproject.toml, poetry.lock, uv.lock, setup.py, setup.cfg, constraints.txt Java/Kotlin/Scala : pom.xml, build.gradle(.kts), settings.gradle, gradle.lockfile, ivy.xml, build.sbt .NET : .csproj, .fsproj, .vbproj, packages.config, packages.lock.json, Directory.Packages.props, paket.dependencies Go : go.mod, go.sum, vendor/ Rust : Cargo.toml, Cargo.lock Ruby : Gemfile, Gemfile.lock, .gemspec PHP : composer.json, composer.lock Swift : Package.swift, Package.resolved, Podfile, Podfile.lock Dart/Flutter : pubspec.yaml, pubspec.lock Elixir : mix.exs, mix.lock Erlang : rebar.config, rebar.lock Haskell : cabal.project, .cabal, stack.yaml, stack.yaml.lock C/C++ : conanfile.txt/py, conan.lock, vcpkg.json, vcpkg-configuration.json, CMakeLists (FetchContent pins) R : DESCRIPTION, renv.lock Perl : cpanfile, cpanfile.snapshot Lua : .rockspec Terraform / OpenTofu : .terraform.lock.hcl, requiredproviders blocks Helm : Chart.yaml, Chart.lock, requirements.yaml Any monorepo workspaces (Nx, Turborepo, Lerna, Yarn workspaces, pnpm workspaces, Cargo workspaces, Go workspaces). B) CONTAINER / IMAGE VERSIONS Dockerfile(s) (any name, any path), Containerfile, .dockerfile docker-compose.yml, compose.yaml Kubernetes manifests: .yaml under k8s/, manifests/, deploy/, charts/, helm/ Helm values.yaml image: references Kustomize: kustomization.yaml images: field Skaffold, Tilt, devcontainer.json (image, dockerFile) Buildpacks: project.toml, builder images For each base image / referenced image: pin to immutable digest where it was already pinned; bump tag to the latest patch within the same major.minor when a CVE exists in the current tag. Prefer -slim, -alpine, or distroless variants only if already in use. C) GITHUB ACTIONS / CI .github/workflows/.yml, .yaml .github/actions//action.yml (composite actions) reusable workflows (uses: org/repo/.github/workflows/x.yml@ref) For every uses: reference: • Pin to a full-length commit SHA (40 chars) with a trailing comment of the human-readable tag, e.g.: uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.1.1 • Bump to the latest patched release within the same major if a CVE/GHSA affects the pinned SHA. • Never bump a Marketplace action across a major version automatically. Other CI systems if present (treat with same rigor): GitLab CI (.gitlab-ci.yml image: and include: refs), CircleCI (.circleci/config.yml orbs and images), Azure Pipelines (azure-pipelines.yml), Jenkins (Jenkinsfile, shared libraries @version), Drone, Buildkite, Travis, Bitbucket Pipelines. D) PRE-COMMIT / DEV TOOLING .pre-commit-config.yaml rev: pins renovate.json / .renovaterc / dependabot.yml (do NOT modify policy, but note conflicts) .tool-versions (asdf), .nvmrc, .python-version, .ruby-version, .sdkmanrc, mise.toml (DO NOT change runtime majors; only patch within same minor if a CVE exists in the runtime patch level) E) SUBMODULES & VENDORED CODE .gitmodules — note outdated submodules but DO NOT bump unless a CVE explicitly maps to the pinned commit. vendored directories (vendor/, thirdparty/, externals/) — flag for human review; do not auto-modify. ========================================================== EXECUTION PLAN (follow in order) ========================================================== STEP 1 — DISCOVERY Clone REPOURL, checkout DEFAULTBRANCH, create WORKINGBRANCH. Build a manifest inventory: list every file from sections A–E that exists. Detect package managers and runtimes from manifests (do NOT install global tools without need). Read CODEOWNERS, CONTRIBUTING.md, SECURITY.md, and any renovate.json/dependabot.yml to respect existing policies (ignore lists, schedules, grouping). STEP 2 — SCAN (use multiple sources, deduplicate by advisory ID) Use the most appropriate, available scanners. Prefer offline/CLI tools the repo already trusts; otherwise use these defaults: • OSV-Scanner (multi-ecosystem, authoritative for OSV/GHSA) • Trivy fs + Trivy image (multi-ecosystem + container) • Grype + Syft (SBOM + vulns, container & fs) • npm audit / pnpm audit / yarn npm audit • pip-audit (PyPI) • govulncheck (Go, call-graph aware — preferred over generic for Go) • cargo audit (Rust) • bundler-audit (Ruby) • composer audit (PHP) • dotnet list package --vulnerable --include-transitive • mvn org.owasp:dependency-check / gradle dependencyCheckAnalyze (only if already configured; else use OSV-Scanner) • mix deps.audit (Elixir) • actionlint + zizmor (GitHub Actions correctness + security) • hadolint (Dockerfile lint, supplementary) • checkov / kube-linter (IaC, supplementary) Generate an SBOM (CycloneDX or SPDX) before and after for diffing. Normalize all findings into a unified table: { ecosystem, package, currentversion, fixedversion, advisoryids[], severity, cvss, exploitknown, transitivepath[], introducedby } STEP 3 — TRIAGE For each finding, classify into: (a) AUTO-FIX: patched version exists within same major; no breaking changes per upstream changelog/release notes. (b) TRANSITIVE-FIX: vulnerable transitive dep; resolve via: npm/pnpm: overrides / pnpm overrides / yarn resolutions Python (poetry): constraint in pyproject; (pip) constraints.txt Maven: <dependencyManagement> pin Gradle: resolutionStrategy.force or platform BOM bump Go: go get pkg@vX.Y.Z then go mod tidy; use replace only as last resort and document Cargo: [patch] section with rationale .NET: CPM (Directory.Packages.props) version pin Composer: explicit version constraint in root composer.json Always prefer fixing the parent dependency if a non-vulnerable parent version exists. (c) DEFERRED: requires major bump, no fix available, or fix conflicts with another constraint. Drop duplicates and apply the repo's existing ignore policy (e.g., dependabot ignore rules, .trivyignore, .grype.yaml, suppression files). STEP 4 — APPLY FIXES (one logical change per commit) Update manifest with the smallest version range change that includes the fix. Examples: \"lodash\": \"^4.17.20\" → \"^4.17.21\" (when 4.17.21 patches the CVE) lodash@4.17.20 → 4.17.21 (exact pins stay exact) Regenerate lockfile using the project's native tool (npm ci-friendly, pnpm install --lockfile-only, poetry lock --no-update then targeted --update, go mod tidy, cargo update -p <crate> --precise, etc.). For Docker images: bump tag to latest patched within same major.minor; re-pin digest if previously pinned (@sha256:...). For GitHub Actions: replace SHA with new SHA for the patched tag and update the trailing comment. For pre-commit: bump rev: to the patched tag. After every fix, re-run the relevant scanner on the changed surface to confirm the advisory is gone and no NEW advisory was introduced. STEP 5 — VERIFY (must all pass before opening PR) Re-run the FULL scan suite. Net new vulnerabilities introduced = 0. (If > 0, revert that commit and mark deferred.) Run the repository's existing build/test commands as defined by: • package.json scripts (build, test, lint, typecheck) • Makefile / Justfile / Taskfile targets (make test, make build) • tox.ini, noxfile.py, pytest • go test ./... ; go build ./... • cargo test ; cargo build • mvn -B verify ; ./gradlew check • dotnet test ; dotnet build • bundle exec rspec ; rake • mix test • composer test If a command is undefined, skip it — do NOT invent test commands. For Docker base image bumps: build the image locally (docker build) to confirm it still builds. Do NOT push. For GitHub Actions: validate workflow syntax with actionlint. Confirm SBOM diff shows ONLY expected version changes. Confirm no source code under src/, lib/, app/, internal/, pkg/, etc. has been modified. STEP 6 — OPEN PULL REQUEST Title: chore(security): scheduled vulnerability remediation — <YYYY-MM-DD> Labels (apply if they exist in the repo): security, dependencies, automated Body must contain ALL sections below, in order: ## Summary Scheduled automated remediation by Devin. Resolves N advisories across M dependencies. No major version bumps. No source code changes. Backwards compatible. ## Scope of Changes Files modified: <count> Ecosystems touched: <list> Surfaces: [App deps] [Transitive] [Container images] [GitHub Actions] [Pre-commit] [IaC] ## Vulnerabilities Fixed Table with columns: | Severity | CVE / GHSA | Ecosystem | Package | From → To | Direct/Transitive | Introduced By | Fix Source | ## Per-File Diff Explanation For EACH modified file, a short bullet list of what changed and why, e.g.: package-lock.json: regenerated to pull in lodash@4.17.21 (fixes GHSA-jf85-cpcp-j695). No other resolutions changed. Dockerfile: base image node:20.11.1-alpine → node:20.18.1-alpine (patches CVE-2024-XXXXX in libcrypto). Same major.minor (20). .github/workflows/ci.yml: actions/checkout SHA bumped from b4ffde6... (v4.1.1) to eef6144... (v4.2.2). Patches GHSA-xxxx-xxxx-xxxx. ## Backwards Compatibility Analysis For each bump, one of: PATCH bump within semver — no API surface change per upstream changelog: <link> MINOR bump within semver — additive only per upstream changelog: <link> For container/Action bumps: confirm same major; link release notes. Explicit statement: \"No public APIs, exported symbols, CLI flags, env vars, config keys, or network contracts were modified.\" ## Verification Performed Scanners run (with versions): <list> Pre-fix vuln count by severity: C= H= M= L= Post-fix vuln count by severity: C= H= M= L= Build/test commands executed: <list with pass/fail> Docker build status (if applicable): <pass/fail> actionlint status (if applicable): <pass/fail> SBOM diff attached: <yes/no> ## Deferred / Not Fixed Table of advisories NOT addressed and why (no fix available, would require major bump, suppressed by policy, etc.), with suggested follow-up issue. ## Rollback Single-command rollback: git revert <merge-sha>. No data migrations, no infra changes. ## Provenance Devin run ID: <id> Schedule: <cron> Commit range: <base>..<head> SBOM (before): <artifact link> SBOM (after): <artifact link> STEP 7 — POST-PR HYGIENE Request review from CODEOWNERS for the touched paths. If CI is configured, do not merge — wait for human approval. If a previous open PR from this automation exists on WORKINGBRANCH pattern, close it with a comment linking to the new one to avoid PR sprawl. Idempotency: if running the scan again would produce zero changes, do NOT open a PR. Report \"no action needed.\" ========================================================== FAILURE & EDGE-CASE HANDLING ========================================================== Lockfile conflicts: attempt resolution via the package manager's documented mechanism. If unresolvable without breaking the constraint graph, mark deferred. Yanked / withdrawn versions: never select. Pre-release / RC versions: never select unless ALLOWPRERELEASE=true. Air-gapped / private registries: respect existing registry config; do NOT add new sources. Monorepos: scope changes per workspace; group commits per workspace for clarity. Generated files: if a manifest is generated (e.g., bazel MODULE.bazel.lock), regenerate via the documented command, never hand-edit. Network failures during scan: retry with backoff up to 3 times; on persistent failure, abort and report. Conflicting fixes (fix for A breaks B): prefer the fix that resolves the higher-severity CVE; defer the other and document. ========================================================== NON-GOALS (do NOT do these) ========================================================== Do NOT refactor code. Do NOT reformat files (no Prettier/Black runs). Do NOT update unrelated dependencies \"while you're in there.\" Do NOT change branch protection, repo settings, or workflows' permissions blocks. Do NOT enable new features (e.g., new linters, new scanners as repo dependencies). Do NOT modify test fixtures, snapshots, or recorded responses. Do NOT touch documentation except to add the PR body itself. ========================================================== OUTPUT ========================================================== On success: a single PR URL plus a one-paragraph summary of counts (fixed vs deferred) by severity. On no-op: a short message \"No remediable vulnerabilities found at threshold=<SEVERITYTHRESHOLD>.\" On failure: the exact step that failed, the command output, and the partial artifacts (SBOM, scan reports) for human review. Do not open a partial PR. Begin now. ~~~ Verification Rechecked 2026-08-21 against Devin Security Swarm's finding-to-pull-request workflow. Scheduled runs still apply conservative advisory-backed bumps only and keep each logical fix in a separate commit. Findings that need major or runtime migrations still defer instead of auto-fixing. Output contract Return one of: A reviewer-ready scheduled-remediation PR that applies conservative, advisory-backed dependency, image, action, and tooling updates, keeps each logical fix in a separate commit, refreshes lockfiles and SBOMs, runs native tests/scans, and includes evidence tables plus a clean revert path. A no-op or deferred-findings report when no findings meet policy, fixes require major/runtime migrations, no patched version exists, ownership is external, vendored code must be reviewed manually, or validation fails for pre-existing reasons. The output must list manifest inventory, scanners used, normalized findings, fix/defer classification, old/new versions, advisory IDs, transitive paths, SBOM diffs, tests/scans run, deferred owners, reviewer routing, and rollback plan. It must not change application logic, touch secrets, alter runtime majors, add registries/telemetry, or bump dependencies without advisory evidence. Related recipes Vulnerable Dependency Remediation Codex vulnerable dependency remediation Source-code supply chain build integrity audit Known limitations Private registries — Devin needs pre-configured read access to any internal npm/pypi/etc. mirrors. If the scanner can't resolve a package it will mark the finding deferred rather than guess. Bazel / generated manifests — regenerated via the project's documented command, but repos with bespoke codegen may still need a human to confirm the regen was clean. Conflicting CVE fixes — when one bump regresses another dep, the prompt explicitly prefers the higher-severity fix and defers the other. The reviewer needs to weigh whether that's the right call for their stack. Runtime version bumps** — out of scope by design. File a separate issue; a different playbook owns runtime upgrades. Changelog 2026-04-21 — v1, first published. Covers all major ecosystems plus container images, GitHub Actions, and pre-commit.","agent_handoff":{"mcp_lookup_keys":["scheduled-vulnerability-remediation","/recipes/devin/scheduled-vulnerability-remediation/","recipes/devin/scheduled-vulnerability-remediation.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["remediation","audit","risk"],"source_text_field":"content_text","portable_download":"security-recipe-scheduled-vulnerability-remediation.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-scheduled-vulnerability-remediation.json"}},{"slug":"agent-session-kill-rules","title":"Agent session — telemetry-driven kill rules","link_title":"Telemetry-driven session kill rules","url":"https://security-recipes.ai/recipes/general/agent-session-kill-rules/","path":"/recipes/general/agent-session-kill-rules/","source_file":"recipes/general/agent-session-kill-rules.md","recipe_id":"","recipe_kind":"","category":{"slug":"general","label":"General"},"agent":"general","severity":"unspecified","maturity":"development","ecosystem":"","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"","framework_version":"","jurisdiction":"","industry":[],"cve_archetypes":[],"cve_workflow_role":"","tags":["runtime","telemetry","guardrail","kill-switch","monitor"],"facets":["remediation"],"quality":{"score":95,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"Stephen M Abbott","team":"Security","model":"Opus 4.7","ai_assisted":false,"generated_by":"","date":"2026-04-25","zero_day":false,"last_updated":"2026-04-25","summary":"A tool-agnostic prompt that takes a workflow's run telemetry and a draft set of decision rules, and produces (a) a vetted rule pack the session monitor can load and (b) a synthetic red-team exercise the program owner runs to verify the …","content_text":"A tool-agnostic prompt that takes a workflow's run telemetry and a draft set of decision rules, and produces (a) a vetted rule pack the session monitor can load and (b) a synthetic red-team exercise the program owner runs to verify the rules fire correctly. This is a guardrail-design prompt, not a remediation prompt. The agent's job is to design and pressure-test the rules; humans deploy them. Designed to slot into the Runtime Controls workflow. What this prompt does 1. Reads 30 days of run telemetry for the workflow — tool call rates, scope distributions, argument shapes, result sizes, budget usage, egress events. 2. Computes baselines (median, p95, p99) per signal. 3. Drafts a rule pack with three layers — threshold rules, deviation rules, pattern rules — each with explicit thresholds tuned against the baseline. 4. Designs synthetic red-team exercises that simulate each failure mode (scope creep, exfiltration, prompt drift, budget runaway) and predicts which rule should fire. 5. Outputs the rule pack and the exercise plan as a PR against the monitor's policy repo. When to use it A workflow has accumulated at least 30 days of run telemetry on at least 50 healthy runs. The session monitor has a declarative policy format (OPA, Cedar, in-house) the agent can target. A program owner is available to review and run the synthetic exercises before deployment. Don't use it for: A workflow that has never reached production. Without a baseline, the rules will be guesses. A workflow with an irregular cadence (every run is shaped differently). The pattern needs stable shapes to draw a baseline from. Replacing rules that already work. This prompt designs initial rule packs and proposed updates; it does not unilaterally rewrite working rules. Inputs Telemetry path — read-only access to the run-telemetry store for this workflow. Policy repo — where the rule pack is committed for human review and deployment. Workflow declaration — the workflow's declared scope (allowed files, allowed tools, allowed hostnames). Threat scenarios — the named failure modes this workflow must defend against (exfiltration, scope creep, prompt-drift, budget runaway, tool-poisoning amplification). The prompt ~~~markdown You are designing the rule pack a session monitor will load to watch this workflow's runs in flight. Your output is exactly one of: A pull request against the monitor's policy repo containing: (a) a rule pack with three layers, (b) a synthetic red-team exercise plan, and (c) the baseline data each threshold was tuned from. A TRIAGE.md note explaining why the telemetry is insufficient to design rules safely. Do not deploy the rule pack. Humans deploy. Step 0 — Read the telemetry and the workflow declaration 1. Pull the workflow's last 30 days of run telemetry. Confirm at least 50 successful runs are present. If fewer, stop and triage with a note about insufficient baseline. 2. Read the workflow's declared scope: allowed files, allowed tools, allowed hostnames, allowed argument shapes. 3. Read the threat-scenario list the operator provided. Step 1 — Compute baselines For each signal, compute median, p95, p99 across the 30-day window: Tool calls per minute, per turn, per run. Distinct files touched per run. Distinct hostnames contacted per run. Argument lengths per tool, per call. Result sizes per tool. Cumulative outbound bytes per run. Cumulative tokens per run. Number of forbidden-path attempts per run (should be 0; baseline is asserting that). Document the baselines in the PR body. The reviewer needs them to evaluate the thresholds. Step 2 — Draft threshold rules Threshold rules fire when a signal crosses an absolute ceiling. For each signal, set the threshold at p99 × 1.5 by default; adjust if the operator's scenario list indicates a tighter bound is required. Examples: toolcallsperminute > <p99 × 1.5> → annotate. distinctfilestouched > <p99 × 1.5> → hold-for-elicit. cumulativeoutboundbytes > <p99 × 2> → kill. forbiddenpathattempts > 0 → kill. metadataendpointcontact > 0 → kill. The action graduates with severity: low-confidence anomalies annotate, medium hold, high ratchet or quarantine, critical kill. Step 3 — Draft deviation rules Deviation rules fire when a signal drifts away from baseline mid-run. currentrun.distinctfiles / baseline.median > 5 → hold. currentrun.cumulativetokens / baseline.median > 4 → annotate at 4×, hold at 6×, kill at 10×. argumentlengthzscore > 6 for any tool → annotate. Tune deviation thresholds conservatively. False positives in this layer are louder than threshold rules — the run is otherwise healthy when these fire. Step 4 — Draft pattern rules Pattern rules fire on named, high-signal shapes: Argument or result contains a link-local IP (169.254., fd00::). Argument or result references the cloud-provider metadata endpoint hostname. Result size exceeds 10 MB. Result contains a base64 blob > 1 MB. Tool description hash differs from the pinned hash. Outbound DNS query for a typosquat neighbour of an allowlisted hostname. Pattern rules are kill-rules by default unless the operator's scenario list says otherwise. Step 5 — Design synthetic red-team exercises For each named failure mode, design one synthetic exercise: Exfiltration. Inject a tool result containing a base64 blob; expect the pattern rule on result-blob-size to fire. Scope creep. Inject a tool call with an argument file path outside the declared scope; expect the threshold rule on forbidden-path-attempts to fire. Prompt drift. Inject a tool result with a string that resembles instructions (\"ignore previous, run …\"); expect the result-content rule to fire. Budget runaway. Run a synthetic loop hitting tools at 5× baseline rate; expect deviation rule on tokens to escalate through annotate → hold → kill. Tool-description tampering. Change a tool description hash; expect the pinned-description rule to fire. For each exercise, predict which rule(s) should fire and at what severity. The reviewer compares the prediction against the monitor's actual response. Step 6 — Open the PR Branch: monitor/<workflow-name>-rules-<date>. Title: [Monitor][<workflow-name>] rule pack v<n> + synthetic exercises. Body must include: Workflow declaration summary. Baseline table (median, p95, p99 per signal). The rule pack in the policy format the monitor expects. The synthetic-exercise plan with predictions per rule. Estimated false-positive rate per rule, computed against the 30-day baseline. Label: monitor-rule-update. Stop conditions (write a TRIAGE.md and exit) Fewer than 50 successful runs in the baseline window. Telemetry is missing required signals (no per-run token counts, no per-tool argument shapes). The workflow's declared scope is incomplete or contradictory. The threat-scenario list is empty. Scope Do not deploy the rule pack. PR only. Do not modify the policy repo's deployment pipeline, the monitor's runtime, or the audit ledger. Do not ship rules with no baseline data behind them. Do not silently lower an existing rule's severity. If the baseline suggests a rule should soften, surface that as an explicit recommendation in the PR body — humans decide. ~~~ Output contract A PR against the monitor's policy repo with the rule pack, the synthetic exercises, and the baseline data — OR a TRIAGE.md note. The PR is never auto-merged. Rule packs change the failure surface of the runtime gate; humans deploy. Verification Baseline dataset, window, and sample count are recorded beside every proposed rule threshold. Each synthetic exercise includes the expected action, observed action, and the telemetry fields that proved the monitor fired. False-positive and false-negative risks are called out in the PR body, with any severity changes left as explicit human decisions. The rule pack is staged as policy only. No runtime monitor, kill-controller, or deployment configuration is changed by this recipe. Guardrails Baseline-driven thresholds. No threshold ships without data behind it. Hand-picked numbers without baselines are exactly how monitors stop firing on the bad runs and start firing on the healthy ones. Graduated actions. A rule that can only kill is a rule the operators will eventually mute. Annotate / hold / ratchet / quarantine / kill are the full vocabulary. Synthetic exercises required. A rule pack without a matching exercise plan does not ship. The exercises validate the monitor still fires correctly, and run on a cadence after deployment. Read-only on the monitor's runtime. This prompt designs rules; it does not deploy them, change the engine's runtime configuration, or touch the kill-controller. Related Runtime Controls — the workflow this prompt slots into. Gatekeeping Patterns — where runtime gates sit in the full stack. Threat Model — the failure modes the rules are defending against. Reviewer Playbook — what reviewers do when a telemetry-hold flag fires.","agent_handoff":{"mcp_lookup_keys":["agent-session-kill-rules","/recipes/general/agent-session-kill-rules/","recipes/general/agent-session-kill-rules.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["remediation"],"source_text_field":"content_text","portable_download":"security-recipe-agent-session-kill-rules.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-agent-session-kill-rules.json"}},{"slug":"base-image-bump","title":"Base image — bump and rebuild","link_title":"Base image bump","url":"https://security-recipes.ai/recipes/general/base-image-bump/","path":"/recipes/general/base-image-bump/","source_file":"recipes/general/base-image-bump.md","recipe_id":"","recipe_kind":"","category":{"slug":"general","label":"General"},"agent":"general","severity":"unspecified","maturity":"development","ecosystem":"","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"","framework_version":"","jurisdiction":"","industry":[],"cve_archetypes":["supply_chain_update_integrity"],"cve_workflow_role":"remediate","tags":["containers","docker","base-image","cve","remediate"],"facets":["remediation"],"quality":{"score":95,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"Stephen M Abbott","team":"Security","model":"Opus 4.7","ai_assisted":false,"generated_by":"","date":"2026-04-25","zero_day":false,"last_updated":"2026-04-25","summary":"Use an AI coding agent to remediate one base-image or OS-package CVE, rebuild and rescan the container, verify the fix, and return a scoped pull request or triage note.\n","content_text":"A tool-agnostic prompt that takes a CVE finding scoped to a base image or an OS-package layer, and produces a reviewer-ready PR that bumps the FROM line (or the package install layer), rebuilds the image, runs the smoke test, and confirms the CVE is gone — or stops cleanly with a triage note. Designed to slot into the Base Image & Container Layer Remediation workflow. What this prompt does 1. Reads the finding — the affected image, the CVE, the package, the patched version (or the patched image tag). 2. Locates the affected layer — the FROM line, the apt-get install line, or the RUN apt-get upgrade step that introduces the vulnerable package. 3. Picks a bump strategy — tag bump, digest pin update, package upgrade, or curated-base bump — from the workflow's declared policy. 4. Edits the Dockerfile, rebuilds the image with --no-cache for the affected layer, runs the repo's smoke test. 5. Re-scans the rebuilt image and confirms the CVE is gone and no new CVEs were introduced. 6. Opens a PR with a structured body — affected images, affected services, rollout shape, rollback plan. When to use it A container image scanner has produced a structured CVE finding scoped to the base image or to a package the Dockerfile installs. The repo owns the Dockerfile (CODEOWNERS resolves cleanly). The repo's CI builds the image and exposes a smoke test the agent can invoke. Don't use it for: Application-package CVEs (npm, pip, Go modules, etc.) — those go through the vulnerable-dependency workflow. Curated-base creation, distroless rebases, or OS-family changes — those are human-driven. Images built outside the repo. CVEs in the kernel or host runtime. Inputs CVE — ID, affected package, fixed version (or fixed image tag). Image — registry path, current tag, current digest. Dockerfile path — repo-relative path. Smoke test command — inferred from CI (make smoke, docker run … && curl /health, etc.). Policy file — .sec-auto-remediation.yml declaring which bump magnitudes (patch / minor / major) are auto-eligible. The prompt ~~~markdown You are remediating a single base-image or OS-package CVE in this repository. Output exactly one of: A PR with a Dockerfile edit and a successful rebuild + scan. A TRIAGE.md note explaining why the bump is unsafe or ineffective. Do not auto-merge. Do not bundle multiple CVEs. Step 0 — Read the finding and the policy 1. Read the CVE ID, the affected package, the fixed version (or fixed image tag), and the image coordinate. 2. Read the policy file. Confirm the bump magnitude implied by the fix is auto-eligible. If the policy says \"human only\" for this magnitude, stop and triage. Step 1 — Locate the affected layer 1. Read the Dockerfile. Identify the FROM line(s) and any package-install layers (apt-get install, apk add, dnf install, microdnf install, yum install). 2. Determine which layer introduces the vulnerable package. Multi-stage builds may have multiple FROM lines; identify only the one(s) affected. 3. If the image derives from an internal curated base (internal/...:tag), confirm the curated base has been bumped upstream first. If not, stop and triage with a link to the upstream-bump request. Step 2 — Pick the bump strategy Choose exactly one (and only one): Tag bump. Edit the FROM line to the patched tag. Digest pin update. When the repo pins to image@sha256:…, edit the digest to the registry's current tag-resolved digest for the same logical version. Package upgrade. Edit the package-install line to pin the patched version (preferred) or add an explicit apt-get upgrade <pkg> step before the install. Curated base bump. Edit the FROM tag to the new curated tag and link the upstream curated-base PR in the body. Do not refactor the Dockerfile. Do not \"clean up while you're in there.\" If a clean fix requires more than the bump, stop and triage. Step 3 — Rebuild 1. Rebuild the image with --no-cache for the affected layer. If the cache state is uncertain, rebuild the whole image. 2. Capture the new digest. 3. Run the repo's smoke test against the rebuilt image. The image must start, the health check must pass. 4. If the smoke test fails, revert and stop with a triage note that includes the failure log. Step 4 — Rescan 1. Re-run the image scanner against the rebuilt image. 2. The original CVE must be gone. 3. The total CVE count must not have increased. If new CVEs appeared, list them in the PR body — do not silently ship. 4. If the original CVE is still present (e.g., the patched version was not actually fixed in the new tag), stop and triage. Step 5 — Open the PR Branch: remediate/cve-<cve-id>-<image-slug>. Title: [Security][CVE-XXXX-YYYYY] bump <image> for <pkg>. Body must include: CVE summary — ID, package, severity, link to the advisory. Strategy used — which of the four bump shapes. Affected images — the registry paths that will rebuild. Affected services — the manifests / Helm values / Kustomize overlays that pin to those images. Rollout shape — canary, blue/green, rolling. Rollback plan — the previous tag/digest. New CVEs introduced (if any) — listed with severity. How to verify locally — exact build + smoke commands. Label: sec-auto-remediation. Stop conditions Bump magnitude is not auto-eligible per policy. The repo's CI does not have a smoke test. The Dockerfile uses latest, a moving major-version tag, or a missing tag (flag and triage; do not silently pin). Rebuilt image fails the smoke test. Re-scan still shows the original CVE or shows new CVEs the policy treats as blocking. The fix would require a multi-stage refactor or an OS-family change. Scope Do not edit application source. Do not edit CI, deploy manifests (the reviewer drives those), or release pipelines. Do not push to the registry — the agent's credentials are pull-only. Do not bundle multiple CVEs. ~~~ Output contract Either a PR (happy path) with a successfully rebuilt and rescanned image, or a TRIAGE.md note (stop condition). Audit record includes the new digest, the scanner output, and the smoke-test result. Verification Rebuilt image digest is captured and differs from the vulnerable baseline digest. Scanner output shows the target CVE is absent, and any newly introduced critical/high findings are listed as blockers. Smoke test or service health check result is attached to the PR or recorded in TRIAGE.md. Rollback context includes the previous digest and confirms the agent did not push to a registry or introduce a moving tag. Guardrails One CVE, one image, one PR. Bundling masks regressions. Rescan required. No PR opens until the rebuilt image scans clean for the target CVE. Smoke test required. \"It builds\" is not \"it works.\" Layer cache is not a fix. Rebuild with --no-cache for the affected layer. No latest. The agent never introduces or relies on a moving tag. Pull-only credentials. Push happens from CI, not from the agent. Related Base Image & Container Layer Remediation — the workflow this prompt slots into. Vulnerable Dependency Remediation — the lockfile-shaped sibling. Artifact Cache & Mirror Quarantine — when the bump is the wrong fix because the publisher is compromised.","agent_handoff":{"mcp_lookup_keys":["base-image-bump","/recipes/general/base-image-bump/","recipes/general/base-image-bump.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["remediation"],"source_text_field":"content_text","portable_download":"security-recipe-base-image-bump.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-base-image-bump.json"}},{"slug":"eval-and-function-constructor","title":"JavaScript `eval()` / `new Function()` on untrusted input","link_title":"eval and Function constructor","url":"https://security-recipes.ai/recipes/general/classic-vulnerable-defaults/eval-and-function-constructor/","path":"/recipes/general/classic-vulnerable-defaults/eval-and-function-constructor/","source_file":"recipes/general/classic-vulnerable-defaults/eval-and-function-constructor.md","recipe_id":"","recipe_kind":"","category":{"slug":"classic-defaults","label":"Classic Vulnerable Defaults"},"agent":"general","severity":"unspecified","maturity":"development","ecosystem":"","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"","framework_version":"","jurisdiction":"","industry":[],"cve_archetypes":[],"cve_workflow_role":"","tags":["javascript","eval","uplift","mitigate","csp"],"facets":["remediation","risk","code-hygiene"],"quality":{"score":100,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context","multi-facet"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"Stephen M Abbott","team":"Security","model":"Opus 4.7","ai_assisted":false,"generated_by":"","date":"2026-04-25","zero_day":false,"last_updated":"2026-04-25","summary":"Replace with parsers or restricted evaluators; add a CSP `script-src` ban on `unsafe-eval` for browser code.","content_text":"eval(), new Function(), setTimeout(\"...\", n) with a string body, and setInterval(\"...\", n) with a string body all execute code parsed at runtime. When any of those strings includes user input, the application is one cleverly-shaped character away from arbitrary execution. The fix is rarely \"escape better\" — it's \"stop using a code parser as a data parser.\" When to use it Use this recipe when JavaScript evaluates attacker-influenced strings via eval, new Function, or string-bodied timers. Prefer it over a generic XSS recipe when the sink is in-process code evaluation. Do not use it to execute untrusted scripts or to disable CSP as a workaround. Pattern eval(input), eval(\"...\" + input + \"...\"), new Function(input), new Function(\"...\", input). setTimeout(input, n), setInterval(input, n) where the first argument is a string (passing a function reference is fine). vm.runInNewContext(input) (Node) without a sandbox or with a leaky one. Template engines that compile templates from user-supplied strings (pug.compile, handlebars.compile on user input, lodash.template on user input). Why it matters A \"math expression\" feature, a \"let users compute totals\" feature, a \"let users write rules\" feature — all classic shapes where a developer reaches for eval because writing a parser felt like overkill. It's not overkill; it's the safe shape. Mitigation — restricted evaluator When the codebase truly needs runtime expression evaluation (business rules, formula fields, calculator features), replace eval with a restricted evaluator that only supports the operations the use case requires: expr-eval (npm) — arithmetic + a small set of named functions, no JavaScript globals. In 2025+ remediation work, prefer expr-eval-fork 3.0.1+ or another reviewed maintained parser; avoid the original expr-eval package unless the project carries a reviewed downstream patch for CVE-2025-12735 and CVE-2025-13204. mathjs with an explicit function allowlist — strong scope-control, careful with import/evaluate. A purpose-built parser (Jison, Chevrotain, Nearley) that outputs an AST you walk yourself with no eval in sight. Uplift — replace with the right parser The shape depends on what the input was actually for: JSON-shaped data: JSON.parse. Always. A formula language: a parser library, not eval. A configuration DSL: YAML (safeload) or JSON, not JavaScript. Dynamic UI rules: a structured-rule object the client sends as JSON, evaluated by a typed interpreter. Templates from user input: do not. Compile templates from trusted source only. If users need to \"customize,\" give them a typed schema with named placeholders. Mitigation — CSP unsafe-eval ban For browser code, the page-level mitigation is the Content-Security-Policy header. script-src 'self' (without 'unsafe-eval') makes eval, new Function, and the string-body setTimeout/setInterval throw at the browser level, regardless of what the JavaScript code says. This is a strong control — but it breaks any legitimate eval-using library you ship. Audit before deploying. Inputs Call sites — every eval, new Function, string-body setTimeout/setInterval, vm.runInNewContext, template-compile-on-user-input. Use-case classification — what each call site was actually trying to do. The prompt ~~~markdown You are remediating eval-shape call sites in this repository. Output a PR or a TRIAGE.md. Step 0 — Inventory 1. Grep for eval(, new Function(, setTimeout(\", setInterval(\", vm.runInNewContext, pug.compile, handlebars.compile, lodash.template, .template, Function(. 2. For each call, classify the use case: parsing JSON, evaluating a formula, dynamic configuration, template rendering, or \"unknown / sketchy.\" Step 1 — Pick the replacement per call site JSON-shaped: JSON.parse. Formula: restricted evaluator (expr-eval-fork 3.0.1+, mathjs with allowlist) or a real parser. Configuration: load YAML/JSON instead. Templates: compile only trusted templates; for user-customization, switch to a typed-placeholder schema. String-body setTimeout/setInterval: pass a function reference instead. Unknown / sketchy: triage. Do not auto-replace. Step 2 — Apply the replacement 1. Replace each call site. 2. For formula evaluation, register the allowlist of functions the use case actually needs. Default deny. 3. For template rendering, the source of the template must be a static file or a constant — not a user-supplied string. Step 3 — Tests For each replaced call, add tests: A representative legitimate input produces the same result as the old code (behaviour preservation). An input designed to escape ('; require(\"childprocess\").exec(\"...\")', \"constructor.constructor('return process')()\") is rejected by the new parser. Step 4 — Add the CSP header (browser code) If the application has a browser front-end: 1. Add script-src 'self' (without 'unsafe-eval') to the Content-Security-Policy response header. 2. Add a CSP-violation reporting endpoint and watch for unsafe-eval violations from third-party scripts. 3. Roll out behind report-only mode first when uncertain about third-party usage. Step 5 — Open the PR Branch: remediate/eval-uplift-<module-slug>. Title: [Security][eval] replace eval-shape calls in <module>. Body: per-call-site classification, replacement chosen, tests added, CSP header changes (if any). Label: sec-auto-remediation. Stop conditions A call site classified as \"unknown / sketchy\" — triage, don't auto-replace. The replacement requires a parser library that's not available on the project's runtime version. The CSP header would break a third-party library the application depends on; defer the CSP change until that's resolved. Scope Do not bundle unrelated refactors. Do not silently broaden the allowlist of functions a restricted evaluator exposes. Do not commit the CSP change without report-only validation if there's third-party JS in the application. ~~~ Watch for Function.prototype.constructor.constructor. A classic restricted-evaluator bypass. The replacement parser needs to reject access to constructor, proto, and prototype. Stale \"safe evaluator\" packages. expr-eval is now tracked by CVE-2025-12735 and CVE-2025-13204. A PR that swaps eval for the vulnerable original package should not be accepted as a security fix. Template engines that read from a database. If the template content is dynamic but stored in a \"safe\" place (database, S3), an attacker who can write there can compromise the page. Compiling templates from any user-controlled storage is the same shape as eval on user input. vm module sandboxes leaking. Node's vm module is not a security boundary. Use a real isolate (isolated-vm) if isolation is the goal. Server-side eval in JSON-Schema validators. Some schema-validation libraries compile schemas via new Function. Check the validator's release notes. Output contract PR or TRIAGE.md only; no broad expression-language redesign unless explicitly authorized. Inventory lists every eval, Function, string timer, dynamic template compile, server-side schema compiler, and wrapper helper in scope. Each call site is classified as arithmetic/formula evaluation, dynamic property access, template rendering, timer callback, unknown, or framework-owned. Replacement names the restricted parser, typed dispatch table, static template path, or triage rationale. Tests prove legitimate behavior is preserved and representative escape payloads fail closed. Verification Before opening the PR or final triage note, verify that: no user-controlled string reaches eval, new Function, string timers, or dynamic template compilation; replacement evaluators reject access to constructor, proto__, prototype, globals, imports, filesystem, process, and network primitives; function allowlists are minimal and documented per use case; CSP changes are report-only first when third-party browser scripts are present; no production expressions, private templates, secrets, or customer data are committed as fixtures. Guardrails Do not replace eval with a stale or vulnerable “safe eval” package without checking advisories. Do not treat Node vm as a security sandbox. Do not broaden a formula/function allowlist to make old dynamic behavior pass without owner approval. Do not bundle CSP rollout with unrelated frontend changes. Related Classic Vulnerable Defaults — workflow context. Prototype pollution merges — companion JS pattern.","agent_handoff":{"mcp_lookup_keys":["eval-and-function-constructor","/recipes/general/classic-vulnerable-defaults/eval-and-function-constructor/","recipes/general/classic-vulnerable-defaults/eval-and-function-constructor.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["remediation","risk","code-hygiene"],"source_text_field":"content_text","portable_download":"security-recipe-eval-and-function-constructor.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-eval-and-function-constructor.json"}},{"slug":"java-deserialization","title":"Java ObjectInputStream and friends","link_title":"Java ObjectInputStream","url":"https://security-recipes.ai/recipes/general/classic-vulnerable-defaults/java-deserialization/","path":"/recipes/general/classic-vulnerable-defaults/java-deserialization/","source_file":"recipes/general/classic-vulnerable-defaults/java-deserialization.md","recipe_id":"","recipe_kind":"","category":{"slug":"classic-defaults","label":"Classic Vulnerable Defaults"},"agent":"general","severity":"unspecified","maturity":"development","ecosystem":"","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"","framework_version":"","jurisdiction":"","industry":[],"cve_archetypes":["unsafe_deserialization"],"cve_workflow_role":"remediate","tags":["java","deserialization","uplift","mitigate","jep-290"],"facets":["remediation","risk"],"quality":{"score":95,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"Stephen M Abbott","team":"Security","model":"Opus 4.7","ai_assisted":false,"generated_by":"","date":"2026-04-25","zero_day":false,"last_updated":"2026-04-25","summary":"Replace with JSON serializers; mitigate via JEP 290 deserialization filters with a strict class allowlist.","content_text":"ObjectInputStream.readObject() is the Java equivalent of pickle: a payload of class metadata that the runtime reconstructs, including invoking constructors, setting fields, and triggering readObject / readResolve / finalize on every class in the graph. The \"gadget chains\" that make this exploitable have been written and re-written since 2015; the CVE shelf is full. When to use it Use this recipe when Java code deserializes untrusted bytes with ObjectInputStream, XMLDecoder, or similar polymorphic serializers. Prefer it when the finding is gadget-chain RCE risk rather than a generic SAST deserialization label with no reachable object stream. Do not use it to invent a gadget chain or to test against live untrusted payloads. Pattern new ObjectInputStream(...).readObject() on any network / file / DB-blob input. Frameworks that serialize via Java serialization under the hood: older RMI, JMS, JNDI lookup-with-RemoteObject paths, some session-replication backends. Legacy uses of ObjectInputStream for \"convenient\" same-VM persistence — still dangerous if the file ever reaches a different VM with different classpath assumptions. Why it matters A malicious payload using a known gadget chain (commons- collections, Spring, Groovy, the long-running Pwn-Twitter list) can RCE on readObject() without the application code ever being entered. There is no patch coming; the design predates the threat model. Mitigation — JEP 290 deserialization filters Java 9+ exposes ObjectInputFilter / ObjectInputFilter.Config (and the older setObjectInputFilter API). Set a strict allowlist filter on every ObjectInputStream the application creates: ObjectInputFilter allowlist = ObjectInputFilter.Config.createFilter( \"com.example.Order;com.example.OrderItem;java.lang.Number;\" + \"java.util.ArrayList;java.util.HashMap;\" + \"!\" // reject everything else ); try (ObjectInputStream in = new ObjectInputStream(input)) { in.setObjectInputFilter(allowlist); Object obj = in.readObject(); // ... } Or set it globally at JVM start: -Djdk.serialFilter='com.example.;java.lang.Number;!'. The filter rejects every class outside the allowlist before the class is loaded, before readObject is invoked, before any gadget chain runs. Uplift — replace ObjectInputStream entirely For any new-write path, switch to a JSON serializer with explicit type handling: Jackson with default-typing disabled and @JsonTypeInfo(use=Id.NAME) plus @JsonSubTypes({...}) enumerations on polymorphic fields, or a BasicPolymorphicTypeValidator allowlist if default typing genuinely cannot be removed. Gson with explicit TypeAdapter / RuntimeTypeAdapterFactory registrations. Protobuf when the data is structured enough to warrant a schema. Read paths for legacy data: keep an ObjectInputStream reader with the JEP 290 filter installed until the persisted data has been migrated; then remove the reader. Inputs Call sites — every new ObjectInputStream(...) and every framework call known to deserialize Java objects internally. Strategy — mitigate / uplift / both. The prompt ~~~markdown You are remediating Java deserialization call sites in this repo. Output a PR or a TRIAGE.md. Step 0 — Inventory 1. List every new ObjectInputStream(...) in the repo. 2. List every framework usage that deserializes Java objects internally — check for ObjectMapper.readValue with enableDefaultTyping, RMI registrations, JMS message listeners that trust message bodies, session-replication bindings. 3. For each, record whether the input crosses a trust boundary. Step 1 — Pick the strategy All call sites: mitigate by adding a JEP 290 filter. This is required regardless of any uplift. New-write paths: also uplift to JSON with explicit typing. Legacy read paths: keep the filtered ObjectInputStream until data is migrated. Step 2 — Mitigate 1. Define a single allowlist filter as a constant in a security utility class. 2. Apply the filter to every ObjectInputStream creation. If the codebase has many call sites, factor a safeObjectInputStream(InputStream) helper and migrate to it. 3. Optionally, add the global JEP 290 filter to the application's JVM args / Dockerfile / launcher. 4. Add tests: A payload containing an allowlisted class deserializes successfully. A payload containing a non-allowlisted class (org.apache.commons.collections.functors.InvokerTransformer, java.lang.Runtime) is rejected. Step 3 — Uplift (when applicable) 1. Replace ObjectOutputStream writers with the chosen JSON serializer. 2. Add a behaviour-preservation test that round-trips a representative object through the old binary format and the new JSON format and asserts field-by-field equality. 3. If the codebase persists data: add a one-time migration job that reads old binary files via the filtered ObjectInputStream and writes them as JSON. Document a removal date for the legacy reader. Step 4 — Open the PR Branch: remediate/java-deser-<module-slug>. Title: [Security][deserialization] add JEP 290 filter / uplift to JSON in <module>. Body: call-site inventory, allowlist contents, test additions, migration plan if applicable, and the JVM-args change if global filter applied. Label: sec-auto-remediation. Stop conditions A framework is doing the deserialization and the agent cannot inject a filter. (E.g., a third-party library that exposes no filter hook — flag and triage.) Default typing in Jackson is load-bearing for a feature the agent cannot reshape without an API change. Test coverage on the call path is too thin to detect regressions safely. Scope Do not bundle in unrelated refactors. Do not silently broaden the allowlist. Do not remove the legacy reader without a documented migration. ~~~ Watch for Allowlist drift. A reviewer who adds a class to the allowlist next quarter without re-reading the gadget-chain list defeats the mitigation. Guard with a comment that says so explicitly, and re-review the allowlist quarterly. enableDefaultTyping re-enabled. Jackson will resolve arbitrary classes if default typing is on. The Jackson recipe is a sibling pattern; if the codebase uses it, fix both at once. JNDI lookups in deserialized payloads. Even with a strict filter, some allowed classes can re-trigger lookups — validate the allowlist against the log4j-style JNDI lookups threat surface. Globally setting the JVM filter** can break other applications on the same JVM if any. Prefer per-stream filters when the JVM hosts multiple applications. Output contract PR or TRIAGE.md only; no production data migration without explicit operator approval. Call-site inventory includes every ObjectInputStream, framework deserialization hook, persisted binary payload reader, and writer path found. Mitigation explains the chosen JEP 290 allowlist, global filter, helper wrapper, or JSON uplift strategy. Tests prove allowed payloads still work and representative gadget or non-allowlisted payloads fail closed. Migration notes name any legacy reader, persisted-data format, rollback path, and owner review required before removal. Verification Before opening the PR or final triage note, verify that: every deserialization call site is either filtered, uplifted, or documented as framework-owned with a stop condition; the allowlist is minimal and does not include broad packages, reflective gadget classes, or application superclasses without review rationale; tests cover both accepted and rejected payload paths; no serialized production data, secrets, or customer records are committed as fixtures; reviewers can see whether the fix is mitigation-only, full uplift, or staged migration. Guardrails Keep binary-format compatibility unless the operator approves a migration. Do not broaden an allowlist to make tests pass; fix the model or fixture. Do not remove legacy readers until data migration and rollback are reviewed. Do not attempt live gadget-chain exploitation against production systems. Related Classic Vulnerable Defaults — workflow context. Python pickle — same risk class in Python.","agent_handoff":{"mcp_lookup_keys":["java-deserialization","/recipes/general/classic-vulnerable-defaults/java-deserialization/","recipes/general/classic-vulnerable-defaults/java-deserialization.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["remediation","risk"],"source_text_field":"content_text","portable_download":"security-recipe-java-deserialization.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-java-deserialization.json"}},{"slug":"jwt-alg-none","title":"JWT — `alg: none` and algorithm confusion","link_title":"JWT alg none","url":"https://security-recipes.ai/recipes/general/classic-vulnerable-defaults/jwt-alg-none/","path":"/recipes/general/classic-vulnerable-defaults/jwt-alg-none/","source_file":"recipes/general/classic-vulnerable-defaults/jwt-alg-none.md","recipe_id":"","recipe_kind":"","category":{"slug":"classic-defaults","label":"Classic Vulnerable Defaults"},"agent":"general","severity":"unspecified","maturity":"development","ecosystem":"","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"","framework_version":"","jurisdiction":"","industry":[],"cve_archetypes":[],"cve_workflow_role":"","tags":["jwt","auth","uplift","mitigate"],"facets":["remediation","risk"],"quality":{"score":95,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"Stephen M Abbott","team":"Security","model":"Opus 4.7","ai_assisted":false,"generated_by":"","date":"2026-04-25","zero_day":false,"last_updated":"2026-04-25","summary":"Force an explicit algorithm allowlist on every verify call; reject `none` at the import boundary.","content_text":"JWTs are validated against an alg field the token itself declares. The spec includes none (for \"validation skipped\"); some libraries used to honour it; some still do under specific configurations. A second class of bug — the RS256 → HS256 algorithm-confusion attack — happens when an HMAC-verifier uses the public RSA key as the HMAC secret because the token says alg: HS256. The robust shape is the same in both cases: never trust the alg field. Decide the expected algorithm on the verifier side and refuse anything else. When to use it Use this recipe when a repository verifies JWTs and the verifier might honor the token alg field, accept none, or treat an RSA public key as an HMAC secret. Prefer it over a generic auth audit when the finding is algorithm confusion or a missing algorithms allowlist. Do not use it to weaken signature checks, accept attacker-chosen algorithms, or skip tests that prove legitimate tokens still verify. Pattern jwt.decode(token, key) (PyJWT pre-2.0) without an algorithms=[...] argument. jsonwebtoken.verify(token, secret) (Node.js) without { algorithms: [...] }. JWT.decode(token, key) (Ruby) without explicit algorithm. Jwts.parser().setSigningKey(key).parseClaimsJws(token) (Java jjwt 0.10–) without .parseClaimsJws() / .parserBuilder().setSigningKey(...) with explicit algorithm verification. Any custom verifier that reads header.alg and dispatches. Why it matters A token with alg: none and an empty signature is valid in any library that honours the field — the attacker forges any claim they like. RS256-to-HS256 confusion is subtler: the attacker takes the server's public RSA key (often published in a JWKS), signs an HMAC with it, sets alg: HS256, and the verifier (if naive) treats the public key as the HMAC secret and accepts. Mitigation — algorithm allowlist + import-time monkey patch For codebases with many call sites, add a wrapper that refuses to call any underlying JWT verifier without an explicit algorithm allowlist: Python (PyJWT) import jwt import os origdecode = jwt.decode def safedecode(token, key, algorithms=None, kw): if not algorithms: raise jwt.InvalidAlgorithmError( \"JWT verify requires an explicit algorithms allowlist\" ) if \"none\" in [a.lower() for a in algorithms]: raise jwt.InvalidAlgorithmError(\"JWT alg=none is forbidden\") return origdecode(token, key, algorithms=algorithms, kw) jwt.decode = safedecode Equivalent shims exist for jsonwebtoken (Node) and jwt-ruby. Install at the application's entry point. Uplift — explicit algorithm allowlist at every call The clean fix: payload = jwt.decode( token, key, algorithms=[\"RS256\"], # exactly one, named audience=\"myapi\", issuer=\"https://idp.example\", options={\"require\": [\"exp\", \"iat\", \"aud\", \"iss\", \"sub\"]}, ) Single algorithm, named. Plus require expected claims. Plus verify aud and iss against the application's expected values. Inputs Call sites — every JWT verify call. Algorithm policy — which algorithm(s) the application legitimately uses. Required claims — which claims must be present. The prompt ~~~markdown You are remediating JWT verification call sites. Output a PR or a TRIAGE.md. Step 0 — Inventory 1. List every JWT verification call across the repo. 2. For each, record: the library and version, the current algorithm argument (if any), the key source (HMAC secret vs. RSA/EC public key vs. JWKS endpoint), and the claim expectations. 3. Read the application's auth design docs (if available) to learn the legitimate algorithm. Step 1 — Pick the strategy Always uplift (explicit allowlist on every call). If there are >5 call sites, also install the import-time shim as defence-in-depth. Step 2 — Uplift each call For each verify call, change to: algorithms=[\"<expected-alg>\"] — exactly one, named. Verify aud against the application's expected audience. Verify iss against the application's expected issuer. Require exp, iat, and any other application-required claims. Step 3 — Install the shim (when chosen) 1. Add the wrapper module at a stable import path. 2. Import it from every application entry point. 3. Add a unit test that calls jwt.decode without an algorithms argument and asserts the wrapper rejects. Step 4 — Tests Add tests: A token signed with the wrong algorithm is rejected. A token with alg: none is rejected. A token with alg: HS256 and the public RSA key as the \"secret\" is rejected. A token with alg: <expected> and the right key but wrong aud is rejected. A valid token is accepted. Step 5 — Open the PR Branch: remediate/jwt-alg-allowlist-<short-slug>. Title: [Security][jwt] enforce algorithm allowlist on every verify. Body: call-site inventory, algorithm chosen per call, shim installation, test additions, and a follow-up checklist for any service whose tokens did not declare a single algorithm. Label: sec-auto-remediation. Stop conditions A service legitimately accepts multiple algorithms (e.g., during a key-rotation window). Confirm with the auth team before allowlisting both; do not silently widen the allowlist. The verification path uses a custom signature implementation the agent cannot reason about safely. Tests on unrelated code break in ways the agent cannot resolve without touching auth logic. Scope Do not change token issuance. This recipe is for verifiers. Do not change key material. Do not bundle unrelated auth refactors. ~~~ Watch for Multi-algorithm services during key rotation. During rotation, allowlists may legitimately include both old and new. Document the window and remove the old algorithm on schedule. JWKS keys with alg unset. Some IdPs ship JWKS without alg; the verifier must enforce the expected algorithm even when JWKS doesn't constrain it. kid confusion. A token can name a JWKS key id; if the verifier trusts the kid to pick the algorithm, you've re-introduced algorithm confusion through the back door. Decide the algorithm on the server, not the token. exp without skew. Refusing tokens for sub-second clock skew is an availability bug. Allow a small skew (e.g., 60 seconds) — but no more. Output contract PR or TRIAGE.md only; no token issuance, key rotation, or auth-provider configuration changes unless explicitly requested. Inventory lists every JWT verification call, wrapper helper, middleware, gateway, and test helper in scope. Each verifier has an expected algorithm allowlist, key source, issuer, audience, and clock-skew policy. Tests reject alg: none, wrong algorithm, algorithm/key confusion, bad audience, and expired tokens while accepting one valid token. Any multi-algorithm exception includes owner approval, rotation window, and removal follow-up. Verification Before opening the PR or final triage note, verify that: no verifier trusts the token header to choose the algorithm; JWKS kid lookup cannot switch algorithm families or key types; algorithm allowlists are explicit at every decode/verify call; issuer, audience, expiry, and skew checks remain intact; test fixtures do not contain live signing keys, production tokens, or customer claims. Guardrails Do not alter token issuance or key material in this recipe. Do not silently allow multiple algorithms to preserve compatibility. Do not weaken issuer, audience, expiry, or key-use checks while fixing the algorithm allowlist. Do not include production JWTs in tests or reports. Related Classic Vulnerable Defaults — workflow context. OWASP Top 10:2025 -> A07 Authentication Failures — broader auth-failure pattern.","agent_handoff":{"mcp_lookup_keys":["jwt-alg-none","/recipes/general/classic-vulnerable-defaults/jwt-alg-none/","recipes/general/classic-vulnerable-defaults/jwt-alg-none.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["remediation","risk"],"source_text_field":"content_text","portable_download":"security-recipe-jwt-alg-none.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-jwt-alg-none.json"}},{"slug":"php-unserialize","title":"PHP object deserialization — `unserialize` on untrusted data","link_title":"PHP unserialize","url":"https://security-recipes.ai/recipes/general/classic-vulnerable-defaults/php-unserialize/","path":"/recipes/general/classic-vulnerable-defaults/php-unserialize/","source_file":"recipes/general/classic-vulnerable-defaults/php-unserialize.md","recipe_id":"","recipe_kind":"","category":{"slug":"classic-defaults","label":"Classic Vulnerable Defaults"},"agent":"general","severity":"unspecified","maturity":"development","ecosystem":"","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"","framework_version":"","jurisdiction":"","industry":[],"cve_archetypes":["unsafe_deserialization"],"cve_workflow_role":"remediate","tags":["php","deserialization","uplift","mitigate"],"facets":["remediation","risk"],"quality":{"score":95,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"Stephen M Abbott","team":"Security","model":"Opus 4.7","ai_assisted":false,"generated_by":"","date":"2026-04-26","zero_day":false,"last_updated":"2026-04-26","summary":"Replace unsafe `unserialize` usage with JSON or strict allowed-class deserialization; add tests that preserve payload behavior.","content_text":"unserialize($POST[\"data\"]) is a long-lived PHP footgun. When attacker-controlled bytes hit unserialize, PHP can instantiate gadget objects and trigger magic methods such as wakeup / destruct. That's object-injection territory, with real-world RCE chains in common ecosystems. When to use it Use this recipe when PHP unserialize() (or equivalent) processes data that can be influenced by an untrusted caller. Prefer it over a generic PHP audit when the call site is the finding. Do not use it to craft POP gadget chains or to deserialize production session blobs as a proof. Pattern unserialize($input) where $input comes from HTTP, cookies, message queues, or user-editable DB fields. Session or cache adapters that deserialize values from shared stores without strict provenance checks. Framework wrappers that indirectly call unserialize (custom middleware, queue/job payload handling). Why it matters Unsafe deserialization in PHP is frequently exploitable via POP (property-oriented programming) chains. Even when no direct RCE exists, object injection can corrupt authorization state, overwrite files, or invoke network callbacks through gadget classes. Mitigation — constrain classes immediately If a full migration cannot ship in one PR, use strict class allowlisting and fail closed: <?php $decoded = unserialize($payload, ['allowedclasses' => false]); Or, where specific DTO classes are required: <?php $decoded = unserialize($payload, ['allowedclasses' => [OrderDTO::class]]); Pair this with input provenance checks and rejection logging. Uplift — replace with JSON (or schema-validated format) Preferred uplift: Replace serialized object payloads with JSON arrays/maps. Hydrate explicit DTOs from decoded arrays. Validate shape and types at boundaries before use. Keep a temporary legacy-read path only for migration windows, with telemetry and a removal date. Inputs Call sites — all unserialize invocations and wrappers. Trust boundary — where each payload originates. Compat constraints — which payload formats must continue to round-trip during migration. The prompt ~~~markdown You are remediating unsafe PHP deserialization call sites. Output a PR or a TRIAGE.md. Step 0 — Inventory 1. Search for unserialize( and wrappers around payload decode. 2. For each call site, record source of bytes and whether input can be attacker-controlled. 3. Identify classes currently instantiated by deserialize paths. Step 1 — Decide per call site Untrusted / ambiguous input: uplift to JSON + DTO hydrate. Trusted-only legacy path with hard dependency: mitigate with allowedclasses and explicit provenance checks. Cannot classify trust boundary: triage. Step 2 — Implement For uplifted sites: 1. Replace serialize/unserialize with jsonencode/jsondecode(..., true, flags). 2. Add boundary validation for required keys and value types. 3. Convert arrays into explicit DTO/value objects. For mitigated sites: 1. Add allowedclasses with the narrowest possible list (false whenever feasible). 2. Reject and log payloads that require disallowed classes. Step 3 — Tests Add behavior-preservation tests: Existing valid payloads still decode to expected domain values. A payload requiring a disallowed class is rejected. Malformed payloads fail closed. Step 4 — Open the PR Branch: remediate/php-unserialize-<module-slug>. Title: [Security][PHP] remediate unserialize in <module>. Body: inventory, trust-boundary classification, uplift vs mitigation, compatibility plan, tests. Label: sec-auto-remediation. Stop conditions You cannot identify payload provenance. Migration requires coordinated cross-service schema rollout not feasible in one PR. No test harness exists for the affected decode path. Scope Do not bundle unrelated refactors. Do not expand allowed class lists beyond what tests require. Do not silently keep legacy deserialize paths without a dated removal note. ~~~ Watch for Framework internals that deserialize session/queue data; ensure your target call sites are truly app-controlled. Base64 wrappers around serialized bytes (easy to miss in grep). “Trusted DB” assumptions where user-controlled values are eventually written into that table. Over-broad allowlists that reintroduce gadget surfaces. Output contract PR or TRIAGE.md only; no coordinated cross-service schema migration unless explicitly approved. Inventory lists every unserialize, wrapper decoder, base64 payload wrapper, session/queue deserializer, and class reachable from deserialize paths. Each call site is classified as untrusted, trusted-only legacy, ambiguous, or framework-owned. Fix is labeled as JSON/DTO uplift, allowedclasses mitigation, or triage. Tests prove valid payloads still decode, disallowed classes are rejected, and malformed payloads fail closed. Verification Before opening the PR or final triage note, verify that: attacker-controlled or ambiguous payloads do not reach unrestricted unserialize; allowed_classes is false or narrowly enumerated with class rationale; legacy serialized data has a dated removal or migration note; framework/session internals are not changed unless explicitly in scope; no production serialized blobs, secrets, or customer data are committed as fixtures. Guardrails Do not expand allowed class lists to make tests pass without owner review. Do not assume database-stored serialized data is trusted if users can write to that table indirectly. Do not remove compatibility readers without migration and rollback planning. Do not bundle unrelated DTO or framework refactors. Related Classic Vulnerable Defaults — workflow context. Java ObjectInputStream — analogous deserialization risk in JVM stacks.","agent_handoff":{"mcp_lookup_keys":["php-unserialize","/recipes/general/classic-vulnerable-defaults/php-unserialize/","recipes/general/classic-vulnerable-defaults/php-unserialize.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["remediation","risk"],"source_text_field":"content_text","portable_download":"security-recipe-php-unserialize.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-php-unserialize.json"}},{"slug":"prototype-pollution-merge","title":"Prototype pollution — `merge`, `assign`, and friends","link_title":"Prototype pollution merges","url":"https://security-recipes.ai/recipes/general/classic-vulnerable-defaults/prototype-pollution-merge/","path":"/recipes/general/classic-vulnerable-defaults/prototype-pollution-merge/","source_file":"recipes/general/classic-vulnerable-defaults/prototype-pollution-merge.md","recipe_id":"","recipe_kind":"","category":{"slug":"classic-defaults","label":"Classic Vulnerable Defaults"},"agent":"general","severity":"unspecified","maturity":"development","ecosystem":"","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"","framework_version":"","jurisdiction":"","industry":[],"cve_archetypes":[],"cve_workflow_role":"","tags":["javascript","prototype-pollution","uplift","mitigate"],"facets":["remediation","risk"],"quality":{"score":95,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"Stephen M Abbott","team":"Security","model":"Opus 4.7","ai_assisted":false,"generated_by":"","date":"2026-04-25","zero_day":false,"last_updated":"2026-04-25","summary":"Filter `__proto__` / `constructor` / `prototype` keys at parse boundaries; replace hand-rolled merges with vetted utilities.","content_text":"JavaScript objects inherit from Object.prototype. A function that recursively merges a user-controlled JSON payload into an internal object can — if it doesn't filter proto, constructor, or prototype keys — modify the prototype, which then leaks into every other object in the runtime. The attack vector is decades old; the unsafe shape is still the default in many homemade merge and extend utilities. When to use it Use this recipe when JavaScript or TypeScript merges, assigns, or recursively copies attacker-influenced objects without blocking proto, constructor, or prototype. Prefer it when the sink is a merge utility or recursive assign, not a general XSS finding. Do not use it to pollute Object.prototype in shared environments as a demonstration. Pattern The vulnerable shape: function merge(target, source) { for (const key in source) { if (typeof source[key] === \"object\") { target[key] = target[key] || {}; merge(target[key], source[key]); } else { target[key] = source[key]; } } return target; } merge({}, JSON.parse(userInput)); A userInput of {\"proto\": {\"isAdmin\": true}} makes every object in the runtime suddenly have isAdmin: true. Equivalent shapes appear in: Hand-rolled merge / extend / assign / set / setProperty utilities. Some old versions of lodash.merge, lodash.set, lodash.defaultsDeep (patched, but pinned-old versions still appear in repos). Express middleware that maps query strings or request bodies directly into options objects. Form-handling libraries that build nested objects from nested[a][b] form keys without filtering. React state-update reducers that spread user-controlled payloads. Why it matters A polluted prototype changes the behaviour of code far away from the call site. The classic exploit is making authorization checks return true; subtler ones change default-handling in libraries, set unexpected event handlers, or break framework invariants. SAST scanners catch only the most obvious shapes. Mitigation — key filter at the boundary Add a global filter that strips proto, constructor, and prototype keys from every parsed user payload before it reaches application code: function stripDangerousKeys(value) { if (Array.isArray(value)) return value.map(stripDangerousKeys); if (value && typeof value === \"object\") { const out = Object.create(null); for (const key of Object.keys(value)) { if (key === \"proto\" || key === \"constructor\" || key === \"prototype\") { continue; } out[key] = stripDangerousKeys(value[key]); } return out; } return value; } Wrap the application's body-parser, query-parser, and JSON.parse boundary so every external object passes through the filter once. For Node, Object.freeze(Object.prototype) at startup is a nuclear-grade defence — but it breaks libraries that legitimately mutate the prototype. Test before deploying. Uplift — replace home-rolled merge with vetted utilities Vetted merge libraries: deepmerge (current versions filter), merge-deep (current versions), lodash.merge (post-4.17.20). Pin to the patched version and pin forward. Null-prototype objects: Object.create(null) for any object built from user input — it has no prototype to pollute. structuredClone: for cases where the merge can be replaced with \"clone the user input and overlay it onto a fresh defaults object,\" structuredClone (Node 17+, modern browsers) is a safe primitive. Object.assign is fine — it doesn't recurse, so prototype-pollution payloads don't propagate. Many hand-rolled merge functions are used where Object.assign would be enough. Inputs Call sites — every hand-rolled merge / extend / set function and every entry-point that maps user input into nested objects. Library versions — for any merge utility, the pinned version. The prompt ~~~markdown You are remediating prototype-pollution surface in this JavaScript / TypeScript repo. Output a PR or a TRIAGE.md. Step 0 — Inventory 1. Grep for hand-rolled merge functions: function merge(, function extend(, function deepMerge(, recursive for-in loops that assign into nested objects. 2. Identify every entry-point that parses user input into nested objects: body-parser, qs.parse with allowPrototypes, form-data parsers, GraphQL resolvers that spread untyped variables. 3. Check pinned versions of lodash, deepmerge, hoek, merge-deep, defaults-deep. Anything pinned old is a suspect. Step 1 — Pick the strategy Hand-rolled merge: uplift to a vetted library, and install the boundary filter for defence-in-depth. Old-pinned vetted library: bump to the patched version, install the boundary filter. Boundary parsers without filtering: install the boundary filter. Step 2 — Install the boundary filter 1. Add the stripDangerousKeys utility (or import a maintained equivalent) at a stable module path. 2. Wrap every parsed-from-user-input boundary: Express body-parser: replace app.use(express.json()) with a wrapper that filters after parse. Form parsers: filter after parse. JSON.parse(req.body): wrap with the filter. 3. Use Object.create(null) for any object built from user input where the application logic doesn't depend on Object.prototype methods being inherited. Step 3 — Replace hand-rolled merges For each hand-rolled merge: 1. Identify the closest vetted equivalent (Object.assign, lodash.merge@latest, deepmerge, structuredClone). 2. Replace the hand-rolled function. Delete the old one if no callers remain. 3. If the hand-rolled merge had application-specific behaviour (e.g., array concatenation rules), encode that behaviour in the vetted library's options. Step 4 — Tests Add tests: A proto payload: the merge does not set Object.prototype.<key>. A constructor.prototype payload: same assertion. A normal nested payload: the merge produces the expected object (behaviour preservation). After the request returns, ({}).polluted is undefined (no leakage to other objects in the runtime). Step 5 — Open the PR Branch: remediate/proto-pollution-<module-slug>. Title: [Security][prototype-pollution] filter dangerous keys at <module>. Body: call-site inventory, library bumps, boundary filter installation, tests added. Label: sec-auto-remediation. Stop conditions The codebase legitimately uses proto as a property name (rare; if so, document and triage). A merge utility's behaviour-preservation test fails on a normal payload after the swap. Triage. Object.freeze(Object.prototype) would break load-bearing libraries; defer that mitigation. Scope Do not bundle unrelated refactors. Do not silently broaden the boundary filter to permit dangerous keys. Do not delete hand-rolled merges that are still called by code outside this PR's scope. ~~~ Watch for Object.assign mistaken for the unsafe pattern. It isn't — Object.assign does shallow assignment and ignores proto as a key (it's a getter, not a writable property on plain objects). The audit should keep it. qs.parse with allowPrototypes: true. Some legacy Express apps set this. Remove. Object.create(null) breaking libraries that expect .hasOwnProperty. Use Object.prototype.hasOwnProperty.call(obj, k) instead. GraphQL variables. Mapping untyped GraphQL variables into nested option objects is a common entry-point. TypeScript doesn't save you. A type assertion on a parsed JSON payload is not a runtime check. The boundary filter is. Output contract PR or TRIAGE.md only; no broad framework rewrites unless explicitly authorized. Inventory lists every deep merge, query/body parser, config merge, GraphQL variable mapper, and object-construction helper in scope. Boundary filter behavior is documented, including rejected keys and where the filter is applied. Tests cover proto, constructor.prototype, normal nested payloads, and runtime leakage checks. Any replacement merge library or version bump is named with behavior preservation notes. Verification Before opening the PR or final triage note, verify that: dangerous keys are blocked at the first trust boundary, not only at one sink; normal nested object behavior is preserved by tests; Object.prototype remains unmodified after malicious payload handling; parser options such as allowPrototypes are searched and hardened; no unrelated serialization, validation, or API-shape refactors are bundled. Guardrails Do not permit dangerous keys for compatibility without owner review. Do not rely on TypeScript types as runtime validation. Do not freeze global prototypes if load-bearing libraries would break. Do not delete hand-rolled merge helpers until all callers are accounted for. Related Classic Vulnerable Defaults — workflow context. eval and Function constructor — companion JavaScript pattern.","agent_handoff":{"mcp_lookup_keys":["prototype-pollution-merge","/recipes/general/classic-vulnerable-defaults/prototype-pollution-merge/","recipes/general/classic-vulnerable-defaults/prototype-pollution-merge.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["remediation","risk"],"source_text_field":"content_text","portable_download":"security-recipe-prototype-pollution-merge.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-prototype-pollution-merge.json"}},{"slug":"python-pickle","title":"Python pickle / dill on untrusted input","link_title":"Python pickle / dill","url":"https://security-recipes.ai/recipes/general/classic-vulnerable-defaults/python-pickle/","path":"/recipes/general/classic-vulnerable-defaults/python-pickle/","source_file":"recipes/general/classic-vulnerable-defaults/python-pickle.md","recipe_id":"","recipe_kind":"","category":{"slug":"classic-defaults","label":"Classic Vulnerable Defaults"},"agent":"general","severity":"unspecified","maturity":"development","ecosystem":"","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"","framework_version":"","jurisdiction":"","industry":[],"cve_archetypes":["unsafe_deserialization"],"cve_workflow_role":"remediate","tags":["python","deserialization","pickle","uplift","mitigate"],"facets":["remediation","risk"],"quality":{"score":95,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"Stephen M Abbott","team":"Security","model":"Opus 4.7","ai_assisted":false,"generated_by":"","date":"2026-04-25","zero_day":false,"last_updated":"2026-04-25","summary":"Replace pickle on untrusted input; mitigate via a restricted unpickler with an explicit class allowlist.","content_text":"pickle.load, pickle.loads, cPickle.load, dill.load, and their friends are arbitrary-code-execution primitives when fed untrusted input. The Python docs say so plainly. The CVE trail is decades long. The unsafe behaviour is the design — pickle is meant to reconstruct any Python object, including ones whose reduce runs code. When to use it Use this recipe when Python pickle, dill, or similar serializers load bytes that are not from a mutually trusted process. Prefer it when the finding is an untrusted pickle sink rather than a generic serialization review. Do not use it to execute pickle payloads or to load production model files as a proof of exploitability. Pattern Any of: pickle.load(f), pickle.loads(s), cPickle.load(f), cPickle.loads(s). dill.load(f), dill.loads(s) (same problem, larger surface). joblib.load(path) when the path is user-controlled. numpy.load(allowpickle=True) on user files (silent default before 1.16.3 was unsafe; current default is safe but the flag is often re-enabled in legacy code). torch.load(path) (Python 2.6+ pickling underneath; safer options now exist as of PyTorch 2.5+). Why it matters A pickled payload can carry a reduce that returns (os.system, (\"rm -rf /\",)) — pickle.load happily executes it. There is no patch coming. Reading attacker-controlled pickles is RCE. Mitigation — restricted unpickler When the call is on a backwards-compat read path (a legacy checkpoint format, an old persistence file), wrap the unpickler: import pickle, io class SafeUnpickler(pickle.Unpickler): ALLOWED = { (\"builtins\", \"dict\"), (\"builtins\", \"list\"), (\"builtins\", \"set\"), (\"builtins\", \"tuple\"), # Add only the application-specific classes # that legitimately round-trip through pickle. } def findclass(self, module, name): if (module, name) in self.ALLOWED: return super().findclass(module, name) raise pickle.UnpicklingError(f\"forbidden: {module}.{name}\") def safeloads(data: bytes): return SafeUnpickler(io.BytesIO(data)).load() Every rejection logs at WARN. The allowlist is the policy; it is narrow on purpose. Uplift — replace pickle entirely Default replacement choices: JSON (json.dumps / json.loads) — when the data is already a tree of primitives. msgpack — when binary payload size matters. protobuf / pydantic JSON — when the data has a schema worth declaring. For ML-shaped state: safetensors for weights, JSON for metadata. Behaviour preservation: round-trip a representative payload through the old pickle.dumps and the new serializer; assert the in-memory shape matches. Inputs Call site — file + line range. Data path — where the input comes from (file, network, user-uploaded, intra-process). Replacement strategy — uplift / mitigate / both. The prompt ~~~markdown You are remediating one Python pickle call site. Output a PR or a TRIAGE.md. Step 0 — Read the call site and trace input 1. Read the function containing the pickle call. Identify the input source (file handle, bytes, network payload). 2. If the input is provably trusted-only (e.g., a file written in the same process, never read across a trust boundary), stop and write a triage note documenting the trust boundary — do not auto-replace. Step 1 — Pick the strategy If the call is on a backwards-compat read path with active callers reading legacy data, do mitigate. Otherwise do uplift. For checkpoint loaders that take user-supplied paths, do both — mitigate the legacy path, uplift the write path. Step 2 — Mitigate (when applicable) 1. Add a SafeUnpickler subclass with an explicit class allowlist scoped to the classes that legitimately round-trip here. Log rejections at WARN. 2. Replace the pickle.load(f) call with the safe wrapper. 3. Add a unit test that loads a known-good payload (passes) and a payload referencing os.system (raises UnpicklingError). Step 3 — Uplift (when applicable) 1. Choose the replacement format from this list, in order: JSON if the payload is primitives, msgpack if binary size matters, protobuf/pydantic if schema is worth declaring, safetensors+JSON for ML weights. 2. Add a writer that emits the new format, and a reader that parses it. 3. If old data exists, add a one-time migration that reads the pickle (via the SafeUnpickler from Step 2) and writes the new format. The migration is its own commit. 4. Add a behaviour-preservation test that asserts the in-memory shape after uplift matches what the old pickle would have produced. Step 4 — Open the PR Branch: remediate/pickle-<short-slug>. Title: [Security][pickle] replace untrusted-input pickle in <module>. Body must include: input-source analysis, strategy chosen, test plan, legacy data migration plan if any, and a follow-up checklist for adjacent pickle call sites that this PR did not touch. Label: sec-auto-remediation. Stop conditions Input source cannot be classified as untrusted vs. trusted. Replacement requires a coordinated migration across repos. Test coverage on the call path is too thin to detect regressions. Scope Do not touch other pickle call sites in the repo. One per PR. Do not silently broaden the SafeUnpickler allowlist beyond the classes the local code actually uses. Do not remove the legacy read-path without a documented data migration. ~~~ Watch for *reduce in tests. Some test suites legitimately pickle and unpickle custom classes. Don't break those — add the classes to the allowlist explicitly. numpy.load(allowpickle=True) left enabled. Often a copy-paste from a stack-overflow answer. The default is safe now; flip it back. torch.load on a user-supplied path. The mitigation shape depends on the PyTorch version; check the loader's weightsonly parameter (PyTorch 2.5+ defaults it true). Cross-version pickles. A pickle written by Python 3.11 may not round-trip cleanly on 3.9. The behaviour-preservation test catches this. Output contract PR or TRIAGE.md only; no production data migration unless explicitly approved. Inventory names every pickle, dill, joblib, numpy.load, torch.load, and wrapper-loader call in scope. Strategy is clearly labeled as block, SafeUnpickler mitigation, format uplift, or triage-only. Tests cover a known-good payload and a representative unsafe payload or unsafe-loader configuration. Migration notes identify legacy data, reader compatibility, rollback, and owner approval before removal. Verification Before opening the PR or final triage note, verify that: untrusted input cannot reach a general-purpose pickle loader; any allowlist is minimal, local to the call path, and documented with class rationale; ML/model loaders use safer options such as weightsonly where available; no production pickles, customer data, private model weights, or credentials are committed as fixtures; reviewers can tell whether the fix is temporary mitigation or permanent serialization uplift. Guardrails Do not broaden SafeUnpickler allowlists to make old fixtures pass. Do not remove legacy readers without a migration and rollback plan. Do not run untrusted pickle payloads outside isolated unit tests. Do not mix unrelated serialization refactors into the same PR. Related Classic Vulnerable Defaults — workflow context. PyYAML yaml.load — sibling pattern with a different fix. Java ObjectInputStream — same pattern in Java.","agent_handoff":{"mcp_lookup_keys":["python-pickle","/recipes/general/classic-vulnerable-defaults/python-pickle/","recipes/general/classic-vulnerable-defaults/python-pickle.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["remediation","risk"],"source_text_field":"content_text","portable_download":"security-recipe-python-pickle.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-python-pickle.json"}},{"slug":"pyyaml-load","title":"PyYAML `yaml.load` without a safe Loader","link_title":"PyYAML yaml.load","url":"https://security-recipes.ai/recipes/general/classic-vulnerable-defaults/pyyaml-load/","path":"/recipes/general/classic-vulnerable-defaults/pyyaml-load/","source_file":"recipes/general/classic-vulnerable-defaults/pyyaml-load.md","recipe_id":"","recipe_kind":"","category":{"slug":"classic-defaults","label":"Classic Vulnerable Defaults"},"agent":"general","severity":"unspecified","maturity":"development","ecosystem":"","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"","framework_version":"","jurisdiction":"","industry":[],"cve_archetypes":["unsafe_deserialization"],"cve_workflow_role":"remediate","tags":["python","yaml","deserialization","uplift","mitigate"],"facets":["remediation","risk"],"quality":{"score":95,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"Stephen M Abbott","team":"Security","model":"Opus 4.7","ai_assisted":false,"generated_by":"","date":"2026-04-25","zero_day":false,"last_updated":"2026-04-25","summary":"Default to `yaml.safe_load`; install an import-time shim that defaults the loader for legacy callers.","content_text":"yaml.load(s) — without an explicit Loader= — was unsafe by default for over a decade. The default loader resolves !!python/object tags, which is the YAML equivalent of pickle: arbitrary code execution on untrusted input. PyYAML 5.1 added a warning, 6.0 made the warning louder; the call shape is still out there in repos by the thousands. When to use it Use this recipe when Python calls yaml.load without a safe Loader on data that is not fully trusted. Prefer it over CVE-2017-18342 when the issue is the local call site rather than a pinned PyYAML version. Do not use it to execute YAML tags or to load production secrets as a test. Pattern yaml.load(s) — no Loader= argument. yaml.load(s, Loader=yaml.Loader) — explicit unsafe loader. yaml.load(s, Loader=yaml.UnsafeLoader) — same, named. yaml.fullload(s) — looser than safeload; resolves arbitrary types, just not arbitrary Python. The safe shapes: yaml.safeload(s) — refuses every Python tag. Almost always the right answer. yaml.load(s, Loader=yaml.SafeLoader) — same thing, more verbose. Why it matters !!python/object/apply:os.system [\"rm -rf /\"] …is a payload yaml.load will happily execute. There is no patch coming; safeload is the patch. Mitigation — monkey-patch at import When the repo has dozens of call sites, replacing every one in a single PR is risky. The mitigation is a one-line shim that makes the unsafe loader behave like the safe one: importable as e.g. import myapp.yamlsafetyshim import yaml import warnings origload = yaml.load def safeload(stream, Loader=None, kwargs): if Loader in (None, yaml.Loader, yaml.UnsafeLoader, yaml.FullLoader): warnings.warn( \"yaml.load shimmed to SafeLoader\", stacklevel=2, ) return origload(stream, Loader=yaml.SafeLoader, kwargs) return origload(stream, Loader=Loader, kwargs) yaml.load = safeload Import this shim once at the application's entry point. Every unsafe call now warns at runtime and decodes safely. Uplift — replace each call The clean fix: replace every yaml.load(s) with yaml.safeload(s). Mechanical change. A repo-wide search and a sed-equivalent is enough for most cases — but the agent inspects each call to confirm the data flow and adds a behaviour-preservation test. Inputs Call sites — list of files / lines where yaml.load appears. Strategy — uplift each / install shim / both. The prompt ~~~markdown You are remediating PyYAML yaml.load call sites that resolve unsafe tags. Output a PR or a TRIAGE.md. Step 0 — Inventory 1. List every yaml.load, yaml.fullload, yaml.load(..., Loader=yaml.Loader), yaml.load(..., Loader=yaml.UnsafeLoader), yaml.load(..., Loader=yaml.FullLoader) call in the repo. 2. For each call, record whether the input is untrusted (file uploaded by a user, fetched from a URL, parsed from a request body) or trusted-only (a config file written by the same process). Step 1 — Pick the strategy ≤5 call sites or all in application code: uplift each call site directly to yaml.safeload. Many call sites or the codebase imports through helpers: install the import-time shim and still uplift the call sites that legitimately need a non-default loader. Trusted-only call sites: still uplift; the safe loader costs nothing on trusted input. Step 2 — Uplift 1. Replace yaml.load(s) with yaml.safeload(s). 2. Replace yaml.load(s, Loader=yaml.Loader) with yaml.safeload(s). 3. If the call truly needs a non-Safe loader (e.g., the YAML carries a custom tag this codebase legitimately registers), keep the explicit loader and document why in a comment with a # noqa: yaml-load-policy marker. 4. Add a unit test: a payload containing !!python/object/apply:os.system [\"echo pwned\"] must raise yaml.constructor.ConstructorError after the change. Step 3 — Install the shim (when chosen) 1. Add the shim module at a stable import path (<package>/yamlsafetyshim.py). 2. Import the shim from the application's entry point(s). 3. Add a unit test that imports the shim, calls yaml.load without a Loader, and confirms the SafeLoader was used. Step 4 — Open the PR Branch: remediate/yaml-safe-load-<short-slug>. Title: [Security][yaml] use safeload on untrusted YAML. Body: per-call-site analysis, strategy chosen, test additions, the # noqa exceptions if any. Label: sec-auto-remediation. Stop conditions The codebase relies on a custom YAML tag that requires yaml.Loader and the agent can't determine whether the custom tag's resolver is itself safe. Tests fail because of a legitimate behaviour change in unrelated code. Scope Do not change YAML files themselves. Do not add new YAML tags. Do not bundle in unrelated refactors. ~~~ Watch for yaml.load(s, Loader=Loader) where Loader is a custom subclass. Custom loaders may already be safe. Read the subclass before swapping. yaml.loadall and yaml.fullloadall. Same problem, same fix — yaml.safeloadall. The shim breaking custom-tag YAML in the repo's own config files. The shim opts out only when an explicit Loader is passed; verify all legitimate custom-tag callers pass an explicit Loader. Output contract PR or TRIAGE.md only; no YAML data-file rewrites unless explicitly asked. Call-site inventory lists every unsafe loader, wrapper helper, and loadall variant with trusted/untrusted input classification. Diff replaces unsafe defaults with safeload/safeloadall or documents a reviewed explicit-loader exception. Tests include an unsafe Python tag payload that fails closed and a legitimate YAML fixture that still parses. Any import-time shim names its entry points, opt-out behavior, and test coverage. Verification Before opening the PR or final triage note, verify that: every yaml.load, fullload, unsafe Loader, and load_all call is handled or listed as a stop condition; custom loaders are read before replacement and exceptions include a local rationale; unsafe Python object construction payloads fail with SafeLoader behavior; no production secrets or customer YAML documents are added as fixtures; the report states whether the selected strategy was direct uplift, shim plus uplift, or triage-only. Guardrails Do not add new YAML tags to preserve behavior without owner review. Do not hide loader exceptions in broad try/except blocks. Do not treat trusted-only config as permanently safe; prefer safe loaders unless a custom tag is required and reviewed. Do not bundle dependency upgrades or formatting churn into the same PR. Related Classic Vulnerable Defaults — workflow context. Python pickle — same risk class, different syntax.","agent_handoff":{"mcp_lookup_keys":["pyyaml-load","/recipes/general/classic-vulnerable-defaults/pyyaml-load/","recipes/general/classic-vulnerable-defaults/pyyaml-load.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["remediation","risk"],"source_text_field":"content_text","portable_download":"security-recipe-pyyaml-load.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-pyyaml-load.json"}},{"slug":"requests-verify-false","title":"Disabled TLS verification — `verify=False` and friends","link_title":"Disabled TLS verification","url":"https://security-recipes.ai/recipes/general/classic-vulnerable-defaults/requests-verify-false/","path":"/recipes/general/classic-vulnerable-defaults/requests-verify-false/","source_file":"recipes/general/classic-vulnerable-defaults/requests-verify-false.md","recipe_id":"","recipe_kind":"","category":{"slug":"classic-defaults","label":"Classic Vulnerable Defaults"},"agent":"general","severity":"unspecified","maturity":"development","ecosystem":"","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"","framework_version":"","jurisdiction":"","industry":[],"cve_archetypes":[],"cve_workflow_role":"","tags":["tls","http-client","uplift","mitigate"],"facets":["remediation","risk"],"quality":{"score":95,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"Stephen M Abbott","team":"Security","model":"Opus 4.7","ai_assisted":false,"generated_by":"","date":"2026-04-25","zero_day":false,"last_updated":"2026-04-25","summary":"Install the right CA bundle; add a fail-closed shim that refuses `verify=False` outside an opt-in test environment.","content_text":"requests.get(url, verify=False) is the line of Python that disables TLS certificate verification. It's also one of the most-copy-pasted lines on Stack Overflow. Equivalent lines exist in every language's HTTP client. Each of them transforms a secure channel into a man-in-the-middleable one. There is no patch coming; the fix is \"stop disabling verification, configure the client correctly.\" When to use it Use this recipe when HTTP clients disable TLS certificate verification (verify=False, CURLOPTSSLVERIFYPEER=0, InsecureSkipVerify, and equivalents) outside a tightly scoped test harness. Prefer it over a broad TLS audit when the change is restoring verification and installing the right CA bundle. Do not use it to permanently disable verification or to ship a custom trust store that includes untrusted CAs. Pattern Python. requests.get(url, verify=False), urllib3.disablewarnings(), httpx.Client(verify=False), aiohttp.ClientSession(connector=TCPConnector(ssl=False)). Node. https.Agent({ rejectUnauthorized: false }), axios.create({ httpsAgent: new https.Agent({...}) }), process.env.NODETLSREJECTUNAUTHORIZED = \"0\". Java. HttpsURLConnection.setDefaultHostnameVerifier((h, s) -> true), SSLContext with a trust-all TrustManager. Go. &tls.Config{InsecureSkipVerify: true}. curl. --insecure / -k baked into shell scripts and CI steps. Environment overrides. PYTHONHTTPSVERIFY=0, GITSSLNOVERIFY=true, HTTPSPROXY pointing to a proxy with cert-stripping. Why it matters Disabled verification means an attacker on the network path can substitute their own certificate, decrypt the traffic, and re-encrypt to the real endpoint. The application sees a normal response. Credentials, tokens, and personal data flow in the clear to the attacker. The CVE shelf is not where this lives; it lives in incident reports. Mitigation — fail-closed monkey patch For the cases where the codebase has many verify=False calls and a coordinated cleanup is impractical, install an import-time shim that refuses to honour verify=False outside of an opt-in test environment: Python import os, requests, ssl, warnings if os.environ.get(\"ENV\") not in (\"dev-local\", \"test\"): origrequest = requests.Session.request def saferequest(self, method, url, , verify=True, kw): if verify is False: raise ssl.SSLError( f\"TLS verification is required (request to {url})\" ) return origrequest(self, method, url, verify=verify, kw) requests.Session.request = saferequest Equivalent shims exist for httpx, aiohttp, the Node https module, and Java's SSLContext factories. Install at the application's entry point. Uplift — configure the trust store correctly Most verify=False calls are present because the developer hit a TLS error and disabling was the fastest fix. The right fix: Self-signed cert in dev / staging: install the cert into the system trust store, or pass verify=\"/path/to/ca-bundle\". Internal CA: install the org's CA into the application's trust bundle (certifi-merged in Python, truststore for system trust, JVM cacerts for Java). Cert pinning: use the framework's pinning API rather than disabling verification. urllib3 exposes assertfingerprint; Java has pin-based TrustManager patterns. Proxy with TLS interception: point the application at the org's TLS-intercepting proxy with the proxy's CA installed in the trust store. Don't disable verification just because the proxy is in the path. Inputs Call sites — every disabled-TLS call. Reason classification — why was verification disabled at each site? The prompt ~~~markdown You are remediating disabled-TLS-verification call sites. Output a PR or a TRIAGE.md. Step 0 — Inventory 1. Grep for verify=False, verify = False, rejectUnauthorized: false, InsecureSkipVerify: true, HostnameVerifier((h,s)->true), setDefaultHostnameVerifier, TrustManager overrides, --insecure / -k curl flags, and the env-var overrides listed in the recipe. 2. For each call site, classify the reason: self-signed cert in dev, internal CA missing, broken cert chain, proxy in path, or unknown. Step 1 — Pick the strategy per call site Self-signed dev cert / internal CA: uplift — install the CA into the application's trust bundle. Broken cert chain: uplift — fix the chain (intermediate cert missing). Proxy in path: uplift — install the proxy's CA into the trust store; do not disable verification. Unknown: triage. Step 2 — Uplift For each call site, do the language-appropriate fix: Python: pass verify=\"/path/to/ca-bundle\" or verify=True with the CA installed via certifi.where() a startup script that merges in the org CA. Node: load the CA via tls.createSecureContext({ ca: ... }) and pass that as the agent's secure context. Java: load the CA into the JVM cacerts keystore (or application-specific keystore) and remove trust-all TrustManagers. Go: populate RootCAs on the TLS config; remove InsecureSkipVerify. curl: install the CA via --cacert or set CURLCABUNDLE; remove --insecure. Step 3 — Install the fail-closed shim (when chosen) For codebases with many call sites, install the import-time shim at the application entry point. The shim should: 1. Allow verify=False only when an explicit ENV=dev-local (or equivalent) environment variable is set. 2. Otherwise raise SSLError immediately. 3. Log every shim activation so test environments are visible in audit. Step 4 — Tests Add tests: A request to a server with a valid certificate succeeds. A request to a server with a self-signed certificate (in test env) succeeds only when an explicit verify=... argument names that cert. In a non-test environment, a verify=False call raises. Step 5 — Open the PR Branch: remediate/tls-verify-<module-slug>. Title: [Security][TLS] re-enable verification across <module>. Body: call-site inventory, reason per site, uplift chosen, shim installation, test additions. Label: sec-auto-remediation. Stop conditions A genuinely insecure-by-design integration (e.g., a legacy partner endpoint that has no valid cert and cannot get one). Do not auto-disable verification — flag and triage; the right path is a network-isolated proxy. The reason a site disabled verification cannot be classified. A test infrastructure depends on verify=False and the agent cannot reshape it without touching test infra. Scope Do not modify CI test infrastructure. Do not bundle unrelated refactors. Do not silently widen the shim's \"allowed in dev\" scope. ~~~ Watch for urllib3.disablewarnings. Often paired with verify=False. Removing the warning suppression doesn't fix the bug; the warnings exist because the bug exists. NODETLSREJECTUNAUTHORIZED=0 baked into Dockerfiles. Easy to miss when reviewing application code. GITSSLNOVERIFY=true baked into CI to clone internal git over a self-signed proxy. Same fix: install the proxy's CA, don't disable verification. Trust-all TrustManager registered globally in older Java apps — affects every HTTPS call in the JVM. The shim has to override the registration, not just the call sites. TLS pin churn. Pinning is a strong control but a deploy burden. Don't pin without a documented rotation playbook. Output contract PR or TRIAGE.md only; no live endpoint probing or certificate changes unless explicitly authorized. Call-site inventory covers application code, tests, Dockerfiles, CI scripts, environment variables, curl commands, and language-specific trust-all hooks. Each call site is classified as production, test-only, local-dev, vendor proxy, or unknown. Fix replaces disabled verification with a trusted CA path, installed internal CA, fail-closed shim, or documented stop condition. Tests prove valid certificates succeed and invalid/self-signed certificates fail unless a test-only CA is explicitly configured. Verification Before opening the PR or final triage note, verify that: verify=False, InsecureSkipVerify, trust-all managers, --insecure, NODETLSREJECTUNAUTHORIZED=0, and CI SSL bypass variables were searched; warning suppression is removed only after verification is re-enabled; internal/self-signed CA handling is explicit and environment-scoped; no private CA keys, client certificates, tokens, or live endpoint secrets are committed as fixtures; production behavior fails closed when certificate validation cannot be established. Guardrails Do not replace verify=False with a global trust-all shim. Do not pin certificates without an owner-approved rotation playbook. Do not modify CI infrastructure or partner endpoints outside the requested repository scope. Do not call production services to test certificate validity. Related Classic Vulnerable Defaults — workflow context. OWASP Top 10:2025 -> A04 Cryptographic Failures — broader crypto-failure pattern.","agent_handoff":{"mcp_lookup_keys":["requests-verify-false","/recipes/general/classic-vulnerable-defaults/requests-verify-false/","recipes/general/classic-vulnerable-defaults/requests-verify-false.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["remediation","risk"],"source_text_field":"content_text","portable_download":"security-recipe-requests-verify-false.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-requests-verify-false.json"}},{"slug":"ruby-marshal-yaml-load","title":"Ruby unsafe deserialization — `Marshal.load` / `YAML.load`","link_title":"Ruby Marshal/YAML.load","url":"https://security-recipes.ai/recipes/general/classic-vulnerable-defaults/ruby-marshal-yaml-load/","path":"/recipes/general/classic-vulnerable-defaults/ruby-marshal-yaml-load/","source_file":"recipes/general/classic-vulnerable-defaults/ruby-marshal-yaml-load.md","recipe_id":"","recipe_kind":"","category":{"slug":"classic-defaults","label":"Classic Vulnerable Defaults"},"agent":"general","severity":"unspecified","maturity":"development","ecosystem":"","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"","framework_version":"","jurisdiction":"","industry":[],"cve_archetypes":[],"cve_workflow_role":"","tags":["ruby","deserialization","yaml","uplift","mitigate"],"facets":["remediation","risk"],"quality":{"score":95,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"Stephen M Abbott","team":"Security","model":"Opus 4.7","ai_assisted":false,"generated_by":"","date":"2026-04-26","zero_day":false,"last_updated":"2026-04-26","summary":"Replace `Marshal.load` and unsafe YAML loading with safe parsers, typed coercion, and strict migration tests.","content_text":"Marshal.load and permissive YAML loaders are durable Ruby security traps. If untrusted bytes reach these APIs, attacker payloads can instantiate arbitrary classes and trigger dangerous code paths. This pattern appears in Rails jobs, cache/session layers, signed-cookie migrations, and background workers. When to use it Use this recipe when Ruby Marshal.load or unsafe YAML.load processes untrusted data. Prefer it when the call site is identified; use a broader Ruby audit only when the sink is unknown. Do not use it to deserialize attacker-controlled Marshal streams as a demonstration. Pattern Marshal.load(payload) where payload crosses trust boundaries (HTTP params, Redis, MQ, DB rows editable by users). YAML.load / Psych.load on untrusted YAML. YAML.unsafeload in modern Ruby/Psych. Indirect wrappers that decode serialized data before model/job processing. Why it matters Unsafe Ruby deserialization can become RCE via gadget chains in application or gem classes. Even without direct execution, attackers can tamper with object state to bypass authz checks, poison jobs, or trigger SSRF/file operations. Mitigation — safe loader with strict class policy For YAML, switch to safeload with explicit permitted classes: parsed = YAML.safeload(payload, permittedclasses: [Date, Time], aliases: false) For Marshal paths that cannot be removed immediately, enforce trusted provenance and fail-closed guards at ingress. Treat as a temporary bridge, not a steady state. Uplift — move to JSON + explicit coercion Preferred uplift: Replace Marshal/YAML object payloads with JSON hashes/arrays. Perform explicit coercion into value objects/DTOs. Validate required fields and types before business logic. Keep temporary legacy decode only where required, with telemetry and a removal date. Inputs Call sites — every Marshal.load, YAML.load, Psych.load, and unsafeload usage. Data provenance — where each payload originates. Compatibility needs — which historical payloads must continue to decode during migration. The prompt ~~~markdown You are remediating unsafe Ruby deserialization call sites. Output a PR or a TRIAGE.md. Step 0 — Inventory 1. Search for Marshal.load, YAML.load, Psych.load, and unsafeload. 2. Classify each by trust boundary: trusted-only internal, external/untrusted, or unknown. 3. Map legacy payload producers/consumers. Step 1 — Choose remediation per site Untrusted or unknown: uplift to JSON + explicit coercion. Trusted-only temporary compatibility path: mitigate with strict guards and bounded lifespan. Step 2 — Implement For YAML sites: Replace with YAML.safeload and minimal permittedclasses list. Disable aliases unless explicitly required. For Marshal sites: Replace with JSON decode + schema/type validation. Remove Marshal.load from runtime paths handling external input. For temporary compat paths: Isolate in a clearly named legacy decoder module. Add telemetry counters for legacy decode usage. Add TODO with owner and removal date. Step 3 — Tests Add behavior-preservation tests: Valid legacy payloads decode to equivalent domain values. Untrusted crafted payloads are rejected. Unknown class tags / alias abuse fails closed. Step 4 — Open the PR Branch: remediate/ruby-deser-<module-slug>. Title: [Security][Ruby] remove unsafe deserialize in <module>. Body: inventory, trust classification, uplift/mitigation decisions, compatibility plan, test evidence. Label: sec-auto-remediation. Stop conditions Trust boundary cannot be determined. Required migration spans multiple services with no staged rollout plan. Critical path lacks tests and cannot be safely instrumented. Scope Do not ship unrelated refactors. Do not introduce broad permittedclasses catch-alls. Do not retain legacy decode paths without explicit expiry. ~~~ Watch for Rails cookie/session migrations where old serializers are still enabled. Background job payload formats shared across deploy waves. aliases: true in YAML parsers reopening gadget vectors. Monkey patches in initializers that re-enable unsafe loading globally. Output contract PR or TRIAGE.md only; no multi-service payload migration unless explicitly authorized. Inventory lists every Marshal.load, YAML.load, Psych.load, unsafeload, serializer initializer, and background-job/session decoder in scope. Each call site is classified as untrusted, trusted-only temporary compatibility, unknown, or framework-owned. Fix is labeled as JSON/coercion uplift, YAML.safeload mitigation, legacy decoder isolation, or triage. Tests prove valid legacy payloads still decode, unsafe classes/tags are rejected, and YAML aliases fail closed unless explicitly approved. Verification Before opening the PR or final triage note, verify that: untrusted input cannot reach Marshal.load or unsafe YAML/Psych loaders; permittedclasses lists are minimal and justified by local domain objects; any legacy decoder has telemetry, owner, removal date, and rollback notes; Rails cookie/session and background-job serializers are checked for deploy compatibility; no production serialized payloads, secrets, or customer data are committed as fixtures. Guardrails Do not add broad Object, Symbol, or application namespace catch-alls to permitted classes. Do not enable YAML aliases unless the owner explicitly accepts the risk. Do not remove shared job/session formats without staged rollout planning. Do not mix unrelated Rails initializer or serialization refactors into the same PR. Related Classic Vulnerable Defaults — workflow context. PyYAML yaml.load — analogous unsafe YAML default in Python.","agent_handoff":{"mcp_lookup_keys":["ruby-marshal-yaml-load","/recipes/general/classic-vulnerable-defaults/ruby-marshal-yaml-load/","recipes/general/classic-vulnerable-defaults/ruby-marshal-yaml-load.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["remediation","risk"],"source_text_field":"content_text","portable_download":"security-recipe-ruby-marshal-yaml-load.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-ruby-marshal-yaml-load.json"}},{"slug":"xxe-xml-defaults","title":"XML external entities (XXE) — parser defaults","link_title":"XML external entities (XXE)","url":"https://security-recipes.ai/recipes/general/classic-vulnerable-defaults/xxe-xml-defaults/","path":"/recipes/general/classic-vulnerable-defaults/xxe-xml-defaults/","source_file":"recipes/general/classic-vulnerable-defaults/xxe-xml-defaults.md","recipe_id":"","recipe_kind":"","category":{"slug":"classic-defaults","label":"Classic Vulnerable Defaults"},"agent":"general","severity":"unspecified","maturity":"development","ecosystem":"","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"","framework_version":"","jurisdiction":"","industry":[],"cve_archetypes":["xxe"],"cve_workflow_role":"remediate","tags":["xml","xxe","uplift","mitigate","defusedxml"],"facets":["remediation","risk"],"quality":{"score":95,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"Stephen M Abbott","team":"Security","model":"Opus 4.7","ai_assisted":false,"generated_by":"","date":"2026-04-25","zero_day":false,"last_updated":"2026-04-25","summary":"Per-language parser hardening: defusedxml for Python, factory feature flags for Java, libxml entity-loading off in PHP.","content_text":"XML parsers in most languages historically defaulted to resolving external entities. A single XML payload can read local files, exfiltrate data over DNS, hang the parser on a billion-laughs payload, or pivot through SSRF. Most parsers have safer modes; few default to them. The fix is to set the right flags everywhere — every parser, every library, every vendored XML toolkit. When to use it Use this recipe when an XML parser still resolves external entities or DTDs on untrusted input. Prefer it when the language and parser are known (Python, Java, PHP, libxml) and the change is disabling entity loading. Do not use it to fetch internal URLs or files through XXE as a test. Pattern Python. xml.etree.ElementTree.parse, xml.dom.minidom.parse, xml.sax.parse, lxml.etree.parse with default options. Java. DocumentBuilderFactory, SAXParserFactory, XMLInputFactory, TransformerFactory, SchemaFactory — all entity-resolving by default. PHP. simplexmlloadstring, DOMDocument::loadXML with default options; libxmldisableentityloader global flag was the historical mitigation but its semantics changed in PHP 8. .NET. XmlDocument, XmlReader defaults pre-4.5.2 resolved entities; current defaults are safer but application code often re-enables them. Ruby. Nokogiri::XML(input) with default options — noent: true is the dangerous flag. Go. encoding/xml does not resolve entities (good); but third-party XML libraries vary. Why it matters The classic XXE payload reads a local file: <?xml version=\"1.0\"?> <!DOCTYPE foo [<!ENTITY x SYSTEM \"file:///etc/passwd\">]> <foo>&x;</foo> …and your parser returns the contents in the response body, or in an error message, or via a side-channel DNS lookup. There is no patch coming for \"the XML spec allows this\" — the fix is to configure the parser to refuse. Mitigation — disable entity resolution and DTD loading Per language, the right flags: Python (uplift to defusedxml). Replace import xml.etree.ElementTree as ET import defusedxml.ElementTree as ET All ET. calls now refuse external entities, DTDs, and entity-expansion attacks. defusedxml has wrappers for ElementTree, minidom, sax, lxml, pulldom, and xmlrpc. Replacing the import is the fix. Java. DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance(); dbf.setFeature(\"http://apache.org/xml/features/disallow-doctype-decl\", true); dbf.setFeature(\"http://xml.org/sax/features/external-general-entities\", false); dbf.setFeature(\"http://xml.org/sax/features/external-parameter-entities\", false); dbf.setFeature(\"http://apache.org/xml/features/nonvalidating/load-external-dtd\", false); dbf.setXIncludeAware(false); dbf.setExpandEntityReferences(false); Equivalent flag-sets exist for SAXParserFactory, XMLInputFactory (ISSUPPORTINGEXTERNALENTITIES, SUPPORTDTD), and TransformerFactory (XMLConstants.ACCESSEXTERNALDTD, ACCESSEXTERNALSTYLESHEET). PHP. $dom = new DOMDocument(); $dom->loadXML( $input, LIBXMLNONET | LIBXMLNOENT ? 0 // default safe in PHP 8+; verify with phpunit : 0 // explicitly no LIBXMLNOENT, no LIBXMLDTDLOAD ); PHP 8 changed libxmldisableentityloader semantics; the correct shape is now flag-based at the load call. .NET. var settings = new XmlReaderSettings { DtdProcessing = DtdProcessing.Prohibit, XmlResolver = null, }; using var reader = XmlReader.Create(input, settings); Never use XmlDocument.Load(stream) directly without setting XmlResolver = null and DtdProcessing = Prohibit. Ruby. doc = Nokogiri::XML(input) do |config| config.strict.nonet # no network, no DTD loading end Uplift — replace XML where possible For new APIs and config files, prefer JSON, YAML (with safeload), or protobuf. XML's parser-level vulnerabilities are not a fixable category; the only real fix is to stop parsing XML where the format isn't required. Inputs Call sites — every XML-parser instantiation in the repo. Languages and parsers in scope. The prompt ~~~markdown You are remediating XML-parser defaults across this repo. Output a PR or a TRIAGE.md. Step 0 — Inventory 1. List every XML-parser instantiation: ElementTree.parse, DocumentBuilderFactory.newInstance, XmlDocument, Nokogiri::XML, simplexmlloadstring, etc. 2. For each, identify whether the input is untrusted (request body, uploaded file, partner data feed) or trusted (a bundled config file). 3. Flag any code path that returns parsed XML content in an HTTP response (XXE exfiltration surface) and any path that logs parsed content. Step 1 — Mitigate per language Apply the language-specific configuration from the recipe body: Python: swap imports to defusedxml. Java: set the disallow-doctype-decl, external-general-entities, external-parameter-entities, load-external-dtd features to safe values on every parser factory, plus setXIncludeAware(false) and setExpandEntityReferences(false). PHP: pass safe libxml flags to every parser; remove LIBXMLNOENT and LIBXMLDTDLOAD everywhere. .NET: set DtdProcessing = Prohibit and XmlResolver = null on every reader. Ruby: use nonet, noent: false. Step 2 — Uplift the API surface (when applicable) If a public API takes XML and the agent has authority to introduce a JSON endpoint side-by-side, do it. Mark XML endpoints deprecated; keep them serving (with the mitigated parser) until clients migrate. Step 3 — Tests For every language touched, add a test: 1. The classic XXE payload (referencing file:///etc/passwd or a local DTD) is rejected without resolving the entity. 2. A billion-laughs / quadratic-blowup payload is rejected without exhausting memory. 3. A normal XML payload still parses correctly (behaviour preservation). Step 4 — Open the PR Branch: remediate/xxe-<module-slug>. Title: [Security][XXE] harden XML parsers in <module>. Body: per-language summary, call-site list, test additions, any deprecation notices. Label: sec-auto-remediation. Stop conditions A parser configuration option changes the schema-validation semantics in a way that breaks legitimate inputs. Tests fail in unrelated code that depends on XInclude or DTD resolution for a real reason. Triage. A vendored XML library has no exposed safe-mode flag. Flag and triage; consider replacing the library. Scope Do not change XML schemas (XSDs). The fix is parser configuration, not schema content. Do not bundle unrelated refactors. Do not silently re-enable any flag the recipe disables. ~~~ Watch for DTD-using legitimate inputs. Some partner integrations ship inline DTDs. The mitigation breaks them. Identify before deploying; allowlist the partner-DTD path explicitly rather than globally re-enabling DTDs. Logging the parsed payload. Even with entities disabled, logging unparsed XML can leak data via log-injection. Log the payload's hash, not its content. Dependency-injected parsers. A framework that injects a parser bean (Spring, Symfony, Rails) needs the parser bean reconfigured at construction. Find and fix the bean definition, not just the call sites. Schema validation feature-flags re-enabling DTDs. Some XSD validators re-resolve external schemas; double-check SchemaFactory settings. Output contract PR or TRIAGE.md only; no schema redesign or endpoint migration unless explicitly authorized. Inventory lists every XML parser, parser factory, framework parser bean, schema validator, and XML-accepting entry point in scope. Fix documents language-specific flags that disable external entities, DTD loading, XInclude, resolver access, and entity expansion. Tests cover XXE, entity-expansion DoS, and normal XML behavior preservation. Any XML-to-JSON uplift is side-by-side and includes deprecation notes rather than a breaking replacement. Verification Before opening the PR or final triage note, verify that: external entity resolution is disabled for every parser construction path; schema validation does not re-enable external schemas or DTD resolution; legitimate XML fixtures still parse without external network or filesystem access; payload contents are not logged in tests or reports; vendored or framework-owned parsers without safe hooks are listed as stop conditions. Guardrails Do not re-enable DTDs globally to preserve one partner integration. Do not change XSDs or public XML contracts unless the task explicitly asks. Do not use real sensitive files in XXE tests; use inert local fixtures. Do not call external network resources to validate parser behavior. Related Classic Vulnerable Defaults — workflow context. Java ObjectInputStream — sibling Java deserialization pattern.","agent_handoff":{"mcp_lookup_keys":["xxe-xml-defaults","/recipes/general/classic-vulnerable-defaults/xxe-xml-defaults/","recipes/general/classic-vulnerable-defaults/xxe-xml-defaults.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["remediation","risk"],"source_text_field":"content_text","portable_download":"security-recipe-xxe-xml-defaults.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-xxe-xml-defaults.json"}},{"slug":"c-cpp-atomic-lock-and-thread-lifecycle","title":"C and C++ atomic, lock, and thread lifecycle","link_title":"C and C++ atomic, lock, and thread lifecycle","url":"https://security-recipes.ai/recipes/general/code-hygiene/c-cpp/c-cpp-atomic-lock-and-thread-lifecycle/","path":"/recipes/general/code-hygiene/c-cpp/c-cpp-atomic-lock-and-thread-lifecycle/","source_file":"recipes/general/code-hygiene/c-cpp/c-cpp-atomic-lock-and-thread-lifecycle.md","recipe_id":"code-hygiene.c-cpp.c-cpp-atomic-lock-and-thread-lifecycle","recipe_kind":"code-hygiene","category":{"slug":"code-hygiene","label":"Code Hygiene"},"agent":"general","severity":"unspecified","maturity":"development","ecosystem":"c-cpp/cmake","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"","framework_version":"","jurisdiction":"","industry":[],"cve_archetypes":[],"cve_workflow_role":"","tags":["code-hygiene","c-cpp","c","cpp","atomics","locks","threads"],"facets":["code-hygiene","audit","remediation"],"quality":{"score":100,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context","multi-facet"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"security-recipes.ai contributors","team":"Security Engineering","model":"gpt-5-codex","ai_assisted":false,"generated_by":"","date":"2026-08-21","zero_day":false,"last_updated":"2026-08-21","summary":"C and C++ atomic, lock, and thread lifecycle: Remove data races, lock-order hazards, and detached thread lifetimes.","content_text":"<!-- Generated by scripts/synccodehygiene_recipes.py; edit data/code-hygiene/catalog.json. --> A tool-agnostic recipe to remove data races, lock-order hazards, and detached thread lifetimes. It supports a read-only audit and, when explicitly authorized, a narrow remediation. When to use it Use this recipe when the operator's specific objective is to remove data races, lock-order hazards, and detached thread lifetimes. Prefer a narrower CVE, scanner-finding, security-audit, or compliance-evidence recipe when that is the operator's actual job. Inputs Repository root and the files, package, service, or module in scope. Requested mode: audit or explicitly authorized fix. Supported runtime, compiler, framework, operating-system, and deployment versions inferred from repository files. Existing formatter, compiler, analyzer, test, build, and package-manager commands. Public API, compatibility, performance, generated-code, vendor, and migration constraints. The prompt ~~~markdown You are running the Security Recipes code-hygiene workflow code-hygiene.c-cpp.c-cpp-atomic-lock-and-thread-lifecycle. Start read-only. Do not edit files until the operator explicitly authorizes a fix. Use repository configuration and installed tool versions as authoritative; do not impose a new style or toolchain. Scope Your bounded objective is to remove data races, lock-order hazards, and detached thread lifetimes. Inspect only operator-scoped, first-party source and configuration. Exclude generated, vendored, minified, fixture snapshot, lock history, and migration history unless explicitly included. Detection Map shared mutable state, synchronization, memory order, lock order, callbacks under locks, and thread join ownership. Use configured thread-safety analysis or race detection on representative workloads. Record file and symbol evidence for every candidate. Mark uncertain or dynamically reachable behavior instead of guessing. Fix, only when authorized Prefer scoped locking and task ownership, minimize sharing, and use the weakest proven-correct atomic ordering only with rationale. Keep the diff limited to the proven issue and its focused tests. Preserve public behavior, API compatibility, and repository conventions. Do not add or broaden suppressions, weaken diagnostics, mass-format unrelated files, upgrade dependencies, or mutate external state. Verification Run race-enabled concurrent tests, shutdown cases, saturation, and repeated start-stop cycles. Compare diagnostic counts and relevant behavior before and after. Report every command, result, and check that could not run. Stop conditions Stop if lock-free correctness or memory ordering lacks a documented proof and specialist review. Stop and hand off to a focused security recipe if evidence indicates a vulnerability, secret exposure, authorization failure, injection path, or named CVE. Stop rather than widening scope when the safe result requires architecture, product, compliance, operational, or data-owner decisions. ~~~ Output contract Scope and repository evidence reviewed. A candidate table with file or symbol, evidence, confidence, and disposition. In audit mode: no edits, plus the smallest safe next action for each confirmed item. In fix mode: one bounded patch, focused regression coverage, and no unrelated cleanup. Commands run, results, remaining uncertainty, and any stop-condition handoff. Verification Run race-enabled concurrent tests, shutdown cases, saturation, and repeated start-stop cycles. Confirm that diagnostic configuration, suppressions, public interfaces, generated files, vendored files, and dependencies did not change outside the authorized scope. Review the final diff for behavior changes and run the repository's focused checks before broader suites. Guardrails Read-only until edits are explicitly authorized. Do not deploy, publish, rotate secrets, alter cloud or database state, change CI permissions, or open external tickets. Do not hide debt by disabling rules, adding retries or sleeps, weakening tests, broadening ignores, or lowering warning levels. Treat generated, vendored, minified, migration-history, and fixture-snapshot files as out of scope unless explicitly named. Stop if lock-free correctness or memory ordering lacks a documented proof and specialist review. Related recipes C and C++ compiler warning and suppression debt C and C++ ownership, RAII, and resource lifecycle Browse all code-hygiene recipes References NIST SP 800-218 Secure Software Development Framework 1.1 — NIST C++ Core Guidelines — Standard C++ Foundation Clang sanitizers documentation — LLVM","agent_handoff":{"mcp_lookup_keys":["c-cpp-atomic-lock-and-thread-lifecycle","/recipes/general/code-hygiene/c-cpp/c-cpp-atomic-lock-and-thread-lifecycle/","recipes/general/code-hygiene/c-cpp/c-cpp-atomic-lock-and-thread-lifecycle.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["code-hygiene","audit","remediation"],"source_text_field":"content_text","portable_download":"security-recipe-c-cpp-atomic-lock-and-thread-lifecycle.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-c-cpp-atomic-lock-and-thread-lifecycle.json"}},{"slug":"c-cpp-bounds-integer-and-undefined-behavior","title":"C and C++ bounds, integer, and undefined-behavior hygiene","link_title":"C and C++ bounds, integer, and undefined-behavior hygiene","url":"https://security-recipes.ai/recipes/general/code-hygiene/c-cpp/c-cpp-bounds-integer-and-undefined-behavior/","path":"/recipes/general/code-hygiene/c-cpp/c-cpp-bounds-integer-and-undefined-behavior/","source_file":"recipes/general/code-hygiene/c-cpp/c-cpp-bounds-integer-and-undefined-behavior.md","recipe_id":"code-hygiene.c-cpp.c-cpp-bounds-integer-and-undefined-behavior","recipe_kind":"code-hygiene","category":{"slug":"code-hygiene","label":"Code Hygiene"},"agent":"general","severity":"unspecified","maturity":"development","ecosystem":"c-cpp/cmake","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"","framework_version":"","jurisdiction":"","industry":[],"cve_archetypes":[],"cve_workflow_role":"","tags":["code-hygiene","c-cpp","c","cpp","bounds","integers","undefined-behavior"],"facets":["code-hygiene","audit","remediation"],"quality":{"score":100,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context","multi-facet"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"security-recipes.ai contributors","team":"Security Engineering","model":"gpt-5-codex","ai_assisted":false,"generated_by":"","date":"2026-08-21","zero_day":false,"last_updated":"2026-08-21","summary":"C and C++ bounds, integer, and undefined-behavior hygiene: Remove unchecked bounds, lossy arithmetic, lifetime, and undefined-behavior hazards.","content_text":"<!-- Generated by scripts/synccodehygiene_recipes.py; edit data/code-hygiene/catalog.json. --> A tool-agnostic recipe to remove unchecked bounds, lossy arithmetic, lifetime, and undefined-behavior hazards. It supports a read-only audit and, when explicitly authorized, a narrow remediation. When to use it Use this recipe when the operator's specific objective is to remove unchecked bounds, lossy arithmetic, lifetime, and undefined-behavior hazards. Prefer a narrower CVE, scanner-finding, security-audit, or compliance-evidence recipe when that is the operator's actual job. Inputs Repository root and the files, package, service, or module in scope. Requested mode: audit or explicitly authorized fix. Supported runtime, compiler, framework, operating-system, and deployment versions inferred from repository files. Existing formatter, compiler, analyzer, test, build, and package-manager commands. Public API, compatibility, performance, generated-code, vendor, and migration constraints. The prompt ~~~markdown You are running the Security Recipes code-hygiene workflow code-hygiene.c-cpp.c-cpp-bounds-integer-and-undefined-behavior. Start read-only. Do not edit files until the operator explicitly authorizes a fix. Use repository configuration and installed tool versions as authoritative; do not impose a new style or toolchain. Scope Your bounded objective is to remove unchecked bounds, lossy arithmetic, lifetime, and undefined-behavior hazards. Inspect only operator-scoped, first-party source and configuration. Exclude generated, vendored, minified, fixture snapshot, lock history, and migration history unless explicitly included. Detection Trace lengths, offsets, signedness, narrowing, pointer arithmetic, shifts, overflow assumptions, and object lifetimes. Exercise parser and allocation boundaries with sanitizer-supported inputs. Record file and symbol evidence for every candidate. Mark uncertain or dynamically reachable behavior instead of guessing. Fix, only when authorized Validate before arithmetic, use suitable types and checked operations, and preserve object lifetime rules. Keep the diff limited to the proven issue and its focused tests. Preserve public behavior, API compatibility, and repository conventions. Do not add or broaden suppressions, weaken diagnostics, mass-format unrelated files, upgrade dependencies, or mutate external state. Verification Run boundary tests, fuzz targets if present, and address and undefined-behavior sanitizers. Compare diagnostic counts and relevant behavior before and after. Report every command, result, and check that could not run. Stop conditions Stop if wire format, ABI width, or performance constraints make the safe representation unclear. Stop and hand off to a focused security recipe if evidence indicates a vulnerability, secret exposure, authorization failure, injection path, or named CVE. Stop rather than widening scope when the safe result requires architecture, product, compliance, operational, or data-owner decisions. ~~~ Output contract Scope and repository evidence reviewed. A candidate table with file or symbol, evidence, confidence, and disposition. In audit mode: no edits, plus the smallest safe next action for each confirmed item. In fix mode: one bounded patch, focused regression coverage, and no unrelated cleanup. Commands run, results, remaining uncertainty, and any stop-condition handoff. Verification Run boundary tests, fuzz targets if present, and address and undefined-behavior sanitizers. Confirm that diagnostic configuration, suppressions, public interfaces, generated files, vendored files, and dependencies did not change outside the authorized scope. Review the final diff for behavior changes and run the repository's focused checks before broader suites. Guardrails Read-only until edits are explicitly authorized. Do not deploy, publish, rotate secrets, alter cloud or database state, change CI permissions, or open external tickets. Do not hide debt by disabling rules, adding retries or sleeps, weakening tests, broadening ignores, or lowering warning levels. Treat generated, vendored, minified, migration-history, and fixture-snapshot files as out of scope unless explicitly named. Stop if wire format, ABI width, or performance constraints make the safe representation unclear. Related recipes C and C++ compiler warning and suppression debt C and C++ ownership, RAII, and resource lifecycle Browse all code-hygiene recipes References NIST SP 800-218 Secure Software Development Framework 1.1 — NIST C++ Core Guidelines — Standard C++ Foundation Clang sanitizers documentation — LLVM","agent_handoff":{"mcp_lookup_keys":["c-cpp-bounds-integer-and-undefined-behavior","/recipes/general/code-hygiene/c-cpp/c-cpp-bounds-integer-and-undefined-behavior/","recipes/general/code-hygiene/c-cpp/c-cpp-bounds-integer-and-undefined-behavior.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["code-hygiene","audit","remediation"],"source_text_field":"content_text","portable_download":"security-recipe-c-cpp-bounds-integer-and-undefined-behavior.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-c-cpp-bounds-integer-and-undefined-behavior.json"}},{"slug":"c-cpp-compiler-warning-and-suppression-debt","title":"C and C++ compiler warning and suppression debt","link_title":"C and C++ compiler warning and suppression debt","url":"https://security-recipes.ai/recipes/general/code-hygiene/c-cpp/c-cpp-compiler-warning-and-suppression-debt/","path":"/recipes/general/code-hygiene/c-cpp/c-cpp-compiler-warning-and-suppression-debt/","source_file":"recipes/general/code-hygiene/c-cpp/c-cpp-compiler-warning-and-suppression-debt.md","recipe_id":"code-hygiene.c-cpp.c-cpp-compiler-warning-and-suppression-debt","recipe_kind":"code-hygiene","category":{"slug":"code-hygiene","label":"Code Hygiene"},"agent":"general","severity":"unspecified","maturity":"development","ecosystem":"c-cpp/cmake","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"","framework_version":"","jurisdiction":"","industry":[],"cve_archetypes":[],"cve_workflow_role":"","tags":["code-hygiene","c-cpp","c","cpp","compiler","warnings"],"facets":["code-hygiene","audit","remediation"],"quality":{"score":100,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context","multi-facet"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"security-recipes.ai contributors","team":"Security Engineering","model":"gpt-5-codex","ai_assisted":false,"generated_by":"","date":"2026-08-21","zero_day":false,"last_updated":"2026-08-21","summary":"C and C++ compiler warning and suppression debt: Resolve portable compiler diagnostics without blanket flags or pragmas.","content_text":"<!-- Generated by scripts/synccodehygiene_recipes.py; edit data/code-hygiene/catalog.json. --> A tool-agnostic recipe to resolve portable compiler diagnostics without blanket flags or pragmas. It supports a read-only audit and, when explicitly authorized, a narrow remediation. When to use it Use this recipe when the operator's specific objective is to resolve portable compiler diagnostics without blanket flags or pragmas. Prefer a narrower CVE, scanner-finding, security-audit, or compliance-evidence recipe when that is the operator's actual job. Inputs Repository root and the files, package, service, or module in scope. Requested mode: audit or explicitly authorized fix. Supported runtime, compiler, framework, operating-system, and deployment versions inferred from repository files. Existing formatter, compiler, analyzer, test, build, and package-manager commands. Public API, compatibility, performance, generated-code, vendor, and migration constraints. The prompt ~~~markdown You are running the Security Recipes code-hygiene workflow code-hygiene.c-cpp.c-cpp-compiler-warning-and-suppression-debt. Start read-only. Do not edit files until the operator explicitly authorizes a fix. Use repository configuration and installed tool versions as authoritative; do not impose a new style or toolchain. Scope Your bounded objective is to resolve portable compiler diagnostics without blanket flags or pragmas. Inspect only operator-scoped, first-party source and configuration. Exclude generated, vendored, minified, fixture snapshot, lock history, and migration history unless explicitly included. Detection Read build flags per compiler, target, configuration, and generated-code boundary and inventory pragmas. Compare diagnostics across supported compilers and standards modes. Record file and symbol evidence for every candidate. Mark uncertain or dynamically reachable behavior instead of guessing. Fix, only when authorized Correct owned warnings and scope unavoidable compiler-specific suppression with documented rationale. Keep the diff limited to the proven issue and its focused tests. Preserve public behavior, API compatibility, and repository conventions. Do not add or broaden suppressions, weaken diagnostics, mass-format unrelated files, upgrade dependencies, or mutate external state. Verification Build supported targets and configurations with existing warning-as-error gates and tests. Compare diagnostic counts and relevant behavior before and after. Report every command, result, and check that could not run. Stop conditions Stop if the change alters ABI, calling convention, packed layout, or unsupported compiler compatibility. Stop and hand off to a focused security recipe if evidence indicates a vulnerability, secret exposure, authorization failure, injection path, or named CVE. Stop rather than widening scope when the safe result requires architecture, product, compliance, operational, or data-owner decisions. ~~~ Output contract Scope and repository evidence reviewed. A candidate table with file or symbol, evidence, confidence, and disposition. In audit mode: no edits, plus the smallest safe next action for each confirmed item. In fix mode: one bounded patch, focused regression coverage, and no unrelated cleanup. Commands run, results, remaining uncertainty, and any stop-condition handoff. Verification Build supported targets and configurations with existing warning-as-error gates and tests. Confirm that diagnostic configuration, suppressions, public interfaces, generated files, vendored files, and dependencies did not change outside the authorized scope. Review the final diff for behavior changes and run the repository's focused checks before broader suites. Guardrails Read-only until edits are explicitly authorized. Do not deploy, publish, rotate secrets, alter cloud or database state, change CI permissions, or open external tickets. Do not hide debt by disabling rules, adding retries or sleeps, weakening tests, broadening ignores, or lowering warning levels. Treat generated, vendored, minified, migration-history, and fixture-snapshot files as out of scope unless explicitly named. Stop if the change alters ABI, calling convention, packed layout, or unsupported compiler compatibility. Related recipes C and C++ ownership, RAII, and resource lifecycle C and C++ bounds, integer, and undefined-behavior hygiene Browse all code-hygiene recipes References NIST SP 800-218 Secure Software Development Framework 1.1 — NIST C++ Core Guidelines — Standard C++ Foundation Clang sanitizers documentation — LLVM","agent_handoff":{"mcp_lookup_keys":["c-cpp-compiler-warning-and-suppression-debt","/recipes/general/code-hygiene/c-cpp/c-cpp-compiler-warning-and-suppression-debt/","recipes/general/code-hygiene/c-cpp/c-cpp-compiler-warning-and-suppression-debt.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["code-hygiene","audit","remediation"],"source_text_field":"content_text","portable_download":"security-recipe-c-cpp-compiler-warning-and-suppression-debt.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-c-cpp-compiler-warning-and-suppression-debt.json"}},{"slug":"c-cpp-const-span-view-and-lifetime-hygiene","title":"C and C++ const, span, view, and lifetime hygiene","link_title":"C and C++ const, span, view, and lifetime hygiene","url":"https://security-recipes.ai/recipes/general/code-hygiene/c-cpp/c-cpp-const-span-view-and-lifetime-hygiene/","path":"/recipes/general/code-hygiene/c-cpp/c-cpp-const-span-view-and-lifetime-hygiene/","source_file":"recipes/general/code-hygiene/c-cpp/c-cpp-const-span-view-and-lifetime-hygiene.md","recipe_id":"code-hygiene.c-cpp.c-cpp-const-span-view-and-lifetime-hygiene","recipe_kind":"code-hygiene","category":{"slug":"code-hygiene","label":"Code Hygiene"},"agent":"general","severity":"unspecified","maturity":"development","ecosystem":"c-cpp/cmake","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"","framework_version":"","jurisdiction":"","industry":[],"cve_archetypes":[],"cve_workflow_role":"","tags":["code-hygiene","c-cpp","c","cpp","const","span","string-view","lifetimes"],"facets":["code-hygiene","audit","remediation"],"quality":{"score":100,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context","multi-facet"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"security-recipes.ai contributors","team":"Security Engineering","model":"gpt-5-codex","ai_assisted":false,"generated_by":"","date":"2026-08-21","zero_day":false,"last_updated":"2026-08-21","summary":"C and C++ const, span, view, and lifetime hygiene: Make mutation and non-owning view lifetimes explicit.","content_text":"<!-- Generated by scripts/synccodehygiene_recipes.py; edit data/code-hygiene/catalog.json. --> A tool-agnostic recipe to make mutation and non-owning view lifetimes explicit. It supports a read-only audit and, when explicitly authorized, a narrow remediation. When to use it Use this recipe when the operator's specific objective is to make mutation and non-owning view lifetimes explicit. Prefer a narrower CVE, scanner-finding, security-audit, or compliance-evidence recipe when that is the operator's actual job. Inputs Repository root and the files, package, service, or module in scope. Requested mode: audit or explicitly authorized fix. Supported runtime, compiler, framework, operating-system, and deployment versions inferred from repository files. Existing formatter, compiler, analyzer, test, build, and package-manager commands. Public API, compatibility, performance, generated-code, vendor, and migration constraints. The prompt ~~~markdown You are running the Security Recipes code-hygiene workflow code-hygiene.c-cpp.c-cpp-const-span-view-and-lifetime-hygiene. Start read-only. Do not edit files until the operator explicitly authorizes a fix. Use repository configuration and installed tool versions as authoritative; do not impose a new style or toolchain. Scope Your bounded objective is to make mutation and non-owning view lifetimes explicit. Inspect only operator-scoped, first-party source and configuration. Exclude generated, vendored, minified, fixture snapshot, lock history, and migration history unless explicitly included. Detection Find raw pointer-length pairs, dangling views, temporaries bound to references, unnecessary mutation, and const casts. Trace container reallocation and owner lifetime past every span or view use. Record file and symbol evidence for every candidate. Mark uncertain or dynamically reachable behavior instead of guessing. Fix, only when authorized Use explicit owner and view types with const-correct interfaces and lifetime-safe call structure. Keep the diff limited to the proven issue and its focused tests. Preserve public behavior, API compatibility, and repository conventions. Do not add or broaden suppressions, weaken diagnostics, mass-format unrelated files, upgrade dependencies, or mutate external state. Verification Run tests under sanitizers and exercise empty, temporary, reallocated, and moved-owner cases. Compare diagnostic counts and relevant behavior before and after. Report every command, result, and check that could not run. Stop conditions Stop if interface changes affect ABI or callers outside the repository. Stop and hand off to a focused security recipe if evidence indicates a vulnerability, secret exposure, authorization failure, injection path, or named CVE. Stop rather than widening scope when the safe result requires architecture, product, compliance, operational, or data-owner decisions. ~~~ Output contract Scope and repository evidence reviewed. A candidate table with file or symbol, evidence, confidence, and disposition. In audit mode: no edits, plus the smallest safe next action for each confirmed item. In fix mode: one bounded patch, focused regression coverage, and no unrelated cleanup. Commands run, results, remaining uncertainty, and any stop-condition handoff. Verification Run tests under sanitizers and exercise empty, temporary, reallocated, and moved-owner cases. Confirm that diagnostic configuration, suppressions, public interfaces, generated files, vendored files, and dependencies did not change outside the authorized scope. Review the final diff for behavior changes and run the repository's focused checks before broader suites. Guardrails Read-only until edits are explicitly authorized. Do not deploy, publish, rotate secrets, alter cloud or database state, change CI permissions, or open external tickets. Do not hide debt by disabling rules, adding retries or sleeps, weakening tests, broadening ignores, or lowering warning levels. Treat generated, vendored, minified, migration-history, and fixture-snapshot files as out of scope unless explicitly named. Stop if interface changes affect ABI or callers outside the repository. Related recipes C and C++ compiler warning and suppression debt C and C++ ownership, RAII, and resource lifecycle Browse all code-hygiene recipes References NIST SP 800-218 Secure Software Development Framework 1.1 — NIST C++ Core Guidelines — Standard C++ Foundation Clang sanitizers documentation — LLVM","agent_handoff":{"mcp_lookup_keys":["c-cpp-const-span-view-and-lifetime-hygiene","/recipes/general/code-hygiene/c-cpp/c-cpp-const-span-view-and-lifetime-hygiene/","recipes/general/code-hygiene/c-cpp/c-cpp-const-span-view-and-lifetime-hygiene.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["code-hygiene","audit","remediation"],"source_text_field":"content_text","portable_download":"security-recipe-c-cpp-const-span-view-and-lifetime-hygiene.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-c-cpp-const-span-view-and-lifetime-hygiene.json"}},{"slug":"c-cpp-ownership-raii-and-resource-lifecycle","title":"C and C++ ownership, RAII, and resource lifecycle","link_title":"C and C++ ownership, RAII, and resource lifecycle","url":"https://security-recipes.ai/recipes/general/code-hygiene/c-cpp/c-cpp-ownership-raii-and-resource-lifecycle/","path":"/recipes/general/code-hygiene/c-cpp/c-cpp-ownership-raii-and-resource-lifecycle/","source_file":"recipes/general/code-hygiene/c-cpp/c-cpp-ownership-raii-and-resource-lifecycle.md","recipe_id":"code-hygiene.c-cpp.c-cpp-ownership-raii-and-resource-lifecycle","recipe_kind":"code-hygiene","category":{"slug":"code-hygiene","label":"Code Hygiene"},"agent":"general","severity":"unspecified","maturity":"development","ecosystem":"c-cpp/cmake","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"","framework_version":"","jurisdiction":"","industry":[],"cve_archetypes":[],"cve_workflow_role":"","tags":["code-hygiene","c-cpp","c","cpp","ownership","raii"],"facets":["code-hygiene","audit","remediation"],"quality":{"score":100,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context","multi-facet"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"security-recipes.ai contributors","team":"Security Engineering","model":"gpt-5-codex","ai_assisted":false,"generated_by":"","date":"2026-08-21","zero_day":false,"last_updated":"2026-08-21","summary":"C and C++ ownership, RAII, and resource lifecycle: Make memory, file, socket, lock, and handle ownership explicit.","content_text":"<!-- Generated by scripts/synccodehygiene_recipes.py; edit data/code-hygiene/catalog.json. --> A tool-agnostic recipe to make memory, file, socket, lock, and handle ownership explicit. It supports a read-only audit and, when explicitly authorized, a narrow remediation. When to use it Use this recipe when the operator's specific objective is to make memory, file, socket, lock, and handle ownership explicit. Prefer a narrower CVE, scanner-finding, security-audit, or compliance-evidence recipe when that is the operator's actual job. Inputs Repository root and the files, package, service, or module in scope. Requested mode: audit or explicitly authorized fix. Supported runtime, compiler, framework, operating-system, and deployment versions inferred from repository files. Existing formatter, compiler, analyzer, test, build, and package-manager commands. Public API, compatibility, performance, generated-code, vendor, and migration constraints. The prompt ~~~markdown You are running the Security Recipes code-hygiene workflow code-hygiene.c-cpp.c-cpp-ownership-raii-and-resource-lifecycle. Start read-only. Do not edit files until the operator explicitly authorizes a fix. Use repository configuration and installed tool versions as authoritative; do not impose a new style or toolchain. Scope Your bounded objective is to make memory, file, socket, lock, and handle ownership explicit. Inspect only operator-scoped, first-party source and configuration. Exclude generated, vendored, minified, fixture snapshot, lock history, and migration history unless explicitly included. Detection Trace allocation, acquisition, transfer, release, error jumps, destructors, and raw owning pointers. Identify mismatched allocators, double release, leaks, and resources held beyond need. Record file and symbol evidence for every candidate. Mark uncertain or dynamically reachable behavior instead of guessing. Fix, only when authorized Use scoped cleanup or RAII owners and express transfers without changing non-owning views. Keep the diff limited to the proven issue and its focused tests. Preserve public behavior, API compatibility, and repository conventions. Do not add or broaden suppressions, weaken diagnostics, mass-format unrelated files, upgrade dependencies, or mutate external state. Verification Run focused failure-path tests and configured leak, address, or resource sanitizers. Compare diagnostic counts and relevant behavior before and after. Report every command, result, and check that could not run. Stop conditions Stop when ownership crosses an undocumented C ABI or third-party callback boundary. Stop and hand off to a focused security recipe if evidence indicates a vulnerability, secret exposure, authorization failure, injection path, or named CVE. Stop rather than widening scope when the safe result requires architecture, product, compliance, operational, or data-owner decisions. ~~~ Output contract Scope and repository evidence reviewed. A candidate table with file or symbol, evidence, confidence, and disposition. In audit mode: no edits, plus the smallest safe next action for each confirmed item. In fix mode: one bounded patch, focused regression coverage, and no unrelated cleanup. Commands run, results, remaining uncertainty, and any stop-condition handoff. Verification Run focused failure-path tests and configured leak, address, or resource sanitizers. Confirm that diagnostic configuration, suppressions, public interfaces, generated files, vendored files, and dependencies did not change outside the authorized scope. Review the final diff for behavior changes and run the repository's focused checks before broader suites. Guardrails Read-only until edits are explicitly authorized. Do not deploy, publish, rotate secrets, alter cloud or database state, change CI permissions, or open external tickets. Do not hide debt by disabling rules, adding retries or sleeps, weakening tests, broadening ignores, or lowering warning levels. Treat generated, vendored, minified, migration-history, and fixture-snapshot files as out of scope unless explicitly named. Stop when ownership crosses an undocumented C ABI or third-party callback boundary. Related recipes C and C++ compiler warning and suppression debt C and C++ bounds, integer, and undefined-behavior hygiene Browse all code-hygiene recipes References NIST SP 800-218 Secure Software Development Framework 1.1 — NIST C++ Core Guidelines — Standard C++ Foundation Clang sanitizers documentation — LLVM","agent_handoff":{"mcp_lookup_keys":["c-cpp-ownership-raii-and-resource-lifecycle","/recipes/general/code-hygiene/c-cpp/c-cpp-ownership-raii-and-resource-lifecycle/","recipes/general/code-hygiene/c-cpp/c-cpp-ownership-raii-and-resource-lifecycle.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["code-hygiene","audit","remediation"],"source_text_field":"content_text","portable_download":"security-recipe-c-cpp-ownership-raii-and-resource-lifecycle.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-c-cpp-ownership-raii-and-resource-lifecycle.json"}},{"slug":"complexity-and-long-function-reduction","title":"Complexity and long-function reduction","link_title":"Complexity and long-function reduction","url":"https://security-recipes.ai/recipes/general/code-hygiene/cross-language/complexity-and-long-function-reduction/","path":"/recipes/general/code-hygiene/cross-language/complexity-and-long-function-reduction/","source_file":"recipes/general/code-hygiene/cross-language/complexity-and-long-function-reduction.md","recipe_id":"code-hygiene.cross-language.complexity-and-long-function-reduction","recipe_kind":"code-hygiene","category":{"slug":"code-hygiene","label":"Code Hygiene"},"agent":"general","severity":"unspecified","maturity":"development","ecosystem":"multi-language","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"","framework_version":"","jurisdiction":"","industry":[],"cve_archetypes":[],"cve_workflow_role":"","tags":["code-hygiene","cross-language","complexity","control-flow","refactor"],"facets":["code-hygiene","audit","remediation"],"quality":{"score":100,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context","multi-facet"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"security-recipes.ai contributors","team":"Security Engineering","model":"gpt-5-codex","ai_assisted":false,"generated_by":"","date":"2026-08-21","zero_day":false,"last_updated":"2026-08-21","summary":"Complexity and long-function reduction: Reduce hard-to-review control flow without changing behavior. Includes scoped detection, verification, and stop conditions.","content_text":"<!-- Generated by scripts/synccodehygiene_recipes.py; edit data/code-hygiene/catalog.json. --> A tool-agnostic recipe to reduce hard-to-review control flow without changing behavior. It supports a read-only audit and, when explicitly authorized, a narrow remediation. When to use it Use this recipe when the operator's specific objective is to reduce hard-to-review control flow without changing behavior. Prefer a narrower CVE, scanner-finding, security-audit, or compliance-evidence recipe when that is the operator's actual job. Inputs Repository root and the files, package, service, or module in scope. Requested mode: audit or explicitly authorized fix. Supported runtime, compiler, framework, operating-system, and deployment versions inferred from repository files. Existing formatter, compiler, analyzer, test, build, and package-manager commands. Public API, compatibility, performance, generated-code, vendor, and migration constraints. The prompt ~~~markdown You are running the Security Recipes code-hygiene workflow code-hygiene.cross-language.complexity-and-long-function-reduction. Start read-only. Do not edit files until the operator explicitly authorizes a fix. Use repository configuration and installed tool versions as authoritative; do not impose a new style or toolchain. Scope Your bounded objective is to reduce hard-to-review control flow without changing behavior. Inspect only operator-scoped, first-party source and configuration. Exclude generated, vendored, minified, fixture snapshot, lock history, and migration history unless explicitly included. Detection Use configured complexity diagnostics and inspect nesting, early exits, state mutation, and mixed responsibilities. Capture observable behavior before choosing extraction boundaries. Record file and symbol evidence for every candidate. Mark uncertain or dynamically reachable behavior instead of guessing. Fix, only when authorized Extract cohesive pure or side-effect-bounded units and simplify control flow in reviewable increments. Keep the diff limited to the proven issue and its focused tests. Preserve public behavior, API compatibility, and repository conventions. Do not add or broaden suppressions, weaken diagnostics, mass-format unrelated files, upgrade dependencies, or mutate external state. Verification Run characterization tests and compare outputs, exceptions, side effects, and performance-sensitive paths. Compare diagnostic counts and relevant behavior before and after. Report every command, result, and check that could not run. Stop conditions Stop if behavior is untested, timing-dependent, protocol-sensitive, or requires a public API redesign. Stop and hand off to a focused security recipe if evidence indicates a vulnerability, secret exposure, authorization failure, injection path, or named CVE. Stop rather than widening scope when the safe result requires architecture, product, compliance, operational, or data-owner decisions. ~~~ Output contract Scope and repository evidence reviewed. A candidate table with file or symbol, evidence, confidence, and disposition. In audit mode: no edits, plus the smallest safe next action for each confirmed item. In fix mode: one bounded patch, focused regression coverage, and no unrelated cleanup. Commands run, results, remaining uncertainty, and any stop-condition handoff. Verification Run characterization tests and compare outputs, exceptions, side effects, and performance-sensitive paths. Confirm that diagnostic configuration, suppressions, public interfaces, generated files, vendored files, and dependencies did not change outside the authorized scope. Review the final diff for behavior changes and run the repository's focused checks before broader suites. Guardrails Read-only until edits are explicitly authorized. Do not deploy, publish, rotate secrets, alter cloud or database state, change CI permissions, or open external tickets. Do not hide debt by disabling rules, adding retries or sleeps, weakening tests, broadening ignores, or lowering warning levels. Treat generated, vendored, minified, migration-history, and fixture-snapshot files as out of scope unless explicitly named. Stop if behavior is untested, timing-dependent, protocol-sensitive, or requires a public API redesign. Related recipes Lint warning baseline and budget Dead code and unused symbol removal Browse all code-hygiene recipes References NIST SP 800-218 Secure Software Development Framework 1.1 — NIST OWASP Developer Guide - Implementation — OWASP","agent_handoff":{"mcp_lookup_keys":["complexity-and-long-function-reduction","/recipes/general/code-hygiene/cross-language/complexity-and-long-function-reduction/","recipes/general/code-hygiene/cross-language/complexity-and-long-function-reduction.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["code-hygiene","audit","remediation"],"source_text_field":"content_text","portable_download":"security-recipe-complexity-and-long-function-reduction.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-complexity-and-long-function-reduction.json"}},{"slug":"configuration-validation-and-default-hygiene","title":"Configuration validation and default hygiene","link_title":"Configuration validation and default hygiene","url":"https://security-recipes.ai/recipes/general/code-hygiene/cross-language/configuration-validation-and-default-hygiene/","path":"/recipes/general/code-hygiene/cross-language/configuration-validation-and-default-hygiene/","source_file":"recipes/general/code-hygiene/cross-language/configuration-validation-and-default-hygiene.md","recipe_id":"code-hygiene.cross-language.configuration-validation-and-default-hygiene","recipe_kind":"code-hygiene","category":{"slug":"code-hygiene","label":"Code Hygiene"},"agent":"general","severity":"unspecified","maturity":"development","ecosystem":"multi-language","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"","framework_version":"","jurisdiction":"","industry":[],"cve_archetypes":[],"cve_workflow_role":"","tags":["code-hygiene","cross-language","configuration","validation","defaults"],"facets":["code-hygiene","audit","remediation"],"quality":{"score":100,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context","multi-facet"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"security-recipes.ai contributors","team":"Security Engineering","model":"gpt-5-codex","ai_assisted":false,"generated_by":"","date":"2026-08-21","zero_day":false,"last_updated":"2026-08-21","summary":"Configuration validation and default hygiene: Make invalid configuration fail clearly and defaults behave consistently.","content_text":"<!-- Generated by scripts/synccodehygiene_recipes.py; edit data/code-hygiene/catalog.json. --> A tool-agnostic recipe to make invalid configuration fail clearly and defaults behave consistently. It supports a read-only audit and, when explicitly authorized, a narrow remediation. When to use it Use this recipe when the operator's specific objective is to make invalid configuration fail clearly and defaults behave consistently. Prefer a narrower CVE, scanner-finding, security-audit, or compliance-evidence recipe when that is the operator's actual job. Inputs Repository root and the files, package, service, or module in scope. Requested mode: audit or explicitly authorized fix. Supported runtime, compiler, framework, operating-system, and deployment versions inferred from repository files. Existing formatter, compiler, analyzer, test, build, and package-manager commands. Public API, compatibility, performance, generated-code, vendor, and migration constraints. The prompt ~~~markdown You are running the Security Recipes code-hygiene workflow code-hygiene.cross-language.configuration-validation-and-default-hygiene. Start read-only. Do not edit files until the operator explicitly authorizes a fix. Use repository configuration and installed tool versions as authoritative; do not impose a new style or toolchain. Scope Your bounded objective is to make invalid configuration fail clearly and defaults behave consistently. Inspect only operator-scoped, first-party source and configuration. Exclude generated, vendored, minified, fixture snapshot, lock history, and migration history unless explicitly included. Detection Trace configuration sources, precedence, parsing, coercion, defaults, and startup failure behavior. Identify ambiguous empty, missing, zero, false, and null states. Record file and symbol evidence for every candidate. Mark uncertain or dynamically reachable behavior instead of guessing. Fix, only when authorized Centralize typed validation and preserve documented precedence and backward-compatible defaults. Keep the diff limited to the proven issue and its focused tests. Preserve public behavior, API compatibility, and repository conventions. Do not add or broaden suppressions, weaken diagnostics, mass-format unrelated files, upgrade dependencies, or mutate external state. Verification Test valid, missing, malformed, boundary, and conflicting configuration inputs. Compare diagnostic counts and relevant behavior before and after. Report every command, result, and check that could not run. Stop conditions Stop if changing a default could alter production behavior or requires secret values to test. Stop and hand off to a focused security recipe if evidence indicates a vulnerability, secret exposure, authorization failure, injection path, or named CVE. Stop rather than widening scope when the safe result requires architecture, product, compliance, operational, or data-owner decisions. ~~~ Output contract Scope and repository evidence reviewed. A candidate table with file or symbol, evidence, confidence, and disposition. In audit mode: no edits, plus the smallest safe next action for each confirmed item. In fix mode: one bounded patch, focused regression coverage, and no unrelated cleanup. Commands run, results, remaining uncertainty, and any stop-condition handoff. Verification Test valid, missing, malformed, boundary, and conflicting configuration inputs. Confirm that diagnostic configuration, suppressions, public interfaces, generated files, vendored files, and dependencies did not change outside the authorized scope. Review the final diff for behavior changes and run the repository's focused checks before broader suites. Guardrails Read-only until edits are explicitly authorized. Do not deploy, publish, rotate secrets, alter cloud or database state, change CI permissions, or open external tickets. Do not hide debt by disabling rules, adding retries or sleeps, weakening tests, broadening ignores, or lowering warning levels. Treat generated, vendored, minified, migration-history, and fixture-snapshot files as out of scope unless explicitly named. Stop if changing a default could alter production behavior or requires secret values to test. Related recipes Lint warning baseline and budget Dead code and unused symbol removal Browse all code-hygiene recipes References NIST SP 800-218 Secure Software Development Framework 1.1 — NIST OWASP Developer Guide - Implementation — OWASP","agent_handoff":{"mcp_lookup_keys":["configuration-validation-and-default-hygiene","/recipes/general/code-hygiene/cross-language/configuration-validation-and-default-hygiene/","recipes/general/code-hygiene/cross-language/configuration-validation-and-default-hygiene.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["code-hygiene","audit","remediation"],"source_text_field":"content_text","portable_download":"security-recipe-configuration-validation-and-default-hygiene.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-configuration-validation-and-default-hygiene.json"}},{"slug":"dead-code-and-unused-symbol-removal","title":"Dead code and unused symbol removal","link_title":"Dead code and unused symbol removal","url":"https://security-recipes.ai/recipes/general/code-hygiene/cross-language/dead-code-and-unused-symbol-removal/","path":"/recipes/general/code-hygiene/cross-language/dead-code-and-unused-symbol-removal/","source_file":"recipes/general/code-hygiene/cross-language/dead-code-and-unused-symbol-removal.md","recipe_id":"code-hygiene.cross-language.dead-code-and-unused-symbol-removal","recipe_kind":"code-hygiene","category":{"slug":"code-hygiene","label":"Code Hygiene"},"agent":"general","severity":"unspecified","maturity":"development","ecosystem":"multi-language","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"","framework_version":"","jurisdiction":"","industry":[],"cve_archetypes":[],"cve_workflow_role":"","tags":["code-hygiene","cross-language","dead-code","unused","reachability"],"facets":["code-hygiene","audit","remediation"],"quality":{"score":100,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context","multi-facet"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"security-recipes.ai contributors","team":"Security Engineering","model":"gpt-5-codex","ai_assisted":false,"generated_by":"","date":"2026-08-21","zero_day":false,"last_updated":"2026-08-21","summary":"Dead code and unused symbol removal: Remove unreachable code and unused symbols without deleting runtime-discovered behavior.","content_text":"<!-- Generated by scripts/synccodehygiene_recipes.py; edit data/code-hygiene/catalog.json. --> A tool-agnostic recipe to remove unreachable code and unused symbols without deleting runtime-discovered behavior. It supports a read-only audit and, when explicitly authorized, a narrow remediation. When to use it Use this recipe when the operator's specific objective is to remove unreachable code and unused symbols without deleting runtime-discovered behavior. Prefer a narrower CVE, scanner-finding, security-audit, or compliance-evidence recipe when that is the operator's actual job. Inputs Repository root and the files, package, service, or module in scope. Requested mode: audit or explicitly authorized fix. Supported runtime, compiler, framework, operating-system, and deployment versions inferred from repository files. Existing formatter, compiler, analyzer, test, build, and package-manager commands. Public API, compatibility, performance, generated-code, vendor, and migration constraints. The prompt ~~~markdown You are running the Security Recipes code-hygiene workflow code-hygiene.cross-language.dead-code-and-unused-symbol-removal. Start read-only. Do not edit files until the operator explicitly authorizes a fix. Use repository configuration and installed tool versions as authoritative; do not impose a new style or toolchain. Scope Your bounded objective is to remove unreachable code and unused symbols without deleting runtime-discovered behavior. Inspect only operator-scoped, first-party source and configuration. Exclude generated, vendored, minified, fixture snapshot, lock history, and migration history unless explicitly included. Detection Combine compiler or linter diagnostics with call-site, export, reflection, plugin, and configuration searches. Mark code as proven unused, dynamically reachable, or uncertain. Record file and symbol evidence for every candidate. Mark uncertain or dynamically reachable behavior instead of guessing. Fix, only when authorized Delete only proven-unused code and update tests, exports, and documentation that referenced it. Keep the diff limited to the proven issue and its focused tests. Preserve public behavior, API compatibility, and repository conventions. Do not add or broaden suppressions, weaken diagnostics, mass-format unrelated files, upgrade dependencies, or mutate external state. Verification Build and run focused tests plus any plugin, reflection, serialization, or registration checks. Compare diagnostic counts and relevant behavior before and after. Report every command, result, and check that could not run. Stop conditions Stop on dynamic loading, public API compatibility, reflection, generated registration, or unclear ownership. Stop and hand off to a focused security recipe if evidence indicates a vulnerability, secret exposure, authorization failure, injection path, or named CVE. Stop rather than widening scope when the safe result requires architecture, product, compliance, operational, or data-owner decisions. ~~~ Output contract Scope and repository evidence reviewed. A candidate table with file or symbol, evidence, confidence, and disposition. In audit mode: no edits, plus the smallest safe next action for each confirmed item. In fix mode: one bounded patch, focused regression coverage, and no unrelated cleanup. Commands run, results, remaining uncertainty, and any stop-condition handoff. Verification Build and run focused tests plus any plugin, reflection, serialization, or registration checks. Confirm that diagnostic configuration, suppressions, public interfaces, generated files, vendored files, and dependencies did not change outside the authorized scope. Review the final diff for behavior changes and run the repository's focused checks before broader suites. Guardrails Read-only until edits are explicitly authorized. Do not deploy, publish, rotate secrets, alter cloud or database state, change CI permissions, or open external tickets. Do not hide debt by disabling rules, adding retries or sleeps, weakening tests, broadening ignores, or lowering warning levels. Treat generated, vendored, minified, migration-history, and fixture-snapshot files as out of scope unless explicitly named. Stop on dynamic loading, public API compatibility, reflection, generated registration, or unclear ownership. Related recipes Lint warning baseline and budget Duplicated logic consolidation Browse all code-hygiene recipes References NIST SP 800-218 Secure Software Development Framework 1.1 — NIST OWASP Developer Guide - Implementation — OWASP","agent_handoff":{"mcp_lookup_keys":["dead-code-and-unused-symbol-removal","/recipes/general/code-hygiene/cross-language/dead-code-and-unused-symbol-removal/","recipes/general/code-hygiene/cross-language/dead-code-and-unused-symbol-removal.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["code-hygiene","audit","remediation"],"source_text_field":"content_text","portable_download":"security-recipe-dead-code-and-unused-symbol-removal.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-dead-code-and-unused-symbol-removal.json"}},{"slug":"dependency-manifest-and-lockfile-hygiene","title":"Dependency manifest and lockfile hygiene","link_title":"Dependency manifest and lockfile hygiene","url":"https://security-recipes.ai/recipes/general/code-hygiene/cross-language/dependency-manifest-and-lockfile-hygiene/","path":"/recipes/general/code-hygiene/cross-language/dependency-manifest-and-lockfile-hygiene/","source_file":"recipes/general/code-hygiene/cross-language/dependency-manifest-and-lockfile-hygiene.md","recipe_id":"code-hygiene.cross-language.dependency-manifest-and-lockfile-hygiene","recipe_kind":"code-hygiene","category":{"slug":"code-hygiene","label":"Code Hygiene"},"agent":"general","severity":"unspecified","maturity":"development","ecosystem":"multi-language","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"","framework_version":"","jurisdiction":"","industry":[],"cve_archetypes":[],"cve_workflow_role":"","tags":["code-hygiene","cross-language","dependencies","lockfiles","manifests"],"facets":["code-hygiene","audit","remediation"],"quality":{"score":100,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context","multi-facet"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"security-recipes.ai contributors","team":"Security Engineering","model":"gpt-5-codex","ai_assisted":false,"generated_by":"","date":"2026-08-21","zero_day":false,"last_updated":"2026-08-21","summary":"Dependency manifest and lockfile hygiene: Align declared, resolved, direct, optional, and unused dependencies without upgrading them.","content_text":"<!-- Generated by scripts/synccodehygiene_recipes.py; edit data/code-hygiene/catalog.json. --> A tool-agnostic recipe to align declared, resolved, direct, optional, and unused dependencies without upgrading them. It supports a read-only audit and, when explicitly authorized, a narrow remediation. When to use it Use this recipe when the operator's specific objective is to align declared, resolved, direct, optional, and unused dependencies without upgrading them. Prefer a narrower CVE, scanner-finding, security-audit, or compliance-evidence recipe when that is the operator's actual job. Inputs Repository root and the files, package, service, or module in scope. Requested mode: audit or explicitly authorized fix. Supported runtime, compiler, framework, operating-system, and deployment versions inferred from repository files. Existing formatter, compiler, analyzer, test, build, and package-manager commands. Public API, compatibility, performance, generated-code, vendor, and migration constraints. The prompt ~~~markdown You are running the Security Recipes code-hygiene workflow code-hygiene.cross-language.dependency-manifest-and-lockfile-hygiene. Start read-only. Do not edit files until the operator explicitly authorizes a fix. Use repository configuration and installed tool versions as authoritative; do not impose a new style or toolchain. Scope Your bounded objective is to align declared, resolved, direct, optional, and unused dependencies without upgrading them. Inspect only operator-scoped, first-party source and configuration. Exclude generated, vendored, minified, fixture snapshot, lock history, and migration history unless explicitly included. Detection Compare manifests, lockfiles, workspace definitions, imports, build plugins, scripts, and deployment packaging. Classify direct, transitive, optional, platform, development, and apparently unused dependencies. Record file and symbol evidence for every candidate. Mark uncertain or dynamically reachable behavior instead of guessing. Fix, only when authorized Remove only proven-unused declarations and regenerate lock metadata with the repository's pinned toolchain. Keep the diff limited to the proven issue and its focused tests. Preserve public behavior, API compatibility, and repository conventions. Do not add or broaden suppressions, weaken diagnostics, mass-format unrelated files, upgrade dependencies, or mutate external state. Verification Perform frozen or locked installs, builds, tests, and package-content checks. Compare diagnostic counts and relevant behavior before and after. Report every command, result, and check that could not run. Stop conditions Stop before version upgrades, provenance changes, registry changes, or removal of dynamically loaded packages. Stop and hand off to a focused security recipe if evidence indicates a vulnerability, secret exposure, authorization failure, injection path, or named CVE. Stop rather than widening scope when the safe result requires architecture, product, compliance, operational, or data-owner decisions. ~~~ Output contract Scope and repository evidence reviewed. A candidate table with file or symbol, evidence, confidence, and disposition. In audit mode: no edits, plus the smallest safe next action for each confirmed item. In fix mode: one bounded patch, focused regression coverage, and no unrelated cleanup. Commands run, results, remaining uncertainty, and any stop-condition handoff. Verification Perform frozen or locked installs, builds, tests, and package-content checks. Confirm that diagnostic configuration, suppressions, public interfaces, generated files, vendored files, and dependencies did not change outside the authorized scope. Review the final diff for behavior changes and run the repository's focused checks before broader suites. Guardrails Read-only until edits are explicitly authorized. Do not deploy, publish, rotate secrets, alter cloud or database state, change CI permissions, or open external tickets. Do not hide debt by disabling rules, adding retries or sleeps, weakening tests, broadening ignores, or lowering warning levels. Treat generated, vendored, minified, migration-history, and fixture-snapshot files as out of scope unless explicitly named. Stop before version upgrades, provenance changes, registry changes, or removal of dynamically loaded packages. Related recipes Lint warning baseline and budget Dead code and unused symbol removal Browse all code-hygiene recipes References NIST SP 800-218 Secure Software Development Framework 1.1 — NIST OWASP Developer Guide - Implementation — OWASP","agent_handoff":{"mcp_lookup_keys":["dependency-manifest-and-lockfile-hygiene","/recipes/general/code-hygiene/cross-language/dependency-manifest-and-lockfile-hygiene/","recipes/general/code-hygiene/cross-language/dependency-manifest-and-lockfile-hygiene.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["code-hygiene","audit","remediation"],"source_text_field":"content_text","portable_download":"security-recipe-dependency-manifest-and-lockfile-hygiene.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-dependency-manifest-and-lockfile-hygiene.json"}},{"slug":"deprecated-api-migration","title":"Deprecated API migration","link_title":"Deprecated API migration","url":"https://security-recipes.ai/recipes/general/code-hygiene/cross-language/deprecated-api-migration/","path":"/recipes/general/code-hygiene/cross-language/deprecated-api-migration/","source_file":"recipes/general/code-hygiene/cross-language/deprecated-api-migration.md","recipe_id":"code-hygiene.cross-language.deprecated-api-migration","recipe_kind":"code-hygiene","category":{"slug":"code-hygiene","label":"Code Hygiene"},"agent":"general","severity":"unspecified","maturity":"development","ecosystem":"multi-language","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"","framework_version":"","jurisdiction":"","industry":[],"cve_archetypes":[],"cve_workflow_role":"","tags":["code-hygiene","cross-language","deprecation","compatibility","migration"],"facets":["code-hygiene","audit","remediation"],"quality":{"score":100,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context","multi-facet"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"security-recipes.ai contributors","team":"Security Engineering","model":"gpt-5-codex","ai_assisted":false,"generated_by":"","date":"2026-08-21","zero_day":false,"last_updated":"2026-08-21","summary":"Deprecated API migration: Replace deprecated APIs using the repository's supported runtime versions. Includes scoped detection, verification, and stop conditions.","content_text":"<!-- Generated by scripts/synccodehygiene_recipes.py; edit data/code-hygiene/catalog.json. --> A tool-agnostic recipe to replace deprecated APIs using the repository's supported runtime versions. It supports a read-only audit and, when explicitly authorized, a narrow remediation. When to use it Use this recipe when the operator's specific objective is to replace deprecated APIs using the repository's supported runtime versions. Prefer a narrower CVE, scanner-finding, security-audit, or compliance-evidence recipe when that is the operator's actual job. Inputs Repository root and the files, package, service, or module in scope. Requested mode: audit or explicitly authorized fix. Supported runtime, compiler, framework, operating-system, and deployment versions inferred from repository files. Existing formatter, compiler, analyzer, test, build, and package-manager commands. Public API, compatibility, performance, generated-code, vendor, and migration constraints. The prompt ~~~markdown You are running the Security Recipes code-hygiene workflow code-hygiene.cross-language.deprecated-api-migration. Start read-only. Do not edit files until the operator explicitly authorizes a fix. Use repository configuration and installed tool versions as authoritative; do not impose a new style or toolchain. Scope Your bounded objective is to replace deprecated APIs using the repository's supported runtime versions. Inspect only operator-scoped, first-party source and configuration. Exclude generated, vendored, minified, fixture snapshot, lock history, and migration history unless explicitly included. Detection Collect compiler and runtime deprecations and confirm the installed and minimum supported versions. Find wrappers, downstream callers, serialization contracts, and documented compatibility promises. Record file and symbol evidence for every candidate. Mark uncertain or dynamically reachable behavior instead of guessing. Fix, only when authorized Use the documented replacement with the smallest compatibility-preserving adapter necessary. Keep the diff limited to the proven issue and its focused tests. Preserve public behavior, API compatibility, and repository conventions. Do not add or broaden suppressions, weaken diagnostics, mass-format unrelated files, upgrade dependencies, or mutate external state. Verification Build against supported version bounds and run focused behavior and compatibility tests. Compare diagnostic counts and relevant behavior before and after. Report every command, result, and check that could not run. Stop conditions Stop if the replacement requires dropping a supported runtime or changing a public contract. Stop and hand off to a focused security recipe if evidence indicates a vulnerability, secret exposure, authorization failure, injection path, or named CVE. Stop rather than widening scope when the safe result requires architecture, product, compliance, operational, or data-owner decisions. ~~~ Output contract Scope and repository evidence reviewed. A candidate table with file or symbol, evidence, confidence, and disposition. In audit mode: no edits, plus the smallest safe next action for each confirmed item. In fix mode: one bounded patch, focused regression coverage, and no unrelated cleanup. Commands run, results, remaining uncertainty, and any stop-condition handoff. Verification Build against supported version bounds and run focused behavior and compatibility tests. Confirm that diagnostic configuration, suppressions, public interfaces, generated files, vendored files, and dependencies did not change outside the authorized scope. Review the final diff for behavior changes and run the repository's focused checks before broader suites. Guardrails Read-only until edits are explicitly authorized. Do not deploy, publish, rotate secrets, alter cloud or database state, change CI permissions, or open external tickets. Do not hide debt by disabling rules, adding retries or sleeps, weakening tests, broadening ignores, or lowering warning levels. Treat generated, vendored, minified, migration-history, and fixture-snapshot files as out of scope unless explicitly named. Stop if the replacement requires dropping a supported runtime or changing a public contract. Related recipes Lint warning baseline and budget Dead code and unused symbol removal Browse all code-hygiene recipes References NIST SP 800-218 Secure Software Development Framework 1.1 — NIST OWASP Developer Guide - Implementation — OWASP","agent_handoff":{"mcp_lookup_keys":["deprecated-api-migration","/recipes/general/code-hygiene/cross-language/deprecated-api-migration/","recipes/general/code-hygiene/cross-language/deprecated-api-migration.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["code-hygiene","audit","remediation"],"source_text_field":"content_text","portable_download":"security-recipe-deprecated-api-migration.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-deprecated-api-migration.json"}},{"slug":"deterministic-test-and-flake-remediation","title":"Deterministic test and flake remediation","link_title":"Deterministic test and flake remediation","url":"https://security-recipes.ai/recipes/general/code-hygiene/cross-language/deterministic-test-and-flake-remediation/","path":"/recipes/general/code-hygiene/cross-language/deterministic-test-and-flake-remediation/","source_file":"recipes/general/code-hygiene/cross-language/deterministic-test-and-flake-remediation.md","recipe_id":"code-hygiene.cross-language.deterministic-test-and-flake-remediation","recipe_kind":"code-hygiene","category":{"slug":"code-hygiene","label":"Code Hygiene"},"agent":"general","severity":"unspecified","maturity":"development","ecosystem":"multi-language","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"","framework_version":"","jurisdiction":"","industry":[],"cve_archetypes":[],"cve_workflow_role":"","tags":["code-hygiene","cross-language","tests","flaky","determinism"],"facets":["code-hygiene","audit","remediation"],"quality":{"score":100,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context","multi-facet"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"security-recipes.ai contributors","team":"Security Engineering","model":"gpt-5-codex","ai_assisted":false,"generated_by":"","date":"2026-08-21","zero_day":false,"last_updated":"2026-08-21","summary":"Deterministic test and flake remediation: Remove nondeterminism from a reproducibly flaky test. Includes scoped detection, verification, and stop conditions.","content_text":"<!-- Generated by scripts/synccodehygiene_recipes.py; edit data/code-hygiene/catalog.json. --> A tool-agnostic recipe to remove nondeterminism from a reproducibly flaky test. It supports a read-only audit and, when explicitly authorized, a narrow remediation. When to use it Use this recipe when the operator's specific objective is to remove nondeterminism from a reproducibly flaky test. Prefer a narrower CVE, scanner-finding, security-audit, or compliance-evidence recipe when that is the operator's actual job. Inputs Repository root and the files, package, service, or module in scope. Requested mode: audit or explicitly authorized fix. Supported runtime, compiler, framework, operating-system, and deployment versions inferred from repository files. Existing formatter, compiler, analyzer, test, build, and package-manager commands. Public API, compatibility, performance, generated-code, vendor, and migration constraints. The prompt ~~~markdown You are running the Security Recipes code-hygiene workflow code-hygiene.cross-language.deterministic-test-and-flake-remediation. Start read-only. Do not edit files until the operator explicitly authorizes a fix. Use repository configuration and installed tool versions as authoritative; do not impose a new style or toolchain. Scope Your bounded objective is to remove nondeterminism from a reproducibly flaky test. Inspect only operator-scoped, first-party source and configuration. Exclude generated, vendored, minified, fixture snapshot, lock history, and migration history unless explicitly included. Detection Reproduce with repeated, shuffled, isolated, and parallel runs while recording seed and environment. Classify clock, randomness, shared state, network, filesystem, ordering, or concurrency causes. Record file and symbol evidence for every candidate. Mark uncertain or dynamically reachable behavior instead of guessing. Fix, only when authorized Control the identified nondeterministic boundary instead of adding retries or broad sleeps. Keep the diff limited to the proven issue and its focused tests. Preserve public behavior, API compatibility, and repository conventions. Do not add or broaden suppressions, weaken diagnostics, mass-format unrelated files, upgrade dependencies, or mutate external state. Verification Run the focused test repeatedly under the triggering mode and then run the containing suite. Compare diagnostic counts and relevant behavior before and after. Report every command, result, and check that could not run. Stop conditions Stop if the failure cannot be reproduced or the fix would weaken assertions or mask a product race. Stop and hand off to a focused security recipe if evidence indicates a vulnerability, secret exposure, authorization failure, injection path, or named CVE. Stop rather than widening scope when the safe result requires architecture, product, compliance, operational, or data-owner decisions. ~~~ Output contract Scope and repository evidence reviewed. A candidate table with file or symbol, evidence, confidence, and disposition. In audit mode: no edits, plus the smallest safe next action for each confirmed item. In fix mode: one bounded patch, focused regression coverage, and no unrelated cleanup. Commands run, results, remaining uncertainty, and any stop-condition handoff. Verification Run the focused test repeatedly under the triggering mode and then run the containing suite. Confirm that diagnostic configuration, suppressions, public interfaces, generated files, vendored files, and dependencies did not change outside the authorized scope. Review the final diff for behavior changes and run the repository's focused checks before broader suites. Guardrails Read-only until edits are explicitly authorized. Do not deploy, publish, rotate secrets, alter cloud or database state, change CI permissions, or open external tickets. Do not hide debt by disabling rules, adding retries or sleeps, weakening tests, broadening ignores, or lowering warning levels. Treat generated, vendored, minified, migration-history, and fixture-snapshot files as out of scope unless explicitly named. Stop if the failure cannot be reproduced or the fix would weaken assertions or mask a product race. Related recipes Lint warning baseline and budget Dead code and unused symbol removal Browse all code-hygiene recipes References NIST SP 800-218 Secure Software Development Framework 1.1 — NIST OWASP Developer Guide - Implementation — OWASP","agent_handoff":{"mcp_lookup_keys":["deterministic-test-and-flake-remediation","/recipes/general/code-hygiene/cross-language/deterministic-test-and-flake-remediation/","recipes/general/code-hygiene/cross-language/deterministic-test-and-flake-remediation.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["code-hygiene","audit","remediation"],"source_text_field":"content_text","portable_download":"security-recipe-deterministic-test-and-flake-remediation.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-deterministic-test-and-flake-remediation.json"}},{"slug":"duplicated-logic-consolidation","title":"Duplicated logic consolidation","link_title":"Duplicated logic consolidation","url":"https://security-recipes.ai/recipes/general/code-hygiene/cross-language/duplicated-logic-consolidation/","path":"/recipes/general/code-hygiene/cross-language/duplicated-logic-consolidation/","source_file":"recipes/general/code-hygiene/cross-language/duplicated-logic-consolidation.md","recipe_id":"code-hygiene.cross-language.duplicated-logic-consolidation","recipe_kind":"code-hygiene","category":{"slug":"code-hygiene","label":"Code Hygiene"},"agent":"general","severity":"unspecified","maturity":"development","ecosystem":"multi-language","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"","framework_version":"","jurisdiction":"","industry":[],"cve_archetypes":[],"cve_workflow_role":"","tags":["code-hygiene","cross-language","duplication","refactor","contracts"],"facets":["code-hygiene","audit","remediation"],"quality":{"score":100,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context","multi-facet"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"security-recipes.ai contributors","team":"Security Engineering","model":"gpt-5-codex","ai_assisted":false,"generated_by":"","date":"2026-08-21","zero_day":false,"last_updated":"2026-08-21","summary":"Duplicated logic consolidation: Consolidate behaviorally equivalent logic while preserving each caller's contract.","content_text":"<!-- Generated by scripts/synccodehygiene_recipes.py; edit data/code-hygiene/catalog.json. --> A tool-agnostic recipe to consolidate behaviorally equivalent logic while preserving each caller's contract. It supports a read-only audit and, when explicitly authorized, a narrow remediation. When to use it Use this recipe when the operator's specific objective is to consolidate behaviorally equivalent logic while preserving each caller's contract. Prefer a narrower CVE, scanner-finding, security-audit, or compliance-evidence recipe when that is the operator's actual job. Inputs Repository root and the files, package, service, or module in scope. Requested mode: audit or explicitly authorized fix. Supported runtime, compiler, framework, operating-system, and deployment versions inferred from repository files. Existing formatter, compiler, analyzer, test, build, and package-manager commands. Public API, compatibility, performance, generated-code, vendor, and migration constraints. The prompt ~~~markdown You are running the Security Recipes code-hygiene workflow code-hygiene.cross-language.duplicated-logic-consolidation. Start read-only. Do not edit files until the operator explicitly authorizes a fix. Use repository configuration and installed tool versions as authoritative; do not impose a new style or toolchain. Scope Your bounded objective is to consolidate behaviorally equivalent logic while preserving each caller's contract. Inspect only operator-scoped, first-party source and configuration. Exclude generated, vendored, minified, fixture snapshot, lock history, and migration history unless explicitly included. Detection Find structurally similar blocks and compare inputs, outputs, side effects, and error semantics. Reject textually similar code whose business rules or lifecycle differ. Record file and symbol evidence for every candidate. Mark uncertain or dynamically reachable behavior instead of guessing. Fix, only when authorized Extract the smallest shared unit and keep caller-specific policy at the call sites. Keep the diff limited to the proven issue and its focused tests. Preserve public behavior, API compatibility, and repository conventions. Do not add or broaden suppressions, weaken diagnostics, mass-format unrelated files, upgrade dependencies, or mutate external state. Verification Run tests for every former copy and add a characterization test for the shared invariant. Compare diagnostic counts and relevant behavior before and after. Report every command, result, and check that could not run. Stop conditions Stop when consolidation would merge distinct authorization, tenancy, transaction, or compatibility rules. Stop and hand off to a focused security recipe if evidence indicates a vulnerability, secret exposure, authorization failure, injection path, or named CVE. Stop rather than widening scope when the safe result requires architecture, product, compliance, operational, or data-owner decisions. ~~~ Output contract Scope and repository evidence reviewed. A candidate table with file or symbol, evidence, confidence, and disposition. In audit mode: no edits, plus the smallest safe next action for each confirmed item. In fix mode: one bounded patch, focused regression coverage, and no unrelated cleanup. Commands run, results, remaining uncertainty, and any stop-condition handoff. Verification Run tests for every former copy and add a characterization test for the shared invariant. Confirm that diagnostic configuration, suppressions, public interfaces, generated files, vendored files, and dependencies did not change outside the authorized scope. Review the final diff for behavior changes and run the repository's focused checks before broader suites. Guardrails Read-only until edits are explicitly authorized. Do not deploy, publish, rotate secrets, alter cloud or database state, change CI permissions, or open external tickets. Do not hide debt by disabling rules, adding retries or sleeps, weakening tests, broadening ignores, or lowering warning levels. Treat generated, vendored, minified, migration-history, and fixture-snapshot files as out of scope unless explicitly named. Stop when consolidation would merge distinct authorization, tenancy, transaction, or compatibility rules. Related recipes Lint warning baseline and budget Dead code and unused symbol removal Browse all code-hygiene recipes References NIST SP 800-218 Secure Software Development Framework 1.1 — NIST OWASP Developer Guide - Implementation — OWASP","agent_handoff":{"mcp_lookup_keys":["duplicated-logic-consolidation","/recipes/general/code-hygiene/cross-language/duplicated-logic-consolidation/","recipes/general/code-hygiene/cross-language/duplicated-logic-consolidation.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["code-hygiene","audit","remediation"],"source_text_field":"content_text","portable_download":"security-recipe-duplicated-logic-consolidation.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-duplicated-logic-consolidation.json"}},{"slug":"feature-flag-and-experiment-cleanup","title":"Feature flag and experiment cleanup","link_title":"Feature flag and experiment cleanup","url":"https://security-recipes.ai/recipes/general/code-hygiene/cross-language/feature-flag-and-experiment-cleanup/","path":"/recipes/general/code-hygiene/cross-language/feature-flag-and-experiment-cleanup/","source_file":"recipes/general/code-hygiene/cross-language/feature-flag-and-experiment-cleanup.md","recipe_id":"code-hygiene.cross-language.feature-flag-and-experiment-cleanup","recipe_kind":"code-hygiene","category":{"slug":"code-hygiene","label":"Code Hygiene"},"agent":"general","severity":"unspecified","maturity":"development","ecosystem":"multi-language","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"","framework_version":"","jurisdiction":"","industry":[],"cve_archetypes":[],"cve_workflow_role":"","tags":["code-hygiene","cross-language","feature-flags","experiments","dead-code"],"facets":["code-hygiene","audit","remediation"],"quality":{"score":100,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context","multi-facet"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"security-recipes.ai contributors","team":"Security Engineering","model":"gpt-5-codex","ai_assisted":false,"generated_by":"","date":"2026-08-21","zero_day":false,"last_updated":"2026-08-21","summary":"Feature flag and experiment cleanup: Remove stale feature-flag branches after rollout state is proven. Includes scoped detection, verification, and stop conditions.","content_text":"<!-- Generated by scripts/synccodehygiene_recipes.py; edit data/code-hygiene/catalog.json. --> A tool-agnostic recipe to remove stale feature-flag branches after rollout state is proven. It supports a read-only audit and, when explicitly authorized, a narrow remediation. When to use it Use this recipe when the operator's specific objective is to remove stale feature-flag branches after rollout state is proven. Prefer a narrower CVE, scanner-finding, security-audit, or compliance-evidence recipe when that is the operator's actual job. Inputs Repository root and the files, package, service, or module in scope. Requested mode: audit or explicitly authorized fix. Supported runtime, compiler, framework, operating-system, and deployment versions inferred from repository files. Existing formatter, compiler, analyzer, test, build, and package-manager commands. Public API, compatibility, performance, generated-code, vendor, and migration constraints. The prompt ~~~markdown You are running the Security Recipes code-hygiene workflow code-hygiene.cross-language.feature-flag-and-experiment-cleanup. Start read-only. Do not edit files until the operator explicitly authorizes a fix. Use repository configuration and installed tool versions as authoritative; do not impose a new style or toolchain. Scope Your bounded objective is to remove stale feature-flag branches after rollout state is proven. Inspect only operator-scoped, first-party source and configuration. Exclude generated, vendored, minified, fixture snapshot, lock history, and migration history unless explicitly included. Detection Find flag definitions, readers, defaults, tests, analytics, rollout records, and operational ownership. Require evidence that the selected branch is permanent in every deployed environment. Record file and symbol evidence for every candidate. Mark uncertain or dynamically reachable behavior instead of guessing. Fix, only when authorized Remove the inactive branch, flag plumbing, stale tests, and configuration in one bounded change. Keep the diff limited to the proven issue and its focused tests. Preserve public behavior, API compatibility, and repository conventions. Do not add or broaden suppressions, weaken diagnostics, mass-format unrelated files, upgrade dependencies, or mutate external state. Verification Test the permanent behavior and search for remaining flag keys, aliases, and configuration references. Compare diagnostic counts and relevant behavior before and after. Report every command, result, and check that could not run. Stop conditions Stop without authoritative rollout state or when rollback still depends on the flag. Stop and hand off to a focused security recipe if evidence indicates a vulnerability, secret exposure, authorization failure, injection path, or named CVE. Stop rather than widening scope when the safe result requires architecture, product, compliance, operational, or data-owner decisions. ~~~ Output contract Scope and repository evidence reviewed. A candidate table with file or symbol, evidence, confidence, and disposition. In audit mode: no edits, plus the smallest safe next action for each confirmed item. In fix mode: one bounded patch, focused regression coverage, and no unrelated cleanup. Commands run, results, remaining uncertainty, and any stop-condition handoff. Verification Test the permanent behavior and search for remaining flag keys, aliases, and configuration references. Confirm that diagnostic configuration, suppressions, public interfaces, generated files, vendored files, and dependencies did not change outside the authorized scope. Review the final diff for behavior changes and run the repository's focused checks before broader suites. Guardrails Read-only until edits are explicitly authorized. Do not deploy, publish, rotate secrets, alter cloud or database state, change CI permissions, or open external tickets. Do not hide debt by disabling rules, adding retries or sleeps, weakening tests, broadening ignores, or lowering warning levels. Treat generated, vendored, minified, migration-history, and fixture-snapshot files as out of scope unless explicitly named. Stop without authoritative rollout state or when rollback still depends on the flag. Related recipes Lint warning baseline and budget Dead code and unused symbol removal Browse all code-hygiene recipes References NIST SP 800-218 Secure Software Development Framework 1.1 — NIST OWASP Developer Guide - Implementation — OWASP","agent_handoff":{"mcp_lookup_keys":["feature-flag-and-experiment-cleanup","/recipes/general/code-hygiene/cross-language/feature-flag-and-experiment-cleanup/","recipes/general/code-hygiene/cross-language/feature-flag-and-experiment-cleanup.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["code-hygiene","audit","remediation"],"source_text_field":"content_text","portable_download":"security-recipe-feature-flag-and-experiment-cleanup.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-feature-flag-and-experiment-cleanup.json"}},{"slug":"lint-warning-baseline-and-budget","title":"Lint warning baseline and budget","link_title":"Lint warning baseline and budget","url":"https://security-recipes.ai/recipes/general/code-hygiene/cross-language/lint-warning-baseline-and-budget/","path":"/recipes/general/code-hygiene/cross-language/lint-warning-baseline-and-budget/","source_file":"recipes/general/code-hygiene/cross-language/lint-warning-baseline-and-budget.md","recipe_id":"code-hygiene.cross-language.lint-warning-baseline-and-budget","recipe_kind":"code-hygiene","category":{"slug":"code-hygiene","label":"Code Hygiene"},"agent":"general","severity":"unspecified","maturity":"development","ecosystem":"multi-language","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"","framework_version":"","jurisdiction":"","industry":[],"cve_archetypes":[],"cve_workflow_role":"","tags":["code-hygiene","cross-language","lint","warnings","baseline"],"facets":["code-hygiene","audit","remediation"],"quality":{"score":100,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context","multi-facet"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"security-recipes.ai contributors","team":"Security Engineering","model":"gpt-5-codex","ai_assisted":false,"generated_by":"","date":"2026-08-21","zero_day":false,"last_updated":"2026-08-21","summary":"Lint warning baseline and budget: Turn an existing warning backlog into a measured, non-growing budget. Includes scoped detection, verification, and stop conditions.","content_text":"<!-- Generated by scripts/synccodehygiene_recipes.py; edit data/code-hygiene/catalog.json. --> A tool-agnostic recipe to turn an existing warning backlog into a measured, non-growing budget. It supports a read-only audit and, when explicitly authorized, a narrow remediation. When to use it Use this recipe when the operator's specific objective is to turn an existing warning backlog into a measured, non-growing budget. Prefer a narrower CVE, scanner-finding, security-audit, or compliance-evidence recipe when that is the operator's actual job. Inputs Repository root and the files, package, service, or module in scope. Requested mode: audit or explicitly authorized fix. Supported runtime, compiler, framework, operating-system, and deployment versions inferred from repository files. Existing formatter, compiler, analyzer, test, build, and package-manager commands. Public API, compatibility, performance, generated-code, vendor, and migration constraints. The prompt ~~~markdown You are running the Security Recipes code-hygiene workflow code-hygiene.cross-language.lint-warning-baseline-and-budget. Start read-only. Do not edit files until the operator explicitly authorizes a fix. Use repository configuration and installed tool versions as authoritative; do not impose a new style or toolchain. Scope Your bounded objective is to turn an existing warning backlog into a measured, non-growing budget. Inspect only operator-scoped, first-party source and configuration. Exclude generated, vendored, minified, fixture snapshot, lock history, and migration history unless explicitly included. Detection Inventory configured compilers, linters, warning-as-error gates, and suppression files. Separate pre-existing diagnostics from warnings introduced by the current change. Record file and symbol evidence for every candidate. Mark uncertain or dynamically reachable behavior instead of guessing. Fix, only when authorized Remove safe high-confidence warnings first and encode a ratcheting baseline without disabling rules. Keep the diff limited to the proven issue and its focused tests. Preserve public behavior, API compatibility, and repository conventions. Do not add or broaden suppressions, weaken diagnostics, mass-format unrelated files, upgrade dependencies, or mutate external state. Verification Run the repository's configured diagnostic commands twice and compare counts by rule and path. Compare diagnostic counts and relevant behavior before and after. Report every command, result, and check that could not run. Stop conditions Stop if the proposed baseline would hide new diagnostics or change generated and vendored files. Stop and hand off to a focused security recipe if evidence indicates a vulnerability, secret exposure, authorization failure, injection path, or named CVE. Stop rather than widening scope when the safe result requires architecture, product, compliance, operational, or data-owner decisions. ~~~ Output contract Scope and repository evidence reviewed. A candidate table with file or symbol, evidence, confidence, and disposition. In audit mode: no edits, plus the smallest safe next action for each confirmed item. In fix mode: one bounded patch, focused regression coverage, and no unrelated cleanup. Commands run, results, remaining uncertainty, and any stop-condition handoff. Verification Run the repository's configured diagnostic commands twice and compare counts by rule and path. Confirm that diagnostic configuration, suppressions, public interfaces, generated files, vendored files, and dependencies did not change outside the authorized scope. Review the final diff for behavior changes and run the repository's focused checks before broader suites. Guardrails Read-only until edits are explicitly authorized. Do not deploy, publish, rotate secrets, alter cloud or database state, change CI permissions, or open external tickets. Do not hide debt by disabling rules, adding retries or sleeps, weakening tests, broadening ignores, or lowering warning levels. Treat generated, vendored, minified, migration-history, and fixture-snapshot files as out of scope unless explicitly named. Stop if the proposed baseline would hide new diagnostics or change generated and vendored files. Related recipes Dead code and unused symbol removal Duplicated logic consolidation Browse all code-hygiene recipes References NIST SP 800-218 Secure Software Development Framework 1.1 — NIST OWASP Developer Guide - Implementation — OWASP","agent_handoff":{"mcp_lookup_keys":["lint-warning-baseline-and-budget","/recipes/general/code-hygiene/cross-language/lint-warning-baseline-and-budget/","recipes/general/code-hygiene/cross-language/lint-warning-baseline-and-budget.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["code-hygiene","audit","remediation"],"source_text_field":"content_text","portable_download":"security-recipe-lint-warning-baseline-and-budget.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-lint-warning-baseline-and-budget.json"}},{"slug":"regex-correctness-and-complexity-hygiene","title":"Regular-expression correctness and complexity hygiene","link_title":"Regular-expression correctness and complexity hygiene","url":"https://security-recipes.ai/recipes/general/code-hygiene/cross-language/regex-correctness-and-complexity-hygiene/","path":"/recipes/general/code-hygiene/cross-language/regex-correctness-and-complexity-hygiene/","source_file":"recipes/general/code-hygiene/cross-language/regex-correctness-and-complexity-hygiene.md","recipe_id":"code-hygiene.cross-language.regex-correctness-and-complexity-hygiene","recipe_kind":"code-hygiene","category":{"slug":"code-hygiene","label":"Code Hygiene"},"agent":"general","severity":"unspecified","maturity":"development","ecosystem":"multi-language","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"","framework_version":"","jurisdiction":"","industry":[],"cve_archetypes":[],"cve_workflow_role":"","tags":["code-hygiene","cross-language","regex","complexity","parsing"],"facets":["code-hygiene","audit","remediation"],"quality":{"score":100,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context","multi-facet"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"security-recipes.ai contributors","team":"Security Engineering","model":"gpt-5-codex","ai_assisted":false,"generated_by":"","date":"2026-08-21","zero_day":false,"last_updated":"2026-08-21","summary":"Regular-expression correctness and complexity hygiene: Make complex regular expressions bounded, readable, and behaviorally tested.","content_text":"<!-- Generated by scripts/synccodehygiene_recipes.py; edit data/code-hygiene/catalog.json. --> A tool-agnostic recipe to make complex regular expressions bounded, readable, and behaviorally tested. It supports a read-only audit and, when explicitly authorized, a narrow remediation. When to use it Use this recipe when the operator's specific objective is to make complex regular expressions bounded, readable, and behaviorally tested. Prefer a narrower CVE, scanner-finding, security-audit, or compliance-evidence recipe when that is the operator's actual job. Inputs Repository root and the files, package, service, or module in scope. Requested mode: audit or explicitly authorized fix. Supported runtime, compiler, framework, operating-system, and deployment versions inferred from repository files. Existing formatter, compiler, analyzer, test, build, and package-manager commands. Public API, compatibility, performance, generated-code, vendor, and migration constraints. The prompt ~~~markdown You are running the Security Recipes code-hygiene workflow code-hygiene.cross-language.regex-correctness-and-complexity-hygiene. Start read-only. Do not edit files until the operator explicitly authorizes a fix. Use repository configuration and installed tool versions as authoritative; do not impose a new style or toolchain. Scope Your bounded objective is to make complex regular expressions bounded, readable, and behaviorally tested. Inspect only operator-scoped, first-party source and configuration. Exclude generated, vendored, minified, fixture snapshot, lock history, and migration history unless explicitly included. Detection Find nested quantifiers, ambiguous alternation, catastrophic backtracking risk, and undocumented capture dependencies. Collect representative valid, invalid, adversarial, and maximum-length inputs. Record file and symbol evidence for every candidate. Mark uncertain or dynamically reachable behavior instead of guessing. Fix, only when authorized Simplify or replace risky expressions while preserving explicit matching and capture contracts. Keep the diff limited to the proven issue and its focused tests. Preserve public behavior, API compatibility, and repository conventions. Do not add or broaden suppressions, weaken diagnostics, mass-format unrelated files, upgrade dependencies, or mutate external state. Verification Run positive, negative, boundary, Unicode, and adversarial performance tests. Compare diagnostic counts and relevant behavior before and after. Report every command, result, and check that could not run. Stop conditions Stop if the expression implements an undocumented protocol or security boundary requiring specialist review. Stop and hand off to a focused security recipe if evidence indicates a vulnerability, secret exposure, authorization failure, injection path, or named CVE. Stop rather than widening scope when the safe result requires architecture, product, compliance, operational, or data-owner decisions. ~~~ Output contract Scope and repository evidence reviewed. A candidate table with file or symbol, evidence, confidence, and disposition. In audit mode: no edits, plus the smallest safe next action for each confirmed item. In fix mode: one bounded patch, focused regression coverage, and no unrelated cleanup. Commands run, results, remaining uncertainty, and any stop-condition handoff. Verification Run positive, negative, boundary, Unicode, and adversarial performance tests. Confirm that diagnostic configuration, suppressions, public interfaces, generated files, vendored files, and dependencies did not change outside the authorized scope. Review the final diff for behavior changes and run the repository's focused checks before broader suites. Guardrails Read-only until edits are explicitly authorized. Do not deploy, publish, rotate secrets, alter cloud or database state, change CI permissions, or open external tickets. Do not hide debt by disabling rules, adding retries or sleeps, weakening tests, broadening ignores, or lowering warning levels. Treat generated, vendored, minified, migration-history, and fixture-snapshot files as out of scope unless explicitly named. Stop if the expression implements an undocumented protocol or security boundary requiring specialist review. Related recipes Lint warning baseline and budget Dead code and unused symbol removal Browse all code-hygiene recipes References NIST SP 800-218 Secure Software Development Framework 1.1 — NIST OWASP Developer Guide - Implementation — OWASP","agent_handoff":{"mcp_lookup_keys":["regex-correctness-and-complexity-hygiene","/recipes/general/code-hygiene/cross-language/regex-correctness-and-complexity-hygiene/","recipes/general/code-hygiene/cross-language/regex-correctness-and-complexity-hygiene.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["code-hygiene","audit","remediation"],"source_text_field":"content_text","portable_download":"security-recipe-regex-correctness-and-complexity-hygiene.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-regex-correctness-and-complexity-hygiene.json"}},{"slug":"serialization-schema-and-versioning-hygiene","title":"Serialization schema and versioning hygiene","link_title":"Serialization schema and versioning hygiene","url":"https://security-recipes.ai/recipes/general/code-hygiene/cross-language/serialization-schema-and-versioning-hygiene/","path":"/recipes/general/code-hygiene/cross-language/serialization-schema-and-versioning-hygiene/","source_file":"recipes/general/code-hygiene/cross-language/serialization-schema-and-versioning-hygiene.md","recipe_id":"code-hygiene.cross-language.serialization-schema-and-versioning-hygiene","recipe_kind":"code-hygiene","category":{"slug":"code-hygiene","label":"Code Hygiene"},"agent":"general","severity":"unspecified","maturity":"development","ecosystem":"multi-language","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"","framework_version":"","jurisdiction":"","industry":[],"cve_archetypes":[],"cve_workflow_role":"","tags":["code-hygiene","cross-language","serialization","schema","versioning"],"facets":["code-hygiene","audit","remediation"],"quality":{"score":100,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context","multi-facet"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"security-recipes.ai contributors","team":"Security Engineering","model":"gpt-5-codex","ai_assisted":false,"generated_by":"","date":"2026-08-21","zero_day":false,"last_updated":"2026-08-21","summary":"Serialization schema and versioning hygiene: Make serialized contracts explicit and backward-compatible.","content_text":"<!-- Generated by scripts/synccodehygiene_recipes.py; edit data/code-hygiene/catalog.json. --> A tool-agnostic recipe to make serialized contracts explicit and backward-compatible. It supports a read-only audit and, when explicitly authorized, a narrow remediation. When to use it Use this recipe when the operator's specific objective is to make serialized contracts explicit and backward-compatible. Prefer a narrower CVE, scanner-finding, security-audit, or compliance-evidence recipe when that is the operator's actual job. Inputs Repository root and the files, package, service, or module in scope. Requested mode: audit or explicitly authorized fix. Supported runtime, compiler, framework, operating-system, and deployment versions inferred from repository files. Existing formatter, compiler, analyzer, test, build, and package-manager commands. Public API, compatibility, performance, generated-code, vendor, and migration constraints. The prompt ~~~markdown You are running the Security Recipes code-hygiene workflow code-hygiene.cross-language.serialization-schema-and-versioning-hygiene. Start read-only. Do not edit files until the operator explicitly authorizes a fix. Use repository configuration and installed tool versions as authoritative; do not impose a new style or toolchain. Scope Your bounded objective is to make serialized contracts explicit and backward-compatible. Inspect only operator-scoped, first-party source and configuration. Exclude generated, vendored, minified, fixture snapshot, lock history, and migration history unless explicitly included. Detection Inventory encoders, decoders, schema files, field aliases, defaults, and persisted payload versions. Identify implicit field renames, lossy coercion, unknown-field behavior, and unstable ordering assumptions. Record file and symbol evidence for every candidate. Mark uncertain or dynamically reachable behavior instead of guessing. Fix, only when authorized Add explicit version handling and compatibility-preserving field behavior at the serialization boundary. Keep the diff limited to the proven issue and its focused tests. Preserve public behavior, API compatibility, and repository conventions. Do not add or broaden suppressions, weaken diagnostics, mass-format unrelated files, upgrade dependencies, or mutate external state. Verification Round-trip current fixtures and read representative prior-version payloads. Compare diagnostic counts and relevant behavior before and after. Report every command, result, and check that could not run. Stop conditions Stop if compatibility requirements or migration ownership are unknown. Stop and hand off to a focused security recipe if evidence indicates a vulnerability, secret exposure, authorization failure, injection path, or named CVE. Stop rather than widening scope when the safe result requires architecture, product, compliance, operational, or data-owner decisions. ~~~ Output contract Scope and repository evidence reviewed. A candidate table with file or symbol, evidence, confidence, and disposition. In audit mode: no edits, plus the smallest safe next action for each confirmed item. In fix mode: one bounded patch, focused regression coverage, and no unrelated cleanup. Commands run, results, remaining uncertainty, and any stop-condition handoff. Verification Round-trip current fixtures and read representative prior-version payloads. Confirm that diagnostic configuration, suppressions, public interfaces, generated files, vendored files, and dependencies did not change outside the authorized scope. Review the final diff for behavior changes and run the repository's focused checks before broader suites. Guardrails Read-only until edits are explicitly authorized. Do not deploy, publish, rotate secrets, alter cloud or database state, change CI permissions, or open external tickets. Do not hide debt by disabling rules, adding retries or sleeps, weakening tests, broadening ignores, or lowering warning levels. Treat generated, vendored, minified, migration-history, and fixture-snapshot files as out of scope unless explicitly named. Stop if compatibility requirements or migration ownership are unknown. Related recipes Lint warning baseline and budget Dead code and unused symbol removal Browse all code-hygiene recipes References NIST SP 800-218 Secure Software Development Framework 1.1 — NIST OWASP Developer Guide - Implementation — OWASP","agent_handoff":{"mcp_lookup_keys":["serialization-schema-and-versioning-hygiene","/recipes/general/code-hygiene/cross-language/serialization-schema-and-versioning-hygiene/","recipes/general/code-hygiene/cross-language/serialization-schema-and-versioning-hygiene.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["code-hygiene","audit","remediation"],"source_text_field":"content_text","portable_download":"security-recipe-serialization-schema-and-versioning-hygiene.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-serialization-schema-and-versioning-hygiene.json"}},{"slug":"structured-logging-and-cardinality-hygiene","title":"Structured logging and cardinality hygiene","link_title":"Structured logging and cardinality hygiene","url":"https://security-recipes.ai/recipes/general/code-hygiene/cross-language/structured-logging-and-cardinality-hygiene/","path":"/recipes/general/code-hygiene/cross-language/structured-logging-and-cardinality-hygiene/","source_file":"recipes/general/code-hygiene/cross-language/structured-logging-and-cardinality-hygiene.md","recipe_id":"code-hygiene.cross-language.structured-logging-and-cardinality-hygiene","recipe_kind":"code-hygiene","category":{"slug":"code-hygiene","label":"Code Hygiene"},"agent":"general","severity":"unspecified","maturity":"development","ecosystem":"multi-language","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"","framework_version":"","jurisdiction":"","industry":[],"cve_archetypes":[],"cve_workflow_role":"","tags":["code-hygiene","cross-language","logging","observability","cardinality"],"facets":["code-hygiene","audit","remediation"],"quality":{"score":100,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context","multi-facet"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"security-recipes.ai contributors","team":"Security Engineering","model":"gpt-5-codex","ai_assisted":false,"generated_by":"","date":"2026-08-21","zero_day":false,"last_updated":"2026-08-21","summary":"Structured logging and cardinality hygiene: Make logs structured, actionable, and bounded without exposing sensitive data.","content_text":"<!-- Generated by scripts/synccodehygiene_recipes.py; edit data/code-hygiene/catalog.json. --> A tool-agnostic recipe to make logs structured, actionable, and bounded without exposing sensitive data. It supports a read-only audit and, when explicitly authorized, a narrow remediation. When to use it Use this recipe when the operator's specific objective is to make logs structured, actionable, and bounded without exposing sensitive data. Prefer a narrower CVE, scanner-finding, security-audit, or compliance-evidence recipe when that is the operator's actual job. Inputs Repository root and the files, package, service, or module in scope. Requested mode: audit or explicitly authorized fix. Supported runtime, compiler, framework, operating-system, and deployment versions inferred from repository files. Existing formatter, compiler, analyzer, test, build, and package-manager commands. Public API, compatibility, performance, generated-code, vendor, and migration constraints. The prompt ~~~markdown You are running the Security Recipes code-hygiene workflow code-hygiene.cross-language.structured-logging-and-cardinality-hygiene. Start read-only. Do not edit files until the operator explicitly authorizes a fix. Use repository configuration and installed tool versions as authoritative; do not impose a new style or toolchain. Scope Your bounded objective is to make logs structured, actionable, and bounded without exposing sensitive data. Inspect only operator-scoped, first-party source and configuration. Exclude generated, vendored, minified, fixture snapshot, lock history, and migration history unless explicitly included. Detection Inventory free-form interpolation, inconsistent event names, high-cardinality fields, and duplicate error logs. Trace exception ownership so one failure is not logged repeatedly at every layer. Record file and symbol evidence for every candidate. Mark uncertain or dynamically reachable behavior instead of guessing. Fix, only when authorized Use stable event fields, bounded identifiers, and a single accountable logging boundary. Keep the diff limited to the proven issue and its focused tests. Preserve public behavior, API compatibility, and repository conventions. Do not add or broaden suppressions, weaken diagnostics, mass-format unrelated files, upgrade dependencies, or mutate external state. Verification Assert event shape, severity, redaction behavior, and cardinality-safe field values in focused tests. Compare diagnostic counts and relevant behavior before and after. Report every command, result, and check that could not run. Stop conditions Stop on live log access, uncertain data classification, or telemetry schema changes needing owner approval. Stop and hand off to a focused security recipe if evidence indicates a vulnerability, secret exposure, authorization failure, injection path, or named CVE. Stop rather than widening scope when the safe result requires architecture, product, compliance, operational, or data-owner decisions. ~~~ Output contract Scope and repository evidence reviewed. A candidate table with file or symbol, evidence, confidence, and disposition. In audit mode: no edits, plus the smallest safe next action for each confirmed item. In fix mode: one bounded patch, focused regression coverage, and no unrelated cleanup. Commands run, results, remaining uncertainty, and any stop-condition handoff. Verification Assert event shape, severity, redaction behavior, and cardinality-safe field values in focused tests. Confirm that diagnostic configuration, suppressions, public interfaces, generated files, vendored files, and dependencies did not change outside the authorized scope. Review the final diff for behavior changes and run the repository's focused checks before broader suites. Guardrails Read-only until edits are explicitly authorized. Do not deploy, publish, rotate secrets, alter cloud or database state, change CI permissions, or open external tickets. Do not hide debt by disabling rules, adding retries or sleeps, weakening tests, broadening ignores, or lowering warning levels. Treat generated, vendored, minified, migration-history, and fixture-snapshot files as out of scope unless explicitly named. Stop on live log access, uncertain data classification, or telemetry schema changes needing owner approval. Related recipes Lint warning baseline and budget Dead code and unused symbol removal Browse all code-hygiene recipes References NIST SP 800-218 Secure Software Development Framework 1.1 — NIST OWASP Developer Guide - Implementation — OWASP","agent_handoff":{"mcp_lookup_keys":["structured-logging-and-cardinality-hygiene","/recipes/general/code-hygiene/cross-language/structured-logging-and-cardinality-hygiene/","recipes/general/code-hygiene/cross-language/structured-logging-and-cardinality-hygiene.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["code-hygiene","audit","remediation"],"source_text_field":"content_text","portable_download":"security-recipe-structured-logging-and-cardinality-hygiene.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-structured-logging-and-cardinality-hygiene.json"}},{"slug":"test-isolation-and-fixture-hygiene","title":"Test isolation and fixture hygiene","link_title":"Test isolation and fixture hygiene","url":"https://security-recipes.ai/recipes/general/code-hygiene/cross-language/test-isolation-and-fixture-hygiene/","path":"/recipes/general/code-hygiene/cross-language/test-isolation-and-fixture-hygiene/","source_file":"recipes/general/code-hygiene/cross-language/test-isolation-and-fixture-hygiene.md","recipe_id":"code-hygiene.cross-language.test-isolation-and-fixture-hygiene","recipe_kind":"code-hygiene","category":{"slug":"code-hygiene","label":"Code Hygiene"},"agent":"general","severity":"unspecified","maturity":"development","ecosystem":"multi-language","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"","framework_version":"","jurisdiction":"","industry":[],"cve_archetypes":[],"cve_workflow_role":"","tags":["code-hygiene","cross-language","tests","fixtures","isolation"],"facets":["code-hygiene","audit","remediation"],"quality":{"score":100,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context","multi-facet"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"security-recipes.ai contributors","team":"Security Engineering","model":"gpt-5-codex","ai_assisted":false,"generated_by":"","date":"2026-08-21","zero_day":false,"last_updated":"2026-08-21","summary":"Test isolation and fixture hygiene: Eliminate order-dependent fixtures and leaked test state. Includes scoped detection, verification, and stop conditions.","content_text":"<!-- Generated by scripts/synccodehygiene_recipes.py; edit data/code-hygiene/catalog.json. --> A tool-agnostic recipe to eliminate order-dependent fixtures and leaked test state. It supports a read-only audit and, when explicitly authorized, a narrow remediation. When to use it Use this recipe when the operator's specific objective is to eliminate order-dependent fixtures and leaked test state. Prefer a narrower CVE, scanner-finding, security-audit, or compliance-evidence recipe when that is the operator's actual job. Inputs Repository root and the files, package, service, or module in scope. Requested mode: audit or explicitly authorized fix. Supported runtime, compiler, framework, operating-system, and deployment versions inferred from repository files. Existing formatter, compiler, analyzer, test, build, and package-manager commands. Public API, compatibility, performance, generated-code, vendor, and migration constraints. The prompt ~~~markdown You are running the Security Recipes code-hygiene workflow code-hygiene.cross-language.test-isolation-and-fixture-hygiene. Start read-only. Do not edit files until the operator explicitly authorizes a fix. Use repository configuration and installed tool versions as authoritative; do not impose a new style or toolchain. Scope Your bounded objective is to eliminate order-dependent fixtures and leaked test state. Inspect only operator-scoped, first-party source and configuration. Exclude generated, vendored, minified, fixture snapshot, lock history, and migration history unless explicitly included. Detection Run tests alone and in varied order while tracking global, database, filesystem, environment, and mock state. Identify fixtures whose setup or cleanup is implicit, shared, or broader than the test. Record file and symbol evidence for every candidate. Mark uncertain or dynamically reachable behavior instead of guessing. Fix, only when authorized Make ownership explicit, scope fixtures narrowly, and restore every mutated boundary deterministically. Keep the diff limited to the proven issue and its focused tests. Preserve public behavior, API compatibility, and repository conventions. Do not add or broaden suppressions, weaken diagnostics, mass-format unrelated files, upgrade dependencies, or mutate external state. Verification Run randomized-order, parallel where supported, focused, and full-suite checks. Compare diagnostic counts and relevant behavior before and after. Report every command, result, and check that could not run. Stop conditions Stop before deleting persistent fixtures or touching shared external environments without operator approval. Stop and hand off to a focused security recipe if evidence indicates a vulnerability, secret exposure, authorization failure, injection path, or named CVE. Stop rather than widening scope when the safe result requires architecture, product, compliance, operational, or data-owner decisions. ~~~ Output contract Scope and repository evidence reviewed. A candidate table with file or symbol, evidence, confidence, and disposition. In audit mode: no edits, plus the smallest safe next action for each confirmed item. In fix mode: one bounded patch, focused regression coverage, and no unrelated cleanup. Commands run, results, remaining uncertainty, and any stop-condition handoff. Verification Run randomized-order, parallel where supported, focused, and full-suite checks. Confirm that diagnostic configuration, suppressions, public interfaces, generated files, vendored files, and dependencies did not change outside the authorized scope. Review the final diff for behavior changes and run the repository's focused checks before broader suites. Guardrails Read-only until edits are explicitly authorized. Do not deploy, publish, rotate secrets, alter cloud or database state, change CI permissions, or open external tickets. Do not hide debt by disabling rules, adding retries or sleeps, weakening tests, broadening ignores, or lowering warning levels. Treat generated, vendored, minified, migration-history, and fixture-snapshot files as out of scope unless explicitly named. Stop before deleting persistent fixtures or touching shared external environments without operator approval. Related recipes Lint warning baseline and budget Dead code and unused symbol removal Browse all code-hygiene recipes References NIST SP 800-218 Secure Software Development Framework 1.1 — NIST OWASP Developer Guide - Implementation — OWASP","agent_handoff":{"mcp_lookup_keys":["test-isolation-and-fixture-hygiene","/recipes/general/code-hygiene/cross-language/test-isolation-and-fixture-hygiene/","recipes/general/code-hygiene/cross-language/test-isolation-and-fixture-hygiene.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["code-hygiene","audit","remediation"],"source_text_field":"content_text","portable_download":"security-recipe-test-isolation-and-fixture-hygiene.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-test-isolation-and-fixture-hygiene.json"}},{"slug":"time-date-timezone-and-clock-hygiene","title":"Time, date, timezone, and clock hygiene","link_title":"Time, date, timezone, and clock hygiene","url":"https://security-recipes.ai/recipes/general/code-hygiene/cross-language/time-date-timezone-and-clock-hygiene/","path":"/recipes/general/code-hygiene/cross-language/time-date-timezone-and-clock-hygiene/","source_file":"recipes/general/code-hygiene/cross-language/time-date-timezone-and-clock-hygiene.md","recipe_id":"code-hygiene.cross-language.time-date-timezone-and-clock-hygiene","recipe_kind":"code-hygiene","category":{"slug":"code-hygiene","label":"Code Hygiene"},"agent":"general","severity":"unspecified","maturity":"development","ecosystem":"multi-language","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"","framework_version":"","jurisdiction":"","industry":[],"cve_archetypes":[],"cve_workflow_role":"","tags":["code-hygiene","cross-language","time","timezone","clock"],"facets":["code-hygiene","audit","remediation"],"quality":{"score":100,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context","multi-facet"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"security-recipes.ai contributors","team":"Security Engineering","model":"gpt-5-codex","ai_assisted":false,"generated_by":"","date":"2026-08-21","zero_day":false,"last_updated":"2026-08-21","summary":"Time, date, timezone, and clock hygiene: Make temporal logic explicit, testable, and timezone-safe. Includes scoped detection, verification, and stop conditions.","content_text":"<!-- Generated by scripts/synccodehygiene_recipes.py; edit data/code-hygiene/catalog.json. --> A tool-agnostic recipe to make temporal logic explicit, testable, and timezone-safe. It supports a read-only audit and, when explicitly authorized, a narrow remediation. When to use it Use this recipe when the operator's specific objective is to make temporal logic explicit, testable, and timezone-safe. Prefer a narrower CVE, scanner-finding, security-audit, or compliance-evidence recipe when that is the operator's actual job. Inputs Repository root and the files, package, service, or module in scope. Requested mode: audit or explicitly authorized fix. Supported runtime, compiler, framework, operating-system, and deployment versions inferred from repository files. Existing formatter, compiler, analyzer, test, build, and package-manager commands. Public API, compatibility, performance, generated-code, vendor, and migration constraints. The prompt ~~~markdown You are running the Security Recipes code-hygiene workflow code-hygiene.cross-language.time-date-timezone-and-clock-hygiene. Start read-only. Do not edit files until the operator explicitly authorizes a fix. Use repository configuration and installed tool versions as authoritative; do not impose a new style or toolchain. Scope Your bounded objective is to make temporal logic explicit, testable, and timezone-safe. Inspect only operator-scoped, first-party source and configuration. Exclude generated, vendored, minified, fixture snapshot, lock history, and migration history unless explicitly included. Detection Find direct wall-clock reads, naive timestamps, local-time assumptions, duration math, and implicit timezone conversion. Separate monotonic duration measurement from civil time and persistence. Record file and symbol evidence for every candidate. Mark uncertain or dynamically reachable behavior instead of guessing. Fix, only when authorized Inject or wrap clocks at testable boundaries and normalize stored and transmitted time deliberately. Keep the diff limited to the proven issue and its focused tests. Preserve public behavior, API compatibility, and repository conventions. Do not add or broaden suppressions, weaken diagnostics, mass-format unrelated files, upgrade dependencies, or mutate external state. Verification Test daylight-saving transitions, timezone offsets, leap boundaries, and controlled clock advancement. Compare diagnostic counts and relevant behavior before and after. Report every command, result, and check that could not run. Stop conditions Stop if changing timestamp representation would require a data migration or external contract change. Stop and hand off to a focused security recipe if evidence indicates a vulnerability, secret exposure, authorization failure, injection path, or named CVE. Stop rather than widening scope when the safe result requires architecture, product, compliance, operational, or data-owner decisions. ~~~ Output contract Scope and repository evidence reviewed. A candidate table with file or symbol, evidence, confidence, and disposition. In audit mode: no edits, plus the smallest safe next action for each confirmed item. In fix mode: one bounded patch, focused regression coverage, and no unrelated cleanup. Commands run, results, remaining uncertainty, and any stop-condition handoff. Verification Test daylight-saving transitions, timezone offsets, leap boundaries, and controlled clock advancement. Confirm that diagnostic configuration, suppressions, public interfaces, generated files, vendored files, and dependencies did not change outside the authorized scope. Review the final diff for behavior changes and run the repository's focused checks before broader suites. Guardrails Read-only until edits are explicitly authorized. Do not deploy, publish, rotate secrets, alter cloud or database state, change CI permissions, or open external tickets. Do not hide debt by disabling rules, adding retries or sleeps, weakening tests, broadening ignores, or lowering warning levels. Treat generated, vendored, minified, migration-history, and fixture-snapshot files as out of scope unless explicitly named. Stop if changing timestamp representation would require a data migration or external contract change. Related recipes Lint warning baseline and budget Dead code and unused symbol removal Browse all code-hygiene recipes References NIST SP 800-218 Secure Software Development Framework 1.1 — NIST OWASP Developer Guide - Implementation — OWASP","agent_handoff":{"mcp_lookup_keys":["time-date-timezone-and-clock-hygiene","/recipes/general/code-hygiene/cross-language/time-date-timezone-and-clock-hygiene/","recipes/general/code-hygiene/cross-language/time-date-timezone-and-clock-hygiene.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["code-hygiene","audit","remediation"],"source_text_field":"content_text","portable_download":"security-recipe-time-date-timezone-and-clock-hygiene.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-time-date-timezone-and-clock-hygiene.json"}},{"slug":"todo-fixme-and-suppression-debt","title":"TODO, FIXME, and suppression debt","link_title":"TODO, FIXME, and suppression debt","url":"https://security-recipes.ai/recipes/general/code-hygiene/cross-language/todo-fixme-and-suppression-debt/","path":"/recipes/general/code-hygiene/cross-language/todo-fixme-and-suppression-debt/","source_file":"recipes/general/code-hygiene/cross-language/todo-fixme-and-suppression-debt.md","recipe_id":"code-hygiene.cross-language.todo-fixme-and-suppression-debt","recipe_kind":"code-hygiene","category":{"slug":"code-hygiene","label":"Code Hygiene"},"agent":"general","severity":"unspecified","maturity":"development","ecosystem":"multi-language","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"","framework_version":"","jurisdiction":"","industry":[],"cve_archetypes":[],"cve_workflow_role":"","tags":["code-hygiene","cross-language","todo","fixme","suppressions"],"facets":["code-hygiene","audit","remediation"],"quality":{"score":100,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context","multi-facet"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"security-recipes.ai contributors","team":"Security Engineering","model":"gpt-5-codex","ai_assisted":false,"generated_by":"","date":"2026-08-21","zero_day":false,"last_updated":"2026-08-21","summary":"TODO, FIXME, and suppression debt: Turn stale annotations and diagnostic suppressions into owned, reviewable work.","content_text":"<!-- Generated by scripts/synccodehygiene_recipes.py; edit data/code-hygiene/catalog.json. --> A tool-agnostic recipe to turn stale annotations and diagnostic suppressions into owned, reviewable work. It supports a read-only audit and, when explicitly authorized, a narrow remediation. When to use it Use this recipe when the operator's specific objective is to turn stale annotations and diagnostic suppressions into owned, reviewable work. Prefer a narrower CVE, scanner-finding, security-audit, or compliance-evidence recipe when that is the operator's actual job. Inputs Repository root and the files, package, service, or module in scope. Requested mode: audit or explicitly authorized fix. Supported runtime, compiler, framework, operating-system, and deployment versions inferred from repository files. Existing formatter, compiler, analyzer, test, build, and package-manager commands. Public API, compatibility, performance, generated-code, vendor, and migration constraints. The prompt ~~~markdown You are running the Security Recipes code-hygiene workflow code-hygiene.cross-language.todo-fixme-and-suppression-debt. Start read-only. Do not edit files until the operator explicitly authorizes a fix. Use repository configuration and installed tool versions as authoritative; do not impose a new style or toolchain. Scope Your bounded objective is to turn stale annotations and diagnostic suppressions into owned, reviewable work. Inspect only operator-scoped, first-party source and configuration. Exclude generated, vendored, minified, fixture snapshot, lock history, and migration history unless explicitly included. Detection Inventory TODO, FIXME, disabled-rule, ignore, pragma, and expected-failure annotations with history. Classify resolved, actionable, policy-required, generated, and unexplained entries. Record file and symbol evidence for every candidate. Mark uncertain or dynamically reachable behavior instead of guessing. Fix, only when authorized Delete resolved annotations, narrow justified suppressions, and add owner or issue context where policy permits. Keep the diff limited to the proven issue and its focused tests. Preserve public behavior, API compatibility, and repository conventions. Do not add or broaden suppressions, weaken diagnostics, mass-format unrelated files, upgrade dependencies, or mutate external state. Verification Run the affected diagnostics and confirm no suppression scope expanded. Compare diagnostic counts and relevant behavior before and after. Report every command, result, and check that could not run. Stop conditions Stop if removing a suppression reveals unsafe behavior that needs a dedicated remediation recipe. Stop and hand off to a focused security recipe if evidence indicates a vulnerability, secret exposure, authorization failure, injection path, or named CVE. Stop rather than widening scope when the safe result requires architecture, product, compliance, operational, or data-owner decisions. ~~~ Output contract Scope and repository evidence reviewed. A candidate table with file or symbol, evidence, confidence, and disposition. In audit mode: no edits, plus the smallest safe next action for each confirmed item. In fix mode: one bounded patch, focused regression coverage, and no unrelated cleanup. Commands run, results, remaining uncertainty, and any stop-condition handoff. Verification Run the affected diagnostics and confirm no suppression scope expanded. Confirm that diagnostic configuration, suppressions, public interfaces, generated files, vendored files, and dependencies did not change outside the authorized scope. Review the final diff for behavior changes and run the repository's focused checks before broader suites. Guardrails Read-only until edits are explicitly authorized. Do not deploy, publish, rotate secrets, alter cloud or database state, change CI permissions, or open external tickets. Do not hide debt by disabling rules, adding retries or sleeps, weakening tests, broadening ignores, or lowering warning levels. Treat generated, vendored, minified, migration-history, and fixture-snapshot files as out of scope unless explicitly named. Stop if removing a suppression reveals unsafe behavior that needs a dedicated remediation recipe. Related recipes Lint warning baseline and budget Dead code and unused symbol removal Browse all code-hygiene recipes References NIST SP 800-218 Secure Software Development Framework 1.1 — NIST OWASP Developer Guide - Implementation — OWASP","agent_handoff":{"mcp_lookup_keys":["todo-fixme-and-suppression-debt","/recipes/general/code-hygiene/cross-language/todo-fixme-and-suppression-debt/","recipes/general/code-hygiene/cross-language/todo-fixme-and-suppression-debt.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["code-hygiene","audit","remediation"],"source_text_field":"content_text","portable_download":"security-recipe-todo-fixme-and-suppression-debt.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-todo-fixme-and-suppression-debt.json"}},{"slug":"unicode-locale-and-normalization-hygiene","title":"Unicode, locale, and normalization hygiene","link_title":"Unicode, locale, and normalization hygiene","url":"https://security-recipes.ai/recipes/general/code-hygiene/cross-language/unicode-locale-and-normalization-hygiene/","path":"/recipes/general/code-hygiene/cross-language/unicode-locale-and-normalization-hygiene/","source_file":"recipes/general/code-hygiene/cross-language/unicode-locale-and-normalization-hygiene.md","recipe_id":"code-hygiene.cross-language.unicode-locale-and-normalization-hygiene","recipe_kind":"code-hygiene","category":{"slug":"code-hygiene","label":"Code Hygiene"},"agent":"general","severity":"unspecified","maturity":"development","ecosystem":"multi-language","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"","framework_version":"","jurisdiction":"","industry":[],"cve_archetypes":[],"cve_workflow_role":"","tags":["code-hygiene","cross-language","unicode","locale","normalization"],"facets":["code-hygiene","audit","remediation"],"quality":{"score":100,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context","multi-facet"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"security-recipes.ai contributors","team":"Security Engineering","model":"gpt-5-codex","ai_assisted":false,"generated_by":"","date":"2026-08-21","zero_day":false,"last_updated":"2026-08-21","summary":"Unicode, locale, and normalization hygiene: Make text comparison and normalization semantics intentional.","content_text":"<!-- Generated by scripts/synccodehygiene_recipes.py; edit data/code-hygiene/catalog.json. --> A tool-agnostic recipe to make text comparison and normalization semantics intentional. It supports a read-only audit and, when explicitly authorized, a narrow remediation. When to use it Use this recipe when the operator's specific objective is to make text comparison and normalization semantics intentional. Prefer a narrower CVE, scanner-finding, security-audit, or compliance-evidence recipe when that is the operator's actual job. Inputs Repository root and the files, package, service, or module in scope. Requested mode: audit or explicitly authorized fix. Supported runtime, compiler, framework, operating-system, and deployment versions inferred from repository files. Existing formatter, compiler, analyzer, test, build, and package-manager commands. Public API, compatibility, performance, generated-code, vendor, and migration constraints. The prompt ~~~markdown You are running the Security Recipes code-hygiene workflow code-hygiene.cross-language.unicode-locale-and-normalization-hygiene. Start read-only. Do not edit files until the operator explicitly authorizes a fix. Use repository configuration and installed tool versions as authoritative; do not impose a new style or toolchain. Scope Your bounded objective is to make text comparison and normalization semantics intentional. Inspect only operator-scoped, first-party source and configuration. Exclude generated, vendored, minified, fixture snapshot, lock history, and migration history unless explicitly included. Detection Trace case conversion, normalization, collation, length, slicing, identifier, and display operations. Identify locale-dependent behavior and byte-versus-code-point assumptions. Record file and symbol evidence for every candidate. Mark uncertain or dynamically reachable behavior instead of guessing. Fix, only when authorized Normalize only at documented boundaries and use locale-aware or locale-independent operations deliberately. Keep the diff limited to the proven issue and its focused tests. Preserve public behavior, API compatibility, and repository conventions. Do not add or broaden suppressions, weaken diagnostics, mass-format unrelated files, upgrade dependencies, or mutate external state. Verification Test composed and decomposed text, non-ASCII case, grapheme clusters, and configured locales. Compare diagnostic counts and relevant behavior before and after. Report every command, result, and check that could not run. Stop conditions Stop if normalization affects identifiers, authentication, signatures, or stored keys without a migration plan. Stop and hand off to a focused security recipe if evidence indicates a vulnerability, secret exposure, authorization failure, injection path, or named CVE. Stop rather than widening scope when the safe result requires architecture, product, compliance, operational, or data-owner decisions. ~~~ Output contract Scope and repository evidence reviewed. A candidate table with file or symbol, evidence, confidence, and disposition. In audit mode: no edits, plus the smallest safe next action for each confirmed item. In fix mode: one bounded patch, focused regression coverage, and no unrelated cleanup. Commands run, results, remaining uncertainty, and any stop-condition handoff. Verification Test composed and decomposed text, non-ASCII case, grapheme clusters, and configured locales. Confirm that diagnostic configuration, suppressions, public interfaces, generated files, vendored files, and dependencies did not change outside the authorized scope. Review the final diff for behavior changes and run the repository's focused checks before broader suites. Guardrails Read-only until edits are explicitly authorized. Do not deploy, publish, rotate secrets, alter cloud or database state, change CI permissions, or open external tickets. Do not hide debt by disabling rules, adding retries or sleeps, weakening tests, broadening ignores, or lowering warning levels. Treat generated, vendored, minified, migration-history, and fixture-snapshot files as out of scope unless explicitly named. Stop if normalization affects identifiers, authentication, signatures, or stored keys without a migration plan. Related recipes Lint warning baseline and budget Dead code and unused symbol removal Browse all code-hygiene recipes References NIST SP 800-218 Secure Software Development Framework 1.1 — NIST OWASP Developer Guide - Implementation — OWASP","agent_handoff":{"mcp_lookup_keys":["unicode-locale-and-normalization-hygiene","/recipes/general/code-hygiene/cross-language/unicode-locale-and-normalization-hygiene/","recipes/general/code-hygiene/cross-language/unicode-locale-and-normalization-hygiene.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["code-hygiene","audit","remediation"],"source_text_field":"content_text","portable_download":"security-recipe-unicode-locale-and-normalization-hygiene.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-unicode-locale-and-normalization-hygiene.json"}},{"slug":"dart-analyzer-null-safety-and-ignore-debt","title":"Dart analyzer, null-safety, and ignore debt","link_title":"Dart analyzer, null-safety, and ignore debt","url":"https://security-recipes.ai/recipes/general/code-hygiene/dart-flutter/dart-analyzer-null-safety-and-ignore-debt/","path":"/recipes/general/code-hygiene/dart-flutter/dart-analyzer-null-safety-and-ignore-debt/","source_file":"recipes/general/code-hygiene/dart-flutter/dart-analyzer-null-safety-and-ignore-debt.md","recipe_id":"code-hygiene.dart-flutter.dart-analyzer-null-safety-and-ignore-debt","recipe_kind":"code-hygiene","category":{"slug":"code-hygiene","label":"Code Hygiene"},"agent":"general","severity":"unspecified","maturity":"development","ecosystem":"dart/pub","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"","framework_version":"","jurisdiction":"","industry":[],"cve_archetypes":[],"cve_workflow_role":"","tags":["code-hygiene","dart-flutter","dart","analyzer","null-safety","ignores"],"facets":["code-hygiene","audit","remediation"],"quality":{"score":100,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context","multi-facet"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"security-recipes.ai contributors","team":"Security Engineering","model":"gpt-5-codex","ai_assisted":false,"generated_by":"","date":"2026-08-21","zero_day":false,"last_updated":"2026-08-21","summary":"Dart analyzer, null-safety, and ignore debt: Resolve analyzer diagnostics and remove unsafe null assertions and broad ignores.","content_text":"<!-- Generated by scripts/synccodehygienerecipes.py; edit data/code-hygiene/catalog.json. --> A tool-agnostic recipe to resolve analyzer diagnostics and remove unsafe null assertions and broad ignores. It supports a read-only audit and, when explicitly authorized, a narrow remediation. When to use it Use this recipe when the operator's specific objective is to resolve analyzer diagnostics and remove unsafe null assertions and broad ignores. Prefer a narrower CVE, scanner-finding, security-audit, or compliance-evidence recipe when that is the operator's actual job. Inputs Repository root and the files, package, service, or module in scope. Requested mode: audit or explicitly authorized fix. Supported runtime, compiler, framework, operating-system, and deployment versions inferred from repository files. Existing formatter, compiler, analyzer, test, build, and package-manager commands. Public API, compatibility, performance, generated-code, vendor, and migration constraints. The prompt ~~~markdown You are running the Security Recipes code-hygiene workflow code-hygiene.dart-flutter.dart-analyzer-null-safety-and-ignore-debt. Start read-only. Do not edit files until the operator explicitly authorizes a fix. Use repository configuration and installed tool versions as authoritative; do not impose a new style or toolchain. Scope Your bounded objective is to resolve analyzer diagnostics and remove unsafe null assertions and broad ignores. Inspect only operator-scoped, first-party source and configuration. Exclude generated, vendored, minified, fixture snapshot, lock history, and migration history unless explicitly included. Detection Read analysisoptions, SDK constraints, generated exclusions, ignore comments, dynamic values, casts, and bang assertions. Separate plugin and platform-channel boundaries from application-owned types. Record file and symbol evidence for every candidate. Mark uncertain or dynamically reachable behavior instead of guessing. Fix, only when authorized Use flow analysis, typed models, and narrow boundary validation without weakening analyzer rules. Keep the diff limited to the proven issue and its focused tests. Preserve public behavior, API compatibility, and repository conventions. Do not add or broaden suppressions, weaken diagnostics, mass-format unrelated files, upgrade dependencies, or mutate external state. Verification Run dart format check, analyze, and focused tests under the constrained SDK. Compare diagnostic counts and relevant behavior before and after. Report every command, result, and check that could not run. Stop conditions Stop if the fix raises the SDK floor or changes a published package API. Stop and hand off to a focused security recipe if evidence indicates a vulnerability, secret exposure, authorization failure, injection path, or named CVE. Stop rather than widening scope when the safe result requires architecture, product, compliance, operational, or data-owner decisions. ~~~ Output contract Scope and repository evidence reviewed. A candidate table with file or symbol, evidence, confidence, and disposition. In audit mode: no edits, plus the smallest safe next action for each confirmed item. In fix mode: one bounded patch, focused regression coverage, and no unrelated cleanup. Commands run, results, remaining uncertainty, and any stop-condition handoff. Verification Run dart format check, analyze, and focused tests under the constrained SDK. Confirm that diagnostic configuration, suppressions, public interfaces, generated files, vendored files, and dependencies did not change outside the authorized scope. Review the final diff for behavior changes and run the repository's focused checks before broader suites. Guardrails Read-only until edits are explicitly authorized. Do not deploy, publish, rotate secrets, alter cloud or database state, change CI permissions, or open external tickets. Do not hide debt by disabling rules, adding retries or sleeps, weakening tests, broadening ignores, or lowering warning levels. Treat generated, vendored, minified, migration-history, and fixture-snapshot files as out of scope unless explicitly named. Stop if the fix raises the SDK floor or changes a published package API. Related recipes Flutter Future, stream, controller, and widget lifecycle Lint warning baseline and budget Browse all code-hygiene recipes References NIST SP 800-218 Secure Software Development Framework 1.1 — NIST Dart analysis options — Dart project Dart asynchronous programming — Dart project Flutter State dispose lifecycle — Flutter project","agent_handoff":{"mcp_lookup_keys":["dart-analyzer-null-safety-and-ignore-debt","/recipes/general/code-hygiene/dart-flutter/dart-analyzer-null-safety-and-ignore-debt/","recipes/general/code-hygiene/dart-flutter/dart-analyzer-null-safety-and-ignore-debt.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["code-hygiene","audit","remediation"],"source_text_field":"content_text","portable_download":"security-recipe-dart-analyzer-null-safety-and-ignore-debt.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-dart-analyzer-null-safety-and-ignore-debt.json"}},{"slug":"flutter-future-stream-controller-and-widget-lifecycle","title":"Flutter Future, stream, controller, and widget lifecycle","link_title":"Flutter Future, stream, controller, and widget lifecycle","url":"https://security-recipes.ai/recipes/general/code-hygiene/dart-flutter/flutter-future-stream-controller-and-widget-lifecycle/","path":"/recipes/general/code-hygiene/dart-flutter/flutter-future-stream-controller-and-widget-lifecycle/","source_file":"recipes/general/code-hygiene/dart-flutter/flutter-future-stream-controller-and-widget-lifecycle.md","recipe_id":"code-hygiene.dart-flutter.flutter-future-stream-controller-and-widget-lifecycle","recipe_kind":"code-hygiene","category":{"slug":"code-hygiene","label":"Code Hygiene"},"agent":"general","severity":"unspecified","maturity":"development","ecosystem":"dart/pub","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"","framework_version":"","jurisdiction":"","industry":[],"cve_archetypes":[],"cve_workflow_role":"","tags":["code-hygiene","dart-flutter","flutter","futures","streams","controllers","dispose"],"facets":["code-hygiene","audit","remediation"],"quality":{"score":100,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context","multi-facet"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"security-recipes.ai contributors","team":"Security Engineering","model":"gpt-5-codex","ai_assisted":false,"generated_by":"","date":"2026-08-21","zero_day":false,"last_updated":"2026-08-21","summary":"Flutter Future, stream, controller, and widget lifecycle: Cancel subscriptions and dispose controllers and async work with the owning widget or service.","content_text":"<!-- Generated by scripts/synccodehygiene_recipes.py; edit data/code-hygiene/catalog.json. --> A tool-agnostic recipe to cancel subscriptions and dispose controllers and async work with the owning widget or service. It supports a read-only audit and, when explicitly authorized, a narrow remediation. When to use it Use this recipe when the operator's specific objective is to cancel subscriptions and dispose controllers and async work with the owning widget or service. Prefer a narrower CVE, scanner-finding, security-audit, or compliance-evidence recipe when that is the operator's actual job. Inputs Repository root and the files, package, service, or module in scope. Requested mode: audit or explicitly authorized fix. Supported runtime, compiler, framework, operating-system, and deployment versions inferred from repository files. Existing formatter, compiler, analyzer, test, build, and package-manager commands. Public API, compatibility, performance, generated-code, vendor, and migration constraints. The prompt ~~~markdown You are running the Security Recipes code-hygiene workflow code-hygiene.dart-flutter.flutter-future-stream-controller-and-widget-lifecycle. Start read-only. Do not edit files until the operator explicitly authorizes a fix. Use repository configuration and installed tool versions as authoritative; do not impose a new style or toolchain. Scope Your bounded objective is to cancel subscriptions and dispose controllers and async work with the owning widget or service. Inspect only operator-scoped, first-party source and configuration. Exclude generated, vendored, minified, fixture snapshot, lock history, and migration history unless explicitly included. Detection Trace subscriptions, timers, controllers, focus nodes, animations, futures, mounted checks, and dispose ordering. Find callbacks that call setState after teardown or retain State objects. Record file and symbol evidence for every candidate. Mark uncertain or dynamically reachable behavior instead of guessing. Fix, only when authorized Assign lifecycle ownership, cancel or dispose symmetrically, and guard unavoidable asynchronous completion. Keep the diff limited to the proven issue and its focused tests. Preserve public behavior, API compatibility, and repository conventions. Do not add or broaden suppressions, weaken diagnostics, mass-format unrelated files, upgrade dependencies, or mutate external state. Verification Run widget tests for mount, update, navigation away, cancellation, error, and repeated creation. Compare diagnostic counts and relevant behavior before and after. Report every command, result, and check that could not run. Stop conditions Stop if ownership belongs to a state-management container whose lifecycle is not visible. Stop and hand off to a focused security recipe if evidence indicates a vulnerability, secret exposure, authorization failure, injection path, or named CVE. Stop rather than widening scope when the safe result requires architecture, product, compliance, operational, or data-owner decisions. ~~~ Output contract Scope and repository evidence reviewed. A candidate table with file or symbol, evidence, confidence, and disposition. In audit mode: no edits, plus the smallest safe next action for each confirmed item. In fix mode: one bounded patch, focused regression coverage, and no unrelated cleanup. Commands run, results, remaining uncertainty, and any stop-condition handoff. Verification Run widget tests for mount, update, navigation away, cancellation, error, and repeated creation. Confirm that diagnostic configuration, suppressions, public interfaces, generated files, vendored files, and dependencies did not change outside the authorized scope. Review the final diff for behavior changes and run the repository's focused checks before broader suites. Guardrails Read-only until edits are explicitly authorized. Do not deploy, publish, rotate secrets, alter cloud or database state, change CI permissions, or open external tickets. Do not hide debt by disabling rules, adding retries or sleeps, weakening tests, broadening ignores, or lowering warning levels. Treat generated, vendored, minified, migration-history, and fixture-snapshot files as out of scope unless explicitly named. Stop if ownership belongs to a state-management container whose lifecycle is not visible. Related recipes Dart analyzer, null-safety, and ignore debt Lint warning baseline and budget Browse all code-hygiene recipes References NIST SP 800-218 Secure Software Development Framework 1.1 — NIST Dart analysis options — Dart project Dart asynchronous programming — Dart project Flutter State dispose lifecycle — Flutter project","agent_handoff":{"mcp_lookup_keys":["flutter-future-stream-controller-and-widget-lifecycle","/recipes/general/code-hygiene/dart-flutter/flutter-future-stream-controller-and-widget-lifecycle/","recipes/general/code-hygiene/dart-flutter/flutter-future-stream-controller-and-widget-lifecycle.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["code-hygiene","audit","remediation"],"source_text_field":"content_text","portable_download":"security-recipe-flutter-future-stream-controller-and-widget-lifecycle.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-flutter-future-stream-controller-and-widget-lifecycle.json"}},{"slug":"sql-migration-idempotence-and-rollback","title":"SQL migration idempotence and rollback hygiene","link_title":"SQL migration idempotence and rollback hygiene","url":"https://security-recipes.ai/recipes/general/code-hygiene/data/sql-migration-idempotence-and-rollback/","path":"/recipes/general/code-hygiene/data/sql-migration-idempotence-and-rollback/","source_file":"recipes/general/code-hygiene/data/sql-migration-idempotence-and-rollback.md","recipe_id":"code-hygiene.data.sql-migration-idempotence-and-rollback","recipe_kind":"code-hygiene","category":{"slug":"code-hygiene","label":"Code Hygiene"},"agent":"general","severity":"unspecified","maturity":"development","ecosystem":"sql/database","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"","framework_version":"","jurisdiction":"","industry":[],"cve_archetypes":[],"cve_workflow_role":"","tags":["code-hygiene","data","sql","migrations","rollback","schema"],"facets":["code-hygiene","audit","remediation"],"quality":{"score":100,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context","multi-facet"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"security-recipes.ai contributors","team":"Security Engineering","model":"gpt-5-codex","ai_assisted":false,"generated_by":"","date":"2026-08-21","zero_day":false,"last_updated":"2026-08-21","summary":"SQL migration idempotence and rollback hygiene: Make schema migrations ordered, restartable where required, and operationally reversible.","content_text":"<!-- Generated by scripts/synccodehygiene_recipes.py; edit data/code-hygiene/catalog.json. --> A tool-agnostic recipe to make schema migrations ordered, restartable where required, and operationally reversible. It supports a read-only audit and, when explicitly authorized, a narrow remediation. When to use it Use this recipe when the operator's specific objective is to make schema migrations ordered, restartable where required, and operationally reversible. Prefer a narrower CVE, scanner-finding, security-audit, or compliance-evidence recipe when that is the operator's actual job. Inputs Repository root and the files, package, service, or module in scope. Requested mode: audit or explicitly authorized fix. Supported runtime, compiler, framework, operating-system, and deployment versions inferred from repository files. Existing formatter, compiler, analyzer, test, build, and package-manager commands. Public API, compatibility, performance, generated-code, vendor, and migration constraints. The prompt ~~~markdown You are running the Security Recipes code-hygiene workflow code-hygiene.data.sql-migration-idempotence-and-rollback. Start read-only. Do not edit files until the operator explicitly authorizes a fix. Use repository configuration and installed tool versions as authoritative; do not impose a new style or toolchain. Scope Your bounded objective is to make schema migrations ordered, restartable where required, and operationally reversible. Inspect only operator-scoped, first-party source and configuration. Exclude generated, vendored, minified, fixture snapshot, lock history, and migration history unless explicitly included. Detection Inspect migration framework ordering, transactional DDL support, backfills, locks, defaults, and deploy sequencing. Classify expand, migrate, contract, irreversible, and data-loss operations. Record file and symbol evidence for every candidate. Mark uncertain or dynamically reachable behavior instead of guessing. Fix, only when authorized Split incompatible changes into bounded forward-safe steps and document honest rollback or roll-forward behavior. Keep the diff limited to the proven issue and its focused tests. Preserve public behavior, API compatibility, and repository conventions. Do not add or broaden suppressions, weaken diagnostics, mass-format unrelated files, upgrade dependencies, or mutate external state. Verification Apply from a prior schema, retry interrupted steps where supported, and validate application compatibility before and after. Compare diagnostic counts and relevant behavior before and after. Report every command, result, and check that could not run. Stop conditions Stop on destructive changes, unknown table scale, or lock duration requiring database-owner approval. Stop and hand off to a focused security recipe if evidence indicates a vulnerability, secret exposure, authorization failure, injection path, or named CVE. Stop rather than widening scope when the safe result requires architecture, product, compliance, operational, or data-owner decisions. ~~~ Output contract Scope and repository evidence reviewed. A candidate table with file or symbol, evidence, confidence, and disposition. In audit mode: no edits, plus the smallest safe next action for each confirmed item. In fix mode: one bounded patch, focused regression coverage, and no unrelated cleanup. Commands run, results, remaining uncertainty, and any stop-condition handoff. Verification Apply from a prior schema, retry interrupted steps where supported, and validate application compatibility before and after. Confirm that diagnostic configuration, suppressions, public interfaces, generated files, vendored files, and dependencies did not change outside the authorized scope. Review the final diff for behavior changes and run the repository's focused checks before broader suites. Guardrails Read-only until edits are explicitly authorized. Do not deploy, publish, rotate secrets, alter cloud or database state, change CI permissions, or open external tickets. Do not hide debt by disabling rules, adding retries or sleeps, weakening tests, broadening ignores, or lowering warning levels. Treat generated, vendored, minified, migration-history, and fixture-snapshot files as out of scope unless explicitly named. Stop on destructive changes, unknown table scale, or lock duration requiring database-owner approval. Related recipes SQL transaction, locking, and concurrency hygiene SQL query plan, index, and N+1 hygiene Browse all code-hygiene recipes References NIST SP 800-218 Secure Software Development Framework 1.1 — NIST PostgreSQL transaction isolation — PostgreSQL Global Development Group PostgreSQL using EXPLAIN — PostgreSQL Global Development Group","agent_handoff":{"mcp_lookup_keys":["sql-migration-idempotence-and-rollback","/recipes/general/code-hygiene/data/sql-migration-idempotence-and-rollback/","recipes/general/code-hygiene/data/sql-migration-idempotence-and-rollback.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["code-hygiene","audit","remediation"],"source_text_field":"content_text","portable_download":"security-recipe-sql-migration-idempotence-and-rollback.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-sql-migration-idempotence-and-rollback.json"}},{"slug":"sql-query-plan-index-and-n-plus-one","title":"SQL query plan, index, and N+1 hygiene","link_title":"SQL query plan, index, and N+1 hygiene","url":"https://security-recipes.ai/recipes/general/code-hygiene/data/sql-query-plan-index-and-n-plus-one/","path":"/recipes/general/code-hygiene/data/sql-query-plan-index-and-n-plus-one/","source_file":"recipes/general/code-hygiene/data/sql-query-plan-index-and-n-plus-one.md","recipe_id":"code-hygiene.data.sql-query-plan-index-and-n-plus-one","recipe_kind":"code-hygiene","category":{"slug":"code-hygiene","label":"Code Hygiene"},"agent":"general","severity":"unspecified","maturity":"development","ecosystem":"sql/database","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"","framework_version":"","jurisdiction":"","industry":[],"cve_archetypes":[],"cve_workflow_role":"","tags":["code-hygiene","data","sql","query-plan","indexes","n-plus-one"],"facets":["code-hygiene","audit","remediation"],"quality":{"score":100,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context","multi-facet"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"security-recipes.ai contributors","team":"Security Engineering","model":"gpt-5-codex","ai_assisted":false,"generated_by":"","date":"2026-08-21","zero_day":false,"last_updated":"2026-08-21","summary":"SQL query plan, index, and N+1 hygiene: Remove proven query amplification and plan regressions using representative evidence.","content_text":"<!-- Generated by scripts/synccodehygiene_recipes.py; edit data/code-hygiene/catalog.json. --> A tool-agnostic recipe to remove proven query amplification and plan regressions using representative evidence. It supports a read-only audit and, when explicitly authorized, a narrow remediation. When to use it Use this recipe when the operator's specific objective is to remove proven query amplification and plan regressions using representative evidence. Prefer a narrower CVE, scanner-finding, security-audit, or compliance-evidence recipe when that is the operator's actual job. Inputs Repository root and the files, package, service, or module in scope. Requested mode: audit or explicitly authorized fix. Supported runtime, compiler, framework, operating-system, and deployment versions inferred from repository files. Existing formatter, compiler, analyzer, test, build, and package-manager commands. Public API, compatibility, performance, generated-code, vendor, and migration constraints. The prompt ~~~markdown You are running the Security Recipes code-hygiene workflow code-hygiene.data.sql-query-plan-index-and-n-plus-one. Start read-only. Do not edit files until the operator explicitly authorizes a fix. Use repository configuration and installed tool versions as authoritative; do not impose a new style or toolchain. Scope Your bounded objective is to remove proven query amplification and plan regressions using representative evidence. Inspect only operator-scoped, first-party source and configuration. Exclude generated, vendored, minified, fixture snapshot, lock history, and migration history unless explicitly included. Detection Capture query count, parameterized SQL, representative EXPLAIN output, row estimates, scans, joins, and sort or spill behavior. Distinguish application N+1 calls from a single intentionally repeated query. Record file and symbol evidence for every candidate. Mark uncertain or dynamically reachable behavior instead of guessing. Fix, only when authorized Batch or reshape application access first and propose indexes only when predicates and workload justify them. Keep the diff limited to the proven issue and its focused tests. Preserve public behavior, API compatibility, and repository conventions. Do not add or broaden suppressions, weaken diagnostics, mass-format unrelated files, upgrade dependencies, or mutate external state. Verification Compare result sets, query counts, plans, and representative timing without relying on tiny fixtures alone. Compare diagnostic counts and relevant behavior before and after. Report every command, result, and check that could not run. Stop conditions Stop before adding or removing indexes without table size, write cost, and production-owner review. Stop and hand off to a focused security recipe if evidence indicates a vulnerability, secret exposure, authorization failure, injection path, or named CVE. Stop rather than widening scope when the safe result requires architecture, product, compliance, operational, or data-owner decisions. ~~~ Output contract Scope and repository evidence reviewed. A candidate table with file or symbol, evidence, confidence, and disposition. In audit mode: no edits, plus the smallest safe next action for each confirmed item. In fix mode: one bounded patch, focused regression coverage, and no unrelated cleanup. Commands run, results, remaining uncertainty, and any stop-condition handoff. Verification Compare result sets, query counts, plans, and representative timing without relying on tiny fixtures alone. Confirm that diagnostic configuration, suppressions, public interfaces, generated files, vendored files, and dependencies did not change outside the authorized scope. Review the final diff for behavior changes and run the repository's focused checks before broader suites. Guardrails Read-only until edits are explicitly authorized. Do not deploy, publish, rotate secrets, alter cloud or database state, change CI permissions, or open external tickets. Do not hide debt by disabling rules, adding retries or sleeps, weakening tests, broadening ignores, or lowering warning levels. Treat generated, vendored, minified, migration-history, and fixture-snapshot files as out of scope unless explicitly named. Stop before adding or removing indexes without table size, write cost, and production-owner review. Related recipes SQL migration idempotence and rollback hygiene SQL transaction, locking, and concurrency hygiene Browse all code-hygiene recipes References NIST SP 800-218 Secure Software Development Framework 1.1 — NIST PostgreSQL transaction isolation — PostgreSQL Global Development Group PostgreSQL using EXPLAIN — PostgreSQL Global Development Group","agent_handoff":{"mcp_lookup_keys":["sql-query-plan-index-and-n-plus-one","/recipes/general/code-hygiene/data/sql-query-plan-index-and-n-plus-one/","recipes/general/code-hygiene/data/sql-query-plan-index-and-n-plus-one.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["code-hygiene","audit","remediation"],"source_text_field":"content_text","portable_download":"security-recipe-sql-query-plan-index-and-n-plus-one.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-sql-query-plan-index-and-n-plus-one.json"}},{"slug":"sql-transaction-locking-and-concurrency","title":"SQL transaction, locking, and concurrency hygiene","link_title":"SQL transaction, locking, and concurrency hygiene","url":"https://security-recipes.ai/recipes/general/code-hygiene/data/sql-transaction-locking-and-concurrency/","path":"/recipes/general/code-hygiene/data/sql-transaction-locking-and-concurrency/","source_file":"recipes/general/code-hygiene/data/sql-transaction-locking-and-concurrency.md","recipe_id":"code-hygiene.data.sql-transaction-locking-and-concurrency","recipe_kind":"code-hygiene","category":{"slug":"code-hygiene","label":"Code Hygiene"},"agent":"general","severity":"unspecified","maturity":"development","ecosystem":"sql/database","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"","framework_version":"","jurisdiction":"","industry":[],"cve_archetypes":[],"cve_workflow_role":"","tags":["code-hygiene","data","sql","transactions","locks","concurrency"],"facets":["code-hygiene","audit","remediation"],"quality":{"score":100,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context","multi-facet"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"security-recipes.ai contributors","team":"Security Engineering","model":"gpt-5-codex","ai_assisted":false,"generated_by":"","date":"2026-08-21","zero_day":false,"last_updated":"2026-08-21","summary":"SQL transaction, locking, and concurrency hygiene: Make transaction scope and concurrent update behavior explicit.","content_text":"<!-- Generated by scripts/synccodehygiene_recipes.py; edit data/code-hygiene/catalog.json. --> A tool-agnostic recipe to make transaction scope and concurrent update behavior explicit. It supports a read-only audit and, when explicitly authorized, a narrow remediation. When to use it Use this recipe when the operator's specific objective is to make transaction scope and concurrent update behavior explicit. Prefer a narrower CVE, scanner-finding, security-audit, or compliance-evidence recipe when that is the operator's actual job. Inputs Repository root and the files, package, service, or module in scope. Requested mode: audit or explicitly authorized fix. Supported runtime, compiler, framework, operating-system, and deployment versions inferred from repository files. Existing formatter, compiler, analyzer, test, build, and package-manager commands. Public API, compatibility, performance, generated-code, vendor, and migration constraints. The prompt ~~~markdown You are running the Security Recipes code-hygiene workflow code-hygiene.data.sql-transaction-locking-and-concurrency. Start read-only. Do not edit files until the operator explicitly authorizes a fix. Use repository configuration and installed tool versions as authoritative; do not impose a new style or toolchain. Scope Your bounded objective is to make transaction scope and concurrent update behavior explicit. Inspect only operator-scoped, first-party source and configuration. Exclude generated, vendored, minified, fixture snapshot, lock history, and migration history unless explicitly included. Detection Trace transaction begin and end, isolation, lock order, retries, read-modify-write sequences, and external calls inside transactions. Identify lost-update, deadlock, long-transaction, and partial-commit paths. Record file and symbol evidence for every candidate. Mark uncertain or dynamically reachable behavior instead of guessing. Fix, only when authorized Shorten transactions, use appropriate atomic operations, and add bounded retry only for identified transient conflicts. Keep the diff limited to the proven issue and its focused tests. Preserve public behavior, API compatibility, and repository conventions. Do not add or broaden suppressions, weaken diagnostics, mass-format unrelated files, upgrade dependencies, or mutate external state. Verification Run concurrent tests for conflict, deadlock, retry, rollback, and invariant preservation. Compare diagnostic counts and relevant behavior before and after. Report every command, result, and check that could not run. Stop conditions Stop if selecting isolation or lock behavior requires production workload evidence. Stop and hand off to a focused security recipe if evidence indicates a vulnerability, secret exposure, authorization failure, injection path, or named CVE. Stop rather than widening scope when the safe result requires architecture, product, compliance, operational, or data-owner decisions. ~~~ Output contract Scope and repository evidence reviewed. A candidate table with file or symbol, evidence, confidence, and disposition. In audit mode: no edits, plus the smallest safe next action for each confirmed item. In fix mode: one bounded patch, focused regression coverage, and no unrelated cleanup. Commands run, results, remaining uncertainty, and any stop-condition handoff. Verification Run concurrent tests for conflict, deadlock, retry, rollback, and invariant preservation. Confirm that diagnostic configuration, suppressions, public interfaces, generated files, vendored files, and dependencies did not change outside the authorized scope. Review the final diff for behavior changes and run the repository's focused checks before broader suites. Guardrails Read-only until edits are explicitly authorized. Do not deploy, publish, rotate secrets, alter cloud or database state, change CI permissions, or open external tickets. Do not hide debt by disabling rules, adding retries or sleeps, weakening tests, broadening ignores, or lowering warning levels. Treat generated, vendored, minified, migration-history, and fixture-snapshot files as out of scope unless explicitly named. Stop if selecting isolation or lock behavior requires production workload evidence. Related recipes SQL migration idempotence and rollback hygiene SQL query plan, index, and N+1 hygiene Browse all code-hygiene recipes References NIST SP 800-218 Secure Software Development Framework 1.1 — NIST PostgreSQL transaction isolation — PostgreSQL Global Development Group PostgreSQL using EXPLAIN — PostgreSQL Global Development Group","agent_handoff":{"mcp_lookup_keys":["sql-transaction-locking-and-concurrency","/recipes/general/code-hygiene/data/sql-transaction-locking-and-concurrency/","recipes/general/code-hygiene/data/sql-transaction-locking-and-concurrency.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["code-hygiene","audit","remediation"],"source_text_field":"content_text","portable_download":"security-recipe-sql-transaction-locking-and-concurrency.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-sql-transaction-locking-and-concurrency.json"}},{"slug":"dotnet-async-cancellation-and-fire-and-forget","title":".NET async cancellation and fire-and-forget lifecycle","link_title":".NET async cancellation and fire-and-forget lifecycle","url":"https://security-recipes.ai/recipes/general/code-hygiene/dotnet/dotnet-async-cancellation-and-fire-and-forget/","path":"/recipes/general/code-hygiene/dotnet/dotnet-async-cancellation-and-fire-and-forget/","source_file":"recipes/general/code-hygiene/dotnet/dotnet-async-cancellation-and-fire-and-forget.md","recipe_id":"code-hygiene.dotnet.dotnet-async-cancellation-and-fire-and-forget","recipe_kind":"code-hygiene","category":{"slug":"code-hygiene","label":"Code Hygiene"},"agent":"general","severity":"unspecified","maturity":"development","ecosystem":"dotnet/nuget","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"","framework_version":"","jurisdiction":"","industry":[],"cve_archetypes":[],"cve_workflow_role":"","tags":["code-hygiene","dotnet","async","cancellationtoken","tasks"],"facets":["code-hygiene","audit","remediation"],"quality":{"score":100,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context","multi-facet"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"security-recipes.ai contributors","team":"Security Engineering","model":"gpt-5-codex","ai_assisted":false,"generated_by":"","date":"2026-08-21","zero_day":false,"last_updated":"2026-08-21","summary":".NET async cancellation and fire-and-forget lifecycle: Propagate CancellationToken and observe every Task failure.","content_text":"<!-- Generated by scripts/synccodehygiene_recipes.py; edit data/code-hygiene/catalog.json. --> A tool-agnostic recipe to propagate CancellationToken and observe every Task failure. It supports a read-only audit and, when explicitly authorized, a narrow remediation. When to use it Use this recipe when the operator's specific objective is to propagate CancellationToken and observe every Task failure. Prefer a narrower CVE, scanner-finding, security-audit, or compliance-evidence recipe when that is the operator's actual job. Inputs Repository root and the files, package, service, or module in scope. Requested mode: audit or explicitly authorized fix. Supported runtime, compiler, framework, operating-system, and deployment versions inferred from repository files. Existing formatter, compiler, analyzer, test, build, and package-manager commands. Public API, compatibility, performance, generated-code, vendor, and migration constraints. The prompt ~~~markdown You are running the Security Recipes code-hygiene workflow code-hygiene.dotnet.dotnet-async-cancellation-and-fire-and-forget. Start read-only. Do not edit files until the operator explicitly authorizes a fix. Use repository configuration and installed tool versions as authoritative; do not impose a new style or toolchain. Scope Your bounded objective is to propagate CancellationToken and observe every Task failure. Inspect only operator-scoped, first-party source and configuration. Exclude generated, vendored, minified, fixture snapshot, lock history, and migration history unless explicitly included. Detection Trace Task creation, awaiting, token flow, timeout ownership, async void, and background service lifetime. Find sync-over-async and tasks whose exceptions are never observed. Record file and symbol evidence for every candidate. Mark uncertain or dynamically reachable behavior instead of guessing. Fix, only when authorized Return or own tasks explicitly, propagate tokens, and isolate approved background work behind a supervised service. Keep the diff limited to the proven issue and its focused tests. Preserve public behavior, API compatibility, and repository conventions. Do not add or broaden suppressions, weaken diagnostics, mass-format unrelated files, upgrade dependencies, or mutate external state. Verification Test cancellation, timeout, exception, shutdown, and synchronization-context-sensitive paths. Compare diagnostic counts and relevant behavior before and after. Report every command, result, and check that could not run. Stop conditions Stop if changing async signatures breaks a public interface or framework callback contract. Stop and hand off to a focused security recipe if evidence indicates a vulnerability, secret exposure, authorization failure, injection path, or named CVE. Stop rather than widening scope when the safe result requires architecture, product, compliance, operational, or data-owner decisions. ~~~ Output contract Scope and repository evidence reviewed. A candidate table with file or symbol, evidence, confidence, and disposition. In audit mode: no edits, plus the smallest safe next action for each confirmed item. In fix mode: one bounded patch, focused regression coverage, and no unrelated cleanup. Commands run, results, remaining uncertainty, and any stop-condition handoff. Verification Test cancellation, timeout, exception, shutdown, and synchronization-context-sensitive paths. Confirm that diagnostic configuration, suppressions, public interfaces, generated files, vendored files, and dependencies did not change outside the authorized scope. Review the final diff for behavior changes and run the repository's focused checks before broader suites. Guardrails Read-only until edits are explicitly authorized. Do not deploy, publish, rotate secrets, alter cloud or database state, change CI permissions, or open external tickets. Do not hide debt by disabling rules, adding retries or sleeps, weakening tests, broadening ignores, or lowering warning levels. Treat generated, vendored, minified, migration-history, and fixture-snapshot files as out of scope unless explicitly named. Stop if changing async signatures breaks a public interface or framework callback contract. Related recipes .NET nullable and analyzer suppression debt .NET disposable and async-disposable lifecycle Browse all code-hygiene recipes References NIST SP 800-218 Secure Software Development Framework 1.1 — NIST .NET code quality analysis rules — Microsoft C# nullable references — Microsoft C# asynchronous programming — Microsoft","agent_handoff":{"mcp_lookup_keys":["dotnet-async-cancellation-and-fire-and-forget","/recipes/general/code-hygiene/dotnet/dotnet-async-cancellation-and-fire-and-forget/","recipes/general/code-hygiene/dotnet/dotnet-async-cancellation-and-fire-and-forget.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["code-hygiene","audit","remediation"],"source_text_field":"content_text","portable_download":"security-recipe-dotnet-async-cancellation-and-fire-and-forget.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-dotnet-async-cancellation-and-fire-and-forget.json"}},{"slug":"dotnet-disposable-and-async-disposable-lifecycle","title":".NET disposable and async-disposable lifecycle","link_title":".NET disposable and async-disposable lifecycle","url":"https://security-recipes.ai/recipes/general/code-hygiene/dotnet/dotnet-disposable-and-async-disposable-lifecycle/","path":"/recipes/general/code-hygiene/dotnet/dotnet-disposable-and-async-disposable-lifecycle/","source_file":"recipes/general/code-hygiene/dotnet/dotnet-disposable-and-async-disposable-lifecycle.md","recipe_id":"code-hygiene.dotnet.dotnet-disposable-and-async-disposable-lifecycle","recipe_kind":"code-hygiene","category":{"slug":"code-hygiene","label":"Code Hygiene"},"agent":"general","severity":"unspecified","maturity":"development","ecosystem":"dotnet/nuget","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"","framework_version":"","jurisdiction":"","industry":[],"cve_archetypes":[],"cve_workflow_role":"","tags":["code-hygiene","dotnet","idisposable","iasyncdisposable","resources"],"facets":["code-hygiene","audit","remediation"],"quality":{"score":100,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context","multi-facet"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"security-recipes.ai contributors","team":"Security Engineering","model":"gpt-5-codex","ai_assisted":false,"generated_by":"","date":"2026-08-21","zero_day":false,"last_updated":"2026-08-21","summary":".NET disposable and async-disposable lifecycle: Dispose synchronous and asynchronous resources exactly once after their final use.","content_text":"<!-- Generated by scripts/synccodehygiene_recipes.py; edit data/code-hygiene/catalog.json. --> A tool-agnostic recipe to dispose synchronous and asynchronous resources exactly once after their final use. It supports a read-only audit and, when explicitly authorized, a narrow remediation. When to use it Use this recipe when the operator's specific objective is to dispose synchronous and asynchronous resources exactly once after their final use. Prefer a narrower CVE, scanner-finding, security-audit, or compliance-evidence recipe when that is the operator's actual job. Inputs Repository root and the files, package, service, or module in scope. Requested mode: audit or explicitly authorized fix. Supported runtime, compiler, framework, operating-system, and deployment versions inferred from repository files. Existing formatter, compiler, analyzer, test, build, and package-manager commands. Public API, compatibility, performance, generated-code, vendor, and migration constraints. The prompt ~~~markdown You are running the Security Recipes code-hygiene workflow code-hygiene.dotnet.dotnet-disposable-and-async-disposable-lifecycle. Start read-only. Do not edit files until the operator explicitly authorizes a fix. Use repository configuration and installed tool versions as authoritative; do not impose a new style or toolchain. Scope Your bounded objective is to dispose synchronous and asynchronous resources exactly once after their final use. Inspect only operator-scoped, first-party source and configuration. Exclude generated, vendored, minified, fixture snapshot, lock history, and migration history unless explicitly included. Detection Trace IDisposable and IAsyncDisposable ownership across factories, DI scopes, returns, exceptions, and unawaited tasks. Identify double-dispose, early-dispose, and framework-owned services. Record file and symbol evidence for every candidate. Mark uncertain or dynamically reachable behavior instead of guessing. Fix, only when authorized Use using or await using at the true owner and preserve DI/container lifecycle rules. Keep the diff limited to the proven issue and its focused tests. Preserve public behavior, API compatibility, and repository conventions. Do not add or broaden suppressions, weaken diagnostics, mass-format unrelated files, upgrade dependencies, or mutate external state. Verification Test success, exception, cancellation, partial initialization, and final asynchronous flush. Compare diagnostic counts and relevant behavior before and after. Report every command, result, and check that could not run. Stop conditions Stop when ownership belongs to a container or caller and cannot be proven locally. Stop and hand off to a focused security recipe if evidence indicates a vulnerability, secret exposure, authorization failure, injection path, or named CVE. Stop rather than widening scope when the safe result requires architecture, product, compliance, operational, or data-owner decisions. ~~~ Output contract Scope and repository evidence reviewed. A candidate table with file or symbol, evidence, confidence, and disposition. In audit mode: no edits, plus the smallest safe next action for each confirmed item. In fix mode: one bounded patch, focused regression coverage, and no unrelated cleanup. Commands run, results, remaining uncertainty, and any stop-condition handoff. Verification Test success, exception, cancellation, partial initialization, and final asynchronous flush. Confirm that diagnostic configuration, suppressions, public interfaces, generated files, vendored files, and dependencies did not change outside the authorized scope. Review the final diff for behavior changes and run the repository's focused checks before broader suites. Guardrails Read-only until edits are explicitly authorized. Do not deploy, publish, rotate secrets, alter cloud or database state, change CI permissions, or open external tickets. Do not hide debt by disabling rules, adding retries or sleeps, weakening tests, broadening ignores, or lowering warning levels. Treat generated, vendored, minified, migration-history, and fixture-snapshot files as out of scope unless explicitly named. Stop when ownership belongs to a container or caller and cannot be proven locally. Related recipes .NET nullable and analyzer suppression debt .NET async cancellation and fire-and-forget lifecycle Browse all code-hygiene recipes References NIST SP 800-218 Secure Software Development Framework 1.1 — NIST .NET code quality analysis rules — Microsoft C# nullable references — Microsoft .NET dispose pattern — Microsoft","agent_handoff":{"mcp_lookup_keys":["dotnet-disposable-and-async-disposable-lifecycle","/recipes/general/code-hygiene/dotnet/dotnet-disposable-and-async-disposable-lifecycle/","recipes/general/code-hygiene/dotnet/dotnet-disposable-and-async-disposable-lifecycle.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["code-hygiene","audit","remediation"],"source_text_field":"content_text","portable_download":"security-recipe-dotnet-disposable-and-async-disposable-lifecycle.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-dotnet-disposable-and-async-disposable-lifecycle.json"}},{"slug":"dotnet-linq-enumeration-and-ef-query-boundaries","title":".NET LINQ enumeration and EF query boundaries","link_title":".NET LINQ enumeration and EF query boundaries","url":"https://security-recipes.ai/recipes/general/code-hygiene/dotnet/dotnet-linq-enumeration-and-ef-query-boundaries/","path":"/recipes/general/code-hygiene/dotnet/dotnet-linq-enumeration-and-ef-query-boundaries/","source_file":"recipes/general/code-hygiene/dotnet/dotnet-linq-enumeration-and-ef-query-boundaries.md","recipe_id":"code-hygiene.dotnet.dotnet-linq-enumeration-and-ef-query-boundaries","recipe_kind":"code-hygiene","category":{"slug":"code-hygiene","label":"Code Hygiene"},"agent":"general","severity":"unspecified","maturity":"development","ecosystem":"dotnet/nuget","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"","framework_version":"","jurisdiction":"","industry":[],"cve_archetypes":[],"cve_workflow_role":"","tags":["code-hygiene","dotnet","linq","entity-framework","queries"],"facets":["code-hygiene","audit","remediation"],"quality":{"score":100,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context","multi-facet"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"security-recipes.ai contributors","team":"Security Engineering","model":"gpt-5-codex","ai_assisted":false,"generated_by":"","date":"2026-08-21","zero_day":false,"last_updated":"2026-08-21","summary":".NET LINQ enumeration and EF query boundaries: Avoid repeated enumeration, client evaluation, N+1 loading, and leaked query lifetimes.","content_text":"<!-- Generated by scripts/synccodehygiene_recipes.py; edit data/code-hygiene/catalog.json. --> A tool-agnostic recipe to avoid repeated enumeration, client evaluation, N+1 loading, and leaked query lifetimes. It supports a read-only audit and, when explicitly authorized, a narrow remediation. When to use it Use this recipe when the operator's specific objective is to avoid repeated enumeration, client evaluation, N+1 loading, and leaked query lifetimes. Prefer a narrower CVE, scanner-finding, security-audit, or compliance-evidence recipe when that is the operator's actual job. Inputs Repository root and the files, package, service, or module in scope. Requested mode: audit or explicitly authorized fix. Supported runtime, compiler, framework, operating-system, and deployment versions inferred from repository files. Existing formatter, compiler, analyzer, test, build, and package-manager commands. Public API, compatibility, performance, generated-code, vendor, and migration constraints. The prompt ~~~markdown You are running the Security Recipes code-hygiene workflow code-hygiene.dotnet.dotnet-linq-enumeration-and-ef-query-boundaries. Start read-only. Do not edit files until the operator explicitly authorizes a fix. Use repository configuration and installed tool versions as authoritative; do not impose a new style or toolchain. Scope Your bounded objective is to avoid repeated enumeration, client evaluation, N+1 loading, and leaked query lifetimes. Inspect only operator-scoped, first-party source and configuration. Exclude generated, vendored, minified, fixture snapshot, lock history, and migration history unless explicitly included. Detection Trace IQueryable versus IEnumerable transitions, materialization points, repeated enumeration, includes, and per-row queries. Inspect DbContext lifetime and transaction boundaries. Record file and symbol evidence for every candidate. Mark uncertain or dynamically reachable behavior instead of guessing. Fix, only when authorized Materialize deliberately, shape server-side queries, and batch related data without hiding query costs. Keep the diff limited to the proven issue and its focused tests. Preserve public behavior, API compatibility, and repository conventions. Do not add or broaden suppressions, weaken diagnostics, mass-format unrelated files, upgrade dependencies, or mutate external state. Verification Assert query counts and generated SQL where supported plus result, cancellation, and transaction tests. Compare diagnostic counts and relevant behavior before and after. Report every command, result, and check that could not run. Stop conditions Stop if query changes need production data distribution or indexing decisions. Stop and hand off to a focused security recipe if evidence indicates a vulnerability, secret exposure, authorization failure, injection path, or named CVE. Stop rather than widening scope when the safe result requires architecture, product, compliance, operational, or data-owner decisions. ~~~ Output contract Scope and repository evidence reviewed. A candidate table with file or symbol, evidence, confidence, and disposition. In audit mode: no edits, plus the smallest safe next action for each confirmed item. In fix mode: one bounded patch, focused regression coverage, and no unrelated cleanup. Commands run, results, remaining uncertainty, and any stop-condition handoff. Verification Assert query counts and generated SQL where supported plus result, cancellation, and transaction tests. Confirm that diagnostic configuration, suppressions, public interfaces, generated files, vendored files, and dependencies did not change outside the authorized scope. Review the final diff for behavior changes and run the repository's focused checks before broader suites. Guardrails Read-only until edits are explicitly authorized. Do not deploy, publish, rotate secrets, alter cloud or database state, change CI permissions, or open external tickets. Do not hide debt by disabling rules, adding retries or sleeps, weakening tests, broadening ignores, or lowering warning levels. Treat generated, vendored, minified, migration-history, and fixture-snapshot files as out of scope unless explicitly named. Stop if query changes need production data distribution or indexing decisions. Related recipes .NET nullable and analyzer suppression debt .NET async cancellation and fire-and-forget lifecycle Browse all code-hygiene recipes References NIST SP 800-218 Secure Software Development Framework 1.1 — NIST .NET code quality analysis rules — Microsoft C# nullable references — Microsoft","agent_handoff":{"mcp_lookup_keys":["dotnet-linq-enumeration-and-ef-query-boundaries","/recipes/general/code-hygiene/dotnet/dotnet-linq-enumeration-and-ef-query-boundaries/","recipes/general/code-hygiene/dotnet/dotnet-linq-enumeration-and-ef-query-boundaries.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["code-hygiene","audit","remediation"],"source_text_field":"content_text","portable_download":"security-recipe-dotnet-linq-enumeration-and-ef-query-boundaries.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-dotnet-linq-enumeration-and-ef-query-boundaries.json"}},{"slug":"dotnet-nullable-and-analyzer-suppression-debt","title":".NET nullable and analyzer suppression debt","link_title":".NET nullable and analyzer suppression debt","url":"https://security-recipes.ai/recipes/general/code-hygiene/dotnet/dotnet-nullable-and-analyzer-suppression-debt/","path":"/recipes/general/code-hygiene/dotnet/dotnet-nullable-and-analyzer-suppression-debt/","source_file":"recipes/general/code-hygiene/dotnet/dotnet-nullable-and-analyzer-suppression-debt.md","recipe_id":"code-hygiene.dotnet.dotnet-nullable-and-analyzer-suppression-debt","recipe_kind":"code-hygiene","category":{"slug":"code-hygiene","label":"Code Hygiene"},"agent":"general","severity":"unspecified","maturity":"development","ecosystem":"dotnet/nuget","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"","framework_version":"","jurisdiction":"","industry":[],"cve_archetypes":[],"cve_workflow_role":"","tags":["code-hygiene","dotnet","nullable","analyzers","suppressions"],"facets":["code-hygiene","audit","remediation"],"quality":{"score":100,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context","multi-facet"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"security-recipes.ai contributors","team":"Security Engineering","model":"gpt-5-codex","ai_assisted":false,"generated_by":"","date":"2026-08-21","zero_day":false,"last_updated":"2026-08-21","summary":".NET nullable and analyzer suppression debt: Resolve nullable and analyzer warnings without null-forgiving or pragma expansion.","content_text":"<!-- Generated by scripts/synccodehygiene_recipes.py; edit data/code-hygiene/catalog.json. --> A tool-agnostic recipe to resolve nullable and analyzer warnings without null-forgiving or pragma expansion. It supports a read-only audit and, when explicitly authorized, a narrow remediation. When to use it Use this recipe when the operator's specific objective is to resolve nullable and analyzer warnings without null-forgiving or pragma expansion. Prefer a narrower CVE, scanner-finding, security-audit, or compliance-evidence recipe when that is the operator's actual job. Inputs Repository root and the files, package, service, or module in scope. Requested mode: audit or explicitly authorized fix. Supported runtime, compiler, framework, operating-system, and deployment versions inferred from repository files. Existing formatter, compiler, analyzer, test, build, and package-manager commands. Public API, compatibility, performance, generated-code, vendor, and migration constraints. The prompt ~~~markdown You are running the Security Recipes code-hygiene workflow code-hygiene.dotnet.dotnet-nullable-and-analyzer-suppression-debt. Start read-only. Do not edit files until the operator explicitly authorizes a fix. Use repository configuration and installed tool versions as authoritative; do not impose a new style or toolchain. Scope Your bounded objective is to resolve nullable and analyzer warnings without null-forgiving or pragma expansion. Inspect only operator-scoped, first-party source and configuration. Exclude generated, vendored, minified, fixture snapshot, lock history, and migration history unless explicitly included. Detection Read project, Directory.Build, and editorconfig settings and inventory nullable warnings, pragmas, and global suppressions. Separate generated code and external annotations from application contracts. Record file and symbol evidence for every candidate. Mark uncertain or dynamically reachable behavior instead of guessing. Fix, only when authorized Add truthful annotations, guards, initialization, or analyzer-compliant code at the narrowest boundary. Keep the diff limited to the proven issue and its focused tests. Preserve public behavior, API compatibility, and repository conventions. Do not add or broaden suppressions, weaken diagnostics, mass-format unrelated files, upgrade dependencies, or mutate external state. Verification Build with configured analyzers and run focused tests with no new suppressions. Compare diagnostic counts and relevant behavior before and after. Report every command, result, and check that could not run. Stop conditions Stop if annotations change a public contract or suppression rationale cannot be verified. Stop and hand off to a focused security recipe if evidence indicates a vulnerability, secret exposure, authorization failure, injection path, or named CVE. Stop rather than widening scope when the safe result requires architecture, product, compliance, operational, or data-owner decisions. ~~~ Output contract Scope and repository evidence reviewed. A candidate table with file or symbol, evidence, confidence, and disposition. In audit mode: no edits, plus the smallest safe next action for each confirmed item. In fix mode: one bounded patch, focused regression coverage, and no unrelated cleanup. Commands run, results, remaining uncertainty, and any stop-condition handoff. Verification Build with configured analyzers and run focused tests with no new suppressions. Confirm that diagnostic configuration, suppressions, public interfaces, generated files, vendored files, and dependencies did not change outside the authorized scope. Review the final diff for behavior changes and run the repository's focused checks before broader suites. Guardrails Read-only until edits are explicitly authorized. Do not deploy, publish, rotate secrets, alter cloud or database state, change CI permissions, or open external tickets. Do not hide debt by disabling rules, adding retries or sleeps, weakening tests, broadening ignores, or lowering warning levels. Treat generated, vendored, minified, migration-history, and fixture-snapshot files as out of scope unless explicitly named. Stop if annotations change a public contract or suppression rationale cannot be verified. Related recipes .NET async cancellation and fire-and-forget lifecycle .NET disposable and async-disposable lifecycle Browse all code-hygiene recipes References NIST SP 800-218 Secure Software Development Framework 1.1 — NIST .NET code quality analysis rules — Microsoft C# nullable references — Microsoft","agent_handoff":{"mcp_lookup_keys":["dotnet-nullable-and-analyzer-suppression-debt","/recipes/general/code-hygiene/dotnet/dotnet-nullable-and-analyzer-suppression-debt/","recipes/general/code-hygiene/dotnet/dotnet-nullable-and-analyzer-suppression-debt.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["code-hygiene","audit","remediation"],"source_text_field":"content_text","portable_download":"security-recipe-dotnet-nullable-and-analyzer-suppression-debt.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-dotnet-nullable-and-analyzer-suppression-debt.json"}},{"slug":"go-channel-lock-and-shared-state-hygiene","title":"Go channel, lock, and shared-state hygiene","link_title":"Go channel, lock, and shared-state hygiene","url":"https://security-recipes.ai/recipes/general/code-hygiene/go/go-channel-lock-and-shared-state-hygiene/","path":"/recipes/general/code-hygiene/go/go-channel-lock-and-shared-state-hygiene/","source_file":"recipes/general/code-hygiene/go/go-channel-lock-and-shared-state-hygiene.md","recipe_id":"code-hygiene.go.go-channel-lock-and-shared-state-hygiene","recipe_kind":"code-hygiene","category":{"slug":"code-hygiene","label":"Code Hygiene"},"agent":"general","severity":"unspecified","maturity":"development","ecosystem":"go/modules","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"","framework_version":"","jurisdiction":"","industry":[],"cve_archetypes":[],"cve_workflow_role":"","tags":["code-hygiene","go","channels","mutex","race"],"facets":["code-hygiene","audit","remediation"],"quality":{"score":100,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context","multi-facet"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"security-recipes.ai contributors","team":"Security Engineering","model":"gpt-5-codex","ai_assisted":false,"generated_by":"","date":"2026-08-21","zero_day":false,"last_updated":"2026-08-21","summary":"Go channel, lock, and shared-state hygiene: Remove channel ownership ambiguity, lock misuse, and data races.","content_text":"<!-- Generated by scripts/synccodehygiene_recipes.py; edit data/code-hygiene/catalog.json. --> A tool-agnostic recipe to remove channel ownership ambiguity, lock misuse, and data races. It supports a read-only audit and, when explicitly authorized, a narrow remediation. When to use it Use this recipe when the operator's specific objective is to remove channel ownership ambiguity, lock misuse, and data races. Prefer a narrower CVE, scanner-finding, security-audit, or compliance-evidence recipe when that is the operator's actual job. Inputs Repository root and the files, package, service, or module in scope. Requested mode: audit or explicitly authorized fix. Supported runtime, compiler, framework, operating-system, and deployment versions inferred from repository files. Existing formatter, compiler, analyzer, test, build, and package-manager commands. Public API, compatibility, performance, generated-code, vendor, and migration constraints. The prompt ~~~markdown You are running the Security Recipes code-hygiene workflow code-hygiene.go.go-channel-lock-and-shared-state-hygiene. Start read-only. Do not edit files until the operator explicitly authorizes a fix. Use repository configuration and installed tool versions as authoritative; do not impose a new style or toolchain. Scope Your bounded objective is to remove channel ownership ambiguity, lock misuse, and data races. Inspect only operator-scoped, first-party source and configuration. Exclude generated, vendored, minified, fixture snapshot, lock history, and migration history unless explicitly included. Detection Map shared variables, lock scopes, channel creators, senders, closers, and blocking operations. Use the race detector on representative concurrent paths. Record file and symbol evidence for every candidate. Mark uncertain or dynamically reachable behavior instead of guessing. Fix, only when authorized Assign one close owner, minimize shared mutation, and keep blocking or callback work outside locks. Keep the diff limited to the proven issue and its focused tests. Preserve public behavior, API compatibility, and repository conventions. Do not add or broaden suppressions, weaken diagnostics, mass-format unrelated files, upgrade dependencies, or mutate external state. Verification Run race-enabled focused tests plus cancellation, saturation, close, and shutdown cases. Compare diagnostic counts and relevant behavior before and after. Report every command, result, and check that could not run. Stop conditions Stop if lock or channel redesign requires changing ordering or throughput contracts. Stop and hand off to a focused security recipe if evidence indicates a vulnerability, secret exposure, authorization failure, injection path, or named CVE. Stop rather than widening scope when the safe result requires architecture, product, compliance, operational, or data-owner decisions. ~~~ Output contract Scope and repository evidence reviewed. A candidate table with file or symbol, evidence, confidence, and disposition. In audit mode: no edits, plus the smallest safe next action for each confirmed item. In fix mode: one bounded patch, focused regression coverage, and no unrelated cleanup. Commands run, results, remaining uncertainty, and any stop-condition handoff. Verification Run race-enabled focused tests plus cancellation, saturation, close, and shutdown cases. Confirm that diagnostic configuration, suppressions, public interfaces, generated files, vendored files, and dependencies did not change outside the authorized scope. Review the final diff for behavior changes and run the repository's focused checks before broader suites. Guardrails Read-only until edits are explicitly authorized. Do not deploy, publish, rotate secrets, alter cloud or database state, change CI permissions, or open external tickets. Do not hide debt by disabling rules, adding retries or sleeps, weakening tests, broadening ignores, or lowering warning levels. Treat generated, vendored, minified, migration-history, and fixture-snapshot files as out of scope unless explicitly named. Stop if lock or channel redesign requires changing ordering or throughput contracts. Related recipes Go vet and lint suppression debt Go error wrapping and sentinel contracts Browse all code-hygiene recipes References NIST SP 800-218 Secure Software Development Framework 1.1 — NIST Go command documentation - vet — Go project Go errors package — Go project Go context package — Go project Go data race detector — Go project","agent_handoff":{"mcp_lookup_keys":["go-channel-lock-and-shared-state-hygiene","/recipes/general/code-hygiene/go/go-channel-lock-and-shared-state-hygiene/","recipes/general/code-hygiene/go/go-channel-lock-and-shared-state-hygiene.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["code-hygiene","audit","remediation"],"source_text_field":"content_text","portable_download":"security-recipe-go-channel-lock-and-shared-state-hygiene.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-go-channel-lock-and-shared-state-hygiene.json"}},{"slug":"go-error-wrapping-and-sentinel-contracts","title":"Go error wrapping and sentinel contracts","link_title":"Go error wrapping and sentinel contracts","url":"https://security-recipes.ai/recipes/general/code-hygiene/go/go-error-wrapping-and-sentinel-contracts/","path":"/recipes/general/code-hygiene/go/go-error-wrapping-and-sentinel-contracts/","source_file":"recipes/general/code-hygiene/go/go-error-wrapping-and-sentinel-contracts.md","recipe_id":"code-hygiene.go.go-error-wrapping-and-sentinel-contracts","recipe_kind":"code-hygiene","category":{"slug":"code-hygiene","label":"Code Hygiene"},"agent":"general","severity":"unspecified","maturity":"development","ecosystem":"go/modules","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"","framework_version":"","jurisdiction":"","industry":[],"cve_archetypes":[],"cve_workflow_role":"","tags":["code-hygiene","go","errors","wrapping","sentinels"],"facets":["code-hygiene","audit","remediation"],"quality":{"score":100,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context","multi-facet"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"security-recipes.ai contributors","team":"Security Engineering","model":"gpt-5-codex","ai_assisted":false,"generated_by":"","date":"2026-08-21","zero_day":false,"last_updated":"2026-08-21","summary":"Go error wrapping and sentinel contracts: Preserve error identity and context without string matching or duplicate logging.","content_text":"<!-- Generated by scripts/synccodehygiene_recipes.py; edit data/code-hygiene/catalog.json. --> A tool-agnostic recipe to preserve error identity and context without string matching or duplicate logging. It supports a read-only audit and, when explicitly authorized, a narrow remediation. When to use it Use this recipe when the operator's specific objective is to preserve error identity and context without string matching or duplicate logging. Prefer a narrower CVE, scanner-finding, security-audit, or compliance-evidence recipe when that is the operator's actual job. Inputs Repository root and the files, package, service, or module in scope. Requested mode: audit or explicitly authorized fix. Supported runtime, compiler, framework, operating-system, and deployment versions inferred from repository files. Existing formatter, compiler, analyzer, test, build, and package-manager commands. Public API, compatibility, performance, generated-code, vendor, and migration constraints. The prompt ~~~markdown You are running the Security Recipes code-hygiene workflow code-hygiene.go.go-error-wrapping-and-sentinel-contracts. Start read-only. Do not edit files until the operator explicitly authorizes a fix. Use repository configuration and installed tool versions as authoritative; do not impose a new style or toolchain. Scope Your bounded objective is to preserve error identity and context without string matching or duplicate logging. Inspect only operator-scoped, first-party source and configuration. Exclude generated, vendored, minified, fixture snapshot, lock history, and migration history unless explicitly included. Detection Trace error creation, wrapping, comparison, type assertion, logging, and translation at API boundaries. Find formatting that drops identity and callers comparing error strings. Record file and symbol evidence for every candidate. Mark uncertain or dynamically reachable behavior instead of guessing. Fix, only when authorized Wrap with percent-w where identity is contractual and translate once at the owning boundary. Keep the diff limited to the proven issue and its focused tests. Preserve public behavior, API compatibility, and repository conventions. Do not add or broaden suppressions, weaken diagnostics, mass-format unrelated files, upgrade dependencies, or mutate external state. Verification Test errors.Is, errors.As, public status mapping, context, and absence of duplicate logs. Compare diagnostic counts and relevant behavior before and after. Report every command, result, and check that could not run. Stop conditions Stop if changing sentinel identity would break downstream callers. Stop and hand off to a focused security recipe if evidence indicates a vulnerability, secret exposure, authorization failure, injection path, or named CVE. Stop rather than widening scope when the safe result requires architecture, product, compliance, operational, or data-owner decisions. ~~~ Output contract Scope and repository evidence reviewed. A candidate table with file or symbol, evidence, confidence, and disposition. In audit mode: no edits, plus the smallest safe next action for each confirmed item. In fix mode: one bounded patch, focused regression coverage, and no unrelated cleanup. Commands run, results, remaining uncertainty, and any stop-condition handoff. Verification Test errors.Is, errors.As, public status mapping, context, and absence of duplicate logs. Confirm that diagnostic configuration, suppressions, public interfaces, generated files, vendored files, and dependencies did not change outside the authorized scope. Review the final diff for behavior changes and run the repository's focused checks before broader suites. Guardrails Read-only until edits are explicitly authorized. Do not deploy, publish, rotate secrets, alter cloud or database state, change CI permissions, or open external tickets. Do not hide debt by disabling rules, adding retries or sleeps, weakening tests, broadening ignores, or lowering warning levels. Treat generated, vendored, minified, migration-history, and fixture-snapshot files as out of scope unless explicitly named. Stop if changing sentinel identity would break downstream callers. Related recipes Go vet and lint suppression debt Go goroutine, context, cancellation, and leak hygiene Browse all code-hygiene recipes References NIST SP 800-218 Secure Software Development Framework 1.1 — NIST Go command documentation - vet — Go project Go errors package — Go project Go context package — Go project","agent_handoff":{"mcp_lookup_keys":["go-error-wrapping-and-sentinel-contracts","/recipes/general/code-hygiene/go/go-error-wrapping-and-sentinel-contracts/","recipes/general/code-hygiene/go/go-error-wrapping-and-sentinel-contracts.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["code-hygiene","audit","remediation"],"source_text_field":"content_text","portable_download":"security-recipe-go-error-wrapping-and-sentinel-contracts.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-go-error-wrapping-and-sentinel-contracts.json"}},{"slug":"go-goroutine-context-cancellation-and-leaks","title":"Go goroutine, context, cancellation, and leak hygiene","link_title":"Go goroutine, context, cancellation, and leak hygiene","url":"https://security-recipes.ai/recipes/general/code-hygiene/go/go-goroutine-context-cancellation-and-leaks/","path":"/recipes/general/code-hygiene/go/go-goroutine-context-cancellation-and-leaks/","source_file":"recipes/general/code-hygiene/go/go-goroutine-context-cancellation-and-leaks.md","recipe_id":"code-hygiene.go.go-goroutine-context-cancellation-and-leaks","recipe_kind":"code-hygiene","category":{"slug":"code-hygiene","label":"Code Hygiene"},"agent":"general","severity":"unspecified","maturity":"development","ecosystem":"go/modules","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"","framework_version":"","jurisdiction":"","industry":[],"cve_archetypes":[],"cve_workflow_role":"","tags":["code-hygiene","go","goroutines","context","cancellation"],"facets":["code-hygiene","audit","remediation"],"quality":{"score":100,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context","multi-facet"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"security-recipes.ai contributors","team":"Security Engineering","model":"gpt-5-codex","ai_assisted":false,"generated_by":"","date":"2026-08-21","zero_day":false,"last_updated":"2026-08-21","summary":"Go goroutine, context, cancellation, and leak hygiene: Give every goroutine and context a bounded owner and shutdown path.","content_text":"<!-- Generated by scripts/synccodehygiene_recipes.py; edit data/code-hygiene/catalog.json. --> A tool-agnostic recipe to give every goroutine and context a bounded owner and shutdown path. It supports a read-only audit and, when explicitly authorized, a narrow remediation. When to use it Use this recipe when the operator's specific objective is to give every goroutine and context a bounded owner and shutdown path. Prefer a narrower CVE, scanner-finding, security-audit, or compliance-evidence recipe when that is the operator's actual job. Inputs Repository root and the files, package, service, or module in scope. Requested mode: audit or explicitly authorized fix. Supported runtime, compiler, framework, operating-system, and deployment versions inferred from repository files. Existing formatter, compiler, analyzer, test, build, and package-manager commands. Public API, compatibility, performance, generated-code, vendor, and migration constraints. The prompt ~~~markdown You are running the Security Recipes code-hygiene workflow code-hygiene.go.go-goroutine-context-cancellation-and-leaks. Start read-only. Do not edit files until the operator explicitly authorizes a fix. Use repository configuration and installed tool versions as authoritative; do not impose a new style or toolchain. Scope Your bounded objective is to give every goroutine and context a bounded owner and shutdown path. Inspect only operator-scoped, first-party source and configuration. Exclude generated, vendored, minified, fixture snapshot, lock history, and migration history unless explicitly included. Detection Trace goroutine starts, context derivation, cancel calls, channel exits, timers, and WaitGroup or errgroup joins. Find contexts stored in structs and goroutines blocked after caller cancellation. Record file and symbol evidence for every candidate. Mark uncertain or dynamically reachable behavior instead of guessing. Fix, only when authorized Propagate context, defer cancellation at the creator, and join or deliberately supervise every goroutine. Keep the diff limited to the proven issue and its focused tests. Preserve public behavior, API compatibility, and repository conventions. Do not add or broaden suppressions, weaken diagnostics, mass-format unrelated files, upgrade dependencies, or mutate external state. Verification Run cancellation and shutdown tests, leak checks if configured, and the race detector where supported. Compare diagnostic counts and relevant behavior before and after. Report every command, result, and check that could not run. Stop conditions Stop if the goroutine is process-global without a documented supervisor or shutdown contract. Stop and hand off to a focused security recipe if evidence indicates a vulnerability, secret exposure, authorization failure, injection path, or named CVE. Stop rather than widening scope when the safe result requires architecture, product, compliance, operational, or data-owner decisions. ~~~ Output contract Scope and repository evidence reviewed. A candidate table with file or symbol, evidence, confidence, and disposition. In audit mode: no edits, plus the smallest safe next action for each confirmed item. In fix mode: one bounded patch, focused regression coverage, and no unrelated cleanup. Commands run, results, remaining uncertainty, and any stop-condition handoff. Verification Run cancellation and shutdown tests, leak checks if configured, and the race detector where supported. Confirm that diagnostic configuration, suppressions, public interfaces, generated files, vendored files, and dependencies did not change outside the authorized scope. Review the final diff for behavior changes and run the repository's focused checks before broader suites. Guardrails Read-only until edits are explicitly authorized. Do not deploy, publish, rotate secrets, alter cloud or database state, change CI permissions, or open external tickets. Do not hide debt by disabling rules, adding retries or sleeps, weakening tests, broadening ignores, or lowering warning levels. Treat generated, vendored, minified, migration-history, and fixture-snapshot files as out of scope unless explicitly named. Stop if the goroutine is process-global without a documented supervisor or shutdown contract. Related recipes Go vet and lint suppression debt Go error wrapping and sentinel contracts Browse all code-hygiene recipes References NIST SP 800-218 Secure Software Development Framework 1.1 — NIST Go command documentation - vet — Go project Go errors package — Go project Go context package — Go project Go data race detector — Go project","agent_handoff":{"mcp_lookup_keys":["go-goroutine-context-cancellation-and-leaks","/recipes/general/code-hygiene/go/go-goroutine-context-cancellation-and-leaks/","recipes/general/code-hygiene/go/go-goroutine-context-cancellation-and-leaks.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["code-hygiene","audit","remediation"],"source_text_field":"content_text","portable_download":"security-recipe-go-goroutine-context-cancellation-and-leaks.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-go-goroutine-context-cancellation-and-leaks.json"}},{"slug":"go-vet-and-lint-suppression-debt","title":"Go vet and lint suppression debt","link_title":"Go vet and lint suppression debt","url":"https://security-recipes.ai/recipes/general/code-hygiene/go/go-vet-and-lint-suppression-debt/","path":"/recipes/general/code-hygiene/go/go-vet-and-lint-suppression-debt/","source_file":"recipes/general/code-hygiene/go/go-vet-and-lint-suppression-debt.md","recipe_id":"code-hygiene.go.go-vet-and-lint-suppression-debt","recipe_kind":"code-hygiene","category":{"slug":"code-hygiene","label":"Code Hygiene"},"agent":"general","severity":"unspecified","maturity":"development","ecosystem":"go/modules","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"","framework_version":"","jurisdiction":"","industry":[],"cve_archetypes":[],"cve_workflow_role":"","tags":["code-hygiene","go","vet","lint","nolint"],"facets":["code-hygiene","audit","remediation"],"quality":{"score":100,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context","multi-facet"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"security-recipes.ai contributors","team":"Security Engineering","model":"gpt-5-codex","ai_assisted":false,"generated_by":"","date":"2026-08-21","zero_day":false,"last_updated":"2026-08-21","summary":"Go vet and lint suppression debt: Resolve Go diagnostics and narrow nolint directives. Includes scoped detection, verification, and stop conditions.","content_text":"<!-- Generated by scripts/synccodehygiene_recipes.py; edit data/code-hygiene/catalog.json. --> A tool-agnostic recipe to resolve Go diagnostics and narrow nolint directives. It supports a read-only audit and, when explicitly authorized, a narrow remediation. When to use it Use this recipe when the operator's specific objective is to resolve Go diagnostics and narrow nolint directives. Prefer a narrower CVE, scanner-finding, security-audit, or compliance-evidence recipe when that is the operator's actual job. Inputs Repository root and the files, package, service, or module in scope. Requested mode: audit or explicitly authorized fix. Supported runtime, compiler, framework, operating-system, and deployment versions inferred from repository files. Existing formatter, compiler, analyzer, test, build, and package-manager commands. Public API, compatibility, performance, generated-code, vendor, and migration constraints. The prompt ~~~markdown You are running the Security Recipes code-hygiene workflow code-hygiene.go.go-vet-and-lint-suppression-debt. Start read-only. Do not edit files until the operator explicitly authorizes a fix. Use repository configuration and installed tool versions as authoritative; do not impose a new style or toolchain. Scope Your bounded objective is to resolve Go diagnostics and narrow nolint directives. Inspect only operator-scoped, first-party source and configuration. Exclude generated, vendored, minified, fixture snapshot, lock history, and migration history unless explicitly included. Detection Read module, workspace, build-tag, vet, and configured linter settings and inventory nolint directives. Run diagnostics across relevant tags, platforms, and test packages. Record file and symbol evidence for every candidate. Mark uncertain or dynamically reachable behavior instead of guessing. Fix, only when authorized Correct owned diagnostics and require a specific rule and rationale for unavoidable suppressions. Keep the diff limited to the proven issue and its focused tests. Preserve public behavior, API compatibility, and repository conventions. Do not add or broaden suppressions, weaken diagnostics, mass-format unrelated files, upgrade dependencies, or mutate external state. Verification Run gofmt checks, go vet, configured linters, go test, and tagged builds. Compare diagnostic counts and relevant behavior before and after. Report every command, result, and check that could not run. Stop conditions Stop if a diagnostic is generated code, platform-specific by design, or requires an API compatibility decision. Stop and hand off to a focused security recipe if evidence indicates a vulnerability, secret exposure, authorization failure, injection path, or named CVE. Stop rather than widening scope when the safe result requires architecture, product, compliance, operational, or data-owner decisions. ~~~ Output contract Scope and repository evidence reviewed. A candidate table with file or symbol, evidence, confidence, and disposition. In audit mode: no edits, plus the smallest safe next action for each confirmed item. In fix mode: one bounded patch, focused regression coverage, and no unrelated cleanup. Commands run, results, remaining uncertainty, and any stop-condition handoff. Verification Run gofmt checks, go vet, configured linters, go test, and tagged builds. Confirm that diagnostic configuration, suppressions, public interfaces, generated files, vendored files, and dependencies did not change outside the authorized scope. Review the final diff for behavior changes and run the repository's focused checks before broader suites. Guardrails Read-only until edits are explicitly authorized. Do not deploy, publish, rotate secrets, alter cloud or database state, change CI permissions, or open external tickets. Do not hide debt by disabling rules, adding retries or sleeps, weakening tests, broadening ignores, or lowering warning levels. Treat generated, vendored, minified, migration-history, and fixture-snapshot files as out of scope unless explicitly named. Stop if a diagnostic is generated code, platform-specific by design, or requires an API compatibility decision. Related recipes Go error wrapping and sentinel contracts Go goroutine, context, cancellation, and leak hygiene Browse all code-hygiene recipes References NIST SP 800-218 Secure Software Development Framework 1.1 — NIST Go command documentation - vet — Go project Go errors package — Go project Go context package — Go project","agent_handoff":{"mcp_lookup_keys":["go-vet-and-lint-suppression-debt","/recipes/general/code-hygiene/go/go-vet-and-lint-suppression-debt/","recipes/general/code-hygiene/go/go-vet-and-lint-suppression-debt.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["code-hygiene","audit","remediation"],"source_text_field":"content_text","portable_download":"security-recipe-go-vet-and-lint-suppression-debt.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-go-vet-and-lint-suppression-debt.json"}},{"slug":"javascript-module-cycles-side-effects-and-unused-exports","title":"JavaScript module cycles, side effects, and unused exports","link_title":"JavaScript module cycles, side effects, and unused exports","url":"https://security-recipes.ai/recipes/general/code-hygiene/javascript-typescript/javascript-module-cycles-side-effects-and-unused-exports/","path":"/recipes/general/code-hygiene/javascript-typescript/javascript-module-cycles-side-effects-and-unused-exports/","source_file":"recipes/general/code-hygiene/javascript-typescript/javascript-module-cycles-side-effects-and-unused-exports.md","recipe_id":"code-hygiene.javascript-typescript.javascript-module-cycles-side-effects-and-unused-exports","recipe_kind":"code-hygiene","category":{"slug":"code-hygiene","label":"Code Hygiene"},"agent":"general","severity":"unspecified","maturity":"development","ecosystem":"javascript-typescript/npm","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"","framework_version":"","jurisdiction":"","industry":[],"cve_archetypes":[],"cve_workflow_role":"","tags":["code-hygiene","javascript-typescript","javascript","modules","cycles","exports"],"facets":["code-hygiene","audit","remediation"],"quality":{"score":100,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context","multi-facet"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"security-recipes.ai contributors","team":"Security Engineering","model":"gpt-5-codex","ai_assisted":false,"generated_by":"","date":"2026-08-21","zero_day":false,"last_updated":"2026-08-21","summary":"JavaScript module cycles, side effects, and unused exports: Make module initialization order and public exports predictable.","content_text":"<!-- Generated by scripts/synccodehygiene_recipes.py; edit data/code-hygiene/catalog.json. --> A tool-agnostic recipe to make module initialization order and public exports predictable. It supports a read-only audit and, when explicitly authorized, a narrow remediation. When to use it Use this recipe when the operator's specific objective is to make module initialization order and public exports predictable. Prefer a narrower CVE, scanner-finding, security-audit, or compliance-evidence recipe when that is the operator's actual job. Inputs Repository root and the files, package, service, or module in scope. Requested mode: audit or explicitly authorized fix. Supported runtime, compiler, framework, operating-system, and deployment versions inferred from repository files. Existing formatter, compiler, analyzer, test, build, and package-manager commands. Public API, compatibility, performance, generated-code, vendor, and migration constraints. The prompt ~~~markdown You are running the Security Recipes code-hygiene workflow code-hygiene.javascript-typescript.javascript-module-cycles-side-effects-and-unused-exports. Start read-only. Do not edit files until the operator explicitly authorizes a fix. Use repository configuration and installed tool versions as authoritative; do not impose a new style or toolchain. Scope Your bounded objective is to make module initialization order and public exports predictable. Inspect only operator-scoped, first-party source and configuration. Exclude generated, vendored, minified, fixture snapshot, lock history, and migration history unless explicitly included. Detection Build the import graph and inspect cycles, barrel files, side-effect imports, package exports, and unused symbols. Distinguish runtime registration imports from accidental side effects. Record file and symbol evidence for every candidate. Mark uncertain or dynamically reachable behavior instead of guessing. Fix, only when authorized Break cycles at a stable dependency boundary and remove only exports proven private and unused. Keep the diff limited to the proven issue and its focused tests. Preserve public behavior, API compatibility, and repository conventions. Do not add or broaden suppressions, weaken diagnostics, mass-format unrelated files, upgrade dependencies, or mutate external state. Verification Run builds in supported module modes and test startup, tree-shaking, and package import paths. Compare diagnostic counts and relevant behavior before and after. Report every command, result, and check that could not run. Stop conditions Stop on plugin registration, bundler-specific behavior, or public package exports without compatibility evidence. Stop and hand off to a focused security recipe if evidence indicates a vulnerability, secret exposure, authorization failure, injection path, or named CVE. Stop rather than widening scope when the safe result requires architecture, product, compliance, operational, or data-owner decisions. ~~~ Output contract Scope and repository evidence reviewed. A candidate table with file or symbol, evidence, confidence, and disposition. In audit mode: no edits, plus the smallest safe next action for each confirmed item. In fix mode: one bounded patch, focused regression coverage, and no unrelated cleanup. Commands run, results, remaining uncertainty, and any stop-condition handoff. Verification Run builds in supported module modes and test startup, tree-shaking, and package import paths. Confirm that diagnostic configuration, suppressions, public interfaces, generated files, vendored files, and dependencies did not change outside the authorized scope. Review the final diff for behavior changes and run the repository's focused checks before broader suites. Guardrails Read-only until edits are explicitly authorized. Do not deploy, publish, rotate secrets, alter cloud or database state, change CI permissions, or open external tickets. Do not hide debt by disabling rules, adding retries or sleeps, weakening tests, broadening ignores, or lowering warning levels. Treat generated, vendored, minified, migration-history, and fixture-snapshot files as out of scope unless explicitly named. Stop on plugin registration, bundler-specific behavior, or public package exports without compatibility evidence. Related recipes TypeScript strictness and escape-hatch debt JavaScript promise, abort, and listener lifecycle Browse all code-hygiene recipes References NIST SP 800-218 Secure Software Development Framework 1.1 — NIST TypeScript TSConfig reference — Microsoft TypeScript ESLint bulk suppressions — ESLint Node.js events API — OpenJS Foundation","agent_handoff":{"mcp_lookup_keys":["javascript-module-cycles-side-effects-and-unused-exports","/recipes/general/code-hygiene/javascript-typescript/javascript-module-cycles-side-effects-and-unused-exports/","recipes/general/code-hygiene/javascript-typescript/javascript-module-cycles-side-effects-and-unused-exports.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["code-hygiene","audit","remediation"],"source_text_field":"content_text","portable_download":"security-recipe-javascript-module-cycles-side-effects-and-unused-exports.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-javascript-module-cycles-side-effects-and-unused-exports.json"}},{"slug":"javascript-promise-abort-and-listener-lifecycle","title":"JavaScript promise, abort, and listener lifecycle","link_title":"JavaScript promise, abort, and listener lifecycle","url":"https://security-recipes.ai/recipes/general/code-hygiene/javascript-typescript/javascript-promise-abort-and-listener-lifecycle/","path":"/recipes/general/code-hygiene/javascript-typescript/javascript-promise-abort-and-listener-lifecycle/","source_file":"recipes/general/code-hygiene/javascript-typescript/javascript-promise-abort-and-listener-lifecycle.md","recipe_id":"code-hygiene.javascript-typescript.javascript-promise-abort-and-listener-lifecycle","recipe_kind":"code-hygiene","category":{"slug":"code-hygiene","label":"Code Hygiene"},"agent":"general","severity":"unspecified","maturity":"development","ecosystem":"javascript-typescript/npm","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"","framework_version":"","jurisdiction":"","industry":[],"cve_archetypes":[],"cve_workflow_role":"","tags":["code-hygiene","javascript-typescript","javascript","promises","abortcontroller","listeners"],"facets":["code-hygiene","audit","remediation"],"quality":{"score":100,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context","multi-facet"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"security-recipes.ai contributors","team":"Security Engineering","model":"gpt-5-codex","ai_assisted":false,"generated_by":"","date":"2026-08-21","zero_day":false,"last_updated":"2026-08-21","summary":"JavaScript promise, abort, and listener lifecycle: Close floating promises, lost failures, uncancelled work, and leaked event listeners.","content_text":"<!-- Generated by scripts/synccodehygiene_recipes.py; edit data/code-hygiene/catalog.json. --> A tool-agnostic recipe to close floating promises, lost failures, uncancelled work, and leaked event listeners. It supports a read-only audit and, when explicitly authorized, a narrow remediation. When to use it Use this recipe when the operator's specific objective is to close floating promises, lost failures, uncancelled work, and leaked event listeners. Prefer a narrower CVE, scanner-finding, security-audit, or compliance-evidence recipe when that is the operator's actual job. Inputs Repository root and the files, package, service, or module in scope. Requested mode: audit or explicitly authorized fix. Supported runtime, compiler, framework, operating-system, and deployment versions inferred from repository files. Existing formatter, compiler, analyzer, test, build, and package-manager commands. Public API, compatibility, performance, generated-code, vendor, and migration constraints. The prompt ~~~markdown You are running the Security Recipes code-hygiene workflow code-hygiene.javascript-typescript.javascript-promise-abort-and-listener-lifecycle. Start read-only. Do not edit files until the operator explicitly authorizes a fix. Use repository configuration and installed tool versions as authoritative; do not impose a new style or toolchain. Scope Your bounded objective is to close floating promises, lost failures, uncancelled work, and leaked event listeners. Inspect only operator-scoped, first-party source and configuration. Exclude generated, vendored, minified, fixture snapshot, lock history, and migration history unless explicitly included. Detection Trace promise creation, awaiting, rejection ownership, AbortSignal propagation, and listener registration/removal. Find fire-and-forget work without an explicit owner or terminal error handler. Record file and symbol evidence for every candidate. Mark uncertain or dynamically reachable behavior instead of guessing. Fix, only when authorized Attach work to an owning lifecycle, propagate cancellation, and pair every listener with deterministic cleanup. Keep the diff limited to the proven issue and its focused tests. Preserve public behavior, API compatibility, and repository conventions. Do not add or broaden suppressions, weaken diagnostics, mass-format unrelated files, upgrade dependencies, or mutate external state. Verification Test success, rejection, cancellation, timeout, teardown, and repeated mount or invocation paths. Compare diagnostic counts and relevant behavior before and after. Report every command, result, and check that could not run. Stop conditions Stop if changing concurrency or event ordering could affect external protocols without characterization tests. Stop and hand off to a focused security recipe if evidence indicates a vulnerability, secret exposure, authorization failure, injection path, or named CVE. Stop rather than widening scope when the safe result requires architecture, product, compliance, operational, or data-owner decisions. ~~~ Output contract Scope and repository evidence reviewed. A candidate table with file or symbol, evidence, confidence, and disposition. In audit mode: no edits, plus the smallest safe next action for each confirmed item. In fix mode: one bounded patch, focused regression coverage, and no unrelated cleanup. Commands run, results, remaining uncertainty, and any stop-condition handoff. Verification Test success, rejection, cancellation, timeout, teardown, and repeated mount or invocation paths. Confirm that diagnostic configuration, suppressions, public interfaces, generated files, vendored files, and dependencies did not change outside the authorized scope. Review the final diff for behavior changes and run the repository's focused checks before broader suites. Guardrails Read-only until edits are explicitly authorized. Do not deploy, publish, rotate secrets, alter cloud or database state, change CI permissions, or open external tickets. Do not hide debt by disabling rules, adding retries or sleeps, weakening tests, broadening ignores, or lowering warning levels. Treat generated, vendored, minified, migration-history, and fixture-snapshot files as out of scope unless explicitly named. Stop if changing concurrency or event ordering could affect external protocols without characterization tests. Related recipes TypeScript strictness and escape-hatch debt JavaScript module cycles, side effects, and unused exports Browse all code-hygiene recipes References NIST SP 800-218 Secure Software Development Framework 1.1 — NIST TypeScript TSConfig reference — Microsoft TypeScript ESLint bulk suppressions — ESLint Node.js events API — OpenJS Foundation","agent_handoff":{"mcp_lookup_keys":["javascript-promise-abort-and-listener-lifecycle","/recipes/general/code-hygiene/javascript-typescript/javascript-promise-abort-and-listener-lifecycle/","recipes/general/code-hygiene/javascript-typescript/javascript-promise-abort-and-listener-lifecycle.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["code-hygiene","audit","remediation"],"source_text_field":"content_text","portable_download":"security-recipe-javascript-promise-abort-and-listener-lifecycle.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-javascript-promise-abort-and-listener-lifecycle.json"}},{"slug":"node-stream-emitter-and-handle-lifecycle","title":"Node.js stream, emitter, and handle lifecycle","link_title":"Node.js stream, emitter, and handle lifecycle","url":"https://security-recipes.ai/recipes/general/code-hygiene/javascript-typescript/node-stream-emitter-and-handle-lifecycle/","path":"/recipes/general/code-hygiene/javascript-typescript/node-stream-emitter-and-handle-lifecycle/","source_file":"recipes/general/code-hygiene/javascript-typescript/node-stream-emitter-and-handle-lifecycle.md","recipe_id":"code-hygiene.javascript-typescript.node-stream-emitter-and-handle-lifecycle","recipe_kind":"code-hygiene","category":{"slug":"code-hygiene","label":"Code Hygiene"},"agent":"general","severity":"unspecified","maturity":"development","ecosystem":"javascript-typescript/npm","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"","framework_version":"","jurisdiction":"","industry":[],"cve_archetypes":[],"cve_workflow_role":"","tags":["code-hygiene","javascript-typescript","nodejs","streams","eventemitter","handles"],"facets":["code-hygiene","audit","remediation"],"quality":{"score":100,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context","multi-facet"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"security-recipes.ai contributors","team":"Security Engineering","model":"gpt-5-codex","ai_assisted":false,"generated_by":"","date":"2026-08-21","zero_day":false,"last_updated":"2026-08-21","summary":"Node.js stream, emitter, and handle lifecycle: Prevent stream stalls, duplicate listeners, and handles that keep processes alive.","content_text":"<!-- Generated by scripts/synccodehygiene_recipes.py; edit data/code-hygiene/catalog.json. --> A tool-agnostic recipe to prevent stream stalls, duplicate listeners, and handles that keep processes alive. It supports a read-only audit and, when explicitly authorized, a narrow remediation. When to use it Use this recipe when the operator's specific objective is to prevent stream stalls, duplicate listeners, and handles that keep processes alive. Prefer a narrower CVE, scanner-finding, security-audit, or compliance-evidence recipe when that is the operator's actual job. Inputs Repository root and the files, package, service, or module in scope. Requested mode: audit or explicitly authorized fix. Supported runtime, compiler, framework, operating-system, and deployment versions inferred from repository files. Existing formatter, compiler, analyzer, test, build, and package-manager commands. Public API, compatibility, performance, generated-code, vendor, and migration constraints. The prompt ~~~markdown You are running the Security Recipes code-hygiene workflow code-hygiene.javascript-typescript.node-stream-emitter-and-handle-lifecycle. Start read-only. Do not edit files until the operator explicitly authorizes a fix. Use repository configuration and installed tool versions as authoritative; do not impose a new style or toolchain. Scope Your bounded objective is to prevent stream stalls, duplicate listeners, and handles that keep processes alive. Inspect only operator-scoped, first-party source and configuration. Exclude generated, vendored, minified, fixture snapshot, lock history, and migration history unless explicitly included. Detection Trace stream backpressure, pipeline errors, listener counts, timers, sockets, and handle close ownership. Find manual pipe chains and emitter listeners without terminal cleanup. Record file and symbol evidence for every candidate. Mark uncertain or dynamically reachable behavior instead of guessing. Fix, only when authorized Use lifecycle-aware stream composition and close, unref, or unsubscribe handles at the owning boundary. Keep the diff limited to the proven issue and its focused tests. Preserve public behavior, API compatibility, and repository conventions. Do not add or broaden suppressions, weaken diagnostics, mass-format unrelated files, upgrade dependencies, or mutate external state. Verification Test partial reads, errors, aborts, slow consumers, repeated startup, and clean process termination. Compare diagnostic counts and relevant behavior before and after. Report every command, result, and check that could not run. Stop conditions Stop if changing buffering or event ordering could violate a protocol or throughput requirement. Stop and hand off to a focused security recipe if evidence indicates a vulnerability, secret exposure, authorization failure, injection path, or named CVE. Stop rather than widening scope when the safe result requires architecture, product, compliance, operational, or data-owner decisions. ~~~ Output contract Scope and repository evidence reviewed. A candidate table with file or symbol, evidence, confidence, and disposition. In audit mode: no edits, plus the smallest safe next action for each confirmed item. In fix mode: one bounded patch, focused regression coverage, and no unrelated cleanup. Commands run, results, remaining uncertainty, and any stop-condition handoff. Verification Test partial reads, errors, aborts, slow consumers, repeated startup, and clean process termination. Confirm that diagnostic configuration, suppressions, public interfaces, generated files, vendored files, and dependencies did not change outside the authorized scope. Review the final diff for behavior changes and run the repository's focused checks before broader suites. Guardrails Read-only until edits are explicitly authorized. Do not deploy, publish, rotate secrets, alter cloud or database state, change CI permissions, or open external tickets. Do not hide debt by disabling rules, adding retries or sleeps, weakening tests, broadening ignores, or lowering warning levels. Treat generated, vendored, minified, migration-history, and fixture-snapshot files as out of scope unless explicitly named. Stop if changing buffering or event ordering could violate a protocol or throughput requirement. Related recipes TypeScript strictness and escape-hatch debt JavaScript promise, abort, and listener lifecycle Browse all code-hygiene recipes References NIST SP 800-218 Secure Software Development Framework 1.1 — NIST TypeScript TSConfig reference — Microsoft TypeScript ESLint bulk suppressions — ESLint Node.js events API — OpenJS Foundation Node.js streams API — OpenJS Foundation","agent_handoff":{"mcp_lookup_keys":["node-stream-emitter-and-handle-lifecycle","/recipes/general/code-hygiene/javascript-typescript/node-stream-emitter-and-handle-lifecycle/","recipes/general/code-hygiene/javascript-typescript/node-stream-emitter-and-handle-lifecycle.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["code-hygiene","audit","remediation"],"source_text_field":"content_text","portable_download":"security-recipe-node-stream-emitter-and-handle-lifecycle.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-node-stream-emitter-and-handle-lifecycle.json"}},{"slug":"react-hook-effect-and-state-lifecycle","title":"React hook, effect, and state lifecycle","link_title":"React hook, effect, and state lifecycle","url":"https://security-recipes.ai/recipes/general/code-hygiene/javascript-typescript/react-hook-effect-and-state-lifecycle/","path":"/recipes/general/code-hygiene/javascript-typescript/react-hook-effect-and-state-lifecycle/","source_file":"recipes/general/code-hygiene/javascript-typescript/react-hook-effect-and-state-lifecycle.md","recipe_id":"code-hygiene.javascript-typescript.react-hook-effect-and-state-lifecycle","recipe_kind":"code-hygiene","category":{"slug":"code-hygiene","label":"Code Hygiene"},"agent":"general","severity":"unspecified","maturity":"development","ecosystem":"javascript-typescript/npm","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"","framework_version":"","jurisdiction":"","industry":[],"cve_archetypes":[],"cve_workflow_role":"","tags":["code-hygiene","javascript-typescript","react","hooks","effects","state"],"facets":["code-hygiene","audit","remediation"],"quality":{"score":100,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context","multi-facet"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"security-recipes.ai contributors","team":"Security Engineering","model":"gpt-5-codex","ai_assisted":false,"generated_by":"","date":"2026-08-21","zero_day":false,"last_updated":"2026-08-21","summary":"React hook, effect, and state lifecycle: Remove stale closures, redundant state, and effect cleanup defects.","content_text":"<!-- Generated by scripts/synccodehygiene_recipes.py; edit data/code-hygiene/catalog.json. --> A tool-agnostic recipe to remove stale closures, redundant state, and effect cleanup defects. It supports a read-only audit and, when explicitly authorized, a narrow remediation. When to use it Use this recipe when the operator's specific objective is to remove stale closures, redundant state, and effect cleanup defects. Prefer a narrower CVE, scanner-finding, security-audit, or compliance-evidence recipe when that is the operator's actual job. Inputs Repository root and the files, package, service, or module in scope. Requested mode: audit or explicitly authorized fix. Supported runtime, compiler, framework, operating-system, and deployment versions inferred from repository files. Existing formatter, compiler, analyzer, test, build, and package-manager commands. Public API, compatibility, performance, generated-code, vendor, and migration constraints. The prompt ~~~markdown You are running the Security Recipes code-hygiene workflow code-hygiene.javascript-typescript.react-hook-effect-and-state-lifecycle. Start read-only. Do not edit files until the operator explicitly authorizes a fix. Use repository configuration and installed tool versions as authoritative; do not impose a new style or toolchain. Scope Your bounded objective is to remove stale closures, redundant state, and effect cleanup defects. Inspect only operator-scoped, first-party source and configuration. Exclude generated, vendored, minified, fixture snapshot, lock history, and migration history unless explicitly included. Detection Inspect dependency arrays, derived state, effect ownership, subscriptions, async work, and Strict Mode behavior. Separate event-driven work from synchronization effects. Record file and symbol evidence for every candidate. Mark uncertain or dynamically reachable behavior instead of guessing. Fix, only when authorized Move logic to render or events where appropriate and give remaining effects symmetric setup and cleanup. Keep the diff limited to the proven issue and its focused tests. Preserve public behavior, API compatibility, and repository conventions. Do not add or broaden suppressions, weaken diagnostics, mass-format unrelated files, upgrade dependencies, or mutate external state. Verification Test remount, dependency change, cancellation, Strict Mode development behavior, and user-visible state. Compare diagnostic counts and relevant behavior before and after. Report every command, result, and check that could not run. Stop conditions Stop if changing state ownership requires product or component API redesign. Stop and hand off to a focused security recipe if evidence indicates a vulnerability, secret exposure, authorization failure, injection path, or named CVE. Stop rather than widening scope when the safe result requires architecture, product, compliance, operational, or data-owner decisions. ~~~ Output contract Scope and repository evidence reviewed. A candidate table with file or symbol, evidence, confidence, and disposition. In audit mode: no edits, plus the smallest safe next action for each confirmed item. In fix mode: one bounded patch, focused regression coverage, and no unrelated cleanup. Commands run, results, remaining uncertainty, and any stop-condition handoff. Verification Test remount, dependency change, cancellation, Strict Mode development behavior, and user-visible state. Confirm that diagnostic configuration, suppressions, public interfaces, generated files, vendored files, and dependencies did not change outside the authorized scope. Review the final diff for behavior changes and run the repository's focused checks before broader suites. Guardrails Read-only until edits are explicitly authorized. Do not deploy, publish, rotate secrets, alter cloud or database state, change CI permissions, or open external tickets. Do not hide debt by disabling rules, adding retries or sleeps, weakening tests, broadening ignores, or lowering warning levels. Treat generated, vendored, minified, migration-history, and fixture-snapshot files as out of scope unless explicitly named. Stop if changing state ownership requires product or component API redesign. Related recipes TypeScript strictness and escape-hatch debt JavaScript promise, abort, and listener lifecycle Browse all code-hygiene recipes References NIST SP 800-218 Secure Software Development Framework 1.1 — NIST TypeScript TSConfig reference — Microsoft TypeScript ESLint bulk suppressions — ESLint Node.js events API — OpenJS Foundation React synchronizing with effects — React","agent_handoff":{"mcp_lookup_keys":["react-hook-effect-and-state-lifecycle","/recipes/general/code-hygiene/javascript-typescript/react-hook-effect-and-state-lifecycle/","recipes/general/code-hygiene/javascript-typescript/react-hook-effect-and-state-lifecycle.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["code-hygiene","audit","remediation"],"source_text_field":"content_text","portable_download":"security-recipe-react-hook-effect-and-state-lifecycle.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-react-hook-effect-and-state-lifecycle.json"}},{"slug":"typescript-strictness-and-escape-hatches","title":"TypeScript strictness and escape-hatch debt","link_title":"TypeScript strictness and escape-hatch debt","url":"https://security-recipes.ai/recipes/general/code-hygiene/javascript-typescript/typescript-strictness-and-escape-hatches/","path":"/recipes/general/code-hygiene/javascript-typescript/typescript-strictness-and-escape-hatches/","source_file":"recipes/general/code-hygiene/javascript-typescript/typescript-strictness-and-escape-hatches.md","recipe_id":"code-hygiene.javascript-typescript.typescript-strictness-and-escape-hatches","recipe_kind":"code-hygiene","category":{"slug":"code-hygiene","label":"Code Hygiene"},"agent":"general","severity":"unspecified","maturity":"development","ecosystem":"javascript-typescript/npm","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"","framework_version":"","jurisdiction":"","industry":[],"cve_archetypes":[],"cve_workflow_role":"","tags":["code-hygiene","javascript-typescript","typescript","strict","any","ts-ignore"],"facets":["code-hygiene","audit","remediation"],"quality":{"score":100,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context","multi-facet"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"security-recipes.ai contributors","team":"Security Engineering","model":"gpt-5-codex","ai_assisted":false,"generated_by":"","date":"2026-08-21","zero_day":false,"last_updated":"2026-08-21","summary":"TypeScript strictness and escape-hatch debt: Reduce unsafe any, ignore directives, assertions, and disabled strict checks incrementally.","content_text":"<!-- Generated by scripts/synccodehygiene_recipes.py; edit data/code-hygiene/catalog.json. --> A tool-agnostic recipe to reduce unsafe any, ignore directives, assertions, and disabled strict checks incrementally. It supports a read-only audit and, when explicitly authorized, a narrow remediation. When to use it Use this recipe when the operator's specific objective is to reduce unsafe any, ignore directives, assertions, and disabled strict checks incrementally. Prefer a narrower CVE, scanner-finding, security-audit, or compliance-evidence recipe when that is the operator's actual job. Inputs Repository root and the files, package, service, or module in scope. Requested mode: audit or explicitly authorized fix. Supported runtime, compiler, framework, operating-system, and deployment versions inferred from repository files. Existing formatter, compiler, analyzer, test, build, and package-manager commands. Public API, compatibility, performance, generated-code, vendor, and migration constraints. The prompt ~~~markdown You are running the Security Recipes code-hygiene workflow code-hygiene.javascript-typescript.typescript-strictness-and-escape-hatches. Start read-only. Do not edit files until the operator explicitly authorizes a fix. Use repository configuration and installed tool versions as authoritative; do not impose a new style or toolchain. Scope Your bounded objective is to reduce unsafe any, ignore directives, assertions, and disabled strict checks incrementally. Inspect only operator-scoped, first-party source and configuration. Exclude generated, vendored, minified, fixture snapshot, lock history, and migration history unless explicitly included. Detection Read the effective tsconfig graph and inventory any, unknown casts, non-null assertions, and ignore directives. Group diagnostics by boundary so generated declarations and external types remain separate. Record file and symbol evidence for every candidate. Mark uncertain or dynamically reachable behavior instead of guessing. Fix, only when authorized Replace escape hatches with narrowed types, guards, or explicit boundary adapters without broad config changes. Keep the diff limited to the proven issue and its focused tests. Preserve public behavior, API compatibility, and repository conventions. Do not add or broaden suppressions, weaken diagnostics, mass-format unrelated files, upgrade dependencies, or mutate external state. Verification Run the repository's exact TypeScript build and type-test commands with no new suppressions. Compare diagnostic counts and relevant behavior before and after. Report every command, result, and check that could not run. Stop conditions Stop if strictness changes would alter emitted code, public declarations, or unsupported consumers. Stop and hand off to a focused security recipe if evidence indicates a vulnerability, secret exposure, authorization failure, injection path, or named CVE. Stop rather than widening scope when the safe result requires architecture, product, compliance, operational, or data-owner decisions. ~~~ Output contract Scope and repository evidence reviewed. A candidate table with file or symbol, evidence, confidence, and disposition. In audit mode: no edits, plus the smallest safe next action for each confirmed item. In fix mode: one bounded patch, focused regression coverage, and no unrelated cleanup. Commands run, results, remaining uncertainty, and any stop-condition handoff. Verification Run the repository's exact TypeScript build and type-test commands with no new suppressions. Confirm that diagnostic configuration, suppressions, public interfaces, generated files, vendored files, and dependencies did not change outside the authorized scope. Review the final diff for behavior changes and run the repository's focused checks before broader suites. Guardrails Read-only until edits are explicitly authorized. Do not deploy, publish, rotate secrets, alter cloud or database state, change CI permissions, or open external tickets. Do not hide debt by disabling rules, adding retries or sleeps, weakening tests, broadening ignores, or lowering warning levels. Treat generated, vendored, minified, migration-history, and fixture-snapshot files as out of scope unless explicitly named. Stop if strictness changes would alter emitted code, public declarations, or unsupported consumers. Related recipes JavaScript promise, abort, and listener lifecycle JavaScript module cycles, side effects, and unused exports Browse all code-hygiene recipes References NIST SP 800-218 Secure Software Development Framework 1.1 — NIST TypeScript TSConfig reference — Microsoft TypeScript ESLint bulk suppressions — ESLint Node.js events API — OpenJS Foundation","agent_handoff":{"mcp_lookup_keys":["typescript-strictness-and-escape-hatches","/recipes/general/code-hygiene/javascript-typescript/typescript-strictness-and-escape-hatches/","recipes/general/code-hygiene/javascript-typescript/typescript-strictness-and-escape-hatches.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["code-hygiene","audit","remediation"],"source_text_field":"content_text","portable_download":"security-recipe-typescript-strictness-and-escape-hatches.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-typescript-strictness-and-escape-hatches.json"}},{"slug":"java-autocloseable-and-resource-lifecycle","title":"Java AutoCloseable and resource lifecycle","link_title":"Java AutoCloseable and resource lifecycle","url":"https://security-recipes.ai/recipes/general/code-hygiene/jvm/java-autocloseable-and-resource-lifecycle/","path":"/recipes/general/code-hygiene/jvm/java-autocloseable-and-resource-lifecycle/","source_file":"recipes/general/code-hygiene/jvm/java-autocloseable-and-resource-lifecycle.md","recipe_id":"code-hygiene.jvm.java-autocloseable-and-resource-lifecycle","recipe_kind":"code-hygiene","category":{"slug":"code-hygiene","label":"Code Hygiene"},"agent":"general","severity":"unspecified","maturity":"development","ecosystem":"java/maven-gradle","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"","framework_version":"","jurisdiction":"","industry":[],"cve_archetypes":[],"cve_workflow_role":"","tags":["code-hygiene","jvm","java","autocloseable","resources","try-with-resources"],"facets":["code-hygiene","audit","remediation"],"quality":{"score":100,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context","multi-facet"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"security-recipes.ai contributors","team":"Security Engineering","model":"gpt-5-codex","ai_assisted":false,"generated_by":"","date":"2026-08-21","zero_day":false,"last_updated":"2026-08-21","summary":"Java AutoCloseable and resource lifecycle: Close files, streams, clients, cursors, and scopes on every exit path.","content_text":"<!-- Generated by scripts/synccodehygiene_recipes.py; edit data/code-hygiene/catalog.json. --> A tool-agnostic recipe to close files, streams, clients, cursors, and scopes on every exit path. It supports a read-only audit and, when explicitly authorized, a narrow remediation. When to use it Use this recipe when the operator's specific objective is to close files, streams, clients, cursors, and scopes on every exit path. Prefer a narrower CVE, scanner-finding, security-audit, or compliance-evidence recipe when that is the operator's actual job. Inputs Repository root and the files, package, service, or module in scope. Requested mode: audit or explicitly authorized fix. Supported runtime, compiler, framework, operating-system, and deployment versions inferred from repository files. Existing formatter, compiler, analyzer, test, build, and package-manager commands. Public API, compatibility, performance, generated-code, vendor, and migration constraints. The prompt ~~~markdown You are running the Security Recipes code-hygiene workflow code-hygiene.jvm.java-autocloseable-and-resource-lifecycle. Start read-only. Do not edit files until the operator explicitly authorizes a fix. Use repository configuration and installed tool versions as authoritative; do not impose a new style or toolchain. Scope Your bounded objective is to close files, streams, clients, cursors, and scopes on every exit path. Inspect only operator-scoped, first-party source and configuration. Exclude generated, vendored, minified, fixture snapshot, lock history, and migration history unless explicitly included. Detection Find AutoCloseable creation and trace ownership through returns, exceptions, wrappers, and asynchronous work. Identify close ordering, suppressed exceptions, and resources escaping their intended scope. Record file and symbol evidence for every candidate. Mark uncertain or dynamically reachable behavior instead of guessing. Fix, only when authorized Use try-with-resources or an explicit owner whose lifetime matches the escaped resource. Keep the diff limited to the proven issue and its focused tests. Preserve public behavior, API compatibility, and repository conventions. Do not add or broaden suppressions, weaken diagnostics, mass-format unrelated files, upgrade dependencies, or mutate external state. Verification Test normal, partial-init, exception, and early-return paths while asserting closure order. Compare diagnostic counts and relevant behavior before and after. Report every command, result, and check that could not run. Stop conditions Stop if ownership is shared or framework-managed and its lifecycle contract is unclear. Stop and hand off to a focused security recipe if evidence indicates a vulnerability, secret exposure, authorization failure, injection path, or named CVE. Stop rather than widening scope when the safe result requires architecture, product, compliance, operational, or data-owner decisions. ~~~ Output contract Scope and repository evidence reviewed. A candidate table with file or symbol, evidence, confidence, and disposition. In audit mode: no edits, plus the smallest safe next action for each confirmed item. In fix mode: one bounded patch, focused regression coverage, and no unrelated cleanup. Commands run, results, remaining uncertainty, and any stop-condition handoff. Verification Test normal, partial-init, exception, and early-return paths while asserting closure order. Confirm that diagnostic configuration, suppressions, public interfaces, generated files, vendored files, and dependencies did not change outside the authorized scope. Review the final diff for behavior changes and run the repository's focused checks before broader suites. Guardrails Read-only until edits are explicitly authorized. Do not deploy, publish, rotate secrets, alter cloud or database state, change CI permissions, or open external tickets. Do not hide debt by disabling rules, adding retries or sleeps, weakening tests, broadening ignores, or lowering warning levels. Treat generated, vendored, minified, migration-history, and fixture-snapshot files as out of scope unless explicitly named. Stop if ownership is shared or framework-managed and its lifecycle contract is unclear. Related recipes Java compiler warning, deprecation, and suppression debt Java nullability, Optional, and boundary contracts Browse all code-hygiene recipes References NIST SP 800-218 Secure Software Development Framework 1.1 — NIST Java javac command reference — Oracle Kotlin coding conventions — JetBrains Java AutoCloseable API — Oracle","agent_handoff":{"mcp_lookup_keys":["java-autocloseable-and-resource-lifecycle","/recipes/general/code-hygiene/jvm/java-autocloseable-and-resource-lifecycle/","recipes/general/code-hygiene/jvm/java-autocloseable-and-resource-lifecycle.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["code-hygiene","audit","remediation"],"source_text_field":"content_text","portable_download":"security-recipe-java-autocloseable-and-resource-lifecycle.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-java-autocloseable-and-resource-lifecycle.json"}},{"slug":"java-compiler-warning-deprecation-and-suppression-debt","title":"Java compiler warning, deprecation, and suppression debt","link_title":"Java compiler warning, deprecation, and suppression debt","url":"https://security-recipes.ai/recipes/general/code-hygiene/jvm/java-compiler-warning-deprecation-and-suppression-debt/","path":"/recipes/general/code-hygiene/jvm/java-compiler-warning-deprecation-and-suppression-debt/","source_file":"recipes/general/code-hygiene/jvm/java-compiler-warning-deprecation-and-suppression-debt.md","recipe_id":"code-hygiene.jvm.java-compiler-warning-deprecation-and-suppression-debt","recipe_kind":"code-hygiene","category":{"slug":"code-hygiene","label":"Code Hygiene"},"agent":"general","severity":"unspecified","maturity":"development","ecosystem":"java/maven-gradle","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"","framework_version":"","jurisdiction":"","industry":[],"cve_archetypes":[],"cve_workflow_role":"","tags":["code-hygiene","jvm","java","javac","deprecation","suppresswarnings"],"facets":["code-hygiene","audit","remediation"],"quality":{"score":100,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context","multi-facet"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"security-recipes.ai contributors","team":"Security Engineering","model":"gpt-5-codex","ai_assisted":false,"generated_by":"","date":"2026-08-21","zero_day":false,"last_updated":"2026-08-21","summary":"Java compiler warning, deprecation, and suppression debt: Resolve javac warnings and narrow SuppressWarnings annotations.","content_text":"<!-- Generated by scripts/synccodehygiene_recipes.py; edit data/code-hygiene/catalog.json. --> A tool-agnostic recipe to resolve javac warnings and narrow SuppressWarnings annotations. It supports a read-only audit and, when explicitly authorized, a narrow remediation. When to use it Use this recipe when the operator's specific objective is to resolve javac warnings and narrow SuppressWarnings annotations. Prefer a narrower CVE, scanner-finding, security-audit, or compliance-evidence recipe when that is the operator's actual job. Inputs Repository root and the files, package, service, or module in scope. Requested mode: audit or explicitly authorized fix. Supported runtime, compiler, framework, operating-system, and deployment versions inferred from repository files. Existing formatter, compiler, analyzer, test, build, and package-manager commands. Public API, compatibility, performance, generated-code, vendor, and migration constraints. The prompt ~~~markdown You are running the Security Recipes code-hygiene workflow code-hygiene.jvm.java-compiler-warning-deprecation-and-suppression-debt. Start read-only. Do not edit files until the operator explicitly authorizes a fix. Use repository configuration and installed tool versions as authoritative; do not impose a new style or toolchain. Scope Your bounded objective is to resolve javac warnings and narrow SuppressWarnings annotations. Inspect only operator-scoped, first-party source and configuration. Exclude generated, vendored, minified, fixture snapshot, lock history, and migration history unless explicitly included. Detection Read Maven or Gradle compiler settings and inventory lint categories, deprecations, unchecked operations, and suppressions. Confirm source, target, release, and minimum runtime compatibility. Record file and symbol evidence for every candidate. Mark uncertain or dynamically reachable behavior instead of guessing. Fix, only when authorized Replace deprecated or unchecked constructs and scope justified suppressions to the smallest declaration. Keep the diff limited to the proven issue and its focused tests. Preserve public behavior, API compatibility, and repository conventions. Do not add or broaden suppressions, weaken diagnostics, mass-format unrelated files, upgrade dependencies, or mutate external state. Verification Compile with repository lint settings and run affected tests across supported JDKs. Compare diagnostic counts and relevant behavior before and after. Report every command, result, and check that could not run. Stop conditions Stop if the replacement drops a supported JDK or changes a public binary contract. Stop and hand off to a focused security recipe if evidence indicates a vulnerability, secret exposure, authorization failure, injection path, or named CVE. Stop rather than widening scope when the safe result requires architecture, product, compliance, operational, or data-owner decisions. ~~~ Output contract Scope and repository evidence reviewed. A candidate table with file or symbol, evidence, confidence, and disposition. In audit mode: no edits, plus the smallest safe next action for each confirmed item. In fix mode: one bounded patch, focused regression coverage, and no unrelated cleanup. Commands run, results, remaining uncertainty, and any stop-condition handoff. Verification Compile with repository lint settings and run affected tests across supported JDKs. Confirm that diagnostic configuration, suppressions, public interfaces, generated files, vendored files, and dependencies did not change outside the authorized scope. Review the final diff for behavior changes and run the repository's focused checks before broader suites. Guardrails Read-only until edits are explicitly authorized. Do not deploy, publish, rotate secrets, alter cloud or database state, change CI permissions, or open external tickets. Do not hide debt by disabling rules, adding retries or sleeps, weakening tests, broadening ignores, or lowering warning levels. Treat generated, vendored, minified, migration-history, and fixture-snapshot files as out of scope unless explicitly named. Stop if the replacement drops a supported JDK or changes a public binary contract. Related recipes Java nullability, Optional, and boundary contracts Java AutoCloseable and resource lifecycle Browse all code-hygiene recipes References NIST SP 800-218 Secure Software Development Framework 1.1 — NIST Java javac command reference — Oracle Kotlin coding conventions — JetBrains","agent_handoff":{"mcp_lookup_keys":["java-compiler-warning-deprecation-and-suppression-debt","/recipes/general/code-hygiene/jvm/java-compiler-warning-deprecation-and-suppression-debt/","recipes/general/code-hygiene/jvm/java-compiler-warning-deprecation-and-suppression-debt.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["code-hygiene","audit","remediation"],"source_text_field":"content_text","portable_download":"security-recipe-java-compiler-warning-deprecation-and-suppression-debt.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-java-compiler-warning-deprecation-and-suppression-debt.json"}},{"slug":"java-executor-future-and-threadlocal-lifecycle","title":"Java executor, Future, and ThreadLocal lifecycle","link_title":"Java executor, Future, and ThreadLocal lifecycle","url":"https://security-recipes.ai/recipes/general/code-hygiene/jvm/java-executor-future-and-threadlocal-lifecycle/","path":"/recipes/general/code-hygiene/jvm/java-executor-future-and-threadlocal-lifecycle/","source_file":"recipes/general/code-hygiene/jvm/java-executor-future-and-threadlocal-lifecycle.md","recipe_id":"code-hygiene.jvm.java-executor-future-and-threadlocal-lifecycle","recipe_kind":"code-hygiene","category":{"slug":"code-hygiene","label":"Code Hygiene"},"agent":"general","severity":"unspecified","maturity":"development","ecosystem":"java/maven-gradle","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"","framework_version":"","jurisdiction":"","industry":[],"cve_archetypes":[],"cve_workflow_role":"","tags":["code-hygiene","jvm","java","executor","future","threadlocal"],"facets":["code-hygiene","audit","remediation"],"quality":{"score":100,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context","multi-facet"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"security-recipes.ai contributors","team":"Security Engineering","model":"gpt-5-codex","ai_assisted":false,"generated_by":"","date":"2026-08-21","zero_day":false,"last_updated":"2026-08-21","summary":"Java executor, Future, and ThreadLocal lifecycle: Bound background work and clean executor and thread-local state.","content_text":"<!-- Generated by scripts/synccodehygiene_recipes.py; edit data/code-hygiene/catalog.json. --> A tool-agnostic recipe to bound background work and clean executor and thread-local state. It supports a read-only audit and, when explicitly authorized, a narrow remediation. When to use it Use this recipe when the operator's specific objective is to bound background work and clean executor and thread-local state. Prefer a narrower CVE, scanner-finding, security-audit, or compliance-evidence recipe when that is the operator's actual job. Inputs Repository root and the files, package, service, or module in scope. Requested mode: audit or explicitly authorized fix. Supported runtime, compiler, framework, operating-system, and deployment versions inferred from repository files. Existing formatter, compiler, analyzer, test, build, and package-manager commands. Public API, compatibility, performance, generated-code, vendor, and migration constraints. The prompt ~~~markdown You are running the Security Recipes code-hygiene workflow code-hygiene.jvm.java-executor-future-and-threadlocal-lifecycle. Start read-only. Do not edit files until the operator explicitly authorizes a fix. Use repository configuration and installed tool versions as authoritative; do not impose a new style or toolchain. Scope Your bounded objective is to bound background work and clean executor and thread-local state. Inspect only operator-scoped, first-party source and configuration. Exclude generated, vendored, minified, fixture snapshot, lock history, and migration history unless explicitly included. Detection Trace executor creation, queue bounds, Future observation, cancellation, shutdown, and ThreadLocal removal. Find common-pool blocking and per-request state crossing reused threads. Record file and symbol evidence for every candidate. Mark uncertain or dynamically reachable behavior instead of guessing. Fix, only when authorized Assign explicit ownership, propagate cancellation, bound queues, observe failures, and clear thread-local state. Keep the diff limited to the proven issue and its focused tests. Preserve public behavior, API compatibility, and repository conventions. Do not add or broaden suppressions, weaken diagnostics, mass-format unrelated files, upgrade dependencies, or mutate external state. Verification Test saturation, cancellation, task failure, shutdown, and request reuse. Compare diagnostic counts and relevant behavior before and after. Report every command, result, and check that could not run. Stop conditions Stop if changing concurrency limits requires capacity or latency decisions from an owner. Stop and hand off to a focused security recipe if evidence indicates a vulnerability, secret exposure, authorization failure, injection path, or named CVE. Stop rather than widening scope when the safe result requires architecture, product, compliance, operational, or data-owner decisions. ~~~ Output contract Scope and repository evidence reviewed. A candidate table with file or symbol, evidence, confidence, and disposition. In audit mode: no edits, plus the smallest safe next action for each confirmed item. In fix mode: one bounded patch, focused regression coverage, and no unrelated cleanup. Commands run, results, remaining uncertainty, and any stop-condition handoff. Verification Test saturation, cancellation, task failure, shutdown, and request reuse. Confirm that diagnostic configuration, suppressions, public interfaces, generated files, vendored files, and dependencies did not change outside the authorized scope. Review the final diff for behavior changes and run the repository's focused checks before broader suites. Guardrails Read-only until edits are explicitly authorized. Do not deploy, publish, rotate secrets, alter cloud or database state, change CI permissions, or open external tickets. Do not hide debt by disabling rules, adding retries or sleeps, weakening tests, broadening ignores, or lowering warning levels. Treat generated, vendored, minified, migration-history, and fixture-snapshot files as out of scope unless explicitly named. Stop if changing concurrency limits requires capacity or latency decisions from an owner. Related recipes Java compiler warning, deprecation, and suppression debt Java nullability, Optional, and boundary contracts Browse all code-hygiene recipes References NIST SP 800-218 Secure Software Development Framework 1.1 — NIST Java javac command reference — Oracle Kotlin coding conventions — JetBrains Java concurrency utilities — Oracle","agent_handoff":{"mcp_lookup_keys":["java-executor-future-and-threadlocal-lifecycle","/recipes/general/code-hygiene/jvm/java-executor-future-and-threadlocal-lifecycle/","recipes/general/code-hygiene/jvm/java-executor-future-and-threadlocal-lifecycle.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["code-hygiene","audit","remediation"],"source_text_field":"content_text","portable_download":"security-recipe-java-executor-future-and-threadlocal-lifecycle.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-java-executor-future-and-threadlocal-lifecycle.json"}},{"slug":"java-nullability-optional-and-boundary-contracts","title":"Java nullability, Optional, and boundary contracts","link_title":"Java nullability, Optional, and boundary contracts","url":"https://security-recipes.ai/recipes/general/code-hygiene/jvm/java-nullability-optional-and-boundary-contracts/","path":"/recipes/general/code-hygiene/jvm/java-nullability-optional-and-boundary-contracts/","source_file":"recipes/general/code-hygiene/jvm/java-nullability-optional-and-boundary-contracts.md","recipe_id":"code-hygiene.jvm.java-nullability-optional-and-boundary-contracts","recipe_kind":"code-hygiene","category":{"slug":"code-hygiene","label":"Code Hygiene"},"agent":"general","severity":"unspecified","maturity":"development","ecosystem":"java/maven-gradle","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"","framework_version":"","jurisdiction":"","industry":[],"cve_archetypes":[],"cve_workflow_role":"","tags":["code-hygiene","jvm","java","nullability","optional","contracts"],"facets":["code-hygiene","audit","remediation"],"quality":{"score":100,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context","multi-facet"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"security-recipes.ai contributors","team":"Security Engineering","model":"gpt-5-codex","ai_assisted":false,"generated_by":"","date":"2026-08-21","zero_day":false,"last_updated":"2026-08-21","summary":"Java nullability, Optional, and boundary contracts: Make null contracts explicit without misusing Optional in storage or fields.","content_text":"<!-- Generated by scripts/synccodehygiene_recipes.py; edit data/code-hygiene/catalog.json. --> A tool-agnostic recipe to make null contracts explicit without misusing Optional in storage or fields. It supports a read-only audit and, when explicitly authorized, a narrow remediation. When to use it Use this recipe when the operator's specific objective is to make null contracts explicit without misusing Optional in storage or fields. Prefer a narrower CVE, scanner-finding, security-audit, or compliance-evidence recipe when that is the operator's actual job. Inputs Repository root and the files, package, service, or module in scope. Requested mode: audit or explicitly authorized fix. Supported runtime, compiler, framework, operating-system, and deployment versions inferred from repository files. Existing formatter, compiler, analyzer, test, build, and package-manager commands. Public API, compatibility, performance, generated-code, vendor, and migration constraints. The prompt ~~~markdown You are running the Security Recipes code-hygiene workflow code-hygiene.jvm.java-nullability-optional-and-boundary-contracts. Start read-only. Do not edit files until the operator explicitly authorizes a fix. Use repository configuration and installed tool versions as authoritative; do not impose a new style or toolchain. Scope Your bounded objective is to make null contracts explicit without misusing Optional in storage or fields. Inspect only operator-scoped, first-party source and configuration. Exclude generated, vendored, minified, fixture snapshot, lock history, and migration history unless explicitly included. Detection Trace nullable inputs, dereferences, annotations, Optional creation, serialization, persistence, and framework injection. Identify conflicting package-level and external nullness conventions. Record file and symbol evidence for every candidate. Mark uncertain or dynamically reachable behavior instead of guessing. Fix, only when authorized Validate at boundaries and use annotations or Optional only where they reflect the actual API contract. Keep the diff limited to the proven issue and its focused tests. Preserve public behavior, API compatibility, and repository conventions. Do not add or broaden suppressions, weaken diagnostics, mass-format unrelated files, upgrade dependencies, or mutate external state. Verification Run nullness analysis and tests for null, absent, empty, and framework-created values. Compare diagnostic counts and relevant behavior before and after. Report every command, result, and check that could not run. Stop conditions Stop if annotation changes alter a published API contract without consumer review. Stop and hand off to a focused security recipe if evidence indicates a vulnerability, secret exposure, authorization failure, injection path, or named CVE. Stop rather than widening scope when the safe result requires architecture, product, compliance, operational, or data-owner decisions. ~~~ Output contract Scope and repository evidence reviewed. A candidate table with file or symbol, evidence, confidence, and disposition. In audit mode: no edits, plus the smallest safe next action for each confirmed item. In fix mode: one bounded patch, focused regression coverage, and no unrelated cleanup. Commands run, results, remaining uncertainty, and any stop-condition handoff. Verification Run nullness analysis and tests for null, absent, empty, and framework-created values. Confirm that diagnostic configuration, suppressions, public interfaces, generated files, vendored files, and dependencies did not change outside the authorized scope. Review the final diff for behavior changes and run the repository's focused checks before broader suites. Guardrails Read-only until edits are explicitly authorized. Do not deploy, publish, rotate secrets, alter cloud or database state, change CI permissions, or open external tickets. Do not hide debt by disabling rules, adding retries or sleeps, weakening tests, broadening ignores, or lowering warning levels. Treat generated, vendored, minified, migration-history, and fixture-snapshot files as out of scope unless explicitly named. Stop if annotation changes alter a published API contract without consumer review. Related recipes Java compiler warning, deprecation, and suppression debt Java AutoCloseable and resource lifecycle Browse all code-hygiene recipes References NIST SP 800-218 Secure Software Development Framework 1.1 — NIST Java javac command reference — Oracle Kotlin coding conventions — JetBrains","agent_handoff":{"mcp_lookup_keys":["java-nullability-optional-and-boundary-contracts","/recipes/general/code-hygiene/jvm/java-nullability-optional-and-boundary-contracts/","recipes/general/code-hygiene/jvm/java-nullability-optional-and-boundary-contracts.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["code-hygiene","audit","remediation"],"source_text_field":"content_text","portable_download":"security-recipe-java-nullability-optional-and-boundary-contracts.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-java-nullability-optional-and-boundary-contracts.json"}},{"slug":"kotlin-compiler-detekt-and-suppression-debt","title":"Kotlin compiler, Detekt, and suppression debt","link_title":"Kotlin compiler, Detekt, and suppression debt","url":"https://security-recipes.ai/recipes/general/code-hygiene/jvm/kotlin-compiler-detekt-and-suppression-debt/","path":"/recipes/general/code-hygiene/jvm/kotlin-compiler-detekt-and-suppression-debt/","source_file":"recipes/general/code-hygiene/jvm/kotlin-compiler-detekt-and-suppression-debt.md","recipe_id":"code-hygiene.jvm.kotlin-compiler-detekt-and-suppression-debt","recipe_kind":"code-hygiene","category":{"slug":"code-hygiene","label":"Code Hygiene"},"agent":"general","severity":"unspecified","maturity":"development","ecosystem":"kotlin/gradle","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"","framework_version":"","jurisdiction":"","industry":[],"cve_archetypes":[],"cve_workflow_role":"","tags":["code-hygiene","jvm","kotlin","detekt","compiler","suppressions"],"facets":["code-hygiene","audit","remediation"],"quality":{"score":100,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context","multi-facet"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"security-recipes.ai contributors","team":"Security Engineering","model":"gpt-5-codex","ai_assisted":false,"generated_by":"","date":"2026-08-21","zero_day":false,"last_updated":"2026-08-21","summary":"Kotlin compiler, Detekt, and suppression debt: Resolve Kotlin diagnostics and narrow file or declaration suppressions.","content_text":"<!-- Generated by scripts/synccodehygiene_recipes.py; edit data/code-hygiene/catalog.json. --> A tool-agnostic recipe to resolve Kotlin diagnostics and narrow file or declaration suppressions. It supports a read-only audit and, when explicitly authorized, a narrow remediation. When to use it Use this recipe when the operator's specific objective is to resolve Kotlin diagnostics and narrow file or declaration suppressions. Prefer a narrower CVE, scanner-finding, security-audit, or compliance-evidence recipe when that is the operator's actual job. Inputs Repository root and the files, package, service, or module in scope. Requested mode: audit or explicitly authorized fix. Supported runtime, compiler, framework, operating-system, and deployment versions inferred from repository files. Existing formatter, compiler, analyzer, test, build, and package-manager commands. Public API, compatibility, performance, generated-code, vendor, and migration constraints. The prompt ~~~markdown You are running the Security Recipes code-hygiene workflow code-hygiene.jvm.kotlin-compiler-detekt-and-suppression-debt. Start read-only. Do not edit files until the operator explicitly authorizes a fix. Use repository configuration and installed tool versions as authoritative; do not impose a new style or toolchain. Scope Your bounded objective is to resolve Kotlin diagnostics and narrow file or declaration suppressions. Inspect only operator-scoped, first-party source and configuration. Exclude generated, vendored, minified, fixture snapshot, lock history, and migration history unless explicitly included. Detection Read compiler, Gradle, and Detekt settings and inventory warnings, baseline entries, and Suppress annotations. Separate generated sources and Java interop warnings from owned Kotlin code. Record file and symbol evidence for every candidate. Mark uncertain or dynamically reachable behavior instead of guessing. Fix, only when authorized Use idiomatic Kotlin constructs and shrink suppressions without enabling broad auto-correction. Keep the diff limited to the proven issue and its focused tests. Preserve public behavior, API compatibility, and repository conventions. Do not add or broaden suppressions, weaken diagnostics, mass-format unrelated files, upgrade dependencies, or mutate external state. Verification Run the configured compiler and Detekt tasks plus focused tests. Compare diagnostic counts and relevant behavior before and after. Report every command, result, and check that could not run. Stop conditions Stop if automatic changes alter serialization, ABI, or Java-callable signatures. Stop and hand off to a focused security recipe if evidence indicates a vulnerability, secret exposure, authorization failure, injection path, or named CVE. Stop rather than widening scope when the safe result requires architecture, product, compliance, operational, or data-owner decisions. ~~~ Output contract Scope and repository evidence reviewed. A candidate table with file or symbol, evidence, confidence, and disposition. In audit mode: no edits, plus the smallest safe next action for each confirmed item. In fix mode: one bounded patch, focused regression coverage, and no unrelated cleanup. Commands run, results, remaining uncertainty, and any stop-condition handoff. Verification Run the configured compiler and Detekt tasks plus focused tests. Confirm that diagnostic configuration, suppressions, public interfaces, generated files, vendored files, and dependencies did not change outside the authorized scope. Review the final diff for behavior changes and run the repository's focused checks before broader suites. Guardrails Read-only until edits are explicitly authorized. Do not deploy, publish, rotate secrets, alter cloud or database state, change CI permissions, or open external tickets. Do not hide debt by disabling rules, adding retries or sleeps, weakening tests, broadening ignores, or lowering warning levels. Treat generated, vendored, minified, migration-history, and fixture-snapshot files as out of scope unless explicitly named. Stop if automatic changes alter serialization, ABI, or Java-callable signatures. Related recipes Java compiler warning, deprecation, and suppression debt Java nullability, Optional, and boundary contracts Browse all code-hygiene recipes References NIST SP 800-218 Secure Software Development Framework 1.1 — NIST Java javac command reference — Oracle Kotlin coding conventions — JetBrains","agent_handoff":{"mcp_lookup_keys":["kotlin-compiler-detekt-and-suppression-debt","/recipes/general/code-hygiene/jvm/kotlin-compiler-detekt-and-suppression-debt/","recipes/general/code-hygiene/jvm/kotlin-compiler-detekt-and-suppression-debt.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["code-hygiene","audit","remediation"],"source_text_field":"content_text","portable_download":"security-recipe-kotlin-compiler-detekt-and-suppression-debt.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-kotlin-compiler-detekt-and-suppression-debt.json"}},{"slug":"kotlin-coroutine-scope-cancellation-and-flow","title":"Kotlin coroutine scope, cancellation, and Flow lifecycle","link_title":"Kotlin coroutine scope, cancellation, and Flow lifecycle","url":"https://security-recipes.ai/recipes/general/code-hygiene/jvm/kotlin-coroutine-scope-cancellation-and-flow/","path":"/recipes/general/code-hygiene/jvm/kotlin-coroutine-scope-cancellation-and-flow/","source_file":"recipes/general/code-hygiene/jvm/kotlin-coroutine-scope-cancellation-and-flow.md","recipe_id":"code-hygiene.jvm.kotlin-coroutine-scope-cancellation-and-flow","recipe_kind":"code-hygiene","category":{"slug":"code-hygiene","label":"Code Hygiene"},"agent":"general","severity":"unspecified","maturity":"development","ecosystem":"kotlin/gradle","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"","framework_version":"","jurisdiction":"","industry":[],"cve_archetypes":[],"cve_workflow_role":"","tags":["code-hygiene","jvm","kotlin","coroutines","flow","cancellation"],"facets":["code-hygiene","audit","remediation"],"quality":{"score":100,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context","multi-facet"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"security-recipes.ai contributors","team":"Security Engineering","model":"gpt-5-codex","ai_assisted":false,"generated_by":"","date":"2026-08-21","zero_day":false,"last_updated":"2026-08-21","summary":"Kotlin coroutine scope, cancellation, and Flow lifecycle: Replace orphaned coroutines and uncollected or multiply collected flows with owned lifecycles.","content_text":"<!-- Generated by scripts/synccodehygiene_recipes.py; edit data/code-hygiene/catalog.json. --> A tool-agnostic recipe to replace orphaned coroutines and uncollected or multiply collected flows with owned lifecycles. It supports a read-only audit and, when explicitly authorized, a narrow remediation. When to use it Use this recipe when the operator's specific objective is to replace orphaned coroutines and uncollected or multiply collected flows with owned lifecycles. Prefer a narrower CVE, scanner-finding, security-audit, or compliance-evidence recipe when that is the operator's actual job. Inputs Repository root and the files, package, service, or module in scope. Requested mode: audit or explicitly authorized fix. Supported runtime, compiler, framework, operating-system, and deployment versions inferred from repository files. Existing formatter, compiler, analyzer, test, build, and package-manager commands. Public API, compatibility, performance, generated-code, vendor, and migration constraints. The prompt ~~~markdown You are running the Security Recipes code-hygiene workflow code-hygiene.jvm.kotlin-coroutine-scope-cancellation-and-flow. Start read-only. Do not edit files until the operator explicitly authorizes a fix. Use repository configuration and installed tool versions as authoritative; do not impose a new style or toolchain. Scope Your bounded objective is to replace orphaned coroutines and uncollected or multiply collected flows with owned lifecycles. Inspect only operator-scoped, first-party source and configuration. Exclude generated, vendored, minified, fixture snapshot, lock history, and migration history unless explicitly included. Detection Trace scope creation, Job parentage, dispatcher use, cancellation, exception handlers, and Flow collection. Find GlobalScope, blocking calls, leaked collectors, and swallowed CancellationException. Record file and symbol evidence for every candidate. Mark uncertain or dynamically reachable behavior instead of guessing. Fix, only when authorized Attach work to structured scopes, preserve cancellation, and make collection ownership explicit. Keep the diff limited to the proven issue and its focused tests. Preserve public behavior, API compatibility, and repository conventions. Do not add or broaden suppressions, weaken diagnostics, mass-format unrelated files, upgrade dependencies, or mutate external state. Verification Test child failure, parent cancellation, timeout, collector restart, and lifecycle teardown. Compare diagnostic counts and relevant behavior before and after. Report every command, result, and check that could not run. Stop conditions Stop if scope ownership depends on undocumented application or framework lifecycle. Stop and hand off to a focused security recipe if evidence indicates a vulnerability, secret exposure, authorization failure, injection path, or named CVE. Stop rather than widening scope when the safe result requires architecture, product, compliance, operational, or data-owner decisions. ~~~ Output contract Scope and repository evidence reviewed. A candidate table with file or symbol, evidence, confidence, and disposition. In audit mode: no edits, plus the smallest safe next action for each confirmed item. In fix mode: one bounded patch, focused regression coverage, and no unrelated cleanup. Commands run, results, remaining uncertainty, and any stop-condition handoff. Verification Test child failure, parent cancellation, timeout, collector restart, and lifecycle teardown. Confirm that diagnostic configuration, suppressions, public interfaces, generated files, vendored files, and dependencies did not change outside the authorized scope. Review the final diff for behavior changes and run the repository's focused checks before broader suites. Guardrails Read-only until edits are explicitly authorized. Do not deploy, publish, rotate secrets, alter cloud or database state, change CI permissions, or open external tickets. Do not hide debt by disabling rules, adding retries or sleeps, weakening tests, broadening ignores, or lowering warning levels. Treat generated, vendored, minified, migration-history, and fixture-snapshot files as out of scope unless explicitly named. Stop if scope ownership depends on undocumented application or framework lifecycle. Related recipes Java compiler warning, deprecation, and suppression debt Java nullability, Optional, and boundary contracts Browse all code-hygiene recipes References NIST SP 800-218 Secure Software Development Framework 1.1 — NIST Java javac command reference — Oracle Kotlin coding conventions — JetBrains Kotlin coroutines guide — JetBrains","agent_handoff":{"mcp_lookup_keys":["kotlin-coroutine-scope-cancellation-and-flow","/recipes/general/code-hygiene/jvm/kotlin-coroutine-scope-cancellation-and-flow/","recipes/general/code-hygiene/jvm/kotlin-coroutine-scope-cancellation-and-flow.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["code-hygiene","audit","remediation"],"source_text_field":"content_text","portable_download":"security-recipe-kotlin-coroutine-scope-cancellation-and-flow.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-kotlin-coroutine-scope-cancellation-and-flow.json"}},{"slug":"kotlin-nullability-platform-types-and-immutability","title":"Kotlin nullability, platform types, and immutability","link_title":"Kotlin nullability, platform types, and immutability","url":"https://security-recipes.ai/recipes/general/code-hygiene/jvm/kotlin-nullability-platform-types-and-immutability/","path":"/recipes/general/code-hygiene/jvm/kotlin-nullability-platform-types-and-immutability/","source_file":"recipes/general/code-hygiene/jvm/kotlin-nullability-platform-types-and-immutability.md","recipe_id":"code-hygiene.jvm.kotlin-nullability-platform-types-and-immutability","recipe_kind":"code-hygiene","category":{"slug":"code-hygiene","label":"Code Hygiene"},"agent":"general","severity":"unspecified","maturity":"development","ecosystem":"kotlin/gradle","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"","framework_version":"","jurisdiction":"","industry":[],"cve_archetypes":[],"cve_workflow_role":"","tags":["code-hygiene","jvm","kotlin","nullability","platform-types","immutability"],"facets":["code-hygiene","audit","remediation"],"quality":{"score":100,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context","multi-facet"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"security-recipes.ai contributors","team":"Security Engineering","model":"gpt-5-codex","ai_assisted":false,"generated_by":"","date":"2026-08-21","zero_day":false,"last_updated":"2026-08-21","summary":"Kotlin nullability, platform types, and immutability: Contain Java platform types and remove unsafe assertions and unintended mutation.","content_text":"<!-- Generated by scripts/synccodehygiene_recipes.py; edit data/code-hygiene/catalog.json. --> A tool-agnostic recipe to contain Java platform types and remove unsafe assertions and unintended mutation. It supports a read-only audit and, when explicitly authorized, a narrow remediation. When to use it Use this recipe when the operator's specific objective is to contain Java platform types and remove unsafe assertions and unintended mutation. Prefer a narrower CVE, scanner-finding, security-audit, or compliance-evidence recipe when that is the operator's actual job. Inputs Repository root and the files, package, service, or module in scope. Requested mode: audit or explicitly authorized fix. Supported runtime, compiler, framework, operating-system, and deployment versions inferred from repository files. Existing formatter, compiler, analyzer, test, build, and package-manager commands. Public API, compatibility, performance, generated-code, vendor, and migration constraints. The prompt ~~~markdown You are running the Security Recipes code-hygiene workflow code-hygiene.jvm.kotlin-nullability-platform-types-and-immutability. Start read-only. Do not edit files until the operator explicitly authorizes a fix. Use repository configuration and installed tool versions as authoritative; do not impose a new style or toolchain. Scope Your bounded objective is to contain Java platform types and remove unsafe assertions and unintended mutation. Inspect only operator-scoped, first-party source and configuration. Exclude generated, vendored, minified, fixture snapshot, lock history, and migration history unless explicitly included. Detection Find platform types, double-bang assertions, unsafe casts, mutable collection exposure, and data-class copy assumptions. Trace Java interop annotations and framework-created values. Record file and symbol evidence for every candidate. Mark uncertain or dynamically reachable behavior instead of guessing. Fix, only when authorized Narrow at interop boundaries and expose immutable contracts while preserving required framework mutability. Keep the diff limited to the proven issue and its focused tests. Preserve public behavior, API compatibility, and repository conventions. Do not add or broaden suppressions, weaken diagnostics, mass-format unrelated files, upgrade dependencies, or mutate external state. Verification Run compiler checks and tests for null Java returns, collection aliasing, and serialization. Compare diagnostic counts and relevant behavior before and after. Report every command, result, and check that could not run. Stop conditions Stop if changing mutability or nullability alters a public Java or Kotlin API. Stop and hand off to a focused security recipe if evidence indicates a vulnerability, secret exposure, authorization failure, injection path, or named CVE. Stop rather than widening scope when the safe result requires architecture, product, compliance, operational, or data-owner decisions. ~~~ Output contract Scope and repository evidence reviewed. A candidate table with file or symbol, evidence, confidence, and disposition. In audit mode: no edits, plus the smallest safe next action for each confirmed item. In fix mode: one bounded patch, focused regression coverage, and no unrelated cleanup. Commands run, results, remaining uncertainty, and any stop-condition handoff. Verification Run compiler checks and tests for null Java returns, collection aliasing, and serialization. Confirm that diagnostic configuration, suppressions, public interfaces, generated files, vendored files, and dependencies did not change outside the authorized scope. Review the final diff for behavior changes and run the repository's focused checks before broader suites. Guardrails Read-only until edits are explicitly authorized. Do not deploy, publish, rotate secrets, alter cloud or database state, change CI permissions, or open external tickets. Do not hide debt by disabling rules, adding retries or sleeps, weakening tests, broadening ignores, or lowering warning levels. Treat generated, vendored, minified, migration-history, and fixture-snapshot files as out of scope unless explicitly named. Stop if changing mutability or nullability alters a public Java or Kotlin API. Related recipes Java compiler warning, deprecation, and suppression debt Java nullability, Optional, and boundary contracts Browse all code-hygiene recipes References NIST SP 800-218 Secure Software Development Framework 1.1 — NIST Java javac command reference — Oracle Kotlin coding conventions — JetBrains Kotlin null safety — JetBrains","agent_handoff":{"mcp_lookup_keys":["kotlin-nullability-platform-types-and-immutability","/recipes/general/code-hygiene/jvm/kotlin-nullability-platform-types-and-immutability/","recipes/general/code-hygiene/jvm/kotlin-nullability-platform-types-and-immutability.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["code-hygiene","audit","remediation"],"source_text_field":"content_text","portable_download":"security-recipe-kotlin-nullability-platform-types-and-immutability.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-kotlin-nullability-platform-types-and-immutability.json"}},{"slug":"php-exception-stream-and-resource-lifecycle","title":"PHP exception, stream, and resource lifecycle","link_title":"PHP exception, stream, and resource lifecycle","url":"https://security-recipes.ai/recipes/general/code-hygiene/php/php-exception-stream-and-resource-lifecycle/","path":"/recipes/general/code-hygiene/php/php-exception-stream-and-resource-lifecycle/","source_file":"recipes/general/code-hygiene/php/php-exception-stream-and-resource-lifecycle.md","recipe_id":"code-hygiene.php.php-exception-stream-and-resource-lifecycle","recipe_kind":"code-hygiene","category":{"slug":"code-hygiene","label":"Code Hygiene"},"agent":"general","severity":"unspecified","maturity":"development","ecosystem":"php/composer","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"","framework_version":"","jurisdiction":"","industry":[],"cve_archetypes":[],"cve_workflow_role":"","tags":["code-hygiene","php","exceptions","streams","resources"],"facets":["code-hygiene","audit","remediation"],"quality":{"score":100,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context","multi-facet"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"security-recipes.ai contributors","team":"Security Engineering","model":"gpt-5-codex","ai_assisted":false,"generated_by":"","date":"2026-08-21","zero_day":false,"last_updated":"2026-08-21","summary":"PHP exception, stream, and resource lifecycle: Close resources and preserve failure context across PHP request and worker paths.","content_text":"<!-- Generated by scripts/synccodehygiene_recipes.py; edit data/code-hygiene/catalog.json. --> A tool-agnostic recipe to close resources and preserve failure context across PHP request and worker paths. It supports a read-only audit and, when explicitly authorized, a narrow remediation. When to use it Use this recipe when the operator's specific objective is to close resources and preserve failure context across PHP request and worker paths. Prefer a narrower CVE, scanner-finding, security-audit, or compliance-evidence recipe when that is the operator's actual job. Inputs Repository root and the files, package, service, or module in scope. Requested mode: audit or explicitly authorized fix. Supported runtime, compiler, framework, operating-system, and deployment versions inferred from repository files. Existing formatter, compiler, analyzer, test, build, and package-manager commands. Public API, compatibility, performance, generated-code, vendor, and migration constraints. The prompt ~~~markdown You are running the Security Recipes code-hygiene workflow code-hygiene.php.php-exception-stream-and-resource-lifecycle. Start read-only. Do not edit files until the operator explicitly authorizes a fix. Use repository configuration and installed tool versions as authoritative; do not impose a new style or toolchain. Scope Your bounded objective is to close resources and preserve failure context across PHP request and worker paths. Inspect only operator-scoped, first-party source and configuration. Exclude generated, vendored, minified, fixture snapshot, lock history, and migration history unless explicitly included. Detection Trace fopen and stream resources, database handles, locks, temporary files, catches, finally blocks, and worker reuse. Find swallowed Throwable values and cleanup that only occurs on normal return. Record file and symbol evidence for every candidate. Mark uncertain or dynamically reachable behavior instead of guessing. Fix, only when authorized Place cleanup at the owning scope and catch only failures the layer can translate or recover from. Keep the diff limited to the proven issue and its focused tests. Preserve public behavior, API compatibility, and repository conventions. Do not add or broaden suppressions, weaken diagnostics, mass-format unrelated files, upgrade dependencies, or mutate external state. Verification Test normal, warning-to-exception, partial initialization, worker repetition, and failure cleanup paths. Compare diagnostic counts and relevant behavior before and after. Report every command, result, and check that could not run. Stop conditions Stop if resource ownership is extension-managed or framework-managed and undocumented. Stop and hand off to a focused security recipe if evidence indicates a vulnerability, secret exposure, authorization failure, injection path, or named CVE. Stop rather than widening scope when the safe result requires architecture, product, compliance, operational, or data-owner decisions. ~~~ Output contract Scope and repository evidence reviewed. A candidate table with file or symbol, evidence, confidence, and disposition. In audit mode: no edits, plus the smallest safe next action for each confirmed item. In fix mode: one bounded patch, focused regression coverage, and no unrelated cleanup. Commands run, results, remaining uncertainty, and any stop-condition handoff. Verification Test normal, warning-to-exception, partial initialization, worker repetition, and failure cleanup paths. Confirm that diagnostic configuration, suppressions, public interfaces, generated files, vendored files, and dependencies did not change outside the authorized scope. Review the final diff for behavior changes and run the repository's focused checks before broader suites. Guardrails Read-only until edits are explicitly authorized. Do not deploy, publish, rotate secrets, alter cloud or database state, change CI permissions, or open external tickets. Do not hide debt by disabling rules, adding retries or sleeps, weakening tests, broadening ignores, or lowering warning levels. Treat generated, vendored, minified, migration-history, and fixture-snapshot files as out of scope unless explicitly named. Stop if resource ownership is extension-managed or framework-managed and undocumented. Related recipes PHP strict types, static analysis, and suppression debt Lint warning baseline and budget Browse all code-hygiene recipes References NIST SP 800-218 Secure Software Development Framework 1.1 — NIST PHP type declarations — PHP project PHP errors — PHP project","agent_handoff":{"mcp_lookup_keys":["php-exception-stream-and-resource-lifecycle","/recipes/general/code-hygiene/php/php-exception-stream-and-resource-lifecycle/","recipes/general/code-hygiene/php/php-exception-stream-and-resource-lifecycle.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["code-hygiene","audit","remediation"],"source_text_field":"content_text","portable_download":"security-recipe-php-exception-stream-and-resource-lifecycle.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-php-exception-stream-and-resource-lifecycle.json"}},{"slug":"php-strict-types-static-analysis-and-suppression-debt","title":"PHP strict types, static analysis, and suppression debt","link_title":"PHP strict types, static analysis, and suppression debt","url":"https://security-recipes.ai/recipes/general/code-hygiene/php/php-strict-types-static-analysis-and-suppression-debt/","path":"/recipes/general/code-hygiene/php/php-strict-types-static-analysis-and-suppression-debt/","source_file":"recipes/general/code-hygiene/php/php-strict-types-static-analysis-and-suppression-debt.md","recipe_id":"code-hygiene.php.php-strict-types-static-analysis-and-suppression-debt","recipe_kind":"code-hygiene","category":{"slug":"code-hygiene","label":"Code Hygiene"},"agent":"general","severity":"unspecified","maturity":"development","ecosystem":"php/composer","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"","framework_version":"","jurisdiction":"","industry":[],"cve_archetypes":[],"cve_workflow_role":"","tags":["code-hygiene","php","strict-types","static-analysis","suppressions"],"facets":["code-hygiene","audit","remediation"],"quality":{"score":100,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context","multi-facet"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"security-recipes.ai contributors","team":"Security Engineering","model":"gpt-5-codex","ai_assisted":false,"generated_by":"","date":"2026-08-21","zero_day":false,"last_updated":"2026-08-21","summary":"PHP strict types, static analysis, and suppression debt: Narrow mixed values and static-analysis suppressions without breaking framework boundaries.","content_text":"<!-- Generated by scripts/synccodehygienerecipes.py; edit data/code-hygiene/catalog.json. --> A tool-agnostic recipe to narrow mixed values and static-analysis suppressions without breaking framework boundaries. It supports a read-only audit and, when explicitly authorized, a narrow remediation. When to use it Use this recipe when the operator's specific objective is to narrow mixed values and static-analysis suppressions without breaking framework boundaries. Prefer a narrower CVE, scanner-finding, security-audit, or compliance-evidence recipe when that is the operator's actual job. Inputs Repository root and the files, package, service, or module in scope. Requested mode: audit or explicitly authorized fix. Supported runtime, compiler, framework, operating-system, and deployment versions inferred from repository files. Existing formatter, compiler, analyzer, test, build, and package-manager commands. Public API, compatibility, performance, generated-code, vendor, and migration constraints. The prompt ~~~markdown You are running the Security Recipes code-hygiene workflow code-hygiene.php.php-strict-types-static-analysis-and-suppression-debt. Start read-only. Do not edit files until the operator explicitly authorizes a fix. Use repository configuration and installed tool versions as authoritative; do not impose a new style or toolchain. Scope Your bounded objective is to narrow mixed values and static-analysis suppressions without breaking framework boundaries. Inspect only operator-scoped, first-party source and configuration. Exclude generated, vendored, minified, fixture snapshot, lock history, and migration history unless explicitly included. Detection Read PHP version, analyzer configuration and baseline, stricttypes use, docblocks, mixed values, and ignores. Separate framework magic and generated code from application-owned contracts. Record file and symbol evidence for every candidate. Mark uncertain or dynamically reachable behavior instead of guessing. Fix, only when authorized Add truthful parameter, return, property, shape, or assertion types at owned boundaries. Keep the diff limited to the proven issue and its focused tests. Preserve public behavior, API compatibility, and repository conventions. Do not add or broaden suppressions, weaken diagnostics, mass-format unrelated files, upgrade dependencies, or mutate external state. Verification Run syntax checks, the configured analyzer, and focused tests with no broader baseline. Compare diagnostic counts and relevant behavior before and after. Report every command, result, and check that could not run. Stop conditions Stop if strict types or signatures would break public consumers or framework invocation. Stop and hand off to a focused security recipe if evidence indicates a vulnerability, secret exposure, authorization failure, injection path, or named CVE. Stop rather than widening scope when the safe result requires architecture, product, compliance, operational, or data-owner decisions. ~~~ Output contract Scope and repository evidence reviewed. A candidate table with file or symbol, evidence, confidence, and disposition. In audit mode: no edits, plus the smallest safe next action for each confirmed item. In fix mode: one bounded patch, focused regression coverage, and no unrelated cleanup. Commands run, results, remaining uncertainty, and any stop-condition handoff. Verification Run syntax checks, the configured analyzer, and focused tests with no broader baseline. Confirm that diagnostic configuration, suppressions, public interfaces, generated files, vendored files, and dependencies did not change outside the authorized scope. Review the final diff for behavior changes and run the repository's focused checks before broader suites. Guardrails Read-only until edits are explicitly authorized. Do not deploy, publish, rotate secrets, alter cloud or database state, change CI permissions, or open external tickets. Do not hide debt by disabling rules, adding retries or sleeps, weakening tests, broadening ignores, or lowering warning levels. Treat generated, vendored, minified, migration-history, and fixture-snapshot files as out of scope unless explicitly named. Stop if strict types or signatures would break public consumers or framework invocation. Related recipes PHP exception, stream, and resource lifecycle Lint warning baseline and budget Browse all code-hygiene recipes References NIST SP 800-218 Secure Software Development Framework 1.1 — NIST PHP type declarations — PHP project PHP errors — PHP project","agent_handoff":{"mcp_lookup_keys":["php-strict-types-static-analysis-and-suppression-debt","/recipes/general/code-hygiene/php/php-strict-types-static-analysis-and-suppression-debt/","recipes/general/code-hygiene/php/php-strict-types-static-analysis-and-suppression-debt.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["code-hygiene","audit","remediation"],"source_text_field":"content_text","portable_download":"security-recipe-php-strict-types-static-analysis-and-suppression-debt.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-php-strict-types-static-analysis-and-suppression-debt.json"}},{"slug":"ci-workflow-timeout-concurrency-and-cache-hygiene","title":"CI workflow timeout, concurrency, and cache hygiene","link_title":"CI workflow timeout, concurrency, and cache hygiene","url":"https://security-recipes.ai/recipes/general/code-hygiene/platform/ci-workflow-timeout-concurrency-and-cache-hygiene/","path":"/recipes/general/code-hygiene/platform/ci-workflow-timeout-concurrency-and-cache-hygiene/","source_file":"recipes/general/code-hygiene/platform/ci-workflow-timeout-concurrency-and-cache-hygiene.md","recipe_id":"code-hygiene.platform.ci-workflow-timeout-concurrency-and-cache-hygiene","recipe_kind":"code-hygiene","category":{"slug":"code-hygiene","label":"Code Hygiene"},"agent":"general","severity":"unspecified","maturity":"development","ecosystem":"ci/workflows","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"","framework_version":"","jurisdiction":"","industry":[],"cve_archetypes":[],"cve_workflow_role":"","tags":["code-hygiene","platform","ci","workflows","timeouts","concurrency","cache"],"facets":["code-hygiene","audit","remediation"],"quality":{"score":100,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context","multi-facet"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"security-recipes.ai contributors","team":"Security Engineering","model":"gpt-5-codex","ai_assisted":false,"generated_by":"","date":"2026-08-21","zero_day":false,"last_updated":"2026-08-21","summary":"CI workflow timeout, concurrency, and cache hygiene: Bound CI jobs and prevent stale caches and duplicate workflow races.","content_text":"<!-- Generated by scripts/synccodehygiene_recipes.py; edit data/code-hygiene/catalog.json. --> A tool-agnostic recipe to bound CI jobs and prevent stale caches and duplicate workflow races. It supports a read-only audit and, when explicitly authorized, a narrow remediation. When to use it Use this recipe when the operator's specific objective is to bound CI jobs and prevent stale caches and duplicate workflow races. Prefer a narrower CVE, scanner-finding, security-audit, or compliance-evidence recipe when that is the operator's actual job. Inputs Repository root and the files, package, service, or module in scope. Requested mode: audit or explicitly authorized fix. Supported runtime, compiler, framework, operating-system, and deployment versions inferred from repository files. Existing formatter, compiler, analyzer, test, build, and package-manager commands. Public API, compatibility, performance, generated-code, vendor, and migration constraints. The prompt ~~~markdown You are running the Security Recipes code-hygiene workflow code-hygiene.platform.ci-workflow-timeout-concurrency-and-cache-hygiene. Start read-only. Do not edit files until the operator explicitly authorizes a fix. Use repository configuration and installed tool versions as authoritative; do not impose a new style or toolchain. Scope Your bounded objective is to bound CI jobs and prevent stale caches and duplicate workflow races. Inspect only operator-scoped, first-party source and configuration. Exclude generated, vendored, minified, fixture snapshot, lock history, and migration history unless explicitly included. Detection Map triggers, permissions, job dependencies, timeouts, concurrency groups, cancellation, matrices, cache keys, and artifact lifetimes. Identify redundant runs and caches missing lockfile, platform, or toolchain inputs. Record file and symbol evidence for every candidate. Mark uncertain or dynamically reachable behavior instead of guessing. Fix, only when authorized Add bounded timeouts, safe concurrency cancellation, and deterministic cache keys without changing release authority. Keep the diff limited to the proven issue and its focused tests. Preserve public behavior, API compatibility, and repository conventions. Do not add or broaden suppressions, weaken diagnostics, mass-format unrelated files, upgrade dependencies, or mutate external state. Verification Validate workflow syntax and exercise pull-request, branch, retry, and cache-hit or miss paths where tooling permits. Compare diagnostic counts and relevant behavior before and after. Report every command, result, and check that could not run. Stop conditions Stop before changing secrets, permissions, release triggers, protected environments, or third-party action trust. Stop and hand off to a focused security recipe if evidence indicates a vulnerability, secret exposure, authorization failure, injection path, or named CVE. Stop rather than widening scope when the safe result requires architecture, product, compliance, operational, or data-owner decisions. ~~~ Output contract Scope and repository evidence reviewed. A candidate table with file or symbol, evidence, confidence, and disposition. In audit mode: no edits, plus the smallest safe next action for each confirmed item. In fix mode: one bounded patch, focused regression coverage, and no unrelated cleanup. Commands run, results, remaining uncertainty, and any stop-condition handoff. Verification Validate workflow syntax and exercise pull-request, branch, retry, and cache-hit or miss paths where tooling permits. Confirm that diagnostic configuration, suppressions, public interfaces, generated files, vendored files, and dependencies did not change outside the authorized scope. Review the final diff for behavior changes and run the repository's focused checks before broader suites. Guardrails Read-only until edits are explicitly authorized. Do not deploy, publish, rotate secrets, alter cloud or database state, change CI permissions, or open external tickets. Do not hide debt by disabling rules, adding retries or sleeps, weakening tests, broadening ignores, or lowering warning levels. Treat generated, vendored, minified, migration-history, and fixture-snapshot files as out of scope unless explicitly named. Stop before changing secrets, permissions, release triggers, protected environments, or third-party action trust. Related recipes Terraform format, validation, and provider-lock hygiene Terraform state-address and refactor safety Browse all code-hygiene recipes References NIST SP 800-218 Secure Software Development Framework 1.1 — NIST Terraform validate command — HashiCorp Docker build best practices — Docker Kubernetes configuration good practices — Kubernetes GitHub Actions workflow syntax — GitHub","agent_handoff":{"mcp_lookup_keys":["ci-workflow-timeout-concurrency-and-cache-hygiene","/recipes/general/code-hygiene/platform/ci-workflow-timeout-concurrency-and-cache-hygiene/","recipes/general/code-hygiene/platform/ci-workflow-timeout-concurrency-and-cache-hygiene.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["code-hygiene","audit","remediation"],"source_text_field":"content_text","portable_download":"security-recipe-ci-workflow-timeout-concurrency-and-cache-hygiene.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-ci-workflow-timeout-concurrency-and-cache-hygiene.json"}},{"slug":"container-signal-healthcheck-and-shutdown","title":"Container signal, healthcheck, and shutdown hygiene","link_title":"Container signal, healthcheck, and shutdown hygiene","url":"https://security-recipes.ai/recipes/general/code-hygiene/platform/container-signal-healthcheck-and-shutdown/","path":"/recipes/general/code-hygiene/platform/container-signal-healthcheck-and-shutdown/","source_file":"recipes/general/code-hygiene/platform/container-signal-healthcheck-and-shutdown.md","recipe_id":"code-hygiene.platform.container-signal-healthcheck-and-shutdown","recipe_kind":"code-hygiene","category":{"slug":"code-hygiene","label":"Code Hygiene"},"agent":"general","severity":"unspecified","maturity":"development","ecosystem":"containers/oci","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"","framework_version":"","jurisdiction":"","industry":[],"cve_archetypes":[],"cve_workflow_role":"","tags":["code-hygiene","platform","containers","signals","healthcheck","shutdown"],"facets":["code-hygiene","audit","remediation"],"quality":{"score":100,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context","multi-facet"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"security-recipes.ai contributors","team":"Security Engineering","model":"gpt-5-codex","ai_assisted":false,"generated_by":"","date":"2026-08-21","zero_day":false,"last_updated":"2026-08-21","summary":"Container signal, healthcheck, and shutdown hygiene: Make PID 1 signal handling, readiness, health, and graceful shutdown correct.","content_text":"<!-- Generated by scripts/synccodehygiene_recipes.py; edit data/code-hygiene/catalog.json. --> A tool-agnostic recipe to make PID 1 signal handling, readiness, health, and graceful shutdown correct. It supports a read-only audit and, when explicitly authorized, a narrow remediation. When to use it Use this recipe when the operator's specific objective is to make PID 1 signal handling, readiness, health, and graceful shutdown correct. Prefer a narrower CVE, scanner-finding, security-audit, or compliance-evidence recipe when that is the operator's actual job. Inputs Repository root and the files, package, service, or module in scope. Requested mode: audit or explicitly authorized fix. Supported runtime, compiler, framework, operating-system, and deployment versions inferred from repository files. Existing formatter, compiler, analyzer, test, build, and package-manager commands. Public API, compatibility, performance, generated-code, vendor, and migration constraints. The prompt ~~~markdown You are running the Security Recipes code-hygiene workflow code-hygiene.platform.container-signal-healthcheck-and-shutdown. Start read-only. Do not edit files until the operator explicitly authorizes a fix. Use repository configuration and installed tool versions as authoritative; do not impose a new style or toolchain. Scope Your bounded objective is to make PID 1 signal handling, readiness, health, and graceful shutdown correct. Inspect only operator-scoped, first-party source and configuration. Exclude generated, vendored, minified, fixture snapshot, lock history, and migration history unless explicitly included. Detection Trace entrypoint form, PID 1, child processes, signal forwarding, grace periods, health commands, and open listeners. Distinguish readiness from liveness and startup completion. Record file and symbol evidence for every candidate. Mark uncertain or dynamically reachable behavior instead of guessing. Fix, only when authorized Use direct exec or an appropriate init and align health behavior with actual service lifecycle. Keep the diff limited to the proven issue and its focused tests. Preserve public behavior, API compatibility, and repository conventions. Do not add or broaden suppressions, weaken diagnostics, mass-format unrelated files, upgrade dependencies, or mutate external state. Verification Start the image, send termination, observe exit and child cleanup, and test health transitions. Compare diagnostic counts and relevant behavior before and after. Report every command, result, and check that could not run. Stop conditions Stop if changing grace periods or health semantics requires orchestrator or SLO owner approval. Stop and hand off to a focused security recipe if evidence indicates a vulnerability, secret exposure, authorization failure, injection path, or named CVE. Stop rather than widening scope when the safe result requires architecture, product, compliance, operational, or data-owner decisions. ~~~ Output contract Scope and repository evidence reviewed. A candidate table with file or symbol, evidence, confidence, and disposition. In audit mode: no edits, plus the smallest safe next action for each confirmed item. In fix mode: one bounded patch, focused regression coverage, and no unrelated cleanup. Commands run, results, remaining uncertainty, and any stop-condition handoff. Verification Start the image, send termination, observe exit and child cleanup, and test health transitions. Confirm that diagnostic configuration, suppressions, public interfaces, generated files, vendored files, and dependencies did not change outside the authorized scope. Review the final diff for behavior changes and run the repository's focused checks before broader suites. Guardrails Read-only until edits are explicitly authorized. Do not deploy, publish, rotate secrets, alter cloud or database state, change CI permissions, or open external tickets. Do not hide debt by disabling rules, adding retries or sleeps, weakening tests, broadening ignores, or lowering warning levels. Treat generated, vendored, minified, migration-history, and fixture-snapshot files as out of scope unless explicitly named. Stop if changing grace periods or health semantics requires orchestrator or SLO owner approval. Related recipes Terraform format, validation, and provider-lock hygiene Terraform state-address and refactor safety Browse all code-hygiene recipes References NIST SP 800-218 Secure Software Development Framework 1.1 — NIST Terraform validate command — HashiCorp Docker build best practices — Docker Kubernetes configuration good practices — Kubernetes GitHub Actions workflow syntax — GitHub Docker run reference — Docker","agent_handoff":{"mcp_lookup_keys":["container-signal-healthcheck-and-shutdown","/recipes/general/code-hygiene/platform/container-signal-healthcheck-and-shutdown/","recipes/general/code-hygiene/platform/container-signal-healthcheck-and-shutdown.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["code-hygiene","audit","remediation"],"source_text_field":"content_text","portable_download":"security-recipe-container-signal-healthcheck-and-shutdown.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-container-signal-healthcheck-and-shutdown.json"}},{"slug":"dockerfile-layer-cache-and-build-context","title":"Dockerfile layer, cache, and build-context hygiene","link_title":"Dockerfile layer, cache, and build-context hygiene","url":"https://security-recipes.ai/recipes/general/code-hygiene/platform/dockerfile-layer-cache-and-build-context/","path":"/recipes/general/code-hygiene/platform/dockerfile-layer-cache-and-build-context/","source_file":"recipes/general/code-hygiene/platform/dockerfile-layer-cache-and-build-context.md","recipe_id":"code-hygiene.platform.dockerfile-layer-cache-and-build-context","recipe_kind":"code-hygiene","category":{"slug":"code-hygiene","label":"Code Hygiene"},"agent":"general","severity":"unspecified","maturity":"development","ecosystem":"containers/oci","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"","framework_version":"","jurisdiction":"","industry":[],"cve_archetypes":[],"cve_workflow_role":"","tags":["code-hygiene","platform","docker","dockerfile","layers","cache","build-context"],"facets":["code-hygiene","audit","remediation"],"quality":{"score":100,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context","multi-facet"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"security-recipes.ai contributors","team":"Security Engineering","model":"gpt-5-codex","ai_assisted":false,"generated_by":"","date":"2026-08-21","zero_day":false,"last_updated":"2026-08-21","summary":"Dockerfile layer, cache, and build-context hygiene: Make container builds reproducible, cache-efficient, and free of accidental context.","content_text":"<!-- Generated by scripts/synccodehygiene_recipes.py; edit data/code-hygiene/catalog.json. --> A tool-agnostic recipe to make container builds reproducible, cache-efficient, and free of accidental context. It supports a read-only audit and, when explicitly authorized, a narrow remediation. When to use it Use this recipe when the operator's specific objective is to make container builds reproducible, cache-efficient, and free of accidental context. Prefer a narrower CVE, scanner-finding, security-audit, or compliance-evidence recipe when that is the operator's actual job. Inputs Repository root and the files, package, service, or module in scope. Requested mode: audit or explicitly authorized fix. Supported runtime, compiler, framework, operating-system, and deployment versions inferred from repository files. Existing formatter, compiler, analyzer, test, build, and package-manager commands. Public API, compatibility, performance, generated-code, vendor, and migration constraints. The prompt ~~~markdown You are running the Security Recipes code-hygiene workflow code-hygiene.platform.dockerfile-layer-cache-and-build-context. Start read-only. Do not edit files until the operator explicitly authorizes a fix. Use repository configuration and installed tool versions as authoritative; do not impose a new style or toolchain. Scope Your bounded objective is to make container builds reproducible, cache-efficient, and free of accidental context. Inspect only operator-scoped, first-party source and configuration. Exclude generated, vendored, minified, fixture snapshot, lock history, and migration history unless explicitly included. Detection Inspect Dockerfile stage graph, context, dockerignore, copy order, package-manager caches, build arguments, and emitted artifacts. Compare clean and cached builds and final-image contents. Record file and symbol evidence for every candidate. Mark uncertain or dynamically reachable behavior instead of guessing. Fix, only when authorized Narrow context and stages, order stable inputs before volatile inputs, and remove build-only material from final stages. Keep the diff limited to the proven issue and its focused tests. Preserve public behavior, API compatibility, and repository conventions. Do not add or broaden suppressions, weaken diagnostics, mass-format unrelated files, upgrade dependencies, or mutate external state. Verification Run clean and cached builds, inspect final files and history, and execute existing image tests. Compare diagnostic counts and relevant behavior before and after. Report every command, result, and check that could not run. Stop conditions Stop before changing base versions, package versions, registry, signing, or release provenance. Stop and hand off to a focused security recipe if evidence indicates a vulnerability, secret exposure, authorization failure, injection path, or named CVE. Stop rather than widening scope when the safe result requires architecture, product, compliance, operational, or data-owner decisions. ~~~ Output contract Scope and repository evidence reviewed. A candidate table with file or symbol, evidence, confidence, and disposition. In audit mode: no edits, plus the smallest safe next action for each confirmed item. In fix mode: one bounded patch, focused regression coverage, and no unrelated cleanup. Commands run, results, remaining uncertainty, and any stop-condition handoff. Verification Run clean and cached builds, inspect final files and history, and execute existing image tests. Confirm that diagnostic configuration, suppressions, public interfaces, generated files, vendored files, and dependencies did not change outside the authorized scope. Review the final diff for behavior changes and run the repository's focused checks before broader suites. Guardrails Read-only until edits are explicitly authorized. Do not deploy, publish, rotate secrets, alter cloud or database state, change CI permissions, or open external tickets. Do not hide debt by disabling rules, adding retries or sleeps, weakening tests, broadening ignores, or lowering warning levels. Treat generated, vendored, minified, migration-history, and fixture-snapshot files as out of scope unless explicitly named. Stop before changing base versions, package versions, registry, signing, or release provenance. Related recipes Terraform format, validation, and provider-lock hygiene Terraform state-address and refactor safety Browse all code-hygiene recipes References NIST SP 800-218 Secure Software Development Framework 1.1 — NIST Terraform validate command — HashiCorp Docker build best practices — Docker Kubernetes configuration good practices — Kubernetes GitHub Actions workflow syntax — GitHub","agent_handoff":{"mcp_lookup_keys":["dockerfile-layer-cache-and-build-context","/recipes/general/code-hygiene/platform/dockerfile-layer-cache-and-build-context/","recipes/general/code-hygiene/platform/dockerfile-layer-cache-and-build-context.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["code-hygiene","audit","remediation"],"source_text_field":"content_text","portable_download":"security-recipe-dockerfile-layer-cache-and-build-context.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-dockerfile-layer-cache-and-build-context.json"}},{"slug":"kubernetes-probe-resource-and-rollout-hygiene","title":"Kubernetes probe, resource, and rollout hygiene","link_title":"Kubernetes probe, resource, and rollout hygiene","url":"https://security-recipes.ai/recipes/general/code-hygiene/platform/kubernetes-probe-resource-and-rollout-hygiene/","path":"/recipes/general/code-hygiene/platform/kubernetes-probe-resource-and-rollout-hygiene/","source_file":"recipes/general/code-hygiene/platform/kubernetes-probe-resource-and-rollout-hygiene.md","recipe_id":"code-hygiene.platform.kubernetes-probe-resource-and-rollout-hygiene","recipe_kind":"code-hygiene","category":{"slug":"code-hygiene","label":"Code Hygiene"},"agent":"general","severity":"unspecified","maturity":"development","ecosystem":"kubernetes/manifests","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"","framework_version":"","jurisdiction":"","industry":[],"cve_archetypes":[],"cve_workflow_role":"","tags":["code-hygiene","platform","kubernetes","probes","resources","rollout"],"facets":["code-hygiene","audit","remediation"],"quality":{"score":100,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context","multi-facet"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"security-recipes.ai contributors","team":"Security Engineering","model":"gpt-5-codex","ai_assisted":false,"generated_by":"","date":"2026-08-21","zero_day":false,"last_updated":"2026-08-21","summary":"Kubernetes probe, resource, and rollout hygiene: Make probes, resources, disruption, and rollout settings internally consistent.","content_text":"<!-- Generated by scripts/synccodehygiene_recipes.py; edit data/code-hygiene/catalog.json. --> A tool-agnostic recipe to make probes, resources, disruption, and rollout settings internally consistent. It supports a read-only audit and, when explicitly authorized, a narrow remediation. When to use it Use this recipe when the operator's specific objective is to make probes, resources, disruption, and rollout settings internally consistent. Prefer a narrower CVE, scanner-finding, security-audit, or compliance-evidence recipe when that is the operator's actual job. Inputs Repository root and the files, package, service, or module in scope. Requested mode: audit or explicitly authorized fix. Supported runtime, compiler, framework, operating-system, and deployment versions inferred from repository files. Existing formatter, compiler, analyzer, test, build, and package-manager commands. Public API, compatibility, performance, generated-code, vendor, and migration constraints. The prompt ~~~markdown You are running the Security Recipes code-hygiene workflow code-hygiene.platform.kubernetes-probe-resource-and-rollout-hygiene. Start read-only. Do not edit files until the operator explicitly authorizes a fix. Use repository configuration and installed tool versions as authoritative; do not impose a new style or toolchain. Scope Your bounded objective is to make probes, resources, disruption, and rollout settings internally consistent. Inspect only operator-scoped, first-party source and configuration. Exclude generated, vendored, minified, fixture snapshot, lock history, and migration history unless explicitly included. Detection Inspect startup, readiness, and liveness probes; requests and limits; termination grace; strategy; disruption budgets; and autoscaling inputs. Relate probe endpoints to actual dependency and startup behavior visible in code. Record file and symbol evidence for every candidate. Mark uncertain or dynamically reachable behavior instead of guessing. Fix, only when authorized Correct contradictory or clearly invalid configuration while leaving capacity and SLO choices to owners. Keep the diff limited to the proven issue and its focused tests. Preserve public behavior, API compatibility, and repository conventions. Do not add or broaden suppressions, weaken diagnostics, mass-format unrelated files, upgrade dependencies, or mutate external state. Verification Render and validate manifests and test probe endpoints and graceful shutdown locally where possible. Compare diagnostic counts and relevant behavior before and after. Report every command, result, and check that could not run. Stop conditions Stop before choosing production resource values, availability budgets, or rollout percentages without operational evidence. Stop and hand off to a focused security recipe if evidence indicates a vulnerability, secret exposure, authorization failure, injection path, or named CVE. Stop rather than widening scope when the safe result requires architecture, product, compliance, operational, or data-owner decisions. ~~~ Output contract Scope and repository evidence reviewed. A candidate table with file or symbol, evidence, confidence, and disposition. In audit mode: no edits, plus the smallest safe next action for each confirmed item. In fix mode: one bounded patch, focused regression coverage, and no unrelated cleanup. Commands run, results, remaining uncertainty, and any stop-condition handoff. Verification Render and validate manifests and test probe endpoints and graceful shutdown locally where possible. Confirm that diagnostic configuration, suppressions, public interfaces, generated files, vendored files, and dependencies did not change outside the authorized scope. Review the final diff for behavior changes and run the repository's focused checks before broader suites. Guardrails Read-only until edits are explicitly authorized. Do not deploy, publish, rotate secrets, alter cloud or database state, change CI permissions, or open external tickets. Do not hide debt by disabling rules, adding retries or sleeps, weakening tests, broadening ignores, or lowering warning levels. Treat generated, vendored, minified, migration-history, and fixture-snapshot files as out of scope unless explicitly named. Stop before choosing production resource values, availability budgets, or rollout percentages without operational evidence. Related recipes Terraform format, validation, and provider-lock hygiene Terraform state-address and refactor safety Browse all code-hygiene recipes References NIST SP 800-218 Secure Software Development Framework 1.1 — NIST Terraform validate command — HashiCorp Docker build best practices — Docker Kubernetes configuration good practices — Kubernetes GitHub Actions workflow syntax — GitHub Kubernetes liveness, readiness, and startup probes — Kubernetes","agent_handoff":{"mcp_lookup_keys":["kubernetes-probe-resource-and-rollout-hygiene","/recipes/general/code-hygiene/platform/kubernetes-probe-resource-and-rollout-hygiene/","recipes/general/code-hygiene/platform/kubernetes-probe-resource-and-rollout-hygiene.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["code-hygiene","audit","remediation"],"source_text_field":"content_text","portable_download":"security-recipe-kubernetes-probe-resource-and-rollout-hygiene.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-kubernetes-probe-resource-and-rollout-hygiene.json"}},{"slug":"kubernetes-schema-deprecation-and-selector-drift","title":"Kubernetes schema, deprecation, and selector drift","link_title":"Kubernetes schema, deprecation, and selector drift","url":"https://security-recipes.ai/recipes/general/code-hygiene/platform/kubernetes-schema-deprecation-and-selector-drift/","path":"/recipes/general/code-hygiene/platform/kubernetes-schema-deprecation-and-selector-drift/","source_file":"recipes/general/code-hygiene/platform/kubernetes-schema-deprecation-and-selector-drift.md","recipe_id":"code-hygiene.platform.kubernetes-schema-deprecation-and-selector-drift","recipe_kind":"code-hygiene","category":{"slug":"code-hygiene","label":"Code Hygiene"},"agent":"general","severity":"unspecified","maturity":"development","ecosystem":"kubernetes/manifests","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"","framework_version":"","jurisdiction":"","industry":[],"cve_archetypes":[],"cve_workflow_role":"","tags":["code-hygiene","platform","kubernetes","schema","deprecation","selectors"],"facets":["code-hygiene","audit","remediation"],"quality":{"score":100,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context","multi-facet"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"security-recipes.ai contributors","team":"Security Engineering","model":"gpt-5-codex","ai_assisted":false,"generated_by":"","date":"2026-08-21","zero_day":false,"last_updated":"2026-08-21","summary":"Kubernetes schema, deprecation, and selector drift: Remove deprecated fields and prevent selector and label contract drift.","content_text":"<!-- Generated by scripts/synccodehygiene_recipes.py; edit data/code-hygiene/catalog.json. --> A tool-agnostic recipe to remove deprecated fields and prevent selector and label contract drift. It supports a read-only audit and, when explicitly authorized, a narrow remediation. When to use it Use this recipe when the operator's specific objective is to remove deprecated fields and prevent selector and label contract drift. Prefer a narrower CVE, scanner-finding, security-audit, or compliance-evidence recipe when that is the operator's actual job. Inputs Repository root and the files, package, service, or module in scope. Requested mode: audit or explicitly authorized fix. Supported runtime, compiler, framework, operating-system, and deployment versions inferred from repository files. Existing formatter, compiler, analyzer, test, build, and package-manager commands. Public API, compatibility, performance, generated-code, vendor, and migration constraints. The prompt ~~~markdown You are running the Security Recipes code-hygiene workflow code-hygiene.platform.kubernetes-schema-deprecation-and-selector-drift. Start read-only. Do not edit files until the operator explicitly authorizes a fix. Use repository configuration and installed tool versions as authoritative; do not impose a new style or toolchain. Scope Your bounded objective is to remove deprecated fields and prevent selector and label contract drift. Inspect only operator-scoped, first-party source and configuration. Exclude generated, vendored, minified, fixture snapshot, lock history, and migration history unless explicitly included. Detection Render manifests and inspect apiVersion, schema validation, immutable selectors, labels, patches, CRDs, and target cluster versions. Compare base and overlay outputs rather than editing templates in isolation. Record file and symbol evidence for every candidate. Mark uncertain or dynamically reachable behavior instead of guessing. Fix, only when authorized Use supported APIs and align labels and selectors without changing resource identity unintentionally. Keep the diff limited to the proven issue and its focused tests. Preserve public behavior, API compatibility, and repository conventions. Do not add or broaden suppressions, weaken diagnostics, mass-format unrelated files, upgrade dependencies, or mutate external state. Verification Render every overlay and run server-side or version-matched validation without applying resources. Compare diagnostic counts and relevant behavior before and after. Report every command, result, and check that could not run. Stop conditions Stop if migration changes immutable fields, CRDs, resource identity, or requires cluster access. Stop and hand off to a focused security recipe if evidence indicates a vulnerability, secret exposure, authorization failure, injection path, or named CVE. Stop rather than widening scope when the safe result requires architecture, product, compliance, operational, or data-owner decisions. ~~~ Output contract Scope and repository evidence reviewed. A candidate table with file or symbol, evidence, confidence, and disposition. In audit mode: no edits, plus the smallest safe next action for each confirmed item. In fix mode: one bounded patch, focused regression coverage, and no unrelated cleanup. Commands run, results, remaining uncertainty, and any stop-condition handoff. Verification Render every overlay and run server-side or version-matched validation without applying resources. Confirm that diagnostic configuration, suppressions, public interfaces, generated files, vendored files, and dependencies did not change outside the authorized scope. Review the final diff for behavior changes and run the repository's focused checks before broader suites. Guardrails Read-only until edits are explicitly authorized. Do not deploy, publish, rotate secrets, alter cloud or database state, change CI permissions, or open external tickets. Do not hide debt by disabling rules, adding retries or sleeps, weakening tests, broadening ignores, or lowering warning levels. Treat generated, vendored, minified, migration-history, and fixture-snapshot files as out of scope unless explicitly named. Stop if migration changes immutable fields, CRDs, resource identity, or requires cluster access. Related recipes Terraform format, validation, and provider-lock hygiene Terraform state-address and refactor safety Browse all code-hygiene recipes References NIST SP 800-218 Secure Software Development Framework 1.1 — NIST Terraform validate command — HashiCorp Docker build best practices — Docker Kubernetes configuration good practices — Kubernetes GitHub Actions workflow syntax — GitHub","agent_handoff":{"mcp_lookup_keys":["kubernetes-schema-deprecation-and-selector-drift","/recipes/general/code-hygiene/platform/kubernetes-schema-deprecation-and-selector-drift/","recipes/general/code-hygiene/platform/kubernetes-schema-deprecation-and-selector-drift.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["code-hygiene","audit","remediation"],"source_text_field":"content_text","portable_download":"security-recipe-kubernetes-schema-deprecation-and-selector-drift.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-kubernetes-schema-deprecation-and-selector-drift.json"}},{"slug":"terraform-fmt-validate-and-provider-lock","title":"Terraform format, validation, and provider-lock hygiene","link_title":"Terraform format, validation, and provider-lock hygiene","url":"https://security-recipes.ai/recipes/general/code-hygiene/platform/terraform-fmt-validate-and-provider-lock/","path":"/recipes/general/code-hygiene/platform/terraform-fmt-validate-and-provider-lock/","source_file":"recipes/general/code-hygiene/platform/terraform-fmt-validate-and-provider-lock.md","recipe_id":"code-hygiene.platform.terraform-fmt-validate-and-provider-lock","recipe_kind":"code-hygiene","category":{"slug":"code-hygiene","label":"Code Hygiene"},"agent":"general","severity":"unspecified","maturity":"development","ecosystem":"terraform/providers","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"","framework_version":"","jurisdiction":"","industry":[],"cve_archetypes":[],"cve_workflow_role":"","tags":["code-hygiene","platform","terraform","fmt","validate","provider-lock"],"facets":["code-hygiene","audit","remediation"],"quality":{"score":100,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context","multi-facet"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"security-recipes.ai contributors","team":"Security Engineering","model":"gpt-5-codex","ai_assisted":false,"generated_by":"","date":"2026-08-21","zero_day":false,"last_updated":"2026-08-21","summary":"Terraform format, validation, and provider-lock hygiene: Keep configuration canonical and provider resolution reproducible.","content_text":"<!-- Generated by scripts/synccodehygiene_recipes.py; edit data/code-hygiene/catalog.json. --> A tool-agnostic recipe to keep configuration canonical and provider resolution reproducible. It supports a read-only audit and, when explicitly authorized, a narrow remediation. When to use it Use this recipe when the operator's specific objective is to keep configuration canonical and provider resolution reproducible. Prefer a narrower CVE, scanner-finding, security-audit, or compliance-evidence recipe when that is the operator's actual job. Inputs Repository root and the files, package, service, or module in scope. Requested mode: audit or explicitly authorized fix. Supported runtime, compiler, framework, operating-system, and deployment versions inferred from repository files. Existing formatter, compiler, analyzer, test, build, and package-manager commands. Public API, compatibility, performance, generated-code, vendor, and migration constraints. The prompt ~~~markdown You are running the Security Recipes code-hygiene workflow code-hygiene.platform.terraform-fmt-validate-and-provider-lock. Start read-only. Do not edit files until the operator explicitly authorizes a fix. Use repository configuration and installed tool versions as authoritative; do not impose a new style or toolchain. Scope Your bounded objective is to keep configuration canonical and provider resolution reproducible. Inspect only operator-scoped, first-party source and configuration. Exclude generated, vendored, minified, fixture snapshot, lock history, and migration history unless explicitly included. Detection Inventory Terraform versions, required providers, lock hashes, modules, generated configuration, and workspace boundaries. Run formatting and validation without accessing remote backends where possible. Record file and symbol evidence for every candidate. Mark uncertain or dynamically reachable behavior instead of guessing. Fix, only when authorized Apply canonical formatting and regenerate lock metadata only with the declared toolchain and intended platforms. Keep the diff limited to the proven issue and its focused tests. Preserve public behavior, API compatibility, and repository conventions. Do not add or broaden suppressions, weaken diagnostics, mass-format unrelated files, upgrade dependencies, or mutate external state. Verification Run fmt check, init with backend disabled where suitable, validate, and a reviewed plan for affected roots. Compare diagnostic counts and relevant behavior before and after. Report every command, result, and check that could not run. Stop conditions Stop on provider upgrades, backend access, lock hash provenance uncertainty, or state mutation. Stop and hand off to a focused security recipe if evidence indicates a vulnerability, secret exposure, authorization failure, injection path, or named CVE. Stop rather than widening scope when the safe result requires architecture, product, compliance, operational, or data-owner decisions. ~~~ Output contract Scope and repository evidence reviewed. A candidate table with file or symbol, evidence, confidence, and disposition. In audit mode: no edits, plus the smallest safe next action for each confirmed item. In fix mode: one bounded patch, focused regression coverage, and no unrelated cleanup. Commands run, results, remaining uncertainty, and any stop-condition handoff. Verification Run fmt check, init with backend disabled where suitable, validate, and a reviewed plan for affected roots. Confirm that diagnostic configuration, suppressions, public interfaces, generated files, vendored files, and dependencies did not change outside the authorized scope. Review the final diff for behavior changes and run the repository's focused checks before broader suites. Guardrails Read-only until edits are explicitly authorized. Do not deploy, publish, rotate secrets, alter cloud or database state, change CI permissions, or open external tickets. Do not hide debt by disabling rules, adding retries or sleeps, weakening tests, broadening ignores, or lowering warning levels. Treat generated, vendored, minified, migration-history, and fixture-snapshot files as out of scope unless explicitly named. Stop on provider upgrades, backend access, lock hash provenance uncertainty, or state mutation. Related recipes Terraform state-address and refactor safety Dockerfile layer, cache, and build-context hygiene Browse all code-hygiene recipes References NIST SP 800-218 Secure Software Development Framework 1.1 — NIST Terraform validate command — HashiCorp Docker build best practices — Docker Kubernetes configuration good practices — Kubernetes GitHub Actions workflow syntax — GitHub Terraform dependency lock file — HashiCorp","agent_handoff":{"mcp_lookup_keys":["terraform-fmt-validate-and-provider-lock","/recipes/general/code-hygiene/platform/terraform-fmt-validate-and-provider-lock/","recipes/general/code-hygiene/platform/terraform-fmt-validate-and-provider-lock.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["code-hygiene","audit","remediation"],"source_text_field":"content_text","portable_download":"security-recipe-terraform-fmt-validate-and-provider-lock.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-terraform-fmt-validate-and-provider-lock.json"}},{"slug":"terraform-state-address-and-refactor-safety","title":"Terraform state-address and refactor safety","link_title":"Terraform state-address and refactor safety","url":"https://security-recipes.ai/recipes/general/code-hygiene/platform/terraform-state-address-and-refactor-safety/","path":"/recipes/general/code-hygiene/platform/terraform-state-address-and-refactor-safety/","source_file":"recipes/general/code-hygiene/platform/terraform-state-address-and-refactor-safety.md","recipe_id":"code-hygiene.platform.terraform-state-address-and-refactor-safety","recipe_kind":"code-hygiene","category":{"slug":"code-hygiene","label":"Code Hygiene"},"agent":"general","severity":"unspecified","maturity":"development","ecosystem":"terraform/providers","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"","framework_version":"","jurisdiction":"","industry":[],"cve_archetypes":[],"cve_workflow_role":"","tags":["code-hygiene","platform","terraform","state","moved-blocks","refactor"],"facets":["code-hygiene","audit","remediation"],"quality":{"score":100,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context","multi-facet"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"security-recipes.ai contributors","team":"Security Engineering","model":"gpt-5-codex","ai_assisted":false,"generated_by":"","date":"2026-08-21","zero_day":false,"last_updated":"2026-08-21","summary":"Terraform state-address and refactor safety: Preserve resource identity through module and address refactors.","content_text":"<!-- Generated by scripts/synccodehygienerecipes.py; edit data/code-hygiene/catalog.json. --> A tool-agnostic recipe to preserve resource identity through module and address refactors. It supports a read-only audit and, when explicitly authorized, a narrow remediation. When to use it Use this recipe when the operator's specific objective is to preserve resource identity through module and address refactors. Prefer a narrower CVE, scanner-finding, security-audit, or compliance-evidence recipe when that is the operator's actual job. Inputs Repository root and the files, package, service, or module in scope. Requested mode: audit or explicitly authorized fix. Supported runtime, compiler, framework, operating-system, and deployment versions inferred from repository files. Existing formatter, compiler, analyzer, test, build, and package-manager commands. Public API, compatibility, performance, generated-code, vendor, and migration constraints. The prompt ~~~markdown You are running the Security Recipes code-hygiene workflow code-hygiene.platform.terraform-state-address-and-refactor-safety. Start read-only. Do not edit files until the operator explicitly authorizes a fix. Use repository configuration and installed tool versions as authoritative; do not impose a new style or toolchain. Scope Your bounded objective is to preserve resource identity through module and address refactors. Inspect only operator-scoped, first-party source and configuration. Exclude generated, vendored, minified, fixture snapshot, lock history, and migration history unless explicitly included. Detection Map current and desired resource addresses, foreach keys, module paths, imports, moved blocks, and state ownership. Identify destroy-create plans caused only by address changes. Record file and symbol evidence for every candidate. Mark uncertain or dynamically reachable behavior instead of guessing. Fix, only when authorized Use declarative moved blocks or an operator-reviewed state procedure without applying it automatically. Keep the diff limited to the proven issue and its focused tests. Preserve public behavior, API compatibility, and repository conventions. Do not add or broaden suppressions, weaken diagnostics, mass-format unrelated files, upgrade dependencies, or mutate external state. Verification Produce a plan showing address moves and no unintended create, destroy, or replacement actions. Compare diagnostic counts and relevant behavior before and after. Report every command, result, and check that could not run. Stop conditions Stop before state commands, apply, import, or ambiguous many-to-one address mapping. Stop and hand off to a focused security recipe if evidence indicates a vulnerability, secret exposure, authorization failure, injection path, or named CVE. Stop rather than widening scope when the safe result requires architecture, product, compliance, operational, or data-owner decisions. ~~~ Output contract Scope and repository evidence reviewed. A candidate table with file or symbol, evidence, confidence, and disposition. In audit mode: no edits, plus the smallest safe next action for each confirmed item. In fix mode: one bounded patch, focused regression coverage, and no unrelated cleanup. Commands run, results, remaining uncertainty, and any stop-condition handoff. Verification Produce a plan showing address moves and no unintended create, destroy, or replacement actions. Confirm that diagnostic configuration, suppressions, public interfaces, generated files, vendored files, and dependencies did not change outside the authorized scope. Review the final diff for behavior changes and run the repository's focused checks before broader suites. Guardrails Read-only until edits are explicitly authorized. Do not deploy, publish, rotate secrets, alter cloud or database state, change CI permissions, or open external tickets. Do not hide debt by disabling rules, adding retries or sleeps, weakening tests, broadening ignores, or lowering warning levels. Treat generated, vendored, minified, migration-history, and fixture-snapshot files as out of scope unless explicitly named. Stop before state commands, apply, import, or ambiguous many-to-one address mapping. Related recipes Terraform format, validation, and provider-lock hygiene Dockerfile layer, cache, and build-context hygiene Browse all code-hygiene recipes References NIST SP 800-218 Secure Software Development Framework 1.1 — NIST Terraform validate command — HashiCorp Docker build best practices — Docker Kubernetes configuration good practices — Kubernetes GitHub Actions workflow syntax — GitHub Terraform refactoring resources — HashiCorp","agent_handoff":{"mcp_lookup_keys":["terraform-state-address-and-refactor-safety","/recipes/general/code-hygiene/platform/terraform-state-address-and-refactor-safety/","recipes/general/code-hygiene/platform/terraform-state-address-and-refactor-safety.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["code-hygiene","audit","remediation"],"source_text_field":"content_text","portable_download":"security-recipe-terraform-state-address-and-refactor-safety.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-terraform-state-address-and-refactor-safety.json"}},{"slug":"python-asyncio-task-cancellation-and-timeouts","title":"Python asyncio task cancellation and timeouts","link_title":"Python asyncio task cancellation and timeouts","url":"https://security-recipes.ai/recipes/general/code-hygiene/python/python-asyncio-task-cancellation-and-timeouts/","path":"/recipes/general/code-hygiene/python/python-asyncio-task-cancellation-and-timeouts/","source_file":"recipes/general/code-hygiene/python/python-asyncio-task-cancellation-and-timeouts.md","recipe_id":"code-hygiene.python.python-asyncio-task-cancellation-and-timeouts","recipe_kind":"code-hygiene","category":{"slug":"code-hygiene","label":"Code Hygiene"},"agent":"general","severity":"unspecified","maturity":"development","ecosystem":"python/pypi","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"","framework_version":"","jurisdiction":"","industry":[],"cve_archetypes":[],"cve_workflow_role":"","tags":["code-hygiene","python","asyncio","cancellation","timeouts"],"facets":["code-hygiene","audit","remediation"],"quality":{"score":100,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context","multi-facet"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"security-recipes.ai contributors","team":"Security Engineering","model":"gpt-5-codex","ai_assisted":false,"generated_by":"","date":"2026-08-21","zero_day":false,"last_updated":"2026-08-21","summary":"Python asyncio task cancellation and timeouts: Eliminate orphaned tasks, swallowed cancellation, and unbounded awaits.","content_text":"<!-- Generated by scripts/synccodehygienerecipes.py; edit data/code-hygiene/catalog.json. --> A tool-agnostic recipe to eliminate orphaned tasks, swallowed cancellation, and unbounded awaits. It supports a read-only audit and, when explicitly authorized, a narrow remediation. When to use it Use this recipe when the operator's specific objective is to eliminate orphaned tasks, swallowed cancellation, and unbounded awaits. Prefer a narrower CVE, scanner-finding, security-audit, or compliance-evidence recipe when that is the operator's actual job. Inputs Repository root and the files, package, service, or module in scope. Requested mode: audit or explicitly authorized fix. Supported runtime, compiler, framework, operating-system, and deployment versions inferred from repository files. Existing formatter, compiler, analyzer, test, build, and package-manager commands. Public API, compatibility, performance, generated-code, vendor, and migration constraints. The prompt ~~~markdown You are running the Security Recipes code-hygiene workflow code-hygiene.python.python-asyncio-task-cancellation-and-timeouts. Start read-only. Do not edit files until the operator explicitly authorizes a fix. Use repository configuration and installed tool versions as authoritative; do not impose a new style or toolchain. Scope Your bounded objective is to eliminate orphaned tasks, swallowed cancellation, and unbounded awaits. Inspect only operator-scoped, first-party source and configuration. Exclude generated, vendored, minified, fixture snapshot, lock history, and migration history unless explicitly included. Detection Trace createtask ownership, TaskGroup use, cancellation propagation, timeout boundaries, and blocking calls. Find background tasks held only weakly or exceptions never observed. Record file and symbol evidence for every candidate. Mark uncertain or dynamically reachable behavior instead of guessing. Fix, only when authorized Use structured task ownership, explicit timeout boundaries, and finally cleanup while re-propagating cancellation. Keep the diff limited to the proven issue and its focused tests. Preserve public behavior, API compatibility, and repository conventions. Do not add or broaden suppressions, weaken diagnostics, mass-format unrelated files, upgrade dependencies, or mutate external state. Verification Test cancellation at each await, timeout expiry, child failure, shutdown, and task completion. Compare diagnostic counts and relevant behavior before and after. Report every command, result, and check that could not run. Stop conditions Stop if task lifetime is intentionally process-global but has no documented owner. Stop and hand off to a focused security recipe if evidence indicates a vulnerability, secret exposure, authorization failure, injection path, or named CVE. Stop rather than widening scope when the safe result requires architecture, product, compliance, operational, or data-owner decisions. ~~~ Output contract Scope and repository evidence reviewed. A candidate table with file or symbol, evidence, confidence, and disposition. In audit mode: no edits, plus the smallest safe next action for each confirmed item. In fix mode: one bounded patch, focused regression coverage, and no unrelated cleanup. Commands run, results, remaining uncertainty, and any stop-condition handoff. Verification Test cancellation at each await, timeout expiry, child failure, shutdown, and task completion. Confirm that diagnostic configuration, suppressions, public interfaces, generated files, vendored files, and dependencies did not change outside the authorized scope. Review the final diff for behavior changes and run the repository's focused checks before broader suites. Guardrails Read-only until edits are explicitly authorized. Do not deploy, publish, rotate secrets, alter cloud or database state, change CI permissions, or open external tickets. Do not hide debt by disabling rules, adding retries or sleeps, weakening tests, broadening ignores, or lowering warning levels. Treat generated, vendored, minified, migration-history, and fixture-snapshot files as out of scope unless explicitly named. Stop if task lifetime is intentionally process-global but has no documented owner. Related recipes Python typing Any and ignore debt Python mutable-default, dataclass, and sentinel hygiene Browse all code-hygiene recipes References NIST SP 800-218 Secure Software Development Framework 1.1 — NIST Python static typing documentation — Python Software Foundation Python asyncio coroutines and tasks — Python Software Foundation Python contextlib — Python Software Foundation","agent_handoff":{"mcp_lookup_keys":["python-asyncio-task-cancellation-and-timeouts","/recipes/general/code-hygiene/python/python-asyncio-task-cancellation-and-timeouts/","recipes/general/code-hygiene/python/python-asyncio-task-cancellation-and-timeouts.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["code-hygiene","audit","remediation"],"source_text_field":"content_text","portable_download":"security-recipe-python-asyncio-task-cancellation-and-timeouts.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-python-asyncio-task-cancellation-and-timeouts.json"}},{"slug":"python-exception-chaining-context-and-resource-lifecycle","title":"Python exception, context, and resource lifecycle","link_title":"Python exception, context, and resource lifecycle","url":"https://security-recipes.ai/recipes/general/code-hygiene/python/python-exception-chaining-context-and-resource-lifecycle/","path":"/recipes/general/code-hygiene/python/python-exception-chaining-context-and-resource-lifecycle/","source_file":"recipes/general/code-hygiene/python/python-exception-chaining-context-and-resource-lifecycle.md","recipe_id":"code-hygiene.python.python-exception-chaining-context-and-resource-lifecycle","recipe_kind":"code-hygiene","category":{"slug":"code-hygiene","label":"Code Hygiene"},"agent":"general","severity":"unspecified","maturity":"development","ecosystem":"python/pypi","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"","framework_version":"","jurisdiction":"","industry":[],"cve_archetypes":[],"cve_workflow_role":"","tags":["code-hygiene","python","exceptions","context-managers","resources"],"facets":["code-hygiene","audit","remediation"],"quality":{"score":100,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context","multi-facet"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"security-recipes.ai contributors","team":"Security Engineering","model":"gpt-5-codex","ai_assisted":false,"generated_by":"","date":"2026-08-21","zero_day":false,"last_updated":"2026-08-21","summary":"Python exception, context, and resource lifecycle: Preserve exception context and deterministically release files, locks, sessions, and generators.","content_text":"<!-- Generated by scripts/synccodehygiene_recipes.py; edit data/code-hygiene/catalog.json. --> A tool-agnostic recipe to preserve exception context and deterministically release files, locks, sessions, and generators. It supports a read-only audit and, when explicitly authorized, a narrow remediation. When to use it Use this recipe when the operator's specific objective is to preserve exception context and deterministically release files, locks, sessions, and generators. Prefer a narrower CVE, scanner-finding, security-audit, or compliance-evidence recipe when that is the operator's actual job. Inputs Repository root and the files, package, service, or module in scope. Requested mode: audit or explicitly authorized fix. Supported runtime, compiler, framework, operating-system, and deployment versions inferred from repository files. Existing formatter, compiler, analyzer, test, build, and package-manager commands. Public API, compatibility, performance, generated-code, vendor, and migration constraints. The prompt ~~~markdown You are running the Security Recipes code-hygiene workflow code-hygiene.python.python-exception-chaining-context-and-resource-lifecycle. Start read-only. Do not edit files until the operator explicitly authorizes a fix. Use repository configuration and installed tool versions as authoritative; do not impose a new style or toolchain. Scope Your bounded objective is to preserve exception context and deterministically release files, locks, sessions, and generators. Inspect only operator-scoped, first-party source and configuration. Exclude generated, vendored, minified, fixture snapshot, lock history, and migration history unless explicitly included. Detection Find broad catches, swallowed exceptions, raise-without-chaining, manual close paths, and generator cleanup gaps. Trace ownership across normal return, exception, cancellation, and partial initialization. Record file and symbol evidence for every candidate. Mark uncertain or dynamically reachable behavior instead of guessing. Fix, only when authorized Use narrow exception handling and context management at the resource owner. Keep the diff limited to the proven issue and its focused tests. Preserve public behavior, API compatibility, and repository conventions. Do not add or broaden suppressions, weaken diagnostics, mass-format unrelated files, upgrade dependencies, or mutate external state. Verification Test success and each failure edge while asserting cleanup and preserved exception cause. Compare diagnostic counts and relevant behavior before and after. Report every command, result, and check that could not run. Stop conditions Stop if changing exception types would break a documented caller contract. Stop and hand off to a focused security recipe if evidence indicates a vulnerability, secret exposure, authorization failure, injection path, or named CVE. Stop rather than widening scope when the safe result requires architecture, product, compliance, operational, or data-owner decisions. ~~~ Output contract Scope and repository evidence reviewed. A candidate table with file or symbol, evidence, confidence, and disposition. In audit mode: no edits, plus the smallest safe next action for each confirmed item. In fix mode: one bounded patch, focused regression coverage, and no unrelated cleanup. Commands run, results, remaining uncertainty, and any stop-condition handoff. Verification Test success and each failure edge while asserting cleanup and preserved exception cause. Confirm that diagnostic configuration, suppressions, public interfaces, generated files, vendored files, and dependencies did not change outside the authorized scope. Review the final diff for behavior changes and run the repository's focused checks before broader suites. Guardrails Read-only until edits are explicitly authorized. Do not deploy, publish, rotate secrets, alter cloud or database state, change CI permissions, or open external tickets. Do not hide debt by disabling rules, adding retries or sleeps, weakening tests, broadening ignores, or lowering warning levels. Treat generated, vendored, minified, migration-history, and fixture-snapshot files as out of scope unless explicitly named. Stop if changing exception types would break a documented caller contract. Related recipes Python typing Any and ignore debt Python mutable-default, dataclass, and sentinel hygiene Browse all code-hygiene recipes References NIST SP 800-218 Secure Software Development Framework 1.1 — NIST Python static typing documentation — Python Software Foundation Python asyncio coroutines and tasks — Python Software Foundation Python contextlib — Python Software Foundation","agent_handoff":{"mcp_lookup_keys":["python-exception-chaining-context-and-resource-lifecycle","/recipes/general/code-hygiene/python/python-exception-chaining-context-and-resource-lifecycle/","recipes/general/code-hygiene/python/python-exception-chaining-context-and-resource-lifecycle.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["code-hygiene","audit","remediation"],"source_text_field":"content_text","portable_download":"security-recipe-python-exception-chaining-context-and-resource-lifecycle.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-python-exception-chaining-context-and-resource-lifecycle.json"}},{"slug":"python-import-packaging-and-module-boundaries","title":"Python import, packaging, and module boundaries","link_title":"Python import, packaging, and module boundaries","url":"https://security-recipes.ai/recipes/general/code-hygiene/python/python-import-packaging-and-module-boundaries/","path":"/recipes/general/code-hygiene/python/python-import-packaging-and-module-boundaries/","source_file":"recipes/general/code-hygiene/python/python-import-packaging-and-module-boundaries.md","recipe_id":"code-hygiene.python.python-import-packaging-and-module-boundaries","recipe_kind":"code-hygiene","category":{"slug":"code-hygiene","label":"Code Hygiene"},"agent":"general","severity":"unspecified","maturity":"development","ecosystem":"python/pypi","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"","framework_version":"","jurisdiction":"","industry":[],"cve_archetypes":[],"cve_workflow_role":"","tags":["code-hygiene","python","imports","packaging","modules"],"facets":["code-hygiene","audit","remediation"],"quality":{"score":100,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context","multi-facet"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"security-recipes.ai contributors","team":"Security Engineering","model":"gpt-5-codex","ai_assisted":false,"generated_by":"","date":"2026-08-21","zero_day":false,"last_updated":"2026-08-21","summary":"Python import, packaging, and module boundaries: Remove import cycles and make package exports and runtime discovery explicit.","content_text":"<!-- Generated by scripts/synccodehygienerecipes.py; edit data/code-hygiene/catalog.json. --> A tool-agnostic recipe to remove import cycles and make package exports and runtime discovery explicit. It supports a read-only audit and, when explicitly authorized, a narrow remediation. When to use it Use this recipe when the operator's specific objective is to remove import cycles and make package exports and runtime discovery explicit. Prefer a narrower CVE, scanner-finding, security-audit, or compliance-evidence recipe when that is the operator's actual job. Inputs Repository root and the files, package, service, or module in scope. Requested mode: audit or explicitly authorized fix. Supported runtime, compiler, framework, operating-system, and deployment versions inferred from repository files. Existing formatter, compiler, analyzer, test, build, and package-manager commands. Public API, compatibility, performance, generated-code, vendor, and migration constraints. The prompt ~~~markdown You are running the Security Recipes code-hygiene workflow code-hygiene.python.python-import-packaging-and-module-boundaries. Start read-only. Do not edit files until the operator explicitly authorizes a fix. Use repository configuration and installed tool versions as authoritative; do not impose a new style or toolchain. Scope Your bounded objective is to remove import cycles and make package exports and runtime discovery explicit. Inspect only operator-scoped, first-party source and configuration. Exclude generated, vendored, minified, fixture snapshot, lock history, and migration history unless explicitly included. Detection Map imports, init__ exports, entry points, namespace packages, import-time side effects, and optional extras. Distinguish type-only cycles from runtime cycles and plugin discovery. Record file and symbol evidence for every candidate. Mark uncertain or dynamically reachable behavior instead of guessing. Fix, only when authorized Move shared contracts to stable modules and make exports and optional boundaries explicit. Keep the diff limited to the proven issue and its focused tests. Preserve public behavior, API compatibility, and repository conventions. Do not add or broaden suppressions, weaken diagnostics, mass-format unrelated files, upgrade dependencies, or mutate external state. Verification Build wheels and sdists, install into a clean environment, import public modules, and run entry points. Compare diagnostic counts and relevant behavior before and after. Report every command, result, and check that could not run. Stop conditions Stop on undocumented plugin loading or packaging behavior not covered by a clean-install test. Stop and hand off to a focused security recipe if evidence indicates a vulnerability, secret exposure, authorization failure, injection path, or named CVE. Stop rather than widening scope when the safe result requires architecture, product, compliance, operational, or data-owner decisions. ~~~ Output contract Scope and repository evidence reviewed. A candidate table with file or symbol, evidence, confidence, and disposition. In audit mode: no edits, plus the smallest safe next action for each confirmed item. In fix mode: one bounded patch, focused regression coverage, and no unrelated cleanup. Commands run, results, remaining uncertainty, and any stop-condition handoff. Verification Build wheels and sdists, install into a clean environment, import public modules, and run entry points. Confirm that diagnostic configuration, suppressions, public interfaces, generated files, vendored files, and dependencies did not change outside the authorized scope. Review the final diff for behavior changes and run the repository's focused checks before broader suites. Guardrails Read-only until edits are explicitly authorized. Do not deploy, publish, rotate secrets, alter cloud or database state, change CI permissions, or open external tickets. Do not hide debt by disabling rules, adding retries or sleeps, weakening tests, broadening ignores, or lowering warning levels. Treat generated, vendored, minified, migration-history, and fixture-snapshot files as out of scope unless explicitly named. Stop on undocumented plugin loading or packaging behavior not covered by a clean-install test. Related recipes Python typing Any and ignore debt Python mutable-default, dataclass, and sentinel hygiene Browse all code-hygiene recipes References NIST SP 800-218 Secure Software Development Framework 1.1 — NIST Python static typing documentation — Python Software Foundation Python asyncio coroutines and tasks — Python Software Foundation Python contextlib — Python Software Foundation Python import system — Python Software Foundation","agent_handoff":{"mcp_lookup_keys":["python-import-packaging-and-module-boundaries","/recipes/general/code-hygiene/python/python-import-packaging-and-module-boundaries/","recipes/general/code-hygiene/python/python-import-packaging-and-module-boundaries.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["code-hygiene","audit","remediation"],"source_text_field":"content_text","portable_download":"security-recipe-python-import-packaging-and-module-boundaries.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-python-import-packaging-and-module-boundaries.json"}},{"slug":"python-mutable-default-dataclass-and-sentinel-hygiene","title":"Python mutable-default, dataclass, and sentinel hygiene","link_title":"Python mutable-default, dataclass, and sentinel hygiene","url":"https://security-recipes.ai/recipes/general/code-hygiene/python/python-mutable-default-dataclass-and-sentinel-hygiene/","path":"/recipes/general/code-hygiene/python/python-mutable-default-dataclass-and-sentinel-hygiene/","source_file":"recipes/general/code-hygiene/python/python-mutable-default-dataclass-and-sentinel-hygiene.md","recipe_id":"code-hygiene.python.python-mutable-default-dataclass-and-sentinel-hygiene","recipe_kind":"code-hygiene","category":{"slug":"code-hygiene","label":"Code Hygiene"},"agent":"general","severity":"unspecified","maturity":"development","ecosystem":"python/pypi","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"","framework_version":"","jurisdiction":"","industry":[],"cve_archetypes":[],"cve_workflow_role":"","tags":["code-hygiene","python","dataclasses","mutable-defaults","sentinels"],"facets":["code-hygiene","audit","remediation"],"quality":{"score":100,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context","multi-facet"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"security-recipes.ai contributors","team":"Security Engineering","model":"gpt-5-codex","ai_assisted":false,"generated_by":"","date":"2026-08-21","zero_day":false,"last_updated":"2026-08-21","summary":"Python mutable-default, dataclass, and sentinel hygiene: Remove shared mutable defaults and ambiguous sentinel values.","content_text":"<!-- Generated by scripts/synccodehygienerecipes.py; edit data/code-hygiene/catalog.json. --> A tool-agnostic recipe to remove shared mutable defaults and ambiguous sentinel values. It supports a read-only audit and, when explicitly authorized, a narrow remediation. When to use it Use this recipe when the operator's specific objective is to remove shared mutable defaults and ambiguous sentinel values. Prefer a narrower CVE, scanner-finding, security-audit, or compliance-evidence recipe when that is the operator's actual job. Inputs Repository root and the files, package, service, or module in scope. Requested mode: audit or explicitly authorized fix. Supported runtime, compiler, framework, operating-system, and deployment versions inferred from repository files. Existing formatter, compiler, analyzer, test, build, and package-manager commands. Public API, compatibility, performance, generated-code, vendor, and migration constraints. The prompt ~~~markdown You are running the Security Recipes code-hygiene workflow code-hygiene.python.python-mutable-default-dataclass-and-sentinel-hygiene. Start read-only. Do not edit files until the operator explicitly authorizes a fix. Use repository configuration and installed tool versions as authoritative; do not impose a new style or toolchain. Scope Your bounded objective is to remove shared mutable defaults and ambiguous sentinel values. Inspect only operator-scoped, first-party source and configuration. Exclude generated, vendored, minified, fixture snapshot, lock history, and migration history unless explicitly included. Detection Find mutable parameter and field defaults, reused class state, and None overloaded as both data and absence. Inspect dataclass equality, ordering, frozen, slots, and defaultfactory behavior. Record file and symbol evidence for every candidate. Mark uncertain or dynamically reachable behavior instead of guessing. Fix, only when authorized Use factories or private sentinels while preserving signatures, serialization, and equality contracts. Keep the diff limited to the proven issue and its focused tests. Preserve public behavior, API compatibility, and repository conventions. Do not add or broaden suppressions, weaken diagnostics, mass-format unrelated files, upgrade dependencies, or mutate external state. Verification Test repeated construction, mutation isolation, omitted versus explicit null values, and serialization. Compare diagnostic counts and relevant behavior before and after. Report every command, result, and check that could not run. Stop conditions Stop if sentinel changes affect a public API or persisted representation without compatibility handling. Stop and hand off to a focused security recipe if evidence indicates a vulnerability, secret exposure, authorization failure, injection path, or named CVE. Stop rather than widening scope when the safe result requires architecture, product, compliance, operational, or data-owner decisions. ~~~ Output contract Scope and repository evidence reviewed. A candidate table with file or symbol, evidence, confidence, and disposition. In audit mode: no edits, plus the smallest safe next action for each confirmed item. In fix mode: one bounded patch, focused regression coverage, and no unrelated cleanup. Commands run, results, remaining uncertainty, and any stop-condition handoff. Verification Test repeated construction, mutation isolation, omitted versus explicit null values, and serialization. Confirm that diagnostic configuration, suppressions, public interfaces, generated files, vendored files, and dependencies did not change outside the authorized scope. Review the final diff for behavior changes and run the repository's focused checks before broader suites. Guardrails Read-only until edits are explicitly authorized. Do not deploy, publish, rotate secrets, alter cloud or database state, change CI permissions, or open external tickets. Do not hide debt by disabling rules, adding retries or sleeps, weakening tests, broadening ignores, or lowering warning levels. Treat generated, vendored, minified, migration-history, and fixture-snapshot files as out of scope unless explicitly named. Stop if sentinel changes affect a public API or persisted representation without compatibility handling. Related recipes Python typing Any and ignore debt Python exception, context, and resource lifecycle Browse all code-hygiene recipes References NIST SP 800-218 Secure Software Development Framework 1.1 — NIST Python static typing documentation — Python Software Foundation Python asyncio coroutines and tasks — Python Software Foundation Python contextlib — Python Software Foundation Python dataclasses — Python Software Foundation","agent_handoff":{"mcp_lookup_keys":["python-mutable-default-dataclass-and-sentinel-hygiene","/recipes/general/code-hygiene/python/python-mutable-default-dataclass-and-sentinel-hygiene/","recipes/general/code-hygiene/python/python-mutable-default-dataclass-and-sentinel-hygiene.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["code-hygiene","audit","remediation"],"source_text_field":"content_text","portable_download":"security-recipe-python-mutable-default-dataclass-and-sentinel-hygiene.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-python-mutable-default-dataclass-and-sentinel-hygiene.json"}},{"slug":"python-typing-any-and-ignore-debt","title":"Python typing Any and ignore debt","link_title":"Python typing Any and ignore debt","url":"https://security-recipes.ai/recipes/general/code-hygiene/python/python-typing-any-and-ignore-debt/","path":"/recipes/general/code-hygiene/python/python-typing-any-and-ignore-debt/","source_file":"recipes/general/code-hygiene/python/python-typing-any-and-ignore-debt.md","recipe_id":"code-hygiene.python.python-typing-any-and-ignore-debt","recipe_kind":"code-hygiene","category":{"slug":"code-hygiene","label":"Code Hygiene"},"agent":"general","severity":"unspecified","maturity":"development","ecosystem":"python/pypi","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"","framework_version":"","jurisdiction":"","industry":[],"cve_archetypes":[],"cve_workflow_role":"","tags":["code-hygiene","python","typing","any","type-ignore"],"facets":["code-hygiene","audit","remediation"],"quality":{"score":100,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context","multi-facet"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"security-recipes.ai contributors","team":"Security Engineering","model":"gpt-5-codex","ai_assisted":false,"generated_by":"","date":"2026-08-21","zero_day":false,"last_updated":"2026-08-21","summary":"Python typing Any and ignore debt: Narrow Any, casts, and type-ignore suppressions at trusted boundaries.","content_text":"<!-- Generated by scripts/synccodehygiene_recipes.py; edit data/code-hygiene/catalog.json. --> A tool-agnostic recipe to narrow Any, casts, and type-ignore suppressions at trusted boundaries. It supports a read-only audit and, when explicitly authorized, a narrow remediation. When to use it Use this recipe when the operator's specific objective is to narrow Any, casts, and type-ignore suppressions at trusted boundaries. Prefer a narrower CVE, scanner-finding, security-audit, or compliance-evidence recipe when that is the operator's actual job. Inputs Repository root and the files, package, service, or module in scope. Requested mode: audit or explicitly authorized fix. Supported runtime, compiler, framework, operating-system, and deployment versions inferred from repository files. Existing formatter, compiler, analyzer, test, build, and package-manager commands. Public API, compatibility, performance, generated-code, vendor, and migration constraints. The prompt ~~~markdown You are running the Security Recipes code-hygiene workflow code-hygiene.python.python-typing-any-and-ignore-debt. Start read-only. Do not edit files until the operator explicitly authorizes a fix. Use repository configuration and installed tool versions as authoritative; do not impose a new style or toolchain. Scope Your bounded objective is to narrow Any, casts, and type-ignore suppressions at trusted boundaries. Inspect only operator-scoped, first-party source and configuration. Exclude generated, vendored, minified, fixture snapshot, lock history, and migration history unless explicitly included. Detection Read the configured type checker and inventory explicit Any, implicit Any, casts, and ignore codes. Separate untyped third-party boundaries from application-owned types. Record file and symbol evidence for every candidate. Mark uncertain or dynamically reachable behavior instead of guessing. Fix, only when authorized Add precise annotations, protocols, overloads, or runtime narrowing without annotation-only lies. Keep the diff limited to the proven issue and its focused tests. Preserve public behavior, API compatibility, and repository conventions. Do not add or broaden suppressions, weaken diagnostics, mass-format unrelated files, upgrade dependencies, or mutate external state. Verification Run the configured type checker and focused runtime tests with no broader ignores. Compare diagnostic counts and relevant behavior before and after. Report every command, result, and check that could not run. Stop conditions Stop if the change requires falsifying runtime behavior or publishing incompatible type declarations. Stop and hand off to a focused security recipe if evidence indicates a vulnerability, secret exposure, authorization failure, injection path, or named CVE. Stop rather than widening scope when the safe result requires architecture, product, compliance, operational, or data-owner decisions. ~~~ Output contract Scope and repository evidence reviewed. A candidate table with file or symbol, evidence, confidence, and disposition. In audit mode: no edits, plus the smallest safe next action for each confirmed item. In fix mode: one bounded patch, focused regression coverage, and no unrelated cleanup. Commands run, results, remaining uncertainty, and any stop-condition handoff. Verification Run the configured type checker and focused runtime tests with no broader ignores. Confirm that diagnostic configuration, suppressions, public interfaces, generated files, vendored files, and dependencies did not change outside the authorized scope. Review the final diff for behavior changes and run the repository's focused checks before broader suites. Guardrails Read-only until edits are explicitly authorized. Do not deploy, publish, rotate secrets, alter cloud or database state, change CI permissions, or open external tickets. Do not hide debt by disabling rules, adding retries or sleeps, weakening tests, broadening ignores, or lowering warning levels. Treat generated, vendored, minified, migration-history, and fixture-snapshot files as out of scope unless explicitly named. Stop if the change requires falsifying runtime behavior or publishing incompatible type declarations. Related recipes Python mutable-default, dataclass, and sentinel hygiene Python exception, context, and resource lifecycle Browse all code-hygiene recipes References NIST SP 800-218 Secure Software Development Framework 1.1 — NIST Python static typing documentation — Python Software Foundation Python asyncio coroutines and tasks — Python Software Foundation Python contextlib — Python Software Foundation","agent_handoff":{"mcp_lookup_keys":["python-typing-any-and-ignore-debt","/recipes/general/code-hygiene/python/python-typing-any-and-ignore-debt/","recipes/general/code-hygiene/python/python-typing-any-and-ignore-debt.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["code-hygiene","audit","remediation"],"source_text_field":"content_text","portable_download":"security-recipe-python-typing-any-and-ignore-debt.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-python-typing-any-and-ignore-debt.json"}},{"slug":"rails-query-transaction-and-callback-hygiene","title":"Rails query, transaction, and callback hygiene","link_title":"Rails query, transaction, and callback hygiene","url":"https://security-recipes.ai/recipes/general/code-hygiene/ruby/rails-query-transaction-and-callback-hygiene/","path":"/recipes/general/code-hygiene/ruby/rails-query-transaction-and-callback-hygiene/","source_file":"recipes/general/code-hygiene/ruby/rails-query-transaction-and-callback-hygiene.md","recipe_id":"code-hygiene.ruby.rails-query-transaction-and-callback-hygiene","recipe_kind":"code-hygiene","category":{"slug":"code-hygiene","label":"Code Hygiene"},"agent":"general","severity":"unspecified","maturity":"development","ecosystem":"ruby/bundler","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"","framework_version":"","jurisdiction":"","industry":[],"cve_archetypes":[],"cve_workflow_role":"","tags":["code-hygiene","ruby","rails","active-record","transactions","n-plus-one"],"facets":["code-hygiene","audit","remediation"],"quality":{"score":100,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context","multi-facet"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"security-recipes.ai contributors","team":"Security Engineering","model":"gpt-5-codex","ai_assisted":false,"generated_by":"","date":"2026-08-21","zero_day":false,"last_updated":"2026-08-21","summary":"Rails query, transaction, and callback hygiene: Make Active Record query count, transaction scope, and callback side effects explicit.","content_text":"<!-- Generated by scripts/synccodehygiene_recipes.py; edit data/code-hygiene/catalog.json. --> A tool-agnostic recipe to make Active Record query count, transaction scope, and callback side effects explicit. It supports a read-only audit and, when explicitly authorized, a narrow remediation. When to use it Use this recipe when the operator's specific objective is to make Active Record query count, transaction scope, and callback side effects explicit. Prefer a narrower CVE, scanner-finding, security-audit, or compliance-evidence recipe when that is the operator's actual job. Inputs Repository root and the files, package, service, or module in scope. Requested mode: audit or explicitly authorized fix. Supported runtime, compiler, framework, operating-system, and deployment versions inferred from repository files. Existing formatter, compiler, analyzer, test, build, and package-manager commands. Public API, compatibility, performance, generated-code, vendor, and migration constraints. The prompt ~~~markdown You are running the Security Recipes code-hygiene workflow code-hygiene.ruby.rails-query-transaction-and-callback-hygiene. Start read-only. Do not edit files until the operator explicitly authorizes a fix. Use repository configuration and installed tool versions as authoritative; do not impose a new style or toolchain. Scope Your bounded objective is to make Active Record query count, transaction scope, and callback side effects explicit. Inspect only operator-scoped, first-party source and configuration. Exclude generated, vendored, minified, fixture snapshot, lock history, and migration history unless explicitly included. Detection Trace relation materialization, associations, per-row queries, transactions, callbacks, validations, and after-commit work. Identify callbacks whose network or queue side effects occur before commit. Record file and symbol evidence for every candidate. Mark uncertain or dynamically reachable behavior instead of guessing. Fix, only when authorized Preload or batch intentionally and move side effects to an explicit post-commit owner. Keep the diff limited to the proven issue and its focused tests. Preserve public behavior, API compatibility, and repository conventions. Do not add or broaden suppressions, weaken diagnostics, mass-format unrelated files, upgrade dependencies, or mutate external state. Verification Assert query counts, rollback behavior, callback ordering, and representative result sets. Compare diagnostic counts and relevant behavior before and after. Report every command, result, and check that could not run. Stop conditions Stop if indexing, production data distribution, or domain transaction semantics require owner decisions. Stop and hand off to a focused security recipe if evidence indicates a vulnerability, secret exposure, authorization failure, injection path, or named CVE. Stop rather than widening scope when the safe result requires architecture, product, compliance, operational, or data-owner decisions. ~~~ Output contract Scope and repository evidence reviewed. A candidate table with file or symbol, evidence, confidence, and disposition. In audit mode: no edits, plus the smallest safe next action for each confirmed item. In fix mode: one bounded patch, focused regression coverage, and no unrelated cleanup. Commands run, results, remaining uncertainty, and any stop-condition handoff. Verification Assert query counts, rollback behavior, callback ordering, and representative result sets. Confirm that diagnostic configuration, suppressions, public interfaces, generated files, vendored files, and dependencies did not change outside the authorized scope. Review the final diff for behavior changes and run the repository's focused checks before broader suites. Guardrails Read-only until edits are explicitly authorized. Do not deploy, publish, rotate secrets, alter cloud or database state, change CI permissions, or open external tickets. Do not hide debt by disabling rules, adding retries or sleeps, weakening tests, broadening ignores, or lowering warning levels. Treat generated, vendored, minified, migration-history, and fixture-snapshot files as out of scope unless explicitly named. Stop if indexing, production data distribution, or domain transaction semantics require owner decisions. Related recipes Ruby RuboCop baseline and disable debt Lint warning baseline and budget Browse all code-hygiene recipes References NIST SP 800-218 Secure Software Development Framework 1.1 — NIST RuboCop documentation — RuboCop Rails Active Record query interface — Ruby on Rails","agent_handoff":{"mcp_lookup_keys":["rails-query-transaction-and-callback-hygiene","/recipes/general/code-hygiene/ruby/rails-query-transaction-and-callback-hygiene/","recipes/general/code-hygiene/ruby/rails-query-transaction-and-callback-hygiene.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["code-hygiene","audit","remediation"],"source_text_field":"content_text","portable_download":"security-recipe-rails-query-transaction-and-callback-hygiene.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-rails-query-transaction-and-callback-hygiene.json"}},{"slug":"ruby-rubocop-baseline-and-disable-debt","title":"Ruby RuboCop baseline and disable debt","link_title":"Ruby RuboCop baseline and disable debt","url":"https://security-recipes.ai/recipes/general/code-hygiene/ruby/ruby-rubocop-baseline-and-disable-debt/","path":"/recipes/general/code-hygiene/ruby/ruby-rubocop-baseline-and-disable-debt/","source_file":"recipes/general/code-hygiene/ruby/ruby-rubocop-baseline-and-disable-debt.md","recipe_id":"code-hygiene.ruby.ruby-rubocop-baseline-and-disable-debt","recipe_kind":"code-hygiene","category":{"slug":"code-hygiene","label":"Code Hygiene"},"agent":"general","severity":"unspecified","maturity":"development","ecosystem":"ruby/bundler","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"","framework_version":"","jurisdiction":"","industry":[],"cve_archetypes":[],"cve_workflow_role":"","tags":["code-hygiene","ruby","rubocop","lint","disable"],"facets":["code-hygiene","audit","remediation"],"quality":{"score":100,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context","multi-facet"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"security-recipes.ai contributors","team":"Security Engineering","model":"gpt-5-codex","ai_assisted":false,"generated_by":"","date":"2026-08-21","zero_day":false,"last_updated":"2026-08-21","summary":"Ruby RuboCop baseline and disable debt: Resolve RuboCop offenses and narrow disabled cops without broad rewrites.","content_text":"<!-- Generated by scripts/synccodehygiene_recipes.py; edit data/code-hygiene/catalog.json. --> A tool-agnostic recipe to resolve RuboCop offenses and narrow disabled cops without broad rewrites. It supports a read-only audit and, when explicitly authorized, a narrow remediation. When to use it Use this recipe when the operator's specific objective is to resolve RuboCop offenses and narrow disabled cops without broad rewrites. Prefer a narrower CVE, scanner-finding, security-audit, or compliance-evidence recipe when that is the operator's actual job. Inputs Repository root and the files, package, service, or module in scope. Requested mode: audit or explicitly authorized fix. Supported runtime, compiler, framework, operating-system, and deployment versions inferred from repository files. Existing formatter, compiler, analyzer, test, build, and package-manager commands. Public API, compatibility, performance, generated-code, vendor, and migration constraints. The prompt ~~~markdown You are running the Security Recipes code-hygiene workflow code-hygiene.ruby.ruby-rubocop-baseline-and-disable-debt. Start read-only. Do not edit files until the operator explicitly authorizes a fix. Use repository configuration and installed tool versions as authoritative; do not impose a new style or toolchain. Scope Your bounded objective is to resolve RuboCop offenses and narrow disabled cops without broad rewrites. Inspect only operator-scoped, first-party source and configuration. Exclude generated, vendored, minified, fixture snapshot, lock history, and migration history unless explicitly included. Detection Read inherited RuboCop configuration, target Ruby version, generated paths, TODO baselines, and inline disables. Separate safe autocorrect candidates from behavior-changing or framework-sensitive cops. Record file and symbol evidence for every candidate. Mark uncertain or dynamically reachable behavior instead of guessing. Fix, only when authorized Apply reviewed local corrections and remove stale baseline entries without broad unsafe autocorrect. Keep the diff limited to the proven issue and its focused tests. Preserve public behavior, API compatibility, and repository conventions. Do not add or broaden suppressions, weaken diagnostics, mass-format unrelated files, upgrade dependencies, or mutate external state. Verification Run RuboCop with the repository config and focused tests under the supported Ruby version. Compare diagnostic counts and relevant behavior before and after. Report every command, result, and check that could not run. Stop conditions Stop if autocorrection changes metaprogramming, DSL, serialization, or public behavior. Stop and hand off to a focused security recipe if evidence indicates a vulnerability, secret exposure, authorization failure, injection path, or named CVE. Stop rather than widening scope when the safe result requires architecture, product, compliance, operational, or data-owner decisions. ~~~ Output contract Scope and repository evidence reviewed. A candidate table with file or symbol, evidence, confidence, and disposition. In audit mode: no edits, plus the smallest safe next action for each confirmed item. In fix mode: one bounded patch, focused regression coverage, and no unrelated cleanup. Commands run, results, remaining uncertainty, and any stop-condition handoff. Verification Run RuboCop with the repository config and focused tests under the supported Ruby version. Confirm that diagnostic configuration, suppressions, public interfaces, generated files, vendored files, and dependencies did not change outside the authorized scope. Review the final diff for behavior changes and run the repository's focused checks before broader suites. Guardrails Read-only until edits are explicitly authorized. Do not deploy, publish, rotate secrets, alter cloud or database state, change CI permissions, or open external tickets. Do not hide debt by disabling rules, adding retries or sleeps, weakening tests, broadening ignores, or lowering warning levels. Treat generated, vendored, minified, migration-history, and fixture-snapshot files as out of scope unless explicitly named. Stop if autocorrection changes metaprogramming, DSL, serialization, or public behavior. Related recipes Rails query, transaction, and callback hygiene Lint warning baseline and budget Browse all code-hygiene recipes References NIST SP 800-218 Secure Software Development Framework 1.1 — NIST RuboCop documentation — RuboCop Rails Active Record query interface — Ruby on Rails","agent_handoff":{"mcp_lookup_keys":["ruby-rubocop-baseline-and-disable-debt","/recipes/general/code-hygiene/ruby/ruby-rubocop-baseline-and-disable-debt/","recipes/general/code-hygiene/ruby/ruby-rubocop-baseline-and-disable-debt.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["code-hygiene","audit","remediation"],"source_text_field":"content_text","portable_download":"security-recipe-ruby-rubocop-baseline-and-disable-debt.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-ruby-rubocop-baseline-and-disable-debt.json"}},{"slug":"rust-async-cancellation-lock-and-task-lifecycle","title":"Rust async cancellation, lock, and task lifecycle","link_title":"Rust async cancellation, lock, and task lifecycle","url":"https://security-recipes.ai/recipes/general/code-hygiene/rust/rust-async-cancellation-lock-and-task-lifecycle/","path":"/recipes/general/code-hygiene/rust/rust-async-cancellation-lock-and-task-lifecycle/","source_file":"recipes/general/code-hygiene/rust/rust-async-cancellation-lock-and-task-lifecycle.md","recipe_id":"code-hygiene.rust.rust-async-cancellation-lock-and-task-lifecycle","recipe_kind":"code-hygiene","category":{"slug":"code-hygiene","label":"Code Hygiene"},"agent":"general","severity":"unspecified","maturity":"development","ecosystem":"rust/cargo","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"","framework_version":"","jurisdiction":"","industry":[],"cve_archetypes":[],"cve_workflow_role":"","tags":["code-hygiene","rust","async","cancellation","locks"],"facets":["code-hygiene","audit","remediation"],"quality":{"score":100,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context","multi-facet"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"security-recipes.ai contributors","team":"Security Engineering","model":"gpt-5-codex","ai_assisted":false,"generated_by":"","date":"2026-08-21","zero_day":false,"last_updated":"2026-08-21","summary":"Rust async cancellation, lock, and task lifecycle: Avoid detached tasks, locks across await, and cancellation-unsafe partial operations.","content_text":"<!-- Generated by scripts/synccodehygiene_recipes.py; edit data/code-hygiene/catalog.json. --> A tool-agnostic recipe to avoid detached tasks, locks across await, and cancellation-unsafe partial operations. It supports a read-only audit and, when explicitly authorized, a narrow remediation. When to use it Use this recipe when the operator's specific objective is to avoid detached tasks, locks across await, and cancellation-unsafe partial operations. Prefer a narrower CVE, scanner-finding, security-audit, or compliance-evidence recipe when that is the operator's actual job. Inputs Repository root and the files, package, service, or module in scope. Requested mode: audit or explicitly authorized fix. Supported runtime, compiler, framework, operating-system, and deployment versions inferred from repository files. Existing formatter, compiler, analyzer, test, build, and package-manager commands. Public API, compatibility, performance, generated-code, vendor, and migration constraints. The prompt ~~~markdown You are running the Security Recipes code-hygiene workflow code-hygiene.rust.rust-async-cancellation-lock-and-task-lifecycle. Start read-only. Do not edit files until the operator explicitly authorizes a fix. Use repository configuration and installed tool versions as authoritative; do not impose a new style or toolchain. Scope Your bounded objective is to avoid detached tasks, locks across await, and cancellation-unsafe partial operations. Inspect only operator-scoped, first-party source and configuration. Exclude generated, vendored, minified, fixture snapshot, lock history, and migration history unless explicitly included. Detection Trace spawn ownership, JoinHandle observation, select cancellation points, lock guards, and shutdown signals. Find blocking operations and resource mutation spanning await points. Record file and symbol evidence for every candidate. Mark uncertain or dynamically reachable behavior instead of guessing. Fix, only when authorized Use structured task ownership, shorten guard scope, and make cancellation-safe state transitions. Keep the diff limited to the proven issue and its focused tests. Preserve public behavior, API compatibility, and repository conventions. Do not add or broaden suppressions, weaken diagnostics, mass-format unrelated files, upgrade dependencies, or mutate external state. Verification Test task failure, cancellation at each await, shutdown, lock contention, and partial progress. Compare diagnostic counts and relevant behavior before and after. Report every command, result, and check that could not run. Stop conditions Stop if cancellation semantics or executor choice are part of an undocumented external contract. Stop and hand off to a focused security recipe if evidence indicates a vulnerability, secret exposure, authorization failure, injection path, or named CVE. Stop rather than widening scope when the safe result requires architecture, product, compliance, operational, or data-owner decisions. ~~~ Output contract Scope and repository evidence reviewed. A candidate table with file or symbol, evidence, confidence, and disposition. In audit mode: no edits, plus the smallest safe next action for each confirmed item. In fix mode: one bounded patch, focused regression coverage, and no unrelated cleanup. Commands run, results, remaining uncertainty, and any stop-condition handoff. Verification Test task failure, cancellation at each await, shutdown, lock contention, and partial progress. Confirm that diagnostic configuration, suppressions, public interfaces, generated files, vendored files, and dependencies did not change outside the authorized scope. Review the final diff for behavior changes and run the repository's focused checks before broader suites. Guardrails Read-only until edits are explicitly authorized. Do not deploy, publish, rotate secrets, alter cloud or database state, change CI permissions, or open external tickets. Do not hide debt by disabling rules, adding retries or sleeps, weakening tests, broadening ignores, or lowering warning levels. Treat generated, vendored, minified, migration-history, and fixture-snapshot files as out of scope unless explicitly named. Stop if cancellation semantics or executor choice are part of an undocumented external contract. Related recipes Rust Clippy lint baseline and allow debt Rust panic, unwrap, expect, and error boundaries Browse all code-hygiene recipes References NIST SP 800-218 Secure Software Development Framework 1.1 — NIST Rust Clippy documentation — Rust project Rust error handling — Rust project Asynchronous Programming in Rust — Rust project","agent_handoff":{"mcp_lookup_keys":["rust-async-cancellation-lock-and-task-lifecycle","/recipes/general/code-hygiene/rust/rust-async-cancellation-lock-and-task-lifecycle/","recipes/general/code-hygiene/rust/rust-async-cancellation-lock-and-task-lifecycle.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["code-hygiene","audit","remediation"],"source_text_field":"content_text","portable_download":"security-recipe-rust-async-cancellation-lock-and-task-lifecycle.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-rust-async-cancellation-lock-and-task-lifecycle.json"}},{"slug":"rust-clippy-lint-baseline-and-allow-debt","title":"Rust Clippy lint baseline and allow debt","link_title":"Rust Clippy lint baseline and allow debt","url":"https://security-recipes.ai/recipes/general/code-hygiene/rust/rust-clippy-lint-baseline-and-allow-debt/","path":"/recipes/general/code-hygiene/rust/rust-clippy-lint-baseline-and-allow-debt/","source_file":"recipes/general/code-hygiene/rust/rust-clippy-lint-baseline-and-allow-debt.md","recipe_id":"code-hygiene.rust.rust-clippy-lint-baseline-and-allow-debt","recipe_kind":"code-hygiene","category":{"slug":"code-hygiene","label":"Code Hygiene"},"agent":"general","severity":"unspecified","maturity":"development","ecosystem":"rust/cargo","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"","framework_version":"","jurisdiction":"","industry":[],"cve_archetypes":[],"cve_workflow_role":"","tags":["code-hygiene","rust","clippy","lints","allow"],"facets":["code-hygiene","audit","remediation"],"quality":{"score":100,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context","multi-facet"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"security-recipes.ai contributors","team":"Security Engineering","model":"gpt-5-codex","ai_assisted":false,"generated_by":"","date":"2026-08-21","zero_day":false,"last_updated":"2026-08-21","summary":"Rust Clippy lint baseline and allow debt: Resolve correctness and suspicious lints and narrow allow attributes.","content_text":"<!-- Generated by scripts/synccodehygiene_recipes.py; edit data/code-hygiene/catalog.json. --> A tool-agnostic recipe to resolve correctness and suspicious lints and narrow allow attributes. It supports a read-only audit and, when explicitly authorized, a narrow remediation. When to use it Use this recipe when the operator's specific objective is to resolve correctness and suspicious lints and narrow allow attributes. Prefer a narrower CVE, scanner-finding, security-audit, or compliance-evidence recipe when that is the operator's actual job. Inputs Repository root and the files, package, service, or module in scope. Requested mode: audit or explicitly authorized fix. Supported runtime, compiler, framework, operating-system, and deployment versions inferred from repository files. Existing formatter, compiler, analyzer, test, build, and package-manager commands. Public API, compatibility, performance, generated-code, vendor, and migration constraints. The prompt ~~~markdown You are running the Security Recipes code-hygiene workflow code-hygiene.rust.rust-clippy-lint-baseline-and-allow-debt. Start read-only. Do not edit files until the operator explicitly authorizes a fix. Use repository configuration and installed tool versions as authoritative; do not impose a new style or toolchain. Scope Your bounded objective is to resolve correctness and suspicious lints and narrow allow attributes. Inspect only operator-scoped, first-party source and configuration. Exclude generated, vendored, minified, fixture snapshot, lock history, and migration history unless explicitly included. Detection Read Cargo lint tables, clippy configuration, MSRV, feature matrix, and allow or expect attributes. Separate generated code and intentional restriction-lint policy from owned warnings. Record file and symbol evidence for every candidate. Mark uncertain or dynamically reachable behavior instead of guessing. Fix, only when authorized Correct diagnostics and scope justified lint levels to the smallest item with rationale. Keep the diff limited to the proven issue and its focused tests. Preserve public behavior, API compatibility, and repository conventions. Do not add or broaden suppressions, weaken diagnostics, mass-format unrelated files, upgrade dependencies, or mutate external state. Verification Run cargo fmt check, Clippy with repository features and targets, and focused tests. Compare diagnostic counts and relevant behavior before and after. Report every command, result, and check that could not run. Stop conditions Stop before enabling whole pedantic or restriction groups or breaking the documented MSRV. Stop and hand off to a focused security recipe if evidence indicates a vulnerability, secret exposure, authorization failure, injection path, or named CVE. Stop rather than widening scope when the safe result requires architecture, product, compliance, operational, or data-owner decisions. ~~~ Output contract Scope and repository evidence reviewed. A candidate table with file or symbol, evidence, confidence, and disposition. In audit mode: no edits, plus the smallest safe next action for each confirmed item. In fix mode: one bounded patch, focused regression coverage, and no unrelated cleanup. Commands run, results, remaining uncertainty, and any stop-condition handoff. Verification Run cargo fmt check, Clippy with repository features and targets, and focused tests. Confirm that diagnostic configuration, suppressions, public interfaces, generated files, vendored files, and dependencies did not change outside the authorized scope. Review the final diff for behavior changes and run the repository's focused checks before broader suites. Guardrails Read-only until edits are explicitly authorized. Do not deploy, publish, rotate secrets, alter cloud or database state, change CI permissions, or open external tickets. Do not hide debt by disabling rules, adding retries or sleeps, weakening tests, broadening ignores, or lowering warning levels. Treat generated, vendored, minified, migration-history, and fixture-snapshot files as out of scope unless explicitly named. Stop before enabling whole pedantic or restriction groups or breaking the documented MSRV. Related recipes Rust panic, unwrap, expect, and error boundaries Rust unsafe block and safety-invariant hygiene Browse all code-hygiene recipes References NIST SP 800-218 Secure Software Development Framework 1.1 — NIST Rust Clippy documentation — Rust project Rust error handling — Rust project","agent_handoff":{"mcp_lookup_keys":["rust-clippy-lint-baseline-and-allow-debt","/recipes/general/code-hygiene/rust/rust-clippy-lint-baseline-and-allow-debt/","recipes/general/code-hygiene/rust/rust-clippy-lint-baseline-and-allow-debt.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["code-hygiene","audit","remediation"],"source_text_field":"content_text","portable_download":"security-recipe-rust-clippy-lint-baseline-and-allow-debt.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-rust-clippy-lint-baseline-and-allow-debt.json"}},{"slug":"rust-panic-unwrap-expect-and-error-boundaries","title":"Rust panic, unwrap, expect, and error boundaries","link_title":"Rust panic, unwrap, expect, and error boundaries","url":"https://security-recipes.ai/recipes/general/code-hygiene/rust/rust-panic-unwrap-expect-and-error-boundaries/","path":"/recipes/general/code-hygiene/rust/rust-panic-unwrap-expect-and-error-boundaries/","source_file":"recipes/general/code-hygiene/rust/rust-panic-unwrap-expect-and-error-boundaries.md","recipe_id":"code-hygiene.rust.rust-panic-unwrap-expect-and-error-boundaries","recipe_kind":"code-hygiene","category":{"slug":"code-hygiene","label":"Code Hygiene"},"agent":"general","severity":"unspecified","maturity":"development","ecosystem":"rust/cargo","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"","framework_version":"","jurisdiction":"","industry":[],"cve_archetypes":[],"cve_workflow_role":"","tags":["code-hygiene","rust","panic","unwrap","errors"],"facets":["code-hygiene","audit","remediation"],"quality":{"score":100,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context","multi-facet"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"security-recipes.ai contributors","team":"Security Engineering","model":"gpt-5-codex","ai_assisted":false,"generated_by":"","date":"2026-08-21","zero_day":false,"last_updated":"2026-08-21","summary":"Rust panic, unwrap, expect, and error boundaries: Keep recoverable failures out of panic paths while preserving invariants.","content_text":"<!-- Generated by scripts/synccodehygiene_recipes.py; edit data/code-hygiene/catalog.json. --> A tool-agnostic recipe to keep recoverable failures out of panic paths while preserving invariants. It supports a read-only audit and, when explicitly authorized, a narrow remediation. When to use it Use this recipe when the operator's specific objective is to keep recoverable failures out of panic paths while preserving invariants. Prefer a narrower CVE, scanner-finding, security-audit, or compliance-evidence recipe when that is the operator's actual job. Inputs Repository root and the files, package, service, or module in scope. Requested mode: audit or explicitly authorized fix. Supported runtime, compiler, framework, operating-system, and deployment versions inferred from repository files. Existing formatter, compiler, analyzer, test, build, and package-manager commands. Public API, compatibility, performance, generated-code, vendor, and migration constraints. The prompt ~~~markdown You are running the Security Recipes code-hygiene workflow code-hygiene.rust.rust-panic-unwrap-expect-and-error-boundaries. Start read-only. Do not edit files until the operator explicitly authorizes a fix. Use repository configuration and installed tool versions as authoritative; do not impose a new style or toolchain. Scope Your bounded objective is to keep recoverable failures out of panic paths while preserving invariants. Inspect only operator-scoped, first-party source and configuration. Exclude generated, vendored, minified, fixture snapshot, lock history, and migration history unless explicitly included. Detection Inventory unwrap, expect, panic, indexing, assertions, and error conversion by binary, library, test, and invariant boundary. Classify impossible states versus input, I/O, configuration, and concurrency failures. Record file and symbol evidence for every candidate. Mark uncertain or dynamically reachable behavior instead of guessing. Fix, only when authorized Return or propagate typed errors for recoverable cases and document true invariant assertions. Keep the diff limited to the proven issue and its focused tests. Preserve public behavior, API compatibility, and repository conventions. Do not add or broaden suppressions, weaken diagnostics, mass-format unrelated files, upgrade dependencies, or mutate external state. Verification Test invalid input, dependency failure, boundary conversion, and invariant-preserving success paths. Compare diagnostic counts and relevant behavior before and after. Report every command, result, and check that could not run. Stop conditions Stop if changing a public error type or panic contract requires downstream coordination. Stop and hand off to a focused security recipe if evidence indicates a vulnerability, secret exposure, authorization failure, injection path, or named CVE. Stop rather than widening scope when the safe result requires architecture, product, compliance, operational, or data-owner decisions. ~~~ Output contract Scope and repository evidence reviewed. A candidate table with file or symbol, evidence, confidence, and disposition. In audit mode: no edits, plus the smallest safe next action for each confirmed item. In fix mode: one bounded patch, focused regression coverage, and no unrelated cleanup. Commands run, results, remaining uncertainty, and any stop-condition handoff. Verification Test invalid input, dependency failure, boundary conversion, and invariant-preserving success paths. Confirm that diagnostic configuration, suppressions, public interfaces, generated files, vendored files, and dependencies did not change outside the authorized scope. Review the final diff for behavior changes and run the repository's focused checks before broader suites. Guardrails Read-only until edits are explicitly authorized. Do not deploy, publish, rotate secrets, alter cloud or database state, change CI permissions, or open external tickets. Do not hide debt by disabling rules, adding retries or sleeps, weakening tests, broadening ignores, or lowering warning levels. Treat generated, vendored, minified, migration-history, and fixture-snapshot files as out of scope unless explicitly named. Stop if changing a public error type or panic contract requires downstream coordination. Related recipes Rust Clippy lint baseline and allow debt Rust unsafe block and safety-invariant hygiene Browse all code-hygiene recipes References NIST SP 800-218 Secure Software Development Framework 1.1 — NIST Rust Clippy documentation — Rust project Rust error handling — Rust project","agent_handoff":{"mcp_lookup_keys":["rust-panic-unwrap-expect-and-error-boundaries","/recipes/general/code-hygiene/rust/rust-panic-unwrap-expect-and-error-boundaries/","recipes/general/code-hygiene/rust/rust-panic-unwrap-expect-and-error-boundaries.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["code-hygiene","audit","remediation"],"source_text_field":"content_text","portable_download":"security-recipe-rust-panic-unwrap-expect-and-error-boundaries.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-rust-panic-unwrap-expect-and-error-boundaries.json"}},{"slug":"rust-unsafe-block-and-safety-invariants","title":"Rust unsafe block and safety-invariant hygiene","link_title":"Rust unsafe block and safety-invariant hygiene","url":"https://security-recipes.ai/recipes/general/code-hygiene/rust/rust-unsafe-block-and-safety-invariants/","path":"/recipes/general/code-hygiene/rust/rust-unsafe-block-and-safety-invariants/","source_file":"recipes/general/code-hygiene/rust/rust-unsafe-block-and-safety-invariants.md","recipe_id":"code-hygiene.rust.rust-unsafe-block-and-safety-invariants","recipe_kind":"code-hygiene","category":{"slug":"code-hygiene","label":"Code Hygiene"},"agent":"general","severity":"unspecified","maturity":"development","ecosystem":"rust/cargo","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"","framework_version":"","jurisdiction":"","industry":[],"cve_archetypes":[],"cve_workflow_role":"","tags":["code-hygiene","rust","unsafe","invariants","ffi"],"facets":["code-hygiene","audit","remediation"],"quality":{"score":100,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context","multi-facet"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"security-recipes.ai contributors","team":"Security Engineering","model":"gpt-5-codex","ai_assisted":false,"generated_by":"","date":"2026-08-21","zero_day":false,"last_updated":"2026-08-21","summary":"Rust unsafe block and safety-invariant hygiene: Minimize unsafe scope and make every safety invariant locally reviewable.","content_text":"<!-- Generated by scripts/synccodehygiene_recipes.py; edit data/code-hygiene/catalog.json. --> A tool-agnostic recipe to minimize unsafe scope and make every safety invariant locally reviewable. It supports a read-only audit and, when explicitly authorized, a narrow remediation. When to use it Use this recipe when the operator's specific objective is to minimize unsafe scope and make every safety invariant locally reviewable. Prefer a narrower CVE, scanner-finding, security-audit, or compliance-evidence recipe when that is the operator's actual job. Inputs Repository root and the files, package, service, or module in scope. Requested mode: audit or explicitly authorized fix. Supported runtime, compiler, framework, operating-system, and deployment versions inferred from repository files. Existing formatter, compiler, analyzer, test, build, and package-manager commands. Public API, compatibility, performance, generated-code, vendor, and migration constraints. The prompt ~~~markdown You are running the Security Recipes code-hygiene workflow code-hygiene.rust.rust-unsafe-block-and-safety-invariants. Start read-only. Do not edit files until the operator explicitly authorizes a fix. Use repository configuration and installed tool versions as authoritative; do not impose a new style or toolchain. Scope Your bounded objective is to minimize unsafe scope and make every safety invariant locally reviewable. Inspect only operator-scoped, first-party source and configuration. Exclude generated, vendored, minified, fixture snapshot, lock history, and migration history unless explicitly included. Detection Inventory unsafe blocks, functions, impls, FFI boundaries, raw pointer lifetimes, aliasing, and layout assumptions. Require a concrete invariant for each operation rather than a block-level assertion. Record file and symbol evidence for every candidate. Mark uncertain or dynamically reachable behavior instead of guessing. Fix, only when authorized Move safe checks outside, shrink unsafe regions, and document caller and callee obligations next to operations. Keep the diff limited to the proven issue and its focused tests. Preserve public behavior, API compatibility, and repository conventions. Do not add or broaden suppressions, weaken diagnostics, mass-format unrelated files, upgrade dependencies, or mutate external state. Verification Run tests, Miri or sanitizers when configured, and boundary cases for layout, aliasing, and lifetime. Compare diagnostic counts and relevant behavior before and after. Report every command, result, and check that could not run. Stop conditions Stop when soundness depends on undocumented foreign code, compiler behavior, or platform ABI. Stop and hand off to a focused security recipe if evidence indicates a vulnerability, secret exposure, authorization failure, injection path, or named CVE. Stop rather than widening scope when the safe result requires architecture, product, compliance, operational, or data-owner decisions. ~~~ Output contract Scope and repository evidence reviewed. A candidate table with file or symbol, evidence, confidence, and disposition. In audit mode: no edits, plus the smallest safe next action for each confirmed item. In fix mode: one bounded patch, focused regression coverage, and no unrelated cleanup. Commands run, results, remaining uncertainty, and any stop-condition handoff. Verification Run tests, Miri or sanitizers when configured, and boundary cases for layout, aliasing, and lifetime. Confirm that diagnostic configuration, suppressions, public interfaces, generated files, vendored files, and dependencies did not change outside the authorized scope. Review the final diff for behavior changes and run the repository's focused checks before broader suites. Guardrails Read-only until edits are explicitly authorized. Do not deploy, publish, rotate secrets, alter cloud or database state, change CI permissions, or open external tickets. Do not hide debt by disabling rules, adding retries or sleeps, weakening tests, broadening ignores, or lowering warning levels. Treat generated, vendored, minified, migration-history, and fixture-snapshot files as out of scope unless explicitly named. Stop when soundness depends on undocumented foreign code, compiler behavior, or platform ABI. Related recipes Rust Clippy lint baseline and allow debt Rust panic, unwrap, expect, and error boundaries Browse all code-hygiene recipes References NIST SP 800-218 Secure Software Development Framework 1.1 — NIST Rust Clippy documentation — Rust project Rust error handling — Rust project Rust unsafe guidelines — Rust project","agent_handoff":{"mcp_lookup_keys":["rust-unsafe-block-and-safety-invariants","/recipes/general/code-hygiene/rust/rust-unsafe-block-and-safety-invariants/","recipes/general/code-hygiene/rust/rust-unsafe-block-and-safety-invariants.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["code-hygiene","audit","remediation"],"source_text_field":"content_text","portable_download":"security-recipe-rust-unsafe-block-and-safety-invariants.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-rust-unsafe-block-and-safety-invariants.json"}},{"slug":"powershell-error-output-and-resource-lifecycle","title":"PowerShell error, output, and resource lifecycle","link_title":"PowerShell error, output, and resource lifecycle","url":"https://security-recipes.ai/recipes/general/code-hygiene/shell-powershell/powershell-error-output-and-resource-lifecycle/","path":"/recipes/general/code-hygiene/shell-powershell/powershell-error-output-and-resource-lifecycle/","source_file":"recipes/general/code-hygiene/shell-powershell/powershell-error-output-and-resource-lifecycle.md","recipe_id":"code-hygiene.shell-powershell.powershell-error-output-and-resource-lifecycle","recipe_kind":"code-hygiene","category":{"slug":"code-hygiene","label":"Code Hygiene"},"agent":"general","severity":"unspecified","maturity":"development","ecosystem":"powershell/modules","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"","framework_version":"","jurisdiction":"","industry":[],"cve_archetypes":[],"cve_workflow_role":"","tags":["code-hygiene","shell-powershell","powershell","errors","pipeline","resources"],"facets":["code-hygiene","audit","remediation"],"quality":{"score":100,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context","multi-facet"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"security-recipes.ai contributors","team":"Security Engineering","model":"gpt-5-codex","ai_assisted":false,"generated_by":"","date":"2026-08-21","zero_day":false,"last_updated":"2026-08-21","summary":"PowerShell error, output, and resource lifecycle: Make terminating behavior, pipeline output, and disposable resources predictable.","content_text":"<!-- Generated by scripts/synccodehygiene_recipes.py; edit data/code-hygiene/catalog.json. --> A tool-agnostic recipe to make terminating behavior, pipeline output, and disposable resources predictable. It supports a read-only audit and, when explicitly authorized, a narrow remediation. When to use it Use this recipe when the operator's specific objective is to make terminating behavior, pipeline output, and disposable resources predictable. Prefer a narrower CVE, scanner-finding, security-audit, or compliance-evidence recipe when that is the operator's actual job. Inputs Repository root and the files, package, service, or module in scope. Requested mode: audit or explicitly authorized fix. Supported runtime, compiler, framework, operating-system, and deployment versions inferred from repository files. Existing formatter, compiler, analyzer, test, build, and package-manager commands. Public API, compatibility, performance, generated-code, vendor, and migration constraints. The prompt ~~~markdown You are running the Security Recipes code-hygiene workflow code-hygiene.shell-powershell.powershell-error-output-and-resource-lifecycle. Start read-only. Do not edit files until the operator explicitly authorizes a fix. Use repository configuration and installed tool versions as authoritative; do not impose a new style or toolchain. Scope Your bounded objective is to make terminating behavior, pipeline output, and disposable resources predictable. Inspect only operator-scoped, first-party source and configuration. Exclude generated, vendored, minified, fixture snapshot, lock history, and migration history unless explicitly included. Detection Trace ErrorAction, preference variables, try-catch-finally, native exit codes, Write-Output leakage, streams, jobs, and runspaces. Find functions mixing data output with status text or losing native failures. Record file and symbol evidence for every candidate. Mark uncertain or dynamically reachable behavior instead of guessing. Fix, only when authorized Use explicit terminating boundaries, correct output streams, and deterministic job or resource cleanup. Keep the diff limited to the proven issue and its focused tests. Preserve public behavior, API compatibility, and repository conventions. Do not add or broaden suppressions, weaken diagnostics, mass-format unrelated files, upgrade dependencies, or mutate external state. Verification Test native and cmdlet failures, pipeline composition, WhatIf where supported, cancellation, and cleanup. Compare diagnostic counts and relevant behavior before and after. Report every command, result, and check that could not run. Stop conditions Stop if error semantics are part of a public module contract without consumer tests. Stop and hand off to a focused security recipe if evidence indicates a vulnerability, secret exposure, authorization failure, injection path, or named CVE. Stop rather than widening scope when the safe result requires architecture, product, compliance, operational, or data-owner decisions. ~~~ Output contract Scope and repository evidence reviewed. A candidate table with file or symbol, evidence, confidence, and disposition. In audit mode: no edits, plus the smallest safe next action for each confirmed item. In fix mode: one bounded patch, focused regression coverage, and no unrelated cleanup. Commands run, results, remaining uncertainty, and any stop-condition handoff. Verification Test native and cmdlet failures, pipeline composition, WhatIf where supported, cancellation, and cleanup. Confirm that diagnostic configuration, suppressions, public interfaces, generated files, vendored files, and dependencies did not change outside the authorized scope. Review the final diff for behavior changes and run the repository's focused checks before broader suites. Guardrails Read-only until edits are explicitly authorized. Do not deploy, publish, rotate secrets, alter cloud or database state, change CI permissions, or open external tickets. Do not hide debt by disabling rules, adding retries or sleeps, weakening tests, broadening ignores, or lowering warning levels. Treat generated, vendored, minified, migration-history, and fixture-snapshot files as out of scope unless explicitly named. Stop if error semantics are part of a public module contract without consumer tests. Related recipes ShellCheck quoting and word-splitting hygiene Shell exit, pipeline, trap, and temporary-file lifecycle Browse all code-hygiene recipes References NIST SP 800-218 Secure Software Development Framework 1.1 — NIST ShellCheck wiki — ShellCheck POSIX shell command language — The Open Group PSScriptAnalyzer overview — Microsoft PowerShell about error action preference — Microsoft","agent_handoff":{"mcp_lookup_keys":["powershell-error-output-and-resource-lifecycle","/recipes/general/code-hygiene/shell-powershell/powershell-error-output-and-resource-lifecycle/","recipes/general/code-hygiene/shell-powershell/powershell-error-output-and-resource-lifecycle.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["code-hygiene","audit","remediation"],"source_text_field":"content_text","portable_download":"security-recipe-powershell-error-output-and-resource-lifecycle.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-powershell-error-output-and-resource-lifecycle.json"}},{"slug":"powershell-scriptanalyzer-and-suppression-debt","title":"PowerShell ScriptAnalyzer and suppression debt","link_title":"PowerShell ScriptAnalyzer and suppression debt","url":"https://security-recipes.ai/recipes/general/code-hygiene/shell-powershell/powershell-scriptanalyzer-and-suppression-debt/","path":"/recipes/general/code-hygiene/shell-powershell/powershell-scriptanalyzer-and-suppression-debt/","source_file":"recipes/general/code-hygiene/shell-powershell/powershell-scriptanalyzer-and-suppression-debt.md","recipe_id":"code-hygiene.shell-powershell.powershell-scriptanalyzer-and-suppression-debt","recipe_kind":"code-hygiene","category":{"slug":"code-hygiene","label":"Code Hygiene"},"agent":"general","severity":"unspecified","maturity":"development","ecosystem":"powershell/modules","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"","framework_version":"","jurisdiction":"","industry":[],"cve_archetypes":[],"cve_workflow_role":"","tags":["code-hygiene","shell-powershell","powershell","psscriptanalyzer","lint","suppressions"],"facets":["code-hygiene","audit","remediation"],"quality":{"score":100,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context","multi-facet"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"security-recipes.ai contributors","team":"Security Engineering","model":"gpt-5-codex","ai_assisted":false,"generated_by":"","date":"2026-08-21","zero_day":false,"last_updated":"2026-08-21","summary":"PowerShell ScriptAnalyzer and suppression debt: Resolve PSScriptAnalyzer findings and narrow rule exclusions.","content_text":"<!-- Generated by scripts/synccodehygiene_recipes.py; edit data/code-hygiene/catalog.json. --> A tool-agnostic recipe to resolve PSScriptAnalyzer findings and narrow rule exclusions. It supports a read-only audit and, when explicitly authorized, a narrow remediation. When to use it Use this recipe when the operator's specific objective is to resolve PSScriptAnalyzer findings and narrow rule exclusions. Prefer a narrower CVE, scanner-finding, security-audit, or compliance-evidence recipe when that is the operator's actual job. Inputs Repository root and the files, package, service, or module in scope. Requested mode: audit or explicitly authorized fix. Supported runtime, compiler, framework, operating-system, and deployment versions inferred from repository files. Existing formatter, compiler, analyzer, test, build, and package-manager commands. Public API, compatibility, performance, generated-code, vendor, and migration constraints. The prompt ~~~markdown You are running the Security Recipes code-hygiene workflow code-hygiene.shell-powershell.powershell-scriptanalyzer-and-suppression-debt. Start read-only. Do not edit files until the operator explicitly authorizes a fix. Use repository configuration and installed tool versions as authoritative; do not impose a new style or toolchain. Scope Your bounded objective is to resolve PSScriptAnalyzer findings and narrow rule exclusions. Inspect only operator-scoped, first-party source and configuration. Exclude generated, vendored, minified, fixture snapshot, lock history, and migration history unless explicitly included. Detection Read analyzer settings, target editions and versions, module manifests, suppressions, and compatibility rules. Separate generated code and intentional public command naming from fixable diagnostics. Record file and symbol evidence for every candidate. Mark uncertain or dynamically reachable behavior instead of guessing. Fix, only when authorized Use approved PowerShell patterns and scope justified suppressions to a named rule and declaration. Keep the diff limited to the proven issue and its focused tests. Preserve public behavior, API compatibility, and repository conventions. Do not add or broaden suppressions, weaken diagnostics, mass-format unrelated files, upgrade dependencies, or mutate external state. Verification Run Invoke-ScriptAnalyzer with repository settings plus module import and Pester tests if present. Compare diagnostic counts and relevant behavior before and after. Report every command, result, and check that could not run. Stop conditions Stop if a change breaks exported command names or supported Windows PowerShell compatibility. Stop and hand off to a focused security recipe if evidence indicates a vulnerability, secret exposure, authorization failure, injection path, or named CVE. Stop rather than widening scope when the safe result requires architecture, product, compliance, operational, or data-owner decisions. ~~~ Output contract Scope and repository evidence reviewed. A candidate table with file or symbol, evidence, confidence, and disposition. In audit mode: no edits, plus the smallest safe next action for each confirmed item. In fix mode: one bounded patch, focused regression coverage, and no unrelated cleanup. Commands run, results, remaining uncertainty, and any stop-condition handoff. Verification Run Invoke-ScriptAnalyzer with repository settings plus module import and Pester tests if present. Confirm that diagnostic configuration, suppressions, public interfaces, generated files, vendored files, and dependencies did not change outside the authorized scope. Review the final diff for behavior changes and run the repository's focused checks before broader suites. Guardrails Read-only until edits are explicitly authorized. Do not deploy, publish, rotate secrets, alter cloud or database state, change CI permissions, or open external tickets. Do not hide debt by disabling rules, adding retries or sleeps, weakening tests, broadening ignores, or lowering warning levels. Treat generated, vendored, minified, migration-history, and fixture-snapshot files as out of scope unless explicitly named. Stop if a change breaks exported command names or supported Windows PowerShell compatibility. Related recipes ShellCheck quoting and word-splitting hygiene Shell exit, pipeline, trap, and temporary-file lifecycle Browse all code-hygiene recipes References NIST SP 800-218 Secure Software Development Framework 1.1 — NIST ShellCheck wiki — ShellCheck POSIX shell command language — The Open Group PSScriptAnalyzer overview — Microsoft","agent_handoff":{"mcp_lookup_keys":["powershell-scriptanalyzer-and-suppression-debt","/recipes/general/code-hygiene/shell-powershell/powershell-scriptanalyzer-and-suppression-debt/","recipes/general/code-hygiene/shell-powershell/powershell-scriptanalyzer-and-suppression-debt.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["code-hygiene","audit","remediation"],"source_text_field":"content_text","portable_download":"security-recipe-powershell-scriptanalyzer-and-suppression-debt.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-powershell-scriptanalyzer-and-suppression-debt.json"}},{"slug":"shell-exit-pipeline-trap-and-temp-file-lifecycle","title":"Shell exit, pipeline, trap, and temporary-file lifecycle","link_title":"Shell exit, pipeline, trap, and temporary-file lifecycle","url":"https://security-recipes.ai/recipes/general/code-hygiene/shell-powershell/shell-exit-pipeline-trap-and-temp-file-lifecycle/","path":"/recipes/general/code-hygiene/shell-powershell/shell-exit-pipeline-trap-and-temp-file-lifecycle/","source_file":"recipes/general/code-hygiene/shell-powershell/shell-exit-pipeline-trap-and-temp-file-lifecycle.md","recipe_id":"code-hygiene.shell-powershell.shell-exit-pipeline-trap-and-temp-file-lifecycle","recipe_kind":"code-hygiene","category":{"slug":"code-hygiene","label":"Code Hygiene"},"agent":"general","severity":"unspecified","maturity":"development","ecosystem":"shell/posix","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"","framework_version":"","jurisdiction":"","industry":[],"cve_archetypes":[],"cve_workflow_role":"","tags":["code-hygiene","shell-powershell","shell","exit-codes","pipelines","traps","temp-files"],"facets":["code-hygiene","audit","remediation"],"quality":{"score":100,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context","multi-facet"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"security-recipes.ai contributors","team":"Security Engineering","model":"gpt-5-codex","ai_assisted":false,"generated_by":"","date":"2026-08-21","zero_day":false,"last_updated":"2026-08-21","summary":"Shell exit, pipeline, trap, and temporary-file lifecycle: Propagate failures and clean temporary state on every signal and exit.","content_text":"<!-- Generated by scripts/synccodehygiene_recipes.py; edit data/code-hygiene/catalog.json. --> A tool-agnostic recipe to propagate failures and clean temporary state on every signal and exit. It supports a read-only audit and, when explicitly authorized, a narrow remediation. When to use it Use this recipe when the operator's specific objective is to propagate failures and clean temporary state on every signal and exit. Prefer a narrower CVE, scanner-finding, security-audit, or compliance-evidence recipe when that is the operator's actual job. Inputs Repository root and the files, package, service, or module in scope. Requested mode: audit or explicitly authorized fix. Supported runtime, compiler, framework, operating-system, and deployment versions inferred from repository files. Existing formatter, compiler, analyzer, test, build, and package-manager commands. Public API, compatibility, performance, generated-code, vendor, and migration constraints. The prompt ~~~markdown You are running the Security Recipes code-hygiene workflow code-hygiene.shell-powershell.shell-exit-pipeline-trap-and-temp-file-lifecycle. Start read-only. Do not edit files until the operator explicitly authorizes a fix. Use repository configuration and installed tool versions as authoritative; do not impose a new style or toolchain. Scope Your bounded objective is to propagate failures and clean temporary state on every signal and exit. Inspect only operator-scoped, first-party source and configuration. Exclude generated, vendored, minified, fixture snapshot, lock history, and migration history unless explicitly included. Detection Trace pipeline status, subshells, command substitutions, conditional exceptions, traps, mktemp use, and cleanup ownership. Check actual target-shell behavior rather than assuming one strict-mode policy. Record file and symbol evidence for every candidate. Mark uncertain or dynamically reachable behavior instead of guessing. Fix, only when authorized Handle expected failures explicitly and install idempotent cleanup for owned temporary resources. Keep the diff limited to the proven issue and its focused tests. Preserve public behavior, API compatibility, and repository conventions. Do not add or broaden suppressions, weaken diagnostics, mass-format unrelated files, upgrade dependencies, or mutate external state. Verification Test each command failure, interrupted execution, partial setup, spaces in paths, and successful cleanup. Compare diagnostic counts and relevant behavior before and after. Report every command, result, and check that could not run. Stop conditions Stop before adopting shell options incompatible with supported shells or sourced-script callers. Stop and hand off to a focused security recipe if evidence indicates a vulnerability, secret exposure, authorization failure, injection path, or named CVE. Stop rather than widening scope when the safe result requires architecture, product, compliance, operational, or data-owner decisions. ~~~ Output contract Scope and repository evidence reviewed. A candidate table with file or symbol, evidence, confidence, and disposition. In audit mode: no edits, plus the smallest safe next action for each confirmed item. In fix mode: one bounded patch, focused regression coverage, and no unrelated cleanup. Commands run, results, remaining uncertainty, and any stop-condition handoff. Verification Test each command failure, interrupted execution, partial setup, spaces in paths, and successful cleanup. Confirm that diagnostic configuration, suppressions, public interfaces, generated files, vendored files, and dependencies did not change outside the authorized scope. Review the final diff for behavior changes and run the repository's focused checks before broader suites. Guardrails Read-only until edits are explicitly authorized. Do not deploy, publish, rotate secrets, alter cloud or database state, change CI permissions, or open external tickets. Do not hide debt by disabling rules, adding retries or sleeps, weakening tests, broadening ignores, or lowering warning levels. Treat generated, vendored, minified, migration-history, and fixture-snapshot files as out of scope unless explicitly named. Stop before adopting shell options incompatible with supported shells or sourced-script callers. Related recipes ShellCheck quoting and word-splitting hygiene PowerShell ScriptAnalyzer and suppression debt Browse all code-hygiene recipes References NIST SP 800-218 Secure Software Development Framework 1.1 — NIST ShellCheck wiki — ShellCheck POSIX shell command language — The Open Group PSScriptAnalyzer overview — Microsoft","agent_handoff":{"mcp_lookup_keys":["shell-exit-pipeline-trap-and-temp-file-lifecycle","/recipes/general/code-hygiene/shell-powershell/shell-exit-pipeline-trap-and-temp-file-lifecycle/","recipes/general/code-hygiene/shell-powershell/shell-exit-pipeline-trap-and-temp-file-lifecycle.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["code-hygiene","audit","remediation"],"source_text_field":"content_text","portable_download":"security-recipe-shell-exit-pipeline-trap-and-temp-file-lifecycle.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-shell-exit-pipeline-trap-and-temp-file-lifecycle.json"}},{"slug":"shellcheck-quoting-and-word-splitting","title":"ShellCheck quoting and word-splitting hygiene","link_title":"ShellCheck quoting and word-splitting hygiene","url":"https://security-recipes.ai/recipes/general/code-hygiene/shell-powershell/shellcheck-quoting-and-word-splitting/","path":"/recipes/general/code-hygiene/shell-powershell/shellcheck-quoting-and-word-splitting/","source_file":"recipes/general/code-hygiene/shell-powershell/shellcheck-quoting-and-word-splitting.md","recipe_id":"code-hygiene.shell-powershell.shellcheck-quoting-and-word-splitting","recipe_kind":"code-hygiene","category":{"slug":"code-hygiene","label":"Code Hygiene"},"agent":"general","severity":"unspecified","maturity":"development","ecosystem":"shell/posix","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"","framework_version":"","jurisdiction":"","industry":[],"cve_archetypes":[],"cve_workflow_role":"","tags":["code-hygiene","shell-powershell","shell","shellcheck","quoting","word-splitting"],"facets":["code-hygiene","audit","remediation"],"quality":{"score":100,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context","multi-facet"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"security-recipes.ai contributors","team":"Security Engineering","model":"gpt-5-codex","ai_assisted":false,"generated_by":"","date":"2026-08-21","zero_day":false,"last_updated":"2026-08-21","summary":"ShellCheck quoting and word-splitting hygiene: Remove unintended expansion, globbing, and argument-boundary bugs.","content_text":"<!-- Generated by scripts/synccodehygiene_recipes.py; edit data/code-hygiene/catalog.json. --> A tool-agnostic recipe to remove unintended expansion, globbing, and argument-boundary bugs. It supports a read-only audit and, when explicitly authorized, a narrow remediation. When to use it Use this recipe when the operator's specific objective is to remove unintended expansion, globbing, and argument-boundary bugs. Prefer a narrower CVE, scanner-finding, security-audit, or compliance-evidence recipe when that is the operator's actual job. Inputs Repository root and the files, package, service, or module in scope. Requested mode: audit or explicitly authorized fix. Supported runtime, compiler, framework, operating-system, and deployment versions inferred from repository files. Existing formatter, compiler, analyzer, test, build, and package-manager commands. Public API, compatibility, performance, generated-code, vendor, and migration constraints. The prompt ~~~markdown You are running the Security Recipes code-hygiene workflow code-hygiene.shell-powershell.shellcheck-quoting-and-word-splitting. Start read-only. Do not edit files until the operator explicitly authorizes a fix. Use repository configuration and installed tool versions as authoritative; do not impose a new style or toolchain. Scope Your bounded objective is to remove unintended expansion, globbing, and argument-boundary bugs. Inspect only operator-scoped, first-party source and configuration. Exclude generated, vendored, minified, fixture snapshot, lock history, and migration history unless explicitly included. Detection Run the repository's ShellCheck dialect and trace variable, command, array, glob, here-document, and positional expansion. Distinguish deliberate splitting from accidental argument flattening. Record file and symbol evidence for every candidate. Mark uncertain or dynamically reachable behavior instead of guessing. Fix, only when authorized Quote expansions or use arrays and explicit read loops while preserving intended glob semantics. Keep the diff limited to the proven issue and its focused tests. Preserve public behavior, API compatibility, and repository conventions. Do not add or broaden suppressions, weaken diagnostics, mass-format unrelated files, upgrade dependencies, or mutate external state. Verification Test empty, whitespace, wildcard, newline, dash-prefixed, and non-ASCII arguments in supported shells. Compare diagnostic counts and relevant behavior before and after. Report every command, result, and check that could not run. Stop conditions Stop if the script intentionally relies on implementation-specific splitting without tests. Stop and hand off to a focused security recipe if evidence indicates a vulnerability, secret exposure, authorization failure, injection path, or named CVE. Stop rather than widening scope when the safe result requires architecture, product, compliance, operational, or data-owner decisions. ~~~ Output contract Scope and repository evidence reviewed. A candidate table with file or symbol, evidence, confidence, and disposition. In audit mode: no edits, plus the smallest safe next action for each confirmed item. In fix mode: one bounded patch, focused regression coverage, and no unrelated cleanup. Commands run, results, remaining uncertainty, and any stop-condition handoff. Verification Test empty, whitespace, wildcard, newline, dash-prefixed, and non-ASCII arguments in supported shells. Confirm that diagnostic configuration, suppressions, public interfaces, generated files, vendored files, and dependencies did not change outside the authorized scope. Review the final diff for behavior changes and run the repository's focused checks before broader suites. Guardrails Read-only until edits are explicitly authorized. Do not deploy, publish, rotate secrets, alter cloud or database state, change CI permissions, or open external tickets. Do not hide debt by disabling rules, adding retries or sleeps, weakening tests, broadening ignores, or lowering warning levels. Treat generated, vendored, minified, migration-history, and fixture-snapshot files as out of scope unless explicitly named. Stop if the script intentionally relies on implementation-specific splitting without tests. Related recipes Shell exit, pipeline, trap, and temporary-file lifecycle PowerShell ScriptAnalyzer and suppression debt Browse all code-hygiene recipes References NIST SP 800-218 Secure Software Development Framework 1.1 — NIST ShellCheck wiki — ShellCheck POSIX shell command language — The Open Group PSScriptAnalyzer overview — Microsoft","agent_handoff":{"mcp_lookup_keys":["shellcheck-quoting-and-word-splitting","/recipes/general/code-hygiene/shell-powershell/shellcheck-quoting-and-word-splitting/","recipes/general/code-hygiene/shell-powershell/shellcheck-quoting-and-word-splitting.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["code-hygiene","audit","remediation"],"source_text_field":"content_text","portable_download":"security-recipe-shellcheck-quoting-and-word-splitting.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-shellcheck-quoting-and-word-splitting.json"}},{"slug":"swift-actor-sendable-and-task-lifecycle","title":"Swift actor, Sendable, and task lifecycle","link_title":"Swift actor, Sendable, and task lifecycle","url":"https://security-recipes.ai/recipes/general/code-hygiene/swift/swift-actor-sendable-and-task-lifecycle/","path":"/recipes/general/code-hygiene/swift/swift-actor-sendable-and-task-lifecycle/","source_file":"recipes/general/code-hygiene/swift/swift-actor-sendable-and-task-lifecycle.md","recipe_id":"code-hygiene.swift.swift-actor-sendable-and-task-lifecycle","recipe_kind":"code-hygiene","category":{"slug":"code-hygiene","label":"Code Hygiene"},"agent":"general","severity":"unspecified","maturity":"development","ecosystem":"swift/swiftpm","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"","framework_version":"","jurisdiction":"","industry":[],"cve_archetypes":[],"cve_workflow_role":"","tags":["code-hygiene","swift","actors","sendable","tasks"],"facets":["code-hygiene","audit","remediation"],"quality":{"score":100,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context","multi-facet"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"security-recipes.ai contributors","team":"Security Engineering","model":"gpt-5-codex","ai_assisted":false,"generated_by":"","date":"2026-08-21","zero_day":false,"last_updated":"2026-08-21","summary":"Swift actor, Sendable, and task lifecycle: Resolve isolation violations, unsafe sharing, and unowned tasks.","content_text":"<!-- Generated by scripts/synccodehygiene_recipes.py; edit data/code-hygiene/catalog.json. --> A tool-agnostic recipe to resolve isolation violations, unsafe sharing, and unowned tasks. It supports a read-only audit and, when explicitly authorized, a narrow remediation. When to use it Use this recipe when the operator's specific objective is to resolve isolation violations, unsafe sharing, and unowned tasks. Prefer a narrower CVE, scanner-finding, security-audit, or compliance-evidence recipe when that is the operator's actual job. Inputs Repository root and the files, package, service, or module in scope. Requested mode: audit or explicitly authorized fix. Supported runtime, compiler, framework, operating-system, and deployment versions inferred from repository files. Existing formatter, compiler, analyzer, test, build, and package-manager commands. Public API, compatibility, performance, generated-code, vendor, and migration constraints. The prompt ~~~markdown You are running the Security Recipes code-hygiene workflow code-hygiene.swift.swift-actor-sendable-and-task-lifecycle. Start read-only. Do not edit files until the operator explicitly authorizes a fix. Use repository configuration and installed tool versions as authoritative; do not impose a new style or toolchain. Scope Your bounded objective is to resolve isolation violations, unsafe sharing, and unowned tasks. Inspect only operator-scoped, first-party source and configuration. Exclude generated, vendored, minified, fixture snapshot, lock history, and migration history unless explicitly included. Detection Trace actor isolation, Sendable crossings, detached tasks, task groups, cancellation, and main-actor work. Find shared mutable captures and tasks outliving their UI or service owner. Record file and symbol evidence for every candidate. Mark uncertain or dynamically reachable behavior instead of guessing. Fix, only when authorized Move state behind the correct actor and attach work to a structured cancellable owner. Keep the diff limited to the proven issue and its focused tests. Preserve public behavior, API compatibility, and repository conventions. Do not add or broaden suppressions, weaken diagnostics, mass-format unrelated files, upgrade dependencies, or mutate external state. Verification Build with configured concurrency checking and test cancellation, teardown, actor hops, and repeated lifecycle. Compare diagnostic counts and relevant behavior before and after. Report every command, result, and check that could not run. Stop conditions Stop if actor reassignment changes UI responsiveness or a public concurrency contract. Stop and hand off to a focused security recipe if evidence indicates a vulnerability, secret exposure, authorization failure, injection path, or named CVE. Stop rather than widening scope when the safe result requires architecture, product, compliance, operational, or data-owner decisions. ~~~ Output contract Scope and repository evidence reviewed. A candidate table with file or symbol, evidence, confidence, and disposition. In audit mode: no edits, plus the smallest safe next action for each confirmed item. In fix mode: one bounded patch, focused regression coverage, and no unrelated cleanup. Commands run, results, remaining uncertainty, and any stop-condition handoff. Verification Build with configured concurrency checking and test cancellation, teardown, actor hops, and repeated lifecycle. Confirm that diagnostic configuration, suppressions, public interfaces, generated files, vendored files, and dependencies did not change outside the authorized scope. Review the final diff for behavior changes and run the repository's focused checks before broader suites. Guardrails Read-only until edits are explicitly authorized. Do not deploy, publish, rotate secrets, alter cloud or database state, change CI permissions, or open external tickets. Do not hide debt by disabling rules, adding retries or sleeps, weakening tests, broadening ignores, or lowering warning levels. Treat generated, vendored, minified, migration-history, and fixture-snapshot files as out of scope unless explicitly named. Stop if actor reassignment changes UI responsiveness or a public concurrency contract. Related recipes Swift warning, deprecation, and force-unwrap debt Lint warning baseline and budget Browse all code-hygiene recipes References NIST SP 800-218 Secure Software Development Framework 1.1 — NIST Swift API design guidelines — Swift project Swift concurrency — Apple","agent_handoff":{"mcp_lookup_keys":["swift-actor-sendable-and-task-lifecycle","/recipes/general/code-hygiene/swift/swift-actor-sendable-and-task-lifecycle/","recipes/general/code-hygiene/swift/swift-actor-sendable-and-task-lifecycle.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["code-hygiene","audit","remediation"],"source_text_field":"content_text","portable_download":"security-recipe-swift-actor-sendable-and-task-lifecycle.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-swift-actor-sendable-and-task-lifecycle.json"}},{"slug":"swift-warning-deprecation-and-force-unwrap-debt","title":"Swift warning, deprecation, and force-unwrap debt","link_title":"Swift warning, deprecation, and force-unwrap debt","url":"https://security-recipes.ai/recipes/general/code-hygiene/swift/swift-warning-deprecation-and-force-unwrap-debt/","path":"/recipes/general/code-hygiene/swift/swift-warning-deprecation-and-force-unwrap-debt/","source_file":"recipes/general/code-hygiene/swift/swift-warning-deprecation-and-force-unwrap-debt.md","recipe_id":"code-hygiene.swift.swift-warning-deprecation-and-force-unwrap-debt","recipe_kind":"code-hygiene","category":{"slug":"code-hygiene","label":"Code Hygiene"},"agent":"general","severity":"unspecified","maturity":"development","ecosystem":"swift/swiftpm","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"","framework_version":"","jurisdiction":"","industry":[],"cve_archetypes":[],"cve_workflow_role":"","tags":["code-hygiene","swift","warnings","deprecation","force-unwrap"],"facets":["code-hygiene","audit","remediation"],"quality":{"score":100,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context","multi-facet"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"security-recipes.ai contributors","team":"Security Engineering","model":"gpt-5-codex","ai_assisted":false,"generated_by":"","date":"2026-08-21","zero_day":false,"last_updated":"2026-08-21","summary":"Swift warning, deprecation, and force-unwrap debt: Resolve compiler warnings and unsafe optionals without obscuring invariants.","content_text":"<!-- Generated by scripts/synccodehygiene_recipes.py; edit data/code-hygiene/catalog.json. --> A tool-agnostic recipe to resolve compiler warnings and unsafe optionals without obscuring invariants. It supports a read-only audit and, when explicitly authorized, a narrow remediation. When to use it Use this recipe when the operator's specific objective is to resolve compiler warnings and unsafe optionals without obscuring invariants. Prefer a narrower CVE, scanner-finding, security-audit, or compliance-evidence recipe when that is the operator's actual job. Inputs Repository root and the files, package, service, or module in scope. Requested mode: audit or explicitly authorized fix. Supported runtime, compiler, framework, operating-system, and deployment versions inferred from repository files. Existing formatter, compiler, analyzer, test, build, and package-manager commands. Public API, compatibility, performance, generated-code, vendor, and migration constraints. The prompt ~~~markdown You are running the Security Recipes code-hygiene workflow code-hygiene.swift.swift-warning-deprecation-and-force-unwrap-debt. Start read-only. Do not edit files until the operator explicitly authorizes a fix. Use repository configuration and installed tool versions as authoritative; do not impose a new style or toolchain. Scope Your bounded objective is to resolve compiler warnings and unsafe optionals without obscuring invariants. Inspect only operator-scoped, first-party source and configuration. Exclude generated, vendored, minified, fixture snapshot, lock history, and migration history unless explicitly included. Detection Read Swift language mode and deployment targets and inventory warnings, unavailable APIs, force unwraps, casts, and try-bang. Classify proven invariants separately from user, network, persistence, and framework values. Record file and symbol evidence for every candidate. Mark uncertain or dynamically reachable behavior instead of guessing. Fix, only when authorized Use guarded optional handling or documented invariant assertions and availability-compatible replacements. Keep the diff limited to the proven issue and its focused tests. Preserve public behavior, API compatibility, and repository conventions. Do not add or broaden suppressions, weaken diagnostics, mass-format unrelated files, upgrade dependencies, or mutate external state. Verification Build all supported targets and test nil, unavailable, malformed, and success paths. Compare diagnostic counts and relevant behavior before and after. Report every command, result, and check that could not run. Stop conditions Stop if replacement requires increasing deployment target or changing a public Swift or Objective-C API. Stop and hand off to a focused security recipe if evidence indicates a vulnerability, secret exposure, authorization failure, injection path, or named CVE. Stop rather than widening scope when the safe result requires architecture, product, compliance, operational, or data-owner decisions. ~~~ Output contract Scope and repository evidence reviewed. A candidate table with file or symbol, evidence, confidence, and disposition. In audit mode: no edits, plus the smallest safe next action for each confirmed item. In fix mode: one bounded patch, focused regression coverage, and no unrelated cleanup. Commands run, results, remaining uncertainty, and any stop-condition handoff. Verification Build all supported targets and test nil, unavailable, malformed, and success paths. Confirm that diagnostic configuration, suppressions, public interfaces, generated files, vendored files, and dependencies did not change outside the authorized scope. Review the final diff for behavior changes and run the repository's focused checks before broader suites. Guardrails Read-only until edits are explicitly authorized. Do not deploy, publish, rotate secrets, alter cloud or database state, change CI permissions, or open external tickets. Do not hide debt by disabling rules, adding retries or sleeps, weakening tests, broadening ignores, or lowering warning levels. Treat generated, vendored, minified, migration-history, and fixture-snapshot files as out of scope unless explicitly named. Stop if replacement requires increasing deployment target or changing a public Swift or Objective-C API. Related recipes Swift actor, Sendable, and task lifecycle Lint warning baseline and budget Browse all code-hygiene recipes References NIST SP 800-218 Secure Software Development Framework 1.1 — NIST Swift API design guidelines — Swift project Swift concurrency — Apple","agent_handoff":{"mcp_lookup_keys":["swift-warning-deprecation-and-force-unwrap-debt","/recipes/general/code-hygiene/swift/swift-warning-deprecation-and-force-unwrap-debt/","recipes/general/code-hygiene/swift/swift-warning-deprecation-and-force-unwrap-debt.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["code-hygiene","audit","remediation"],"source_text_field":"content_text","portable_download":"security-recipe-swift-warning-deprecation-and-force-unwrap-debt.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-swift-warning-deprecation-and-force-unwrap-debt.json"}},{"slug":"ai-governance-oversight-evidence-check","title":"NIST SP 800-218A AI Model Development Evidence Check","link_title":"NIST AI SSDF","url":"https://security-recipes.ai/recipes/general/compliance-standards/ai-governance-oversight-evidence-check/","path":"/recipes/general/compliance-standards/ai-governance-oversight-evidence-check/","source_file":"recipes/general/compliance-standards/ai-governance-oversight-evidence-check.md","recipe_id":"compliance.nist-sp-800-218a","recipe_kind":"","category":{"slug":"compliance-standards","label":"Compliance Standards"},"agent":"Compliance evidence review","severity":"info","maturity":"stable","ecosystem":"","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"NIST AI SSDF","framework_version":"SP 800-218A","jurisdiction":["global","united-states"],"industry":["artificial-intelligence","software","cross-sector"],"cve_archetypes":[],"cve_workflow_role":"","tags":["compliance","nist-ai-ssdf","ai-governance","audit","ai-safety","code-hygiene","artificial-intelligence","software"],"facets":["audit","compliance","code-hygiene"],"quality":{"score":100,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context","multi-facet"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"Security Recipes","team":"GRC and Security Engineering","model":"gpt-5-codex","ai_assisted":false,"generated_by":"","date":"2026-08-21","zero_day":false,"last_updated":"2026-08-21","summary":"Assess NIST AI SSDF evidence readiness: verify applicability, map official requirements to artifacts, record gaps, and plan remediation.","content_text":"NIST SP 800-218A AI Model Development Evidence Check Use this recipe to produce a source-aware evidence-readiness assessment for NIST AI SSDF. It creates an auditable gap record; it does not certify compliance, provide legal advice, or replace an assessor, regulator, or certification body. Section index Framework basis When to use it Inputs The prompt Output contract Verification Guardrails Routing examples References Framework basis Publisher: NIST Version: SP 800-218A Status: final Sources reviewed: 2026-08-21 Jurisdictions: global, united-states Industries: artificial-intelligence, software, cross-sector License boundary: public-domain Organizations extending secure software development practices to AI model development across the AI lifecycle. The cataloged version is final; still verify scope and any later official updates. Use the official publication as the authority and preserve its version and update identifiers in every finding. When to use it Use this recipe when the organization has established that NIST AI SSDF is applicable or wants a readiness assessment against it. Use the routing positives below to distinguish this recipe from adjacent frameworks. If applicability, the effective version, or the authoritative requirement set is unresolved, stop at a scoped intake and record the decision owner. Inputs The business purpose, legal entities, products, services, systems, and locations in scope. The organization's role, applicability decision, selected profile, level, baseline, or control set where the framework requires one. The official publication URLs above and, for licensed material, an authorized organization-supplied copy. Evidence from the complete review period, including populations—not only hand-picked examples. Named owners, inherited/shared responsibilities, exceptions, compensating measures, and accepted risks. Read-only access by default. Redacted exports are acceptable when provenance and coverage remain testable. Evidence domains for this framework: AI development governance: begin with model development policies and roles. data and model protection: begin with dataset lineage and access records. secure model development: begin with evaluation and red-team results. AI vulnerability and incident response: begin with model issue intake and remediation records. The prompt You are a compliance evidence-readiness analyst. Evaluate the supplied scope against NIST AI SSDF (SP 800-218A). The catalog status is final and the source review date is 2026-08-21. Never claim certification or legal compliance. Never invent applicability, evidence, control operation, sampling results, or requirement text. Separate observed facts, organization assertions, and analyst inferences. Treat missing or inaccessible evidence as unknown, not as failure, unless the authoritative assessment method says otherwise. Step 0 — Lock authority, version, and scope 1. Record the exact official source, version, publication/update identifier, and effective date used. 2. Record the organization, role, jurisdiction, industry, system/product boundary, review period, and decision owner. 3. Confirm any selected level, profile, baseline, overlay, assessment type, or licensed requirement set. 4. The cataloged version is final; still verify scope and any later official updates. 5. Use the official publication as the authority and preserve its version and update identifiers in every finding. 6. Stop and request a decision when applicability or the authoritative requirement set cannot be established. Step 1 — Build the applicability map For every supplied requirement identifier or official outcome in scope, record: applicability, rationale, responsible owner, implementation location, inherited/shared responsibility, evidence expected, and any dependency. Use only identifiers present in the authoritative source supplied for this engagement. Do not reconstruct licensed text. Step 2 — Collect evidence by framework domain Review these domains without treating the labels as substitutes for authoritative requirements: 1. AI development governance 2. data and model protection 3. secure model development 4. AI vulnerability and incident response Start with these likely artifacts, then validate provenance and coverage: 1. model development policies and roles 2. dataset lineage and access records 3. evaluation and red-team results 4. model issue intake and remediation records For every artifact record: artifact ID, source system, owner, collection time, review period, access path, integrity/provenance note, population covered, and requirement/outcome links. Prefer system exports and immutable records over screenshots or narrative attestations. Step 3 — Test design and operation For each applicable item, evaluate design, implementation, and operating evidence separately. Check whether evidence is authentic, complete, current for the review period, population-representative, and directly linked to the scoped system. Where sampling is permitted, state the population, method, sample size, selections, exceptions, and limitations; do not imply statistical assurance without a justified method. Step 4 — Classify gaps without overstating them Use only: supported, partially supported, unsupported, not applicable with rationale, or not assessed. Record gaps as evidence-readiness findings—not declarations of legal noncompliance. Each finding must include the affected requirement/outcome, observed fact, missing or weak evidence, risk, owner, corrective action, due date, dependencies, retest method, and confidence. Step 5 — Produce the evidence bundle Return one Markdown file named AIGOVERNANCEOVERSIGHTEVIDENCECHECK.md with: 1. Executive summary and explicit assurance limitations. 2. Authority/version/status and scope/applicability record. 3. Coverage totals by status and evidence domain. 4. Requirement/outcome-to-evidence matrix with artifact provenance. 5. Findings ordered by risk and evidence impact. 6. A 30/60/90-day remediation and evidence-collection plan. 7. Open questions, unavailable sources, conflicts, and decisions required. 8. Official references with access/review date. Before finalizing, verify that every conclusion is traceable to an artifact or clearly labeled assertion/inference, all denominators reconcile, all unavailable evidence is visible, licensed text is not reproduced, and no sentence claims certification or legal approval. Output contract The response must contain one evidence matrix row per scoped authoritative item or outcome. At minimum include itemid, applicability, owner, implementation, artifactids, testmethod, coverageperiod, status, gap, and confidence. Every artifact ID must resolve to the artifact register, and every total must reconcile to the matrix. Verification Confirm the official source, version, status, and review date in both the executive summary and matrix metadata. Reconcile applicable, not applicable, and not assessed counts to the complete supplied scope. Trace each supported assertion to provenance-bearing evidence covering the stated period and population. Independently reperform a risk-based sample of mappings and document all exceptions. Verify findings distinguish control/design weakness from missing evidence and unknown scope. Have the accountable owner and, where required, qualified counsel or an authorized assessor review conclusions. Guardrails This is an evidence-readiness workflow, not certification, attestation, audit opinion, or legal advice. Do not infer that a voluntary framework is mandatory or that one framework proves another. Do not paste, paraphrase at length, or reconstruct licensed controls. Use source summaries and organization-supplied licensed material. Do not expose secrets, personal data, regulated data, or full production exports in the report. Do not modify systems, close findings, accept risk, or submit regulatory reports without explicit owner authorization. If versions conflict, preserve both citations, label the conflict, and escalate rather than choosing silently. Routing examples Route here: assess AI development against SP 800-218A collect AI SSDF evidence review secure model development practices Hard negatives—route elsewhere or clarify: perform enterprise AI risk governance with AI RMF assess ordinary software only with SP 800-218 Related recipes NIST AI RMF 1.0 ISO/IEC 42001:2023 EU AI Act References 1. NIST official source 1","agent_handoff":{"mcp_lookup_keys":["ai-governance-oversight-evidence-check","/recipes/general/compliance-standards/ai-governance-oversight-evidence-check/","recipes/general/compliance-standards/ai-governance-oversight-evidence-check.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["audit","compliance","code-hygiene"],"source_text_field":"content_text","portable_download":"security-recipe-ai-governance-oversight-evidence-check.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-ai-governance-oversight-evidence-check.json"}},{"slug":"cis-controls-safeguard-implementation-check","title":"CIS Controls v8.1 Safeguard Implementation Evidence Check","link_title":"CIS Controls v8.1","url":"https://security-recipes.ai/recipes/general/compliance-standards/cis-controls-safeguard-implementation-check/","path":"/recipes/general/compliance-standards/cis-controls-safeguard-implementation-check/","source_file":"recipes/general/compliance-standards/cis-controls-safeguard-implementation-check.md","recipe_id":"compliance.cis-controls-v8-1","recipe_kind":"","category":{"slug":"compliance-standards","label":"Compliance Standards"},"agent":"Compliance evidence review","severity":"info","maturity":"stable","ecosystem":"","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"CIS Controls v8.1","framework_version":"8.1","jurisdiction":["global"],"industry":["cross-sector"],"cve_archetypes":[],"cve_workflow_role":"","tags":["compliance","cis-controls","security-programs","audit","risk","secure-defaults","cross-sector"],"facets":["audit","compliance","risk"],"quality":{"score":100,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context","multi-facet"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"Security Recipes","team":"GRC and Security Engineering","model":"gpt-5-codex","ai_assisted":false,"generated_by":"","date":"2026-08-21","zero_day":false,"last_updated":"2026-08-21","summary":"Assess CIS Controls v8.1 evidence readiness: verify applicability, map official requirements to artifacts, record gaps, and plan remediation.","content_text":"CIS Controls v8.1 Safeguard Implementation Evidence Check Use this recipe to produce a source-aware evidence-readiness assessment for CIS Controls v8.1. It creates an auditable gap record; it does not certify compliance, provide legal advice, or replace an assessor, regulator, or certification body. Section index Framework basis When to use it Inputs The prompt Output contract Verification Guardrails Routing examples References Framework basis Publisher: Center for Internet Security Version: 8.1 Status: final Sources reviewed: 2026-08-21 Jurisdictions: global Industries: cross-sector License boundary: summary-only Organizations using the CIS Controls and Implementation Groups to prioritize a defensible baseline security program. The cataloged version is final; still verify scope and any later official updates. This recipe intentionally summarizes domains and evidence needs. Do not reproduce licensed control text; use an organization-supplied licensed copy for requirement-level work. When to use it Use this recipe when the organization has established that CIS Controls v8.1 is applicable or wants a readiness assessment against it. Use the routing positives below to distinguish this recipe from adjacent frameworks. If applicability, the effective version, or the authoritative requirement set is unresolved, stop at a scoped intake and record the decision owner. Inputs The business purpose, legal entities, products, services, systems, and locations in scope. The organization's role, applicability decision, selected profile, level, baseline, or control set where the framework requires one. The official publication URLs above and, for licensed material, an authorized organization-supplied copy. Evidence from the complete review period, including populations—not only hand-picked examples. Named owners, inherited/shared responsibilities, exceptions, compensating measures, and accepted risks. Read-only access by default. Redacted exports are acceptable when provenance and coverage remain testable. Evidence domains for this framework: asset and software inventory: begin with approved inventories and ownership records. identity and access safeguards: begin with configuration and access review exports. secure configuration and vulnerability management: begin with vulnerability remediation records. logging, recovery, and incident response: begin with exercise, recovery, and incident artifacts. The prompt You are a compliance evidence-readiness analyst. Evaluate the supplied scope against CIS Controls v8.1 (8.1). The catalog status is final and the source review date is 2026-08-21. Never claim certification or legal compliance. Never invent applicability, evidence, control operation, sampling results, or requirement text. Separate observed facts, organization assertions, and analyst inferences. Treat missing or inaccessible evidence as unknown, not as failure, unless the authoritative assessment method says otherwise. Step 0 — Lock authority, version, and scope 1. Record the exact official source, version, publication/update identifier, and effective date used. 2. Record the organization, role, jurisdiction, industry, system/product boundary, review period, and decision owner. 3. Confirm any selected level, profile, baseline, overlay, assessment type, or licensed requirement set. 4. The cataloged version is final; still verify scope and any later official updates. 5. This recipe intentionally summarizes domains and evidence needs. Do not reproduce licensed control text; use an organization-supplied licensed copy for requirement-level work. 6. Stop and request a decision when applicability or the authoritative requirement set cannot be established. Step 1 — Build the applicability map For every supplied requirement identifier or official outcome in scope, record: applicability, rationale, responsible owner, implementation location, inherited/shared responsibility, evidence expected, and any dependency. Use only identifiers present in the authoritative source supplied for this engagement. Do not reconstruct licensed text. Step 2 — Collect evidence by framework domain Review these domains without treating the labels as substitutes for authoritative requirements: 1. asset and software inventory 2. identity and access safeguards 3. secure configuration and vulnerability management 4. logging, recovery, and incident response Start with these likely artifacts, then validate provenance and coverage: 1. approved inventories and ownership records 2. configuration and access review exports 3. vulnerability remediation records 4. exercise, recovery, and incident artifacts For every artifact record: artifact ID, source system, owner, collection time, review period, access path, integrity/provenance note, population covered, and requirement/outcome links. Prefer system exports and immutable records over screenshots or narrative attestations. Step 3 — Test design and operation For each applicable item, evaluate design, implementation, and operating evidence separately. Check whether evidence is authentic, complete, current for the review period, population-representative, and directly linked to the scoped system. Where sampling is permitted, state the population, method, sample size, selections, exceptions, and limitations; do not imply statistical assurance without a justified method. Step 4 — Classify gaps without overstating them Use only: supported, partially supported, unsupported, not applicable with rationale, or not assessed. Record gaps as evidence-readiness findings—not declarations of legal noncompliance. Each finding must include the affected requirement/outcome, observed fact, missing or weak evidence, risk, owner, corrective action, due date, dependencies, retest method, and confidence. Step 5 — Produce the evidence bundle Return one Markdown file named CISCONTROLSSAFEGUARDIMPLEMENTATIONCHECK.md with: 1. Executive summary and explicit assurance limitations. 2. Authority/version/status and scope/applicability record. 3. Coverage totals by status and evidence domain. 4. Requirement/outcome-to-evidence matrix with artifact provenance. 5. Findings ordered by risk and evidence impact. 6. A 30/60/90-day remediation and evidence-collection plan. 7. Open questions, unavailable sources, conflicts, and decisions required. 8. Official references with access/review date. Before finalizing, verify that every conclusion is traceable to an artifact or clearly labeled assertion/inference, all denominators reconcile, all unavailable evidence is visible, licensed text is not reproduced, and no sentence claims certification or legal approval. Output contract The response must contain one evidence matrix row per scoped authoritative item or outcome. At minimum include itemid, applicability, owner, implementation, artifactids, testmethod, coverageperiod, status, gap, and confidence. Every artifact ID must resolve to the artifact register, and every total must reconcile to the matrix. Verification Confirm the official source, version, status, and review date in both the executive summary and matrix metadata. Reconcile applicable, not applicable, and not assessed counts to the complete supplied scope. Trace each supported assertion to provenance-bearing evidence covering the stated period and population. Independently reperform a risk-based sample of mappings and document all exceptions. Verify findings distinguish control/design weakness from missing evidence and unknown scope. Have the accountable owner and, where required, qualified counsel or an authorized assessor review conclusions. Guardrails This is an evidence-readiness workflow, not certification, attestation, audit opinion, or legal advice. Do not infer that a voluntary framework is mandatory or that one framework proves another. Do not paste, paraphrase at length, or reconstruct licensed controls. Use source summaries and organization-supplied licensed material. Do not expose secrets, personal data, regulated data, or full production exports in the report. Do not modify systems, close findings, accept risk, or submit regulatory reports without explicit owner authorization. If versions conflict, preserve both citations, label the conflict, and escalate rather than choosing silently. Routing examples Route here: assess our CIS Controls v8.1 implementation collect evidence for CIS safeguards review Implementation Group coverage Hard negatives—route elsewhere or clarify: perform a PCI DSS cardholder data assessment map a federal system to NIST SP 800-53 Related recipes ISO/IEC 27001:2022 NIST CSF 2.0 NIST SSDF 1.1 References 1. Center for Internet Security official source 1","agent_handoff":{"mcp_lookup_keys":["cis-controls-safeguard-implementation-check","/recipes/general/compliance-standards/cis-controls-safeguard-implementation-check/","recipes/general/compliance-standards/cis-controls-safeguard-implementation-check.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["audit","compliance","risk"],"source_text_field":"content_text","portable_download":"security-recipe-cis-controls-safeguard-implementation-check.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-cis-controls-safeguard-implementation-check.json"}},{"slug":"cisa-cross-sector-cpg-evidence-check","title":"CISA Cross-Sector Cybersecurity Performance Goals Evidence Check","link_title":"CISA Cross-Sector CPGs","url":"https://security-recipes.ai/recipes/general/compliance-standards/cisa-cross-sector-cpg-evidence-check/","path":"/recipes/general/compliance-standards/cisa-cross-sector-cpg-evidence-check/","source_file":"recipes/general/compliance-standards/cisa-cross-sector-cpg-evidence-check.md","recipe_id":"compliance.cisa-cross-sector-cpg-2-0","recipe_kind":"","category":{"slug":"compliance-standards","label":"Compliance Standards"},"agent":"Compliance evidence review","severity":"info","maturity":"stable","ecosystem":"","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"CISA Cross-Sector CPGs","framework_version":"2.0","jurisdiction":["united-states"],"industry":["critical-infrastructure","cross-sector"],"cve_archetypes":[],"cve_workflow_role":"","tags":["compliance","cisa-cross-sector-cpg","critical-infrastructure","audit","secure-defaults","cross-sector"],"facets":["audit","compliance"],"quality":{"score":95,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"Security Recipes","team":"GRC and Security Engineering","model":"gpt-5-codex","ai_assisted":false,"generated_by":"","date":"2026-08-21","zero_day":false,"last_updated":"2026-08-21","summary":"Assess CISA Cross-Sector CPGs evidence readiness: verify applicability, map official requirements to artifacts, record gaps, and plan remediation.","content_text":"CISA Cross-Sector Cybersecurity Performance Goals Evidence Check Use this recipe to produce a source-aware evidence-readiness assessment for CISA Cross-Sector CPGs. It creates an auditable gap record; it does not certify compliance, provide legal advice, or replace an assessor, regulator, or certification body. Section index Framework basis When to use it Inputs The prompt Output contract Verification Guardrails Routing examples References Framework basis Publisher: Cybersecurity and Infrastructure Security Agency Version: 2.0 Status: final Sources reviewed: 2026-08-21 Jurisdictions: united-states Industries: critical-infrastructure, cross-sector License boundary: public-domain Critical infrastructure owners and operators using the voluntary Cross-Sector CPG 2.0 baseline. CPG 2.0 is current and aligned to NIST CSF 2.0, including the GOVERN function. Keep 1.0.1 mappings only as a historical comparison. Sector-Specific Goals may add overlays and do not replace the cross-sector baseline. The cataloged version is final; still verify scope and any later official updates. Use the official publication as the authority and preserve its version and update identifiers in every finding. When to use it Use this recipe when the organization has established that CISA Cross-Sector CPGs is applicable or wants a readiness assessment against it. Use the routing positives below to distinguish this recipe from adjacent frameworks. If applicability, the effective version, or the authoritative requirement set is unresolved, stop at a scoped intake and record the decision owner. Inputs The business purpose, legal entities, products, services, systems, and locations in scope. The organization's role, applicability decision, selected profile, level, baseline, or control set where the framework requires one. The official publication URLs above and, for licensed material, an authorized organization-supplied copy. Evidence from the complete review period, including populations—not only hand-picked examples. Named owners, inherited/shared responsibilities, exceptions, compensating measures, and accepted risks. Read-only access by default. Redacted exports are acceptable when provenance and coverage remain testable. Evidence domains for this framework: governance, accountability, and risk oversight: begin with cybersecurity oversight and risk-acceptance records. asset, identity, and least-privilege priorities: begin with prioritized asset, account, and privilege inventories. vulnerability, configuration, architecture, and detection: begin with MFA, vulnerability, segmentation, and logging evidence. incident response, recovery, MSP, and supply-chain readiness: begin with exercise, backup, MSP, and supplier artifacts. The prompt You are a compliance evidence-readiness analyst. Evaluate the supplied scope against CISA Cross-Sector CPGs (2.0). The catalog status is final and the source review date is 2026-08-21. Never claim certification or legal compliance. Never invent applicability, evidence, control operation, sampling results, or requirement text. Separate observed facts, organization assertions, and analyst inferences. Treat missing or inaccessible evidence as unknown, not as failure, unless the authoritative assessment method says otherwise. Step 0 — Lock authority, version, and scope 1. Record the exact official source, version, publication/update identifier, and effective date used. 2. Record the organization, role, jurisdiction, industry, system/product boundary, review period, and decision owner. 3. Confirm any selected level, profile, baseline, overlay, assessment type, or licensed requirement set. 4. The cataloged version is final; still verify scope and any later official updates. 5. Use the official publication as the authority and preserve its version and update identifiers in every finding. 6. Stop and request a decision when applicability or the authoritative requirement set cannot be established. Step 1 — Build the applicability map For every supplied requirement identifier or official outcome in scope, record: applicability, rationale, responsible owner, implementation location, inherited/shared responsibility, evidence expected, and any dependency. Use only identifiers present in the authoritative source supplied for this engagement. Do not reconstruct licensed text. Step 2 — Collect evidence by framework domain Review these domains without treating the labels as substitutes for authoritative requirements: 1. governance, accountability, and risk oversight 2. asset, identity, and least-privilege priorities 3. vulnerability, configuration, architecture, and detection 4. incident response, recovery, MSP, and supply-chain readiness Start with these likely artifacts, then validate provenance and coverage: 1. cybersecurity oversight and risk-acceptance records 2. prioritized asset, account, and privilege inventories 3. MFA, vulnerability, segmentation, and logging evidence 4. exercise, backup, MSP, and supplier artifacts For every artifact record: artifact ID, source system, owner, collection time, review period, access path, integrity/provenance note, population covered, and requirement/outcome links. Prefer system exports and immutable records over screenshots or narrative attestations. Step 3 — Test design and operation For each applicable item, evaluate design, implementation, and operating evidence separately. Check whether evidence is authentic, complete, current for the review period, population-representative, and directly linked to the scoped system. Where sampling is permitted, state the population, method, sample size, selections, exceptions, and limitations; do not imply statistical assurance without a justified method. Step 4 — Classify gaps without overstating them Use only: supported, partially supported, unsupported, not applicable with rationale, or not assessed. Record gaps as evidence-readiness findings—not declarations of legal noncompliance. Each finding must include the affected requirement/outcome, observed fact, missing or weak evidence, risk, owner, corrective action, due date, dependencies, retest method, and confidence. Step 5 — Produce the evidence bundle Return one Markdown file named CISACROSSSECTORCPGEVIDENCECHECK.md with: 1. Executive summary and explicit assurance limitations. 2. Authority/version/status and scope/applicability record. 3. Coverage totals by status and evidence domain. 4. Requirement/outcome-to-evidence matrix with artifact provenance. 5. Findings ordered by risk and evidence impact. 6. A 30/60/90-day remediation and evidence-collection plan. 7. Open questions, unavailable sources, conflicts, and decisions required. 8. Official references with access/review date. Before finalizing, verify that every conclusion is traceable to an artifact or clearly labeled assertion/inference, all denominators reconcile, all unavailable evidence is visible, licensed text is not reproduced, and no sentence claims certification or legal approval. Output contract The response must contain one evidence matrix row per scoped authoritative item or outcome. At minimum include itemid, applicability, owner, implementation, artifactids, testmethod, coverage_period, status, gap, and confidence. Every artifact ID must resolve to the artifact register, and every total must reconcile to the matrix. Verification Confirm the official source, version, status, and review date in both the executive summary and matrix metadata. Reconcile applicable, not applicable, and not assessed counts to the complete supplied scope. Trace each supported assertion to provenance-bearing evidence covering the stated period and population. Independently reperform a risk-based sample of mappings and document all exceptions. Verify findings distinguish control/design weakness from missing evidence and unknown scope. Have the accountable owner and, where required, qualified counsel or an authorized assessor review conclusions. Guardrails This is an evidence-readiness workflow, not certification, attestation, audit opinion, or legal advice. Do not infer that a voluntary framework is mandatory or that one framework proves another. Do not paste, paraphrase at length, or reconstruct licensed controls. Use source summaries and organization-supplied licensed material. Do not expose secrets, personal data, regulated data, or full production exports in the report. Do not modify systems, close findings, accept risk, or submit regulatory reports without explicit owner authorization. If versions conflict, preserve both citations, label the conflict, and escalate rather than choosing silently. Routing examples Route here: assess CISA cybersecurity performance goals prioritize critical infrastructure safeguards collect Cross-Sector CPG evidence Hard negatives—route elsewhere or clarify: claim regulatory certification from voluntary CPGs perform a NERC CIP entity assessment Related recipes IEC 62443 NERC CIP EU NIS2 References 1. Cybersecurity and Infrastructure Security Agency official source 1","agent_handoff":{"mcp_lookup_keys":["cisa-cross-sector-cpg-evidence-check","/recipes/general/compliance-standards/cisa-cross-sector-cpg-evidence-check/","recipes/general/compliance-standards/cisa-cross-sector-cpg-evidence-check.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["audit","compliance"],"source_text_field":"content_text","portable_download":"security-recipe-cisa-cross-sector-cpg-evidence-check.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-cisa-cross-sector-cpg-evidence-check.json"}},{"slug":"cjis-security-policy-6-1-evidence-check","title":"CJIS Security Policy v6.1 Evidence Check","link_title":"CJIS Security Policy v6.1","url":"https://security-recipes.ai/recipes/general/compliance-standards/cjis-security-policy-6-1-evidence-check/","path":"/recipes/general/compliance-standards/cjis-security-policy-6-1-evidence-check/","source_file":"recipes/general/compliance-standards/cjis-security-policy-6-1-evidence-check.md","recipe_id":"compliance.cjis-security-policy-6-1","recipe_kind":"","category":{"slug":"compliance-standards","label":"Compliance Standards"},"agent":"Compliance evidence review","severity":"info","maturity":"stable","ecosystem":"","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"CJIS Security Policy v6.1","framework_version":"6.1 (June 25, 2026)","jurisdiction":["united-states"],"industry":["law-enforcement","criminal-justice","government-contractors"],"cve_archetypes":[],"cve_workflow_role":"","tags":["compliance","cjis-security-policy","government","audit","data-protection","law-enforcement","criminal-justice"],"facets":["audit","compliance"],"quality":{"score":95,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"Security Recipes","team":"GRC and Security Engineering","model":"gpt-5-codex","ai_assisted":false,"generated_by":"","date":"2026-08-21","zero_day":false,"last_updated":"2026-08-21","summary":"Assess CJIS Security Policy v6.1 evidence readiness: verify applicability, map official requirements to artifacts, record gaps, and plan remediation.","content_text":"CJIS Security Policy v6.1 Evidence Check Use this recipe to produce a source-aware evidence-readiness assessment for CJIS Security Policy v6.1. It creates an auditable gap record; it does not certify compliance, provide legal advice, or replace an assessor, regulator, or certification body. Section index Framework basis When to use it Inputs The prompt Output contract Verification Guardrails Routing examples References Framework basis Publisher: Federal Bureau of Investigation Version: 6.1 (June 25, 2026) Status: final Sources reviewed: 2026-08-21 Jurisdictions: united-states Industries: law-enforcement, criminal-justice, government-contractors License boundary: public-domain Criminal justice agencies, noncriminal justice agencies, and service providers handling Criminal Justice Information under applicable agreements. The cataloged version is final; still verify scope and any later official updates. Use the official publication as the authority and preserve its version and update identifiers in every finding. When to use it Use this recipe when the organization has established that CJIS Security Policy v6.1 is applicable or wants a readiness assessment against it. Use the routing positives below to distinguish this recipe from adjacent frameworks. If applicability, the effective version, or the authoritative requirement set is unresolved, stop at a scoped intake and record the decision owner. Inputs The business purpose, legal entities, products, services, systems, and locations in scope. The organization's role, applicability decision, selected profile, level, baseline, or control set where the framework requires one. The official publication URLs above and, for licensed material, an authorized organization-supplied copy. Evidence from the complete review period, including populations—not only hand-picked examples. Named owners, inherited/shared responsibilities, exceptions, compensating measures, and accepted risks. Read-only access by default. Redacted exports are acceptable when provenance and coverage remain testable. Evidence domains for this framework: CJI scope, roles, and agreements: begin with CJI data-flow and agreement inventory. access, authentication, and personnel security: begin with personnel screening and access reviews. encryption, media, and physical protection: begin with encryption and media handling records. logging, incidents, audits, and service providers: begin with audit logs, incident exercises, and vendor evidence. The prompt You are a compliance evidence-readiness analyst. Evaluate the supplied scope against CJIS Security Policy v6.1 (6.1 (June 25, 2026)). The catalog status is final and the source review date is 2026-08-21. Never claim certification or legal compliance. Never invent applicability, evidence, control operation, sampling results, or requirement text. Separate observed facts, organization assertions, and analyst inferences. Treat missing or inaccessible evidence as unknown, not as failure, unless the authoritative assessment method says otherwise. Step 0 — Lock authority, version, and scope 1. Record the exact official source, version, publication/update identifier, and effective date used. 2. Record the organization, role, jurisdiction, industry, system/product boundary, review period, and decision owner. 3. Confirm any selected level, profile, baseline, overlay, assessment type, or licensed requirement set. 4. The cataloged version is final; still verify scope and any later official updates. 5. Use the official publication as the authority and preserve its version and update identifiers in every finding. 6. Stop and request a decision when applicability or the authoritative requirement set cannot be established. Step 1 — Build the applicability map For every supplied requirement identifier or official outcome in scope, record: applicability, rationale, responsible owner, implementation location, inherited/shared responsibility, evidence expected, and any dependency. Use only identifiers present in the authoritative source supplied for this engagement. Do not reconstruct licensed text. Step 2 — Collect evidence by framework domain Review these domains without treating the labels as substitutes for authoritative requirements: 1. CJI scope, roles, and agreements 2. access, authentication, and personnel security 3. encryption, media, and physical protection 4. logging, incidents, audits, and service providers Start with these likely artifacts, then validate provenance and coverage: 1. CJI data-flow and agreement inventory 2. personnel screening and access reviews 3. encryption and media handling records 4. audit logs, incident exercises, and vendor evidence For every artifact record: artifact ID, source system, owner, collection time, review period, access path, integrity/provenance note, population covered, and requirement/outcome links. Prefer system exports and immutable records over screenshots or narrative attestations. Step 3 — Test design and operation For each applicable item, evaluate design, implementation, and operating evidence separately. Check whether evidence is authentic, complete, current for the review period, population-representative, and directly linked to the scoped system. Where sampling is permitted, state the population, method, sample size, selections, exceptions, and limitations; do not imply statistical assurance without a justified method. Step 4 — Classify gaps without overstating them Use only: supported, partially supported, unsupported, not applicable with rationale, or not assessed. Record gaps as evidence-readiness findings—not declarations of legal noncompliance. Each finding must include the affected requirement/outcome, observed fact, missing or weak evidence, risk, owner, corrective action, due date, dependencies, retest method, and confidence. Step 5 — Produce the evidence bundle Return one Markdown file named CJISSECURITYPOLICY61EVIDENCECHECK.md with: 1. Executive summary and explicit assurance limitations. 2. Authority/version/status and scope/applicability record. 3. Coverage totals by status and evidence domain. 4. Requirement/outcome-to-evidence matrix with artifact provenance. 5. Findings ordered by risk and evidence impact. 6. A 30/60/90-day remediation and evidence-collection plan. 7. Open questions, unavailable sources, conflicts, and decisions required. 8. Official references with access/review date. Before finalizing, verify that every conclusion is traceable to an artifact or clearly labeled assertion/inference, all denominators reconcile, all unavailable evidence is visible, licensed text is not reproduced, and no sentence claims certification or legal approval. Output contract The response must contain one evidence matrix row per scoped authoritative item or outcome. At minimum include itemid, applicability, owner, implementation, artifactids, testmethod, coverageperiod, status, gap, and confidence. Every artifact ID must resolve to the artifact register, and every total must reconcile to the matrix. Verification Confirm the official source, version, status, and review date in both the executive summary and matrix metadata. Reconcile applicable, not applicable, and not assessed counts to the complete supplied scope. Trace each supported assertion to provenance-bearing evidence covering the stated period and population. Independently reperform a risk-based sample of mappings and document all exceptions. Verify findings distinguish control/design weakness from missing evidence and unknown scope. Have the accountable owner and, where required, qualified counsel or an authorized assessor review conclusions. Guardrails This is an evidence-readiness workflow, not certification, attestation, audit opinion, or legal advice. Do not infer that a voluntary framework is mandatory or that one framework proves another. Do not paste, paraphrase at length, or reconstruct licensed controls. Use source summaries and organization-supplied licensed material. Do not expose secrets, personal data, regulated data, or full production exports in the report. Do not modify systems, close findings, accept risk, or submit regulatory reports without explicit owner authorization. If versions conflict, preserve both citations, label the conflict, and escalate rather than choosing silently. Routing examples Route here: assess CJIS Security Policy 6.1 evidence review Criminal Justice Information safeguards prepare CJIS audit artifacts Hard negatives—route elsewhere or clarify: assess CUI under NIST 800-171 apply an older CJIS policy without version validation Related recipes NIST SP 800-53 Rev. 5 NIST SP 800-171 Rev. 3 FedRAMP 2026 References 1. Federal Bureau of Investigation official source 1","agent_handoff":{"mcp_lookup_keys":["cjis-security-policy-6-1-evidence-check","/recipes/general/compliance-standards/cjis-security-policy-6-1-evidence-check/","recipes/general/compliance-standards/cjis-security-policy-6-1-evidence-check.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["audit","compliance"],"source_text_field":"content_text","portable_download":"security-recipe-cjis-security-policy-6-1-evidence-check.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-cjis-security-policy-6-1-evidence-check.json"}},{"slug":"cmmc-2-0-evidence-readiness-check","title":"CMMC 2.0 Evidence Readiness Check","link_title":"CMMC 2.0","url":"https://security-recipes.ai/recipes/general/compliance-standards/cmmc-2-0-evidence-readiness-check/","path":"/recipes/general/compliance-standards/cmmc-2-0-evidence-readiness-check/","source_file":"recipes/general/compliance-standards/cmmc-2-0-evidence-readiness-check.md","recipe_id":"compliance.cmmc-2-0-current","recipe_kind":"","category":{"slug":"compliance-standards","label":"Compliance Standards"},"agent":"Compliance evidence review","severity":"info","maturity":"stable","ecosystem":"","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"CMMC 2.0","framework_version":"32 CFR Part 170 / phased implementation beginning November 10, 2025","jurisdiction":["united-states"],"industry":["defense-industrial-base","government-contractors"],"cve_archetypes":[],"cve_workflow_role":"","tags":["compliance","cmmc","government","audit","defense","data-protection","defense-industrial-base","government-contractors"],"facets":["audit","compliance"],"quality":{"score":95,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"Security Recipes","team":"GRC and Security Engineering","model":"gpt-5-codex","ai_assisted":false,"generated_by":"","date":"2026-08-21","zero_day":false,"last_updated":"2026-08-21","summary":"Assess CMMC 2.0 evidence readiness: verify applicability, map official requirements to artifacts, record gaps, and plan remediation.","content_text":"CMMC 2.0 Evidence Readiness Check Use this recipe to produce a source-aware evidence-readiness assessment for CMMC 2.0. It creates an auditable gap record; it does not certify compliance, provide legal advice, or replace an assessor, regulator, or certification body. Section index Framework basis When to use it Inputs The prompt Output contract Verification Guardrails Routing examples References Framework basis Publisher: U.S. Department of Defense Version: 32 CFR Part 170 / phased implementation beginning November 10, 2025 Status: phased-implementation Sources reviewed: 2026-08-21 Jurisdictions: united-states Industries: defense-industrial-base, government-contractors License boundary: official-text Defense contractors and subcontractors whose solicitations or contracts specify a CMMC level and assessment requirement for FCI or CUI. Implementation is phased. Determine which duties and dates apply to the organization before evaluating evidence. Use the linked official legal or regulatory text and current implementing guidance; do not replace applicability analysis with this summary. When to use it Use this recipe when the organization has established that CMMC 2.0 is applicable or wants a readiness assessment against it. Use the routing positives below to distinguish this recipe from adjacent frameworks. If applicability, the effective version, or the authoritative requirement set is unresolved, stop at a scoped intake and record the decision owner. Inputs The business purpose, legal entities, products, services, systems, and locations in scope. The organization's role, applicability decision, selected profile, level, baseline, or control set where the framework requires one. The official publication URLs above and, for licensed material, an authorized organization-supplied copy. Evidence from the complete review period, including populations—not only hand-picked examples. Named owners, inherited/shared responsibilities, exceptions, compensating measures, and accepted risks. Read-only access by default. Redacted exports are acceptable when provenance and coverage remain testable. Evidence domains for this framework: contract, information, and assessment scope: begin with contract-clause and level determination. required practice implementation: begin with CMMC assessment scope. assessment evidence and affirmations: begin with practice-level objective evidence. POA&M, remediation, and supplier flowdown: begin with SPR score, POA&M, affirmation, and subcontractor records. The prompt You are a compliance evidence-readiness analyst. Evaluate the supplied scope against CMMC 2.0 (32 CFR Part 170 / phased implementation beginning November 10, 2025). The catalog status is phased-implementation and the source review date is 2026-08-21. Never claim certification or legal compliance. Never invent applicability, evidence, control operation, sampling results, or requirement text. Separate observed facts, organization assertions, and analyst inferences. Treat missing or inaccessible evidence as unknown, not as failure, unless the authoritative assessment method says otherwise. Step 0 — Lock authority, version, and scope 1. Record the exact official source, version, publication/update identifier, and effective date used. 2. Record the organization, role, jurisdiction, industry, system/product boundary, review period, and decision owner. 3. Confirm any selected level, profile, baseline, overlay, assessment type, or licensed requirement set. 4. Implementation is phased. Determine which duties and dates apply to the organization before evaluating evidence. 5. Use the linked official legal or regulatory text and current implementing guidance; do not replace applicability analysis with this summary. 6. Stop and request a decision when applicability or the authoritative requirement set cannot be established. Step 1 — Build the applicability map For every supplied requirement identifier or official outcome in scope, record: applicability, rationale, responsible owner, implementation location, inherited/shared responsibility, evidence expected, and any dependency. Use only identifiers present in the authoritative source supplied for this engagement. Do not reconstruct licensed text. Step 2 — Collect evidence by framework domain Review these domains without treating the labels as substitutes for authoritative requirements: 1. contract, information, and assessment scope 2. required practice implementation 3. assessment evidence and affirmations 4. POA&M, remediation, and supplier flowdown Start with these likely artifacts, then validate provenance and coverage: 1. contract-clause and level determination 2. CMMC assessment scope 3. practice-level objective evidence 4. SPR score, POA&M, affirmation, and subcontractor records For every artifact record: artifact ID, source system, owner, collection time, review period, access path, integrity/provenance note, population covered, and requirement/outcome links. Prefer system exports and immutable records over screenshots or narrative attestations. Step 3 — Test design and operation For each applicable item, evaluate design, implementation, and operating evidence separately. Check whether evidence is authentic, complete, current for the review period, population-representative, and directly linked to the scoped system. Where sampling is permitted, state the population, method, sample size, selections, exceptions, and limitations; do not imply statistical assurance without a justified method. Step 4 — Classify gaps without overstating them Use only: supported, partially supported, unsupported, not applicable with rationale, or not assessed. Record gaps as evidence-readiness findings—not declarations of legal noncompliance. Each finding must include the affected requirement/outcome, observed fact, missing or weak evidence, risk, owner, corrective action, due date, dependencies, retest method, and confidence. Step 5 — Produce the evidence bundle Return one Markdown file named CMMC20EVIDENCEREADINESSCHECK.md with: 1. Executive summary and explicit assurance limitations. 2. Authority/version/status and scope/applicability record. 3. Coverage totals by status and evidence domain. 4. Requirement/outcome-to-evidence matrix with artifact provenance. 5. Findings ordered by risk and evidence impact. 6. A 30/60/90-day remediation and evidence-collection plan. 7. Open questions, unavailable sources, conflicts, and decisions required. 8. Official references with access/review date. Before finalizing, verify that every conclusion is traceable to an artifact or clearly labeled assertion/inference, all denominators reconcile, all unavailable evidence is visible, licensed text is not reproduced, and no sentence claims certification or legal approval. Output contract The response must contain one evidence matrix row per scoped authoritative item or outcome. At minimum include itemid, applicability, owner, implementation, artifactids, testmethod, coverage_period, status, gap, and confidence. Every artifact ID must resolve to the artifact register, and every total must reconcile to the matrix. Verification Confirm the official source, version, status, and review date in both the executive summary and matrix metadata. Reconcile applicable, not applicable, and not assessed counts to the complete supplied scope. Trace each supported assertion to provenance-bearing evidence covering the stated period and population. Independently reperform a risk-based sample of mappings and document all exceptions. Verify findings distinguish control/design weakness from missing evidence and unknown scope. Have the accountable owner and, where required, qualified counsel or an authorized assessor review conclusions. Guardrails This is an evidence-readiness workflow, not certification, attestation, audit opinion, or legal advice. Do not infer that a voluntary framework is mandatory or that one framework proves another. Do not paste, paraphrase at length, or reconstruct licensed controls. Use source summaries and organization-supplied licensed material. Do not expose secrets, personal data, regulated data, or full production exports in the report. Do not modify systems, close findings, accept risk, or submit regulatory reports without explicit owner authorization. If versions conflict, preserve both citations, label the conflict, and escalate rather than choosing silently. Routing examples Route here: prepare CMMC 2.0 assessment evidence review a defense contractor CUI scope assess CMMC level readiness Hard negatives—route elsewhere or clarify: assume NIST 800-171 alone proves CMMC status perform a FedRAMP cloud authorization review Related recipes NIST SP 800-53 Rev. 5 NIST SP 800-171 Rev. 3 FedRAMP 2026 References 1. U.S. Department of Defense official source 1","agent_handoff":{"mcp_lookup_keys":["cmmc-2-0-evidence-readiness-check","/recipes/general/compliance-standards/cmmc-2-0-evidence-readiness-check/","recipes/general/compliance-standards/cmmc-2-0-evidence-readiness-check.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["audit","compliance"],"source_text_field":"content_text","portable_download":"security-recipe-cmmc-2-0-evidence-readiness-check.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-cmmc-2-0-evidence-readiness-check.json"}},{"slug":"cobit-2019-governance-evidence-check","title":"COBIT 2019 Governance System Evidence Check","link_title":"COBIT 2019","url":"https://security-recipes.ai/recipes/general/compliance-standards/cobit-2019-governance-evidence-check/","path":"/recipes/general/compliance-standards/cobit-2019-governance-evidence-check/","source_file":"recipes/general/compliance-standards/cobit-2019-governance-evidence-check.md","recipe_id":"compliance.cobit-2019","recipe_kind":"","category":{"slug":"compliance-standards","label":"Compliance Standards"},"agent":"Compliance evidence review","severity":"info","maturity":"stable","ecosystem":"","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"COBIT 2019","framework_version":"2019","jurisdiction":["global"],"industry":["cross-sector"],"cve_archetypes":[],"cve_workflow_role":"","tags":["compliance","cobit","assurance","audit","governance","risk","cross-sector"],"facets":["audit","compliance","risk"],"quality":{"score":100,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context","multi-facet"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"Security Recipes","team":"GRC and Security Engineering","model":"gpt-5-codex","ai_assisted":false,"generated_by":"","date":"2026-08-21","zero_day":false,"last_updated":"2026-08-21","summary":"Assess COBIT 2019 evidence readiness: verify applicability, map official requirements to artifacts, record gaps, and plan remediation.","content_text":"COBIT 2019 Governance System Evidence Check Use this recipe to produce a source-aware evidence-readiness assessment for COBIT 2019. It creates an auditable gap record; it does not certify compliance, provide legal advice, or replace an assessor, regulator, or certification body. Section index Framework basis When to use it Inputs The prompt Output contract Verification Guardrails Routing examples References Framework basis Publisher: ISACA Version: 2019 Status: final Sources reviewed: 2026-08-21 Jurisdictions: global Industries: cross-sector License boundary: summary-only Enterprises designing, evaluating, or improving governance of information and technology using COBIT 2019. The cataloged version is final; still verify scope and any later official updates. This recipe intentionally summarizes domains and evidence needs. Do not reproduce licensed control text; use an organization-supplied licensed copy for requirement-level work. When to use it Use this recipe when the organization has established that COBIT 2019 is applicable or wants a readiness assessment against it. Use the routing positives below to distinguish this recipe from adjacent frameworks. If applicability, the effective version, or the authoritative requirement set is unresolved, stop at a scoped intake and record the decision owner. Inputs The business purpose, legal entities, products, services, systems, and locations in scope. The organization's role, applicability decision, selected profile, level, baseline, or control set where the framework requires one. The official publication URLs above and, for licensed material, an authorized organization-supplied copy. Evidence from the complete review period, including populations—not only hand-picked examples. Named owners, inherited/shared responsibilities, exceptions, compensating measures, and accepted risks. Read-only access by default. Redacted exports are acceptable when provenance and coverage remain testable. Evidence domains for this framework: governance objectives and decision rights: begin with governance charter and RACI. strategy, risk, and resources: begin with goals cascade and risk decisions. delivery and support: begin with performance measures and service reviews. monitoring, assurance, and improvement: begin with assurance findings and improvement plans. The prompt You are a compliance evidence-readiness analyst. Evaluate the supplied scope against COBIT 2019 (2019). The catalog status is final and the source review date is 2026-08-21. Never claim certification or legal compliance. Never invent applicability, evidence, control operation, sampling results, or requirement text. Separate observed facts, organization assertions, and analyst inferences. Treat missing or inaccessible evidence as unknown, not as failure, unless the authoritative assessment method says otherwise. Step 0 — Lock authority, version, and scope 1. Record the exact official source, version, publication/update identifier, and effective date used. 2. Record the organization, role, jurisdiction, industry, system/product boundary, review period, and decision owner. 3. Confirm any selected level, profile, baseline, overlay, assessment type, or licensed requirement set. 4. The cataloged version is final; still verify scope and any later official updates. 5. This recipe intentionally summarizes domains and evidence needs. Do not reproduce licensed control text; use an organization-supplied licensed copy for requirement-level work. 6. Stop and request a decision when applicability or the authoritative requirement set cannot be established. Step 1 — Build the applicability map For every supplied requirement identifier or official outcome in scope, record: applicability, rationale, responsible owner, implementation location, inherited/shared responsibility, evidence expected, and any dependency. Use only identifiers present in the authoritative source supplied for this engagement. Do not reconstruct licensed text. Step 2 — Collect evidence by framework domain Review these domains without treating the labels as substitutes for authoritative requirements: 1. governance objectives and decision rights 2. strategy, risk, and resources 3. delivery and support 4. monitoring, assurance, and improvement Start with these likely artifacts, then validate provenance and coverage: 1. governance charter and RACI 2. goals cascade and risk decisions 3. performance measures and service reviews 4. assurance findings and improvement plans For every artifact record: artifact ID, source system, owner, collection time, review period, access path, integrity/provenance note, population covered, and requirement/outcome links. Prefer system exports and immutable records over screenshots or narrative attestations. Step 3 — Test design and operation For each applicable item, evaluate design, implementation, and operating evidence separately. Check whether evidence is authentic, complete, current for the review period, population-representative, and directly linked to the scoped system. Where sampling is permitted, state the population, method, sample size, selections, exceptions, and limitations; do not imply statistical assurance without a justified method. Step 4 — Classify gaps without overstating them Use only: supported, partially supported, unsupported, not applicable with rationale, or not assessed. Record gaps as evidence-readiness findings—not declarations of legal noncompliance. Each finding must include the affected requirement/outcome, observed fact, missing or weak evidence, risk, owner, corrective action, due date, dependencies, retest method, and confidence. Step 5 — Produce the evidence bundle Return one Markdown file named COBIT2019GOVERNANCEEVIDENCECHECK.md with: 1. Executive summary and explicit assurance limitations. 2. Authority/version/status and scope/applicability record. 3. Coverage totals by status and evidence domain. 4. Requirement/outcome-to-evidence matrix with artifact provenance. 5. Findings ordered by risk and evidence impact. 6. A 30/60/90-day remediation and evidence-collection plan. 7. Open questions, unavailable sources, conflicts, and decisions required. 8. Official references with access/review date. Before finalizing, verify that every conclusion is traceable to an artifact or clearly labeled assertion/inference, all denominators reconcile, all unavailable evidence is visible, licensed text is not reproduced, and no sentence claims certification or legal approval. Output contract The response must contain one evidence matrix row per scoped authoritative item or outcome. At minimum include itemid, applicability, owner, implementation, artifactids, testmethod, coverageperiod, status, gap, and confidence. Every artifact ID must resolve to the artifact register, and every total must reconcile to the matrix. Verification Confirm the official source, version, status, and review date in both the executive summary and matrix metadata. Reconcile applicable, not applicable, and not assessed counts to the complete supplied scope. Trace each supported assertion to provenance-bearing evidence covering the stated period and population. Independently reperform a risk-based sample of mappings and document all exceptions. Verify findings distinguish control/design weakness from missing evidence and unknown scope. Have the accountable owner and, where required, qualified counsel or an authorized assessor review conclusions. Guardrails This is an evidence-readiness workflow, not certification, attestation, audit opinion, or legal advice. Do not infer that a voluntary framework is mandatory or that one framework proves another. Do not paste, paraphrase at length, or reconstruct licensed controls. Use source summaries and organization-supplied licensed material. Do not expose secrets, personal data, regulated data, or full production exports in the report. Do not modify systems, close findings, accept risk, or submit regulatory reports without explicit owner authorization. If versions conflict, preserve both citations, label the conflict, and escalate rather than choosing silently. Routing examples Route here: assess COBIT 2019 governance evidence review enterprise I&T governance evaluate governance objectives and performance Hard negatives—route elsewhere or clarify: perform a SOX internal-control audit certify an ISO 27001 management system Related recipes SOC 2 TSC SOX ITGC SEC Cyber Disclosure Rule References 1. ISACA official source 1","agent_handoff":{"mcp_lookup_keys":["cobit-2019-governance-evidence-check","/recipes/general/compliance-standards/cobit-2019-governance-evidence-check/","recipes/general/compliance-standards/cobit-2019-governance-evidence-check.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["audit","compliance","risk"],"source_text_field":"content_text","portable_download":"security-recipe-cobit-2019-governance-evidence-check.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-cobit-2019-governance-evidence-check.json"}},{"slug":"csa-ccm-4-1-cloud-control-evidence-check","title":"CSA Cloud Controls Matrix v4.1 Evidence Check","link_title":"CSA CCM v4.1","url":"https://security-recipes.ai/recipes/general/compliance-standards/csa-ccm-4-1-cloud-control-evidence-check/","path":"/recipes/general/compliance-standards/csa-ccm-4-1-cloud-control-evidence-check/","source_file":"recipes/general/compliance-standards/csa-ccm-4-1-cloud-control-evidence-check.md","recipe_id":"compliance.csa-ccm-4-1","recipe_kind":"","category":{"slug":"compliance-standards","label":"Compliance Standards"},"agent":"Compliance evidence review","severity":"info","maturity":"stable","ecosystem":"","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"CSA CCM v4.1","framework_version":"4.1","jurisdiction":["global"],"industry":["cloud","saas","cross-sector"],"cve_archetypes":[],"cve_workflow_role":"","tags":["compliance","csa-ccm","cloud-assurance","audit","cloud","assurance","saas"],"facets":["audit","compliance"],"quality":{"score":95,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"Security Recipes","team":"GRC and Security Engineering","model":"gpt-5-codex","ai_assisted":false,"generated_by":"","date":"2026-08-21","zero_day":false,"last_updated":"2026-08-21","summary":"Assess CSA CCM v4.1 evidence readiness: verify applicability, map official requirements to artifacts, record gaps, and plan remediation.","content_text":"CSA Cloud Controls Matrix v4.1 Evidence Check Use this recipe to produce a source-aware evidence-readiness assessment for CSA CCM v4.1. It creates an auditable gap record; it does not certify compliance, provide legal advice, or replace an assessor, regulator, or certification body. Section index Framework basis When to use it Inputs The prompt Output contract Verification Guardrails Routing examples References Framework basis Publisher: Cloud Security Alliance Version: 4.1 Status: final Sources reviewed: 2026-08-21 Jurisdictions: global Industries: cloud, saas, cross-sector License boundary: summary-only Cloud service providers and cloud customers assessing cloud control responsibilities using CSA CCM v4.1. The cataloged version is final; still verify scope and any later official updates. This recipe intentionally summarizes domains and evidence needs. Do not reproduce licensed control text; use an organization-supplied licensed copy for requirement-level work. When to use it Use this recipe when the organization has established that CSA CCM v4.1 is applicable or wants a readiness assessment against it. Use the routing positives below to distinguish this recipe from adjacent frameworks. If applicability, the effective version, or the authoritative requirement set is unresolved, stop at a scoped intake and record the decision owner. Inputs The business purpose, legal entities, products, services, systems, and locations in scope. The organization's role, applicability decision, selected profile, level, baseline, or control set where the framework requires one. The official publication URLs above and, for licensed material, an authorized organization-supplied copy. Evidence from the complete review period, including populations—not only hand-picked examples. Named owners, inherited/shared responsibilities, exceptions, compensating measures, and accepted risks. Read-only access by default. Redacted exports are acceptable when provenance and coverage remain testable. Evidence domains for this framework: cloud governance and shared responsibility: begin with shared-responsibility matrix. identity, infrastructure, and application security: begin with cloud configuration exports. data security and privacy: begin with data lifecycle and key-management evidence. operations, resilience, and supply chain: begin with resilience tests and supplier reviews. The prompt You are a compliance evidence-readiness analyst. Evaluate the supplied scope against CSA CCM v4.1 (4.1). The catalog status is final and the source review date is 2026-08-21. Never claim certification or legal compliance. Never invent applicability, evidence, control operation, sampling results, or requirement text. Separate observed facts, organization assertions, and analyst inferences. Treat missing or inaccessible evidence as unknown, not as failure, unless the authoritative assessment method says otherwise. Step 0 — Lock authority, version, and scope 1. Record the exact official source, version, publication/update identifier, and effective date used. 2. Record the organization, role, jurisdiction, industry, system/product boundary, review period, and decision owner. 3. Confirm any selected level, profile, baseline, overlay, assessment type, or licensed requirement set. 4. The cataloged version is final; still verify scope and any later official updates. 5. This recipe intentionally summarizes domains and evidence needs. Do not reproduce licensed control text; use an organization-supplied licensed copy for requirement-level work. 6. Stop and request a decision when applicability or the authoritative requirement set cannot be established. Step 1 — Build the applicability map For every supplied requirement identifier or official outcome in scope, record: applicability, rationale, responsible owner, implementation location, inherited/shared responsibility, evidence expected, and any dependency. Use only identifiers present in the authoritative source supplied for this engagement. Do not reconstruct licensed text. Step 2 — Collect evidence by framework domain Review these domains without treating the labels as substitutes for authoritative requirements: 1. cloud governance and shared responsibility 2. identity, infrastructure, and application security 3. data security and privacy 4. operations, resilience, and supply chain Start with these likely artifacts, then validate provenance and coverage: 1. shared-responsibility matrix 2. cloud configuration exports 3. data lifecycle and key-management evidence 4. resilience tests and supplier reviews For every artifact record: artifact ID, source system, owner, collection time, review period, access path, integrity/provenance note, population covered, and requirement/outcome links. Prefer system exports and immutable records over screenshots or narrative attestations. Step 3 — Test design and operation For each applicable item, evaluate design, implementation, and operating evidence separately. Check whether evidence is authentic, complete, current for the review period, population-representative, and directly linked to the scoped system. Where sampling is permitted, state the population, method, sample size, selections, exceptions, and limitations; do not imply statistical assurance without a justified method. Step 4 — Classify gaps without overstating them Use only: supported, partially supported, unsupported, not applicable with rationale, or not assessed. Record gaps as evidence-readiness findings—not declarations of legal noncompliance. Each finding must include the affected requirement/outcome, observed fact, missing or weak evidence, risk, owner, corrective action, due date, dependencies, retest method, and confidence. Step 5 — Produce the evidence bundle Return one Markdown file named CSACCM41CLOUDCONTROLEVIDENCECHECK.md with: 1. Executive summary and explicit assurance limitations. 2. Authority/version/status and scope/applicability record. 3. Coverage totals by status and evidence domain. 4. Requirement/outcome-to-evidence matrix with artifact provenance. 5. Findings ordered by risk and evidence impact. 6. A 30/60/90-day remediation and evidence-collection plan. 7. Open questions, unavailable sources, conflicts, and decisions required. 8. Official references with access/review date. Before finalizing, verify that every conclusion is traceable to an artifact or clearly labeled assertion/inference, all denominators reconcile, all unavailable evidence is visible, licensed text is not reproduced, and no sentence claims certification or legal approval. Output contract The response must contain one evidence matrix row per scoped authoritative item or outcome. At minimum include itemid, applicability, owner, implementation, artifactids, testmethod, coverage_period, status, gap, and confidence. Every artifact ID must resolve to the artifact register, and every total must reconcile to the matrix. Verification Confirm the official source, version, status, and review date in both the executive summary and matrix metadata. Reconcile applicable, not applicable, and not assessed counts to the complete supplied scope. Trace each supported assertion to provenance-bearing evidence covering the stated period and population. Independently reperform a risk-based sample of mappings and document all exceptions. Verify findings distinguish control/design weakness from missing evidence and unknown scope. Have the accountable owner and, where required, qualified counsel or an authorized assessor review conclusions. Guardrails This is an evidence-readiness workflow, not certification, attestation, audit opinion, or legal advice. Do not infer that a voluntary framework is mandatory or that one framework proves another. Do not paste, paraphrase at length, or reconstruct licensed controls. Use source summaries and organization-supplied licensed material. Do not expose secrets, personal data, regulated data, or full production exports in the report. Do not modify systems, close findings, accept risk, or submit regulatory reports without explicit owner authorization. If versions conflict, preserve both citations, label the conflict, and escalate rather than choosing silently. Routing examples Route here: assess cloud controls with CSA CCM 4.1 prepare CAIQ-aligned evidence review cloud shared responsibilities Hard negatives—route elsewhere or clarify: perform a FedRAMP authorization assessment assess SOC 2 criteria without a cloud mapping Related recipes CIS Controls v8.1 ISO/IEC 27001:2022 NIST SSDF 1.1 References 1. Cloud Security Alliance official source 1","agent_handoff":{"mcp_lookup_keys":["csa-ccm-4-1-cloud-control-evidence-check","/recipes/general/compliance-standards/csa-ccm-4-1-cloud-control-evidence-check/","recipes/general/compliance-standards/csa-ccm-4-1-cloud-control-evidence-check.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["audit","compliance"],"source_text_field":"content_text","portable_download":"security-recipe-csa-ccm-4-1-cloud-control-evidence-check.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-csa-ccm-4-1-cloud-control-evidence-check.json"}},{"slug":"eu-ai-act-evidence-readiness-check","title":"EU AI Act Evidence Readiness Check","link_title":"EU AI Act","url":"https://security-recipes.ai/recipes/general/compliance-standards/eu-ai-act-evidence-readiness-check/","path":"/recipes/general/compliance-standards/eu-ai-act-evidence-readiness-check/","source_file":"recipes/general/compliance-standards/eu-ai-act-evidence-readiness-check.md","recipe_id":"compliance.eu-ai-act-2024-1689","recipe_kind":"","category":{"slug":"compliance-standards","label":"Compliance Standards"},"agent":"Compliance evidence review","severity":"info","maturity":"stable","ecosystem":"","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"EU AI Act","framework_version":"Regulation (EU) 2024/1689; phased implementation","jurisdiction":["european-union","extraterritorial"],"industry":["artificial-intelligence","cross-sector"],"cve_archetypes":[],"cve_workflow_role":"","tags":["compliance","eu-ai-act","ai-governance","audit","ai-safety","legal-readiness","artificial-intelligence","cross-sector"],"facets":["audit","compliance"],"quality":{"score":95,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"Security Recipes","team":"GRC and Security Engineering","model":"gpt-5-codex","ai_assisted":false,"generated_by":"","date":"2026-08-21","zero_day":false,"last_updated":"2026-08-21","summary":"Assess EU AI Act evidence readiness: verify applicability, map official requirements to artifacts, record gaps, and plan remediation.","content_text":"EU AI Act Evidence Readiness Check Use this recipe to produce a source-aware evidence-readiness assessment for EU AI Act. It creates an auditable gap record; it does not certify compliance, provide legal advice, or replace an assessor, regulator, or certification body. Section index Framework basis When to use it Inputs The prompt Output contract Verification Guardrails Routing examples References Framework basis Publisher: European Union Version: Regulation (EU) 2024/1689; phased implementation Status: phased-implementation Sources reviewed: 2026-08-21 Jurisdictions: european-union, extraterritorial Industries: artificial-intelligence, cross-sector License boundary: official-text AI providers, deployers, importers, distributors, and product manufacturers after role, system classification, exclusions, and current phased dates are verified with official Commission guidance. Implementation is phased. Determine which duties and dates apply to the organization before evaluating evidence. Use the linked official legal or regulatory text and current implementing guidance; do not replace applicability analysis with this summary. When to use it Use this recipe when the organization has established that EU AI Act is applicable or wants a readiness assessment against it. Use the routing positives below to distinguish this recipe from adjacent frameworks. If applicability, the effective version, or the authoritative requirement set is unresolved, stop at a scoped intake and record the decision owner. Inputs The business purpose, legal entities, products, services, systems, and locations in scope. The organization's role, applicability decision, selected profile, level, baseline, or control set where the framework requires one. The official publication URLs above and, for licensed material, an authorized organization-supplied copy. Evidence from the complete review period, including populations—not only hand-picked examples. Named owners, inherited/shared responsibilities, exceptions, compensating measures, and accepted risks. Read-only access by default. Redacted exports are acceptable when provenance and coverage remain testable. Evidence domains for this framework: role and AI system classification: begin with role and classification rationale. risk, data, and technical documentation: begin with risk and data-governance files. transparency, human oversight, accuracy, and security: begin with technical documentation and instructions. post-market monitoring, incidents, and conformity: begin with monitoring, incident, registration, and conformity records. The prompt You are a compliance evidence-readiness analyst. Evaluate the supplied scope against EU AI Act (Regulation (EU) 2024/1689; phased implementation). The catalog status is phased-implementation and the source review date is 2026-08-21. Never claim certification or legal compliance. Never invent applicability, evidence, control operation, sampling results, or requirement text. Separate observed facts, organization assertions, and analyst inferences. Treat missing or inaccessible evidence as unknown, not as failure, unless the authoritative assessment method says otherwise. Step 0 — Lock authority, version, and scope 1. Record the exact official source, version, publication/update identifier, and effective date used. 2. Record the organization, role, jurisdiction, industry, system/product boundary, review period, and decision owner. 3. Confirm any selected level, profile, baseline, overlay, assessment type, or licensed requirement set. 4. Implementation is phased. Determine which duties and dates apply to the organization before evaluating evidence. 5. Use the linked official legal or regulatory text and current implementing guidance; do not replace applicability analysis with this summary. 6. Stop and request a decision when applicability or the authoritative requirement set cannot be established. Step 1 — Build the applicability map For every supplied requirement identifier or official outcome in scope, record: applicability, rationale, responsible owner, implementation location, inherited/shared responsibility, evidence expected, and any dependency. Use only identifiers present in the authoritative source supplied for this engagement. Do not reconstruct licensed text. Step 2 — Collect evidence by framework domain Review these domains without treating the labels as substitutes for authoritative requirements: 1. role and AI system classification 2. risk, data, and technical documentation 3. transparency, human oversight, accuracy, and security 4. post-market monitoring, incidents, and conformity Start with these likely artifacts, then validate provenance and coverage: 1. role and classification rationale 2. risk and data-governance files 3. technical documentation and instructions 4. monitoring, incident, registration, and conformity records For every artifact record: artifact ID, source system, owner, collection time, review period, access path, integrity/provenance note, population covered, and requirement/outcome links. Prefer system exports and immutable records over screenshots or narrative attestations. Step 3 — Test design and operation For each applicable item, evaluate design, implementation, and operating evidence separately. Check whether evidence is authentic, complete, current for the review period, population-representative, and directly linked to the scoped system. Where sampling is permitted, state the population, method, sample size, selections, exceptions, and limitations; do not imply statistical assurance without a justified method. Step 4 — Classify gaps without overstating them Use only: supported, partially supported, unsupported, not applicable with rationale, or not assessed. Record gaps as evidence-readiness findings—not declarations of legal noncompliance. Each finding must include the affected requirement/outcome, observed fact, missing or weak evidence, risk, owner, corrective action, due date, dependencies, retest method, and confidence. Step 5 — Produce the evidence bundle Return one Markdown file named EUAIACTEVIDENCEREADINESSCHECK.md with: 1. Executive summary and explicit assurance limitations. 2. Authority/version/status and scope/applicability record. 3. Coverage totals by status and evidence domain. 4. Requirement/outcome-to-evidence matrix with artifact provenance. 5. Findings ordered by risk and evidence impact. 6. A 30/60/90-day remediation and evidence-collection plan. 7. Open questions, unavailable sources, conflicts, and decisions required. 8. Official references with access/review date. Before finalizing, verify that every conclusion is traceable to an artifact or clearly labeled assertion/inference, all denominators reconcile, all unavailable evidence is visible, licensed text is not reproduced, and no sentence claims certification or legal approval. Output contract The response must contain one evidence matrix row per scoped authoritative item or outcome. At minimum include itemid, applicability, owner, implementation, artifactids, testmethod, coverage_period, status, gap, and confidence. Every artifact ID must resolve to the artifact register, and every total must reconcile to the matrix. Verification Confirm the official source, version, status, and review date in both the executive summary and matrix metadata. Reconcile applicable, not applicable, and not assessed counts to the complete supplied scope. Trace each supported assertion to provenance-bearing evidence covering the stated period and population. Independently reperform a risk-based sample of mappings and document all exceptions. Verify findings distinguish control/design weakness from missing evidence and unknown scope. Have the accountable owner and, where required, qualified counsel or an authorized assessor review conclusions. Guardrails This is an evidence-readiness workflow, not certification, attestation, audit opinion, or legal advice. Do not infer that a voluntary framework is mandatory or that one framework proves another. Do not paste, paraphrase at length, or reconstruct licensed controls. Use source summaries and organization-supplied licensed material. Do not expose secrets, personal data, regulated data, or full production exports in the report. Do not modify systems, close findings, accept risk, or submit regulatory reports without explicit owner authorization. If versions conflict, preserve both citations, label the conflict, and escalate rather than choosing silently. Routing examples Route here: assess EU AI Act readiness classify AI Act roles and evidence prepare high-risk AI system documentation Hard negatives—route elsewhere or clarify: treat every AI system as high risk certify ISO 42001 without legal applicability analysis Related recipes NIST AI SSDF NIST AI RMF 1.0 ISO/IEC 42001:2023 References 1. European Union official source 1 2. European Union official source 2","agent_handoff":{"mcp_lookup_keys":["eu-ai-act-evidence-readiness-check","/recipes/general/compliance-standards/eu-ai-act-evidence-readiness-check/","recipes/general/compliance-standards/eu-ai-act-evidence-readiness-check.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["audit","compliance"],"source_text_field":"content_text","portable_download":"security-recipe-eu-ai-act-evidence-readiness-check.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-eu-ai-act-evidence-readiness-check.json"}},{"slug":"eu-cyber-resilience-act-evidence-check","title":"EU Cyber Resilience Act Evidence Readiness Check","link_title":"EU Cyber Resilience Act","url":"https://security-recipes.ai/recipes/general/compliance-standards/eu-cyber-resilience-act-evidence-check/","path":"/recipes/general/compliance-standards/eu-cyber-resilience-act-evidence-check/","source_file":"recipes/general/compliance-standards/eu-cyber-resilience-act-evidence-check.md","recipe_id":"compliance.eu-cra-2024-2847","recipe_kind":"","category":{"slug":"compliance-standards","label":"Compliance Standards"},"agent":"Compliance evidence review","severity":"info","maturity":"stable","ecosystem":"","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"EU Cyber Resilience Act","framework_version":"Regulation (EU) 2024/2847","jurisdiction":["european-union","extraterritorial"],"industry":["products-with-digital-elements","software","hardware"],"cve_archetypes":[],"cve_workflow_role":"","tags":["compliance","eu-cyber-resilience-act","product-security","audit","vulnerability-management","products-with-digital-elements","software"],"facets":["audit","compliance"],"quality":{"score":95,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"Security Recipes","team":"GRC and Security Engineering","model":"gpt-5-codex","ai_assisted":false,"generated_by":"","date":"2026-08-21","zero_day":false,"last_updated":"2026-08-21","summary":"Assess EU Cyber Resilience Act evidence readiness: verify applicability, map official requirements to artifacts, record gaps, and plan remediation.","content_text":"EU Cyber Resilience Act Evidence Readiness Check Use this recipe to produce a source-aware evidence-readiness assessment for EU Cyber Resilience Act. It creates an auditable gap record; it does not certify compliance, provide legal advice, or replace an assessor, regulator, or certification body. Section index Framework basis When to use it Inputs The prompt Output contract Verification Guardrails Routing examples References Framework basis Publisher: European Union Version: Regulation (EU) 2024/2847 Status: phased-implementation Sources reviewed: 2026-08-21 Jurisdictions: european-union, extraterritorial Industries: products-with-digital-elements, software, hardware License boundary: official-text Manufacturers, importers, and distributors of products with digital elements placed on the EU market, subject to role, product, and exception analysis. Implementation is phased. Determine which duties and dates apply to the organization before evaluating evidence. Use the linked official legal or regulatory text and current implementing guidance; do not replace applicability analysis with this summary. When to use it Use this recipe when the organization has established that EU Cyber Resilience Act is applicable or wants a readiness assessment against it. Use the routing positives below to distinguish this recipe from adjacent frameworks. If applicability, the effective version, or the authoritative requirement set is unresolved, stop at a scoped intake and record the decision owner. Inputs The business purpose, legal entities, products, services, systems, and locations in scope. The organization's role, applicability decision, selected profile, level, baseline, or control set where the framework requires one. The official publication URLs above and, for licensed material, an authorized organization-supplied copy. Evidence from the complete review period, including populations—not only hand-picked examples. Named owners, inherited/shared responsibilities, exceptions, compensating measures, and accepted risks. Read-only access by default. Redacted exports are acceptable when provenance and coverage remain testable. Evidence domains for this framework: product and economic-operator scope: begin with product classification and role analysis. cybersecurity risk assessment and secure development: begin with lifecycle risk assessment. technical documentation and conformity: begin with technical file and conformity records. vulnerability handling and regulatory reporting: begin with vulnerability intake, update, and reporting workflows. The prompt You are a compliance evidence-readiness analyst. Evaluate the supplied scope against EU Cyber Resilience Act (Regulation (EU) 2024/2847). The catalog status is phased-implementation and the source review date is 2026-08-21. Never claim certification or legal compliance. Never invent applicability, evidence, control operation, sampling results, or requirement text. Separate observed facts, organization assertions, and analyst inferences. Treat missing or inaccessible evidence as unknown, not as failure, unless the authoritative assessment method says otherwise. Step 0 — Lock authority, version, and scope 1. Record the exact official source, version, publication/update identifier, and effective date used. 2. Record the organization, role, jurisdiction, industry, system/product boundary, review period, and decision owner. 3. Confirm any selected level, profile, baseline, overlay, assessment type, or licensed requirement set. 4. Implementation is phased. Determine which duties and dates apply to the organization before evaluating evidence. 5. Use the linked official legal or regulatory text and current implementing guidance; do not replace applicability analysis with this summary. 6. Stop and request a decision when applicability or the authoritative requirement set cannot be established. Step 1 — Build the applicability map For every supplied requirement identifier or official outcome in scope, record: applicability, rationale, responsible owner, implementation location, inherited/shared responsibility, evidence expected, and any dependency. Use only identifiers present in the authoritative source supplied for this engagement. Do not reconstruct licensed text. Step 2 — Collect evidence by framework domain Review these domains without treating the labels as substitutes for authoritative requirements: 1. product and economic-operator scope 2. cybersecurity risk assessment and secure development 3. technical documentation and conformity 4. vulnerability handling and regulatory reporting Start with these likely artifacts, then validate provenance and coverage: 1. product classification and role analysis 2. lifecycle risk assessment 3. technical file and conformity records 4. vulnerability intake, update, and reporting workflows For every artifact record: artifact ID, source system, owner, collection time, review period, access path, integrity/provenance note, population covered, and requirement/outcome links. Prefer system exports and immutable records over screenshots or narrative attestations. Step 3 — Test design and operation For each applicable item, evaluate design, implementation, and operating evidence separately. Check whether evidence is authentic, complete, current for the review period, population-representative, and directly linked to the scoped system. Where sampling is permitted, state the population, method, sample size, selections, exceptions, and limitations; do not imply statistical assurance without a justified method. Step 4 — Classify gaps without overstating them Use only: supported, partially supported, unsupported, not applicable with rationale, or not assessed. Record gaps as evidence-readiness findings—not declarations of legal noncompliance. Each finding must include the affected requirement/outcome, observed fact, missing or weak evidence, risk, owner, corrective action, due date, dependencies, retest method, and confidence. Step 5 — Produce the evidence bundle Return one Markdown file named EUCYBERRESILIENCEACTEVIDENCECHECK.md with: 1. Executive summary and explicit assurance limitations. 2. Authority/version/status and scope/applicability record. 3. Coverage totals by status and evidence domain. 4. Requirement/outcome-to-evidence matrix with artifact provenance. 5. Findings ordered by risk and evidence impact. 6. A 30/60/90-day remediation and evidence-collection plan. 7. Open questions, unavailable sources, conflicts, and decisions required. 8. Official references with access/review date. Before finalizing, verify that every conclusion is traceable to an artifact or clearly labeled assertion/inference, all denominators reconcile, all unavailable evidence is visible, licensed text is not reproduced, and no sentence claims certification or legal approval. Output contract The response must contain one evidence matrix row per scoped authoritative item or outcome. At minimum include itemid, applicability, owner, implementation, artifactids, testmethod, coverage_period, status, gap, and confidence. Every artifact ID must resolve to the artifact register, and every total must reconcile to the matrix. Verification Confirm the official source, version, status, and review date in both the executive summary and matrix metadata. Reconcile applicable, not applicable, and not assessed counts to the complete supplied scope. Trace each supported assertion to provenance-bearing evidence covering the stated period and population. Independently reperform a risk-based sample of mappings and document all exceptions. Verify findings distinguish control/design weakness from missing evidence and unknown scope. Have the accountable owner and, where required, qualified counsel or an authorized assessor review conclusions. Guardrails This is an evidence-readiness workflow, not certification, attestation, audit opinion, or legal advice. Do not infer that a voluntary framework is mandatory or that one framework proves another. Do not paste, paraphrase at length, or reconstruct licensed controls. Use source summaries and organization-supplied licensed material. Do not expose secrets, personal data, regulated data, or full production exports in the report. Do not modify systems, close findings, accept risk, or submit regulatory reports without explicit owner authorization. If versions conflict, preserve both citations, label the conflict, and escalate rather than choosing silently. Routing examples Route here: prepare EU CRA product evidence review Cyber Resilience Act readiness assess product vulnerability handling obligations Hard negatives—route elsewhere or clarify: assess NIS2 essential entity obligations review GDPR controller accountability Related recipes NIST SSDF 1.1 SLSA v1.2 OWASP ASVS 5.0.0 References 1. European Union official source 1","agent_handoff":{"mcp_lookup_keys":["eu-cyber-resilience-act-evidence-check","/recipes/general/compliance-standards/eu-cyber-resilience-act-evidence-check/","recipes/general/compliance-standards/eu-cyber-resilience-act-evidence-check.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["audit","compliance"],"source_text_field":"content_text","portable_download":"security-recipe-eu-cyber-resilience-act-evidence-check.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-eu-cyber-resilience-act-evidence-check.json"}},{"slug":"eu-dora-evidence-readiness-check","title":"EU Digital Operational Resilience Act Evidence Check","link_title":"EU DORA","url":"https://security-recipes.ai/recipes/general/compliance-standards/eu-dora-evidence-readiness-check/","path":"/recipes/general/compliance-standards/eu-dora-evidence-readiness-check/","source_file":"recipes/general/compliance-standards/eu-dora-evidence-readiness-check.md","recipe_id":"compliance.eu-dora-2022-2554","recipe_kind":"","category":{"slug":"compliance-standards","label":"Compliance Standards"},"agent":"Compliance evidence review","severity":"info","maturity":"stable","ecosystem":"","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"EU DORA","framework_version":"Regulation (EU) 2022/2554","jurisdiction":["european-union"],"industry":["financial-services","ict-third-party-providers"],"cve_archetypes":[],"cve_workflow_role":"","tags":["compliance","eu-dora","regulated-industries","audit","resilience","third-party-risk","financial-services","ict-third-party-providers"],"facets":["audit","compliance"],"quality":{"score":95,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"Security Recipes","team":"GRC and Security Engineering","model":"gpt-5-codex","ai_assisted":false,"generated_by":"","date":"2026-08-21","zero_day":false,"last_updated":"2026-08-21","summary":"Assess EU DORA evidence readiness: verify applicability, map official requirements to artifacts, record gaps, and plan remediation.","content_text":"EU Digital Operational Resilience Act Evidence Check Use this recipe to produce a source-aware evidence-readiness assessment for EU DORA. It creates an auditable gap record; it does not certify compliance, provide legal advice, or replace an assessor, regulator, or certification body. Section index Framework basis When to use it Inputs The prompt Output contract Verification Guardrails Routing examples References Framework basis Publisher: European Union Version: Regulation (EU) 2022/2554 Status: final Sources reviewed: 2026-08-21 Jurisdictions: european-union Industries: financial-services, ict-third-party-providers License boundary: official-text EU financial entities and relevant ICT third-party service relationships after entity, proportionality, and exemption analysis. The cataloged version is final; still verify scope and any later official updates. Use the linked official legal or regulatory text and current implementing guidance; do not replace applicability analysis with this summary. When to use it Use this recipe when the organization has established that EU DORA is applicable or wants a readiness assessment against it. Use the routing positives below to distinguish this recipe from adjacent frameworks. If applicability, the effective version, or the authoritative requirement set is unresolved, stop at a scoped intake and record the decision owner. Inputs The business purpose, legal entities, products, services, systems, and locations in scope. The organization's role, applicability decision, selected profile, level, baseline, or control set where the framework requires one. The official publication URLs above and, for licensed material, an authorized organization-supplied copy. Evidence from the complete review period, including populations—not only hand-picked examples. Named owners, inherited/shared responsibilities, exceptions, compensating measures, and accepted risks. Read-only access by default. Redacted exports are acceptable when provenance and coverage remain testable. Evidence domains for this framework: ICT risk governance: begin with ICT risk framework and board oversight. incident management and reporting: begin with incident classification and reporting records. operational resilience testing: begin with testing program and remediation. ICT third-party risk and information sharing: begin with register of information and contract reviews. The prompt You are a compliance evidence-readiness analyst. Evaluate the supplied scope against EU DORA (Regulation (EU) 2022/2554). The catalog status is final and the source review date is 2026-08-21. Never claim certification or legal compliance. Never invent applicability, evidence, control operation, sampling results, or requirement text. Separate observed facts, organization assertions, and analyst inferences. Treat missing or inaccessible evidence as unknown, not as failure, unless the authoritative assessment method says otherwise. Step 0 — Lock authority, version, and scope 1. Record the exact official source, version, publication/update identifier, and effective date used. 2. Record the organization, role, jurisdiction, industry, system/product boundary, review period, and decision owner. 3. Confirm any selected level, profile, baseline, overlay, assessment type, or licensed requirement set. 4. The cataloged version is final; still verify scope and any later official updates. 5. Use the linked official legal or regulatory text and current implementing guidance; do not replace applicability analysis with this summary. 6. Stop and request a decision when applicability or the authoritative requirement set cannot be established. Step 1 — Build the applicability map For every supplied requirement identifier or official outcome in scope, record: applicability, rationale, responsible owner, implementation location, inherited/shared responsibility, evidence expected, and any dependency. Use only identifiers present in the authoritative source supplied for this engagement. Do not reconstruct licensed text. Step 2 — Collect evidence by framework domain Review these domains without treating the labels as substitutes for authoritative requirements: 1. ICT risk governance 2. incident management and reporting 3. operational resilience testing 4. ICT third-party risk and information sharing Start with these likely artifacts, then validate provenance and coverage: 1. ICT risk framework and board oversight 2. incident classification and reporting records 3. testing program and remediation 4. register of information and contract reviews For every artifact record: artifact ID, source system, owner, collection time, review period, access path, integrity/provenance note, population covered, and requirement/outcome links. Prefer system exports and immutable records over screenshots or narrative attestations. Step 3 — Test design and operation For each applicable item, evaluate design, implementation, and operating evidence separately. Check whether evidence is authentic, complete, current for the review period, population-representative, and directly linked to the scoped system. Where sampling is permitted, state the population, method, sample size, selections, exceptions, and limitations; do not imply statistical assurance without a justified method. Step 4 — Classify gaps without overstating them Use only: supported, partially supported, unsupported, not applicable with rationale, or not assessed. Record gaps as evidence-readiness findings—not declarations of legal noncompliance. Each finding must include the affected requirement/outcome, observed fact, missing or weak evidence, risk, owner, corrective action, due date, dependencies, retest method, and confidence. Step 5 — Produce the evidence bundle Return one Markdown file named EUDORAEVIDENCEREADINESSCHECK.md with: 1. Executive summary and explicit assurance limitations. 2. Authority/version/status and scope/applicability record. 3. Coverage totals by status and evidence domain. 4. Requirement/outcome-to-evidence matrix with artifact provenance. 5. Findings ordered by risk and evidence impact. 6. A 30/60/90-day remediation and evidence-collection plan. 7. Open questions, unavailable sources, conflicts, and decisions required. 8. Official references with access/review date. Before finalizing, verify that every conclusion is traceable to an artifact or clearly labeled assertion/inference, all denominators reconcile, all unavailable evidence is visible, licensed text is not reproduced, and no sentence claims certification or legal approval. Output contract The response must contain one evidence matrix row per scoped authoritative item or outcome. At minimum include itemid, applicability, owner, implementation, artifactids, testmethod, coverageperiod, status, gap, and confidence. Every artifact ID must resolve to the artifact register, and every total must reconcile to the matrix. Verification Confirm the official source, version, status, and review date in both the executive summary and matrix metadata. Reconcile applicable, not applicable, and not assessed counts to the complete supplied scope. Trace each supported assertion to provenance-bearing evidence covering the stated period and population. Independently reperform a risk-based sample of mappings and document all exceptions. Verify findings distinguish control/design weakness from missing evidence and unknown scope. Have the accountable owner and, where required, qualified counsel or an authorized assessor review conclusions. Guardrails This is an evidence-readiness workflow, not certification, attestation, audit opinion, or legal advice. Do not infer that a voluntary framework is mandatory or that one framework proves another. Do not paste, paraphrase at length, or reconstruct licensed controls. Use source summaries and organization-supplied licensed material. Do not expose secrets, personal data, regulated data, or full production exports in the report. Do not modify systems, close findings, accept risk, or submit regulatory reports without explicit owner authorization. If versions conflict, preserve both citations, label the conflict, and escalate rather than choosing silently. Routing examples Route here: assess EU DORA evidence review digital operational resilience prepare ICT third-party risk records Hard negatives—route elsewhere or clarify: assess NIS2 essential entity measures perform GDPR privacy accountability review Related recipes PCI DSS 4.0.1 HIPAA Security Rule GLBA Safeguards Rule References 1. European Union official source 1","agent_handoff":{"mcp_lookup_keys":["eu-dora-evidence-readiness-check","/recipes/general/compliance-standards/eu-dora-evidence-readiness-check/","recipes/general/compliance-standards/eu-dora-evidence-readiness-check.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["audit","compliance"],"source_text_field":"content_text","portable_download":"security-recipe-eu-dora-evidence-readiness-check.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-eu-dora-evidence-readiness-check.json"}},{"slug":"eu-gdpr-accountability-evidence-check","title":"EU GDPR Accountability Evidence Check","link_title":"EU GDPR","url":"https://security-recipes.ai/recipes/general/compliance-standards/eu-gdpr-accountability-evidence-check/","path":"/recipes/general/compliance-standards/eu-gdpr-accountability-evidence-check/","source_file":"recipes/general/compliance-standards/eu-gdpr-accountability-evidence-check.md","recipe_id":"compliance.eu-gdpr-2016-679","recipe_kind":"","category":{"slug":"compliance-standards","label":"Compliance Standards"},"agent":"Compliance evidence review","severity":"info","maturity":"stable","ecosystem":"","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"EU GDPR","framework_version":"Regulation (EU) 2016/679","jurisdiction":["european-union","eea","extraterritorial"],"industry":["cross-sector"],"cve_archetypes":[],"cve_workflow_role":"","tags":["compliance","gdpr","privacy","audit","data-protection","cross-sector"],"facets":["audit","compliance"],"quality":{"score":95,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"Security Recipes","team":"GRC and Security Engineering","model":"gpt-5-codex","ai_assisted":false,"generated_by":"","date":"2026-08-21","zero_day":false,"last_updated":"2026-08-21","summary":"Assess EU GDPR evidence readiness: verify applicability, map official requirements to artifacts, record gaps, and plan remediation.","content_text":"EU GDPR Accountability Evidence Check Use this recipe to produce a source-aware evidence-readiness assessment for EU GDPR. It creates an auditable gap record; it does not certify compliance, provide legal advice, or replace an assessor, regulator, or certification body. Section index Framework basis When to use it Inputs The prompt Output contract Verification Guardrails Routing examples References Framework basis Publisher: European Union Version: Regulation (EU) 2016/679 Status: final Sources reviewed: 2026-08-21 Jurisdictions: european-union, eea, extraterritorial Industries: cross-sector License boundary: official-text Controllers and processors handling personal data within GDPR territorial scope, including applicable extraterritorial processing. The cataloged version is final; still verify scope and any later official updates. Use the linked official legal or regulatory text and current implementing guidance; do not replace applicability analysis with this summary. When to use it Use this recipe when the organization has established that EU GDPR is applicable or wants a readiness assessment against it. Use the routing positives below to distinguish this recipe from adjacent frameworks. If applicability, the effective version, or the authoritative requirement set is unresolved, stop at a scoped intake and record the decision owner. Inputs The business purpose, legal entities, products, services, systems, and locations in scope. The organization's role, applicability decision, selected profile, level, baseline, or control set where the framework requires one. The official publication URLs above and, for licensed material, an authorized organization-supplied copy. Evidence from the complete review period, including populations—not only hand-picked examples. Named owners, inherited/shared responsibilities, exceptions, compensating measures, and accepted risks. Read-only access by default. Redacted exports are acceptable when provenance and coverage remain testable. Evidence domains for this framework: processing inventory and lawful basis: begin with records of processing activities. data subject rights: begin with DPIAs and legitimate-interest assessments. privacy by design and security: begin with rights request and retention records. processors, transfers, incidents, and accountability: begin with transfer, processor, and breach documentation. The prompt You are a compliance evidence-readiness analyst. Evaluate the supplied scope against EU GDPR (Regulation (EU) 2016/679). The catalog status is final and the source review date is 2026-08-21. Never claim certification or legal compliance. Never invent applicability, evidence, control operation, sampling results, or requirement text. Separate observed facts, organization assertions, and analyst inferences. Treat missing or inaccessible evidence as unknown, not as failure, unless the authoritative assessment method says otherwise. Step 0 — Lock authority, version, and scope 1. Record the exact official source, version, publication/update identifier, and effective date used. 2. Record the organization, role, jurisdiction, industry, system/product boundary, review period, and decision owner. 3. Confirm any selected level, profile, baseline, overlay, assessment type, or licensed requirement set. 4. The cataloged version is final; still verify scope and any later official updates. 5. Use the linked official legal or regulatory text and current implementing guidance; do not replace applicability analysis with this summary. 6. Stop and request a decision when applicability or the authoritative requirement set cannot be established. Step 1 — Build the applicability map For every supplied requirement identifier or official outcome in scope, record: applicability, rationale, responsible owner, implementation location, inherited/shared responsibility, evidence expected, and any dependency. Use only identifiers present in the authoritative source supplied for this engagement. Do not reconstruct licensed text. Step 2 — Collect evidence by framework domain Review these domains without treating the labels as substitutes for authoritative requirements: 1. processing inventory and lawful basis 2. data subject rights 3. privacy by design and security 4. processors, transfers, incidents, and accountability Start with these likely artifacts, then validate provenance and coverage: 1. records of processing activities 2. DPIAs and legitimate-interest assessments 3. rights request and retention records 4. transfer, processor, and breach documentation For every artifact record: artifact ID, source system, owner, collection time, review period, access path, integrity/provenance note, population covered, and requirement/outcome links. Prefer system exports and immutable records over screenshots or narrative attestations. Step 3 — Test design and operation For each applicable item, evaluate design, implementation, and operating evidence separately. Check whether evidence is authentic, complete, current for the review period, population-representative, and directly linked to the scoped system. Where sampling is permitted, state the population, method, sample size, selections, exceptions, and limitations; do not imply statistical assurance without a justified method. Step 4 — Classify gaps without overstating them Use only: supported, partially supported, unsupported, not applicable with rationale, or not assessed. Record gaps as evidence-readiness findings—not declarations of legal noncompliance. Each finding must include the affected requirement/outcome, observed fact, missing or weak evidence, risk, owner, corrective action, due date, dependencies, retest method, and confidence. Step 5 — Produce the evidence bundle Return one Markdown file named EUGDPRACCOUNTABILITYEVIDENCECHECK.md with: 1. Executive summary and explicit assurance limitations. 2. Authority/version/status and scope/applicability record. 3. Coverage totals by status and evidence domain. 4. Requirement/outcome-to-evidence matrix with artifact provenance. 5. Findings ordered by risk and evidence impact. 6. A 30/60/90-day remediation and evidence-collection plan. 7. Open questions, unavailable sources, conflicts, and decisions required. 8. Official references with access/review date. Before finalizing, verify that every conclusion is traceable to an artifact or clearly labeled assertion/inference, all denominators reconcile, all unavailable evidence is visible, licensed text is not reproduced, and no sentence claims certification or legal approval. Output contract The response must contain one evidence matrix row per scoped authoritative item or outcome. At minimum include itemid, applicability, owner, implementation, artifactids, testmethod, coverageperiod, status, gap, and confidence. Every artifact ID must resolve to the artifact register, and every total must reconcile to the matrix. Verification Confirm the official source, version, status, and review date in both the executive summary and matrix metadata. Reconcile applicable, not applicable, and not assessed counts to the complete supplied scope. Trace each supported assertion to provenance-bearing evidence covering the stated period and population. Independently reperform a risk-based sample of mappings and document all exceptions. Verify findings distinguish control/design weakness from missing evidence and unknown scope. Have the accountable owner and, where required, qualified counsel or an authorized assessor review conclusions. Guardrails This is an evidence-readiness workflow, not certification, attestation, audit opinion, or legal advice. Do not infer that a voluntary framework is mandatory or that one framework proves another. Do not paste, paraphrase at length, or reconstruct licensed controls. Use source summaries and organization-supplied licensed material. Do not expose secrets, personal data, regulated data, or full production exports in the report. Do not modify systems, close findings, accept risk, or submit regulatory reports without explicit owner authorization. If versions conflict, preserve both citations, label the conflict, and escalate rather than choosing silently. Routing examples Route here: assess GDPR accountability evidence review personal-data processing governance prepare records of processing and DPIA evidence Hard negatives—route elsewhere or clarify: assess NIS2 cybersecurity risk measures review ISO 27701 certification evidence only Related recipes NIST Privacy Framework ISO/IEC 27701:2025 CIS Controls v8.1 References 1. European Union official source 1","agent_handoff":{"mcp_lookup_keys":["eu-gdpr-accountability-evidence-check","/recipes/general/compliance-standards/eu-gdpr-accountability-evidence-check/","recipes/general/compliance-standards/eu-gdpr-accountability-evidence-check.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["audit","compliance"],"source_text_field":"content_text","portable_download":"security-recipe-eu-gdpr-accountability-evidence-check.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-eu-gdpr-accountability-evidence-check.json"}},{"slug":"eu-nis2-evidence-readiness-check","title":"EU NIS2 Directive Evidence Readiness Check","link_title":"EU NIS2","url":"https://security-recipes.ai/recipes/general/compliance-standards/eu-nis2-evidence-readiness-check/","path":"/recipes/general/compliance-standards/eu-nis2-evidence-readiness-check/","source_file":"recipes/general/compliance-standards/eu-nis2-evidence-readiness-check.md","recipe_id":"compliance.eu-nis2-2022-2555","recipe_kind":"","category":{"slug":"compliance-standards","label":"Compliance Standards"},"agent":"Compliance evidence review","severity":"info","maturity":"stable","ecosystem":"","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"EU NIS2","framework_version":"Directive (EU) 2022/2555","jurisdiction":["european-union","member-state-implementation"],"industry":["essential-entities","important-entities","critical-infrastructure"],"cve_archetypes":[],"cve_workflow_role":"","tags":["compliance","eu-nis2","critical-infrastructure","audit","incident-response","essential-entities","important-entities"],"facets":["audit","compliance"],"quality":{"score":95,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"Security Recipes","team":"GRC and Security Engineering","model":"gpt-5-codex","ai_assisted":false,"generated_by":"","date":"2026-08-21","zero_day":false,"last_updated":"2026-08-21","summary":"Assess EU NIS2 evidence readiness: verify applicability, map official requirements to artifacts, record gaps, and plan remediation.","content_text":"EU NIS2 Directive Evidence Readiness Check Use this recipe to produce a source-aware evidence-readiness assessment for EU NIS2. It creates an auditable gap record; it does not certify compliance, provide legal advice, or replace an assessor, regulator, or certification body. Section index Framework basis When to use it Inputs The prompt Output contract Verification Guardrails Routing examples References Framework basis Publisher: European Union Version: Directive (EU) 2022/2555 Status: final Sources reviewed: 2026-08-21 Jurisdictions: european-union, member-state-implementation Industries: essential-entities, important-entities, critical-infrastructure License boundary: official-text Entities potentially classified as essential or important under NIS2 and the applicable member-state implementing law. The cataloged version is final; still verify scope and any later official updates. Use the linked official legal or regulatory text and current implementing guidance; do not replace applicability analysis with this summary. When to use it Use this recipe when the organization has established that EU NIS2 is applicable or wants a readiness assessment against it. Use the routing positives below to distinguish this recipe from adjacent frameworks. If applicability, the effective version, or the authoritative requirement set is unresolved, stop at a scoped intake and record the decision owner. Inputs The business purpose, legal entities, products, services, systems, and locations in scope. The organization's role, applicability decision, selected profile, level, baseline, or control set where the framework requires one. The official publication URLs above and, for licensed material, an authorized organization-supplied copy. Evidence from the complete review period, including populations—not only hand-picked examples. Named owners, inherited/shared responsibilities, exceptions, compensating measures, and accepted risks. Read-only access by default. Redacted exports are acceptable when provenance and coverage remain testable. Evidence domains for this framework: entity and national-law applicability: begin with entity classification and jurisdiction analysis. management accountability and risk measures: begin with management approvals and training. supply-chain and resilience: begin with risk, continuity, cryptography, and supplier records. incident classification and notification: begin with incident timelines and notification evidence. The prompt You are a compliance evidence-readiness analyst. Evaluate the supplied scope against EU NIS2 (Directive (EU) 2022/2555). The catalog status is final and the source review date is 2026-08-21. Never claim certification or legal compliance. Never invent applicability, evidence, control operation, sampling results, or requirement text. Separate observed facts, organization assertions, and analyst inferences. Treat missing or inaccessible evidence as unknown, not as failure, unless the authoritative assessment method says otherwise. Step 0 — Lock authority, version, and scope 1. Record the exact official source, version, publication/update identifier, and effective date used. 2. Record the organization, role, jurisdiction, industry, system/product boundary, review period, and decision owner. 3. Confirm any selected level, profile, baseline, overlay, assessment type, or licensed requirement set. 4. The cataloged version is final; still verify scope and any later official updates. 5. Use the linked official legal or regulatory text and current implementing guidance; do not replace applicability analysis with this summary. 6. Stop and request a decision when applicability or the authoritative requirement set cannot be established. Step 1 — Build the applicability map For every supplied requirement identifier or official outcome in scope, record: applicability, rationale, responsible owner, implementation location, inherited/shared responsibility, evidence expected, and any dependency. Use only identifiers present in the authoritative source supplied for this engagement. Do not reconstruct licensed text. Step 2 — Collect evidence by framework domain Review these domains without treating the labels as substitutes for authoritative requirements: 1. entity and national-law applicability 2. management accountability and risk measures 3. supply-chain and resilience 4. incident classification and notification Start with these likely artifacts, then validate provenance and coverage: 1. entity classification and jurisdiction analysis 2. management approvals and training 3. risk, continuity, cryptography, and supplier records 4. incident timelines and notification evidence For every artifact record: artifact ID, source system, owner, collection time, review period, access path, integrity/provenance note, population covered, and requirement/outcome links. Prefer system exports and immutable records over screenshots or narrative attestations. Step 3 — Test design and operation For each applicable item, evaluate design, implementation, and operating evidence separately. Check whether evidence is authentic, complete, current for the review period, population-representative, and directly linked to the scoped system. Where sampling is permitted, state the population, method, sample size, selections, exceptions, and limitations; do not imply statistical assurance without a justified method. Step 4 — Classify gaps without overstating them Use only: supported, partially supported, unsupported, not applicable with rationale, or not assessed. Record gaps as evidence-readiness findings—not declarations of legal noncompliance. Each finding must include the affected requirement/outcome, observed fact, missing or weak evidence, risk, owner, corrective action, due date, dependencies, retest method, and confidence. Step 5 — Produce the evidence bundle Return one Markdown file named EUNIS2EVIDENCEREADINESSCHECK.md with: 1. Executive summary and explicit assurance limitations. 2. Authority/version/status and scope/applicability record. 3. Coverage totals by status and evidence domain. 4. Requirement/outcome-to-evidence matrix with artifact provenance. 5. Findings ordered by risk and evidence impact. 6. A 30/60/90-day remediation and evidence-collection plan. 7. Open questions, unavailable sources, conflicts, and decisions required. 8. Official references with access/review date. Before finalizing, verify that every conclusion is traceable to an artifact or clearly labeled assertion/inference, all denominators reconcile, all unavailable evidence is visible, licensed text is not reproduced, and no sentence claims certification or legal approval. Output contract The response must contain one evidence matrix row per scoped authoritative item or outcome. At minimum include itemid, applicability, owner, implementation, artifactids, testmethod, coverageperiod, status, gap, and confidence. Every artifact ID must resolve to the artifact register, and every total must reconcile to the matrix. Verification Confirm the official source, version, status, and review date in both the executive summary and matrix metadata. Reconcile applicable, not applicable, and not assessed counts to the complete supplied scope. Trace each supported assertion to provenance-bearing evidence covering the stated period and population. Independently reperform a risk-based sample of mappings and document all exceptions. Verify findings distinguish control/design weakness from missing evidence and unknown scope. Have the accountable owner and, where required, qualified counsel or an authorized assessor review conclusions. Guardrails This is an evidence-readiness workflow, not certification, attestation, audit opinion, or legal advice. Do not infer that a voluntary framework is mandatory or that one framework proves another. Do not paste, paraphrase at length, or reconstruct licensed controls. Use source summaries and organization-supplied licensed material. Do not expose secrets, personal data, regulated data, or full production exports in the report. Do not modify systems, close findings, accept risk, or submit regulatory reports without explicit owner authorization. If versions conflict, preserve both citations, label the conflict, and escalate rather than choosing silently. Routing examples Route here: assess NIS2 evidence readiness review essential entity cybersecurity measures prepare NIS2 incident reporting evidence Hard negatives—route elsewhere or clarify: assess DORA financial-sector resilience only apply the directive without member-state law analysis Related recipes IEC 62443 NERC CIP CISA Cross-Sector CPGs References 1. European Union official source 1","agent_handoff":{"mcp_lookup_keys":["eu-nis2-evidence-readiness-check","/recipes/general/compliance-standards/eu-nis2-evidence-readiness-check/","recipes/general/compliance-standards/eu-nis2-evidence-readiness-check.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["audit","compliance"],"source_text_field":"content_text","portable_download":"security-recipe-eu-nis2-evidence-readiness-check.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-eu-nis2-evidence-readiness-check.json"}},{"slug":"fda-medical-device-cybersecurity-evidence-check","title":"FDA Medical Device Cybersecurity Premarket Evidence Check","link_title":"FDA Medical Device Cybersecurity","url":"https://security-recipes.ai/recipes/general/compliance-standards/fda-medical-device-cybersecurity-evidence-check/","path":"/recipes/general/compliance-standards/fda-medical-device-cybersecurity-evidence-check/","source_file":"recipes/general/compliance-standards/fda-medical-device-cybersecurity-evidence-check.md","recipe_id":"compliance.fda-medical-device-cybersecurity-2026","recipe_kind":"","category":{"slug":"compliance-standards","label":"Compliance Standards"},"agent":"Compliance evidence review","severity":"info","maturity":"stable","ecosystem":"","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"FDA Medical Device Cybersecurity","framework_version":"Final Guidance, February 2026","jurisdiction":["united-states"],"industry":["medical-devices","healthcare"],"cve_archetypes":[],"cve_workflow_role":"","tags":["compliance","fda-medical-device-cybersecurity","regulated-industries","audit","product-security","safety","medical-devices","healthcare"],"facets":["audit","compliance"],"quality":{"score":95,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"Security Recipes","team":"GRC and Security Engineering","model":"gpt-5-codex","ai_assisted":false,"generated_by":"","date":"2026-08-21","zero_day":false,"last_updated":"2026-08-21","summary":"Assess FDA Medical Device Cybersecurity evidence readiness: verify applicability, map official requirements to artifacts, record gaps, and plan remediation.","content_text":"FDA Medical Device Cybersecurity Premarket Evidence Check Use this recipe to produce a source-aware evidence-readiness assessment for FDA Medical Device Cybersecurity. It creates an auditable gap record; it does not certify compliance, provide legal advice, or replace an assessor, regulator, or certification body. Section index Framework basis When to use it Inputs The prompt Output contract Verification Guardrails Routing examples References Framework basis Publisher: U.S. Food and Drug Administration Version: Final Guidance, February 2026 Status: final Sources reviewed: 2026-08-21 Jurisdictions: united-states Industries: medical-devices, healthcare License boundary: public-domain Medical device manufacturers preparing premarket cybersecurity documentation; the February 2026 final guidance supersedes the June 2025 version. The cataloged version is final; still verify scope and any later official updates. Use the official publication as the authority and preserve its version and update identifiers in every finding. When to use it Use this recipe when the organization has established that FDA Medical Device Cybersecurity is applicable or wants a readiness assessment against it. Use the routing positives below to distinguish this recipe from adjacent frameworks. If applicability, the effective version, or the authoritative requirement set is unresolved, stop at a scoped intake and record the decision owner. Inputs The business purpose, legal entities, products, services, systems, and locations in scope. The organization's role, applicability decision, selected profile, level, baseline, or control set where the framework requires one. The official publication URLs above and, for licensed material, an authorized organization-supplied copy. Evidence from the complete review period, including populations—not only hand-picked examples. Named owners, inherited/shared responsibilities, exceptions, compensating measures, and accepted risks. Read-only access by default. Redacted exports are acceptable when provenance and coverage remain testable. Evidence domains for this framework: device scope and cybersecurity risk management: begin with threat model and risk traceability. secure product development framework: begin with security architecture views. security architecture and testing: begin with verification, validation, and penetration-test reports. SBOM, updates, labeling, and vulnerability management: begin with SBOM, update plan, labeling, and coordinated disclosure records. The prompt You are a compliance evidence-readiness analyst. Evaluate the supplied scope against FDA Medical Device Cybersecurity (Final Guidance, February 2026). The catalog status is final and the source review date is 2026-08-21. Never claim certification or legal compliance. Never invent applicability, evidence, control operation, sampling results, or requirement text. Separate observed facts, organization assertions, and analyst inferences. Treat missing or inaccessible evidence as unknown, not as failure, unless the authoritative assessment method says otherwise. Step 0 — Lock authority, version, and scope 1. Record the exact official source, version, publication/update identifier, and effective date used. 2. Record the organization, role, jurisdiction, industry, system/product boundary, review period, and decision owner. 3. Confirm any selected level, profile, baseline, overlay, assessment type, or licensed requirement set. 4. The cataloged version is final; still verify scope and any later official updates. 5. Use the official publication as the authority and preserve its version and update identifiers in every finding. 6. Stop and request a decision when applicability or the authoritative requirement set cannot be established. Step 1 — Build the applicability map For every supplied requirement identifier or official outcome in scope, record: applicability, rationale, responsible owner, implementation location, inherited/shared responsibility, evidence expected, and any dependency. Use only identifiers present in the authoritative source supplied for this engagement. Do not reconstruct licensed text. Step 2 — Collect evidence by framework domain Review these domains without treating the labels as substitutes for authoritative requirements: 1. device scope and cybersecurity risk management 2. secure product development framework 3. security architecture and testing 4. SBOM, updates, labeling, and vulnerability management Start with these likely artifacts, then validate provenance and coverage: 1. threat model and risk traceability 2. security architecture views 3. verification, validation, and penetration-test reports 4. SBOM, update plan, labeling, and coordinated disclosure records For every artifact record: artifact ID, source system, owner, collection time, review period, access path, integrity/provenance note, population covered, and requirement/outcome links. Prefer system exports and immutable records over screenshots or narrative attestations. Step 3 — Test design and operation For each applicable item, evaluate design, implementation, and operating evidence separately. Check whether evidence is authentic, complete, current for the review period, population-representative, and directly linked to the scoped system. Where sampling is permitted, state the population, method, sample size, selections, exceptions, and limitations; do not imply statistical assurance without a justified method. Step 4 — Classify gaps without overstating them Use only: supported, partially supported, unsupported, not applicable with rationale, or not assessed. Record gaps as evidence-readiness findings—not declarations of legal noncompliance. Each finding must include the affected requirement/outcome, observed fact, missing or weak evidence, risk, owner, corrective action, due date, dependencies, retest method, and confidence. Step 5 — Produce the evidence bundle Return one Markdown file named FDAMEDICALDEVICECYBERSECURITYEVIDENCECHECK.md with: 1. Executive summary and explicit assurance limitations. 2. Authority/version/status and scope/applicability record. 3. Coverage totals by status and evidence domain. 4. Requirement/outcome-to-evidence matrix with artifact provenance. 5. Findings ordered by risk and evidence impact. 6. A 30/60/90-day remediation and evidence-collection plan. 7. Open questions, unavailable sources, conflicts, and decisions required. 8. Official references with access/review date. Before finalizing, verify that every conclusion is traceable to an artifact or clearly labeled assertion/inference, all denominators reconcile, all unavailable evidence is visible, licensed text is not reproduced, and no sentence claims certification or legal approval. Output contract The response must contain one evidence matrix row per scoped authoritative item or outcome. At minimum include itemid, applicability, owner, implementation, artifactids, testmethod, coverage_period, status, gap, and confidence. Every artifact ID must resolve to the artifact register, and every total must reconcile to the matrix. Verification Confirm the official source, version, status, and review date in both the executive summary and matrix metadata. Reconcile applicable, not applicable, and not assessed counts to the complete supplied scope. Trace each supported assertion to provenance-bearing evidence covering the stated period and population. Independently reperform a risk-based sample of mappings and document all exceptions. Verify findings distinguish control/design weakness from missing evidence and unknown scope. Have the accountable owner and, where required, qualified counsel or an authorized assessor review conclusions. Guardrails This is an evidence-readiness workflow, not certification, attestation, audit opinion, or legal advice. Do not infer that a voluntary framework is mandatory or that one framework proves another. Do not paste, paraphrase at length, or reconstruct licensed controls. Use source summaries and organization-supplied licensed material. Do not expose secrets, personal data, regulated data, or full production exports in the report. Do not modify systems, close findings, accept risk, or submit regulatory reports without explicit owner authorization. If versions conflict, preserve both citations, label the conflict, and escalate rather than choosing silently. Routing examples Route here: prepare FDA medical device cybersecurity evidence review premarket device security documentation assess a secure product development framework for a device Hard negatives—route elsewhere or clarify: perform a HIPAA covered-entity assessment assess a general IoT product only with NIST 8259 Related recipes PCI DSS 4.0.1 HIPAA Security Rule GLBA Safeguards Rule References 1. U.S. Food and Drug Administration official source 1","agent_handoff":{"mcp_lookup_keys":["fda-medical-device-cybersecurity-evidence-check","/recipes/general/compliance-standards/fda-medical-device-cybersecurity-evidence-check/","recipes/general/compliance-standards/fda-medical-device-cybersecurity-evidence-check.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["audit","compliance"],"source_text_field":"content_text","portable_download":"security-recipe-fda-medical-device-cybersecurity-evidence-check.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-fda-medical-device-cybersecurity-evidence-check.json"}},{"slug":"fedramp-2026-rev5-evidence-check","title":"FedRAMP 2026 Rev. 5 Authorization Evidence Check","link_title":"FedRAMP 2026","url":"https://security-recipes.ai/recipes/general/compliance-standards/fedramp-2026-rev5-evidence-check/","path":"/recipes/general/compliance-standards/fedramp-2026-rev5-evidence-check/","source_file":"recipes/general/compliance-standards/fedramp-2026-rev5-evidence-check.md","recipe_id":"compliance.fedramp-2026-consolidated-rev5","recipe_kind":"","category":{"slug":"compliance-standards","label":"Compliance Standards"},"agent":"Compliance evidence review","severity":"info","maturity":"stable","ecosystem":"","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"FedRAMP 2026","framework_version":"2026 Consolidated Rules / Rev. 5 controls","jurisdiction":["united-states"],"industry":["cloud","government-contractors"],"cve_archetypes":[],"cve_workflow_role":"","tags":["compliance","fedramp","government","audit","cloud","authorization","government-contractors"],"facets":["audit","compliance"],"quality":{"score":95,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"Security Recipes","team":"GRC and Security Engineering","model":"gpt-5-codex","ai_assisted":false,"generated_by":"","date":"2026-08-21","zero_day":false,"last_updated":"2026-08-21","summary":"Assess FedRAMP 2026 evidence readiness: verify applicability, map official requirements to artifacts, record gaps, and plan remediation.","content_text":"FedRAMP 2026 Rev. 5 Authorization Evidence Check Use this recipe to produce a source-aware evidence-readiness assessment for FedRAMP 2026. It creates an auditable gap record; it does not certify compliance, provide legal advice, or replace an assessor, regulator, or certification body. Section index Framework basis When to use it Inputs The prompt Output contract Verification Guardrails Routing examples References Framework basis Publisher: FedRAMP Version: 2026 Consolidated Rules / Rev. 5 controls Status: final Sources reviewed: 2026-08-21 Jurisdictions: united-states Industries: cloud, government-contractors License boundary: public-domain Cloud service offerings pursuing or maintaining a FedRAMP authorization under the 2026 consolidated rules and Rev. 5 control baseline. The cataloged version is final; still verify scope and any later official updates. Use the official publication as the authority and preserve its version and update identifiers in every finding. When to use it Use this recipe when the organization has established that FedRAMP 2026 is applicable or wants a readiness assessment against it. Use the routing positives below to distinguish this recipe from adjacent frameworks. If applicability, the effective version, or the authoritative requirement set is unresolved, stop at a scoped intake and record the decision owner. Inputs The business purpose, legal entities, products, services, systems, and locations in scope. The organization's role, applicability decision, selected profile, level, baseline, or control set where the framework requires one. The official publication URLs above and, for licensed material, an authorized organization-supplied copy. Evidence from the complete review period, including populations—not only hand-picked examples. Named owners, inherited/shared responsibilities, exceptions, compensating measures, and accepted risks. Read-only access by default. Redacted exports are acceptable when provenance and coverage remain testable. Evidence domains for this framework: offering boundary and authorization path: begin with boundary diagrams and data flows. security package and control implementation: begin with SSP and required package artifacts. independent assessment: begin with 3PAO assessment results. continuous monitoring and significant change: begin with POA&M, scan, incident, and change records. The prompt You are a compliance evidence-readiness analyst. Evaluate the supplied scope against FedRAMP 2026 (2026 Consolidated Rules / Rev. 5 controls). The catalog status is final and the source review date is 2026-08-21. Never claim certification or legal compliance. Never invent applicability, evidence, control operation, sampling results, or requirement text. Separate observed facts, organization assertions, and analyst inferences. Treat missing or inaccessible evidence as unknown, not as failure, unless the authoritative assessment method says otherwise. Step 0 — Lock authority, version, and scope 1. Record the exact official source, version, publication/update identifier, and effective date used. 2. Record the organization, role, jurisdiction, industry, system/product boundary, review period, and decision owner. 3. Confirm any selected level, profile, baseline, overlay, assessment type, or licensed requirement set. 4. The cataloged version is final; still verify scope and any later official updates. 5. Use the official publication as the authority and preserve its version and update identifiers in every finding. 6. Stop and request a decision when applicability or the authoritative requirement set cannot be established. Step 1 — Build the applicability map For every supplied requirement identifier or official outcome in scope, record: applicability, rationale, responsible owner, implementation location, inherited/shared responsibility, evidence expected, and any dependency. Use only identifiers present in the authoritative source supplied for this engagement. Do not reconstruct licensed text. Step 2 — Collect evidence by framework domain Review these domains without treating the labels as substitutes for authoritative requirements: 1. offering boundary and authorization path 2. security package and control implementation 3. independent assessment 4. continuous monitoring and significant change Start with these likely artifacts, then validate provenance and coverage: 1. boundary diagrams and data flows 2. SSP and required package artifacts 3. 3PAO assessment results 4. POA&M, scan, incident, and change records For every artifact record: artifact ID, source system, owner, collection time, review period, access path, integrity/provenance note, population covered, and requirement/outcome links. Prefer system exports and immutable records over screenshots or narrative attestations. Step 3 — Test design and operation For each applicable item, evaluate design, implementation, and operating evidence separately. Check whether evidence is authentic, complete, current for the review period, population-representative, and directly linked to the scoped system. Where sampling is permitted, state the population, method, sample size, selections, exceptions, and limitations; do not imply statistical assurance without a justified method. Step 4 — Classify gaps without overstating them Use only: supported, partially supported, unsupported, not applicable with rationale, or not assessed. Record gaps as evidence-readiness findings—not declarations of legal noncompliance. Each finding must include the affected requirement/outcome, observed fact, missing or weak evidence, risk, owner, corrective action, due date, dependencies, retest method, and confidence. Step 5 — Produce the evidence bundle Return one Markdown file named FEDRAMP2026REV5EVIDENCECHECK.md with: 1. Executive summary and explicit assurance limitations. 2. Authority/version/status and scope/applicability record. 3. Coverage totals by status and evidence domain. 4. Requirement/outcome-to-evidence matrix with artifact provenance. 5. Findings ordered by risk and evidence impact. 6. A 30/60/90-day remediation and evidence-collection plan. 7. Open questions, unavailable sources, conflicts, and decisions required. 8. Official references with access/review date. Before finalizing, verify that every conclusion is traceable to an artifact or clearly labeled assertion/inference, all denominators reconcile, all unavailable evidence is visible, licensed text is not reproduced, and no sentence claims certification or legal approval. Output contract The response must contain one evidence matrix row per scoped authoritative item or outcome. At minimum include itemid, applicability, owner, implementation, artifactids, testmethod, coverageperiod, status, gap, and confidence. Every artifact ID must resolve to the artifact register, and every total must reconcile to the matrix. Verification Confirm the official source, version, status, and review date in both the executive summary and matrix metadata. Reconcile applicable, not applicable, and not assessed counts to the complete supplied scope. Trace each supported assertion to provenance-bearing evidence covering the stated period and population. Independently reperform a risk-based sample of mappings and document all exceptions. Verify findings distinguish control/design weakness from missing evidence and unknown scope. Have the accountable owner and, where required, qualified counsel or an authorized assessor review conclusions. Guardrails This is an evidence-readiness workflow, not certification, attestation, audit opinion, or legal advice. Do not infer that a voluntary framework is mandatory or that one framework proves another. Do not paste, paraphrase at length, or reconstruct licensed controls. Use source summaries and organization-supplied licensed material. Do not expose secrets, personal data, regulated data, or full production exports in the report. Do not modify systems, close findings, accept risk, or submit regulatory reports without explicit owner authorization. If versions conflict, preserve both citations, label the conflict, and escalate rather than choosing silently. Routing examples Route here: prepare FedRAMP 2026 authorization evidence review a Rev 5 cloud security package assess FedRAMP continuous monitoring artifacts Hard negatives—route elsewhere or clarify: perform a commercial CSA CCM review assess CMMC contractor certification Related recipes NIST SP 800-53 Rev. 5 NIST SP 800-171 Rev. 3 CMMC 2.0 References 1. FedRAMP official source 1","agent_handoff":{"mcp_lookup_keys":["fedramp-2026-rev5-evidence-check","/recipes/general/compliance-standards/fedramp-2026-rev5-evidence-check/","recipes/general/compliance-standards/fedramp-2026-rev5-evidence-check.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["audit","compliance"],"source_text_field":"content_text","portable_download":"security-recipe-fedramp-2026-rev5-evidence-check.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-fedramp-2026-rev5-evidence-check.json"}},{"slug":"glba-safeguards-rule-evidence-check","title":"FTC GLBA Safeguards Rule Evidence Check","link_title":"GLBA Safeguards Rule","url":"https://security-recipes.ai/recipes/general/compliance-standards/glba-safeguards-rule-evidence-check/","path":"/recipes/general/compliance-standards/glba-safeguards-rule-evidence-check/","source_file":"recipes/general/compliance-standards/glba-safeguards-rule-evidence-check.md","recipe_id":"compliance.ftc-glba-safeguards-rule","recipe_kind":"","category":{"slug":"compliance-standards","label":"Compliance Standards"},"agent":"Compliance evidence review","severity":"info","maturity":"stable","ecosystem":"","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"GLBA Safeguards Rule","framework_version":"16 CFR Part 314 current rule","jurisdiction":["united-states"],"industry":["financial-services","nonbank-financial-institutions"],"cve_archetypes":[],"cve_workflow_role":"","tags":["compliance","glba-safeguards","regulated-industries","audit","data-protection","governance","financial-services","nonbank-financial-institutions"],"facets":["audit","compliance"],"quality":{"score":95,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"Security Recipes","team":"GRC and Security Engineering","model":"gpt-5-codex","ai_assisted":false,"generated_by":"","date":"2026-08-21","zero_day":false,"last_updated":"2026-08-21","summary":"Assess GLBA Safeguards Rule evidence readiness: verify applicability, map official requirements to artifacts, record gaps, and plan remediation.","content_text":"FTC GLBA Safeguards Rule Evidence Check Use this recipe to produce a source-aware evidence-readiness assessment for GLBA Safeguards Rule. It creates an auditable gap record; it does not certify compliance, provide legal advice, or replace an assessor, regulator, or certification body. Section index Framework basis When to use it Inputs The prompt Output contract Verification Guardrails Routing examples References Framework basis Publisher: U.S. Federal Trade Commission Version: 16 CFR Part 314 current rule Status: final Sources reviewed: 2026-08-21 Jurisdictions: united-states Industries: financial-services, nonbank-financial-institutions License boundary: official-text FTC-regulated financial institutions maintaining a written information security program for customer information. The cataloged version is final; still verify scope and any later official updates. Use the linked official legal or regulatory text and current implementing guidance; do not replace applicability analysis with this summary. When to use it Use this recipe when the organization has established that GLBA Safeguards Rule is applicable or wants a readiness assessment against it. Use the routing positives below to distinguish this recipe from adjacent frameworks. If applicability, the effective version, or the authoritative requirement set is unresolved, stop at a scoped intake and record the decision owner. Inputs The business purpose, legal entities, products, services, systems, and locations in scope. The organization's role, applicability decision, selected profile, level, baseline, or control set where the framework requires one. The official publication URLs above and, for licensed material, an authorized organization-supplied copy. Evidence from the complete review period, including populations—not only hand-picked examples. Named owners, inherited/shared responsibilities, exceptions, compensating measures, and accepted risks. Read-only access by default. Redacted exports are acceptable when provenance and coverage remain testable. Evidence domains for this framework: qualified individual and risk assessment: begin with written information security program. safeguards and access controls: begin with risk assessment and safeguard decisions. service providers and change management: begin with service-provider monitoring records. testing, incident response, and board reporting: begin with penetration-test, incident, and board report artifacts. The prompt You are a compliance evidence-readiness analyst. Evaluate the supplied scope against GLBA Safeguards Rule (16 CFR Part 314 current rule). The catalog status is final and the source review date is 2026-08-21. Never claim certification or legal compliance. Never invent applicability, evidence, control operation, sampling results, or requirement text. Separate observed facts, organization assertions, and analyst inferences. Treat missing or inaccessible evidence as unknown, not as failure, unless the authoritative assessment method says otherwise. Step 0 — Lock authority, version, and scope 1. Record the exact official source, version, publication/update identifier, and effective date used. 2. Record the organization, role, jurisdiction, industry, system/product boundary, review period, and decision owner. 3. Confirm any selected level, profile, baseline, overlay, assessment type, or licensed requirement set. 4. The cataloged version is final; still verify scope and any later official updates. 5. Use the linked official legal or regulatory text and current implementing guidance; do not replace applicability analysis with this summary. 6. Stop and request a decision when applicability or the authoritative requirement set cannot be established. Step 1 — Build the applicability map For every supplied requirement identifier or official outcome in scope, record: applicability, rationale, responsible owner, implementation location, inherited/shared responsibility, evidence expected, and any dependency. Use only identifiers present in the authoritative source supplied for this engagement. Do not reconstruct licensed text. Step 2 — Collect evidence by framework domain Review these domains without treating the labels as substitutes for authoritative requirements: 1. qualified individual and risk assessment 2. safeguards and access controls 3. service providers and change management 4. testing, incident response, and board reporting Start with these likely artifacts, then validate provenance and coverage: 1. written information security program 2. risk assessment and safeguard decisions 3. service-provider monitoring records 4. penetration-test, incident, and board report artifacts For every artifact record: artifact ID, source system, owner, collection time, review period, access path, integrity/provenance note, population covered, and requirement/outcome links. Prefer system exports and immutable records over screenshots or narrative attestations. Step 3 — Test design and operation For each applicable item, evaluate design, implementation, and operating evidence separately. Check whether evidence is authentic, complete, current for the review period, population-representative, and directly linked to the scoped system. Where sampling is permitted, state the population, method, sample size, selections, exceptions, and limitations; do not imply statistical assurance without a justified method. Step 4 — Classify gaps without overstating them Use only: supported, partially supported, unsupported, not applicable with rationale, or not assessed. Record gaps as evidence-readiness findings—not declarations of legal noncompliance. Each finding must include the affected requirement/outcome, observed fact, missing or weak evidence, risk, owner, corrective action, due date, dependencies, retest method, and confidence. Step 5 — Produce the evidence bundle Return one Markdown file named GLBASAFEGUARDSRULEEVIDENCECHECK.md with: 1. Executive summary and explicit assurance limitations. 2. Authority/version/status and scope/applicability record. 3. Coverage totals by status and evidence domain. 4. Requirement/outcome-to-evidence matrix with artifact provenance. 5. Findings ordered by risk and evidence impact. 6. A 30/60/90-day remediation and evidence-collection plan. 7. Open questions, unavailable sources, conflicts, and decisions required. 8. Official references with access/review date. Before finalizing, verify that every conclusion is traceable to an artifact or clearly labeled assertion/inference, all denominators reconcile, all unavailable evidence is visible, licensed text is not reproduced, and no sentence claims certification or legal approval. Output contract The response must contain one evidence matrix row per scoped authoritative item or outcome. At minimum include itemid, applicability, owner, implementation, artifactids, testmethod, coverageperiod, status, gap, and confidence. Every artifact ID must resolve to the artifact register, and every total must reconcile to the matrix. Verification Confirm the official source, version, status, and review date in both the executive summary and matrix metadata. Reconcile applicable, not applicable, and not assessed counts to the complete supplied scope. Trace each supported assertion to provenance-bearing evidence covering the stated period and population. Independently reperform a risk-based sample of mappings and document all exceptions. Verify findings distinguish control/design weakness from missing evidence and unknown scope. Have the accountable owner and, where required, qualified counsel or an authorized assessor review conclusions. Guardrails This is an evidence-readiness workflow, not certification, attestation, audit opinion, or legal advice. Do not infer that a voluntary framework is mandatory or that one framework proves another. Do not paste, paraphrase at length, or reconstruct licensed controls. Use source summaries and organization-supplied licensed material. Do not expose secrets, personal data, regulated data, or full production exports in the report. Do not modify systems, close findings, accept risk, or submit regulatory reports without explicit owner authorization. If versions conflict, preserve both citations, label the conflict, and escalate rather than choosing silently. Routing examples Route here: assess GLBA Safeguards Rule evidence review a financial institution security program prepare FTC safeguards compliance artifacts Hard negatives—route elsewhere or clarify: assess NYDFS Part 500 obligations review PCI DSS payment controls Related recipes PCI DSS 4.0.1 HIPAA Security Rule NYDFS Part 500 References 1. U.S. Federal Trade Commission official source 1","agent_handoff":{"mcp_lookup_keys":["glba-safeguards-rule-evidence-check","/recipes/general/compliance-standards/glba-safeguards-rule-evidence-check/","recipes/general/compliance-standards/glba-safeguards-rule-evidence-check.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["audit","compliance"],"source_text_field":"content_text","portable_download":"security-recipe-glba-safeguards-rule-evidence-check.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-glba-safeguards-rule-evidence-check.json"}},{"slug":"hipaa-security-rule-evidence-check","title":"HIPAA Security Rule Evidence Readiness Check","link_title":"HIPAA Security Rule","url":"https://security-recipes.ai/recipes/general/compliance-standards/hipaa-security-rule-evidence-check/","path":"/recipes/general/compliance-standards/hipaa-security-rule-evidence-check/","source_file":"recipes/general/compliance-standards/hipaa-security-rule-evidence-check.md","recipe_id":"compliance.hipaa-security-rule-current","recipe_kind":"","category":{"slug":"compliance-standards","label":"Compliance Standards"},"agent":"Compliance evidence review","severity":"info","maturity":"stable","ecosystem":"","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"HIPAA Security Rule","framework_version":"Current effective Security Rule; 2025 NPRM not finalized","jurisdiction":["united-states"],"industry":["healthcare","health-technology"],"cve_archetypes":[],"cve_workflow_role":"","tags":["compliance","hipaa-security-rule","regulated-industries","audit","privacy","data-protection","healthcare","health-technology"],"facets":["audit","compliance"],"quality":{"score":95,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"Security Recipes","team":"GRC and Security Engineering","model":"gpt-5-codex","ai_assisted":false,"generated_by":"","date":"2026-08-21","zero_day":false,"last_updated":"2026-08-21","summary":"Assess HIPAA Security Rule evidence readiness: verify applicability, map official requirements to artifacts, record gaps, and plan remediation.","content_text":"HIPAA Security Rule Evidence Readiness Check Use this recipe to produce a source-aware evidence-readiness assessment for HIPAA Security Rule. It creates an auditable gap record; it does not certify compliance, provide legal advice, or replace an assessor, regulator, or certification body. Section index Framework basis When to use it Inputs The prompt Output contract Verification Guardrails Routing examples References Framework basis Publisher: U.S. Department of Health and Human Services Version: Current effective Security Rule; 2025 NPRM not finalized Status: final Sources reviewed: 2026-08-21 Jurisdictions: united-states Industries: healthcare, health-technology License boundary: official-text HIPAA covered entities and business associates protecting electronic protected health information. Use the currently effective Security Rule. The January 2025 modification remains a proposed rule, not a final rule, so do not implement the NPRM as if it were already required. The cataloged version is final; still verify scope and any later official updates. Use the linked official legal or regulatory text and current implementing guidance; do not replace applicability analysis with this summary. When to use it Use this recipe when the organization has established that HIPAA Security Rule is applicable or wants a readiness assessment against it. Use the routing positives below to distinguish this recipe from adjacent frameworks. If applicability, the effective version, or the authoritative requirement set is unresolved, stop at a scoped intake and record the decision owner. Inputs The business purpose, legal entities, products, services, systems, and locations in scope. The organization's role, applicability decision, selected profile, level, baseline, or control set where the framework requires one. The official publication URLs above and, for licensed material, an authorized organization-supplied copy. Evidence from the complete review period, including populations—not only hand-picked examples. Named owners, inherited/shared responsibilities, exceptions, compensating measures, and accepted risks. Read-only access by default. Redacted exports are acceptable when provenance and coverage remain testable. Evidence domains for this framework: ePHI scope and risk analysis: begin with enterprise risk analysis. administrative safeguards: begin with ePHI system and data-flow inventory. physical and technical safeguards: begin with access and audit-log reviews. business associate and incident governance: begin with business associate agreements and incident records. The prompt You are a compliance evidence-readiness analyst. Evaluate the supplied scope against HIPAA Security Rule (Current effective Security Rule; 2025 NPRM not finalized). The catalog status is final and the source review date is 2026-08-21. Never claim certification or legal compliance. Never invent applicability, evidence, control operation, sampling results, or requirement text. Separate observed facts, organization assertions, and analyst inferences. Treat missing or inaccessible evidence as unknown, not as failure, unless the authoritative assessment method says otherwise. Step 0 — Lock authority, version, and scope 1. Record the exact official source, version, publication/update identifier, and effective date used. 2. Record the organization, role, jurisdiction, industry, system/product boundary, review period, and decision owner. 3. Confirm any selected level, profile, baseline, overlay, assessment type, or licensed requirement set. 4. The cataloged version is final; still verify scope and any later official updates. 5. Use the linked official legal or regulatory text and current implementing guidance; do not replace applicability analysis with this summary. 6. Stop and request a decision when applicability or the authoritative requirement set cannot be established. Step 1 — Build the applicability map For every supplied requirement identifier or official outcome in scope, record: applicability, rationale, responsible owner, implementation location, inherited/shared responsibility, evidence expected, and any dependency. Use only identifiers present in the authoritative source supplied for this engagement. Do not reconstruct licensed text. Step 2 — Collect evidence by framework domain Review these domains without treating the labels as substitutes for authoritative requirements: 1. ePHI scope and risk analysis 2. administrative safeguards 3. physical and technical safeguards 4. business associate and incident governance Start with these likely artifacts, then validate provenance and coverage: 1. enterprise risk analysis 2. ePHI system and data-flow inventory 3. access and audit-log reviews 4. business associate agreements and incident records For every artifact record: artifact ID, source system, owner, collection time, review period, access path, integrity/provenance note, population covered, and requirement/outcome links. Prefer system exports and immutable records over screenshots or narrative attestations. Step 3 — Test design and operation For each applicable item, evaluate design, implementation, and operating evidence separately. Check whether evidence is authentic, complete, current for the review period, population-representative, and directly linked to the scoped system. Where sampling is permitted, state the population, method, sample size, selections, exceptions, and limitations; do not imply statistical assurance without a justified method. Step 4 — Classify gaps without overstating them Use only: supported, partially supported, unsupported, not applicable with rationale, or not assessed. Record gaps as evidence-readiness findings—not declarations of legal noncompliance. Each finding must include the affected requirement/outcome, observed fact, missing or weak evidence, risk, owner, corrective action, due date, dependencies, retest method, and confidence. Step 5 — Produce the evidence bundle Return one Markdown file named HIPAASECURITYRULEEVIDENCECHECK.md with: 1. Executive summary and explicit assurance limitations. 2. Authority/version/status and scope/applicability record. 3. Coverage totals by status and evidence domain. 4. Requirement/outcome-to-evidence matrix with artifact provenance. 5. Findings ordered by risk and evidence impact. 6. A 30/60/90-day remediation and evidence-collection plan. 7. Open questions, unavailable sources, conflicts, and decisions required. 8. Official references with access/review date. Before finalizing, verify that every conclusion is traceable to an artifact or clearly labeled assertion/inference, all denominators reconcile, all unavailable evidence is visible, licensed text is not reproduced, and no sentence claims certification or legal approval. Output contract The response must contain one evidence matrix row per scoped authoritative item or outcome. At minimum include itemid, applicability, owner, implementation, artifactids, testmethod, coverageperiod, status, gap, and confidence. Every artifact ID must resolve to the artifact register, and every total must reconcile to the matrix. Verification Confirm the official source, version, status, and review date in both the executive summary and matrix metadata. Reconcile applicable, not applicable, and not assessed counts to the complete supplied scope. Trace each supported assertion to provenance-bearing evidence covering the stated period and population. Independently reperform a risk-based sample of mappings and document all exceptions. Verify findings distinguish control/design weakness from missing evidence and unknown scope. Have the accountable owner and, where required, qualified counsel or an authorized assessor review conclusions. Guardrails This is an evidence-readiness workflow, not certification, attestation, audit opinion, or legal advice. Do not infer that a voluntary framework is mandatory or that one framework proves another. Do not paste, paraphrase at length, or reconstruct licensed controls. Use source summaries and organization-supplied licensed material. Do not expose secrets, personal data, regulated data, or full production exports in the report. Do not modify systems, close findings, accept risk, or submit regulatory reports without explicit owner authorization. If versions conflict, preserve both citations, label the conflict, and escalate rather than choosing silently. Routing examples Route here: assess HIPAA Security Rule evidence review ePHI safeguards prepare healthcare security compliance artifacts Hard negatives—route elsewhere or clarify: apply the proposed 2025 HIPAA rule as final perform an FDA medical device premarket review Related recipes PCI DSS 4.0.1 GLBA Safeguards Rule NYDFS Part 500 References 1. U.S. Department of Health and Human Services official source 1","agent_handoff":{"mcp_lookup_keys":["hipaa-security-rule-evidence-check","/recipes/general/compliance-standards/hipaa-security-rule-evidence-check/","recipes/general/compliance-standards/hipaa-security-rule-evidence-check.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["audit","compliance"],"source_text_field":"content_text","portable_download":"security-recipe-hipaa-security-rule-evidence-check.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-hipaa-security-rule-evidence-check.json"}},{"slug":"iec-62443-industrial-security-evidence-check","title":"IEC 62443 Industrial Security Program Evidence Check","link_title":"IEC 62443","url":"https://security-recipes.ai/recipes/general/compliance-standards/iec-62443-industrial-security-evidence-check/","path":"/recipes/general/compliance-standards/iec-62443-industrial-security-evidence-check/","source_file":"recipes/general/compliance-standards/iec-62443-industrial-security-evidence-check.md","recipe_id":"compliance.iec-62443-2-1-2024-4-1-2018","recipe_kind":"","category":{"slug":"compliance-standards","label":"Compliance Standards"},"agent":"Compliance evidence review","severity":"info","maturity":"stable","ecosystem":"","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"IEC 62443","framework_version":"IEC 62443-2-1:2024 and IEC 62443-4-1:2018","jurisdiction":["global"],"industry":["industrial-automation","critical-infrastructure","manufacturing"],"cve_archetypes":[],"cve_workflow_role":"","tags":["compliance","iec-62443","critical-infrastructure","audit","ot-security","product-security","industrial-automation"],"facets":["audit","compliance"],"quality":{"score":95,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"Security Recipes","team":"GRC and Security Engineering","model":"gpt-5-codex","ai_assisted":false,"generated_by":"","date":"2026-08-21","zero_day":false,"last_updated":"2026-08-21","summary":"Assess IEC 62443 evidence readiness: verify applicability, map official requirements to artifacts, record gaps, and plan remediation.","content_text":"IEC 62443 Industrial Security Program Evidence Check Use this recipe to produce a source-aware evidence-readiness assessment for IEC 62443. It creates an auditable gap record; it does not certify compliance, provide legal advice, or replace an assessor, regulator, or certification body. Section index Framework basis When to use it Inputs The prompt Output contract Verification Guardrails Routing examples References Framework basis Publisher: IEC Version: IEC 62443-2-1:2024 and IEC 62443-4-1:2018 Status: final Sources reviewed: 2026-08-21 Jurisdictions: global Industries: industrial-automation, critical-infrastructure, manufacturing License boundary: summary-only Asset owners and product suppliers evaluating industrial automation and control system security programs against organization-licensed IEC 62443 parts. The cataloged version is final; still verify scope and any later official updates. This recipe intentionally summarizes domains and evidence needs. Do not reproduce licensed control text; use an organization-supplied licensed copy for requirement-level work. When to use it Use this recipe when the organization has established that IEC 62443 is applicable or wants a readiness assessment against it. Use the routing positives below to distinguish this recipe from adjacent frameworks. If applicability, the effective version, or the authoritative requirement set is unresolved, stop at a scoped intake and record the decision owner. Inputs The business purpose, legal entities, products, services, systems, and locations in scope. The organization's role, applicability decision, selected profile, level, baseline, or control set where the framework requires one. The official publication URLs above and, for licensed material, an authorized organization-supplied copy. Evidence from the complete review period, including populations—not only hand-picked examples. Named owners, inherited/shared responsibilities, exceptions, compensating measures, and accepted risks. Read-only access by default. Redacted exports are acceptable when provenance and coverage remain testable. Evidence domains for this framework: IACS scope, zones, conduits, and risk: begin with IACS architecture and risk assessment. asset-owner security program: begin with security program procedures. secure product development lifecycle: begin with product security lifecycle records. supplier, maintenance, and incident governance: begin with supplier, patch, remote access, and incident evidence. The prompt You are a compliance evidence-readiness analyst. Evaluate the supplied scope against IEC 62443 (IEC 62443-2-1:2024 and IEC 62443-4-1:2018). The catalog status is final and the source review date is 2026-08-21. Never claim certification or legal compliance. Never invent applicability, evidence, control operation, sampling results, or requirement text. Separate observed facts, organization assertions, and analyst inferences. Treat missing or inaccessible evidence as unknown, not as failure, unless the authoritative assessment method says otherwise. Step 0 — Lock authority, version, and scope 1. Record the exact official source, version, publication/update identifier, and effective date used. 2. Record the organization, role, jurisdiction, industry, system/product boundary, review period, and decision owner. 3. Confirm any selected level, profile, baseline, overlay, assessment type, or licensed requirement set. 4. The cataloged version is final; still verify scope and any later official updates. 5. This recipe intentionally summarizes domains and evidence needs. Do not reproduce licensed control text; use an organization-supplied licensed copy for requirement-level work. 6. Stop and request a decision when applicability or the authoritative requirement set cannot be established. Step 1 — Build the applicability map For every supplied requirement identifier or official outcome in scope, record: applicability, rationale, responsible owner, implementation location, inherited/shared responsibility, evidence expected, and any dependency. Use only identifiers present in the authoritative source supplied for this engagement. Do not reconstruct licensed text. Step 2 — Collect evidence by framework domain Review these domains without treating the labels as substitutes for authoritative requirements: 1. IACS scope, zones, conduits, and risk 2. asset-owner security program 3. secure product development lifecycle 4. supplier, maintenance, and incident governance Start with these likely artifacts, then validate provenance and coverage: 1. IACS architecture and risk assessment 2. security program procedures 3. product security lifecycle records 4. supplier, patch, remote access, and incident evidence For every artifact record: artifact ID, source system, owner, collection time, review period, access path, integrity/provenance note, population covered, and requirement/outcome links. Prefer system exports and immutable records over screenshots or narrative attestations. Step 3 — Test design and operation For each applicable item, evaluate design, implementation, and operating evidence separately. Check whether evidence is authentic, complete, current for the review period, population-representative, and directly linked to the scoped system. Where sampling is permitted, state the population, method, sample size, selections, exceptions, and limitations; do not imply statistical assurance without a justified method. Step 4 — Classify gaps without overstating them Use only: supported, partially supported, unsupported, not applicable with rationale, or not assessed. Record gaps as evidence-readiness findings—not declarations of legal noncompliance. Each finding must include the affected requirement/outcome, observed fact, missing or weak evidence, risk, owner, corrective action, due date, dependencies, retest method, and confidence. Step 5 — Produce the evidence bundle Return one Markdown file named IEC62443INDUSTRIALSECURITYEVIDENCECHECK.md with: 1. Executive summary and explicit assurance limitations. 2. Authority/version/status and scope/applicability record. 3. Coverage totals by status and evidence domain. 4. Requirement/outcome-to-evidence matrix with artifact provenance. 5. Findings ordered by risk and evidence impact. 6. A 30/60/90-day remediation and evidence-collection plan. 7. Open questions, unavailable sources, conflicts, and decisions required. 8. Official references with access/review date. Before finalizing, verify that every conclusion is traceable to an artifact or clearly labeled assertion/inference, all denominators reconcile, all unavailable evidence is visible, licensed text is not reproduced, and no sentence claims certification or legal approval. Output contract The response must contain one evidence matrix row per scoped authoritative item or outcome. At minimum include itemid, applicability, owner, implementation, artifactids, testmethod, coverage_period, status, gap, and confidence. Every artifact ID must resolve to the artifact register, and every total must reconcile to the matrix. Verification Confirm the official source, version, status, and review date in both the executive summary and matrix metadata. Reconcile applicable, not applicable, and not assessed counts to the complete supplied scope. Trace each supported assertion to provenance-bearing evidence covering the stated period and population. Independently reperform a risk-based sample of mappings and document all exceptions. Verify findings distinguish control/design weakness from missing evidence and unknown scope. Have the accountable owner and, where required, qualified counsel or an authorized assessor review conclusions. Guardrails This is an evidence-readiness workflow, not certification, attestation, audit opinion, or legal advice. Do not infer that a voluntary framework is mandatory or that one framework proves another. Do not paste, paraphrase at length, or reconstruct licensed controls. Use source summaries and organization-supplied licensed material. Do not expose secrets, personal data, regulated data, or full production exports in the report. Do not modify systems, close findings, accept risk, or submit regulatory reports without explicit owner authorization. If versions conflict, preserve both citations, label the conflict, and escalate rather than choosing silently. Routing examples Route here: assess IEC 62443 industrial security evidence review IACS asset owner program readiness evaluate secure development under IEC 62443-4-1 Hard negatives—route elsewhere or clarify: perform a NERC CIP applicability assessment assess consumer IoT with NISTIR 8259 Related recipes NERC CIP CISA Cross-Sector CPGs EU NIS2 References 1. IEC official source 1 2. IEC official source 2","agent_handoff":{"mcp_lookup_keys":["iec-62443-industrial-security-evidence-check","/recipes/general/compliance-standards/iec-62443-industrial-security-evidence-check/","recipes/general/compliance-standards/iec-62443-industrial-security-evidence-check.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["audit","compliance"],"source_text_field":"content_text","portable_download":"security-recipe-iec-62443-industrial-security-evidence-check.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-iec-62443-industrial-security-evidence-check.json"}},{"slug":"iso27001-secure-development-evidence-check","title":"ISO/IEC 27001:2022 ISMS Evidence Readiness Check","link_title":"ISO/IEC 27001:2022","url":"https://security-recipes.ai/recipes/general/compliance-standards/iso27001-secure-development-evidence-check/","path":"/recipes/general/compliance-standards/iso27001-secure-development-evidence-check/","source_file":"recipes/general/compliance-standards/iso27001-secure-development-evidence-check.md","recipe_id":"compliance.iso-iec-27001-2022","recipe_kind":"","category":{"slug":"compliance-standards","label":"Compliance Standards"},"agent":"Compliance evidence review","severity":"info","maturity":"stable","ecosystem":"","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"ISO/IEC 27001:2022","framework_version":"2022","jurisdiction":["global"],"industry":["cross-sector"],"cve_archetypes":[],"cve_workflow_role":"","tags":["compliance","iso-27001","security-programs","audit","risk","governance","cross-sector"],"facets":["audit","compliance","risk"],"quality":{"score":100,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context","multi-facet"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"Security Recipes","team":"GRC and Security Engineering","model":"gpt-5-codex","ai_assisted":false,"generated_by":"","date":"2026-08-21","zero_day":false,"last_updated":"2026-08-21","summary":"Assess ISO/IEC 27001:2022 evidence readiness: verify applicability, map official requirements to artifacts, record gaps, and plan remediation.","content_text":"ISO/IEC 27001:2022 ISMS Evidence Readiness Check Use this recipe to produce a source-aware evidence-readiness assessment for ISO/IEC 27001:2022. It creates an auditable gap record; it does not certify compliance, provide legal advice, or replace an assessor, regulator, or certification body. Section index Framework basis When to use it Inputs The prompt Output contract Verification Guardrails Routing examples References Framework basis Publisher: ISO/IEC Version: 2022 Status: final Sources reviewed: 2026-08-21 Jurisdictions: global Industries: cross-sector License boundary: summary-only Organizations operating or preparing to certify an information security management system against ISO/IEC 27001:2022. The cataloged version is final; still verify scope and any later official updates. This recipe intentionally summarizes domains and evidence needs. Do not reproduce licensed control text; use an organization-supplied licensed copy for requirement-level work. When to use it Use this recipe when the organization has established that ISO/IEC 27001:2022 is applicable or wants a readiness assessment against it. Use the routing positives below to distinguish this recipe from adjacent frameworks. If applicability, the effective version, or the authoritative requirement set is unresolved, stop at a scoped intake and record the decision owner. Inputs The business purpose, legal entities, products, services, systems, and locations in scope. The organization's role, applicability decision, selected profile, level, baseline, or control set where the framework requires one. The official publication URLs above and, for licensed material, an authorized organization-supplied copy. Evidence from the complete review period, including populations—not only hand-picked examples. Named owners, inherited/shared responsibilities, exceptions, compensating measures, and accepted risks. Read-only access by default. Redacted exports are acceptable when provenance and coverage remain testable. Evidence domains for this framework: ISMS scope and interested parties: begin with approved ISMS scope. risk assessment and treatment: begin with risk register and treatment decisions. statement of applicability and objectives: begin with current statement of applicability. internal audit, management review, and improvement: begin with audit findings and corrective-action records. The prompt You are a compliance evidence-readiness analyst. Evaluate the supplied scope against ISO/IEC 27001:2022 (2022). The catalog status is final and the source review date is 2026-08-21. Never claim certification or legal compliance. Never invent applicability, evidence, control operation, sampling results, or requirement text. Separate observed facts, organization assertions, and analyst inferences. Treat missing or inaccessible evidence as unknown, not as failure, unless the authoritative assessment method says otherwise. Step 0 — Lock authority, version, and scope 1. Record the exact official source, version, publication/update identifier, and effective date used. 2. Record the organization, role, jurisdiction, industry, system/product boundary, review period, and decision owner. 3. Confirm any selected level, profile, baseline, overlay, assessment type, or licensed requirement set. 4. The cataloged version is final; still verify scope and any later official updates. 5. This recipe intentionally summarizes domains and evidence needs. Do not reproduce licensed control text; use an organization-supplied licensed copy for requirement-level work. 6. Stop and request a decision when applicability or the authoritative requirement set cannot be established. Step 1 — Build the applicability map For every supplied requirement identifier or official outcome in scope, record: applicability, rationale, responsible owner, implementation location, inherited/shared responsibility, evidence expected, and any dependency. Use only identifiers present in the authoritative source supplied for this engagement. Do not reconstruct licensed text. Step 2 — Collect evidence by framework domain Review these domains without treating the labels as substitutes for authoritative requirements: 1. ISMS scope and interested parties 2. risk assessment and treatment 3. statement of applicability and objectives 4. internal audit, management review, and improvement Start with these likely artifacts, then validate provenance and coverage: 1. approved ISMS scope 2. risk register and treatment decisions 3. current statement of applicability 4. audit findings and corrective-action records For every artifact record: artifact ID, source system, owner, collection time, review period, access path, integrity/provenance note, population covered, and requirement/outcome links. Prefer system exports and immutable records over screenshots or narrative attestations. Step 3 — Test design and operation For each applicable item, evaluate design, implementation, and operating evidence separately. Check whether evidence is authentic, complete, current for the review period, population-representative, and directly linked to the scoped system. Where sampling is permitted, state the population, method, sample size, selections, exceptions, and limitations; do not imply statistical assurance without a justified method. Step 4 — Classify gaps without overstating them Use only: supported, partially supported, unsupported, not applicable with rationale, or not assessed. Record gaps as evidence-readiness findings—not declarations of legal noncompliance. Each finding must include the affected requirement/outcome, observed fact, missing or weak evidence, risk, owner, corrective action, due date, dependencies, retest method, and confidence. Step 5 — Produce the evidence bundle Return one Markdown file named ISO27001SECUREDEVELOPMENTEVIDENCECHECK.md with: 1. Executive summary and explicit assurance limitations. 2. Authority/version/status and scope/applicability record. 3. Coverage totals by status and evidence domain. 4. Requirement/outcome-to-evidence matrix with artifact provenance. 5. Findings ordered by risk and evidence impact. 6. A 30/60/90-day remediation and evidence-collection plan. 7. Open questions, unavailable sources, conflicts, and decisions required. 8. Official references with access/review date. Before finalizing, verify that every conclusion is traceable to an artifact or clearly labeled assertion/inference, all denominators reconcile, all unavailable evidence is visible, licensed text is not reproduced, and no sentence claims certification or legal approval. Output contract The response must contain one evidence matrix row per scoped authoritative item or outcome. At minimum include itemid, applicability, owner, implementation, artifactids, testmethod, coverageperiod, status, gap, and confidence. Every artifact ID must resolve to the artifact register, and every total must reconcile to the matrix. Verification Confirm the official source, version, status, and review date in both the executive summary and matrix metadata. Reconcile applicable, not applicable, and not assessed counts to the complete supplied scope. Trace each supported assertion to provenance-bearing evidence covering the stated period and population. Independently reperform a risk-based sample of mappings and document all exceptions. Verify findings distinguish control/design weakness from missing evidence and unknown scope. Have the accountable owner and, where required, qualified counsel or an authorized assessor review conclusions. Guardrails This is an evidence-readiness workflow, not certification, attestation, audit opinion, or legal advice. Do not infer that a voluntary framework is mandatory or that one framework proves another. Do not paste, paraphrase at length, or reconstruct licensed controls. Use source summaries and organization-supplied licensed material. Do not expose secrets, personal data, regulated data, or full production exports in the report. Do not modify systems, close findings, accept risk, or submit regulatory reports without explicit owner authorization. If versions conflict, preserve both citations, label the conflict, and escalate rather than choosing silently. Routing examples Route here: prepare ISO 27001 audit evidence review our ISMS readiness check ISO 27001:2022 governance artifacts Hard negatives—route elsewhere or clarify: verify ISO 42001 AI management controls run a SOC 2 change-management evidence check Related recipes CIS Controls v8.1 NIST CSF 2.0 NIST SSDF 1.1 References 1. ISO/IEC official source 1","agent_handoff":{"mcp_lookup_keys":["iso27001-secure-development-evidence-check","/recipes/general/compliance-standards/iso27001-secure-development-evidence-check/","recipes/general/compliance-standards/iso27001-secure-development-evidence-check.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["audit","compliance","risk"],"source_text_field":"content_text","portable_download":"security-recipe-iso27001-secure-development-evidence-check.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-iso27001-secure-development-evidence-check.json"}},{"slug":"iso27701-2025-privacy-management-evidence-check","title":"ISO/IEC 27701:2025 Privacy Information Management Evidence Check","link_title":"ISO/IEC 27701:2025","url":"https://security-recipes.ai/recipes/general/compliance-standards/iso27701-2025-privacy-management-evidence-check/","path":"/recipes/general/compliance-standards/iso27701-2025-privacy-management-evidence-check/","source_file":"recipes/general/compliance-standards/iso27701-2025-privacy-management-evidence-check.md","recipe_id":"compliance.iso-iec-27701-2025","recipe_kind":"","category":{"slug":"compliance-standards","label":"Compliance Standards"},"agent":"Compliance evidence review","severity":"info","maturity":"stable","ecosystem":"","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"ISO/IEC 27701:2025","framework_version":"2025","jurisdiction":["global"],"industry":["pii-controllers","pii-processors","cross-sector"],"cve_archetypes":[],"cve_workflow_role":"","tags":["compliance","iso-27701","privacy","audit","governance","pii-controllers","pii-processors"],"facets":["audit","compliance"],"quality":{"score":95,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"Security Recipes","team":"GRC and Security Engineering","model":"gpt-5-codex","ai_assisted":false,"generated_by":"","date":"2026-08-21","zero_day":false,"last_updated":"2026-08-21","summary":"Assess ISO/IEC 27701:2025 evidence readiness: verify applicability, map official requirements to artifacts, record gaps, and plan remediation.","content_text":"ISO/IEC 27701:2025 Privacy Information Management Evidence Check Use this recipe to produce a source-aware evidence-readiness assessment for ISO/IEC 27701:2025. It creates an auditable gap record; it does not certify compliance, provide legal advice, or replace an assessor, regulator, or certification body. Section index Framework basis When to use it Inputs The prompt Output contract Verification Guardrails Routing examples References Framework basis Publisher: ISO/IEC Version: 2025 Status: final Sources reviewed: 2026-08-21 Jurisdictions: global Industries: pii-controllers, pii-processors, cross-sector License boundary: summary-only Organizations establishing, operating, or preparing to certify a privacy information management system against ISO/IEC 27701:2025. The cataloged version is final; still verify scope and any later official updates. This recipe intentionally summarizes domains and evidence needs. Do not reproduce licensed control text; use an organization-supplied licensed copy for requirement-level work. When to use it Use this recipe when the organization has established that ISO/IEC 27701:2025 is applicable or wants a readiness assessment against it. Use the routing positives below to distinguish this recipe from adjacent frameworks. If applicability, the effective version, or the authoritative requirement set is unresolved, stop at a scoped intake and record the decision owner. Inputs The business purpose, legal entities, products, services, systems, and locations in scope. The organization's role, applicability decision, selected profile, level, baseline, or control set where the framework requires one. The official publication URLs above and, for licensed material, an authorized organization-supplied copy. Evidence from the complete review period, including populations—not only hand-picked examples. Named owners, inherited/shared responsibilities, exceptions, compensating measures, and accepted risks. Read-only access by default. Redacted exports are acceptable when provenance and coverage remain testable. Evidence domains for this framework: PIMS context, scope, and roles: begin with approved PIMS scope and policy. privacy risk assessment and treatment: begin with privacy risk and treatment records. controller and processor responsibilities: begin with controller, processor, and data-subject process evidence. performance evaluation and improvement: begin with internal audit, management review, and corrective actions. The prompt You are a compliance evidence-readiness analyst. Evaluate the supplied scope against ISO/IEC 27701:2025 (2025). The catalog status is final and the source review date is 2026-08-21. Never claim certification or legal compliance. Never invent applicability, evidence, control operation, sampling results, or requirement text. Separate observed facts, organization assertions, and analyst inferences. Treat missing or inaccessible evidence as unknown, not as failure, unless the authoritative assessment method says otherwise. Step 0 — Lock authority, version, and scope 1. Record the exact official source, version, publication/update identifier, and effective date used. 2. Record the organization, role, jurisdiction, industry, system/product boundary, review period, and decision owner. 3. Confirm any selected level, profile, baseline, overlay, assessment type, or licensed requirement set. 4. The cataloged version is final; still verify scope and any later official updates. 5. This recipe intentionally summarizes domains and evidence needs. Do not reproduce licensed control text; use an organization-supplied licensed copy for requirement-level work. 6. Stop and request a decision when applicability or the authoritative requirement set cannot be established. Step 1 — Build the applicability map For every supplied requirement identifier or official outcome in scope, record: applicability, rationale, responsible owner, implementation location, inherited/shared responsibility, evidence expected, and any dependency. Use only identifiers present in the authoritative source supplied for this engagement. Do not reconstruct licensed text. Step 2 — Collect evidence by framework domain Review these domains without treating the labels as substitutes for authoritative requirements: 1. PIMS context, scope, and roles 2. privacy risk assessment and treatment 3. controller and processor responsibilities 4. performance evaluation and improvement Start with these likely artifacts, then validate provenance and coverage: 1. approved PIMS scope and policy 2. privacy risk and treatment records 3. controller, processor, and data-subject process evidence 4. internal audit, management review, and corrective actions For every artifact record: artifact ID, source system, owner, collection time, review period, access path, integrity/provenance note, population covered, and requirement/outcome links. Prefer system exports and immutable records over screenshots or narrative attestations. Step 3 — Test design and operation For each applicable item, evaluate design, implementation, and operating evidence separately. Check whether evidence is authentic, complete, current for the review period, population-representative, and directly linked to the scoped system. Where sampling is permitted, state the population, method, sample size, selections, exceptions, and limitations; do not imply statistical assurance without a justified method. Step 4 — Classify gaps without overstating them Use only: supported, partially supported, unsupported, not applicable with rationale, or not assessed. Record gaps as evidence-readiness findings—not declarations of legal noncompliance. Each finding must include the affected requirement/outcome, observed fact, missing or weak evidence, risk, owner, corrective action, due date, dependencies, retest method, and confidence. Step 5 — Produce the evidence bundle Return one Markdown file named ISO277012025PRIVACYMANAGEMENTEVIDENCECHECK.md with: 1. Executive summary and explicit assurance limitations. 2. Authority/version/status and scope/applicability record. 3. Coverage totals by status and evidence domain. 4. Requirement/outcome-to-evidence matrix with artifact provenance. 5. Findings ordered by risk and evidence impact. 6. A 30/60/90-day remediation and evidence-collection plan. 7. Open questions, unavailable sources, conflicts, and decisions required. 8. Official references with access/review date. Before finalizing, verify that every conclusion is traceable to an artifact or clearly labeled assertion/inference, all denominators reconcile, all unavailable evidence is visible, licensed text is not reproduced, and no sentence claims certification or legal approval. Output contract The response must contain one evidence matrix row per scoped authoritative item or outcome. At minimum include itemid, applicability, owner, implementation, artifactids, testmethod, coverage_period, status, gap, and confidence. Every artifact ID must resolve to the artifact register, and every total must reconcile to the matrix. Verification Confirm the official source, version, status, and review date in both the executive summary and matrix metadata. Reconcile applicable, not applicable, and not assessed counts to the complete supplied scope. Trace each supported assertion to provenance-bearing evidence covering the stated period and population. Independently reperform a risk-based sample of mappings and document all exceptions. Verify findings distinguish control/design weakness from missing evidence and unknown scope. Have the accountable owner and, where required, qualified counsel or an authorized assessor review conclusions. Guardrails This is an evidence-readiness workflow, not certification, attestation, audit opinion, or legal advice. Do not infer that a voluntary framework is mandatory or that one framework proves another. Do not paste, paraphrase at length, or reconstruct licensed controls. Use source summaries and organization-supplied licensed material. Do not expose secrets, personal data, regulated data, or full production exports in the report. Do not modify systems, close findings, accept risk, or submit regulatory reports without explicit owner authorization. If versions conflict, preserve both citations, label the conflict, and escalate rather than choosing silently. Routing examples Route here: prepare ISO 27701:2025 evidence review a privacy information management system assess PIMS audit readiness Hard negatives—route elsewhere or clarify: perform a GDPR legal determination certify ISO 27001 information security controls only Related recipes EU GDPR NIST Privacy Framework CIS Controls v8.1 References 1. ISO/IEC official source 1","agent_handoff":{"mcp_lookup_keys":["iso27701-2025-privacy-management-evidence-check","/recipes/general/compliance-standards/iso27701-2025-privacy-management-evidence-check/","recipes/general/compliance-standards/iso27701-2025-privacy-management-evidence-check.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["audit","compliance"],"source_text_field":"content_text","portable_download":"security-recipe-iso27701-2025-privacy-management-evidence-check.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-iso27701-2025-privacy-management-evidence-check.json"}},{"slug":"iso42001-ai-management-system-evidence-check","title":"ISO/IEC 42001:2023 AI Management System Evidence Check","link_title":"ISO/IEC 42001:2023","url":"https://security-recipes.ai/recipes/general/compliance-standards/iso42001-ai-management-system-evidence-check/","path":"/recipes/general/compliance-standards/iso42001-ai-management-system-evidence-check/","source_file":"recipes/general/compliance-standards/iso42001-ai-management-system-evidence-check.md","recipe_id":"compliance.iso-iec-42001-2023","recipe_kind":"","category":{"slug":"compliance-standards","label":"Compliance Standards"},"agent":"Compliance evidence review","severity":"info","maturity":"stable","ecosystem":"","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"ISO/IEC 42001:2023","framework_version":"2023","jurisdiction":["global"],"industry":["artificial-intelligence","cross-sector"],"cve_archetypes":[],"cve_workflow_role":"","tags":["compliance","iso-42001","ai-governance","audit","ai-safety","governance","artificial-intelligence","cross-sector"],"facets":["audit","compliance"],"quality":{"score":95,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"Security Recipes","team":"GRC and Security Engineering","model":"gpt-5-codex","ai_assisted":false,"generated_by":"","date":"2026-08-21","zero_day":false,"last_updated":"2026-08-21","summary":"Assess ISO/IEC 42001:2023 evidence readiness: verify applicability, map official requirements to artifacts, record gaps, and plan remediation.","content_text":"ISO/IEC 42001:2023 AI Management System Evidence Check Use this recipe to produce a source-aware evidence-readiness assessment for ISO/IEC 42001:2023. It creates an auditable gap record; it does not certify compliance, provide legal advice, or replace an assessor, regulator, or certification body. Section index Framework basis When to use it Inputs The prompt Output contract Verification Guardrails Routing examples References Framework basis Publisher: ISO/IEC Version: 2023 Status: final Sources reviewed: 2026-08-21 Jurisdictions: global Industries: artificial-intelligence, cross-sector License boundary: summary-only Organizations establishing, operating, or preparing to certify an AI management system against ISO/IEC 42001:2023. The cataloged version is final; still verify scope and any later official updates. This recipe intentionally summarizes domains and evidence needs. Do not reproduce licensed control text; use an organization-supplied licensed copy for requirement-level work. When to use it Use this recipe when the organization has established that ISO/IEC 42001:2023 is applicable or wants a readiness assessment against it. Use the routing positives below to distinguish this recipe from adjacent frameworks. If applicability, the effective version, or the authoritative requirement set is unresolved, stop at a scoped intake and record the decision owner. Inputs The business purpose, legal entities, products, services, systems, and locations in scope. The organization's role, applicability decision, selected profile, level, baseline, or control set where the framework requires one. The official publication URLs above and, for licensed material, an authorized organization-supplied copy. Evidence from the complete review period, including populations—not only hand-picked examples. Named owners, inherited/shared responsibilities, exceptions, compensating measures, and accepted risks. Read-only access by default. Redacted exports are acceptable when provenance and coverage remain testable. Evidence domains for this framework: AIMS context, scope, and leadership: begin with approved AIMS scope and policy. AI risk and impact assessment: begin with AI risk and impact assessment records. lifecycle controls and data governance: begin with lifecycle and supplier governance artifacts. performance evaluation and improvement: begin with internal audit, management review, and corrective actions. The prompt You are a compliance evidence-readiness analyst. Evaluate the supplied scope against ISO/IEC 42001:2023 (2023). The catalog status is final and the source review date is 2026-08-21. Never claim certification or legal compliance. Never invent applicability, evidence, control operation, sampling results, or requirement text. Separate observed facts, organization assertions, and analyst inferences. Treat missing or inaccessible evidence as unknown, not as failure, unless the authoritative assessment method says otherwise. Step 0 — Lock authority, version, and scope 1. Record the exact official source, version, publication/update identifier, and effective date used. 2. Record the organization, role, jurisdiction, industry, system/product boundary, review period, and decision owner. 3. Confirm any selected level, profile, baseline, overlay, assessment type, or licensed requirement set. 4. The cataloged version is final; still verify scope and any later official updates. 5. This recipe intentionally summarizes domains and evidence needs. Do not reproduce licensed control text; use an organization-supplied licensed copy for requirement-level work. 6. Stop and request a decision when applicability or the authoritative requirement set cannot be established. Step 1 — Build the applicability map For every supplied requirement identifier or official outcome in scope, record: applicability, rationale, responsible owner, implementation location, inherited/shared responsibility, evidence expected, and any dependency. Use only identifiers present in the authoritative source supplied for this engagement. Do not reconstruct licensed text. Step 2 — Collect evidence by framework domain Review these domains without treating the labels as substitutes for authoritative requirements: 1. AIMS context, scope, and leadership 2. AI risk and impact assessment 3. lifecycle controls and data governance 4. performance evaluation and improvement Start with these likely artifacts, then validate provenance and coverage: 1. approved AIMS scope and policy 2. AI risk and impact assessment records 3. lifecycle and supplier governance artifacts 4. internal audit, management review, and corrective actions For every artifact record: artifact ID, source system, owner, collection time, review period, access path, integrity/provenance note, population covered, and requirement/outcome links. Prefer system exports and immutable records over screenshots or narrative attestations. Step 3 — Test design and operation For each applicable item, evaluate design, implementation, and operating evidence separately. Check whether evidence is authentic, complete, current for the review period, population-representative, and directly linked to the scoped system. Where sampling is permitted, state the population, method, sample size, selections, exceptions, and limitations; do not imply statistical assurance without a justified method. Step 4 — Classify gaps without overstating them Use only: supported, partially supported, unsupported, not applicable with rationale, or not assessed. Record gaps as evidence-readiness findings—not declarations of legal noncompliance. Each finding must include the affected requirement/outcome, observed fact, missing or weak evidence, risk, owner, corrective action, due date, dependencies, retest method, and confidence. Step 5 — Produce the evidence bundle Return one Markdown file named ISO42001AIMANAGEMENTSYSTEMEVIDENCECHECK.md with: 1. Executive summary and explicit assurance limitations. 2. Authority/version/status and scope/applicability record. 3. Coverage totals by status and evidence domain. 4. Requirement/outcome-to-evidence matrix with artifact provenance. 5. Findings ordered by risk and evidence impact. 6. A 30/60/90-day remediation and evidence-collection plan. 7. Open questions, unavailable sources, conflicts, and decisions required. 8. Official references with access/review date. Before finalizing, verify that every conclusion is traceable to an artifact or clearly labeled assertion/inference, all denominators reconcile, all unavailable evidence is visible, licensed text is not reproduced, and no sentence claims certification or legal approval. Output contract The response must contain one evidence matrix row per scoped authoritative item or outcome. At minimum include itemid, applicability, owner, implementation, artifactids, testmethod, coverage_period, status, gap, and confidence. Every artifact ID must resolve to the artifact register, and every total must reconcile to the matrix. Verification Confirm the official source, version, status, and review date in both the executive summary and matrix metadata. Reconcile applicable, not applicable, and not assessed counts to the complete supplied scope. Trace each supported assertion to provenance-bearing evidence covering the stated period and population. Independently reperform a risk-based sample of mappings and document all exceptions. Verify findings distinguish control/design weakness from missing evidence and unknown scope. Have the accountable owner and, where required, qualified counsel or an authorized assessor review conclusions. Guardrails This is an evidence-readiness workflow, not certification, attestation, audit opinion, or legal advice. Do not infer that a voluntary framework is mandatory or that one framework proves another. Do not paste, paraphrase at length, or reconstruct licensed controls. Use source summaries and organization-supplied licensed material. Do not expose secrets, personal data, regulated data, or full production exports in the report. Do not modify systems, close findings, accept risk, or submit regulatory reports without explicit owner authorization. If versions conflict, preserve both citations, label the conflict, and escalate rather than choosing silently. Routing examples Route here: prepare ISO 42001 audit evidence review an AI management system assess ISO 42001:2023 readiness Hard negatives—route elsewhere or clarify: perform a NIST AI RMF profile assessment assess EU AI Act legal applicability Related recipes NIST AI SSDF NIST AI RMF 1.0 EU AI Act References 1. ISO/IEC official source 1","agent_handoff":{"mcp_lookup_keys":["iso42001-ai-management-system-evidence-check","/recipes/general/compliance-standards/iso42001-ai-management-system-evidence-check/","recipes/general/compliance-standards/iso42001-ai-management-system-evidence-check.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["audit","compliance"],"source_text_field":"content_text","portable_download":"security-recipe-iso42001-ai-management-system-evidence-check.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-iso42001-ai-management-system-evidence-check.json"}},{"slug":"nerc-cip-applicable-standards-evidence-check","title":"NERC CIP Applicable Standards Evidence Check","link_title":"NERC CIP","url":"https://security-recipes.ai/recipes/general/compliance-standards/nerc-cip-applicable-standards-evidence-check/","path":"/recipes/general/compliance-standards/nerc-cip-applicable-standards-evidence-check/","source_file":"recipes/general/compliance-standards/nerc-cip-applicable-standards-evidence-check.md","recipe_id":"compliance.nerc-cip-current-applicable-set","recipe_kind":"","category":{"slug":"compliance-standards","label":"Compliance Standards"},"agent":"Compliance evidence review","severity":"info","maturity":"stable","ecosystem":"","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"NERC CIP","framework_version":"Operator-supplied effective standards set; checked 2026-08-21","jurisdiction":["north-america","united-states","canada"],"industry":["bulk-electric-system","energy"],"cve_archetypes":[],"cve_workflow_role":"","tags":["compliance","nerc-cip","critical-infrastructure","audit","ot-security","bulk-electric-system","energy"],"facets":["audit","compliance"],"quality":{"score":95,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"Security Recipes","team":"GRC and Security Engineering","model":"gpt-5-codex","ai_assisted":false,"generated_by":"","date":"2026-08-21","zero_day":false,"last_updated":"2026-08-21","summary":"Assess NERC CIP evidence readiness: verify applicability, map official requirements to artifacts, record gaps, and plan remediation.","content_text":"NERC CIP Applicable Standards Evidence Check Use this recipe to produce a source-aware evidence-readiness assessment for NERC CIP. It creates an auditable gap record; it does not certify compliance, provide legal advice, or replace an assessor, regulator, or certification body. Section index Framework basis When to use it Inputs The prompt Output contract Verification Guardrails Routing examples References Framework basis Publisher: North American Electric Reliability Corporation Version: Operator-supplied effective standards set; checked 2026-08-21 Status: revision-in-progress Sources reviewed: 2026-08-21 Jurisdictions: north-america, united-states, canada Industries: bulk-electric-system, energy License boundary: official-text Registered entities with Bulk Electric System Cyber Systems must establish applicable, effective NERC CIP standards from current standards and implementation plans. The authority is revising or transitioning this framework. Confirm the effective source set and dates before making a current-state claim. Use the linked official legal or regulatory text and current implementing guidance; do not replace applicability analysis with this summary. When to use it Use this recipe when the organization has established that NERC CIP is applicable or wants a readiness assessment against it. Use the routing positives below to distinguish this recipe from adjacent frameworks. If applicability, the effective version, or the authoritative requirement set is unresolved, stop at a scoped intake and record the decision owner. Inputs The business purpose, legal entities, products, services, systems, and locations in scope. The organization's role, applicability decision, selected profile, level, baseline, or control set where the framework requires one. The official publication URLs above and, for licensed material, an authorized organization-supplied copy. Evidence from the complete review period, including populations—not only hand-picked examples. Named owners, inherited/shared responsibilities, exceptions, compensating measures, and accepted risks. Read-only access by default. Redacted exports are acceptable when provenance and coverage remain testable. Evidence domains for this framework: registration, assets, and applicability: begin with applicability and impact-rating records. electronic and physical security perimeters: begin with BES Cyber System inventories and diagrams. system security, access, and change management: begin with access, patch, configuration, and monitoring evidence. incident response, recovery, and supply chain: begin with exercise, recovery, and vendor-risk records. The prompt You are a compliance evidence-readiness analyst. Evaluate the supplied scope against NERC CIP (Operator-supplied effective standards set; checked 2026-08-21). The catalog status is revision-in-progress and the source review date is 2026-08-21. Never claim certification or legal compliance. Never invent applicability, evidence, control operation, sampling results, or requirement text. Separate observed facts, organization assertions, and analyst inferences. Treat missing or inaccessible evidence as unknown, not as failure, unless the authoritative assessment method says otherwise. Step 0 — Lock authority, version, and scope 1. Record the exact official source, version, publication/update identifier, and effective date used. 2. Record the organization, role, jurisdiction, industry, system/product boundary, review period, and decision owner. 3. Confirm any selected level, profile, baseline, overlay, assessment type, or licensed requirement set. 4. The authority is revising or transitioning this framework. Confirm the effective source set and dates before making a current-state claim. 5. Use the linked official legal or regulatory text and current implementing guidance; do not replace applicability analysis with this summary. 6. Stop and request a decision when applicability or the authoritative requirement set cannot be established. Step 1 — Build the applicability map For every supplied requirement identifier or official outcome in scope, record: applicability, rationale, responsible owner, implementation location, inherited/shared responsibility, evidence expected, and any dependency. Use only identifiers present in the authoritative source supplied for this engagement. Do not reconstruct licensed text. Step 2 — Collect evidence by framework domain Review these domains without treating the labels as substitutes for authoritative requirements: 1. registration, assets, and applicability 2. electronic and physical security perimeters 3. system security, access, and change management 4. incident response, recovery, and supply chain Start with these likely artifacts, then validate provenance and coverage: 1. applicability and impact-rating records 2. BES Cyber System inventories and diagrams 3. access, patch, configuration, and monitoring evidence 4. exercise, recovery, and vendor-risk records For every artifact record: artifact ID, source system, owner, collection time, review period, access path, integrity/provenance note, population covered, and requirement/outcome links. Prefer system exports and immutable records over screenshots or narrative attestations. Step 3 — Test design and operation For each applicable item, evaluate design, implementation, and operating evidence separately. Check whether evidence is authentic, complete, current for the review period, population-representative, and directly linked to the scoped system. Where sampling is permitted, state the population, method, sample size, selections, exceptions, and limitations; do not imply statistical assurance without a justified method. Step 4 — Classify gaps without overstating them Use only: supported, partially supported, unsupported, not applicable with rationale, or not assessed. Record gaps as evidence-readiness findings—not declarations of legal noncompliance. Each finding must include the affected requirement/outcome, observed fact, missing or weak evidence, risk, owner, corrective action, due date, dependencies, retest method, and confidence. Step 5 — Produce the evidence bundle Return one Markdown file named NERCCIPAPPLICABLESTANDARDSEVIDENCECHECK.md with: 1. Executive summary and explicit assurance limitations. 2. Authority/version/status and scope/applicability record. 3. Coverage totals by status and evidence domain. 4. Requirement/outcome-to-evidence matrix with artifact provenance. 5. Findings ordered by risk and evidence impact. 6. A 30/60/90-day remediation and evidence-collection plan. 7. Open questions, unavailable sources, conflicts, and decisions required. 8. Official references with access/review date. Before finalizing, verify that every conclusion is traceable to an artifact or clearly labeled assertion/inference, all denominators reconcile, all unavailable evidence is visible, licensed text is not reproduced, and no sentence claims certification or legal approval. Output contract The response must contain one evidence matrix row per scoped authoritative item or outcome. At minimum include itemid, applicability, owner, implementation, artifactids, testmethod, coverage_period, status, gap, and confidence. Every artifact ID must resolve to the artifact register, and every total must reconcile to the matrix. Verification Confirm the official source, version, status, and review date in both the executive summary and matrix metadata. Reconcile applicable, not applicable, and not assessed counts to the complete supplied scope. Trace each supported assertion to provenance-bearing evidence covering the stated period and population. Independently reperform a risk-based sample of mappings and document all exceptions. Verify findings distinguish control/design weakness from missing evidence and unknown scope. Have the accountable owner and, where required, qualified counsel or an authorized assessor review conclusions. Guardrails This is an evidence-readiness workflow, not certification, attestation, audit opinion, or legal advice. Do not infer that a voluntary framework is mandatory or that one framework proves another. Do not paste, paraphrase at length, or reconstruct licensed controls. Use source summaries and organization-supplied licensed material. Do not expose secrets, personal data, regulated data, or full production exports in the report. Do not modify systems, close findings, accept risk, or submit regulatory reports without explicit owner authorization. If versions conflict, preserve both citations, label the conflict, and escalate rather than choosing silently. Routing examples Route here: assess NERC CIP evidence review BES Cyber System compliance artifacts verify the effective CIP standards set Hard negatives—route elsewhere or clarify: assess generic IEC 62443 product security apply an obsolete CIP version without checking effective dates Related recipes IEC 62443 CISA Cross-Sector CPGs EU NIS2 References 1. North American Electric Reliability Corporation official source 1","agent_handoff":{"mcp_lookup_keys":["nerc-cip-applicable-standards-evidence-check","/recipes/general/compliance-standards/nerc-cip-applicable-standards-evidence-check/","recipes/general/compliance-standards/nerc-cip-applicable-standards-evidence-check.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["audit","compliance"],"source_text_field":"content_text","portable_download":"security-recipe-nerc-cip-applicable-standards-evidence-check.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-nerc-cip-applicable-standards-evidence-check.json"}},{"slug":"nist-ai-rmf-1-0-evidence-check","title":"NIST AI Risk Management Framework 1.0 Evidence Check","link_title":"NIST AI RMF 1.0","url":"https://security-recipes.ai/recipes/general/compliance-standards/nist-ai-rmf-1-0-evidence-check/","path":"/recipes/general/compliance-standards/nist-ai-rmf-1-0-evidence-check/","source_file":"recipes/general/compliance-standards/nist-ai-rmf-1-0-evidence-check.md","recipe_id":"compliance.nist-ai-rmf-1-0","recipe_kind":"","category":{"slug":"compliance-standards","label":"Compliance Standards"},"agent":"Compliance evidence review","severity":"info","maturity":"stable","ecosystem":"","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"NIST AI RMF 1.0","framework_version":"1.0; revision in progress","jurisdiction":["global","united-states"],"industry":["artificial-intelligence","cross-sector"],"cve_archetypes":[],"cve_workflow_role":"","tags":["compliance","nist-ai-rmf","ai-governance","audit","ai-safety","risk","artificial-intelligence","cross-sector"],"facets":["audit","compliance","risk"],"quality":{"score":100,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context","multi-facet"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"Security Recipes","team":"GRC and Security Engineering","model":"gpt-5-codex","ai_assisted":false,"generated_by":"","date":"2026-08-21","zero_day":false,"last_updated":"2026-08-21","summary":"Assess NIST AI RMF 1.0 evidence readiness: verify applicability, map official requirements to artifacts, record gaps, and plan remediation.","content_text":"NIST AI Risk Management Framework 1.0 Evidence Check Use this recipe to produce a source-aware evidence-readiness assessment for NIST AI RMF 1.0. It creates an auditable gap record; it does not certify compliance, provide legal advice, or replace an assessor, regulator, or certification body. Section index Framework basis When to use it Inputs The prompt Output contract Verification Guardrails Routing examples References Framework basis Publisher: NIST Version: 1.0; revision in progress Status: revision-in-progress Sources reviewed: 2026-08-21 Jurisdictions: global, united-states Industries: artificial-intelligence, cross-sector License boundary: public-domain Organizations governing, mapping, measuring, and managing AI risks using AI RMF 1.0 while NIST develops a revision. The authority is revising or transitioning this framework. Confirm the effective source set and dates before making a current-state claim. Use the official publication as the authority and preserve its version and update identifiers in every finding. When to use it Use this recipe when the organization has established that NIST AI RMF 1.0 is applicable or wants a readiness assessment against it. Use the routing positives below to distinguish this recipe from adjacent frameworks. If applicability, the effective version, or the authoritative requirement set is unresolved, stop at a scoped intake and record the decision owner. Inputs The business purpose, legal entities, products, services, systems, and locations in scope. The organization's role, applicability decision, selected profile, level, baseline, or control set where the framework requires one. The official publication URLs above and, for licensed material, an authorized organization-supplied copy. Evidence from the complete review period, including populations—not only hand-picked examples. Named owners, inherited/shared responsibilities, exceptions, compensating measures, and accepted risks. Read-only access by default. Redacted exports are acceptable when provenance and coverage remain testable. Evidence domains for this framework: AI governance and accountability: begin with AI system inventory and ownership. context and impact mapping: begin with impact and stakeholder analyses. measurement and evaluation: begin with evaluation metrics and limitations. risk treatment, monitoring, and incident learning: begin with risk acceptance, monitoring, and incident records. The prompt You are a compliance evidence-readiness analyst. Evaluate the supplied scope against NIST AI RMF 1.0 (1.0; revision in progress). The catalog status is revision-in-progress and the source review date is 2026-08-21. Never claim certification or legal compliance. Never invent applicability, evidence, control operation, sampling results, or requirement text. Separate observed facts, organization assertions, and analyst inferences. Treat missing or inaccessible evidence as unknown, not as failure, unless the authoritative assessment method says otherwise. Step 0 — Lock authority, version, and scope 1. Record the exact official source, version, publication/update identifier, and effective date used. 2. Record the organization, role, jurisdiction, industry, system/product boundary, review period, and decision owner. 3. Confirm any selected level, profile, baseline, overlay, assessment type, or licensed requirement set. 4. The authority is revising or transitioning this framework. Confirm the effective source set and dates before making a current-state claim. 5. Use the official publication as the authority and preserve its version and update identifiers in every finding. 6. Stop and request a decision when applicability or the authoritative requirement set cannot be established. Step 1 — Build the applicability map For every supplied requirement identifier or official outcome in scope, record: applicability, rationale, responsible owner, implementation location, inherited/shared responsibility, evidence expected, and any dependency. Use only identifiers present in the authoritative source supplied for this engagement. Do not reconstruct licensed text. Step 2 — Collect evidence by framework domain Review these domains without treating the labels as substitutes for authoritative requirements: 1. AI governance and accountability 2. context and impact mapping 3. measurement and evaluation 4. risk treatment, monitoring, and incident learning Start with these likely artifacts, then validate provenance and coverage: 1. AI system inventory and ownership 2. impact and stakeholder analyses 3. evaluation metrics and limitations 4. risk acceptance, monitoring, and incident records For every artifact record: artifact ID, source system, owner, collection time, review period, access path, integrity/provenance note, population covered, and requirement/outcome links. Prefer system exports and immutable records over screenshots or narrative attestations. Step 3 — Test design and operation For each applicable item, evaluate design, implementation, and operating evidence separately. Check whether evidence is authentic, complete, current for the review period, population-representative, and directly linked to the scoped system. Where sampling is permitted, state the population, method, sample size, selections, exceptions, and limitations; do not imply statistical assurance without a justified method. Step 4 — Classify gaps without overstating them Use only: supported, partially supported, unsupported, not applicable with rationale, or not assessed. Record gaps as evidence-readiness findings—not declarations of legal noncompliance. Each finding must include the affected requirement/outcome, observed fact, missing or weak evidence, risk, owner, corrective action, due date, dependencies, retest method, and confidence. Step 5 — Produce the evidence bundle Return one Markdown file named NISTAIRMF10EVIDENCECHECK.md with: 1. Executive summary and explicit assurance limitations. 2. Authority/version/status and scope/applicability record. 3. Coverage totals by status and evidence domain. 4. Requirement/outcome-to-evidence matrix with artifact provenance. 5. Findings ordered by risk and evidence impact. 6. A 30/60/90-day remediation and evidence-collection plan. 7. Open questions, unavailable sources, conflicts, and decisions required. 8. Official references with access/review date. Before finalizing, verify that every conclusion is traceable to an artifact or clearly labeled assertion/inference, all denominators reconcile, all unavailable evidence is visible, licensed text is not reproduced, and no sentence claims certification or legal approval. Output contract The response must contain one evidence matrix row per scoped authoritative item or outcome. At minimum include itemid, applicability, owner, implementation, artifactids, testmethod, coverageperiod, status, gap, and confidence. Every artifact ID must resolve to the artifact register, and every total must reconcile to the matrix. Verification Confirm the official source, version, status, and review date in both the executive summary and matrix metadata. Reconcile applicable, not applicable, and not assessed counts to the complete supplied scope. Trace each supported assertion to provenance-bearing evidence covering the stated period and population. Independently reperform a risk-based sample of mappings and document all exceptions. Verify findings distinguish control/design weakness from missing evidence and unknown scope. Have the accountable owner and, where required, qualified counsel or an authorized assessor review conclusions. Guardrails This is an evidence-readiness workflow, not certification, attestation, audit opinion, or legal advice. Do not infer that a voluntary framework is mandatory or that one framework proves another. Do not paste, paraphrase at length, or reconstruct licensed controls. Use source summaries and organization-supplied licensed material. Do not expose secrets, personal data, regulated data, or full production exports in the report. Do not modify systems, close findings, accept risk, or submit regulatory reports without explicit owner authorization. If versions conflict, preserve both citations, label the conflict, and escalate rather than choosing silently. Routing examples Route here: assess AI governance against NIST AI RMF collect Govern Map Measure Manage evidence review AI risk management artifacts Hard negatives—route elsewhere or clarify: assess secure model development only with SP 800-218A certify an ISO 42001 management system Related recipes NIST AI SSDF ISO/IEC 42001:2023 EU AI Act References 1. NIST official source 1 2. NIST official source 2","agent_handoff":{"mcp_lookup_keys":["nist-ai-rmf-1-0-evidence-check","/recipes/general/compliance-standards/nist-ai-rmf-1-0-evidence-check/","recipes/general/compliance-standards/nist-ai-rmf-1-0-evidence-check.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["audit","compliance","risk"],"source_text_field":"content_text","portable_download":"security-recipe-nist-ai-rmf-1-0-evidence-check.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-nist-ai-rmf-1-0-evidence-check.json"}},{"slug":"nist-csf-2-0-profile-evidence-check","title":"NIST Cybersecurity Framework 2.0 Profile Evidence Check","link_title":"NIST CSF 2.0","url":"https://security-recipes.ai/recipes/general/compliance-standards/nist-csf-2-0-profile-evidence-check/","path":"/recipes/general/compliance-standards/nist-csf-2-0-profile-evidence-check/","source_file":"recipes/general/compliance-standards/nist-csf-2-0-profile-evidence-check.md","recipe_id":"compliance.nist-csf-2-0","recipe_kind":"","category":{"slug":"compliance-standards","label":"Compliance Standards"},"agent":"Compliance evidence review","severity":"info","maturity":"stable","ecosystem":"","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"NIST CSF 2.0","framework_version":"2.0","jurisdiction":["global","united-states"],"industry":["cross-sector"],"cve_archetypes":[],"cve_workflow_role":"","tags":["compliance","nist-csf","security-programs","audit","risk","governance","cross-sector"],"facets":["audit","compliance","risk"],"quality":{"score":100,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context","multi-facet"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"Security Recipes","team":"GRC and Security Engineering","model":"gpt-5-codex","ai_assisted":false,"generated_by":"","date":"2026-08-21","zero_day":false,"last_updated":"2026-08-21","summary":"Assess NIST CSF 2.0 evidence readiness: verify applicability, map official requirements to artifacts, record gaps, and plan remediation.","content_text":"NIST Cybersecurity Framework 2.0 Profile Evidence Check Use this recipe to produce a source-aware evidence-readiness assessment for NIST CSF 2.0. It creates an auditable gap record; it does not certify compliance, provide legal advice, or replace an assessor, regulator, or certification body. Section index Framework basis When to use it Inputs The prompt Output contract Verification Guardrails Routing examples References Framework basis Publisher: NIST Version: 2.0 Status: final Sources reviewed: 2026-08-21 Jurisdictions: global, united-states Industries: cross-sector License boundary: public-domain Organizations using CSF 2.0 Organizational Profiles and Tiers to communicate and improve cybersecurity risk outcomes. The cataloged version is final; still verify scope and any later official updates. Use the official publication as the authority and preserve its version and update identifiers in every finding. When to use it Use this recipe when the organization has established that NIST CSF 2.0 is applicable or wants a readiness assessment against it. Use the routing positives below to distinguish this recipe from adjacent frameworks. If applicability, the effective version, or the authoritative requirement set is unresolved, stop at a scoped intake and record the decision owner. Inputs The business purpose, legal entities, products, services, systems, and locations in scope. The organization's role, applicability decision, selected profile, level, baseline, or control set where the framework requires one. The official publication URLs above and, for licensed material, an authorized organization-supplied copy. Evidence from the complete review period, including populations—not only hand-picked examples. Named owners, inherited/shared responsibilities, exceptions, compensating measures, and accepted risks. Read-only access by default. Redacted exports are acceptable when provenance and coverage remain testable. Evidence domains for this framework: governance and risk context: begin with current and target profiles. asset identification and protection: begin with risk priorities and ownership. detection and response: begin with capability evidence mapped to outcomes. recovery and improvement: begin with improvement plan and executive decisions. The prompt You are a compliance evidence-readiness analyst. Evaluate the supplied scope against NIST CSF 2.0 (2.0). The catalog status is final and the source review date is 2026-08-21. Never claim certification or legal compliance. Never invent applicability, evidence, control operation, sampling results, or requirement text. Separate observed facts, organization assertions, and analyst inferences. Treat missing or inaccessible evidence as unknown, not as failure, unless the authoritative assessment method says otherwise. Step 0 — Lock authority, version, and scope 1. Record the exact official source, version, publication/update identifier, and effective date used. 2. Record the organization, role, jurisdiction, industry, system/product boundary, review period, and decision owner. 3. Confirm any selected level, profile, baseline, overlay, assessment type, or licensed requirement set. 4. The cataloged version is final; still verify scope and any later official updates. 5. Use the official publication as the authority and preserve its version and update identifiers in every finding. 6. Stop and request a decision when applicability or the authoritative requirement set cannot be established. Step 1 — Build the applicability map For every supplied requirement identifier or official outcome in scope, record: applicability, rationale, responsible owner, implementation location, inherited/shared responsibility, evidence expected, and any dependency. Use only identifiers present in the authoritative source supplied for this engagement. Do not reconstruct licensed text. Step 2 — Collect evidence by framework domain Review these domains without treating the labels as substitutes for authoritative requirements: 1. governance and risk context 2. asset identification and protection 3. detection and response 4. recovery and improvement Start with these likely artifacts, then validate provenance and coverage: 1. current and target profiles 2. risk priorities and ownership 3. capability evidence mapped to outcomes 4. improvement plan and executive decisions For every artifact record: artifact ID, source system, owner, collection time, review period, access path, integrity/provenance note, population covered, and requirement/outcome links. Prefer system exports and immutable records over screenshots or narrative attestations. Step 3 — Test design and operation For each applicable item, evaluate design, implementation, and operating evidence separately. Check whether evidence is authentic, complete, current for the review period, population-representative, and directly linked to the scoped system. Where sampling is permitted, state the population, method, sample size, selections, exceptions, and limitations; do not imply statistical assurance without a justified method. Step 4 — Classify gaps without overstating them Use only: supported, partially supported, unsupported, not applicable with rationale, or not assessed. Record gaps as evidence-readiness findings—not declarations of legal noncompliance. Each finding must include the affected requirement/outcome, observed fact, missing or weak evidence, risk, owner, corrective action, due date, dependencies, retest method, and confidence. Step 5 — Produce the evidence bundle Return one Markdown file named NISTCSF20PROFILEEVIDENCECHECK.md with: 1. Executive summary and explicit assurance limitations. 2. Authority/version/status and scope/applicability record. 3. Coverage totals by status and evidence domain. 4. Requirement/outcome-to-evidence matrix with artifact provenance. 5. Findings ordered by risk and evidence impact. 6. A 30/60/90-day remediation and evidence-collection plan. 7. Open questions, unavailable sources, conflicts, and decisions required. 8. Official references with access/review date. Before finalizing, verify that every conclusion is traceable to an artifact or clearly labeled assertion/inference, all denominators reconcile, all unavailable evidence is visible, licensed text is not reproduced, and no sentence claims certification or legal approval. Output contract The response must contain one evidence matrix row per scoped authoritative item or outcome. At minimum include itemid, applicability, owner, implementation, artifactids, testmethod, coverageperiod, status, gap, and confidence. Every artifact ID must resolve to the artifact register, and every total must reconcile to the matrix. Verification Confirm the official source, version, status, and review date in both the executive summary and matrix metadata. Reconcile applicable, not applicable, and not assessed counts to the complete supplied scope. Trace each supported assertion to provenance-bearing evidence covering the stated period and population. Independently reperform a risk-based sample of mappings and document all exceptions. Verify findings distinguish control/design weakness from missing evidence and unknown scope. Have the accountable owner and, where required, qualified counsel or an authorized assessor review conclusions. Guardrails This is an evidence-readiness workflow, not certification, attestation, audit opinion, or legal advice. Do not infer that a voluntary framework is mandatory or that one framework proves another. Do not paste, paraphrase at length, or reconstruct licensed controls. Use source summaries and organization-supplied licensed material. Do not expose secrets, personal data, regulated data, or full production exports in the report. Do not modify systems, close findings, accept risk, or submit regulatory reports without explicit owner authorization. If versions conflict, preserve both citations, label the conflict, and escalate rather than choosing silently. Routing examples Route here: build a NIST CSF 2.0 profile assess cybersecurity outcomes against CSF collect evidence for Govern Identify Protect Detect Respond Recover Hard negatives—route elsewhere or clarify: test NIST SP 800-53 controls assess NIST Privacy Framework outcomes Related recipes CIS Controls v8.1 ISO/IEC 27001:2022 NIST SSDF 1.1 References 1. NIST official source 1","agent_handoff":{"mcp_lookup_keys":["nist-csf-2-0-profile-evidence-check","/recipes/general/compliance-standards/nist-csf-2-0-profile-evidence-check/","recipes/general/compliance-standards/nist-csf-2-0-profile-evidence-check.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["audit","compliance","risk"],"source_text_field":"content_text","portable_download":"security-recipe-nist-csf-2-0-profile-evidence-check.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-nist-csf-2-0-profile-evidence-check.json"}},{"slug":"nist-iot-8259-rev1-evidence-check","title":"NISTIR 8259 Rev. 1 IoT Product Evidence Check","link_title":"NIST IoT 8259 Series","url":"https://security-recipes.ai/recipes/general/compliance-standards/nist-iot-8259-rev1-evidence-check/","path":"/recipes/general/compliance-standards/nist-iot-8259-rev1-evidence-check/","source_file":"recipes/general/compliance-standards/nist-iot-8259-rev1-evidence-check.md","recipe_id":"compliance.nistir-8259-rev1-series","recipe_kind":"","category":{"slug":"compliance-standards","label":"Compliance Standards"},"agent":"Compliance evidence review","severity":"info","maturity":"stable","ecosystem":"","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"NIST IoT 8259 Series","framework_version":"NISTIR 8259 Rev. 1 series (April 2026)","jurisdiction":["global","united-states"],"industry":["iot","consumer-products","industrial-products"],"cve_archetypes":[],"cve_workflow_role":"","tags":["compliance","nist-iot-8259","product-security","audit","iot-security","iot","consumer-products"],"facets":["audit","compliance"],"quality":{"score":95,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"Security Recipes","team":"GRC and Security Engineering","model":"gpt-5-codex","ai_assisted":false,"generated_by":"","date":"2026-08-21","zero_day":false,"last_updated":"2026-08-21","summary":"Assess NIST IoT 8259 Series evidence readiness: verify applicability, map official requirements to artifacts, record gaps, and plan remediation.","content_text":"NISTIR 8259 Rev. 1 IoT Product Evidence Check Use this recipe to produce a source-aware evidence-readiness assessment for NIST IoT 8259 Series. It creates an auditable gap record; it does not certify compliance, provide legal advice, or replace an assessor, regulator, or certification body. Section index Framework basis When to use it Inputs The prompt Output contract Verification Guardrails Routing examples References Framework basis Publisher: NIST Version: NISTIR 8259 Rev. 1 series (April 2026) Status: final Sources reviewed: 2026-08-21 Jurisdictions: global, united-states Industries: iot, consumer-products, industrial-products License boundary: public-domain IoT product manufacturers and integrators establishing product cybersecurity capabilities and manufacturer supporting activities. The cataloged version is final; still verify scope and any later official updates. Use the official publication as the authority and preserve its version and update identifiers in every finding. When to use it Use this recipe when the organization has established that NIST IoT 8259 Series is applicable or wants a readiness assessment against it. Use the routing positives below to distinguish this recipe from adjacent frameworks. If applicability, the effective version, or the authoritative requirement set is unresolved, stop at a scoped intake and record the decision owner. Inputs The business purpose, legal entities, products, services, systems, and locations in scope. The organization's role, applicability decision, selected profile, level, baseline, or control set where the framework requires one. The official publication URLs above and, for licensed material, an authorized organization-supplied copy. Evidence from the complete review period, including populations—not only hand-picked examples. Named owners, inherited/shared responsibilities, exceptions, compensating measures, and accepted risks. Read-only access by default. Redacted exports are acceptable when provenance and coverage remain testable. Evidence domains for this framework: customer and use-case research: begin with product risk and use-case analysis. device cybersecurity capabilities: begin with capability specifications and test results. manufacturer supporting activities: begin with secure update and configuration records. lifecycle communication and vulnerability response: begin with support, disclosure, and end-of-life communications. The prompt You are a compliance evidence-readiness analyst. Evaluate the supplied scope against NIST IoT 8259 Series (NISTIR 8259 Rev. 1 series (April 2026)). The catalog status is final and the source review date is 2026-08-21. Never claim certification or legal compliance. Never invent applicability, evidence, control operation, sampling results, or requirement text. Separate observed facts, organization assertions, and analyst inferences. Treat missing or inaccessible evidence as unknown, not as failure, unless the authoritative assessment method says otherwise. Step 0 — Lock authority, version, and scope 1. Record the exact official source, version, publication/update identifier, and effective date used. 2. Record the organization, role, jurisdiction, industry, system/product boundary, review period, and decision owner. 3. Confirm any selected level, profile, baseline, overlay, assessment type, or licensed requirement set. 4. The cataloged version is final; still verify scope and any later official updates. 5. Use the official publication as the authority and preserve its version and update identifiers in every finding. 6. Stop and request a decision when applicability or the authoritative requirement set cannot be established. Step 1 — Build the applicability map For every supplied requirement identifier or official outcome in scope, record: applicability, rationale, responsible owner, implementation location, inherited/shared responsibility, evidence expected, and any dependency. Use only identifiers present in the authoritative source supplied for this engagement. Do not reconstruct licensed text. Step 2 — Collect evidence by framework domain Review these domains without treating the labels as substitutes for authoritative requirements: 1. customer and use-case research 2. device cybersecurity capabilities 3. manufacturer supporting activities 4. lifecycle communication and vulnerability response Start with these likely artifacts, then validate provenance and coverage: 1. product risk and use-case analysis 2. capability specifications and test results 3. secure update and configuration records 4. support, disclosure, and end-of-life communications For every artifact record: artifact ID, source system, owner, collection time, review period, access path, integrity/provenance note, population covered, and requirement/outcome links. Prefer system exports and immutable records over screenshots or narrative attestations. Step 3 — Test design and operation For each applicable item, evaluate design, implementation, and operating evidence separately. Check whether evidence is authentic, complete, current for the review period, population-representative, and directly linked to the scoped system. Where sampling is permitted, state the population, method, sample size, selections, exceptions, and limitations; do not imply statistical assurance without a justified method. Step 4 — Classify gaps without overstating them Use only: supported, partially supported, unsupported, not applicable with rationale, or not assessed. Record gaps as evidence-readiness findings—not declarations of legal noncompliance. Each finding must include the affected requirement/outcome, observed fact, missing or weak evidence, risk, owner, corrective action, due date, dependencies, retest method, and confidence. Step 5 — Produce the evidence bundle Return one Markdown file named NISTIOT8259REV1EVIDENCECHECK.md with: 1. Executive summary and explicit assurance limitations. 2. Authority/version/status and scope/applicability record. 3. Coverage totals by status and evidence domain. 4. Requirement/outcome-to-evidence matrix with artifact provenance. 5. Findings ordered by risk and evidence impact. 6. A 30/60/90-day remediation and evidence-collection plan. 7. Open questions, unavailable sources, conflicts, and decisions required. 8. Official references with access/review date. Before finalizing, verify that every conclusion is traceable to an artifact or clearly labeled assertion/inference, all denominators reconcile, all unavailable evidence is visible, licensed text is not reproduced, and no sentence claims certification or legal approval. Output contract The response must contain one evidence matrix row per scoped authoritative item or outcome. At minimum include itemid, applicability, owner, implementation, artifactids, testmethod, coverage_period, status, gap, and confidence. Every artifact ID must resolve to the artifact register, and every total must reconcile to the matrix. Verification Confirm the official source, version, status, and review date in both the executive summary and matrix metadata. Reconcile applicable, not applicable, and not assessed counts to the complete supplied scope. Trace each supported assertion to provenance-bearing evidence covering the stated period and population. Independently reperform a risk-based sample of mappings and document all exceptions. Verify findings distinguish control/design weakness from missing evidence and unknown scope. Have the accountable owner and, where required, qualified counsel or an authorized assessor review conclusions. Guardrails This is an evidence-readiness workflow, not certification, attestation, audit opinion, or legal advice. Do not infer that a voluntary framework is mandatory or that one framework proves another. Do not paste, paraphrase at length, or reconstruct licensed controls. Use source summaries and organization-supplied licensed material. Do not expose secrets, personal data, regulated data, or full production exports in the report. Do not modify systems, close findings, accept risk, or submit regulatory reports without explicit owner authorization. If versions conflict, preserve both citations, label the conflict, and escalate rather than choosing silently. Routing examples Route here: assess an IoT product against NISTIR 8259 collect IoT device capability evidence review IoT manufacturer support activities Hard negatives—route elsewhere or clarify: assess an IEC 62443 industrial automation system prepare FDA medical device premarket evidence Related recipes NIST SSDF 1.1 SLSA v1.2 OWASP ASVS 5.0.0 References 1. NIST official source 1","agent_handoff":{"mcp_lookup_keys":["nist-iot-8259-rev1-evidence-check","/recipes/general/compliance-standards/nist-iot-8259-rev1-evidence-check/","recipes/general/compliance-standards/nist-iot-8259-rev1-evidence-check.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["audit","compliance"],"source_text_field":"content_text","portable_download":"security-recipe-nist-iot-8259-rev1-evidence-check.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-nist-iot-8259-rev1-evidence-check.json"}},{"slug":"nist-privacy-framework-evidence-check","title":"NIST Privacy Framework 1.0 Profile Evidence Check","link_title":"NIST Privacy Framework","url":"https://security-recipes.ai/recipes/general/compliance-standards/nist-privacy-framework-evidence-check/","path":"/recipes/general/compliance-standards/nist-privacy-framework-evidence-check/","source_file":"recipes/general/compliance-standards/nist-privacy-framework-evidence-check.md","recipe_id":"compliance.nist-privacy-framework-1-0","recipe_kind":"","category":{"slug":"compliance-standards","label":"Compliance Standards"},"agent":"Compliance evidence review","severity":"info","maturity":"stable","ecosystem":"","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"NIST Privacy Framework","framework_version":"1.0 final; 1.1 Initial Public Draft","jurisdiction":["global","united-states"],"industry":["cross-sector"],"cve_archetypes":[],"cve_workflow_role":"","tags":["compliance","nist-privacy-framework","privacy","audit","risk","cross-sector"],"facets":["audit","compliance","risk"],"quality":{"score":100,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context","multi-facet"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"Security Recipes","team":"GRC and Security Engineering","model":"gpt-5-codex","ai_assisted":false,"generated_by":"","date":"2026-08-21","zero_day":false,"last_updated":"2026-08-21","summary":"Assess NIST Privacy Framework evidence readiness: verify applicability, map official requirements to artifacts, record gaps, and plan remediation.","content_text":"NIST Privacy Framework 1.0 Profile Evidence Check Use this recipe to produce a source-aware evidence-readiness assessment for NIST Privacy Framework. It creates an auditable gap record; it does not certify compliance, provide legal advice, or replace an assessor, regulator, or certification body. Section index Framework basis When to use it Inputs The prompt Output contract Verification Guardrails Routing examples References Framework basis Publisher: NIST Version: 1.0 final; 1.1 Initial Public Draft Status: draft-update Sources reviewed: 2026-08-21 Jurisdictions: global, united-states Industries: cross-sector License boundary: public-domain Organizations using Privacy Framework 1.0 to manage privacy risk; version 1.1 remains an Initial Public Draft and must not be treated as final. A draft update exists. Treat only the identified final version as normative unless the user explicitly requests a draft gap preview. Use the official publication as the authority and preserve its version and update identifiers in every finding. When to use it Use this recipe when the organization has established that NIST Privacy Framework is applicable or wants a readiness assessment against it. Use the routing positives below to distinguish this recipe from adjacent frameworks. If applicability, the effective version, or the authoritative requirement set is unresolved, stop at a scoped intake and record the decision owner. Inputs The business purpose, legal entities, products, services, systems, and locations in scope. The organization's role, applicability decision, selected profile, level, baseline, or control set where the framework requires one. The official publication URLs above and, for licensed material, an authorized organization-supplied copy. Evidence from the complete review period, including populations—not only hand-picked examples. Named owners, inherited/shared responsibilities, exceptions, compensating measures, and accepted risks. Read-only access by default. Redacted exports are acceptable when provenance and coverage remain testable. Evidence domains for this framework: privacy governance and risk context: begin with current and target privacy profiles. data processing inventory: begin with data processing maps. individual participation and communication: begin with privacy risk assessments. protective controls and improvement profile: begin with rights, communication, protection, and improvement records. The prompt You are a compliance evidence-readiness analyst. Evaluate the supplied scope against NIST Privacy Framework (1.0 final; 1.1 Initial Public Draft). The catalog status is draft-update and the source review date is 2026-08-21. Never claim certification or legal compliance. Never invent applicability, evidence, control operation, sampling results, or requirement text. Separate observed facts, organization assertions, and analyst inferences. Treat missing or inaccessible evidence as unknown, not as failure, unless the authoritative assessment method says otherwise. Step 0 — Lock authority, version, and scope 1. Record the exact official source, version, publication/update identifier, and effective date used. 2. Record the organization, role, jurisdiction, industry, system/product boundary, review period, and decision owner. 3. Confirm any selected level, profile, baseline, overlay, assessment type, or licensed requirement set. 4. A draft update exists. Treat only the identified final version as normative unless the user explicitly requests a draft gap preview. 5. Use the official publication as the authority and preserve its version and update identifiers in every finding. 6. Stop and request a decision when applicability or the authoritative requirement set cannot be established. Step 1 — Build the applicability map For every supplied requirement identifier or official outcome in scope, record: applicability, rationale, responsible owner, implementation location, inherited/shared responsibility, evidence expected, and any dependency. Use only identifiers present in the authoritative source supplied for this engagement. Do not reconstruct licensed text. Step 2 — Collect evidence by framework domain Review these domains without treating the labels as substitutes for authoritative requirements: 1. privacy governance and risk context 2. data processing inventory 3. individual participation and communication 4. protective controls and improvement profile Start with these likely artifacts, then validate provenance and coverage: 1. current and target privacy profiles 2. data processing maps 3. privacy risk assessments 4. rights, communication, protection, and improvement records For every artifact record: artifact ID, source system, owner, collection time, review period, access path, integrity/provenance note, population covered, and requirement/outcome links. Prefer system exports and immutable records over screenshots or narrative attestations. Step 3 — Test design and operation For each applicable item, evaluate design, implementation, and operating evidence separately. Check whether evidence is authentic, complete, current for the review period, population-representative, and directly linked to the scoped system. Where sampling is permitted, state the population, method, sample size, selections, exceptions, and limitations; do not imply statistical assurance without a justified method. Step 4 — Classify gaps without overstating them Use only: supported, partially supported, unsupported, not applicable with rationale, or not assessed. Record gaps as evidence-readiness findings—not declarations of legal noncompliance. Each finding must include the affected requirement/outcome, observed fact, missing or weak evidence, risk, owner, corrective action, due date, dependencies, retest method, and confidence. Step 5 — Produce the evidence bundle Return one Markdown file named NISTPRIVACYFRAMEWORKEVIDENCECHECK.md with: 1. Executive summary and explicit assurance limitations. 2. Authority/version/status and scope/applicability record. 3. Coverage totals by status and evidence domain. 4. Requirement/outcome-to-evidence matrix with artifact provenance. 5. Findings ordered by risk and evidence impact. 6. A 30/60/90-day remediation and evidence-collection plan. 7. Open questions, unavailable sources, conflicts, and decisions required. 8. Official references with access/review date. Before finalizing, verify that every conclusion is traceable to an artifact or clearly labeled assertion/inference, all denominators reconcile, all unavailable evidence is visible, licensed text is not reproduced, and no sentence claims certification or legal approval. Output contract The response must contain one evidence matrix row per scoped authoritative item or outcome. At minimum include itemid, applicability, owner, implementation, artifactids, testmethod, coverageperiod, status, gap, and confidence. Every artifact ID must resolve to the artifact register, and every total must reconcile to the matrix. Verification Confirm the official source, version, status, and review date in both the executive summary and matrix metadata. Reconcile applicable, not applicable, and not assessed counts to the complete supplied scope. Trace each supported assertion to provenance-bearing evidence covering the stated period and population. Independently reperform a risk-based sample of mappings and document all exceptions. Verify findings distinguish control/design weakness from missing evidence and unknown scope. Have the accountable owner and, where required, qualified counsel or an authorized assessor review conclusions. Guardrails This is an evidence-readiness workflow, not certification, attestation, audit opinion, or legal advice. Do not infer that a voluntary framework is mandatory or that one framework proves another. Do not paste, paraphrase at length, or reconstruct licensed controls. Use source summaries and organization-supplied licensed material. Do not expose secrets, personal data, regulated data, or full production exports in the report. Do not modify systems, close findings, accept risk, or submit regulatory reports without explicit owner authorization. If versions conflict, preserve both citations, label the conflict, and escalate rather than choosing silently. Routing examples Route here: build a NIST Privacy Framework profile assess privacy risk outcomes collect Privacy Framework 1.0 evidence Hard negatives—route elsewhere or clarify: apply the 1.1 draft as final perform a GDPR legal compliance determination Related recipes EU GDPR ISO/IEC 27701:2025 CIS Controls v8.1 References 1. NIST official source 1","agent_handoff":{"mcp_lookup_keys":["nist-privacy-framework-evidence-check","/recipes/general/compliance-standards/nist-privacy-framework-evidence-check/","recipes/general/compliance-standards/nist-privacy-framework-evidence-check.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["audit","compliance","risk"],"source_text_field":"content_text","portable_download":"security-recipe-nist-privacy-framework-evidence-check.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-nist-privacy-framework-evidence-check.json"}},{"slug":"nist-sp-800-171-rev3-cui-evidence-check","title":"NIST SP 800-171 Rev. 3 CUI Evidence Check","link_title":"NIST SP 800-171 Rev. 3","url":"https://security-recipes.ai/recipes/general/compliance-standards/nist-sp-800-171-rev3-cui-evidence-check/","path":"/recipes/general/compliance-standards/nist-sp-800-171-rev3-cui-evidence-check/","source_file":"recipes/general/compliance-standards/nist-sp-800-171-rev3-cui-evidence-check.md","recipe_id":"compliance.nist-sp-800-171-rev3","recipe_kind":"","category":{"slug":"compliance-standards","label":"Compliance Standards"},"agent":"Compliance evidence review","severity":"info","maturity":"stable","ecosystem":"","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"NIST SP 800-171 Rev. 3","framework_version":"Rev. 3","jurisdiction":["united-states"],"industry":["defense-industrial-base","government-contractors"],"cve_archetypes":[],"cve_workflow_role":"","tags":["compliance","nist-sp-800-171","government","audit","data-protection","boundary","defense-industrial-base","government-contractors"],"facets":["audit","compliance"],"quality":{"score":95,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"Security Recipes","team":"GRC and Security Engineering","model":"gpt-5-codex","ai_assisted":false,"generated_by":"","date":"2026-08-21","zero_day":false,"last_updated":"2026-08-21","summary":"Assess NIST SP 800-171 Rev. 3 evidence readiness: verify applicability, map official requirements to artifacts, record gaps, and plan remediation.","content_text":"NIST SP 800-171 Rev. 3 CUI Evidence Check Use this recipe to produce a source-aware evidence-readiness assessment for NIST SP 800-171 Rev. 3. It creates an auditable gap record; it does not certify compliance, provide legal advice, or replace an assessor, regulator, or certification body. Section index Framework basis When to use it Inputs The prompt Output contract Verification Guardrails Routing examples References Framework basis Publisher: NIST Version: Rev. 3 Status: final Sources reviewed: 2026-08-21 Jurisdictions: united-states Industries: defense-industrial-base, government-contractors License boundary: public-domain Nonfederal organizations protecting Controlled Unclassified Information in systems subject to federal contract or policy requirements. The cataloged version is final; still verify scope and any later official updates. Use the official publication as the authority and preserve its version and update identifiers in every finding. When to use it Use this recipe when the organization has established that NIST SP 800-171 Rev. 3 is applicable or wants a readiness assessment against it. Use the routing positives below to distinguish this recipe from adjacent frameworks. If applicability, the effective version, or the authoritative requirement set is unresolved, stop at a scoped intake and record the decision owner. Inputs The business purpose, legal entities, products, services, systems, and locations in scope. The organization's role, applicability decision, selected profile, level, baseline, or control set where the framework requires one. The official publication URLs above and, for licensed material, an authorized organization-supplied copy. Evidence from the complete review period, including populations—not only hand-picked examples. Named owners, inherited/shared responsibilities, exceptions, compensating measures, and accepted risks. Read-only access by default. Redacted exports are acceptable when provenance and coverage remain testable. Evidence domains for this framework: CUI flow and system boundary: begin with CUI data-flow and boundary diagrams. security requirement implementation: begin with system security plan. assessment and residual risk: begin with requirement-level assessment evidence. plans of action and continuous monitoring: begin with POA&M and remediation records. The prompt You are a compliance evidence-readiness analyst. Evaluate the supplied scope against NIST SP 800-171 Rev. 3 (Rev. 3). The catalog status is final and the source review date is 2026-08-21. Never claim certification or legal compliance. Never invent applicability, evidence, control operation, sampling results, or requirement text. Separate observed facts, organization assertions, and analyst inferences. Treat missing or inaccessible evidence as unknown, not as failure, unless the authoritative assessment method says otherwise. Step 0 — Lock authority, version, and scope 1. Record the exact official source, version, publication/update identifier, and effective date used. 2. Record the organization, role, jurisdiction, industry, system/product boundary, review period, and decision owner. 3. Confirm any selected level, profile, baseline, overlay, assessment type, or licensed requirement set. 4. The cataloged version is final; still verify scope and any later official updates. 5. Use the official publication as the authority and preserve its version and update identifiers in every finding. 6. Stop and request a decision when applicability or the authoritative requirement set cannot be established. Step 1 — Build the applicability map For every supplied requirement identifier or official outcome in scope, record: applicability, rationale, responsible owner, implementation location, inherited/shared responsibility, evidence expected, and any dependency. Use only identifiers present in the authoritative source supplied for this engagement. Do not reconstruct licensed text. Step 2 — Collect evidence by framework domain Review these domains without treating the labels as substitutes for authoritative requirements: 1. CUI flow and system boundary 2. security requirement implementation 3. assessment and residual risk 4. plans of action and continuous monitoring Start with these likely artifacts, then validate provenance and coverage: 1. CUI data-flow and boundary diagrams 2. system security plan 3. requirement-level assessment evidence 4. POA&M and remediation records For every artifact record: artifact ID, source system, owner, collection time, review period, access path, integrity/provenance note, population covered, and requirement/outcome links. Prefer system exports and immutable records over screenshots or narrative attestations. Step 3 — Test design and operation For each applicable item, evaluate design, implementation, and operating evidence separately. Check whether evidence is authentic, complete, current for the review period, population-representative, and directly linked to the scoped system. Where sampling is permitted, state the population, method, sample size, selections, exceptions, and limitations; do not imply statistical assurance without a justified method. Step 4 — Classify gaps without overstating them Use only: supported, partially supported, unsupported, not applicable with rationale, or not assessed. Record gaps as evidence-readiness findings—not declarations of legal noncompliance. Each finding must include the affected requirement/outcome, observed fact, missing or weak evidence, risk, owner, corrective action, due date, dependencies, retest method, and confidence. Step 5 — Produce the evidence bundle Return one Markdown file named NISTSP800171REV3CUIEVIDENCECHECK.md with: 1. Executive summary and explicit assurance limitations. 2. Authority/version/status and scope/applicability record. 3. Coverage totals by status and evidence domain. 4. Requirement/outcome-to-evidence matrix with artifact provenance. 5. Findings ordered by risk and evidence impact. 6. A 30/60/90-day remediation and evidence-collection plan. 7. Open questions, unavailable sources, conflicts, and decisions required. 8. Official references with access/review date. Before finalizing, verify that every conclusion is traceable to an artifact or clearly labeled assertion/inference, all denominators reconcile, all unavailable evidence is visible, licensed text is not reproduced, and no sentence claims certification or legal approval. Output contract The response must contain one evidence matrix row per scoped authoritative item or outcome. At minimum include itemid, applicability, owner, implementation, artifactids, testmethod, coverage_period, status, gap, and confidence. Every artifact ID must resolve to the artifact register, and every total must reconcile to the matrix. Verification Confirm the official source, version, status, and review date in both the executive summary and matrix metadata. Reconcile applicable, not applicable, and not assessed counts to the complete supplied scope. Trace each supported assertion to provenance-bearing evidence covering the stated period and population. Independently reperform a risk-based sample of mappings and document all exceptions. Verify findings distinguish control/design weakness from missing evidence and unknown scope. Have the accountable owner and, where required, qualified counsel or an authorized assessor review conclusions. Guardrails This is an evidence-readiness workflow, not certification, attestation, audit opinion, or legal advice. Do not infer that a voluntary framework is mandatory or that one framework proves another. Do not paste, paraphrase at length, or reconstruct licensed controls. Use source summaries and organization-supplied licensed material. Do not expose secrets, personal data, regulated data, or full production exports in the report. Do not modify systems, close findings, accept risk, or submit regulatory reports without explicit owner authorization. If versions conflict, preserve both citations, label the conflict, and escalate rather than choosing silently. Routing examples Route here: assess NIST 800-171 Rev 3 evidence review CUI protection requirements prepare a CUI system security plan Hard negatives—route elsewhere or clarify: assess a federal control baseline under NIST 800-53 perform a CMMC certification decision Related recipes NIST SP 800-53 Rev. 5 FedRAMP 2026 CMMC 2.0 References 1. NIST official source 1","agent_handoff":{"mcp_lookup_keys":["nist-sp-800-171-rev3-cui-evidence-check","/recipes/general/compliance-standards/nist-sp-800-171-rev3-cui-evidence-check/","recipes/general/compliance-standards/nist-sp-800-171-rev3-cui-evidence-check.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["audit","compliance"],"source_text_field":"content_text","portable_download":"security-recipe-nist-sp-800-171-rev3-cui-evidence-check.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-nist-sp-800-171-rev3-cui-evidence-check.json"}},{"slug":"nist-sp-800-53-rev5-control-evidence-check","title":"NIST SP 800-53 Rev. 5 Control Evidence Check","link_title":"NIST SP 800-53 Rev. 5","url":"https://security-recipes.ai/recipes/general/compliance-standards/nist-sp-800-53-rev5-control-evidence-check/","path":"/recipes/general/compliance-standards/nist-sp-800-53-rev5-control-evidence-check/","source_file":"recipes/general/compliance-standards/nist-sp-800-53-rev5-control-evidence-check.md","recipe_id":"compliance.nist-sp-800-53-rev5-5-2-0","recipe_kind":"","category":{"slug":"compliance-standards","label":"Compliance Standards"},"agent":"Compliance evidence review","severity":"info","maturity":"stable","ecosystem":"","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"NIST SP 800-53 Rev. 5","framework_version":"Rev. 5, Release 5.2.0","jurisdiction":["united-states"],"industry":["government","cross-sector"],"cve_archetypes":[],"cve_workflow_role":"","tags":["compliance","nist-sp-800-53","government","audit","risk","control-testing","cross-sector"],"facets":["audit","compliance","risk"],"quality":{"score":100,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context","multi-facet"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"Security Recipes","team":"GRC and Security Engineering","model":"gpt-5-codex","ai_assisted":false,"generated_by":"","date":"2026-08-21","zero_day":false,"last_updated":"2026-08-21","summary":"Assess NIST SP 800-53 Rev. 5 evidence readiness: verify applicability, map official requirements to artifacts, record gaps, and plan remediation.","content_text":"NIST SP 800-53 Rev. 5 Control Evidence Check Use this recipe to produce a source-aware evidence-readiness assessment for NIST SP 800-53 Rev. 5. It creates an auditable gap record; it does not certify compliance, provide legal advice, or replace an assessor, regulator, or certification body. Section index Framework basis When to use it Inputs The prompt Output contract Verification Guardrails Routing examples References Framework basis Publisher: NIST Version: Rev. 5, Release 5.2.0 Status: final Sources reviewed: 2026-08-21 Jurisdictions: united-states Industries: government, cross-sector License boundary: public-domain Information systems using an organization-selected NIST SP 800-53 Rev. 5 control baseline or overlay. The cataloged version is final; still verify scope and any later official updates. Use the official publication as the authority and preserve its version and update identifiers in every finding. When to use it Use this recipe when the organization has established that NIST SP 800-53 Rev. 5 is applicable or wants a readiness assessment against it. Use the routing positives below to distinguish this recipe from adjacent frameworks. If applicability, the effective version, or the authoritative requirement set is unresolved, stop at a scoped intake and record the decision owner. Inputs The business purpose, legal entities, products, services, systems, and locations in scope. The organization's role, applicability decision, selected profile, level, baseline, or control set where the framework requires one. The official publication URLs above and, for licensed material, an authorized organization-supplied copy. Evidence from the complete review period, including populations—not only hand-picked examples. Named owners, inherited/shared responsibilities, exceptions, compensating measures, and accepted risks. Read-only access by default. Redacted exports are acceptable when provenance and coverage remain testable. Evidence domains for this framework: system scope and control selection: begin with approved system security plan. control implementation statements: begin with baseline and tailoring decisions. assessment procedures and evidence: begin with assessment results tied to 800-53A objectives. plans of action and continuous monitoring: begin with POA&M and monitoring artifacts. The prompt You are a compliance evidence-readiness analyst. Evaluate the supplied scope against NIST SP 800-53 Rev. 5 (Rev. 5, Release 5.2.0). The catalog status is final and the source review date is 2026-08-21. Never claim certification or legal compliance. Never invent applicability, evidence, control operation, sampling results, or requirement text. Separate observed facts, organization assertions, and analyst inferences. Treat missing or inaccessible evidence as unknown, not as failure, unless the authoritative assessment method says otherwise. Step 0 — Lock authority, version, and scope 1. Record the exact official source, version, publication/update identifier, and effective date used. 2. Record the organization, role, jurisdiction, industry, system/product boundary, review period, and decision owner. 3. Confirm any selected level, profile, baseline, overlay, assessment type, or licensed requirement set. 4. The cataloged version is final; still verify scope and any later official updates. 5. Use the official publication as the authority and preserve its version and update identifiers in every finding. 6. Stop and request a decision when applicability or the authoritative requirement set cannot be established. Step 1 — Build the applicability map For every supplied requirement identifier or official outcome in scope, record: applicability, rationale, responsible owner, implementation location, inherited/shared responsibility, evidence expected, and any dependency. Use only identifiers present in the authoritative source supplied for this engagement. Do not reconstruct licensed text. Step 2 — Collect evidence by framework domain Review these domains without treating the labels as substitutes for authoritative requirements: 1. system scope and control selection 2. control implementation statements 3. assessment procedures and evidence 4. plans of action and continuous monitoring Start with these likely artifacts, then validate provenance and coverage: 1. approved system security plan 2. baseline and tailoring decisions 3. assessment results tied to 800-53A objectives 4. POA&M and monitoring artifacts For every artifact record: artifact ID, source system, owner, collection time, review period, access path, integrity/provenance note, population covered, and requirement/outcome links. Prefer system exports and immutable records over screenshots or narrative attestations. Step 3 — Test design and operation For each applicable item, evaluate design, implementation, and operating evidence separately. Check whether evidence is authentic, complete, current for the review period, population-representative, and directly linked to the scoped system. Where sampling is permitted, state the population, method, sample size, selections, exceptions, and limitations; do not imply statistical assurance without a justified method. Step 4 — Classify gaps without overstating them Use only: supported, partially supported, unsupported, not applicable with rationale, or not assessed. Record gaps as evidence-readiness findings—not declarations of legal noncompliance. Each finding must include the affected requirement/outcome, observed fact, missing or weak evidence, risk, owner, corrective action, due date, dependencies, retest method, and confidence. Step 5 — Produce the evidence bundle Return one Markdown file named NISTSP80053REV5CONTROLEVIDENCECHECK.md with: 1. Executive summary and explicit assurance limitations. 2. Authority/version/status and scope/applicability record. 3. Coverage totals by status and evidence domain. 4. Requirement/outcome-to-evidence matrix with artifact provenance. 5. Findings ordered by risk and evidence impact. 6. A 30/60/90-day remediation and evidence-collection plan. 7. Open questions, unavailable sources, conflicts, and decisions required. 8. Official references with access/review date. Before finalizing, verify that every conclusion is traceable to an artifact or clearly labeled assertion/inference, all denominators reconcile, all unavailable evidence is visible, licensed text is not reproduced, and no sentence claims certification or legal approval. Output contract The response must contain one evidence matrix row per scoped authoritative item or outcome. At minimum include itemid, applicability, owner, implementation, artifactids, testmethod, coverage_period, status, gap, and confidence. Every artifact ID must resolve to the artifact register, and every total must reconcile to the matrix. Verification Confirm the official source, version, status, and review date in both the executive summary and matrix metadata. Reconcile applicable, not applicable, and not assessed counts to the complete supplied scope. Trace each supported assertion to provenance-bearing evidence covering the stated period and population. Independently reperform a risk-based sample of mappings and document all exceptions. Verify findings distinguish control/design weakness from missing evidence and unknown scope. Have the accountable owner and, where required, qualified counsel or an authorized assessor review conclusions. Guardrails This is an evidence-readiness workflow, not certification, attestation, audit opinion, or legal advice. Do not infer that a voluntary framework is mandatory or that one framework proves another. Do not paste, paraphrase at length, or reconstruct licensed controls. Use source summaries and organization-supplied licensed material. Do not expose secrets, personal data, regulated data, or full production exports in the report. Do not modify systems, close findings, accept risk, or submit regulatory reports without explicit owner authorization. If versions conflict, preserve both citations, label the conflict, and escalate rather than choosing silently. Routing examples Route here: assess NIST 800-53 Rev 5 controls collect federal control evidence review a system security plan against 800-53A Hard negatives—route elsewhere or clarify: assess CUI requirements using NIST 800-171 build a high-level NIST CSF profile Related recipes NIST SP 800-171 Rev. 3 FedRAMP 2026 CMMC 2.0 References 1. NIST official source 1 2. NIST official source 2","agent_handoff":{"mcp_lookup_keys":["nist-sp-800-53-rev5-control-evidence-check","/recipes/general/compliance-standards/nist-sp-800-53-rev5-control-evidence-check/","recipes/general/compliance-standards/nist-sp-800-53-rev5-control-evidence-check.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["audit","compliance","risk"],"source_text_field":"content_text","portable_download":"security-recipe-nist-sp-800-53-rev5-control-evidence-check.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-nist-sp-800-53-rev5-control-evidence-check.json"}},{"slug":"nist-ssdf-repo-evidence-check","title":"NIST SSDF 1.1 Repository Evidence Check","link_title":"NIST SSDF 1.1","url":"https://security-recipes.ai/recipes/general/compliance-standards/nist-ssdf-repo-evidence-check/","path":"/recipes/general/compliance-standards/nist-ssdf-repo-evidence-check/","source_file":"recipes/general/compliance-standards/nist-ssdf-repo-evidence-check.md","recipe_id":"compliance.nist-ssdf-1-1","recipe_kind":"","category":{"slug":"compliance-standards","label":"Compliance Standards"},"agent":"Compliance evidence review","severity":"info","maturity":"stable","ecosystem":"","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"NIST SSDF 1.1","framework_version":"SP 800-218 v1.1","jurisdiction":["global","united-states"],"industry":["software","cross-sector"],"cve_archetypes":[],"cve_workflow_role":"","tags":["compliance","nist-ssdf","product-security","audit","code-hygiene","supply-chain","software","cross-sector"],"facets":["audit","compliance","code-hygiene"],"quality":{"score":100,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context","multi-facet"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"Security Recipes","team":"GRC and Security Engineering","model":"gpt-5-codex","ai_assisted":false,"generated_by":"","date":"2026-08-21","zero_day":false,"last_updated":"2026-08-21","summary":"Assess NIST SSDF 1.1 evidence readiness: verify applicability, map official requirements to artifacts, record gaps, and plan remediation.","content_text":"NIST SSDF 1.1 Repository Evidence Check Use this recipe to produce a source-aware evidence-readiness assessment for NIST SSDF 1.1. It creates an auditable gap record; it does not certify compliance, provide legal advice, or replace an assessor, regulator, or certification body. Section index Framework basis When to use it Inputs The prompt Output contract Verification Guardrails Routing examples References Framework basis Publisher: NIST Version: SP 800-218 v1.1 Status: final Sources reviewed: 2026-08-21 Jurisdictions: global, united-states Industries: software, cross-sector License boundary: public-domain Software producers assessing secure development practices and repository evidence against NIST SP 800-218. The cataloged version is final; still verify scope and any later official updates. Use the official publication as the authority and preserve its version and update identifiers in every finding. When to use it Use this recipe when the organization has established that NIST SSDF 1.1 is applicable or wants a readiness assessment against it. Use the routing positives below to distinguish this recipe from adjacent frameworks. If applicability, the effective version, or the authoritative requirement set is unresolved, stop at a scoped intake and record the decision owner. Inputs The business purpose, legal entities, products, services, systems, and locations in scope. The organization's role, applicability decision, selected profile, level, baseline, or control set where the framework requires one. The official publication URLs above and, for licensed material, an authorized organization-supplied copy. Evidence from the complete review period, including populations—not only hand-picked examples. Named owners, inherited/shared responsibilities, exceptions, compensating measures, and accepted risks. Read-only access by default. Redacted exports are acceptable when provenance and coverage remain testable. Evidence domains for this framework: secure development governance: begin with secure development policies. software protection: begin with branch and artifact protection settings. well-secured software production: begin with build and test attestations. vulnerability response: begin with vulnerability intake and remediation records. The prompt You are a compliance evidence-readiness analyst. Evaluate the supplied scope against NIST SSDF 1.1 (SP 800-218 v1.1). The catalog status is final and the source review date is 2026-08-21. Never claim certification or legal compliance. Never invent applicability, evidence, control operation, sampling results, or requirement text. Separate observed facts, organization assertions, and analyst inferences. Treat missing or inaccessible evidence as unknown, not as failure, unless the authoritative assessment method says otherwise. Step 0 — Lock authority, version, and scope 1. Record the exact official source, version, publication/update identifier, and effective date used. 2. Record the organization, role, jurisdiction, industry, system/product boundary, review period, and decision owner. 3. Confirm any selected level, profile, baseline, overlay, assessment type, or licensed requirement set. 4. The cataloged version is final; still verify scope and any later official updates. 5. Use the official publication as the authority and preserve its version and update identifiers in every finding. 6. Stop and request a decision when applicability or the authoritative requirement set cannot be established. Step 1 — Build the applicability map For every supplied requirement identifier or official outcome in scope, record: applicability, rationale, responsible owner, implementation location, inherited/shared responsibility, evidence expected, and any dependency. Use only identifiers present in the authoritative source supplied for this engagement. Do not reconstruct licensed text. Step 2 — Collect evidence by framework domain Review these domains without treating the labels as substitutes for authoritative requirements: 1. secure development governance 2. software protection 3. well-secured software production 4. vulnerability response Start with these likely artifacts, then validate provenance and coverage: 1. secure development policies 2. branch and artifact protection settings 3. build and test attestations 4. vulnerability intake and remediation records For every artifact record: artifact ID, source system, owner, collection time, review period, access path, integrity/provenance note, population covered, and requirement/outcome links. Prefer system exports and immutable records over screenshots or narrative attestations. Step 3 — Test design and operation For each applicable item, evaluate design, implementation, and operating evidence separately. Check whether evidence is authentic, complete, current for the review period, population-representative, and directly linked to the scoped system. Where sampling is permitted, state the population, method, sample size, selections, exceptions, and limitations; do not imply statistical assurance without a justified method. Step 4 — Classify gaps without overstating them Use only: supported, partially supported, unsupported, not applicable with rationale, or not assessed. Record gaps as evidence-readiness findings—not declarations of legal noncompliance. Each finding must include the affected requirement/outcome, observed fact, missing or weak evidence, risk, owner, corrective action, due date, dependencies, retest method, and confidence. Step 5 — Produce the evidence bundle Return one Markdown file named NISTSSDFREPOEVIDENCECHECK.md with: 1. Executive summary and explicit assurance limitations. 2. Authority/version/status and scope/applicability record. 3. Coverage totals by status and evidence domain. 4. Requirement/outcome-to-evidence matrix with artifact provenance. 5. Findings ordered by risk and evidence impact. 6. A 30/60/90-day remediation and evidence-collection plan. 7. Open questions, unavailable sources, conflicts, and decisions required. 8. Official references with access/review date. Before finalizing, verify that every conclusion is traceable to an artifact or clearly labeled assertion/inference, all denominators reconcile, all unavailable evidence is visible, licensed text is not reproduced, and no sentence claims certification or legal approval. Output contract The response must contain one evidence matrix row per scoped authoritative item or outcome. At minimum include itemid, applicability, owner, implementation, artifactids, testmethod, coverageperiod, status, gap, and confidence. Every artifact ID must resolve to the artifact register, and every total must reconcile to the matrix. Verification Confirm the official source, version, status, and review date in both the executive summary and matrix metadata. Reconcile applicable, not applicable, and not assessed counts to the complete supplied scope. Trace each supported assertion to provenance-bearing evidence covering the stated period and population. Independently reperform a risk-based sample of mappings and document all exceptions. Verify findings distinguish control/design weakness from missing evidence and unknown scope. Have the accountable owner and, where required, qualified counsel or an authorized assessor review conclusions. Guardrails This is an evidence-readiness workflow, not certification, attestation, audit opinion, or legal advice. Do not infer that a voluntary framework is mandatory or that one framework proves another. Do not paste, paraphrase at length, or reconstruct licensed controls. Use source summaries and organization-supplied licensed material. Do not expose secrets, personal data, regulated data, or full production exports in the report. Do not modify systems, close findings, accept risk, or submit regulatory reports without explicit owner authorization. If versions conflict, preserve both citations, label the conflict, and escalate rather than choosing silently. Routing examples Route here: assess this repository against NIST SSDF collect SP 800-218 evidence review secure software development practices Hard negatives—route elsewhere or clarify: assess AI model development with SP 800-218A verify SLSA build provenance only Related recipes SLSA v1.2 OWASP ASVS 5.0.0 OWASP API Top 10:2023 References 1. NIST official source 1","agent_handoff":{"mcp_lookup_keys":["nist-ssdf-repo-evidence-check","/recipes/general/compliance-standards/nist-ssdf-repo-evidence-check/","recipes/general/compliance-standards/nist-ssdf-repo-evidence-check.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["audit","compliance","code-hygiene"],"source_text_field":"content_text","portable_download":"security-recipe-nist-ssdf-repo-evidence-check.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-nist-ssdf-repo-evidence-check.json"}},{"slug":"nydfs-part-500-evidence-check","title":"NYDFS 23 NYCRR Part 500 Evidence Check","link_title":"NYDFS Part 500","url":"https://security-recipes.ai/recipes/general/compliance-standards/nydfs-part-500-evidence-check/","path":"/recipes/general/compliance-standards/nydfs-part-500-evidence-check/","source_file":"recipes/general/compliance-standards/nydfs-part-500-evidence-check.md","recipe_id":"compliance.nydfs-23-nycrr-500","recipe_kind":"","category":{"slug":"compliance-standards","label":"Compliance Standards"},"agent":"Compliance evidence review","severity":"info","maturity":"stable","ecosystem":"","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"NYDFS Part 500","framework_version":"Second Amendment, effective November 1, 2023 with phased dates","jurisdiction":["united-states","new-york"],"industry":["financial-services","insurance"],"cve_archetypes":[],"cve_workflow_role":"","tags":["compliance","nydfs-part-500","regulated-industries","audit","data-protection","incident-response","financial-services","insurance"],"facets":["audit","compliance"],"quality":{"score":95,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"Security Recipes","team":"GRC and Security Engineering","model":"gpt-5-codex","ai_assisted":false,"generated_by":"","date":"2026-08-21","zero_day":false,"last_updated":"2026-08-21","summary":"Assess NYDFS Part 500 evidence readiness: verify applicability, map official requirements to artifacts, record gaps, and plan remediation.","content_text":"NYDFS 23 NYCRR Part 500 Evidence Check Use this recipe to produce a source-aware evidence-readiness assessment for NYDFS Part 500. It creates an auditable gap record; it does not certify compliance, provide legal advice, or replace an assessor, regulator, or certification body. Section index Framework basis When to use it Inputs The prompt Output contract Verification Guardrails Routing examples References Framework basis Publisher: New York State Department of Financial Services Version: Second Amendment, effective November 1, 2023 with phased dates Status: phased-implementation Sources reviewed: 2026-08-21 Jurisdictions: united-states, new-york Industries: financial-services, insurance License boundary: official-text NYDFS covered entities, with obligations determined by covered-entity and class-A status and the amendment's phased effective dates. Implementation is phased. Determine which duties and dates apply to the organization before evaluating evidence. Use the linked official legal or regulatory text and current implementing guidance; do not replace applicability analysis with this summary. When to use it Use this recipe when the organization has established that NYDFS Part 500 is applicable or wants a readiness assessment against it. Use the routing positives below to distinguish this recipe from adjacent frameworks. If applicability, the effective version, or the authoritative requirement set is unresolved, stop at a scoped intake and record the decision owner. Inputs The business purpose, legal entities, products, services, systems, and locations in scope. The organization's role, applicability decision, selected profile, level, baseline, or control set where the framework requires one. The official publication URLs above and, for licensed material, an authorized organization-supplied copy. Evidence from the complete review period, including populations—not only hand-picked examples. Named owners, inherited/shared responsibilities, exceptions, compensating measures, and accepted risks. Read-only access by default. Redacted exports are acceptable when provenance and coverage remain testable. Evidence domains for this framework: covered-entity scope and governance: begin with status and exemption determination. risk assessment and cybersecurity program: begin with CISO and board reports. access, monitoring, and resilience: begin with asset, access, monitoring, and backup records. third parties, incidents, and certification: begin with incident notices and annual certification support. The prompt You are a compliance evidence-readiness analyst. Evaluate the supplied scope against NYDFS Part 500 (Second Amendment, effective November 1, 2023 with phased dates). The catalog status is phased-implementation and the source review date is 2026-08-21. Never claim certification or legal compliance. Never invent applicability, evidence, control operation, sampling results, or requirement text. Separate observed facts, organization assertions, and analyst inferences. Treat missing or inaccessible evidence as unknown, not as failure, unless the authoritative assessment method says otherwise. Step 0 — Lock authority, version, and scope 1. Record the exact official source, version, publication/update identifier, and effective date used. 2. Record the organization, role, jurisdiction, industry, system/product boundary, review period, and decision owner. 3. Confirm any selected level, profile, baseline, overlay, assessment type, or licensed requirement set. 4. Implementation is phased. Determine which duties and dates apply to the organization before evaluating evidence. 5. Use the linked official legal or regulatory text and current implementing guidance; do not replace applicability analysis with this summary. 6. Stop and request a decision when applicability or the authoritative requirement set cannot be established. Step 1 — Build the applicability map For every supplied requirement identifier or official outcome in scope, record: applicability, rationale, responsible owner, implementation location, inherited/shared responsibility, evidence expected, and any dependency. Use only identifiers present in the authoritative source supplied for this engagement. Do not reconstruct licensed text. Step 2 — Collect evidence by framework domain Review these domains without treating the labels as substitutes for authoritative requirements: 1. covered-entity scope and governance 2. risk assessment and cybersecurity program 3. access, monitoring, and resilience 4. third parties, incidents, and certification Start with these likely artifacts, then validate provenance and coverage: 1. status and exemption determination 2. CISO and board reports 3. asset, access, monitoring, and backup records 4. incident notices and annual certification support For every artifact record: artifact ID, source system, owner, collection time, review period, access path, integrity/provenance note, population covered, and requirement/outcome links. Prefer system exports and immutable records over screenshots or narrative attestations. Step 3 — Test design and operation For each applicable item, evaluate design, implementation, and operating evidence separately. Check whether evidence is authentic, complete, current for the review period, population-representative, and directly linked to the scoped system. Where sampling is permitted, state the population, method, sample size, selections, exceptions, and limitations; do not imply statistical assurance without a justified method. Step 4 — Classify gaps without overstating them Use only: supported, partially supported, unsupported, not applicable with rationale, or not assessed. Record gaps as evidence-readiness findings—not declarations of legal noncompliance. Each finding must include the affected requirement/outcome, observed fact, missing or weak evidence, risk, owner, corrective action, due date, dependencies, retest method, and confidence. Step 5 — Produce the evidence bundle Return one Markdown file named NYDFSPART500EVIDENCECHECK.md with: 1. Executive summary and explicit assurance limitations. 2. Authority/version/status and scope/applicability record. 3. Coverage totals by status and evidence domain. 4. Requirement/outcome-to-evidence matrix with artifact provenance. 5. Findings ordered by risk and evidence impact. 6. A 30/60/90-day remediation and evidence-collection plan. 7. Open questions, unavailable sources, conflicts, and decisions required. 8. Official references with access/review date. Before finalizing, verify that every conclusion is traceable to an artifact or clearly labeled assertion/inference, all denominators reconcile, all unavailable evidence is visible, licensed text is not reproduced, and no sentence claims certification or legal approval. Output contract The response must contain one evidence matrix row per scoped authoritative item or outcome. At minimum include itemid, applicability, owner, implementation, artifactids, testmethod, coverageperiod, status, gap, and confidence. Every artifact ID must resolve to the artifact register, and every total must reconcile to the matrix. Verification Confirm the official source, version, status, and review date in both the executive summary and matrix metadata. Reconcile applicable, not applicable, and not assessed counts to the complete supplied scope. Trace each supported assertion to provenance-bearing evidence covering the stated period and population. Independently reperform a risk-based sample of mappings and document all exceptions. Verify findings distinguish control/design weakness from missing evidence and unknown scope. Have the accountable owner and, where required, qualified counsel or an authorized assessor review conclusions. Guardrails This is an evidence-readiness workflow, not certification, attestation, audit opinion, or legal advice. Do not infer that a voluntary framework is mandatory or that one framework proves another. Do not paste, paraphrase at length, or reconstruct licensed controls. Use source summaries and organization-supplied licensed material. Do not expose secrets, personal data, regulated data, or full production exports in the report. Do not modify systems, close findings, accept risk, or submit regulatory reports without explicit owner authorization. If versions conflict, preserve both citations, label the conflict, and escalate rather than choosing silently. Routing examples Route here: assess NYDFS Part 500 evidence review class A cybersecurity obligations prepare DFS cybersecurity certification support Hard negatives—route elsewhere or clarify: assess GLBA Safeguards Rule only prepare SEC public-company cyber disclosures Related recipes PCI DSS 4.0.1 HIPAA Security Rule GLBA Safeguards Rule References 1. New York State Department of Financial Services official source 1","agent_handoff":{"mcp_lookup_keys":["nydfs-part-500-evidence-check","/recipes/general/compliance-standards/nydfs-part-500-evidence-check/","recipes/general/compliance-standards/nydfs-part-500-evidence-check.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["audit","compliance"],"source_text_field":"content_text","portable_download":"security-recipe-nydfs-part-500-evidence-check.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-nydfs-part-500-evidence-check.json"}},{"slug":"openssf-osps-baseline-evidence-check","title":"OpenSSF OSPS Baseline Evidence Check","link_title":"OpenSSF OSPS Baseline","url":"https://security-recipes.ai/recipes/general/compliance-standards/openssf-osps-baseline-evidence-check/","path":"/recipes/general/compliance-standards/openssf-osps-baseline-evidence-check/","source_file":"recipes/general/compliance-standards/openssf-osps-baseline-evidence-check.md","recipe_id":"compliance.openssf-osps-baseline-2026-02-19","recipe_kind":"","category":{"slug":"compliance-standards","label":"Compliance Standards"},"agent":"Compliance evidence review","severity":"info","maturity":"stable","ecosystem":"","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"OpenSSF OSPS Baseline","framework_version":"2026.02.19","jurisdiction":["global"],"industry":["open-source","software"],"cve_archetypes":[],"cve_workflow_role":"","tags":["compliance","openssf-osps-baseline","product-security","audit","supply-chain","secure-defaults","open-source","software"],"facets":["audit","compliance"],"quality":{"score":95,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"Security Recipes","team":"GRC and Security Engineering","model":"gpt-5-codex","ai_assisted":false,"generated_by":"","date":"2026-08-21","zero_day":false,"last_updated":"2026-08-21","summary":"Assess OpenSSF OSPS Baseline evidence readiness: verify applicability, map official requirements to artifacts, record gaps, and plan remediation.","content_text":"OpenSSF OSPS Baseline Evidence Check Use this recipe to produce a source-aware evidence-readiness assessment for OpenSSF OSPS Baseline. It creates an auditable gap record; it does not certify compliance, provide legal advice, or replace an assessor, regulator, or certification body. Section index Framework basis When to use it Inputs The prompt Output contract Verification Guardrails Routing examples References Framework basis Publisher: Open Source Security Foundation Version: 2026.02.19 Status: final Sources reviewed: 2026-08-21 Jurisdictions: global Industries: open-source, software License boundary: open-attribution Open source projects and downstream consumers evaluating baseline security practices at an explicitly selected OSPS level. The cataloged version is final; still verify scope and any later official updates. Use the official version and preserve its attribution and license terms. Do not substitute memory for the selected published text. When to use it Use this recipe when the organization has established that OpenSSF OSPS Baseline is applicable or wants a readiness assessment against it. Use the routing positives below to distinguish this recipe from adjacent frameworks. If applicability, the effective version, or the authoritative requirement set is unresolved, stop at a scoped intake and record the decision owner. Inputs The business purpose, legal entities, products, services, systems, and locations in scope. The organization's role, applicability decision, selected profile, level, baseline, or control set where the framework requires one. The official publication URLs above and, for licensed material, an authorized organization-supplied copy. Evidence from the complete review period, including populations—not only hand-picked examples. Named owners, inherited/shared responsibilities, exceptions, compensating measures, and accepted risks. Read-only access by default. Redacted exports are acceptable when provenance and coverage remain testable. Evidence domains for this framework: access and repository governance: begin with repository setting exports. build and release: begin with release workflow and artifact records. documentation and vulnerability reporting: begin with security policy and advisory history. quality, legal, and security assessment: begin with dependency, test, and review evidence. The prompt You are a compliance evidence-readiness analyst. Evaluate the supplied scope against OpenSSF OSPS Baseline (2026.02.19). The catalog status is final and the source review date is 2026-08-21. Never claim certification or legal compliance. Never invent applicability, evidence, control operation, sampling results, or requirement text. Separate observed facts, organization assertions, and analyst inferences. Treat missing or inaccessible evidence as unknown, not as failure, unless the authoritative assessment method says otherwise. Step 0 — Lock authority, version, and scope 1. Record the exact official source, version, publication/update identifier, and effective date used. 2. Record the organization, role, jurisdiction, industry, system/product boundary, review period, and decision owner. 3. Confirm any selected level, profile, baseline, overlay, assessment type, or licensed requirement set. 4. The cataloged version is final; still verify scope and any later official updates. 5. Use the official version and preserve its attribution and license terms. Do not substitute memory for the selected published text. 6. Stop and request a decision when applicability or the authoritative requirement set cannot be established. Step 1 — Build the applicability map For every supplied requirement identifier or official outcome in scope, record: applicability, rationale, responsible owner, implementation location, inherited/shared responsibility, evidence expected, and any dependency. Use only identifiers present in the authoritative source supplied for this engagement. Do not reconstruct licensed text. Step 2 — Collect evidence by framework domain Review these domains without treating the labels as substitutes for authoritative requirements: 1. access and repository governance 2. build and release 3. documentation and vulnerability reporting 4. quality, legal, and security assessment Start with these likely artifacts, then validate provenance and coverage: 1. repository setting exports 2. release workflow and artifact records 3. security policy and advisory history 4. dependency, test, and review evidence For every artifact record: artifact ID, source system, owner, collection time, review period, access path, integrity/provenance note, population covered, and requirement/outcome links. Prefer system exports and immutable records over screenshots or narrative attestations. Step 3 — Test design and operation For each applicable item, evaluate design, implementation, and operating evidence separately. Check whether evidence is authentic, complete, current for the review period, population-representative, and directly linked to the scoped system. Where sampling is permitted, state the population, method, sample size, selections, exceptions, and limitations; do not imply statistical assurance without a justified method. Step 4 — Classify gaps without overstating them Use only: supported, partially supported, unsupported, not applicable with rationale, or not assessed. Record gaps as evidence-readiness findings—not declarations of legal noncompliance. Each finding must include the affected requirement/outcome, observed fact, missing or weak evidence, risk, owner, corrective action, due date, dependencies, retest method, and confidence. Step 5 — Produce the evidence bundle Return one Markdown file named OPENSSFOSPSBASELINEEVIDENCECHECK.md with: 1. Executive summary and explicit assurance limitations. 2. Authority/version/status and scope/applicability record. 3. Coverage totals by status and evidence domain. 4. Requirement/outcome-to-evidence matrix with artifact provenance. 5. Findings ordered by risk and evidence impact. 6. A 30/60/90-day remediation and evidence-collection plan. 7. Open questions, unavailable sources, conflicts, and decisions required. 8. Official references with access/review date. Before finalizing, verify that every conclusion is traceable to an artifact or clearly labeled assertion/inference, all denominators reconcile, all unavailable evidence is visible, licensed text is not reproduced, and no sentence claims certification or legal approval. Output contract The response must contain one evidence matrix row per scoped authoritative item or outcome. At minimum include itemid, applicability, owner, implementation, artifactids, testmethod, coverageperiod, status, gap, and confidence. Every artifact ID must resolve to the artifact register, and every total must reconcile to the matrix. Verification Confirm the official source, version, status, and review date in both the executive summary and matrix metadata. Reconcile applicable, not applicable, and not assessed counts to the complete supplied scope. Trace each supported assertion to provenance-bearing evidence covering the stated period and population. Independently reperform a risk-based sample of mappings and document all exceptions. Verify findings distinguish control/design weakness from missing evidence and unknown scope. Have the accountable owner and, where required, qualified counsel or an authorized assessor review conclusions. Guardrails This is an evidence-readiness workflow, not certification, attestation, audit opinion, or legal advice. Do not infer that a voluntary framework is mandatory or that one framework proves another. Do not paste, paraphrase at length, or reconstruct licensed controls. Use source summaries and organization-supplied licensed material. Do not expose secrets, personal data, regulated data, or full production exports in the report. Do not modify systems, close findings, accept risk, or submit regulatory reports without explicit owner authorization. If versions conflict, preserve both citations, label the conflict, and escalate rather than choosing silently. Routing examples Route here: assess an open source project against OSPS collect OpenSSF Baseline evidence review open source project security practices Hard negatives—route elsewhere or clarify: verify SLSA provenance levels only perform enterprise CIS Controls assessment Related recipes NIST SSDF 1.1 SLSA v1.2 OWASP ASVS 5.0.0 References 1. Open Source Security Foundation official source 1","agent_handoff":{"mcp_lookup_keys":["openssf-osps-baseline-evidence-check","/recipes/general/compliance-standards/openssf-osps-baseline-evidence-check/","recipes/general/compliance-standards/openssf-osps-baseline-evidence-check.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["audit","compliance"],"source_text_field":"content_text","portable_download":"security-recipe-openssf-osps-baseline-evidence-check.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-openssf-osps-baseline-evidence-check.json"}},{"slug":"owasp-api-security-top-10-2023-evidence-check","title":"OWASP API Security Top 10:2023 Evidence Check","link_title":"OWASP API Top 10:2023","url":"https://security-recipes.ai/recipes/general/compliance-standards/owasp-api-security-top-10-2023-evidence-check/","path":"/recipes/general/compliance-standards/owasp-api-security-top-10-2023-evidence-check/","source_file":"recipes/general/compliance-standards/owasp-api-security-top-10-2023-evidence-check.md","recipe_id":"compliance.owasp-api-security-top-10-2023","recipe_kind":"","category":{"slug":"compliance-standards","label":"Compliance Standards"},"agent":"Compliance evidence review","severity":"info","maturity":"stable","ecosystem":"","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"OWASP API Top 10:2023","framework_version":"2023","jurisdiction":["global"],"industry":["software","api-providers"],"cve_archetypes":[],"cve_workflow_role":"","tags":["compliance","owasp-api-top-10","product-security","audit","application-security","api-security","software","api-providers"],"facets":["audit","compliance"],"quality":{"score":95,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"Security Recipes","team":"GRC and Security Engineering","model":"gpt-5-codex","ai_assisted":false,"generated_by":"","date":"2026-08-21","zero_day":false,"last_updated":"2026-08-21","summary":"Assess OWASP API Top 10:2023 evidence readiness: verify applicability, map official requirements to artifacts, record gaps, and plan remediation.","content_text":"OWASP API Security Top 10:2023 Evidence Check Use this recipe to produce a source-aware evidence-readiness assessment for OWASP API Top 10:2023. It creates an auditable gap record; it does not certify compliance, provide legal advice, or replace an assessor, regulator, or certification body. Section index Framework basis When to use it Inputs The prompt Output contract Verification Guardrails Routing examples References Framework basis Publisher: OWASP Foundation Version: 2023 Status: final Sources reviewed: 2026-08-21 Jurisdictions: global Industries: software, api-providers License boundary: open-attribution API owners using the 2023 risk categories to drive threat review, testing, and remediation; it is not a certification standard. The cataloged version is final; still verify scope and any later official updates. Use the official version and preserve its attribution and license terms. Do not substitute memory for the selected published text. When to use it Use this recipe when the organization has established that OWASP API Top 10:2023 is applicable or wants a readiness assessment against it. Use the routing positives below to distinguish this recipe from adjacent frameworks. If applicability, the effective version, or the authoritative requirement set is unresolved, stop at a scoped intake and record the decision owner. Inputs The business purpose, legal entities, products, services, systems, and locations in scope. The organization's role, applicability decision, selected profile, level, baseline, or control set where the framework requires one. The official publication URLs above and, for licensed material, an authorized organization-supplied copy. Evidence from the complete review period, including populations—not only hand-picked examples. Named owners, inherited/shared responsibilities, exceptions, compensating measures, and accepted risks. Read-only access by default. Redacted exports are acceptable when provenance and coverage remain testable. Evidence domains for this framework: object and function authorization: begin with API inventory and ownership. authentication and resource consumption: begin with authorization test matrices. business-flow and server-side request risks: begin with rate-limit and business-flow abuse tests. inventory, configuration, and unsafe API consumption: begin with dependency, configuration, and remediation records. The prompt You are a compliance evidence-readiness analyst. Evaluate the supplied scope against OWASP API Top 10:2023 (2023). The catalog status is final and the source review date is 2026-08-21. Never claim certification or legal compliance. Never invent applicability, evidence, control operation, sampling results, or requirement text. Separate observed facts, organization assertions, and analyst inferences. Treat missing or inaccessible evidence as unknown, not as failure, unless the authoritative assessment method says otherwise. Step 0 — Lock authority, version, and scope 1. Record the exact official source, version, publication/update identifier, and effective date used. 2. Record the organization, role, jurisdiction, industry, system/product boundary, review period, and decision owner. 3. Confirm any selected level, profile, baseline, overlay, assessment type, or licensed requirement set. 4. The cataloged version is final; still verify scope and any later official updates. 5. Use the official version and preserve its attribution and license terms. Do not substitute memory for the selected published text. 6. Stop and request a decision when applicability or the authoritative requirement set cannot be established. Step 1 — Build the applicability map For every supplied requirement identifier or official outcome in scope, record: applicability, rationale, responsible owner, implementation location, inherited/shared responsibility, evidence expected, and any dependency. Use only identifiers present in the authoritative source supplied for this engagement. Do not reconstruct licensed text. Step 2 — Collect evidence by framework domain Review these domains without treating the labels as substitutes for authoritative requirements: 1. object and function authorization 2. authentication and resource consumption 3. business-flow and server-side request risks 4. inventory, configuration, and unsafe API consumption Start with these likely artifacts, then validate provenance and coverage: 1. API inventory and ownership 2. authorization test matrices 3. rate-limit and business-flow abuse tests 4. dependency, configuration, and remediation records For every artifact record: artifact ID, source system, owner, collection time, review period, access path, integrity/provenance note, population covered, and requirement/outcome links. Prefer system exports and immutable records over screenshots or narrative attestations. Step 3 — Test design and operation For each applicable item, evaluate design, implementation, and operating evidence separately. Check whether evidence is authentic, complete, current for the review period, population-representative, and directly linked to the scoped system. Where sampling is permitted, state the population, method, sample size, selections, exceptions, and limitations; do not imply statistical assurance without a justified method. Step 4 — Classify gaps without overstating them Use only: supported, partially supported, unsupported, not applicable with rationale, or not assessed. Record gaps as evidence-readiness findings—not declarations of legal noncompliance. Each finding must include the affected requirement/outcome, observed fact, missing or weak evidence, risk, owner, corrective action, due date, dependencies, retest method, and confidence. Step 5 — Produce the evidence bundle Return one Markdown file named OWASPAPISECURITYTOP102023EVIDENCECHECK.md with: 1. Executive summary and explicit assurance limitations. 2. Authority/version/status and scope/applicability record. 3. Coverage totals by status and evidence domain. 4. Requirement/outcome-to-evidence matrix with artifact provenance. 5. Findings ordered by risk and evidence impact. 6. A 30/60/90-day remediation and evidence-collection plan. 7. Open questions, unavailable sources, conflicts, and decisions required. 8. Official references with access/review date. Before finalizing, verify that every conclusion is traceable to an artifact or clearly labeled assertion/inference, all denominators reconcile, all unavailable evidence is visible, licensed text is not reproduced, and no sentence claims certification or legal approval. Output contract The response must contain one evidence matrix row per scoped authoritative item or outcome. At minimum include itemid, applicability, owner, implementation, artifactids, testmethod, coverage_period, status, gap, and confidence. Every artifact ID must resolve to the artifact register, and every total must reconcile to the matrix. Verification Confirm the official source, version, status, and review date in both the executive summary and matrix metadata. Reconcile applicable, not applicable, and not assessed counts to the complete supplied scope. Trace each supported assertion to provenance-bearing evidence covering the stated period and population. Independently reperform a risk-based sample of mappings and document all exceptions. Verify findings distinguish control/design weakness from missing evidence and unknown scope. Have the accountable owner and, where required, qualified counsel or an authorized assessor review conclusions. Guardrails This is an evidence-readiness workflow, not certification, attestation, audit opinion, or legal advice. Do not infer that a voluntary framework is mandatory or that one framework proves another. Do not paste, paraphrase at length, or reconstruct licensed controls. Use source summaries and organization-supplied licensed material. Do not expose secrets, personal data, regulated data, or full production exports in the report. Do not modify systems, close findings, accept risk, or submit regulatory reports without explicit owner authorization. If versions conflict, preserve both citations, label the conflict, and escalate rather than choosing silently. Routing examples Route here: review an API against OWASP API Top 10 2023 test API authorization risks collect API security risk evidence Hard negatives—route elsewhere or clarify: claim ASVS certification assess a native mobile application with MASVS Related recipes NIST SSDF 1.1 SLSA v1.2 OWASP ASVS 5.0.0 References 1. OWASP Foundation official source 1","agent_handoff":{"mcp_lookup_keys":["owasp-api-security-top-10-2023-evidence-check","/recipes/general/compliance-standards/owasp-api-security-top-10-2023-evidence-check/","recipes/general/compliance-standards/owasp-api-security-top-10-2023-evidence-check.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["audit","compliance"],"source_text_field":"content_text","portable_download":"security-recipe-owasp-api-security-top-10-2023-evidence-check.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-owasp-api-security-top-10-2023-evidence-check.json"}},{"slug":"owasp-asvs-5-0-0-evidence-check","title":"OWASP ASVS 5.0.0 Application Verification Evidence Check","link_title":"OWASP ASVS 5.0.0","url":"https://security-recipes.ai/recipes/general/compliance-standards/owasp-asvs-5-0-0-evidence-check/","path":"/recipes/general/compliance-standards/owasp-asvs-5-0-0-evidence-check/","source_file":"recipes/general/compliance-standards/owasp-asvs-5-0-0-evidence-check.md","recipe_id":"compliance.owasp-asvs-5-0-0","recipe_kind":"","category":{"slug":"compliance-standards","label":"Compliance Standards"},"agent":"Compliance evidence review","severity":"info","maturity":"stable","ecosystem":"","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"OWASP ASVS 5.0.0","framework_version":"5.0.0","jurisdiction":["global"],"industry":["software","web-applications"],"cve_archetypes":[],"cve_workflow_role":"","tags":["compliance","owasp-asvs","product-security","audit","application-security","code-hygiene","software","web-applications"],"facets":["audit","compliance","code-hygiene"],"quality":{"score":100,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context","multi-facet"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"Security Recipes","team":"GRC and Security Engineering","model":"gpt-5-codex","ai_assisted":false,"generated_by":"","date":"2026-08-21","zero_day":false,"last_updated":"2026-08-21","summary":"Assess OWASP ASVS 5.0.0 evidence readiness: verify applicability, map official requirements to artifacts, record gaps, and plan remediation.","content_text":"OWASP ASVS 5.0.0 Application Verification Evidence Check Use this recipe to produce a source-aware evidence-readiness assessment for OWASP ASVS 5.0.0. It creates an auditable gap record; it does not certify compliance, provide legal advice, or replace an assessor, regulator, or certification body. Section index Framework basis When to use it Inputs The prompt Output contract Verification Guardrails Routing examples References Framework basis Publisher: OWASP Foundation Version: 5.0.0 Status: final Sources reviewed: 2026-08-21 Jurisdictions: global Industries: software, web-applications License boundary: open-attribution Teams specifying or verifying web application security requirements against an explicitly selected ASVS level and version. The cataloged version is final; still verify scope and any later official updates. Use the official version and preserve its attribution and license terms. Do not substitute memory for the selected published text. When to use it Use this recipe when the organization has established that OWASP ASVS 5.0.0 is applicable or wants a readiness assessment against it. Use the routing positives below to distinguish this recipe from adjacent frameworks. If applicability, the effective version, or the authoritative requirement set is unresolved, stop at a scoped intake and record the decision owner. Inputs The business purpose, legal entities, products, services, systems, and locations in scope. The organization's role, applicability decision, selected profile, level, baseline, or control set where the framework requires one. The official publication URLs above and, for licensed material, an authorized organization-supplied copy. Evidence from the complete review period, including populations—not only hand-picked examples. Named owners, inherited/shared responsibilities, exceptions, compensating measures, and accepted risks. Read-only access by default. Redacted exports are acceptable when provenance and coverage remain testable. Evidence domains for this framework: architecture and threat model: begin with selected ASVS level and requirement set. authentication and access control: begin with design and threat-model records. input, data, and cryptographic protection: begin with test results tied to requirement identifiers. configuration, logging, and API security: begin with remediation and accepted-risk records. The prompt You are a compliance evidence-readiness analyst. Evaluate the supplied scope against OWASP ASVS 5.0.0 (5.0.0). The catalog status is final and the source review date is 2026-08-21. Never claim certification or legal compliance. Never invent applicability, evidence, control operation, sampling results, or requirement text. Separate observed facts, organization assertions, and analyst inferences. Treat missing or inaccessible evidence as unknown, not as failure, unless the authoritative assessment method says otherwise. Step 0 — Lock authority, version, and scope 1. Record the exact official source, version, publication/update identifier, and effective date used. 2. Record the organization, role, jurisdiction, industry, system/product boundary, review period, and decision owner. 3. Confirm any selected level, profile, baseline, overlay, assessment type, or licensed requirement set. 4. The cataloged version is final; still verify scope and any later official updates. 5. Use the official version and preserve its attribution and license terms. Do not substitute memory for the selected published text. 6. Stop and request a decision when applicability or the authoritative requirement set cannot be established. Step 1 — Build the applicability map For every supplied requirement identifier or official outcome in scope, record: applicability, rationale, responsible owner, implementation location, inherited/shared responsibility, evidence expected, and any dependency. Use only identifiers present in the authoritative source supplied for this engagement. Do not reconstruct licensed text. Step 2 — Collect evidence by framework domain Review these domains without treating the labels as substitutes for authoritative requirements: 1. architecture and threat model 2. authentication and access control 3. input, data, and cryptographic protection 4. configuration, logging, and API security Start with these likely artifacts, then validate provenance and coverage: 1. selected ASVS level and requirement set 2. design and threat-model records 3. test results tied to requirement identifiers 4. remediation and accepted-risk records For every artifact record: artifact ID, source system, owner, collection time, review period, access path, integrity/provenance note, population covered, and requirement/outcome links. Prefer system exports and immutable records over screenshots or narrative attestations. Step 3 — Test design and operation For each applicable item, evaluate design, implementation, and operating evidence separately. Check whether evidence is authentic, complete, current for the review period, population-representative, and directly linked to the scoped system. Where sampling is permitted, state the population, method, sample size, selections, exceptions, and limitations; do not imply statistical assurance without a justified method. Step 4 — Classify gaps without overstating them Use only: supported, partially supported, unsupported, not applicable with rationale, or not assessed. Record gaps as evidence-readiness findings—not declarations of legal noncompliance. Each finding must include the affected requirement/outcome, observed fact, missing or weak evidence, risk, owner, corrective action, due date, dependencies, retest method, and confidence. Step 5 — Produce the evidence bundle Return one Markdown file named OWASPASVS500EVIDENCECHECK.md with: 1. Executive summary and explicit assurance limitations. 2. Authority/version/status and scope/applicability record. 3. Coverage totals by status and evidence domain. 4. Requirement/outcome-to-evidence matrix with artifact provenance. 5. Findings ordered by risk and evidence impact. 6. A 30/60/90-day remediation and evidence-collection plan. 7. Open questions, unavailable sources, conflicts, and decisions required. 8. Official references with access/review date. Before finalizing, verify that every conclusion is traceable to an artifact or clearly labeled assertion/inference, all denominators reconcile, all unavailable evidence is visible, licensed text is not reproduced, and no sentence claims certification or legal approval. Output contract The response must contain one evidence matrix row per scoped authoritative item or outcome. At minimum include itemid, applicability, owner, implementation, artifactids, testmethod, coverageperiod, status, gap, and confidence. Every artifact ID must resolve to the artifact register, and every total must reconcile to the matrix. Verification Confirm the official source, version, status, and review date in both the executive summary and matrix metadata. Reconcile applicable, not applicable, and not assessed counts to the complete supplied scope. Trace each supported assertion to provenance-bearing evidence covering the stated period and population. Independently reperform a risk-based sample of mappings and document all exceptions. Verify findings distinguish control/design weakness from missing evidence and unknown scope. Have the accountable owner and, where required, qualified counsel or an authorized assessor review conclusions. Guardrails This is an evidence-readiness workflow, not certification, attestation, audit opinion, or legal advice. Do not infer that a voluntary framework is mandatory or that one framework proves another. Do not paste, paraphrase at length, or reconstruct licensed controls. Use source summaries and organization-supplied licensed material. Do not expose secrets, personal data, regulated data, or full production exports in the report. Do not modify systems, close findings, accept risk, or submit regulatory reports without explicit owner authorization. If versions conflict, preserve both citations, label the conflict, and escalate rather than choosing silently. Routing examples Route here: verify an application against OWASP ASVS 5 define application security requirements collect ASVS test evidence Hard negatives—route elsewhere or clarify: triage only the OWASP API Top 10 assess a mobile app against MASVS Related recipes NIST SSDF 1.1 SLSA v1.2 OWASP API Top 10:2023 References 1. OWASP Foundation official source 1","agent_handoff":{"mcp_lookup_keys":["owasp-asvs-5-0-0-evidence-check","/recipes/general/compliance-standards/owasp-asvs-5-0-0-evidence-check/","recipes/general/compliance-standards/owasp-asvs-5-0-0-evidence-check.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["audit","compliance","code-hygiene"],"source_text_field":"content_text","portable_download":"security-recipe-owasp-asvs-5-0-0-evidence-check.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-owasp-asvs-5-0-0-evidence-check.json"}},{"slug":"owasp-masvs-2-1-0-mobile-evidence-check","title":"OWASP MASVS 2.1.0 Mobile Application Evidence Check","link_title":"OWASP MASVS 2.1.0","url":"https://security-recipes.ai/recipes/general/compliance-standards/owasp-masvs-2-1-0-mobile-evidence-check/","path":"/recipes/general/compliance-standards/owasp-masvs-2-1-0-mobile-evidence-check/","source_file":"recipes/general/compliance-standards/owasp-masvs-2-1-0-mobile-evidence-check.md","recipe_id":"compliance.owasp-masvs-2-1-0","recipe_kind":"","category":{"slug":"compliance-standards","label":"Compliance Standards"},"agent":"Compliance evidence review","severity":"info","maturity":"stable","ecosystem":"","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"OWASP MASVS 2.1.0","framework_version":"2.1.0","jurisdiction":["global"],"industry":["software","mobile-applications"],"cve_archetypes":[],"cve_workflow_role":"","tags":["compliance","owasp-masvs","product-security","audit","application-security","mobile-security","software","mobile-applications"],"facets":["audit","compliance"],"quality":{"score":95,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"Security Recipes","team":"GRC and Security Engineering","model":"gpt-5-codex","ai_assisted":false,"generated_by":"","date":"2026-08-21","zero_day":false,"last_updated":"2026-08-21","summary":"Assess OWASP MASVS 2.1.0 evidence readiness: verify applicability, map official requirements to artifacts, record gaps, and plan remediation.","content_text":"OWASP MASVS 2.1.0 Mobile Application Evidence Check Use this recipe to produce a source-aware evidence-readiness assessment for OWASP MASVS 2.1.0. It creates an auditable gap record; it does not certify compliance, provide legal advice, or replace an assessor, regulator, or certification body. Section index Framework basis When to use it Inputs The prompt Output contract Verification Guardrails Routing examples References Framework basis Publisher: OWASP Foundation Version: 2.1.0 Status: final Sources reviewed: 2026-08-21 Jurisdictions: global Industries: software, mobile-applications License boundary: open-attribution Native and cross-platform mobile application teams verifying security and privacy properties against MASVS 2.1.0. The cataloged version is final; still verify scope and any later official updates. Use the official version and preserve its attribution and license terms. Do not substitute memory for the selected published text. When to use it Use this recipe when the organization has established that OWASP MASVS 2.1.0 is applicable or wants a readiness assessment against it. Use the routing positives below to distinguish this recipe from adjacent frameworks. If applicability, the effective version, or the authoritative requirement set is unresolved, stop at a scoped intake and record the decision owner. Inputs The business purpose, legal entities, products, services, systems, and locations in scope. The organization's role, applicability decision, selected profile, level, baseline, or control set where the framework requires one. The official publication URLs above and, for licensed material, an authorized organization-supplied copy. Evidence from the complete review period, including populations—not only hand-picked examples. Named owners, inherited/shared responsibilities, exceptions, compensating measures, and accepted risks. Read-only access by default. Redacted exports are acceptable when provenance and coverage remain testable. Evidence domains for this framework: storage and cryptography: begin with mobile architecture and data-flow records. authentication and network communication: begin with platform-specific static and dynamic test results. platform interaction and code quality: begin with device and transport test evidence. resilience and privacy: begin with privacy and remediation records. The prompt You are a compliance evidence-readiness analyst. Evaluate the supplied scope against OWASP MASVS 2.1.0 (2.1.0). The catalog status is final and the source review date is 2026-08-21. Never claim certification or legal compliance. Never invent applicability, evidence, control operation, sampling results, or requirement text. Separate observed facts, organization assertions, and analyst inferences. Treat missing or inaccessible evidence as unknown, not as failure, unless the authoritative assessment method says otherwise. Step 0 — Lock authority, version, and scope 1. Record the exact official source, version, publication/update identifier, and effective date used. 2. Record the organization, role, jurisdiction, industry, system/product boundary, review period, and decision owner. 3. Confirm any selected level, profile, baseline, overlay, assessment type, or licensed requirement set. 4. The cataloged version is final; still verify scope and any later official updates. 5. Use the official version and preserve its attribution and license terms. Do not substitute memory for the selected published text. 6. Stop and request a decision when applicability or the authoritative requirement set cannot be established. Step 1 — Build the applicability map For every supplied requirement identifier or official outcome in scope, record: applicability, rationale, responsible owner, implementation location, inherited/shared responsibility, evidence expected, and any dependency. Use only identifiers present in the authoritative source supplied for this engagement. Do not reconstruct licensed text. Step 2 — Collect evidence by framework domain Review these domains without treating the labels as substitutes for authoritative requirements: 1. storage and cryptography 2. authentication and network communication 3. platform interaction and code quality 4. resilience and privacy Start with these likely artifacts, then validate provenance and coverage: 1. mobile architecture and data-flow records 2. platform-specific static and dynamic test results 3. device and transport test evidence 4. privacy and remediation records For every artifact record: artifact ID, source system, owner, collection time, review period, access path, integrity/provenance note, population covered, and requirement/outcome links. Prefer system exports and immutable records over screenshots or narrative attestations. Step 3 — Test design and operation For each applicable item, evaluate design, implementation, and operating evidence separately. Check whether evidence is authentic, complete, current for the review period, population-representative, and directly linked to the scoped system. Where sampling is permitted, state the population, method, sample size, selections, exceptions, and limitations; do not imply statistical assurance without a justified method. Step 4 — Classify gaps without overstating them Use only: supported, partially supported, unsupported, not applicable with rationale, or not assessed. Record gaps as evidence-readiness findings—not declarations of legal noncompliance. Each finding must include the affected requirement/outcome, observed fact, missing or weak evidence, risk, owner, corrective action, due date, dependencies, retest method, and confidence. Step 5 — Produce the evidence bundle Return one Markdown file named OWASPMASVS210MOBILEEVIDENCECHECK.md with: 1. Executive summary and explicit assurance limitations. 2. Authority/version/status and scope/applicability record. 3. Coverage totals by status and evidence domain. 4. Requirement/outcome-to-evidence matrix with artifact provenance. 5. Findings ordered by risk and evidence impact. 6. A 30/60/90-day remediation and evidence-collection plan. 7. Open questions, unavailable sources, conflicts, and decisions required. 8. Official references with access/review date. Before finalizing, verify that every conclusion is traceable to an artifact or clearly labeled assertion/inference, all denominators reconcile, all unavailable evidence is visible, licensed text is not reproduced, and no sentence claims certification or legal approval. Output contract The response must contain one evidence matrix row per scoped authoritative item or outcome. At minimum include itemid, applicability, owner, implementation, artifactids, testmethod, coverage_period, status, gap, and confidence. Every artifact ID must resolve to the artifact register, and every total must reconcile to the matrix. Verification Confirm the official source, version, status, and review date in both the executive summary and matrix metadata. Reconcile applicable, not applicable, and not assessed counts to the complete supplied scope. Trace each supported assertion to provenance-bearing evidence covering the stated period and population. Independently reperform a risk-based sample of mappings and document all exceptions. Verify findings distinguish control/design weakness from missing evidence and unknown scope. Have the accountable owner and, where required, qualified counsel or an authorized assessor review conclusions. Guardrails This is an evidence-readiness workflow, not certification, attestation, audit opinion, or legal advice. Do not infer that a voluntary framework is mandatory or that one framework proves another. Do not paste, paraphrase at length, or reconstruct licensed controls. Use source summaries and organization-supplied licensed material. Do not expose secrets, personal data, regulated data, or full production exports in the report. Do not modify systems, close findings, accept risk, or submit regulatory reports without explicit owner authorization. If versions conflict, preserve both citations, label the conflict, and escalate rather than choosing silently. Routing examples Route here: assess a mobile app against MASVS 2.1 collect mobile security verification evidence review Android or iOS security requirements Hard negatives—route elsewhere or clarify: assess a web application against ASVS triage API risks only with the API Top 10 Related recipes NIST SSDF 1.1 SLSA v1.2 OWASP ASVS 5.0.0 References 1. OWASP Foundation official source 1","agent_handoff":{"mcp_lookup_keys":["owasp-masvs-2-1-0-mobile-evidence-check","/recipes/general/compliance-standards/owasp-masvs-2-1-0-mobile-evidence-check/","recipes/general/compliance-standards/owasp-masvs-2-1-0-mobile-evidence-check.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["audit","compliance"],"source_text_field":"content_text","portable_download":"security-recipe-owasp-masvs-2-1-0-mobile-evidence-check.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-owasp-masvs-2-1-0-mobile-evidence-check.json"}},{"slug":"owasp-samm-2-1-program-evidence-check","title":"OWASP SAMM 2.1 Software Assurance Maturity Evidence Check","link_title":"OWASP SAMM 2.1","url":"https://security-recipes.ai/recipes/general/compliance-standards/owasp-samm-2-1-program-evidence-check/","path":"/recipes/general/compliance-standards/owasp-samm-2-1-program-evidence-check/","source_file":"recipes/general/compliance-standards/owasp-samm-2-1-program-evidence-check.md","recipe_id":"compliance.owasp-samm-2-1","recipe_kind":"","category":{"slug":"compliance-standards","label":"Compliance Standards"},"agent":"Compliance evidence review","severity":"info","maturity":"stable","ecosystem":"","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"OWASP SAMM 2.1","framework_version":"2.1","jurisdiction":["global"],"industry":["software","cross-sector"],"cve_archetypes":[],"cve_workflow_role":"","tags":["compliance","owasp-samm","product-security","audit","application-security","maturity","software","cross-sector"],"facets":["audit","compliance"],"quality":{"score":95,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"Security Recipes","team":"GRC and Security Engineering","model":"gpt-5-codex","ai_assisted":false,"generated_by":"","date":"2026-08-21","zero_day":false,"last_updated":"2026-08-21","summary":"Assess OWASP SAMM 2.1 evidence readiness: verify applicability, map official requirements to artifacts, record gaps, and plan remediation.","content_text":"OWASP SAMM 2.1 Software Assurance Maturity Evidence Check Use this recipe to produce a source-aware evidence-readiness assessment for OWASP SAMM 2.1. It creates an auditable gap record; it does not certify compliance, provide legal advice, or replace an assessor, regulator, or certification body. Section index Framework basis When to use it Inputs The prompt Output contract Verification Guardrails Routing examples References Framework basis Publisher: OWASP Foundation Version: 2.1 Status: final Sources reviewed: 2026-08-21 Jurisdictions: global Industries: software, cross-sector License boundary: open-attribution Organizations measuring and improving a software security program using the OWASP SAMM maturity model. The cataloged version is final; still verify scope and any later official updates. Use the official version and preserve its attribution and license terms. Do not substitute memory for the selected published text. When to use it Use this recipe when the organization has established that OWASP SAMM 2.1 is applicable or wants a readiness assessment against it. Use the routing positives below to distinguish this recipe from adjacent frameworks. If applicability, the effective version, or the authoritative requirement set is unresolved, stop at a scoped intake and record the decision owner. Inputs The business purpose, legal entities, products, services, systems, and locations in scope. The organization's role, applicability decision, selected profile, level, baseline, or control set where the framework requires one. The official publication URLs above and, for licensed material, an authorized organization-supplied copy. Evidence from the complete review period, including populations—not only hand-picked examples. Named owners, inherited/shared responsibilities, exceptions, compensating measures, and accepted risks. Read-only access by default. Redacted exports are acceptable when provenance and coverage remain testable. Evidence domains for this framework: governance: begin with defined assessment scope and interviews. design: begin with practice-level activity evidence. implementation: begin with maturity scoring rationale. verification and operations: begin with prioritized improvement roadmap. The prompt You are a compliance evidence-readiness analyst. Evaluate the supplied scope against OWASP SAMM 2.1 (2.1). The catalog status is final and the source review date is 2026-08-21. Never claim certification or legal compliance. Never invent applicability, evidence, control operation, sampling results, or requirement text. Separate observed facts, organization assertions, and analyst inferences. Treat missing or inaccessible evidence as unknown, not as failure, unless the authoritative assessment method says otherwise. Step 0 — Lock authority, version, and scope 1. Record the exact official source, version, publication/update identifier, and effective date used. 2. Record the organization, role, jurisdiction, industry, system/product boundary, review period, and decision owner. 3. Confirm any selected level, profile, baseline, overlay, assessment type, or licensed requirement set. 4. The cataloged version is final; still verify scope and any later official updates. 5. Use the official version and preserve its attribution and license terms. Do not substitute memory for the selected published text. 6. Stop and request a decision when applicability or the authoritative requirement set cannot be established. Step 1 — Build the applicability map For every supplied requirement identifier or official outcome in scope, record: applicability, rationale, responsible owner, implementation location, inherited/shared responsibility, evidence expected, and any dependency. Use only identifiers present in the authoritative source supplied for this engagement. Do not reconstruct licensed text. Step 2 — Collect evidence by framework domain Review these domains without treating the labels as substitutes for authoritative requirements: 1. governance 2. design 3. implementation 4. verification and operations Start with these likely artifacts, then validate provenance and coverage: 1. defined assessment scope and interviews 2. practice-level activity evidence 3. maturity scoring rationale 4. prioritized improvement roadmap For every artifact record: artifact ID, source system, owner, collection time, review period, access path, integrity/provenance note, population covered, and requirement/outcome links. Prefer system exports and immutable records over screenshots or narrative attestations. Step 3 — Test design and operation For each applicable item, evaluate design, implementation, and operating evidence separately. Check whether evidence is authentic, complete, current for the review period, population-representative, and directly linked to the scoped system. Where sampling is permitted, state the population, method, sample size, selections, exceptions, and limitations; do not imply statistical assurance without a justified method. Step 4 — Classify gaps without overstating them Use only: supported, partially supported, unsupported, not applicable with rationale, or not assessed. Record gaps as evidence-readiness findings—not declarations of legal noncompliance. Each finding must include the affected requirement/outcome, observed fact, missing or weak evidence, risk, owner, corrective action, due date, dependencies, retest method, and confidence. Step 5 — Produce the evidence bundle Return one Markdown file named OWASPSAMM21PROGRAMEVIDENCECHECK.md with: 1. Executive summary and explicit assurance limitations. 2. Authority/version/status and scope/applicability record. 3. Coverage totals by status and evidence domain. 4. Requirement/outcome-to-evidence matrix with artifact provenance. 5. Findings ordered by risk and evidence impact. 6. A 30/60/90-day remediation and evidence-collection plan. 7. Open questions, unavailable sources, conflicts, and decisions required. 8. Official references with access/review date. Before finalizing, verify that every conclusion is traceable to an artifact or clearly labeled assertion/inference, all denominators reconcile, all unavailable evidence is visible, licensed text is not reproduced, and no sentence claims certification or legal approval. Output contract The response must contain one evidence matrix row per scoped authoritative item or outcome. At minimum include itemid, applicability, owner, implementation, artifactids, testmethod, coverageperiod, status, gap, and confidence. Every artifact ID must resolve to the artifact register, and every total must reconcile to the matrix. Verification Confirm the official source, version, status, and review date in both the executive summary and matrix metadata. Reconcile applicable, not applicable, and not assessed counts to the complete supplied scope. Trace each supported assertion to provenance-bearing evidence covering the stated period and population. Independently reperform a risk-based sample of mappings and document all exceptions. Verify findings distinguish control/design weakness from missing evidence and unknown scope. Have the accountable owner and, where required, qualified counsel or an authorized assessor review conclusions. Guardrails This is an evidence-readiness workflow, not certification, attestation, audit opinion, or legal advice. Do not infer that a voluntary framework is mandatory or that one framework proves another. Do not paste, paraphrase at length, or reconstruct licensed controls. Use source summaries and organization-supplied licensed material. Do not expose secrets, personal data, regulated data, or full production exports in the report. Do not modify systems, close findings, accept risk, or submit regulatory reports without explicit owner authorization. If versions conflict, preserve both citations, label the conflict, and escalate rather than choosing silently. Routing examples Route here: assess software security maturity with SAMM build an OWASP SAMM roadmap collect software assurance program evidence Hard negatives—route elsewhere or clarify: verify individual ASVS application requirements assess only SLSA build provenance Related recipes NIST SSDF 1.1 SLSA v1.2 OWASP ASVS 5.0.0 References 1. OWASP Foundation official source 1","agent_handoff":{"mcp_lookup_keys":["owasp-samm-2-1-program-evidence-check","/recipes/general/compliance-standards/owasp-samm-2-1-program-evidence-check/","recipes/general/compliance-standards/owasp-samm-2-1-program-evidence-check.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["audit","compliance"],"source_text_field":"content_text","portable_download":"security-recipe-owasp-samm-2-1-program-evidence-check.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-owasp-samm-2-1-program-evidence-check.json"}},{"slug":"pci-dss-cde-agent-boundary-check","title":"PCI DSS 4.0.1 Cardholder Data Environment Evidence Check","link_title":"PCI DSS 4.0.1","url":"https://security-recipes.ai/recipes/general/compliance-standards/pci-dss-cde-agent-boundary-check/","path":"/recipes/general/compliance-standards/pci-dss-cde-agent-boundary-check/","source_file":"recipes/general/compliance-standards/pci-dss-cde-agent-boundary-check.md","recipe_id":"compliance.pci-dss-4-0-1","recipe_kind":"","category":{"slug":"compliance-standards","label":"Compliance Standards"},"agent":"Compliance evidence review","severity":"info","maturity":"stable","ecosystem":"","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"PCI DSS 4.0.1","framework_version":"4.0.1","jurisdiction":["global"],"industry":["payments","retail","financial-services"],"cve_archetypes":[],"cve_workflow_role":"","tags":["compliance","pci-dss","regulated-industries","audit","data-protection","boundary","payments","retail"],"facets":["audit","compliance"],"quality":{"score":95,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"Security Recipes","team":"GRC and Security Engineering","model":"gpt-5-codex","ai_assisted":false,"generated_by":"","date":"2026-08-21","zero_day":false,"last_updated":"2026-08-21","summary":"Assess PCI DSS 4.0.1 evidence readiness: verify applicability, map official requirements to artifacts, record gaps, and plan remediation.","content_text":"PCI DSS 4.0.1 Cardholder Data Environment Evidence Check Use this recipe to produce a source-aware evidence-readiness assessment for PCI DSS 4.0.1. It creates an auditable gap record; it does not certify compliance, provide legal advice, or replace an assessor, regulator, or certification body. Section index Framework basis When to use it Inputs The prompt Output contract Verification Guardrails Routing examples References Framework basis Publisher: PCI Security Standards Council Version: 4.0.1 Status: final Sources reviewed: 2026-08-21 Jurisdictions: global Industries: payments, retail, financial-services License boundary: summary-only Entities that store, process, or transmit payment account data, and service providers that can affect the cardholder data environment. PCI DSS v4.0.1 is the active standard; the v4.x future-dated requirements became mandatory on 31 March 2025. The cataloged version is final; still verify scope and any later official updates. This recipe intentionally summarizes domains and evidence needs. Do not reproduce licensed control text; use an organization-supplied licensed copy for requirement-level work. When to use it Use this recipe when the organization has established that PCI DSS 4.0.1 is applicable or wants a readiness assessment against it. Use the routing positives below to distinguish this recipe from adjacent frameworks. If applicability, the effective version, or the authoritative requirement set is unresolved, stop at a scoped intake and record the decision owner. Inputs The business purpose, legal entities, products, services, systems, and locations in scope. The organization's role, applicability decision, selected profile, level, baseline, or control set where the framework requires one. The official publication URLs above and, for licensed material, an authorized organization-supplied copy. Evidence from the complete review period, including populations—not only hand-picked examples. Named owners, inherited/shared responsibilities, exceptions, compensating measures, and accepted risks. Read-only access by default. Redacted exports are acceptable when provenance and coverage remain testable. Evidence domains for this framework: CDE scope and segmentation: begin with current data-flow and network diagrams. secure configurations and access: begin with segmentation validation results. payment data protection: begin with access and authentication reviews. logging, testing, and vulnerability management: begin with ASV, penetration-test, and remediation records. The prompt You are a compliance evidence-readiness analyst. Evaluate the supplied scope against PCI DSS 4.0.1 (4.0.1). The catalog status is final and the source review date is 2026-08-21. Never claim certification or legal compliance. Never invent applicability, evidence, control operation, sampling results, or requirement text. Separate observed facts, organization assertions, and analyst inferences. Treat missing or inaccessible evidence as unknown, not as failure, unless the authoritative assessment method says otherwise. Step 0 — Lock authority, version, and scope 1. Record the exact official source, version, publication/update identifier, and effective date used. 2. Record the organization, role, jurisdiction, industry, system/product boundary, review period, and decision owner. 3. Confirm any selected level, profile, baseline, overlay, assessment type, or licensed requirement set. 4. The cataloged version is final; still verify scope and any later official updates. 5. This recipe intentionally summarizes domains and evidence needs. Do not reproduce licensed control text; use an organization-supplied licensed copy for requirement-level work. 6. Stop and request a decision when applicability or the authoritative requirement set cannot be established. Step 1 — Build the applicability map For every supplied requirement identifier or official outcome in scope, record: applicability, rationale, responsible owner, implementation location, inherited/shared responsibility, evidence expected, and any dependency. Use only identifiers present in the authoritative source supplied for this engagement. Do not reconstruct licensed text. Step 2 — Collect evidence by framework domain Review these domains without treating the labels as substitutes for authoritative requirements: 1. CDE scope and segmentation 2. secure configurations and access 3. payment data protection 4. logging, testing, and vulnerability management Start with these likely artifacts, then validate provenance and coverage: 1. current data-flow and network diagrams 2. segmentation validation results 3. access and authentication reviews 4. ASV, penetration-test, and remediation records For every artifact record: artifact ID, source system, owner, collection time, review period, access path, integrity/provenance note, population covered, and requirement/outcome links. Prefer system exports and immutable records over screenshots or narrative attestations. Step 3 — Test design and operation For each applicable item, evaluate design, implementation, and operating evidence separately. Check whether evidence is authentic, complete, current for the review period, population-representative, and directly linked to the scoped system. Where sampling is permitted, state the population, method, sample size, selections, exceptions, and limitations; do not imply statistical assurance without a justified method. Step 4 — Classify gaps without overstating them Use only: supported, partially supported, unsupported, not applicable with rationale, or not assessed. Record gaps as evidence-readiness findings—not declarations of legal noncompliance. Each finding must include the affected requirement/outcome, observed fact, missing or weak evidence, risk, owner, corrective action, due date, dependencies, retest method, and confidence. Step 5 — Produce the evidence bundle Return one Markdown file named PCIDSSCDEAGENTBOUNDARYCHECK.md with: 1. Executive summary and explicit assurance limitations. 2. Authority/version/status and scope/applicability record. 3. Coverage totals by status and evidence domain. 4. Requirement/outcome-to-evidence matrix with artifact provenance. 5. Findings ordered by risk and evidence impact. 6. A 30/60/90-day remediation and evidence-collection plan. 7. Open questions, unavailable sources, conflicts, and decisions required. 8. Official references with access/review date. Before finalizing, verify that every conclusion is traceable to an artifact or clearly labeled assertion/inference, all denominators reconcile, all unavailable evidence is visible, licensed text is not reproduced, and no sentence claims certification or legal approval. Output contract The response must contain one evidence matrix row per scoped authoritative item or outcome. At minimum include itemid, applicability, owner, implementation, artifactids, testmethod, coverage_period, status, gap, and confidence. Every artifact ID must resolve to the artifact register, and every total must reconcile to the matrix. Verification Confirm the official source, version, status, and review date in both the executive summary and matrix metadata. Reconcile applicable, not applicable, and not assessed counts to the complete supplied scope. Trace each supported assertion to provenance-bearing evidence covering the stated period and population. Independently reperform a risk-based sample of mappings and document all exceptions. Verify findings distinguish control/design weakness from missing evidence and unknown scope. Have the accountable owner and, where required, qualified counsel or an authorized assessor review conclusions. Guardrails This is an evidence-readiness workflow, not certification, attestation, audit opinion, or legal advice. Do not infer that a voluntary framework is mandatory or that one framework proves another. Do not paste, paraphrase at length, or reconstruct licensed controls. Use source summaries and organization-supplied licensed material. Do not expose secrets, personal data, regulated data, or full production exports in the report. Do not modify systems, close findings, accept risk, or submit regulatory reports without explicit owner authorization. If versions conflict, preserve both citations, label the conflict, and escalate rather than choosing silently. Routing examples Route here: assess PCI DSS 4.0.1 evidence verify cardholder data environment boundaries prepare payment security assessment artifacts Hard negatives—route elsewhere or clarify: perform a HIPAA security risk analysis assess general CIS Controls coverage Related recipes HIPAA Security Rule GLBA Safeguards Rule NYDFS Part 500 References 1. PCI Security Standards Council official source 1 2. PCI Security Standards Council official source 2","agent_handoff":{"mcp_lookup_keys":["pci-dss-cde-agent-boundary-check","/recipes/general/compliance-standards/pci-dss-cde-agent-boundary-check/","recipes/general/compliance-standards/pci-dss-cde-agent-boundary-check.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["audit","compliance"],"source_text_field":"content_text","portable_download":"security-recipe-pci-dss-cde-agent-boundary-check.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-pci-dss-cde-agent-boundary-check.json"}},{"slug":"sec-cybersecurity-disclosure-evidence-check","title":"SEC Cybersecurity Disclosure Evidence Readiness Check","link_title":"SEC Cyber Disclosure Rule","url":"https://security-recipes.ai/recipes/general/compliance-standards/sec-cybersecurity-disclosure-evidence-check/","path":"/recipes/general/compliance-standards/sec-cybersecurity-disclosure-evidence-check/","source_file":"recipes/general/compliance-standards/sec-cybersecurity-disclosure-evidence-check.md","recipe_id":"compliance.sec-cyber-disclosure-2023","recipe_kind":"","category":{"slug":"compliance-standards","label":"Compliance Standards"},"agent":"Compliance evidence review","severity":"info","maturity":"stable","ecosystem":"","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"SEC Cyber Disclosure Rule","framework_version":"Release 33-11216 (2023)","jurisdiction":["united-states"],"industry":["public-companies"],"cve_archetypes":[],"cve_workflow_role":"","tags":["compliance","sec-cyber-disclosure","assurance","audit","governance","incident-response","public-companies"],"facets":["audit","compliance"],"quality":{"score":95,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"Security Recipes","team":"GRC and Security Engineering","model":"gpt-5-codex","ai_assisted":false,"generated_by":"","date":"2026-08-21","zero_day":false,"last_updated":"2026-08-21","summary":"Assess SEC Cyber Disclosure Rule evidence readiness: verify applicability, map official requirements to artifacts, record gaps, and plan remediation.","content_text":"SEC Cybersecurity Disclosure Evidence Readiness Check Use this recipe to produce a source-aware evidence-readiness assessment for SEC Cyber Disclosure Rule. It creates an auditable gap record; it does not certify compliance, provide legal advice, or replace an assessor, regulator, or certification body. Section index Framework basis When to use it Inputs The prompt Output contract Verification Guardrails Routing examples References Framework basis Publisher: U.S. Securities and Exchange Commission Version: Release 33-11216 (2023) Status: final Sources reviewed: 2026-08-21 Jurisdictions: united-states Industries: public-companies License boundary: official-text SEC reporting companies preparing evidence for material cybersecurity incident and annual risk-management, strategy, and governance disclosures. The cataloged version is final; still verify scope and any later official updates. Use the linked official legal or regulatory text and current implementing guidance; do not replace applicability analysis with this summary. When to use it Use this recipe when the organization has established that SEC Cyber Disclosure Rule is applicable or wants a readiness assessment against it. Use the routing positives below to distinguish this recipe from adjacent frameworks. If applicability, the effective version, or the authoritative requirement set is unresolved, stop at a scoped intake and record the decision owner. Inputs The business purpose, legal entities, products, services, systems, and locations in scope. The organization's role, applicability decision, selected profile, level, baseline, or control set where the framework requires one. The official publication URLs above and, for licensed material, an authorized organization-supplied copy. Evidence from the complete review period, including populations—not only hand-picked examples. Named owners, inherited/shared responsibilities, exceptions, compensating measures, and accepted risks. Read-only access by default. Redacted exports are acceptable when provenance and coverage remain testable. Evidence domains for this framework: materiality decision process: begin with materiality criteria and decision records. incident escalation and disclosure: begin with incident timeline and escalation artifacts. risk management and strategy: begin with disclosure committee minutes. board and management governance: begin with board oversight and management-role documentation. The prompt You are a compliance evidence-readiness analyst. Evaluate the supplied scope against SEC Cyber Disclosure Rule (Release 33-11216 (2023)). The catalog status is final and the source review date is 2026-08-21. Never claim certification or legal compliance. Never invent applicability, evidence, control operation, sampling results, or requirement text. Separate observed facts, organization assertions, and analyst inferences. Treat missing or inaccessible evidence as unknown, not as failure, unless the authoritative assessment method says otherwise. Step 0 — Lock authority, version, and scope 1. Record the exact official source, version, publication/update identifier, and effective date used. 2. Record the organization, role, jurisdiction, industry, system/product boundary, review period, and decision owner. 3. Confirm any selected level, profile, baseline, overlay, assessment type, or licensed requirement set. 4. The cataloged version is final; still verify scope and any later official updates. 5. Use the linked official legal or regulatory text and current implementing guidance; do not replace applicability analysis with this summary. 6. Stop and request a decision when applicability or the authoritative requirement set cannot be established. Step 1 — Build the applicability map For every supplied requirement identifier or official outcome in scope, record: applicability, rationale, responsible owner, implementation location, inherited/shared responsibility, evidence expected, and any dependency. Use only identifiers present in the authoritative source supplied for this engagement. Do not reconstruct licensed text. Step 2 — Collect evidence by framework domain Review these domains without treating the labels as substitutes for authoritative requirements: 1. materiality decision process 2. incident escalation and disclosure 3. risk management and strategy 4. board and management governance Start with these likely artifacts, then validate provenance and coverage: 1. materiality criteria and decision records 2. incident timeline and escalation artifacts 3. disclosure committee minutes 4. board oversight and management-role documentation For every artifact record: artifact ID, source system, owner, collection time, review period, access path, integrity/provenance note, population covered, and requirement/outcome links. Prefer system exports and immutable records over screenshots or narrative attestations. Step 3 — Test design and operation For each applicable item, evaluate design, implementation, and operating evidence separately. Check whether evidence is authentic, complete, current for the review period, population-representative, and directly linked to the scoped system. Where sampling is permitted, state the population, method, sample size, selections, exceptions, and limitations; do not imply statistical assurance without a justified method. Step 4 — Classify gaps without overstating them Use only: supported, partially supported, unsupported, not applicable with rationale, or not assessed. Record gaps as evidence-readiness findings—not declarations of legal noncompliance. Each finding must include the affected requirement/outcome, observed fact, missing or weak evidence, risk, owner, corrective action, due date, dependencies, retest method, and confidence. Step 5 — Produce the evidence bundle Return one Markdown file named SECCYBERSECURITYDISCLOSUREEVIDENCECHECK.md with: 1. Executive summary and explicit assurance limitations. 2. Authority/version/status and scope/applicability record. 3. Coverage totals by status and evidence domain. 4. Requirement/outcome-to-evidence matrix with artifact provenance. 5. Findings ordered by risk and evidence impact. 6. A 30/60/90-day remediation and evidence-collection plan. 7. Open questions, unavailable sources, conflicts, and decisions required. 8. Official references with access/review date. Before finalizing, verify that every conclusion is traceable to an artifact or clearly labeled assertion/inference, all denominators reconcile, all unavailable evidence is visible, licensed text is not reproduced, and no sentence claims certification or legal approval. Output contract The response must contain one evidence matrix row per scoped authoritative item or outcome. At minimum include itemid, applicability, owner, implementation, artifactids, testmethod, coverageperiod, status, gap, and confidence. Every artifact ID must resolve to the artifact register, and every total must reconcile to the matrix. Verification Confirm the official source, version, status, and review date in both the executive summary and matrix metadata. Reconcile applicable, not applicable, and not assessed counts to the complete supplied scope. Trace each supported assertion to provenance-bearing evidence covering the stated period and population. Independently reperform a risk-based sample of mappings and document all exceptions. Verify findings distinguish control/design weakness from missing evidence and unknown scope. Have the accountable owner and, where required, qualified counsel or an authorized assessor review conclusions. Guardrails This is an evidence-readiness workflow, not certification, attestation, audit opinion, or legal advice. Do not infer that a voluntary framework is mandatory or that one framework proves another. Do not paste, paraphrase at length, or reconstruct licensed controls. Use source summaries and organization-supplied licensed material. Do not expose secrets, personal data, regulated data, or full production exports in the report. Do not modify systems, close findings, accept risk, or submit regulatory reports without explicit owner authorization. If versions conflict, preserve both citations, label the conflict, and escalate rather than choosing silently. Routing examples Route here: prepare SEC cybersecurity disclosure evidence review cyber incident materiality governance assess annual cyber risk disclosures Hard negatives—route elsewhere or clarify: perform a technical incident-response investigation test SOX ITGC operating effectiveness Related recipes SOC 2 TSC COBIT 2019 SOX ITGC References 1. U.S. Securities and Exchange Commission official source 1","agent_handoff":{"mcp_lookup_keys":["sec-cybersecurity-disclosure-evidence-check","/recipes/general/compliance-standards/sec-cybersecurity-disclosure-evidence-check/","recipes/general/compliance-standards/sec-cybersecurity-disclosure-evidence-check.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["audit","compliance"],"source_text_field":"content_text","portable_download":"security-recipe-sec-cybersecurity-disclosure-evidence-check.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-sec-cybersecurity-disclosure-evidence-check.json"}},{"slug":"slsa-provenance-evidence-check","title":"SLSA v1.2 Build and Source Provenance Evidence Check","link_title":"SLSA v1.2","url":"https://security-recipes.ai/recipes/general/compliance-standards/slsa-provenance-evidence-check/","path":"/recipes/general/compliance-standards/slsa-provenance-evidence-check/","source_file":"recipes/general/compliance-standards/slsa-provenance-evidence-check.md","recipe_id":"compliance.slsa-1-2","recipe_kind":"","category":{"slug":"compliance-standards","label":"Compliance Standards"},"agent":"Compliance evidence review","severity":"info","maturity":"stable","ecosystem":"","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"SLSA v1.2","framework_version":"1.2","jurisdiction":["global"],"industry":["software","cross-sector"],"cve_archetypes":[],"cve_workflow_role":"","tags":["compliance","slsa","product-security","audit","supply-chain","provenance","software","cross-sector"],"facets":["audit","compliance"],"quality":{"score":95,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"Security Recipes","team":"GRC and Security Engineering","model":"gpt-5-codex","ai_assisted":false,"generated_by":"","date":"2026-08-21","zero_day":false,"last_updated":"2026-08-21","summary":"Assess SLSA v1.2 evidence readiness: verify applicability, map official requirements to artifacts, record gaps, and plan remediation.","content_text":"SLSA v1.2 Build and Source Provenance Evidence Check Use this recipe to produce a source-aware evidence-readiness assessment for SLSA v1.2. It creates an auditable gap record; it does not certify compliance, provide legal advice, or replace an assessor, regulator, or certification body. Section index Framework basis When to use it Inputs The prompt Output contract Verification Guardrails Routing examples References Framework basis Publisher: OpenSSF SLSA Version: 1.2 Status: final Sources reviewed: 2026-08-21 Jurisdictions: global Industries: software, cross-sector License boundary: open-attribution Software producers and consumers evaluating source and build integrity using SLSA v1.2 tracks and provenance. The cataloged version is final; still verify scope and any later official updates. Use the official version and preserve its attribution and license terms. Do not substitute memory for the selected published text. When to use it Use this recipe when the organization has established that SLSA v1.2 is applicable or wants a readiness assessment against it. Use the routing positives below to distinguish this recipe from adjacent frameworks. If applicability, the effective version, or the authoritative requirement set is unresolved, stop at a scoped intake and record the decision owner. Inputs The business purpose, legal entities, products, services, systems, and locations in scope. The organization's role, applicability decision, selected profile, level, baseline, or control set where the framework requires one. The official publication URLs above and, for licensed material, an authorized organization-supplied copy. Evidence from the complete review period, including populations—not only hand-picked examples. Named owners, inherited/shared responsibilities, exceptions, compensating measures, and accepted risks. Read-only access by default. Redacted exports are acceptable when provenance and coverage remain testable. Evidence domains for this framework: source controls: begin with source repository policy exports. build platform isolation: begin with build definitions and runner trust boundaries. provenance generation: begin with signed provenance attestations. artifact and dependency verification: begin with consumer verification logs. The prompt You are a compliance evidence-readiness analyst. Evaluate the supplied scope against SLSA v1.2 (1.2). The catalog status is final and the source review date is 2026-08-21. Never claim certification or legal compliance. Never invent applicability, evidence, control operation, sampling results, or requirement text. Separate observed facts, organization assertions, and analyst inferences. Treat missing or inaccessible evidence as unknown, not as failure, unless the authoritative assessment method says otherwise. Step 0 — Lock authority, version, and scope 1. Record the exact official source, version, publication/update identifier, and effective date used. 2. Record the organization, role, jurisdiction, industry, system/product boundary, review period, and decision owner. 3. Confirm any selected level, profile, baseline, overlay, assessment type, or licensed requirement set. 4. The cataloged version is final; still verify scope and any later official updates. 5. Use the official version and preserve its attribution and license terms. Do not substitute memory for the selected published text. 6. Stop and request a decision when applicability or the authoritative requirement set cannot be established. Step 1 — Build the applicability map For every supplied requirement identifier or official outcome in scope, record: applicability, rationale, responsible owner, implementation location, inherited/shared responsibility, evidence expected, and any dependency. Use only identifiers present in the authoritative source supplied for this engagement. Do not reconstruct licensed text. Step 2 — Collect evidence by framework domain Review these domains without treating the labels as substitutes for authoritative requirements: 1. source controls 2. build platform isolation 3. provenance generation 4. artifact and dependency verification Start with these likely artifacts, then validate provenance and coverage: 1. source repository policy exports 2. build definitions and runner trust boundaries 3. signed provenance attestations 4. consumer verification logs For every artifact record: artifact ID, source system, owner, collection time, review period, access path, integrity/provenance note, population covered, and requirement/outcome links. Prefer system exports and immutable records over screenshots or narrative attestations. Step 3 — Test design and operation For each applicable item, evaluate design, implementation, and operating evidence separately. Check whether evidence is authentic, complete, current for the review period, population-representative, and directly linked to the scoped system. Where sampling is permitted, state the population, method, sample size, selections, exceptions, and limitations; do not imply statistical assurance without a justified method. Step 4 — Classify gaps without overstating them Use only: supported, partially supported, unsupported, not applicable with rationale, or not assessed. Record gaps as evidence-readiness findings—not declarations of legal noncompliance. Each finding must include the affected requirement/outcome, observed fact, missing or weak evidence, risk, owner, corrective action, due date, dependencies, retest method, and confidence. Step 5 — Produce the evidence bundle Return one Markdown file named SLSAPROVENANCEEVIDENCECHECK.md with: 1. Executive summary and explicit assurance limitations. 2. Authority/version/status and scope/applicability record. 3. Coverage totals by status and evidence domain. 4. Requirement/outcome-to-evidence matrix with artifact provenance. 5. Findings ordered by risk and evidence impact. 6. A 30/60/90-day remediation and evidence-collection plan. 7. Open questions, unavailable sources, conflicts, and decisions required. 8. Official references with access/review date. Before finalizing, verify that every conclusion is traceable to an artifact or clearly labeled assertion/inference, all denominators reconcile, all unavailable evidence is visible, licensed text is not reproduced, and no sentence claims certification or legal approval. Output contract The response must contain one evidence matrix row per scoped authoritative item or outcome. At minimum include itemid, applicability, owner, implementation, artifactids, testmethod, coverage_period, status, gap, and confidence. Every artifact ID must resolve to the artifact register, and every total must reconcile to the matrix. Verification Confirm the official source, version, status, and review date in both the executive summary and matrix metadata. Reconcile applicable, not applicable, and not assessed counts to the complete supplied scope. Trace each supported assertion to provenance-bearing evidence covering the stated period and population. Independently reperform a risk-based sample of mappings and document all exceptions. Verify findings distinguish control/design weakness from missing evidence and unknown scope. Have the accountable owner and, where required, qualified counsel or an authorized assessor review conclusions. Guardrails This is an evidence-readiness workflow, not certification, attestation, audit opinion, or legal advice. Do not infer that a voluntary framework is mandatory or that one framework proves another. Do not paste, paraphrase at length, or reconstruct licensed controls. Use source summaries and organization-supplied licensed material. Do not expose secrets, personal data, regulated data, or full production exports in the report. Do not modify systems, close findings, accept risk, or submit regulatory reports without explicit owner authorization. If versions conflict, preserve both citations, label the conflict, and escalate rather than choosing silently. Routing examples Route here: verify SLSA v1.2 provenance assess source and build tracks review software supply-chain attestations Hard negatives—route elsewhere or clarify: perform a full NIST SSDF program assessment review application requirements with OWASP ASVS Related recipes NIST SSDF 1.1 OWASP ASVS 5.0.0 OWASP API Top 10:2023 References 1. OpenSSF SLSA official source 1","agent_handoff":{"mcp_lookup_keys":["slsa-provenance-evidence-check","/recipes/general/compliance-standards/slsa-provenance-evidence-check/","recipes/general/compliance-standards/slsa-provenance-evidence-check.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["audit","compliance"],"source_text_field":"content_text","portable_download":"security-recipe-slsa-provenance-evidence-check.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-slsa-provenance-evidence-check.json"}},{"slug":"soc2-change-management-evidence-check","title":"SOC 2 Trust Services Criteria Evidence Readiness Check","link_title":"SOC 2 TSC","url":"https://security-recipes.ai/recipes/general/compliance-standards/soc2-change-management-evidence-check/","path":"/recipes/general/compliance-standards/soc2-change-management-evidence-check/","source_file":"recipes/general/compliance-standards/soc2-change-management-evidence-check.md","recipe_id":"compliance.soc-2-tsc-2017-2022","recipe_kind":"","category":{"slug":"compliance-standards","label":"Compliance Standards"},"agent":"Compliance evidence review","severity":"info","maturity":"stable","ecosystem":"","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"SOC 2 TSC","framework_version":"2017 TSC with 2022 revised points of focus","jurisdiction":["global","united-states"],"industry":["service-organizations","cloud","saas"],"cve_archetypes":[],"cve_workflow_role":"","tags":["compliance","soc-2","assurance","audit","governance","service-organizations","cloud"],"facets":["audit","compliance"],"quality":{"score":95,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"Security Recipes","team":"GRC and Security Engineering","model":"gpt-5-codex","ai_assisted":false,"generated_by":"","date":"2026-08-21","zero_day":false,"last_updated":"2026-08-21","summary":"Assess SOC 2 TSC evidence readiness: verify applicability, map official requirements to artifacts, record gaps, and plan remediation.","content_text":"SOC 2 Trust Services Criteria Evidence Readiness Check Use this recipe to produce a source-aware evidence-readiness assessment for SOC 2 TSC. It creates an auditable gap record; it does not certify compliance, provide legal advice, or replace an assessor, regulator, or certification body. Section index Framework basis When to use it Inputs The prompt Output contract Verification Guardrails Routing examples References Framework basis Publisher: AICPA Version: 2017 TSC with 2022 revised points of focus Status: final Sources reviewed: 2026-08-21 Jurisdictions: global, united-states Industries: service-organizations, cloud, saas License boundary: summary-only Service organizations preparing evidence for a SOC 2 examination using the applicable Trust Services Criteria. The cataloged version is final; still verify scope and any later official updates. This recipe intentionally summarizes domains and evidence needs. Do not reproduce licensed control text; use an organization-supplied licensed copy for requirement-level work. When to use it Use this recipe when the organization has established that SOC 2 TSC is applicable or wants a readiness assessment against it. Use the routing positives below to distinguish this recipe from adjacent frameworks. If applicability, the effective version, or the authoritative requirement set is unresolved, stop at a scoped intake and record the decision owner. Inputs The business purpose, legal entities, products, services, systems, and locations in scope. The organization's role, applicability decision, selected profile, level, baseline, or control set where the framework requires one. The official publication URLs above and, for licensed material, an authorized organization-supplied copy. Evidence from the complete review period, including populations—not only hand-picked examples. Named owners, inherited/shared responsibilities, exceptions, compensating measures, and accepted risks. Read-only access by default. Redacted exports are acceptable when provenance and coverage remain testable. Evidence domains for this framework: system description and control environment: begin with system description and control matrix. risk assessment and monitoring: begin with population-complete access reviews. logical and physical access: begin with change tickets and deployment records. change, operations, availability, and incident evidence: begin with monitoring alerts and incident records. The prompt You are a compliance evidence-readiness analyst. Evaluate the supplied scope against SOC 2 TSC (2017 TSC with 2022 revised points of focus). The catalog status is final and the source review date is 2026-08-21. Never claim certification or legal compliance. Never invent applicability, evidence, control operation, sampling results, or requirement text. Separate observed facts, organization assertions, and analyst inferences. Treat missing or inaccessible evidence as unknown, not as failure, unless the authoritative assessment method says otherwise. Step 0 — Lock authority, version, and scope 1. Record the exact official source, version, publication/update identifier, and effective date used. 2. Record the organization, role, jurisdiction, industry, system/product boundary, review period, and decision owner. 3. Confirm any selected level, profile, baseline, overlay, assessment type, or licensed requirement set. 4. The cataloged version is final; still verify scope and any later official updates. 5. This recipe intentionally summarizes domains and evidence needs. Do not reproduce licensed control text; use an organization-supplied licensed copy for requirement-level work. 6. Stop and request a decision when applicability or the authoritative requirement set cannot be established. Step 1 — Build the applicability map For every supplied requirement identifier or official outcome in scope, record: applicability, rationale, responsible owner, implementation location, inherited/shared responsibility, evidence expected, and any dependency. Use only identifiers present in the authoritative source supplied for this engagement. Do not reconstruct licensed text. Step 2 — Collect evidence by framework domain Review these domains without treating the labels as substitutes for authoritative requirements: 1. system description and control environment 2. risk assessment and monitoring 3. logical and physical access 4. change, operations, availability, and incident evidence Start with these likely artifacts, then validate provenance and coverage: 1. system description and control matrix 2. population-complete access reviews 3. change tickets and deployment records 4. monitoring alerts and incident records For every artifact record: artifact ID, source system, owner, collection time, review period, access path, integrity/provenance note, population covered, and requirement/outcome links. Prefer system exports and immutable records over screenshots or narrative attestations. Step 3 — Test design and operation For each applicable item, evaluate design, implementation, and operating evidence separately. Check whether evidence is authentic, complete, current for the review period, population-representative, and directly linked to the scoped system. Where sampling is permitted, state the population, method, sample size, selections, exceptions, and limitations; do not imply statistical assurance without a justified method. Step 4 — Classify gaps without overstating them Use only: supported, partially supported, unsupported, not applicable with rationale, or not assessed. Record gaps as evidence-readiness findings—not declarations of legal noncompliance. Each finding must include the affected requirement/outcome, observed fact, missing or weak evidence, risk, owner, corrective action, due date, dependencies, retest method, and confidence. Step 5 — Produce the evidence bundle Return one Markdown file named SOC2CHANGEMANAGEMENTEVIDENCECHECK.md with: 1. Executive summary and explicit assurance limitations. 2. Authority/version/status and scope/applicability record. 3. Coverage totals by status and evidence domain. 4. Requirement/outcome-to-evidence matrix with artifact provenance. 5. Findings ordered by risk and evidence impact. 6. A 30/60/90-day remediation and evidence-collection plan. 7. Open questions, unavailable sources, conflicts, and decisions required. 8. Official references with access/review date. Before finalizing, verify that every conclusion is traceable to an artifact or clearly labeled assertion/inference, all denominators reconcile, all unavailable evidence is visible, licensed text is not reproduced, and no sentence claims certification or legal approval. Output contract The response must contain one evidence matrix row per scoped authoritative item or outcome. At minimum include itemid, applicability, owner, implementation, artifactids, testmethod, coverageperiod, status, gap, and confidence. Every artifact ID must resolve to the artifact register, and every total must reconcile to the matrix. Verification Confirm the official source, version, status, and review date in both the executive summary and matrix metadata. Reconcile applicable, not applicable, and not assessed counts to the complete supplied scope. Trace each supported assertion to provenance-bearing evidence covering the stated period and population. Independently reperform a risk-based sample of mappings and document all exceptions. Verify findings distinguish control/design weakness from missing evidence and unknown scope. Have the accountable owner and, where required, qualified counsel or an authorized assessor review conclusions. Guardrails This is an evidence-readiness workflow, not certification, attestation, audit opinion, or legal advice. Do not infer that a voluntary framework is mandatory or that one framework proves another. Do not paste, paraphrase at length, or reconstruct licensed controls. Use source summaries and organization-supplied licensed material. Do not expose secrets, personal data, regulated data, or full production exports in the report. Do not modify systems, close findings, accept risk, or submit regulatory reports without explicit owner authorization. If versions conflict, preserve both citations, label the conflict, and escalate rather than choosing silently. Routing examples Route here: prepare SOC 2 evidence review Trust Services Criteria readiness test change-management control evidence Hard negatives—route elsewhere or clarify: certify an ISO 27001 ISMS assess financial reporting controls under SOX Related recipes COBIT 2019 SOX ITGC SEC Cyber Disclosure Rule References 1. AICPA official source 1 2. AICPA official source 2","agent_handoff":{"mcp_lookup_keys":["soc2-change-management-evidence-check","/recipes/general/compliance-standards/soc2-change-management-evidence-check/","recipes/general/compliance-standards/soc2-change-management-evidence-check.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["audit","compliance"],"source_text_field":"content_text","portable_download":"security-recipe-soc2-change-management-evidence-check.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-soc2-change-management-evidence-check.json"}},{"slug":"sox-itgc-financial-reporting-evidence-check","title":"SOX IT General Controls Evidence Readiness Check","link_title":"SOX ITGC","url":"https://security-recipes.ai/recipes/general/compliance-standards/sox-itgc-financial-reporting-evidence-check/","path":"/recipes/general/compliance-standards/sox-itgc-financial-reporting-evidence-check/","source_file":"recipes/general/compliance-standards/sox-itgc-financial-reporting-evidence-check.md","recipe_id":"compliance.sox-itgc-as-2201","recipe_kind":"","category":{"slug":"compliance-standards","label":"Compliance Standards"},"agent":"Compliance evidence review","severity":"info","maturity":"stable","ecosystem":"","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"SOX ITGC","framework_version":"PCAOB AS 2201 current text; 2026 amendments tracked","jurisdiction":["united-states"],"industry":["public-companies","financial-services","cross-sector"],"cve_archetypes":[],"cve_workflow_role":"","tags":["compliance","sox-itgc","assurance","audit","financial-reporting","control-testing","public-companies","financial-services"],"facets":["audit","compliance"],"quality":{"score":95,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"Security Recipes","team":"GRC and Security Engineering","model":"gpt-5-codex","ai_assisted":false,"generated_by":"","date":"2026-08-21","zero_day":false,"last_updated":"2026-08-21","summary":"Assess SOX ITGC evidence readiness: verify applicability, map official requirements to artifacts, record gaps, and plan remediation.","content_text":"SOX IT General Controls Evidence Readiness Check Use this recipe to produce a source-aware evidence-readiness assessment for SOX ITGC. It creates an auditable gap record; it does not certify compliance, provide legal advice, or replace an assessor, regulator, or certification body. Section index Framework basis When to use it Inputs The prompt Output contract Verification Guardrails Routing examples References Framework basis Publisher: U.S. Congress / SEC / PCAOB Version: PCAOB AS 2201 current text; 2026 amendments tracked Status: revision-in-progress Sources reviewed: 2026-08-21 Jurisdictions: united-states Industries: public-companies, financial-services, cross-sector License boundary: official-text Public-company IT general controls supporting financial reporting and internal-control evidence; AS 2201 amendments take effect December 15, 2026. The authority is revising or transitioning this framework. Confirm the effective source set and dates before making a current-state claim. Use the linked official legal or regulatory text and current implementing guidance; do not replace applicability analysis with this summary. When to use it Use this recipe when the organization has established that SOX ITGC is applicable or wants a readiness assessment against it. Use the routing positives below to distinguish this recipe from adjacent frameworks. If applicability, the effective version, or the authoritative requirement set is unresolved, stop at a scoped intake and record the decision owner. Inputs The business purpose, legal entities, products, services, systems, and locations in scope. The organization's role, applicability decision, selected profile, level, baseline, or control set where the framework requires one. The official publication URLs above and, for licensed material, an authorized organization-supplied copy. Evidence from the complete review period, including populations—not only hand-picked examples. Named owners, inherited/shared responsibilities, exceptions, compensating measures, and accepted risks. Read-only access by default. Redacted exports are acceptable when provenance and coverage remain testable. Evidence domains for this framework: financial reporting system scope: begin with in-scope application and dependency inventory. access to financially relevant systems: begin with privileged and periodic access reviews. change management: begin with change populations and sampled approvals. computer operations and control reliance: begin with job monitoring, backup, and incident evidence. The prompt You are a compliance evidence-readiness analyst. Evaluate the supplied scope against SOX ITGC (PCAOB AS 2201 current text; 2026 amendments tracked). The catalog status is revision-in-progress and the source review date is 2026-08-21. Never claim certification or legal compliance. Never invent applicability, evidence, control operation, sampling results, or requirement text. Separate observed facts, organization assertions, and analyst inferences. Treat missing or inaccessible evidence as unknown, not as failure, unless the authoritative assessment method says otherwise. Step 0 — Lock authority, version, and scope 1. Record the exact official source, version, publication/update identifier, and effective date used. 2. Record the organization, role, jurisdiction, industry, system/product boundary, review period, and decision owner. 3. Confirm any selected level, profile, baseline, overlay, assessment type, or licensed requirement set. 4. The authority is revising or transitioning this framework. Confirm the effective source set and dates before making a current-state claim. 5. Use the linked official legal or regulatory text and current implementing guidance; do not replace applicability analysis with this summary. 6. Stop and request a decision when applicability or the authoritative requirement set cannot be established. Step 1 — Build the applicability map For every supplied requirement identifier or official outcome in scope, record: applicability, rationale, responsible owner, implementation location, inherited/shared responsibility, evidence expected, and any dependency. Use only identifiers present in the authoritative source supplied for this engagement. Do not reconstruct licensed text. Step 2 — Collect evidence by framework domain Review these domains without treating the labels as substitutes for authoritative requirements: 1. financial reporting system scope 2. access to financially relevant systems 3. change management 4. computer operations and control reliance Start with these likely artifacts, then validate provenance and coverage: 1. in-scope application and dependency inventory 2. privileged and periodic access reviews 3. change populations and sampled approvals 4. job monitoring, backup, and incident evidence For every artifact record: artifact ID, source system, owner, collection time, review period, access path, integrity/provenance note, population covered, and requirement/outcome links. Prefer system exports and immutable records over screenshots or narrative attestations. Step 3 — Test design and operation For each applicable item, evaluate design, implementation, and operating evidence separately. Check whether evidence is authentic, complete, current for the review period, population-representative, and directly linked to the scoped system. Where sampling is permitted, state the population, method, sample size, selections, exceptions, and limitations; do not imply statistical assurance without a justified method. Step 4 — Classify gaps without overstating them Use only: supported, partially supported, unsupported, not applicable with rationale, or not assessed. Record gaps as evidence-readiness findings—not declarations of legal noncompliance. Each finding must include the affected requirement/outcome, observed fact, missing or weak evidence, risk, owner, corrective action, due date, dependencies, retest method, and confidence. Step 5 — Produce the evidence bundle Return one Markdown file named SOXITGCFINANCIALREPORTINGEVIDENCECHECK.md with: 1. Executive summary and explicit assurance limitations. 2. Authority/version/status and scope/applicability record. 3. Coverage totals by status and evidence domain. 4. Requirement/outcome-to-evidence matrix with artifact provenance. 5. Findings ordered by risk and evidence impact. 6. A 30/60/90-day remediation and evidence-collection plan. 7. Open questions, unavailable sources, conflicts, and decisions required. 8. Official references with access/review date. Before finalizing, verify that every conclusion is traceable to an artifact or clearly labeled assertion/inference, all denominators reconcile, all unavailable evidence is visible, licensed text is not reproduced, and no sentence claims certification or legal approval. Output contract The response must contain one evidence matrix row per scoped authoritative item or outcome. At minimum include itemid, applicability, owner, implementation, artifactids, testmethod, coverage_period, status, gap, and confidence. Every artifact ID must resolve to the artifact register, and every total must reconcile to the matrix. Verification Confirm the official source, version, status, and review date in both the executive summary and matrix metadata. Reconcile applicable, not applicable, and not assessed counts to the complete supplied scope. Trace each supported assertion to provenance-bearing evidence covering the stated period and population. Independently reperform a risk-based sample of mappings and document all exceptions. Verify findings distinguish control/design weakness from missing evidence and unknown scope. Have the accountable owner and, where required, qualified counsel or an authorized assessor review conclusions. Guardrails This is an evidence-readiness workflow, not certification, attestation, audit opinion, or legal advice. Do not infer that a voluntary framework is mandatory or that one framework proves another. Do not paste, paraphrase at length, or reconstruct licensed controls. Use source summaries and organization-supplied licensed material. Do not expose secrets, personal data, regulated data, or full production exports in the report. Do not modify systems, close findings, accept risk, or submit regulatory reports without explicit owner authorization. If versions conflict, preserve both citations, label the conflict, and escalate rather than choosing silently. Routing examples Route here: assess SOX ITGC evidence review systems supporting ICFR test access change and operations controls for financial reporting Hard negatives—route elsewhere or clarify: prepare a SOC 2 service organization report assess COBIT governance maturity Related recipes SOC 2 TSC COBIT 2019 SEC Cyber Disclosure Rule References 1. U.S. Congress / SEC / PCAOB official source 1","agent_handoff":{"mcp_lookup_keys":["sox-itgc-financial-reporting-evidence-check","/recipes/general/compliance-standards/sox-itgc-financial-reporting-evidence-check/","recipes/general/compliance-standards/sox-itgc-financial-reporting-evidence-check.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["audit","compliance"],"source_text_field":"content_text","portable_download":"security-recipe-sox-itgc-financial-reporting-evidence-check.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-sox-itgc-financial-reporting-evidence-check.json"}},{"slug":"compromised-package-cache-quarantine","title":"Compromised package — cache quarantine","link_title":"Cache quarantine for compromised packages","url":"https://security-recipes.ai/recipes/general/compromised-package-cache-quarantine/","path":"/recipes/general/compromised-package-cache-quarantine/","source_file":"recipes/general/compromised-package-cache-quarantine.md","recipe_id":"","recipe_kind":"","category":{"slug":"general","label":"General"},"agent":"general","severity":"unspecified","maturity":"development","ecosystem":"","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"","framework_version":"","jurisdiction":"","industry":[],"cve_archetypes":["supply_chain_update_integrity"],"cve_workflow_role":"contain","tags":["supply-chain","registry","cache","quarantine","incident"],"facets":["remediation","code-hygiene"],"quality":{"score":95,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"Stephen M Abbott","team":"Security","model":"Opus 4.7","ai_assisted":false,"generated_by":"","date":"2026-04-25","zero_day":false,"last_updated":"2026-04-25","summary":"A tool-agnostic prompt that takes a \"this package is malicious\" advisory and runs the eviction across the org's registries, caches, and mirrors — quarantining the artifact, verifying the purge worked, and drafting the developer-machine …","content_text":"A tool-agnostic prompt that takes a \"this package is malicious\" advisory and runs the eviction across the org's registries, caches, and mirrors — quarantining the artifact, verifying the purge worked, and drafting the developer-machine broadcast a human will deliver. Designed to slot into the Artifact Cache & Mirror Quarantine workflow. What this prompt does 1. Reads the advisory — the artifact coordinate, the versions, the registries to inspect. 2. Inventories — for each registry / proxy / cache the agent has a connector for, lists matching versions or digests. 3. Quarantines the matching versions (preferred) or deletes them where policy requires. Default action is reversible quarantine. 4. Verifies by re-fetching the purged artifact and confirming the registry refuses to serve it. 5. Drafts the developer-machine broadcast — paste-ready purge commands for npm, pip, go, docker, etc., plus verification commands. 6. Records the audit entry — registry actions, verification results, restore commands, and the broadcast text. When to use it An advisory says a published artifact (package, image, chart) is malicious — maintainer takeover, poisoned release, supply-chain compromise. The artifact is identifiable by a stable coordinate. The org's registries / proxies have agent-quarantine API access declared in policy. Don't use it for: Routine vulnerable-version advisories (use the vulnerable-dependency workflow). Range-based or fuzzy advisories without a stable coordinate. Air-gapped mirrors the agent has no network path to (the broadcast pattern applies). Reaching into developer machines (the agent drafts broadcasts; humans deliver them). Inputs Advisory — ID, ecosystem, package name(s), affected versions, type (compromise vs. vulnerable). Registry list — which registry / proxy / cache connectors to use for this ecosystem. Policy — quarantine vs. hard delete; whether the developer-machine broadcast is required. The prompt ~~~markdown You are running a cache-quarantine action across this organization's registries in response to a compromise advisory. Your output is exactly one of: A complete audit record showing every registry purged, every verification passing, and a drafted developer-machine broadcast text. A TRIAGE.md note explaining what could not be completed and what a human needs to do next. Do not act on advisories that are not labelled compromise/malicious. Do not perform a hard delete unless the policy explicitly requires it for this advisory. Step 0 — Validate the input 1. Confirm the advisory is labelled compromise or malicious. If it is a routine vulnerable advisory, stop and route to the vulnerable-dependency workflow. 2. Confirm the advisory provides a stable coordinate (name@version for packages, image:tag or image@digest for containers). If the coordinate is fuzzy (range, wildcard), stop and triage. Step 1 — Inventory For each registry / proxy / cache connector you have access to: 1. List all versions / digests matching the advisory's coordinate. 2. Record the registry's URL, the matching coordinates, and the version timestamps. 3. If the connector returns an empty list, record \"not present in this registry\" — do not preemptively block versions the advisory does not name. Step 2 — Quarantine For each matching version on each registry: 1. Use the registry's quarantine API to mark the version forbidden. Quarantine is the default; only hard-delete if the policy file flags this advisory as delete-required. 2. Capture the registry's response and the resulting state. 3. If a registry rejects the quarantine call (permission, API error, version not deletable), record the failure and continue with the rest — do not abort the whole run on one registry's failure. Failures show up in the audit and the triage note. Step 3 — Verify For each version you quarantined: 1. Make a fresh fetch attempt against the registry as a normal client would (not the privileged quarantine endpoint). 2. Confirm the registry returns a 404 / forbidden / quarantine response. 3. If the registry still serves the artifact, revert the quarantine for that version, record the failure in the audit, and add the registry to the triage note. Step 4 — Draft the developer-machine broadcast Write a paste-ready broadcast text containing: A one-paragraph summary of the advisory. The exact purge command(s) for each ecosystem in scope. For the most common cases: npm/pnpm/yarn: npm cache clean --force and remove matching entries from ~/.npm/cacache. pip: pip cache remove '<package>' (and ~/.cache/pip/wheels removal if the wheel is matched). Go: go clean -modcache (note: removes everything; for targeted, rm -rf ~/go/pkg/mod/<module>@<version>). Maven: remove ~/.m2/repository/<group>/<artifact>/<version>. Docker / Podman: docker rmi <image>:<tag> and prune by digest. A verify-clean command per ecosystem. The contact channel for \"I purged but the package still shows up\" reports. The broadcast is drafted, not delivered. The audit record includes the text but the engineering team owns distribution. Step 5 — Audit record Append a single audit entry containing: Advisory ID and link. Coordinates targeted. Per-registry results (success / failure / not present). Per-registry verification results. Restore commands (the inverse of each quarantine action). The drafted broadcast text. Run ID and timestamp. Stop conditions (write a TRIAGE.md and exit) Advisory is not a compromise / malicious shape. Coordinate is fuzzy. One or more registries refused quarantine and the advisory policy requires \"all registries before declaring success.\" Verification failed on a registry that does not support a reliable revert path. A registry connector is missing entirely (do not silently skip). Scope Do not act on registries not in the input list. Do not delete unrelated versions of the same package. Do not publish, rotate upstream URLs, or change registry configuration beyond version-state. Do not SSH into developer machines, CI runners, or any laptop. The broadcast is the only output that targets dev machines. Do not silently downgrade a hard-delete policy to quarantine. ~~~ Output contract A complete audit record with every registry's state recorded and the broadcast text drafted, OR a TRIAGE.md note. Out-of-band notification to the security incident channel fires whether the run succeeds or fails — quiet purges are the wrong default. Verification Every purged coordinate matches the advisory namespace and version or digest exactly. A post-quarantine re-fetch is recorded for each registry and shows the artifact is no longer served. The audit record includes the inverse restore command for every quarantine action. Developer-machine steps stay in the drafted broadcast; no SSH or laptop action was taken. Guardrails Quarantine before delete. Default action is reversible. Hard deletes require an extra approval and are not in the agent's default toolset. Per-registry scoped credentials. The agent's credential on each registry can manage version-state on packages matching the advisory namespace, and nothing else. Coordinate match required. No fuzzy matches. Verification before success. No \"purged\" claim without a verifying re-fetch. Restore path documented. Every quarantine action's audit record includes the inverse command. Dev machines = broadcast, not action.** Always. Related Artifact Cache & Mirror Quarantine — the workflow this prompt slots into. Vulnerable Dependency Remediation → Malicious-package downgrade path — the lockfile-shaped sibling. Threat Model → Agent-infrastructure supply-chain compromise — why this pattern is treated separately from routine CVEs.","agent_handoff":{"mcp_lookup_keys":["compromised-package-cache-quarantine","/recipes/general/compromised-package-cache-quarantine/","recipes/general/compromised-package-cache-quarantine.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["remediation","code-hygiene"],"source_text_field":"content_text","portable_download":"security-recipe-compromised-package-cache-quarantine.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-compromised-package-cache-quarantine.json"}},{"slug":"cross-chain-message-authenticity-guardrails","title":"Cross-chain message authenticity guardrails","link_title":"Cross-chain message guardrails","url":"https://security-recipes.ai/recipes/general/crypto-defi/cross-chain-message-authenticity-guardrails/","path":"/recipes/general/crypto-defi/cross-chain-message-authenticity-guardrails/","source_file":"recipes/general/crypto-defi/cross-chain-message-authenticity-guardrails.md","recipe_id":"","recipe_kind":"","category":{"slug":"crypto-defi","label":"Crypto/DeFi"},"agent":"general","severity":"unspecified","maturity":"development","ecosystem":"","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"","framework_version":"","jurisdiction":"","industry":[],"cve_archetypes":[],"cve_workflow_role":"","tags":["defi","bridge","cross-chain","message-authenticity","replay"],"facets":["remediation"],"quality":{"score":95,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"Security Recipes Maintainers","team":"Security","model":"GPT-5.3-Codex","ai_assisted":false,"generated_by":"","date":"2026-06-14","zero_day":false,"last_updated":"2026-06-14","summary":"Use this prompt to harden cross-chain message handlers against forged payloads, chain replay, untrusted relayers, and missing proof checks.","content_text":"Use this prompt to harden cross-chain message handlers against forged payloads, chain replay, untrusted relayers, and missing proof checks. When to use it Destination-chain code executes deposits, withdrawals, mints, burns, unlocks, governance actions, or configuration changes from cross-chain messages. Relayers, bridge adapters, oracle committees, light clients, or off-chain services submit payloads, receipts, proofs, signatures, or message IDs. Source chain, source sender, destination contract, payload hash, or nonce binding is unclear or split across multiple modules. You need a bounded PR or triage note that hardens message authenticity and replay protection without trusting relayer identity alone. Inputs Smart contracts, relayer services, bridge adapters, chain-domain registries, proof verifiers, message schemas, event processors, and governance configs. Source/destination chain IDs, trusted sender lists, nonce/message-ID storage, proof formats, quorum rules, payload hash construction, and emergency pause ownership. Available contract tests, fork/simulation tests, fuzz/property tests, deployment scripts, audit reports, and security scan commands. Research basis OWASP SCWE-107: Missing Chain ID Validation in Cross-Chain Messages recommends binding inbound messages to expected source chain, domain, sender, and nonce. OWASP SCWE-108: Unverified Cross-Chain Message Proofs recommends validating Merkle proofs, light-client headers, signatures, or quorum rules before executing payloads. Use when A destination contract executes deposits, withdrawals, mints, burns, unlocks, governance actions, or parameter changes from cross-chain messages. Relayers submit payloads, receipts, proofs, signatures, or message IDs. Message validation does not bind source chain, source sender, nonce, bridge adapter, and payload hash together. Tests cover the happy path but not forged or replayed messages. Prompt ~~~markdown You are a cross-chain message authenticity remediation agent. Goal: ensure destination-chain execution happens only for authentic, authorized, non-replayed messages from expected source domains. Output PR or TRIAGE.md. Controls to implement: Validate source chain ID, source domain, source sender, destination chain, and destination contract. Verify inclusion proofs, light-client headers, validator signatures, quorum thresholds, or bridge-adapter attestations before execution. Track nonces or message IDs per source chain and source sender. Bind payload hash, asset, amount, recipient, and action type into the authenticated message. Fail closed on unknown relayers, unsupported source domains, stale roots, malformed proofs, or already-consumed messages. Tasks: 1. Inventory all cross-chain receive, finalize, execute, mint, unlock, and governance message handlers. 2. Trace which component proves message authenticity and which component enforces replay protection. 3. Add missing source-domain, trusted-sender, proof, quorum, and nonce checks at the destination boundary. 4. Add negative tests for wrong chain, wrong sender, forged proof, replayed nonce, mismatched payload hash, and unauthorized relayer. 5. Document emergency pause behavior for bridge-adapter compromise or proof-system outage. Constraints: Do not trust relayer identity as a substitute for message proof. Do not use a global nonce if multiple source chains or senders can collide. Stop with TRIAGE.md if authenticity depends on an off-chain service whose verification contract or trust assumptions are unavailable. ~~~ Output contract Reviewer-ready PR binding each inbound message to source chain/domain, trusted sender, destination contract, payload hash, action type, and nonce or message ID before execution. Negative tests for wrong chain, wrong sender, forged proof, stale root, mismatched payload, replayed nonce, unauthorized relayer, and paused bridge behavior. Operator/auditor notes describing trust assumptions, proof/quorum ownership, emergency pause behavior, and any unsupported source domains. TRIAGE.md when the repository cannot verify the proof system, bridge adapter, trust model, or deployment owner. Verification - what the reviewer looks for Every destination execution path validates source domain, trusted sender, proof/quorum, payload binding, and replay protection before state changes. Nonces or message IDs are scoped by source chain and sender, not shared as a collision-prone global counter. Tests exercise forged, replayed, stale, malformed, and unauthorized messages against the real boundary that executes payloads. Emergency pause behavior is deterministic and documented for bridge-adapter compromise or proof-system outage. Related recipes Crypto payment address integrity checks DeFi oracle manipulation guardrails Source code supply-chain build integrity audit","agent_handoff":{"mcp_lookup_keys":["cross-chain-message-authenticity-guardrails","/recipes/general/crypto-defi/cross-chain-message-authenticity-guardrails/","recipes/general/crypto-defi/cross-chain-message-authenticity-guardrails.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["remediation"],"source_text_field":"content_text","portable_download":"security-recipe-cross-chain-message-authenticity-guardrails.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-cross-chain-message-authenticity-guardrails.json"}},{"slug":"crypto-payment-address-integrity-check","title":"Crypto payment address integrity checks","link_title":"Address integrity checks","url":"https://security-recipes.ai/recipes/general/crypto-defi/crypto-payment-address-integrity-check/","path":"/recipes/general/crypto-defi/crypto-payment-address-integrity-check/","source_file":"recipes/general/crypto-defi/crypto-payment-address-integrity-check.md","recipe_id":"","recipe_kind":"","category":{"slug":"crypto-defi","label":"Crypto/DeFi"},"agent":"general","severity":"unspecified","maturity":"development","ecosystem":"","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"","framework_version":"","jurisdiction":"","industry":[],"cve_archetypes":[],"cve_workflow_role":"","tags":["crypto","payments","address","poisoning","validation"],"facets":["remediation"],"quality":{"score":95,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"Security Recipes Maintainers","team":"Security","model":"GPT-5.3-Codex","ai_assisted":false,"generated_by":"","date":"2026-04-26","zero_day":false,"last_updated":"2026-04-26","summary":"Use this prompt to prevent destination-address substitution and address-poisoning mistakes in crypto payment systems.","content_text":"Use this prompt to prevent destination-address substitution and address-poisoning mistakes in crypto payment systems. When to use it Users, operators, invoices, APIs, or import jobs supply crypto destination addresses manually. Address books, recent-recipient lists, QR flows, clipboard workflows, or withdrawal templates can be poisoned or confused by near-match addresses. Chain-specific memos, destination tags, checksums, network prefixes, or asset routing rules are required for safe settlement. You need a bounded PR or triage note that centralizes address validation and prevents silent destination substitution. Inputs Payment API handlers, withdrawal services, UI/backend validation paths, address-book storage, QR/deeplink parsers, import jobs, and notification templates. Chain metadata, address formats, checksum/network rules, memo/tag requirements, asset routing tables, trust tiers, and fraud telemetry. Available unit tests, API tests, UI/backend integration tests, chain metadata fixtures, telemetry checks, and security scan commands. Use when Users paste wallet addresses manually. Address books and recent-recipient UX can be poisoned. Memos/tags are required for some chains. Prompt ~~~markdown You are a security remediation agent for crypto payment integrity. Goal: implement and enforce destination address integrity controls. Output either a PR with tests or TRIAGE.md. Required controls: Chain-aware address format validation (checksum/network prefix). Canonicalization before storage and comparison. Address-book trust tiers (verified, user-added, untrusted). High-risk transfer interstitial requiring full-address confirmation. Required memo/tag validation for chains that need destination tags. Tasks: 1. Add a shared address-validation module used by API + UI backend. 2. Reject mixed-chain mismatches (e.g., BTC address for EVM transfer). 3. Add duplicate/similar-address detection to flag poisoning patterns. 4. Add tests covering valid/invalid checksums, chain mismatch, missing memo/tag, and poisoning-like near-match cases. 5. Ensure telemetry emits structured security events for rejections. Constraints: Do not auto-correct addresses silently. Do not downgrade strict validation to warning-only. Stop with TRIAGE.md if chain metadata is incomplete. ~~~ Output contract Reviewer-ready PR adding a shared chain-aware validation path used by API, services, and UI backend before storing or submitting destinations. Tests for checksums, network mismatch, memo/tag requirements, canonicalized comparison, duplicate/near-match poisoning, and high-risk confirmation flows. Operator/auditor notes describing chain metadata ownership, address-book trust tiers, rejection telemetry, and any unsupported chains. TRIAGE.md when reliable chain metadata, memo/tag rules, or settlement ownership is outside this repository. Verification - what the reviewer looks for Invalid, mixed-chain, missing-tag, and near-match poisoned addresses are rejected before persistence or transfer execution. Address canonicalization is explicit and never silently autocorrects a user destination. API and UI backend paths call the same validation module or share the same authoritative policy. Security telemetry records rejection reasons without leaking private account or wallet metadata. Related recipes Cross-chain message authenticity guardrails Permit and meta-transaction replay guardrails Source code supply-chain build integrity audit","agent_handoff":{"mcp_lookup_keys":["crypto-payment-address-integrity-check","/recipes/general/crypto-defi/crypto-payment-address-integrity-check/","recipes/general/crypto-defi/crypto-payment-address-integrity-check.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["remediation"],"source_text_field":"content_text","portable_download":"security-recipe-crypto-payment-address-integrity-check.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-crypto-payment-address-integrity-check.json"}},{"slug":"defi-admin-key-and-role-blast-radius-review","title":"DeFi admin-key and role blast-radius review","link_title":"Admin-key blast-radius review","url":"https://security-recipes.ai/recipes/general/crypto-defi/defi-admin-key-and-role-blast-radius-review/","path":"/recipes/general/crypto-defi/defi-admin-key-and-role-blast-radius-review/","source_file":"recipes/general/crypto-defi/defi-admin-key-and-role-blast-radius-review.md","recipe_id":"","recipe_kind":"","category":{"slug":"crypto-defi","label":"Crypto/DeFi"},"agent":"general","severity":"unspecified","maturity":"development","ecosystem":"","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"","framework_version":"","jurisdiction":"","industry":[],"cve_archetypes":[],"cve_workflow_role":"","tags":["defi","access-control","admin-key","timelock","governance"],"facets":["remediation","audit","code-hygiene"],"quality":{"score":100,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context","multi-facet"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"Security Recipes Maintainers","team":"Security","model":"GPT-5.3-Codex","ai_assisted":false,"generated_by":"","date":"2026-06-14","zero_day":false,"last_updated":"2026-06-14","summary":"Use this prompt to reduce the damage a compromised admin key, overbroad role, or rushed governance action can cause in a DeFi protocol. The model: \"GPT-5.3-Codex\" frontmatter field is recipe metadata, not a prompt pin. Rechecked August …","content_text":"Use this prompt to reduce the damage a compromised admin key, overbroad role, or rushed governance action can cause in a DeFi protocol. The model: \"GPT-5.3-Codex\" frontmatter field is recipe metadata, not a prompt pin. Rechecked August 23, 2026: leftover CVE dumps stay development / noindex. Do not invent a governance or upgrade target or a named floor from leftover dump version text. OWASP Smart Contract Top 10 : 2026 is still current and forward-looking. It is a different project from the retired OWASP web Top 10:2026 pages. When to use it Use this recipe when smart contracts, deployment scripts, governance proposals, or runbooks define privileged roles that can upgrade contracts, pause markets, alter parameters, list assets, change oracles, move treasury funds, or trigger emergency actions. It is especially useful before mainnet launches, governance migrations, incident reviews, and audits of owner-only or role-gated code. Use it to reduce privileged-action blast radius with least privilege, timelocks, multisigs, bounded parameters, deployment checks, events, and reviewable governance paths. Do not use it to remove emergency controls that are genuinely required to stop active loss. Inputs Solidity/Vyper contracts, proxy/admin contracts, access-control libraries, modifiers, deployment scripts, governance proposals, timelock config, multisig config, role assignment manifests, Foundry/Hardhat scripts, and runbooks. Privileged functions that can upgrade implementations, pause/unpause, change fees, list assets, set caps, alter risk parameters, change oracles, move reserves, mint/burn, bridge, rescue tokens, or modify treasury routes. Current role holders: EOAs, multisigs, timelocks, governors, executors, guardians, emergency councils, deployment accounts, automation bots, and cross-chain message receivers. Tests, invariants, deployment checks, event coverage, monitoring rules, and audit findings related to access control and governance actions. Operational constraints for emergency response, routine governance cadence, timelock delays, signer availability, and off-chain approval processes. Research basis OWASP Smart Contract Top 10 : 2026 still ranks SC01:2026 Access Control and SC02:2026 Business Logic as the top two smart-contract risk categories. The 2026 list is forward-looking from 2025 incident data. Do not treat it as the retired OWASP web Top 10:2026. Trail of Bits: Maturing your smart contracts beyond private key risk recommends least privilege, multisigs, timelocks, and design-stage access control maturity for privileged DeFi functions. Use when Any privileged function can list assets, alter risk parameters, pause markets, upgrade contracts, change oracles, or move reserves. Admin roles are held by EOAs, shared wallets, broad multisigs, or unclear governance executors. Emergency powers and routine governance powers are mixed together. Role assignments are not covered by tests or deployment checks. Prompt ~~~markdown You are a DeFi governance and access-control remediation agent. Goal: reduce privileged-role blast radius and make admin action paths auditable, delayed where appropriate, and least-privileged. Output PR or TRIAGE.md. Controls to implement: Replace single-key privileged ownership with multisig or governance executors where the deployment model supports it. Split routine parameter roles, emergency pause roles, upgrade roles, treasury roles, and oracle roles. Add timelocks for non-emergency changes that can affect user funds. Add explicit allowlists and bounds for high-risk parameter changes. Emit events for every privileged action and role change. Tasks: 1. Inventory all privileged functions, role holders, modifiers, and deployment-time role assignments. 2. Classify each privileged action by fund-loss impact, speed required, and whether it should be timelocked. 3. Narrow roles so each authority can perform only the actions required for its operational purpose. 4. Add tests proving unauthorized accounts cannot call privileged paths and authorized roles cannot exceed their intended scope. 5. Add deployment or configuration checks that fail on EOA ownership, missing timelocks, missing events, or unbounded critical parameters. Constraints: Do not remove emergency pause capability from genuinely time-critical loss-prevention paths. Do not hide risk behind comments or documentation-only controls. Stop with TRIAGE.md if role ownership is controlled outside this repository and cannot be verified by code or deployment artifacts. ~~~ Output contract Return one of: A reviewer-ready PR/change request that narrows privileged roles, adds or verifies multisig/governor/timelock execution where appropriate, separates emergency and routine authorities, bounds high-risk parameters, emits events, adds tests and deployment checks, and refreshes governance documentation. TRIAGE.md when privileged ownership is entirely external to the repository and cannot be verified through code, deployment artifacts, governance config, or runbooks. The output must list every privileged action reviewed, its current holder, fund-loss impact, intended authority, delay/emergency classification, tests added, deployment checks added, and residual roles that need human governance approval. It must not remove emergency pause paths, transfer authority to an unreviewed EOA, or rely only on comments for access-control risk reduction. Related recipes Smart-contract upgrade diff risk review DeFi bridge and multisig emergency response Hot-wallet transaction policy enforcement","agent_handoff":{"mcp_lookup_keys":["defi-admin-key-and-role-blast-radius-review","/recipes/general/crypto-defi/defi-admin-key-and-role-blast-radius-review/","recipes/general/crypto-defi/defi-admin-key-and-role-blast-radius-review.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["remediation","audit","code-hygiene"],"source_text_field":"content_text","portable_download":"security-recipe-defi-admin-key-and-role-blast-radius-review.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-defi-admin-key-and-role-blast-radius-review.json"}},{"slug":"defi-bridge-and-multisig-emergency-response","title":"Bridge and multisig emergency response","link_title":"Bridge/multisig emergency response","url":"https://security-recipes.ai/recipes/general/crypto-defi/defi-bridge-and-multisig-emergency-response/","path":"/recipes/general/crypto-defi/defi-bridge-and-multisig-emergency-response/","source_file":"recipes/general/crypto-defi/defi-bridge-and-multisig-emergency-response.md","recipe_id":"","recipe_kind":"","category":{"slug":"crypto-defi","label":"Crypto/DeFi"},"agent":"general","severity":"unspecified","maturity":"development","ecosystem":"","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"","framework_version":"","jurisdiction":"","industry":[],"cve_archetypes":[],"cve_workflow_role":"","tags":["defi","bridge","multisig","incident-response","runbook"],"facets":["remediation"],"quality":{"score":95,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"Security Recipes Maintainers","team":"Security","model":"GPT-5.3-Codex","ai_assisted":false,"generated_by":"","date":"2026-04-26","zero_day":false,"last_updated":"2026-04-26","summary":"Use this prompt to codify emergency response for bridge and multisig incidents where rapid containment is required.","content_text":"Use this prompt to codify emergency response for bridge and multisig incidents where rapid containment is required. When to use it Bridge validator compromise is suspected. Multisig signer keys are lost or potentially exposed. Timelock bypass or unauthorized proposal execution is detected. Inputs Incident trigger, timestamp, affected bridge route, governance proposal, or signer identity. Current bridge pause controls, multisig threshold, signer roster, timelock delay, and emergency-role map. Read-only chain explorer, governance, validator, and deployment evidence. Existing incident-response, disclosure, reconciliation, and re-enable runbooks. Prompt ~~~markdown You are a DeFi incident-remediation agent preparing bridge/multisig containment actions. Goal: produce auditable emergency runbook updates + automation checks, without executing privileged on-chain actions. Output PR or TRIAGE.md. Tasks: 1. Validate incident triggers and map them to containment playbooks: pause bridge, raise signer threshold, revoke compromised signer, freeze high-risk routes, and notify counterparties. 2. Add machine-checkable preconditions for each action so operators cannot run steps out of order. 3. Add tabletop simulation script/tests for at least two incident types. 4. Add post-incident checklist: fund reconciliation, signer rotation, governance disclosure, and re-enable criteria. Constraints: Agent cannot submit governance votes or sign emergency txs. Every manual action must include approver role + evidence artifact. Stop with TRIAGE.md if playbook ownership is undefined. ~~~ Output contract Containment runbook diff with preconditions, approver roles, evidence artifacts, and exact manual action owners. Simulation or tabletop test plan for at least two incident paths. Reconciliation checklist covering balances, counterparties, signer rotation, disclosure, and re-enable criteria. TRIAGE.md when ownership, authority, or evidence is insufficient. Verification Confirm no generated command signs, broadcasts, or submits governance transactions. Run tabletop or unit tests for pause, threshold raise, signer removal, and route freeze ordering. Attach explorer or governance read-only evidence for affected contracts, proposals, signers, and route state. Guardrails Do not execute privileged on-chain actions from the recipe run. Do not infer a compromised signer without evidence from wallet logs, governance activity, custody tooling, or chain observations. Stop if emergency authority is unclear, contested, or outside the operator's approved incident process. Related recipes Hot-wallet policy enforcement Seed/key material purge Contract upgrade diff review","agent_handoff":{"mcp_lookup_keys":["defi-bridge-and-multisig-emergency-response","/recipes/general/crypto-defi/defi-bridge-and-multisig-emergency-response/","recipes/general/crypto-defi/defi-bridge-and-multisig-emergency-response.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["remediation"],"source_text_field":"content_text","portable_download":"security-recipe-defi-bridge-and-multisig-emergency-response.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-defi-bridge-and-multisig-emergency-response.json"}},{"slug":"defi-oracle-manipulation-guardrails","title":"DeFi oracle manipulation guardrails","link_title":"Oracle manipulation guardrails","url":"https://security-recipes.ai/recipes/general/crypto-defi/defi-oracle-manipulation-guardrails/","path":"/recipes/general/crypto-defi/defi-oracle-manipulation-guardrails/","source_file":"recipes/general/crypto-defi/defi-oracle-manipulation-guardrails.md","recipe_id":"","recipe_kind":"","category":{"slug":"crypto-defi","label":"Crypto/DeFi"},"agent":"general","severity":"unspecified","maturity":"development","ecosystem":"","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"","framework_version":"","jurisdiction":"","industry":[],"cve_archetypes":[],"cve_workflow_role":"","tags":["defi","oracle","plan documentation","manipulation","risk-controls"],"facets":["remediation","risk","code-hygiene"],"quality":{"score":100,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context","multi-facet"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"Security Recipes Maintainers","team":"Security","model":"GPT-5.3-Codex","ai_assisted":false,"generated_by":"","date":"2026-04-26","zero_day":false,"last_updated":"2026-04-26","summary":"Use this prompt to add and verify protections against oracle-based price manipulation in DeFi execution paths. The model: \"GPT-5.3-Codex\" frontmatter field is recipe metadata, not a prompt pin. Rechecked August 23, 2026: leftover CVE …","content_text":"Use this prompt to add and verify protections against oracle-based price manipulation in DeFi execution paths. The model: \"GPT-5.3-Codex\" frontmatter field is recipe metadata, not a prompt pin. Rechecked August 23, 2026: leftover CVE dumps stay development / noindex. Do not invent an oracle or protocol upgrade target or a named floor from leftover dump version text. OWASP SC03:2026 Price Oracle Manipulation is still current on the Smart Contract Top 10. That list is not the retired OWASP web Top 10:2026. When to use it Borrowing, liquidation, swaps, minting, vault accounting, collateral limits, or settlement logic depends on oracle prices. Thin-liquidity assets, stale feeds, single-source spot prices, or governance-controlled parameters can create manipulation windows. Existing tests cover normal price movement but not flash spikes, stale data, feed outage, deviation limits, or fallback behavior. You need a bounded PR or triage note that adds deterministic oracle guardrails and proves risky actions fail closed. Inputs Contracts/modules that read oracle values, feed adapters, TWAP/median logic, collateral configs, liquidation paths, pause/circuit-breaker code, and governance parameter files. Feed freshness/deviation thresholds, fallback sources, emergency controls, asset liquidity assumptions, deployment configs, and prior audit findings. Available unit tests, fork/simulation tests, invariant/fuzz tests, oracle fixtures, deployment scripts, and security scan commands. Use when Liquidation and borrow limits rely on oracle prices. Thin-liquidity assets can be manipulated intra-block. Protocol needs bounded fallback behavior during oracle anomalies. Prompt ~~~markdown You are a DeFi security remediation agent implementing oracle guardrails. Goal: harden oracle consumption paths and add tests proving safe behavior under manipulation scenarios. Output PR or TRIAGE.md. Controls to implement: TWAP/medianized price checks where applicable. Maximum deviation and staleness thresholds. Secondary-source cross-check or safe pause mode. Circuit breaker for extreme price movement. Tasks: 1. Identify every contract/module that reads oracle values. 2. Add validation wrapper enforcing staleness + deviation limits. 3. Add simulation tests for flash-spike, stale feed, and feed outage. 4. Ensure fail mode is deterministic (pause/reject) rather than partially executing risky actions. Constraints: Do not relax collateral requirements to make tests pass. Keep guardrail constants in governance-controlled config. Stop with TRIAGE.md if no reliable fallback oracle exists. ~~~ Output contract Reviewer-ready PR routing oracle reads through validated wrappers with staleness, deviation, fallback, and circuit-breaker behavior. Tests or simulations for flash spikes, stale feeds, feed outage, thin liquidity, fallback mismatch, and paused/rejected execution. Operator/auditor notes describing guardrail constants, governance ownership, fallback assumptions, monitored events, and any unsupported assets. TRIAGE.md when reliable fallback sources, governance authority, or oracle deployment ownership is outside this repository. Verification - what the reviewer looks for Risky execution paths cannot consume stale, missing, manipulated, or unsupported oracle values without deterministic rejection or pause. Guardrail thresholds live in reviewable configuration with clear governance ownership, not scattered magic numbers. Negative tests hit liquidation/borrow/swap/vault paths that actually consume oracle data, not only standalone helpers. Events or telemetry provide non-secret evidence when oracle guardrails reject execution. Related recipes ERC-4626 vault inflation and rounding guardrails Cross-chain message authenticity guardrails Source code supply-chain build integrity audit","agent_handoff":{"mcp_lookup_keys":["defi-oracle-manipulation-guardrails","/recipes/general/crypto-defi/defi-oracle-manipulation-guardrails/","recipes/general/crypto-defi/defi-oracle-manipulation-guardrails.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["remediation","risk","code-hygiene"],"source_text_field":"content_text","portable_download":"security-recipe-defi-oracle-manipulation-guardrails.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-defi-oracle-manipulation-guardrails.json"}},{"slug":"defi-reentrancy-and-callback-hardening","title":"DeFi reentrancy and callback hardening","link_title":"Reentrancy and callback hardening","url":"https://security-recipes.ai/recipes/general/crypto-defi/defi-reentrancy-and-callback-hardening/","path":"/recipes/general/crypto-defi/defi-reentrancy-and-callback-hardening/","source_file":"recipes/general/crypto-defi/defi-reentrancy-and-callback-hardening.md","recipe_id":"","recipe_kind":"","category":{"slug":"crypto-defi","label":"Crypto/DeFi"},"agent":"general","severity":"unspecified","maturity":"development","ecosystem":"","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"","framework_version":"","jurisdiction":"","industry":[],"cve_archetypes":[],"cve_workflow_role":"","tags":["defi","smart-contract","reentrancy","callbacks","invariants"],"facets":["remediation","code-hygiene"],"quality":{"score":95,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"Security Recipes Maintainers","team":"Security","model":"GPT-5.3-Codex","ai_assisted":false,"generated_by":"","date":"2026-06-14","zero_day":false,"last_updated":"2026-06-14","summary":"Use this prompt to harden DeFi contracts that make external calls, transfer tokens, or rely on callback-capable standards. The model: \"GPT-5.3-Codex\" frontmatter field is recipe metadata, not a prompt pin. Rechecked August 23, 2026: …","content_text":"Use this prompt to harden DeFi contracts that make external calls, transfer tokens, or rely on callback-capable standards. The model: \"GPT-5.3-Codex\" frontmatter field is recipe metadata, not a prompt pin. Rechecked August 23, 2026: leftover CVE dumps stay development / noindex. Do not invent a contract upgrade target or a named floor from leftover dump version text. OWASP SC08:2026 and SC06:2026 still match the current Smart Contract Top 10. That list is not the retired OWASP web Top 10:2026. When to use it Use this recipe when contracts send ETH, call unknown contracts, integrate with routers, vaults, token receivers, bridges, ERC-777 hooks, ERC-4626 flows, plugin systems, or any callback-capable standard. It is also useful when multiple entry points mutate shared balances, shares, debt, rewards, reserves, or liquidation state. Use it to remove exploitable reentrancy, unchecked external-call assumptions, and callback-driven accounting drift. Do not use it as a one-function guard when the same accounting can be reached through another public path. Inputs Solidity/Vyper contracts, interfaces, external-call wrappers, token adapters, router integrations, vault adapters, bridge handlers, liquidation paths, reward contracts, and receiver/callback implementations. All value-moving entry points: deposit, withdraw, redeem, mint, borrow, repay, liquidate, claim, rebalance, harvest, flash-loan, swap, bridge, and rescue flows. Shared accounting state: balances, shares, reserves, debt, collateral, pending rewards, cumulative indexes, nonce/permit state, caps, and per-account snapshots. Existing unit tests, fuzz tests, invariant tests, malicious receiver fixtures, static-analysis findings, audit reports, and deployment constraints. External trust assumptions for tokens, routers, aggregators, callbacks, plugins, receivers, or downstream protocols that can execute code during the transaction. Research basis OWASP SC08:2026 Reentrancy Attacks still highlights stale-state exploits caused by external calls that can re-enter before the original invocation is complete. OWASP SC06:2026 Unchecked External Calls still recommends treating external calls as untrusted, checking return values, and favoring pull-based flows. Current OpenZeppelin Contracts 5.x imports ReentrancyGuard from @openzeppelin/contracts/utils/ReentrancyGuard.sol. The SCS SC08 example still shows the 4.x security/ReentrancyGuard.sol path. Do not keep that older import as current. OpenZeppelin 5.x also marks the storage-based guard deprecated in favor of ReentrancyGuardTransient for v6. Use when Contracts send ETH, call unknown contracts, or use low-level call. Token flows involve ERC-777 hooks, ERC-4626 hooks, receivers, callbacks, or plugin-style integrations. Shared accounting can be touched by multiple public entry points. Tests do not include nested-call or cross-function reentrancy cases. Prompt ~~~markdown You are a DeFi security remediation agent hardening reentrancy and callback boundaries. Goal: remove exploitable reentrancy, unchecked call assumptions, and callback-driven accounting drift. Output PR or TRIAGE.md. Controls to implement: Apply checks-effects-interactions to every value-moving path. Add scoped non-reentrant guards to sensitive entry points and cross-function shared-state paths. Prefer pull withdrawals over push transfers for untrusted recipients. Check low-level call results and token transfer return behavior. Treat token hooks, vault callbacks, receiver callbacks, and routers as untrusted external execution. Tasks: 1. Inventory all external calls, token transfers, and callback-capable integrations. 2. Map shared balances, shares, debt, rewards, and reserves that can be mutated across multiple entry points. 3. Move state updates before external calls, or isolate the external call behind a post-state pull pattern. 4. Add tests for same-function, cross-function, and multi-contract reentrancy using malicious receivers or hook-enabled tokens. 5. Add invariants proving no nested call can withdraw, mint, redeem, borrow, liquidate, or claim more value than allowed. Constraints: Do not silence a reentrancy finding only by adding a guard to one function if another entry point touches the same accounting. Do not switch to transfer or hardcoded gas assumptions as the sole mitigation. Stop with TRIAGE.md if an external dependency requires trusted callback behavior that cannot be constrained in this codebase. ~~~ Output contract Return one of: A reviewer-ready PR/change request that maps external calls and shared accounting, moves state updates before untrusted calls or converts them to pull flows, adds scoped non-reentrant protection across shared-state paths, checks low-level call and token-transfer results, adds malicious-callback tests and invariants, and documents remaining trusted-callback assumptions. TRIAGE.md when the repository does not own the value-moving code or an external dependency requires unconstrained callback behavior that cannot be remediated in this codebase. The output must list each external call/callback path, the shared state it can mutate, the mitigation applied, same-function and cross-function tests added, invariants added, and residual dependencies that still require review. It must not rely only on frontend controls, gas-stipend assumptions, or a guard on one function while another path reaches the same accounting. Related recipes ERC-4626 vault inflation and rounding guardrails DEX slippage and MEV guardrails Cross-chain message authenticity guardrails","agent_handoff":{"mcp_lookup_keys":["defi-reentrancy-and-callback-hardening","/recipes/general/crypto-defi/defi-reentrancy-and-callback-hardening/","recipes/general/crypto-defi/defi-reentrancy-and-callback-hardening.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["remediation","code-hygiene"],"source_text_field":"content_text","portable_download":"security-recipe-defi-reentrancy-and-callback-hardening.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-defi-reentrancy-and-callback-hardening.json"}},{"slug":"dex-slippage-and-mev-guardrails","title":"DEX slippage and MEV guardrails","link_title":"DEX slippage and MEV guardrails","url":"https://security-recipes.ai/recipes/general/crypto-defi/dex-slippage-and-mev-guardrails/","path":"/recipes/general/crypto-defi/dex-slippage-and-mev-guardrails/","source_file":"recipes/general/crypto-defi/dex-slippage-and-mev-guardrails.md","recipe_id":"","recipe_kind":"","category":{"slug":"crypto-defi","label":"Crypto/DeFi"},"agent":"general","severity":"unspecified","maturity":"development","ecosystem":"","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"","framework_version":"","jurisdiction":"","industry":[],"cve_archetypes":[],"cve_workflow_role":"","tags":["defi","dex","slippage","mev","front-running"],"facets":["remediation","risk"],"quality":{"score":95,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"Security Recipes Maintainers","team":"Security","model":"GPT-5.3-Codex","ai_assisted":false,"generated_by":"","date":"2026-06-14","zero_day":false,"last_updated":"2026-06-14","summary":"Use this prompt to harden swaps, liquidations, rebalances, and routing flows against missing slippage checks and predictable-ordering risk.","content_text":"Use this prompt to harden swaps, liquidations, rebalances, and routing flows against missing slippage checks and predictable-ordering risk. When to use it Use this recipe when contracts, bots, keepers, or backend services execute DEX swaps, AMM routes, aggregator calls, liquidations, rebalances, zaps, vault deposits, or strategy trades. It is especially relevant when execution bounds are zero, static, optional, UI-only, stale, or not enforced on-chain. Use it to add slippage, deadline, quote-freshness, price-impact, and ordering guardrails. Do not use it to paper over missing execution bounds with a hardcoded amountOutMin = 0 placeholder or frontend-only setting. Inputs Smart contracts, keeper code, bots, backend route builders, liquidation scripts, rebalance scripts, vault adapters, router integrations, aggregator calls, deployment config, and runbooks. Route parameters such as amountOutMin, minShares, maxAmountIn, deadlines, quote IDs, TWAP windows, oracle checks, path selection, partial fill behavior, and private-orderflow settings. On-chain and off-chain quote sources, oracle feeds, pre-trade simulations, mempool/orderflow assumptions, keeper permissions, and transaction submission paths. Existing tests, fuzz/invariant coverage, fork tests, slippage settings, sandwich/MEV findings, audit reports, and production incident notes. Monitoring and event data for quoted amount, bounded amount, executed route, realized output/input, deadline rejection, and price-impact rejection. Research basis OWASP SCWE-090: Missing Slippage Protection warns that zero or static amountOutMin values disable execution protection. OWASP SCWE-142: MEV and Transaction Ordering Dependence recommends private mempools, commit-reveal, slippage and deadline parameters, batch auctions, or fair-ordering mechanisms where appropriate. Uniswap V3 swapping guide calls out zero amountOutMinimum as a significant production risk. Use when Code calls DEX routers, aggregators, AMMs, or liquidation routes. amountOutMin, minShares, maxAmountIn, or deadlines are zero, static, optional, or controlled only by the UI. Trades can be sandwiched, backrun, or executed against stale quotes. Automated strategies rebalance or liquidate based on public mempool transactions. Prompt ~~~markdown You are a DEX execution and MEV guardrail remediation agent. Goal: prevent bad execution caused by missing slippage checks, stale quotes, and predictable transaction ordering. Output PR or TRIAGE.md. Controls to implement: Require caller-provided minimum output, maximum input, minimum shares, or equivalent execution bounds. Enforce deadlines or block-validity windows on user and automated trades. Derive default bounds from live quotes, TWAPs, oracle checks, or pre-trade simulation where the protocol owns execution. Use private orderflow, commit-reveal, batch execution, auctions, or fair-ordering design where public ordering creates material loss. Emit events for executed route, quoted amount, bounded amount, and realized amount. Tasks: 1. Inventory every swap, route, liquidation, rebalance, zap, and aggregator call. 2. Replace zero or static slippage bounds with required parameters or protocol-computed limits. 3. Add stale-quote, deadline, and price-impact rejection checks. 4. Add tests for sandwich-style price movement, volatile pool reserves, stale quote reuse, and unfavorable partial fills. 5. Add runbook notes for routes that must use private mempools or batch settlement to reduce ordering exposure. Constraints: Do not hardcode amountOutMin = 0 or equivalent placeholders in production paths. Do not rely only on frontend slippage controls if contracts can be called directly. Stop with TRIAGE.md if the code cannot access a reliable quote, oracle, or user-supplied bound for a value-moving route. ~~~ Output contract Return one of: A reviewer-ready PR/change request that inventories every value-moving route, replaces zero/static bounds with required or protocol-computed limits, enforces deadlines and quote freshness, rejects excessive price impact, adds sandwich/stale-quote/unfavorable-fill tests, emits execution evidence events, and documents private-orderflow or batch-settlement requirements. TRIAGE.md when the repository does not own the execution path or cannot access a reliable quote, oracle, pre-trade simulation, or user-supplied bound for a value-moving route. The output must list each route reviewed, old and new execution bounds, deadline/freshness policy, quote or oracle source, tests added, monitoring events added, and residual MEV/orderflow risk. It must not leave production paths with zero bounds, rely only on frontend controls, or introduce stale off-chain quotes without a rejection window. Related recipes DeFi oracle manipulation guardrails DeFi reentrancy and callback hardening ERC-4626 vault inflation and rounding guardrails","agent_handoff":{"mcp_lookup_keys":["dex-slippage-and-mev-guardrails","/recipes/general/crypto-defi/dex-slippage-and-mev-guardrails/","recipes/general/crypto-defi/dex-slippage-and-mev-guardrails.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["remediation","risk"],"source_text_field":"content_text","portable_download":"security-recipe-dex-slippage-and-mev-guardrails.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-dex-slippage-and-mev-guardrails.json"}},{"slug":"erc4626-vault-inflation-and-rounding-guardrails","title":"ERC-4626 vault inflation and rounding guardrails","link_title":"ERC-4626 inflation guardrails","url":"https://security-recipes.ai/recipes/general/crypto-defi/erc4626-vault-inflation-and-rounding-guardrails/","path":"/recipes/general/crypto-defi/erc4626-vault-inflation-and-rounding-guardrails/","source_file":"recipes/general/crypto-defi/erc4626-vault-inflation-and-rounding-guardrails.md","recipe_id":"","recipe_kind":"","category":{"slug":"crypto-defi","label":"Crypto/DeFi"},"agent":"general","severity":"unspecified","maturity":"development","ecosystem":"","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"","framework_version":"","jurisdiction":"","industry":[],"cve_archetypes":[],"cve_workflow_role":"","tags":["defi","erc4626","vault","rounding","invariants"],"facets":["remediation","code-hygiene"],"quality":{"score":95,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"Security Recipes Maintainers","team":"Security","model":"GPT-5.3-Codex","ai_assisted":false,"generated_by":"","date":"2026-06-14","zero_day":false,"last_updated":"2026-06-14","summary":"Use this prompt to harden ERC-4626 vaults and vault-like share systems against first-depositor inflation, donation attacks, and unsafe rounding. The model: \"GPT-5.3-Codex\" frontmatter field is recipe metadata, not a prompt pin. Rechecked …","content_text":"Use this prompt to harden ERC-4626 vaults and vault-like share systems against first-depositor inflation, donation attacks, and unsafe rounding. The model: \"GPT-5.3-Codex\" frontmatter field is recipe metadata, not a prompt pin. Rechecked August 23, 2026: leftover CVE dumps stay development / noindex. Do not invent a vault upgrade target or a named floor from leftover dump version text. When to use it A contract mints shares from assets, redeems assets from shares, or exposes ERC-4626-style preview/conversion functions. First deposits, direct donations, decimal offsets, fee-on-transfer assets, or custom totalAssets logic can distort share price. Rounding direction is unclear across deposit, mint, withdraw, redeem, and preview paths. You need a bounded PR or triage note that proves vault accounting resists inflation, zero-share mints, and repeated rounding loops. Inputs Vault contracts, adapters, routers, accounting libraries, preview functions, share/asset decimals, seed-liquidity scripts, and deployment parameters. Existing mitigation choices such as virtual shares/assets, dead shares, internal asset accounting, min-share slippage, fee logic, and donation policy. Available unit tests, invariant/fuzz tests, simulation scripts, deployment scripts, audit reports, and security scan commands. Research basis OpenZeppelin ERC-4626 documentation is the current Contracts 5.x guide. It still explains how direct asset donations can shift the exchange rate and cause small deposits to mint zero or too few shares. Do not keep citing the 4.x URL as current. OpenZeppelin: A novel defense against ERC4626 inflation attacks compares mitigations such as routers, internal asset accounting, virtual shares/assets, and dead shares. OWASP SC07: Arithmetic Errors recommends documenting rounding behavior and proving repeated interactions cannot create free value. Use when A vault mints shares from deposited assets or redeems assets from shares. The first deposit can be front-run by a tiny deposit plus a direct donation. Rounding may mint zero shares, leak value, or favor an attacker over repeated deposits and withdrawals. totalAssets, share supply, or conversion math is custom. Prompt ~~~markdown You are an ERC-4626 and vault-accounting remediation agent. Goal: prevent vault inflation, unsafe rounding, and accounting drift in share-based deposit and redemption flows. Output PR or TRIAGE.md. Controls to implement: Add virtual assets/shares, decimal offset, internal total-asset accounting, seed liquidity, or another explicit inflation defense. Reject deposits that would mint zero shares or violate caller-provided minimum-share expectations. Make rounding direction explicit for deposit, mint, withdraw, and redeem paths. Keep direct donations from creating profitable share-price manipulation. Add invariant and fuzz tests for first-depositor and repeated-rounding scenarios. Tasks: 1. Identify all asset-to-share and share-to-asset conversion functions. 2. Model first-depositor front-running with a tiny deposit, direct donation, victim deposit, and attacker withdrawal. 3. Patch conversion math or accounting so the attack is unprofitable and small deposits cannot be silently donated. 4. Add user-facing slippage or minimum-share parameters where callers need execution protection. 5. Add invariants proving total value cannot be created through donations, rounding loops, or deposit/redeem cycling. Constraints: Do not rely only on UI warnings or off-chain sequencing. Do not change rounding in one function without checking the inverse operation and all preview functions. Stop with TRIAGE.md if the protocol intentionally accepts donations into share price and cannot distinguish them from managed yield. ~~~ Output contract Reviewer-ready PR implementing an explicit inflation defense and consistent rounding policy across deposit, mint, withdraw, redeem, and preview flows. Tests or invariants for first-depositor attacks, direct donations, zero-share deposits, repeated rounding loops, fee edge cases, and small-value deposits. Operator/auditor notes describing mitigation choice, configured constants, migration implications, donation/yield assumptions, and residual risks. TRIAGE.md when vault economics, donation policy, or migration authority is outside this repository. Verification - what the reviewer looks for Deposits cannot silently mint zero shares or transfer value to an existing shareholder without explicit caller-provided minimums or rejection. Direct donations cannot create a profitable first-depositor or rounding-loop attack under the repository's modeled assumptions. Preview functions match execution functions and document rounding direction. Invariant or fuzz tests cover low-liquidity, first-deposit, donation, and repeated deposit/redeem scenarios. Related recipes DeFi oracle manipulation guardrails Permit and meta-transaction replay guardrails Source code supply-chain build integrity audit","agent_handoff":{"mcp_lookup_keys":["erc4626-vault-inflation-and-rounding-guardrails","/recipes/general/crypto-defi/erc4626-vault-inflation-and-rounding-guardrails/","recipes/general/crypto-defi/erc4626-vault-inflation-and-rounding-guardrails.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["remediation","code-hygiene"],"source_text_field":"content_text","portable_download":"security-recipe-erc4626-vault-inflation-and-rounding-guardrails.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-erc4626-vault-inflation-and-rounding-guardrails.json"}},{"slug":"hot-wallet-transaction-policy-enforcement","title":"Hot-wallet transaction policy enforcement","link_title":"Hot-wallet policy enforcement","url":"https://security-recipes.ai/recipes/general/crypto-defi/hot-wallet-transaction-policy-enforcement/","path":"/recipes/general/crypto-defi/hot-wallet-transaction-policy-enforcement/","source_file":"recipes/general/crypto-defi/hot-wallet-transaction-policy-enforcement.md","recipe_id":"","recipe_kind":"","category":{"slug":"crypto-defi","label":"Crypto/DeFi"},"agent":"general","severity":"unspecified","maturity":"development","ecosystem":"","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"","framework_version":"","jurisdiction":"","industry":[],"cve_archetypes":[],"cve_workflow_role":"","tags":["crypto","wallet","payments","policy","transaction-signing"],"facets":["remediation"],"quality":{"score":95,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"Security Recipes Maintainers","team":"Security","model":"GPT-5.3-Codex","ai_assisted":false,"generated_by":"","date":"2026-04-26","zero_day":false,"last_updated":"2026-04-26","summary":"Use this prompt to harden a hot-wallet signing pipeline so unsafe transactions are blocked before they can be signed.","content_text":"Use this prompt to harden a hot-wallet signing pipeline so unsafe transactions are blocked before they can be signed. When to use it Payment services sign transfers from online wallets. Destination and amount controls exist but are inconsistently enforced. You need reproducible policy checks in CI and runtime. Inputs Signing entrypoint names, wallet service paths, and transaction request schemas. Approved chains, assets, destination allowlists, per-transaction caps, rolling daily caps, and business-reason requirements. Existing policy store, logging, metrics, and alerting conventions. Test harness or simulation mode that can exercise signing flows without broadcasting transactions. Prompt ~~~markdown You are a security remediation agent for a cryptocurrency payment system. Goal: enforce a deterministic transaction-policy gate for hot-wallet signing requests. Produce either: 1) a PR that adds policy enforcement + tests, or 2) TRIAGE.md if you cannot safely complete. Policy checks must include: allowed chain, allowed asset, destination allowlist, per-tx cap, rolling daily cap, and required business reason. Constraints: Never sign or broadcast real transactions. Operate in dry-run/simulation mode only. Fail closed if policy data is unavailable. Implementation tasks: 1. Locate signing entrypoints and insert a validateTransactionPolicy guard before any signer call. 2. Ensure every rejection is logged with reason code and request ID, without logging secrets. 3. Add tests for allow, reject-by-destination, reject-by-amount, reject-by-daily-cap, and reject-by-missing-policy-store. 4. Add a runbook note describing rollback and emergency deny-all mode. Stop and write TRIAGE.md if signing paths are dynamic/reflection-based and cannot be bounded confidently. ~~~ Output contract PR that inserts fail-closed policy enforcement before every signer call. Tests for allowed requests, blocked destinations, blocked amounts, rolling-limit exhaustion, and missing policy data. Audit log fields for request id, rejection reason, policy version, and actor without secrets or private keys. TRIAGE.md when signing paths, policy ownership, or simulation coverage cannot be bounded safely. Verification Run unit and integration tests in dry-run mode only. Confirm no code path signs or broadcasts a real transaction during the recipe run. Verify missing policy data, policy-store outage, and malformed requests fail closed. Guardrails Do not sign, broadcast, sweep, or move funds. Do not log seed phrases, private keys, full wallet addresses beyond the approved audit format, or raw transaction secrets. Stop if a signing path cannot be located, policy limits conflict, or the runtime cannot enforce deny-all mode. Related recipes Bridge/multisig emergency response Seed/key material purge Crypto payment address integrity checks","agent_handoff":{"mcp_lookup_keys":["hot-wallet-transaction-policy-enforcement","/recipes/general/crypto-defi/hot-wallet-transaction-policy-enforcement/","recipes/general/crypto-defi/hot-wallet-transaction-policy-enforcement.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["remediation"],"source_text_field":"content_text","portable_download":"security-recipe-hot-wallet-transaction-policy-enforcement.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-hot-wallet-transaction-policy-enforcement.json"}},{"slug":"permit-and-meta-transaction-replay-guardrails","title":"Permit and meta-transaction replay guardrails","link_title":"Permit replay guardrails","url":"https://security-recipes.ai/recipes/general/crypto-defi/permit-and-meta-transaction-replay-guardrails/","path":"/recipes/general/crypto-defi/permit-and-meta-transaction-replay-guardrails/","source_file":"recipes/general/crypto-defi/permit-and-meta-transaction-replay-guardrails.md","recipe_id":"","recipe_kind":"","category":{"slug":"crypto-defi","label":"Crypto/DeFi"},"agent":"general","severity":"unspecified","maturity":"development","ecosystem":"","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"","framework_version":"","jurisdiction":"","industry":[],"cve_archetypes":[],"cve_workflow_role":"","tags":["defi","signature","permit","replay","eip712"],"facets":["remediation","code-hygiene"],"quality":{"score":95,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"Security Recipes Maintainers","team":"Security","model":"GPT-5.3-Codex","ai_assisted":false,"generated_by":"","date":"2026-06-14","zero_day":false,"last_updated":"2026-06-14","summary":"Use this prompt to prevent signature replay across chains, contracts, forks, functions, and repeated permit or meta-transaction execution. The model: \"GPT-5.3-Codex\" frontmatter field is recipe metadata, not a prompt pin. Rechecked August …","content_text":"Use this prompt to prevent signature replay across chains, contracts, forks, functions, and repeated permit or meta-transaction execution. The model: \"GPT-5.3-Codex\" frontmatter field is recipe metadata, not a prompt pin. Rechecked August 23, 2026: leftover CVE dumps stay development / noindex. Do not invent a permit or meta-transaction upgrade target or a named floor from leftover dump version text. When to use it Contracts or services implement permit, delegated execution, meta-transactions, gasless approvals, off-chain orders, claims, or governance signatures. Signed payloads can authorize transfers, approvals, withdrawals, orders, claims, role changes, or other state-changing actions. Domain separators, nonces, deadlines, typed-data fields, upgrade behavior, or fork handling are custom or partially implemented. You need a bounded PR or triage note that binds every signature to one chain, contract, purpose, signer state, and expiration window. Inputs Signature verification code, EIP-712 domain construction, nonce storage, order books, relayer/meta-tx handlers, upgradeable proxy config, and permit adapters. Chain IDs, verifying contracts, domain names/versions, typed-data schemas, nonce namespaces, deadline rules, signer recovery logic, and migration notes. Available unit tests, fork tests, fuzz/property tests, signature fixtures, deployment scripts, audit reports, and security scan commands. Research basis OWASP SCWE-105: Permit Signature Replay recommends EIP-712 domain separators with name, version, chain ID, and verifying contract plus nonce handling. EIP-2612 defines permit, nonces, deadlines, and domain separation requirements. EIP-712 uses domain separation to prevent collisions between otherwise identical signed structures. Use when Contracts implement permit, meta-transactions, delegated actions, or off-chain approvals. Signatures authorize transfers, approvals, withdrawals, orders, claims, or governance actions. Domain separators, nonces, deadlines, or typed-data fields are custom. Signatures may be replayed after forks, upgrades, or deployments to another chain. Prompt ~~~markdown You are a DeFi signature replay remediation agent. Goal: bind every signed action to one chain, one contract, one purpose, one signer state, and one expiration window. Output PR or TRIAGE.md. Controls to implement: Use EIP-712 typed data with domain fields for name, version, chainId, and verifyingContract. Include action-specific fields so signatures cannot authorize a different function or asset. Enforce per-signer nonces, order nonces, or nonce bitmaps before state changes complete. Enforce deadlines or validity windows. Reject zero address owners, mismatched signers, reused signatures, and malformed signatures. Tasks: 1. Inventory all signature verification paths and the assets or actions they authorize. 2. Compare signed fields against the state changes they permit and add any missing chain, contract, nonce, deadline, spender, asset, amount, recipient, or function intent fields. 3. Ensure nonce consumption is atomic and cannot be skipped on success. 4. Add tests replaying signatures across chains, contracts, forks, functions, nonce states, and expired deadlines. 5. Add migration notes for any domain separator or version change that intentionally invalidates old signatures. Constraints: Do not accept signatures without clear replay scope and expiration. Do not reuse one nonce namespace for unrelated actions unless that behavior is intentional and tested. Stop with TRIAGE.md if existing live signatures must remain valid and the safe migration path requires governance or user coordination. ~~~ Output contract Reviewer-ready PR binding each signed action to explicit domain fields, action-specific typed data, signer identity, nonce state, and deadline before any state change. Tests for replay across chains, contracts, forks, function intents, nonce states, expired deadlines, malformed signatures, and zero-address owners. Operator/auditor notes describing domain/version changes, migration effects, nonce namespace choices, live-signature invalidation, and governance needs. TRIAGE.md when a safe signature migration or governance decision is outside this repository. Verification - what the reviewer looks for Signatures cannot be replayed across chain IDs, verifying contracts, proxy deployments, function intents, assets, recipients, or nonce states. Nonce consumption is atomic with successful execution and cannot be skipped or reused after partial failure. Deadlines or validity windows are enforced before state changes. Tests cover both canonical valid signatures and malicious reuse scenarios against the actual entry points. Related recipes ERC-4626 vault inflation and rounding guardrails Crypto payment address integrity checks Source code supply-chain build integrity audit","agent_handoff":{"mcp_lookup_keys":["permit-and-meta-transaction-replay-guardrails","/recipes/general/crypto-defi/permit-and-meta-transaction-replay-guardrails/","recipes/general/crypto-defi/permit-and-meta-transaction-replay-guardrails.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["remediation","code-hygiene"],"source_text_field":"content_text","portable_download":"security-recipe-permit-and-meta-transaction-replay-guardrails.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-permit-and-meta-transaction-replay-guardrails.json"}},{"slug":"seed-phrase-and-key-material-purge","title":"Seed phrase and key-material purge","link_title":"Seed/key material purge","url":"https://security-recipes.ai/recipes/general/crypto-defi/seed-phrase-and-key-material-purge/","path":"/recipes/general/crypto-defi/seed-phrase-and-key-material-purge/","source_file":"recipes/general/crypto-defi/seed-phrase-and-key-material-purge.md","recipe_id":"","recipe_kind":"","category":{"slug":"crypto-defi","label":"Crypto/DeFi"},"agent":"general","severity":"unspecified","maturity":"development","ecosystem":"","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"","framework_version":"","jurisdiction":"","industry":[],"cve_archetypes":[],"cve_workflow_role":"","tags":["crypto","secrets","seed-phrase","private-key","incident-response"],"facets":["remediation","code-hygiene"],"quality":{"score":95,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"Security Recipes Maintainers","team":"Security","model":"GPT-5.3-Codex","ai_assisted":false,"generated_by":"","date":"2026-04-26","zero_day":false,"last_updated":"2026-04-26","summary":"Use this prompt to locate and remove exposed wallet seed phrases, private keys, and signing credentials from code and operational systems.","content_text":"Use this prompt to locate and remove exposed wallet seed phrases, private keys, and signing credentials from code and operational systems. When to use it A scan found possible BIP-39 mnemonics or private keys. Secrets appeared in logs, tickets, or CI output. Key rotation and chain migration runbooks are needed. Inputs Finding id, detector output, affected file/log/ticket locations, and first-seen evidence. Secret class, chain or wallet context, custody system, owner, and rotation authority. Approved redaction, placeholder, test-vector, and secret-scanning rules. Incident ticket, disclosure requirements, and balance-migration runbook. Prompt ~~~markdown You are a security remediation agent handling exposed crypto key material. Goal: eradicate exposed key material and stage rotation actions. Output either: PR + incident audit note, or TRIAGE.md when privileged rotation steps are blocked. Tasks: 1. Search repository and generated artifacts for candidate seed phrases, private keys, and keystore passphrases using approved detectors. 2. Remove exposures from source, examples, docs, tests, and fixtures. 3. Replace with redacted placeholders and safe test vectors. 4. Add pre-commit/CI secret detection rules tuned for crypto material. 5. Draft rotation checklist: revoke old keys, rotate signer identities, migrate remaining balances, and verify post-rotation health. Constraints: Never print full secret values in output. Keep only minimal fingerprint/hash for audit correlation. If active key rotation requires production privileges, stop and write TRIAGE.md with explicit human steps. ~~~ Output contract PR removing exposed key material from source, docs, tests, examples, and generated artifacts. Scanner or pre-commit rule update that prevents recurrence. Incident audit note with minimal fingerprints, affected locations, rotation owner, and remaining human actions. TRIAGE.md when production rotation, chain migration, or history rewriting requires a privileged human runbook. Verification Run the approved secret scanners over the repository and generated artifacts after remediation. Confirm outputs include only hashes or minimal fingerprints, never full key material. Verify safe test vectors replace real-looking private keys and seed phrases in fixtures. Guardrails Do not print, copy, or transform full seed phrases, private keys, or keystore passphrases into logs, commit messages, prompts, or PR bodies. Do not rewrite shared git history or rotate production keys from this recipe run. Stop if ownership, custody workflow, or rotation authority is missing. Related recipes Sensitive data remediation Hot-wallet policy enforcement Compromised package cache quarantine","agent_handoff":{"mcp_lookup_keys":["seed-phrase-and-key-material-purge","/recipes/general/crypto-defi/seed-phrase-and-key-material-purge/","recipes/general/crypto-defi/seed-phrase-and-key-material-purge.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["remediation","code-hygiene"],"source_text_field":"content_text","portable_download":"security-recipe-seed-phrase-and-key-material-purge.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-seed-phrase-and-key-material-purge.json"}},{"slug":"smart-contract-upgrade-diff-risk-review","title":"Smart-contract upgrade diff risk review","link_title":"Contract upgrade diff review","url":"https://security-recipes.ai/recipes/general/crypto-defi/smart-contract-upgrade-diff-risk-review/","path":"/recipes/general/crypto-defi/smart-contract-upgrade-diff-risk-review/","source_file":"recipes/general/crypto-defi/smart-contract-upgrade-diff-risk-review.md","recipe_id":"","recipe_kind":"","category":{"slug":"crypto-defi","label":"Crypto/DeFi"},"agent":"general","severity":"unspecified","maturity":"development","ecosystem":"","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"","framework_version":"","jurisdiction":"","industry":[],"cve_archetypes":[],"cve_workflow_role":"","tags":["defi","smart-contract","upgrade","proxy","invariants"],"facets":["remediation","audit","risk","code-hygiene"],"quality":{"score":100,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context","multi-facet"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"Security Recipes Maintainers","team":"Security","model":"GPT-5.3-Codex","ai_assisted":false,"generated_by":"","date":"2026-04-26","zero_day":false,"last_updated":"2026-04-26","summary":"Use this prompt to review upgrade diffs and enforce invariant checks before smart-contract changes are approved. The model: \"GPT-5.3-Codex\" frontmatter field is recipe metadata, not a prompt pin. Rechecked August 23, 2026: leftover CVE …","content_text":"Use this prompt to review upgrade diffs and enforce invariant checks before smart-contract changes are approved. The model: \"GPT-5.3-Codex\" frontmatter field is recipe metadata, not a prompt pin. Rechecked August 23, 2026: leftover CVE dumps stay development / noindex. Do not invent an implementation or proxy-admin upgrade target or a named floor from leftover dump version text. OWASP SC10:2026 Proxy and Upgradeability is still current on the Smart Contract Top 10. That list is not the retired OWASP web Top 10:2026. When to use it Proxy implementation contracts are changing. Storage layout or access-control logic is modified. Emergency patches must still prove safety. Inputs Old and new implementation addresses, source commits, compiler versions, ABI files, storage-layout artifacts, and deployment chain id. Timelock, proxy admin, guardian, owner, and role-assignment evidence. Existing invariant, fork-test, simulation, and formal-check outputs. Approved upgrade proposal, reviewer policy, and emergency-change exception record when applicable. Prompt ~~~markdown You are a DeFi security remediation agent reviewing contract upgrades. Goal: produce a PR that adds upgrade-risk checks and test coverage, or TRIAGE.md if upgrade safety cannot be established. Required checks: Storage layout compatibility (no unsafe slot collisions). Access-control changes and role escalation diff. Pause/guardian semantics unchanged or explicitly approved. Solvency and collateral invariants across fork tests. Tasks: 1. Generate a machine-readable diff of old vs new ABI, storage layout, events, and privileged functions. 2. Add/extend tests for invariants and permission boundaries. 3. Fail CI on unauthorized changes to timelock delay or signer threshold. 4. Produce reviewer checklist summarizing high-risk deltas. Constraints: No mainnet execution from this run. No silent ignore of compiler warnings. Stop with TRIAGE.md if baseline artifacts are missing. ~~~ Output contract Machine-readable upgrade diff covering ABI, storage layout, events, privileged functions, roles, and timelock-sensitive parameters. Added or updated tests for storage compatibility, authorization, pause/guardian behavior, solvency, and collateral invariants. Reviewer checklist that separates approved deltas from unresolved risks. TRIAGE.md when baseline artifacts, chain evidence, or test harnesses are missing. Verification Run compiler, storage-layout comparison, invariant tests, and fork tests required by the repository. Confirm unauthorized timelock, signer-threshold, proxy-admin, or guardian changes fail CI. Compare generated ABI and privileged-function diffs against the approved proposal. Guardrails Do not execute mainnet transactions, submit proposals, or sign upgrade payloads. Do not approve compiler warnings, storage-layout drift, or access-control expansion without explicit reviewer evidence. Stop if the old implementation artifact cannot be reproduced. Related recipes Bridge/multisig emergency response DeFi admin key and role blast-radius review DeFi reentrancy and callback hardening","agent_handoff":{"mcp_lookup_keys":["smart-contract-upgrade-diff-risk-review","/recipes/general/crypto-defi/smart-contract-upgrade-diff-risk-review/","recipes/general/crypto-defi/smart-contract-upgrade-diff-risk-review.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["remediation","audit","risk","code-hygiene"],"source_text_field":"content_text","portable_download":"security-recipe-smart-contract-upgrade-diff-risk-review.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-smart-contract-upgrade-diff-risk-review.json"}},{"slug":"cve-intelligence-intake-gate","title":"CVE intelligence intake gate","link_title":"CVE intelligence intake gate","url":"https://security-recipes.ai/recipes/general/cve-intelligence-intake-gate/","path":"/recipes/general/cve-intelligence-intake-gate/","source_file":"recipes/general/cve-intelligence-intake-gate.md","recipe_id":"","recipe_kind":"","category":{"slug":"general","label":"General"},"agent":"general","severity":"unspecified","maturity":"development","ecosystem":"","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"","framework_version":"","jurisdiction":"","industry":[],"cve_archetypes":["*"],"cve_workflow_role":"intake","tags":["cve","intelligence","triage","advisory","guardrail"],"facets":["remediation"],"quality":{"score":95,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"Codex","team":"Security","model":"GPT 5.5 Extra High reasoning","ai_assisted":false,"generated_by":"","date":"2026-06-06","zero_day":false,"last_updated":"2026-06-06","summary":"Process one CVE intelligence signal through source validation, finding classification, recipe routing, and bounded agent handoff before remediation.\n","content_text":"A tool-agnostic prompt that turns a fresh CVE, GHSA, OSV, vendor bulletin, scanner alert, or ticket into one of five bounded outcomes: accept for a remediation PR; accept for temporary containment; suppress as not exposed; stop for human triage; reject as an unverified signal. Use this before handing an agent a remediation prompt when the advisory is new, sources disagree, exploitability is unclear, or the scanner finding lacks enough context for a reviewer-ready fix. What this prompt does 1. Reads the advisory signal and normalizes its identifiers, aliases, affected surface, affected range, fixed versions, mitigations, and source links. 2. Prioritizes primary sources: vendor patch notes, GitHub Advisory Database, CVE/NVD, OSV or package-registry advisories, then CISA KEV or exploitation signals. 3. Checks repository evidence: manifests, lockfiles, images, code paths, middleware, runtime configuration, deployment artifacts, and scanner output. 4. Decides whether a safe agent task exists. 5. Outputs either a remediation packet, a containment packet, a suppression note, or TRIAGE.md. When to use it A CVE or GHSA just landed and the team needs to know whether an agent should patch, contain, suppress, or stop. Multiple sources disagree about fixed versions, severity, affected ranges, or exploitability. A scanner reports a vulnerable dependency but does not prove reachability or ownership. The advisory targets an agent, MCP, browser automation, workflow, identity, tenant, or connector surface where naive upgrades may miss the real boundary. Do not use this to replace the actual remediation recipe. This gate decides whether the remediation prompt is safe to run and what evidence it must carry. Floor honesty for agents and MCP Do not invent a fixed version. A named floor is only usable when the live source still publishes it. Live GitHub Advisory Database pages at https://github.com/advisories/GHSA-… can 404 even when a repository advisory still exists. A 404 is not a floor. A GHSA with empty vulnerabilities or a null firstpatchedversion is not a floor. Do not write “GHAD names” or “per GHSA” in that state. NVD can return no row. Retry once. If the row is still missing, say NVD has no row. Do not invent CPE ranges to fill the gap. When NVD versionEndExcluding and a vendor last-affects or first-patched line disagree, keep both. Do not flatten the higher vendor line onto NVD. A ghsa: null frontmatter field is stale metadata until the live GHSA is confirmed. It is not proof that GitHub never published an advisory. MCP tools that return this recipe must keep that split. Search snippets and agent answers inherit the same rule. Inputs Advisory ID: CVE, GHSA, OSV-family ID, ecosystem advisory ID such as PYSEC, RUSTSEC, GO, USN, RHSA, ALAS, or VMSA, vendor ID, package-registry advisory, or scanner finding ID. Optional affected package, image, runtime, route, plugin, framework, or product hint. Scanner output, ticket text, SBOM row, dependency graph row, or incident note. Repository path or deployment scope the agent is allowed to inspect. The local intake policy: data/intelligence/cve-intelligence-intake-gates.json. Optional local evaluator: scripts/evaluatecveintelligenceintake.py. The prompt ~~~markdown You are running the CVE intelligence intake gate for this repository. Output exactly one of: REMEDIATIONPACKET.md CONTAINMENTPACKET.md SUPPRESSION.md TRIAGE.md REJECTEDSIGNAL.md Do not change application code, dependencies, lockfiles, deployment manifests, runtime configuration, scanner suppressions, or tickets. This is an intake and routing task only. Step 0 - Load policy and scope 1. Read data/intelligence/cve-intelligence-intake-gates.json. 2. Record the repository path, service, package, image, route, or deployment scope you are allowed to inspect. 3. Record evaluationdate in YYYY-MM-DD format for this intake decision. 4. Normalize the advisory identifiers: CVE, GHSA, OSV-family ID, ecosystem or vendor advisory ID, registry advisory ID, scanner finding ID, and aliases. The canonical ID must match a supported advisory format exactly. If the only candidate is a prefix plus extra text, or the canonical ID is malformed even though an alias is valid, stop with TRIAGE.md. Step 1 - Gather primary evidence For each available source, capture the link, publisher, timestamp if present, affected surface, affected range, fixed version or commit, mitigation, severity, and exploitation status. A source type without an absolute http or https source URL is not primary evidence. Keep it as a note, but stop with TRIAGE.md unless another primary source link is available. Likewise, primarysourcebacked: true does not turn scanner output, ticket text, social-media links, or unknown-source links into primary evidence. Use this priority order: 1. Vendor advisory, release notes, patch commit, or security bulletin. 2. GitHub Advisory Database. 3. CVE record or NVD entry. 4. OSV, package-registry advisory, or ecosystem security feed. 5. CISA KEV, vendor exploitation notice, incident signal, or trusted threat intelligence feed. A known-exploited or threat-intelligence feed raises priority, but it is not a standalone remediation source. Pair it with a vendor advisory or patch, GitHub Advisory Database entry, CVE/NVD record, OSV entry, or package-registry advisory before accepting remediation, containment, or suppression. If sources disagree in a way that changes the fix, stop with TRIAGE.md. Do not invent a fixed version to resolve the disagreement. A live GHAD 404, empty vulnerabilities, or null firstpatchedversion is not a floor. Do not write “GHAD names” or “per GHSA” in that state. If NVD returns no row after one retry, say NVD has no row. Step 2 - Prove repository relevance Inspect only the allowed scope. 1. Search manifests, lockfiles, SBOMs, image definitions, vendored code, runtime config, deployment manifests, and scanner output for the affected surface. 2. Identify whether the vulnerable component is direct, transitive, vendored, image-layer, runtime-provided, plugin-provided, or deployment-provided. 3. Determine whether exploit preconditions are present: untrusted input, internet reachability, tenant crossing, auth or billing gate, file upload, model/checkpoint loading, deserialization, SSRF-capable URL fetch, command execution, browser automation, MCP tool execution, or connector approval. 4. Capture exact evidence paths and commands. Do not use secrets, production customer data, live tokens, or exploit payloads. Step 3 - Choose one decision Choose REMEDIATIONPACKET.md only when all are true: stable identifier exists; affected surface maps to repository-owned code, dependency, image, or deployment artifact; fixed version, fixed commit, or safe configuration mitigation exists; the fix is inside repository ownership and a named owner is recorded; reviewer-runnable verification exists. Choose CONTAINMENTPACKET.md when exposure is plausible or confirmed but the full fix is blocked and a temporary control can reduce exposure. Include an owner and YYYY-MM-DD follow-up date that is not earlier than evaluationdate. Name the exact control, configuration change, rule, or compensating action; a boolean temporary-control marker is not enough. Choose SUPPRESSION.md when the vulnerable surface is absent, unreachable, dev-only, test-only, or below exploit preconditions. Include owner, YYYY-MM-DD expiration that is not already stale, and recheck command. Choose TRIAGE.md when evidence is missing, sources disagree, ownership is unclear, the fix requires a migration, or safe verification is not possible. Choose REJECTEDSIGNAL.md when the claim has no primary source, no stable affected surface, and no safe reviewer-runnable validation. Step 4 - Write the packet Every output must include: canonical ID and aliases; source links used; which source links counted as standalone primary evidence and which were auxiliary, invalid, or non-standalone; affected surface and affected range; repository evidence found; decision and why; evaluation date used for follow-up freshness; priority modifiers such as KEV, public reachability, agent/control-plane impact, or no known fix; selected SecurityRecipes recipe or prompt if one is ready to run; fix, containment, suppression, triage, or rejection path; exact verification or recheck commands; owner for the decision record; YYYY-MM-DD follow-up date, not earlier than evaluationdate, when action continues outside this packet. Safety rules Do not auto-merge. Do not generate exploit payloads against live systems. Do not log secrets, cookies, tokens, tenant IDs, customer content, or private vulnerability details. Do not change unrelated dependencies while routing one advisory. Do not disable authentication, authorization, validation, or tests to make an upgrade appear safe. Do not open write-capable connectors only to gather vulnerability context. ~~~ Output contract The output is a routing artifact, not a patch. A reviewer should be able to read it and decide whether to run a per-CVE recipe, the generic vulnerable-dependency workflow, the base-image workflow, containment, or human triage. Validate reviewer-ready packets with: python3 scripts/evaluatecveintelligenceintake.py \\ --packet path/to/intake-packet.json For model-generated Markdown packets, translate the required fields into JSON first or pass them as CLI flags. The evaluator checks policy evidence, primary source backing, source disagreement, ownership clarity, verification safety, exposure status, and whether the packet should remediate, contain, suppress, triage, or reject the signal. The evaluator output includes sourceevidence, validprimarysourcecount, and invalidornonstandalonesourcecount. Use those fields in review notes and CI logs so a KEV, scanner, ticket, social-media, or unknown-source link does not get mistaken for standalone remediation evidence. Verification The packet names a primary vendor, NVD, or GHSA source. CISA KEV is supporting context, not standalone remediation evidence. Affected range and fixed version disagreements that change the patch are marked triage, not remediate. Exposure is recorded as installed vs reachable, and every accepted task names a reviewer-runnable verification command. evaluatecveintelligenceintake.py accepts the packet or the CLI flags translated from it. Guardrails Primary-source backed. Scanner text is an input, not the final source of truth. KEV-only or threat-intelligence-only packets need a remediation source before an agent patches. Exposure-aware. Installed is not the same as reachable. Fix-path required. No remediation PR without a known fixed version, fixed commit, safe mitigation, or explicit containment path. A live GHAD 404, empty vulnerabilities, or null firstpatchedversion is not a known fixed version. Stop on disagreement. If the affected range or fixed version differs across sources in a way that changes the patch, triage. Keep the GHAD and NVD split. Do not invent a later tag. Reviewer-runnable verification.** Every accepted task names the command or probe that proves the decision. Related CVE Database targeted prompts for high-signal named vulnerabilities. Vulnerable Dependency Remediation the generic workflow for routine package CVEs. Base Image & Container Layer Remediation the generic workflow for OS-package and image-layer CVEs. Artifact Cache & Mirror Quarantine the downgrade path for malicious-package or compromised-artifact advisories.","agent_handoff":{"mcp_lookup_keys":["cve-intelligence-intake-gate","/recipes/general/cve-intelligence-intake-gate/","recipes/general/cve-intelligence-intake-gate.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["remediation"],"source_text_field":"content_text","portable_download":"security-recipe-cve-intelligence-intake-gate.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-cve-intelligence-intake-gate.json"}},{"slug":"owasp-top-10-2025-audit","title":"OWASP Top 10:2025 — repo audit","link_title":"OWASP Top 10:2025 audit","url":"https://security-recipes.ai/recipes/general/owasp-top-10-2025-audit/","path":"/recipes/general/owasp-top-10-2025-audit/","source_file":"recipes/general/owasp-top-10-2025-audit.md","recipe_id":"","recipe_kind":"","category":{"slug":"general","label":"General"},"agent":"general","severity":"unspecified","maturity":"development","ecosystem":"","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"","framework_version":"","jurisdiction":"","industry":[],"cve_archetypes":[],"cve_workflow_role":"","tags":["owasp","top-10","audit","hunt","sast","security-posture"],"facets":["remediation","audit","compliance","risk","code-hygiene"],"quality":{"score":100,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context","multi-facet"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"Stephen M Abbott","team":"Security","model":"Opus 4.7","ai_assisted":false,"generated_by":"","date":"2026-04-22","zero_day":false,"last_updated":"2026-04-22","summary":"Audit a repository against the current OWASP Top 10:2025 web application risks and return a prioritized, read-only report with file-level evidence.\n","content_text":"A tool-agnostic hunt prompt that walks an agent through a structured audit of a repository against every category in the OWASP Web Application Top 10:2025. Rechecked August 23, 2026: OWASP still identifies 2025 as the current web-application Top 10 edition. Retired 2026 audit and remediate slugs on this site stay noindex redirects to these 2025 recipes. The output is a prioritised report with file-level pointers and concrete remediation recommendations — not a fix. Pair this with the companion remediate prompt, OWASP Top 10:2025 — remediate, to take a single finding from the report to an open PR. What this prompt does It asks the agent to: 1. Enumerate the repo — language, framework, entry points, auth mechanism, data stores, external calls, secret-handling paths. 2. Walk each OWASP Top 10:2025 category and look for concrete instances, not theoretical risk. 3. Score and group findings by category, severity, and blast radius. 4. Emit a structured report a reviewer can hand to product teams or feed into the remediate prompt. Runs read-only. Does not edit files. No PRs. When to use it Quarterly posture review of a service you own. Diligence pass before a new service moves to production. Follow-on after a pen-test report that only listed categories, not file paths. Don't use it for: Real-time exploit triage — too slow and too broad. Replacing SAST/DAST — this is a structured LLM pass, not a vulnerability scanner. It catches design-level issues scanners miss and misses pattern-level issues scanners catch. Run both. Inputs The agent should infer as much as it can from the working session and prompt only when genuinely ambiguous: Repo — the working directory the agent is running in. Scope — if the user mentions a specific directory or service, restrict to that. Otherwise, audit the whole repo. Deployment target — infer from Dockerfile / k8s/ / terraform/ / CI config. If unknown, note it in the report. Auth / authz model — infer from routing + middleware + any auth/ module. If unclear, note it. Do not refuse to run because an input is missing; produce the best report you can and flag the gaps. The prompt ~~~markdown You are performing a security posture audit of this repository against the OWASP Web Application Top 10:2025. Run read-only. Do not edit files or run destructive commands. Step 0 — Repo orientation Before auditing, infer and record: Primary language and framework. Entry points (HTTP routes, gRPC services, queue consumers, CLI commands, scheduled jobs). Authentication mechanism. Data stores touched (databases, caches, object storage, message queues). External services called. Secret handling (env vars, secret managers, config files). CI / deployment pipeline — where is this run, how is it built. Record these in a short \"Context\" section at the top of the report. If any are unknown after a reasonable look, say so — do not guess. Step 1 — Walk each OWASP Top 10:2025 category For each category, answer three questions: 1. What would this look like in this codebase? (The concrete shape the weakness would take, given the framework and entry points.) 2. Did you find any instances? (File paths, line numbers, and a one-line excerpt for each.) 3. What would fix or mitigate it? (Specific, actionable — \"add authz check to route X\" beats \"improve access control\".) Categories to cover Use the official OWASP Top 10:2025 web-application category names. If OWASP publishes a newer web-application Top 10, note the newer version and date at the top of the report before applying this prompt. Cover: A01 — Broken Access Control. Missing authz checks on routes, IDOR patterns, tenant-id trust from client, over-broad admin endpoints. Include SSRF-shaped outbound-request trust failures here when they cross access-control boundaries. A02 — Security Misconfiguration. Debug mode in production paths, permissive CORS, default credentials, verbose error pages, cloud resources without least-privilege IAM, missing security headers. A03 — Software Supply Chain Failures. Unpinned or vulnerable dependencies, unsigned release artifacts, CI pipelines that trust unverified third-party actions, abandoned upstreams, vendored code without clear provenance. A04 — Cryptographic Failures. Weak/old ciphers, hard-coded keys, TLS verification disabled, plaintext-at-rest for sensitive fields, bad password hashing (MD5/SHA1/unsalted). A05 — Injection. SQL/NoSQL/command/LDAP/XPath injection, unsafe template rendering, prompt injection paths for LLM features (untrusted text pasted into a system prompt or tool call). A06 — Insecure Design. Missing rate limits on auth-adjacent endpoints, enumeration oracles (login, password-reset, invite-by-email), trust boundaries crossed without validation, features shipped without a threat model. A07 — Authentication Failures. Weak session handling, no MFA for sensitive ops, no account lockout or rate limiting on login, password policy gaps, tokens in URLs. A08 — Software or Data Integrity Failures. Deserialization of untrusted data, unsafe auto-update paths, unsigned data artifacts, missing integrity checks for code or data inputs. A09 — Security Logging and Alerting Failures. Sensitive operations that emit no audit record, PII/secrets in logs, missing correlation IDs, no alerting on auth anomalies. A10 — Mishandling of Exceptional Conditions. Failing open, unsafe error recovery, exception paths that skip authorization or validation, verbose exception leaks, and crash loops that become denial-of-service or privilege boundary failures. Do not substitute the OWASP LLM, Agentic, API, Mobile, or Smart Contract Top 10 projects unless the finding explicitly targets those domains; those are separate OWASP projects with different category taxonomies. Step 2 — Score and prioritise For each finding, assign: Severity — critical / high / medium / low. Use CVSS-style reasoning; err low when exploitation requires already-privileged access. Blast radius — scope of impact if exploited (one tenant, all tenants, infra, etc.). Confidence — high / medium / low. Low confidence is fine; flag it so a reviewer can verify. Sort the report by (severity, blast radius, confidence). Step 3 — Emit the report Write the report to SECURITYAUDIT.md at the repo root (or print to stdout if the session is read-only). Use this structure: OWASP Top 10:2025 audit — <repo name> Generated by <agent name> on <date>. OWASP version: Web Application Top 10:2025. Context Language / framework: ... Entry points: ... Auth model: ... Data stores: ... Deploy target: ... Gaps in context: ... Findings <Severity> — <A0X category> — <short title> File: path/to/file.py:42 Excerpt: ...one line of code... Why it's flagged: ... Blast radius: ... Confidence: ... Recommended fix: ... (repeat for each finding, sorted) Categories with no findings A0X — reasoning for why no instance was found (searched patterns, areas covered). Gaps Things the audit could not reach (e.g., \"no access to the IAM config for the deployed environment\"). Stop conditions Stop and write a note rather than guessing if: The repo is larger than you can meaningfully audit in one pass. Suggest splitting by module and re-running. A category requires runtime context you do not have (for example, deploy configuration lives in another repo). You find credentials, private keys, or unmistakable exploit artifacts — flag these to the top of the report immediately and stop; they are an incident, not an audit finding. ~~~ Output contract A single SECURITYAUDIT.md file with the structure above, or the same content on stdout if write access is not available. No source file edits. No PRs. Guardrails Read-only. The agent should not use any write tool. Do not exfiltrate repo contents to external services. If the agent has web-search / fetch tools, restrict them to looking up CVE advisories and OWASP documentation. Redact any credentials, tokens, or private keys the agent stumbles on while reading code — the report references them by file/line, never by value. How to hand off to remediation Pick the top finding. Feed its file, line, category, and recommended fix into the companion prompt: OWASP Top 10:2025 — remediate. Review the PR it opens. Related Fundamentals — vocabulary used in the report (SAST, SSRF, blast radius). MCP Integration — wiring an agent to scanners so audits can cross-reference existing findings. OWASP Top 10:2025 — remediate OWASP Top 10:2025 official project","agent_handoff":{"mcp_lookup_keys":["owasp-top-10-2025-audit","/recipes/general/owasp-top-10-2025-audit/","recipes/general/owasp-top-10-2025-audit.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["remediation","audit","compliance","risk","code-hygiene"],"source_text_field":"content_text","portable_download":"security-recipe-owasp-top-10-2025-audit.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-owasp-top-10-2025-audit.json"}},{"slug":"owasp-top-10-2025-remediate","title":"OWASP Top 10:2025 — remediate","link_title":"OWASP Top 10:2025 remediate","url":"https://security-recipes.ai/recipes/general/owasp-top-10-2025-remediate/","path":"/recipes/general/owasp-top-10-2025-remediate/","source_file":"recipes/general/owasp-top-10-2025-remediate.md","recipe_id":"","recipe_kind":"","category":{"slug":"general","label":"General"},"agent":"general","severity":"unspecified","maturity":"development","ecosystem":"","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"","framework_version":"","jurisdiction":"","industry":[],"cve_archetypes":[],"cve_workflow_role":"","tags":["owasp","top-10","remediate","pr","fix"],"facets":["remediation","audit","compliance"],"quality":{"score":100,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context","multi-facet"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"Stephen M Abbott","team":"Security","model":"Opus 4.7","ai_assisted":false,"generated_by":"","date":"2026-04-22","zero_day":false,"last_updated":"2026-04-22","summary":"Turn one current OWASP Top 10:2025 web application finding into a bounded, tested, reviewer-ready remediation pull request or an explicit triage note.\n","content_text":"A tool-agnostic remediation prompt that takes a single finding from an OWASP Web Application Top 10:2025 audit — or any equivalent source — and turns it into a reviewer-ready pull request. Rechecked August 23, 2026: OWASP still identifies 2025 as the current web-application Top 10 edition. Retired 2026 audit and remediate slugs on this site stay noindex redirects to these 2025 recipes. Includes category-specific \"how to fix this well\" guidance so the agent doesn't apply a naive patch that looks right and isn't. Works with the hunt side at OWASP Top 10:2025 — audit, but does not require it — any clear finding (SAST result, pen-test note, internal review comment) is a valid input. What this prompt does 1. Reproduces the finding — confirms the weakness exists on the specified file and lines. 2. Plans a fix using the category-appropriate pattern. 3. Applies the fix on a new branch with small, reviewable commits. 4. Adds tests that would have caught the original weakness. 5. Opens a PR with blast-radius notes, before/after snippets, and a link back to the finding. If the fix is out of scope for a safe agent change — needs a data migration, API contract change, or cross-repo coordination — the agent writes a triage note and stops. When to use it You have a specific finding with a file + category + fix direction. The fix is a code change in the repo the agent has access to. A human will review the PR before merge. Don't use it for: Runtime-only fixes (WAF rules, IAM policies in a separate repo). Findings that require behavioural changes in a downstream consumer. Anything labelled \"critical, exploit in the wild\" — go straight to your incident playbook. Inputs Infer what you can from the session; prompt only when ambiguous. Finding — category (e.g., A01 — Broken Access Control), file path, line range, and a short description. If the user only pasted a finding title and a file, that is enough; do not refuse. Recommended fix — optional. If present, treat it as a starting point, not a mandate. Repo — the working directory the agent is running in. Test runner — infer from the repo (pytest, go test, npm test, etc.). If there is no test setup, note it and proceed with manual verification only. The prompt ~~~markdown You are remediating a single OWASP Top 10:2025 finding in this repository. Open one reviewer-ready PR or write a triage note. Do not auto-merge. Step 0 — Reproduce and confirm 1. Read the file and surrounding context. 2. Confirm the weakness is present as described. If it is not reproducible (e.g., the code has been refactored), write a one-paragraph note and stop — do not invent a different finding to remediate. 3. Identify the minimum scope required to fix it. If the scope expands beyond ~200 lines or multiple unrelated files, stop and triage. Step 1 — Apply the category-appropriate pattern Do not default to \"add a check and ship it.\" Use the pattern that fits the category. A01 Broken Access Control — Add authorization at the controller/handler layer, not the view layer. Prefer centralized middleware / policy objects over ad-hoc if checks scattered across routes. Verify the check runs on every code path, including error and retry paths. A02 Security Misconfiguration — Turn the defaults right. Tighten CORS to explicit origins, disable debug in production paths, add the standard security headers (CSP, HSTS, X-Content-Type-Options, Referrer-Policy). If the config is environment-specific, fix the default and override only where needed. A03 Software Supply Chain Failures — Pin third-party CI actions by SHA, require signatures on release artifacts, use lockfiles with digest verification where the ecosystem supports it, and remove abandoned or unmaintained dependencies. For vulnerable packages, bump to the lowest non-vulnerable version that keeps the repo's major / minor contract. A04 Cryptographic Failures — Replace weak primitives with the library's current recommended default. Never roll your own. For password hashing, use argon2id or bcrypt with current cost parameters. For data-at-rest, prefer envelope encryption with a KMS-managed key. Remove the old cipher path — do not leave a fallback. A05 Injection — Parameterize. For SQL, use prepared statements or the ORM's parameter binding. For shell, prefer execFile/subprocess.run(args=[...]) with an explicit allowlist over string concatenation. For templates, escape at render time, not at input time. For LLM prompt injection, treat model output as untrusted and keep untrusted text out of system prompts and tool-call arguments. A06 Insecure Design — If the fix is design-level (missing rate limit, enumeration oracle), add the minimum control: server-side rate limit keyed on account + IP, uniform response for valid and invalid enumerable inputs, etc. Flag the larger design gap in the PR body. A07 Authentication Failures — Add the missing control (MFA requirement on sensitive op, account lockout on repeated failures, secure session cookie flags). Invalidate existing sessions if the old behaviour made them trust-on-first-use. A08 Software or Data Integrity Failures — Replace pickle/unsafe-eval/Marshal on untrusted input with a safe serialization format. Verify integrity for trusted data artifacts before use, and reject unsigned or unexpected data feeds. A09 Security Logging and Alerting Failures — Add structured audit events for sensitive operations (auth, authz, privilege escalation, data export). Scrub PII and secrets from the log pipeline — not from the log statement. A10 Mishandling of Exceptional Conditions — Make error paths fail closed. Ensure exception handling does not skip authz, validation, audit logging, transaction rollback, or cleanup. Replace broad catch-and-continue blocks with typed handling and safe defaults. If a newer official OWASP web-application Top 10 exists, apply the nearest fitting pattern above and note the version/date in the PR description. Step 2 — Tests that would have caught this Add at least one test that fails against the old code and passes against the new code. If the project has no test setup, add a minimal one; do not skip the test step silently. Step 3 — Commit and open the PR Branch: remediate/owasp-<category>-<short-slug>. Small commits that tell a story: reproduction test, fix, any supporting refactor, docstring/config updates. PR title: [Security][<category>] <short description>. PR body must include: OWASP category and link to the source finding. Summary of the weakness and the exploitation path. What was changed, per file. Blast radius — who and what this PR affects. A \"how to verify\" section with the commands a reviewer should run locally. Out-of-scope items discovered along the way, as checklist items for follow-up. Do not merge. Label as security-review (or the repo's equivalent). Stop conditions Stop and write a triage note at TRIAGE.md (and ping the PR reviewer channel) instead of forcing a PR if: The fix requires a data migration. The fix changes an externally-observable API contract. The finding turns out to be a false positive (explain briefly why). Tests fail and you cannot fix them without touching unrelated code. The fix requires credentials or infra you do not have. Scope Do not touch files outside the direct fix and its tests. Do not rewrite unrelated code \"while you're in there.\" Do not update dependencies other than the one the finding targets (if any). Do not modify CI pipelines, release automation, or secrets. ~~~ Output contract Either a PR (happy path) with the structure above, or a TRIAGE.md note (stop condition) with a short justification and a recommendation for the human next step. No auto-merge. Ever. Guardrails Single-finding scope. One finding → one PR. If the agent notices adjacent issues, it lists them in the PR body's follow-up checklist — it does not quietly fix them. Tests-before-ship. A PR without a new or updated test is an automatic block. If no test framework exists, the PR adds one minimally. Sensitive-data handling. The agent must never include secrets, keys, or PII in the PR description, commits, or test fixtures. Use obvious dummies. Reversibility. Every change should be reversible via a single revert. No data migrations bundled in. Related OWASP Top 10:2025 — audit — the hunt side OWASP Top 10:2025 official project Fundamentals — vocabulary used in the PR body Agentic Security Remediation — how a security team runs prompts like this in production","agent_handoff":{"mcp_lookup_keys":["owasp-top-10-2025-remediate","/recipes/general/owasp-top-10-2025-remediate/","recipes/general/owasp-top-10-2025-remediate.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["remediation","audit","compliance"],"source_text_field":"content_text","portable_download":"security-recipe-owasp-top-10-2025-remediate.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-owasp-top-10-2025-remediate.json"}},{"slug":"sast-finding-triage-and-fix","title":"SAST finding — triage and fix","link_title":"SAST finding triage and fix","url":"https://security-recipes.ai/recipes/general/sast-finding-triage-and-fix/","path":"/recipes/general/sast-finding-triage-and-fix/","source_file":"recipes/general/sast-finding-triage-and-fix.md","recipe_id":"","recipe_kind":"","category":{"slug":"general","label":"General"},"agent":"general","severity":"unspecified","maturity":"development","ecosystem":"","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"","framework_version":"","jurisdiction":"","industry":[],"cve_archetypes":["authentication_bypass","authorization_idor","command_code_injection","cross_site_scripting","information_disclosure","path_traversal_file_handling","privilege_escalation","race_lifetime","resource_exhaustion_dos","sql_query_injection","ssrf","unsafe_deserialization","use_after_free","xxe"],"cve_workflow_role":"remediate","tags":["sast","triage","false-positive","remediate","pr"],"facets":["remediation","audit","code-hygiene"],"quality":{"score":100,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context","multi-facet"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"Stephen M Abbott","team":"Security","model":"Opus 4.7","ai_assisted":false,"generated_by":"","date":"2026-04-25","zero_day":false,"last_updated":"2026-04-25","summary":"A tool-agnostic prompt that takes a single SAST finding and either opens a reviewer-ready PR (true positive, fixable), opens a suppression PR with justification and an expiry (confirmed false positive), or writes a triage note (uncertain …","content_text":"A tool-agnostic prompt that takes a single SAST finding and either opens a reviewer-ready PR (true positive, fixable), opens a suppression PR with justification and an expiry (confirmed false positive), or writes a triage note (uncertain or out-of-scope). Designed to slot into the SAST Finding Remediation workflow, where the SAST scanner is the source of truth and the agent is bounded to a named catalogue of fix shapes. The model: \"Opus 4.7\" frontmatter field is recipe metadata, not a prompt pin. Rechecked August 23, 2026: leftover CVE dumps stay development / noindex. Do not import leftover dump version text or a guessed next tag as the SAST fix. The scanner rule, source, and sink remain the finding identity. What this prompt does 1. Reads the finding — rule ID, file, line range, data flow. 2. Reproduces the data flow locally — confirms the source, the sink, and the path between them on the current code. 3. Classifies the finding as true positive / false positive / uncertain. Defaults to true-positive under doubt. 4. For true positives, picks a fix shape from the workflow's pre-approved catalogue and applies it. Adds a test that fails on the old code and passes on the new code. Re-runs the scanner and confirms the finding is gone. 5. For false positives, opens a suppression PR with an inline comment explaining the data flow that makes the finding benign and an explicit expiry date (default 6 months). 6. For everything else, writes a triage note and stops. When to use it A SAST scanner has produced a structured finding (Semgrep, CodeQL, SonarQube, Snyk Code, etc.) with a stable rule ID. The repo has a passing CI pipeline and a test target. The finding's data flow is local — confined to one function or one module. Don't use it for: Findings where the data flow crosses a module boundary. Findings whose fix would require an API contract change, a schema migration, or new infrastructure. Vendored or generated code. Findings labelled \"exploit available, in the wild\" — those go through your incident playbook, not this prompt. Inputs Infer from session where possible. Finding — rule ID, file path, line range, data-flow description. Catalogue path — the path in this repo (or a sibling) where the workflow's fix-shape catalogue lives. The agent reads it but does not edit it. Test runner — inferred from repo (pytest, npm test, go test, etc.). The prompt ~~~markdown You are triaging and (when appropriate) fixing a single SAST finding in this repository. Your output is exactly one of: A pull request with a fix and a regression test. A pull request that adds a scoped suppression with a written justification and an expiry date. A triage note (TRIAGE.md) explaining why neither option is safe and what a human should do next. Do not auto-merge. Do not bundle multiple findings. Step 0 — Read the finding and the catalogue 1. Read the rule ID, the affected file, the line range, and the data flow the scanner emitted. 2. Read the fix-shape catalogue at the path the operator provided. The catalogue maps rule IDs (or rule families) to named fix shapes, each with an edit pattern and a test template. The catalogue is the policy. If no shape matches, treat the finding as out-of-scope. Step 1 — Reproduce the data flow 1. Open the file and trace the data flow described by the scanner against the current code. 2. If the code has been refactored such that the flow no longer exists, classify as a stale finding and stop with a triage note (do not invent a new finding to fix). 3. Confirm the source, the sink, and any sanitizers / validators in the path. Note any confidence-reducing facts. Step 2 — Classify Pick exactly one: True positive. The data flow is real, the sanitization is insufficient or absent, and a fix shape from the catalogue matches. Continue to Step 3a. True positive, no shape. The flow is real but the catalogue has no shape for it. Stop and write a triage note. False positive. A sanitizer / validator / type constraint on the path makes the flow safe in practice. Continue to Step 3b. Default to true-positive under any doubt. Cross-module flow. The flow leaves this function/module. Stop and triage. Uncertain. Stop and triage. Step 3a — Apply the fix shape 1. Apply the catalogue's edit pattern to the file. Stay within the function boundary unless the catalogue explicitly says otherwise. 2. Instantiate the catalogue's test template against this finding. The test must fail on the old code and pass on the new code. 3. Run the repo's test target. If anything unrelated breaks, revert and triage — do not fix unrelated breakage. 4. Re-run the SAST scanner against the sandbox. The original finding must be gone, and no new finding may have appeared in the same file. If a new finding appears, revert and triage. 5. Open a PR (do not merge): Branch: remediate/sast-<rule-id-slug>-<short-slug>. Title: [Security][SAST][<rule-id>] <short description>. Body: rule ID, fix shape applied, before/after snippet, blast radius, \"how to verify locally,\" follow-up checklist for adjacent issues you noticed but did not fix. Label: sec-auto-remediation (or your repo's equivalent). Step 3b — Suppress with justification (false positive) 1. Add an inline suppression comment in the syntax the scanner expects (e.g., # nosem: <rule-id>, // codeql[js/sql-injection]: ignore, // NOSONAR). 2. The comment must include: The rule ID. A one-paragraph explanation of the data flow that makes the finding benign. The link to the data-flow trace you walked in Step 1. An explicit expiry date 6 months from today, written as expires: YYYY-MM-DD. 3. Open a PR (do not merge): Branch: remediate/sast-suppress-<rule-id-slug>. Title: [Security][SAST][suppress][<rule-id>] <short description>. Body: rule ID, why this is a false positive, the expiry date, and a link to the workflow page. 4. Tag with the auto-remediation label. Stop conditions (write a TRIAGE.md and exit) The data flow crosses a module boundary. No catalogue fix shape matches the rule ID. The fix would require an API change, a schema migration, or a credential / infra change. The scanner re-run after your fix shows new findings in the same file. You cannot make tests pass without editing unrelated code. The finding looks like a logic bug rather than the syntactic pattern the rule fires on. Scope Do not touch files outside the affected function and its test. Do not bundle multiple findings. Do not invent new fix shapes — only use the catalogue. Do not silently broaden the suppression scope (e.g., file-level when the finding is line-level). Do not modify CI, secrets, or release pipelines. ~~~ Output contract Either a PR (fix or suppression) with the structure above, or a TRIAGE.md note. Never an auto-merge. Suppression PRs always include an explicit expiry; the workflow's expiry-sweep job re-fires findings whose suppressions have aged out. Verification The finding's rule ID, file, and line range match the current sandbox, not a stale report. True-positive PRs include a test that fails on the old code and a clean re-scan of the patched files. False-positive suppressions are line-scoped, justified from the data flow, and carry an expiry date. Uncertain or out-of-scope cases stop at TRIAGE.md instead of inventing a new fix shape. Guardrails Catalogue-only fixes. The agent will never apply an edit pattern that isn't in the catalogue, even when it knows one that \"would work.\" Default to true-positive. False-negative cost (real bug marked benign) is much higher than false-positive cost (a human looks at a real false positive). The prompt is biased accordingly. Re-scan required. No PR opens without a clean re-scan of the patched sandbox. One finding, one PR. Never bundle. Each PR is independently revertible. Suppression has a half-life. No forever suppressions. Every suppression is dated and re-fires. Related SAST Finding Remediation — the workflow this prompt slots into. Reviewer Playbook — what the reviewer reads before approving. Emerging Patterns → AI-assisted SAST triage — the pattern this prompt implements.","agent_handoff":{"mcp_lookup_keys":["sast-finding-triage-and-fix","/recipes/general/sast-finding-triage-and-fix/","recipes/general/sast-finding-triage-and-fix.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["remediation","audit","code-hygiene"],"source_text_field":"content_text","portable_download":"security-recipe-sast-finding-triage-and-fix.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-sast-finding-triage-and-fix.json"}},{"slug":"source-code-attack-surface-map","title":"Source code audit - attack surface map","link_title":"Source code attack surface map","url":"https://security-recipes.ai/recipes/general/source-code-attack-surface-map/","path":"/recipes/general/source-code-attack-surface-map/","source_file":"recipes/general/source-code-attack-surface-map.md","recipe_id":"","recipe_kind":"","category":{"slug":"general","label":"General"},"agent":"general","severity":"unspecified","maturity":"development","ecosystem":"","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"","framework_version":"","jurisdiction":"","industry":[],"cve_archetypes":[],"cve_workflow_role":"","tags":["source-code","audit","attack-surface","threat-model","read-only"],"facets":["remediation","audit","risk","code-hygiene"],"quality":{"score":100,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context","multi-facet"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"Stephen M Abbott","team":"Security","model":"gpt-5-codex","ai_assisted":false,"generated_by":"","date":"2026-06-06","zero_day":false,"last_updated":"2026-06-06","summary":"A tool-agnostic source-code audit recipe that asks an agent to map where untrusted input enters a repository, where privileged actions happen, and which trust boundaries deserve deeper review.","content_text":"A tool-agnostic source-code audit recipe that asks an agent to map where untrusted input enters a repository, where privileged actions happen, and which trust boundaries deserve deeper review. Use this before focused audits like authz, injection, secrets, or supply-chain review. The output is an inventory and prioritised audit plan, not a vulnerability report and not a code change. The model: \"gpt-5-codex\" frontmatter field is recipe metadata, not a prompt pin. Rechecked August 23, 2026: leftover CVE dumps stay development / noindex. Do not invent a floor from a leftover dump, a guessed next tag, or an empty GHAD advisory. Mark unknown versions unknown. What this prompt does 1. Enumerates entry points, identities, storage systems, external integrations, and privileged operations. 2. Draws trust boundaries from code evidence instead of architecture guesses. 3. Flags high-value paths that should receive deeper audit attention. 4. Produces a compact SECURITYATTACKSURFACE.md report that can be handed to another agent or a reviewer. When to use it Before the first security pass on a new service. Before deciding which security audit prompt should run next. After a large refactor, framework migration, or new integration. During diligence when you need code-backed orientation fast. Do not use it as a substitute for SAST, dependency scanning, runtime testing, or a full threat model. It is the map, not the expedition. Inputs Infer from the session where possible: Repo root and scope. If no scope is given, inspect the whole repo. Primary deployment target, inferred from Docker, Kubernetes, CI, or infrastructure files. Any product-critical flows named by the operator. Any files or directories that are out of scope. The prompt ~~~markdown You are performing a read-only source-code attack-surface mapping pass for this repository. Do not edit files. Do not open a pull request. Your job is to map the system well enough that a security reviewer can choose the next focused audit. Prefer code evidence over guesses. Step 0 - Repository orientation Identify and record: Primary languages and frameworks. Main entry points: HTTP routes, controllers, middleware, and API handlers. GraphQL, gRPC, WebSocket, webhook, queue, cron, CLI, or background job entry points. Browser/client entry points when they call privileged APIs. Authn and authz modules. Datastores and persistence layers. External network calls and third-party SDKs. Secret, credential, key, and token handling paths. Build, CI, release, and deployment entry points. Use file paths and short notes. If something is unknown after a reasonable look, mark it unknown instead of guessing. Step 1 - Identify trust boundaries For each boundary, write: Boundary name. Incoming trust level. Outgoing trust level. Code locations that cross the boundary. Why the boundary matters. Cover at minimum: Internet or user-controlled input entering server code. Authenticated user input crossing into tenant-owned resources. Internal service calls crossing service or account boundaries. Model, agent, or tool input crossing into code execution, filesystem, network, ticketing, or cloud APIs. Build-time inputs crossing into release artifacts. Secrets crossing into logs, telemetry, model prompts, or browser state. Step 2 - Find privileged operations List code paths that can: Read, write, delete, export, or share user/customer data. Change roles, permissions, billing state, ownership, or tenant membership. Execute commands, evaluate code, render templates, deserialize data, or load plugins. Make outbound network requests from user-provided values. Create, rotate, display, persist, or transmit secrets. Publish artifacts, deploy code, or mutate CI/CD state. For each operation, include: File path and function/class/route name. Required identity or permission if the code makes it clear. Missing context if the permission model is unclear. Step 3 - Prioritise deeper audit paths Pick the top 10 paths for focused security review. Prioritise by: Untrusted input reaches privileged operation. Tenant or role boundary is involved. Secrets or regulated data are involved. Runtime side effects are hard to reverse. Code path is internet-facing, webhook-facing, or reachable by an integration token. Existing tests do not cover the boundary. For each path, recommend the next audit recipe: Auth and tenant-boundary audit. Injection and unsafe-sink audit. Secrets and sensitive-data exposure audit. Dependency and build-integrity audit. Manual design review. Step 4 - Write the report Write SECURITYATTACKSURFACE.md at the repository root. If the session is read-only, print the same content to stdout. Use this structure: Source code attack-surface map - <repo name> Generated on <date>. Scope: <scope>. Context Languages/frameworks: Entry points: Auth model: Datastores: External integrations: Build/deploy surface: Unknowns: Trust Boundaries <Boundary name> Code: path/to/file.ext:line Incoming trust: ... Outgoing trust: ... Why it matters: ... Notes: ... Privileged Operations <Operation name> Code: path/to/file.ext:line Capability: ... Required identity/permission: ... Missing context: ... Recommended Follow-Up Audits P1 - <path name> Why this first: ... Recipe: ... Files to inspect: ... Question to answer: ... Gaps ... Stop conditions Stop and report the reason if: The repository is too large for one pass. Split by service or top-level module and recommend the split. Secrets, private keys, or live credentials are discovered. Do not print values. Put the file path and redacted line reference at the top of the report. The requested scope would require reading private data, production logs, or customer content outside the source tree. ~~~ Output contract SECURITYATTACKSURFACE.md or equivalent stdout report. No source-code edits. File and function pointers for every material claim. A ranked list of follow-up audit paths. Verification Every material claim points to a file, function, or config path, or is labeled unknown. Trust boundaries come from code evidence, not an inferred architecture diagram. Follow-up audit paths are ranked and mapped to a focused sibling recipe. The report contains no secret values, live credentials, or production data. Guardrails Read-only. Do not run commands that mutate the repo, package cache, cloud state, CI state, or databases. Do not include secret values in the report. Treat generated, vendored, and minified code as out of scope unless the operator explicitly says otherwise. Prefer \"unknown\" over inferred certainty when auth, deployment, or data classification is not visible in the repo. Related Source code audit - auth and tenant boundaries Source code audit - injection and unsafe sinks Source code audit - secrets and data exposure Source code audit - dependency and build integrity","agent_handoff":{"mcp_lookup_keys":["source-code-attack-surface-map","/recipes/general/source-code-attack-surface-map/","recipes/general/source-code-attack-surface-map.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["remediation","audit","risk","code-hygiene"],"source_text_field":"content_text","portable_download":"security-recipe-source-code-attack-surface-map.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-source-code-attack-surface-map.json"}},{"slug":"source-code-authz-tenant-boundary-audit","title":"Source code audit - auth and tenant boundaries","link_title":"Source code auth boundary audit","url":"https://security-recipes.ai/recipes/general/source-code-authz-tenant-boundary-audit/","path":"/recipes/general/source-code-authz-tenant-boundary-audit/","source_file":"recipes/general/source-code-authz-tenant-boundary-audit.md","recipe_id":"","recipe_kind":"","category":{"slug":"general","label":"General"},"agent":"general","severity":"unspecified","maturity":"development","ecosystem":"","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"","framework_version":"","jurisdiction":"","industry":[],"cve_archetypes":["authentication_bypass","authorization_idor","privilege_escalation"],"cve_workflow_role":"audit","tags":["source-code","audit","authorization","tenant-boundary","idor"],"facets":["remediation","audit","code-hygiene"],"quality":{"score":100,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context","multi-facet"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"Stephen M Abbott","team":"Security","model":"gpt-5-codex","ai_assisted":false,"generated_by":"","date":"2026-06-06","zero_day":false,"last_updated":"2026-06-06","summary":"A focused source-code audit recipe for authorization, tenant isolation, object ownership, and privilege-boundary mistakes. It is designed for code review sessions where the question is not \"is there login?\" but \"can the wrong …","content_text":"A focused source-code audit recipe for authorization, tenant isolation, object ownership, and privilege-boundary mistakes. It is designed for code review sessions where the question is not \"is there login?\" but \"can the wrong authenticated principal reach the wrong object?\" The output is a finding report. The agent should not patch code during this run. The model: \"gpt-5-codex\" frontmatter field is recipe metadata, not a prompt pin. Rechecked August 23, 2026: leftover CVE dumps stay development / noindex. A leftover dump is not proof that a tenant or object-ownership boundary is safe or fixed. What this prompt does 1. Builds a map of identities, roles, permissions, tenants, and owned resources from the code. 2. Reviews routes and service methods that read or mutate protected objects. 3. Looks for IDOR, confused-deputy, role escalation, missing policy checks, and client-trusted tenant IDs. 4. Emits file-level findings with reproduction ideas and recommended fixes. When to use it Reviewing an app with multi-tenant accounts or customer-owned data. Auditing admin routes, support tooling, billing flows, user invites, API keys, or organization membership. After adding a new authorization framework or policy layer. After an incident or bug report involving object access. Do not use it for authentication protocol review alone. Session cookies, OAuth, SSO, MFA, and password flows can be noted here, but the core job is authorization and isolation after identity is established. Inputs Infer where possible: Repo scope. Identity providers and auth middleware. Tenant or organization concept names. Admin, support, service-account, or integration-token roles. High-value resource types if the operator names any. The prompt ~~~markdown You are performing a read-only authorization and tenant-boundary source audit. Do not edit files. Do not open a pull request. Focus on whether authenticated principals can access only the resources and actions they are allowed to access. Step 0 - Build the auth map Find and record: Authentication middleware and session/token parsing. Authorization middleware, policy objects, permission checks, guards, or decorators. Role names, permission names, tenant/org/account identifiers, and resource ownership fields. Admin/support/service-account bypasses. Places where the current user, tenant, org, account, or workspace is read from request parameters, headers, cookies, JWT claims, body fields, path params, or database state. Create a short glossary: Principal types. Resource types. Privileged operations. Trustworthy sources of tenant/resource ownership. Untrustworthy sources that must be validated. Step 1 - Enumerate protected routes and methods Review every route, resolver, controller action, command, queue handler, or service method that: Reads a resource by ID. Lists resources. Creates, updates, deletes, exports, shares, transfers, or imports data. Changes role, ownership, membership, billing, plan, API key, webhook, integration, or admin state. Acts on behalf of another user, tenant, or organization. For each, answer: Is authentication required? Where does authorization happen? Is object ownership or tenant membership checked server-side? Is the tenant/resource ID trusted from the client? Is the policy enforced before side effects happen? Do all branches, retries, fallbacks, and error paths pass through the same check? Step 2 - Look for failure patterns Search for these concrete patterns: Object lookup by user-controlled ID without joining through tenant, owner, or policy scope. Tenant ID, org ID, workspace ID, role, or account ID accepted from the client and used directly in a query or command. Admin/support bypasses without explicit role checks and audit logging. List endpoints filtered by request parameters instead of policy-scoped query builders. Bulk operations that check the parent object but not every child object. Export, share, invite, webhook, and API-key endpoints with weaker checks than normal CRUD. Authorization checks after mutation. Cached permission decisions that do not include tenant, role, resource, or token version in the cache key. Background jobs that trust the enqueuer instead of re-checking authority when the job runs. Service-account or integration-token flows that can act outside their intended tenant. Test fixtures that use only admin users and therefore miss normal-user denial cases. Step 3 - Validate likely findings For every candidate issue: 1. Trace the route from entry point to data access or side effect. 2. Identify the source of the principal and the source of the resource identifier. 3. Identify the exact policy check or confirm it is missing. 4. Check whether an upstream middleware guarantees the missing property. 5. Look for tests that prove denial for another tenant, lower role, or unrelated owner. Only report a finding when you can point to a concrete path. If evidence is incomplete, put it in \"Needs human confirmation\" instead of inflating severity. Step 4 - Score findings Assign: Severity: critical, high, medium, low. Boundary: tenant, role, object ownership, admin/support, service account, or background job. Blast radius: one object, one tenant, cross-tenant, admin, platform. Confidence: high, medium, low. Use higher severity when exploitation crosses tenants, changes privileges, exports sensitive data, or affects admin/support tools. Step 5 - Write the report Write SECURITYAUTHZAUDIT.md at the repo root. If the session is read-only, print the same content to stdout. Use this structure: Authorization and tenant-boundary audit - <repo name> Generated on <date>. Scope: <scope>. Auth Map Principals: Roles/permissions: Tenant/resource model: Trusted identity sources: Unknowns: Findings <Severity> - <Boundary> - <short title> File: path/to/file.ext:line Entry point: ... Path: ... Why it is flagged: ... Exploit sketch: ... Blast radius: ... Confidence: ... Recommended fix: ... Tests to add: ... Needs Human Confirmation ... Routes Reviewed With No Finding path - authorization evidence found. Gaps ... Stop conditions Stop and report rather than guessing if: The auth or policy layer lives in another repo you cannot inspect. The repository lacks enough routing context to connect entry points to data access. You find live credentials or private keys while auditing. A suspected issue depends entirely on production IAM, feature flags, or runtime config not present in the repo. ~~~ Output contract SECURITYAUTHZAUDIT.md or equivalent stdout report. Findings include file paths, boundary type, blast radius, confidence, and test ideas. No code edits. Verification Each finding names the entry point, the object or tenant identifier, and the missing or bypassed check. Middleware, framework guards, and policy wrappers were inspected before treating a missing inline check as a bug. Uncertain issues are labeled Needs Human Confirmation instead of proven vulnerabilities. The report stays read-only and does not call production APIs or use customer data. Guardrails Do not exploit live systems or call production APIs. Do not use customer data to validate access control. Do not assume a missing inline check is a bug until middleware, framework guards, and policy wrappers have been checked. Default uncertain issues to \"Needs Human Confirmation\" instead of dressing them up as proven vulnerabilities. Related Source code audit - attack surface map OWASP Top 10:2025 repository audit Reviewer Playbook","agent_handoff":{"mcp_lookup_keys":["source-code-authz-tenant-boundary-audit","/recipes/general/source-code-authz-tenant-boundary-audit/","recipes/general/source-code-authz-tenant-boundary-audit.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["remediation","audit","code-hygiene"],"source_text_field":"content_text","portable_download":"security-recipe-source-code-authz-tenant-boundary-audit.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-source-code-authz-tenant-boundary-audit.json"}},{"slug":"source-code-injection-sink-audit","title":"Source code audit - injection and unsafe sinks","link_title":"Source code injection sink audit","url":"https://security-recipes.ai/recipes/general/source-code-injection-sink-audit/","path":"/recipes/general/source-code-injection-sink-audit/","source_file":"recipes/general/source-code-injection-sink-audit.md","recipe_id":"","recipe_kind":"","category":{"slug":"general","label":"General"},"agent":"general","severity":"unspecified","maturity":"development","ecosystem":"","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"","framework_version":"","jurisdiction":"","industry":[],"cve_archetypes":["command_code_injection","cross_site_scripting","path_traversal_file_handling","sql_query_injection","ssrf","unsafe_deserialization","xxe"],"cve_workflow_role":"audit","tags":["source-code","audit","injection","ssrf","unsafe-sinks","dataflow"],"facets":["remediation","audit","code-hygiene"],"quality":{"score":100,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context","multi-facet"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"Stephen M Abbott","team":"Security","model":"gpt-5-codex","ai_assisted":false,"generated_by":"","date":"2026-06-06","zero_day":false,"last_updated":"2026-06-06","summary":"Audit source-to-sink data flows for SQL injection, shell execution, SSRF, XSS, unsafe deserialization, path traversal, XXE, and LLM tool calls.","content_text":"A source-code audit recipe for tracing untrusted input into dangerous sinks: SQL, shell, template rendering, SSRF, deserialization, file paths, regular expressions, dynamic evaluation, and LLM/tool-call boundaries. This is a read-only hunt prompt. It produces evidence-backed findings and safe remediation recommendations, but it does not patch code. The model: \"gpt-5-codex\" frontmatter field is recipe metadata, not a prompt pin. Rechecked August 23, 2026: leftover CVE dumps stay development / noindex. Do not invent exploits or a named floor from leftover dump version text. Mark unknown sinks unknown. What this prompt does 1. Identifies untrusted input sources in the scoped code. 2. Builds a sink catalogue for the language and framework in use. 3. Traces source-to-sink data flow with sanitizer and validator checks. 4. Reports exploitable or suspicious flows with confidence and test ideas. When to use it After the attack-surface map identifies user input reaching privileged operations. Before or after SAST results for injection-heavy code. When reviewing importers, webhook processors, URL fetchers, search endpoints, report builders, template systems, plugin systems, or agent tool adapters. Do not use it for dependency CVEs unless the vulnerable dependency creates one of these source-to-sink paths in your code. Inputs Infer where possible: Repo or directory scope. Framework and routing layer. User-controlled input sources if the operator has a specific flow in mind. Any SAST rule IDs or findings that should be checked first. The prompt ~~~markdown You are performing a read-only source-code audit for injection and unsafe sink paths. Do not edit files. Do not open a pull request. Your output should distinguish proven findings from suspicious flows that need human confirmation. Step 0 - Identify untrusted input sources Map inputs from: HTTP path, query, body, headers, cookies, file uploads, and multipart fields. GraphQL variables and resolver args. WebSocket messages. Webhook payloads. Queue messages and scheduled-job payloads. CLI args and environment variables. Database fields previously written by users. Object storage files, archives, uploaded documents, and generated artifacts. Third-party API responses. Model output, agent memory, retrieved context, and tool-call arguments. Record file paths and handler/function names. Step 1 - Build the sink catalogue Search for dangerous or policy-sensitive sinks in the scoped code: SQL/NoSQL query construction. Shell command execution and process spawning. Template rendering and HTML/JS/CSS interpolation. Filesystem path construction, archive extraction, symlink handling, and file writes. Outbound HTTP requests, webhook fetchers, URL previews, proxying, and cloud metadata access. XML parsing, YAML loading, pickle/marshal/deserialization, dynamic module loading, plugin loading, and reflection. eval, function constructors, dynamic import, expression languages, sandbox escapes, and generated code execution. Regular expressions built from input or run against unbounded input. LLM prompts, system/developer instructions, tool arguments, browser automation commands, and MCP tool calls that include untrusted content. For each sink, record: File path and function/class. Sink type. Inputs reaching the sink. Existing sanitizers, validators, parameter binding, escaping, allowlists, or policy checks. Step 2 - Trace source-to-sink flows For each promising flow: 1. Start at the source and follow variable transformations to the sink. 2. Note validators, normalizers, encoders, escaping, type checks, length limits, allowlists, and permission checks. 3. Decide whether the control is sufficient for the sink: SQL: parameter binding or ORM-safe query APIs. Shell: argument array plus command and argument allowlists; no shell. Template: contextual escaping at render time. SSRF: scheme/host allowlist, DNS/IP checks, link-local and metadata blocking, redirect handling. File path: canonicalization, base-directory containment, symlink policy, extension/type checks. Deserialization: safe format or trusted signed payload only. Regex: length caps, anchored intent, no user-controlled catastrophic patterns. LLM/tool calls: untrusted text kept out of system instructions and privileged arguments; tool output treated as untrusted. 4. If the path crosses modules and cannot be fully traced, mark it \"partial flow\" and explain what is missing. Step 3 - Check tests and exploitability For each candidate finding: Look for tests that would catch the payload class. Sketch a safe local reproduction payload without hitting production systems or destructive operations. Identify the minimum assertion a regression test should make. Identify whether exploitation requires authentication, a special role, internal network access, or prior data seeding. Do not execute exploit payloads against live services. Keep any payloads local, harmless, and illustrative. Step 4 - Score findings Assign: Severity: critical, high, medium, low. Sink class. Exploit preconditions. Blast radius. Confidence: high, medium, low. Raise severity for unauthenticated reachability, remote code execution, credential exposure, cross-tenant impact, metadata-service access, and server-side write primitives. Step 5 - Write the report Write SECURITYINJECTIONSINKAUDIT.md at the repo root. If the session is read-only, print the same content to stdout. Use this structure: Injection and unsafe-sink audit - <repo name> Generated on <date>. Scope: <scope>. Source Map ... Sink Catalogue ... Findings <Severity> - <Sink class> - <short title> File: path/to/file.ext:line Source: ... Sink: ... Data flow: ... Existing controls: ... Why controls are insufficient: ... Exploit sketch: ... Blast radius: ... Confidence: ... Recommended fix: ... Tests to add: ... Partial Flows / Needs Human Confirmation ... Sinks Reviewed With No Finding ... Gaps ... Stop conditions Stop and report rather than pushing through if: A candidate issue would require running a destructive payload to validate. A key flow depends on production-only routing, secrets, network topology, or policy code outside the repo. Live credentials, private keys, or unmistakable exploit artifacts are discovered. ~~~ Output contract SECURITYINJECTIONSINKAUDIT.md or equivalent stdout report. Findings must include source, sink, data flow, existing controls, and why the controls fail. No code edits. Verification Each finding names the source, sink, and the data-flow path between them. Existing sanitization, parameterization, or allowlists are recorded before calling them insufficient. No finding is labeled exploitable without a source-to-sink explanation. The report stays read-only and contains no payloads, credentials, or live-system tests. Guardrails Read-only and local-only validation. Do not include credential values, tokens, or private keys. Do not label a flow exploitable solely because a dangerous function is present; prove or explain the source-to-sink path. Treat model output, retrieved context, and tool output as untrusted data when auditing AI-assisted code paths. Related Source code audit - attack surface map SAST finding - triage and fix Classic Vulnerable Defaults","agent_handoff":{"mcp_lookup_keys":["source-code-injection-sink-audit","/recipes/general/source-code-injection-sink-audit/","recipes/general/source-code-injection-sink-audit.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["remediation","audit","code-hygiene"],"source_text_field":"content_text","portable_download":"security-recipe-source-code-injection-sink-audit.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-source-code-injection-sink-audit.json"}},{"slug":"source-code-secrets-data-exposure-audit","title":"Source code audit - secrets and data exposure","link_title":"Source code secrets audit","url":"https://security-recipes.ai/recipes/general/source-code-secrets-data-exposure-audit/","path":"/recipes/general/source-code-secrets-data-exposure-audit/","source_file":"recipes/general/source-code-secrets-data-exposure-audit.md","recipe_id":"","recipe_kind":"","category":{"slug":"general","label":"General"},"agent":"general","severity":"unspecified","maturity":"development","ecosystem":"","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"","framework_version":"","jurisdiction":"","industry":[],"cve_archetypes":["crypto_certificate_validation","information_disclosure"],"cve_workflow_role":"audit","tags":["source-code","audit","secrets","sensitive-data","logging","privacy"],"facets":["remediation","audit","code-hygiene"],"quality":{"score":100,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context","multi-facet"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"Stephen M Abbott","team":"Security","model":"gpt-5-codex","ai_assisted":false,"generated_by":"","date":"2026-06-06","zero_day":false,"last_updated":"2026-06-06","summary":"A source-code audit recipe for finding places where secrets, tokens, credentials, regulated data, or customer content can leak through code, logs, telemetry, prompts, artifacts, exports, caches, or browser state.","content_text":"A source-code audit recipe for finding places where secrets, tokens, credentials, regulated data, or customer content can leak through code, logs, telemetry, prompts, artifacts, exports, caches, or browser state. This recipe is read-only. It reports exposure paths and containment recommendations; it does not rotate secrets or patch code during the audit pass. The model: \"gpt-5-codex\" frontmatter field is recipe metadata, not a prompt pin. Rechecked August 23, 2026: leftover CVE dumps stay development / noindex. Do not treat leftover dump version text as a rotation or containment floor. What this prompt does 1. Maps secret and sensitive-data sources. 2. Reviews storage, logging, telemetry, export, prompt, cache, and artifact paths. 3. Flags hard-coded secrets, unsafe redaction, over-broad data release, and missing classification boundaries. 4. Produces a report that separates incident candidates from normal engineering findings. When to use it Before launching an AI assistant, export feature, audit-log pipeline, or customer evidence portal. After adding observability, analytics, tracing, support tooling, or report generation. When reviewing code that handles API keys, OAuth tokens, session cookies, private keys, PII, PHI, payment data, customer source code, or internal prompts. After a secrets scanner finds a pattern and you need context. Do not use this prompt to print, copy, validate, or test live secrets. Inputs Infer where possible: Repo scope. Data classes the application handles. Secret managers, environment variable names, config paths, and logging systems. Known scanner findings, if any. The prompt ~~~markdown You are performing a read-only source-code audit for secrets and sensitive-data exposure. Do not edit files. Do not rotate credentials. Do not call external services to validate secrets. If you find a live-looking secret, redact it immediately in your notes and treat it as a potential incident. Step 0 - Define sensitive classes From code evidence, identify sensitive classes such as: API keys, OAuth tokens, refresh tokens, session cookies, JWT signing keys, webhook secrets, SSH keys, private keys, database passwords, cloud credentials, package tokens, and model-provider keys. User PII, employee data, customer content, customer source code, regulated data, payment data, health data, secrets embedded in tickets, and security findings. Internal prompts, system instructions, agent transcripts, retrieved context, tool output, and model-generated evidence packs. Create a table of classes and likely code locations. Step 1 - Map ingress and storage Find where sensitive data enters: Environment variables and config files. Secret managers and cloud SDKs. HTTP requests, uploads, webhooks, and forms. OAuth, SSO, API-key, and session flows. Database reads and writes. Object storage, queues, caches, and local temp files. CI variables and deployment manifests. MCP tools, browser agents, model prompts, retrieval indexes, and memory. For each class, record: Where it enters. Where it is stored. Whether it is encrypted, hashed, tokenized, redacted, or classified. Retention and deletion logic if visible. Step 2 - Review exposure paths Inspect paths that can release data: Logs, traces, metrics, exceptions, debug output, screenshots, and crash dumps. Audit events and security telemetry. API responses, exports, reports, evidence packs, support bundles, and downloadable artifacts. Email, Slack, ticketing, webhook, or notification integrations. Browser local storage, session storage, cookies, query strings, and frontend error reporters. Prompt construction, retrieval augmentation, model-provider requests, model outputs, agent memory, tool calls, and MCP resources. Test fixtures, snapshots, golden files, generated docs, and sample payloads. Build artifacts, container layers, source maps, package tarballs, and CI logs. For each exposure path, check: Is the sensitive value included at all? Is redaction applied at the boundary or only downstream? Is redaction structured and type-aware, or string-based and brittle? Can an error path bypass redaction? Is access to the released artifact scoped to the right tenant/role? Is retention visible and bounded? Step 3 - Review hard-coded and committed secrets safely Search for likely secret material, but do not print values: Private key block headers. Token-like variable names with literal values. Cloud provider key patterns. .env, config, fixture, and test-data files. Build scripts and CI workflow files. Dockerfiles and container entrypoints. For each candidate: Redact the value in your notes. Record file path, line, secret type, and confidence. Decide whether it looks live, test-only, dummy, or unknown. If live or unknown, elevate it to \"Potential incident\" and stop broad auditing until a human decides whether rotation is needed. Step 4 - Review controls Look for: Centralized redaction helpers. Data classification labels or schemas. Secret wrappers that prevent accidental stringification. Encryption-at-rest or envelope-encryption paths for stored sensitive data. Hashing for passwords or one-way tokens. Token expiration, revocation, rotation, and audit trails. Export review gates and tenant-bound release checks. Tests for redaction, export scoping, and prompt/tool data boundaries. Flag duplicated or ad-hoc redaction code when it creates likely bypasses. Step 5 - Write the report Write SECURITYSECRETSDATAAUDIT.md at the repo root. If the session is read-only, print the same content to stdout. Use this structure: Secrets and sensitive-data exposure audit - <repo name> Generated on <date>. Scope: <scope>. Sensitive Data Classes ... Potential Incidents <Secret/data class> - <short title> File: path/to/file.ext:line Value: redacted Why this may be live: ... Immediate action: ... Confidence: ... Findings <Severity> - <Exposure path> - <short title> File: path/to/file.ext:line Data class: ... Exposure path: ... Existing controls: ... Why controls are insufficient: ... Blast radius: ... Confidence: ... Recommended fix: ... Tests to add: ... Controls Reviewed ... Gaps ... Stop conditions Stop and escalate to the top of the report if: A live-looking credential, private key, or signing secret is present. The code appears to exfiltrate customer data, source code, prompts, or tokens to an unapproved external service. Validating the issue would require using a secret, calling production, or reading customer data. ~~~ Output contract SECURITYSECRETSDATAAUDIT.md or equivalent stdout report. Secret values are always redacted. Potential incidents are separated from ordinary findings. No code edits or credential validation. Verification Every secret or token reference is redacted; only file path and a redacted line pointer appear. Potential incidents are listed separately from ordinary logging or config findings. No external call was used to test whether a credential works. Source maps, CI logs, prompt transcripts, and support bundles are treated as leak surfaces, not ignored. Guardrails Never print raw secret values. Never call external services to test whether a token works. Do not paste customer data, source code, logs, or private prompts into external tools while auditing. Treat source maps, CI logs, prompt transcripts, evidence exports, and support bundles as release artifacts that can leak data. Related Source code audit - attack surface map Sensitive Data Exposure Remediation Context Egress Boundary","agent_handoff":{"mcp_lookup_keys":["source-code-secrets-data-exposure-audit","/recipes/general/source-code-secrets-data-exposure-audit/","recipes/general/source-code-secrets-data-exposure-audit.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["remediation","audit","code-hygiene"],"source_text_field":"content_text","portable_download":"security-recipe-source-code-secrets-data-exposure-audit.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-source-code-secrets-data-exposure-audit.json"}},{"slug":"source-code-supply-chain-build-integrity-audit","title":"Source code audit - dependency and build integrity","link_title":"Source code build integrity audit","url":"https://security-recipes.ai/recipes/general/source-code-supply-chain-build-integrity-audit/","path":"/recipes/general/source-code-supply-chain-build-integrity-audit/","source_file":"recipes/general/source-code-supply-chain-build-integrity-audit.md","recipe_id":"","recipe_kind":"","category":{"slug":"general","label":"General"},"agent":"general","severity":"unspecified","maturity":"development","ecosystem":"","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"","framework_version":"","jurisdiction":"","industry":[],"cve_archetypes":["supply_chain_update_integrity"],"cve_workflow_role":"audit","tags":["source-code","audit","supply-chain","dependencies","ci","build-integrity"],"facets":["remediation","audit","code-hygiene"],"quality":{"score":100,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context","multi-facet"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"Stephen M Abbott","team":"Security","model":"gpt-5-codex","ai_assisted":false,"generated_by":"","date":"2026-06-06","zero_day":false,"last_updated":"2026-06-06","summary":"A source-code audit recipe for dependency hygiene, lockfile integrity, build and CI trust boundaries, generated artifacts, package publishing, and release provenance.","content_text":"A source-code audit recipe for dependency hygiene, lockfile integrity, build and CI trust boundaries, generated artifacts, package publishing, and release provenance. This is not a dependency scanner. It complements SCA by reviewing the source-controlled build decisions that scanners often cannot reason about: unpinned actions, install scripts, custom package mirrors, build secrets, generated code, and release mutation paths. The model: \"gpt-5-codex\" frontmatter field is recipe metadata, not a prompt pin. Rechecked August 23, 2026: leftover CVE dumps stay development / noindex. Do not invent a named floor from leftover dump version text. This repository's workflows pin actions/checkout@v7; do not restore v5 as current. What this prompt does 1. Maps package manifests, lockfiles, build scripts, CI workflows, and release paths. 2. Reviews where third-party code or untrusted build input enters the system. 3. Flags source-controlled choices that weaken integrity or provenance. 4. Produces a report with scanner follow-ups and concrete hardening recommendations. When to use it Before granting CI jobs access to deployment, signing, or package publishing credentials. After adding a new package manager, build tool, code generator, or CI workflow. Before publishing an SDK, container image, action, plugin, model adapter, MCP server, or agent skill. After SCA finds repeated vulnerable transitive dependencies and you need to inspect build policy. Do not use it as a replacement for SCA, SBOM generation, or signature verification tools. Run those separately and attach their output when available. Inputs Infer where possible: Repo scope. Package managers and build systems. CI providers and release workflows. Artifact types: packages, containers, binaries, generated docs, models, plugins, agent skills, or MCP servers. Any SCA/SBOM/signing reports supplied by the operator. The prompt ~~~markdown You are performing a read-only source-code audit for dependency and build integrity. Do not edit files. Do not run package installs that execute scripts. Do not publish, deploy, sign, or upload artifacts. Your job is to identify integrity risks visible from source-controlled manifests, workflows, scripts, and release configuration. Step 0 - Inventory build surfaces Find and record: Package manifests and lockfiles. Build scripts, task runners, Makefiles, shell scripts, Dockerfiles, compose files, and language-specific build config. CI workflows and reusable workflow references. Code generation, schema generation, protobuf/OpenAPI generation, model download, plugin install, and asset pipeline steps. Container build contexts and base images. Release, signing, publishing, deployment, and provenance steps. Package mirrors, registries, artifact caches, and dependency proxies. For each surface, record file path and purpose. Step 1 - Review dependency trust Check for: Missing lockfiles where the ecosystem normally supports them. Lockfiles not committed or ignored by CI. Wildcard, floating, branch, tag, local path, or git dependencies where immutable versions are expected. Dependency confusion risk from private package names without scoped registry configuration. Custom registries, mirrors, or install URLs without TLS and provenance expectations. Postinstall/preinstall/build scripts that execute third-party code. Vendored code without origin, version, license, or update process. Transitive dependency overrides that pin vulnerable or abandoned code. Package-manager config that disables integrity checks or scripts unexpectedly. If SCA output is present, cross-check whether manifests and lockfiles match the scanned state. Step 2 - Review CI and workflow integrity Check CI workflows for: Third-party actions or reusable workflows pinned by mutable tag instead of commit SHA. Pull-request workflows that expose write tokens, secrets, deploy keys, cloud credentials, package tokens, or signing keys to untrusted code. pullrequesttarget or equivalent privileged triggers that check out attacker-controlled code. Build scripts that fetch and execute remote scripts. Cache restore keys that allow untrusted branches to poison trusted builds. Missing least-privilege permissions for repo tokens. Missing separation between test, build, sign, publish, and deploy jobs. Secrets printed in logs or passed through command-line args. Release jobs that can be triggered by unreviewed branches, tags, or user-controlled metadata. Record exact workflow file paths and job names. Step 3 - Review artifact and release provenance Check for: Unsigned packages, containers, binaries, or generated artifacts where signing is expected. Missing SBOM or provenance generation for release artifacts. Container base images not pinned by digest. Dockerfiles that copy broad build contexts, .git, secrets, or local config into images. Multi-stage builds that leak build secrets into final layers. Generated code committed without a reproducible generation command. Release notes, package metadata, or version files generated from untrusted input. Model, plugin, skill, extension, or MCP-server artifacts loaded from unverified sources. Step 4 - Review build-time secret handling Identify where CI/build code can access: Cloud credentials. Package publishing tokens. Signing keys. Deployment credentials. Source-control tokens. Model-provider keys. Scanner or security-tool tokens. For each, check whether access is limited to trusted jobs and whether the job can be influenced by untrusted code or metadata. Step 5 - Score findings Assign: Severity: critical, high, medium, low. Integrity boundary: dependency, CI, cache, artifact, release, signing, registry, generated code, or build secret. Exploit preconditions. Blast radius. Confidence. Raise severity for paths that let untrusted contributors affect signed, published, deployed, or production-trusted artifacts. Step 6 - Write the report Write SECURITYBUILDINTEGRITYAUDIT.md at the repo root. If the session is read-only, print the same content to stdout. Use this structure: Dependency and build-integrity audit - <repo name> Generated on <date>. Scope: <scope>. Build Surface Inventory ... Findings <Severity> - <Boundary> - <short title> File: path/to/file.ext:line Surface: ... Why it is flagged: ... Exploit sketch: ... Blast radius: ... Confidence: ... Recommended fix: ... Verification: ... Scanner Follow-Ups ... Surfaces Reviewed With No Finding ... Gaps ... Stop conditions Stop and report rather than continuing if: Validation would require running install scripts from untrusted dependencies. Validation would require publish, deploy, signing, or credential access. You discover live secrets in workflow files, package config, Docker layers, or build logs. CI policy is managed in another repo and cannot be inspected. ~~~ Output contract SECURITYBUILDINTEGRITYAUDIT.md or equivalent stdout report. Findings include file path, boundary, exploit sketch, blast radius, and verification suggestion. No package installs that execute scripts. No code edits. Verification Findings name the lockfile, workflow, Dockerfile, or publish path that creates the integrity gap. Mutable tags, unsigned artifacts, and script-running installs are called out with the verification that would prove them. No untrusted install scripts, publishes, deploys, or cache mutations were run. Live secrets found in CI or image layers are redacted and escalated instead of validated. Guardrails Prefer static inspection over running build steps. If commands are needed, use read-only commands such as lockfile parsing, npm ls --ignore-scripts, pip-audit --dry-run equivalents, or scanner output supplied by the operator. Do not publish, deploy, upload, sign, or mutate caches. Do not assume a mutable tag is safe because it belongs to a well-known project; record the integrity trade-off. Related Source code audit - attack surface map Vulnerable Dependency Remediation Base Image Remediation","agent_handoff":{"mcp_lookup_keys":["source-code-supply-chain-build-integrity-audit","/recipes/general/source-code-supply-chain-build-integrity-audit/","recipes/general/source-code-supply-chain-build-integrity-audit.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["remediation","audit","code-hygiene"],"source_text_field":"content_text","portable_download":"security-recipe-source-code-supply-chain-build-integrity-audit.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-source-code-supply-chain-build-integrity-audit.json"}},{"slug":"sensitive-data-remediation","title":"GitHub Copilot Sensitive Data Remediation","link_title":"Sensitive data remediation","url":"https://security-recipes.ai/recipes/github_copilot/sensitive-data-remediation/","path":"/recipes/github_copilot/sensitive-data-remediation/","source_file":"recipes/github_copilot/sensitive-data-remediation.md","recipe_id":"","recipe_kind":"","category":{"slug":"github-copilot","label":"GitHub Copilot"},"agent":"github_copilot","severity":"unspecified","maturity":"development","ecosystem":"","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"","framework_version":"","jurisdiction":"","industry":[],"cve_archetypes":[],"cve_workflow_role":"","tags":["sde","secrets","pii","dlp","copilot","cloud-agent","issue-template"],"facets":["remediation","code-hygiene"],"quality":{"score":95,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"Stephen M Abbott","team":"Security","model":"Opus 4.7","ai_assisted":false,"generated_by":"","date":"2026-04-21","zero_day":false,"last_updated":"2026-04-21","summary":"A three-part bundle for the GitHub Copilot cloud agent — a .github/copilot-instructions.md addendum, an issue template, and a repository policy — that shapes Copilot into a careful SDE remediator: pre-exposure findings get a minimal code …","content_text":"A three-part bundle for the GitHub Copilot cloud agent — a .github/copilot-instructions.md addendum, an issue template, and a repository policy — that shapes Copilot into a careful SDE remediator: pre-exposure findings get a minimal code fix in a draft PR; exposed findings get a structured triage issue and no code edits at all. Rechecked August 23, 2026: leftover CVE dumps stay development / noindex. Do not invent a named floor. Dependabot-to-agent assignment is generally available and still requires GitHub Code Security plus a Copilot plan with coding-agent access. That is not this SDE workflow. The Copilot issue-assignment and agent-tasks APIs remain public preview. Frontmatter model strings stay metadata, not prompt pins. What this prompt does When an engineer (or a scanner's issue projector) creates an issue from the security-remediation-sde.yml template and it lands labeled copilot-remediate, it becomes a bounded candidate for the GitHub Copilot cloud agent; the label alone does not start a session. An authorized operator must assign Copilot explicitly, use the supported issue assignment API, or configure an eligible Copilot automation. Manual assignment is the safest default for sensitive-data work. Once started, the agent follows the repo-level instructions and: 1. Confirms the SDE literal still appears in the current working tree. 2. Classifies the exposure scope using the issue's metadata + a git-history check. 3. Pre-exposure: replaces the literal with a reference to the approved secret store (or redaction helper), adds a regression guard, runs CI, and opens a draft PR linked to the issue. 4. Exposed: does not edit code. Instead it comments on the issue with a rotation + disclosure checklist and adds the needs-rotation label, routing the work to the on-call. Inputs: finding id, SDE class, exposure hint (from the issue body); repo-level copilot-instructions.md; an explicit Copilot assignment or eligible automation.<br/> Outputs: either a draft PR (pre-exposure) or an issue comment with a rotation checklist + needs-rotation label (exposed). Inputs Finding id, SDE class, exposure hint, affected file, line number, and scanner metadata from the issue template. Repository secret-store, redaction-helper, and CODEOWNERS policy. Approved labels, branch naming convention, PR template, and human reviewer route. Scanner evidence that can be referenced without echoing the literal secret or personal data. When to use it GitHub push protection, GitLeaks, TruffleHog, or Wiz already writes findings into Issues (or has a webhook you can fan into Issues via repositorydispatch). Your repo has an approved secret-store client documented in docs/security/secrets.md and (for PII) a redaction helper. Branch protection on main requires a human reviewer — critical because this class of change benefits from a second pair of eyes. Don't use it for: Already-exposed SDEs as primary-fix — the rule forces rotation first. The comment + label is the correct outcome. History cleanup — that's a git filter-repo runbook, not a Copilot job. Binary artifact scrubbing. The prompt Three files, checked in to the repo. .github/copilot-instructions.md — SDE remediation addendum Append this to your existing copilot-instructions.md: ~~~markdown Sensitive data element remediation When working on an issue labeled copilot-remediate whose body declares an SDE class (secret, token, pii, pci, phi), follow these rules. Exposure scope — classify first PRE-EXPOSURE: literal exists only in the current working tree. Never committed to a shared remote. Never printed in CI logs. EXPOSED: anything else. If in doubt, it's EXPOSED. Determine scope by: Reading the \"Exposure\" field of the issue body. Running git log --all -S '<literal-hash>' (hash the literal; never echo it). EXPOSED — do NOT edit code If scope is EXPOSED: Do not open a PR. Do not modify the offending file. Post a single comment on the issue with: The rotation checklist (revoke, rotate, re-deploy, invalidate cached sessions). The disclosure checklist (IR ticket, service owner, legal routing). The first-seen commit sha + date. Add the needs-rotation label. Remove the copilot-remediate label (the finding is now a rotation task, not an agent task). PRE-EXPOSURE — minimal code fix Branch: copilot/<finding-id>. Commit: fix(sec): remove <class> <finding-id>. Replacement patterns: secret / token → reference the project's approved secret store. Identify the client from docs/security/secrets.md. If that document doesn't exist or names no client, comment on the issue explaining why remediation is blocked and stop. pii / pci / phi → route through the project's redaction helper (grep for redact(, maskpii, scrubPII). If none exists, comment on the issue and stop — do not invent one. Test fixtures with real user data → replace with Faker-style synthetic values. Comment each fixture with the finding id. Add a regression guard: a unit test that fails if the literal reappears, or a scanner-config entry that flags it. Allowlist only the synthetic-fixture path. Minimal edit only. No renames. No reformatting unrelated code. What you must NEVER do Rewrite git history. Echo the SDE literal in commit messages, PR bodies, chat output, or logs. When referring to it, hash it. Commit or remove .env / credentials.json files — those require a git filter-repo runbook + human sign-off. Merge your own PR. Never enable auto-merge. PR shape (pre-exposure path) Title: fix(sec): remove <class> from <file> (<finding-id>). Body: link the issue (Closes #NNN), exposure scope (pre-exposure), replacement pattern used, test pass evidence, one-line revert instructions. Never include the literal. Labels: security, sde-remediation. Keep the PR as DRAFT. Never mark ready-for-review. ~~~ .github/ISSUETEMPLATE/security-remediation-sde.yml ~~~yaml name: Security — Sensitive data element remediation description: Open a remediation task for a single SDE finding. title: \"Remediate: <finding-id> (<sde-class>)\" labels: [\"copilot-remediate\", \"security\"] assignees: [] body: type: input id: findingid attributes: label: Finding id placeholder: GITLEAKS-AWS-001 validations: required: true type: dropdown id: sdeclass attributes: label: SDE class options: [secret, token, pii, pci, phi] validations: required: true type: dropdown id: exposure attributes: label: Exposure scope description: Best-known answer at the time of filing. The agent will re-verify. options: pre-exposure (literal only in working tree) exposed (committed / pushed / seen in CI logs / public) unknown validations: required: true type: input id: filepath attributes: label: File path placeholder: src/config/stripe.ts validations: required: true type: input id: line attributes: label: Line number placeholder: \"42\" validations: required: false type: textarea id: notes attributes: label: Notes for the agent description: | DO NOT paste the literal SDE value in this field. Hash or abstract it. Example: \"STRIPELIVEKEYsklive_ (last 4 chars: abcd)\". validations: required: false ~~~ Dispatch Copilot explicitly Creating or labeling the issue does not start the cloud agent. Use one current dispatch mechanism: Manual assignment (recommended here): open the issue, choose Copilot from the assignee list, and review the target repository, starting branch, and additional instructions. See GitHub's issue-assignment workflow. API assignment: assign copilot-swe-agent[bot] and include the supported agentassignment object. This API is a public preview; follow GitHub's current REST or GraphQL contract rather than inventing an assignee alias. Copilot automation: in an eligible private or internal repository, use an issue-created trigger filtered to label:copilot-remediate, grant only the required tools, and retain the default protection against events created by users without write access. See Copilot automations. The copilot-remediate label is a routing and filter signal only. Do not rely on an ordinary GitHub Action assigning @copilot, and do not put assignees: [\"copilot\"] in the issue template. CODEOWNERS pairing Make sure your CODEOWNERS routes SDE-relevant paths to the security team so branch protection blocks merges until they review: ~~~ CODEOWNERS excerpt src/config/ @org/security @org/platform /.env.example @org/security docs/security/ @org/security ~~~ Output contract For pre-exposure findings: draft PR with the minimal code replacement, regression guard, passing test or scanner evidence, linked issue, and explicit human reviewer. For exposed findings: issue comment with rotation and disclosure checklist, first-seen evidence, needs-rotation label, and no code edit. For blocked findings: issue comment naming the missing secret-store, redaction-helper, ownership, or exposure evidence. No output may contain the literal SDE value. Verification Run the repository's secret or DLP scanner after the fix, plus the regression test added by the PR. Confirm the issue, PR body, commit message, and logs contain only hashes or approved redacted forms. Verify CODEOWNERS routes the changed path to a security reviewer. Related recipes Seed/key material purge Codex sensitive data remediation Claude sensitive data remediation skill Known limitations Issue templates accept free-form text. If a reporter pastes the SDE literal into the notes field by mistake, it becomes part of the issue history. Gate the template with a CI step that scans issue.body and auto-edits if a known secret pattern appears — don't rely on the reporter. Git-history check is a heuristic. Renames, whitespace normalization, or format changes can hide a secret from git log -S. Prefer the scanner's own \"first seen\" metadata when it's provided. Exposure classification still benefits from a human. If Exposure is unknown, the agent will treat it as exposed (safer default) — which may feel conservative on false-positive findings. Needs-rotation label is the handoff.** Make sure on-call rotates actually subscribe to it. Changelog 2026-04-21 — v1, first published. Exposed-SDE path deliberately refuses code edits. Pair with CODEOWNERS to make path protections enforceable at the branch level.","agent_handoff":{"mcp_lookup_keys":["sensitive-data-remediation","/recipes/github_copilot/sensitive-data-remediation/","recipes/github_copilot/sensitive-data-remediation.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["remediation","code-hygiene"],"source_text_field":"content_text","portable_download":"security-recipe-sensitive-data-remediation.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-sensitive-data-remediation.json"}},{"slug":"vulnerable-dep-remediation","title":"GitHub Copilot Vulnerable Dependency Remediation","link_title":"Vulnerable dep remediation","url":"https://security-recipes.ai/recipes/github_copilot/vulnerable-dep-remediation/","path":"/recipes/github_copilot/vulnerable-dep-remediation/","source_file":"recipes/github_copilot/vulnerable-dep-remediation.md","recipe_id":"","recipe_kind":"","category":{"slug":"github-copilot","label":"GitHub Copilot"},"agent":"github_copilot","severity":"unspecified","maturity":"development","ecosystem":"","cve":"","ghsa":"","kev":false,"aliases":[],"framework":"","framework_version":"","jurisdiction":"","industry":[],"cve_archetypes":[],"cve_workflow_role":"","tags":["sca","cve","dependencies","copilot","cloud-agent","issue-template"],"facets":["remediation","audit","risk","code-hygiene"],"quality":{"score":100,"tier":"world-class","signals":["inputs","selection-guidance","output-contract","verification","guardrails","related-context","multi-facet"],"scorecard":"inputs + selection guidance + output contract + verification + guardrails + related context + multi-facet coverage"},"recipe_contract":{"primary_job":"Give an agent bounded remediation context for one source-code security finding, audit question, or hygiene improvement.","selection_guidance":"Prefer the narrowest recipe that matches the finding, affected technology, compliance objective, and permitted output.","output_expectation":"Reviewer-ready patch, triage note, evidence report, or stop-condition report as specified by the recipe.","safety_boundary":"Read only until the operator explicitly authorizes edits; never rotate secrets, deploy, change cloud state, or widen scope unless the recipe and task both allow it."},"author":"Stephen M Abbott","team":"Security","model":"Opus 4.7","ai_assisted":false,"generated_by":"","date":"2026-04-21","zero_day":false,"last_updated":"2026-04-21","summary":"A three-part bundle — a .github/copilot-instructions.md addendum, a GitHub issue template, and an explicit assignment step after the finding is validated. Together they shape the GitHub Copilot cloud agent into a narrow, reviewable …","content_text":"A three-part bundle — a .github/copilot-instructions.md addendum, a GitHub issue template, and an explicit assignment step after the finding is validated. Together they shape the GitHub Copilot cloud agent into a narrow, reviewable dependency remediator: one finding per issue, one draft PR per issue, no auto-merge. Rechecked August 23, 2026: leftover CVE dumps stay development / noindex. Do not invent a named floor. Dependabot-to-agent assignment is generally available for Copilot, Claude, and Codex and still requires GitHub Code Security plus a Copilot plan with coding-agent access. That is not the same as one-step Autofix. The Copilot issue-assignment and agent-tasks APIs remain public preview. Frontmatter model strings stay metadata, not prompt pins. What this prompt does When the scanner (or a developer) creates an issue from the security-remediation-dep.yml template and labels it copilot-remediate, the label routes the issue for validation; it does not start the GitHub Copilot cloud agent. After an authorized reviewer confirms the advisory, affected package, repository, and scope, they explicitly assign the issue to Copilot. The cloud agent then reads the repository-level instructions, applies the minimum viable version bump in the affected manifest + lockfile, runs CI, and opens a draft PR linked back to the issue. The agent respects the house rules — no major bumps, no lockfile-only edits, no disabling of tests. Inputs: finding id + affected package (from the issue body), repository-level instructions (from .github/copilot-instructions.md).<br/> Outputs: a draft PR linked to the issue, passing CI, and a human reviewer assigned via CODEOWNERS. When to use it You want the shortest-setup remediation path. GitHub-native, no separate orchestration layer. Your scanner already supports projecting findings into GitHub Issues (CodeQL, Snyk, Semgrep, Dependabot alerts converted to issues). You have branch protection on main that requires review and green CI, so the \"agent opens a draft PR\" pattern is safe. Don't use it for: Major version migrations — the repository instructions refuse. Cross-repo fanouts — each repo needs its own instructions and dispatch policy; this prompt is per-repo. First-party SAST findings — use the SDE remediation recipe. Inputs GitHub issue template fields: finding id, affected package, severity, advisory URLs, scanner notes, workspace hint, direct/transitive evidence, and a copilot-remediate routing label that does not itself dispatch the agent. Repository instructions from .github/copilot-instructions.md, issue body, CODEOWNERS, branch protection, required CI, PR labeling rules, and reviewer routing. Dependency evidence: manifests, lockfiles, package manager, dependency tree, current version, patched range, direct parent for transitive fixes, and ecosystem-specific update commands. Verification evidence: documented lint/test commands, CI status, scanner re-run output, lockfile diff, refused-fix issue comments, and revert instructions. Triage evidence for major bump, prerelease-only, package-not-installed, tests failing, unavailable patch, monorepo workspace scope, and branch or CODEOWNERS restrictions. The prompt Two files are checked in to the repository; a validated issue is then dispatched through an explicit assignment step. .github/copilot-instructions.md — dependency remediation addendum Append this to your existing copilot-instructions.md: ~~~markdown Vulnerable dependency remediation When working on an issue labeled copilot-remediate whose body includes a finding id (CVE- / GHSA-), follow these rules. Scope ONE finding per PR. Never bundle multiple advisories. Branch: copilot/<finding-id>. Commit: Conventional Commits: fix(sec): bump <pkg> from <old> to <new> (<finding-id>). Version bump policy Pick the LOWEST version in the advisory's patched range. NEVER bump across a major-version boundary. If the only fix is a major bump, post a comment on the issue explaining why (direct dep vs transitive, breaking changes expected) and stop — do not push a PR. Pre-release / rc / beta versions are off by default. If the advisory lists only a pre-release fix, comment on the issue and stop. Tooling Use the native package manager to apply the bump. Never hand-edit the lockfile. After the bump, run the lint and test commands documented at the top of this file. If they fail because of the bump, revert, comment on the issue with the failing tests, and stop. Paths you may NOT touch db/migrations/ — any DB migration. infra/terraform/ — infra-as-code. /.generated. — generated code. Any CI workflow, except to update a pinned action version in response to a CVE on that action. PR shape Title: fix(sec): bump <pkg> to <ver> (<finding-id>). Body: link the issue (Closes #NNN), finding id + link to advisory, old → new version, direct vs transitive, test command + pass evidence, one-line revert instructions. Keep the PR as DRAFT. Never mark ready-for-review. Never enable auto-merge. ~~~ .github/ISSUETEMPLATE/security-remediation-dep.yml ~~~yaml name: Security — Dependency remediation description: Open a remediation task for a single CVE / GHSA finding. title: \"Remediate: <finding-id> in <package>\" labels: [\"copilot-remediate\", \"security\"] assignees: [] body: type: input id: findingid attributes: label: Finding id description: CVE id, GHSA id, or scanner-assigned id. placeholder: CVE-2026-1234 validations: required: true type: input id: package attributes: label: Affected package description: Package name (best-effort hint from the scanner). placeholder: \"@example/unsafe-parser\" validations: required: true type: dropdown id: severity attributes: label: Advisory severity options: [critical, high, medium, low] validations: required: true type: textarea id: advisoryurl attributes: label: Advisory link(s) description: Paste the GHSA / CVE / NVD URL. validations: required: true type: textarea id: notes attributes: label: Notes for the agent description: Anything the scanner couldn't auto-populate. placeholder: | Dependency is transitive via \"express@4\". Workspace package apps/web is the caller. validations: required: false ~~~ Dispatch the validated issue Creating or labeling the issue does not start the cloud agent. First confirm that the advisory is authoritative, the package is installed, and the issue is in the repository that owns the fix. Then choose one supported mechanism: Manual assignment (recommended): select Copilot from the issue's assignee list and review the target repository, starting branch, and additional instructions. See GitHub's issue-assignment workflow. API assignment after validation: assign copilot-swe-agent[bot] and send the supported agentassignment object. The API is a public preview; use GitHub's current REST or GraphQL contract. Copilot automation only for a trusted intake: eligible private and internal repositories can use an issue-created automation with a narrow search filter and least-privilege tools. Do not connect raw third-party scanner output directly to an autonomous code-writing session. Preserve the default protection against events created by users without write access. See Copilot automations. The copilot-remediate label is a routing and filter signal only. Do not rely on an assign-copilot.yml Action, an @copilot alias, or assignees: [\"copilot\"] in the issue template. Once the session starts, the GitHub Copilot cloud agent reads: 1. The repo-level copilot-instructions.md (house rules + the dependency addendum above). 2. The issue body (finding id, package, advisory link). It produces a draft PR on copilot/<finding-id> that either fixes the finding or posts a comment explaining why the fix was refused (major bump required, pre-release only, tests fail). Verification Rechecked 2026-08-21 against GitHub's current Copilot Autofix and Copilot cloud agent (\"Assign to Copilot\") workflow. Creating or labeling an issue still does not start the agent; an authorized reviewer must assign the issue after validation. One finding still produces one draft PR or a refusal comment. Output contract Return one of: A draft PR linked to the issue that remediates one advisory-driven dependency path, uses the native package manager, touches only allowed manifest/lockfile artifacts, records test evidence, follows branch/commit/title/body rules, and routes to CODEOWNERS review. An issue comment without code changes when the package is not installed, the fix requires a disallowed major bump, only a prerelease exists, tests fail, the scope is ambiguous, or the finding belongs to another repo/workspace. The output must list finding id, package, advisory link, old/new version, direct/transitive status, files touched, tests/CI evidence, PR URL or refusal reason, and reviewer routing. It must not mark the PR ready, auto-merge, edit forbidden paths, disable tests, or bundle multiple advisories. Related recipes Vulnerable Dependency Remediation Codex vulnerable dependency remediation Cursor vulnerable dependency remediation Known limitations Instructions are a prompt, not enforcement. Pair this with strict branch protection + CODEOWNERS routing on any path the agent must not touch. The addendum's \"paths you may NOT touch\" list is advisory; CODEOWNERS makes it a hard gate. Single-manifest assumption. For monorepos, file one issue per affected workspace so the agent has a narrow scope. Transitive fixes. The agent can only hoist a transitive fix by bumping a parent; if the parent requires a major bump, the addendum forces a stop. That's the correct behavior, but expect more \"refused\" comments than raw PRs for older ecosystems. Scanner projection cadence matters.** If your scanner projects every low-severity finding into an issue, the Copilot review queue will balloon. Gate projection on severity high | critical and label drift manually. Changelog 2026-04-21 — v1, first published. Covers Node / Python / Go lockfiles. Major-bump refusal is intentional.","agent_handoff":{"mcp_lookup_keys":["vulnerable-dep-remediation","/recipes/github_copilot/vulnerable-dep-remediation/","recipes/github_copilot/vulnerable-dep-remediation.md"],"recommended_mcp_tools":["recipes_search","recipes_get","recipes_match_finding"],"selection_facets":["remediation","audit","risk","code-hygiene"],"source_text_field":"content_text","portable_download":"security-recipe-vulnerable-dep-remediation.json"},"download":{"content_type":"application/json","suggested_filename":"security-recipe-vulnerable-dep-remediation.json"}}]}