Dependabot Configuration Skill

Use this skill to create or review Dependabot configuration that keeps dependencies current without turning dependency automation into a supply-chain risk. The normal output is a proposed .github/dependabot.yml, optional Dependabot automation workflow guidance, and a validation plan using GitHub's own checks plus zizmor.

APM cannot deploy .github/dependabot.yml directly as a raw repository file. This skill helps agents create that file inside a future project when asked.

Use when

Use this skill for:

Creating or reviewing .github/dependabot.yml.
Enabling GitHub Actions, npm, NuGet, pip, uv, Docker, Terraform, devcontainer, Bicep-adjacent, or other ecosystem updates.
Configuring groups, multi-ecosystem groups, cooldown, registries, labels, reviewers, assignees, PR limits, or commit messages.
Auditing Dependabot config with zizmor.

Do not use it as the primary skill for:

General GitHub Actions workflow design with no dependency-update scope.
Runtime vulnerability triage after a dependency is already deployed.
Replacing Dependabot with Renovate as the main tool.
Auditing unrelated workflow vulnerabilities only.

Nearby skill collisions:

Use github-actions-ci-cd for workflow architecture, OIDC, and broad workflow hardening.
Use container, language, cloud security, or runtime skills for remediation outside dependency-update configuration.

Anti-hallucination rule

Dependabot configuration is version-sensitive. GitHub adds ecosystems and options regularly, and unsupported keys can silently prevent update jobs from running. Before writing a production .github/dependabot.yml, verify these surfaces against current official documentation or the target repository:

Supported package-ecosystem values and package-manager version support.
Whether the target uses directory or directories. Do not use both in one update block.
Whether each ecosystem supports cooldown, vendor, private registries, and indirect dependency updates.
Exact group and multi-ecosystem group syntax.
Whether configuration options affect security updates as well as version updates. GitHub marks shared options in the options reference, but target-branch changes the behavior.
Private registry authentication mode: automatic GitHub Packages access, Dependabot secrets, organization-level private registries, or OIDC.
Current zizmor audit names and CLI flags.

Never invent ecosystem names, registry types, action SHAs, or config keys from memory. If verification is blocked, return a labelled skeleton with [VERIFY] markers rather than production-shaped YAML.

Source of truth

Use these sources before writing current configuration:

GitHub Docs, Dependabot options reference: https://docs.github.com/en/code-security/dependabot/working-with-dependabot/dependabot-options-reference
GitHub Docs, supported ecosystems: https://docs.github.com/en/code-security/dependabot/ecosystems-supported-by-dependabot/supported-ecosystems-and-repositories
GitHub Docs, multi-ecosystem updates: https://docs.github.com/en/code-security/how-tos/secure-your-supply-chain/secure-your-dependencies/configuring-multi-ecosystem-updates
GitHub Docs, private registries: https://docs.github.com/en/code-security/dependabot/working-with-dependabot/configuring-access-to-private-registries-for-dependabot
GitHub Docs, automating Dependabot with GitHub Actions: https://docs.github.com/en/code-security/dependabot/working-with-dependabot/automating-dependabot-with-github-actions
Azure Bicep issue tracking Dependabot API-version scanning: https://github.com/Azure/bicep/issues/8324
Azure Bicep issue tracking Azure resource provider scanning: https://github.com/Azure/bicep/issues/18465
Azure Bicep Registry Modules issue for Dependabot module support: https://github.com/Azure/bicep-registry-modules/issues/452
Dependabot Core releases: https://github.com/dependabot/dependabot-core/releases
zizmor audits reference: https://docs.zizmor.sh/audits/
zizmor usage, configuration, installation, and integrations: https://docs.zizmor.sh/usage/, https://docs.zizmor.sh/configuration/, https://docs.zizmor.sh/installation/, https://docs.zizmor.sh/integrations/

Current upstream snapshot from research: Dependabot Core v0.383.0 was the latest public release observed on 2026-06-24. Treat that as context, not a version pin for GitHub-hosted Dependabot.

