Anchore Enterprise 5.22 introduces three capabilities designed to make vulnerability management clearer, cleaner, and more trustworthy:
- VEX annotations with OpenVEX export
- PURLs by default, and
- RHEL Extended Update Support (EUS) indicators.
Each of these features adds context and precision to vulnerability data—helping teams reduce noise, speed triage, and strengthen communication across the supply chain.
Security teams are flooded with vulnerability alerts that lack actionable context. A single CVE may appear in thousands of scans—even if it’s already fixed, mitigated, or irrelevant to the deployed package. The emerging VEX (Vulnerability Exploitability eXchange) standards aim to fix that by allowing publishers to communicate the status of vulnerabilities alongside scan data.
Anchore Enterprise 5.22 builds on this movement with better data hygiene and interoperability: improving how vulnerabilities are described (via annotations), identified (via PURLs), and evaluated (via RHEL EUS awareness).
VEX Annotations and OpenVEX Support
Anchore Enterprise users can now add annotations to individual vulnerabilities on an image—via either the API or the UI—to record their status with additional context. These annotated findings can be exported as an OpenVEX document, enabling teams to share accurate vulnerability states with downstream consumers.
When customers scan your software using their own tools, they may flag vulnerabilities that your team already understands or has mitigated. Annotations let publishers include authoritative explanations—such as “not applicable,” “patched in internal branch,” or “mitigated via configuration.” Exporting this context in OpenVEX, a widely recognized standard, prevents repetitive triage cycles and improves trust across the supply chain.
(CycloneDX VEX support is coming next, ensuring full compatibility with both major standards.)
The annotation workflow supports multiple status indicators that align with VEX standards, allowing teams to document whether vulnerabilities are:
- Not applicable to the specific deployment context
- Mitigated through compensating controls
- Under investigation for remediation
- Scheduled for fixes in upcoming releases
Once annotations are applied to an image, users can download the complete vulnerability list with all contextual annotations in OpenVEX format—a standardized, machine-readable structure that security tools can consume automatically. Read the docs →
PURLs by Default
All Anchore Enterprise APIs now return Package URLs (PURLs) by default for software components where one exists. A PURL provides a canonical, standardized identity for a package—combining its ecosystem, name, and version into a single unambiguous reference.
The PURL format follows the specification:
pkg:ecosystem/namespace/name@version (e.g., pkg:npm/[email protected])
Unlike older CPE identifiers, PURLs precisely map vulnerabilities to the correct package—even when names or versions overlap across ecosystems. This precision improves downstream workflows such as VEX annotations, ensuring that vulnerability status is attached only to the intended software component, not an entire family of similarly named packages. This leads to more reliable matching, fewer false correlations, and a cleaner chain of evidence in SBOM and VEX exchanges.
For packages without ecosystem-specific PURLs, Anchore Enterprise continues to provide alternative identifiers while working toward comprehensive PURL coverage.
PURLs + VEX Workflows
PURLs significantly improve the precision of VEX annotations. When documenting that a vulnerability is not applicable or has been mitigated, the PURL ensures the annotation applies to exactly the intended package—not a range of similarly-named packages across different ecosystems.
This precision prevents misapplication of vulnerability status when:
- Multiple ecosystems contain packages with identical names
- Different versions exist across a software portfolio
- Vulnerability annotations need to be narrowly scoped
- Automated tools process VEX documents
For organizations distributing software to customers with their own security scanning tools, PURLs provide the unambiguous identifiers necessary for reliable vulnerability communication.
RHEL EUS Indicators
Anchore Enterprise now detects and flags RHEL Extended Update Support (EUS) content in container images, applying the correct EUS vulnerability data automatically.
RHEL EUS subscribers receive backported fixes for longer lifecycles than standard RHEL releases. Without this visibility, scanners can misclassify vulnerabilities—either missing patches or reporting false positives. The new EUS indicators verify that vulnerability assessments are based on the right lifecycle data, ensuring consistent and accurate reporting.
If an image is based on an EUS branch (e.g., RHEL 8.8 EUS), Anchore now displays that context directly in the vulnerability report, confirming that all findings use EUS-aware data feeds.
How to Get Started
- Upgrade to Anchore Enterprise 5.22. Release notes →
- Add annotations: via UI (Vulnerability tab → Annotate) or API (
/vulnerabilities/annotations). - Export OpenVEX: from the Vulnerability Report interface or CLI to share with partners.
- Check EUS status: in the Vulnerability Report summary—look for “EUS Detected.”
- Integrate PURLs: via API or SBOM exports for precise package mapping.
Ready to Upgrade?
Anchore Enterprise 5.22 delivers the vulnerability communication and software identification capabilities that modern software distribution requires. The combination of OpenVEX support, PURL integration, and RHEL EUS detection enables teams to manage vulnerability workflows with precision while reducing noise in security communications.
Existing customers: Contact your account manager to upgrade to Anchore Enterprise 5.22 and begin leveraging OpenVEX annotations, PURL identifiers, and EUS detection.
Technical guidance: Visit our documentation site for detailed configuration and implementation instructions.
New to Anchore? Request a demo to see these features in action.
Learn the 5 best practices for container security and how SBOMs play a pivotal role in securing your software supply chain.
