Secure Container Image Building with SBOM and Cosign

The challenge of invisibility in container images

When we package an application to run in the cloud, we rarely write every single line of code or build every library from scratch. We use base images like Alpine or Ubuntu and layer dozens of third-party packages on top. In practice, this means a simple Dockerfile can carry hundreds of hidden vulnerabilities inherited from dependencies that no one on the team remembers installing. Without rigorous inspection, the production environment becomes a black box vulnerable to silent attacks.

To solve this opacity, we need to change how we approach the build process. Security cannot just be a test run at the end of the development cycle; it must be an integral part of the infrastructure foundation. This is where two fundamental technologies come into play: the SBOM, which acts as the detailed ingredient list of our software package, and cryptographic signing, which seals the package to guarantee its authenticity before it crosses the border into production servers.

Understanding SBOM as a traceability recipe

The acronym SBOM stands for Software Bill of Materials. Think of it as a medicine leaflet or the nutritional label on an industrially processed food item: it transparently lists every library, module, and dependency contained inside the container, specifying the exact versions of each item. Modern tools like Syft can scan a compiled image and generate this detailed map in a few seconds, exporting the data in standardized formats like SPDX or CycloneDX.

Having this list in hand is a game changer because when a new critical security flaw is discovered in a popular library, you do not need to guess if your application is affected. You simply query the generated SBOM to immediately know whether that specific component lives inside any of your running services. In practice, this transforms incident response from a blind hunt in the dark into precise surgical intervention, allowing rapid fixes before any attacker can exploit the vulnerability.

Detecting vulnerabilities before deployment

Generating the ingredient list is only the first step; the next is checking whether those ingredients are spoiled. Vulnerability scanning tools, such as Grype, cross-reference SBOM data with public databases of known flaws, like the CVE database. When the scanner finds a match between an outdated package and a documented breach, it issues an alert classifying the risk according to severity, helping the engineering team make informed decisions.

However, the major technical advantage of integrating this scan into the continuous integration (CI/CD) pipeline is the ability to block the image from progressing. If the tool detects a critical-level vulnerability, the automation workflow is stopped immediately. This prevents insecure code from ever reaching the image registry. In practice, we create an impassable security gate that protects production against human errors and long-forgotten dependencies.

Ensuring authenticity with Cosign-based signatures

Knowing what is inside the container is essential, but how do you ensure that the image you tested and approved in staging is the exact same one running on the production server? This is where Cosign comes in, a tool from the Sigstore project focused on signing, verifying, and transparently storing container artifacts, removing the traditional complexity of managing cumbersome private keys.

Cosign allows you to sign an image using asymmetric keys or OpenID Connect-based identities, directly linking the developer's or pipeline's identity to the image's digital signature. In practice, when the Kubernetes cluster tries to pull a container to run it, an admission controller verifies whether the signature is valid and issued by a trusted source. If the image has been modified by an attacker along the way, the signature fails and the container is summarily rejected by the system.

Integrating the complete workflow into automation

Putting all these pieces together requires a well-structured automation pipeline. The process begins when the developer pushes code to the repository, triggering the Docker image build. Right after creation, the SBOM tool kicks in to extract the inventory, immediately followed by the vulnerability scanner that evaluates the risk of every dependency found in the package.

If all security checks pass without critical issues, the next step triggers Cosign to digitally sign the newly created image and push both the image and the SBOM file to the remote registry. This workflow ensures that every published artifact carries an inviolable seal of provenance. In practice, the infrastructure starts accepting only what possesses the correct signature, closing the doors on cyber supply chain attacks.

Final thoughts on environment hardening

Adopting secure container building with SBOM and Cosign elevates the operational maturity of any engineering team. While it requires an initial cultural shift and adjustments to existing pipelines, the return on investment in terms of peace of mind and compliance is immeasurable. Security stops being a bureaucratic obstacle and becomes an inherent, verifiable property of the software we build every day.