Don Magee, security engineer, and his team have been using GitGuardian tools for 2 years to catch secrets before they have made it to production. Peerspot interviewed him and here are some of the key elements:
His recommendation is to consider all secrets in the source code as n°1 Priority. And to be successful at dealing with all occurrences, they use the Developer in The Loop feature:
“With the new feedback system, it has definitely improved our lives. We expect every developer to remediate them as soon as they are notified.
The security team has the ability to immediately reach out to the developer and get feedback via email in a portal, where the developer can see what we see and put comments on it. We are a worldwide company so we have engineers in a dozen countries. Sometimes, the engineer who made the bad commit isn't even awake, so sending a Slack message doesn't get a response. This is more pressing, so it helps us.”
Regarding GitGuardian accuracy, Don reports a 90 to 95% accuracy and concerning the performance:
“We have over 500 repositories. We get detections within seconds of people making those commits. It seems like it can scale to any size that we would need.”
Don also explains how other solutions are generating alert fatigue:
“The breadth of the solution’s detection capabilities is the best one out there. I came from a very large Fortune 100 insurance company where we used a couple different products. They were full of false positives and noise, and in my opinion, not that valuable.“
As for the ROI, Don reports a real impact on the security team’s productivity.
"We don't have to spend our time running scans in repositories to see if they contain secrets. Within 10 seconds of a commit, we know whether it contains a secret. I would probably spend a couple of hours a week just running open-source tools, trying to find secrets, and seeing if anything bad was going on. "
Don also deployed pre-commit hooks to capture the secrets very early in the SDLC and he has some advice about this:
"Make the detection of a secret a blocking action so you can't deploy until you have resolved it. When we first started, we had it as a non-blocking informative action and were shocked at how many times an engineer just wants to go home on a weekend and pushes the button anyway. Then, you have clean-up and investigative work to do. Make it blocking so they have to do the right thing."
You can also try the solution today! Remember if you are an individual developer or part of a small team, it is free!Sign up to GitGuardian with GitHub