Fair questions, straight answers.

No. A CVE identifies a vulnerability, CVSS rates it in the abstract, and CIR uses both as they are: the core layer points to the CVE and stores the CVSS vector, it never redefines them.

What CIR adds is everything those two do not carry: who exploits the issue, how one entity stands against it, and what one organization decided about it.

OSV is excellent at one thing: which package versions are affected. CIR adopts its range model as is, so the affected part of a CIR record imports from and exports to OSV.

OSV stops there by design. It has no threat intelligence, no posture, no organizational context, and no sharing model for any of it.

VEX answers one question: is this product affected? The posture.status of a CIR record is aligned with VEX and exports as a VEX statement, so CIR covers that question and keeps compatibility.

Around it, CIR records why: the controls in place, the detection, the blast radius, the decision. See the mapping.

STIX is a graph language for exchanging threat intelligence at large. CIR is one record per issue, meant to be read by a SOC analyst, a developer and a CISO alike.

They meet in threat_intel: actors and campaigns are references to existing namespaces (MITRE, MISP, Malpedia), and large indicator sets ship as external STIX or MISP bundles.

A ticket tracks work for one team. The same issue usually lives in five tickets, three emails and a spreadsheet, each a little different. A CIR record is the single reference they all point to.

It does not replace the tickets: context.remediation.tickets lists them, and context.communication logs who was informed, when and how.

Because people write and review these records, not only machines. YAML takes comments, reads well in a pull request and diffs cleanly. A JSON Schema is planned as the source of truth for validators.

Yes, that is half the point. A pentest finding, a misconfiguration or an in-house bug uses the exact same structure, with an internal identifier (CIR-2026-LAB-0012) and a restrictive TLP. See one.

Because a typed score is an opinion, and opinions don't compare across teams. cir-risk is computed from the record fields, and validators reject a stored score that does not match.

You may still store your own score under another method name. How scoring works.

Unknown severity, exposure or impact count as the worst case. Otherwise the fastest way to lower a risk would be to document less. This way, filling the layers is what brings a score down.

Because posture is the layer you send outside: to a group CERT, a sector ISAC. Free text is where hostnames, product names and rule IDs slip in by accident. Enums cannot leak. If one is missing, it gets added to the specification. More on this.

The TLP of each layer, set by the author. Exporting to an audience drops every layer it may not receive; nothing is redacted by hand. How sharing works.

The CIR project, in the open at github.com/cirsec. The specification is published under the Apache 2.0 license. Changes are discussed in issues and land through pull requests reviewed by the maintainers.

Public records use an issuer code starting with 0, e.g. CIR-2026-0CERTFR-0001. Codes are listed in the authorities registry and added through a pull request reviewed by the maintainers. Validators reject a public code that is not in it.

Internal records need nothing: any code that does not start with 0 is yours.

Every record states the version it follows in cir_version, and every stored score names its method, e.g. cir-risk/0.1. Tooling always knows which rules apply to a record.

CIR is a draft (v0.1): fields may still change before the format is declared stable.

Not yet. Next on the roadmap: a JSON Schema as the source of truth, then a reference CLI to validate a record, compute its scores and export it by TLP.

Write a real issue as a CIR record and tell us where it did not fit. That feedback shapes the format more than anything else. Issues are open.