Le Site de François

The Cyclades

Sat, 27 Jun 2026 00:00:00 +0000

Fifteen days across Santorini, Folegandros, Sifnos and Milos — flights via Athens, Seajets ferries and an island-hopping road trip.

Craft Beer

Sat, 16 May 2026 00:00:00 +0000

The craft breweries I have discovered, sorted by country.

Theatres in Paris

Fri, 15 May 2026 00:00:00 +0000

A selection of Parisian theatres to discover.

Skip the Use

Fri, 24 Apr 2026 00:00:00 +0000

Skip the Use and the Love & Anxiety album — high-voltage rock from Lille.

Kid Kapichi

Fri, 16 Jan 2026 00:00:00 +0000

Kid Kapichi — razor-sharp British punk from Hastings, blending social rage with raw introspection.

Cooking Recipes

Sat, 01 Nov 2025 00:00:00 +0000

Here are some recipes we have already tried.

Bali & Java

Mon, 28 Jul 2025 00:00:00 +0000

Off to Indonesia for a 2-week trip between the Island of the Gods and the Island of Fire. On the agenda: volcano ascents, visits to majestic temples, discovering Hindu culture, walks and relaxation among the rice terraces… not forgetting the mie goreng and dardar gulung!

Kyoto

Sun, 22 Jun 2025 00:00:00 +0000

Less than 48 hours to visit one of the iconic cities of the Land of the Rising Sun…

Paris

Wed, 08 Jan 2025 00:00:00 +0000

Useful tips for visiting Paris.

Montréal & Ottawa

Sat, 26 Oct 2024 00:00:00 +0000

A city trip between two Canadian capitals: the cobblestone streets of Old Montréal, the train to Ottawa and Parliament Hill. Bonus: a giant spider and a UNESCO-listed canal.

Seoul

Sat, 01 Jun 2024 00:00:00 +0000

Less than 48 hours to visit Seoul, capital of the “Land of the Morning Calm”.

Sicily & the Aeolian Islands

Sun, 14 Apr 2024 00:00:00 +0000

19 days between Palermo, Scopello, Agrigento, Taormina, Lipari, Vulcano, Stromboli and Cefalù.

Minorca

Mon, 01 Apr 2024 00:00:00 +0000

A week-long stay in Minorca. Visit to Ciutadella, coastal hikes and discovering the island.

Shaka Ponk

Sun, 31 Mar 2024 00:00:00 +0000

The last Shaka Ponk concert at the Forest National arena.

Frank Carter & The Rattlesnakes

Fri, 29 Mar 2024 00:00:00 +0000

One of my favourite bands. A subtle blend of pure energy and sensitivity.

Speciality Coffee

Thu, 28 Mar 2024 00:00:00 +0000

Speciality coffee shops I have discovered, sorted by country.

Croatia

Tue, 26 Mar 2024 00:00:00 +0000

Exploring Croatia from Zadar down to Dubrovnik, kicking off at Plitvice Lakes. Short hops through the Kornati and Korčula, Ston’s walls, and Mljet National Park.

Jordan

Sun, 24 Mar 2024 00:00:00 +0000

Everyone kept telling us how great Jordan is, so we went to see for ourselves. On the itinerary: hikes in the wadis, historic sites, a night in the desert, diving and snorkelling…

Portugal

Sun, 10 Mar 2024 00:00:00 +0000

This year, our destination was Portugal. On the itinerary: Guimarães, Porto, the Douro Valley, Coimbra, Sintra, Lisbon, and the Rota Vicentina.

Dead Poet Society

Fri, 26 Jan 2024 00:00:00 +0000

Dead Poet Society — intense alternative rock from Los Angeles, blending sharp riffs with cathartic melodies. New album Monarch out October 2, 2026; European tour early 2027.

Barcelona

Sun, 05 Nov 2023 00:00:00 +0000

Craving a bit of blue sky at All Saints’ Day. Barcelona as the destination for a colourful city break. On the agenda: Sagrada Família, Palau de la Música Catalana, Recinte Modernista de Sant Pau, not to mention traditional tapas.

New York & Boston

Sun, 05 Nov 2023 00:00:00 +0000

A weekend discovering the Big Apple and a week in Boston

Planning Outings

Sun, 03 Sep 2023 00:00:00 +0000

Bookings, theatres and concerts in Belgium, Lille and Paris.

Sardinia

Fri, 18 Aug 2023 00:00:00 +0000

After going back and forth between lots of destinations for ages, we finally decided to set our course for Sardinia. On the agenda: hikes, kayaking, nuragic sites, beaches and coves with crystal-clear water, dolphin watching…

When it rains...

Sun, 01 Jan 2023 00:00:00 +0000

Activity ideas for rainy days.

Aqualibi

Sun, 17 Mar 2019 00:00:00 +0000

Aqualibi, the water park.

Shaka Ponk

Fri, 01 Mar 2019 00:00:00 +0000

An exceptional concert at La Cigale.

Puglia

Mon, 30 Jul 2018 00:00:00 +0000

This year we decided to explore southern Italy, starting from the buzzing city of Naples. On the agenda: pizza, Vespas, historic sights, a national park, beaches, gelato—in short, a packed schedule that was pure pleasure.

Il Mezzogiorno

Tue, 19 Jun 2018 00:00:00 +0000

Lovely Italian restaurant in Ghent, located a stone’s throw from the Vrijdagsmarkt.

Portfolio

Tue, 19 Jun 2018 00:00:00 +0000

A unique menu to discover the chef’s creations. A festival of flavours with every dish.

3GPP SCAS

Mon, 01 Jan 0001 00:00:00 +0000

3GPP Security Assurance Specifications (SCAS) are technical specifications developed by 3GPP’s SA3 working group (Security) that define security requirements and associated test cases for specific network product classes — each 3GPP-defined network function (AMF, SMF, UPF, gNB, MME, etc.) has its own SCAS document. 3GPP is the international standards body responsible for mobile telecommunications standards (comprising seven organizational partners covering Europe, US, China, Japan, Korea, India), making SCAS a globally recognized specification set rather than a national or regional scheme. Each SCAS document follows a structured approach: it identifies the assets of the network product class that require protection, performs a threat analysis describing how those assets can be exploited, defines security requirements (objectives) that mitigate the identified threats, and specifies concrete test cases to verify that a product implementation meets those requirements. SCAS specifications serve as the technical foundation for the GSMA NESAS scheme — when a vendor submits a network product for NESAS evaluation, accredited test laboratories evaluate it against the applicable SCAS test cases. Compliance is voluntary (there is no legal mandate to pass SCAS tests), but SCAS/NESAS evaluation results are increasingly used as a procurement requirement by telecom operators and are referenced by the EU 5G Security Toolbox and national security assessments. The list of adopted SCAS documents is maintained by the GSMA in FS.63 and continues to expand as 3GPP defines new network functions.

5G Core (5GC)

Mon, 01 Jan 0001 00:00:00 +0000

The 5G Core (5GC) is the packet core network architecture defined by 3GPP from Release 15 onward as the control and user-plane backbone of standalone 5G deployments. It replaces the Evolved Packet Core (EPC) of 4G LTE not through incremental evolution but through a deliberate architectural break: where the EPC was built around monolithic, hardware-bound network functions interconnected by point-to-point interfaces, the 5GC is designed from the ground up around a Service-Based Architecture (SBA) — every network function exposes its capabilities as a set of services over a common HTTP/2 bus (the Service-Based Interface, SBI), and any authorised consumer NF can discover and invoke those services through the NRF (Network Repository Function) without bilateral peering agreements or proprietary protocols. This shift reflects two structural requirements of 5G that EPC could not satisfy: network slicing — the ability to run logically independent end-to-end networks (each with its own QoS, isolation, and lifecycle) on shared physical infrastructure — and cloud-native deployment, where NFs run as containerised microservices on commodity compute, can be horizontally scaled, and are managed by standard Kubernetes-compatible orchestration rather than vendor-specific element managers. The 5GC also enforces a hard separation between Control Plane (CP) and User Plane (UP) — the CUPS principle inherited from 3GPP Release 14 and fully operationalised here — so that the UPF (User Plane Function) handling packet forwarding, QoS enforcement, and traffic anchoring can be distributed to the edge independently of the control logic, enabling ultra-low-latency and MEC scenarios without redesigning the control plane. The architecture is access-agnostic: the same 5GC serves NR (New Radio), eLTE, Wi-Fi (untrusted/trusted non-3GPP access), and fixed-wireless access through a unified N2/N3 reference point toward the access network and a common UE context model in the AMF.

6G

Mon, 01 Jan 0001 00:00:00 +0000

6G denotes the next generation of mobile cellular systems, framed internationally as IMT-2030 by ITU-R and studied in 3GPP from Release 18 (5G Advanced) onward with dedicated 6G work items accelerating in Release 19–21. Commercial deployment is widely targeted for around 2030, following the typical decade-long cycle after 5G (IMT-2020). Unlike incremental 5G releases, 6G research programmes emphasise a native integration of AI/ML in the air interface and the core (not only as an overlay analytics function), Integrated Sensing and Communication (ISAC) — using radio resources jointly for connectivity and environment sensing — and exploration of sub-terahertz and advanced MIMO for extreme capacity and sensing resolution. Energy efficiency, ubiquitous coverage (including NTN/satellite as a first-class component), and trustworthy / resilient network operation are recurring design goals across regional initiatives (Europe’s Hexa-X / Hexa-X-II, Korea’s 6G R&D, Japan’s Beyond 5G, and industry forums such as Next G Alliance in North America).

AD (Active Directory)

Mon, 01 Jan 0001 00:00:00 +0000

Active Directory (AD) is Microsoft’s enterprise directory and identity platform, first released with Windows 2000 and now the dominant identity provider in enterprise environments worldwide. It combines four technologies into a single integrated system: LDAP as the directory access protocol for querying and modifying identity data; Kerberos 5 as the authentication protocol for issuing tickets that prove identity without transmitting passwords; DNS as the service location mechanism that clients use to discover domain controllers, Kerberos KDCs, and LDAP servers; and Group Policy as the configuration management system that pushes security settings, software installation, and policy enforcement to every joined machine. These four components are inseparable in practice: a Linux host joining an AD domain receives a Kerberos principal in AD’s KDC, a machine account object in the AD LDAP directory, a DNS record for its hostname, and (optionally) Group Policy Objects applied to it. The AD forest is the trust boundary: multiple domains can exist within a forest and all share a common schema, configuration, and Global Catalog, with transitive Kerberos trust between them.

AES (Advanced Encryption Standard)

Mon, 01 Jan 0001 00:00:00 +0000

AES (Advanced Encryption Standard), standardised as NIST FIPS 197 in 2001, is the symmetric block cipher that underlies virtually all data encryption in modern infrastructure. It was selected through a five-year open competition that evaluated 15 candidate algorithms; the winner, Rijndael (designed by Joan Daemen and Vincent Rijmen), became AES. A block cipher takes a fixed-size block of plaintext and a key and produces a fixed-size block of ciphertext — AES always operates on 128-bit (16-byte) blocks, regardless of key size. Three key lengths are standardised: AES-128 (128-bit key, 10 rounds), AES-192 (192-bit key, 12 rounds), and AES-256 (256-bit key, 14 rounds), providing 128, 192, and 256 bits of security respectively against classical attacks. AES-256 is the conservative choice for data with long confidentiality requirements and is mandated by CNSA 2.0 for national security systems; AES-128 is widely deployed in TLS and provides adequate security for most workloads. The internal structure — SubBytes, ShiftRows, MixColumns, AddRoundKey — is fully public and has withstood over two decades of cryptanalysis; the best known attacks against full-round AES are theoretical and computationally infeasible, requiring work far beyond brute force but not threatening practical security.

AI-RAN Alliance

Mon, 01 Jan 0001 00:00:00 +0000

The AI-RAN Alliance is a global industry consortium, launched at MWC Barcelona in February 2024 and governed by a Technical Steering Committee (TSC), whose mission is to accelerate the integration of artificial intelligence into Radio Access Networks and to define what an AI-native RAN looks like in practice for 5G Advanced and 6G. The alliance deliberately positions itself as neither a marketing organisation nor a demo factory: it pursues pioneering, pre-competitive work — reference architectures, blueprints, and credible benchmarking — without getting mired in formal standards processes or IP negotiations. Its work spans three complementary objectives — AI-for-RAN (using AI/ML to improve RAN performance and efficiency), AI-and-RAN (co-locating RAN and AI workloads on shared accelerated infrastructure), and AI-on-RAN (hosting tenant-facing AI applications at the network edge for differentiated, monetisable connectivity). Founding members include Ericsson, Nokia, NVIDIA, T-Mobile, SoftBank, Samsung, AWS, Microsoft, and Arm; membership grew from a handful at launch to 130+ organisations by MWC 2026, spanning operators, NEPs, hyperscalers, silicon vendors, universities, and government research bodies across more than 17 countries.

AIDE (Advanced Intrusion Detection Environment)

Mon, 01 Jan 0001 00:00:00 +0000

AIDE (Advanced Intrusion Detection Environment) is a host-based intrusion detection tool that implements file integrity monitoring (FIM): it builds a baseline database capturing cryptographic hashes and metadata for every file it is configured to watch, and on subsequent runs compares the live filesystem against that database, reporting anything that has been added, removed, or changed. Its security premise is detection after the fact: AIDE does not prevent modifications (that is the role of fapolicyd, SELinux, and IMA), but it provides a reliable, auditable record that modifications occurred, when a check was run, and which specific attributes changed. An attacker who compromises a system and modifies a binary, a configuration file, a cron job, or an SSH authorized_keys file will leave a fingerprint in the next AIDE check — provided the database has not also been compromised, which is the central operational concern the tool’s deployment model must address.

ANSSI SecNumCloud

Mon, 01 Jan 0001 00:00:00 +0000

SecNumCloud is a security qualification (“Visa de sécurité”) issued by ANSSI (Agence Nationale de la Sécurité des Systèmes d’Information), France’s national cybersecurity agency. Created in 2016 and currently in version 3.2 (published March 2022), it is the most demanding cloud security standard in France. SecNumCloud applies to cloud service providers offering IaaS, PaaS, SaaS, or CaaS (Container as a Service) and evaluates them against 354 requirements organized across 15 chapters (chapters 5–19) structured on ISO/IEC 27002:2013 Annex A (chapters 5–18: security policies, organization, HR security, asset management, access control, cryptography, physical security, operational security, communications security, system acquisition/development/maintenance, supplier relationships, incident management, business continuity, conformity) plus an additional chapter 19 with sovereignty-specific requirements (data localization, reversibility, and protection from extraterritorial law). The qualification is voluntary in principle — no law forces all cloud providers to obtain it — but it is effectively mandatory for providers serving French public administration, Opérateurs d’Importance Vitale (OIV), and entities handling sensitive government data, as French procurement policy (the “doctrine cloud de confiance”) requires the use of SecNumCloud-qualified providers. Version 3.2’s most significant addition is chapter 19.6, which mandates that qualified providers be headquartered in the EU, owned by European entities (individual non-EU shareholding ≤24 %, collective ≤39 %), and be immune from non-European extraterritorial legislation such as the US CLOUD Act or FISA. SecNumCloud is the model upon which France advocates for the “high+sovereignty” tier in the EU-wide EUCS scheme. Qualification is valid for 3 years with annual audits conducted by PASSI-accredited assessors.

AppArmor (Application Armor)

Mon, 01 Jan 0001 00:00:00 +0000

AppArmor (Application Armor) is a Mandatory Access Control (MAC) system implemented as a major LSM (Linux Security Module), developed originally by Immunix and now maintained by Canonical. It is the default MAC system on Ubuntu, Debian, and their derivatives, and the default container confinement mechanism for containerd and Docker on those distributions. Where SELinux assigns security labels to every object on the system and enforces policy based on label interactions, AppArmor takes a fundamentally different approach: it confines programs by filesystem path. A profile for nginx lists the specific file paths that nginx is allowed to read, write, and execute, the network operations it may perform, and the Linux capabilities it may use — anything not listed is denied. No relabelling of the filesystem is required and no extended attributes are set: AppArmor’s confinement decisions are made purely from the path of the file being accessed and the identity of the confined process. This path-based model makes AppArmor profiles far simpler to read, write, and audit than SELinux policy, and eliminates the mislabelled-file failure mode that is the most common SELinux operational problem.

Autonomous Networks

Mon, 01 Jan 0001 00:00:00 +0000

Autonomous Networks (AN) describe an operator evolution path toward networks that configure, optimise, secure, and heal themselves with minimal manual intervention — expressed as closed loops (sense → analyse → decide → act) spanning RAN, transport, core, and cloud infrastructure. The concept is not a single product but a maturity model: TM Forum defines Autonomous Networks Levels (ANL 0–5), from fully manual operation (L0) through assisted and partial automation (L1–L3) to high and full autonomy (L4–L5) where intent (business or service goals) is translated into technical policies and executed with human oversight only for exceptions. GSMA and major operators (e.g. TM Forum AN Leadership Council participants) align roadmaps on high autonomy by ~2027–2030 for selected domains (energy saving, fault recovery, capacity management) rather than overnight “lights-out” operations.

Bastion Host (Jump Server)

Mon, 01 Jan 0001 00:00:00 +0000

A bastion host (also called a jump server or jump host) is a hardened server placed at the boundary between a public network and a protected private network, through which all administrative access to internal systems must pass. Rather than exposing every server, database, or network device directly to the internet or to operator workstations, the network is designed so that only the bastion host has a publicly reachable address; internal systems accept SSH or RDP connections only from the bastion’s IP. An administrator who needs to reach an internal host connects first to the bastion — authenticating with a key, certificate, or MFA — and then hops onward to the target from there. The bastion’s narrow exposure makes it a concentrated target, which is why it receives disproportionate hardening: a minimal OS with only the necessary services running, strict firewall rules, aggressive patch cadence, and comprehensive session logging. The name comes from military fortification: a bastion is a protruding element of a castle wall designed to be defended at all costs.

bootc (Bootable Containers)

Mon, 01 Jan 0001 00:00:00 +0000

bootc is a CNCF sandbox project, created by Colin Walters, that applies the OCI container model to operating system delivery. Where conventional container images package an application to run inside a host OS, a bootc image packages the entire OS — kernel (under /usr/lib/modules), initrd, systemd units, firmware, and all userspace — as a standard OCI image that can be built with podman build or buildah, stored in any OCI-conformant registry, signed with standard supply chain tools, and pulled to a machine where it becomes the running system. At runtime the base OS is not running inside a container; systemd is pid 1 as usual. The container image format is purely a transport and build model, not an execution model.

Break-Glass User (Emergency Access Account)

Mon, 01 Jan 0001 00:00:00 +0000

