Automate container scanning

A container image bundles your application and an operating system userland. Both carry vulnerabilities, and they age differently: your code changes when you change it, the base image accumulates CVEs on someone else's schedule.

Two things to scan

Where scanning goes in the pipeline

Scan before push so a vulnerable image never enters the registry, and scan in the registry continuously so an image that was clean at build time raises an alert when a new CVE lands. Both are needed for the same reason a quiet repository still needs Dependabot alerts: the code stopped changing, the threat landscape did not.

CodeQL in a container

Running CodeQL analysis inside a container is a documented objective, and it needs advanced setup — the generated workflow file is where you specify the container and the build. Default setup cannot express it.

The typical reason is a compiled language whose build environment lives in the container: CodeQL must observe the real build to analyse it, so the analysis has to run where that build runs.

Rebuilding is the fix

Most base-image findings are resolved by rebuilding on a patched base rather than by changing your code — which makes an automated periodic rebuild a security control, not merely hygiene.

Primary sources

• https://docs.github.com/en/code-security/code-scanning
• https://learn.microsoft.com/en-us/azure/container-registry/scan-images-defender