A practical Dependabot SLA policy template for engineering teams

Start with severity-based deadlines

GitHub alerts become operational work only after they have owners, due dates, and a clear escalation path. A simple starting point is three days for critical alerts, seven days for high alerts, thirty days for medium alerts, and ninety days for low alerts.

The policy should be visible to engineering and security teams, not buried in an audit folder. Every alert should show which rule set produced its deadline.

Assign accountability before escalation

Escalation is useful only when an alert already has a responsible owner. Repository ownership, CODEOWNERS data, and manual overrides give teams a defensible way to route remediation work without turning every alert into a security-team fire drill.

• Map repositories to teams before the first audit request arrives.
• Use manual assignment for ambiguous ownership.
• Track owner changes in an audit log.

Group duplicate work into fix campaigns

When the same vulnerable package appears across many repositories, the work should be managed as a campaign. Grouping by package, ecosystem, advisory, patched version, repository family, and owner reduces noise while keeping the underlying alert evidence intact.

Export evidence continuously

A good evidence export should show what was open, who owned it, when it was due, when it was fixed, and why any risk was accepted. This turns vulnerability management from a spreadsheet scramble into a repeatable workflow.