# Dependency Updates — Renovate, Dependabot, Cadence, Controlled Rollout, and Compatibility Testing

> **Intro:** Dependency updating is not a bot problem. It is a release-governance and compatibility-risk problem with automation in the middle.
>
> **What this page includes**
>
> * how Renovate and Dependabot fit into a secure update program
> * cadence choices by dependency type
> * controlled rollout patterns
> * compatibility-testing expectations

## Why teams struggle here

Most dependency-update failures are not caused by the update tool itself. They come from one of four root problems:

1. **too many PRs at once**;
2. **no grouping or rollout strategy**;
3. **no compatibility tests beyond compile/unit tests**;
4. **no ownership model for riskier updates**.

## Renovate vs Dependabot

| Topic                     | Renovate                                              | Dependabot                                             |
| ------------------------- | ----------------------------------------------------- | ------------------------------------------------------ |
| Configuration flexibility | broader and deeper                                    | simpler and more native to GitHub                      |
| Grouping / policy tuning  | very rich                                             | good and improving, simpler for many teams             |
| Auto-merge controls       | strong and highly configurable                        | workable with native GitHub protections                |
| Best fit                  | mixed ecosystems, larger repos, custom rollout policy | GitHub-native repos needing straightforward automation |

## The real design decision

Do not ask "Which bot is better?" first. Ask:

* which ecosystems we update;
* how many repos and manifests we manage;
* how much grouping, scheduling, and policy control we need;
* whether we need a multi-ecosystem rollout strategy.

## Update cadence by dependency type

| Dependency class                                | Suggested cadence                       | Why                                                |
| ----------------------------------------------- | --------------------------------------- | -------------------------------------------------- |
| direct internet-facing framework / runtime deps | daily or weekly                         | high exploitability, high exposure                 |
| security tooling and scanners                   | weekly                                  | keep detections current without uncontrolled drift |
| transitive libraries                            | weekly or grouped                       | noise control with regular freshness               |
| infra dependencies (Docker, Terraform, Actions) | weekly                                  | needs compatibility validation with environments   |
| low-risk internal libs                          | weekly or biweekly                      | balance churn and freshness                        |
| major version jumps                             | explicit campaign, not blind auto-merge | usually needs human change review                  |

## Controlled rollout model

```mermaid
flowchart LR
  A[Bot opens PR] --> B[Static / unit / lockfile checks]
  B --> C[Integration and compatibility tests]
  C --> D[Low-risk group auto-merge or manual approval]
  D --> E[Staging soak / canary where needed]
  E --> F[Production promotion]
```

### Good rollout pattern

* auto-merge only **small, low-risk, green** updates;
* group related updates so reviewers see fewer, more meaningful PRs;
* separate **security hotfix updates** from **routine hygiene updates**;
* stage risky updates behind canary or lower environment validation;
* use rollback-friendly deployment patterns for runtime/library jumps.

## Compatibility testing expectations

| Test layer                       | Why it matters                                               |
| -------------------------------- | ------------------------------------------------------------ |
| lockfile / reproducibility       | ensures the intended dependency graph is actually what ships |
| unit tests                       | catches obvious local breakage                               |
| integration tests                | catches protocol, DB, auth, and API behavior changes         |
| contract / consumer-driven tests | catches upstream / downstream incompatibilities              |
| smoke tests in staging           | catches environment-specific packaging/runtime issues        |
| canary or phased rollout         | catches production-shape behavior without full blast radius  |

### Important rule

A dependency update that passes unit tests but breaks auth middleware, serialization, TLS behavior, migrations, or runtime packaging is still a failed update program.

## Dependabot example

```yaml
version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
    open-pull-requests-limit: 5
    groups:
      patch-and-minor:
        patterns:
          - "*"
        update-types:
          - "minor"
          - "patch"
```

## Renovate example

```json
{
  "extends": ["config:recommended"],
  "schedule": ["after 9pm every weekday"],
  "packageRules": [
    {
      "matchUpdateTypes": ["patch", "minor"],
      "groupName": "safe-weekly-batch",
      "automerge": true,
      "platformAutomerge": false
    },
    {
      "matchUpdateTypes": ["major"],
      "dependencyDashboardApproval": true,
      "automerge": false
    }
  ]
}
```

## Review and approval rules

| Update type                                   | Suggested policy                                          |
| --------------------------------------------- | --------------------------------------------------------- |
| patch / low-risk minor                        | auto-merge after required checks where confidence is high |
| auth, crypto, serialization, database drivers | explicit reviewer with domain context                     |
| major framework/runtime                       | manual approval + staging validation + rollback plan      |
| build / deploy plane components               | release-engineering or platform-owner review              |

## Security-specific best practices

* keep dependency manifests and lockfiles in source control;
* treat update bots as **change producers**, not decision makers;
* use PR templates that call out **security relevance** and **breaking-change risk**;
* test compatibility across **runtime, build, and deployment** planes;
* avoid letting update volume outrun reviewer capacity;
* create a separate fast lane for **known-vulnerable dependencies**.

## Related pages

* [Commit to Deployment Security Control Plane](/devsecops-cicd-and-supply-chain/index-1/commit-to-deploy-security-repository-pipeline-runners-secrets-approvals-provenance-and-release-contr.md)
* [Repository Governance, CODEOWNERS, SECURITY.md, and Default Files](/devsecops-cicd-and-supply-chain/index-1/repository-governance-codeowners-security-md-and-default-files.md)
* [Release Governance — Security Sign-Off, Quality Gates, Acceptance Criteria, and Escalation](/devsecops-cicd-and-supply-chain/index-1/release-governance-security-signoff-quality-gates-acceptance-criteria-and-escalation.md)
* [SCA, SBOM, and Supply-Chain Tooling — Legacy vs Current](/devsecops-cicd-and-supply-chain/index-1/sca-sbom-and-supply-chain-tooling-legacy-vs-current.md)

***

*Author attribution: Ivan Piskunov, 2026 - Educational and defensive-engineering use.*


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.product-security.expert/devsecops-cicd-and-supply-chain/index-1/dependency-updates-renovate-dependabot-cadence-controlled-rollout-and-compatibility-testing.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.