Grype on AWS User Guide
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), 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 works offline, and exports the cache for every shell. Backed by 24/7 cloudimg support.
What is included:
- Grype 0.116.0 (the
/usr/bin/grypeCLI) from the official Anchore release, checksum-verified against the project's signedchecksums.txt - The vulnerability database pre-downloaded into a shared cache at
/var/lib/grype/db GRYPE_DB_CACHE_DIRexported for every shell (via/etc/profile.d/grype.shand/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 headless command-line product: there is 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 allowing 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.
Step 1: 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 cloudimg 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.
Step 2: Launch the Instance from the AWS CLI
The following block launches an instance from the cloudimg Grype Marketplace AMI into an existing subnet and security group. Replace <ami-id> with the AMI ID shown on the Marketplace listing, <key-name> with your EC2 key pair name, <subnet-id> with your subnet ID, and <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.
Step 3: Connect to Your Instance
Connect over SSH using your key pair and the login user for your operating system variant.
| OS variant | SSH login user |
|---|---|
| Ubuntu 24.04 | 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.
Step 4: Confirm Grype is Installed
Confirm the toolchain is installed and on the system path by printing the version:
grype version
It reports Version: 0.116.0 along with the build date, platform and the bundled Syft version.

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:
export GRYPE_DB_CACHE_DIR=/var/lib/grype/db
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 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. The cache is world-readable with the sticky bit set, so any user can read it and refresh it.
Step 6: 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. The example below 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, so you know exactly what to upgrade and what to prioritise.

Step 7: Scan a Container Image (no Docker needed)
Grype pulls and scans an image directly from any registry - no Docker daemon required. Replace <name:tag> with the image you want to scan:
grype <name:tag>
To scan an image you have already exported to a tar archive, point Grype at the file instead, which needs no registry access:
grype oci-archive:./myimage.tar
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:
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 marked Critical and flagged (kev) for a Known Exploited Vulnerability, confirming the vulnerability matcher and offline database work end to end.

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 dir:/path/to/project --fail-on critical
# Only show findings that have a fix available
grype dir:/path/to/project --only-fixed
# Emit JSON for a dashboard or policy engine
grype dir:/path/to/project -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 updateand check it withgrype db status. - Upgrades: download a newer Grype
.debfrom the Anchore releases andsudo 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: run scans on this instance as a remote scanning host; the
--fail-onflag 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.