Cloud Resource Identifier Templates (CRIT)

1.1. Overview

CPE [CPE23] and PURL [PURL] model the vulnerable entity as a build-from-source artifact — something with a static name, a version string, and a build-time identity that persists across deployment. Cloud infrastructure resources do not have these properties. An RDS instance, an EKS cluster, and a Cloudflare Worker are each identified by provider-native runtime identifiers whose components include consumer-specific variables (account identifiers, region codes, resource IDs) that do not exist until the resource is deployed. No package name, version string, or source repository URL applies.¶

CRIT defines a parameterised template system over these provider-native identifier schemas, together with fix propagation semantics, exposure window computation rules, and detection metadata. It integrates with CVEListv5 ([CVEListv5]) ADP containers and OSV schema ([OSV-Schema]) using their existing extension mechanisms. Risk-based prioritisation signals such as EPSS ([EPSS]) remain complementary inputs to consumer tooling.¶

1.2. The Identifier Gap

CPE and PURL both assume the vulnerable entity is produced by a build process — compiled from source, packaged into a distributable artifact, and deployed by installing that artifact. This assumption holds for operating systems, libraries, and application binaries. It does not hold for cloud infrastructure resources.¶

A cloud resource is instantiated by a provider API call, not by installing a package. It is identified by a provider-native runtime identifier — an ARN, an Azure Resource ID, a GCP Resource Name, an OCID, or a Cloudflare Locator — that is assigned at creation time and contains components specific to the consumer's account, region, and deployment. These identifiers have no analogue in any package registry. There is no source repository, no version string, and no build manifest.¶

Representing a cloud resource as a pkg:generic/ PURL, a synthesised CPE string, or a custom PURL type does not resolve this gap. The PURL specification [PURL] defines no registered type for cloud infrastructure resources. The pkg:cloud/ convention observed in the OSV ecosystem (see Section 9.3.1) is not a registered PURL type. Regardless of identifier scheme, the resulting string carries none of the information required to determine whether a specific deployed resource is affected: the deployment date relative to the fix, the propagation mechanism, whether the consumer has taken the required action, or whether a configuration change has since been reverted.¶

1.3. Cloud Resource Exposure Model

For package vulnerabilities, affected status is determined by a version comparison: if the installed version falls within the affected range, the package is vulnerable. Cloud resources have no equivalent comparison. Affected status is a function of four factors that must be evaluated simultaneously:¶

• When the resource was deployed relative to when the provider fix became available.¶
• The fix propagation type — whether the fix applies automatically, requires a version update, requires a configuration change, or requires the resource to be destroyed and recreated.¶
• Whether the consumer has taken the required action, if any.¶
• Whether a previously applied remediation has been reverted by subsequent configuration drift.¶

No static identifier carries these factors. A CPE or PURL string identifies what the resource is; it does not encode how the fix reaches the resource or whether a specific instance has been remediated. Each consumer tool that evaluates cloud resource exposure must independently model these semantics.¶

Discovery additionally requires interpolation. The identifier for a specific resource instance contains consumer-specific variables — account, region, resource ID — that must be substituted at resolution time. A single CRIT template represents all instances of a resource type; resolution produces the concrete identifier for a specific instance.¶

1.4. CRIT Approach

CRIT addresses the identifier gap by defining a parameterisation layer over provider-native identifier schemas. A CRIT record does not invent a new identifier format. It parameterises the identifier format the provider already defines, expressing consumer-specific and context-dependent values as variable slots within the provider's own schema.¶

Each CRIT record carries the fix propagation type, shared responsibility model, temporal metadata, remediation actions, and detection queries required for a consumer to evaluate exposure and drive remediation for a specific vulnerability on a specific cloud resource type. The record is bound to exactly one vulnerability identifier. Cross-provider and multi-resource-type coverage of a single vulnerability is expressed as a set of records sharing the same vulnerability identifier, each independently specifying the provider-specific semantics.¶

CRIT does not replace CVE, CPE, or PURL. It complements them by providing the cloud resource scope, fix propagation semantics, and exposure window computation that those schemes do not address.¶

1.5. What CRIT Is and What It Is Not

