Basically, Semmle offers a static analysis tool that operates on your source code as a graph (from what I understand) and points out bugs and security holes in your code. Github is now offering that for free on repos at all tiers.
[0] https://github.blog/2019-09-18-securing-software-together/
For what it works for, it works nice. But it is not a pancaea.
Security vulnerability finding is almost certainly the wrong target for Semmle - I am unsure why they are trying to push that angle. There are much better stories in things like refactoring and understanding. (I say this having overseen a number of deployments for various reasons, some successful, some not)
You're right though, it's not a panacea, and it could probably be great for other uses too.
Static code analysis tooling is never the end all be all for vulnerability research, but it does let you express vulnerability patterns for implementation type vulnerabilities and find them at a mass scale (that is if your rules/queries are legit).
CVE-2019-5876
CVE-2019-16230
CVE-2019-16231
CVE-2019-16232
CVE-2019-16233
CVE-2019-16234
CVE-2019-15026
CVE-2019-14192
CVE-2019-14193
CVE-2019-14194
CVE-2019-14195
CVE-2019-14196
CVE-2019-14197
CVE-2019-14198
CVE-2019-14199
CVE-2019-14200
CVE-2019-14201
CVE-2019-14202
CVE-2019-14203
CVE-2019-14204
CVE-2019-14437
CVE-2019-14438
CVE-2019-14438
CVE-2019-14498
CVE-2019-14535
CVE-2019-14534
CVE-2019-14533
CVE-2019-14776
CVE-2019-14778
CVE-2019-14779
CVE-2019-14777
CVE-2019-14970
CVE-2019-15119
CVE-2019-14524
CVE-2019-14523
CVE-2019-7307
CVE-2019-11476
CVE-2019-13115
CVE-2019-3570
CVE-2019-13110
CVE-2019-13112
CVE-2019-13113
CVE-2019-13108
CVE-2019-13109
CVE-2019-13111
CVE-2019-13114
CVE-2019-3560
CVE-2019-9721
CVE-2019-9718
CVE-2019-9717
CVE-2019-9720
CVE-2019-9719
CVE-2018-20222
CVE-2019-3828
CVE-2019-6986
CVE-2019-5414
CVE-2018-4460
CVE-2018-16491
CVE-2018-16489
CVE-2018-16490
CVE-2018-19476
CVE-2018-19477
CVE-2018-19475
CVE-2018-19134
CVE-2018-16472
CVE-2018-18820
CVE-2018-4407
CVE-2018-16487
CVE-2018-4259
CVE-2018-4286
CVE-2018-4287
CVE-2018-4288
CVE-2018-4291
CVE-2019-5413
CVE-2018-16461
CVE-2018-16469
CVE-2018-16486
CVE-2018-16460
CVE-2018-16492
CVE-2018-11776
CVE-2018-8018
CVE-2018-8294
CVE-2018-4249
CVE-2018-8013
CVE-2018-5388
CVE-2018-1295
CVE-2018-4136
CVE-2018-4160
CVE-2018-1000140
CVE-2017-15692
CVE-2017-15693
CVE-2017-13904
CVE-2017-15089
CVE-2018-6834
CVE-2018-6835
CVE-2017-15713
CVE-2017-12634
CVE-2017-13782
CVE-2017-7545
CVE-2017-14949
CVE-2017-14868
CVE-2017-8046
CVE-2017-8045
CVE-2017-9805
CVE-2017-1000207
CVE-2017-1000208
CVE-2017-12612
CVE-2017-0141
I'd push something else for security, though, to complement it. RV-Match is my favorite commercial one because they built on a formal semantics for C, it's set for low false positives, and they open source a lot of stuff. They have something for Java and smart contracts, too. Past that, what's good depends on what language you use.
Github appears to be going the aqui-hire route with Semmle, dependabot, pullpanda etc, where as I don't think Gitlab's made an acquisition for a year or two.
> The total purchase price of the deal, paid in cash, will not exceed $1M and will be the total and only compensation for the entire deal.
This implies that in addition to self-funded ventures, they are looking for fire sales from failed start-ups.
It would allow a small team of hackers to have a decent exit without having to go through the whole startup road.
https://about.gitlab.com/devops-tools/ https://about.gitlab.com/stages-devops-lifecycle/secure/
The surprise is really that they're not being more aggressive in their acquisitions.
I've not heard from Yahoo in a year at least, do they still exist ...
(Non native speaker here). Am I misunderstanding something, or is the author explaining that humanity can not progress without the open source community?
Aspirational, as in, they wish that github would be the key factor in human progress. Maybe I can say that even plainer: to the leadership at github, the progress of the human race depends on github.
The open source community depends on github.
That's what it's implying.
(The reader is left to identify that as wishful thinking.)
What a way to begin an article.
1) identified str.replace('[ABC]+', '') correctly as a bug (looks like a regex but is string literal)
2) identified various unnecessary code that TypeScript overlooked
3) identified double-unescaping of html (this one would have probably gone unnoticed for years)
And a bunch of other stuff. No actual vulnerability in our case, but still very useful. I'm enabling their checks on every future PR.
This was TypeScript but they support the rest of our stack too (Python, Java). I wonder if this includes Kotlin - will try.
https://lgtm.com/projects/g/rust-lang/rust/snapshot/f5aa590b...
exist_ok is available from python 3.2, so this isn't a good impression.
Am sure this will bring some amazing advances to Github and thus a huge % of the developer community.