A break-glass user (or break-glass account, emergency access account) is a privileged account that exists outside the normal access control workflow — bypassing PAM approval gates, MFA requirements, or SSO dependencies — and is reserved for situations where those normal mechanisms are themselves unavailable or would prevent responding to a critical incident in time. The name is a physical analogy: like the fire alarm panel behind a pane of glass that reads break glass in emergency, the account is designed so that accessing it requires a deliberate, detectable act. It is not a convenience mechanism; it is an organisational safety net for scenarios such as an identity provider outage locking all administrators out of their own infrastructure, a PAM platform failing during an active incident, or a ransomware attack disabling the tooling needed to contain it.

BSI C5

Mon, 01 Jan 0001 00:00:00 +0000

The BSI C5 (Cloud Computing Compliance Criteria Catalogue) is a German federal standard published by the BSI that defines minimum security requirements for cloud service providers. First released in 2016, the catalogue has undergone two major revisions: C5:2020 and the current C5:2026 (published 7 April 2026, replacing C5:2020). C5:2026 contains 168 criteria (up from 121 in C5:2020, a 39 % increase) structured across 17 domains aligned with ISO/IEC 27001 Annex A. The new version introduces a sub-criteria structure aligned with the European EUCS scheme, and adds five major new requirement areas: Confidential Computing (OPS-32/33: documented policies for Trusted Execution Environments and technical implementation of Remote Attestation), Container Management (OPS-34/35: lifecycle security for containerized workloads), Post-Quantum Cryptography (inventory of cryptographic assets and migration plan to quantum-resistant algorithms), AI transparency (disclosure of AI use in internal control systems), and Supply Chain Security (SBOM requirements, documented sub-processor audits). The catalogue is published in machine-readable YAML format for the first time. C5 is designed as an attestation standard (not a certification): providers undergo a Type 2 audit by an independent auditing firm (under IDW PS 880 or ISAE 3000), which verifies both the design and operational effectiveness of security controls over a period of at least six months. C5 is now effectively mandatory in two key domains: since 1 July 2025, cloud providers processing healthcare data must hold a valid C5 Type 2 attestation under §393 SGB V (Social Code, Fifth Book), and the revised BSI-KritisV (2024) requires KRITIS operators to use C5-attested cloud services in security-relevant contexts. Public-sector procurement in Germany also increasingly demands C5 attestation. C5:2026 becomes mandatory on 1 June 2027 for all audit periods starting on or after that date. During the transition: C5:2020 audits remain valid without additional requirements until 28 February 2027; between 28 February and 31 May 2027, C5:2020 is still permitted but requires a transition roadmap to C5:2026 in the system description.

BSI IT-Grundschutz

Mon, 01 Jan 0001 00:00:00 +0000

BSI IT-Grundschutz is Germany’s national framework for establishing, implementing, and certifying an Information Security Management System (ISMS). It is developed and maintained by the BSI (Bundesamt für Sicherheit in der Informationstechnik) and stands out from generic standards like ISO/IEC 27001 by its extreme level of prescriptive detail — the IT-Grundschutz Compendium contains hundreds of specific security building blocks (“Bausteine”) covering technical, organizational, infrastructure, and personnel aspects. The framework is defined across four BSI Standards: 200-1 (ISMS requirements), 200-2 (methodology with three approaches: Basis-Absicherung, Standard-Absicherung, Kern-Absicherung), 200-3 (risk analysis), and 200-4 (business continuity management). Organizations can pursue ISO 27001 certification based on IT-Grundschutz, which is recognized as equivalent to standalone ISO 27001 but with the added rigor of the BSI’s detailed control catalog. Compliance is mandatory for German federal agencies (Bundesbehörden) under the UP Bund framework and is strongly recommended — often contractually required — for KRITIS operators and public-sector contractors. A major modernization is underway: Grundschutz++, introduced in 2025–2026, replaces the traditional PDF-based building blocks with OSCAL/JSON machine-readable catalogs, aligning with the NIS2 implementation requirement for a BSI-defined “state of the art.” The classic IT-Grundschutz remains valid for audits until end of 2028.

cert-manager

Mon, 01 Jan 0001 00:00:00 +0000

cert-manager is a CNCF graduated project that brings PKI lifecycle management into Kubernetes as a first-class controller, eliminating the manual processes — CSR generation, CA submission, secret rotation, renewal tracking — that cause certificate-related outages in clusters that manage TLS manually. Its premise is that X.509 certificates should be declared as Kubernetes resources with the same GitOps-friendly, reconciliation-driven lifecycle as any other workload configuration: an operator declares the desired certificate, cert-manager continuously ensures that a valid, non-expired certificate matching that declaration exists and is stored in a Kubernetes Secret, and renews it automatically before expiry. The default renewal threshold is two-thirds of the certificate’s validity period, so a certificate with a 90-day lifetime is renewed at 60 days without operator intervention.

cgroups (Control Groups) v2

Mon, 01 Jan 0001 00:00:00 +0000

Control Groups (cgroups) is a Linux kernel mechanism, introduced in 2.6.24 (2008), that organises processes into a hierarchy of named groups and uses controllers to account for and limit each group’s consumption of CPU time, memory, I/O bandwidth, and process count. Every container runtime in existence — Docker, containerd, CRI-O, Podman — uses cgroups to enforce the resource limits declared in a container spec (--memory, --cpus, requests.memory, limits.cpu). Every systemd service on a modern Linux system runs in its own cgroup slice. Without cgroups, a container or service could consume all available memory, CPU, or file descriptors, starving other workloads on the same host. The current production version is cgroups v2 (also written cgroupv2, unified hierarchy), stable since kernel 4.5 and the default on all major distributions since RHEL 9, Ubuntu 21.10, and Fedora 31.

CIS Benchmarks

Mon, 01 Jan 0001 00:00:00 +0000

CIS Benchmarks are detailed, prescriptive security configuration guidelines published by the Center for Internet Security (CIS), a US-based non-profit organization. They are developed through a consensus process involving cybersecurity practitioners, vendors, and government agencies, and cover over 100 technology families — operating systems (Linux, Windows, macOS), cloud platforms (AWS, Azure, GCP), container orchestrators (Kubernetes, Docker), databases, web servers, and network devices. CIS Benchmarks are international in applicability — they are not tied to any single jurisdiction — and are referenced by regulatory frameworks worldwide (NIST, PCI-DSS, HIPAA, FedRAMP, NIS2 national implementations). Each benchmark provides two recommendation levels: Level 1 (practical hardening that does not significantly impact functionality) and Level 2 (defense-in-depth settings for high-security environments). CIS Benchmarks are voluntary — no law mandates CIS compliance directly — but they are frequently required by procurement contracts, industry standards, and as evidence of “reasonable security measures” in regulatory audits. The CIS also offers CIS Controls (formerly the SANS Top 20), a prioritized set of cybersecurity best practices, and the CIS Hardened Images program for pre-configured virtual machine images.

composefs

Mon, 01 Jan 0001 00:00:00 +0000

composefs is a Linux filesystem technology created by Alexander Larsson and Giuseppe Scrivano at Red Hat that provides cryptographically verified, read-only filesystem trees with opportunistic file-level sharing across images. Its motivating problem is a gap that neither dm-verity nor plain overlayfs fills cleanly: dm-verity provides strong integrity over a whole block device but requires a self-contained disk image and cannot share files between images; overlayfs allows layered, shared filesystems but protects only file contents (via fs-verity) and not the directory structure or metadata — an attacker who can manipulate a file’s name, permissions, or position in the tree is not caught. composefs closes that gap by separately protecting content and metadata, then composing them at mount time.

Confidential Cluster

Mon, 01 Jan 0001 00:00:00 +0000

A Confidential Cluster is a Kubernetes cluster designed so that the cloud or infrastructure operator — including hypervisor administrators, datacenter staff, and anyone who can access the underlying hardware — is entirely outside the trusted computing base. It achieves this by running every Kubernetes node, including control plane nodes, as a Confidential VM, and by extending the confidential boundary to cover not just individual workloads but the cluster’s network traffic, persistent storage, and control plane state. The goal is that a workload owner can cryptographically verify the entire cluster before trusting it, and that no privileged party outside the cluster’s own CVMs can read or tamper with workload data, cluster secrets, or etcd contents.

Confidential Containers (CoCo)

Mon, 01 Jan 0001 00:00:00 +0000

Confidential Containers (CoCo) is a CNCF sandbox project that lifts hardware confidential computing — TDX, SEV-SNP, Intel SGX, IBM Secure Execution — up to the Kubernetes pod level, providing a unified software layer that abstracts away the underlying TEE technology. Its defining trust model is unusually strict: the Kubernetes control plane, the kubelet, the container runtime, and the cloud operator are all treated as explicitly untrusted. Only the hardware itself and the workload owner’s own supply chain are in scope for trust.

Confidential GPU

Mon, 01 Jan 0001 00:00:00 +0000

A Confidential GPU is a GPU whose memory, computation state, and data transfers are hardware-encrypted and isolated from the host system — extending the Trusted Execution Environment (TEE) boundary that technologies like TDX and SEV-SNP provide at the CPU level to encompass the GPU accelerator as well. The primary implementation today is NVIDIA Confidential Computing on the Hopper architecture (H100 and later), which encrypts all data resident in GPU High Bandwidth Memory (HBM) using per-context keys managed by the GPU’s on-die security processor. This means that model weights, training data, activations, and intermediate computations are cryptographically protected throughout GPU processing — a host administrator, hypervisor, or co-tenant with DMA access to the PCIe bus sees only ciphertext. The GPU also participates in a dedicated attestation flow: the NVIDIA Remote Attestation Service (NRAS) produces signed evidence that a specific GPU is genuine NVIDIA hardware running in Confidential Computing mode with unmodified firmware, analogous to how Intel DCAP or AMD KDS attest CPU TEEs. This GPU attestation is verified alongside CPU attestation before secrets (model decryption keys, dataset credentials) are released to the combined CPU+GPU TEE. The technology requires no application code changes — existing TensorFlow, PyTorch, and CUDA workloads run unmodified inside the confidential boundary. The primary threat model is the same as CPU-level confidential computing (protecting data-in-use from the infrastructure operator) but applied to the specific risk of AI workloads: model intellectual property theft, training data exfiltration, and inference input/output interception during GPU computation.

Confidential VM (CVM)

Mon, 01 Jan 0001 00:00:00 +0000

A Confidential VM (CVM) is a virtual machine in which the guest’s memory contents, CPU register state, and execution flow are hardware-encrypted and isolated from everything outside it: the hypervisor, the host operating system, the cloud operator, other tenants, and anyone with physical access to the machine. The isolation is enforced not by software policy but by the CPU itself, using TEE technology — Intel TDX, AMD SEV-SNP, or Arm CCA — so that no amount of privilege on the host side grants access to the guest’s private state. A CVM is the VM-granularity equivalent of what SGX enclaves provide at the process level: the key difference is that a CVM requires no application changes, making it the practical path for lifting existing workloads into a confidential computing environment.

Context window

Mon, 01 Jan 0001 00:00:00 +0000

The context window is the maximum span of tokens—input prompt plus model-generated output—that an LLM can process in a single forward pass chain without truncating or sliding attention. It is set by model architecture (positional encoding limit, e.g. 8K, 128K, 1M+ in newer models) and by practical VRAM on the serving GPU, because the KV cache scales with total sequence length. Its objective is to bound memory and compute: longer windows enable whole documents, multi-turn chat history, and large RAG payloads in one shot, but cost more on every prefill and decode step. APIs expose this as max_tokens, context limits, or model cards; exceeding it yields errors or silent truncation.

CRL (Certificate Revocation List)

Mon, 01 Jan 0001 00:00:00 +0000

A Certificate Revocation List (CRL) is a signed data structure, published by a Certificate Authority as part of its PKI operations, that lists the serial numbers of X.509 certificates the CA has revoked before their scheduled expiry date. A CA revokes a certificate when its private key is compromised, the subject’s identity information changes, the certificate was mis-issued, or the subject is no longer authorised. Without revocation, a compromised certificate remains trusted by all verifiers until it expires — which for long-lived CA and infrastructure certificates can be years. The CRL is the oldest revocation mechanism, defined in RFC 5280 alongside the X.509 v3 certificate format, and remains widely deployed for CA certificates, code signing certificates, and client certificates in contexts where OCSP is impractical.

CUDA (Compute Unified Device Architecture)

Mon, 01 Jan 0001 00:00:00 +0000

CUDA (Compute Unified Device Architecture) is NVIDIA’s software platform for general-purpose computing on GPUs. Its objective is to give developers a familiar C/C++ (and Fortran, Python bindings) programming model with explicit control over kernels (functions that run on the device), streams (ordered queues of work), and memory spaces (host, device, unified). CUDA sits above the GPU driver and below frameworks such as cuDNN, NCCL, and higher-level ML stacks; it is the layer that makes it practical to implement custom operators, HPC solvers, and inference engines that are not covered by a closed library. For AI, virtually every major training and inference stack ultimately depends on CUDA (or a CUDA-compatible runtime) on NVIDIA hardware.

cuDNN (CUDA Deep Neural Network library)

Mon, 01 Jan 0001 00:00:00 +0000

cuDNN (CUDA Deep Neural Network library) is NVIDIA’s library of highly optimized GPU kernels for operations that dominate deep learning: convolutions, matrix multiplies used in attention, pooling, normalization (batch/layer), activations, and recurrent cells. Its objective is to deliver near-peak performance on CUDA-capable GPUs without every framework author hand-writing assembly-tuned kernels. PyTorch, TensorFlow, and many inference engines call cuDNN (directly or via cuBLAS) under the hood for training and serving. cuDNN sits between raw CUDA and application code; version alignment with the CUDA toolkit and driver is mandatory for supported deployments.

CVSS (Common Vulnerability Scoring System)

Mon, 01 Jan 0001 00:00:00 +0000

CVSS (Common Vulnerability Scoring System) is an open framework published by FIRST (Forum of Incident Response and Security Teams) for characterising and communicating the technical severity of software vulnerabilities through a standardised numerical score. The current version is CVSS v4.0 (released November 2023), which introduced a fourth metric group and clarified nomenclature to address the persistent misuse of CVSS Base scores as standalone risk measurements. CVSS scores appear in the NVD (National Vulnerability Database), CVE entries, scanner output from Qualys, Tenable, Rapid7, Grype, and Trivy, and in compliance frameworks that specify remediation SLAs based on severity bands — “critical (9.0–10.0) within 15 days, high (7.0–8.9) within 30 days.” The score ranges from 0.0 (no impact) to 10.0 (maximum severity) and maps to five qualitative ratings: None (0.0), Low (0.1–3.9), Medium (4.0–6.9), High (7.0–8.9), and Critical (9.0–10.0).

Decode

Mon, 01 Jan 0001 00:00:00 +0000

Decode is the second stage of LLM inference: after prefill has stored keys and values for the prompt, the model generates one new token per forward pass, appends it to the sequence, extends the KV cache, and repeats until a stop condition (EOS token, max length, or API limit). Its objective is fluent continuation—answer text, code, or tool-call JSON—at acceptable inter-token latency and cluster throughput (tokens per second across many concurrent sessions). Decode drives the “typing” experience in chat UIs; prefill drives how long users wait before the first character appears.

Diffie-Hellman (DH / ECDH / X25519)

Mon, 01 Jan 0001 00:00:00 +0000

Diffie-Hellman (DH) is a key exchange protocol published by Whitfield Diffie and Martin Hellman in 1976 — the first public description of asymmetric cryptography and one of the most consequential cryptographic publications in history. Its fundamental contribution is solving the key establishment problem: two parties who have never communicated before, communicating over a channel that an adversary can fully observe, can nonetheless agree on a shared secret that the adversary cannot determine. The security of finite-field DH rests on the discrete logarithm problem: given g^a mod p and g^b mod p (the public values exchanged), computing g^ab mod p (the shared secret) requires solving for either a or b, which is computationally infeasible for sufficiently large groups. The 1976 original uses multiplicative groups of integers modulo a prime p; the security level is determined by the size of p (currently 2048-bit minimum, 3072-bit recommended) and the group’s structure. Finite-field DH is still deployed in TLS 1.2 DHE cipher suites and legacy IPsec configurations, but has been supplanted in new deployments by Elliptic Curve Diffie-Hellman (ECDH) and specifically by X25519, which provide equivalent security at dramatically smaller key sizes.

DISA STIG

Mon, 01 Jan 0001 00:00:00 +0000

DISA STIGs (Security Technical Implementation Guides) are published by the Defense Information Systems Agency (DISA), the US Department of Defense (DoD) agency responsible for IT infrastructure security standards. STIGs provide extremely prescriptive, line-item security configuration requirements for specific technology products — each STIG contains hundreds of individual “findings” (rules) specifying exact settings, permissions, and configurations required to harden a system. Unlike flexible frameworks (NIST 800-53) or guideline-oriented benchmarks (CIS), STIGs are mandatory for all DoD information systems and are referenced by the broader US federal government, defense contractors (via CMMC), and intelligence community systems. Each finding is categorized by severity: CAT I (high — failure could directly lead to loss of confidentiality, integrity, or availability), CAT II (medium), and CAT III (low). Systems must achieve full CAT I compliance and substantially address CAT II/III findings to receive an Authority to Operate (ATO). DISA publishes STIGs for hundreds of products and regularly updates them (typically quarterly). STIGs are developed in collaboration with the vendor — Red Hat, for instance, works directly with DISA to produce the RHEL STIG — and are made available to the public through DoD Cyber Exchange (public.cyber.mil). STIG compliance is verified using DISA’s STIG Viewer or automated tools like OpenSCAP that consume the machine-readable XCCDF/SCAP content.

dm-verity

Mon, 01 Jan 0001 00:00:00 +0000

dm-verity is a Linux device mapper target, available since kernel 3.4, that provides transparent read-only integrity verification for block devices. When a block device is mapped through dm-verity, every data block read from the underlying device is verified against a pre-computed Merkle tree of cryptographic hashes before being returned to the caller — any modification to any block, whether from corruption, bit rot, or deliberate tampering, produces a hash mismatch that dm-verity detects and handles according to its configured error mode. The verification is transparent to the filesystem and applications mounted above it: they read from the dm-verity device as if it were a normal block device, with no awareness that every read is being hash-checked. The security guarantee is that the integrity of the entire block device is committed to by a single root hash — a 32-byte SHA-256 value that covers the entire Merkle tree and therefore the entire data volume. If the root hash is known to be correct (because it was measured into a TPM PCR, embedded in a UKI, or signed by a Secure Boot key), then any verified read from the dm-verity device is guaranteed to return exactly the data that was present when the Merkle tree was computed.

DOCA (Data Center Infrastructure on a Chip Architecture)