If the problem could be described in one word, that word is affected. For packages, "affected" is a version comparison. For cloud, "affected" is a function of four factors evaluated simultaneously: when the resource was deployed relative to the fix, the fix propagation type, whether the consumer has acted, and whether a previously applied remediation has been reverted by configuration drift. No static identifier carries these factors. CRIT encodes all four.¶

1.6. Conventions and Terminology

3.1. Overview

A CRIT record is a template engine for cloud-native resources: discovery requires interpolation of consumer-specific variables at resolution time, which no static identifier can express.¶

A CRIT template string is a provider identifier format with zero or more variable slots. Each slot expresses one of four states. The choice of state is normative: it is determined by the semantics of the field for the given resource type, not by what the consumer happens to know.¶

3.2. Slot Syntax

Variable slots are delimited with { and }. The content within the delimiters is a slot descriptor with the following ABNF ([RFC5234]) grammar:¶

slot            = "{" slot-descriptor "}"
slot-descriptor = named-var / wildcard / empty-marker / hardcoded
named-var       = field-name
wildcard        = field-name "=" "*"
empty-marker    = field-name "="
hardcoded       = field-name "=" literal-value
field-name      = 1*( ALPHA / DIGIT / "-" / "_" )
literal-value   = 1*( ALPHA / DIGIT / "-" / "_" / "." / ":" )

The characters { and } are reserved as slot delimiters and MUST NOT appear in literal-value or as literal characters within a template string outside of slot expressions.¶

3.3. Design Relationship to RFC 6570

CRIT slot syntax uses curly-brace delimiters that resemble [RFC6570] URI Templates. This resemblance is intentional but superficial. CRIT slots are not URI Templates and implementations MUST NOT process them with an RFC 6570 expansion engine.¶

The CRIT variable system defines exactly four slot states. The number four is a design invariant: each additional state multiplies the number of producer-consumer interactions that require specification and testing. Because cloud provider identifier schemas are not standardised, and the number of providers is unbounded, the slot state vocabulary must remain fixed to prevent combinatorial growth in conformance surface area. The four states are the minimum set that satisfies all operational requirements defined in this specification:¶

1. Named variable ({field}): Consumer-supplied value. This is the only state that corresponds to [RFC6570] Level 1 simple string expansion.¶
2. Wildcard ({field=*}): Population enumeration. No [RFC6570] equivalent exists. The semantic is an inventory operation, not a URI construction.¶
3. Empty ({field=}): Structurally present but inapplicable. The resolved value is the empty string. [RFC6570] does not distinguish between an undefined variable and a field that is normatively absent from the provider schema; CRIT requires this distinction to prevent consumers from treating a structurally absent field as an unknown value requiring resolution.¶
4. Hardcoded ({field=literal}): Provider-fixed value. The value is determined by the provider schema, not by the consumer. This state is required because some provider identifier schemas contain positional fields whose value is invariant for a given resource type (e.g., a region field that is always us-east-1 for a global service). Without a distinct hardcoded state, a consumer cannot distinguish a provider-fixed value from a consumer-specific value that coincidentally matches.¶

