Superagent scans dependency changes in pull requests before they reach your default branch. The Superagent Supply Chain Scan runs as a separate GitHub check alongside the regular security scan.

How it works

When a pull request changes a supported dependency file, Superagent:

1. Compares the pull request head with its base commit.
2. Resolves the exact added or upgraded dependency versions.
3. Analyzes those versions with static package and metadata rules inside an isolated sandbox.
4. Feeds candidate risks to a Kimi K3-powered Claude Code verifier in the same sandbox so it can inspect the exact published artifacts without another sandbox startup.
5. Publishes and persists only risks confirmed by the sandboxed verifier, then completes the GitHub check. Candidate signals and their verification verdicts remain attached to the scan result for auditability.

Removed and unchanged dependency versions are not scanned as new pull request risks.

Supported dependency files

Ecosystem	Files
npm	package.json, package-lock.json, npm-shrinkwrap.json, yarn.lock, pnpm-lock.yaml
PyPI	requirements.txt and named requirement files such as requirements-dev.txt
Go	go.mod
RubyGems	Gemfile.lock
GitHub Actions	.github/workflows/*.yml and .github/workflows/*.yaml

Superagent uses committed lockfiles and exact pins when they are available. If a changed dependency cannot be resolved to an exact version, the check reports an inconclusive result instead of treating the package as clean.

GitHub Action tags and branches are resolved to commit SHAs before analysis.

Check results

The check can complete with:

• Success: no candidate risks were found, or sandboxed verification rejected all candidates as false positives.
• Failure: the sandboxed verifier confirmed one or more actionable risks.
• Neutral: Superagent could not resolve, analyze, or conclusively verify a changed dependency.

If your branch protection rules require Superagent Supply Chain Scan, a failed or neutral result prevents merge until the check passes or your repository policy allows an override.

Inline findings

Verified actionable issues appear as inline review comments on the changed manifest, lockfile, or workflow line. Static scanner candidates are not published unless the sandboxed Claude Code verifier confirms them with concrete artifact evidence.

Superagent groups correlated rule matches by dependency and diff location. For example, six related behavioral signals on one GitHub Action are presented as one supply chain issue, with the individual signals retained in the finding evidence and check details.

Rerunning the scan on a new commit does not post the same grouped issue again. Findings that cannot be mapped to a valid diff line fall back to a pull request summary comment.

Remediate a finding

To clear a failed check:

1. Remove, replace, or update the flagged dependency.
2. Commit the corrected manifest, lockfile, or workflow.
3. Push the commit to the pull request.

Superagent scans the new dependency delta automatically. When no actionable dependency change remains, the check passes. Resolving the GitHub review conversation without changing the dependency does not change the check result.

Enable or deactivate scanning

Supply chain scanning is enabled by default for repositories connected to the Superagent Security GitHub App.

To change it:

1. Open Repository in Superagent.
2. Select the repository.
3. Find Supply Chain Scan in the repository settings.
4. Turn the setting on or off.

Deactivating the setting prevents new supply chain checks from starting for that repository. It does not remove historical GitHub checks or comments.

Detection scope

Supply chain scanning focuses on suspicious package behavior and metadata, including install hooks, process execution, network activity, obfuscation, sensitive file access, persistence behavior, and package identity concerns.

It is not a replacement for vulnerability, license, or software-bill-of-materials tooling.

Next steps

• PR Scans
• Repositories
• Install GitHub Apps