Mon, 01 Jan 0001 00:00:00 +0000

DOCA (Data Center Infrastructure on a Chip Architecture) is NVIDIA’s software framework for building and operating services on BlueField DPUs. Its objective is to standardize how operators and ISVs develop infrastructure applications—OVS offload, firewall/VNF, storage targets, RDMA/RoCE control, TLS inspection, telemetry agents—on Arm cores and hardware accelerators embedded in the NIC, using a consistent set of libraries instead of ad hoc kernel modules on the host. DOCA spans drivers, userspace APIs, reference pipelines, and marketplace-packaged applications; it is the DPU counterpart to CUDA on GPUs, oriented toward I/O and packet processing rather than tensor math.

DPDK

Mon, 01 Jan 0001 00:00:00 +0000

The Data Plane Development Kit (DPDK) is an open-source set of libraries and poll-mode drivers (PMDs) that move packet processing from the kernel to userspace, enabling telco and cloud applications to achieve millions of packets per second per core with predictable latency. DPDK bypasses the traditional socket stack: applications busy-poll NIC queues (or virtio/vhost rings), use hugepages to reduce TLB misses, and pin threads to NUMA-local cores — a model suited to UPF, vRouter, CG-NAT, load balancers, and 5G user-plane functions where per-packet syscall overhead is unacceptable.

DPU (Data Processing Unit)

Mon, 01 Jan 0001 00:00:00 +0000

A DPU (Data Processing Unit)—also marketed as an infrastructure processing unit or SmartNIC—is a programmable accelerator placed on the network path between servers and the fabric. Its objective is to offload infrastructure work that would otherwise consume host CPU cycles and pollute caches: virtual switching (OVS), overlay encapsulation (VXLAN/Geneve), storage initiation (NVMe-oF), firewalling, TLS termination, telemetry export, and increasingly zero-trust policy enforcement. In AI clusters, DPUs help preserve GPU servers for model compute by moving east-west networking, storage, and security functions to the NIC. A DPU is not a replacement for a training GPU; it complements it by making the surrounding data-center network and storage stack more efficient and isolatable.

E-ITS / ISKE (Estonian Information Security Standard)

Mon, 01 Jan 0001 00:00:00 +0000

E-ITS (Eesti infoturbestandard — Estonian Information Security Standard) is Estonia’s national information security framework, developed and maintained by the RIA (Riigi Infosüsteemi Amet — Information System Authority). It replaced the previous ISKE (Infosüsteemide kolmeastmeline etalonturbe süsteem) system, which was in effect until 31 December 2022. E-ITS entered into force in December 2022 and is mandatory for all organizations performing public duties in Estonia — state agencies, local governments, and any entity operating information systems essential for the functioning of society. Private organizations may also voluntarily adopt E-ITS to achieve their information security goals. The standard is based on the German BSI IT-Grundschutz baseline protection methodology and is designed to be fully compatible with ISO/IEC 27001 — an audited E-ITS conformity allows organizations to demonstrate compliance equivalent to the international standard. E-ITS presents a baseline protection catalog containing security modules with specific measures, organized by asset type (IT systems, networks, applications, industrial automation, vehicles, etc.). Organizations must identify their assets, determine protection needs, apply the corresponding baseline measures, and undergo periodic audits. Alternatively, organizations may satisfy their obligation by holding a valid ISO/IEC 27001 certificate and submitting it to RIA. The standard is updated annually each autumn to reflect new threats and technological developments, and RIA provides a free support application (based on the 2024 version) to guide implementers through the process.

eBPF (Extended Berkeley Packet Filter)

Mon, 01 Jan 0001 00:00:00 +0000

eBPF (Extended Berkeley Packet Filter) is a Linux kernel subsystem, its modern form dating to kernel 3.18 (2014), that allows user-authored programs to run inside the kernel with near-native performance, subject to safety guarantees enforced at load time by a verifier. The name is historical: the original BPF (Berkeley Packet Filter, 1992) was a narrow packet filtering mechanism for tools like tcpdump. eBPF extended the instruction set, registers, and capabilities far beyond packet filtering into a general-purpose in-kernel programmability platform. The central design constraint is that eBPF programs must be provably safe: they cannot crash the kernel, loop infinitely, or access memory out of bounds. The verifier statically analyses every program at load time, checking that all memory accesses are bounds-checked, all loops are bounded or unrolled, and all pointer dereferences are preceded by null checks. Only programs that pass verification are accepted; once accepted, the kernel JIT-compiles the eBPF bytecode to native machine code for the host architecture — x86-64, ARM64, RISC-V — so eBPF programs run at the same speed as compiled kernel code, not as an interpreter.

ECC (Elliptic Curve Cryptography)

Mon, 01 Jan 0001 00:00:00 +0000

Elliptic Curve Cryptography (ECC) is a family of public-key cryptographic algorithms built on the mathematics of elliptic curves over finite fields. Its security rests on the Elliptic Curve Discrete Logarithm Problem (ECDLP): given a public point Q = k × G on a curve (where G is a fixed base point and k is the private key scalar), recovering k from Q and G is computationally infeasible on classical computers. The practical advantage over RSA is dramatic key size efficiency: a 256-bit ECC key provides roughly the same classical security as a 3072-bit RSA key, because the best known classical algorithms for ECDLP (Pollard’s rho) are exponential whereas the best RSA algorithms (GNFS) are sub-exponential. This size difference has compounding benefits — smaller keys mean faster operations, smaller certificates, smaller TLS handshake messages, and lower power consumption on constrained devices. ECC is now the dominant choice for all new asymmetric cryptography deployments: TLS 1.3 mandates ECDHE for key exchange, and ECDSA or EdDSA for authentication; SSH defaults to Ed25519; code signing infrastructure increasingly uses ECDSA P-256 or Ed25519.

ECDSA (Elliptic Curve Digital Signature Algorithm)

Mon, 01 Jan 0001 00:00:00 +0000

ECDSA (Elliptic Curve Digital Signature Algorithm) is the elliptic curve analogue of DSA, standardised in FIPS 186 and the IETF, that produces digital signatures using a private key and verifies them with the corresponding public key. It is the most widely deployed signature algorithm in X.509 certificates (P-256 with SHA-256 is the default for certificate authorities issuing TLS certificates), in code signing (Authenticode, macOS, Linux package signing), in TLS 1.3 certificate authentication, in SSH host keys and user keys (though Ed25519 is increasingly preferred), and in blockchain and cryptocurrency systems. An ECDSA signature over a message m with private key d on curve with base point G produces a pair (r, s), where r is the x-coordinate of an ephemeral public key k × G and s encodes the relationship between the message hash, r, the private key d, and the nonce k. Verification requires only the public key Q = d × G and is fast; signing requires the private key and a nonce.

Edge Computing

Mon, 01 Jan 0001 00:00:00 +0000

Edge computing in telecommunications places compute, storage, and application execution close to users and devices — at cell sites, regional points of presence, or on-prem enterprise locations — rather than only in distant hyperscale data centres. The goal is to reduce end-to-end latency, limit backhaul load, satisfy data residency, and enable real-time applications (AR/VR, industrial control, V2X, video analytics) that are impractical with 50–100 ms round trips to central clouds. In 5G, edge is tightly coupled to the user plane: a local UPF on N6 breakout forwards traffic to an edge data network (DN) hosting MEC applications without hairpinning through the operator’s core hub.

ENS (Esquema Nacional de Seguridad)

Mon, 01 Jan 0001 00:00:00 +0000

The Esquema Nacional de Seguridad (ENS) is Spain’s national security framework, currently governed by Royal Decree 311/2022 (effective May 2022, with a transition period that ended April 2024). It is a mandatory regulatory requirement — not a voluntary standard — enforced by Spain’s CCN (Centro Criptológico Nacional, part of the CNI intelligence service) and applies to all Spanish public administrations (central, regional, local), as well as private-sector organizations that provide technology services or process data on behalf of the public sector. The ENS defines basic security principles, 16 minimum requirements (covering risk management, access control, incident handling, continuity, personnel security, etc.), and 73 security measures organized in three groups: organizational framework (4 measures), operational framework (31 measures), and protection measures (38 measures). Systems are classified into three categories — Basic, Medium, and High — based on the potential impact of a security incident on each security dimension (confidentiality, integrity, availability, authenticity, traceability). Each category level triggers progressively stricter “reinforcement” requirements for the applicable measures. Organizations with Medium or High systems must obtain formal certification every two years through an ENAC-accredited auditor, while Basic systems require a self-assessment declaration. The ENS is aligned with ISO/IEC 27001 and is being updated to incorporate NIS2 Directive requirements as Spain transposes the directive through its draft Cybersecurity Coordination and Governance Law (approved by the Council of Ministers in January 2025).

ESO (External Secrets Operator)

Mon, 01 Jan 0001 00:00:00 +0000

External Secrets Operator (ESO) is a CNCF incubating project that bridges the gap between Kubernetes-native secrets and enterprise secret management backends. Its premise is that native Kubernetes Secrets — base64-encoded values stored in etcd — are not adequate as a primary secret store: they offer no encryption at rest by default, no access audit trail, no versioning or rotation lifecycle, and no single source of truth across multiple clusters. Rather than replacing Kubernetes Secrets as a consumption mechanism (applications still mount them as environment variables or files in the familiar way), ESO replaces etcd as their source of authority, pulling the real values from a backend that does provide those properties and keeping the Kubernetes Secret as a synchronised, ephemeral projection.

EU Cloud Services Scheme (EUCS)

Mon, 01 Jan 0001 00:00:00 +0000

The European Cybersecurity Certification Scheme for Cloud Services (EUCS) is a certification framework being developed under the 2019 EU Cybersecurity Act (CSA), led by ENISA. It is not yet adopted — the scheme has been in drafting since 2020 and remains stalled as of mid-2026 due to unresolved political disagreements over digital sovereignty requirements. EUCS is designed as an EU-wide, voluntary certification that would harmonize the fragmented national cloud certifications (such as France’s SecNumCloud or Germany’s C5) into three assurance levels: basic, substantial, and high. It applies to cloud service providers offering IaaS, PaaS, or SaaS on the European market. While EUCS is technically voluntary, its practical impact will be significant because the NIS2 Directive allows Member States to require entities in essential and important sectors to use only EUCS-certified cloud services. The core political controversy centers on whether the “high” assurance level should include sovereignty requirements — mandating EU headquarters, EU-only data processing, and immunity from non-EU extraterritorial laws (e.g. the US CLOUD Act). A March 2024 draft removed these requirements to achieve technical consensus, but the proposed recast of the Cybersecurity Act (CSA2), tabled in January 2026, would reinstate a formal sovereignty tier, with France leading advocacy for its inclusion.

EU Cyber Resilience Act (CRA)

Mon, 01 Jan 0001 00:00:00 +0000

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.

EU Cybersecurity Act (CSA)

Mon, 01 Jan 0001 00:00:00 +0000

The EU Cybersecurity Act (CSA) — Regulation (EU) 2019/881 — was adopted by the European Council in April 2019 and fully entered into force on 28 June 2021. It is a European regulation (directly applicable in all Member States without transposition) that serves two primary functions: it strengthened and made permanent the mandate of ENISA (the EU Agency for Cybersecurity), and it established a voluntary EU-wide cybersecurity certification framework for ICT products, services, and processes. The CSA is not itself a certification scheme but rather the legal foundation upon which specific schemes are built — currently EUCC (adopted January 2024), EUCS (cloud, under development), EU5G (5G networks, under development), EUDI Wallets, and EUMSS (managed security services). Each scheme defines assurance levels (basic, substantial, high), evaluation methodologies, and mutual recognition rules so that a certificate issued in one Member State is valid across the entire EU. The CSA applies to any entity — manufacturer, service provider, or operator — that voluntarily seeks EU cybersecurity certification for its offerings, though sector-specific regulations (NIS2, CRA, DORA) may make certification effectively mandatory for certain use cases. A recast of the CSA (CSA2) was proposed by the European Commission on 20 January 2026, aiming to strengthen certification mandates, reinstate sovereignty requirements in cloud certification, and reinforce ENISA’s supervisory role.

EU5G Certification Scheme

Mon, 01 Jan 0001 00:00:00 +0000

The EU5G cybersecurity certification scheme is a certification framework being developed under the EU Cybersecurity Act (Regulation 2019/881), intended to provide harmonized security assurance for 5G network products and components across the European Union. ENISA established an Ad Hoc Working Group (AHWG) on EU5G in Q4 2021 following a European Commission request. As of mid-2026, the scheme has not been formally adopted and no complete public draft is available — making it the least mature of the three schemes requested under the CSA (after EUCC, adopted in January 2024, and EUCS, still stalled). Current work has focused on specific components: in June 2024, ENISA launched a public consultation on technical specifications for eUICC (embedded Universal Integrated Circuit Card) certification, which will be handled under the existing EUCC framework rather than a new standalone scheme. A broader EU NESAS scheme for 5G network products is under development, leveraging the existing GSMA NESAS/3GPP SCAS methodology. The scheme is expected to be voluntary once adopted, with assurance levels aligned to the CSA’s basic/substantial/high structure. Its practical significance will be shaped by the revised Cybersecurity Act (CSA2), proposed in January 2026, which strengthens ENISA’s mandate and may provide additional impetus for adoption.

EUCC (EU Common Criteria)

Mon, 01 Jan 0001 00:00:00 +0000

The European Common Criteria-based cybersecurity certification scheme (EUCC) is the first certification scheme formally adopted under the EU Cybersecurity Act (Regulation 2019/881). The European Commission published the implementing regulation on 31 January 2024, and an amendment (Regulation 2024/3144) followed in December 2024 to clarify applicable ISO/IEC 15408 standard versions and transition rules. EUCC is managed by ENISA and builds on the existing SOG-IS Mutual Recognition Agreement that was already used by 17 EU Member States, effectively replacing those national Common Criteria schemes with a single EU-wide framework. It applies to ICT products — hardware, software, and embedded components — and evaluates their cybersecurity properties through accredited Conformity Assessment Bodies (CABs). The scheme offers two assurance levels: “substantial” (based on AVA_VAN levels 1–2) and “high” (AVA_VAN levels 3–5). Certification is voluntary — there is no legal obligation to certify ICT products under EUCC — but it provides market-recognized evidence of security properties and is expected to be referenced by procurement requirements and sector-specific legislation (e.g. medical devices, smart metering). EUCC certificates are recognized uniformly across the entire EU, eliminating the need for country-by-country certification.

fapolicyd (File Access Policy Daemon)

Mon, 01 Jan 0001 00:00:00 +0000

fapolicyd (File Access Policy Daemon) is an application allowlisting framework for Linux, developed by Red Hat and shipped as a supported component of RHEL 8+. Its security premise is supply-chain integrity at the execution layer: only software that was installed through a trusted package manager (DNF/RPM) or explicitly declared as trusted by an administrator may execute on the system. An attacker who achieves a foothold and drops a new binary — a reverse shell, a lateral movement tool, a cryptominer — will find that binary blocked at execution time, because it is absent from the trust database, regardless of its Unix permissions or SELinux label. fapolicyd addresses a different dimension of access control than SELinux: SELinux models how applications behave (what resources they may access); fapolicyd models whether applications are trusted at all (whether they may execute in the first place). The two are complementary: SELinux confines a trusted application’s behaviour; fapolicyd prevents untrusted applications from running.

FedRAMP

Mon, 01 Jan 0001 00:00:00 +0000

The Federal Risk and Authorization Management Program (FedRAMP) is a US government-wide program, codified into law by the FedRAMP Authorization Act of 2022, that provides a standardized approach to security assessment, authorization, and continuous monitoring for cloud products and services used by federal agencies. FedRAMP is administered by the General Services Administration (GSA) and is mandatory — any cloud service (SaaS, PaaS, IaaS) that stores, processes, or transmits federal data or metadata must achieve FedRAMP authorization before it can be used by US government agencies or their contractors. The program defines three impact levels: Low (limited adverse effect), Moderate (serious adverse effect), and High (severe or catastrophic effect — applies to law enforcement, emergency, financial, and health systems). Each level maps to NIST SP 800-53 Rev 5 control baselines: FedRAMP High requires implementation of approximately 421 controls. Authorization is achieved through either an Agency ATO (a specific agency sponsors the assessment) or the newer FedRAMP 20-X experimental accelerated path. Once authorized, cloud service providers (CSPs) must maintain continuous monitoring — monthly vulnerability scans, annual penetration testing, and Plan of Action & Milestones (POA&M) reporting — or risk revocation. Authorized services are listed on the FedRAMP Marketplace.

FIDO (Fast IDentity Online) / FIDO2

Mon, 01 Jan 0001 00:00:00 +0000

FIDO2 is the current generation of authentication standards produced jointly by the FIDO Alliance and the W3C, combining two specifications: WebAuthn (Web Authentication API, W3C Level 3, 2025) and CTAP2 (Client to Authenticator Protocol 2, FIDO Alliance). Its defining security property is origin binding: every FIDO2 credential is generated and used with a cryptographic binding to the specific Relying Party ID (RP ID — typically the registering domain’s origin) encoded into every authentication assertion. An authenticator will refuse to produce an assertion for evil.com using a credential registered with bank.com, even if the phishing site presents an identical login page and intercepts the WebAuthn call — the origin check is enforced inside the authenticator, not in JavaScript, and cannot be bypassed by a man-in-the-middle who controls the network or the browser DOM. This property is what makes FIDO2 phishing-resistant by construction, whereas TOTP, SMS OTP, and push-notification MFA are all interceptable by a real-time phishing proxy. FIDO2 is the direct successor to FIDO U2F (Universal 2nd Factor), which provided phishing resistance as a second factor only; FIDO2 extends the model to full passwordless primary authentication.

Fine-tuning / LoRA

Mon, 01 Jan 0001 00:00:00 +0000

Fine-tuning is training continued from a pretrained LLM (or other model) on a smaller, task-specific dataset so behavior matches a domain—support tone, internal jargon, classification format, or tool-use style—without pretraining from scratch. LoRA (Low-Rank Adaptation) is a parameter-efficient fine-tuning method: instead of updating all billions of weights, small low-rank matrices are inserted into attention (and sometimes MLP) layers and only those adapters are trained, drastically cutting VRAM and checkpoint size. The objective is better task accuracy or alignment at lower cost than full fine-tuning; adapters can be swapped per tenant while a frozen base model stays shared. Fine-tuning differs from RAG, which injects external facts at inference time without changing weights.

FIPS 140-2 / FIPS 140-3

Mon, 01 Jan 0001 00:00:00 +0000

