VEX (Vulnerability Exploitability eXchange) is a machine-readable assertion format that answers the question an SBOM alone cannot: given that a product contains a component affected by a known CVE, is that vulnerability actually exploitable in this specific product? An SBOM identifies components and versions; a CVE database maps those versions to known vulnerabilities; but the intersection of the two systematically overstates actual risk. A container image built on a minimal base may include a library with a known buffer overflow in a network-parsing function — but if that function is never called by anything in the image, or the affected code path requires a configuration flag that is hardcoded off, the CVE is present but not exploitable. Without VEX, every scanner that ingests the SBOM raises an alert; with VEX, the supplier asserts the non-exploitability with a machine-readable justification that automated tooling can consume to suppress the alert without human triage. VEX originated in the same NTIA multistakeholder process that produced the SBOM minimum elements framework, and was formalised by CISA in 2021–2022.
SLSA (Supply-chain Levels for Software Artifacts), pronounced “salsa”, is a security framework published by OpenSSF (originally proposed by Google in 2021, version 1.0 released April 2023) that defines progressively stronger requirements for build integrity and provenance — the verifiable record of where a software artifact came from, what source it was built from, how it was built, and what the build environment looked like. The motivating threat is supply chain attacks like SolarWinds (malicious code injected into the build system) and XZ Utils (malicious code injected into the source repository): in both cases the artifact that reached users was not what the source code claimed, and consumers had no way to verify the discrepancy. SLSA’s answer is a provenance attestation: a signed, machine-readable document produced by the build platform that records the source repository and commit, the build instructions, the builder’s identity, the build environment’s properties, and the digest of the resulting artifact. Signed provenance is the basis on which consumers can make automated trust decisions rather than relying on reputation or manual inspection.
Sigstore is an OpenSSF project, initiated by Google, Red Hat, and Purdue University, that provides a free public-good infrastructure for cryptographically signing software artifacts — container images, binaries, SBOMs, attestations — without the operational burden of managing long-lived private keys. Its founding insight is that the two hardest problems in code signing are key management (generating, protecting, distributing, rotating, and revoking signing keys across thousands of developers and CI pipelines) and signature discoverability (how does a verifier find and trust the correct public key for an artifact it has never seen before). Sigstore solves both by eliminating long-lived keys entirely: every signing operation generates a fresh ephemeral key pair, uses it once, discards the private key, and records the event in a public transparency log — replacing “do you trust this key?” with “do you trust this identity at this moment in time?”.
A Software Bill of Materials (SBOM) is a structured, machine-readable list of the components that make up a software artifact: open-source libraries, proprietary packages, operating system packages, programming language dependencies, and the transitive dependencies of all of the above. It is the software analogue of the ingredient list on packaged food — the thing that tells a consumer (or an automated system) precisely what is inside. The term and concept predate current security mandates but became a regulatory requirement in the US through Executive Order 14028 (May 2021), which directed NIST and NTIA to define minimum SBOM elements for software sold to the federal government. The NTIA’s resulting guidance specifies seven minimum data fields per component: supplier name, component name, version, component identifier (CPE or PURL), dependency relationships, SBOM author, and timestamp. The practical use cases SBOMs enable are vulnerability management (correlating component versions against CVE databases to identify affected software), licence compliance (detecting GPL or other licence obligations across the dependency graph), and incident response (determining within minutes which systems in a fleet contain a newly-disclosed vulnerable component, as organisations that had SBOMs could do during the Log4Shell response and those without could not).
ORAS (OCI Registry As Storage) is a CNCF project that treats an OCI-conformant registry not as a container image store but as a general-purpose content-addressable storage system for any kind of artifact. Its central insight is that the OCI Distribution and Image specifications are already a well-understood, widely-deployed, access-controlled, geo-replicated, content-addressed storage substrate — and that the ecosystem does not need a separate storage solution for every new artifact type (Helm charts, WebAssembly modules, ML models, firmware images, OPA policies, SBOMs, attestations) when the same registry infrastructure can store all of them, using the same authentication, the same tooling, and the same pull-by-digest semantics that container images already use.
OpenPGP is an open standard for encryption and digital signatures of arbitrary data, defined in RFC 4880 (2007) and substantially revised in RFC 9580 (2024, adding Ed25519, X25519, and modern AEAD encryption). GnuPG (GPG) is the dominant open-source implementation, maintained by Werner Koch and the GnuPG project, and the tool most users interact with. OpenPGP predates the PKI/CA model and takes a fundamentally different approach to trust: rather than a hierarchy of certificate authorities that users must trust transitively, OpenPGP uses a Web of Trust in which individual users sign each other’s public keys, and trust is established through chains of personal endorsements. In the Web of Trust model, Alice trusts Bob’s key because she verified it in person and signed it; Carol trusts Bob’s key because Alice (whom Carol trusts) signed it. This decentralised, peer-to-peer trust model made sense for email encryption between individuals who could meet at key-signing parties, but does not scale to automated infrastructure verification, which is why OpenPGP’s role in modern infrastructure is primarily supply chain signing — package repositories, Git commits, and release artifacts — rather than interactive authentication.
OCI Referrers is a mechanism introduced in the OCI Image and Distribution Specification v1.1 (finalised 2024) that allows arbitrary artifacts — signatures, SBOMs, vulnerability scan reports, attestations, provenance documents — to be attached to an existing image in a registry without modifying the image itself and without requiring out-of-band storage or tag conventions. The attachment is expressed through a subject field added to any OCI manifest: a descriptor pointing to the digest of the target image. The registry then indexes these relationships, and the referrers API makes them discoverable.
The NIS2 Directive (EU 2022/2555) is an EU directive — the successor to the original NIS1 of 2016 — that entered into force on 16 January 2023 with a transposition deadline of 17 October 2024, meaning each EU Member State was required to adopt it into national law by that date and enforce it from 18 October 2024 onward. NIS2 is issued by the European Parliament and Council; as a directive (not a regulation), its exact requirements vary by Member State, but the baseline obligations are binding. It applies to medium and large organizations (50+ employees or €10M+ annual turnover) operating in 18 critical sectors including energy, transport, health, banking, digital infrastructure, ICT service management, public administration, and manufacturing. Entities are classified as essential (proactive supervision, fines up to €10M or 2 % of global turnover) or important (reactive supervision, fines up to €7M or 1.4 % of turnover). Compliance is mandatory — management bodies are personally liable for overseeing cybersecurity risk management. Key obligations include implementing proportionate technical and organizational security measures, conducting supply chain risk assessments, reporting significant incidents to the national CSIRT within 24 hours (early warning), 72 hours (full notification), and one month (final report), and cooperating with national cybersecurity authorities. Member States were required to publish their lists of essential and important entities by 17 April 2025.
The CISA Known Exploited Vulnerabilities (KEV) Catalog is a living database maintained by the US Cybersecurity and Infrastructure Security Agency that lists CVEs for which CISA has obtained reliable evidence of active exploitation in the wild. It was established under Binding Operational Directive 22-01 (BOD 22-01), issued in November 2021, which requires all US Federal Civilian Executive Branch (FCEB) agencies to remediate KEV-listed vulnerabilities within prescribed timeframes — typically 2 weeks for critical vulnerabilities and up to 6 months for older ones. A vulnerability must meet three criteria to be added: it must have a CVE ID, there must be reliable evidence of exploitation in the wild (not just a proof-of-concept or theoretical risk), and there must be clear remediation guidance available. CISA accepts nominations from the public and adds vulnerabilities continuously; the catalog is available in CSV and JSON formats at a stable URL, making it machine-consumable for integration into vulnerability management platforms and asset inventory tools.
The Cyber Resilience Act (CRA) is a European Union regulation — not a voluntary standard — that entered into force on 10 December 2024 and will be fully applicable on 11 December 2027. It is issued by the European Commission and co-legislated by the European Parliament and Council; it is not a certification scheme but a horizontal product-safety law, comparable in structure to the CE-marking directives for physical goods. The CRA applies to all manufacturers, importers, and distributors of “products with digital elements” — any software or hardware product containing a data connection — that is made available on the EU single market, regardless of where the manufacturer is headquartered. Compliance is mandatory: non-compliant products cannot legally be placed on the EU market after the deadline, and penalties can reach €15 million or 2.5 % of global annual turnover. Key intermediate deadlines include 11 September 2026 (manufacturers must report actively exploited vulnerabilities and severe incidents to ENISA within 24 hours) and 11 June 2026 (conformity assessment body framework becomes operational). Products already on the market before 11 December 2027 are exempt from the full requirements unless they undergo a “substantial modification,” but they are subject to the vulnerability reporting obligation from September 2026 onward.
