Head of Product
Camila Bedretchuk
Introduction
In technology, it is almost impossible to escape the well-known “acronym soup.”
When the topic is software supply chain, even more terms, acronyms, and concepts emerge in discussions of security, risk management, cloud, and software development.
With this in mind, we have created this QUOR security software supply chain glossary: a selection of the most used terms in daily discussions 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 that, when it makes sense, are connected to the way QUOR perceives and addresses these topics.
In summary, it is a quick reference to support meetings or to share with teams and colleagues whenever the question arises: “what does that really mean?”.
Index
1. Kubernetes Fundamentals and Workloads
Kubernetes (cluster / multicluster)
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 another for applications.
Multicluster is an operational strategy in which more than one Kubernetes cluster is managed in a coordinated manner, allowing applications to be transparently distributed among them.
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 resources from the cluster (CPU, memory, network) to deliver a business capability. When we talk about “protecting the workload,” we are talking about protecting that application in production: image, configuration, and runtime.
2. Container Images and Registries
Container Image
An immutable package (in the OCI standard) that can contain the filesystem, binaries, libraries, and metadata needed to run a process in a container.
It is versioned (by tags or digest) and portable between registries, clusters, and cloud providers. When deploying a workload on Kubernetes, this image is what will be obtained from the registry and executed 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 the organization's “official” 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, as multiple workloads start to share a common and secure base image.
Hardened Image
A container image built with a focus on security, typically with the following characteristics:
Minimal Surface: absence of shell, debugging tools, and unnecessary runtimes;
Reduced Set of Packages: only what is strictly necessary for the application;
Applied Security Patches regularly;
Configured according to 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 the layers (layers) to the environment that executes 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)
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, that is, registries authorized as the official source of images for production environments. In them, the organization can apply policies such as: “only images from QUOR are accepted in the cluster.”
In more mature security strategies, it is common to restrict the use of public registries directly in production, favoring trusted (controlled) registries.
Runtime / Shell in Image
Components present in the image, such as bash, diagnostic tools, full interpreters, or generic runtimes.
In many traditional bases, these components come embedded by default. When they are not needed for the application's operation, remove them:
Reduces the attack surface;
Decreases image size;
Reduces the number of packages subject to vulnerabilities (CVEs).
Tag latest
A mutable label that generally points to the most recently published version of an image. It is practical in development environments but not well-suited for production because:
It is non-deterministic (it may point to different images over time);
It complicates auditing and traceability of incidents;
It obscures the version actually used.
Therefore, it is recommended to use immutable tags (for example, app:1.4.3) or digests (@sha256:...) in critical environments.
3. Software Supply Chain Security
Cryptographic Signature of Images
The process of d digitally signing an image (or its manifest) to ensure:
Integrity: the content has not been altered since the signature;
Authorship: who published that image (identity or system).
Tools like Sigstore/Cosign allow 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:
Source repository and reference commit;
Build pipeline and environment;
Dependencies used;
Identity of who triggered or approved the process.
Provenance is a pillar of software supply chain security: it allows tracing the reliability of an artifact back to its origin.
SLSA (Supply-chain Levels for Software Artifacts)
Security framework for the software supply chain that defines assurance levels for artifacts, focusing on protecting the build process, the provenance, and the integrity of the software.
It establishes progressive requirements (SLSA levels) to reduce the risk of tampering in pipelines, strengthen origin traceability, and make software artifacts more reliable throughout the chain.
SBOM (Software Bill of Materials) [es-bom]
Structured inventory of all software components (libraries, frameworks, packages, versions, licenses) used to build an application or image.
It functions as a “label of ingredients” of the software and is essential for:
Quickly identifying if a vulnerable component is present;
Assessing the impact of new CVEs;
Meeting regulatory and auditing requirements;
Managing risks of 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 environment.
The focus is to preserve integrity, confidentiality, and availability of the software, preventing vulnerabilities or malicious code from being introduced into the chain and reaching production.
Security by design
Principle of designing systems, applications, and infrastructure with security built-in from the conception, not as a component to be added later, but as an intrinsic feature of the design.
In the context of software supply chain security, it involves considering threats, controls, and protection requirements already in the definition of architecture, choice of technologies, build pipelines, base images, and dependence usage policies.
The use of a catalog of secure base images, such as QUOR, is an example of a decision aligned with the principle of security by design in the software supply chain.
Shift-left (in security)
Practice of bringing security activities to earlier stages of the development cycle, rather than 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 to fix vulnerabilities and supporting DevSecOps approaches.
Read more: Shift-Left and Economy: Why Fixing Early 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 particular 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 Clients
Layered Hardening
Incremental approach to strengthening images and environments. Instead of trying to “harden everything at once,” you apply successive layers of protection, for example:
Choose a leaner and more secure baseline;
Remove unused packages and functionalities;
Adjust runtime settings (non-root user, minimal capabilities, filesystem read-only, etc.);
Reinforce cluster policies (admission, network policies, quotas);
Continuously monitor for vulnerabilities and misconfigurations.
Each layer reduces the attack surface and increases resilience.
Pareto 80/20 (in the context of CVEs)
Application of 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 significant portion of the benefit (substantial reduction of CVEs) focusing on 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 “doormen” that can:
Validate if the object follows the policies (e.g., image must be signed and come from QUOR);
Mutate the object (inject default configurations, sidecars, labels, etc.);
Or block the deploy if something is out of standard.
They are a key point for applying software supply chain security directly at the cluster.
Recurrence of CVEs
When the same vulnerability (same CVE ID) reappears in multiple images and workloads.
This multiplies cost and risk because:
It makes triage redundant (same analysis repeated dozens of times);
Spreads the impact of a single flaw throughout the environment;
Increases the effort of correction and coordination between teams.
Acting on 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 there is still no fix available or which is not yet known to the software vendor, but which can already be exploited by attackers.
Zero CVE (at the time of deployment)
State in which, at the time of deploy, the image has no known vulnerabilities in the reference bases consulted by the scanner (like NVD and others).
Important:
Does not mean the image is “forever faultless”;
Means that, at the time of deployment, there are no known public CVEs associated with the components of that image.
Read more: Do you know what a CVE is? And what it can do to your product strategy?
5. Continuous Operation and Update Practices
Daily Builds (Build Cadence)
Routine of generating new builds and images at a fixed frequency (for example, daily), incorporating patches and updates of dependencies with explicit versioning.
This reduces the exposure window to newly disclosed vulnerabilities and facilitates automating the path: “new CVE → fix applied to base → new image → re-deploy.”
Backward Compatibility
Property of a new version of software (or base image) to maintain the expected behavior of previous application versions that depend on it.
In the context of QUOR, it means that updating to a more recent hardened image should not break your applications, as long as they use supported interfaces and contracts. This increases confidence to apply updates more frequently.
MTTR (Mean Time to Repair)
Average time between the identification of a vulnerability and the elimination of the risk in production (fix applied and corrected version deployed).
In the context of the software supply chain, it encompasses the stages of detection, analysis, prioritization, implementation of the fix, and redeployment.
QUOR contributes to the reduction of MTTR by reducing the volume and recurrence of vulnerabilities in base images, which simplifies prioritization and speeds up the correction process.
Re-deploy
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-deploy does the risk associated with that vulnerable image really decrease in production.
6. Risk, Financial Impact, and Compliance
Audit and Regulatory Compliance
Ability to demonstrate, to auditors and regulators (e.g., BACEN, LGPD, SOX, PCI DSS), that the organization:
Controls the origin and lifecycle of images (provenance, signature, secure baseline);
Knows the components used (SBOM);
Monitors and addresses vulnerabilities in a timeframe compatible with the criticality;
Maintains evidence trails (logs, policies, deployment, and correction records).
QUOR supports this governance by standardizing images, exposing provenance/SBOM, and facilitating the generation of consistent evidence.
ARO (Annualized Rate of Occurrence)
Expected annual frequency of a type of incident (how many times, on average, occurs per year).
Examples: 1 time a year → ARO = 1.0; 1 time every 2 years → ARO = 0.5.
SLE (Single Loss Expectancy)
Expected loss in a single incident of that type, usually expressed in financial value (direct and indirect costs).
ALE (Annualized Loss Expectancy)
Expected annual loss associated with a type of incident.
Formula: ALE = ARO × SLE.
SCF (Supply Chain Factor)
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
Approach in which vulnerabilities are addressed after detection in production, with a large volume of alerts, recurring triage, and corrections distributed across multiple applications and images.
QUOR Model (Preventive)
Approach that focuses on preventing vulnerabilities (CVEs) from reaching production environments. Workloads are built from hardened base images, with provenance, SBOM, and the criterion of Zero CVE at the time of deployment, which reduces:
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 to prove adherence to regulatory and auditing requirements.
QUOR
Catalog of secure container images operated by Getup, aimed at companies that use Kubernetes and need to reduce the attack surface without increasing complexity for their teams.
The architecture of QUOR is composed of two main components:
Catalog (private registry compatible with OCI)
A set of hardened base images, rebuilt frequently whenever new vulnerabilities are detected. Each image includes, in a standardized manner:
Cryptographic signature (Cosign);
SBOM (CycloneDX or SPDX);
Origin traceability aligned with best practices like SLSA.
The result is Zero CVE images, suitable for critical and regulated environments.
Web Console (SaaS)
Interface for:
Navigating and filtering the image catalog;
Consulting update history and metadata;
Managing access and tokens;
Configuring integrations and notifications (e.g., alerting a team when a critical vulnerability is fixed).
Conceptually, QUOR acts as a secure foundation of the software supply chain, standardizing the baseline of images and supporting compliance with security, governance, and compliance requirements.
Final Considerations
This glossary arises from the conversations we have with our clients and teams: recurring doubts, architectural decisions, and discussions about risk, governance, and operation in Kubernetes.
We believe that it helps to create a common language about the software supply chain and security and will be continually enriched as new practices, learnings, and needs arise around QUOR.
Quor Newsletter
With Quor, security becomes your competitive edge. See how in a personalized demo.