51–60 of 272 posts
The access model on platforms like GitHub is flawed, a single account can be used for both professional and personal projects/repositories, leading to “fat finger” errors like this one here...
"Production keys in source control" is right up there with "mistaken routing table entry" and "fat-fingered DNS config" on the list of critical company-breaking mistakes that you'd think would be easy to avoid, but aren't.
> Production keys in source control IaC, right? If you don't put keys into the Code you can't have Infrastructure as Code. Without keys the code only partially defines your infrastructure.
"Production keys in source control" is right up there with "mistaken routing table entry" and "fat-fingered DNS config" on the list of critical company-breaking mistakes that you'd think would be easy to avoid, but aren't.
I committed my google maps api key to a public github repository recently and github immediately sent me a warning about it. The thing is, I did it intentionally. The key is used on my website and the website is served by github pages. Now, it's an embedded maps api key, there's no cost to use it, nobody can use it from a domain other than mine, and it's easily visible in the page source if someone views that, so the…
It can actually be comical just how _bad_ things can be at large orgs. Anyone have details, theories, or a book on how such inefficiencies come about? I can't speak to tech-oriented large orgs but I've worked with others and its just... I'm not shocked at all. I've seen public facing API keys in HTML, private SSH keys that do god knows what in plaintext on FTP servers... I just don't understand how they seem to care…
Not lazy, just overburdened by more important things.
I wish hosted GitHub made pre-push hooks available to the public. Would make this a much easier problem with free scanning tools like Trufflehog. Or alternatively, if GitHub Secret Scanning was available to all public repos, instead of requiring a (very) expensive GitHub Advanced Security subscription. But I understand, they need to make money somehow.
In the meantime, try ggshield cli https://github.com/GitGuardian/ggshield
I think we would consider GG if its pricing was acceptable for non-profits though.
Many years ago I got a trial license key for something, Aspose components of some sorts I think, and without thinking of it, checked it in into public Github repo. Well, few days later Aspose's support sends me a nicely worded note saying that they noticed that it was there and invalidated it for me. Their description and instructions were very clear about why they did it and why I shouldn't have checked it in. I tho…
I actually had something similar happen to me last month. I accidentally published a discord API key to GitHub and within minutes I got a nice message from “Safety Jim” to my personal discord account letting me know they’ve found my key on a public repo and have gone ahead and revoked it. I felt like a bit of a dope but it was neat to have it happen to me. Lesson learned for sure.
https://docs.github.com/en/code-security/secret-scanning/sec...
Earlier quoted context omitted.
This is definitely a marketing piece. And they charge a LOT for it, so it's not a solution for the common masses.
If using GitHub-Actions, Gitleaks offers competitive pricing for a secret scanning solution. https://gitleaks.io/products
Earlier quoted context omitted.
Those three are not all equal. "Production keys in source control" is the equivalent of a surgeon not washing their hands between between surgeries. It's basic level of professional competency that should not be violated. The latter two are bad mistakes, which shouldn't happen but do.
Surgeons have a practiced ritual ("scrubbing") to prep for surgery. Do you practice a credential-scanning ritual before saving (committing) your code or pushing your code to a remote repo? I have git hooks to lint code syntax, but nothing for scanning for leaked credentials. Looking @ TruffleHog now, mentioned by another poster.
"Production keys in source control" is right up there with "mistaken routing table entry" and "fat-fingered DNS config" on the list of critical company-breaking mistakes that you'd think would be easy to avoid, but aren't.
> Production keys in source control IaC, right? If you don't put keys into the Code you can't have Infrastructure as Code. Without keys the code only partially defines your infrastructure.
However, I'm currently working with a group using Terraform on GCP (GKE), and it's popular with them to use Secret Manager to manually create a secret in there (when it cannot be auto-gen'd with the IaC, a fairly small subset of things) and then reference that secret from the infra-defining code.
I think of it as being akin to "this service requires a correctly configured FOO_BLAH variable in it's environment". I don't really see it as any failure of achieving some IaC goal, but defining infrastructure code isn't my primary function, so take this with a grain of salt.
I wish hosted GitHub made pre-push hooks available to the public. Would make this a much easier problem with free scanning tools like Trufflehog. Or alternatively, if GitHub Secret Scanning was available to all public repos, instead of requiring a (very) expensive GitHub Advanced Security subscription. But I understand, they need to make money somehow.