Issue in COMDEV created: https://issues.apache.org/jira/browse/COMDEV-382
I will prepare an early draft of the proposal shortly and ping here to spark a discussion J. On Tue, Sep 8, 2020 at 5:59 PM Matt Sicker <boa...@gmail.com> wrote: > 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 > > -- +48 660 796 129
