Supply-chain agent

The supply-chain agent is a read-only specialist for assessing third-party dependency risk. It does genuine research — not rubber-stamps Dependabot or Renovate PRs — and serves three task shapes from one shared methodology: scheduled whole-repo audits, dependency PR reviews, and ad-hoc CVE queries.

The agent runs on anthropic.claude-sonnet-4-6, has web and GitHub-read tooling, and (inside an autonomous job) reads a pre-computed scan file produced by osv-scanner plus ecosystem audits.

What it does

Mode	Trigger	Output
Scheduled audit	Scheduled workflow → quant_autonomous_start	Open or update a single labelled GitHub issue (supply-chain-audit) with severity-ranked findings + an “Unpinned dependencies” section
Pull-request review	GitHub pull_request webhook → workflow → quant_autonomous_start	Post a single PR review comment via gh pr review. REQUEST_CHANGES only on a genuine high-risk finding — never blind-approve
Ad-hoc query	Chat the agent directly (dashboard, API, or via the Slack bot’s orchestrator)	A direct verdict with evidence — does the CVE affect the version and code path in use, and what’s the recommended action

The agent is read-only with respect to the repository under audit — it produces findings, never edits code. A separate gated remediation capability (see Remediation below) can open a real fix PR scoped strictly to pinning.

Methodology

For every mode, the agent applies the same shared methodology:

Check	What the agent does
Confirmed CVEs	Works from the upfront scan (osv-scanner + npm audit/pip-audit/composer audit). For each advisory, confirms it affects the version AND the code path actually in use before reporting it — drops theoretical or unreachable ones. Cites CVE / GHSA / OSV IDs.
Release age	Fetches each new or changed dependency’s registry publish date. A release less than 5 days old is an elevated-risk flag — fresh releases are a prime supply-chain-attack vector.
Supply-chain signals	Web-searches the package for compromise / malware / typosquatting reports; notes maintainer or ownership changes and sudden permission scopes.
Usage & criticality	Greps how the dependency is actually used in the repo. Weights prod/runtime high, dev/CI-only low — a risky dep that’s only a CI tool is lower priority than one in the request path.
Pinning audit (always)	Scans Dockerfiles (FROM, apt/apk), GitHub Actions (uses: on floating tags or branches), and package.json / composer.json / lockfiles for unpinned, floating, or range specifiers. Always highlights these — especially anything auto-accepted during a build.

Every finding cites file:line and the authority (CVE / OWASP / CWE / advisory link). Findings without that level of evidence are dropped, not softened — the agent uses Blocker / Warning / Nit severity buckets and only marks something a Blocker if there’s a demonstrable failure or a cited authority.

Scheduled audit

A workflow with a scheduled trigger fires on cron, runs quant_autonomous_start against the target repo with an audit task. Inside the autonomous container, the orchestrator runs the scanners up-front, persists .supply-chain/scan.json, then delegates analysis to the supply-chain agent.

What you get

A single GitHub issue per repo, labelled supply-chain-audit, idempotently updated on subsequent runs (find-or-update by label). The issue body contains:

• A short executive summary
• A severity table (🔴 High / 🟠 Medium / 🟡 Low)
• Each finding with file:line evidence and a cited authority
• A dedicated “Unpinned dependencies” section listing every floating ref

Setup

1. Create the workflow in the dashboard (AI Workflows → New). Add a trigger node set to scheduled and a tool node calling quant_autonomous_start.

2. Configure the tool input — for example:

   {
     "toolName": "quant_autonomous_start",
     "input": {
       "repo": "quantcdn/your-repo",
       "tasks": [
         "Run a READ-ONLY supply-chain audit of {{repo}}. Run osv-scanner + ecosystem audits into .supply-chain/scan.json. Delegate to the supply-chain agent. Publish ONE GitHub issue labelled supply-chain-audit with severity-ranked findings and an Unpinned dependencies section. Do not commit, push, or open PRs."
       ]
     }
   }

3. Set the cron on the trigger (e.g. 0 18 * * 0 for weekly Sunday 18:00). See workflow triggers for the schedule format.

4. Ensure the GitHub App is installed on the target repo so the autonomous container can clone and post the issue.

The first run opens the labelled issue; subsequent runs update it in place.

Pull-request review

A workflow with a webhook trigger (HMAC-authenticated) receives GitHub pull_request events. The dispatched job reviews the PR diff and posts a single review comment.

Self-filtering

GitHub fires pull_request for every PR and every action. The agent only reviews dependency PRs — author is dependabot[bot] or renovate[bot], or the diff touches a manifest / lockfile (or a GitHub Actions uses: / Dockerfile FROM line). For any other PR, it no-ops with a single-line note in the job logs and stops.

So you can point the webhook at every PR without spamming non-dep PRs with reviews.

What you get

A single PR review comment, posted via gh pr review --comment (or --request-changes if there’s a genuine merge-blocker — e.g. a non-existent action tag that would break CI). The comment follows the same Blocker / Warning / Nit structure as the audit findings.

Setup

