131–140 of 272 posts
The social media manager at GitGuardian is winning. They just got us each to read a 1000 word ad for GitGuardian.
Earlier quoted context omitted.
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.
GitHub PM here. Glad that was a good experience! We work with ~50 partners (details in the link below) to notify them when tokens for their service are exposed in public repos, so that they can notify you. https://docs.github.com/en/code-security/secret-scanning/sec...
Earlier quoted context omitted.
I wish I could set this up to block pushes proactively instead of reacting to pushed secrets.
You could set up something like https://github.com/godaddy/tartufo in a pre-commit hook. Not sure if github has a way to hook into the push hooks on server side, they might though.
Earlier quoted context omitted.
It's totally free - there are details of how to join the program at https://docs.github.com/en/developers/overview/secret-scanni...
Hm - this would work better if keys were easy to scan with regular expressions. Next time I implement api keys I wonder if it’s worth going out of my way to make them easy to identify. Eg, by prefixing every key with a few well known characters. Like FMLA_xxxxx for a fastmail app key.
https://github.blog/2021-04-05-behind-githubs-new-authentica...
Earlier quoted context omitted.
Yikes. It is sad to hear stories like that, where security is not a concern until panic sets in. :( Yet another reason we need to adopt standards like security.txt and make it easy to report these things as it is to tell robots to ignore us with robots.txt. See securitytxt.org for more on the project.
It's tough. I'm our public security reporting email list. We get a lot of things that boil down to "When I go to your website, I am able to see the content of your html files!" ... yes, reporter. That is what a web server does. It gives you HTML files. Congrats that you have figure out the dev console on your browser, but you're not a hacker. I'm trying to go with Hanlon's razor here and assume this is inexperienced…
100% this. And it bites harder when you’re a scrappy time constrained startup, or just offering a public service.
I maintain a public API that returns public information- observable facts about the world. As such, the API doesn’t have any authn/z. Anyone can use it as little or as much as they want, free of charge.
Of course I get at least 1 email per year telling me my API is insecure and that I should really set up some OAuth JWT tokens and blah blah blah.
I used to reply telling them they are wrong but it gets hostile because they want money for finding the “vulnerability”.
On the flip side, at another company I once got a security@ email that sounded like a false alarm. I quickly wrote it off and sent a templates response. Then they came back with screenshots of things that shocked me. It was not a false alarm. That guy got paid a handsome sum and an apology from me for writing him off.
Earlier quoted context omitted.
In fact, you can apply as a Github "secret scanning partner" to have your own secret's format (regexp) be a part of this secret scanning, with a webhook to your servers whenever they find one, so that you can do the credential-invalidation on your own backend + send the kindly-worded email from your own domain. Mind you, your secrets need to have a distinctive format in order for this to work. Probably a distinctive…
The GitHub public events API is delayed by 5 minutes, presumably to give secret scanning partners time to react before commits are made public. https://github.blog/changelog/2018-08-01-new-delay-public-ev... Disclosure: I'm an ex-GitHub employee but was not involved in the secret scanning API.
Mind you, the Github dataset isn't the leak itself; the leak is the public repo that the user pushed their key to. The dataset just makes such searches scalable / cost-effective to third parties who aren't already indexing Github for some other reason.
Earlier quoted context omitted.
Hm - this would work better if keys were easy to scan with regular expressions. Next time I implement api keys I wonder if it’s worth going out of my way to make them easy to identify. Eg, by prefixing every key with a few well known characters. Like FMLA_xxxxx for a fastmail app key.
That's exactly what GitHub did with their own keys and their new keys fit this format. https://github.blog/2021-04-05-behind-githubs-new-authentica...
We will be applying thanks for sharing greystell