> For clean Markdown of this page, append .md to its URL. For the complete documentation index, see https://www.superagent.sh/llms.txt.


Generate dependency updates on demand or on a schedule and bring policy-cleared pull requests to review.

# Secure Dependency Updates

Secure Dependency Updates finds available dependency versions and proposes the
resulting manifest and lockfile changes as pull requests. Superagent generates
each update with pinned self-hosted Renovate tooling. Before Renovate pushes a
branch or opens a pull request, Superagent evaluates the exact proposed commit
through Kernel-backed supply chain checks. Proposals that Kernel flags or cannot
fully verify are never published. Immediately before opening a pull request,
Superagent reads the branch and base refs through Renovate's authenticated GitHub
client without using cached heads. Publication requires the exact approved commit
and reviewed base to remain unchanged. If verification fails, publication stops;
run diagnostics include a bounded failure category without host error details.

This complements [Supply chain scanning](https://www.superagent.sh/docs/security-workers/pr-security/supply-chain-scanning).
Secure Dependency Updates gates each proposal before publication. The Supply
Chain Scan checks the published pull request again before merge.

## Enable scheduled updates

Open **Repository**, select a repository, and find **Secure Dependency Updates**
in its settings. Choose a scope:

- **Vulnerabilities** (default)
- **Version updates**
- **All updates**

Then choose one schedule:

- **Off** disables new scheduled update runs. This is the default.
- **Daily** checks once per day.
- **Weekly** checks once per UTC week.
- **Monthly** checks once per UTC month.

The schedule is repository specific. Turning the setting off does not close
existing update pull requests.

Each live run on a private repository costs **5 credits** when it starts, whether
scheduled or manual, even if it fails or finds no updates. Public repository runs
and dry-runs cost no credits. Private free-plan runs cannot start when fewer than
5 credits remain; a queued manual run can also fail if other usage consumes the
remaining credits before it begins.

## Run updates manually

Organization owners can open a repository and select **Run now** in the
**Dependency updates** section header. The button uses the current scope.
You can run updates while the schedule is **Off** without enabling or changing
the schedule.

For automation, use the
[Dependency Updates API](https://www.superagent.sh/docs/api/dependency-updates) or the
[Superagent MCP server](https://www.superagent.sh/docs/mcp):

- `POST /api/v1/repositories/{repositoryId}/dependency-updates` starts a run.
  The optional `scope` is `vulnerabilities`, `versions`, or `all`; omit it to
  use the repository's saved scope.
- `GET /api/v1/dependency-updates/{runId}` polls the run status.
- MCP `trigger_dependency_updates(repository_id, scope?)` starts a run, and
  `get_dependency_update(run_id)` retrieves it.

The repository must belong to the API key's organization and have an active
Superagent Security GitHub App installation. An already active run returns
`409 conflict`. An inactive repository or installation, or a repository or run
outside the organization, returns `404 not_found`.

A `202 Accepted` response means the run is queued, not that a pull request has
been published. Status progresses through `queued` and `in_progress` to
`completed` or `failed`. Even a completed run can produce no pull requests.
The REST polling response includes a structured `summary`: inspect its outcome,
manifest counts, candidate counts, skips, and resolution failures. Missing counts
are unknown, not zero; `no_supported_dependencies` is an empty extraction, not
proof that the repository has no vulnerabilities.
Publication is asynchronous; use `dependency_update.published` to react when
an approved update actually reaches GitHub.

## Update scopes

### Vulnerabilities

Superagent uses GitHub's open Dependabot alerts alongside Renovate's OSV
(Open Source Vulnerabilities) advisory database. **Vulnerabilities** and **All
updates** require the Superagent Security GitHub App to have **Dependabot alerts:
Read** permission; existing installations must approve it before running.
OSV is additional coverage, not a fallback for missing GitHub permissions.
GitHub must expose alerts for its dependency-graph coverage to be available.

For npm dependencies, OSV checks require resolved lockfile versions rather than
manifest declarations. The pnpm adapter checks every supported resolved package
version, including transitive entries, without treating stale override values as
installed versions. npm and Yarn direct dependencies use Renovate's extracted
locked versions; other ecosystems retain native Renovate OSV behavior.

Renovate generates fixes for supported extracted dependencies and applicable
global overrides. For supported pnpm transitive findings, Superagent creates native lockfile-only
candidates without inventing manifest dependencies. If every resolved parent's
declared version range accepts the proposed fix, it may add an override scoped
to the vulnerable installed version in `pnpm-workspace.yaml` and let pnpm
regenerate the lockfile. It does not replace an existing override for that
package or force fixes outside parent ranges. Before committing a candidate,
it checks the proposed lockfile against the original advisory and blocks
publication when vulnerable versions remain or the result cannot be verified.
Incompatible parent constraints, unsupported lockfiles, and unproven override
applicability can still prevent a fix pull request. A detected advisory or a
completed run does not guarantee one.

### Version updates

Superagent checks direct dependencies for available versions. It does not
target every transitive dependency independently. Transitive packages can
still change when the package manager resolves the lockfile for an approved
direct update.

### All updates

Renovate checks security fixes and regular dependency updates in the same
repository run. Both kinds of proposals receive the same Kernel-backed supply
chain checks before publication and again before merge.

## Lockfile and manifest constraints

Secure Dependency Updates uses the repository's committed manifests and
lockfiles as the source of truth. Renovate invokes the repository's package
manager rather than editing resolved versions by hand. Existing workspace
boundaries, version ranges, peer requirements, overrides, resolutions,
catalogs, engine requirements, and lockfile format remain part of dependency
resolution.

A direct version proposal can intentionally update its declared manifest
requirement. Superagent does not bypass unrelated constraints to force an
update. A compatible pnpm transitive fix may add a version-specific workspace
override, which should be reviewed with the generated lockfile. Renovate may
also append an exact package-version entry to `minimumReleaseAgeExclude`, or
expand an existing entry such as `next@16.3.0` to `next@16.3.0 || 16.3.8`, so a
fresh security fix can install without waiting for pnpm's release-age delay.
Superagent accepts added union members only when the same proposed lockfile
introduces those exact versions for that package. Every existing exclusion remains
covered; new ranges, wildcards, and unrelated versions or workspace settings are
rejected. Existing legacy exclusion patterns can remain unchanged.
Kernel still evaluates every introduced package version before publication.
If a patched transitive version cannot be resolved through a supported Renovate
update, the repository owner may need to update the parent dependency, adjust an
override or resolution, or change the relevant version constraint before rerunning.
Superagent does not inject blanket security-floor overrides or run the retired
Dependabot fallback.

Review the generated lockfile and supply chain check results before merging.
An advisory being detected does not establish that every affected resolved
version was removed.

## How an update is created

For each repository run, Superagent:

1. Starts pinned self-hosted Renovate in an isolated sandbox against the default
   branch.
2. Provides a short-lived GitHub App token restricted to that repository. Live
   runs can write branches and pull requests; dry-runs receive read-only access.
3. Lets Renovate discover supported dependencies, query advisories, and
   resolve updates.
4. Holds each proposed commit before any push and evaluates its exact file
   changes through Kernel, including exact transitive lockfile deltas. Only
   approved proposals are pushed and opened or updated as pull requests.
5. Runs the normal pull request supply chain checks again on published pull
   requests.
6. Records observed Renovate pull requests and cleans up the sandbox.

Generated titles use `chore(bump): <update title>`. Pull request bodies are
Superagent-branded and retain the package update table, advisory details,
warnings, and available release notes. They do not include Renovate's
Configuration section, rebase/retry checkbox, or Mend Renovate CLI footer.
To run updates again, use **Run now** or the Dependency Updates API.

Automerge and repository scripts/plugins are disabled. Script suppression is
defense in depth, not credential isolation: package managers processing
repository files share the sandbox with the repository-scoped token.

## Package risk coverage

Generated npm, PyPI, Go, and RubyGems changes use the same managed package risk
pipeline as pull request supply chain scans. Evaluation includes exact versions
introduced by the generated lockfile, including transitive changes.

Kernel checks run before Renovate publishes anything. A proposal with a
blocking finding is skipped as `kernel-flagged`. A proposal whose delta cannot
be verified exactly, whose base is not the default branch, or whose analysis is
incomplete or fails is skipped as `kernel-inconclusive`. Evaluation is bound to
the exact proposed contents, so a changed commit cannot reuse an earlier
approval. If a prior run pushed a branch but did not create its pull request,
Renovate may reuse that branch without making another commit. Before opening the
pull request, Superagent reconstructs the entire base-to-head delta from GitHub
and runs a fresh Kernel review of that exact remote head. Missing files, a
changed base or head, and inconclusive or flagged reviews block publication.
Dry-runs use the same gate.

The published pull request is scanned again by the independent Supply Chain
Scan. A generated pull request is not a policy approval: review the generated
lockfile and check results before merging.

## Package managers

The enabled Renovate managers are JavaScript (`npm`, including npm, pnpm, and
Yarn projects), Python requirements files (`pip_requirements`), Go modules
(`gomod`), Ruby Bundler (`bundler`), Terraform (`terraform`), Dockerfiles
(`dockerfile`), and GitHub Actions (`github-actions`). Hidden source directories
such as `.github/actions` are included; recommended generated, vendor, example,
test, and `__fixtures__` directory exclusions remain in place. Hidden action
sources do not require widening discovery to executable test Gemfiles. Toolchain and catalog edits
without complete exact-delta scanner support are excluded.

Infrastructure updates do not imply Kernel package-intelligence coverage.
Parsed Terraform, Docker, and Actions changes are explicitly marked **Not
scanned** where managed package intelligence is unavailable. Exact infra pin
replacements may still be published so they can be reviewed; package changes in
the same proposal are still evaluated by Kernel. Unverified or non-dependency
edits block publication rather than passing as clean.
GitHub Actions publication requires the App's **Workflows: Read and write**
permission.

Renovate detects supported manifests throughout the repository. Superagent
controls scope and scheduling centrally; repository Renovate configuration and
`.github/dependabot.yml` are not used to configure these runs.

Private package registry credentials are not included in the initial release.
Update tasks that require a private registry fail without publishing a pull request and
record the failure for operational diagnostics.

Published updates appear as pull requests in GitHub.

To trigger your own automation when an approved update reaches GitHub,
subscribe an organization webhook to `dependency_update.published`. The event
includes the repository, persisted Renovate pull request observation ID, title,
and pull request URL. The run ID is `null` when no matching run was found. The
same publication also creates a home-page notification for organization owners.
See [Webhooks](https://www.superagent.sh/docs/webhooks) for the payload and signature format.

## Next steps

- [Understand supply chain scanning](https://www.superagent.sh/docs/security-workers/pr-security/supply-chain-scanning)
- [Subscribe to published updates with Webhooks](https://www.superagent.sh/docs/webhooks)
- [Validate dependency updates with Devin](https://www.superagent.sh/docs/use-cases/validate-dependency-updates-with-devin)

---
Source: https://www.superagent.sh/docs/security-workers/secure-dependency-updates
Index: https://www.superagent.sh/llms.txt