Pull requests
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 the regular security scan.
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.
- Analyzes those versions inside an isolated sandbox.
- Correlates package behavior and metadata signals into actionable issues.
- Persists the scan and findings, then completes the GitHub check.
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 actionable supply chain issues were found.
- Failure — one or more changed dependencies contain actionable risks.
- 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
Actionable issues appear as inline review comments on the changed manifest, lockfile, or workflow line.
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.