// pr scans
Supply chain scanning
Detect risky dependency changes in pull requests with grouped inline findings and a dedicated GitHub check.
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 security scanning. Together they are PR Scans: the security scan reviews the diff; this scan reviews added or upgraded packages.
How it works
When a pull request changes a supported dependency file, Superagent:
- Compares the pull request head with its base commit.
- Resolves the exact added or upgraded dependency versions.
- Inspects exact versions for direct dependency changes in an isolated browser session.
- Extracts structured security signals and uses an LLM to assign a risk score, severity, and evidence.
- Publishes high scoring, high severity policy blocking risks, persists lower confidence signals for auditability, and completes the GitHub check.
Removed, unchanged, and transitive 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 policy blocking risks were found. Nonblocking warning or monitoring signals may still appear in the check details.
- Failure: package policy marked one or more supply chain risks as blocking.
- Neutral: Superagent could not resolve or fully analyze 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
Policy blocking issues appear as inline review comments on the changed manifest, lockfile, or workflow line. Warning and monitoring signals remain nonblocking.
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:
- Remove, replace, or update the flagged dependency.
- Commit the corrected manifest, lockfile, or workflow.
- 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:
- Open Repository in Superagent.
- Select the repository.
- Find Supply Chain Scan in the repository settings.
- 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.
The same pipeline is available on demand through package scoring when an agent is about to install a package. Score a coordinate such as npm:lodash@4.17.21 from Agents → Context, POST /api/v1/context/package, or the MCP tool scan_package.