3 ms·
If anything, it hugely increases the risk of vulnerable libraries being built into the binary and forgotten. Same with containers. Statistics clearly show the
by eeZah7Ux 8y ago
If anything, it hugely increases the risk of vulnerable libraries being built into the binary and forgotten.
Same with containers. Statistics clearly show the security impact.
- cassianoleal 8y agoDo you have a reference to such statistics? I'd love to use them as yet another reason against vendoring dependencies when I talk to colleagues.
- viraptor 8y agohttps://blog.acolyer.org/2017/04/03/a-study-of-security-vulnerabilities-on-docker-hub/ https://blog.acolyer.org/2017/04/03/a-study-of-security-vuln... Cautiously posting that link, because I'm not against vendoring. You just need a process around keeping your dependencies up to date / refreshed automatically. The ability to vendor is one thing, how you use it is another.
- cassianoleal 8y agoThanks! I agree with your statement, but what I usually see in real life is that once dependencies are vendored in they never change.
- eeZah7Ux 8y ago> You just need a process around keeping your dependencies up to date / refreshed automatically That's what dynamic linking and Linux distributions are for.
- kbar13 8y agoi dont see how that's true. in both worlds, a developer has to take the manual action to review published vulnerabilities and track down repos they own that are affected and upgrade the dependencies.
- eeZah7Ux 8y agoNo: with dynamic linking, and especially with Linux distributions, most of the work is automated and the patching is done by the distribution security team. The time to write a patch and deliver it to running systems goes down to days or, more often, hours.