Remediate incidents

Guidelines (& misconceptions)

It is crucial development teams fully understand the problem of secrets-in-code, beyond the simple act of exposing a secret in plain text and committing it to the shared codebase.

Developers need to acknowledge the threats and consequences of secrets sprawl, and picture how collaborating with security teams can strengthen the overall security posture – without compromising speed and productivity.

Collaborating with developers

Pulling developers closer to the remediation process

How can I share incidents with developers?

In the GitGuardian dashboard

This feature is only available for workspaces under our Business plan (or in Business trial).

Granting access to the incident

From an incident's details page, you can grant access to a selection of Restricted users or even invite members to sign up for GitGuardian and join as Restricted users. The selected users will have read and write permissions on the incident.

Collaborating on the incident

For example, if you are giving access to the incident details to the involved developer, they will be able to assign the incident to themselves, set its severity, and leave comments on the incident. It will also be possible for them to resolve or ignore the incident, precising the reasons that led them to either decision.

Every action taken by the Restricted user, the developer here, will be logged in the incident details timeline.

Revoking access

You can also revoke access for the Restricted users. Simply click on the Grant access button to see the list of users and press on the bin icon to revoke access.

Revoking access for a Restricted user to an incident is not possible if the incident is assigned to them. The assignment needs to be changed first for access to be revoked.

How can I automate incident this workflow?

If you are under our Business plan (or in Business trial), you can automate this entire process with our Auto-access granting playbook.

Outside the GitGuardian dashboard

Sharing the incident

You can share any incident by turning on the sharing switch. Such action will generate a unique link containing by default:

• the incident with the secret visible,
• its occurrences with links to their locations on the VCS and the resulting check of their presence in the git history,
• the resulting check of the secret's validity,
• "How to remediate" guidelines.

This link will automatically expire either 30 days after its creation or 5 days after the incident is closed, whichever of the two dates is earlier. A new link can be generated at any time after the expiration of the previous one.

Any person, registered on GitGuardian or not, would have access to this incident through this link.

Enabling feedback collection

The feedback collection process is achieved via this link. The sharing link of an incident has a "Feedback collection" option. When this option is on, an entire section becomes available in the shared page where the person having access to it can submit their feedback.

The feedback form is not customizable yet.

When the feedback is submitted, it will be directly visible on the incident page of your GitGuardian dashboard under the "Feedback" section, helping you to take the appropriate decision for remediation. Upon feedback submission, GitGuardian notifies via email the assignee of the incident at stake if any. Otherwise, notification is sent to every dashboard user except Viewers.

This "Feedback collection" option is on by default whenever a share link is generated manually.

Allowing auto-healing

The share link also provides a "Resolve or ignore via link" option. When turned on, you enable the auto-healing of the incident: the person who has access to the link can close the incident themselves. An entire section becomes accessible within the shared page to enable "Resolve" and "Ignore" actions.

This is particularly useful if you want to reduce your workload and if you trust members of your team external to your dashboard, namely the developer responsible for the leak, to properly remediate the incident.

This "Auto-healing" option is off by default whenever a share link is generated manually as GitGuardian considers closing an incident as a sensitive action.

How can I automate incident this workflow?

If you are under our Business plan (or in Business trial), you can automate this entire process with our Auto-healing playbook.

Remediation workflow

Default remediation workflow

Remediating an incident can be complex. That is why a remediation workflow is displayed by default on an incident's details page.

This workflow is intended to guide anyone involved in the remediation of a hardcoded secret incident. It describes the steps that must be followed to mitigate the risks of exposure.

Custom remediation workflow

GitGuardian provides a remediation workflow by default. As each organization has its own context and remediation policies, you have the ability to customize the remediation workflow.

Managing the remediation workflow

As a workspace Manager, you can manage the remediation workflow in the Secrets detection section of your settings.

From here, you can create, edit or delete a custom remediation workflow. You may also have the ability to switch between the default GitGuardian remediation workflow and your custom remediation workflow.

Alternatively, you can access this section directly by clicking the Edit workflow button on any remediation workflow in an incident's details page.

Creating a new custom remediation workflow

By default, there is no custom remediation workflow on your workspace. You can create one by clicking the Create custom workflow button.

You will be asked to create each step of your remediation workflow:

Remediation workflow steps

Each step is composed of:

• A title (mandatory)
• A description (optional, Markdown syntax is not yet supported)
• A link (optional, this link is a good way to provide direct access to an external resource specific to your company)

Once the fields are filled in, simply click on the Add step button to validate the creation of your step. Repeat the process to add any other steps. Note that you can create a maximum of 20 steps for a custom remediation workflow.

Activating a remediation workflow

Once a custom remediation workflow has been created, you are free to select between the default GitGuardian remediation workflow and your own custom remediation workflow.

Once activated, the selected remediation workflow will be immediately displayed on all your incident's details pages. It will also affect any shared incident pages.

Editing a custom remediation workflow

Once created, a custom remediation workflow can be edited by:

• Adding a new step with the Next Step button
• Editing a step with the pen button close to it
• Deleting a step with the thrash button close to it
• Reordering steps by dragging & dropping them

Any modification will be taken into account in real-time.

Deleting your custom remediation workflow

You can delete your custom remediation workflow with the red Delete workflow button. By doing this, the default GitGuardian remediation workflow will be activated automatically. This will also allow you to create a new custom remediation workflow.