Option 1: Adding feature to npm/composer/gem/pip ad infinitum
Option 2: add per-language parser support to the alerting tool instead.
Option 2 doesn't necessitate a new (information-duplicating, still potentially error prone) standard, and can likely leverage available, tested libraries ;-)
* any non Javascript / ruby / go languages don't have standard packages, package names, etc.
* any non Javascript / ruby / go languages may be using one of many build systems. It's just too hard to troll through random build systems to see what dependencies are used
* therefore, a simple text file is what will work, and is what will be trivial for everyone to use
* if you find it too hard to update one line in a text file when you add (for example) a new dependency on libldap... you shouldn't be programming
Even more than that, Maven came up with the groupId concept, which I think is under-utilized by many other package managers... The leftpad fiasco could have been mitigated with it, for example.
Another cost of every language wanting at least one of its own dependency managers, often tightly integrated with the build system. The least-bad solution at this point would be to spin up a clean image, install the package in question, and figure out what else was also installed.
Point probably for lacking support for other than npm&gem packages is that for those langs/formats, there is a good sources for getting that sort of data externally.
This is something that lgtm.com supports. Right now, I can't find a Python project with a dependency on a vulnerable package to show you, but here's the page that shows Django's dependencies (and this is where a known vulnerable version would be highlighted).
When I ran the languages team at Heroku this was something we'd in some ad-hoc basis do for customers when there were major vulnerabilities. To see this fully productized is absolutely awesome! Well done to the GitHub team.
Clicked through the link to the security apps on the Github Marketplace and had a look at Snyk.io's pricing: 119$ through Github, 99$ if you get it straight from Snyk.io.
What is the benefit of getting anything via the Github marketplace that can be subscribed to outside of the marketplace ? What justifies that 25% cut appart from having a listing of apps ?
Perhaps GitHub is taking a cut from the purchase when purchased through their marketplace (20% is reasonably close to other marketplaces). Some services may be building that into the price.
What is the benefit of getting anything via the Github marketplace that can be subscribed to outside of the marketplace?
Potentially, your company might have a GitHub account you're allowed to add services to, but the finance department is less keen on new accounts. It also provides a well known company to complain to instead of yet another small vendor. Things enterprisey type customers tend to like. Manifold - https://www.manifold.co/ - is another player in this space.
Hey, I'm one of the cofounders of ZenHub - we're another popular integration on the marketplace and also sell our product separately through our own website.
From a company/integration on the marketplace, the marketplace has been great in terms of building awareness and exposure. Can confidently say that we've been able to reach new users and customers that we wouldn't have otherwise had if we weren't on the marketplace.
From the perspective of a GitHub user/team, lots of teams prefer to consolidate everything together on a single invoice. If you're using GitHub for software development, you're almost certainly going to need a CI/CD tool and PM tool, so why not bring everything together on a single bill?
If you're a large enterprise, paying an extra $20/month could definitely be worth not having the pain & cost of having your employees having to manage paying an extra bill each month.
Pricing for the marketplace was completely left up to the discretion of the integrators. There's a number of integrations (ZenHub included) that are the same price whether you buy through the marketplace or through company websites :)
If you see it that way, yes. But getting people to sign up on your website without the 25% cut is also not for free, think about costly advertising and so on. This is probably what Github and other marketplaces bet on. You always pay for any channel, whether it's direct cuts or upfront costs to get a customer.
I think the answer will be: Once it has been on github.com long enough for people to find any issues that GitHub themselves missed in their internal testing.
(Meta: That GIF should have been two small screenshots. No animation, no looping, no racing to understand before it switches frames. Stop making things GIFs that don't need to be GIFs. It hurts accessibility and adds nothing.)
Just looked at the "dependencies" for one of my projects and it interprets "react" as this 5 year old, defunct repo: https://github.com/wballard/react.
Let's be honest, unless you use a private NPM registry, "react" means https://www.npmjs.com/package/react. GitHub should use the standard resolution algorithm as employed by npm/yarn (the CLI tools).
Well this is frustrating. There is an issue with one of my projects apparently (actually saw it before I saw this on HN) and it is because of one of my indirect dependencies.
I presume in this scenario I need to either wait for a patch from the direct dependency or fork and submit a PR myself.
It's a great idea. I like it quite a bit. I just feel like the floodgates just got opened.
I don't know of any way to keep up with vulnerabilities _except_ an automated system. I use `bundle audit` in ruby-land. I don't know why github's automated system will be worse than anyone elses.
What alternative is there? Hoping you notice something on a listserv and realize its' one of your (possibly indirect) dependencies? That does not seem better. Automated monitoring and alert is the way to go.
And _everyone_ should _always_ be filing CVE's for their vulnerabilities, to make automated detection so much easier.
Automated tooling is a must, yes. The riskiest part about relying on ONLY GH's solution (IMO) is the NVD/CVE limitation.
I agree, CVE would be _awesome_ in theory. In reality, very few file for CVE's and so the coverage is iffy (~11% of npm package vulns and about ~67% of rubygem vulns https://snyk.io/stateofossecurity/).
But it goes beyond that. There was a great paper earlier this year (https://arxiv.org/abs/1705.05347) that highlighted many other issues: lag between CVE and NVD (which is where all the useful info comes from), mismatched CPE's, nonexistent CPE's, etc.
I would love to see us get to a point where the CVE/NVD was enough, but we're far from it right now.
I'd like it if github shows which projects had to be reminded of vulnerabilities this way instead of the developers knowing/addressing things themselves.
It seems like GitHub is slowly moving towards building their own static code analysis and security scanning. CI is probably coming up. This will bury many 3rd party services, but will be more convenient for end users.
I've said this in the past, but you really have to focus on the more difficult things, if you want to stay competitive in Git hosting. If it is easy to implement and is useful, one of your competitors, is going to copy you.
Right now GitHub, GitLab, Bitbucket, Microsoft, Gogs/Gitea, etc. all have something unique to them, but none of them, have the lock in power, like it was in the past with Perforce, ClearCase and other SCMs.
GitLab and other open source solutions, has turned core Git hosting functionality, into commodity features, that people expect to be good and cheap. So it only makes sense to start focusing on the not so hard things to do, which can't be easily duplicated.
Lego forums (I don't know if they still exist though). Apparently they went to great lengths to make them safe and accessible for children.
That said though, if anyone can crack this problem, it will be awesome. Children are already social, and are increasingly on the internet. And there are very few, if any, kid-friendly (not kid-condescending, or kids-as-afterthought) resources.
Most of the other problems listed look like first-world problems.
This is awesome! I found a security issue in an Elixir/Erlang project that was a dependency of many other projects and it was manual and complicated to coordinate amongst them. IIRC I suggested this to one of the other parties, although it seems trivial and obvious to other people, but it's good that GH also came upon this independently and shipped it.
Are the consequences significantly different than having private repos on Github to begin with?
I realize this is one more Github service with access to metadata about your code, so the attack surface is technically larger, but is the probability of leak that much greater from this service than it already is by having your code on their servers (which, I assume, are protected by the same security team)?
Maybe it's an oversimplification but my expectation is that any project with such sensitivity wouldn't be hosted on an external service at all.
It's absurd that companies are charging $100/mo just to run your dependency list against another public list of vulnerabilities. This service should be offered for free by GitHub.
102 comments
[ 3.2 ms ] story [ 167 ms ] threadThe lack of Python requirements.txt support is a bit odd, since it's conceptually quite similar to the two supported mechanisms.
I don't see that happening.
If people get value from it, editing a simple text file once or twice a year wouldn't be difficult.
A text file that just declares that "this project uses lib 2.1". It isn't a part of the build system in any way.
That would be awesome.
Option 1: Adding feature to npm/composer/gem/pip ad infinitum
Option 2: add per-language parser support to the alerting tool instead.
Option 2 doesn't necessitate a new (information-duplicating, still potentially error prone) standard, and can likely leverage available, tested libraries ;-)
* any non Javascript / ruby / go languages don't have standard packages, package names, etc.
* any non Javascript / ruby / go languages may be using one of many build systems. It's just too hard to troll through random build systems to see what dependencies are used
* therefore, a simple text file is what will work, and is what will be trivial for everyone to use
* if you find it too hard to update one line in a text file when you add (for example) a new dependency on libldap... you shouldn't be programming
Would have thought Maven popularized standard package names and build dependency (POM) files.
That allows you to run a check for vulnerable packages before each commit and via CI.
[0] https://docs.pipenv.org/advanced.html#detection-of-security-...
[1] https://github.com/kennethreitz/pipenv
https://python-packaging.readthedocs.io/en/latest/dependenci...
Example: https://github.com/HearthSim/python-hslog/blob/master/setup....
Altho you can write to one of the other formats or read from it - you'd have to tell the scanner what the true build source is
[0] https://github.com/kennethreitz/pipenv/blob/master/Pipfile
[0] https://docs.pipenv.org/advanced.html#detection-of-security-...
I hope they go with Pipfile/Pipfile.lock [0] and pipenv [1] rigth away!
[0] https://github.com/pypa/pipfile
[1] https://github.com/kennethreitz/pipenv
https://lgtm.com/projects/g/django/django/dependencies
And looking deeper into Github Marketplace pricing, I can see that Github takes a 25% cut (https://developer.github.com/apps/adding-integrations/managi...).
What is the benefit of getting anything via the Github marketplace that can be subscribed to outside of the marketplace ? What justifies that 25% cut appart from having a listing of apps ?
Potentially, your company might have a GitHub account you're allowed to add services to, but the finance department is less keen on new accounts. It also provides a well known company to complain to instead of yet another small vendor. Things enterprisey type customers tend to like. Manifold - https://www.manifold.co/ - is another player in this space.
From a company/integration on the marketplace, the marketplace has been great in terms of building awareness and exposure. Can confidently say that we've been able to reach new users and customers that we wouldn't have otherwise had if we weren't on the marketplace.
From the perspective of a GitHub user/team, lots of teams prefer to consolidate everything together on a single invoice. If you're using GitHub for software development, you're almost certainly going to need a CI/CD tool and PM tool, so why not bring everything together on a single bill?
https://github.com/facebook/react/blob/master/package.json
See Redux: https://github.com/reactjs/redux/blob/master/package.json#L3...
https://github.com/facebook/react/blob/master/packages/react...
I just checked 3 of my projects that use it, and all 3 are pointing to the correct "facebook react" repo.
Whether github is doing it or not, the baddies will be using similar tools to scan I'm sure.
I presume in this scenario I need to either wait for a patch from the direct dependency or fork and submit a PR myself.
It's a great idea. I like it quite a bit. I just feel like the floodgates just got opened.
Would be great to see PHP and Python in there.
What alternative is there? Hoping you notice something on a listserv and realize its' one of your (possibly indirect) dependencies? That does not seem better. Automated monitoring and alert is the way to go.
And _everyone_ should _always_ be filing CVE's for their vulnerabilities, to make automated detection so much easier.
I agree, CVE would be _awesome_ in theory. In reality, very few file for CVE's and so the coverage is iffy (~11% of npm package vulns and about ~67% of rubygem vulns https://snyk.io/stateofossecurity/).
But it goes beyond that. There was a great paper earlier this year (https://arxiv.org/abs/1705.05347) that highlighted many other issues: lag between CVE and NVD (which is where all the useful info comes from), mismatched CPE's, nonexistent CPE's, etc.
I would love to see us get to a point where the CVE/NVD was enough, but we're far from it right now.
Yup, that is the point I was trying to make.
I think a great many people at non-large companies are using free tools that I think are unlikely to be better than github's. Or no tool at all.
Right now GitHub, GitLab, Bitbucket, Microsoft, Gogs/Gitea, etc. all have something unique to them, but none of them, have the lock in power, like it was in the past with Perforce, ClearCase and other SCMs.
GitLab and other open source solutions, has turned core Git hosting functionality, into commodity features, that people expect to be good and cheap. So it only makes sense to start focusing on the not so hard things to do, which can't be easily duplicated.
Lego forums (I don't know if they still exist though). Apparently they went to great lengths to make them safe and accessible for children.
That said though, if anyone can crack this problem, it will be awesome. Children are already social, and are increasingly on the internet. And there are very few, if any, kid-friendly (not kid-condescending, or kids-as-afterthought) resources.
Most of the other problems listed look like first-world problems.
[1] https://github.com/rickhull?tab=repositories&type=source&lan...
mvn org.owasp:dependency-check-maven:check
Java FTW again :)
I realize this is one more Github service with access to metadata about your code, so the attack surface is technically larger, but is the probability of leak that much greater from this service than it already is by having your code on their servers (which, I assume, are protected by the same security team)?
Maybe it's an oversimplification but my expectation is that any project with such sensitivity wouldn't be hosted on an external service at all.
There are plenty of open source alternatives such as https://github.com/RetireJS/retire.js for JavaScript.
It's absurd that companies are charging $100/mo just to run your dependency list against another public list of vulnerabilities. This service should be offered for free by GitHub.