From threatmodel-skills
Scans container images, filesystems, and SBOMs for vulnerabilities using Grype with CVSS, EPSS, and CISA KEV metrics. Integrates into CI/CD pipelines with severity thresholds and generates JSON/SARIF/CycloneDX reports.
npx claudepluginhub agentsecops/secopsagentkit --plugin offsec-skillsThis skill uses the workspace's default tool permissions.
Grype is an open-source vulnerability scanner that identifies known security flaws in container images,
Designs and optimizes AI agent action spaces, tool definitions, observation formats, error recovery, and context for higher task completion rates.
Compares coding agents like Claude Code and Aider on custom YAML-defined codebase tasks using git worktrees, measuring pass rate, cost, time, and consistency.
Designs, implements, and audits WCAG 2.2 AA accessible UIs for Web (ARIA/HTML5), iOS (SwiftUI traits), and Android (Compose semantics). Audits code for compliance gaps.
Grype is an open-source vulnerability scanner that identifies known security flaws in container images, filesystems, and Software Bill of Materials (SBOM) documents. It analyzes operating system packages (Alpine, Ubuntu, Red Hat, Debian) and language-specific dependencies (Java, Python, JavaScript, Ruby, Go, PHP, Rust) against vulnerability databases to detect CVEs.
Grype emphasizes actionable security insights through:
Scan a container image:
grype <image-name>
Examples:
# Scan official Docker image
grype alpine:latest
# Scan local Docker image
grype myapp:v1.2.3
# Scan filesystem directory
grype dir:/path/to/project
# Scan SBOM file
grype sbom:/path/to/sbom.json
grype <target> to analyze for vulnerabilitiesFor automated pipeline security gates:
# Fail build if any critical vulnerabilities found
grype <image> --fail-on critical
# Fail on high or critical severities
grype <image> --fail-on high
# Output JSON for further processing
grype <image> -o json > results.json
Pipeline integration pattern:
--fail-on thresholdUse Grype with Syft-generated SBOMs for faster re-scanning:
# Generate SBOM with Syft (separate skill: sbom-syft)
syft <image> -o json > sbom.json
# Scan SBOM with Grype (faster than re-analyzing image)
grype sbom:sbom.json
# Pipe Syft output directly to Grype
syft <image> -o json | grype
Benefits of SBOM workflow:
Progress:
[ ] 1. Run full Grype scan with JSON output: grype <target> -o json > results.json
[ ] 2. Use helper script to extract high-risk CVEs: ./scripts/prioritize_cves.py results.json
[ ] 3. Review CISA KEV matches (actively exploited vulnerabilities)
[ ] 4. Check EPSS scores (exploit probability) for non-KEV findings
[ ] 5. Prioritize remediation: KEV > High EPSS > CVSS Critical > CVSS High
[ ] 6. Document remediation plan with CVE IDs and affected packages
[ ] 7. Apply fixes and re-scan to verify
Work through each step systematically. Check off completed items.
Grype supports multiple output formats for different use cases:
Table (default): Human-readable console output
grype <image>
JSON: Machine-parseable for automation
grype <image> -o json
SARIF: Static Analysis Results Interchange Format for IDE integration
grype <image> -o sarif
CycloneDX: SBOM format with vulnerability data
grype <image> -o cyclonedx-json
Template: Custom output using Go templates
grype <image> -o template -t custom-template.tmpl
Exclude specific file paths:
grype <image> --exclude '/usr/share/doc/**'
Filter by severity:
grype <image> --only-fixed # Only show vulnerabilities with available fixes
Create .grype.yaml to suppress false positives:
ignore:
# Ignore specific CVE
- vulnerability: CVE-YYYY-XXXXX
reason: "False positive - component not used"
# Ignore CVE for specific package
- vulnerability: CVE-YYYY-ZZZZZ
package:
name: example-lib
version: 1.2.3
reason: "Risk accepted - mitigation controls in place"
Update vulnerability database:
grype db update
Check database status:
grype db status
Use specific database location:
grype <image> --db /path/to/database
Sensitive Data Handling: Scan results may contain package names and versions that reveal application architecture. Store results securely and limit access to authorized security personnel.
Access Control: Grype requires Docker socket access when scanning container images. Restrict permissions to prevent unauthorized image access.
Audit Logging: Log all Grype scans with timestamps, target details, and operator identity for compliance and incident response. Archive scan results for historical vulnerability tracking.
Compliance: Regular vulnerability scanning supports SOC2, PCI-DSS, NIST 800-53, and ISO 27001 requirements. Document scan frequency and remediation SLAs.
Safe Defaults: Use --fail-on critical as minimum threshold for production deployments.
Configure automated scans in CI/CD to prevent vulnerable images from reaching production.
scripts/)references/)assets/)Scan before pushing images to registry:
# Build image
docker build -t myapp:latest .
# Scan locally before push
grype myapp:latest --fail-on critical
# If scan passes, push to registry
docker push myapp:latest
Re-scan existing images for newly disclosed vulnerabilities:
# Scan all production images daily
for image in $(docker images --format '{{.Repository}}:{{.Tag}}' | grep prod); do
grype $image -o json >> daily-scan-$(date +%Y%m%d).json
done
Compare base images to choose least vulnerable option:
# Compare Alpine versions
grype alpine:3.18
grype alpine:3.19
# Compare distros
grype ubuntu:22.04
grype debian:12-slim
grype alpine:3.19
--fail-on thresholdsSymptoms: grype db update fails with network errors
Solution:
grype db update --verbose for detailed error messagesgrype db import /path/to/database.tar.gzSymptoms: Grype reports vulnerabilities in unused code or misidentified packages
Solution:
.grype.yaml ignore file with specific CVE suppressions--only-fixed to focus on actionable findingsSymptoms: Grype scans take excessive time on large images
Solution:
--exclude '/usr/share/doc/**'grype db update before batch scans