Five months ago, we launched Safeguard with SBOM lifecycle management, vulnerability scanning, and policy enforcement. Today we are releasing Safeguard v2, and the theme is enterprise readiness.
v2 is not a rewrite. It is the result of deploying the platform with dozens of enterprise customers and systematically addressing every gap they identified. The core architecture is the same. The capabilities are significantly broader.
Here is what is new.
Container Image Scanning
This was the most requested feature since launch. Enterprise customers do not just ship source code -- they ship container images. And container images carry their own supply chain: base images, system packages, application dependencies, and configuration files.
Safeguard v2 can analyze container images directly. Point it at an image in a registry or a local tarball, and it produces a comprehensive SBOM covering:
- OS packages -- Packages installed through apt, yum, apk, or other system package managers
- Application dependencies -- Language-specific packages detected from manifest files and lockfiles within the image layers
- Base image identification -- The base image and its version, so you can track upstream changes
The SBOM is then processed through the same vulnerability correlation and policy engine as source-level SBOMs. You get a unified view of your supply chain risk across both source code and container images.
# Scan a container image
safeguard scan --image myapp:v2.1.0
# Generate SBOM from a container image
safeguard sbom generate --image myapp:v2.1.0 --format cyclonedx
For CI/CD integration, container scanning fits naturally into the build pipeline after the image is built but before it is pushed to the registry. This gives you a quality gate for container images that matches the quality gate you already have for source code.
Enhanced Policy Engine
The v1 policy engine supported basic rules: vulnerability thresholds, license restrictions, and component deny lists. v2 extends this significantly.
Conditional policies let you define rules that apply only when certain conditions are met. For example, you might allow medium-severity vulnerabilities in development builds but block them in production releases. Or you might enforce stricter license policies for commercial products than for internal tools.
Policy templates provide pre-built configurations for common compliance frameworks. Instead of building policies from scratch, you can start with a template for NIST SSDF, FDA cybersecurity guidance, or PCI-DSS and customize from there.
Policy versioning and audit trail tracks every change to your policies, who made them, and when. During compliance audits, you can demonstrate exactly which policies were in effect for any historical release.
Grace periods allow you to acknowledge a vulnerability without immediately blocking releases. If a fix is not yet available, you can grant a time-limited exception that automatically expires. This prevents the common anti-pattern of permanently suppressing findings because the initial suppression never gets reviewed.
Team Workspaces
Large organizations have multiple teams, each responsible for different products. v2 introduces workspaces that provide logical isolation between teams while still allowing cross-team visibility for security and compliance functions.
Each workspace has its own:
- Projects and SBOMs
- Policies (which can inherit from organization-level defaults)
- Members and roles
- Dashboard and reporting
Organization-level administrators can see across all workspaces for portfolio-wide queries and reporting. Team members see only their workspace. This mirrors the organizational structure of most enterprises and eliminates the need for a single global view that shows everything to everyone.
API v1.1 and Webhooks
The API receives several enhancements in v2.
Pagination is now consistent across all list endpoints, using cursor-based pagination instead of offset-based. This is more performant for large result sets and eliminates the inconsistencies that some API consumers reported with v1.
Bulk operations allow creating, updating, or deleting multiple resources in a single API call. For customers that manage hundreds of projects, bulk operations reduce the number of API calls from hundreds to one.
Webhooks are the most significant addition. You can configure Safeguard to send HTTP callbacks when specific events occur:
- New vulnerability found in a monitored component
- Policy check passed or failed
- SBOM uploaded or updated
- Health score changed above a threshold
Webhooks enable event-driven integration with any system that can receive HTTP requests: Slack, PagerDuty, Jira, ServiceNow, custom automation. Instead of polling the API for changes, your systems are notified immediately.
{
"event": "vulnerability.new",
"timestamp": "2024-08-01T14:32:00Z",
"data": {
"cve": "CVE-2024-38816",
"severity": "critical",
"affected_products": ["product-a", "product-b"],
"affected_component": "spring-webmvc@6.1.10"
}
}
Performance Improvements
v2 includes significant performance work based on production workload analysis.
SBOM ingestion is 3x faster for large SBOMs (10,000+ components). The normalization pipeline was rewritten to use parallel processing for component deduplication and purl resolution.
Vulnerability correlation scales linearly with the number of components in your inventory. Customers with 100,000+ components across their portfolio see sub-second correlation for new advisories.
Dashboard queries that previously took 5-10 seconds for large portfolios now complete in under 2 seconds. We added materialized views for the most common query patterns and optimized the database indexes.
Migration From v1
v2 is backward compatible with v1 at the data level. Your existing SBOMs, projects, policies, and configurations carry forward without modification. The API v1 endpoints continue to work alongside v1.1, so existing integrations do not break.
The CLI auto-updates by default, so running safeguard update pulls the latest version. CI/CD integrations that pin to a specific CLI version should update to the v2 CLI for access to new features but will continue to work with the v1 CLI for existing functionality.
What We Learned From v1
Building v2 was driven by specific lessons from v1 deployments.
Container scanning was not optional. More than 80% of our customers deploy via containers. Ignoring container-layer dependencies meant significant blind spots in their supply chain visibility.
Policy enforcement needed flexibility. The v1 binary pass/fail was too rigid. Real-world policies have exceptions, grace periods, and environment-specific rules. v2's conditional policies and grace periods reflect this reality.
Multi-team organizations need isolation. A single flat namespace for all projects and SBOMs does not work when you have 50 teams. Workspaces provide the boundaries that enterprise organizations need without creating completely separate installations.
Webhooks were table stakes. Every enterprise customer had the same request: "tell us when something changes instead of making us check." Webhooks are infrastructure-level plumbing that should have been in v1.
What Comes Next
v2 lays the groundwork for several capabilities planned for the rest of 2024:
- Reachability analysis -- Determining whether vulnerable code paths are actually invoked in your application
- CycloneDX VEX support -- Generating and consuming Vulnerability Exploitability eXchange documents
- Enhanced AI capabilities -- Expanding Griffin's ability to provide proactive insights, not just reactive queries
Safeguard v2 is available now. Existing customers on any plan get the update automatically. New customers can start with the free tier, which includes all v2 features for up to 10 projects.