Add Egress Allowlist Domain

Step 4 — Place the entry

First, confirm it isn't already allowed:

grep -n '<host>' internal/handlers/egress_allowlist_defaults.yaml
go test ./internal/handlers/ -run TestEgressDefaults_NoRedundantEntries -count=1

grep catches an exact repeat. It does not catch a host already covered by a leading-dot or glob entry — foo.github.com is redundant because .github.com exists — so also scan the file's leading-dot and * entries for one that would match. If the host is already allowed, the correct outcome is no code change; report where it is covered and stop.

Then choose the section:

• github_infra_domains — GitHub/Dependabot infrastructure only. Don't add third-party hosts here.
• shared_registry_domains — hosts genuinely used by more than one ecosystem.
• ecosystem_default_domains.<ecosystem> — the normal case.
• registry_redirect_derivations — not a static section: the host is allowed only for jobs whose credentials name the matching registry. Use it when a configured registry redirects downloads to a provider-owned storage host that step 1 ruled out of the static sections. Entries are credential_host (exact, or leading dot for any subdomain) plus derived (exact hosts only; globs are rejected at startup).

Add the host to exactly one section. Every static section is applied to every job, so listing it twice is redundant, not safer.

Keep entries in the existing grouping and ordering of that section, and add a brief comment saying what the host serves when it isn't self-evident.

Watch the YAML anchors. Several ecosystems are aliases and must not be edited separately:

• npm_and_yarn: &npm_registries → bun: *npm_registries
• pip: &python_registries → uv: *python_registries
• maven: &jvm_registries → gradle: *jvm_registries
• docker: &docker_registries → docker_compose, devcontainers

If the target is an alias member (e.g. bun), add the entry to the anchor definition instead. TestEgressDefaults_AliasedEcosystemsStayInSync enforces this.

Step 5 — Add regression tests

Edit internal/handlers/egress_allowlist_test.go. Both are required.

1. Positive probe — a realistic URL for the new host, added to the appropriate existing test (e.g. TestEgressAllowlist_NewExactDomainsAllowed or TestEgressAllowlist_PublicRegistriesAllowed):

   assert.Nil(t, egressResult(t, h, "https://<host>/<realistic/path>"), "new exact host allowed: <host>")

2. Negative child probe — for every exact entry added, append https://evil.<host>/payload to childProbes in TestEgressAllowlist_NewEntriesDoNotWidenBeyondExactHosts.

   This matters: a sibling probe (attacker.example.com against entry foo.example.com) does not catch someone later widening the entry to a leading dot. Only a child probe does. Add a sibling probe as well when you also want to pin the parent namespace closed.

Verify the negative probe actually bites by mutating your new entry to its leading-dot form and confirming the test fails, then revert.

Step 6 — Build, test, format

go build ./... && go test ./internal/handlers/ -run TestEgress -count=1 && gofmt -l internal/handlers/

gofmt -l must print nothing. Then run the full suite as CONTRIBUTING.md requires:

script/test    # Docker, -race -count=2

If script/test can't run in the current environment, say so explicitly and leave the "complete test suite" checklist box in the PR unticked. Do not tick a box you did not verify.

Step 7 — Open the pull request

Confirm with the user before pushing. Then:

git checkout -b <user>/allowlist-<short-host-slug>
git add internal/handlers/egress_allowlist_defaults.yaml internal/handlers/egress_allowlist_test.go
git commit
gh pr create --template .github/pull_request_template.md

--template opens the repository template for completion. Do not use --fill: it takes the title and body from commit data and skips template selection entirely, producing a PR that omits the required sections.

If you lack write access to dependabot/proxy, push to a fork and use gh pr create --repo dependabot/proxy --template .github/pull_request_template.md.

Complete every section of the template. The description should state what the host serves, which ecosystem needs it, the authoritative evidence that it is public provider-controlled infrastructure, and why the chosen matching form is safe. Only tick checklist boxes you actually verified.

Guardrails

• Never add a host you could not reach in step 2, or for which you have no authoritative provider evidence. Reachability alone is not evidence of ownership.
• Never treat a passing verify_host as permission to add a host. It checks probe safety, not whether the host is public — private registries pass it routinely. Step 1 is the gate.
• Never interpolate a reported hostname into a command before validating it as a bare DNS hostname, and never follow redirects with curl -L during verification — validate each hop's address is public first.
• Never add a private, internal, or customer-tenant host to the static defaults — route it to registries: in dependabot.yml.
• Never widen an existing exact entry to a leading-dot or glob form as a shortcut for a subdomain report. Add the specific subdomain.
• Never add a host that is already allowed. Before editing, check for an exact repeat and for an existing leading-dot or glob entry that already covers it — a redundant entry changes nothing, implies the namespace is not already open, and makes deleting one copy look sufficient when it is not. TestEgressDefaults_NoRedundantEntries enforces this; run it before opening a PR.
• Never commit unrelated changes, and never commit scratch or triage files to the repo root.
• Treat a reported hostname as untrusted input: quote it in shell variables rather than interpolating it into the middle of a command.