GitGuardian / ggshield

Find and fix 400+ types of hardcoded secrets and 70+ types of infrastructure-as-code misconfigurations.
https://gitguardian.com
MIT License
1.68k stars 150 forks source link

[FEATURE] Fail only upon adding a secret (not when removing or when a secret is on the line above or below). #1001

Open neraun opened 4 days ago

neraun commented 4 days ago

Is your feature request related to a problem? Please describe.

I am using ggshield in a few projects pipeline, and first of all thanks for this great tool !

I am annoyed with a behaviour of ggshield that AFAIK, cannot be customized. Since I've started a work of taking secrets out of my project repo, I am removing secrets one by one.

Each time I am removing a secret, ggshield job is failing and need to use SKIP=ggshield as a workaround.

Example 1 (original names and value were changed) :

 10 | +define('ENV', $_ENV['ENV']);
...
25    | -$_ENV['USER'] = 'token';
26    | -$_ENV['PASSWORD'] = 'g42wyu2zA*********************************xyzxyzk7g';
27    | -$_ENV['X-OVH-TOKEN'] = '8au611**-****-****-****-******21xyq6';
                                 |______________apikey______________|
28 11 |  

>> Secret detected: Generic Password

Similar issue occurs when modifying a line below or above a secret. GGshield job fails even though the line you modified has nothing to do with a secret.

Example 2 (original names and value were changed) :

27    | -$_ENV['ELASTIC_ALIAS'] = 'logs-xt-04221-a-dev-logs';
...
   27 | +$_ENV['ELASTIC_ALIAS'] = 'logs-xt-04221-a-tests-logs';
28 28 |  $_ENV['AN_API_TOKEN'] = '6yz828**-****-****-****-******2ufg2';
                                 |______________apikey_______________|
29 29 |  
30 30 |  /**

>> Secret detected: Generic Password

Here I modified line 27 and got the job failed for an existing secret on line 28.

Describe the solution you'd like

To ensure tests hermeticity ggshield should be able to fail only when a secret has been added on a specific commit.

It is even more relevant when several developers are working on the same repo, a developer should not be blocked for a vulnerability he did not introduced.

Describe alternatives you've considered

In case the behaviour of ggshield could not be changed (for backward compatibility), implement an option to behave the way described above.

Additional context

Add any other context or screenshots about the feature request here.

pierrelalanne commented 4 days ago

Hi @neraun, Thanks for reporting this. Let me cc @Walz and @V-O: I think they'll have some insights to share regarding our plans about this.