FIPS 140 (Federal Information Processing Standard, Publication 140) is the US and Canadian government standard that defines security requirements for cryptographic modules — the hardware, software, or firmware components that perform cryptographic operations (encryption, decryption, hashing, signing, key management). It is published by NIST (National Institute of Standards and Technology) and jointly administered with CCCS (Canadian Centre for Cyber Security) through the Cryptographic Module Validation Program (CMVP). The standard has two active versions: FIPS 140-2 (published 2001, no longer accepting new submissions since April 2022) and FIPS 140-3 (effective September 2020, the current standard for all new validations). FIPS 140-2 certificates remain valid until 21 September 2026, after which they move to the Historical list — meaning only FIPS 140-3 validated modules will be accepted for new federal procurements. FIPS 140 defines four security levels (Level 1 through Level 4), with Level 1 being the baseline for software modules and Level 4 requiring physical tamper-active hardware. Compliance is mandatory for all US federal agencies and their contractors under FISMA, for Canadian federal systems, and is widely adopted by regulated industries (finance, healthcare, critical infrastructure) globally. Non-validated cryptography is treated as providing no protection — effectively plaintext — regardless of the algorithm strength. Validation is a formal, lab-based process: vendors submit modules to accredited Cryptographic and Security Testing (CST) laboratories, which test against the standard and submit results to CMVP for certificate issuance.

firewalld

Mon, 01 Jan 0001 00:00:00 +0000

firewalld is the firewall management daemon on RHEL, CentOS Stream, Fedora, SUSE, and their derivatives, providing a higher-level policy model and a runtime-safe management API on top of nftables (RHEL 8+ / Fedora 32+) or iptables (older systems). Its defining feature is runtime versus permanent configuration: firewall rule changes can be applied immediately to the running system without restarting the service or dropping existing connections (--runtime, the default), and separately persisted to disk so they survive reboots (--permanent). This two-phase model solves the operational problem that raw nftables or iptables rule changes traditionally required either accepting a momentary policy gap during reload or building custom transaction logic. The daemon exposes its API over D-Bus, allowing NetworkManager, libvirt, Podman, and other system components to request firewall policy changes programmatically — when a VM is started in libvirt or a container port is published in Podman, the respective tool calls firewalld over D-Bus to open the required port rather than directly manipulating nftables rules.

fs-verity

Mon, 01 Jan 0001 00:00:00 +0000

fs-verity is a Linux kernel filesystem feature, merged in kernel 5.4, that provides read-only, content-addressable integrity verification at the individual file level. When fs-verity is enabled on a file (via the FS_IOC_ENABLE_VERITY ioctl), the kernel builds a Merkle tree of the file’s content blocks and stores it in a filesystem-specific location (in an ext4 or f2fs Merkle tree block range, or in a separate xattr-adjacent structure on btrfs). From that point, the file becomes immutable — writes are rejected — and every page read from the file is verified against the Merkle tree before being returned to userspace. The file’s fs-verity digest is the SHA-256 (or SHA-512) root hash of the Merkle tree, computable without reading the file at all once the tree is built: fsverity digest file returns this digest. A file’s fs-verity digest is a stable, content-derived identity: two files with the same content have the same digest, and any byte-level modification produces a different digest that verification will detect and reject with EIO. The kernel caches verified Merkle tree nodes in the page cache alongside file data, so the amortised verification overhead is low for sequentially-read files.

GPU (Graphics Processing Unit)

Mon, 01 Jan 0001 00:00:00 +0000

A GPU (Graphics Processing Unit) is a specialized processor designed to execute a very large number of arithmetic operations in parallel. Its original objective was real-time rendering; in modern AI and HPC infrastructure the same silicon is used to accelerate matrix multiplications, convolutions, and other kernels that dominate neural network training and inference. Unlike a general-purpose host, a GPU optimizes for throughput: many warps or wavefronts hide memory latency while the device keeps SIMD units busy. In a data-center stack, GPUs typically sit in PCIe or NVLink-attached servers (or on integrated AI appliances) and are scheduled by frameworks such as PyTorch, TensorFlow, or vLLM through a runtime such as CUDA or ROCm.

GRUB (GNU GRand Unified Bootloader)

Mon, 01 Jan 0001 00:00:00 +0000

GRUB (GNU GRand Unified Bootloader) is the bootloader used by the majority of Linux distributions on x86 and x86-64 systems. Its role is to bridge the gap between what firmware hands control to and what the Linux kernel needs: firmware (BIOS or UEFI) loads GRUB, and GRUB locates the kernel image and initrd on disk, assembles a kernel command line, and transfers control to the kernel. Because GRUB understands a wide range of filesystem formats — ext4, XFS, Btrfs, FAT, and more — it can read its own configuration and the kernel directly from the root or boot partition without any intermediate step, which is what distinguishes it from simpler bootloaders that can only read from FAT.

GSMA NESAS

Mon, 01 Jan 0001 00:00:00 +0000

The GSMA Network Equipment Security Assurance Scheme (NESAS) is a voluntary, global security assurance framework jointly led by the GSMA and 3GPP. It was established to provide a universal, industry-driven security evaluation for mobile network equipment — primarily targeting 4G/LTE and 5G infrastructure — that avoids the fragmentation of country-specific security requirements. NESAS operates through two complementary components: first, an audit of the vendor’s development and product lifecycle processes (covering secure design, implementation, testing, and vulnerability handling), conducted by GSMA-appointed auditing organizations; second, a product evaluation against 3GPP-defined Security Assurance Specifications (SCAS), performed by ISO/IEC 17025 accredited security test laboratories. The GSMA manages scheme governance (accreditation, dispute resolution, publication of results), while 3GPP’s SA3 working group defines the technical security requirements and test cases in SCAS documents. The scheme is currently at NESAS v3.0 (specifications published early 2025), which introduces revised security requirements and expands coverage to include virtualized network functions. NESAS is voluntary — no government mandates it — but it is increasingly referenced by national 5G security reviews and procurement requirements (including the EU 5G Toolbox), and major operators use NESAS assessment results as a procurement criterion. Evaluated vendors and their results are publicly listed on the GSMA website.

Guardrails

Mon, 01 Jan 0001 00:00:00 +0000

Guardrails are controls wrapped around LLM inference to reduce harmful, non-compliant, or off-policy behavior without replacing the base model. Their objective is AI safety and governance in production: block or rewrite prompts that attempt prompt injection or jailbreaks, filter toxic or leaked PII in outputs, enforce topic allowlists, validate structured tool calls, and log decisions for audit. Guardrails sit on the request path (before tokens reach the model or after the model proposes a draft response), combining rule engines, classifiers, regex, and sometimes smaller models. They complement—not replace—application auth, network policy, and human review; enterprises treat them as mandatory for customer-facing and internal copilots.

Hash Function (Cryptographic Hash Function)

Mon, 01 Jan 0001 00:00:00 +0000

A cryptographic hash function maps an input of arbitrary length (a file, a certificate, a password, a block of network data) to a fixed-length digest (also called a hash or fingerprint) with three security properties that distinguish it from non-cryptographic checksums. Preimage resistance: given a digest h, it is computationally infeasible to find any input m such that H(m) = h. Second preimage resistance: given an input m1, it is computationally infeasible to find a different input m2 such that H(m1) = H(m2). Collision resistance: it is computationally infeasible to find any pair (m1, m2) with m1 ≠ m2 such that H(m1) = H(m2). Collision resistance is the strongest property and implies second preimage resistance but not preimage resistance. These properties together make a hash function a one-way, tamper-evident fingerprint: two inputs that produce the same digest cannot be found by an adversary, and knowing the digest reveals nothing about the input beyond its length.

HIPAA

Mon, 01 Jan 0001 00:00:00 +0000

The Health Insurance Portability and Accountability Act (HIPAA) is a United States federal law enacted in 1996 and enforced by the Department of Health and Human Services (HHS) Office for Civil Rights (OCR). HIPAA is not a voluntary standard or certification — it is mandatory US law with civil and criminal penalties for non-compliance (fines up to $1.5M per violation category per year, and criminal penalties including imprisonment). HIPAA applies to covered entities (health plans, healthcare clearinghouses, and healthcare providers who transmit health information electronically) and their business associates (any entity that creates, receives, maintains, or transmits Protected Health Information — PHI — on behalf of a covered entity). The law’s security requirements are defined primarily in two rules: the Privacy Rule (what PHI can be used and disclosed) and the Security Rule (administrative, physical, and technical safeguards required to protect electronic PHI — ePHI). Key technical requirements include access controls, audit controls, integrity controls, transmission security (encryption), and contingency planning. Unlike prescriptive standards (like CIS or DISA STIG), HIPAA’s Security Rule is flexible and scalable — it defines required outcomes but allows organizations to determine the specific technologies used. The Breach Notification Rule requires reporting unauthorized disclosures to HHS and affected individuals within 60 days. HIPAA has no “certification” — compliance is demonstrated through documented risk assessments, policies, and technical controls.

HMAC (Hash-based Message Authentication Code)

Mon, 01 Jan 0001 00:00:00 +0000

HMAC (Hash-based Message Authentication Code), standardised in RFC 2104 (1997) and FIPS 198-1, is a construction that produces a Message Authentication Code (MAC) by combining a cryptographic hash function with a shared secret key. A plain hash function provides integrity — any modification to a message changes its digest — but anyone can recompute the digest of a modified message, so a hash alone cannot prove that a message came from a specific party who holds a secret. HMAC adds authenticity: only a party who knows the key K can produce a valid HMAC(K, message), and only a party who knows K can verify it. The construction is HMAC(K, m) = H((K ⊕ opad) ∥ H((K ⊕ ipad) ∥ m)) — two rounds of hashing with the key XOR’d against inner and outer padding constants — a design chosen to be provably secure against length-extension attacks that affect naive H(K ∥ m) constructions with Merkle-Damgård hash functions like SHA-256. HMAC is proven secure as long as the underlying hash function is a pseudorandom function, a weaker requirement than collision resistance, meaning HMAC-SHA-256 remains secure even in scenarios where SHA-256 collision resistance might be weakened.

HSM (Hardware Security Module)

Mon, 01 Jan 0001 00:00:00 +0000

A Hardware Security Module (HSM) is a purpose-built, tamper-resistant hardware device that holds cryptographic keys and performs cryptographic operations — signing, encryption, decryption, random number generation — entirely within its own protected boundary. The defining property is that private keys generated inside an HSM never exist in plaintext outside it: operations that need the key are sent into the HSM and the result is returned, but the key material itself cannot be extracted. This property is enforced both logically (the firmware refuses export in plaintext) and physically (the device detects and responds to tampering by erasing key material before an attacker can read it). HSMs come in several physical forms: network-attached appliances (rack-mounted devices accessed over the network by many clients), PCIe cards (embedded in a server), and compact USB devices for lower-throughput use cases like protecting CA root keys offline.

IMA (Integrity Measurement Architecture)

Mon, 01 Jan 0001 00:00:00 +0000

IMA (Integrity Measurement Architecture) is a Linux kernel subsystem, merged in kernel 2.6.30, that hooks into the kernel’s file access paths — execve(), mmap(), open() — and computes a cryptographic hash of each file’s contents before it is accessed, according to a configurable policy. It is the runtime half of the Linux integrity story: where TPM PCR measurements and Secure Boot cover what was loaded during the boot sequence, IMA covers what happens after the OS is running, hashing executables, libraries, kernel modules, firmware, and configuration files as they are opened, creating a continuously updated record of everything the system has actually used.

Inference

Mon, 01 Jan 0001 00:00:00 +0000

Inference is the operational phase of machine learning where a trained model is applied to new inputs to produce outputs: next tokens in an LLM, bounding boxes in vision, embeddings for search, or scores in tabular models. Its objective is reliable serving at scale—honoring latency targets (time to first token, p99 completion time), throughput (requests or tokens per second), availability, and cost per query—rather than improving weights. In generative AI, inference splits into prefill (processing the prompt in one or few forward passes) and decode (autoregressive generation of each output token), each with different bottlenecks. Production inference adds API gateways, auth, rate limiting, observability, model versioning, A/B tests, and guardrails; the model file is read-mostly while KV cache and batch state are ephemeral per session.

InfiniBand

Mon, 01 Jan 0001 00:00:00 +0000

InfiniBand is a high-performance network fabric designed for datacenter and HPC clusters, natively supporting RDMA (Remote Direct Memory Access) with low latency, high bandwidth, and features such as adaptive routing and congestion control at the link layer. Its objective in AI is to connect many GPU servers so distributed training (gradient all-reduce via NCCL) and multi-node inference (tensor parallel, llm-d prefill/decode KV transfer) are not limited by TCP overhead on a CPU. InfiniBand NICs (e.g. NVIDIA ConnectX) present verbs APIs; subnets are managed with an Subnet Manager and partitioned for multi-tenant isolation.

initramfs (initial RAM filesystem)

Mon, 01 Jan 0001 00:00:00 +0000

initramfs (initial RAM filesystem) is the temporary root filesystem the Linux kernel mounts immediately after loading itself and before switching to the machine’s real root. The bootloader — GRUB, systemd-boot, or firmware loading a UKI — passes a compressed cpio image (historically called an initrd, though modern Linux always unpacks it as an initramfs into tmpfs, not a separate ramdisk block device). The kernel extracts this archive into an in-memory tree, executes /init as pid 1, and that early userspace environment is responsible for everything the bare kernel cannot yet do: loading storage and filesystem kernel modules, bringing up networking, discovering and unlocking LUKS volumes, activating LVM or multipath devices, mounting the true root partition, and finally calling switch_root (or pivot_root) to hand control to the installed system’s init — typically systemd on current distributions. If the initramfs fails, the boot stops before userspace on the real root ever starts; if it succeeds, it is discarded and its memory reclaimed once the pivot completes.

IPsec (Internet Protocol Security)

Mon, 01 Jan 0001 00:00:00 +0000

IPsec (Internet Protocol Security) is a suite of IETF standards (core specification RFC 4301) that adds cryptographic security to IP packets at the network layer, transparently to applications running above it. Where TLS secures a specific connection between two application endpoints, IPsec secures all IP traffic between two hosts or networks — including traffic from applications that have no TLS support, protocols that predate encryption (routing protocols, SNMP, ICMP), and layer-3 metadata that TLS cannot protect. IPsec provides two protocol headers: AH (Authentication Header, IP protocol 51) signs the IP packet including immutable header fields, providing integrity and source authentication without confidentiality — rarely used in modern deployments because NAT rewrites fields that AH covers. ESP (Encapsulating Security Payload, IP protocol 50) encrypts the payload and provides authenticated encryption with AES-GCM or ChaCha20-Poly1305, optionally protecting the inner IP header as well; ESP is the universally deployed choice. Both operate in two modes: transport mode protects only the payload of an existing IP packet (used for host-to-host encryption between endpoints that share routing), and tunnel mode encapsulates the entire original IP packet inside a new one with new source and destination addresses — the basis of VPN gateways where traffic from one network is tunnelled to another through the public internet.

iptables

Mon, 01 Jan 0001 00:00:00 +0000

iptables is the user-space command-line interface to the Linux kernel’s Netfilter packet filtering framework, the dominant firewall tool on Linux from its introduction in 2001 until nftables began replacing it in the mid-2010s. Netfilter inserts hook points at five positions in the kernel’s IPv4 (and separately IPv6, via ip6tables) packet processing path: PREROUTING (immediately after a packet arrives, before routing), INPUT (packets destined for the local host), FORWARD (packets being routed through the host), OUTPUT (packets generated by local processes), and POSTROUTING (after routing, before transmission). At each hook point, Netfilter calls into the active tables, each of which contains ordered chains of rules. A rule is a match condition (source IP, destination port, protocol, connection state, interface, packet mark, and many more via match extensions) paired with a target — the action to take if the rule matches: ACCEPT, DROP, REJECT, LOG, MASQUERADE, DNAT, SNAT, or a jump to a user-defined chain. Rules are evaluated in order; the first matching rule’s target is applied and evaluation stops (unless the target is LOG or another non-terminating target). If no rule matches, the chain’s policy (the default target) applies.

ISO/IEC 27001

Mon, 01 Jan 0001 00:00:00 +0000

ISO/IEC 27001 is the world’s most widely recognized standard for Information Security Management Systems (ISMS). It is published jointly by ISO (International Organization for Standardization) and IEC (International Electrotechnical Commission) — making it a truly international standard, not tied to any single country or jurisdiction. The current version is ISO/IEC 27001:2022, which replaced the 2013 edition and restructured its Annex A controls to align with the updated ISO/IEC 27002:2022 guidance (93 controls organized in 4 themes: Organizational, People, Physical, Technological). The standard specifies requirements (clauses 4–10) for establishing, implementing, maintaining, and continually improving an ISMS — covering context analysis, leadership commitment, risk assessment, treatment planning, operational controls, performance evaluation, and continuous improvement. Certification is voluntary but has become a global market expectation: ISO 27001 certification is required by countless procurement policies, regulatory frameworks (NIS2 references it, ENS aligns with it, E-ITS accepts it as equivalent, BSI IT-Grundschutz enables ISO 27001 certification), and customer contracts. Certification is issued by accredited certification bodies (accredited under ISO/IEC 17021) following a two-stage audit process, valid for 3 years with annual surveillance audits. Over 70,000 organizations worldwide hold ISO 27001 certification. Unlike prescriptive frameworks (DISA STIG, CIS Benchmarks), ISO 27001 is risk-based and outcome-oriented — it specifies what must be achieved but not how, allowing organizations to tailor implementations to their context.

JWT (JSON Web Token)

Mon, 01 Jan 0001 00:00:00 +0000

JWT (JSON Web Token), standardised in RFC 7519, is a compact, self-contained token format that encodes a set of claims — assertions about a subject, an issuer, an audience, and arbitrary application-defined attributes — as a JSON object, signs or encrypts it, and serialises the result as three base64url-encoded segments separated by dots: header.payload.signature. The header is a JSON object specifying the algorithm (alg) and optionally a key ID (kid) used to produce the signature. The payload is a JSON object containing the claims. The signature is computed over base64url(header) + "." + base64url(payload) using the algorithm declared in the header. The entire token is URL-safe, fits in an HTTP header or query parameter, and is self-describing — a verifier can locate the signing key, check the algorithm, verify the signature, and read the claims without any external lookup beyond fetching the issuer’s public key. This self-contained nature is what makes JWTs efficient at scale: unlike opaque tokens, which require a network call to the issuer’s introspection endpoint per verification, a JWT can be verified locally with a cached public key, making it suitable for high-throughput API gateways and distributed systems.

Kata Containers

Mon, 01 Jan 0001 00:00:00 +0000

