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
