Can I migrate gradually from Engine to Syft/Grype?

Yeah, and you should definitely do this unless you enjoy pain. Install Syft and Grype next to your existing Engine setup and start using them for new stuff while Engine limps along with your old integrations.The CLI tools don't have persistent state, so they won't corrupt each other like Engine's services did. Compare results side-by-side before you kill Engine completely.

Will I lose historical scan data during migration?

Engine's scan history is stuck in PostgreSQL hell, and there's no way to import it into the CLI tools (because they're not idiotic enough to need persistent state). You could export the data if you hate yourself, but parsing those normalized tables is like solving a Rubik's cube blindfolded.Most teams discover they never looked at that historical data anyway - it was just eating disk space. Once you have continuous scanning that doesn't randomly break, you won't miss that archive of ancient scan results.

What about my existing Engine policies?

You gotta translate Engine policies to Grype config files. Basic stuff (vuln thresholds, package exceptions) maps over easily. Complex policies need external scripts because Grype isn't trying to be everything to everyone.Export your Engine policies with `curl "http://your-engine-host:8228/v1/policies"` first to see what rules you actually have. Most orgs find out they can ditch 80% of their policy complexity and nobody notices.

How do I handle the lack of web UI?

Syft and Grype are CLI tools that don't try to be shitty web apps. Your options: - **Grafana dashboards** (most teams go this route) - **ELK stack** for searching results - **Custom web UI** if you enjoy building things - **CI/CD reporting** (GitLab, GitHub security tabs) Most teams prefer this over Engine's built-in UI that crashed half the time anyway. At least now it integrates with your existing monitoring instead of being another thing to babysit.

What's the performance difference in practice?

Night and day difference. Engine took 5-15 minutes on good days, sometimes hours when PostgreSQL decided to shit itself. Syft generates an SBOM in under a minute, Grype scans it in another minute or two. For a typical Node.js image: - **Engine**: 15+ minutes when it worked, infinite time when it hung (which was often) - **Syft + Grype**: 2-3 minutes total Now you can scan every build instead of just production releases because it doesn't take forever.

Do I need to change my CI/CD pipelines significantly?

Not really. CLI tools actually fit in CI/CD pipelines instead of fighting them. Replace API calls with CLI commands and you're basically done. Biggest change is scans are fast enough to run inline instead of the async polling bullshit Engine forced on you.

What about vulnerability database management?

Grype just handles it. Checks for updates before each scan, downloads new data automatically. No manual database management, no PostgreSQL maintenance windows, no feed sync failures at 2am. Vulnerability DB is cached locally and updated incrementally. Subsequent scans work offline unless there are new updates to grab.

Can I still scan running containers and registries?

Yeah, they support everything Engine did plus more: - **Docker daemon**: `grype myapp:latest` - **Container registry**: `grype registry:myregistry.com/myapp:tag` - **Local archives**: `grype docker-archive:image.tar` - **Running containers**: `grype docker:container-name` - **Filesystems**: `grype dir:/path/to/files` Registry monitoring needs external orchestration (cron, scheduled CI/CD), but at least it's predictable unlike Engine's registry polling that worked when it felt like it.

How do I handle air-gapped environments?

Both work offline, way simpler than Engine's feed management nightmare: 1. Download vuln database: `grype db update` (takes forever on slow connections, sorry) 2. Copy `~/.cache/grype/db/` to your air-gapped environment 3. Set `GRYPE_DB_AUTO_UPDATE=false` or Grype hangs trying to phone home 4. Scan normally: `grype myimage:tag` If the DB cache gets fucked, just delete `~/.cache/grype` and start over. Way simpler than Engine's feed sync that broke if you looked at it wrong.

What if I need the policy engine features?

Grype's policy system is way simpler but handles most real use cases through config files and ignore rules. Complex policies need wrapper scripts, but honestly most of Engine's policy complexity was overkill. Most orgs discover they prefer Grype's straightforward approach over Engine's policy engine that required a PhD to understand.

Will Anchore continue supporting the CLI tools?

Yeah, Syft and Grype are what Anchore actually cares about now. They're the foundation of Anchore Enterprise, so they're not going anywhere. Engine is dead and buried - no more security updates, bug fixes, nothing. The CLI tools are the official replacement that actually evolved instead of just accumulating technical debt.

What about integration with Anchore Enterprise?

If you're eyeing Anchore Enterprise, the CLI tools are literally what it's built on. Migrating to Syft/Grype now means less pain later if you need Enterprise features. Enterprise adds centralized policy management, web UI that doesn't suck, compliance reporting, and multi-tenancy on top of the same scanning engines.

How do I migrate 50+ pipelines efficiently?

Template approach works best: 1. Create standard Grype configs for your org 2. Build wrapper scripts that match your Engine API calls 3. Update pipelines in batches, compare results against Engine first 4. Use feature flags to toggle between old and new scanning CLI tools are consistent unlike Engine's API that had different quirks depending on which service was handling your request. Solve it once, apply everywhere. Need more help? The links below have official docs, community guides, and stories from teams who've already escaped Engine hell.

Currently viewing the AI version

Switch to human version

Anchore Engine to Syft & Grype Migration Guide

Executive Summary

Critical Migration Intelligence: Anchore Engine deprecated January 2023. Security scans from Engine are unreliable. Migration to Syft (SBOM generation) + Grype (vulnerability scanning) provides 10x performance improvement with 95% resource reduction.

Deprecation Context

Why Engine Failed

Architecture: Monolithic system requiring PostgreSQL, multiple containers, 4GB+ RAM minimum
Reliability Issues: Database corruption, OOM errors, service failures at 3am
Performance: 15-20 minute scans when functional, often hung indefinitely
Complexity: 5+ interconnected services requiring coordination for updates
CI/CD Problems: Random API timeouts, long startup times breaking pipelines

Replacement Architecture

Syft: Standalone SBOM generation tool (25+ package ecosystems)
Grype: Vulnerability scanner consuming SBOMs or scanning directly
Resource Requirements: ~100MB RAM per scan vs 4GB+ for Engine
Performance: 30 seconds - 2 minutes total vs 5-15+ minutes for Engine

Migration Impact Analysis

What You Lose

Feature	Engine Capability	Migration Impact
Web UI	Built-in dashboard	Build Grafana/custom dashboards
Centralized Policy	Complex JSON policies	Use config files + external orchestration
User Management	Built-in RBAC	Integrate with existing auth systems
Scan History	PostgreSQL storage	Implement external storage if needed
Registry Monitoring	Built-in polling	Use cron jobs or CI/CD scheduling

What You Gain

Improvement	Engine Baseline	Syft/Grype Outcome
Scan Performance	15-20 minutes	2-3 minutes total
Resource Usage	4GB+ RAM	~100MB RAM
Reliability	Frequent failures	Stateless, fail-fast
Maintenance	Weekly PostgreSQL maintenance	Zero maintenance
Integration	Complex API polling	Simple CLI exit codes

Technical Implementation

Installation

# Install both tools
curl -sSfL https://get.anchore.io/syft | sudo sh -s -- -b /usr/local/bin
curl -sSfL https://get.anchore.io/grype | sudo sh -s -- -b /usr/local/bin

# Basic usage
syft your-image:tag -o cyclonedx-json > sbom.json
grype your-image:tag --fail-on medium

CI/CD Migration

Before (Engine API):

# Complex polling workflow
curl -X POST "http://${ENGINE_HOST}/v1/images" -d '{"tag":"myapp:latest"}'
# Wait for analysis completion with polling loop
while [ "$(curl -s http://${ENGINE_HOST}/v1/images/myapp:latest | jq -r '.analysis_status')" != "analyzed" ]; do
  sleep 30
done

After (CLI):

# Direct scan with immediate results
grype myapp:latest --fail-on medium --output json > vulnerability-report.json

Policy Migration

Engine policies translate to Grype configuration:

# ~/.grype.yaml
ignore:
  - package:
      name: libssl1.1
      version: 1.1.1k-r0
    vulnerability: CVE-2021-3711
fail-on-severity: "high"

Critical Migration Warnings

Expected Breaking Changes

Vulnerability Count Differences: Grype finds vulnerabilities Engine missed
- Impact: Security teams panic about "new" vulnerabilities
- Mitigation: Warn stakeholders this indicates improved detection
Package Detection Changes: Syft finds packages in locations Engine ignored
- Impact: "Clean" images suddenly show 70+ vulnerabilities
- Timeline: Reality check, not regression
False Positive Patterns: Different ignore rule requirements
- Estimated Effort: 3-4 weeks to tune ignore rules properly
- Documentation Claims: "Few hours" (inaccurate)

High-Risk Migration Mistakes

Gradual Migration Approach: Running both systems simultaneously
- Failure Mode: Increased complexity, conflicting results
- Recommendation: Complete cutover after parallel testing
Recreating Engine Architecture: Building databases and web UIs
- Failure Mode: More complex than original Engine
- Success Pattern: Use CLI tools as building blocks only

Resource Requirements

Development Time Investment

Basic Migration: 1-2 weeks for simple CI/CD pipeline updates
Policy Tuning: 3-4 weeks for enterprise environments
Advanced Integration: 2-3 months for complex orchestration replacement

Infrastructure Changes

Elimination: PostgreSQL database, service mesh, persistent storage
Addition: External storage for scan history (optional), dashboard tools
Net Result: 95% infrastructure reduction

Air-Gapped Environment Support

# Offline preparation
grype db update
cp ~/.cache/grype/db/latest.tar.gz /path/to/offline/environment/

# Air-gapped usage
export GRYPE_DB_AUTO_UPDATE=false
export GRYPE_DB_CACHE_DIR=/opt/grype-db
grype myimage:tag --db-cache-dir $GRYPE_DB_CACHE_DIR

Enterprise Integration Patterns

High-Volume Scanning

# Parallel processing (impossible with Engine)
echo "image1:tag image2:tag image3:tag" | \
xargs -n 1 -P 10 -I {} sh -c 'grype {} --output json > results/{}.json'

Centralized Reporting

# Push to security API
grype myapp:latest --output json | \
  curl -X POST "https://security-api.company.com/vulnerability-scans" \
  -H "Authorization: Bearer $API_TOKEN" \
  -H "Content-Type: application/json" -d @-

Success Metrics

Performance Benchmarks

Scan Time: 10x+ improvement (15+ minutes → 2-3 minutes)
Resource Usage: 95%+ reduction (4GB+ RAM → 100MB)
Reliability: Near-zero maintenance vs weekly PostgreSQL issues

Operational Improvements

No Database Management: Eliminates corruption, backup, maintenance
Simplified Deployment: Two binaries vs multi-service architecture
Faster Development: Package manager additions don't require service coordination

Migration Decision Framework

When to Migrate Immediately

Engine experiencing frequent failures
CI/CD pipelines breaking due to Engine timeouts
PostgreSQL maintenance consuming significant resources
Need for faster security feedback loops

When to Plan Extended Migration

Complex policy requirements needing external orchestration
Large number of integration points (50+ pipelines)
Air-gapped environments requiring offline database management
Enterprise compliance requiring centralized audit trails

Support and Maintenance

Community Resources

Active GitHub repositories with responsive maintainers
Anchore Discourse community for troubleshooting
Regular updates without breaking changes

Enterprise Options

Anchore Enterprise built on same CLI tools
Professional services for complex migrations
Commercial support for large-scale deployments

Migration Validation

Testing Approach

Install CLI tools alongside existing Engine
Compare scan results on identical images
Measure performance differences
Validate policy rule coverage
Test CI/CD integration with non-critical pipelines

Success Criteria

Scan completion time under 5 minutes
Zero database maintenance requirements
Consistent vulnerability detection
Simplified operational procedures

Useful Links for Further Investigation

Essential Migration Resources

Link	Description
Anchore Engine GitHub (Deprecated)	The original repo where Engine died its official death. Read the README for migration guidance and to see what you're escaping from.
Syft GitHub Repository	Actually maintained and doesn't suck. Complete docs, installation guides that work, and SBOM examples that don't require a PhD.
Grype GitHub Repository	Activeły maintained vulnerability scanner that doesn't randomly break. Config examples and integration guides that actually help.
Syft Installation Guide	Installation methods that work the first time. Curl script, Homebrew, containers - pick your poison.
Grype Installation Guide	Step-by-step installation that doesn't involve debugging Docker Compose hell. Includes verification and troubleshooting.
Anchore Open Source Tools Overview	Official comparison showing why these tools replaced Engine. Use cases and integration patterns that make sense.
Grype Configuration Reference	Config documentation that's actually readable. Ignore rules, output formats, policy settings explained like a human wrote them.
Syft Output Formats	Detailed explanation of SPDX, CycloneDX, and Syft JSON formats with conversion examples.
Grype VEX Support	Vulnerability Exploitability Exchange integration for filtering false positives and augmenting scan results.
GitHub Actions Integration	Official GitHub Action for Anchore container scanning with example workflows and security reporting.
GitLab CI/CD Integration	GitLab's container scanning documentation using Grype with template examples and security dashboards.
Kubernetes Integration Examples	Test examples showing Kubernetes deployment patterns, admission controllers, and policy enforcement.
Chainguard Migration Experience	Real migration story with actual performance numbers. These people survived the transition and lived to tell about it.
SBOM Generation Tutorial	Step-by-step SBOM workflow guide that doesn't assume you're a security expert. Practical Syft and Grype usage.
Container Scanning Tools Comparison	Independent comparison showing where Grype fits against Trivy, Snyk, and others. Actual feature matrices, not marketing bullshit.
Open Source Security Tools Guide	Comprehensive guide to building security workflows with open source tools including migration strategies.
Anchore Enterprise Demo	For organizations needing centralized policy management, web UI, and enterprise support on top of Syft/Grype.
Anchore Community Discourse	Community forum where people actually help each other. Migration questions, troubleshooting, and war stories from the trenches.
Professional Services	Paid help if your migration is too complex or you don't want to figure out the hard parts yourself. They know where the bodies are buried.