Kata Containers is an Open Infrastructure Foundation (OpenInfra Foundation) project that replaces the Linux namespace and cgroup isolation of a conventional container runtime with a full VM boundary, while remaining entirely compatible with the OCI runtime specification and the Kubernetes CRI. From the perspective of containerd, CRI-O, or the Kubernetes kubelet, a Kata pod is indistinguishable from a runc or crun pod — the same API calls, the same lifecycle verbs, the same pod spec — but instead of calling clone() to create a new namespace, Kata starts a lightweight virtual machine. The workload runs inside that VM with its own kernel, its own device model, and a hardware-enforced isolation boundary between itself and the host kernel. The premise is that Linux namespaces, while convenient, share the same kernel as the host: a kernel vulnerability exploitable from inside a container can affect the host and every other container running on the same node. A VM boundary means that even a full guest kernel compromise cannot directly affect the host.

KEV (CISA Known Exploited Vulnerabilities Catalog)

Mon, 01 Jan 0001 00:00:00 +0000

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.

Keylime

Mon, 01 Jan 0001 00:00:00 +0000

Keylime is a CNCF project, originating at MIT Lincoln Laboratory, that turns the raw cryptographic primitives of the TPM into an operable remote attestation system for fleets of Linux machines. Its mission is narrow but important: given that a TPM can produce a signed quote over PCR values, and that IMA can accumulate a runtime measurement log into PCR 10, Keylime provides the infrastructure to continuously collect those quotes from many machines, verify them against policy, react to failures, and gate secret delivery on attestation success — without requiring operators to understand TPM protocols directly.

KMS v2 (Kubernetes KMS Provider v2)

Mon, 01 Jan 0001 00:00:00 +0000

KMS v2 (Kubernetes KMS Provider version 2) is the stable (GA since Kubernetes 1.29, KMS v1 deprecated in 1.28 and disabled by default in 1.29) mechanism for encrypting the contents of the Kubernetes etcd datastore at rest using an external key management service. Without encryption, Kubernetes Secrets stored in etcd are base64-encoded — trivially decodable by anyone with read access to the etcd data files or a snapshot. With KMS v2 enabled, resources written to etcd — Secrets, ConfigMaps, and any other API objects selected by the EncryptionConfiguration — are encrypted before being persisted, using a unique per-object key derived locally. The envelope encryption scheme means those per-object keys are never stored in plaintext: only their encrypted form lives in etcd, and only the external KMS holds the wrapping key. The encryption configuration is declared in a file referenced by the API server’s --encryption-provider-config flag, with kms: apiVersion: v2 selecting the KMS v2 code path, and endpoint: unix:///path/to/plugin.sock pointing at the plugin’s Unix domain socket.

KRITIS (German Critical Infrastructure)

Mon, 01 Jan 0001 00:00:00 +0000

KRITIS (Kritische Infrastrukturen) is Germany’s national regulatory framework for the security and resilience of critical infrastructure. It is enforced by the BSI (Bundesamt für Sicherheit in der Informationstechnik — Federal Office for Information Security) and, for physical resilience, by the BBK (Bundesamt für Bevölkerungsschutz und Katastrophenhilfe — Federal Office of Civil Protection). The framework is now governed by two primary laws: the NIS2-Umsetzungs- und Cybersicherheitsstärkungsgesetz (NIS2UmsuCG), which rewrote the BSI-Gesetz and entered into force on 6 December 2025, and the KRITIS-Dachgesetz (KRITISDachG) for physical resilience, in force since 17 March 2026. Together they transpose the EU NIS2 Directive and CER Directive into German law. The scope expanded dramatically: from approximately 4,000 regulated entities under the previous IT-Sicherheitsgesetz 2.0 to around 30,000 entities now classified as either “besonders wichtige Einrichtungen” (particularly important, equivalent to NIS2 essential) or “wichtige Einrichtungen” (important). KRITIS applies to organizations in 18 sectors (energy, water, health, finance, transport, digital infrastructure, space, public administration, manufacturing, etc.) meeting defined size thresholds. Compliance is mandatory with no transitional period: entities must register with the BSI, implement risk management (§30 BSIG), report security incidents within 24 hours (§32), and management is personally liable (§38) for overseeing cybersecurity measures. Penalties reach up to €10M or 2 % of global turnover for particularly important entities.

KubeVirt

Mon, 01 Jan 0001 00:00:00 +0000

KubeVirt is a CNCF project that makes Kubernetes a native hypervisor management plane, allowing KVM virtual machines to be declared, scheduled, and operated through the Kubernetes API without a separate virtualisation management layer. The motivating use case is organisational convergence: teams running a mix of legacy VM workloads and modern containerised services no longer need two separate platforms (an OpenStack or vSphere cluster for VMs, a Kubernetes cluster for containers) with separate networking, storage, RBAC, and CI/CD integration. With KubeVirt, both workload types live in the same cluster, share the same kubectl and GitOps tooling, and are subject to the same scheduling, resource quota, and network policy primitives. KubeVirt reached 1.0 in 2023 and is the engine behind Red Hat OpenShift Virtualization, the downstream product used by organisations migrating away from VMware.

KV cache (Key-Value Cache)

Mon, 01 Jan 0001 00:00:00 +0000

The KV cache (key-value cache) is the stored result of the attention layers for tokens already processed in a sequence. During autoregressive decode, each new token only needs a forward pass that depends on prior context; recomputing keys and values for all earlier tokens every step would be wasteful. The cache therefore holds, per layer and per sequence, the K and V tensors produced when those tokens were first seen (during prefill for the prompt, then extended one token at a time during decode). The objective is lower time per output token and lower FLOPs; the cost is GPU memory: cache size grows with batch × layers × heads × sequence_length × head_dim, and is often the limit on concurrent sessions or context length before model weights fill VRAM.

KVM/QEMU

Mon, 01 Jan 0001 00:00:00 +0000

KVM (Kernel-based Virtual Machine) and QEMU (Quick Emulator) solve different halves of the same problem and are almost always used together. KVM is a Linux kernel module that turns the kernel into a hypervisor: with Intel VT-x or AMD-V, guest CPUs run on real hardware at near-native speed and guest memory is managed through extended page tables. KVM has no device model of its own — no disk, network, or firmware emulation. QEMU supplies that in userspace (virtio, USB, VGA, ACPI) and controls KVM by issuing ioctl calls on /dev/kvm — creating VMs, mapping memory, running vCPUs via KVM_RUN — while QMP exposes external management over a Unix socket. libvirt, originally from Red Hat, sits above both: it translates domain XML into QEMU command lines and lifecycle operations. The stack is the default on Linux: RHEL ships qemu-kvm, OpenShift Virtualization runs KubeVirt (virt-launcher → libvirt → QEMU), and OpenShift Sandboxed Containers uses Kata Containers with the same hypervisor to isolate pods in micro-VMs.

LDAP (Lightweight Directory Access Protocol)

Mon, 01 Jan 0001 00:00:00 +0000

LDAP (Lightweight Directory Access Protocol) is a client-server protocol for accessing and modifying a directory service: a specialised database optimised for read-heavy, hierarchically-organised identity data. It was derived from the X.500 directory standard in the early 1990s, stripping out OSI transport dependencies to run over TCP/IP, and standardised in its current form in RFC 4511 (LDAPv3, 2006). A directory in the LDAP sense is not a general-purpose database — it is a tree of entries (also called objects), each identified by a Distinguished Name (DN) that encodes its position in the hierarchy: cn=alice,ou=users,dc=example,dc=com. Each entry is an instance of one or more object classes (defined in a schema), and each object class defines a set of mandatory and optional attributes — typed, multi-valued fields such as uid, cn (common name), mail, userPassword, memberOf, sshPublicKey, objectClass, and userCertificate. The schema is extensible: LDAP servers ship with standard schema files (RFC 2307 for POSIX users and groups, RFC 4519 for person entries) and organisations add custom schema for application-specific attributes. The tree structure makes hierarchical policy delegation natural — all objects under ou=engineering,dc=example,dc=com can be administered by a different set of ACL rules than objects under ou=ops.

libvirt

Mon, 01 Jan 0001 00:00:00 +0000

libvirt is an open-source library, daemon, and toolset that provides a unified, stable API for managing virtualisation infrastructure — virtual machines, storage volumes, virtual networks, and host devices — across multiple hypervisor backends. It was originally written by Daniel Berrange at Red Hat and has since become the standard virtualisation management layer on Linux, underpinning KubeVirt, OpenStack Nova, oVirt/RHEV, Proxmox, and the virsh / virt-manager administrative tools. The core value proposition is hypervisor abstraction: the same libvirt API call creates a VM on KVM/QEMU, Xen, LXC, or (historically) VMware ESXi, without the management layer caring about the underlying implementation. In practice, the KVM/QEMU driver is the dominant use case on Linux; the others are progressively less-maintained but remain supported. libvirt communicates with hypervisors through driver-specific mechanisms — with QEMU, it generates the full QEMU command line from the domain XML definition and manages the QEMU process lifecycle, communicating with the running VM through the QEMU Monitor Protocol (QMP) over a Unix socket.

LLM (Large Language Model)

Mon, 01 Jan 0001 00:00:00 +0000

An LLM (large language model) is a deep neural network—almost always a Transformer—trained on large amounts of text (and sometimes multimodal data) to model the probability of the next token given prior context. Its objective at training time is to minimize prediction error over billions of tokens, producing weights that encode grammar, facts (with limitations), reasoning patterns, and task-following behavior after alignment or instruction tuning. At inference time the same model generates completions, answers questions, summarizes documents, or drives agents; production systems expose it through APIs (often OpenAI-compatible) backed by engines such as vLLM or NIM. LLMs power chatbots, code assistants, RAG pipelines, and enterprise copilots.

llm-d

Mon, 01 Jan 0001 00:00:00 +0000

llm-d is an open-source distributed inference serving stack for production LLM workloads on Kubernetes. Its objective is not to replace model servers such as vLLM or SGLang but to sit above them and fix cluster-scale problems: which replica should receive the next request, how to split prefill (compute-heavy) from decode (memory-bandwidth-heavy), how to share or tier KV cache state, and how to scale MoE models with wide expert parallelism. llm-d publishes “well-lit path” guides—benchmarked Helm recipes and architectures—so teams reach strong time-to-first-token and throughput without hand-rolling schedulers. The project is a CNCF sandbox effort with contributors including Red Hat, IBM, Google, and cloud partners.

LSM (Linux Security Module)

Mon, 01 Jan 0001 00:00:00 +0000

Linux Security Modules (LSM) is a hook-based framework integrated into the Linux kernel since 2.6 (2003) that provides a general mechanism for implementing Mandatory Access Control (MAC) without modifying the core kernel. Its origin is the NSA’s presentation of SELinux at the 2001 Linux Kernel Summit: Linus Torvalds accepted the need for flexible access control but refused to hardcode a single security model, directing instead the development of a framework into which any security model could be plugged. The result is LSM: a set of strategically placed hook functions throughout the kernel’s execution paths — over 240 hooks in recent kernels — at points where security-relevant decisions occur: file open, process creation, capability checks, socket operations, IPC access, memory mapping, and more. Each hook is a call into the currently active security module(s), which examine the operation’s context and return allow or deny. The core kernel enforces whatever the security module decides.

LUKS (Linux Unified Key Setup)

Mon, 01 Jan 0001 00:00:00 +0000

LUKS (Linux Unified Key Setup) is the standard specification for block device encryption on Linux, created by Clemens Fruhwirth in 2004. It sits above the kernel’s dm-crypt subsystem — which performs the actual AES sector-by-sector encryption via the device mapper — and adds a structured, on-disk header that decouples key management from the encryption itself. Any block device can be a LUKS container: a partition, a logical volume, a loop device; anything that sits beneath it (filesystem, swap, LVM) is encrypted transparently, with no changes required to the software using it. The managed cryptsetup tool and the libcryptsetup library provide userspace access to LUKS volumes, and are the canonical interface for all operations on them.

MACsec (IEEE 802.1AE)

Mon, 01 Jan 0001 00:00:00 +0000

MACsec (MAC Security, IEEE 802.1AE) is an IEEE standard, first published in 2006 and supported in the Linux kernel since 4.6 (2016), that encrypts and authenticates Ethernet frames at layer 2 — hop by hop between directly connected devices. Its operating layer is what distinguishes it from IPsec (layer 3) and TLS (layer 4): MACsec wraps Ethernet frames, not IP packets or TCP streams, so it can protect every byte that traverses a link segment regardless of what protocol it carries. ARP replies, DHCP offers, LLDP frames, routing protocol adjacencies, and layer-2 broadcast traffic are all encrypted and authenticated alongside application data — something neither IPsec nor TLS can accomplish because both require an IP header to already be present and unenforced. The topology implication of this is that MACsec is link-local and hop-by-hop: it encrypts between two directly adjacent Ethernet peers (a host and a switch, or two switches), decrypts at each hop for forwarding decisions, and re-encrypts toward the next hop. It cannot stretch across a routed boundary; for that, IPsec is the right tool.

MCP (Model Context Protocol)

Mon, 01 Jan 0001 00:00:00 +0000

MCP (Model Context Protocol) is an open standard for how LLM applications discover and invoke tools, read structured resources, and exchange prompts with external systems through MCP servers and clients. The objective is interchangeable integrations: instead of every chat product implementing bespoke plugins for Git, databases, or ticketing, a tool provider ships an MCP server and any compatible client (IDE, assistant, agent runtime) can use it with consistent auth and capability negotiation. MCP complements HTTP inference APIs—it sits at the orchestration layer where the model decides which tool to call, not inside vLLM’s token loop. It is widely associated with agentic workflows (multi-step plans, code execution, retrieval).

Measured Boot

Mon, 01 Jan 0001 00:00:00 +0000

Measured Boot is a boot process architecture in which each component in the boot chain — firmware, bootloader, kernel, initrd, kernel command line — is cryptographically hashed and that hash is recorded into a TPM Platform Configuration Register (PCR) before the component executes. The critical distinction from Secure Boot is in what each mechanism provides: Secure Boot is an enforcement mechanism that prevents unauthorised components from running at all; Measured Boot is a recording mechanism that creates a tamper-evident log of exactly what did run, without necessarily preventing anything. The two are complementary and typically deployed together — Secure Boot enforces a policy at boot time, Measured Boot produces the evidence that the policy was enforced as claimed. A system can have Measured Boot without Secure Boot (it records everything that ran, even unsigned components), but Secure Boot without Measured Boot provides enforcement with no attestable evidence of what was enforced.

MIG (Multi-Instance GPU)

Mon, 01 Jan 0001 00:00:00 +0000

MIG (Multi-Instance GPU) is an NVIDIA GPU partitioning mode on datacenter accelerators (e.g. A100, H100) that splits one physical card into up to seven GPU instances (GIs), each with isolated streaming multiprocessors, memory bandwidth, and HBM capacity. The objective is higher utilization in multi-tenant environments: several smaller models or dev/test workloads share one expensive GPU without time-slicing contention as severe as full-card sharing. Each MIG instance appears to the OS and CUDA as a separate GPU with fixed resources; workloads cannot oversubscribe another instance’s memory. MIG suits inference and modest training more often than massive single-job training that needs the entire GPU and NVLink domain.

ML-DSA (Module-Lattice-Based Digital Signature Algorithm)

Mon, 01 Jan 0001 00:00:00 +0000

ML-DSA (Module-Lattice-Based Digital Signature Algorithm), standardised as NIST FIPS 204 in August 2024, is the primary post-quantum replacement for digital signatures. It replaces ECDSA, EdDSA, and RSA PSS/PKCS#1 signatures in X.509 certificates, code signing, TLS client and server authentication, SSH, JWT signing, and any other context where a party proves possession of a private key by producing a signature that others verify with the public key. ML-DSA is derived from CRYSTALS-Dilithium, the submission that won NIST’s lattice-based signature selection, and its security rests on the Module Learning With Errors (MLWE) and Module Short Integer Solution (MSIS) problems — the same mathematical family as ML-KEM, which is significant because both algorithms can share implementation code and hardware acceleration for the underlying polynomial arithmetic (NTT, number-theoretic transform).

ML-KEM (Module-Lattice-Based Key Encapsulation Mechanism)

Mon, 01 Jan 0001 00:00:00 +0000

ML-KEM (Module-Lattice-Based Key Encapsulation Mechanism), standardised as NIST FIPS 203 in August 2024, is the primary post-quantum replacement for key encapsulation and key exchange. It replaces the role of ECDH (X25519, P-256) and RSA key transport in TLS handshakes, IPsec IKEv2 negotiations, and any other protocol that needs two parties to establish a shared secret without prior key material. ML-KEM is derived from CRYSTALS-Kyber, the submission that won NIST’s lattice-based KEM selection, and its security rests on the Module Learning With Errors (MLWE) problem: distinguishing a structured noisy linear system from a random one is computationally hard, and no efficient quantum algorithm for this problem is known. The “module” qualifier means the construction uses polynomial rings structured in a way that allows a good balance between security and efficiency, contrasting with pure LWE (larger keys, simpler structure) and NTRU (smaller keys, different structure).

mTLS (Mutual TLS)

Mon, 01 Jan 0001 00:00:00 +0000

mTLS (Mutual TLS) is the configuration of TLS in which certificate-based authentication is required from both sides of the connection, not just the server. In standard TLS, only the server presents an X.509 certificate, which the client verifies to confirm it is talking to the intended host; the client is typically anonymous to the server, or authenticates separately via a password or session token at the application layer. In mTLS, the client also presents a certificate during the TLS handshake; the server verifies it against a trusted CA before completing the connection. The result is cryptographic proof of identity in both directions: the client knows it is talking to the legitimate server (as in standard TLS), and the server knows the exact identity of the connecting client — without any password, API key, or token exchanged in the application layer.

NBDE / Clevis / Tang (Network-Bound Disk Encryption)

Mon, 01 Jan 0001 00:00:00 +0000

NBDE (Network-Bound Disk Encryption) is an approach to automatic LUKS disk unlocking that binds the volume key not to hardware state (a TPM PCR measurement) but to network presence: a LUKS-encrypted volume unlocks automatically at boot if and only if the machine can reach a designated Tang server on a trusted network. Remove the machine from that network — because it was stolen, because a data centre drive was pulled, because someone exfiltrated the hardware — and the volume key becomes unrecoverable without a fallback passphrase. The threat model is therefore complementary to TPM-based unlocking: TPM sealing asks “is this the right software stack?” and locks the key to a specific platform measurement; NBDE asks “is this machine on the trusted network?” and locks the key to network presence. Neither addresses both threat classes alone, which is why the two are routinely combined — and why RHEL formalises NBDE as a subcategory of the broader Policy-Based Decryption (PBD) framework that the Clevis pin system implements.

NCCL (NVIDIA Collective Communications Library)

Mon, 01 Jan 0001 00:00:00 +0000

