• Regarding CVE-2016-1585: disabling apparmor didn't change anything in vuls… is some sort of apparmor running inside the containers?

• Regarding CVE-2017-18342: I pip uninstalled pyyaml 5.3.1 (python2) and pyyaml (5.3) which were both installed, but it didn't change anything in vuls - where is it seeing pyyaml (supposedly below 5.1) as a vulnerability? the containers?*

    *Interesting, I removed docker images for validation and re-run bluval and look at this part:
    Step 4/6 : RUN pip3 install -r /opt/akraino/validation/bluval/requirements.txt
     ---> Running in 00ce69d71a8d
    Collecting pyyaml
      Downloading PyYAML-5.3.1.tar.gz (269 kB)

    which means validation containers are indeed using PyYAML (but not below 5.1).

    anyway, still CVE detected after rebuilding the containers.

• Regarding CVE-2017-8283: again, on the host the dpdg version is 1.19.0.5, which is too new to be vulnerable, I'm guessing the problem lies in some container too

• Regarding CVE-2018-11236: the glibc version in my host ubuntu is 2.27-3… and according to https://launchpad.net/ubuntu/+source/glibc/+changelog I don't see anything that states it has been patched, so I'm assuming this CVE applies to the host - however, if Ubuntu 18.04 LTS upstream packages are not fixing it, what should be done?

• Regarding CVE-2018-20839: it seems to be specific to systemd 242, whereas the host has systemd 237 so yet again this must be coming from one of the containers.

• Regarding CVE-2019-9169: since ubuntu is still at 2.27-3 and there is nothing in https://launchpad.net/ubuntu/+source/glibc/+changelog complaining it was patched, so I'm assuming this CVE applies to the host - but just as before, what to do since Ubuntu 18.04 LTS upstream packages don't fix this?