Container Registry Security Scanning

Azure Container Registry (ACR) security scanning, also known as vulnerability assessment, is a built-in or integrated feature that analyzes container images for known security vulnerabilities. The primary goal is to identify and report vulnerabilities in the operating system packages and application dependencies within the image layers. Scanning is essential for maintaining a secure software supply chain and is a key requirement for compliance frameworks like PCI DSS, HIPAA, and FedRAMP.

ACR scanning operates by comparing the contents of each image layer against a continuously updated vulnerability database. The process is: 1. Image Push Trigger: When an image is pushed to an ACR repository, the registry can automatically trigger a scan. This is configured at the registry level via the acr scan policy or by integrating with Microsoft Defender for Cloud. 2. Layer Extraction: The scanner pulls the image manifest and extracts each layer's filesystem. It identifies installed packages (e.g., apt, yum, pip, npm) and their versions. 3. Vulnerability Matching: The extracted package list is cross-referenced with the vulnerability database. For each package, the scanner checks if the installed version is affected by any known Common Vulnerabilities and Exposures (CVEs). The database is updated multiple times daily from sources like the National Vulnerability Database (NVD), Ubuntu Security Notices, Red Hat Security Advisories, and others. 4. Severity Classification: Each matched vulnerability is assigned a severity level (Low, Medium, High, or Critical) based on the CVSS score. The scanner also provides a fix version if available. 5. Report Generation: The scan results are stored in the ACR repository metadata. You can view them via the Azure portal, Azure CLI, or API. The report includes the list of vulnerabilities, their severity, CVE IDs, and remediation advice. 6. Re-scan Triggers: Scans can be re-triggered manually or automatically when the vulnerability database is updated. Microsoft Defender for Cloud can trigger re-scans when new CVEs are published.

To enable scanning via Defender for Cloud:

# Enable Defender for Cloud on subscription
az security pricing create --name 'ContainerRegistry' --pricing-tier 'Standard'

# Verify status
az security pricing show --name 'ContainerRegistry'

To trigger a manual scan (without Defender):

# Install ACR scan extension
az extension add --name acr-scan

# Run scan on an image
az acr scan --registry myregistry --repository myrepo --image myimage:tag

To view scan results:

az acr scan list --registry myregistry --repository myrepo
az acr scan show --registry myregistry --repository myrepo --image myimage:tag

To list vulnerabilities from the result:

az acr scan list-vulnerabilities --registry myregistry --repository myrepo --image myimage:tag

A large bank uses ACR to store container images for its trading applications. Regulatory compliance requires that all images be free of critical and high vulnerabilities before deployment. The bank enables Defender for Cloud for Container Registry across all subscriptions. They integrate scanning into their CI/CD pipeline using Azure DevOps. When a developer pushes a new image, the pipeline triggers a scan. If the scan reports any critical vulnerabilities, the pipeline fails and the image is not deployed. The security team receives alerts via Azure Monitor and uses Defender for Cloud's dashboard to track remediation progress. The bank also uses Azure Policy to enforce that only scanned images (with no critical vulnerabilities) can be deployed to AKS. This ensures compliance with PCI DSS requirement 6.2. The main challenge is handling false positives—packages flagged as vulnerable but not exploitable in the context of the application. The team uses the 'Suppress' feature to ignore known false positives, but they must document the justification for auditors.

An e-commerce company pushes hundreds of images per day to ACR. They use multi-stage builds to keep images small. With Defender for Cloud enabled, every push triggers a scan. The security team noticed that scans sometimes fail due to timeouts for very large images (e.g., ones exceeding 30 minutes). They optimized their Dockerfiles to reduce layer count and image size. They also use the acr scan CLI to trigger scans on demand for pre-production images. For production, they rely on automatic scans. They use Defender for Cloud's 'Recommendations' to prioritize fixes. The biggest issue they faced was a zero-day vulnerability in a popular base image that was discovered after the image had been scanned and deployed. Defender for Cloud automatically re-scanned all images in the registry within 24 hours of the new CVE being added to the database, and flagged the affected images. The team was able to quickly rebuild and redeploy. This proactive re-scanning is critical for maintaining security in a fast-paced environment.

A global SaaS provider uses a single ACR replicated across multiple regions (geo-replication) to serve customers worldwide. They need to ensure that all images are scanned regardless of which region they are pushed to. With Defender for Cloud enabled, scans are performed in the region where the image is pushed. However, scan results are stored in the same region. The security team uses a central Defender for Cloud dashboard to view vulnerabilities across all regions. They encountered a problem: when a vulnerability is suppressed in one region, it is not automatically suppressed in others. They had to use Azure Policy to apply consistent suppression rules across regions. They also use Azure Resource Graph to query scan results across all registries. This allows them to generate compliance reports for auditors.