Video summary

Your CVE Score Is Only Half the Story — CRML Tells the Rest - Hackers On The Rocks Podcast

Main summary

Key takeaways

Technology

Core concept: CVE impact → business risk (not just severity)

This episode of Hackers On The Rocks focuses on why CVE scores (e.g., CVSS) don’t fully capture real-world impact. It also introduces CRML, an open-source “risk as code” / risk modeling language that translates technical vulnerabilities into business-relevant risk scenarios.

A recurring gap is emphasized:

  • Security teams understand CVE details and severity, but often don’t control budgets or response decisions.
  • Executives may not understand why the vulnerability matters to the business.

CRML is presented as a way to model how and where a vulnerability matters differently depending on organizational context, such as:

  • Which department uses a system
  • What role an asset plays
  • How exposure translates into business harm

What CRML is

  • Declarative language for writing risks “in code” in a way that’s closer to machine processing.
  • Positioned as “risk as a code”, analogous in spirit to Terraform (infrastructure as code).
  • Designed to support risk modeling (describing risk scenarios and relationships), which is distinct from risk quantification (running a math model to produce numbers).

Key claim: CRML can feed into different risk quantification engines and is vendor-agnostic.

Why CRML exists / motivation

The guest describes searching for an open-source risk engine and not finding one. The conclusion: the missing piece wasn’t only computation—it was the ability to “write risks” in a standard, machine-readable form.

Personal motivation includes experiences where:

  • Vulnerabilities were reported responsibly
  • Teams still lacked clarity on business impact and prioritization
  • Decision-making was delayed because “why it matters” wasn’t clearly expressed

How CRML models context and dependencies

CRML supports expressing:

  • Dependencies
  • Event chains

For example, the idea that:

  • Combining multiple low/info findings with other findings can form a higher-impact scenario (described as “chain formations”).

It also addresses the “black box” critique often associated with AI risk models by making assumptions and logic explicit, such as:

  • Why a weight is 0.25 vs 0.5
  • What data sources were used
  • How older data might affect outcomes

Example context differences

  • Using the same open-source component (example mentioned: ODO), risk can vary dramatically between organizations (the example contrasts a typical org vs Bank of America).
  • Departmental priorities matter: an R&D team may prioritize risks differently than a marketing team, even if vulnerability scanners see the same CVEs.

Relationship to existing standards (schema / ontology framing)

CRML is framed as an ontology / schema-like language for risk information exchange.

The guest compares it to data normalization schemas in security:

  • OCSF (Open Cybersecurity Schema Framework) is cited as an example of how normalization improves interoperability.
  • Other referenced frameworks/tools include NIST, ISO, and OSCAL, which CRML is said to map into a coherent risk exchange model.

The product argument: a standardized risk language enables organizations (even “friendly nations”) to exchange risk intelligence without revealing confidential internal details.

CRML vs CVSS / EPSS (how they fit together)

CVSS

  • Described mainly as indicating how severe/deadly a vulnerability is, with alignment to exploitability characteristics.
  • Main limitation: CVSS doesn’t answer “how does it affect our organization?”

EPSS

  • Discussed as likelihood a vulnerability will be exploited.

Where CRML fits

CRML is positioned as the missing step:

  • If exploitation happens, what is the business impact to your organization?
  • That enables better prioritization.

Target workflow / user experience (end-to-end)

Two modes are described: CRML as code for contributors and CRML as automation for customers.

Customer experience (no CRML writing required)

The customer does not need to write CRML. Instead, CRML is generated as part of an integrated workflow that fits into existing security tooling (examples mentioned include Cloudflare and an executive/GRC tooling context like SaaS platforms / Zscaler Central One).

The described steps:

  1. Integrate with existing systems so telemetry/data flows.
  2. Ingest the organization’s policies/procedures (uploaded to the platform).
  3. Use AI to detect gaps between stated policies and what is actually being followed.
  4. Automatically translate the data into CRML and run modeling to produce prioritized outputs, such as:
    • Top risk scenarios
    • Suggested remediation actions
    • Modeled impact
    • Estimated cost/ROI for decision-making

Open source: how to contribute

Contributors can expand the language’s usefulness by adding more risk scenarios (i.e., increasing the set of scenarios the language can represent).

The repo is said to include:

  • A contributing guide
  • A CRML Studio tool to simulate risk scenarios, validate them, and flag errors

Claimed adoption / ecosystem signals

The guest states that three global cybersecurity companies are using CRML to transform telemetry into CRML for risk communication.

Main speakers / sources

  • Set — primary guest (author of CRML)
  • Ivan — host (speaks as “Ivan” early in the conversation)

References mentioned in-episode

  • CVSS
  • EPSS
  • NIST, ISO, OSCAL
  • OCSF (Splunk/AWS)

Original video