Deployment guide

Grype

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). It scans container images, directories, filesystems, archives and Git checkouts, and it can read a Syft, SPDX or CycloneDX SBOM that you produced earlier in your pipeline.

This SecureAnyCloud image installs Grype 0.116.0 as the /usr/bin/grype command. It pre-downloads the vulnerability database into a shared system cache so your first scan is fast, and it exports the cache for every shell. The image is backed by 24/7 SecureAnyCloud support.

What you get:

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 (through /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 SecureAnyCloud support

Grype is a command-line product. It has no web UI, no listening service and no open ports beyond SSH.

Prerequisites

You need an active Azure subscription, an SSH key pair, and a VNet and subnet in the target region.

Standard_B2s (2 vCPU / 4 GiB RAM) is a good starting point. For the NSG, allow inbound 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 SecureAnyCloud, and select Create.

On the Basics tab, 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 select Review + create and Create.

Step 2 - Deploy from the Azure CLI

Accept the Marketplace terms once per subscription, then create the VM:

# Accept the Marketplace terms once per subscription (required before the first CLI deploy)
az vm image terms accept --urn sac1647283583153:grype-ubuntu-24-04:default:latest
az vm create \
  --resource-group <your-rg> \
  --name grype \
  --image sac1647283583153:grype-ubuntu-24-04:default:latest \
  --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

Connect over SSH as azureuser:

ssh azureuser@<vm-public-ip>

Step 4 - Confirm Grype is installed

Print the version:

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. Check its status:

grype db status

The output shows 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 through /etc/profile.d/grype.sh, and all sessions through /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, with 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. You do not need to re-scan the original target. This example writes a tiny CycloneDX SBOM that contains a known-vulnerable Log4j, and then 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 is 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. A build then 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 fetches the database from the Anchore listing service. To update it on demand, run:

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 run 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

SecureAnyCloud provides 24/7 expert support for this image. Contact sales@secureanycloud.com.

Deploy on Azure

Launch Grype on Ubuntu 24.04 LTS on Azure with 24/7 support from SecureAnyCloud.

View this image

Need Help?

Our support team is available 24/7.

sales@secureanycloud.com

Deploy on Azure

Overview

Grype is a fast, open-source vulnerability scanner from Anchore. From a single command line, it finds known CVEs in operating system packages and in language dependencies (Java, Python, JavaScript, Ruby, Go, .NET, Rust, PHP and others). It scans container images, directories, filesystems, archives and Git checkouts, and it can read a Syft, SPDX or CycloneDX SBOM that you produced earlier in your pipeline.

This SecureAnyCloud image installs Grype 0.116.0 as the /usr/bin/grype command. It pre-downloads the vulnerability database into a shared system cache so your first scan is fast and works offline, and it exports the cache for every shell. The image is backed by 24/7 SecureAnyCloud support.

What you get:

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 (through /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 SecureAnyCloud support

Grype is a headless command-line product. It has no web UI, no service to log into and no listening ports beyond SSH. You run the grype command against your own targets.

Prerequisites

Before you deploy this image, you need:

An Amazon Web Services account where you can launch EC2 instances
IAM permissions to launch instances, create security groups, and subscribe to AWS Marketplace products
An EC2 key pair in the target Region for SSH access
A VPC and subnet in the target Region, with a security group that allows inbound port 22 from your management network
The AWS CLI (version 2) installed locally, if you plan to deploy from the command line

The recommended instance type is m5.large (2 vCPU / 8 GiB RAM). Grype is a single binary plus its vulnerability database, so no application ports are needed.

Launch the instance from the AWS Marketplace

Sign in to the AWS Management Console, open the EC2 service, and select Launch instance. Under Application and OS Images, choose AWS Marketplace AMIs and search for Grype. Select the SecureAnyCloud listing and choose Select, then Continue on the subscription summary.

Pick an instance type of m5.large or larger. Choose your EC2 key pair under Key pair (login). Under Network settings, select your VPC and subnet, and either create or select a security group that opens port 22 from your management network. Leave the root volume at the default size or larger.

Select Launch instance. The instance is ready to use as soon as its state becomes Running and the status checks pass.

Launch the instance from the AWS CLI

This command launches an instance from the SecureAnyCloud Grype Marketplace AMI into an existing subnet and security group.

Replace <ami-id> with the AMI ID shown on the Marketplace listing. Replace <key-name> with your EC2 key pair name and <subnet-id> with your subnet ID. Replace <security-group-id> with a security group that opens port 22 from your management network.

aws ec2 run-instances \
  --image-id <ami-id> \
  --instance-type m5.large \
  --key-name <key-name> \
  --subnet-id <subnet-id> \
  --security-group-ids <security-group-id> \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=grype}]'

When the instance reaches the Running state and its status checks pass, note its public IP address or DNS name from the EC2 console or with aws ec2 describe-instances.

Connect to your instance

Connect over SSH using your key pair and the login user for your operating system variant. For Ubuntu 24.04, the SSH login user is ubuntu:

ssh -i <key-name>.pem ubuntu@<public-ip>

A welcome banner prints the most useful commands. The login shell exports GRYPE_DB_CACHE_DIR=/var/lib/grype/db automatically, so Grype reads the pre-loaded database from the shared cache without any further configuration.

Confirm Grype is installed

Confirm that the toolchain is installed and on the system path by printing the version:

grype version

The output reports Version: 0.116.0 along with the build date, platform and the bundled Syft version.

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. Check its status:

export GRYPE_DB_CACHE_DIR=/var/lib/grype/db grype db status

The output shows the DB path under /var/lib/grype/db, the schema version, the build date and Status: valid.

GRYPE_DB_CACHE_DIR is exported for every shell (login shells through /etc/profile.d/grype.sh, and all sessions through /etc/environment), so grype uses this shared cache automatically. The cache is world-readable with the sticky bit set, so any user can read it and refresh it.

Scan a directory or project

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

This example writes a small Python project with deliberately out-of-date dependencies and scans it offline against the pre-loaded database, so the report shows real CVEs:

export GRYPE_DB_CACHE_DIR=/var/lib/grype/db
export GRYPE_DB_AUTO_UPDATE=false mkdir -p /tmp/demo-project cat > /tmp/demo-project/requirements.txt <<'REQ' Flask==0.12.2 Jinja2==2.7.2 Werkzeug==0.11.1 PyYAML==3.11 requests==2.6.0 REQ grype dir:/tmp/demo-project

Grype prints a table of each vulnerable component with its installed version, the version that fixes it, the vulnerability identifier, the severity, an EPSS exploit-probability score and a computed risk score. The table shows exactly what to upgrade and what to prioritise.

Scan a container image (no Docker needed)

Grype pulls and scans an image directly from any registry, with no Docker daemon required. Replace <name:tag> with the image you want to scan:

grype <name:tag>

To scan an image that you already exported to a tar archive, point Grype at the file instead. This needs no registry access:

grype oci-archive:./myimage.tar

Scan an SBOM

export GRYPE_DB_CACHE_DIR=/var/lib/grype/db
export GRYPE_DB_AUTO_UPDATE=false 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 is marked Critical and flagged (kev) for a Known Exploited Vulnerability. This confirms that the vulnerability matcher and the offline database work end to end.

Gate a CI pipeline on severity