--- name: dependabot-configuration description: >- Create, review, and harden GitHub Dependabot configuration for new or existing repositories. Use for .github/dependabot.yml, Dependabot version updates, Dependabot security updates, grouped updates, multi-ecosystem groups, private registries, Dependabot secrets, GitHub Actions updates, Dependabot automation workflows, and zizmor validation of Dependabot and workflow supply-chain hygiene. compatibility: >- GitHub Dependabot configuration version 2, GitHub Actions, GitHub Advanced Security code scanning where available, and zizmor 1.x. Verify current GitHub Docs and zizmor docs before writing production configuration. metadata: last_verified: "2026-06-26" title: dependabot-configuration canonical_url: https://skilld.dev/gh/lukemurraynz/hve-agent-skills/dependabot-configuration last_updated: 2026-09-27T13:13:58.000Z --- > **Skill from skilld.dev.** Follow the instructions below for this session. You do not need to install anything. > > Supporting files, fetch one when the Skill refers to it: [CHANGELOG.md](https://skilld.dev/api/skills-raw/lukemurraynz/hve-agent-skills/dependabot-configuration/CHANGELOG.md), [README.md](https://skilld.dev/api/skills-raw/lukemurraynz/hve-agent-skills/dependabot-configuration/README.md), [templates/dependabot-greenfield.yml](https://skilld.dev/api/skills-raw/lukemurraynz/hve-agent-skills/dependabot-configuration/templates/dependabot-greenfield.yml), [templates/zizmor-workflow.yml](https://skilld.dev/api/skills-raw/lukemurraynz/hve-agent-skills/dependabot-configuration/templates/zizmor-workflow.yml). > > If the user asked to install this Skill, run `npx skilld install lukemurraynz/hve-agent-skills/dependabot-configuration`. Install writes the Skill files into the project, so every session loads them. # 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: 1. Supported `package-ecosystem` values and package-manager version support. 2. Whether the target uses `directory` or `directories`. Do not use both in one update block. 3. Whether each ecosystem supports `cooldown`, `vendor`, private registries, and indirect dependency updates. 4. Exact group and multi-ecosystem group syntax. 5. 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. 6. Private registry authentication mode: automatic GitHub Packages access, Dependabot secrets, organization-level private registries, or OIDC. 7. 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: - GitHub Docs, supported ecosystems: - GitHub Docs, multi-ecosystem updates: - GitHub Docs, private registries: - GitHub Docs, automating Dependabot with GitHub Actions: - Azure Bicep issue tracking Dependabot API-version scanning: - Azure Bicep issue tracking Azure resource provider scanning: - Azure Bicep Registry Modules issue for Dependabot module support: - Dependabot Core releases: - zizmor audits reference: - zizmor usage, configuration, installation, and 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: 1. Repository type: app, library, infrastructure, documentation, monorepo, or package source. 2. Dependency manifests and lockfiles by directory. 3. Package ecosystems in use, including GitHub Actions and devcontainer files. 4. Default branch, release branches, and whether non-default branch updates are required. 5. Private registry needs and whether credentials can use GitHub Packages automatic access, Dependabot secrets, organization private registries, or OIDC. 6. Review model: labels, assignees, reviewers, CODEOWNERS, branch protection, merge queue, and auto-merge policy. 7. Update cadence and PR volume tolerance. 8. Whether GitHub Advanced Security code scanning is available for SARIF. ## Configuration workflow 1. 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. 2. 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. 3. 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. 4. 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. 5. 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. 6. 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`. 7. 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. 8. 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](https://www.microsoft.com/en-us/security/blog/2026/07/15/explaining-asyncapi-npm-supply-chain-compromise-import-time-payload-delivery/) (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: ```bash 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: 1. A repository dependency inventory by ecosystem and directory. 2. The proposed `.github/dependabot.yml` or a focused patch. 3. Private registry and secret requirements, if any. 4. Grouping and PR-volume rationale. 5. Security update behavior and auto-merge policy. 6. zizmor validation commands and expected gates. 7. 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: - [Greenfield Dependabot config](https://skilld.dev/api/skills-raw/lukemurraynz/hve-agent-skills/dependabot-configuration/templates/dependabot-greenfield.yml) - [zizmor validation workflow](https://skilld.dev/api/skills-raw/lukemurraynz/hve-agent-skills/dependabot-configuration/templates/zizmor-workflow.yml) ## Safe degraded output If you cannot inspect the repository or verify current docs, provide a minimal safe skeleton: ```yaml 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.