3 ms·

It's interesting to see so many people here checking the code of all their open source packages, so here's my take on it as a security consultant: No, most peo

It's interesting to see so many people here checking the code of all their open source packages, so here's my take on it as a security consultant: No, most people don't, they even have a hard time keeping library versions up to date.

jfoster 6y ago
Do you have a pragmatic approach that you typically recommend, considering that (without version pinning thousands of packages) anything could change from one day to the next? (even if a package was "good" today, it could turn "bad" tomorrow) The best I've been able to come up with is to pick things that have minimal dependencies of their own. It doesn't eliminate the threat, but it does at least reduce it.
- cpach 6y ago
  IIRC there is some kind of SaaS solution for this but right now I can’t recall its name. Maybe someone else here knows? Edited: I reached out to some security people and it seems like the following are popular tools for this use case: Snyk / Dependabot / Whitesource.
  - gitgud 6y ago
    Github have a security check that scans your repo's dependencies and warns you about vulnerabilities too
- alltakendamned 6y ago
  No it’s not easy to realize. From a security perspective the idea is to always run the latest. Breaking backwards compatibility becomes a more difficult proposition. In reality you need to have an engineer test or analyze the updates. Some mature libraries maintain backwards compatibility (eg openssl) but if using something like npm it becomes almost impossible.
stevekemp 6y ago
I used to audit opensource code for security issues, on a regular basis, and even now before I install a public-facing application I generally have a look at the code. It's not often I spot anything major, but I figure if I have the time I should do it just in case. I often look at the code for PHP-extensions, npm-libraries, and similar that colleagues introduce. Just to be sure there's not anything blatently horrid going on.

jfoster 6y ago

Do you have a pragmatic approach that you typically recommend, considering that (without version pinning thousands of packages) anything could change from one day to the next? (even if a package was "good" today, it could turn "bad" tomorrow) The best I've been able to come up with is to pick things that have minimal dependencies of their own. It doesn't eliminate the threat, but it does at least reduce it.

cpach 6y ago
IIRC there is some kind of SaaS solution for this but right now I can’t recall its name. Maybe someone else here knows? Edited: I reached out to some security people and it seems like the following are popular tools for this use case: Snyk / Dependabot / Whitesource.
- gitgud 6y ago
  Github have a security check that scans your repo's dependencies and warns you about vulnerabilities too
alltakendamned 6y ago
No it’s not easy to realize. From a security perspective the idea is to always run the latest. Breaking backwards compatibility becomes a more difficult proposition. In reality you need to have an engineer test or analyze the updates. Some mature libraries maintain backwards compatibility (eg openssl) but if using something like npm it becomes almost impossible.

stevekemp 6y ago

I used to audit opensource code for security issues, on a regular basis, and even now before I install a public-facing application I generally have a look at the code. It's not often I spot anything major, but I figure if I have the time I should do it just in case. I often look at the code for PHP-extensions, npm-libraries, and similar that colleagues introduce. Just to be sure there's not anything blatently horrid going on.