---
name: automagik-dev/supply-chain
source: https://app.decimal.ai/s/automagik-dev-supply-chain@2/SKILL.md
source_sha256: 6e62ab387f2b
---

# 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.