DevSecOps Operations

Delegated Alert Dismissal in GitHub: Building Developer Trust Without Losing Compliance

Learn how SecOps teams can survive the next Log4j. Replace 100 Jira tickets with structured zero-day vulnerability management and InstaSLA fix campaigns

By InstaSLA Superadmin · Published · 9 min read

AppSec alert fatigueGitHub delegated alert dismissalrisk acceptance GitHubdismiss code scanning alertsdeveloper security autonomydelegated alert dismissal best practicesGitHub code scanning false positivesSOC 2 compliance GitHub alertsInstaSLA accepted risk evidencedeveloper friction security controlsGitHub Advanced Security workflowsSOC 2 audit trail code scanningautomated security alert approvalsdelegate security permissions GitHubdeveloper-led threat triagefalse positive dismissal workflowcustom roles alert dismissalGitHub Dependabot alert reviewsecurity alert governancedeveloper velocity vs security
Delegated Alert Dismissal in Git Hub Building Developer Trust Without Losing Compliance

Delegated Alert Dismissal in GitHub: Building Developer Trust Without Losing Compliance

For modern engineering teams, agility is the ultimate currency. But when that agility collides with strict compliance requirements, friction is inevitable. One of the most common friction points in DevSecOps is simple to state and hard to solve: how do you handle a high volume of code scanning alerts without turning the security team into a permanent bottleneck?

Engineering managers want developer security autonomy — the ability for their teams to dismiss alerts that are clearly false positives, test code, or accepted risk. Security teams, bound by SOC 2 and ISO 27001 requirements, cannot allow developers to unilaterally close out vulnerabilities without a paper trail. If an auditor asks why a critical SQL injection alert was closed and the answer is "a developer clicked dismiss and we don't know why," the control fails.

Historically, organizations solved this by removing dismissal rights from developers entirely. Every false positive required a ticket, a Slack ping to security, and days of waiting for manual review — which eroded trust, slowed delivery, and fed alert fatigue.

GitHub's delegated alert dismissal feature is built to close that gap. This article walks through how it actually works today, what changed most recently, where it still leaves a compliance gap for SOC 2 and ISO 27001 audits, and how a platform like InstaSLA fits into closing that gap.

The DevSecOps Bottleneck: The False Positive Problem

Integrating security testing into CI/CD is standard practice. Tools like GitHub Advanced Security (GHAS), Dependabot, and third-party SAST/DAST scanners generate alerts directly on pull requests and in the repository security tab. But automated scanners lack context — they flag a hardcoded secret that's actually a dummy token in a unit test, or an XSS pattern in an internal admin tool that never touches the public internet.

When a developer can't dismiss that kind of alert, the workflow breaks down in a predictable way:

  1. The context switch — the developer stops coding to open a ticket and document why the alert is a false positive.
  2. The waiting game — the request sits in an already-overloaded security backlog.
  3. The blocked pipeline — the PR can't merge until the alert clears, so feature delivery stalls.
  4. The trust deficit — developers start treating security tooling as an obstacle instead of a safeguard.

Security teams don't want to manually review hundreds of false positives, but they're also wary of the alternative: if any developer can dismiss anything, what stops a legitimate remote code execution finding from getting waved through before a release deadline? That's the real tension delegated alert dismissal is designed to resolve.

How GitHub's Delegated Alert Dismissal Actually Works

GitHub shipped delegated alert dismissal for code scanning and secret scanning as a public preview in March 2025, and it reached general availability on GitHub.com on July 1, 2025. The most significant recent update is that Dependabot alerts joined the same governance model on December 19, 2025 — so the same request-and-approve workflow now applies across code scanning, secret scanning, and dependency alerts, not just code scanning.

When the feature is turned on for a repository:

  1. Users with write access can no longer dismiss alerts directly. Attempting to dismiss instead opens a dismissal request.
  2. A comment is required explaining the rationale — the developer has to state, in writing, why they believe the alert is a false positive, test code, or acceptable risk.
  3. Reviewers are notified by email and in GitHub's UI. By default, only organization owners and security managers can approve or deny these requests, or dismiss alerts directly themselves.
  4. The reviewer approves or denies. Approval dismisses the alert; denial leaves it open and the requester is notified of the outcome by email.

The entire exchange — request, comment, reviewer, decision, timestamp — is recorded on the alert's timeline, written to the organization's audit log, and exposed through both the REST API and webhooks (for code scanning, GitHub added dedicated endpoints such as GET /orgs/{org}/dismissal-requests/code-scanning and the equivalent repository-level routes). That's the raw audit trail the rest of this article builds on.

Decentralizing Approval with Custom Roles

If every dismissal request still has to land on the desk of an organization owner or a security manager, you haven't removed the bottleneck — you've just moved it from Jira into GitHub. This is where custom organization roles matter.

As of the July 2025 GA update, you can grant the review authority to people other than owners and security managers — Engineering Leads, Staff Engineers, or embedded "security champions" — by building a custom role with the right permissions:

  • An organization-level permission to review (approve/deny) dismissal requests, plus a separate permission to bypass them (self-approve).
  • A repository-level permission to view, dismiss, and reopen alerts.

