azure-container-image-security

Standard IDs

ID	Severity	What it checks
IMG-001	P0	No base-image vulnerability scanning in the build pipeline
IMG-002	P0	Image runs as root with no non-root USER configured
IMG-003	P2	Full OS base image used where distroless/minimal would shrink the attack surface
IMG-004	P1	No image-signing/provenance verification before deployment

azure-aks-governance reviews the pod spec running a container (resource limits, NetworkPolicy, Workload Identity). This skill reviews the image itself — a perfectly governed pod spec still inherits every vulnerability baked into an unscanned, root-running base image.

---

Check A — No base-image vulnerability scanning (IMG-001)

Detection

Check the CI/CD pipeline (or ACR's built-in scanning, or a dedicated tool like Trivy/ Microsoft Defender for Containers) for an image-scan step that runs before an image is pushed to the registry or deployed. Without one, a known-vulnerable base image (an old Alpine/Debian version with a disclosed CVE) ships to production with nobody having looked.

BAD — image built and pushed with no vulnerability scan

# .github/workflows/build.yml
- run: docker build -t acr.azurecr.io/orders-api:${{ github.sha }} .
- run: docker push acr.azurecr.io/orders-api:${{ github.sha }}
# No scan step — a base image with known CVEs ships straight to the registry.

GOOD — scan gate before push, findings routed the same way as other vulnerability findings

- run: docker build -t acr.azurecr.io/orders-api:${{ github.sha }} .
- name: Scan image
  uses: aquasecurity/trivy-action@master
  with:
    image-ref: acr.azurecr.io/orders-api:${{ github.sha }}
    severity: 'CRITICAL,HIGH'
    exit-code: '1' # fails the build on critical/high findings — same severity bar as dependency-supply-chain
- run: docker push acr.azurecr.io/orders-api:${{ github.sha }} # only reached if the scan passed

Or, if ACR is the registry, enable Microsoft Defender for Containers' continuous registry scanning as a defense-in-depth complement to the build-time gate.