ShieldNet-360/secure-vibe

<!-- Native skill bundle for agent-skills (cross-tool convention). Generated by `secure-vibe dev regenerate`. -->
<!-- Do not edit by hand; the source of truth is skills/api-security/SKILL.md. -->

# API Security

OWASP API Top 10 for HTTP, GraphQL, and gRPC endpoints: input validation, route rate limiting, mass assignment, response caching, and gateway-versus-service control placement. Use when generating or reviewing HTTP handlers, GraphQL resolvers, gRPC service methods, or any API endpoint change.

## ALWAYS

- Require authentication on every non-public endpoint. Default to authenticated; opt out for genuinely public routes by explicit annotation.
- Consult `auth-security` for **who the caller is and what they may touch**. It owns the credential (algorithm pinning, expiry, lifetime, session, CSRF) and the permission (object-level BOLA/IDOR checks, multi-key routes, streaming subjects, function-level role gating). Any endpoint that reads or writes a resource by id needs it; this skill covers everything else about the endpoint.
- Validate all request inputs against an explicit schema (JSON Schema, Pydantic, Zod, validator/v10 struct tags). Reject early; never propagate untrusted input deeper.
- Enforce rate limits at the route level for authentication endpoints, password reset, and any expensive operation.
- Consult `error-handling-security` for what an error response may carry. It owns the boundary between what crosses to the client and what stays in the log, including presence-of-record disclosure (`User not found` vs `Invalid credentials`).

<!-- Native skill bundle for agent-skills (cross-tool convention). Generated by `secure-vibe dev regenerate`. -->
<!-- Do not edit by hand; the source of truth is skills/auth-security/SKILL.md. -->

# Authentication & Authorization Security

[Credential-related source omitted]

## ALWAYS

