Timeline for Current (Feb 2024) High-Severity unfixed Linux Kernel CVEs
Current License: CC BY-SA 4.0
7 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Mar 4 at 17:22 | comment | added | laserslasers | We use Fargate to run the instance(s) the containers are on, and AWS handles managing those completely - there's no visibility of what distro/version of Linux those are running, etc. They handle patch fixes themselves and notify users if necessary for downtime: d1.awsstatic.com/whitepapers/… | |
| Mar 3 at 17:28 | comment | added | AlexD | @multithr3at3d, then they should be reported against the instance that runs the kernel, not a container image in the registry. You should notice that I recommended suppressing these findings for the resource type "ECR Image" only and not for all resources. | |
| Mar 3 at 16:20 | comment | added | multithr3at3d | "Moreover, as these reportings are made against your Docker image you can ignore all Linux kernel vulnerabilities" -- unless they apply to the kernel the container is actually running on. | |
| Feb 28 at 15:56 | vote | accept | laserslasers | ||
| Feb 28 at 15:55 | comment | added | laserslasers | Very helpful - and makes sense on the Linux kernel vulnerabilities not being applicable to a Docker container image in the first place. For the rest, determining whether a CVE actually applies to our application use case certainly makes sense (although may potentially be difficult in some cases given the number of app / OS package dependencies any real production app has). In the past (really for years) we'd simply never had so many false positives / unfixed CVEs even showing up, so this was simply out of the ordinary for us. | |
| Feb 28 at 8:50 | history | edited | AlexD | CC BY-SA 4.0 |
added 28 characters in body
|
| Feb 28 at 8:17 | history | answered | AlexD | CC BY-SA 4.0 |