We have gathered in a single glossary the terms that most frequently appear in conversations about Kubernetes security.
Head of Product
Camila Bedretchuk
Introduction
In technology, it is almost impossible to escape the well-known "alphabet soup".
When it comes to the software supply chain, even more terms, acronyms, and concepts emerge in discussions about security, risk management, cloud, and software development.
With that in mind, we put together this software supply chain security glossary QUOR version: a selection of the most commonly used terms on a daily basis when talking about Kubernetes, container images, vulnerabilities, provenance, SBOM, registries, and other elements of this universe.
The goal is not to be academic, but to offer clear definitions and, where it makes sense, connect them to how QUOR views and addresses these topics.
In short, it is a quick reference to support meetings or to share with teams and colleagues whenever the question arises: "what does this mean again?".
Table of Contents
1. Kubernetes and Workload Fundamentals
Kubernetes (cluster / multicluster)
An open-source platform that orchestrates containers, automating deployment, scaling, and management of workloads.
A Kubernetes cluster is a set of nodes (machines) divided into two main groups, one for management and the other for applications.
Multicluster is an operational strategy where more than one Kubernetes cluster is managed in a coordinated way, allowing applications to be distributed among them transparently.
Workload
An application or service running on Kubernetes, described by objects such as Deployments, StatefulSets, Jobs, etc.
It is the logical unit of execution that consumes cluster resources (CPU, memory, network) to deliver business value. When we talk about "protecting the workload," we are talking about protecting this application in production: image, configuration, and runtime.
2. Container Images and Registries
Container image
An immutable package (in OCI standard) that can contain the filesystem, binaries, libraries, and metadata necessary for running a container process.
It is versionable (by tags or digests) and portable across registries, clusters, and cloud providers. When deploying a workload in Kubernetes, this is the image that will be retrieved from the registry and run as a container.
Read more: Not All Inheritance Is Good: The Risk of Container Images
Secure image baseline
A standardized, versioned, and approved set of "official" organization images.
These images serve as a corporate reference for new services (for example, QUOR images of languages and frameworks), reducing variation, risk, and recurrence of CVEs, since multiple workloads start to share a common and secure base image.
Hardened image
A container image built with security in mind, typically featuring the following characteristics:
Minimal attack surface: absence of a shell, debug tools, and unnecessary runtimes;
Reduced set of packages: only what is strictly necessary for the application;
Security fixes applied on a recurring basis;
Configurations aligned with best practices, such as running with a non-root user and minimal permissions.
The goal is to reduce the attack surface and the likelihood of exploitable vulnerabilities.
Image pull
The operation of obtaining an image from a registry, transferring the manifest and layers (layers) to the environment executing the command (developer's machine, cluster node, automation pipeline, or another registry in mirroring scenarios).
The pull command references the image by tag or digest.
Registry (public / private)
A service responsible for storing and distributing container images and other OCI artifacts.
Public registry: maintained by third parties and accessible via the internet (for example, Docker Hub, GHCR, ECR, Quay).
Private registry: controlled by the organization (internal registry, Harbor, Artifact Registry, etc.), with its own access, auditing, and mirroring policies.
A common practice is to define one or more trusted registries, meaning registries authorized as official sources of images for production environments. In them, the organization can apply policies such as: "only images originating from QUOR are accepted in the cluster".
In more mature security strategies, it is common to restrict the direct use of public registries in production, privileging trusted (controlled) registries.
Runtime / shell in the image
Components present in the image, such as bash, diagnostic tools, full interpreters, or generic runtimes.
In many traditional bases, these components are built-in by default. When they are not needed for application operation, removing them:
Reduces the attack surface;
Decreases image size;
Reduces the number of packages subject to vulnerabilities (CVEs).
Tag latest
A mutable label that typically points to the most recently published version of an image. It is practical in development environments but not suitable for production because:
It is non-deterministic (it can point to different images over time);
It makes auditing and incident traceability difficult;
It hides the version actually being used.
Therefore, using immutable tags (for example, app:1.4.3) or digests (@sha256:...) in critical environments is recommended.
3. Software supply chain security
Cryptographic signing of images
The process of digitally signing an image (or its manifest) to ensure:
Integrity: the content has not been altered since it was signed;
Authorship: who published that image (identity or system).
Tools like Sigstore/Cosign allow for signing and verifying images, integrating this verification into admission policies and CI/CD pipelines.
Provenance (software provenance)
A set of verifiable information about how, where, when, and with what inputs a software artifact was built.
It includes, for example:
Origin repository and reference commit;
Pipeline and build environment;
Dependencies used;
The identity of whoever triggered or approved the process.
Provenance is a pillar of software supply chain security: it allows you to track the reliability of an artifact back to its origin.
SLSA (Supply-chain Levels for Software Artifacts)
A security framework for software supply chains that defines assurance levels for artifacts, with a focus on protecting the build process, provenance, and software integrity.
It establishes progressive requirements (SLSA levels) to reduce the risk of tampering in pipelines, strengthen source traceability, and make software artifacts more reliable throughout the entire chain.
SBOM (Software Bill of Materials)
A structured inventory of all software components (libraries, frameworks, packages, versions, licenses) used to build an application or image.
It acts as an "ingredients label" for the software and is fundamental to:
Quickly identifying if a vulnerable component is present;
Assessing the impact of new CVEs;
Meeting regulatory and compliance audit requirements;
Managing risks in the dependency chain.
Software supply chain security
A set of practices, controls, and tools aimed at protecting the entire software delivery chain, from code to production environments.
The focus is on preserving integrity, confidentiality, and availability of the software, preventing vulnerabilities or malicious code from being introduced into the chain and reaching production.
Security by design
The principle of designing systems, applications, and infrastructure with security built-in from the conception phase, not as a component to be added later, but as an intrinsic characteristic of the project.
In the context of software supply chain security, this involves considering threats, controls, and protection requirements starting from architectural definitions, technology choices, build pipelines, base images, and dependency usage policies.
The use of a secure base image catalog, like QUOR, is an example of a decision aligned with the security by design principle in the software supply chain.
Shift-left (in security)
The practice of moving security activities to earlier stages of the development lifecycle, instead of concentrating detection only in production.
In software supply chain security, this includes validating dependencies, images, and configurations during the build and continuous integration (CI) phases, reducing the cost and time of vulnerability remediation and supporting DevSecOps approaches.
Read more: Shift-Left and Economics: Why Fixing Earlier Is Cheaper
4. Vulnerabilities and technical controls
CVE (Common Vulnerabilities and Exposures)
A standardized public identifier for software vulnerabilities.
Each CVE has a unique ID (e.g., CVE-2025-12345) and a description that allows the industry to speak "the same language" about a given flaw. Databases like NVD, among others, index CVEs and are used by vulnerability scanners.
Read more: The Challenge of Vulnerability Management [CVEs]: Insights from Getup Customers
Layered hardening
An incremental approach to strengthening images and environments. Instead of attempting to "harden everything at once," you apply successive security layers, for example:
Choosing a lean and safer baseline;
Removing unused packages and features;
Adjusting runtime configurations (non-root user, minimal capabilities, read-only filesystem, etc.);
Reinforcing cluster policies (admission, network policies, quotas);
Continuously monitoring for vulnerabilities and misconfigurations.
Each layer reduces the attack surface and increases resilience.
Pareto 80/20 (in the context of CVEs)
Applying the Pareto principle to image security: a small fraction of images (for example, the most popular bases) concentrates most of the vulnerabilities, effort, and cost.
By addressing this "core 20%" with hardened QUOR images, it is possible to capture a large part of the benefit (significant reduction of CVEs) by focusing on just a few artifacts.
Admission Policies (Admission Policies/Controllers)
Kubernetes mechanisms that intercept requests to the cluster API after authentication/authorization, but before the object is persisted.
They serve as "gatekeepers" that can:
Validate if the object complies with policies (e.g., image must be signed and come from QUOR);
Mutate the object (inject default settings, sidecars, labels, etc.);
Or block the deployment if something is non-compliant.
They are a key point for applying software supply chain security directly in the cluster.
Recurrence of CVEs
When the same vulnerability (same CVE ID) reappears across multiple images and workloads.
This multiplies cost and risk because:
It makes triage redundant (the same analysis repeated dozens of times);
It spreads the impact of a single flaw throughout the entire environment;
It increases the remediation and coordination effort among teams.
Addressing the base image (e.g., via QUOR) drastically reduces recurrence, as a single fix benefits multiple services.
Zero-day (zero-day vulnerability)
A vulnerability for which no fix is yet available or that is not yet known by the software vendor, but can already be exploited by attackers.
Zero CVE (at deploy time)
A state where, at the moment of deployment, the image has no known vulnerabilities in the reference databases queried by the scanner (such as NVD and others).
Important:
It does not mean the image is "forever free of flaws";
It means that, at deploy time, there are no known public CVEs associated with the components of that image.
Read more: Do you know what a CVE is? And what can it do to your product strategy?
5. Continuous operations and update practices
Daily builds (build cadence)
A routine of generating new compilations and images at a fixed frequency (for example, daily), incorporating patches and dependency updates with explicit versioning.
This reduces the window of exposure to newly disclosed vulnerabilities and makes it easier to automate the path: "new CVE → fix applied to base → new image → re-deployment".
Backward compatibility
The property of a new software version (or base image) to maintain the behavior expected by previous versions of applications that depend on it.
In the context of QUOR, this means that updating to a newer hardened image should not break your applications, as long as they use supported interfaces and contracts. This increases confidence in applying updates more frequently.
MTTR (Mean Time to Repair)
The average time between identifying a vulnerability and eliminating the risk in production (remediation applied and fixed version deployed).
In the context of the software chain, this covers the stages of detection, analysis, prioritization, implementation of the fix, and re-deployment.
QUOR contributes to reducing MTTR by decreasing the volume and recurrence of vulnerabilities in base images, which simplifies prioritization and speeds up the remediation process.
Re-deployment
A new deployment of a workload pointing to an updated image (by version tag or digest).
This is the final step of remediation: only after a successful re-deployment does the risk associated with that vulnerable image actually decrease in production.
6. Risk, financial impact, and compliance
Auditing and regulatory compliance
The ability to demonstrate to auditors and regulators (for example, BACEN, LGPD, SOX, PCI DSS) that the organization:
Controls the source and lifecycle of images (provenance, signing, secure baseline);
Knows the components used (SBOM);
Monitors and addresses vulnerabilities within a timeframe compatible with their criticality;
Maintains evidence trails (logs, policies, deployment and remediation records).
QUOR supports this governance by normalizing images, exposing provenance/SBOM, and making it easier to generate consistent evidence.
ARO (Annualized Rate of Occurrence)
The expected annual frequency of a type of incident (how many times on average it occurs per year).
Examples: 1 time per year → ARO = 1.0; 1 time every 2 years → ARO = 0.5.
SLE (Single Loss Expectancy)
The expected loss from a single incident of that type, typically expressed in financial terms (direct and indirect costs).
ALE (Annualized Loss Expectancy)
The expected annual loss associated with a type of incident.
Formula: ALE = ARO × SLE.
SCF (Supply Chain Factor)
The fraction of total risk (ALE) specifically attributed to the software supply chain.
Example: SCF = 0.20 indicates that 20% of the expected annual loss comes from supply chain issues (images, dependencies, builds, registries, etc.).
7. QUOR-specific concepts
Reactive model vs. QUOR (prevention)
Reactive model
An approach in which vulnerabilities are addressed after detection in production, resulting in a large volume of alerts, recurring triage, and fixes distributed across multiple applications and images.
QUOR model (preventative)
An approach centered on preventing vulnerabilities (CVEs) from reaching production environments. Workloads are built starting from hardened base images, with provenance, SBOM, and a Zero CVE criteria at deploy time, reducing:
The volume of vulnerabilities in production;
The attack surface (smaller surface, lower probability of incidents);
The operational cost of analyzing and fixing CVEs;
The effort required to prove adherence to regulatory and compliance requirements.
QUOR
A catalog of secure container images operated by Getup, designed for companies that use Kubernetes and need to reduce their attack surface without increasing complexity for their teams.
The QUOR architecture is composed of two main components:
Catalog (OCI-compliant private registry)
A set of hardened base images, rebuilt frequently whenever new vulnerabilities are detected. Each image includes, in a standardized manner:
Cryptographic signing (Cosign);
SBOM (CycloneDX or SPDX);
Source predictability aligned with best practices like SLSA.
The result is Zero CVE images, suitable for critical and regulated environments.
Web console (SaaS)
An interface to:
Browse and filter the image catalog;
Consult update histories and metadata;
Manage credentials and tokens;
Configure integrations and notifications (for example, alert a team when a critical vulnerability is remediated).
Conceptually, QUOR acts as the secure foundation of the software supply chain, organizing the image baseline and supporting the fulfillment of security, governance, and compliance requirements.
Concluding comments
This glossary stems from the conversations we have with our customers and teams: recurring questions, architectural decisions, and discussions about risk, governance, and operation in Kubernetes.
We believe it helps create a common language surrounding software supply chain security and will be continuously enriched as new practices, learnings, and needs arise around QUOR.
Operating Kubernetes in production for more than 13 years. With Quor, this experience extends to software supply chain security as well.
GET UP
© Getup · 2026