- Authorize at the **object level** — confirm the authenticated subject actually has access to the requested resource ID, not just that they are logged in. Being signed in is not permission to read record 4,182 (OWASP API1 — BOLA / IDOR).
- Bind object-level authorization to the **authenticated principal**, never to an actor id echoed in the request: checking that a request-supplied `senderId`/`ownerId`/`actedBy` is a valid member validates the *claimed* actor, not the caller (looks like authorization, isn't).
- On `/{scopeId}/.../{subjectId}` routes, authorize the **relationship** — confirm the subject belongs to that scope. A caller-vs-scope check alone does not authorize the subject (multi-key BOLA).
- Authorize **each subject on streaming responses** (SSE/chunked/WebSocket): the `200` is committed before the handler runs, so an empty/filtered stream — not a `4xx` — is the deny signal; an unauthorized subject gets zero events.
- Enforce a **function-level role / privilege check** on any write that publishes into a shared or global namespace (a global gallery, shared catalog, public template list). Authentication is not authorization (OWASP API5 — Broken Function Level Authorization); a low-privilege user posting into a globally-visible store is a delivery vector for stored-XSS and malicious-link chains.

<!-- Native skill bundle for agent-skills (cross-tool convention). Generated by `secure-vibe dev regenerate`. -->
<!-- Do not edit by hand; the source of truth is skills/cicd-security/SKILL.md. -->

# CI/CD Pipeline Security

Harden GitHub Actions, GitLab CI, and similar pipelines against supply-chain attacks, secret exfiltration, and pwn-request abuse. Use when authoring or reviewing workflow files, adding a third-party action, image, or script, wiring cloud or registry credentials into CI, or triaging a suspected pipeline compromise.

## ALWAYS

- Pin every third-party GitHub Action by **commit SHA** (full 40-char), never by a floating tag (`@v1`, `@main`, `@latest`) — tags can be re-pushed. The tj-actions/changed-files March 2025 incident exfiltrated secrets from 23,000+ repositories specifically because consumers used floating tags. Same applies to GitLab CI `include:` references and reusable workflows. Renovate / Dependabot can keep the SHA pins fresh.
[Credential-related source omitted]
[Credential-related source omitted]
- Treat `pull_request_target`, `workflow_run`, and any `pull_request` job that uses `actions/checkout` with `ref: ${{ github.event.pull_request.head.ref }}` as **trusted-context-on-untrusted-code** — the "pwn request" pattern documented by GitHub Security Lab. Either don't run them, or run with no secrets and no write tokens. A fork's GitLab merge-request pipeline is the same shape — it runs the fork's own `.gitlab-ci.yml` on your runners: isolate them, expose no protected variables.
- Echo every untrusted expression (`${{ github.event.* }}`) through an environment variable first; never interpolate it directly into `run:` body — that's the canonical GitHub Actions script-injection sink. The GitLab sink has the same shape: `$CI_*` / `$TRIGGER_*` interpolated into `bash -c` or `eval`, where merge-request metadata carries the shell metacharacters.

<!-- Native skill bundle for agent-skills (cross-tool convention). Generated by `secure-vibe dev regenerate`. -->
<!-- Do not edit by hand; the source of truth is skills/container-security/SKILL.md. -->

# Container Security

Hardening for Dockerfiles, OCI images, Kubernetes manifests, and Helm charts. Use when generating a Dockerfile or image build, writing Kubernetes, Helm, or Kustomize manifests, or reviewing container changes in a pull request.

## ALWAYS

- Use **multi-stage builds**: separate builder/test stages from the final runtime image so build toolchains and source aren't shipped. The last stage should be a minimal base — `gcr.io/distroless/<variant>`, `scratch`, or a versioned `-slim` / `-alpine` variant — pinned by SHA256 digest, not just tag. Two bases have nothing to pin: `scratch`, and a reference to an earlier stage in the same file (`FROM base`), which is pinned on that stage's own `FROM` line.
- Run as a non-root user: set `USER` explicitly on the **final stage**, as a **number** not a name. Omitting it leaves the container running as root. K8s `runAsNonRoot` rejects UID 0 and cannot resolve a username, so `USER appuser` fails at startup with "image has non-numeric user"; any non-zero UID passes, and 10000+ by convention also avoids colliding with host accounts.
- Use **`npm ci`** (and equivalents `pnpm install --frozen-lockfile`, `yarn install --frozen-lockfile`) in container builds, not `npm install`. `npm install` mutates the lockfile and resolves versions per-build, producing non-deterministic images that drift from the lockfile.
- Add a `.dockerignore` excluding `.git`, `node_modules`, `.env`, `*.pem`, `*.key`, `target/`, `.terraform/`, `dist/`, `coverage/`.
- Build with **BuildKit** (default since Docker Engine 23; `DOCKER_BUILDKIT=1` on older engines) so `RUN --mount=type=secret,id=<name>` is available for build-time credentials. `# syntax=docker/dockerfile:1` selects the frontend and does **not** enable BuildKit by itself.

<!-- Native skill bundle for agent-skills (cross-tool convention). Generated by `secure-vibe dev regenerate`. -->
<!-- Do not edit by hand; the source of truth is skills/cors-security/SKILL.md. -->

# CORS Security

Strict CORS: no wildcard with credentials, exact-match origin allowlists, sane preflight cache, minimal exposed headers. Use when generating CORS middleware or framework config, setting CORS headers in API Gateway, CloudFront, or Nginx, or reviewing a cross-origin browser-facing endpoint.

## ALWAYS

- For any non-public endpoint, allow origins from an explicit allowlist. `*` is correct only when the resource is intentionally public *and* cross-origin access never carries credentials.
- When a cross-origin request carries credentials — the browser's credentials mode is `include`, meaning cookies, TLS client certificates, or browser-managed HTTP auth — respond with `Access-Control-Allow-Credentials: true` and a **single explicit origin**. On a credentialed request every CORS header loses its wildcard meaning: `*` in `Allow-Origin`, `Allow-Methods`, `Allow-Headers`, or `Expose-Headers` is read as the literal string `"*"` and the browser blocks the response. That is why "just set it to `*` for now" fails in a way that is hard to debug.
- Compare origins by exact match on the **serialized** origin — scheme, host, and port, all three. Never substring, prefix, or suffix matching: `endsWith("example.com")` accepts `https://example.com.evil.com`, and an unescaped `.` in `^https://api.example.com$` accepts `https://apiXexample.com`.
- Include `Vary: Origin` on any response whose headers depend on the request `Origin`, so a shared cache cannot hand one origin's `Access-Control-Allow-Origin` to another.
[Credential-related source omitted]

<!-- Native skill bundle for agent-skills (cross-tool convention). Generated by `secure-vibe dev regenerate`. -->
<!-- Do not edit by hand; the source of truth is skills/crypto-misuse/SKILL.md. -->

# Cryptographic Misuse

Block weak ciphers, predictable RNG, undersized keys, fast-hash password storage, nonce reuse, and non-constant-time comparison. Use when generating code that hashes, encrypts, or signs, code that compares secrets, MACs, or tokens, or config for key sizes and randomness.

## ALWAYS

- Use a maintained, widely reviewed cryptographic API — the platform's own (Node `crypto`, Java JCE, .NET `System.Security.Cryptography`, Go `crypto/*`) or a reputable third-party one (PyCA `cryptography`, `golang.org/x/crypto`, Bouncy Castle). Prefer high-level, misuse-resistant APIs over assembling low-level primitives yourself. In Python, `from Crypto…` resolves to either the abandoned `pycrypto` or its maintained fork `pycryptodome` depending on what is installed — the import line is identical, so depend on `pycryptodome` explicitly.
- Use a cryptographically secure RNG for anything security-relevant: Python `secrets.token_bytes` / `secrets.token_urlsafe`, JS `crypto.getRandomValues` / `crypto.randomBytes`, Go `crypto/rand.Read`, Java `SecureRandom`.
- Hash passwords with a password-specific KDF and a unique random salt per password. Prefer Argon2id; scrypt where appropriate; bcrypt for legacy compatibility; PBKDF2-HMAC-SHA-256 where FIPS-140 compliance is required. Take minimum parameters from the current [OWASP Password Storage Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html), then benchmark on production hardware and choose the highest cost that still meets the application's authentication latency and availability budget. The cost is meant to be raised over time as hardware gets cheaper — it is not a constant to copy once.
- Account for bcrypt's 72-byte input limit: it silently truncates, so a long passphrase and its 72-byte prefix hash identically. If bcrypt must take unbounded input, pre-hash with SHA-256 and pass the digest **base64-encoded**, never as raw bytes — a raw digest can contain a NUL byte, which truncates the input again.
- Encrypt with a vetted AEAD: AES-GCM or ChaCha20-Poly1305, or AES-GCM-SIV where nonce-misuse resistance is specifically useful and the platform ships a reviewed implementation. Absent a stated key-size requirement, AES-256-GCM or ChaCha20-Poly1305 is a safe default — AES-128-GCM is not a finding.

<!-- Native skill bundle for agent-skills (cross-tool convention). Generated by `secure-vibe dev regenerate`. -->
<!-- Do not edit by hand; the source of truth is skills/database-security/SKILL.md. -->

# Database Security

Prevent SQL and NoSQL injection, unsafe ORM and raw-query use, over-privileged database identities, weak tenant isolation, and unauthenticated database transport. Use when generating SQL or raw query strings, NoSQL filters, ORM models or queries, database migration files, or connection strings.

## ALWAYS

- Bind every untrusted data value through the driver or ORM parameter API. Never place it into SQL with language-level interpolation or concatenation — `+`, f-strings, `%` formatting, `.format()`, JavaScript template interpolation. Driver placeholders (`%s`, `?`, `$1`, `:name`, `@name`) are the binding *mechanism*, not string formatting; confusing the two is how this rule is most often misread. The same applies to values read back out of the database and used to build a later query: stored input is still input, and second-order injection is this bug with a delay.
- Prefer the ORM's structured query-expression API over textual SQL. Where raw SQL is genuinely needed, use that framework's documented parameter-binding mechanism and never interpolate untrusted values into it. `references/orm-safe-query-examples.md` carries the verified form per framework.
- For SQL structure that cannot be a bind parameter — table and column identifiers, sort direction, sometimes the operator itself — map the external value to a fixed operator-controlled allowlist. Never copy an untrusted identifier or SQL fragment into the statement, escaped or not.
- Treat a NoSQL query as a structure, not a string. Build filters with the driver's typed query objects, and coerce every request-supplied value to its expected scalar type before it reaches a filter. A JSON body substituting `{"$ne": null}` where a string was expected turns an equality check into a match-all — operator injection needs no quote to break out of.
- Give each application its own database identity with the minimum grants it needs, and separate runtime privileges from migration privileges. The runtime identity must not receive schema-owner or DDL rights merely because migrations require them.

<!-- Native skill bundle for agent-skills (cross-tool convention). Generated by `secure-vibe dev regenerate`. -->
<!-- Do not edit by hand; the source of truth is skills/deserialization-security/SKILL.md. -->

# Deserialization Security

Block unsafe deserialization and unsafe XML parsing in Java, Python, .NET, PHP, and Ruby: gadget chains, unrestricted type resolution, external entity expansion, and safer formats. Use when parsing or deserializing data from an untrusted source, wiring cookies, sessions, queues, or RPC payloads, or reviewing pickle, unserialize, Marshal, ObjectInputStream, BinaryFormatter, or XML parser configuration.

## ALWAYS

- Prefer data-only serialization formats — JSON, Protobuf, MessagePack with an explicit type map — over formats that reconstruct arbitrary runtime objects. What makes a format safe here is not schema validation; it is whether the parser can instantiate a class the payload names.
- Constrain polymorphic type resolution to an explicit set of expected application types. Never let payload data choose the runtime class — that is the mechanism behind every gadget chain, whichever serializer is involved.
- Treat an object-reconstructing deserializer crossing a trust boundary as high risk: `pickle`, `ObjectInputStream`, `BinaryFormatter`, `unserialize`, `Marshal.load` and their framework equivalents. Adding one to a request-handling path needs explicit review — check the platform reference for the exact API and the version behaviour before accepting or remediating a use.
- Disable external entity resolution and DTD processing on every XML parser that receives untrusted input. A parser that resolves entities is a file-read and server-side request primitive before it is a parser; `ssrf-prevention` owns where the outbound request lands.
- Where serialized state carries a signature or MAC, verify it **before** invoking the deserializer — and treat that as defense in depth, not a licence to keep an unsafe format. `crypto-misuse` owns the signing key, its algorithm and its rotation.

<!-- Native skill bundle for agent-skills (cross-tool convention). Generated by `secure-vibe dev regenerate`. -->
<!-- Do not edit by hand; the source of truth is skills/dynamic-verification/SKILL.md. -->

# Verify Findings

Confirm or refute a vulnerability candidate against a live target with a deterministic probe, respecting authorization and scope. Use when a SAST or LLM review flags a possible injection or SSRF, when triaging a finding before filing a bug or shipping a fix, or when a verification result turns out wrong.

## ALWAYS

- Treat a static-analysis or LLM-review hit as a *candidate*, not a vulnerability, until a probe with a deterministic oracle confirms it against a live target.
- Prefer an oracle that proves server-side behaviour over one that inspects the response text: out-of-band callbacks (SSRF, blind command injection, XXE) and timing deltas (blind SQLi, command injection) catch *blind* bugs that leave no trace in the body.
- Re-confirm any timing-based result a second time before trusting it — one slow response is noise, a repeatable delay over baseline is signal.
- For reflected oracles (XSS, SSTI), require the dangerous form: XSS confirms only when the payload comes back UNESCAPED; SSTI confirms only when the arithmetic is EVALUATED (the product appears as a standalone number and the raw expression does not).
- Pin file-read oracles (path traversal) to a content signature of a known system file (`root:…:0:0:` from `/etc/passwd`, `[fonts]` from `win.ini`), never to a generic 200/404.

<!-- Native skill bundle for agent-skills (cross-tool convention). Generated by `secure-vibe dev regenerate`. -->
<!-- Do not edit by hand; the source of truth is skills/electron-security/SKILL.md. -->

# Electron Desktop Security

Harden Electron: renderer trust boundary (nodeIntegration, contextIsolation, sandbox), build-time fuses, contextBridge and IPC allowlists, shell.openExternal, navigation guards, deep-link auth, safeStorage. Use when generating main-process code, a preload script, or custom-protocol handlers, when packaging a release, or when storing tokens in an Electron app.

## ALWAYS

- **Treat the renderer as untrusted.** Any renderer-side code execution — XSS in rendered content, a redirect, a deep link — must not be able to reach Node, the shell, the filesystem, or session tokens. Every other rule here follows from this one, and every IPC sink you expose is reachable from a compromised renderer.
- Keep the renderer's process isolation at its defaults rather than restoring them: `nodeIntegration: false`, `contextIsolation: true` and `sandbox: true` have been Electron's defaults for several major versions, so the finding is the line that **turns one off**. Note the coupling: under `sandbox: true` a preload gets a polyfilled module subset, so a preload needing `fs` fails — move that work behind IPC into the main process, never drop the sandbox.
- Set the packaging **fuses** on release builds: disable `RunAsNode`, `EnableNodeCliInspectArguments` and `EnableNodeOptionsEnvironmentVariable`. With `RunAsNode` on, an attacker runs your signed binary as a plain Node process and every renderer-side control above becomes irrelevant — a build-time setting no runtime hardening substitutes for.
- Expose a **minimal, typed** API from the preload via `contextBridge.exposeInMainWorld`. Expose named functions only — never hand the renderer `ipcRenderer`, `require`, `process`, or whole modules. Do not add `@electron/remote`: it restores the main-process object access that was removed from core precisely because it defeats the boundary.
- Validate **every** IPC argument in the main-process handler: type-check, bound, and allowlist. The renderer is an attacker-controlled input source.

<!-- Native skill bundle for agent-skills (cross-tool convention). Generated by `secure-vibe dev regenerate`. -->
<!-- Do not edit by hand; the source of truth is skills/error-handling-security/SKILL.md. -->

# Error-Handling Security

Decide what an error tells the client and what stays server-side: no stack traces, SQL, or paths in responses, no silent suppression, and no distinction between outcomes that would reveal protected state. Use when generating HTTP, GraphQL, or RPC error handlers, exception, panic, or rescue blocks, or configuring production error pages.

## ALWAYS

- Catch exceptions at the boundary — HTTP handler, RPC method, message consumer — and decide *there* what crosses to the client and what stays server-side. Record the failure with a correlation ID under `logging-security`'s policy; do not bypass its redaction rules to attach "full context", which is how request bodies, cookies and tokens end up in logs.
- Put only client-actionable information in an external error: a stable error code, a short human-readable message, and the correlation ID. Anything the caller cannot act on belongs in the log entry that shares that ID.
- Keep responses **consistent within an error class**, and make security-equivalent outcomes externally indistinguishable. Different classes may and should differ — `400 VALIDATION_FAILED`, `401`, `403`, `409`, `429` are not a finding. What must not differ is a pair of outcomes whose distinction reveals protected state: whether an account exists, whether a record the caller may not see is present. `auth-security` owns making the login paths cost the same; this rule owns what they return.
- Disable developer error pages and detailed exception rendering in every non-development environment, and route unhandled errors through the framework's production error handler. This is a wiring decision, not the same thing as an environment variable reading `production` — the setting and its name differ per framework, and `references/framework-error-pages.md` has them.
- Render every external error through one helper, so the sanitization rules live in a single place instead of being re-derived at each handler.

<!-- Native skill bundle for agent-skills (cross-tool convention). Generated by `secure-vibe dev regenerate`. -->
<!-- Do not edit by hand; the source of truth is skills/file-upload-security/SKILL.md. -->

# File Upload Security

Accept, store, process, and serve user uploads safely: type-appropriate content validation, decompression limits, generated storage keys, quarantine before publication, isolated media processing, and scoped direct-to-storage credentials. Use when generating a file-upload endpoint, wiring presigned or SAS uploads to S3, GCS, or Azure Blob, processing user-supplied images or documents, or serving user-generated content.

## ALWAYS

- Put every new upload in a **non-public quarantine** location, and do not expose it, link it, index it, or hand it to a downstream workflow until validation has succeeded. Quarantine → validate → process → publish, in that order. This is the invariant the rest of these rules hang from, and the one direct-to-storage uploads most often skip.
- Validate content **server-side with checks appropriate to the format**. Where a format has a reliable signature, verify it; for container and document formats — DOCX, XLSX and ZIP are all ZIP at the container level — also validate structure against the format you expect. Text-based formats such as SVG and CSV have no signature to check at all, so a signature check alone is not a content policy. The client's `Content-Type` and the filename are attacker-controlled and are never the check.
- Keep a **per-endpoint allowlist** of accepted types and deny everything else. Deny `image/svg+xml` by default: an SVG is a document that can carry script. Where an endpoint genuinely requires SVG, treat it as active content — rasterize it, or run a maintained **SVG-aware** sanitizer with an explicit element, attribute, URL and CSS allowlist. A generic HTML sanitizer is the wrong tool for it.
- Bound the **expansion**, not only the upload. For archives and compressed or container formats, cap expanded bytes, entry count, nesting depth, compression ratio, per-entry size and processing time, and reject before extracting when the projected expansion exceeds policy. A limit on the compressed bytes says nothing about what they become (CWE-409).
- Store under an **application-generated identifier** — a UUID or content hash — outside the executable or web document root, and never build the storage path from the user-supplied name. Keep the original filename as bounded metadata only, and encode it for the specific output context where it is displayed. There is no "escaped at rest" that is safe in every context.

<!-- Native skill bundle for agent-skills (cross-tool convention). Generated by `secure-vibe dev regenerate`. -->
<!-- Do not edit by hand; the source of truth is skills/frontend-security/SKILL.md. -->

# Frontend Security

Browser-side hardening: XSS and safe text binding, per-sink URL policy, DOM clobbering, nonce-based CSP, Trusted Types, subresource integrity, iframe capability minimization, postMessage validation, and where client state may live. Use when generating HTML, JSX, Vue, or Svelte templates, setting response headers in a web app, embedding third-party scripts or frames, or storing anything client-side.

## ALWAYS

- Render untrusted data through the framework's ordinary text interpolation, which escapes for the output context. Do not reach for a raw-HTML API merely to display user data. Where rich HTML genuinely must be rendered, put it through a maintained sanitizer (DOMPurify) with an explicit allowlist first.
- Validate URL-bearing attributes **per sink**, not against one global scheme list. A navigation target (`href`, `action`, `formaction`, an `<iframe src>`) and an image source do not share a trust model: `javascript:` is never acceptable anywhere, while a narrowly constrained `data:image/…` or `blob:` may be exactly what an image sink requires. Decide the permitted schemes for each sink and check against that list.
- Read security-sensitive configuration and control-flow values from lexical variables or an object you own — never from a named `window` / `document` property (`window.config`, `document.redirectTo`, an implicit global). The browser exposes elements by `id` and `name` as named properties, so injected markup can shadow the value your code expected. An explicit `getElementById()` lookup is not the problem; trusting an ambient global is. Type-check what you read before using it in a privileged way.
- Build the `Content-Security-Policy` around a **nonce or hash as the trust root**: `script-src 'nonce-{value}' 'strict-dynamic'; object-src 'none'; base-uri 'none'`. Keeping `'self'` beside the nonce means every same-origin script is still trusted — that is a host-allowlist policy wearing a nonce, which may be the right trade-off but is not a strict CSP, so do not call it one. Generate the nonce from a CSPRNG afresh for **every HTML response**, and apply it only to scripts the server itself authorizes.
- Where you deploy Trusted Types, enforce `require-trusted-types-for 'script'` **and** restrict which policies may exist with the `trusted-types` directive. The first makes DOM sinks demand a typed value; without the second, any code can mint a pass-through policy (`createHTML: s => s`) and the guarantee is gone. Keep policies few, named, and centrally reviewed.

<!-- Native skill bundle for agent-skills (cross-tool convention). Generated by `secure-vibe dev regenerate`. -->
<!-- Do not edit by hand; the source of truth is skills/graphql-security/SKILL.md. -->

# GraphQL Security

Bound and control a GraphQL endpoint: operation cost budgets, cost-based rate limiting, pre-registered operations, alias and batch abuse on authentication paths, introspection, cache keying, and untyped scalar inputs. Use when generating schemas, resolvers, or server config, wiring limits or persisted operations, or reviewing a public /graphql endpoint.

## ALWAYS

- Enforce a **cost budget** on every operation: a maximum depth, plus a complexity score that weights list fields by the page size they can request. Derive the numbers from your own schema and measure them — a depth of 7 is generous for a flat schema and far too permissive for one with a many-to-many edge, where five levels of nesting can address billions of nodes. `references/graphql-limits.md` covers how to derive them and where each server configures them.
- Rate-limit by **cost consumed**, not by request count. Every operation arrives at the same URL, so the per-route limit `api-security` specifies cannot tell a trivial query from one costing a thousand times more. Charge the complexity score against the caller's budget.
- For a public or high-traffic API, restrict it to **pre-registered operations** — a build-time allowlist of the documents the client bundle actually contains, keyed by hash. Automatic Persisted Queries are **not** this: APQ lets a client register any operation it likes and then send its hash, which is a bandwidth optimization. Turning on APQ and believing the API is now allowlisted is a common and expensive mistake.
- Cap aliases per operation and operations per batch, and apply that counting to **authentication and other rate-limited paths**. One request carrying a hundred aliased `login` fields is a hundred attempts against any counter that increments once per request — this is the mechanism behind the account-takeover-by-batching incidents, not a bandwidth concern.
- Batch resolver fetches with a DataLoader or a join. An N+1 resolver turns one cheap-looking query into a database round trip per parent row — the same amplification the cost limit exists to bound, except it happens below the cost analysis where that limit cannot see it.

<!-- Native skill bundle for agent-skills (cross-tool convention). Generated by `secure-vibe dev regenerate`. -->
<!-- Do not edit by hand; the source of truth is skills/iac-security/SKILL.md. -->

# Infrastructure-as-Code Security

Terraform, CloudFormation, and Pulumi hardening: state as a secret store, pinned providers and modules, encryption and network defaults, drift, and the privilege of the pipeline that applies the plan. Use when generating infrastructure code, reviewing IaC changes in a pull request, configuring a state backend, or setting up a new cloud account or workspace.

## ALWAYS

- Treat the **state file as a secret store**. Every value that passes through Terraform — a generated password, an RDS master credential, a private key, the contents of a data source — is written to state in plaintext. `sensitive = true` only hides a value from CLI output; it changes nothing about what is stored. So read access to the backend is read access to those secrets, and the backend's access policy has to be written on that basis.
- Configure a **remote backend** with encryption at rest, state locking, and versioning. Prefer the backend's own locking where it exists — recent Terraform supports S3-native locking, so a separate DynamoDB lock table is no longer required for new stacks. `references/backends-and-state.md` has the per-backend form.
- Pin providers and modules to an exact version or a pessimistic constraint (`~> 5.42`), and pin a third-party module sourced from a git URL to a **commit SHA**, not a branch or tag. A module is code that runs with your apply credentials, and a registry or repository you do not control is a supply-chain input like any other.
- Give the **apply identity** the least privilege that the stack actually needs, and keep it separate from the plan identity. A pipeline role with account-wide admin turns any CI compromise into a full account compromise — `cicd-security` owns hardening the pipeline itself, `iam-best-practices` owns the role's shape.
- Encrypt persistent resources by default with a customer-managed key: object storage, block storage, managed databases, queues, log groups. Prefer a module or default that applies it, so a new resource is encrypted because of how the code is organised rather than because someone remembered.

<!-- Native skill bundle for agent-skills (cross-tool convention). Generated by `secure-vibe dev regenerate`. -->
<!-- Do not edit by hand; the source of truth is skills/iam-best-practices/SKILL.md. -->

# Identity & Access Management Best Practices

Least-privilege cloud IAM: policy scope, privilege-escalation paths, permissions boundaries, workload identity over static keys, MFA enforced by policy, cross-account trust, and separating deploy from runtime. Use when generating IAM policies, roles, or trust documents, wiring CI/CD service accounts or workload identities, delegating role creation, or designing cross-account access.

## ALWAYS

- Grant the minimum permissions the workload's stated job requires: deny by default, then add concrete actions against concrete resources. A wildcard action on a wildcard resource — in a custom policy, in `AdministratorAccess`, or in `iam:*` attached to something that runs continuously — is the same finding wearing three different names.
- Read a policy for the **privileges it can reach**, not only the ones it names. A principal that can write policy (`iam:PutRolePolicy`, `iam:AttachRolePolicy`, `iam:CreatePolicyVersion`) can grant itself anything, and a principal that can pass a role into a compute service it may also create (`iam:PassRole` with `lambda:CreateFunction`, `ec2:RunInstances`, `glue:CreateJob`) inherits that role's privileges. These read as narrow grants and are administrative ones. `references/escalation-paths.md` lists the combinations worth failing a review over.
- Bound delegated permissions with a **permissions boundary** or an organization-level policy (SCP, GCP org policy, Azure management-group policy) when teams may create their own roles. The boundary caps what any role they create can do, which is what makes self-service role creation safe rather than a privilege-escalation primitive.
- Prefer **workload identity** — IRSA on EKS, GKE Workload Identity, Azure Managed Identity, OIDC federation from CI — over a static key. The goal is that no long-lived credential exists to leak. Where one is genuinely unavoidable, give it a documented rotation cadence and automatic disablement on inactivity, and treat that as a temporary state rather than the steady state.
- Enforce MFA for human principals through a **policy condition** (`aws:MultiFactorAuthPresent`), not only a directory setting, so a credential that bypasses the directory still cannot act.

<!-- Native skill bundle for agent-skills (cross-tool convention). Generated by `secure-vibe dev regenerate`. -->
<!-- Do not edit by hand; the source of truth is skills/llm-app-security/SKILL.md. -->

# LLM Application Security

Securing a feature that calls an LLM: prompt injection as an unsolved input problem, bounding what model output is allowed to reach, tool authorization against the human rather than the model, approval gates on consequential actions, RAG context provenance, system-prompt leakage, and cost limits. Use when sending prompts to an LLM API, building a RAG pipeline, giving a model tools, rendering or executing model output, or exposing an LLM-backed endpoint.

## ALWAYS

- Start from the premise that **prompt injection is not solved at the prompt layer**. A model has no privileged channel: system text, user text, a retrieved document and a tool result all arrive as one context, and nothing in that context can be marked as instructions the model must obey over the rest. Message roles are a formatting convention, delimiters raise the cost of an attack, and an instruction such as "treat the following as data" is itself just more text in the same window. Design as though injection will sometimes succeed, and put the real controls after the model rather than in front of it.
- Bound what the model's output is **allowed to reach**. Every downstream sink — a query builder, a shell, a file writer, an HTTP client, a renderer — must validate model output exactly as it would validate a request body from the internet, because that is what it is once injection is assumed. `secure-code-review`, `database-security` and `frontend-security` own the individual sinks; what belongs here is that model output never arrives pre-trusted.
- Constrain the output's **shape** with structured generation — a JSON Schema, function-call mode, constrained decoding — whenever the next step consumes it programmatically, and reject anything that fails validation rather than repairing it. A schema bounds the form, not the intent: a well-formed field can still carry a hostile value, so validate the value too.
- Authorize each tool call against the **human user's** permissions, checked at call time, not against what the model was told it may do. The tool allowlist is a capability list, not an authorization decision — and the agent's own privileges are the attack surface, because injected content drives the agent that holds them. Keep the agent's identity narrow for the same reason `iam-best-practices` keeps a pipeline role narrow.
- Put a **human approval gate** in front of consequential and irreversible actions: moving money, deleting or overwriting data, sending messages on a user's behalf, publishing, changing permissions. Injection that reaches a read-only tool is an information problem; injection that reaches a write tool is an incident. The gate is what keeps a single injected instruction from being final.

<!-- Native skill bundle for agent-skills (cross-tool convention). Generated by `secure-vibe dev regenerate`. -->
<!-- Do not edit by hand; the source of truth is skills/logging-security/SKILL.md. -->

# Logging Security

Keep secrets and personal data out of logs at the call site rather than relying on redaction, neutralize log and field injection, record audit events that survive, and treat log read access as data access. Use when generating logger calls or structured-logging schemas, wiring log shippers, sinks, retention, and access controls, or specifying audit-logging requirements.

## ALWAYS

- Decide what is safe to log **at the call site**, and log a reference rather than a value: an id, a hash, a type, a count. A redactor is the last net, not the design — it matches field names and known patterns, so it cannot see personal data sitting inside an assembled string. A formatted notification body, a templated message, an exception with interpolated arguments: the name and the address are in the prose, in no named field, matching no pattern. Nothing downstream will catch that.
- Run a **redactor** at the sink anyway, for the cases the call site missed: credential-shaped values, `Authorization` and `Cookie` headers, query strings carrying tokens, and the personal-data patterns in `rules/redaction_patterns.json`. `secret-detection` owns which literals count as a credential; this rule is that the redactor exists and runs before anything leaves the process.
- Log in a **structured format** (JSON or logfmt) with stable field names — `timestamp`, `service`, `version`, `level`, `trace_id`, `span_id`, `request_id`, `event`, and `user_id` when there is an authenticated one. Structure is what makes redaction, retention, and access control expressible per field instead of per line.
- Neutralize user-controlled strings before they enter a log record. Line injection (CWE-117) is the classic case — a `\n` or `\r` lets an attacker forge a whole record — but structured logging moves the problem: a value that parses as JSON can inject *fields* into the ingested document, and ANSI escape sequences (`\x1b[`) are interpreted by the terminal of whoever reads the log. Encode the value; do not concatenate it into the line.
- Record security-relevant events as **immutable audit records**: authentication success and failure, MFA challenges, password and role changes, permission grants and revocations, data export, administrative action. These carry longer retention and stricter access than operational logs, and they are the reason failed logins must keep being written even when someone calls them noise.

<!-- Native skill bundle for agent-skills (cross-tool convention). Generated by `secure-vibe dev regenerate`. -->
<!-- Do not edit by hand; the source of truth is skills/ml-security/SKILL.md. -->

# ML Model Security

The model and data artifacts: checkpoint formats that execute code on load, provenance for a model you did not train, training-data poisoning and the ingestion controls that bound it, PII that survives into weights, and notebooks that commit their own output. Use when loading a model from disk, a Hub, or object storage, ingesting user content for training or fine-tuning, or writing training, evaluation, or notebook code.

## ALWAYS

- Prefer a **tensor-only format** — safetensors — for anything you load. It stores arrays and metadata and has no mechanism for executing code, which is the property that matters. A `.pt`, `.pkl`, `.bin`, `.ckpt` or `joblib` artifact is a pickle: loading it runs whatever the author put in it, before you see a single weight.
- Pass `weights_only=True` to `torch.load` **explicitly**, every time. The default has changed across PyTorch releases, so code that relies on it behaves differently depending on the pin — and the flag narrows the surface without removing it, so it is a mitigation rather than a reason to load an untrusted file. `deserialization-security` owns the pickle boundary itself and the per-language detail; `references/artifacts-and-provenance.md` has the format-by-format table.
- Establish provenance before loading: the artifact's **hash matches one you recorded** from a source you decided to trust, at a revision you pinned. A hash the artifact came with proves only that the file is the file. `supply-chain-security` owns what makes a source trustworthy, and its rule holds here — a checksum served next to the download is not authentication, and an author's name is not a signature.
- Pin the Hub revision to an **immutable commit**, not a branch or tag. `main` moves, and `from_pretrained(..., revision="<sha>")` is the difference between a model you reviewed and whatever is there today. Where the loader offers `trust_remote_code`, understand that enabling it executes repository Python at load time, which is the same exposure as the pickle it was meant to avoid.
- Bound what user-contributed data can do to a model. Attribute each training record to its source, keep contributed data in a separate pool from curated data, gate promotion between them on review, and cap how much any single contributor can influence one training run. Poisoning does not need many records — it needs enough of them near one behaviour.

<!-- Native skill bundle for agent-skills (cross-tool convention). Generated by `secure-vibe dev regenerate`. -->
<!-- Do not edit by hand; the source of truth is skills/mobile-security/SKILL.md. -->

# Mobile Application Security

Android and iOS hardening on a device you do not control: hardware-backed credential storage, exported components and IPC, verified deep links, transport defaults and pinning rotation, server-side attestation over client-side root detection, screen capture, and release-build hygiene — including React Native and Flutter packaging. Use when generating Android or iOS app code, manifests, or native modules, wiring deep links or WebViews, or deciding what a mobile client is trusted to assert.

## ALWAYS

- Start from the premise that **the device belongs to whoever is holding it**. The app runs on hardware an attacker can root or jailbreak, instrument at runtime, and read at rest. Everything shipped in the package is extractable, every client-side check is removable, and every local check can be made to return the answer the attacker wants. What you actually control is the backend's willingness to act — so any decision that matters is made server-side, on evidence the server verified.
- Issue short-lived, device-scoped tokens from a backend rather than shipping an API key, signing key, or backend credential in source, resources, `strings.xml`, `BuildConfig`, or `Info.plist`. Anyone can download the package and read it.
- Keep credentials in the platform's hardware-backed store: Android Keystore (`EncryptedSharedPreferences` with a `MasterKey`), iOS Keychain with a `…ThisDeviceOnly` accessibility class — `WhenUnlocked` where the value is never needed in the background, `AfterFirstUnlock` where it is. Never `SharedPreferences`, `UserDefaults`, a plist, or a file. The store protects a key at rest on an uncompromised device; it does not protect against code running inside your process, which is why the credential should be short-lived regardless.
- **Android**: give every `<activity>`, `<service>`, `<receiver>` and `<provider>` an explicit `android:exported`, defaulting to `false`. Since API 31 the attribute is mandatory when an intent filter is present — which forces the question to be asked, not answered. An exported component is a public API of your app that any installed application can call.
- Treat data crossing an app boundary as untrusted in both directions: validate every `Intent` extra and incoming activity payload, send sensitive data with an explicit component rather than an implicit intent any app can register for, and create every `PendingIntent` as `FLAG_IMMUTABLE` so the recipient cannot rewrite its contents.

<!-- Native skill bundle for agent-skills (cross-tool convention). Generated by `secure-vibe dev regenerate`. -->
<!-- Do not edit by hand; the source of truth is skills/protocol-security/SKILL.md. -->

# Protocol Security

Transport security where the client establishes trust: TLS version floor, certificate chain and hostname verification, the trust store, connecting by IP, mTLS and workload identity as authentication, gRPC channel credentials, and SMTP STARTTLS. Use when generating HTTP, gRPC, or SMTP clients and servers, configuring TLS in code or platform config, wiring service-to-service authentication, or when tempted to disable certificate verification.

## ALWAYS

- Default to **TLS 1.3**, and permit TLS 1.2 only where a peer genuinely requires it. Disable TLS 1.0, 1.1, and every SSL version. Cipher-suite selection is a consequence of the version floor rather than a separate decision — `references/tls-configuration.md` carries the suite lists and the per-platform config keys.
- Verify the full certificate chain on every connection: a trusted issuer, an unexpired validity window, and a hostname that matches a **`subjectAltName` dNSName** entry. The hostname is checked *against* the SAN — SAN is not an alternative place to look, and a `CN` match is not a fallback, because current browsers and TLS libraries removed CN as a hostname source.
- When connecting to an **IP address** rather than a name, set the expected name explicitly (`ServerName` in Go's `tls.Config`, the equivalent SNI/verification hostname elsewhere) so verification has something to check, or require a certificate carrying an `iPAddress` SAN. Reaching an endpoint by IP is the single most common reason a developer disables verification — this is the fix that keeps it on.
- Resolve a self-signed or internal-CA endpoint by **adding that CA to the client's trust configuration**, not by turning verification off. Every language has a way to supply a custom root pool; using it keeps hostname and expiry checks intact, which is exactly what the shortcut discards.
- Use **mutual TLS** for service-to-service traffic inside a trust domain, and treat it as what it is: a cryptographic caller identity, which *is* authentication — unlike network position, which is not. A SPIFFE workload identity (`spiffe://trust-domain/...`) with short-lived certificates is the form of this worth reaching for over a long-lived shared API key.

<!-- Native skill bundle for agent-skills (cross-tool convention). Generated by `secure-vibe dev regenerate`. -->
<!-- Do not edit by hand; the source of truth is skills/saas-security/SKILL.md. -->

# SaaS Integration Security

Wiring your application to a third-party SaaS platform: verifying an inbound webhook against the vendor's own scheme rather than a generalized one, why a valid signature identifies the sender and not the user in the payload, replay windows, one credential per integration and per environment, least-privilege scopes, and treating a bulk export as a data boundary. Use when writing a webhook receiver, an OAuth integration, a SCIM endpoint, or any code that authenticates to or from a SaaS vendor.

## ALWAYS

- Verify an inbound webhook against **that vendor's documented scheme**, and do not generalize from another one. Vendors differ in the header, in the secret, and — the part that breaks a generalized implementation — in the **canonical string** that gets signed. Some sign the raw body, some sign a version prefix plus a timestamp plus the body, some sign the HTTP method and path as well. Read the vendor's page for the vendor you are integrating; a signature routine copied from a different vendor produces a receiver that rejects every legitimate event, and the fix someone reaches for is to turn verification off.
- Verify against the **raw request body**, exactly as received, before any parsing or re-serialization. A framework that decodes JSON and re-encodes it changes whitespace and key order, and the HMAC no longer matches — which again ends with verification being disabled rather than fixed.
- Check the **timestamp** the vendor sends and reject requests outside a short window, then reject **replays** inside it by recording delivery or event ids. A signature is valid forever; the window narrows the replay opportunity and the id store closes it.
- Compare signatures in **constant time**. `crypto-misuse` owns the comparison API for each language.
- Treat the signature as proof of **who sent the payload, not who the payload is about**. This is the distinction that matters most in this domain: a verified Zoom or Calendly or HubSpot event genuinely came from that vendor, and the `email`, `from`, or custom fields inside it may still be attacker-chosen — anyone who can book a meeting or submit a form controls them. Resolve the subject to a canonical id server-side. `auth-security` owns the general rule for producer-asserted identity.

<!-- Native skill bundle for agent-skills (cross-tool convention). Generated by `secure-vibe dev regenerate`. -->
<!-- Do not edit by hand; the source of truth is skills/secret-detection/SKILL.md. -->

# Secret Detection

Keeping credentials out of source, and what to do once one is in: rotate before removing, because deleting the line does not un-leak it. Covers where a secret may live, safe .env templates, why a client-reachable config value is public, and running a scanner rather than eyeballing for patterns. Use when writing code that reads a credential, creating config or .env templates, before committing, or after discovering a secret in a repository.

## ALWAYS

- On finding a committed credential, **rotate or revoke it at the provider first**. Deleting the line does not remediate it, and neither does `git rm`, an amended commit, or a history rewrite: the value reached a remote, a clone, a fork, a CI log and a backup, and it is compromised from the moment it was pushed. Rotate, then clean the history, then add the guard that stops it recurring — in that order, because only the first one is time-critical.
- **Run a scanner**; do not scan by eye. `scan_secrets` and `check_secret_pattern` carry the full pattern set with per-pattern entropy floors and hotword proximity, and a person reading a diff matches none of that reliably. A working-tree scan and a history scan answer different questions — the first says what you are about to commit, the second says what is already public.
- Read the credential from the environment or a secret manager at the point of use — `os.environ`, `process.env`, `os.Getenv`, a Vault / AWS Secrets Manager / GCP Secret Manager / 1Password client. Nothing about the value should be reconstructible from the repository.
- Ship a **`.env.example`** that is committed and contains every key with an empty or obviously-fake value, alongside a `.env` that is ignored and never committed. The example file is documentation, so it must never be produced by copying a working `.env` and editing it — that is how a real value survives into the template.
- Ignore the file classes that carry key material, in one list: `.env`, `.env.*` (but not `.env.example`), `*.pem`, `*.key`, `*.p12`, `*.pfx`, `*.ppk`, `id_rsa*`, `id_dsa*`, `id_ecdsa*`, `id_ed25519*`, `*credentials*`, `*secret*`. A `.gitignore` entry is a guard against habit, not a control — it does nothing for a file already tracked, and `git add -f` overrides it.

<!-- Native skill bundle for agent-skills (cross-tool convention). Generated by `secure-vibe dev regenerate`. -->
<!-- Do not edit by hand; the source of truth is skills/secure-code-review/SKILL.md. -->

# Secure Code Review

The sinks and boundaries that belong to no framework: passing input to a shell or an evaluator, letting input choose a filesystem path, validating at a boundary that is not an HTTP request, and handling regulated data (PII, PHI, cardholder data) so it does not spread into paths nobody reviews. Use when generating or reviewing code that shells out, touches the filesystem, reads a queue message, CLI argument, or parsed file, or when a change crosses a PII, PHI, or PCI boundary.

## ALWAYS

- Validate input at **every** trust boundary, not only the HTTP one. A CLI argument, an environment variable, a queue message, a filename, a parsed config or spreadsheet cell all arrive from outside and none of them pass through the request-validation layer. Check type, length, allowed characters and allowed range, and reject before processing. `api-security` owns the HTTP request body and its schema; this rule is every other way input gets in.
- Build a command as an **argument vector**, never as a string a shell will parse: `subprocess.run([...])` without `shell=True`, `execFile`/`spawn` with an array, `exec.Command(name, args...)`. Passing an array is what removes the shell, and removing the shell is what removes the injection — quoting and escaping are the fallback for when you cannot.
- **Canonicalize then check** any path built from input: resolve it to an absolute real path, then confirm it is inside the intended directory. Checking the raw string first misses `..`, symlinks, absolute-path replacement, and encoded separators. `file-upload-security` owns stored uploads and archive extraction; this rule covers a static-file handler, a template loader, a log path, an export filename.
- Tag any function or module handling **PII, PHI or cardholder data** with an explicit classification comment (`// classification: PII`), and keep that handling in clearly-named modules rather than in general utility code. An untagged helper is how regulated data spreads into paths nobody reviews for it, and the tag is what makes the later review possible.
- Consult the owner for anything with one: `database-security` when code builds a query, `crypto-misuse` when it hashes, encrypts, signs or compares a secret, `frontend-security` for output encoding and response headers, `auth-security` for who the caller is, `iam-best-practices` for the privileges a process runs with. Each of those states its rule with the API names and the false positives this skill would have to leave out.

<!-- Native skill bundle for agent-skills (cross-tool convention). Generated by `secure-vibe dev regenerate`. -->
<!-- Do not edit by hand; the source of truth is skills/security-regression-tests/SKILL.md. -->

# Security Regression Tests

Turning a confirmed and fixed finding into a permanent guard: proving the test fails without the fix, asserting the effect and not only the status code, seeding the two principals an authorization test needs, making a timing or out-of-band proof deterministic enough for CI, and keeping the test in a job that can actually block. Use once a security finding has been confirmed and fixed, or when a security test is failing, skipped, or about to be deleted.

## ALWAYS

- **Prove the test fails without the fix.** Revert the patch, or mutate the guard, and confirm the new test goes red — then restore. A test written after the fix can be vacuously green: wrong route, wrong fixture user, wrong assertion target, a typo in the payload. It will stay green forever and nobody will learn anything from it. This is the one step that distinguishes a guard from a decoration, and it is the one most often skipped.
- Assert **both directions**: the attack input now yields the secure outcome, *and* a legitimate input still succeeds. A deny-only test passes equally well against an endpoint that is broken for everyone, so it will hold the line and tell you nothing when someone disables the feature entirely.
- Assert the **effect**, not only the status code. A `403` proves the request was refused; it does not prove the write did not land somewhere else, that the record was not returned in a different shape, or that a queue message was not emitted. Check the state the attack was trying to reach.
- Seed the **fixtures the assertion depends on** before writing it. A cross-tenant test needs two principals and two owned resources, deterministically created — if both test users end up in the same tenant, the deny assertion is untestable and passes for the wrong reason.
- Make it **deterministic and offline**. Freeze the clock for expiry and TTL assertions, stub the HTTP client, dialer or resolver rather than reaching the network, fix random seeds, and avoid sleep-based timing assertions and state shared between tests. Note that a canonical SSRF payload such as `http://169.254.169.254/latest/meta-data/` is a *live, reachable* address on a cloud CI runner, so the naive test both leaves the sandbox and returns a different verdict on a laptop.

<!-- Native skill bundle for agent-skills (cross-tool convention). Generated by `secure-vibe dev regenerate`. -->
<!-- Do not edit by hand; the source of truth is skills/serverless-security/SKILL.md. -->

# Serverless Security

What a function-as-a-service platform changes: an execution environment reused between invocations so /tmp and module globals outlive a request, an event envelope that is attacker-influenced whichever trigger delivered it, encrypted-at-rest configuration that the control-plane API still returns in cleartext, and concurrency as the boundary between an incident and a bill. Use when generating Lambda, Cloud Functions, or Azure Functions code, serverless.yml or SAM templates, or wiring API Gateway, EventBridge, SQS, or S3 triggers.

## ALWAYS

- Treat the **execution environment as reused**. The platform freezes it when the handler returns and thaws it for the next invocation, which may serve a different tenant. So a module-level global holding per-request state — a decrypted payload, an authorization decision, a tenant id, a connection bound to one caller's credentials — is visible to the next request. Cache only what is safe to share, and reset or scope everything else inside the handler.
- Treat **`/tmp` as shared, persistent, and finite**. It is the only writable path, it survives across invocations in the same environment, and a fixed filename written for one user is readable by the next. Use a per-invocation subdirectory, delete it before returning, and never read back a path without having written it in the same invocation.
- Validate the **whole event, envelope included**. The trigger's identity is not authentication: an S3 object key is chosen by whoever can PUT to the bucket, SQS message attributes and EventBridge `detail` are producer-supplied, and an API Gateway authorizer context is only as trustworthy as the authorizer. Validate against an explicit schema before any code touches the payload, and where a function has more than one trigger, check the source discriminant and route by allowlist.
- Give each function its **own execution role** with only the permissions its stated job needs. `iam-best-practices` owns policy scope and the escalation paths; what is serverless-specific is one role per function, never shared, because a shared role gives every function the union of what any of them needs.
- Set concurrency deliberately, and know which control you are reaching for. **Reserved** concurrency caps a function's parallel executions and is the denial-of-wallet control; **provisioned** concurrency pre-initialises environments to remove cold starts and *bills for them whether or not they are used*. Reserved capacity is also drawn from a shared account pool, so setting it per function is a decision about the account, not just that function.

<!-- Native skill bundle for agent-skills (cross-tool convention). Generated by `secure-vibe dev regenerate`. -->
<!-- Do not edit by hand; the source of truth is skills/ssrf-prevention/SKILL.md. -->

# SSRF Prevention

Server-Side Request Forgery: allowlisting the destination of a server-side fetch, when re-resolution between check and connect matters, redirect and scheme bypasses, parsers that fetch on their own (XXE, SVG, HTML-to-PDF), cloud metadata, and keeping the response from becoming an oracle. Use when fetching a client-supplied URL, wiring webhooks, image proxies, PDF or preview renderers, or reviewing any HTTP-client wrapper.

## ALWAYS

- Constrain the destination with an **allowlist of hosts you intend to reach**, not a denylist of addresses you intend to avoid. A denylist has to enumerate every spelling of every internal address — decimal and octal IPv4, IPv6 and IPv4-mapped IPv6, a hostname whose A record is private, a public wildcard resolver like `nip.io` that encodes any address into a name — and it only has to be wrong once.
- Know which of the two controls you built, because it decides whether re-resolution matters. An **allowlist of hostnames** survives DNS rebinding: the attacker controls DNS only for names they own, and those names are not on the list. An **IP-range check** does not: the name resolves to a public address when you validate and a private one when you connect, and the two resolutions are independent. If your control is address-based, resolve once and **connect to that pinned address** — a custom dialer or transport, carrying the original hostname for SNI and `Host` — so no second lookup can occur.
- Re-validate **at every redirect hop**, or disable redirect-following entirely on fetchers that take user-supplied URLs. An allowed host answering `302` to `http://169.254.169.254/` is the single most common bypass, and it defeats a check performed only on the URL the user submitted.
- Restrict the scheme to `http` and `https` before anything else. `file://`, `gopher://`, `dict://`, `ldap://`, `jar://` and friends turn a fetcher into a file reader or a protocol-smuggling primitive.
- Keep the **user-URL fetcher and the internal fetcher as separate clients**, and make mixing them fail to compile rather than fail at runtime — distinct types in Go, Rust or TypeScript. A single client used for both eventually gets called with the wrong argument.

<!-- Native skill bundle for agent-skills (cross-tool convention). Generated by `secure-vibe dev regenerate`. -->
<!-- Do not edit by hand; the source of truth is skills/supply-chain-security/SKILL.md. -->

# Supply Chain Security

Vet dependencies before they enter the build: typosquats, dependency confusion, malicious packages, known vulnerabilities, unlocked resolution, risky install and build hooks, EOL embedded runtimes, and the authenticity and freshness of your own release channel. Use when adding or upgrading a dependency, reviewing package manifests or lockfiles, configuring package sources or internal namespaces, or publishing a package or application update.

## ALWAYS

- Verify the identity of a new dependency before adding it: registry metadata, repository URL, maintainer set, and provenance checked against the signer you *expect*. Name-similarity screening opens the question; it never answers it.
- Query the bundled malicious-package data before adding any dependency — `check_dependency`, `check_typosquat` and `lookup_vulnerability` read it, this file cannot. Match on ecosystem, normalized name **and affected version range**; an active match on the resolved version blocks.
- Treat package age, download volume, maintainer count and activity as risk signals, never as proof of trust. Defaults: a verified maintainer signal within 90 days of a package identity's first publication, plus a documented reason within 30 days.
- Lock the resolution graph for anything you deploy — commit the lockfile, install frozen in CI (`npm ci`, `--frozen-lockfile`, `pip --require-hashes`, `cargo --locked`). Lock what you deploy, range what you publish: a library's dependency metadata needs compatibility ranges.
- Restrict where packages resolve from, so an internal-only identifier cannot come from a public registry. Use the ecosystem's own mechanism — npm scope-to-registry, Gradle `exclusiveContent`, a single authoritative index for Python, which has no scope isolation at all.

<!-- Native skill bundle for agent-skills (cross-tool convention). Generated by `secure-vibe dev regenerate`. -->
<!-- Do not edit by hand; the source of truth is skills/template-injection/SKILL.md. -->

# Template Injection (SSTI)

User input reaching a template compiler rather than its context: the source-versus-values distinction, double-render pipelines, template names chosen by the caller, why a template sandbox is a mitigation and not a boundary, minimizing what the render context exposes, and template-driven resource exhaustion. Use when rendering templates with user-influenced values, when a template string or template name is assembled from input, or when a product lets users author templates.

## ALWAYS

- Pass user data as **bound values**, never into the template **source** string. This is the whole skill in one line: `render(tmpl, {"name": name})` is safe, `render("Hello " + name)` is SSTI. The compiler treats its source as code, and the context as data — so the only question that matters about any user value is which of the two it reaches.
- Keep the set of template sources **static and trusted**, loaded from files or constants. A template body read from a database column, an API response, or a request field is attacker-supplied code, whatever the column is called.
- Choose the template **by name from an allowlist**, never by a name the caller supplies. `render_template(user_value)` and `{% include user_value %}` are the same vulnerability as a user-supplied body: the caller picks which code runs, and on many engines the name resolves as a filesystem path, which makes it an arbitrary-file read as well.
- **Minimize the render context.** Pass the specific values the template needs, never the ambient objects — application config, settings, the request, `self`, a module, a live ORM instance. This is the control that still holds when a sandbox is escaped: an engine that cannot execute code can still print whatever it can reach, and configuration objects hold database URLs and signing keys.
- Treat a **second render pass** as compilation of whatever survived the first. If rendered output is parsed again, a user value that was inert data on pass one is `{{ }}` code on pass two. The fix is architectural — stop re-parsing rendered output. Neutralizing metacharacters before the second pass is a fallback that has to enumerate every delimiter of every engine, including ones a custom delimiter configuration introduces, and two adjacent fields can produce a delimiter that neither of them contains.

<!-- Native skill bundle for agent-skills (cross-tool convention). Generated by `secure-vibe dev regenerate`. -->
<!-- Do not edit by hand; the source of truth is skills/threat-modeling/SKILL.md. -->

# Threat Modeling

Decide what a design must be true before code exists: naming assets and actors, locating trust boundaries, producing a written (asset, boundary, threat, control, owner) list, recording the assumptions the design rests on, and knowing when a change invalidates the model. Use when scaffolding a new feature, service, or endpoint, writing or reviewing a design doc, RFC, or ADR, or introducing a new trust boundary, integration, or data flow.

## ALWAYS

- Produce a **written list**, not an impression. One row per finding, in the design doc, the RFC, or the PR description: `(asset, boundary, threat, control, owner)` — what is worth taking, where it crosses, what could go wrong there, what stops it, and which component enforces it. A model that exists only in the reasoning that produced the code cannot be reviewed, disagreed with, or checked later.
- Name the **assets** and the **actors** first: data, funds, credentials, keys and compute on one side; users, tenants, services, admins and the attacker on the other. Every later row references one of each, which is what makes the list finite.
- Locate the **trust boundaries** — internet to application, tenant to shared store, service to service, user input to an interpreter, model output to anything that acts on it. A boundary is where data arrives from a party you do not control, and it is the unit the rest of the model is organised around.
- At each boundary, ask the six **STRIDE** questions and write down only the answers that matter: can the caller be **spoofed** (is there authentication), can the data be **tampered** with in flight, will there be a record if someone **repudiates** the action, what is **disclosed** if this crossing leaks, what happens under **denial of service**, and does anything here allow **elevation of privilege**. A category with no answer is not a gap; a category nobody asked about is.
- Write down the **assumptions the design depends on**: this gateway is the only ingress, this queue's producers are authenticated, this field is already validated upstream, this CDN strips that header. Assumptions are the part of a threat model that later becomes false without anyone noticing, and an unwritten one cannot be rechecked.

<!-- Native skill bundle for agent-skills (cross-tool convention). Generated by `secure-vibe dev regenerate`. -->
<!-- Do not edit by hand; the source of truth is skills/websocket-security/SKILL.md. -->

# WebSocket Security

Securing the WebSocket upgrade and the frames after it: Origin validation against Cross-Site WebSocket Hijacking, authenticating the handshake rather than the first message, the ticket pattern for browsers that cannot set headers, per-frame authorization, and resource limits on a connection that stays open. Use when generating a WebSocket, Socket.IO, SignalR, or Phoenix Channels server, wiring real-time messaging, presence, or collaborative editing, or reviewing a /ws endpoint.

## ALWAYS

- Validate the **`Origin` header** on the upgrade handshake against an allowlist, and understand precisely what that buys: the browser sets `Origin` and script cannot forge it, so the check stops **Cross-Site WebSocket Hijacking** — a page on `attacker.com` opening `wss://api.example.com/ws` and inheriting the user's cookies. It buys nothing against a non-browser client, which sets any header it likes. Origin is a CSRF control, not authentication. The same-origin policy and CORS preflight do not apply to the upgrade at all, which is why this check must be written by hand.
- Authenticate the **handshake**, not the first frame. Once the upgrade completes the connection exists, has consumed the user's cookie context, and is already a resource the caller controls. A `subscribe` or `auth` message afterwards is too late.
- For a browser client, pick one of two mechanisms, because the browser `WebSocket` constructor **cannot set request headers** — there is no `Authorization` header available to you: 1. **Cookie on the upgrade** plus the `Origin` check above as the CSRF control, or 2. A **single-use ticket**: the authenticated page calls an ordinary HTTP endpoint, receives a short-lived opaque ticket bound to the user and to the intended resource, passes it in the URL, and the server **redeems and invalidates it at handshake time**. A ticket is safe in a URL precisely because replaying it fails.
- Re-authorize **every frame**, both the action and the subject it names. A frame like `{"action":"write","subjectId":"X"}` must be checked against the principal established at handshake — an authenticated socket must never be able to assert an arbitrary subject id per frame. That is per-frame BOLA, and the forged id reaches every consumer downstream of the socket that trusts it. Permissions also change while the connection is open: logout, role change, account lock, token expiry. A socket opened an hour ago carries an authorization decision an hour old.
- Bound the connection: maximum frame and message size, messages per second per connection, concurrent connections per user and per source address, and total connection lifetime after which the client must re-handshake. A WebSocket is an allocation that persists, so every limit HTTP gets per-request must be re-expressed per-connection. Concrete starting values, and the backpressure and heartbeat settings, are in `references/limits-and-handshake.md`.

<!-- Native skill bundle for Claude Code. Generated by `secure-vibe dev regenerate`. -->
<!-- Do not edit by hand; the source of truth is skills/api-security/SKILL.md. -->

# API Security

OWASP API Top 10 for HTTP, GraphQL, and gRPC endpoints: input validation, route rate limiting, mass assignment, response caching, and gateway-versus-service control placement. Use when generating or reviewing HTTP handlers, GraphQL resolvers, gRPC service methods, or any API endpoint change.

## ALWAYS

- Require authentication on every non-public endpoint. Default to authenticated; opt out for genuinely public routes by explicit annotation.
- Consult `auth-security` for **who the caller is and what they may touch**. It owns the credential (algorithm pinning, expiry, lifetime, session, CSRF) and the permission (object-level BOLA/IDOR checks, multi-key routes, streaming subjects, function-level role gating). Any endpoint that reads or writes a resource by id needs it; this skill covers everything else about the endpoint.
- Validate all request inputs against an explicit schema (JSON Schema, Pydantic, Zod, validator/v10 struct tags). Reject early; never propagate untrusted input deeper.
- Enforce rate limits at the route level for authentication endpoints, password reset, and any expensive operation.
- Consult `error-handling-security` for what an error response may carry. It owns the boundary between what crosses to the client and what stays in the log, including presence-of-record disclosure (`User not found` vs `Invalid credentials`).

<!-- Native skill bundle for Claude Code. Generated by `secure-vibe dev regenerate`. -->
<!-- Do not edit by hand; the source of truth is skills/auth-security/SKILL.md. -->

# Authentication & Authorization Security

[Credential-related source omitted]

## ALWAYS

- Authorize at the **object level** — confirm the authenticated subject actually has access to the requested resource ID, not just that they are logged in. Being signed in is not permission to read record 4,182 (OWASP API1 — BOLA / IDOR).
- Bind object-level authorization to the **authenticated principal**, never to an actor id echoed in the request: checking that a request-supplied `senderId`/`ownerId`/`actedBy` is a valid member validates the *claimed* actor, not the caller (looks like authorization, isn't).
- On `/{scopeId}/.../{subjectId}` routes, authorize the **relationship** — confirm the subject belongs to that scope. A caller-vs-scope check alone does not authorize the subject (multi-key BOLA).
- Authorize **each subject on streaming responses** (SSE/chunked/WebSocket): the `200` is committed before the handler runs, so an empty/filtered stream — not a `4xx` — is the deny signal; an unauthorized subject gets zero events.
- Enforce a **function-level role / privilege check** on any write that publishes into a shared or global namespace (a global gallery, shared catalog, public template list). Authentication is not authorization (OWASP API5 — Broken Function Level Authorization); a low-privilege user posting into a globally-visible store is a delivery vector for stored-XSS and malicious-link chains.

<!-- Native skill bundle for Claude Code. Generated by `secure-vibe dev regenerate`. -->
<!-- Do not edit by hand; the source of truth is skills/cicd-security/SKILL.md. -->

# CI/CD Pipeline Security

Harden GitHub Actions, GitLab CI, and similar pipelines against supply-chain attacks, secret exfiltration, and pwn-request abuse. Use when authoring or reviewing workflow files, adding a third-party action, image, or script, wiring cloud or registry credentials into CI, or triaging a suspected pipeline compromise.

## ALWAYS

- Pin every third-party GitHub Action by **commit SHA** (full 40-char), never by a floating tag (`@v1`, `@main`, `@latest`) — tags can be re-pushed. The tj-actions/changed-files March 2025 incident exfiltrated secrets from 23,000+ repositories specifically because consumers used floating tags. Same applies to GitLab CI `include:` references and reusable workflows. Renovate / Dependabot can keep the SHA pins fresh.
[Credential-related source omitted]
[Credential-related source omitted]
- Treat `pull_request_target`, `workflow_run`, and any `pull_request` job that uses `actions/checkout` with `ref: ${{ github.event.pull_request.head.ref }}` as **trusted-context-on-untrusted-code** — the "pwn request" pattern documented by GitHub Security Lab. Either don't run them, or run with no secrets and no write tokens. A fork's GitLab merge-request pipeline is the same shape — it runs the fork's own `.gitlab-ci.yml` on your runners: isolate them, expose no protected variables.
- Echo every untrusted expression (`${{ github.event.* }}`) through an environment variable first; never interpolate it directly into `run:` body — that's the canonical GitHub Actions script-injection sink. The GitLab sink has the same shape: `$CI_*` / `$TRIGGER_*` interpolated into `bash -c` or `eval`, where merge-request metadata carries the shell metacharacters.

<!-- Native skill bundle for Claude Code. Generated by `secure-vibe dev regenerate`. -->
<!-- Do not edit by hand; the source of truth is skills/container-security/SKILL.md. -->

# Container Security

Hardening for Dockerfiles, OCI images, Kubernetes manifests, and Helm charts. Use when generating a Dockerfile or image build, writing Kubernetes, Helm, or Kustomize manifests, or reviewing container changes in a pull request.

## ALWAYS

- Use **multi-stage builds**: separate builder/test stages from the final runtime image so build toolchains and source aren't shipped. The last stage should be a minimal base — `gcr.io/distroless/<variant>`, `scratch`, or a versioned `-slim` / `-alpine` variant — pinned by SHA256 digest, not just tag. Two bases have nothing to pin: `scratch`, and a reference to an earlier stage in the same file (`FROM base`), which is pinned on that stage's own `FROM` line.
- Run as a non-root user: set `USER` explicitly on the **final stage**, as a **number** not a name. Omitting it leaves the container running as root. K8s `runAsNonRoot` rejects UID 0 and cannot resolve a username, so `USER appuser` fails at startup with "image has non-numeric user"; any non-zero UID passes, and 10000+ by convention also avoids colliding with host accounts.
- Use **`npm ci`** (and equivalents `pnpm install --frozen-lockfile`, `yarn install --frozen-lockfile`) in container builds, not `npm install`. `npm install` mutates the lockfile and resolves versions per-build, producing non-deterministic images that drift from the lockfile.
- Add a `.dockerignore` excluding `.git`, `node_modules`, `.env`, `*.pem`, `*.key`, `target/`, `.terraform/`, `dist/`, `coverage/`.
- Build with **BuildKit** (default since Docker Engine 23; `DOCKER_BUILDKIT=1` on older engines) so `RUN --mount=type=secret,id=<name>` is available for build-time credentials. `# syntax=docker/dockerfile:1` selects the frontend and does **not** enable BuildKit by itself.

<!-- Native skill bundle for Claude Code. Generated by `secure-vibe dev regenerate`. -->
<!-- Do not edit by hand; the source of truth is skills/cors-security/SKILL.md. -->

# CORS Security

Strict CORS: no wildcard with credentials, exact-match origin allowlists, sane preflight cache, minimal exposed headers. Use when generating CORS middleware or framework config, setting CORS headers in API Gateway, CloudFront, or Nginx, or reviewing a cross-origin browser-facing endpoint.

## ALWAYS

- For any non-public endpoint, allow origins from an explicit allowlist. `*` is correct only when the resource is intentionally public *and* cross-origin access never carries credentials.
- When a cross-origin request carries credentials — the browser's credentials mode is `include`, meaning cookies, TLS client certificates, or browser-managed HTTP auth — respond with `Access-Control-Allow-Credentials: true` and a **single explicit origin**. On a credentialed request every CORS header loses its wildcard meaning: `*` in `Allow-Origin`, `Allow-Methods`, `Allow-Headers`, or `Expose-Headers` is read as the literal string `"*"` and the browser blocks the response. That is why "just set it to `*` for now" fails in a way that is hard to debug.
- Compare origins by exact match on the **serialized** origin — scheme, host, and port, all three. Never substring, prefix, or suffix matching: `endsWith("example.com")` accepts `https://example.com.evil.com`, and an unescaped `.` in `^https://api.example.com$` accepts `https://apiXexample.com`.
- Include `Vary: Origin` on any response whose headers depend on the request `Origin`, so a shared cache cannot hand one origin's `Access-Control-Allow-Origin` to another.
[Credential-related source omitted]

<!-- Native skill bundle for Claude Code. Generated by `secure-vibe dev regenerate`. -->
<!-- Do not edit by hand; the source of truth is skills/crypto-misuse/SKILL.md. -->

# Cryptographic Misuse

Block weak ciphers, predictable RNG, undersized keys, fast-hash password storage, nonce reuse, and non-constant-time comparison. Use when generating code that hashes, encrypts, or signs, code that compares secrets, MACs, or tokens, or config for key sizes and randomness.

## ALWAYS

- Use a maintained, widely reviewed cryptographic API — the platform's own (Node `crypto`, Java JCE, .NET `System.Security.Cryptography`, Go `crypto/*`) or a reputable third-party one (PyCA `cryptography`, `golang.org/x/crypto`, Bouncy Castle). Prefer high-level, misuse-resistant APIs over assembling low-level primitives yourself. In Python, `from Crypto…` resolves to either the abandoned `pycrypto` or its maintained fork `pycryptodome` depending on what is installed — the import line is identical, so depend on `pycryptodome` explicitly.
- Use a cryptographically secure RNG for anything security-relevant: Python `secrets.token_bytes` / `secrets.token_urlsafe`, JS `crypto.getRandomValues` / `crypto.randomBytes`, Go `crypto/rand.Read`, Java `SecureRandom`.
- Hash passwords with a password-specific KDF and a unique random salt per password. Prefer Argon2id; scrypt where appropriate; bcrypt for legacy compatibility; PBKDF2-HMAC-SHA-256 where FIPS-140 compliance is required. Take minimum parameters from the current [OWASP Password Storage Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html), then benchmark on production hardware and choose the highest cost that still meets the application's authentication latency and availability budget. The cost is meant to be raised over time as hardware gets cheaper — it is not a constant to copy once.
- Account for bcrypt's 72-byte input limit: it silently truncates, so a long passphrase and its 72-byte prefix hash identically. If bcrypt must take unbounded input, pre-hash with SHA-256 and pass the digest **base64-encoded**, never as raw bytes — a raw digest can contain a NUL byte, which truncates the input again.
- Encrypt with a vetted AEAD: AES-GCM or ChaCha20-Poly1305, or AES-GCM-SIV where nonce-misuse resistance is specifically useful and the platform ships a reviewed implementation. Absent a stated key-size requirement, AES-256-GCM or ChaCha20-Poly1305 is a safe default — AES-128-GCM is not a finding.

<!-- Native skill bundle for Claude Code. Generated by `secure-vibe dev regenerate`. -->
<!-- Do not edit by hand; the source of truth is skills/database-security/SKILL.md. -->

# Database Security

Prevent SQL and NoSQL injection, unsafe ORM and raw-query use, over-privileged database identities, weak tenant isolation, and unauthenticated database transport. Use when generating SQL or raw query strings, NoSQL filters, ORM models or queries, database migration files, or connection strings.

## ALWAYS

- Bind every untrusted data value through the driver or ORM parameter API. Never place it into SQL with language-level interpolation or concatenation — `+`, f-strings, `%` formatting, `.format()`, JavaScript template interpolation. Driver placeholders (`%s`, `?`, `$1`, `:name`, `@name`) are the binding *mechanism*, not string formatting; confusing the two is how this rule is most often misread. The same applies to values read back out of the database and used to build a later query: stored input is still input, and second-order injection is this bug with a delay.
- Prefer the ORM's structured query-expression API over textual SQL. Where raw SQL is genuinely needed, use that framework's documented parameter-binding mechanism and never interpolate untrusted values into it. `references/orm-safe-query-examples.md` carries the verified form per framework.
- For SQL structure that cannot be a bind parameter — table and column identifiers, sort direction, sometimes the operator itself — map the external value to a fixed operator-controlled allowlist. Never copy an untrusted identifier or SQL fragment into the statement, escaped or not.
- Treat a NoSQL query as a structure, not a string. Build filters with the driver's typed query objects, and coerce every request-supplied value to its expected scalar type before it reaches a filter. A JSON body substituting `{"$ne": null}` where a string was expected turns an equality check into a match-all — operator injection needs no quote to break out of.
- Give each application its own database identity with the minimum grants it needs, and separate runtime privileges from migration privileges. The runtime identity must not receive schema-owner or DDL rights merely because migrations require them.

<!-- Native skill bundle for Claude Code. Generated by `secure-vibe dev regenerate`. -->
<!-- Do not edit by hand; the source of truth is skills/deserialization-security/SKILL.md. -->

# Deserialization Security

Block unsafe deserialization and unsafe XML parsing in Java, Python, .NET, PHP, and Ruby: gadget chains, unrestricted type resolution, external entity expansion, and safer formats. Use when parsing or deserializing data from an untrusted source, wiring cookies, sessions, queues, or RPC payloads, or reviewing pickle, unserialize, Marshal, ObjectInputStream, BinaryFormatter, or XML parser configuration.

## ALWAYS

- Prefer data-only serialization formats — JSON, Protobuf, MessagePack with an explicit type map — over formats that reconstruct arbitrary runtime objects. What makes a format safe here is not schema validation; it is whether the parser can instantiate a class the payload names.
- Constrain polymorphic type resolution to an explicit set of expected application types. Never let payload data choose the runtime class — that is the mechanism behind every gadget chain, whichever serializer is involved.
- Treat an object-reconstructing deserializer crossing a trust boundary as high risk: `pickle`, `ObjectInputStream`, `BinaryFormatter`, `unserialize`, `Marshal.load` and their framework equivalents. Adding one to a request-handling path needs explicit review — check the platform reference for the exact API and the version behaviour before accepting or remediating a use.
- Disable external entity resolution and DTD processing on every XML parser that receives untrusted input. A parser that resolves entities is a file-read and server-side request primitive before it is a parser; `ssrf-prevention` owns where the outbound request lands.
- Where serialized state carries a signature or MAC, verify it **before** invoking the deserializer — and treat that as defense in depth, not a licence to keep an unsafe format. `crypto-misuse` owns the signing key, its algorithm and its rotation.

<!-- Native skill bundle for Claude Code. Generated by `secure-vibe dev regenerate`. -->
<!-- Do not edit by hand; the source of truth is skills/dynamic-verification/SKILL.md. -->

# Verify Findings

Confirm or refute a vulnerability candidate against a live target with a deterministic probe, respecting authorization and scope. Use when a SAST or LLM review flags a possible injection or SSRF, when triaging a finding before filing a bug or shipping a fix, or when a verification result turns out wrong.

## ALWAYS

- Treat a static-analysis or LLM-review hit as a *candidate*, not a vulnerability, until a probe with a deterministic oracle confirms it against a live target.
- Prefer an oracle that proves server-side behaviour over one that inspects the response text: out-of-band callbacks (SSRF, blind command injection, XXE) and timing deltas (blind SQLi, command injection) catch *blind* bugs that leave no trace in the body.
- Re-confirm any timing-based result a second time before trusting it — one slow response is noise, a repeatable delay over baseline is signal.
- For reflected oracles (XSS, SSTI), require the dangerous form: XSS confirms only when the payload comes back UNESCAPED; SSTI confirms only when the arithmetic is EVALUATED (the product appears as a standalone number and the raw expression does not).
- Pin file-read oracles (path traversal) to a content signature of a known system file (`root:…:0:0:` from `/etc/passwd`, `[fonts]` from `win.ini`), never to a generic 200/404.

<!-- Native skill bundle for Claude Code. Generated by `secure-vibe dev regenerate`. -->
<!-- Do not edit by hand; the source of truth is skills/electron-security/SKILL.md. -->

# Electron Desktop Security

Harden Electron: renderer trust boundary (nodeIntegration, contextIsolation, sandbox), build-time fuses, contextBridge and IPC allowlists, shell.openExternal, navigation guards, deep-link auth, safeStorage. Use when generating main-process code, a preload script, or custom-protocol handlers, when packaging a release, or when storing tokens in an Electron app.

## ALWAYS

- **Treat the renderer as untrusted.** Any renderer-side code execution — XSS in rendered content, a redirect, a deep link — must not be able to reach Node, the shell, the filesystem, or session tokens. Every other rule here follows from this one, and every IPC sink you expose is reachable from a compromised renderer.
- Keep the renderer's process isolation at its defaults rather than restoring them: `nodeIntegration: false`, `contextIsolation: true` and `sandbox: true` have been Electron's defaults for several major versions, so the finding is the line that **turns one off**. Note the coupling: under `sandbox: true` a preload gets a polyfilled module subset, so a preload needing `fs` fails — move that work behind IPC into the main process, never drop the sandbox.
- Set the packaging **fuses** on release builds: disable `RunAsNode`, `EnableNodeCliInspectArguments` and `EnableNodeOptionsEnvironmentVariable`. With `RunAsNode` on, an attacker runs your signed binary as a plain Node process and every renderer-side control above becomes irrelevant — a build-time setting no runtime hardening substitutes for.
- Expose a **minimal, typed** API from the preload via `contextBridge.exposeInMainWorld`. Expose named functions only — never hand the renderer `ipcRenderer`, `require`, `process`, or whole modules. Do not add `@electron/remote`: it restores the main-process object access that was removed from core precisely because it defeats the boundary.
- Validate **every** IPC argument in the main-process handler: type-check, bound, and allowlist. The renderer is an attacker-controlled input source.

<!-- Native skill bundle for Claude Code. Generated by `secure-vibe dev regenerate`. -->
<!-- Do not edit by hand; the source of truth is skills/error-handling-security/SKILL.md. -->

# Error-Handling Security

Decide what an error tells the client and what stays server-side: no stack traces, SQL, or paths in responses, no silent suppression, and no distinction between outcomes that would reveal protected state. Use when generating HTTP, GraphQL, or RPC error handlers, exception, panic, or rescue blocks, or configuring production error pages.

## ALWAYS

- Catch exceptions at the boundary — HTTP handler, RPC method, message consumer — and decide *there* what crosses to the client and what stays server-side. Record the failure with a correlation ID under `logging-security`'s policy; do not bypass its redaction rules to attach "full context", which is how request bodies, cookies and tokens end up in logs.
- Put only client-actionable information in an external error: a stable error code, a short human-readable message, and the correlation ID. Anything the caller cannot act on belongs in the log entry that shares that ID.
- Keep responses **consistent within an error class**, and make security-equivalent outcomes externally indistinguishable. Different classes may and should differ — `400 VALIDATION_FAILED`, `401`, `403`, `409`, `429` are not a finding. What must not differ is a pair of outcomes whose distinction reveals protected state: whether an account exists, whether a record the caller may not see is present. `auth-security` owns making the login paths cost the same; this rule owns what they return.
- Disable developer error pages and detailed exception rendering in every non-development environment, and route unhandled errors through the framework's production error handler. This is a wiring decision, not the same thing as an environment variable reading `production` — the setting and its name differ per framework, and `references/framework-error-pages.md` has them.
- Render every external error through one helper, so the sanitization rules live in a single place instead of being re-derived at each handler.

<!-- Native skill bundle for Claude Code. Generated by `secure-vibe dev regenerate`. -->
<!-- Do not edit by hand; the source of truth is skills/file-upload-security/SKILL.md. -->

# File Upload Security

Accept, store, process, and serve user uploads safely: type-appropriate content validation, decompression limits, generated storage keys, quarantine before publication, isolated media processing, and scoped direct-to-storage credentials. Use when generating a file-upload endpoint, wiring presigned or SAS uploads to S3, GCS, or Azure Blob, processing user-supplied images or documents, or serving user-generated content.

## ALWAYS

- Put every new upload in a **non-public quarantine** location, and do not expose it, link it, index it, or hand it to a downstream workflow until validation has succeeded. Quarantine → validate → process → publish, in that order. This is the invariant the rest of these rules hang from, and the one direct-to-storage uploads most often skip.
- Validate content **server-side with checks appropriate to the format**. Where a format has a reliable signature, verify it; for container and document formats — DOCX, XLSX and ZIP are all ZIP at the container level — also validate structure against the format you expect. Text-based formats such as SVG and CSV have no signature to check at all, so a signature check alone is not a content policy. The client's `Content-Type` and the filename are attacker-controlled and are never the check.
- Keep a **per-endpoint allowlist** of accepted types and deny everything else. Deny `image/svg+xml` by default: an SVG is a document that can carry script. Where an endpoint genuinely requires SVG, treat it as active content — rasterize it, or run a maintained **SVG-aware** sanitizer with an explicit element, attribute, URL and CSS allowlist. A generic HTML sanitizer is the wrong tool for it.
- Bound the **expansion**, not only the upload. For archives and compressed or container formats, cap expanded bytes, entry count, nesting depth, compression ratio, per-entry size and processing time, and reject before extracting when the projected expansion exceeds policy. A limit on the compressed bytes says nothing about what they become (CWE-409).
- Store under an **application-generated identifier** — a UUID or content hash — outside the executable or web document root, and never build the storage path from the user-supplied name. Keep the original filename as bounded metadata only, and encode it for the specific output context where it is displayed. There is no "escaped at rest" that is safe in every context.

<!-- Native skill bundle for Claude Code. Generated by `secure-vibe dev regenerate`. -->
<!-- Do not edit by hand; the source of truth is skills/frontend-security/SKILL.md. -->

# Frontend Security

Browser-side hardening: XSS and safe text binding, per-sink URL policy, DOM clobbering, nonce-based CSP, Trusted Types, subresource integrity, iframe capability minimization, postMessage validation, and where client state may live. Use when generating HTML, JSX, Vue, or Svelte templates, setting response headers in a web app, embedding third-party scripts or frames, or storing anything client-side.

## ALWAYS

- Render untrusted data through the framework's ordinary text interpolation, which escapes for the output context. Do not reach for a raw-HTML API merely to display user data. Where rich HTML genuinely must be rendered, put it through a maintained sanitizer (DOMPurify) with an explicit allowlist first.
- Validate URL-bearing attributes **per sink**, not against one global scheme list. A navigation target (`href`, `action`, `formaction`, an `<iframe src>`) and an image source do not share a trust model: `javascript:` is never acceptable anywhere, while a narrowly constrained `data:image/…` or `blob:` may be exactly what an image sink requires. Decide the permitted schemes for each sink and check against that list.
- Read security-sensitive configuration and control-flow values from lexical variables or an object you own — never from a named `window` / `document` property (`window.config`, `document.redirectTo`, an implicit global). The browser exposes elements by `id` and `name` as named properties, so injected markup can shadow the value your code expected. An explicit `getElementById()` lookup is not the problem; trusting an ambient global is. Type-check what you read before using it in a privileged way.
- Build the `Content-Security-Policy` around a **nonce or hash as the trust root**: `script-src 'nonce-{value}' 'strict-dynamic'; object-src 'none'; base-uri 'none'`. Keeping `'self'` beside the nonce means every same-origin script is still trusted — that is a host-allowlist policy wearing a nonce, which may be the right trade-off but is not a strict CSP, so do not call it one. Generate the nonce from a CSPRNG afresh for **every HTML response**, and apply it only to scripts the server itself authorizes.
- Where you deploy Trusted Types, enforce `require-trusted-types-for 'script'` **and** restrict which policies may exist with the `trusted-types` directive. The first makes DOM sinks demand a typed value; without the second, any code can mint a pass-through policy (`createHTML: s => s`) and the guarantee is gone. Keep policies few, named, and centrally reviewed.

<!-- Native skill bundle for Claude Code. Generated by `secure-vibe dev regenerate`. -->
<!-- Do not edit by hand; the source of truth is skills/graphql-security/SKILL.md. -->

# GraphQL Security

Bound and control a GraphQL endpoint: operation cost budgets, cost-based rate limiting, pre-registered operations, alias and batch abuse on authentication paths, introspection, cache keying, and untyped scalar inputs. Use when generating schemas, resolvers, or server config, wiring limits or persisted operations, or reviewing a public /graphql endpoint.

## ALWAYS

- Enforce a **cost budget** on every operation: a maximum depth, plus a complexity score that weights list fields by the page size they can request. Derive the numbers from your own schema and measure them — a depth of 7 is generous for a flat schema and far too permissive for one with a many-to-many edge, where five levels of nesting can address billions of nodes. `references/graphql-limits.md` covers how to derive them and where each server configures them.
- Rate-limit by **cost consumed**, not by request count. Every operation arrives at the same URL, so the per-route limit `api-security` specifies cannot tell a trivial query from one costing a thousand times more. Charge the complexity score against the caller's budget.
- For a public or high-traffic API, restrict it to **pre-registered operations** — a build-time allowlist of the documents the client bundle actually contains, keyed by hash. Automatic Persisted Queries are **not** this: APQ lets a client register any operation it likes and then send its hash, which is a bandwidth optimization. Turning on APQ and believing the API is now allowlisted is a common and expensive mistake.
- Cap aliases per operation and operations per batch, and apply that counting to **authentication and other rate-limited paths**. One request carrying a hundred aliased `login` fields is a hundred attempts against any counter that increments once per request — this is the mechanism behind the account-takeover-by-batching incidents, not a bandwidth concern.
- Batch resolver fetches with a DataLoader or a join. An N+1 resolver turns one cheap-looking query into a database round trip per parent row — the same amplification the cost limit exists to bound, except it happens below the cost analysis where that limit cannot see it.

<!-- Native skill bundle for Claude Code. Generated by `secure-vibe dev regenerate`. -->
<!-- Do not edit by hand; the source of truth is skills/iac-security/SKILL.md. -->

# Infrastructure-as-Code Security

Terraform, CloudFormation, and Pulumi hardening: state as a secret store, pinned providers and modules, encryption and network defaults, drift, and the privilege of the pipeline that applies the plan. Use when generating infrastructure code, reviewing IaC changes in a pull request, configuring a state backend, or setting up a new cloud account or workspace.

## ALWAYS

- Treat the **state file as a secret store**. Every value that passes through Terraform — a generated password, an RDS master credential, a private key, the contents of a data source — is written to state in plaintext. `sensitive = true` only hides a value from CLI output; it changes nothing about what is stored. So read access to the backend is read access to those secrets, and the backend's access policy has to be written on that basis.
- Configure a **remote backend** with encryption at rest, state locking, and versioning. Prefer the backend's own locking where it exists — recent Terraform supports S3-native locking, so a separate DynamoDB lock table is no longer required for new stacks. `references/backends-and-state.md` has the per-backend form.
- Pin providers and modules to an exact version or a pessimistic constraint (`~> 5.42`), and pin a third-party module sourced from a git URL to a **commit SHA**, not a branch or tag. A module is code that runs with your apply credentials, and a registry or repository you do not control is a supply-chain input like any other.
- Give the **apply identity** the least privilege that the stack actually needs, and keep it separate from the plan identity. A pipeline role with account-wide admin turns any CI compromise into a full account compromise — `cicd-security` owns hardening the pipeline itself, `iam-best-practices` owns the role's shape.
- Encrypt persistent resources by default with a customer-managed key: object storage, block storage, managed databases, queues, log groups. Prefer a module or default that applies it, so a new resource is encrypted because of how the code is organised rather than because someone remembered.

<!-- Native skill bundle for Claude Code. Generated by `secure-vibe dev regenerate`. -->
<!-- Do not edit by hand; the source of truth is skills/iam-best-practices/SKILL.md. -->

# Identity & Access Management Best Practices

Least-privilege cloud IAM: policy scope, privilege-escalation paths, permissions boundaries, workload identity over static keys, MFA enforced by policy, cross-account trust, and separating deploy from runtime. Use when generating IAM policies, roles, or trust documents, wiring CI/CD service accounts or workload identities, delegating role creation, or designing cross-account access.

## ALWAYS

- Grant the minimum permissions the workload's stated job requires: deny by default, then add concrete actions against concrete resources. A wildcard action on a wildcard resource — in a custom policy, in `AdministratorAccess`, or in `iam:*` attached to something that runs continuously — is the same finding wearing three different names.
- Read a policy for the **privileges it can reach**, not only the ones it names. A principal that can write policy (`iam:PutRolePolicy`, `iam:AttachRolePolicy`, `iam:CreatePolicyVersion`) can grant itself anything, and a principal that can pass a role into a compute service it may also create (`iam:PassRole` with `lambda:CreateFunction`, `ec2:RunInstances`, `glue:CreateJob`) inherits that role's privileges. These read as narrow grants and are administrative ones. `references/escalation-paths.md` lists the combinations worth failing a review over.
- Bound delegated permissions with a **permissions boundary** or an organization-level policy (SCP, GCP org policy, Azure management-group policy) when teams may create their own roles. The boundary caps what any role they create can do, which is what makes self-service role creation safe rather than a privilege-escalation primitive.
- Prefer **workload identity** — IRSA on EKS, GKE Workload Identity, Azure Managed Identity, OIDC federation from CI — over a static key. The goal is that no long-lived credential exists to leak. Where one is genuinely unavoidable, give it a documented rotation cadence and automatic disablement on inactivity, and treat that as a temporary state rather than the steady state.
- Enforce MFA for human principals through a **policy condition** (`aws:MultiFactorAuthPresent`), not only a directory setting, so a credential that bypasses the directory still cannot act.

<!-- Native skill bundle for Claude Code. Generated by `secure-vibe dev regenerate`. -->
<!-- Do not edit by hand; the source of truth is skills/llm-app-security/SKILL.md. -->

# LLM Application Security

Securing a feature that calls an LLM: prompt injection as an unsolved input problem, bounding what model output is allowed to reach, tool authorization against the human rather than the model, approval gates on consequential actions, RAG context provenance, system-prompt leakage, and cost limits. Use when sending prompts to an LLM API, building a RAG pipeline, giving a model tools, rendering or executing model output, or exposing an LLM-backed endpoint.

## ALWAYS

- Start from the premise that **prompt injection is not solved at the prompt layer**. A model has no privileged channel: system text, user text, a retrieved document and a tool result all arrive as one context, and nothing in that context can be marked as instructions the model must obey over the rest. Message roles are a formatting convention, delimiters raise the cost of an attack, and an instruction such as "treat the following as data" is itself just more text in the same window. Design as though injection will sometimes succeed, and put the real controls after the model rather than in front of it.
- Bound what the model's output is **allowed to reach**. Every downstream sink — a query builder, a shell, a file writer, an HTTP client, a renderer — must validate model output exactly as it would validate a request body from the internet, because that is what it is once injection is assumed. `secure-code-review`, `database-security` and `frontend-security` own the individual sinks; what belongs here is that model output never arrives pre-trusted.
- Constrain the output's **shape** with structured generation — a JSON Schema, function-call mode, constrained decoding — whenever the next step consumes it programmatically, and reject anything that fails validation rather than repairing it. A schema bounds the form, not the intent: a well-formed field can still carry a hostile value, so validate the value too.
- Authorize each tool call against the **human user's** permissions, checked at call time, not against what the model was told it may do. The tool allowlist is a capability list, not an authorization decision — and the agent's own privileges are the attack surface, because injected content drives the agent that holds them. Keep the agent's identity narrow for the same reason `iam-best-practices` keeps a pipeline role narrow.
- Put a **human approval gate** in front of consequential and irreversible actions: moving money, deleting or overwriting data, sending messages on a user's behalf, publishing, changing permissions. Injection that reaches a read-only tool is an information problem; injection that reaches a write tool is an incident. The gate is what keeps a single injected instruction from being final.

<!-- Native skill bundle for Claude Code. Generated by `secure-vibe dev regenerate`. -->
<!-- Do not edit by hand; the source of truth is skills/logging-security/SKILL.md. -->

# Logging Security

Keep secrets and personal data out of logs at the call site rather than relying on redaction, neutralize log and field injection, record audit events that survive, and treat log read access as data access. Use when generating logger calls or structured-logging schemas, wiring log shippers, sinks, retention, and access controls, or specifying audit-logging requirements.

## ALWAYS

- Decide what is safe to log **at the call site**, and log a reference rather than a value: an id, a hash, a type, a count. A redactor is the last net, not the design — it matches field names and known patterns, so it cannot see personal data sitting inside an assembled string. A formatted notification body, a templated message, an exception with interpolated arguments: the name and the address are in the prose, in no named field, matching no pattern. Nothing downstream will catch that.
- Run a **redactor** at the sink anyway, for the cases the call site missed: credential-shaped values, `Authorization` and `Cookie` headers, query strings carrying tokens, and the personal-data patterns in `rules/redaction_patterns.json`. `secret-detection` owns which literals count as a credential; this rule is that the redactor exists and runs before anything leaves the process.
- Log in a **structured format** (JSON or logfmt) with stable field names — `timestamp`, `service`, `version`, `level`, `trace_id`, `span_id`, `request_id`, `event`, and `user_id` when there is an authenticated one. Structure is what makes redaction, retention, and access control expressible per field instead of per line.
- Neutralize user-controlled strings before they enter a log record. Line injection (CWE-117) is the classic case — a `\n` or `\r` lets an attacker forge a whole record — but structured logging moves the problem: a value that parses as JSON can inject *fields* into the ingested document, and ANSI escape sequences (`\x1b[`) are interpreted by the terminal of whoever reads the log. Encode the value; do not concatenate it into the line.
- Record security-relevant events as **immutable audit records**: authentication success and failure, MFA challenges, password and role changes, permission grants and revocations, data export, administrative action. These carry longer retention and stricter access than operational logs, and they are the reason failed logins must keep being written even when someone calls them noise.

<!-- Native skill bundle for Claude Code. Generated by `secure-vibe dev regenerate`. -->
<!-- Do not edit by hand; the source of truth is skills/ml-security/SKILL.md. -->

# ML Model Security

The model and data artifacts: checkpoint formats that execute code on load, provenance for a model you did not train, training-data poisoning and the ingestion controls that bound it, PII that survives into weights, and notebooks that commit their own output. Use when loading a model from disk, a Hub, or object storage, ingesting user content for training or fine-tuning, or writing training, evaluation, or notebook code.

## ALWAYS

- Prefer a **tensor-only format** — safetensors — for anything you load. It stores arrays and metadata and has no mechanism for executing code, which is the property that matters. A `.pt`, `.pkl`, `.bin`, `.ckpt` or `joblib` artifact is a pickle: loading it runs whatever the author put in it, before you see a single weight.
- Pass `weights_only=True` to `torch.load` **explicitly**, every time. The default has changed across PyTorch releases, so code that relies on it behaves differently depending on the pin — and the flag narrows the surface without removing it, so it is a mitigation rather than a reason to load an untrusted file. `deserialization-security` owns the pickle boundary itself and the per-language detail; `references/artifacts-and-provenance.md` has the format-by-format table.
- Establish provenance before loading: the artifact's **hash matches one you recorded** from a source you decided to trust, at a revision you pinned. A hash the artifact came with proves only that the file is the file. `supply-chain-security` owns what makes a source trustworthy, and its rule holds here — a checksum served next to the download is not authentication, and an author's name is not a signature.
- Pin the Hub revision to an **immutable commit**, not a branch or tag. `main` moves, and `from_pretrained(..., revision="<sha>")` is the difference between a model you reviewed and whatever is there today. Where the loader offers `trust_remote_code`, understand that enabling it executes repository Python at load time, which is the same exposure as the pickle it was meant to avoid.
- Bound what user-contributed data can do to a model. Attribute each training record to its source, keep contributed data in a separate pool from curated data, gate promotion between them on review, and cap how much any single contributor can influence one training run. Poisoning does not need many records — it needs enough of them near one behaviour.

<!-- Native skill bundle for Claude Code. Generated by `secure-vibe dev regenerate`. -->
<!-- Do not edit by hand; the source of truth is skills/mobile-security/SKILL.md. -->

# Mobile Application Security

Android and iOS hardening on a device you do not control: hardware-backed credential storage, exported components and IPC, verified deep links, transport defaults and pinning rotation, server-side attestation over client-side root detection, screen capture, and release-build hygiene — including React Native and Flutter packaging. Use when generating Android or iOS app code, manifests, or native modules, wiring deep links or WebViews, or deciding what a mobile client is trusted to assert.

## ALWAYS

- Start from the premise that **the device belongs to whoever is holding it**. The app runs on hardware an attacker can root or jailbreak, instrument at runtime, and read at rest. Everything shipped in the package is extractable, every client-side check is removable, and every local check can be made to return the answer the attacker wants. What you actually control is the backend's willingness to act — so any decision that matters is made server-side, on evidence the server verified.
- Issue short-lived, device-scoped tokens from a backend rather than shipping an API key, signing key, or backend credential in source, resources, `strings.xml`, `BuildConfig`, or `Info.plist`. Anyone can download the package and read it.
- Keep credentials in the platform's hardware-backed store: Android Keystore (`EncryptedSharedPreferences` with a `MasterKey`), iOS Keychain with a `…ThisDeviceOnly` accessibility class — `WhenUnlocked` where the value is never needed in the background, `AfterFirstUnlock` where it is. Never `SharedPreferences`, `UserDefaults`, a plist, or a file. The store protects a key at rest on an uncompromised device; it does not protect against code running inside your process, which is why the credential should be short-lived regardless.
- **Android**: give every `<activity>`, `<service>`, `<receiver>` and `<provider>` an explicit `android:exported`, defaulting to `false`. Since API 31 the attribute is mandatory when an intent filter is present — which forces the question to be asked, not answered. An exported component is a public API of your app that any installed application can call.
- Treat data crossing an app boundary as untrusted in both directions: validate every `Intent` extra and incoming activity payload, send sensitive data with an explicit component rather than an implicit intent any app can register for, and create every `PendingIntent` as `FLAG_IMMUTABLE` so the recipient cannot rewrite its contents.

<!-- Native skill bundle for Claude Code. Generated by `secure-vibe dev regenerate`. -->
<!-- Do not edit by hand; the source of truth is skills/protocol-security/SKILL.md. -->

# Protocol Security

Transport security where the client establishes trust: TLS version floor, certificate chain and hostname verification, the trust store, connecting by IP, mTLS and workload identity as authentication, gRPC channel credentials, and SMTP STARTTLS. Use when generating HTTP, gRPC, or SMTP clients and servers, configuring TLS in code or platform config, wiring service-to-service authentication, or when tempted to disable certificate verification.

## ALWAYS

- Default to **TLS 1.3**, and permit TLS 1.2 only where a peer genuinely requires it. Disable TLS 1.0, 1.1, and every SSL version. Cipher-suite selection is a consequence of the version floor rather than a separate decision — `references/tls-configuration.md` carries the suite lists and the per-platform config keys.
- Verify the full certificate chain on every connection: a trusted issuer, an unexpired validity window, and a hostname that matches a **`subjectAltName` dNSName** entry. The hostname is checked *against* the SAN — SAN is not an alternative place to look, and a `CN` match is not a fallback, because current browsers and TLS libraries removed CN as a hostname source.
- When connecting to an **IP address** rather than a name, set the expected name explicitly (`ServerName` in Go's `tls.Config`, the equivalent SNI/verification hostname elsewhere) so verification has something to check, or require a certificate carrying an `iPAddress` SAN. Reaching an endpoint by IP is the single most common reason a developer disables verification — this is the fix that keeps it on.
- Resolve a self-signed or internal-CA endpoint by **adding that CA to the client's trust configuration**, not by turning verification off. Every language has a way to supply a custom root pool; using it keeps hostname and expiry checks intact, which is exactly what the shortcut discards.
- Use **mutual TLS** for service-to-service traffic inside a trust domain, and treat it as what it is: a cryptographic caller identity, which *is* authentication — unlike network position, which is not. A SPIFFE workload identity (`spiffe://trust-domain/...`) with short-lived certificates is the form of this worth reaching for over a long-lived shared API key.

<!-- Native skill bundle for Claude Code. Generated by `secure-vibe dev regenerate`. -->
<!-- Do not edit by hand; the source of truth is skills/saas-security/SKILL.md. -->

# SaaS Integration Security

Wiring your application to a third-party SaaS platform: verifying an inbound webhook against the vendor's own scheme rather than a generalized one, why a valid signature identifies the sender and not the user in the payload, replay windows, one credential per integration and per environment, least-privilege scopes, and treating a bulk export as a data boundary. Use when writing a webhook receiver, an OAuth integration, a SCIM endpoint, or any code that authenticates to or from a SaaS vendor.

## ALWAYS

- Verify an inbound webhook against **that vendor's documented scheme**, and do not generalize from another one. Vendors differ in the header, in the secret, and — the part that breaks a generalized implementation — in the **canonical string** that gets signed. Some sign the raw body, some sign a version prefix plus a timestamp plus the body, some sign the HTTP method and path as well. Read the vendor's page for the vendor you are integrating; a signature routine copied from a different vendor produces a receiver that rejects every legitimate event, and the fix someone reaches for is to turn verification off.
- Verify against the **raw request body**, exactly as received, before any parsing or re-serialization. A framework that decodes JSON and re-encodes it changes whitespace and key order, and the HMAC no longer matches — which again ends with verification being disabled rather than fixed.
- Check the **timestamp** the vendor sends and reject requests outside a short window, then reject **replays** inside it by recording delivery or event ids. A signature is valid forever; the window narrows the replay opportunity and the id store closes it.
- Compare signatures in **constant time**. `crypto-misuse` owns the comparison API for each language.
- Treat the signature as proof of **who sent the payload, not who the payload is about**. This is the distinction that matters most in this domain: a verified Zoom or Calendly or HubSpot event genuinely came from that vendor, and the `email`, `from`, or custom fields inside it may still be attacker-chosen — anyone who can book a meeting or submit a form controls them. Resolve the subject to a canonical id server-side. `auth-security` owns the general rule for producer-asserted identity.

<!-- Native skill bundle for Claude Code. Generated by `secure-vibe dev regenerate`. -->
<!-- Do not edit by hand; the source of truth is skills/secret-detection/SKILL.md. -->

# Secret Detection

Keeping credentials out of source, and what to do once one is in: rotate before removing, because deleting the line does not un-leak it. Covers where a secret may live, safe .env templates, why a client-reachable config value is public, and running a scanner rather than eyeballing for patterns. Use when writing code that reads a credential, creating config or .env templates, before committing, or after discovering a secret in a repository.

## ALWAYS

- On finding a committed credential, **rotate or revoke it at the provider first**. Deleting the line does not remediate it, and neither does `git rm`, an amended commit, or a history rewrite: the value reached a remote, a clone, a fork, a CI log and a backup, and it is compromised from the moment it was pushed. Rotate, then clean the history, then add the guard that stops it recurring — in that order, because only the first one is time-critical.
- **Run a scanner**; do not scan by eye. `scan_secrets` and `check_secret_pattern` carry the full pattern set with per-pattern entropy floors and hotword proximity, and a person reading a diff matches none of that reliably. A working-tree scan and a history scan answer different questions — the first says what you are about to commit, the second says what is already public.
- Read the credential from the environment or a secret manager at the point of use — `os.environ`, `process.env`, `os.Getenv`, a Vault / AWS Secrets Manager / GCP Secret Manager / 1Password client. Nothing about the value should be reconstructible from the repository.
- Ship a **`.env.example`** that is committed and contains every key with an empty or obviously-fake value, alongside a `.env` that is ignored and never committed. The example file is documentation, so it must never be produced by copying a working `.env` and editing it — that is how a real value survives into the template.
- Ignore the file classes that carry key material, in one list: `.env`, `.env.*` (but not `.env.example`), `*.pem`, `*.key`, `*.p12`, `*.pfx`, `*.ppk`, `id_rsa*`, `id_dsa*`, `id_ecdsa*`, `id_ed25519*`, `*credentials*`, `*secret*`. A `.gitignore` entry is a guard against habit, not a control — it does nothing for a file already tracked, and `git add -f` overrides it.

<!-- Native skill bundle for Claude Code. Generated by `secure-vibe dev regenerate`. -->
<!-- Do not edit by hand; the source of truth is skills/secure-code-review/SKILL.md. -->

# Secure Code Review

The sinks and boundaries that belong to no framework: passing input to a shell or an evaluator, letting input choose a filesystem path, validating at a boundary that is not an HTTP request, and handling regulated data (PII, PHI, cardholder data) so it does not spread into paths nobody reviews. Use when generating or reviewing code that shells out, touches the filesystem, reads a queue message, CLI argument, or parsed file, or when a change crosses a PII, PHI, or PCI boundary.

## ALWAYS

- Validate input at **every** trust boundary, not only the HTTP one. A CLI argument, an environment variable, a queue message, a filename, a parsed config or spreadsheet cell all arrive from outside and none of them pass through the request-validation layer. Check type, length, allowed characters and allowed range, and reject before processing. `api-security` owns the HTTP request body and its schema; this rule is every other way input gets in.
- Build a command as an **argument vector**, never as a string a shell will parse: `subprocess.run([...])` without `shell=True`, `execFile`/`spawn` with an array, `exec.Command(name, args...)`. Passing an array is what removes the shell, and removing the shell is what removes the injection — quoting and escaping are the fallback for when you cannot.
- **Canonicalize then check** any path built from input: resolve it to an absolute real path, then confirm it is inside the intended directory. Checking the raw string first misses `..`, symlinks, absolute-path replacement, and encoded separators. `file-upload-security` owns stored uploads and archive extraction; this rule covers a static-file handler, a template loader, a log path, an export filename.
- Tag any function or module handling **PII, PHI or cardholder data** with an explicit classification comment (`// classification: PII`), and keep that handling in clearly-named modules rather than in general utility code. An untagged helper is how regulated data spreads into paths nobody reviews for it, and the tag is what makes the later review possible.
- Consult the owner for anything with one: `database-security` when code builds a query, `crypto-misuse` when it hashes, encrypts, signs or compares a secret, `frontend-security` for output encoding and response headers, `auth-security` for who the caller is, `iam-best-practices` for the privileges a process runs with. Each of those states its rule with the API names and the false positives this skill would have to leave out.

<!-- Native skill bundle for Claude Code. Generated by `secure-vibe dev regenerate`. -->
<!-- Do not edit by hand; the source of truth is skills/security-regression-tests/SKILL.md. -->

# Security Regression Tests

Turning a confirmed and fixed finding into a permanent guard: proving the test fails without the fix, asserting the effect and not only the status code, seeding the two principals an authorization test needs, making a timing or out-of-band proof deterministic enough for CI, and keeping the test in a job that can actually block. Use once a security finding has been confirmed and fixed, or when a security test is failing, skipped, or about to be deleted.

## ALWAYS

- **Prove the test fails without the fix.** Revert the patch, or mutate the guard, and confirm the new test goes red — then restore. A test written after the fix can be vacuously green: wrong route, wrong fixture user, wrong assertion target, a typo in the payload. It will stay green forever and nobody will learn anything from it. This is the one step that distinguishes a guard from a decoration, and it is the one most often skipped.
- Assert **both directions**: the attack input now yields the secure outcome, *and* a legitimate input still succeeds. A deny-only test passes equally well against an endpoint that is broken for everyone, so it will hold the line and tell you nothing when someone disables the feature entirely.
- Assert the **effect**, not only the status code. A `403` proves the request was refused; it does not prove the write did not land somewhere else, that the record was not returned in a different shape, or that a queue message was not emitted. Check the state the attack was trying to reach.
- Seed the **fixtures the assertion depends on** before writing it. A cross-tenant test needs two principals and two owned resources, deterministically created — if both test users end up in the same tenant, the deny assertion is untestable and passes for the wrong reason.
- Make it **deterministic and offline**. Freeze the clock for expiry and TTL assertions, stub the HTTP client, dialer or resolver rather than reaching the network, fix random seeds, and avoid sleep-based timing assertions and state shared between tests. Note that a canonical SSRF payload such as `http://169.254.169.254/latest/meta-data/` is a *live, reachable* address on a cloud CI runner, so the naive test both leaves the sandbox and returns a different verdict on a laptop.

<!-- Native skill bundle for Claude Code. Generated by `secure-vibe dev regenerate`. -->
<!-- Do not edit by hand; the source of truth is skills/serverless-security/SKILL.md. -->

# Serverless Security

What a function-as-a-service platform changes: an execution environment reused between invocations so /tmp and module globals outlive a request, an event envelope that is attacker-influenced whichever trigger delivered it, encrypted-at-rest configuration that the control-plane API still returns in cleartext, and concurrency as the boundary between an incident and a bill. Use when generating Lambda, Cloud Functions, or Azure Functions code, serverless.yml or SAM templates, or wiring API Gateway, EventBridge, SQS, or S3 triggers.

## ALWAYS

- Treat the **execution environment as reused**. The platform freezes it when the handler returns and thaws it for the next invocation, which may serve a different tenant. So a module-level global holding per-request state — a decrypted payload, an authorization decision, a tenant id, a connection bound to one caller's credentials — is visible to the next request. Cache only what is safe to share, and reset or scope everything else inside the handler.
- Treat **`/tmp` as shared, persistent, and finite**. It is the only writable path, it survives across invocations in the same environment, and a fixed filename written for one user is readable by the next. Use a per-invocation subdirectory, delete it before returning, and never read back a path without having written it in the same invocation.
- Validate the **whole event, envelope included**. The trigger's identity is not authentication: an S3 object key is chosen by whoever can PUT to the bucket, SQS message attributes and EventBridge `detail` are producer-supplied, and an API Gateway authorizer context is only as trustworthy as the authorizer. Validate against an explicit schema before any code touches the payload, and where a function has more than one trigger, check the source discriminant and route by allowlist.
- Give each function its **own execution role** with only the permissions its stated job needs. `iam-best-practices` owns policy scope and the escalation paths; what is serverless-specific is one role per function, never shared, because a shared role gives every function the union of what any of them needs.
- Set concurrency deliberately, and know which control you are reaching for. **Reserved** concurrency caps a function's parallel executions and is the denial-of-wallet control; **provisioned** concurrency pre-initialises environments to remove cold starts and *bills for them whether or not they are used*. Reserved capacity is also drawn from a shared account pool, so setting it per function is a decision about the account, not just that function.

<!-- Native skill bundle for Claude Code. Generated by `secure-vibe dev regenerate`. -->
<!-- Do not edit by hand; the source of truth is skills/ssrf-prevention/SKILL.md. -->

# SSRF Prevention

Server-Side Request Forgery: allowlisting the destination of a server-side fetch, when re-resolution between check and connect matters, redirect and scheme bypasses, parsers that fetch on their own (XXE, SVG, HTML-to-PDF), cloud metadata, and keeping the response from becoming an oracle. Use when fetching a client-supplied URL, wiring webhooks, image proxies, PDF or preview renderers, or reviewing any HTTP-client wrapper.

## ALWAYS

- Constrain the destination with an **allowlist of hosts you intend to reach**, not a denylist of addresses you intend to avoid. A denylist has to enumerate every spelling of every internal address — decimal and octal IPv4, IPv6 and IPv4-mapped IPv6, a hostname whose A record is private, a public wildcard resolver like `nip.io` that encodes any address into a name — and it only has to be wrong once.
- Know which of the two controls you built, because it decides whether re-resolution matters. An **allowlist of hostnames** survives DNS rebinding: the attacker controls DNS only for names they own, and those names are not on the list. An **IP-range check** does not: the name resolves to a public address when you validate and a private one when you connect, and the two resolutions are independent. If your control is address-based, resolve once and **connect to that pinned address** — a custom dialer or transport, carrying the original hostname for SNI and `Host` — so no second lookup can occur.
- Re-validate **at every redirect hop**, or disable redirect-following entirely on fetchers that take user-supplied URLs. An allowed host answering `302` to `http://169.254.169.254/` is the single most common bypass, and it defeats a check performed only on the URL the user submitted.
- Restrict the scheme to `http` and `https` before anything else. `file://`, `gopher://`, `dict://`, `ldap://`, `jar://` and friends turn a fetcher into a file reader or a protocol-smuggling primitive.
- Keep the **user-URL fetcher and the internal fetcher as separate clients**, and make mixing them fail to compile rather than fail at runtime — distinct types in Go, Rust or TypeScript. A single client used for both eventually gets called with the wrong argument.

<!-- Native skill bundle for Claude Code. Generated by `secure-vibe dev regenerate`. -->
<!-- Do not edit by hand; the source of truth is skills/supply-chain-security/SKILL.md. -->

# Supply Chain Security

Vet dependencies before they enter the build: typosquats, dependency confusion, malicious packages, known vulnerabilities, unlocked resolution, risky install and build hooks, EOL embedded runtimes, and the authenticity and freshness of your own release channel. Use when adding or upgrading a dependency, reviewing package manifests or lockfiles, configuring package sources or internal namespaces, or publishing a package or application update.

## ALWAYS

- Verify the identity of a new dependency before adding it: registry metadata, repository URL, maintainer set, and provenance checked against the signer you *expect*. Name-similarity screening opens the question; it never answers it.
- Query the bundled malicious-package data before adding any dependency — `check_dependency`, `check_typosquat` and `lookup_vulnerability` read it, this file cannot. Match on ecosystem, normalized name **and affected version range**; an active match on the resolved version blocks.
- Treat package age, download volume, maintainer count and activity as risk signals, never as proof of trust. Defaults: a verified maintainer signal within 90 days of a package identity's first publication, plus a documented reason within 30 days.
- Lock the resolution graph for anything you deploy — commit the lockfile, install frozen in CI (`npm ci`, `--frozen-lockfile`, `pip --require-hashes`, `cargo --locked`). Lock what you deploy, range what you publish: a library's dependency metadata needs compatibility ranges.
- Restrict where packages resolve from, so an internal-only identifier cannot come from a public registry. Use the ecosystem's own mechanism — npm scope-to-registry, Gradle `exclusiveContent`, a single authoritative index for Python, which has no scope isolation at all.

<!-- Native skill bundle for Claude Code. Generated by `secure-vibe dev regenerate`. -->
<!-- Do not edit by hand; the source of truth is skills/template-injection/SKILL.md. -->

# Template Injection (SSTI)

User input reaching a template compiler rather than its context: the source-versus-values distinction, double-render pipelines, template names chosen by the caller, why a template sandbox is a mitigation and not a boundary, minimizing what the render context exposes, and template-driven resource exhaustion. Use when rendering templates with user-influenced values, when a template string or template name is assembled from input, or when a product lets users author templates.

## ALWAYS

- Pass user data as **bound values**, never into the template **source** string. This is the whole skill in one line: `render(tmpl, {"name": name})` is safe, `render("Hello " + name)` is SSTI. The compiler treats its source as code, and the context as data — so the only question that matters about any user value is which of the two it reaches.
- Keep the set of template sources **static and trusted**, loaded from files or constants. A template body read from a database column, an API response, or a request field is attacker-supplied code, whatever the column is called.
- Choose the template **by name from an allowlist**, never by a name the caller supplies. `render_template(user_value)` and `{% include user_value %}` are the same vulnerability as a user-supplied body: the caller picks which code runs, and on many engines the name resolves as a filesystem path, which makes it an arbitrary-file read as well.
- **Minimize the render context.** Pass the specific values the template needs, never the ambient objects — application config, settings, the request, `self`, a module, a live ORM instance. This is the control that still holds when a sandbox is escaped: an engine that cannot execute code can still print whatever it can reach, and configuration objects hold database URLs and signing keys.
- Treat a **second render pass** as compilation of whatever survived the first. If rendered output is parsed again, a user value that was inert data on pass one is `{{ }}` code on pass two. The fix is architectural — stop re-parsing rendered output. Neutralizing metacharacters before the second pass is a fallback that has to enumerate every delimiter of every engine, including ones a custom delimiter configuration introduces, and two adjacent fields can produce a delimiter that neither of them contains.

<!-- Native skill bundle for Claude Code. Generated by `secure-vibe dev regenerate`. -->
<!-- Do not edit by hand; the source of truth is skills/threat-modeling/SKILL.md. -->

# Threat Modeling

Decide what a design must be true before code exists: naming assets and actors, locating trust boundaries, producing a written (asset, boundary, threat, control, owner) list, recording the assumptions the design rests on, and knowing when a change invalidates the model. Use when scaffolding a new feature, service, or endpoint, writing or reviewing a design doc, RFC, or ADR, or introducing a new trust boundary, integration, or data flow.

## ALWAYS

- Produce a **written list**, not an impression. One row per finding, in the design doc, the RFC, or the PR description: `(asset, boundary, threat, control, owner)` — what is worth taking, where it crosses, what could go wrong there, what stops it, and which component enforces it. A model that exists only in the reasoning that produced the code cannot be reviewed, disagreed with, or checked later.
- Name the **assets** and the **actors** first: data, funds, credentials, keys and compute on one side; users, tenants, services, admins and the attacker on the other. Every later row references one of each, which is what makes the list finite.
- Locate the **trust boundaries** — internet to application, tenant to shared store, service to service, user input to an interpreter, model output to anything that acts on it. A boundary is where data arrives from a party you do not control, and it is the unit the rest of the model is organised around.
- At each boundary, ask the six **STRIDE** questions and write down only the answers that matter: can the caller be **spoofed** (is there authentication), can the data be **tampered** with in flight, will there be a record if someone **repudiates** the action, what is **disclosed** if this crossing leaks, what happens under **denial of service**, and does anything here allow **elevation of privilege**. A category with no answer is not a gap; a category nobody asked about is.
- Write down the **assumptions the design depends on**: this gateway is the only ingress, this queue's producers are authenticated, this field is already validated upstream, this CDN strips that header. Assumptions are the part of a threat model that later becomes false without anyone noticing, and an unwritten one cannot be rechecked.

<!-- Native skill bundle for Claude Code. Generated by `secure-vibe dev regenerate`. -->
<!-- Do not edit by hand; the source of truth is skills/websocket-security/SKILL.md. -->

# WebSocket Security

Securing the WebSocket upgrade and the frames after it: Origin validation against Cross-Site WebSocket Hijacking, authenticating the handshake rather than the first message, the ticket pattern for browsers that cannot set headers, per-frame authorization, and resource limits on a connection that stays open. Use when generating a WebSocket, Socket.IO, SignalR, or Phoenix Channels server, wiring real-time messaging, presence, or collaborative editing, or reviewing a /ws endpoint.

## ALWAYS

- Validate the **`Origin` header** on the upgrade handshake against an allowlist, and understand precisely what that buys: the browser sets `Origin` and script cannot forge it, so the check stops **Cross-Site WebSocket Hijacking** — a page on `attacker.com` opening `wss://api.example.com/ws` and inheriting the user's cookies. It buys nothing against a non-browser client, which sets any header it likes. Origin is a CSRF control, not authentication. The same-origin policy and CORS preflight do not apply to the upgrade at all, which is why this check must be written by hand.
- Authenticate the **handshake**, not the first frame. Once the upgrade completes the connection exists, has consumed the user's cookie context, and is already a resource the caller controls. A `subscribe` or `auth` message afterwards is too late.
- For a browser client, pick one of two mechanisms, because the browser `WebSocket` constructor **cannot set request headers** — there is no `Authorization` header available to you: 1. **Cookie on the upgrade** plus the `Origin` check above as the CSRF control, or 2. A **single-use ticket**: the authenticated page calls an ordinary HTTP endpoint, receives a short-lived opaque ticket bound to the user and to the intended resource, passes it in the URL, and the server **redeems and invalidates it at handshake time**. A ticket is safe in a URL precisely because replaying it fails.
- Re-authorize **every frame**, both the action and the subject it names. A frame like `{"action":"write","subjectId":"X"}` must be checked against the principal established at handshake — an authenticated socket must never be able to assert an arbitrary subject id per frame. That is per-frame BOLA, and the forged id reaches every consumer downstream of the socket that trusts it. Permissions also change while the connection is open: logout, role change, account lock, token expiry. A socket opened an hour ago carries an authorization decision an hour old.
- Bound the connection: maximum frame and message size, messages per second per connection, concurrent connections per user and per source address, and total connection lifetime after which the client must re-handshake. A WebSocket is an allocation that persists, so every limit HTTP gets per-request must be re-expressed per-connection. Concrete starting values, and the backpressure and heartbeat settings, are in `references/limits-and-handshake.md`.

# API Security

## Rules (for AI agents)

### ALWAYS
- Require authentication on every non-public endpoint. Default to authenticated; opt
  out for genuinely public routes by explicit annotation.
- Consult `auth-security` for **who the caller is and what they may touch**. It owns
  the credential (algorithm pinning, expiry, lifetime, session, CSRF) and the
  permission (object-level BOLA/IDOR checks, multi-key routes, streaming subjects,
  function-level role gating). Any endpoint that reads or writes a resource by id
  needs it; this skill covers everything else about the endpoint.
- Validate all request inputs against an explicit schema (JSON Schema, Pydantic,
  Zod, validator/v10 struct tags). Reject early; never propagate untrusted input

# Authentication & Authorization Security

## Rules (for AI agents)

### ALWAYS
- Authorize at the **object level** — confirm the authenticated subject actually has
  access to the requested resource ID, not just that they are logged in. Being signed
  in is not permission to read record 4,182 (OWASP API1 — BOLA / IDOR).
- Bind object-level authorization to the **authenticated principal**, never to an
  actor id echoed in the request: checking that a request-supplied
  `senderId`/`ownerId`/`actedBy` is a valid member validates the *claimed* actor, not
  the caller (looks like authorization, isn't).
- On `/{scopeId}/.../{subjectId}` routes, authorize the **relationship** — confirm the
  subject belongs to that scope. A caller-vs-scope check alone does not authorize the

# CI/CD Pipeline Security

## Rules (for AI agents)

### ALWAYS
- Pin every third-party GitHub Action by **commit SHA** (full 40-char), never by
  a floating tag (`@v1`, `@main`, `@latest`) — tags can be re-pushed. The
  tj-actions/changed-files March 2025 incident exfiltrated secrets from 23,000+
  repositories specifically because consumers used floating tags. Same applies to
  GitLab CI `include:` references and reusable workflows. Renovate / Dependabot
  can keep the SHA pins fresh.
  <!-- pattern: { id: gha-pin-actions-by-sha, severity: high, check: deterministic } -->
- Declare `permissions:` at the workflow or job level and default to
[Credential-related source omitted]

# Container Security

## Rules (for AI agents)

### ALWAYS
- Use **multi-stage builds**: separate builder/test stages from the final runtime
  image so build toolchains and source aren't shipped. The last stage should be a
  minimal base — `gcr.io/distroless/<variant>`, `scratch`, or a versioned `-slim` /
  `-alpine` variant — pinned by SHA256 digest, not just tag. Two bases have nothing
  to pin: `scratch`, and a reference to an earlier stage in the same file
  (`FROM base`), which is pinned on that stage's own `FROM` line.
  <!-- pattern: { id: dkr-multi-stage, severity: high, check: llm } -->
  <!-- pattern: { id: dkr-pinned-base-digest, severity: high, cwe: 1357, check: deterministic } -->
- Run as a non-root user: set `USER` explicitly on the **final stage**, as a **number**

# CORS Security

## Rules (for AI agents)

### ALWAYS
- For any non-public endpoint, allow origins from an explicit allowlist. `*` is
  correct only when the resource is intentionally public *and* cross-origin access
  never carries credentials.
- When a cross-origin request carries credentials — the browser's credentials mode is
  `include`, meaning cookies, TLS client certificates, or browser-managed HTTP auth —
  respond with `Access-Control-Allow-Credentials: true` and a **single explicit
  origin**. On a credentialed request every CORS header loses its wildcard meaning:
  `*` in `Allow-Origin`, `Allow-Methods`, `Allow-Headers`, or `Expose-Headers` is read
  as the literal string `"*"` and the browser blocks the response. That is why

# Cryptographic Misuse

## Rules (for AI agents)

### ALWAYS
- Use a maintained, widely reviewed cryptographic API — the platform's own (Node
  `crypto`, Java JCE, .NET `System.Security.Cryptography`, Go `crypto/*`) or a
  reputable third-party one (PyCA `cryptography`, `golang.org/x/crypto`, Bouncy
  Castle). Prefer high-level, misuse-resistant APIs over assembling low-level
  primitives yourself. In Python, `from Crypto…` resolves to either the abandoned
  `pycrypto` or its maintained fork `pycryptodome` depending on what is installed —
  the import line is identical, so depend on `pycryptodome` explicitly.
- Use a cryptographically secure RNG for anything security-relevant: Python
  `secrets.token_bytes` / `secrets.token_urlsafe`, JS `crypto.getRandomValues` /

# Database Security

## Rules (for AI agents)

### ALWAYS
- Bind every untrusted data value through the driver or ORM parameter API. Never place
  it into SQL with language-level interpolation or concatenation — `+`, f-strings, `%`
  formatting, `.format()`, JavaScript template interpolation. Driver placeholders
  (`%s`, `?`, `$1`, `:name`, `@name`) are the binding *mechanism*, not string
  formatting; confusing the two is how this rule is most often misread. The same
  applies to values read back out of the database and used to build a later query:
  stored input is still input, and second-order injection is this bug with a delay.
- Prefer the ORM's structured query-expression API over textual SQL. Where raw SQL is
  genuinely needed, use that framework's documented parameter-binding mechanism and

# Deserialization Security

## Rules (for AI agents)

### ALWAYS
- Prefer data-only serialization formats — JSON, Protobuf, MessagePack with an
  explicit type map — over formats that reconstruct arbitrary runtime objects. What
  makes a format safe here is not schema validation; it is whether the parser can
  instantiate a class the payload names.
- Constrain polymorphic type resolution to an explicit set of expected application
  types. Never let payload data choose the runtime class — that is the mechanism
  behind every gadget chain, whichever serializer is involved.
- Treat an object-reconstructing deserializer crossing a trust boundary as high risk:
  `pickle`, `ObjectInputStream`, `BinaryFormatter`, `unserialize`, `Marshal.load` and

# Verify Findings

## Rules (for AI agents)

### ALWAYS
- Treat a static-analysis or LLM-review hit as a *candidate*, not a vulnerability,
  until a probe with a deterministic oracle confirms it against a live target.
- Prefer an oracle that proves server-side behaviour over one that inspects the
  response text: out-of-band callbacks (SSRF, blind command injection, XXE) and
  timing deltas (blind SQLi, command injection) catch *blind* bugs that leave no
  trace in the body.
- Re-confirm any timing-based result a second time before trusting it — one slow
  response is noise, a repeatable delay over baseline is signal.
- For reflected oracles (XSS, SSTI), require the dangerous form: XSS confirms only

# Electron Desktop Security

## Rules (for AI agents)

### ALWAYS
- **Treat the renderer as untrusted.** Any renderer-side code execution — XSS in
  rendered content, a redirect, a deep link — must not be able to reach Node, the
  shell, the filesystem, or session tokens. Every other rule here follows from this
  one, and every IPC sink you expose is reachable from a compromised renderer.
- Keep the renderer's process isolation at its defaults rather than restoring them:
  `nodeIntegration: false`, `contextIsolation: true` and `sandbox: true` have been
  Electron's defaults for several major versions, so the finding is the line that
  **turns one off**. Note the coupling: under `sandbox: true` a preload gets a
  polyfilled module subset, so a preload needing `fs` fails — move that work behind

# Error-Handling Security

## Rules (for AI agents)

### ALWAYS
- Catch exceptions at the boundary — HTTP handler, RPC method, message consumer —
  and decide *there* what crosses to the client and what stays server-side. Record
  the failure with a correlation ID under `logging-security`'s policy; do not bypass
  its redaction rules to attach "full context", which is how request bodies, cookies
  and tokens end up in logs.
- Put only client-actionable information in an external error: a stable error code, a
  short human-readable message, and the correlation ID. Anything the caller cannot
  act on belongs in the log entry that shares that ID.
- Keep responses **consistent within an error class**, and make security-equivalent

# File Upload Security

## Rules (for AI agents)

### ALWAYS
- Put every new upload in a **non-public quarantine** location, and do not expose it,
  link it, index it, or hand it to a downstream workflow until validation has
  succeeded. Quarantine → validate → process → publish, in that order. This is the
  invariant the rest of these rules hang from, and the one direct-to-storage uploads
  most often skip.
- Validate content **server-side with checks appropriate to the format**. Where a
  format has a reliable signature, verify it; for container and document formats —
  DOCX, XLSX and ZIP are all ZIP at the container level — also validate structure
  against the format you expect. Text-based formats such as SVG and CSV have no

# Frontend Security

## Rules (for AI agents)

### ALWAYS
- Render untrusted data through the framework's ordinary text interpolation, which
  escapes for the output context. Do not reach for a raw-HTML API merely to display
  user data. Where rich HTML genuinely must be rendered, put it through a maintained
  sanitizer (DOMPurify) with an explicit allowlist first.
- Validate URL-bearing attributes **per sink**, not against one global scheme list. A
  navigation target (`href`, `action`, `formaction`, an `<iframe src>`) and an image
  source do not share a trust model: `javascript:` is never acceptable anywhere, while
  a narrowly constrained `data:image/…` or `blob:` may be exactly what an image sink
  requires. Decide the permitted schemes for each sink and check against that list.

# GraphQL Security

## Rules (for AI agents)

### ALWAYS
- Enforce a **cost budget** on every operation: a maximum depth, plus a complexity
  score that weights list fields by the page size they can request. Derive the numbers
  from your own schema and measure them — a depth of 7 is generous for a flat schema
  and far too permissive for one with a many-to-many edge, where five levels of
  nesting can address billions of nodes. `references/graphql-limits.md` covers how to
  derive them and where each server configures them.
- Rate-limit by **cost consumed**, not by request count. Every operation arrives at
  the same URL, so the per-route limit `api-security` specifies cannot tell a trivial
  query from one costing a thousand times more. Charge the complexity score against

# Infrastructure-as-Code Security

## Rules (for AI agents)

### ALWAYS
- Treat the **state file as a secret store**. Every value that passes through
  Terraform — a generated password, an RDS master credential, a private key, the
  contents of a data source — is written to state in plaintext. `sensitive = true`
  only hides a value from CLI output; it changes nothing about what is stored. So
  read access to the backend is read access to those secrets, and the backend's
  access policy has to be written on that basis.
- Configure a **remote backend** with encryption at rest, state locking, and
  versioning. Prefer the backend's own locking where it exists — recent Terraform
  supports S3-native locking, so a separate DynamoDB lock table is no longer required

# Identity & Access Management Best Practices

## Rules (for AI agents)

### ALWAYS
- Grant the minimum permissions the workload's stated job requires: deny by default,
  then add concrete actions against concrete resources. A wildcard action on a
  wildcard resource — in a custom policy, in `AdministratorAccess`, or in `iam:*`
  attached to something that runs continuously — is the same finding wearing three
  different names.
- Read a policy for the **privileges it can reach**, not only the ones it names. A
  principal that can write policy (`iam:PutRolePolicy`, `iam:AttachRolePolicy`,
  `iam:CreatePolicyVersion`) can grant itself anything, and a principal that can pass
  a role into a compute service it may also create (`iam:PassRole` with

# LLM Application Security

## Rules (for AI agents)

### ALWAYS
- Start from the premise that **prompt injection is not solved at the prompt layer**.
  A model has no privileged channel: system text, user text, a retrieved document and
  a tool result all arrive as one context, and nothing in that context can be marked
  as instructions the model must obey over the rest. Message roles are a formatting
  convention, delimiters raise the cost of an attack, and an instruction such as
  "treat the following as data" is itself just more text in the same window. Design
  as though injection will sometimes succeed, and put the real controls after the
  model rather than in front of it.
- Bound what the model's output is **allowed to reach**. Every downstream sink — a

# Logging Security

## Rules (for AI agents)

### ALWAYS
- Decide what is safe to log **at the call site**, and log a reference rather than a
  value: an id, a hash, a type, a count. A redactor is the last net, not the design —
  it matches field names and known patterns, so it cannot see personal data sitting
  inside an assembled string. A formatted notification body, a templated message, an
  exception with interpolated arguments: the name and the address are in the prose,
  in no named field, matching no pattern. Nothing downstream will catch that.
- Run a **redactor** at the sink anyway, for the cases the call site missed:
  credential-shaped values, `Authorization` and `Cookie` headers, query strings
  carrying tokens, and the personal-data patterns in `rules/redaction_patterns.json`.

# ML Model Security

## Rules (for AI agents)

### ALWAYS
- Prefer a **tensor-only format** — safetensors — for anything you load. It stores
  arrays and metadata and has no mechanism for executing code, which is the property
  that matters. A `.pt`, `.pkl`, `.bin`, `.ckpt` or `joblib` artifact is a pickle:
  loading it runs whatever the author put in it, before you see a single weight.
- Pass `weights_only=True` to `torch.load` **explicitly**, every time. The default has
  changed across PyTorch releases, so code that relies on it behaves differently
  depending on the pin — and the flag narrows the surface without removing it, so it
  is a mitigation rather than a reason to load an untrusted file.
  `deserialization-security` owns the pickle boundary itself and the per-language