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. 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 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. 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 for the payload and signature format.

Next steps

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