4 ms·

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 ab

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.

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.