Observed github.com/lukemurraynz public repository languages include C#, MDX, TypeScript, Rust, Go, Bicep, PowerShell, JavaScript, Shell, HTML, CSS, Python, TypeSpec, HCL, Dockerfile, Makefile, and PLpgSQL. Default suggestions should cover these ecosystems where Dependabot supports them and use explicit fallback guidance where it does not.

Required inputs

Before creating a config, inspect or ask for:

Repository type: app, library, infrastructure, documentation, monorepo, or package source.
Dependency manifests and lockfiles by directory.
Package ecosystems in use, including GitHub Actions and devcontainer files.
Default branch, release branches, and whether non-default branch updates are required.
Private registry needs and whether credentials can use GitHub Packages automatic access, Dependabot secrets, organization private registries, or OIDC.
Review model: labels, assignees, reviewers, CODEOWNERS, branch protection, merge queue, and auto-merge policy.
Update cadence and PR volume tolerance.
Whether GitHub Advanced Security code scanning is available for SARIF.

Configuration workflow

Inventory manifests.
- Search for dependency manifests and lockfiles.
- Include .github/workflows/** with package-ecosystem: github-actions.
- Include .devcontainer/** with package-ecosystem: devcontainers when devcontainer metadata is present.
- For Azure Bicep repos, do not invent package-ecosystem: bicep. GitHub Docs do not list Bicep as a supported Dependabot ecosystem. Add Bicep validation and AVM-update guidance instead.
Choose update blocks.
- Use one update block per ecosystem and dependency root unless directories safely covers all roots for that ecosystem.
- Prefer directories for monorepos when package roots share the same schedule, reviewers, labels, and registry access.
- Keep unrelated ecosystems separate unless a multi-ecosystem group has a clear operational reason.
Set cadence and volume controls.
- Start with weekly version updates for most ecosystems.
- Use daily checks for GitHub Actions or critical runtime dependencies only when the team can handle the PR flow.
- Set open-pull-requests-limit per ecosystem. Five is a practical default for active repos; lower it for low-maintenance projects.
- Add cooldown.default-days: 7 for version updates unless the ecosystem or business requirement needs faster adoption. Cooldown does not delay security updates.
Group routine updates.
- Use groups to reduce noise within one ecosystem.
- Prefer separate groups for production, development, toolchain, and test dependencies when the ecosystem supports dependency-type filtering.
- Use update-types: ["minor", "patch"] inside groups. Use version-update:semver-* values only for allow and ignore rules.
- Use multi-ecosystem groups only for dependencies that are released and reviewed together, such as Terraform providers plus Docker base images for one infrastructure stack.
- Multi-ecosystem groups require a top-level multi-ecosystem-groups section, a matching multi-ecosystem-group value in each update block, and patterns in each participating ecosystem. Use ["*"] only when every dependency in that ecosystem should join the cross-ecosystem PR.
Preserve security update behavior.
- Enable Dependabot security updates and alerts in repository or organization settings; .github/dependabot.yml customizes PR behavior but is not the same as the alerts switch.
- Do not group security updates across different ecosystems. GitHub states security update grouping is per ecosystem and does not mix security and version updates.
- Avoid target-branch unless the repo intentionally updates a non-default branch. Some shared options stop affecting default-branch security update PRs when target-branch is used.
Configure private registries safely.
- For GitHub Packages and Container registry, prefer automatic Dependabot access through package access settings before adding PAT-based registry entries.
- For third-party registries, use Dependabot secrets or organization-level private registry configuration.
- Prefer OIDC for supported private registries such as AWS CodeArtifact, Azure DevOps Artifacts, Cloudsmith, Google Artifact Registry, and JFrog Artifactory.
- Never put tokens, passwords, or PATs directly in dependabot.yml.
Harden execution.
- Keep insecure-external-code-execution absent or explicitly deny.
- This option is documented for bundler, mix, and pip. Do not add it to ecosystems that do not support it.
- Allow it only after a documented risk decision. If enabled, Dependabot limits code execution to registries attached to that update block, but the supply-chain risk remains.
Validate.
- Run GitHub's Dependabot configuration validation through the repository UI or the next Dependabot run.
- Run zizmor --collect=dependabot . for Dependabot-only checks.
- Run zizmor --collect=all . when workflow automation is also changed.
- If Advanced Security is available, upload zizmor SARIF and enforce code scanning thresholds with rulesets.

Ecosystem mapping for Luke's common repositories

Use this map when scanning repositories under github.com/lukemurraynz or similarly mixed Azure engineering repos. Add only ecosystems with matching files in the target repository.

Recommended mapping:

.github/workflows/*.yml → github-actions.
package.json, npm, pnpm, or yarn → npm.
Bun manifests → bun.
*.csproj or Directory.Packages.props → nuget.
global.json with a .NET SDK pin → dotnet-sdk.
requirements*.txt, pyproject.toml, Poetry, or Pipenv → pip.
uv.lock or uv project metadata → uv.
go.mod → gomod.
Cargo.toml or Cargo.lock → cargo.
rust-toolchain.toml → rust-toolchain.
Dockerfile or Docker tags in Kubernetes or Helm files → docker.
docker-compose.yml → docker-compose.
*.tf or *.tf.lock.hcl → terraform.

Real-world scenario: AsyncAPI npm compromise (July 2026)

The AsyncAPI npm supply chain compromise (Microsoft Security blog, July 15 2026) is a worked example of why npm-ecosystem Dependabot configuration matters. The attack chain: a GitHub Actions pwn request allowed an attacker to deliver a payload at npm import time via the AsyncAPI package.

When reviewing or designing .github/dependabot.yml for an npm-ecosystem repo, this incident reinforces:

Enable Dependabot security updates (github-actions and npm ecosystems at minimum). Security-only updates catch vulnerable transitive dependencies that pwn-request-style attacks exploit.
Group security updates separately from feature updates so a CVE-driven bump is not blocked by a major-version review.
Use allow/ignore lists deliberately. Auto-bumping high-risk dependencies (build tooling, GitHub Actions, codegen) without a pinning strategy creates the exact surface this attack abused.
Pair with github-actions-ci-cd skill for pull_request_target / workflow_run hardening. Dependabot alone cannot stop pwn-request attacks; the workflow permissions block must.

Do not add Dependabot blocks for plain MDX, Markdown, HTML, CSS, Shell, PowerShell, TypeSpec, Makefile, or PLpgSQL unless a supported manifest also exists in the same repository.

Bicep and AVM guidance

Dependabot does not currently have a documented bicep package ecosystem. Requests for Bicep API-version and module update support are tracked in Azure Bicep and Azure Bicep Registry Modules issues, but they are not listed as supported Dependabot ecosystems in GitHub Docs.

For Bicep repositories:

Do not generate package-ecosystem: "bicep".
Include github-actions, docker, terraform, opentofu, devcontainers, nuget, npm, pip, uv, or other supported ecosystems that appear beside the Bicep code.
For AVM Bicep modules, use the update-avm-modules-in-bicep skill. It queries MCR tags for br/public:avm/... module versions and reviews module changelogs before changing versions.
For Bicep API versions, rely on bicep build, bicep lint, and the Bicep linter rule for recent module versions where applicable. Do not treat API version bumps as low-risk dependency updates.
For GitHub Actions deployments of Bicep, prefer OIDC with Azure Login and run what-if before deployment. Use azure-deployment-preflight or github-actions-ci-cd for the workflow design.
If a repo publishes reusable Bicep modules, keep module versioning explicit. Avoid a floating latest pattern unless the target registry and policy explicitly support it and the team accepts breaking-change risk.

Recommended defaults

Use these defaults for new repositories unless the project has stronger local policy:

version: 2 and explicit update blocks for every detected ecosystem.
package-ecosystem: github-actions for .github/workflows.
Weekly version updates for application dependencies.
Daily or weekly GitHub Actions updates, depending on review capacity.
cooldown.default-days: 7 for version updates.
open-pull-requests-limit: 5 per ecosystem.
labels: ["dependencies"], plus ecosystem labels such as npm, nuget, github-actions, or docker.
commit-message.prefix: "chore(deps)" and include: "scope" for repos using Conventional Commits.
Separate major updates from patch/minor groups when the ecosystem supports group update-type filtering.
Avoid auto-merge for runtime production dependencies and major updates.
For ecosystems where immediate updates are risky, prefer cooldown over disabling updates. GitHub's Dependabot Core release notes include ongoing cooldown fixes, so keep this behavior verified against current docs.
Allow auto-merge only for low-risk patch updates after required checks pass, and only through branch protection or merge queue controls.

Stop conditions

Stop and return a design-level plan instead of final YAML when:

The repository has private dependencies but no registry access model.
The user asks for auto-merge but required status checks or branch protection are absent.
A workflow uses pull_request_target, workflow_run, or actor checks to grant extra power to Dependabot PRs without a threat model.
The generated config would require long-lived PATs where OIDC or automatic GitHub Packages access is available.
The exact ecosystem, registry type, or grouping syntax cannot be verified.
The project uses another dependency bot and the user has not confirmed that Dependabot should coexist with or replace it.

Dependabot and GitHub Actions automation

Dependabot can trigger GitHub Actions workflows on its pull requests. GitHub warns that Dependabot always runs on GitHub Actions when enabled, bypassing Actions policy checks and repository or organization Actions disablement. Treat Dependabot workflows as privileged automation surfaces.

Rules for automation:

Prefer pull_request, not pull_request_target, for Dependabot PR checks.
Check github.event.pull_request.user.login == 'dependabot[bot]' rather than only github.actor == 'dependabot[bot]'.
Use dependabot/fetch-metadata to classify dependency name, dependency type, and update type before labelling or auto-merging.
Give automation workflows the smallest permissions possible.
Store workflow-needed secrets as Dependabot secrets when Dependabot PRs need them. GitHub Actions secrets are not automatically available in the same way.
Require all normal checks before merge. If a merge queue is used, the built-in GITHUB_TOKEN cannot add PRs to the queue; use a GitHub App token only after explicit approval.

zizmor validation

Use zizmor as the standard static security check for Dependabot and GitHub Actions configuration.

Important audits for Dependabot work:

dependabot-cooldown checks for missing or insufficient cooldown.
dependabot-execution detects insecure-external-code-execution: allow.
bot-conditions detects spoofable bot checks around privileged workflows.
dangerous-triggers detects risky triggers such as pull_request_target and workflow_run.
template-injection detects untrusted expression expansion into scripts.
unpinned-uses detects unpinned action references.
known-vulnerable-actions detects actions with known vulnerabilities.
excessive-permissions detects overbroad workflow token permissions.
archived-uses, typosquat-uses, cache-poisoning, artipacked, and adhoc-packages catch common workflow supply-chain defects.

Useful commands:

zizmor --collect=dependabot .
zizmor --collect=all .
zizmor --persona=pedantic --collect=all .
zizmor --format=sarif --collect=all . > zizmor.sarif
zizmor --format=github --collect=all .

Suppression rules:

Prefer fixing findings over suppressing them.
Use inline comments only for precise false positives, for example # zizmor: ignore[template-injection].
Use zizmor.yml or .github/zizmor.yml for repository-level ignore and severity remap policy.
Run with --no-ignores periodically to review the suppressed surface.

SARIF caveat: zizmor SARIF output is intended for GitHub code scanning and can exit successfully even when findings are present. Enforce thresholds with GitHub code scanning rulesets or an additional non-SARIF blocking run.

Output contract

When creating or reviewing Dependabot configuration, return:

A repository dependency inventory by ecosystem and directory.
The proposed .github/dependabot.yml or a focused patch.
Private registry and secret requirements, if any.
Grouping and PR-volume rationale.
Security update behavior and auto-merge policy.
zizmor validation commands and expected gates.
Remaining [VERIFY] items with links or commands to resolve them.

Templates

Use these bundled templates as starting points, then adapt them to the target repository:

Safe degraded output

If you cannot inspect the repository or verify current docs, provide a minimal safe skeleton:

version: 2
updates:
  - package-ecosystem: "github-actions"
    directory: "/"
    schedule:
      interval: "weekly"
    cooldown:
      default-days: 7

Then list [VERIFY] markers for every missing ecosystem, directory, group, registry, reviewer, label, and automation decision.

/dependabot-configuration

SKILL.md