You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This looks cool @franbuehler ! I think @bittner has a point in just creating a new one only when something is found. Do you need additional help with setting it up?
Whatever you can do that brings us forward is super-welcome!
We, at @vshn, would still need to invest time to verify the 4 main images (owasp/modsecurity:apache, owasp/modsecurity-crs:apache, and owasp/modsecurity:nginx, owasp/modsecurity-crs:nginx) in Production. We still maintain derivatives of our own image based on CRS 3.1, which is somewhat the "mother" of the changes we applied to the current images. I see some work ahead to align the last bits we might have overlooked when taking over our current features.
Now that modsecurity-docker has moved to Alpine it would be nice to see modsecurity-crs-docker also move from Debian to Alpine.
NGINX maintain both Debian and Alpine images, so hopefully this is not a large increase in maintenance burden as we can still rely on default upstream images.
Implemented in #459, which took over the stalled #296.
Pull requests scan the image they just built and fail on HIGH,CRITICAL findings that have a fix available, so only actionable vulnerabilities block a merge. A daily workflow scans the published ghcr.io images, one scan per image and platform, and reports into code scanning instead of failing.
It has already earned its keep before merging: it caught CVE-2026-34191, CVE-2026-33630 and CVE-2026-56408 in the alpine images (fixed in #465) and CVE-2026-53615 in the debian ones (#466). Both came from base images shipping package versions the distributions had already patched.
Activity
franbuehler commentedon Aug 30, 2020
I tried this in my fork and it works. We have vulnerabilities in our images though:
modsecurity-crs-docker
https://github.com/franbuehler/modsecurity-crs-docker/runs/1047826260?check_suite_focus=true:
I think a rebuild and push of the underlying owasp/modsecurity-docker image would already help, we have fewer vulnerabilities there:
modsecurity-docker
https://github.com/franbuehler/modsecurity-docker/runs/1047876721?check_suite_focus=true
Questions:
Do we want to add a schedule to the "build and push" workflows:
Like once a week so that we always have new images with no vulnerabilites?
And do we want to extend the build and push with this security scan?
bittner commentedon Aug 30, 2020
Adding a scheduled scan makes certainly sense. We should then only trigger rebuilding the image when necessary, e.g. when vulnerabilities were found.
fzipi commentedon Aug 30, 2020
This looks cool @franbuehler ! I think @bittner has a point in just creating a new one only when something is found. Do you need additional help with setting it up?
bittner commentedon Aug 31, 2020
Whatever you can do that brings us forward is super-welcome!
We, at @vshn, would still need to invest time to verify the 4 main images (owasp/modsecurity:apache, owasp/modsecurity-crs:apache, and owasp/modsecurity:nginx, owasp/modsecurity-crs:nginx) in Production. We still maintain derivatives of our own image based on CRS 3.1, which is somewhat the "mother" of the changes we applied to the current images. I see some work ahead to align the last bits we might have overlooked when taking over our current features.
franbuehler commentedon Sep 1, 2020
Thank you @fzipi and @bittner
Ok, I'll try to implement this (when I find some time).
And yes, then we should investigate which changes are still missing in our official images and what else needs to be done.
bittner commentedon Sep 14, 2020
Relates to coreruleset/modsecurity-docker#43.
MitchellCash commentedon Aug 5, 2021
I also just ran a
trivyscan againstowasp/modsecurity-crs:v3.3.2-nginxand it returned:Now that
modsecurity-dockerhas moved to Alpine it would be nice to seemodsecurity-crs-dockeralso move from Debian to Alpine.NGINX maintain both Debian and Alpine images, so hopefully this is not a large increase in maintenance burden as we can still rely on default upstream images.
fzipi commentedon Nov 30, 2021
@MitchellCash Can you run it again now that we have alpine images? We still need to run this in a pipeline.
MitchellCash commentedon Dec 1, 2021
@fzipi Alpine based image looks good to me on the initial
trivyscan (also the image is almost half the size)! Nice work!Debian based image
Alpine based image 🥳
fzipi commentedon Jan 18, 2022
Good, this matches my own tests. I don't think we can do too much in the debian image (I've checked a couple criticals, and they are still there :/ ).
fzipi commentedon Aug 18, 2026
Implemented in #459, which took over the stalled #296.
Pull requests scan the image they just built and fail on
HIGH,CRITICALfindings that have a fix available, so only actionable vulnerabilities block a merge. A daily workflow scans the publishedghcr.ioimages, one scan per image and platform, and reports into code scanning instead of failing.It has already earned its keep before merging: it caught
CVE-2026-34191,CVE-2026-33630andCVE-2026-56408in the alpine images (fixed in #465) andCVE-2026-53615in the debian ones (#466). Both came from base images shipping package versions the distributions had already patched.