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).
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.”
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.
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.
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).
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.
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.
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.
SLSA (Supply-chain Levels for Software Artifacts), pronounced “salsa”, is a security framework published by OpenSSF (originally proposed by Google in 2021, version 1.0 released April 2023) that defines progressively stronger requirements for build integrity and provenance — the verifiable record of where a software artifact came from, what source it was built from, how it was built, and what the build environment looked like. The motivating threat is supply chain attacks like SolarWinds (malicious code injected into the build system) and XZ Utils (malicious code injected into the source repository): in both cases the artifact that reached users was not what the source code claimed, and consumers had no way to verify the discrepancy. SLSA’s answer is a provenance attestation: a signed, machine-readable document produced by the build platform that records the source repository and commit, the build instructions, the builder’s identity, the build environment’s properties, and the digest of the resulting artifact. Signed provenance is the basis on which consumers can make automated trust decisions rather than relying on reputation or manual inspection.
Sigstore is an OpenSSF project, initiated by Google, Red Hat, and Purdue University, that provides a free public-good infrastructure for cryptographically signing software artifacts — container images, binaries, SBOMs, attestations — without the operational burden of managing long-lived private keys. Its founding insight is that the two hardest problems in code signing are key management (generating, protecting, distributing, rotating, and revoking signing keys across thousands of developers and CI pipelines) and signature discoverability (how does a verifier find and trust the correct public key for an artifact it has never seen before). Sigstore solves both by eliminating long-lived keys entirely: every signing operation generates a fresh ephemeral key pair, uses it once, discards the private key, and records the event in a public transparency log — replacing “do you trust this key?” with “do you trust this identity at this moment in time?”.