A narrower view-only permission also exists, so someone can watch the request queue for a set of repositories without being able to act on it. One caveat worth flagging in any rollout plan: GitHub's docs currently note that adding repository-level permissions to a custom organization role is in public preview and subject to change, so treat the exact permission set as something to re-verify before you lock in a long-term access model.

The effect, when it's configured well, is that the central security team stops approving individual alerts and starts auditing the process by which Engineering Leads approve them — a meaningfully different, and much more scalable, job.

Turning It On

Delegated dismissal is controlled by a single toggle, "Prevent direct alert dismissals," but where you flip it depends on scope:

  • Single repository: Settings → Security → Advanced Security (or the relevant "Code Security" / "Secret Protection" / "Dependabot" section), then enable "Prevent direct alert dismissals" for the alert type you want to govern.
  • Organization or enterprise-wide: build this into a custom security configuration and apply it across all or selected repositories, rather than toggling it repo by repo. If an org owner enforces the setting through that configuration, individual repositories lose the ability to override it locally.

The Compliance Gap: Why GitHub Isn't Enough for SOC 2

Delegated dismissal solves the workflow friction, but it creates a different problem for compliance. During a SOC 2 Type II audit, an auditor evaluates your vulnerability management controls directly. If your policy says high and critical vulnerabilities must be remediated within 14 days, the auditor will sample dismissed alerts from that window. Any critical alert that was dismissed instead of fixed needs evidence of a formal risk acceptance — not just a GitHub comment thread.

In a strict compliance framework, that typically means:

  • A documented business justification.
  • Approval from an authorized stakeholder — often at director or executive level, depending on severity.
  • A defined expiration date (accepted risks are rarely indefinite; six to twelve months is common before re-review).
  • A centralized register of every accepted risk, not scattered across individual repos.

GitHub records the comment, the requester, and the approver, and it's genuinely useful raw material — but it isn't a governance, risk, and compliance (GRC) system, and it wasn't built to produce an "Accepted Risk Register" on demand. Manually reconstructing that register from GitHub's audit log and dismissal-request API for every dismissed critical alert is exactly the kind of error-prone, spreadsheet-driven process that produces audit exceptions.

Bridging the Gap: InstaSLA for Audit-Ready Evidence

This is the specific gap a GitHub-native SLA and compliance platform like InstaSLA is built to close. Rather than replacing GitHub's review workflow, it sits on top of it:

  • Ownership. Every GitHub security alert — including Dependabot, code scanning, and secret scanning findings — can be assigned to a person, team, or repository owner, so remediation work has a clearly accountable party rather than sitting anonymously in an alert feed.
  • SLA tracking by severity. Critical, high, medium, and low findings get their own remediation-deadline rules, with a queue view showing what's overdue, due today, or due this week.
  • Fix campaigns. Repeated advisories against the same package across many repositories can be grouped and worked as one coordinated effort instead of dozens of duplicate tickets.
  • Risk acceptance with an expiration date. When a risk is accepted rather than fixed, InstaSLA can pause the SLA clock on that finding only once it's been approved and documented, and it keeps the expiration date and review history attached to the record — the piece that a raw GitHub comment thread doesn't give you on its own.
  • Audit-ready exports. At audit time, remediation evidence — repository, owner, due date, completion date, whether risk was accepted, and any SLA breach history — exports as a CSV or report instead of being assembled by hand from the audit log.

In practice, that turns "we approved a dismissal in GitHub three months ago" into a record an auditor can actually work with: who owned the finding, when it was due, what was decided, and when that decision needs to be revisited.

Best Practices for Rolling Out Delegated Dismissal

  1. Start narrow. When you first enable delegated dismissal, consider restricting approved reasons to "false positive" or "used in tests." Save true risk acceptance ("won't fix") for a later phase once the team has lived with the review workflow for a while.
  2. Cover all three alert types deliberately, not by accident. Because code scanning, secret scanning, and Dependabot now share the same governance model, decide up front whether you want the same approval matrix across all three, or a stricter one for Dependabot given how much higher its alert volume tends to be.
  3. Define the approval matrix by severity. Document who approves what — for example, Tech Leads for low/medium, Engineering Directors for high/critical — and map that matrix onto GitHub custom roles rather than leaving it as an informal norm.
  4. Train the approvers. Approving a dismissal is, functionally, accepting risk on the organization's behalf. Reviewers need a shared standard for what counts as sufficient justification before they start approving requests.
  5. Don't run delegated dismissal without a logging layer. Dismissal volume outpaces manual tracking quickly; a platform like InstaSLA turns GitHub's audit log and dismissal history into something you can actually hand to an auditor.
  6. Spot-check the approvers, not just the alerts. If one Engineering Lead is rubber-stamping every request that comes through, that's a coaching conversation, and it's much easier to catch with an exportable review history than by reading raw GitHub notifications.

Conclusion

Security as a pure gatekeeper doesn't scale, and heavily regulated environments can't run on unverified trust either. GitHub's delegated alert dismissal — now covering code scanning, secret scanning, and, as of December 2025, Dependabot alerts — gives engineering managers a real mechanism for developer autonomy with a built-in paper trail. Pairing it with a compliance layer like InstaSLA is what turns that paper trail into a formal, time-bound risk acceptance record an auditor can rely on, without slowing the pipeline back down.

Further reading

Related articles