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. Renovate opens the pull request, and Superagent evaluates supported package changes through Kernel-backed supply chain checks before merge.

This complements Supply chain scanning. Secure Dependency Updates creates the pull request. 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.

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 or the Superagent MCP server:

• 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 or injecting overrides. 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. pnpm's resolver can still reject a fix because of parent constraints; blocked findings remain explicit. Parent-scoped or nested overrides are skipped when applicability cannot be proven safely. A detected advisory or a completed run does not guarantee a fix pull request.

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 generated pull requests receive the same Kernel-backed supply chain checks 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. 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 custom 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, resolve updates, and create or update pull requests.
4. Runs the normal pull request supply chain checks through Kernel for supported dependency changes, including exact transitive lockfile deltas.
5. Records observed Renovate pull requests and cleans up the sandbox.

Generated titles use chore(bump): <update title>. 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.

Checks happen after Renovate opens the pull request. A generated pull request is not a policy approval: review blocking risks, unresolved dependency changes, and check failures before merging. Kernel checks remain independent of the update runner.

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; unverified or non-dependency edits remain unresolved 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, proposal and run IDs, title, and pull request URL. See Webhooks for the payload and signature format.

Next steps

• Understand supply chain scanning
• Subscribe to published updates with Webhooks
• Validate dependency updates with Devin