greysteil

8 ms·

31.
by greysteil 4y ago
GitHub PM here. It scans using regexes and then applies post-processing. So yep, it can (and does) parse JWTs to understand their properties.
32.
by greysteil 4y ago
For the secret scanning partner program we're happy to work with partners of any size - there are details of the program, including how to get in touch, at the link below.[1] However, with secret scanning alerts we look for credentials
33.
by greysteil 4y ago
GitHub PM here. We switched our own token format to something similar to the above in April of last year and have been encouraging other service providers to do the same. The big benefit of highly identifiable tokens is not just that we can
34.
by greysteil 4y ago
It's totally free - there are details of how to join the program at https://docs.github.com/en/developers/overview/secret-scanni...
35.
by greysteil 4y ago
(GitHub PM here.) The Advanced Security secret scanning experience is coming to public repos (for free, obviously)! Give us a few more months - we have a little more work to do scaling it up
36.
by greysteil 4y ago
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
37.
by greysteil 4y ago
Perfect, thanks!
38.
by greysteil 4y ago
Thanks Dang. Can you also update the title? It's not only Salesforce private repos that may have been exposed.
39.
by greysteil 4y ago
A clearer title for this would be "Heroku and Travis CI GitHub OAuth apps compromised".
40.
by greysteil 4y ago
There's more detail in this blog post from GitHub: https://github.blog/2022-04-15-security-alert-stolen-oauth-u...
41.
by greysteil 5y ago
Oh good question. I can't answer this one as authoritatively as I'd like - I'll double check with the team next week. One thing to note is that the full CVSS 3.1 string is included in the database as assessed by NIST. The sev
42.
by greysteil 5y ago
We already have fixed versions (where they exist) - example link below. On backfilling the data to include advisories from before 2017 - absolutely. So far we've done this in a relatively ad-hoc way - you should already find that the m
43.
by greysteil 5y ago
The 6,465 is curated advisories that apply to open source packages in the ecosystems listed. NVD’s 170,804 is all CVEs issued, many of which (the vast majority) don’t apply to open source packages. (Not trying to claim the GitHub Advisory D
44.
by greysteil 5y ago
That’s awesome to hear. And I hear you on Elixir/Erlang. I have personal skin in the game on that one - in my Dependabot days I created the open source Elixir Advisory Database and very much want to transition that to the GitHub Adviso
45.
by greysteil 5y ago
We do want to expand the number of ecosystems we support, but need to balance that with making sure the data on existing ecosystems is complete and high quality. Right now, our focus is on going deep for a smaller number of ecosystems befor
46.
by greysteil 5y ago
Dependabot and Dependency Graph do detect indirect dependencies in repos (and create alerts and PRs for them) if they’re specified in a lockfile. So if you’re using bundler, npm, yarn, pipenv, composer, etc., and are committing your lockfil
47.
by greysteil 5y ago
You can see some of that metadata in the UI for the database: https://github.com/advisories
48.
by greysteil 5y ago
We do a bit here already, and we've got plans to do more. For repositories using a language the GitHub Dependency Graph supports, we automatically create an inventory of the dependencies the repository uses and create alerts if/wh
49.
by greysteil 5y ago
A lot. Honestly, GitHub dropped the ball for a while here. (The inside story is that we bought a SAST company, shifted a lot of focus into making that acquisition successful, and didn't give enough attention to our open source security
50.
by greysteil 5y ago
We have a full-time team of curators on staff, as part of the GitHub Security Lab, and we're committed to scaling that team to meet the demand here. That team is already responsible for reviewing all new entries on the NVD for inclusio
51.
by greysteil 5y ago
We believe that, on balance, the pros significantly outweigh the cons here. One big reason is that the alternative to this structured data being open source is that it lives in proprietary databases. In that world, attackers still have know
52.
by greysteil 5y ago
For anything that already has a CVE, yes. You can add information about CVEs that are currently "unreviewed" by the GitHub curation team. By doing so, you'll bump those to the top of the stack for our curators to review (and
53.
by greysteil 5y ago
Ha! Well, there's a lot. On major strand is more work like this to make it easy for the community to collaborate. I expect we'll make a lot of iterative improvements to the database over the next few months, aimed at making it eas
54.
by greysteil 5y ago
PM from GitHub here. I’ve been wanting to do this since I joined three years ago! Happy to answer any questions about where we’re going with open source security.
55.
GitHub’s database of security advisories is now open source(github.blog)
317 points by greysteil 5y ago|45 comments
56.
GitHub's database of known vulnerabilities is now open source(github.com)
2 points by greysteil 5y ago|0 comments
57.
by greysteil 5y ago
Appreciate your passion here Remi. I don't think a full standardisation of API token formats is ever likely, but I do think there's value in nudging things in that direction. One big challenge is that it's hard to get service
58.
by greysteil 5y ago
The latter. Our objective for secret scanning is to prevent as many serious secret leaks as possible. Where a service already has a token format that is highly identifiable we want to take advantage of that, rather than rely on the adoption
59.
by greysteil 5y ago
Thanks for doing the good work of encouraging people to mint better tokens!
60.
by greysteil 5y ago
Since the author is on here - reckon you could beat up on simple random tokens a _little_ bit more? In particular how easy they are to identify and prevent leaking (easily fixed by adding a prefix). I work on secret scanning at GitHub. When

More ›