OCI CVE Checker
This skill compares CVE vulnerabilities between two OCI container images and generates detailed reports showing which CVEs were fixed and which new CVEs were introduced.
Instructions
When a user asks to compare CVEs between container images or analyze security differences:
-
Check and install required dependencies:
./scripts/manage_deps.shThis script checks for trivy, jq, and skopeo, and automatically installs any missing tools to a temporary directory if needed.
-
Run the CVE comparison script with two container image references:
./scripts/check_cves.sh <base_image> <target_image> [output_directory] -
Analyze the generated output files:
Output Files
The script generates the following files in the output directory (default:
./cve-reports/):fixed_cves.txt: CVEs that existed in the base image but are fixed in the target imagenew_cves.txt: New CVEs that appear in the target image but weren't in the base imagecommon_cves.txt: CVEs that exist in both imagessummary.txt: High-level summary with counts and statistics<image_name>_<digest>.json: Complete vulnerability scans for each image (filenames include image name and first 12 characters of digest, e.g.,python-3.11_a1b2c3d4e5f6.json)
-
Interpret the results for the user:
Fixed CVEs Analysis
- Count of CVEs resolved between versions
- Severity breakdown of fixed vulnerabilities
- Notable security improvements
- Packages that were updated to fix vulnerabilities
New CVEs Analysis
- Count of newly introduced CVEs
- Severity assessment of new vulnerabilities
- Risk evaluation for production deployment
- Packages introducing new vulnerabilities
- Recommendations for mitigation
Overall Security Posture
- Net change in vulnerability count
- Severity trends (more/fewer critical CVEs)
- Recommendation on whether to upgrade
- Additional security considerations
Usage Examples
Compare Two Container Images
./scripts/check_cves.sh registry.io/app:v1.0 registry.io/app:v1.1
Interpretation: Compare CVEs between version 1.0 and 1.1, identifying security improvements and any regressions.
Compare with Custom Output Directory
./scripts/check_cves.sh quay.io/myapp:latest quay.io/myapp:dev ./security-audit
Interpretation: Generate comparison reports in a custom directory for documentation or CI/CD integration.
Compare Different Registries
./scripts/check_cves.sh docker.io/library/python:3.11 docker.io/library/python:3.12
Interpretation: Analyze security differences between Python base image versions.
Private Registry Authentication
# Method 1: Using auth.json file (Recommended)
REGISTRY_AUTH_FILE=/home/default/containers/auth.json \
./scripts/check_cves.sh private-registry.io/app:v1 private-registry.io/app:v2
# Method 2: Using environment variables
TRIVY_USERNAME=myuser TRIVY_PASSWORD=mypass \
./scripts/check_cves.sh private-registry.io/app:v1 private-registry.io/app:v2
# Method 3: Trivy automatically uses podman credentials from ${XDG_RUNTIME_DIR}/containers/auth.json
podman login private-registry.io
./scripts/check_cves.sh private-registry.io/app:v1 private-registry.io/app:v2
# Method 4: For non-SSL registries
TRIVY_NON_SSL=true REGISTRY_AUTH_FILE=/home/default/containers/auth.json \
./scripts/check_cves.sh insecure-registry.io/app:v1 insecure-registry.io/app:v2
Interpretation: Trivy can authenticate to private registries using the REGISTRY_AUTH_FILE environment variable pointing to your auth.json, or using TRIVY_USERNAME/TRIVY_PASSWORD environment variables, or existing podman credentials.
Key Analysis Points
When Reviewing Fixed CVEs
- Critical/High Severity Fixes: Highlight major security improvements
- Long-standing Vulnerabilities: Note fixes for older, known issues
- Completeness: Check if all expected CVEs were addressed
- Verification: Confirm fixes align with release notes
When Reviewing New CVEs
- Severity Assessment: Prioritize by CVSS score and exploitability
- Exposure Analysis: Determine if vulnerable code paths are reachable
- Mitigation Options: Suggest workarounds if immediate fix isn't available
- Timeline: Check if patches are available or planned
Security Recommendations
Based on the comparison, provide guidance:
For Improved Security (More Fixed than New)
- "Upgrading is recommended - net reduction of X vulnerabilities"
- "Y critical CVEs fixed with only Z new low-severity issues"
- "Security posture improved, safe to deploy after testing"
For Degraded Security (More New than Fixed)
- "Caution: X new vulnerabilities introduced"
- "Review new CVEs before deploying to production"
- "Consider waiting for next release or apply mitigations"
For Mixed Results
- "Security trade-offs detected"
- "Fixed: [critical issues], but introduced: [new concerns]"
- "Recommend risk assessment based on your threat model"
Tool Requirements
This skill requires the following tools to be installed:
- trivy: Container vulnerability scanner
- jq: JSON processor for parsing scan results
- skopeo: For image inspection and pre-validation (validates image tags exist before analysis)
Error Handling
If the dependency check fails:
- Missing tools: Run
./scripts/manage_deps.shfirst to check and install trivy, jq, and skopeo - Auto-install failure: Install tools manually as instructed by the manage_deps script
If the comparison script fails:
- Image not found: Verify image names and registry accessibility
- Authentication required: Set
TRIVY_USERNAME/TRIVY_PASSWORDenvironment variables, or login withpodman login <registry> - Network issues: Check connectivity to container registries
- Insufficient permissions: Verify file write permissions for output directory
- Non-SSL registry: Set
TRIVY_NON_SSL=truefor insecure registries
Integration Notes
This skill works well with:
- CI/CD pipelines: Automated security checks before deployment
- Security audits: Regular vulnerability assessments
- Release validation: Verify security improvements in new releases
- Container image promotion: Gate promotions based on CVE thresholds
- K8s/OpenShift deployments: Pre-deployment security validation
Example Workflow
- Developer builds new container image
- Run CVE checker comparing old vs new image
- Review fixed and new CVEs
- Make deployment decision based on security posture
- Document findings in security reports
- Update deployment runbooks with any new mitigations