NCCL (NVIDIA Collective Communications Library) implements collective operations—all-reduce, broadcast, reduce-scatter, all-gather, and others—optimized for NVIDIA GPUs across NVLink within a node and RDMA (InfiniBand or RoCE) across nodes. Its objective in AI is to make distributed training and multi-GPU inference (tensor parallelism) scale: gradient shards must merge every step; attention and MLP partitions must exchange activations with minimal latency. Frameworks (PyTorch DDP/FSDP, vLLM tensor parallel) call NCCL (or delegate to it) rather than hand-rolling socket code.

nftables

Mon, 01 Jan 0001 00:00:00 +0000

nftables is the successor to iptables within the Linux Netfilter framework, merged into the mainline kernel in 3.13 (2014) and now the default firewall backend on all major distributions — Debian 10+, Ubuntu 20.04+, RHEL 8+, Fedora 32+. It replaces not just iptables but the entire family of legacy Netfilter frontends: ip6tables (IPv6), arptables (ARP), and ebtables (Ethernet bridging) are all unified under a single nft command and a single kernel subsystem. The kernel component is a generic, protocol-independent packet classification engine; the protocol-specific logic (IPv4, IPv6, ARP, bridging) is expressed in user-space rule syntax rather than hardcoded in separate kernel modules. This unification eliminates the fragmented ruleset management of the iptables era, where a firewall with consistent IPv4/IPv6 and bridging policy required coordinating four separate tools with four separate rulesets and four separate persistence mechanisms.

NIM (NVIDIA Inference Microservices)

Mon, 01 Jan 0001 00:00:00 +0000

NIM (NVIDIA Inference Microservices) are container images and Helm charts that deliver ready-to-run inference endpoints for specific models (LLMs, vision, embedding, reranking, and more). The objective is to shrink time-to-production: instead of assembling CUDA drivers, frameworks, model weights, and an OpenAI-compatible server yourself, operators pull a NIM that bundles a performance-tuned engine (often TensorRT-LLM or Triton-backed paths), default model artifacts or download hooks, health checks, and a stable HTTP/gRPC API. NIMs are sized for GPU deployment and target enterprise MLOps teams that want versioned, scannable containers with predictable resource requests rather than bespoke notebooks turned into scripts.

NIS2 Directive

Mon, 01 Jan 0001 00:00:00 +0000

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.

NIST 800-53

Mon, 01 Jan 0001 00:00:00 +0000

NIST Special Publication 800-53 is published by the National Institute of Standards and Technology (NIST), a US federal agency within the Department of Commerce. The current version is Revision 5 (September 2020, updated December 2020), which defines over 1,000 security and privacy controls organized in 20 control families (Access Control, Audit and Accountability, Configuration Management, Incident Response, System and Communications Protection, Supply Chain Risk Management, etc.). NIST 800-53 is mandatory for US federal agencies and their contractors under FISMA (Federal Information Security Modernization Act) and serves as the control baseline for FedRAMP (cloud), CMMC (defense contractors), and many state/local government programs. Beyond the US, it is widely adopted internationally as a comprehensive reference catalog — organizations in finance, healthcare, and critical infrastructure worldwide use NIST 800-53 as their control framework. The standard defines three baselines (Low, Moderate, High) corresponding to the potential impact of a security breach. NIST 800-53 is not a certification itself but the control catalog against which systems are assessed; formal authorization (ATO — Authority to Operate) is granted by an authorizing official after an assessor verifies control implementation using NIST SP 800-53A assessment procedures. The companion OSCAL (Open Security Controls Assessment Language) standard, also from NIST, provides machine-readable formats for expressing 800-53 controls and assessment results.

NVLink

Mon, 01 Jan 0001 00:00:00 +0000

NVLink is NVIDIA’s proprietary high-speed interconnect between GPUs (and, on some platforms, between GPUs and CPUs) inside a server or across an NVLink switch system (e.g. NVL72-class racks). Its objective is to move tensors—activations, gradients, KV cache shards, or partial attention results—at much higher bandwidth and lower latency than PCIe or general Ethernet, so multi-GPU training and large-model inference (tensor parallelism) are not bottlenecked on the bus. NVLink domains define which GPUs can treat each other’s memory as peer-accessible for CUDA and NCCL without leaving the box.

O-RAN Alliance

Mon, 01 Jan 0001 00:00:00 +0000

The O-RAN Alliance is an operator-led global industry alliance, formed in February 2018 through the merger of the C-RAN Alliance and the xRAN Forum, whose mission is to reshape how radio access networks are designed, built, and operated. Where traditional RAN stacks are vertically integrated — baseband software, radio hardware, and management tools delivered as a single vendor bundle — O-RAN promotes disaggregation: separating the RAN into open, standardised functional blocks connected by published interfaces, so a mobile operator can mix DU, CU, RU, and management software from different suppliers. The alliance’s core objectives are multi-vendor interoperability, cloud-native and virtualised deployment, programmable RAN intelligence through the RIC (RAN Intelligent Controller), and operational automation at scale. These goals address vendor lock-in, slow innovation cycles, and the cost structure of legacy RAN, while aligning with 5G and beyond requirements for network slicing, edge deployment, and AI/ML-driven optimisation.

OAuth 2.0

Mon, 01 Jan 0001 00:00:00 +0000

OAuth 2.0 (RFC 6749, 2012) is an authorisation delegation framework — not an authentication protocol — that solves a specific problem: how does a user grant a third-party application access to their resources on a server, without giving that application their password? The canonical example is a user granting a calendar app access to their Google Drive files: OAuth 2.0 lets Google issue the calendar app a scoped, time-limited access token that permits it to read Drive files, without the app ever seeing the user’s Google password. The distinction between authorisation and authentication is fundamental: OAuth 2.0 proves that a token was issued by an authorisation server for a specific scope — it says nothing about who the user is. Attempting to use OAuth 2.0 for authentication (treating token possession as proof of identity) is a well-documented anti-pattern with concrete exploits; OIDC (OpenID Connect) is the authentication layer built on top of OAuth 2.0 that addresses this correctly.

OCI (Open Container Initiative)

Mon, 01 Jan 0001 00:00:00 +0000

The Open Container Initiative (OCI) is a Linux Foundation project founded in June 2015 by Docker, CoreOS, and others to prevent the container ecosystem from fragmenting around proprietary formats. It maintains three interlocking specifications that together describe the complete lifecycle of a container: how an image is structured, how it is transported, and how it is run. Any tool that conforms to these specs — builder, registry, runtime — is interoperable with any other conformant tool, which is why an image built by buildah can be pushed to a registry running Harbor, pulled by containerd, and executed by a runtime written in Rust.

OCI Referrers API

Mon, 01 Jan 0001 00:00:00 +0000

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.

OCSP (Online Certificate Status Protocol)

Mon, 01 Jan 0001 00:00:00 +0000

OCSP (Online Certificate Status Protocol), standardised in RFC 6960, is a request-response protocol that allows a verifier to query an OCSP responder — a service operated by the CA or a delegated party — for the current revocation status of a specific X.509 certificate. Where a CRL requires downloading an entire list and searching it locally, an OCSP query asks about exactly one certificate and receives a signed response: good (the certificate is currently valid and not revoked), revoked (revoked, with the revocation time and reason), or unknown (the responder does not know this certificate). The OCSP response is signed by the CA’s OCSP signing key (or a dedicated OCSP responder key with the id-pkix-ocsp-nocheck extension, exempt from its own revocation checking to prevent circularity) and carries a thisUpdate and nextUpdate timestamp defining its freshness window. Verifiers in strict mode reject responses outside the freshness window; in practice, OCSP responses are valid for 24 hours to 7 days depending on the CA’s policy, meaning OCSP shares CRL’s staleness problem, albeit with a smaller window.

OIDC (OpenID Connect)

Mon, 01 Jan 0001 00:00:00 +0000

OpenID Connect (OIDC) is an authentication protocol built as a thin layer on top of OAuth 2.0, published by the OpenID Foundation in 2014. Where OAuth 2.0 defines how to delegate authorisation (granting access to resources), OIDC adds the missing authentication semantics: a standard ID token that proves who the user is, a UserInfo endpoint that returns standardised identity claims, and a discovery document that allows clients to configure themselves automatically from a single well-known URL. The separation is precise: OAuth 2.0 access tokens prove that a client is authorised to call an API; OIDC ID tokens prove that a specific user authenticated with a specific identity provider at a specific time. OIDC is the protocol behind virtually every “Sign in with Google / GitHub / Microsoft” flow, every SAML-to-modern-stack migration, and every Kubernetes service account token issued today — making it the dominant authentication federation standard in cloud-native infrastructure.

OpenPGP / GPG

Mon, 01 Jan 0001 00:00:00 +0000

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.

OpenSSL

Mon, 01 Jan 0001 00:00:00 +0000

OpenSSL is an open-source cryptographic library and command-line toolkit, originally derived from SSLeay in 1998 and now governed by the OpenSSL Software Foundation under an Apache 2.0 licence (since version 3.0). It is the default cryptographic substrate for the majority of Linux server software: Apache httpd, nginx, curl, wget, PostgreSQL, MySQL, Postfix, OpenLDAP, and hundreds of other projects link against libssl and libcrypto by default. It implements TLS (all versions from 1.2 through 1.3), X.509 certificate parsing and validation, PKI operations (CSR generation, certificate signing, CRL and OCSP processing), and the full range of cryptographic primitives — symmetric ciphers (AES-GCM, ChaCha20-Poly1305), hash functions (SHA-2, SHA-3, SHAKE), RSA, ECC (ECDSA, ECDH, Ed25519, X25519), HMAC, HKDF, and key derivation functions. The library has two primary components: libcrypto, the algorithm library, and libssl, the TLS protocol layer built on top of it. The openssl command-line tool exposes both as a single swiss-army interface for certificate management, key generation, encryption, hashing, benchmarking, and protocol testing.

ORAS (OCI Registry As Storage)

Mon, 01 Jan 0001 00:00:00 +0000

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.

PAM (Privileged Access Management)

Mon, 01 Jan 0001 00:00:00 +0000

Privileged Access Management (PAM) is the security discipline concerned with controlling, auditing, and minimising the use of privileged accounts: root access, domain administrator rights, cloud IAM roles with wide permissions, database superuser credentials, service account tokens, and any other identity that can cause systemic damage if misused. The threat PAM addresses is specific: an attacker who obtains a regular user credential can typically access that user’s data; an attacker who obtains a privileged credential can move laterally, disable security controls, exfiltrate everything, and deploy ransomware. PAM is therefore not a generalisation of identity and access management (IAM) but a specialisation of it — the same concepts of authentication and authorisation, applied with far higher friction to the accounts that most need it.

PCI-DSS

Mon, 01 Jan 0001 00:00:00 +0000

The Payment Card Industry Data Security Standard (PCI-DSS) is a global security standard developed and maintained by the PCI Security Standards Council (PCI SSC), which was founded in 2006 by the five major payment card brands (Visa, Mastercard, American Express, Discover, JCB). The current version is PCI-DSS v4.0.1 (published June 2024, with mandatory compliance required from 31 March 2025 for all new requirements). PCI-DSS is not government legislation but a contractual obligation — compliance is enforced through the agreements between merchants/service providers and their acquiring banks. Failure to comply results in fines (up to $100,000/month from card brands), increased transaction fees, and ultimately loss of the ability to process card payments. PCI-DSS applies to any organization worldwide that stores, processes, or transmits cardholder data (CHD) or sensitive authentication data (SAD), regardless of size or transaction volume. The standard defines 12 requirements organized in 6 control objectives: build and maintain secure networks (firewalls, secure configurations), protect cardholder data (encryption, key management), maintain a vulnerability management program (patching, anti-malware), implement strong access controls (least privilege, MFA, physical access), regularly monitor and test networks (logging, penetration testing), and maintain an information security policy. Compliance is validated through either a Qualified Security Assessor (QSA) on-site assessment (Level 1 merchants) or a Self-Assessment Questionnaire (SAQ) for smaller entities.

Peer Pods

Mon, 01 Jan 0001 00:00:00 +0000

Peer Pods is the deployment model for CoCo (Confidential Containers) designed for public cloud environments where the Kubernetes worker nodes are standard VMs — not bare metal — and therefore cannot host a nested confidential VM for each pod. The fundamental constraint it solves is physical: confidential computing hardware (TDX, SEV-SNP) does not support nested virtualisation, meaning a confidential guest cannot be launched inside another VM. In the conventional CoCo deployment, the Kata Containers runtime asks a local hypervisor (QEMU/KVM) on the worker node to create a micro-VM for each pod; if the worker node is itself a VM, this requires nested virtualisation that the TEE hardware cannot provide. Peer Pods sidestep this entirely by moving the pod’s VM off the worker node and onto a separate, cloud-provisioned instance running directly on bare-metal TEE-capable hardware.

PKI (Public Key Infrastructure)

Mon, 01 Jan 0001 00:00:00 +0000

Public Key Infrastructure (PKI) is the framework that makes asymmetric cryptography operationally useful at scale. Asymmetric cryptography provides a mathematical relationship between a public key and a private key, but by itself it cannot answer the question a relying party cares about: whose public key is this? PKI answers that question by introducing a trusted third party — the Certificate Authority (CA) — that cryptographically binds a public key to an identity (a hostname, an organisation name, an email address, a SPIFFE ID) by signing a certificate. A relying party that trusts the CA can therefore trust any certificate the CA signs, without needing to know the subject directly. The chain of trust extends recursively: a Root CA signs Intermediate CA certificates, which sign end-entity certificates (also called leaf certificates). Root CA private keys are kept offline in HSMs and used rarely; intermediate CAs handle day-to-day issuance and can be revoked without rotating the root. The set of root CA certificates a system trusts is its trust store — browsers and operating systems ship with a pre-populated trust store of publicly-trusted roots, while private PKIs use custom roots distributed by administrators.

Port-based Network Access Control (IEEE 802.1X)

Mon, 01 Jan 0001 00:00:00 +0000

IEEE 802.1X is a standard for Port-Based Network Access Control (PNAC) that prevents any device from sending or receiving traffic on a network port until it has successfully authenticated. Originally designed for wired Ethernet and ratified in 2001, it now equally underpins enterprise Wi-Fi (WPA-Enterprise/WPA3-Enterprise), where access points act as the port gatekeeper. The core premise is that physical access to a port — plugging in a cable or being in range of an access point — does not grant network access. The port is logically divided into two channels: the uncontrolled port, which passes only EAP authentication traffic (EAPOL frames), and the controlled port, which is fully blocked until authentication succeeds. Only after the authentication server approves the device does the switch or access point open the controlled port and allow normal traffic. This port-level gate is what separates 802.1X from higher-layer authentication: a device that fails 802.1X receives no IP address, cannot reach any network resource, and cannot even attempt an attack at layer 3.

PQC (Post-Quantum Cryptography)

Mon, 01 Jan 0001 00:00:00 +0000

Post-Quantum Cryptography (PQC) is the set of cryptographic algorithms designed to resist attacks from a Cryptographically Relevant Quantum Computer (CRQC) — a quantum computer large and stable enough to run Shor’s algorithm at scale. Shor’s algorithm can solve the integer factorisation and discrete logarithm problems that underpin RSA, ECDSA, and ECDH in polynomial time, meaning that every asymmetric algorithm in wide use today — TLS key exchange, X.509 certificate signatures, SSH host keys, code signing, and encrypted email — becomes trivially breakable by a CRQC. Symmetric algorithms (AES, SHA-256) are substantially less affected: Grover’s algorithm provides only a quadratic speedup against them, which is mitigated by doubling key lengths (AES-256 remains appropriate). PQC replaces the asymmetric primitives only, on hard mathematical problems for which no efficient quantum algorithm is known: structured lattices (the Learning With Errors and Module-LWE problems), hash functions (the security of SHA-3 family variants), and error-correcting codes.

Prefill

Mon, 01 Jan 0001 00:00:00 +0000

Prefill is the first stage of LLM inference after a user (or RAG pipeline) submits a prompt: the model runs a forward pass over all input tokens at once (or in chunked blocks for very long contexts) to compute hidden states and populate the KV cache for every layer. Its objective is to prepare context the model will attend to during generation; the user-visible metric is often time to first token (TTFT), which is dominated by prefill for long prompts. Prefill is compute-intensive (large matrix multiplies across the full sequence) compared with decode, which adds one token at a time. In chat, each new user message typically triggers a new prefill over the accumulated conversation (unless caching optimizations apply).

Private 5G

Mon, 01 Jan 0001 00:00:00 +0000

Private 5G (also non-public 5G, dedicated 5G, or campus/industrial 5G) denotes 3GPP-conformant 5G systems operated for a defined organisation or site — factory, port, mine, hospital, stadium, or utility — rather than as a nationwide public mobile service. 3GPP Release 16+ formalised Non-Public Networks (NPN) with two principal models: Standalone NPN (SNPN) — an isolated PLMN (dedicated MCC/MNC or PLMN ID) with its own 5GC and NG-RAN; and Public Network Integrated NPN (PNI-NPN) — a slice or dedicated DNN on a public operator’s 5G with contractual isolation. Private 5G delivers URLLC-capable connectivity, local breakout (traffic stays on-site via local UPF), deterministic QoS, and control over upgrades and security policies — advantages over Wi-Fi 6/7 in mobility, scheduling, and industrial TSN integration scenarios, at higher cost and regulatory complexity.

PSA (Pod Security Admission)

Mon, 01 Jan 0001 00:00:00 +0000

Pod Security Admission (PSA) is the built-in Kubernetes admission controller that enforces the Pod Security Standards (PSS), a set of predefined security profiles that constrain what a pod is allowed to do. It became stable in Kubernetes 1.25, at which point its predecessor PodSecurityPolicy (PSP) was simultaneously removed. Where PSP was a complex, cluster-scoped object requiring deep RBAC wiring and prone to misconfiguration, PSA is deliberately simpler: it is always enabled, requires no CRDs or RBAC setup, and is configured entirely through namespace labels. The trade-off for that simplicity is that PSA is opinionated and coarse-grained — it enforces fixed profiles rather than arbitrary custom rules, and its granularity is the namespace rather than the individual workload or service account. Teams needing finer-grained policy beyond what PSA offers typically combine it with a policy engine such as Kyverno or OPA Gatekeeper.

PTP (Precision Time Protocol)

Mon, 01 Jan 0001 00:00:00 +0000

Precision Time Protocol (PTP), standardised as IEEE 1588, distributes a common reference time across packet networks so that distributed nodes share a clock with sub-microsecond to nanosecond accuracy — far beyond what NTP typically achieves over IP. PTP operates in a master–slave hierarchy: a Grandmaster Clock (GM) holds traceability to GNSS (GPS, Galileo, etc.) or a Primary Reference Time Clock (PRTC); Boundary Clocks (BC) terminate and regenerate timing on hops; Transparent Clocks (TC) correct residence time in switches without terminating the protocol. Messages (Sync, Follow_Up, Delay_Req/Resp, optional Announce) implement a delay request–response mechanism to estimate path asymmetry and offset each Ordinary Clock (OC) slave relative to the grandmaster.

