4 ms·
> Ideally you only use Docker official images,or their equivalent to avoid using unvetted code. Docker images don’t ship every dependency in the average develo
by laumars 5y ago
> Ideally you only use Docker official images,or their equivalent to avoid using unvetted code.
Docker images don’t ship every dependency in the average development project. They’re also not a security guarantee either.
> It is always a trade off, however it is far more likely that a hacker will use a ten year old well exploited CVE, rather than a recent one
In general that’s the case but in practice that’s still the wrong mindset. You pin to a minor version and still get patch updates. Or run CVE checks to prove you’re dependencies have no reported vulnerabilities. And that will also mitigate the risk of you again accidentally updating to to new vulnerabilities (though you’d need to pin against patch version too if you want to be certain there)
- oxfordmale 5y agoI have seen many cases where a something is pinned to a minor version, and then gets forgotten about for 2 or 3 years. In my current companies there is Production codebase that hasn't been touched for over two years. The original developers have long since moved on and no one really owns the code. That is the most common scenario leading to security breaches. This is about succession planning, with the realisation there might not be any succession if business priorities change.
- yardstick 5y agoIn that case, better the devil you know? But either way if you don’t have a vulnerability management plan you are at risk.
- laumars 5y agoI’ve seen many cases were version pinning has caused issues at the worst possible time (like missed delivery dates because of a breaking change in dependencies being pushed by maintainers at an inconvenient time for us). Ultimately there’s no perfect answer here but given a choice I’d rather opt for a known risk than an unknown one.