[reificator]

I find that Go developers also tend to have a 'vendor everything' philosophy which significantly decreases that risk.

At least the ones I meet tend to take that approach...

[eeZah7Ux]

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.

[kbar13]

i 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]

No: 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.

[cassianoleal]

Do 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]

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]

Thanks!

I agree with your statement, but what I usually see in real life is that once dependencies are vendored in they never change.

[eeZah7Ux]

> You just need a process around keeping your dependencies up to date / refreshed automatically

That's what dynamic linking and Linux distributions are for.