I've spent an inordinate amount of time at $dayjob triaging security vulnerabilities from Docker scans, so I can definitely attest to Mark's experience there. In fact, one of the biggest offenders was the official Docker Hub image for openjdk! Then there were a few years where people pushed Alpine Linux in containers, but then maintenance stopped related to that in openjdk, further leading to more outdated images. Then there's the fairly broad lack of security awareness in most published Docker images (e.g., running everything as root, installing unnecessary dependencies, leaving behind private keys, etc.) On the other hand, publishing updated images puts us back into the problem of distributing non-AL software.
Note that you could be releasing a new image every day, yet that doesn't fix the problem of outdated upstream layers, nor is it easily fixable by adding an "apt-get update && apt-get upgrade -y" step as that breaches back into licensing complexity (Apache isn't a Linux distribution after all!). On Tue, 8 Sep 2020 at 07:37, Jarek Potiuk <ja...@potiuk.com> wrote: > > Will definitely include that in my proposal Mark! > > BTW. Speaking of the report you got, we got the user talking to us on > slack, and got the user to retest it on the refreshed image. > > It all boiled down to 4 "undefined" risk issues reported by the tool (seems > that their - reasonable - approach is that anything High or Undefined is a > blocker). And the root cause in this case is that the base image that we > used (python-debian-buster) contains those vulnerabilities. Most have been > fixed in other releases of Debian (stretch, bullseye), but the current > (buster) LTS patch has been released over a month ago (3rd of August). With > their release cadence (~ 1/month) , we should get it sooner rather than > later. And following our tooling - we will regenerate and rebuild our > images once this is available (we are planning to automate this part soon). > And I hope most or all of those will be addressed. > > Following your analogy, that's indeed very true that the images age like > milk, so it looks like you are supposed to replace it with a fresh bottle > from time to time. I will try to capture that as best practice. > > I am tempted to put your analogy to the proposal ;) I wonder whether the > Board shares the same sense of humour. > > J. > > > > > On Tue, Sep 8, 2020 at 12:36 PM Mark J Cox <m...@apache.org> wrote: > > > On Mon, Sep 7, 2020 at 2:21 PM Jarek Potiuk <ja...@potiuk.com> wrote: > > > > > I also talked to the Apache Security team today (there was an issue > > raised > > > about the security of the images which I think should be part of the > > policy > > > as well. > > > > > > > Thanks Jarek. What happened is that we got a report to > > secur...@apache.org > > about a docker container that when scanned showed a lot of "unfixed > > vulnerabilities". I'm using quotes there because our usual response to > > people sending us unfiltered reports from scanning tools is to reject them; > > we get them quite often outside of containers and binary distributions, and > > they very rarely are useful. It's also fairly likely that the majority of > > the reported issues in the container are completely irrelevant too. For > > example the list contained a CVE for a power9 gcc issue. These scanners > > are basically going to just report on all the things in the underlying base > > image that are not updated, and even if you recreated images every day > > you'd still have unfixed CVEs on the list. > > > > Containers and other similar non-source distributions don't age well (a > > colleague used to say they 'age like milk, not wine'), they'll collect more > > and more of these layer vulnerabilities over time, and although most will > > be irrelevant, there are going to be times when such a vulnerability does > > actually matter, and we need to make sure projects producing them have a > > process for tracking that either my monitoring (lots of effort) or by at > > least frequent rebasing to keep them fresh. > > > > That's all assuming projects are making good security decisions to start > > with; basing on images that are maintained, in life, and updated, making > > sure users know the state/freshness of them, making sure users realise > > there will be vulns in the underlying layers and how to escalate reporting > > vulns they find that actually are exposed to the project. That should all > > be part of some guidelines on images. > > > > Cheers, Mark > > ASF Security Team > > > > > -- > +48 660 796 129 -- Matt Sicker <boa...@gmail.com> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@community.apache.org For additional commands, e-mail: dev-h...@community.apache.org
