greysteil

11 ms·

61.
by greysteil 5y ago
Thanks for the feedback Jacob, and for all the support over the years. I'm going to pass those three on to the Dependabot team, who are best placed to think through solutions. (FWIW, I'm sure we can think of something to fix (1) w
62.
by greysteil 5y ago
Hmmm, it's been a long time since I worked on Dependabot Core, but I think I can fix that one - we just need to special case `native-mt` as a version type (as opposed to applying standard Maven version comparison rules on it). I'l
63.
by greysteil 5y ago
I'll make sure the Actions PMs see this. I _think_ I heard from a colleague that there's progress here.
64.
by greysteil 5y ago
PM for security products at GitHub here. Totally agree. The good news is that I think GitHub is in a position to fix this - expect progress in the next 12 months. One change that's needed here is data for each vulnerability on whether
65.
by greysteil 5y ago
We are, and we're talking to them. In an ideal world we would have loved to have merged the databases. I expect the two databases will move in sync. The GitHub advisory database is licensed as CC BY 4.0 (i.e., attribution only), so we
66.
by greysteil 5y ago
Feature requests always welcome! I'll pass it on to the Dependabot team.
67.
by greysteil 5y ago
PM for security products at GitHub here (and one of the original authors of Dependabot). Sorry to hear that. I wouldn't expect us to be telling you about 1-5 security issues a day - do you maybe have (non-security) version updates enab
68.
by greysteil 6y ago
The reason we (GitHub) kept the new tokens to 40 characters, matching the length of our old tokens, was to make this change as backwards compatible as possible. We’ve never documented or committed to our tokens being 40 characters long, but
69.
by greysteil 6y ago
If you haven’t already read it and are interested in sleep research, I found “Why we sleep” was a wonderful, accessible summary of the literature.
70.
by greysteil 6y ago
People are more than the company they work for. Be careful not to be reductionist by judging them too much on it.
71.
by greysteil 6y ago
Slow for me
72.
by greysteil 6y ago
I think so, and we 100% should do, but I just did a test and the secret I committed was still working a full minute after I converted the repo. Could be that the scan was in a queue, could be that it didn't trigger. I'll dig into
73.
by greysteil 6y ago
Private repos need a different approach, but committing secrets to them can still be a problem. If a secret is committed to a private repo then anyone with read access to that repo could use it. That might give those users more permissions
74.
by greysteil 6y ago
The author of sshgit wrote a great post on how it works using the public GitHub API: https://darkport.co.uk/blog/ahh-shhgit!/
75.
by greysteil 6y ago
There are a few considerations on that one, but one very practical reason is the developer experience of dealing with false positives. False positives are one of the big problems in secret scanning. Some partners issue credentials with patt
76.
by greysteil 6y ago
Cool experiment! I PM the secret scanning team at GitHub and wanted to mention what GitHub did behind the scenes here. GitHub scans every commit to a public repo for secrets one of our secret scanning partners may have issued. We forward th
77.
by greysteil 6y ago
I had no idea that we do that, but I can try to hunt it down internally for you. Ping me an email - greysteil@github.com.
78.
by greysteil 6y ago
Wow, jinx, this is pretty much identical to the answer I just wrote!
79.
by greysteil 6y ago
PM from GitHub here and author of Dependabot. It's different. - Dependabot looks for vulnerabilities in your dependencies, and creates pull requests to update you to fixed versions. - Code scanning looks for vulnerabilities in your own
80.
by greysteil 6y ago
PM from GitHub here. We're adding Ruby support to CodeQL (the scanning engine used in code scanning by default). It's our top requested language, and one we use extensively internally. Adding each new language to CodeQL takes abou
81.
by greysteil 6y ago
PM for GitHub Advanced Security here. We use SARIF as the input format so third party code analysis engines can easily integrate with code scanning. Their results can then be shown in the same way that scans using our own CodeQL analysis en
82.
by greysteil 6y ago
That's exactly the process - there are full docs at the link below, and we're always keen to hear from potential partners. Please also note that we only automatically send details from _public_ repos to our secret scanning partner
83.
by greysteil 6y ago
Done - thanks!
84.
by greysteil 6y ago
PM for GitHub Advanced Security here. We handle that with secret scanning - code scanning focusses on static analysis of your code to find vulnerabilities in your code, rather than committed secrets. We have a partnership with AWS (and many
85.
by greysteil 6y ago
We (GitHub) absolutely plan to expand the list of languages CodeQL supports, and Ruby is a language we'd love to add (we're heavy users of it internally). In the meantime, because code scanning is extensible you can plug in third
86.
by greysteil 6y ago
At GitHub we're pretty proud of the scan results from CodeQL. Currently, 70% of alerts flagged in PRs are fixed (rather than marked as a false positive or won't fix). We think we can get that number up to 85%+ as we gather more da
87.
by greysteil 7y ago
Not sure the revert is fully deployed yet, but it will be soon. This was my error at GitHub - happy to answer any questions about it.
88.
by greysteil 7y ago
They're a bank. Banks have been profitable for hundreds of years. It's not the business model that's being innovated here, it's the execution.
89.
by greysteil 7y ago
Yep - GitHub Package Registry is a set of registries. It should plan nice with as many package managers as possible
90.
by greysteil 7y ago
This is a really neat idea.

More ›