When it comes to application security, incident remediation cannot be half-baked.

Today, we’re introducing Validity Checks in GitGuardian for Internal Repositories Monitoring. For each incident, users will now be able to verify if the leaked credentials are still valid — bringing their attention to unresolved incidents.

Reminder: exposed and valid credentials can be exploited by malevolent actors. We recommend you take care of revoking and rotating them as soon as possible since they still represent an unmitigated threat.

How does the Validity Check work?

Before deep-diving into the mechanics of Validity Checks, we need a quick refresher on GitGuardian’s secrets detection engine. Detecting secrets in source code is a probabilistic problem and to solve it, we are implementing two types of detectors:

  • Specific detectors: this class of detectors has one algorithm per specific type of secret. For example, AWS keys, Stripe API keys, PostgreSQL URI, or SMTP credentials each have their specific detector.
  • Generic detectors: this class of detectors catches what our specific detectors cannot, simply because the secrets are not associated with a service provider or do not have a discernible format. Our algorithms will look for patterns such as high entropy strings or contextual hints to the presence of a secret like ‘username’ and ‘pwd’ keywords for example.

You can learn more about our detection engine in our documentation.

Back to Validity Checks. For every incident, the dedicated secret detector will try and perform the least intrusive call possible to the associated service. This operation will return one of the following values:

  • Valid: the secret can still be exploited and needs to be revoked and rotated ⚠️.
  • Invalid: the secret has been likely revoked.
  • Cannot be checked: the service provider or the secret type does not allow for validity checks by GitGuardian.
  • Unknown: GitGuardian has recently introduced a validity checker, this secret’s validity has not been verified yet.

In the case of generic secrets, validity is hard if not impossible to verify. For example, GitGuardian cannot infer what authentication endpoint it needs to reach when it finds a JWT secret in the source code. For such incidents, the resulting value of the validity check will be Cannot be checked.

How does this help you?

Use case 1 — Prioritizing your incidents

In the Incidents section of your dashboard, you will find a table listing all your secrets incidents. Next to every incident, an icon and an on-hover tooltip will display:

  • The result of the secret validity check: valid, invalid, cannot be checked, unknown.
  • The date and time at which the first and last checks were performed.
Incidents Table — Filtering incidents by their secret's validity check

The table view also allows for filtering on incidents with valid secrets. This will help you set your priorities straight in terms of remediation. You should take care of exposed and valid credentials as soon as possible since they can still be exploited.

Use case 2 — Obtaining proof of revocation

For security teams

Revoking and rotating an exposed credential can require the asynchronous intervention of multiple teams within your organization: developers, ops, SREs…

On the incident page, the secret’s validity check result is displayed below the incident status. Security teams can refer to this for proof of revocation of the compromised secret.

Lastly, GitGuardian will regularly check for the validity of exposed secrets, to the best of its ability, to reflect their accurate state. You can also manually run the Validity Check should you need to force update the status since the last check.

Incident details view — Validity check result is displayed below the incident status
Incident details view — Validity check result is displayed below the incident status

For developers

If you choose to put your developers in the loop for the incidents they are involved in, they will receive a link to a feedback collection form.

On this form, GitGuardian will now display the status of the secret’s validity check. Developers responsible for remediating the incident will be able to verify on their end if the secret has been revoked.

Developer feedback form — Validity check result is displayed next to the secret type
Developer feedback form — Validity check result is displayed next to the secret type

What’s next?

Validity checks are currently designed to perform well for specific secrets, ones associated with identified services or hosts. We also want to make it possible for GitGuardian users to check the validity of generic secrets, by configuring custom endpoints.

This is currently a work in progress. Sign up below to stay up to date with our next releases.