The Anchore OSS team was on the Microsoft community call for mariner users last week. At this meeting, we got a chance to demo some new grype capabilities for when Azure Linux 3.0 becomes generally available.
The Anchore OSS team builds its vulnerability feeds and data sourcing out in the open. It’s important to note that an update to support a new distro release (or naming migration for past releases) can require pull requests in up to three different repositories. Let’s look at the pull requests supporting this new release of Azure Linux and walk through how we can build a local copy of the demo on our machines.
Grype ecosystem changes that support new Linux distributions
Here are the three pull requests required to get Azure Linux 3.0 working with grype.
- Grype-db: this change asserts that the new data shape and data mapping is being done correctly when processing the new Azure Linux 3.0 vulnerability data
- Vunnel: this change sources the vulnerability data from Microsoft and transforms it into a common scheme that grype-db can distribute
- Grype: this change adds the base distro types used by grype-db, vunnel, and grype so that matching can be correctly associated with both the old mariner and new Azure Linux 3.0 data
For this preview, let’s do a quick walkthrough on how a user could test this new functionality locally and get a grype db for just Azure Linux 3.0 setup. When Azure Linux 3.0 is released as generally available, readers can look forward to a more technical post on how the vunnel and grype-db data pipeline works in GitHub actions, what matching looks like, and how syft/grype can discern the different distribution versions.
Let’s get our demo working locally in anticipation of the coming release!
Setting up the Demo
To get the demo setup readers will want to make sure they have the following installed:
- Git to clone and interact with the repositories
- The latest version of Golang
- A managed version of Python running at 3.12.x. If you need help getting a managed version of python setup we recommend mise.
- The poetry python dependency manager
- Make is also required as part of developing and bootstrapping commands in the three development environments.
After the dev dependencies are installed, clone down the three repositories listed above (grype, grype-db, and vunnel) into a local development folder and checkout the branches listed in the above pull requests. I have included a script to do all this for you below.
#!/bin/bash
# Define the repositories and the branch
REPOS=(
"https://github.com/anchore/grype.git"
"https://github.com/anchore/grype-db.git"
"https://github.com/anchore/vunnel.git"
)
BRANCH="feat-azure-linux-3-support"
FOLDER="demo"
# Create the folder if it doesn't exist
mkdir -p "$FOLDER"
# Change to the folder
cd "$FOLDER" || exit
# Clone each repository, checkout the branch, and run make bootstrap
for REPO in "${REPOS[@]}"; do
# Extract the repo name from the URL
REPO_NAME=$(basename -s .git "$REPO")
# Clone the repository
git clone "$REPO"
# Change to the repository directory
cd "$REPO_NAME" || exit
# Checkout the branch
git checkout "$BRANCH"
# Run make bootstrap
make bootstrap
# Special handling for grype-db repository
if [ "$REPO_NAME" == "grype-db" ]; then
# Add the replace directive to go.mod
echo 'replace github.com/anchore/grype v0.78.0 => ../grype' >> go.mod
# Run go mod tidy
go mod tidy
fi
# Special handling for grype repository
if [ "$REPO_NAME" == "grype" ]; then
# Run go mod tidy
go mod tidy
fi
# Change back to the parent folder
cd ..
done
echo "All repositories have been cloned, checked out, and built."
Pulling the new Azure Linux 3.0 vulnerability data
We will be doing all of our work in the vunnel repository. We needed to pull the other two repositories since vunnel can orchestrate and build those binaries to accomplish its data aggregation goals.
To get all the repositories built and usable in vunnel, run the following commands:
cd demo/vunnel
poetry shell
make dev provider="mariner"
make update-db
That should produce output similar to the following:
Entering vunnel development shell...
• Configuring with providers: mariner ...
• Writing grype config: ./demo/vunnel/.grype.yaml ...
• Writing grype-db config: ./demo/vunnel/.grype-db.yaml ...
• Activating poetry virtual env: /Library/Caches/pypoetry/virtualenvs/vunnel-0PTQ8JOw-py3.12 ...
• Installing editable version of vunnel ...
• Building grype ...
• Building grype-db ...
mkdir -p ./bin
Note: development builds grype and grype-db are now available in your path.
To update these builds run 'make build-grype' and 'make build-grype-db' respectively.
To run your provider and update the grype database run 'make update-db'.
Type 'exit' to exit the development shell.
.....Records being processed
This should lead to a local vulnerability db being built for just the Azure Linux 3.0 data. You can interact with this data and use the locally built grype to see how the data can be used against an older preview image of Azure Linux 3.0.
Let’s run the following command to interact with the new Azure Linux 3.0 data and preview grype against an older dev build of the container image to make sure everything is working correctly:
./bin/grype azurelinuxpreview.azurecr.io/public/azurelinux/base/core:3.0.20240401-amd64
✔ Loaded image azurelinuxpreview.azurecr.io/public/azurelinux/base/core:3.0.20240401-amd64
✔ Parsed image sha256:3017b52132fb240b9c714bd09e88c4bc1f8e55860de23c74fe2431b8f75981dd
✔ Cataloged contents 9b4fcfdd3a247b97e02cda6011cd6d6858dcdf98d1f95fb8af54d57d2da89d5f
├── ✔ Packages [75 packages]
├── ✔ File digests [1,495 files]
├── ✔ File metadata [1,495 locations]
└── ✔ Executables [380 executables]
✔ Scanned for vulnerabilities [17 vulnerability matches]
├── by severity: 0 critical, 8 high, 7 medium, 2 low, 0 negligible
└── by status: 17 fixed, 0 not-fixed, 0 ignored
NAME INSTALLED FIXED-IN TYPE VULNERABILITY SEVERITY
expat 2.5.0-1.azl3 0:2.6.2-1.azl3 rpm CVE-2024-28757 High
expat 2.5.0-1.azl3 0:2.6.2-1.azl3 rpm CVE-2023-52425 High
expat 2.5.0-1.azl3 0:2.6.2-1.azl3 rpm CVE-2023-52426 Medium
expat-libs 2.5.0-1.azl3 0:2.6.2-1.azl3 rpm CVE-2024-28757 High
expat-libs 2.5.0-1.azl3 0:2.6.2-1.azl3 rpm CVE-2023-52425 High
expat-libs 2.5.0-1.azl3 0:2.6.2-1.azl3 rpm CVE-2023-52426 Medium
glibc 2.38-3.azl3 0:2.38-6.azl3 rpm CVE-2023-6779 High
glibc 2.38-3.azl3 0:2.38-6.azl3 rpm CVE-2023-6246 High
glibc 2.38-3.azl3 0:2.38-6.azl3 rpm CVE-2023-5156 High
glibc 2.38-3.azl3 0:2.38-6.azl3 rpm CVE-2023-4911 High
glibc 2.38-3.azl3 0:2.38-6.azl3 rpm CVE-2023-6780 Medium
libgcc 13.2.0-3.azl3 0:13.2.0-7.azl3 rpm CVE-2023-4039 Medium
libstdc++ 13.2.0-3.azl3 0:13.2.0-7.azl3 rpm CVE-2023-4039 Medium
openssl 3.1.4-3.azl3 0:3.3.0-1.azl3 rpm CVE-2023-6237 Medium
openssl 3.1.4-3.azl3 0:3.3.0-1.azl3 rpm CVE-2024-2511 Low
openssl-libs 3.1.4-3.azl3 0:3.3.0-1.azl3 rpm CVE-2023-6237 Medium
openssl-libs 3.1.4-3.azl3 0:3.3.0-1.azl3 rpm CVE-2024-2511 Low
Updating the image
Many vulnerable container images can be remediated by consuming the upstream security team’s fixes. Let’s run the same command against the latest preview version released from Microsoft:
./bin/grype azurelinuxpreview.azurecr.io/public/azurelinux/base/core:3.0
✔ Loaded image azurelinuxpreview.azurecr.io/public/azurelinux/base/core:3.0
✔ Parsed image sha256:234cac9f296dd1d336eecde7a97074bec0d691c6fd87bd4ff098b5968e579ce1
✔ Cataloged contents 9964aca715152fb6b14bfb57be5e27c655fb7d733a33dd995a5ba72157c54ee7
├── ✔ Packages [76 packages]
├── ✔ File digests [1,521 files]
├── ✔ File metadata [1,521 locations]
└── ✔ Executables [380 executables]
✔ Scanned for vulnerabilities [0 vulnerability matches]
├── by severity: 0 critical, 0 high, 0 medium, 0 low, 0 negligible
└── by status: 0 fixed, 0 not-fixed, 0 ignored
No vulnerabilities found
Awesome! Microsoft security teams for the Azure Linux 3 preview images have been highly responsive in ensuring up-to-date images containing fixes or remediations to any security findings are published.
We’re excited to see the new Azure Linux 3 release when it’s ready! In the meantime, you can grab our latest Grype release and try it on all your other containers. If you have questions or problems, join the Anchore Open Source Team on Discourse or check out one of our weekly Live Streams on YouTube.
Automate your SBOM management with Anchore Enterprise. Get instant access with a 15-day free trial.