5 ms·

Doesn’t the same logic apply to using :latest? If you are always pulling the latest, unvetted, code, shouldn’t you also have a vulnerability management process

Doesn’t the same logic apply to using :latest? If you are always pulling the latest, unvetted, code, shouldn’t you also have a vulnerability management process in place? You need vulnerability & risk management for any dependency, full stop.

oxfordmale 5y ago
Ideally you only use Docker official images,or their equivalent to avoid using unvetted code. 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
- yardstick 5y ago
  I wouldn’t describe Docker official images as more or less secure than anything else. Supply chain attacks can easily slip a vulnerability in.
- 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 ago
    I 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 ago
      In 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 ago
      I’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.

oxfordmale 5y ago

Ideally you only use Docker official images,or their equivalent to avoid using unvetted code. 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

yardstick 5y ago
I wouldn’t describe Docker official images as more or less secure than anything else. Supply chain attacks can easily slip a vulnerability in.
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 ago
  I 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 ago
    In 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 ago
    I’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.