Automated Gatekeeping

In modern CI/CD pipelines, fast release frequency is often considered the primary success metric. However, for platform operators and software providers in regulated markets, this unchecked dynamism increasingly leads to severe security risks: When external base images, third-party libraries, and ephemeral dependencies are rolled out uncontrollably into production clusters, the software supply chain becomes an unpredictable entry point for attackers. The binding requirements of the NIS-2 directive and the Digital Operational Resilience Act (DORA) therefore demand a fundamental shift in direction—away from trusting deployments, towards a seamlessly verifiable software supply chain security.

A robust security strategy does not rely on manual checks or subsequent audits but enforces compliance as an integral part of the deployment chain. Through Automated Gatekeeping based on a private enterprise container registry (Harbor), automated vulnerability scans, machine-readable Software Bill of Materials (SBOMs), and strict admission control rules, ayedo ensures that vulnerable or unsecured Container artifacts never reach the cluster.

The Problem: The Underestimated Entry Points of Modern Container Supply Chains

The practice of modern Cloud-Native development is based on over 80% open-source components and pre-built base images. Without automated control mechanisms, three critical vulnerabilities arise in the operational process:

1. The Blind Flight Risk from Transitive Dependencies

Developers often integrate external libraries and base images without deeper inspection. Known security vulnerabilities (CVEs) often hide in deeply nested, transitive dependencies. Without automated deep inspection, these vulnerabilities are deployed directly into the production environment, where they are only noticed after a successful security incident or during external audits.

2. The Failure in Comprehensive Component Inventory

Both NIS-2 and DORA demand exact transparency over all deployed software artifacts. If applications are delivered without standardized Software Bill of Materials (SBOM), companies cannot immediately determine which microservices, versions, or customer namespaces are specifically affected when new zero-day vulnerabilities become known. This leads to fatal delays in threat response.

3. The Failure of Purely Reactive Patch Processes

The traditional principle of “build, deploy, and patch later” collapses under the sheer volume of daily security alerts. Without systemic enforcement (policy enforcement) at the interface between registry and Kubernetes cluster, containers with critical vulnerabilities often remain in live operation for weeks because operational teams must prioritize in daily business.

The Solution: The Architecture of Automated Security Gatekeeping

ayedo establishes a multi-stage DevSecOps pipeline that isolates, analyzes, inventories, and validates each container image before execution using cryptographic signatures.

1. The Isolated Enterprise Registry with Automated CVE Scanning

The central entry point is a hardened Harbor instance on European infrastructure. With each push of a new container image, the system automatically initiates static vulnerability analyses via integrated scanners like Trivy. The results are matched against global CVE databases and classified with standardized severity levels (CVSS).

2. Automated SBOM Generation and Crypto-Signing

Parallel to the scanning process, the pipeline generates a complete, machine-readable Software Bill of Materials for each build artifact in the standardized SPDX or CycloneDX format. After successful verification, the image is cryptographically signed via Cosign/Sigstore. This signature acts as an immutable trust seal for the integrity of the entire supply chain.

3. Admission Control Gatekeeping at the Cluster Level

In the Kubernetes cluster, Validating Admission Webhooks (e.g., via Kyverno or OPA/Gatekeeper) act as incorruptible control instances. If a deployment attempts to start an image without a valid signature or with CVE values above the defined thresholds (e.g., no unresolved CRITICAL findings), the API server blocks execution at the kernel level and deterministically denies pod creation.

Strategic and Economic Benefits

• 100% Compliance with NIS-2 and DORA Due Diligence: The combination of automatic SBOM creation and seamless CVE tracking meets the highest regulatory requirements for supply chain risk management and provides auditable reports at the push of a button.
• Radical Reduction of the Attack Surface in Live Operation: By proactively blocking compromised artifacts, zero-day and supply chain attacks are stopped before malicious code can even gain network access or persistence in the cluster.
• Massive Relief for Security and Platform Teams: Policy-based gates standardize the approval process, eliminate time-consuming manual approval loops, and enable developers to work securely in true self-service.
• Complete Data Sovereignty without US SaaS Dependencies: The entire registry and scanning infrastructure operates on certified servers in European data centers, protecting proprietary source code and internal vulnerability metadata from third-party access.

Conclusion

Security in the software supply chain must not be a theoretical guiding principle that is only tested after security incidents. Those responsible for modern platform operations must embed security policies directly into the deployment mechanics. Automated gatekeeping based on open standards transforms the software supply chain from a latent liability risk into a robust foundation for digital resilience, regulatory sovereignty, and sustainable market growth.

Frequently Asked Questions (FAQ)

How does the system handle zero-day vulnerabilities that become known only after an image is deployed? Harbor conducts continuous background scans for already stored images as soon as new CVE definitions are added to the databases. If an already running image is subsequently classified as critical, the system reports the status to the central observability stack (VictoriaMetrics/Alertmanager). At the same time, the admission controllers prevent further pods of this affected image from being started in the cluster during a restart or horizontal scaling operation (HPA).

Do strict CVE gates block productive operations if no upstream fix exists for a critical vulnerability? No. The governance engine supports controlled exception management (Vulnerability Exceptions / VEX). If no patch is available for a discovered vulnerability, but the risk is isolated through compensating measures (such as Cilium L7 network policies), a temporary, audit-proof documented bypass certificate can be issued. The four-eyes principle remains fully traceable in the Git audit trail.

What performance impacts occur during CI/CD deployments due to the validating webhooks? The latency is negligible. Since the time-intensive scan and signing process occurs asynchronously in the registry during the build push, the admission webhook during deployment in the Kubernetes cluster only checks the cryptographic signature and the available metadata. This validation takes only a few milliseconds and does not affect rollout speed or regular API server throughput.