Quantization

Mon, 01 Jan 0001 00:00:00 +0000

Quantization is the process of representing a model’s weights and/or activations with fewer bits than full FP32 training precision—commonly FP16, BF16, FP8, INT8, or INT4 (GPTQ, AWQ, GGUF-style formats). The objective is lower GPU memory (larger models or more concurrent sessions per card), higher throughput, and sometimes faster kernels on hardware with native low-precision units, at the cost of possible quality degradation if pushed too aggressively. Quantization can be applied post-training (calibration on a sample dataset) or during training (quantization-aware training). For inference, serving engines vLLM and NIM load quantized checkpoints and dispatch to vendor libraries (TensorRT-LLM, CUTLASS, etc.) that implement fused low-precision matmuls.

RAG (Retrieval-Augmented Generation)

Mon, 01 Jan 0001 00:00:00 +0000

RAG (retrieval-augmented generation) is an architecture pattern, not a single product: before the LLM generates an answer, a retriever finds relevant chunks from a knowledge base (wikis, tickets, PDFs, databases) and injects them into the prompt as context. The objective is grounded responses—fewer hallucinations on company facts, answers that reflect documents updated yesterday, and traceability to sources—without running full fine-tuning every time content changes. A typical pipeline embeds queries and documents with an embedding model, stores vectors in a search index, retrieves top-k passages, optionally reranks them, then calls the LLM with a system prompt plus retrieved text. RAG is the dominant enterprise pattern for private AI assistants and support bots.

RDMA (Remote Direct Memory Access)

Mon, 01 Jan 0001 00:00:00 +0000

RDMA (Remote Direct Memory Access) allows a network adapter to transfer data between the memory of two machines with little CPU overhead, low latency, and often kernel bypass (userspace stacks such as verbs on InfiniBand or RoCE). Its objective in AI infrastructure is to keep GPUs fed and synchronized: distributed training exchanges gradients quickly, disaggregated inference (llm-d) moves KV cache blocks between prefill and decode nodes, and NVMe-oF storage delivers checkpoints without the host spending cycles copying every byte. DPUs and SmartNICs also use RDMA paths for storage and east-west traffic while the host CPU runs models.

RHCOS (Red Hat Enterprise Linux CoreOS)

Mon, 01 Jan 0001 00:00:00 +0000

RHCOS (Red Hat Enterprise Linux CoreOS) is the operating system that runs on every OpenShift control plane and worker node. It is not a general-purpose Linux distribution — it is a purpose-built, immutable, container-optimised OS designed to run exclusively as a managed node in an OpenShift cluster. Its security posture is architecturally different from a hardened RHEL installation: rather than hardening a mutable system through configuration management, RHCOS makes the OS layer structurally resistant to modification by design. The root filesystem’s /usr tree is read-only (enforced at mount time by rpm-ostree and, in recent versions, by composefs over the OSTree object store), /etc and /var are writable but managed exclusively by the Machine Config Operator (MCO), and no package manager is available at runtime for ad-hoc software installation. An operator who wants to change any node-level configuration — kernel arguments, sysctl settings, systemd units, certificates, kubelet configuration — creates a MachineConfig object in the OpenShift API; the MCO renders it into an Ignition config, applies it to the target MachineConfigPool (master, worker, or custom), and drains and reboots the affected nodes in a rolling fashion. Direct SSH access to nodes for configuration changes is explicitly unsupported and actively discouraged — oc debug node/<name> is the supported emergency access path, dropping into a privileged container on the node’s host namespaces under audit.

RoCE (RDMA over Converged Ethernet)

Mon, 01 Jan 0001 00:00:00 +0000

RoCE (RDMA over Converged Ethernet) implements RDMA semantics on Ethernet (RoCEv2 uses UDP/IP), so NICs can perform remote memory access with low CPU utilization over the same physical switches many enterprises already operate. Its objective is to deliver InfiniBand-like GPU communication economics—fast NCCL all-reduces, NVMe-oF, llm-d KV moves—without maintaining a separate InfiniBand fabric. RoCE requires lossless Ethernet behavior: Priority Flow Control (PFC), Explicit Congestion Notification (ECN), buffer tuning, and often dedicated traffic classes so RDMA traffic is not dropped under burst load.

ROCm (Radeon Open Compute)

Mon, 01 Jan 0001 00:00:00 +0000

ROCm (Radeon Open Compute) is AMD’s software stack for GPU compute on datacenter Instinct accelerators (and select consumer GPUs in community setups). Its objective mirrors CUDA for NVIDIA: provide kernel compilers (HIP), math libraries (rocBLAS, rocFFT), collective communication (RCCL, analogous to NCCL), and framework integrations so PyTorch and inference runtimes can execute training and inference on AMD hardware. ROCm is positioned as an open platform (Linux-first) for customers who want accelerator choice or who standardize on AMD in HPC and AI clusters.

RSA (Rivest–Shamir–Adleman)

Mon, 01 Jan 0001 00:00:00 +0000

RSA (Rivest–Shamir–Adleman), published in 1977, was the first widely adopted public-key cryptosystem and for decades the most deployed asymmetric algorithm in existence. Its security rests on the integer factorisation problem: given a public modulus n = p × q (the product of two large primes), recovering p and q is computationally infeasible on classical computers for sufficiently large n. The public key is the pair (n, e) and the private key is (n, d), where e and d are related by the modular arithmetic of Euler’s totient function. RSA enables two operations: encryption (the sender uses the public key to encrypt a message that only the private key holder can decrypt) and signing (the private key holder produces a signature that anyone with the public key can verify). In practice, RSA encryption is used almost exclusively for key encapsulation — encrypting a randomly generated symmetric key — rather than encrypting arbitrary data directly, both because RSA is slow and because direct RSA encryption of large messages requires padding schemes that are historically error-prone.

SBOM (Software Bill of Materials)

Mon, 01 Jan 0001 00:00:00 +0000

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).

SCC (Security Context Constraints)

Mon, 01 Jan 0001 00:00:00 +0000

Security Context Constraints (SCCs) are OpenShift’s mechanism for controlling and enforcing the security posture of pods at admission time. They predate and are more expressive than Kubernetes PSA: where PSA validates a pod spec against a fixed profile and either admits or rejects it, an SCC acts as both a validator and a mutator — it can inject missing fields into the pod spec (a UID from the namespace’s allocated range, an SELinux context, capability drops) so that a pod that did not specify its full security context in its manifest is brought into compliance automatically rather than rejected. SCCs are cluster-scoped resources, and access to them is controlled via RBAC: a service account must be granted use of an SCC through a Role or ClusterRole binding before pods running under that service account can be admitted with the permissions that SCC grants.

Sealed Secrets

Mon, 01 Jan 0001 00:00:00 +0000

Sealed Secrets is a Kubernetes controller and companion CLI tool (kubeseal) created by Bitnami that solves a specific GitOps problem: how to store Kubernetes Secret manifests in a Git repository without exposing their contents. A standard Kubernetes Secret is base64-encoded, not encrypted — anyone who can read the manifest file or the Git history can decode the values instantly. Sealed Secrets resolves this by encrypting the secret values using asymmetric cryptography before they ever leave the developer’s machine, producing a SealedSecret custom resource that contains only ciphertext and is safe to commit to any repository, public or private. The corresponding plaintext Secret is materialised exclusively inside the cluster by the controller, which holds the only private key capable of decryption.

seccomp (Secure Computing Mode)

Mon, 01 Jan 0001 00:00:00 +0000

seccomp (Secure Computing Mode) is a Linux kernel facility, activated by the seccomp(2) syscall, that restricts which system calls a process may subsequently invoke. In its original SECCOMP_SET_MODE_STRICT form (2005) it was a blunt instrument: the process could call only read, write, _exit, and sigreturn. The operationally useful form is SECCOMP_SET_MODE_FILTER, introduced in kernel 3.5 (2012), which accepts a BPF (classic BPF, predating eBPF) filter program that receives each syscall’s number and arguments and returns one of several verdicts: ALLOW (continue normally), ERRNO (return a specified error to the process), KILL_PROCESS or KILL_THREAD (terminate immediately without giving the process a chance to handle signals), TRAP (deliver SIGSYS), or TRACE (notify a ptracer). Once installed, a seccomp filter cannot be removed, and child processes created by fork() or threads created by clone() inherit it. Filters may only add restrictions, never loosen them — so a chain of filters is the intersection of all their allowlists. The filter runs entirely in the kernel, in BPF bytecode verified for safety, before the syscall implementation is entered, making it extremely low-overhead relative to the security it provides.

Secrets Store CSI Driver

Mon, 01 Jan 0001 00:00:00 +0000

Secrets Store CSI Driver (formally secrets-store.csi.k8s.io) is a Kubernetes SIG Auth project that uses the Container Storage Interface to mount secrets, certificates, and keys from external secret backends directly into pod filesystems as ephemeral tmpfs volumes, bypassing the Kubernetes Secret object and etcd entirely. The driver runs as a DaemonSet on every node; when a pod referencing a CSI volume of type secrets-store.csi.k8s.io is scheduled, the driver communicates with a provider plugin over gRPC to retrieve the secret content from the configured backend, writes it to a per-pod tmpfs mount, and makes it available inside the container at the specified path. When the pod terminates, the tmpfs is unmounted and the data is gone — secrets have no persistence beyond the lifetime of the pod that requested them.

Secure Boot (UEFI Secure Boot)

Mon, 01 Jan 0001 00:00:00 +0000

UEFI Secure Boot is a firmware-level mechanism that ensures each binary executed during the boot process — bootloader, kernel, UEFI drivers — is cryptographically signed by a key the firmware trusts, before it is allowed to run. It is defined in the UEFI specification and implemented by the firmware on virtually all modern x86 and ARM platforms. Its threat model is bootkits and rootkits that install themselves before the OS loads and therefore survive reboots, OS reinstalls, and cannot be detected by any software running after them.

SELinux (Security-Enhanced Linux)

Mon, 01 Jan 0001 00:00:00 +0000

SELinux (Security-Enhanced Linux) is a Mandatory Access Control (MAC) implementation developed by the NSA and released as open source in 2000, merged into the mainline Linux kernel in 2.6 via the LSM framework in 2003. Its defining characteristic is default deny: unlike the standard Linux Discretionary Access Control model (file permission bits), where anything not explicitly forbidden is permitted, SELinux refuses all access that is not explicitly allowed by policy. Every process and every object — every file, socket, pipe, device node, and IPC object — carries a security context (also called a label) of the form user:role:type:level. The policy is a compiled set of rules, loaded at boot, that defines precisely which combinations of process context and object context may interact and how. An Apache web server process running in the httpd_t domain can read files labelled httpd_sys_content_t but is denied access to files labelled user_home_t or shadow_t, regardless of what Unix file permission bits say. If the web server is compromised, the attacker is confined to what httpd_t permits — typically a narrow, well-defined set of files and network operations — rather than having the full access of the user account running Apache.

SEV-SNP (AMD Secure Encrypted Virtualization – Secure Nested Paging)

Mon, 01 Jan 0001 00:00:00 +0000

SEV-SNP is AMD’s third-generation confidential computing technology for EPYC processors, and the generation in production use across major cloud providers (AWS, Google Cloud) and Linux distributions today. It builds on two predecessors: SEV (2016), which encrypted each VM’s memory with a per-VM AES key managed by the AMD Secure Processor, and SEV-ES (2017), which additionally encrypted CPU register state on VM exit to prevent the hypervisor from reading guest execution state. SEV-SNP’s defining addition is memory integrity: using Secure Nested Paging, the firmware enforces that if a guest can read an encrypted memory location, the value returned must be exactly what the guest last wrote there — closing the replay, remap, and memory aliasing attacks that made earlier generations insufficient for a fully untrusted hypervisor threat model.

SHA (Secure Hash Algorithm)

Mon, 01 Jan 0001 00:00:00 +0000

SHA (Secure Hash Algorithm) is the name given to a series of cryptographic hash function families standardised by NIST under FIPS 180 and FIPS 202. Three generations exist with fundamentally different design lineages. SHA-1 (1995, FIPS 180-1) produces a 160-bit digest and is fully broken for collision resistance: the SHAttered attack (Google and CWI Amsterdam, 2017) produced a chosen-prefix collision — two different PDF files with identical SHA-1 hashes — using approximately 9.2 × 10^18 SHA-1 operations, within practical reach of well-resourced attackers. SHA-1 must not be used for any security purpose; it persists only in legacy Git object identifiers (SHA-1 is being phased out in Git’s object store in favour of SHA-256 under the sha256 object format) and in TOTP’s HMAC-SHA-1 inner construction (where collision resistance is not the relevant security property, but migration to SHA-256 variants is still recommended). SHA-2 (2001, FIPS 180-2 and subsequent revisions) is the Merkle-Damgård family that includes SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224, and SHA-512/256. SHA-256 and SHA-512 are the two variants in universal production use; the others serve niche roles. SHA-3 (2015, FIPS 202) is the Keccak sponge construction — structurally independent of SHA-2 — providing algorithm diversity and including fixed-output variants (SHA3-256, SHA3-512) and extendable output functions (SHAKE128, SHAKE256).

SIEM (Security Information and Event Management)

Mon, 01 Jan 0001 00:00:00 +0000

SIEM (Security Information and Event Management) is a platform that aggregates security telemetry from across an organisation’s infrastructure, normalises it into a common schema, applies correlation rules and behavioural analytics to detect threats, and retains the data for investigation and compliance reporting. The name combines two earlier disciplines: SIM (Security Information Management) — long-term log retention, compliance reporting, and forensic search — and SEM (Security Event Management) — real-time alert correlation and incident detection. Modern SIEMs do both simultaneously, serving as the primary visibility layer for a Security Operations Centre (SOC). Leading platforms include Splunk Enterprise Security, IBM QRadar, Microsoft Sentinel, Elastic Security, Exabeam, and LogRhythm; all share the same fundamental architecture despite differing in query language (SPL for Splunk, KQL for Sentinel, EQL/KQL for Elastic, AQL for QRadar), correlation engine design (search-based vs dedicated CEP engine), and deployment model (on-premises, SaaS, or hybrid).

Sigstore

Mon, 01 Jan 0001 00:00:00 +0000

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?”.

SLH-DSA (Stateless Hash-Based Digital Signature Algorithm)

Mon, 01 Jan 0001 00:00:00 +0000

SLH-DSA (Stateless Hash-Based Digital Signature Algorithm), standardised as NIST FIPS 205 in August 2024, is the post-quantum signature standard based on hash functions rather than lattice problems. Where ML-DSA and ML-KEM both rest their security on the hardness of Module Learning With Errors — a relatively young mathematical assumption first formulated in 2005 — SLH-DSA’s security rests exclusively on the collision resistance and preimage resistance of an underlying hash function (SHA-256, SHA-512, or SHAKE, depending on parameter set). Hash function security against quantum computers is well-understood: Grover’s algorithm provides at most a quadratic speedup, which is fully mitigated by doubling output size (SHA-256 remains adequate against classical attacks; SHA-512 provides AES-256-equivalent quantum resistance). The decades-long cryptanalytic confidence in SHA-2 and SHA-3 makes SLH-DSA’s security argument the most conservative available: it requires no new mathematical assumption beyond the hash functions already trusted throughout the entire cryptographic stack.

SLSA (Supply-chain Levels for Software Artifacts)

Mon, 01 Jan 0001 00:00:00 +0000

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.

SOAR (Security Orchestration, Automation and Response)

Mon, 01 Jan 0001 00:00:00 +0000

SOAR (Security Orchestration, Automation and Response) is the actuation complement to a SIEM: where the SIEM detects and alerts, SOAR responds and acts. It receives alerts — primarily from the SIEM, but also directly from EDR platforms, vulnerability scanners, cloud security posture tools, and CNI/container security platforms — and executes structured response playbooks: predefined, branching workflows that enrich the alert with additional context from connected systems, make automated or human-gated decisions based on that context, and issue remediation actions across the organisation’s security tooling. The three pillars of SOAR are orchestration (connecting disparate security tools into a unified, API-driven workflow so they exchange data and coordinate actions without human clipboard-copying), automation (executing repeatable investigation and containment steps at machine speed, consistently and without analyst fatigue), and case management (tracking the full lifecycle of a security incident — detection, triage, investigation, containment, eradication, recovery, and post-incident review — in a structured, auditable record). Leading platforms include Splunk SOAR (formerly Phantom), IBM QRadar SOAR (formerly Resilient), Palo Alto XSOAR (formerly Demisto), Microsoft Sentinel with Playbooks (Logic Apps), and open-source options such as TheHive with Cortex.

SOC (Security Operations Centre)

Mon, 01 Jan 0001 00:00:00 +0000

A SOC (Security Operations Centre) is the organisational function responsible for defending an infrastructure against security threats through continuous monitoring, alert triage, incident investigation, and coordinated response. It is not a single product: it is the combination of people (security analysts operating in tiered roles), processes (runbooks, escalation paths, incident classification, post-incident review), and technology (primarily a SIEM for detection and visibility, a SOAR platform for orchestration and actuation, EDR agents, vulnerability scanners, threat intelligence feeds, and ticketing or case management systems). The SOC’s purpose is to close the loop between something going wrong in the infrastructure and someone doing something about it — with enough structure that the response is consistent, attributable, and auditable regardless of which analyst is on shift. Operating models range from a fully internal 24×7 team, through a virtual SOC (vSOC) sharing analysts across business units, to an outsourced MDR (Managed Detection and Response) or MSSP engagement where a third party operates the SIEM and initial triage on the organisation’s behalf; the technology stack is largely the same across models, but the boundary of who performs each tier of work changes. Analyst tiers are conventionally structured as L1 (alert triage, false-positive filtering, initial enrichment, escalation decisions), L2 (deeper investigation, correlation across data sources, containment recommendations), and L3 (threat hunting, malware reverse engineering, incident lead, playbook authoring, purple-team exercises) — with escalation governed by severity classification (P1–P4 or equivalent), SLA targets for MTTD (Mean Time to Detect) and MTTR (Mean Time to Respond), and documented runbooks that define what each tier may do autonomously versus what requires approval.

SOC 2

Mon, 01 Jan 0001 00:00:00 +0000