1. Create the workflow with a webhook trigger configured for HMAC auth and a tool node calling quant_autonomous_start. The task templates the PR URL from the webhook payload:

   {
     "toolName": "quant_autonomous_start",
     "input": {
       "repo": "{{webhook.payload.repository.full_name}}",
       "tasks": [
         "Review the dependency pull request {{webhook.payload.pull_request.html_url}}. First confirm it is a dependency change; if not, no-op. Otherwise delegate to the supply-chain agent and post a single PR review comment via gh pr review."
       ]
     }
   }

2. Get the webhook URL and secret from the Triggers page (the URL is a Portal URL; the secret is the per-workflow webhook secret). See Webhook secrets for the reveal / rotate UX.

3. Configure the GitHub webhook on the target repo:

   • Payload URL: the Portal URL from step 2
   • Content type: application/json
   • Secret: the value from step 2
   • Events: “Pull requests”

GitHub never points at the backend AI API directly — webhooks always go through Portal, which verifies routing and forwards to the workflow engine with proper authentication.

Note

HMAC auth means GitHub signs each delivery with X-Hub-Signature-256 using your webhook secret. The backend verifies the signature; a tampered body or wrong secret returns 401 without ever starting the workflow.

Ad-hoc query (chat / Slack)

For one-off questions (“does CVE-X affect us in quantcdn/foo?”), chat the agent directly — no workflow setup required.

From the dashboard

Open the supply-chain agent and ask in the chat panel:

Does CVE-2021-23337 affect quantcdn/foo? Check whether the repo uses an affected version and where, then give a direct verdict.

The agent uses its GitHub-read tools to inspect the repo, applies the methodology, and answers with evidence:

Not affected. quantcdn/foo is a pure PHP/Apache repo — no package.json, no node_modules, zero lodash references. CI uses Docker Buildx only.

From Slack

Slack bots are bound to one agent (typically an orchestrator). The orchestrator can delegate to the supply-chain agent via call_agent — so the same question works from a Slack thread:

@quant audit quantcdn/foo for supply-chain risk

See Slack bots — agents and routing for the bot binding and routing model.

Remediation (optional, gated)

By default the agent is read-only — it never edits code or opens PRs. It highlights pinning; fixing it is a gated capability.

When enabled, the agent emits a machine-actionable remediation plan alongside the issue (or, in chat, after explicit user confirmation), and the autonomous code agent applies the plan — opening a real fix PR scoped strictly to pinning.

Scope (v1)

Pinning target	Auto-remediated?	Source of truth for the pin
GitHub Actions uses: foo/bar@<tag> → @<sha>	✅	Action repo’s git/refs/tags/<tag>
Dockerfile FROM <img>:<tag> → @sha256:<digest>	✅	Docker registry digest lookup
uses: foo/bar@main (branch) → @<sha>	✅	Latest release SHA (tag in a comment)
composer.json / package.json ranges → exact	❌ — manual recommendation in the issue
apt apt install foo → foo=<version>	❌ — manual recommendation in the issue
CVE-driven version bumps	❌ — always manual (carry regression risk)

The unsupported categories continue to be highlighted in the issue body — they’re just not auto-fixed yet.

The two gates

The gate lives in workflow config (or user intent), never on the GitHub webhook itself.

• Workflow flow — set remediate: true on the workflow’s tool.input. Default is off. The flag is per-workflow; toggle it in the workflow editor’s webhook-trigger node.
• Chat flow — the user’s explicit request gates it. “Resolve the pinning in quantcdn/foo” triggers it; “Does CVE-X affect us?” does not. The agent proposes the plan and waits for explicit confirmation in the same conversation before dispatching quant_autonomous_start.

The remediation PR

Whatever the entry point, the resulting PR is identical in shape:

• Branch: supply-chain/remediate-pin-<issue-N>
• Title: fix: pin supply-chain dependencies
• Body: Remediates: #N (or the chat session URL), plus a per-pin source citation
• Diff: only the pins from the plan — never version bumps, never adjacent edits
• Never auto-merged. A human reviews and merges.

Idempotency

A second remediation run updates the existing PR in place rather than opening duplicates. The branch and PR persist across runs, refreshed on each pass.

Honesty rule

A pin only lands in the plan if the SHA / digest resolves from a primary source (the action repo’s tag→ref endpoint, the Docker registry digest API). If the agent cannot resolve a ref authoritatively, the entry is omitted — the issue still flags it as unpinned, just without an automatic fix. The agent never guesses a SHA.

What it does NOT do

• It does not edit application code. Even when remediation is enabled, only pinning fixes are applied — never version bumps, refactors, or anything outside the plan.
• It does not auto-merge. Every remediation PR requires human review.
• It does not blind-approve PRs. In review mode, it posts a comment by default and only uses REQUEST_CHANGES for genuine high-risk findings.
• It does not bypass the audit’s read-only stance to “fix while it’s there.” Audit and remediation are separate passes.

See also

• Workflow triggers — webhook (HMAC) and scheduled trigger formats
• Webhook secrets — reveal vs rotate, GitHub webhook configuration
• Slack bots — agents and routing — calling the supply-chain agent from Slack
• Cloud agents overview — the full set of pre-built specialists