Available playbooks
GitGuardian provides several built-in playbooks that can be applied to internal incidents, public incidents, or both.
Auto-share incident public link to involved developer
This playbook is available only for Internal Monitoring.
Automates sharing incidents with involved developers via email with public share links.
Trigger: Incident created by non-workspace member
Action: Creates public share link and emails developer
Requirements: Public sharing must be enabled in workspace settings
Options:
- Feedback collection: Developer can submit feedback via the link
- Resolution capability: Developer can resolve/ignore incident via the link
If the incident is triggered by a workspace member, this playbook won't apply as they can access the incident through the authenticated dashboard.
Auto-grant access to involved developer (in-app)
This playbook is available for both Internal Monitoring and Public Monitoring.
Automatically grants incident access to workspace members with Restricted or Member access levels when they are involved in the incident.
Trigger: The playbook grants access in three situations:
- New incidents — when a new incident is detected involving a workspace member, that member is granted access automatically.
- On activation (historical incidents) — when the playbook is first enabled, GitGuardian runs a one-time backfill that grants access to all existing incidents where a current workspace member is the author. Enabling the playbook therefore applies retroactively, not only to incidents detected afterwards.
- When a member joins — when a new member is added to the workspace while the playbook is active, they are granted access to the existing incidents they are involved in.
Action: Grants the involved user access to view this specific incident. This is done by matching the commit author email against the dashboard user email.
Auto-resolve revoked secrets
This playbook is available for both Internal Monitoring and Public Monitoring. It is activated by default for Internal Monitoring.
Automatically resolves incidents when previously valid secrets are revoked.
Trigger: A secret previously checked as valid by GitGuardian becomes invalid.
Action: Automatically close the incident as "Resolved", with reason "Secret was revoked"
Activating this playbook applies to both real-time detection (when an incident is re-checked and found invalid) and all historical incidents that became invalid in the past. Upon activation, you will see a confirmation prompt indicating how many historical incidents will be automatically resolved.
Auto-ignore invalid secrets
This playbook is available for both Internal Monitoring and Public Monitoring. It is activated by default for Internal Monitoring.
Automatically ignores open incidents whose secret is known to be invalid.
Trigger: GitGuardian learns that the secret of an open incident is invalid. This happens in four situations:
- New incidents: an incident is created with a secret that is already checked as invalid.
- Validity re-checks: a periodic re-check, an on-demand re-check, an endpoint validity refresh, or a manual validity override reports the secret as invalid.
- Regressions: an incident re-opens while its secret is still invalid.
- On activation (historical incidents): when the playbook is first enabled, GitGuardian applies it to the existing incidents of your workspace.
Action: Automatically close the incident as "Ignored", with reason "Invalid secret".
Upon activation, you will see a confirmation prompt indicating how many historical incidents will be automatically ignored.
Precedence with Auto-resolve revoked secrets: both playbooks react to the same signal. Auto-resolve revoked secrets runs first and takes the incidents whose secret was checked as valid at least once. Auto-ignore invalid secrets then takes the incidents still open.
| Secret validity history | Auto-resolve revoked secrets | Outcome |
|---|---|---|
| Was checked as valid at least once | Active | Resolved, with reason "Secret was revoked" |
| Was checked as valid at least once | Inactive | Ignored, with reason "Invalid secret" |
| Was never checked as valid | Active or inactive | Ignored, with reason "Invalid secret" |
This playbook does not apply to detectors that support custom hosts. For those detectors, validity depends on which host the secret is checked against. See Customize validity checks.
Auto-ignore false positives
This playbook is available and enabled by default for both Internal Monitoring and Public Monitoring.
Automatically ignores incidents that have been tagged as false positives by GitGuardian's internal machine learning model.
Trigger: An incident is identified as a false positive by the ML model
Action: Automatically close the incident as "Ignored", with reason "False positive (not a secret)"
This playbook works exclusively with generic secrets, as the machine learning model only analyzes this secret type. It applies to real-time detection whenever an incident is identified as a false positive, and can also be applied to historical incidents by launching a historical scan on your perimeter.
Activating this playbook applies to both real-time incidents and historical incidents that were already invalid when detected. Upon activation, you will see a confirmation prompt indicating how many historical incidents will be automatically resolved.
