Secure Dependency Updates finds available dependency versions and proposes the resulting manifest and lockfile changes as pull requests. Superagent generates each update with pinned open source Dependabot tooling, evaluates supported package changes, and publishes only proposals that satisfy supply chain policy.

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.

Update scopes

Vulnerabilities

Superagent targets dependencies affected by known security advisories, including transitive dependencies recorded in the lockfile. It uses repository Dependabot alerts when available. If the repository does not expose them, Superagent parses exact lockfile versions and queries the global GitHub Advisory Database. Repository-level Dependabot does not need to be enabled for this fallback.

Each affected package and patched range is passed to the pinned Dependabot updater as a security-only update task. A pull request is created only when the package manager can resolve a non-vulnerable version under the repository's current manifest and lockfile constraints.

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

Superagent runs vulnerability remediation first, then checks direct dependencies for version updates. Security and version proposals pass through the same package-risk policy and publication safeguards.

Lockfile and manifest constraints

Secure Dependency Updates uses the repository's committed manifests and lockfiles as the source of truth. Dependabot 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 without changes the updater cannot safely determine, the run records security_update_not_possible and does not create a pull request. The repository owner can then update the parent dependency, adjust an override or resolution, or change the relevant version constraint before rerunning.

An updater can also report security_update_not_possible because of a package manager limitation even when declared ranges allow the patched version. For pnpm workspaces, Superagent verifies that outcome and can fall back to explicit exact-version security floors in pnpm-workspace.yaml, regenerate the lockfile with scripts disabled, and evaluate the complete resulting delta with Socket. This fallback is used only for affected versions and is not a general transitive version refresh.

How an update is created

For each configured or detected package manager, Superagent:

1. Resolves the current default branch to an exact commit.
2. Runs a pinned Dependabot CLI and package manager updater in an isolated sandbox with repository read access.
3. Records the generated dependency files as an immutable private artifact.
4. Evaluates the complete generated dependency delta where package risk scoring is supported.
5. Publishes an approved update from the recorded base commit with a separate, short lived GitHub write credential.
6. Runs the normal pull request checks after GitHub opens the pull request.

The update runner never receives repository write access. A changed default branch supersedes an unpublished proposal instead of applying stale files.

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.

If a blocking risk is found, or an exact supported dependency change cannot be evaluated, Superagent records the skipped proposal and does not open a pull request.

Dependabot supports additional package managers. Superagent can generate those updates, but package risk scoring does not cover every ecosystem yet. An unsupported update can be published with a clear Not scanned disclosure in the pull request. It is never represented as clean.

GitHub Actions updates require the Superagent Security GitHub App to have Workflows: Read and write permission. Existing installations must approve that permission before Superagent can publish workflow file updates.

Package managers

The update engine supports Dependabot Core managers, including JavaScript, Python, Go, Ruby, Rust, Java, .NET, PHP, Dart, Swift, Docker, GitHub Actions, Terraform, OpenTofu, Helm, Bazel, Nix, and related manifest formats.

Superagent uses .github/dependabot.yml manager and directory entries when the file is present. Otherwise, it detects known manifests throughout the repository. Superagent controls the daily, weekly, or monthly execution schedule from repository settings.

The initial release does not translate Dependabot allow, ignore, groups, registries, or nonzero pull request limit options. A repository using those options fails the scheduled run with an explicit configuration error instead of silently ignoring its policy.

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