AzureFeeds

Last year, I blogged about Container Patching with Azure DevOps, Trivy and Copacetic, and how to use Azure DevOps to automate the patching of your container images using Trivy and Copacetic. This was a great solution, but it required a lot of manual work to set up and maintain. Today, I am going to take a look at Continuous Patching with Azure Container Registry (ACR) and how to use it to automate the patching of your container images.

🛡️ What is ACR Continuous Patching?​

🧪 Test Environment Setup​

In my testing, I am going to use the api-firewall image, version 0.6.16 that I have pushed to my Azure Container Registry.

⚙️ How Continuous Patching Works​

Let’s take a look at how this will work.

Continuous Patching in ACR creates a new image per patch. ACR relies on a tag convention to version and identify patched images. The two main approaches are incremental and floating.

Incremental (default) is ideal for environments where auditability and rollbacks are crucial, as a unique tag identifies each new patch.

Floating is ideal if you prefer a single pointer to the latest patch for your CI/CD pipelines. Reduces complexity by eliminating the need to update references in downstream applications with each patch, but sacrifices strict versioning, making it challenging to roll back.

🚀 Getting Started with Continuous Patching​

So let us get started. To begin, I will utilize my Codespace_IaC_Coding Codespace configuration, which already meets the prerequisites I need, specifically Azure CLI.

📦 Installing the Required Extension​

To start, we need to install the CLI extension for ACR Continuous Patching:

az extension add --source https://acrcssc.z5.web.core.windows.net/debug/acrcssc-1.0.0b2-py3-none-any.whl

Then we need to log in to our Azure Container Registry:

az login
az acr login -n <myRegistry>

📝 Configuring the Continuous Patching Schema​

Now we need to prepare the JSON schema that we will use to configure our Continuous Patching.

This schema defines which repositories and tags to patch, when to patch them, and how to tag the patched images.

The schema includes these key components:

• version – Used by the ACR team to track schema versions. Don’t modify this unless instructed.
• tag-convention – Optional field that specifies the tagging method. Values can be “incremental” (default) or “floating”.
• repositories – An array of objects containing:
  • repository – The name of the repository to patch
  • tags – Array of specific tags to patch (use wildcard * to include all tags)
  • enabled – Boolean (true/false) to enable or disable patching for this repository

For example:

{
  "version": "v1",
  "tag-convention": "incremental",
  "repositories": [
    {
      "repository": "api-firewall",
      "tags": ["0.6.7", "latest"],
      "enabled": true
    }
  ]
}

So let us create the file as below:

cat <<EOF > continuouspatching.json
{
  "version": "v1",
  "tag-convention": "incremental",
  "repositories": [
    {
      "repository": "api-firewall",
      "tags": ["0.6.7", "latest"],
      "enabled": true
    }
  ]
}
EOF

🧐 Running a Dry Run​

Next, we can run a dry run of the supply-chain workflow to validate that our repository and tags are correct:

az acr supply-chain workflow create -r myRegistry -g myResourceGroup -t continuouspatchv1 --config ./continuouspatching.json --schedule 1d --dry-run   

You can also view the run in the Azure Portal, and see it pull the CSSC (Microsoft’s Containers Secure Supply Chain (CSSC) framework) image to run the workflow.

📅 Understanding the Scheduling System​

Before we do, let’s understand how scheduling works in ACR Continuous Patching.

The scheduling system works like a calendar with fixed dates each month, not like a countdown timer!

The --schedule parameter sets how many days between patch runs, but these always align to fixed days counting from the 1st of each month. Think of it like marking specific dates on a calendar.

For example, if you choose --schedule 7d, patching will run on the 1st, 8th, 15th, 22nd, and 29th of each month (every 7 days from the 1st).

Here’s what happens with different schedule values:

When you add the --run-immediately flag, a patch happens right away, and then the next one follows the regular schedule.

Remember: The schedule always resets at the beginning of each month. So if your last patch in January was on the 29th with a 7d schedule, the next one will be on February 1st, not February 5th.

▶️ Executing the Workflow​

Now let’s run the workflow:

az acr supply-chain workflow create -r myRegistry -g myResourceGroup -t continuouspatchv1 --config ./continuouspatching.json --schedule 14d --run-immediately --verbose

az acr supply-chain workflow delete -r myRegistry -g myResourceGroup -t continuouspatchv1 --yes

🔧 Reviewing the Created Tasks​

Now that the Tasks have been created, you can see them in the Azure Portal.

You can also run the following command to see the state of the workflows:

az acr supply-chain workflow show -r myRegistry -g myResourceGroup -t Continuouspatchv1  -o table

The workflow creates three tasks in your Azure Container Registry:

These three tasks work together to form a complete patching pipeline: the trigger starts on schedule, the scanner identifies vulnerabilities, and the patcher automatically fixes them.

📊 Monitoring Task Execution​

You can check the logs of the run by looking up the recent Runs:

az acr task logs --registry myRegistry

🎯 Viewing the Results​

Now, if we go into the repositories in the Azure Portal, we can see that the image has been patched with the incremental tag.