SOC 2 (System and Organization Controls 2) is an auditing framework developed by the AICPA (American Institute of Certified Public Accountants). It is not government legislation or a certification scheme but a voluntary attestation standard — however, it has become a de facto market requirement for any technology company, cloud service provider, or SaaS vendor serving enterprise customers, particularly in the US. A SOC 2 report is produced by an independent CPA firm that evaluates an organization’s controls against the AICPA’s Trust Services Criteria (TSC), organized in five categories: Security (mandatory for all SOC 2 reports, covering Common Criteria CC1–CC9), Availability, Processing Integrity, Confidentiality, and Privacy (each optional depending on the organization’s services and customer commitments). The Common Criteria (CC1–CC9) are derived from the COSO Internal Control Framework and cover control environment, risk assessment, monitoring, logical/physical access, system operations, change management, and risk mitigation. There are two report types: Type I (evaluates control design at a point in time) and Type II (evaluates both design and operating effectiveness over 6–12 months — the standard enterprise customers demand). SOC 2 reports are restricted-use documents shared with customers under NDA. While not legally mandatory, major enterprises, financial institutions, and regulated industries routinely require SOC 2 Type II reports from their vendors before signing contracts, making it an essential market-access requirement for technology service providers.

SPIFFE / SPIRE

Mon, 01 Jan 0001 00:00:00 +0000

SPIFFE (Secure Production Identity Framework for Everyone) is a CNCF graduated specification that defines a standard for workload identity: a universal answer to the question “how does a service prove who it is to another service, without a human provisioning a secret?” The core primitives are simple. A SPIFFE ID is a URI of the form spiffe://trust-domain/path that unambiguously names a workload within a trust domain — for example spiffe://prod.example.com/payments/api. A SVID (SPIFFE Verifiable Identity Document) is a cryptographically signed document asserting that SPIFFE ID, in one of two forms: an X.509-SVID, which is a standard X.509 certificate with the SPIFFE ID encoded in the Subject Alternative Name field (used for mTLS), or a JWT-SVID, which is a short-lived JWT bearing the SPIFFE ID as the sub claim (used for service-to-service authentication where TLS termination is handled elsewhere). A trust bundle is the set of CA certificates for a trust domain that relying parties use to validate SVIDs — analogous to a root CA store, but scoped to a SPIFFE trust domain. The Workload API is the local gRPC API through which a workload retrieves its SVID and the trust bundles of domains it needs to communicate with, with automatic rotation before expiry.

SR-IOV

Mon, 01 Jan 0001 00:00:00 +0000

SR-IOV (Single Root I/O Virtualisation) is a PCI-SIG specification that lets one physical PCIe device (typically a NIC or accelerator) expose multiple lightweight Virtual Functions (VFs) — each assignable directly to a VM or container — while a Physical Function (PF) remains for management and global configuration. VFs bypass much of the hypervisor’s software switching path, delivering lower latency, higher throughput, and more deterministic behaviour than paravirtualised virtio alone — properties valued in telco NFV (vEPC, vRAN CU/DU, firewall, DPI) and in cloud-native packet workloads on Kubernetes.

SSH (Secure Shell)

Mon, 01 Jan 0001 00:00:00 +0000

SSH (Secure Shell) is a cryptographic protocol, standardised in RFC 4251–4254, that provides a secure channel over an unsecured network for remote login, remote command execution, file transfer (via SFTP and SCP), and general TCP port forwarding. It replaced the plaintext protocols it was designed to obsolete — Telnet, rlogin, rsh, rcp — by providing mutual authentication and full session encryption. SSH is the universal administrative access mechanism for Linux servers, network devices, and embedded systems, and the transport layer for Git over SSH, Ansible, Fabric, and most configuration management tooling. The protocol stack has three layers: SSH-TRANS (the transport layer — handles the initial key exchange, server authentication, and establishes the encrypted channel), SSH-AUTH (the authentication protocol — authenticates the client to the server using one of several methods), and SSH-CONN (the connection protocol — multiplexes the encrypted channel into multiple logical channels for sessions, port forwards, and X11 forwarding).

SSSD (System Security Services Daemon)

Mon, 01 Jan 0001 00:00:00 +0000

SSSD (System Security Services Daemon) is a multi-daemon suite that connects Linux systems to remote identity and authentication providers, presenting their data through the standard Linux identity interfaces — NSS (Name Service Switch) for identity lookups (user names, UIDs, GIDs, group membership) and PAM (Pluggable Authentication Modules) for authentication and session management — without creating local user accounts. It was originally developed as a component of the FreeIPA project at Red Hat, introduced in Fedora 11 (2009), and quickly became the standard identity integration layer across RHEL, Fedora, Ubuntu, Debian, and most enterprise Linux distributions. Before SSSD, integrating a Linux host with LDAP or AD required configuring nss_ldap, pam_ldap, pam_krb5, and pam_winbind independently — each with its own caching (or lack thereof), its own reconnection logic, and its own configuration syntax. SSSD replaced this collection with a single, unified daemon providing caching, offline authentication, multi-domain support, and access control in one place.

Storage Encryption

Mon, 01 Jan 0001 00:00:00 +0000

Storage encryption is not a single feature but a four-layer decision that must be made independently, because each layer addresses a different adversary and a different failure mode. Layer 1 — disk/OSD at-rest encryption protects against physical media theft: a decommissioned OSD or stolen drive is unreadable without the key. Layer 2 — cluster-internal wire encryption protects against a network-layer attacker who can observe traffic between storage nodes: OSDs, monitors, and clients on the cluster network. Layer 3 — PV/volume-level encryption protects against a storage operator or another tenant reading a workload’s data through the storage system itself — the threat model where the storage cluster is itself potentially untrusted or multi-tenant. Layer 4 — object storage server-side encryption provides per-object key management for S3-compatible workloads, enabling customer-managed keys (CMK) and per-tenant key isolation in object stores. These layers are independent and composable: enabling Layer 1 without Layer 2 protects against physical theft but not a network interceptor; enabling Layer 3 without Layer 1 protects against the storage operator but not physical media extraction. A complete encryption posture addresses all four explicitly, even if some layers are deliberately left disabled with a documented rationale.

Syscall (System Call)

Mon, 01 Jan 0001 00:00:00 +0000

A system call (syscall) is the formal interface through which a user-space process asks the kernel to perform a privileged operation on its behalf — opening a file, allocating memory, creating a process, establishing a network connection, sending a signal, or any other action that requires kernel mediation. User-space code runs at CPU privilege level 3 (ring 3) and cannot directly access hardware, manipulate kernel data structures, or perform I/O; the kernel runs at ring 0 with unrestricted access. A syscall is the crossing point: the process places its request in a defined register convention and issues a syscall instruction (on x86-64) that atomically switches the CPU to ring 0 and transfers control to the kernel’s syscall dispatch table. The kernel validates the request, performs the operation if permitted by standard Unix permissions and any active LSM hooks, and returns the result. From a security perspective, the syscall boundary is the complete list of what a process can ask the kernel to do — and therefore the complete list of operations that security controls like seccomp and BPF LSM can police.

TCB (Trusted Computing Base)

Mon, 01 Jan 0001 00:00:00 +0000

The Trusted Computing Base (TCB) is everything you must trust for your security guarantees to hold: CPU and firmware, the host kernel, the hypervisor, the container runtime, the kubelet, identity and secrets infrastructure, and any management plane that can change workload configuration. If any component in the TCB is buggy, misconfigured, or controlled by an adversary, the whole security argument fails — regardless of how well the application itself is written. The classic design principle is TCB minimisation: keep this set as small as possible, because every added component is another place where a flaw can void your policy. “Trusted” here does not mean “trustworthy in practice”; it means “assumed correct by the security model.”

TDX (Intel Trust Domain Extensions)

Mon, 01 Jan 0001 00:00:00 +0000

Intel Trust Domain Extensions (TDX) is a confidential computing technology built into Intel CPUs that allows entire virtual machines — called Trust Domains (TDs) — to run with hardware-enforced isolation from the host hypervisor, VMM, and any other software on the platform, including privileged system software with administrative access. Unlike SGX, which protects small application-level enclaves, TDX operates at the VM level, making it suitable for lifting existing workloads into a confidential environment without significant code changes.

TEE (Trusted Execution Environment)

Mon, 01 Jan 0001 00:00:00 +0000

A Trusted Execution Environment (TEE) is a hardware-enforced isolated execution context whose confidentiality and integrity are protected by the CPU itself, rather than by software policy. The defining property of a TEE is that its guarantees hold against an adversary with full control of the software stack outside it — the hypervisor, the host operating system, the BIOS firmware, and even a user with physical access to the machine — because the enforcement is implemented in silicon and cannot be overridden by software. Code and data inside a TEE are encrypted in DRAM using a key held within the CPU’s memory controller or on-die security processor, CPU register state is isolated from the host at context switch boundaries, and memory integrity protection prevents the host from replaying, remapping, or aliasing TEE memory pages. The threat model TEEs are designed against is therefore the infrastructure provider: a cloud operator, a data centre staff member, or a co-tenant who controls the hypervisor layer — the party that traditional virtualisation, namespaces, and access control cannot protect against because they depend on a trusted host kernel.

TensorRT

Mon, 01 Jan 0001 00:00:00 +0000

TensorRT is NVIDIA’s SDK for optimizing and deploying trained neural networks for inference on NVIDIA GPUs. Its objective is minimum latency and maximum throughput: it ingests a model (ONNX, TensorFlow, PyTorch export, or framework-specific parsers), applies graph optimizations (layer fusion, constant folding, kernel autotuning), selects precisions (FP32, FP16, INT8, FP8), and produces a serialized engine executed by a lightweight runtime. For LLMs, TensorRT-LLM extends this with attention-specific fusions, inflight batching, and multi-GPU serving patterns; many NIM microservices bundle TensorRT-LLM–optimized engines rather than raw PyTorch loops.

TLS (Transport Layer Security)

Mon, 01 Jan 0001 00:00:00 +0000

TLS (Transport Layer Security) is the protocol that establishes an encrypted, integrity-protected, and authenticated channel between two parties over an untrusted network. It is the successor to SSL (which is deprecated and broken) and the mechanism behind HTTPS, gRPC, LDAPS, SMTPS, database connections, and most other encrypted transport in modern infrastructure. The current version is TLS 1.3 (RFC 8446, 2018); TLS 1.2 remains in wide use but TLS 1.0 and 1.1 are deprecated by RFC 8996. The fundamental security properties TLS provides are: confidentiality (a passive observer cannot read the session content), integrity (an active attacker cannot modify session content without detection), and server authentication (the client can verify it is talking to the intended server rather than an impersonator). Client authentication is optional in standard TLS and is provided by mTLS.

TPM (Trusted Platform Module)

Mon, 01 Jan 0001 00:00:00 +0000

A Trusted Platform Module (TPM) is a tamper-resistant security chip — implemented in hardware (dTPM), firmware (fTPM), or software — that acts as a hardware-anchored root of trust for a system. It provides a secure enclave for generating and storing cryptographic keys, performing cryptographic operations, and recording integrity measurements of the boot process.

Training

Mon, 01 Jan 0001 00:00:00 +0000

Training is the phase of machine learning where model parameters are adjusted to minimize a loss on a dataset. For deep learning, that means repeated forward passes (compute predictions), backward passes (propagate gradients via autodiff), and optimizer steps (update weights)—from scratch pretraining, continued pretraining, or fine-tuning (full, LoRA, or other parameter-efficient methods). The objective is model quality (accuracy, perplexity, task metrics) within a compute and time budget, not millisecond response to end users. Training jobs are batch-oriented: large minibatches, epochs over terabytes of tokens or images, checkpointing to durable storage, and experiment tracking. LLM training at scale uses distributed strategies—data parallel, tensor parallel, pipeline parallel, and expert parallel for MoE—coordinated by frameworks such as PyTorch with FSDP or DeepSpeed.

Trustee

Mon, 01 Jan 0001 00:00:00 +0000

Trustee is the server-side attestation infrastructure for the CoCo (Confidential Containers) project, previously known as CoCo-KBS. It implements the relying-party and verifier roles from the IETF RATS (Remote ATtestation procedureS) architecture: it receives hardware attestation evidence from workloads running inside TEEs, verifies that evidence against known-good reference values, evaluates it against policy, and — if the workload passes — releases the secrets it needs to operate. Trustee runs outside the TEE in a separately trusted environment (a dedicated server, a different confidential VM, or a Kubernetes operator deployment) and is by design not accessible to the untrusted host or hypervisor.

UKI (Unified Kernel Image)

Mon, 01 Jan 0001 00:00:00 +0000

A Unified Kernel Image (UKI) is a single EFI executable that packages together the Linux kernel, the initramfs (initrd), the kernel command line, and optionally other resources like a splash screen or system credentials. Instead of relying on a bootloader to assemble these components at runtime, a UKI bundles them statically into one signed binary.

USBGuard

Mon, 01 Jan 0001 00:00:00 +0000

USBGuard is a security framework for Linux that controls which USB devices are permitted to interact with the system. It sits above the kernel’s native USB authorisation subsystem — a per-device authorisation flag in the USB core that determines whether a device can be configured and begin sending data — and enforces a policy defined in a rule file against every device that connects or is present at startup. The threat model USBGuard addresses is both insider threat (unauthorised storage devices, data exfiltration) and hardware attack: BadUSB devices — malicious firmware embedded in devices that present themselves as HID keyboards, network adapters, or other trusted classes — can be blocked by a sufficiently specific USBGuard policy that restricts which USB interface classes are permitted. A USB device that claims to be a keyboard (03:01:01) but was not explicitly authorised cannot send keystrokes; a USB storage device plugged into a workstation with a policy that only allows a specific keyboard and mouse is blocked outright. USBGuard cannot protect against devices present at boot (before the daemon starts), so it is a defence-in-depth control for the running OS rather than a substitute for physical port security.

Vault (HashiCorp Vault)

Mon, 01 Jan 0001 00:00:00 +0000

HashiCorp Vault is a secrets management platform designed to replace the pattern of static, long-lived credentials scattered across configuration files, environment variables, and CI pipelines with a centralised, policy-enforced, fully audited secrets API. Its core abstraction is that every secret has an identity (a path), an owner (determined by an auth method), a policy (an HCL HashiCorp Configuration Language document granting access to specific paths), and a lease (a TTL after which the secret expires or must be renewed). Nothing in Vault is persistent by default — every access is authenticated, every secret access is logged to an immutable audit trail, and credentials that are no longer needed expire automatically rather than accumulating indefinitely.

VEX (Vulnerability Exploitability eXchange)

Mon, 01 Jan 0001 00:00:00 +0000

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.

vLLM

Mon, 01 Jan 0001 00:00:00 +0000

vLLM is an open-source library and serving stack for large language model (LLM) inference. Its objective is to turn a trained model into a production service that sustains many concurrent users with low latency and high tokens per second per GPU. vLLM targets the inference phase (prefill + decode), not training: it loads weights onto accelerators, batches incoming prompts, schedules decode steps, and streams completions back to clients over HTTP/gRPC (often via an OpenAI-compatible API). It has become a de facto engine behind many private and cloud AI gateways because it ships integrations for Hugging Face models, LoRA adapters, tensor parallelism, pipeline parallelism, speculative decoding, and quantization (GPTQ, AWQ, FP8).

VSA / VS-NfD (German Classified Information)

Mon, 01 Jan 0001 00:00:00 +0000

VS-NfD (Verschlusssache — Nur für den Dienstgebrauch, “Classified — For Official Use Only”) is the lowest of Germany’s four classification levels (VS-NfD, VS-Vertraulich, Geheim, Streng Geheim). The legal and regulatory framework governing its handling consists of the Sicherheitsüberprüfungsgesetz (SÜG) as the legal basis, the Verschlusssachenanweisung (VSA) as the administrative directive for federal agencies (fundamentally revised in 2023), and the VS-NfD-Merkblatt (Annex 4 to the Geheimschutzhandbuch) for private-sector companies handling classified contracts. The framework is administered by the BSI for IT security aspects and the BMWK (Federal Ministry for Economic Affairs) for industrial security (Geheimschutz in der Wirtschaft). Compliance is absolutely mandatory — it is a legal obligation under the SÜG, and failure to comply results in loss of the ability to participate in classified government contracts. Key IT requirements include: using exclusively BSI-approved (zugelassen) IT security products listed in the VS-Produktkatalog (BSI-Schrift 7164) for encryption, VPN, and security-critical functions; implementing an information security concept based on BSI IT-Grundschutz (including risk analysis and Grundschutz-Check); applying the multi-layered security principle (prevention, detection, reaction); and personnel security clearances under the SÜG. Since 1 September 2025, a mandatory self-accreditation (Selbstakkreditierung) obligation entered into force: every three years, the VS-NfD-responsible person must formally confirm to their management (and on request to the BMWK or the contracting authority) that all technical and organizational measures are fully implemented. The BSI’s IT-Grundschutz module CON.11.1 specifically addresses VS-NfD requirements that go beyond standard IT-Grundschutz measures.

WireGuard

Mon, 01 Jan 0001 00:00:00 +0000

WireGuard is a VPN protocol and implementation designed by Jason Donenfeld, merged into the Linux kernel in 5.6 (2020) and subsequently ported to Windows, macOS, iOS, Android, and BSD. Its defining characteristic is radical simplicity: the reference Linux kernel implementation is approximately 4,000 lines of code, compared to tens of thousands for IPsec’s XFRM subsystem and hundreds of thousands for OpenVPN. This simplicity is a deliberate security property — a smaller codebase has a smaller attack surface, is easier to audit, and is less likely to contain implementation vulnerabilities. WireGuard achieves this by making every design decision that allows optionality to be eliminated: there is no algorithm negotiation, no handshake negotiation, no cipher suite selection. The cryptographic suite is fixed: X25519 for key exchange, ChaCha20-Poly1305 for authenticated encryption, BLAKE2s for hashing and key derivation (via a custom HKDF-like construction), and Curve25519 for the static key pairs that identify peers. Peers are identified exclusively by their 32-byte Curve25519 public key, making WireGuard a public-key routed VPN: there are no usernames, passwords, certificates, or CAs; access control is entirely a function of which public keys are listed in each peer’s configuration.

X.509

Mon, 01 Jan 0001 00:00:00 +0000

X.509 is the ITU-T standard (first published in 1988, currently at version 3) that defines the structure of a digital certificate: a signed data structure that binds a public key to an identity and a set of constraints, issued by a Certificate Authority whose signature vouches for the binding. It is the near-universal format for certificates in PKI, TLS, code signing, S/MIME encrypted email, SPIFFE X.509-SVIDs, and SSH host certificates. When someone refers to a TLS certificate, a CA certificate, or a code-signing certificate, they are referring to an X.509 certificate. The format is defined using ASN.1 (Abstract Syntax Notation One) and most commonly serialised as DER (Distinguished Encoding Rules, binary) or PEM (base64-wrapped DER with -----BEGIN CERTIFICATE----- headers, the format seen in most configuration files).