Cloud Resource Identifier Templates. CVSS-style for cloud-native CVEs.

A machine-readable format for identifying the cloud resources a known vulnerability actually affects — with the lifecycle, fix-propagation and shared-responsibility metadata operators need to remediate it.

How CRIT works

From CVE to remediation, in three deterministic steps.

1. IDENTIFY
Name the resource, not the package.

Bind each CVE to a `(provider, service, resource_type)` tuple with a template URL/ARN/locator. Slots — known, derived, opaque or omitted — encode exactly what an operator must resolve.

2. MATCH
Resolve templates against live inventory.

Consumers turn templates into provider identifiers using the dictionary library, then check the exposure window — when the resource was vulnerable, when the provider shipped a fix, and whether your specific resource has propagated past it.

3. REMEDIATE
Embed VEX-aware decisions in CVE 5.x.

CRIT records ride inside the CVE 5.x ADP container as `x_crit`, carrying `vex_status`, `fix_propagation`, `shared_responsibility` and `resource_lifecycle` — spec-bound enums with cross-field consistency the validator enforces.

Built for the cloud stack you actually run.

30+ provider dictionaries shipped in the spec library — Tier-1 hyperscalers, Tier-2 IaaS, and Tier-3 SaaS — all addressable through the same template grammar.

AWS Azure GCP Cloudflare Oracle IBM Cloud Alibaba Tencent DigitalOcean Linode Vultr Hetzner Kubernetes Confluent Snowflake Databricks Salesforce SAP ServiceNow Workday Atlassian GitHub GitLab Okta + many more

Ready to make CVE-to-cloud-resource matching deterministic?

Validate a record, read the spec, or open an issue on the draft. CRIT is Apache 2.0 and the schemas are versioned alongside the IETF draft.