[RFC6570] operators (+, #, ., /, ;, ?, &) are not supported. CRIT templates use simple string replacement only. A fully-resolved CRIT template — one in which every named-variable slot has been substituted with a concrete value, every empty slot resolved to the empty string, and every hardcoded slot resolved to its literal — produces a valid provider-native resource identifier. The result is a plain string, not a URI Template expansion.¶

3.4. The Four Slot States

3.5. Slot State Selection Rules

A CRIT producer MUST select the slot state according to the following precedence:¶

1. If the provider schema normatively fixes this field to a specific value for the resource type: hardcoded.¶
2. If the provider schema specifies the field is structurally absent or inapplicable for this resource type: empty.¶
3. If the field represents a cross-resource population query rather than a specific resource: wildcard.¶
4. Otherwise: named variable.¶

A CRIT producer MUST NOT use wildcard as a fallback when the correct state is unknown. An unknown consumer-specific value is always a named variable; wildcard is a deliberate semantic choice meaning "enumerate all".¶

4.1. Envelope and Identity

{
  "vectorString": "<crit-vector>",
  "vuln_id": "<string>",
  "provider": "<enum>",
  "service": "<string>",
  "resource_type": "<string>",
  "resource_lifecycle": "<enum>",
  "shared_responsibility": "<enum>",
  "vex_status": "<enum>"
}

crit-vector     = prefix "/" metrics "#" qualifiers
prefix          = "CRITv" semver
semver          = 1*DIGIT "." 1*DIGIT "." 1*DIGIT
                  [ "-" 1*(ALPHA / DIGIT / ".") ]
metrics         = metric *("/" metric)
metric          = metric-key ":" metric-value
metric-key      = 2ALPHA
metric-value    = 1*(ALPHA / DIGIT)
qualifiers      = qual-value ":" qual-value ":" qual-value
qual-value      = 1*(ALPHA / DIGIT / "-" / "_" / ".")

CRITv0.2.0/CP:AW/VS:FX/FP:RR/SR:CA/RL:SC/EV:T/PP:1719792000/SA:1514764800#CVE-2024-6387:ec2:instance

4.2. Resource Template

4.3. Temporal Fields and Exposure Window

These fields collectively define the bounds of exposure. No single field closes the exposure window for a given consumer resource; see Section 7 for the formal computation.¶

{
  "temporal": {
    "service_available_date": "<date>",
    "vulnerability_introduced_date": "<date>",
    "vulnerability_introduced_date_estimated": "<boolean>",
    "vuln_published_date": "<date>",
    "provider_acknowledged_date": "<date>",
    "provider_fix_date": "<date>",
    "customer_deadline_date": "<date>",
    "customer_deadline_source": "<enum>"
  }
}

service_available_date (OPTIONAL):

When the provider first made this service or feature generally available. Bounds the earliest any resource could have been deployed into a vulnerable configuration.¶

vulnerability_introduced_date (OPTIONAL):

When the vulnerability was first present. MAY predate vuln_published_date by months or years. When present, MUST be used as W_start of the exposure window.¶

vulnerability_introduced_date_estimated (OPTIONAL):

When true, vulnerability_introduced_date is an estimate. Consumers SHOULD surface this flag in exposure window reporting.¶

vuln_published_date (REQUIRED):

Date the vulnerability record was first published. MUST match the vulnerability record's datePublished field.¶

provider_acknowledged_date (OPTIONAL):

When the provider first confirmed the vulnerability.¶

provider_fix_date (OPTIONAL):

When the provider made a fix generally available. MUST NOT be interpreted as the date a consumer resource is remediated. Absent when no fix has been released.¶

customer_deadline_date (OPTIONAL):

A normative remediation deadline. Conformant consumer tools SHOULD use this for SLA computations.¶

customer_deadline_source (OPTIONAL):

One of: cisa_kev, pci_dss, hipaa, sox, internal_policy, other. REQUIRED when customer_deadline_date is present.¶

4.4. Fix Propagation and Remediation Actions

4.5. Provider Fix Version

Cloud resources do not use package-style versioning. There is no semver string to compare against a fixed bound, no registry entry to look up, and no universal version format that applies across providers or even across services within a single provider. "Version" for a cloud resource might mean an engine release string, a runtime build date, a Kubernetes minor version within a release channel, a container image digest, or a platform image creation date -- depending on the service. In some cases, such as Cloudflare Workers, there is no consumer-visible version at all; only a platform build date.¶

The provider_fix_version field is a discriminated object whose structure is determined by the version_type discriminator. Each version_type value defines a specific set of fields and a comparison operator that together give a consumer everything needed to evaluate whether a deployed resource meets the fix threshold.¶

4.6. Detection Fields

Detection fields enable consumers to deploy log queries, metric filters, and alerting rules that identify vulnerable configurations, active exploitation, or configuration drift. A record with vex_status of affected or fixed SHOULD include at least one detection entry.¶

4.7. Provider Advisory

4.8. VEX Status

The vex_status field aligns CRIT records with the OpenVEX ([OpenVEX]) / CSAF VEX ([CSAF-VEX]) vocabulary for composability with VEX-aware tooling.¶

A consumer MUST treat vex_status as a record-level statement about provider fix availability, not as a per-resource remediation status. A record with vex_status = fixed and existing_deployments_remain_vulnerable = true represents the common real-world condition: a fix exists at the provider level, but existing deployed resources are not automatically remediated. Both facts are simultaneously true and MUST both be surfaced to operators.¶

5.1. AWS ARN

Canonical formats:¶

arn:aws:{service-prefix}:{region}:{account}:{resource-type}/{id}
arn:aws:{service-prefix}:{region}:{account}:{resource-type}:{id}

The {service-prefix} slot is always hardcoded (e.g., iam, s3, ec2, lambda, eks, rds).¶

The {region} slot MUST be hardcoded to us-east-1 for globally-scoped services whose ARN schema requires the region field to carry a fixed value: iam, cloudfront, route53, waf, wafv2, shield, organizations, sts, globalaccelerator. For globally-scoped services whose ARN schema structurally omits the region field (the field is positionally present but the value is the empty string), the region slot MUST be empty ({region=}). S3 buckets and objects are the principal example: the ARN format is arn:aws:s3:::{resource}. For all other AWS services the region slot MUST be a named variable or wildcard and MUST NOT be empty.¶

The {account} slot is a named variable, except for resource types whose ARN schema structurally omits the account field (e.g., S3 buckets and objects), in which case it MUST be empty ({account=}). The {resource-type} slot is hardcoded or empty per the service schema. The {resource-id} slot is a named variable or wildcard.¶

arn:aws:iam:{region=us-east-1}:{account}:role/{resource-id}
arn:aws:s3:{region=}:{account=}:{resource-id}
arn:aws:ec2:{region}:{account}:instance/{resource-id}
arn:aws:lambda:{region}:{account}:function:{resource-id}
arn:aws:eks:{region}:{account}:cluster/{resource-id}

5.2. Azure Resource ID

Canonical format:¶

/subscriptions/{subscriptionId}/resourceGroups/{resourceGroup}
  /providers/{namespace}/{type}/{name}

{subscriptionId} and {name} are always named variables. {resourceGroup} is a named variable or wildcard. {namespace} and {type} are always hardcoded (e.g., Microsoft.Compute/virtualMachines, Microsoft.ContainerService/managedClusters).¶

5.3. GCP Resource Name

Canonical format:¶

//{api}.googleapis.com/{collection-path}

{api} is always hardcoded (e.g., compute, container, sqladmin). {project} is always a named variable. {zone} is a named variable for zonal resources and empty ({zone=}) for global or regional resources.¶

5.4. Cloudflare Locator

Canonical format:¶

com.cloudflare.api.account.{account_id}.{resource-type}.{id}

Cloudflare resources are globally scoped. There is no region component. A CRIT producer MUST NOT add a region slot to a Cloudflare template. {resource-type} is always hardcoded (e.g., worker, r2_bucket, zone, d1_database).¶

5.5. Oracle OCID

Canonical formats:¶

ocid1.{type}.{realm}.{region}..{unique-id}       (regional)
ocid1.{type}.{realm}...{unique-id}               (global)

{type} is always hardcoded. {realm} is hardcoded to oc1 for commercial regions. Separate CRIT records SHOULD be produced for government realms (oc2, oc3) when fix timelines differ. {region} is a named variable for regional resources and empty ({region=}) for global resources.¶

5.6. Parameter Naming Conventions

Slot field names vary between providers by design. AWS ARNs use a consistent positional structure so slot names are uniform across services (region, account, resource-id). GCP, Azure, Oracle, and Cloudflare use service-specific path components (project, location, subscriptionId, resourceGroup, realm, account_id) because their resource path structures are service-specific. This asymmetry is intentional: CRIT adopts provider-native naming conventions rather than imposing a normalised abstraction. Consumers SHOULD expect different slot vocabularies per provider and MUST NOT assume that all providers use the same field names.¶

6.1. Resolution Order

A consumer resolving a CRIT template to a live identifier MUST apply substitutions in the following order:¶

1. Replace all hardcoded slots ({field=literal}) with their literal value.¶
2. Replace all empty slots ({field=}) with the empty string.¶
3. Replace all named variable slots ({field}) with consumer-supplied concrete values.¶
4. Wildcard slots ({field=*}) MUST NOT be resolved to a live identifier. For inventory enumeration, a consumer MAY enumerate known values to produce a set of resolved templates.¶

After step 3, the resulting string MUST be a valid provider identifier conforming to the declared template_format. A consumer MUST validate this and MUST reject a template that fails validation after full substitution.¶

6.2. Reserved Field Names

The following field names carry defined semantics across all providers. A CRIT producer MUST use these names where applicable and MUST NOT reuse them for different semantics.¶

7.1. Definition

For package vulnerabilities, an exposure window can be approximated from version data alone: a package was exposed from the time the vulnerable version was released until the time the fixed version was installed. Cloud resources have no equivalent computation. There is no "installed version" to timestamp, no registry entry recording when a resource was last updated, and no version comparison that determines whether a specific running resource is currently in the affected range.¶

The CRIT exposure window is therefore defined over time and consumer action, not over version ranges. A resource enters the window when it is deployed into a vulnerable configuration. It exits the window when a qualifying remediation event is recorded -- which may be long after provider_fix_date for resources where existing_deployments_remain_vulnerable is true, or never, for resources under no_fix_available propagation.¶

Formally, the exposure window is the interval [W_start, W_end] where:¶

• W_start = vulnerability_introduced_date when present; otherwise vuln_published_date. When vulnerability_introduced_date_estimated is true, consumers SHOULD indicate this in user-facing reporting.¶
• W_end is determined per Section 7.2.¶

7.2. Record-Level W_end

7.3. The Deployed-Before-Fix Problem

When existing_deployments_remain_vulnerable is true, the exposure window for a specific resource instance is NOT closed by provider_fix_date. A consumer MUST apply the following logic per resource:¶

if resource.deployed_date < provider_fix_date
  AND existing_deployments_remain_vulnerable == true
  AND no confirmed remediation action recorded for this resource:
    resource.exposure_window_end = null  // open

A consumer MUST record a per-resource remediation event to close the window for that resource. A consumer MUST NOT mark a resource as remediated solely because provider_fix_date has passed.¶

7.4. Opt-In and Config Change Drift

When fix_propagation is opt_in or config_change, a remediation may be reversed by a subsequent configuration change, reopening the window. When a misconfiguration-phase detection fires for a resource, a consumer MUST treat this as a window-reopening event. A consumer MUST keep misconfiguration-phase detections active indefinitely for any resource remediated via opt_in or config_change.¶

7.5. Rolling Replace Fleet Exposure

When fix_propagation is rolling_replace, the exposure window is partially open during the fleet transition. A consumer MUST NOT consider the window closed until fleet replacement is confirmed at 100%.¶

7.6. Channel-Gated Exposure

When provider_fix_version.comparison is channel_and_gte, the effective fix availability date differs by release channel. A consumer MUST use the channel-specific fix date derived from the note field when computing per-cluster exposure windows.¶

8.1. Producer Conformance

A conformant CRIT producer MUST:¶

• Emit records that validate against the schema defined in Section 4.¶
• Enforce the natural key uniqueness constraint: no two records in a corpus MAY share (vuln_id, provider, service, resource_type).¶
• Apply slot state selection rules defined in Section 3.5.¶
• Apply AWS region hardcoding rules defined in Section 5.1.¶
• Set existing_deployments_remain_vulnerable = false only when fix_propagation = automatic AND shared_responsibility = provider_only.¶
• Set existing_deployments_remain_vulnerable = true when provider_fix_version.auto_upgrade is present and false.¶
• Set fix_propagation = no_fix_available and omit provider_fix_date when no fix exists.¶
• Include at least one remediation_actions entry for every record where vex_status is affected or fixed.¶
• Use ISO 8601 [ISO8601] full-date format for all date fields.¶
• Include at least one misconfiguration-phase detection entry for records where fix_propagation is opt_in or config_change. A placeholder entry with pending_reason (Section 4.6.4) satisfies this requirement.¶
• Compute vectorString as the canonical CRIT vector string from the record's own fields per Section 4.1.2.¶
• Encode temporal.vuln_published_date as the PP metric value in Unix epoch seconds (UTC).¶
• Encode temporal.service_available_date as the SA metric value in Unix epoch seconds (UTC).¶

A conformant CRIT producer SHOULD:¶

• Include at least one detection entry for records where vex_status is affected or fixed.¶
• Populate provider_advisory when a provider security advisory exists.¶
• Populate vulnerability_introduced_date when determinable; set vulnerability_introduced_date_estimated = true when the date is an estimate.¶

8.2. Consumer Conformance

A conformant CRIT consumer MUST:¶

• Treat provider_fix_date as closing the exposure window only when existing_deployments_remain_vulnerable is false.¶
• Not substitute hardcoded slot values with alternative values.¶
• Not use wildcard templates as live provider API identifiers.¶
• Track per-resource remediation events separately from record-level vex_status.¶
• Treat a misconfiguration-phase detection match as a window-reopening event.¶
• Keep misconfiguration-phase detections active indefinitely once deployed.¶
• Use channel-specific fix dates for channel_and_gte version types when per-resource channel enrollment is known.¶
• Prefer image_digest over image_tag for container_image version comparison when both are present.¶
• Ignore unknown metric keys in a vectorString without error (forward compatibility per Section 4.1.2.3).¶
• Reject a vectorString missing any registered metric.¶
• Not treat a vectorString as a complete record representation. Use the full JSON record for operational decisions requiring fields not carried in the vector (see Section 4.1.2.4).¶

A conformant CRIT consumer SHOULD:¶

• Present remediation_actions in declared sequence order.¶
• Substitute consumer-specific named variable values into detection query slots before deploying queries.¶
• Apply customer_deadline_date when computing remediation SLAs.¶
• Surface vulnerability_introduced_date_estimated = true in operator-facing exposure window reporting.¶

9.1. Integration Strategy and Phasing

CRIT data is published via two upstream vulnerability schema ecosystems: the CVE List v5 ADP container and the OSV schema. Each integration follows a two-phase strategy.¶

Phase 1 -- Extension (current): CRIT records are embedded as custom x_ properties within conformant records of the target schema. This is immediately deployable without requiring changes to either upstream schema. Phase 1 records are fully schema-valid because both CVEListv5 and OSV permit additional properties with the x_ prefix.¶

Phase 2 -- Native integration (proposed): CRIT fields are expressed using native objects defined by the upstream schema wherever a semantic mapping exists. Fields without a native mapping continue to use x_crit_* prefixed properties within the appropriate extension points. Phase 2 requires coordination with CVEProject and OpenSSF but does not require either upstream schema to define new first-class fields for all CRIT concepts.¶

A producer MUST NOT remove Phase 1 fields until: Phase 2 native fields have been published for at least one full release cycle of the target schema; the cloud:* ecosystem namespace has been formally registered with OSV schema maintainers or the ADP native field mapping accepted by the CVEProject schema working group; downstream consumers have confirmed migration to Phase 2; and a 90-day deprecation notice has been in the relevant records.¶

9.2. CVE List v5 ADP Container Integration

Vulnetix publishes CRIT data as an Authorized Data Publisher (ADP) in CVEListv5 records. The Vulnetix ADP container is identified by providerMetadata.shortName = "VVD" or by Vulnetix's orgId in the containers.adp[] array.¶

9.3. OSV Schema Integration

Publishers may produce CRIT data in OSV schema format for consumption by OSV.dev and compatible tooling.¶

11.1. Detection Query Sensitivity

Detection strings specify exact log filter patterns for identifying vulnerable configurations and exploitation. A corpus of CRIT detection entries reveals what a consumer is and is not monitoring for. CRIT records SHOULD be treated as security-sensitive and access-controlled in consumer systems.¶

11.2. Exposure Window Date Sensitivity

The combination of vulnerability_introduced_date, provider_fix_date, and existing_deployments_remain_vulnerable can allow an adversary to infer whether specific consumer resources remain vulnerable. Consumers SHOULD NOT expose exposure window details in public-facing interfaces.¶

11.3. Compensating Control Disclosure

Remediation actions with compensating_control = true reveal which mitigating controls are in place. Consumers SHOULD NOT expose active compensating control details in contexts where that information assists an adversary in targeting unmitigated surface.¶

11.4. Template Wildcard Enumeration

Wildcard templates reveal the structural scope of a consumer's cloud footprint. A consumer MUST NOT expose unresolved wildcard templates in contexts where asset enumeration is harmful.¶

11.5. Provider Fix Version Trust

provider_fix_version values are advisory in nature. A consumer MUST independently verify that a deployed resource meets the version threshold. Container image tags are mutable; digest comparison MUST be preferred. A consumer MUST NOT assume remediation solely on the basis of a version string match.¶

11.6. Natural Key Collision

A producer accepting CRIT records from multiple upstream sources MUST enforce natural key uniqueness before serving records. Duplicate natural keys with conflicting field values can cause consumers to make incorrect remediation decisions. Producers SHOULD define and expose a conflict resolution policy.¶

12.1. Definition

A CRIT Dictionary is a machine-readable catalogue of entries that enumerate the valid combinations of provider, service, and resource_type values recognised by this specification, together with the provider-native identifier template and supporting metadata for each combination. A dictionary entry is the atomic unit of service coverage: it asserts that a given cloud provider service and resource type is within CRIT scope and provides the template and slot semantics required to locate instances of that resource type in a consumer’s inventory.¶

A CRIT Dictionary is not a vulnerability database and does not contain vulnerability-specific data. It is a stable reference layer that producers and consumers use to validate and resolve CRIT records. A CRIT record’s (provider, service, resource_type) tuple MUST resolve to an entry in a conformant dictionary before the record is considered valid.¶

Two categories of dictionary exist:¶

Spec Default Dictionary:

The normative dictionary published alongside this specification in the specification repository. It covers the providers described in Section 12.6 and representative service and resource type combinations for each. Producers and consumers MUST support the Spec Default Dictionary as a baseline.¶

Extended Dictionary:

A superset of the Spec Default Dictionary produced by a Vulnetix deployment or third party. Extended dictionaries MAY add entries for services or resource types not present in the Spec Default Dictionary, and MAY add entries for additional providers. Extended dictionaries MUST NOT remove or alter the semantics of entries present in the Spec Default Dictionary.¶

12.2. Dictionary Entry Schema

Each dictionary entry is a JSON object. All fields except notes are REQUIRED.¶

{
  "provider":        "<enum: aws | azure | gcp | cloudflare | oracle
                            | salesforce | sap | servicenow>",
  "service":         "<string: normalised service key>",
  "resource_type":   "<string: resource type within service>",
  "template":        "<CRIT template string>",
  "template_format": "<enum: aws_arn | azure_resource_id | gcp_resource_name
                             | cloudflare_locator | oracle_ocid
                             | salesforce_url | sap_btp_url | sap_odata_url
                             | sap_sf_url | servicenow_table_url>",
  "region_behavior": "<enum: regional | global-only>",
  "notes":           "<string: optional annotation>"
}

provider:

The canonical provider key as defined in Section 4.1.¶

service:

The normalised service key (lowercase, underscores). This is the value used in the CRIT record service field and the second component of the natural key tuple. Where a provider uses multiple common names for the same service, the dictionary carries the canonical key; synonyms are resolved to it by the producer prior to record emission.¶

resource_type:

The resource type within the service. This is the value used in the CRIT record resource_type field. For services with multiple resource types, each type has its own dictionary entry with a distinct (provider, service, resource_type) natural key.¶

template:

The CRIT template string for this entry, expressed using the slot syntax defined in Section 3. After variable resolution, the string MUST be a valid provider identifier of the declared template_format.¶

template_format:

One of: aws_arn, azure_resource_id, gcp_resource_name, cloudflare_locator, oracle_ocid, salesforce_url, sap_btp_url, sap_odata_url, sap_sf_url, servicenow_table_url. The applicable value for each provider is defined in Section 12.6.¶

region_behavior:

One of: regional (the {region} slot is a named variable, consumer-supplied) or global-only (the region slot is hardcoded in the template; the resource type is not regional).¶

notes:

Optional human-readable annotation. Used to document aliasing, deprecation, or provider-specific constraints not expressible in other fields.¶

12.3. Dictionary Conformance

A conformant CRIT producer MUST:¶

• Validate each record’s (provider, service, resource_type) tuple against a conformant dictionary before emitting the record.¶
• Use the template and template_format values from the matching dictionary entry as the basis for the record’s template fields.¶
• Support the Spec Default Dictionary as a minimum baseline. An extended dictionary MAY be used in addition but not in place of the Spec Default Dictionary.¶

A conformant CRIT consumer MUST:¶

• Reject records whose (provider, service, resource_type) tuple does not resolve to an entry in any dictionary the consumer supports, rather than silently ignoring them.¶
• Use the dictionary entry’s region_behavior field when constructing inventory queries from wildcard templates, to avoid submitting region-qualified identifiers for global-only resource types.¶

12.4. Dictionary Versioning

The Spec Default Dictionary is versioned alongside the CRIT specification. The dictionary version is the same as the semver string carried in the vectorString prefix of CRIT records. Additions of new entries within a minor version are backwards compatible. Removal or semantic modification of existing entries requires a major version increment.¶

Producers SHOULD include a dictionary_version field in their extended dictionaries to allow consumers to detect stale dictionary coverage.¶

12.5. Dictionary Governance

The Spec Default Dictionary is maintained alongside this specification and represents the minimum baseline catalogue. It is not an exhaustive enumeration of all cloud resource types. Additions to the Spec Default Dictionary within a minor version are backwards compatible; removal or semantic modification of existing entries requires a major version increment.¶

Extended Dictionaries are independently maintained by implementers and are subject to the conformance requirements of Section 12.3.¶

A conformant consumer MUST validate CRIT records against a dictionary before accepting them. Validation requires a known, trusted dictionary as the source of truth for the (provider, service, resource_type) tuple space. A consumer that does not maintain a dictionary cannot distinguish a valid tuple from an arbitrary one; therefore, dictionary availability is a prerequisite for conformant consumption.¶

A conformant producer MAY emit CRIT records without consulting a dictionary, but the resulting records are non-conformant until validated by a consumer that holds a dictionary containing matching entries. Producers SHOULD validate records against a dictionary before emission to avoid producing records that no conformant consumer will accept.¶

Cloud providers are encouraged to contribute dictionary entries for their services. Community contributions are accepted via the specification repository. No IANA registry is proposed for dictionary entries. The dictionary is a template catalogue scoped by provider, not a shared identifier namespace; provider-scoped entries do not compete for a global name and therefore do not require a central allocation authority.¶

12.6. Provider Identification Systems

Each provider covered by this specification maintains a published, authoritative identification scheme for its resources. CRIT dictionary entries do not define these schemes; they encode them as CRIT templates so that producers can emit identifiers that conform to the provider’s own published format. Implementers adding dictionary entries for services not listed here MUST derive templates from the provider’s current documentation; those entries MAY be contributed to the Spec Default Dictionary via the specification repository.¶

arn:aws:ec2:{region}:{account}:instance/{resource-id}
arn:aws:iam:{region=us-east-1}:{account}:role/{resource-id}

/subscriptions/{subscriptionId}/resourceGroups/{resourceGroup}/providers/Microsoft.Compute/virtualMachines/{name}

//compute.googleapis.com/projects/{project}/zones/{location}/instances/{resource-id}
//storage.googleapis.com/projects/{project}/buckets/{resource-id}

com.cloudflare.api.account.{account_id}.zone.{id}

ocid1.instance.{realm=oc1}.{region}..{unique-id}
ocid1.compartment.{realm=oc1}...{unique-id}

https://{instance}.salesforce.com/services/data/v{api-version}/sobjects/{object-type}/{record-id}

https://api.{region}.hana.ondemand.com/resourcemanager/v1/instances/{resource-id}
https://{host}/sap/opu/odata/sap/{service-path}/{object-id}
https://api{api-server}.sapsf.com/odata/v2/{entity-set}('{resource-id}')

https://{instance}.service-now.com/api/now/table/{table-name}/{sys-id}