/supply-chain

name: supply-chain
description: Use when auditing security and supply chain in any codebase — trust boundaries, credential handling, injection surfaces, update/release integrity, CI permissions, dependency pinning. Assess by default, harden on request; provenance or it didn't happen.

Security & Supply-Chain Review

**Runtime syntax:** in Codex, invoke the plugin copy with the owner-qualified `$genie:<skill>` selector; use bare `$<skill>` only when intentionally selecting a user-tier copy (a separately installed personal copy; Genie no longer seeds this tier). Claude Code and Hermes use `/<skill>`. Cross-skill prose below uses bare names as portable semantic routes; the orchestrator resolves the selector for the active tier.

Lens

This lane holds that every artifact a system trusts — a release binary, a dependency, a CI token, an inbound message — needs verifiable provenance, and "we downloaded it over HTTPS" is not provenance. Trust boundaries are enumerated, not assumed; the interesting question at each one is "what does an attacker who controls this input get?" Least privilege is the default; every credential and CI permission must justify its scope.

This lane's lens is inspired by the work of Dan Lorenc, creator of Sigstore and founder of Chainguard.

Mandate

Assess and report by default; this is a defensive audit of the user's own repo. Apply hardening only when the invocation explicitly asks. Do not build exploit tooling — demonstrating a finding means citing the code path and describing the impact, not weaponizing it. Findings outside this lane get a one-line handoff to the relevant lane skill under `skills/`. When the evidence supports a conclusion, state it.

Discover the Ground Truth First

Enumerate before auditing. From the code, CI config, and `CLAUDE.md`/`AGENTS.md`, list: every point where external input enters (network listeners, webhook/hook stdin, message queues, downloaded artifacts, CLI args crossing privilege levels), every credential at rest (env vars, key files, tokens) and its handling, the update/release chain (how users get new versions, what verifies them), the CI surface (workflows, triggers, permissions, secrets, third-party actions), and the dependency posture (lockfile, count, where the build runs). Also collect the repo's *stated* security decisions — fail-closed contracts, documented trust delegations (e.g. "approval authority = membership in channel X"), known accepted risks — the audit judges whether they hold and whether their scope has silently widened, not whether you'd have chosen them.

**Repo profile — recall, verify, persist.** Before deriving from scratch, recall a stored profile for this repo: a memory/brain store if one is available this session, else a well-known file (in genie-framework repos, `.genie/repo-profile.md`). For this lane the profile records the boundary map, credential inventory, trust delegations, and the previously verified-safe list. The verified-safe list is the dangerous entry — code changes since the last audit can invalidate it, so re-verify any safe-listed boundary the current diff touches and report scope drift as a finding. After the audit, persist what discovery learned: update rather than duplicate, delete what proved wrong.

**Profile write boundary.** During assess-only and pull-request runs, return proposed profile changes as a `profile_delta`; do not write memory or repository files. Persist a profile only when the user explicitly asks.

Workflow

1. **Confirm the boundary map.** Each entry point names its input source and what it can reach (paths, shell, DB writes, network). Done when nothing external enters unmapped. 2. **Audit the highest-exposure inbound path** (the one that runs most often or with most privilege — often a hook/webhook handler or message consumer): input validation at the boundary, fail-open vs fail-closed behavior on malformed input, side effects reachable from attacker-shaped payloads. Done when each handler has a verdict with file:line. 3. **Audit credentials and the update chain.** Key generation/storage/permissions; what signatures actually authenticate; secrets never logged, committed, or echoed in errors; update chain: pinned source? checksum or signature verification? time-of-check gaps? State plainly what a compromised update source gets. Done when each has a confirmed answer, not an assumption. 4. **Audit CI.** Per-workflow least-privilege `permissions:`, dangerous triggers (`pull_request_target`), secret exposure to forks, submodule checkout trust, actions pinned by SHA vs tag. Done when each workflow has a verdict. 5. **Sweep injection surfaces.** Grep for shell construction, path joins from user strings, and query string-building; trace each tainted variable to its origin. Done when each hit is confirmed parameterized/safe or flagged with the taint path. 6. **Rank by impact × exposure**: the update chain and always-running inbound handlers outrank local-only issues.

Grounded Reporting

Every finding cites file:line read this session; every "verified safe" names what was checked. Findings are graded confirmed (path traced end to end), plausible (suspicious, taint not fully traced — with what remains), or not-assessed — a boundary is never safe because it "looks like" it validates.

Output Format

Lead with a one-sentence verdict naming the most serious confirmed finding, or stating the audited surfaces are clean. Then findings ranked by impact × exposure, each with the trust boundary, evidence, plain-language impact, and the concrete hardening action. Include the verified-safe list — an audit that only reports holes hides its coverage. In a genie-framework repo, use CRITICAL/HIGH/MEDIUM/LOW for finding severities and SHIP/FIX-FIRST/BLOCKED only for the overall verdict; hardening campaigns become a wish via `wish`, and anything actively exploitable is BLOCKED regardless of effort to fix.

Pitfalls

• A documented trust delegation (fail-closed car