After evaluating several SAST and SCA solutions for our compliance workflows, our team has settled on a process within GitHub Advanced Security that I believe merits discussion, particularly for organizations managing PCI DSS scope. Our primary challenge was maintaining a clean, auditable record of vulnerabilities we had formally accepted as part of our risk management program, without those alerts drowning out new, actionable findings in the Security tab.
We developed a workflow-centric approach using GitHub Actions and the CodeQL CLI to systematically tag certain alerts with a custom `risk-accepted` label. The goal is not to suppress alerts, but to annotate them with a structured rationale that is visible both in the UI and via the API for compliance reporting. Our method involves a two-gate process:
* First, a manual review and decision documented in our GRC platform triggers a curated list of alert IDs.
* Second, a scheduled Actions workflow uses the GitHub Security Advisories API to add a `risk-accepted` label to these specific alerts, appending a comment with the JIRA ticket reference and the expiration date of the acceptance.
The key configuration snippet from our workflow involves using the `gh api` command to patch the alert. We found it crucial to update the `dismissed_reason` to `"risk accepted"` and to set the `dismissed_comment` field with our standardized rationale, rather than just using a custom `state_reason`. This ensures the alert's state reflects the business decision accurately.
**Considerations & Pitfalls:**
* This process requires strict IAM controls on the repository secrets and the token used, as it alters the security alert state.
* We maintain a separate, immutable log of all risk acceptance decisions outside of GitHub for audit purposes. The GitHub alert annotation is a convenient cross-reference, not our system of record.
* We run a weekly audit job that queries for all alerts with the `risk-accepted` label and checks their expiration dates against our GRC platform, flagging any discrepancies.
From a comparative standpoint, this workflow offers more transparency and auditability than simply dismissing alerts or using bulk `gh asap` commands without annotation. However, it lacks the granularity of native risk-acceptance features found in some dedicated application security platforms. For teams already committed to GitHub's ecosystem and requiring PCI scope segmentation, this has proven to be a methodical and reportable middle ground.
I am interested in hearing from others who have implemented similar governance layers on top of GitHub Advanced Security. Specifically:
* Have you encountered any issues with alert re-opening or notification noise using this API-driven approach?
* Are there alternative methods for scoping alerts (e.g., using repositories, tags, or custom properties) that you've found more effective for compliance boundaries like PCI?