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.
This feature is only available for workspaces under our Business plan (or in Business trial).
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.
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.
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.
If you are under our Business plan (or in Business trial), you can automate this entire process with our Auto-access granting playbook.
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.
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.
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.
If you are under our Business plan (or in Business trial), you can automate this entire process with our Auto-healing playbook.