Experiment reveals differences in secret leak detection on Git code repositories
Limited Time Offer!
For Less Than the Cost of a Starbucks Coffee, Access All DevOpsSchool Videos on YouTube Unlimitedly.
Master DevOps, SRE, DevSecOps Skills!
Source:-https://portswigger.net
A new experiment by a Polish security researcher offers a fresh perspective on the well understood but still all too common problem of developers accidentally publishing secrets to code repositories.
Andrzej Dyjak recently ran an experiment to see how long it took before a secret committed to a public repository (such as API or cryptographic keys) was exploited.
An AWS key generated using the Thinkst Canary digital tripwire service was first compromised after 11 minutes when posted to GitHub, before getting repeatedly attacked thereafter.
A similar dummy secret went 62 minutes before suffering its first and only compromise on GitLab.
Dyjak used GitGuardian, a Git secrets scanning technology, during his experiment.
In the case of GitHub, Dyjak received an alert within seven minutes, and therefore before the first compromise, of possible secret leakage.
Time to pwnage
The time it takes for accidentally committed secrets on public repositories to being compromised has been the subject of previous, more extensive studies by North Carolina State University (PDF), IBM Research (PDF), and a GitHub honeypot exercise put together by security researcher Bob Diachenko.
Dyjak said that although people have focused on the honeypot part of his experiment, he was more interested in a comparison between the secret detection features of GitHub and GitLab.
“GitHub won – they caught the secret, alerted me, informed the provider, and on top of all that they also alerted me about vulnerable dependencies
“GitLab lost – it does offer similar SAST [static application security testing] features but they require setup of Auto DevOps which is a bottleneck.”
The Daily Swig approached both GitHub and GitLab for comment on this story, which we’ll update as and when more information comes to hand.
Dyjak deliberately leaked two secret API keys, attached to AWS and Slack, respectively.
“While AWS was compromised in both cases (GH and GL),” Dyjak reports, “Slack was not compromised in neither.”
This finding provides anecdotal evidence that adversaries are actively and selectively hunting for leaked AWS secrets rather than any inadvertently exposed tokens or credentials within code repositories.