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 job. 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.
Jobs 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.

Next steps

• PR Scans
• Supply chain scanning
• Repositories
• Install GitHub Apps