6 ms·

I think these sort of tools are detrimental to the security of apps and developers that use them. 1. They often treat all vulns the same and do almost nothing

I think these sort of tools are detrimental to the security of apps and developers that use them. 1. They often treat all vulns the same and do almost nothing to let a dev know if they are actually vulnerable or how bad a vuln really is (and no, just a pure CVSS is not good enough). 2. They lead to the idea that fixing vulns is just updating the dependencies. If you have enough vulns in your dependencies that you need it visualized in your IDE then the problem is how you choose dependencies or how many you have, not keeping them up to date. 3. Updates themselves are not always a safe bet since they bring in unknown code, so an update should not be treated as a silver bullet for fixing vulns without checking the code or actually trusting the authors. 4. Just like some of snyks blogposts (like https://news.ycombinator.com/item?id=19255603 https://news.ycombinator.com/item?id=19255603) they lead to more hysteria and security theater than productive work. In my experience all this leads to security fatigue and people not taking the profession or the work done seriously.

bastijn 7y ago
I'm mixed between nodding my head in this and finding arguments against it. For myself, I would absolutely see your points and agree to them but when I think about the engineers inside the company at scale I'm seeing it's worth. A large part of our company comes from hardware or more traditional console languages like c/c++/c#. Now switching to .net core, typescript and the whole open-source ecosystem is something they just are becoming familiar with. This extension would certainly make them aware of the impact of their choices. Raising awareness about the implications of taking in that third party dependency the moment they do it.
- SahAssar 7y ago
  > Raising awareness about the implications of taking in that third party dependency the moment they do it. Sure, but if that was the goal then I think it should show that a package has "578 subdependencies with 935 authors that have had 7681 vulns that took an average of 67 days to be resolved. No currently active vulns (that we know of...) though!" Currently I think it more encourages shifting the blame to the tool and I think some engineers would say something along the lines of "well, it didn't show me any vulns when I installed the package, so it should be fine, right?" Taking on deep or complex dependencies should be treated as code that needs to be maintained in the long run, not as a one-time decision. When a vuln appears in either a PR or in released code the checks in CI/CD should alert and refuse to build that release or approve that PR.
  - bastijn 7y ago
    Of course, yet it starts with awareness. Would love if the extensions would also show the number of child's, number of authors, if it has an active community, the license, and more info that you use to make the decision. Then again, we would also need the licenses of the children, their activity etc. It's a zoo out there these days. Packages that are licensed MIT have children that are GPL licensed. One package dragging in 200 more, leading to famous left-shift debacles and maintenance hell. Meanwhile support periods are being lowered to 1-3 years, even on big projects. Another issue we run into is different libraries using different packages which depend on the same package down the line but a different version which do not work together. So yes, I wholeheartedly agree that one must think before taking in a dependency. Especially if you just took it because a nice stackoverflow.com answer said so and you are going to use 1% of the package. Our build already immediately flags SOUP that is brought in but not assessed yet. We had it failing for a while but that was too much of a barrier for engineers. CI/CD scans for vulnerabilities using tools like whitesource or blackduck. Tools like fortify and sonarqube run amongst many more. All leading to better code, definitely. Yet, at a cost. Haven't found the best set of 'rules' yet what to allow and what a practical choice is today. Keeping velocity at the right quality.
L84Dinner 7y ago
1 - this is totally true. The problem here is it's excessively hard to tell someone what their risk profile is. Vulns kinda run a wild gamut, some occuring because you use a vulnerable method, but others because the library doesn't handle crypto right, uses an easy to guess default password, etc... Tooling around this has been hard to nail down, for a lot of those reasons. Some vendors are making tooling that will only report if you are using the "vulnerable method", but that has to be taken with a bit of caution as well, on account of it can't be 100% accurate. 2 - yeah, sort of. I think the tools do a really bad job as of today of going "well am I actually using this when it's deployed?". A lot of the vulnerabilities in a JS project are buried in devDependencies (which can be totally bad, imagine a bad actor of a library that has a bitcoin miner and now it's in your CI/CD process). Tooling that kinda tailors towards your "deployed" risk profile I think personally is more helpful, because it's about reducing the noise down to what matters. This can be hard to do in certain ecosystems, because for example in Python it's difficult to discern what a library is used for, but in JS, etc... it's a bit easier. 3 - agree 100% here, which is why overall project hygiene is probably the best indicator to if you would want to do that or not. Hygiene is something we should be using at the front end of selection of libraries in order to know that as time moves, we can trust updating, because the library is being managed in a responsible manner. 4 - ambulance chasing, more or less. If everything is an emergency than nothing is an emergency, either. Agree with you there, and I think the tone that has been set by companies in this space is not exactly right, but it originates from you know, trying to sell their stuff. Those posts likely resonate with AppSec people more than Developers, hence why they keep making them. That's just a guess however. Full disclosure, I work at Sonatype, and I work on a lot of the free tooling related to security scanning. Don't like how it is all playing out? Come work with us. Our tooling is open source, and we truly want to help developers out. Couple projects I think people would benefit from, and are community driven/participated in: Golang scanning: https://github.com/sonatype-nexus-community/nancy https://github.com/sonatype-nexus-community/nancy JavaScript scanning: https://github.com/sonatype-nexus-community/auditjs https://github.com/sonatype-nexus-community/auditjs RubyGems scanning: https://github.com/sonatype-nexus-community/chelsea https://github.com/sonatype-nexus-community/chelsea Conda (and soon PyPI) scanning: https://github.com/sonatype-nexus-community/jake https://github.com/sonatype-nexus-community/jake R (CRAN) scanning: https://github.com/sonatype-nexus-community/oysteR https://github.com/sonatype-nexus-community/oysteR We try and write these native to each ecosystem so that developers can work with us on them. Also we have them setup so you can use them anonymously by default, we have to eat sandwiches (or whatever your chosen food is) as well, but we try and provide tooling that all can benefit from. Come help us if you want!

bastijn 7y ago

I'm mixed between nodding my head in this and finding arguments against it. For myself, I would absolutely see your points and agree to them but when I think about the engineers inside the company at scale I'm seeing it's worth. A large part of our company comes from hardware or more traditional console languages like c/c++/c#. Now switching to .net core, typescript and the whole open-source ecosystem is something they just are becoming familiar with. This extension would certainly make them aware of the impact of their choices. Raising awareness about the implications of taking in that third party dependency the moment they do it.

SahAssar 7y ago
> Raising awareness about the implications of taking in that third party dependency the moment they do it. Sure, but if that was the goal then I think it should show that a package has "578 subdependencies with 935 authors that have had 7681 vulns that took an average of 67 days to be resolved. No currently active vulns (that we know of...) though!" Currently I think it more encourages shifting the blame to the tool and I think some engineers would say something along the lines of "well, it didn't show me any vulns when I installed the package, so it should be fine, right?" Taking on deep or complex dependencies should be treated as code that needs to be maintained in the long run, not as a one-time decision. When a vuln appears in either a PR or in released code the checks in CI/CD should alert and refuse to build that release or approve that PR.
- bastijn 7y ago
  Of course, yet it starts with awareness. Would love if the extensions would also show the number of child's, number of authors, if it has an active community, the license, and more info that you use to make the decision. Then again, we would also need the licenses of the children, their activity etc. It's a zoo out there these days. Packages that are licensed MIT have children that are GPL licensed. One package dragging in 200 more, leading to famous left-shift debacles and maintenance hell. Meanwhile support periods are being lowered to 1-3 years, even on big projects. Another issue we run into is different libraries using different packages which depend on the same package down the line but a different version which do not work together. So yes, I wholeheartedly agree that one must think before taking in a dependency. Especially if you just took it because a nice stackoverflow.com answer said so and you are going to use 1% of the package. Our build already immediately flags SOUP that is brought in but not assessed yet. We had it failing for a while but that was too much of a barrier for engineers. CI/CD scans for vulnerabilities using tools like whitesource or blackduck. Tools like fortify and sonarqube run amongst many more. All leading to better code, definitely. Yet, at a cost. Haven't found the best set of 'rules' yet what to allow and what a practical choice is today. Keeping velocity at the right quality.

L84Dinner 7y ago

1 - this is totally true. The problem here is it's excessively hard to tell someone what their risk profile is. Vulns kinda run a wild gamut, some occuring because you use a vulnerable method, but others because the library doesn't handle crypto right, uses an easy to guess default password, etc... Tooling around this has been hard to nail down, for a lot of those reasons. Some vendors are making tooling that will only report if you are using the "vulnerable method", but that has to be taken with a bit of caution as well, on account of it can't be 100% accurate. 2 - yeah, sort of. I think the tools do a really bad job as of today of going "well am I actually using this when it's deployed?". A lot of the vulnerabilities in a JS project are buried in devDependencies (which can be totally bad, imagine a bad actor of a library that has a bitcoin miner and now it's in your CI/CD process). Tooling that kinda tailors towards your "deployed" risk profile I think personally is more helpful, because it's about reducing the noise down to what matters. This can be hard to do in certain ecosystems, because for example in Python it's difficult to discern what a library is used for, but in JS, etc... it's a bit easier. 3 - agree 100% here, which is why overall project hygiene is probably the best indicator to if you would want to do that or not. Hygiene is something we should be using at the front end of selection of libraries in order to know that as time moves, we can trust updating, because the library is being managed in a responsible manner. 4 - ambulance chasing, more or less. If everything is an emergency than nothing is an emergency, either. Agree with you there, and I think the tone that has been set by companies in this space is not exactly right, but it originates from you know, trying to sell their stuff. Those posts likely resonate with AppSec people more than Developers, hence why they keep making them. That's just a guess however. Full disclosure, I work at Sonatype, and I work on a lot of the free tooling related to security scanning. Don't like how it is all playing out? Come work with us. Our tooling is open source, and we truly want to help developers out. Couple projects I think people would benefit from, and are community driven/participated in: Golang scanning: https://github.com/sonatype-nexus-community/nancy https://github.com/sonatype-nexus-community/nancy JavaScript scanning: https://github.com/sonatype-nexus-community/auditjs https://github.com/sonatype-nexus-community/auditjs RubyGems scanning: https://github.com/sonatype-nexus-community/chelsea https://github.com/sonatype-nexus-community/chelsea Conda (and soon PyPI) scanning: https://github.com/sonatype-nexus-community/jake https://github.com/sonatype-nexus-community/jake R (CRAN) scanning: https://github.com/sonatype-nexus-community/oysteR https://github.com/sonatype-nexus-community/oysteR We try and write these native to each ecosystem so that developers can work with us on them. Also we have them setup so you can use them anonymously by default, we have to eat sandwiches (or whatever your chosen food is) as well, but we try and provide tooling that all can benefit from. Come help us if you want!