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: invoke the plugin copy through the active runtime's owner-qualified skill selector; use a bare selector only when intentionally selecting a user-tier copy (a separately installed personal copy; Genie no longer seeds this tier). Cross-skill prose below uses bare names as portable semantic routes; the orchestrator resolves the selector for the active runtime.

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 carve-outs, approval-by-channel-membership) is a decision to scope-check, not a hole to report — the finding is silent scope widening, not the delegation's existence.
• Before reporting "errors are swallowed" or "fails open," find the test that locks the fail-closed behavior and run or read it; bots misread fail-closed envelopes constantly.
• Do not report theoretical issues on inputs that never cross a privilege boundary — a user's own CLI args writing the user's own files is not a finding.
• The user's own local state files are not a secret store to flag; the audit target is what external input can write into them.
• Severity inflation destroys audit credibility: label something critical only when you can state the attacker, the input, and the concrete impact in one sentence.