Grype on Ubuntu 24.04 on Azure User Guide

Overview

Grype is a fast, open-source vulnerability scanner from Anchore. From a single CLI it finds known CVEs in OS packages (Alpine, Debian/Ubuntu, RHEL and more) and in language dependencies (Java, Python, JavaScript, Ruby, Go, .NET, Rust, PHP and others), across container images, directories, filesystems, archives and git checkouts, and it can read a Syft, SPDX or CycloneDX SBOM you produced earlier in your pipeline. The cloudimg image installs Grype 0.116.0 as the /usr/bin/grype command, pre-downloads the vulnerability database into a shared system cache so your first scan is fast, and exports the cache for every shell. Backed by 24/7 cloudimg support.

What is included:

• Grype 0.116.0 (the /usr/bin/grype CLI) from the official Anchore release, checksum-verified against the project's signed checksums.txt
• The vulnerability database pre-downloaded into a shared cache at /var/lib/grype/db
• GRYPE_DB_CACHE_DIR exported for every shell (via /etc/profile.d/grype.sh and /etc/environment)
• Container-image scanning with no Docker daemon required
• OS-package, language-dependency and SBOM vulnerability scanning with severity gating for CI
• 24/7 cloudimg support

This is a command-line product: no web UI, no listening service, no open ports beyond SSH.

Prerequisites

An active Azure subscription, an SSH key pair, and a VNet + subnet in the target region. Standard_B2s (2 vCPU / 4 GiB RAM) is a good starting point. NSG inbound: allow 22/tcp from your management network. No inbound application ports are needed.

Step 1 - Deploy from the Azure Marketplace

Sign in to the Azure Portal, choose Create a resource, search the Marketplace for Grype by cloudimg, and select Create. On Basics pick your subscription, resource group, region and size; under Administrator account choose SSH public key and paste your key; under Inbound port rules allow SSH (22). Then Review + create -> Create.

Step 2 - Deploy from the Azure CLI

az vm create \
  --resource-group <your-rg> \
  --name grype \
  --image <marketplace-image-urn> \
  --size Standard_B2s \
  --admin-username azureuser \
  --ssh-key-values ~/.ssh/id_ed25519.pub \
  --vnet-name <your-vnet> --subnet <your-subnet> \
  --public-ip-sku Standard

Step 3 - Connect to your VM

ssh azureuser@<vm-public-ip>

Step 4 - Confirm Grype is installed

grype version

It reports Version: 0.116.0 along with the build date and platform.

Step 5 - Confirm the vulnerability database is pre-cached

The database is downloaded at build time into a shared cache, so your first scan is instant and works offline:

grype db status

It prints the DB path under /var/lib/grype/db, the schema version, the build date and Status: valid. GRYPE_DB_CACHE_DIR=/var/lib/grype/db is exported for every shell (login shells via /etc/profile.d/grype.sh, and all sessions via /etc/environment), so grype uses this shared cache automatically.

Step 6 - Scan a container image (no Docker needed)

Grype pulls and scans an image directly from any registry - no Docker daemon required. It prints a table of packages, the CVE, its severity, an EPSS exploit-probability score and the version that fixes it:

grype alpine:3.10

Step 7 - Scan a directory or filesystem

Point Grype at a directory to catalogue the OS packages, language dependencies and binaries it contains and report their known vulnerabilities:

grype dir:/usr/bin

Grype prints a table of any vulnerable components it finds, with the fixed-in version so you know what to upgrade to.

Step 8 - Scan an SBOM

If an earlier pipeline stage produced a software bill of materials, Grype scans it directly - no need to re-scan the artifact. This example writes a tiny CycloneDX SBOM containing a known-vulnerable Log4j and scans it:

cat > /tmp/demo-sbom.json <<'CDX'
{
  "bomFormat": "CycloneDX",
  "specVersion": "1.5",
  "version": 1,
  "components": [
    { "type": "library", "name": "log4j-core", "version": "2.14.1",
      "purl": "pkg:maven/org.apache.logging.log4j/log4j-core@2.14.1" }
  ]
}
CDX
grype sbom:/tmp/demo-sbom.json

Grype reports the Log4Shell family of vulnerabilities (GHSA-jfh8-c2jp-5v3q and related), each marked Critical and, where applicable, flagged (kev) for a Known Exploited Vulnerability.

Step 9 - Gate a CI pipeline on severity

Grype returns a non-zero exit code when it finds a vulnerability at or above the severity you specify, so a build fails automatically when something serious appears:

# Fail the build if any Critical vulnerability is found
grype alpine:3.10 --fail-on critical

# Only show High and Critical findings
grype alpine:3.10 --only-fixed --output table | grep -E 'High|Critical'

# Emit JSON for a dashboard or policy engine
grype alpine:3.10 -o json > results.json

Updating the database

Grype refreshes the vulnerability database automatically when it ages out (it is fetched from the Anchore listing service). To update it on demand:

grype db update

The shared cache at /var/lib/grype/db is world-readable with the sticky bit set, so any user can read it and refresh it.

Maintenance

• Database: kept current automatically; force a refresh with grype db update and check it with grype db status.
• Upgrades: download a newer Grype .deb from the Anchore releases and sudo apt-get install ./grype_<version>_linux_amd64.deb.
• Security patches: unattended-upgrades remains enabled so the OS continues to receive security updates automatically.
• CI/CD: install Grype into your pipeline images or run scans on this VM as a remote scanning host; the --fail-on flag and JSON output make it easy to gate builds and feed dashboards.

Support

cloudimg provides 24/7 expert support for this image. Contact support@cloudimg.co.uk.