A beginner-friendly route to open-source container security

Updated on Apr 07,2026

Containers have become a default unit for shipping software for many teams. One CNCF report put container use in production at 91% of organisations. When something’s that widespread, the best improvements often look boring on paper: a few checks you can run every time, in the same place, with the same outputs. In this article, we’ll build a beginner-friendly, open-source container security starter pack that fits into normal CI/CD, using open source container security: one image scan, one SBOM and one simple policy gate.

I’ll go over why with CNCF adoption data, use the NTIA’s SBOM minimum elements to keep the SBOM part grounded, and pull in Verizon’s DBIR to explain why supply-chain visibility has become a day-to-day need. You’ll be left with with a lightweight checklist you can implement without switching platforms, and a clearer way to decide what deserves your attention when vulnerability worry starts stacking up.

Your containers have friends

Container security rarely fails because people don’t care; it fails because there are too many moving pieces to hold in your head at once. CNCF has reported the average number of containers used by organisations was 2,341 in 2024 (up from 1,140 in 2023), which is a neat way of saying you need repeatable habits, not heroics.

That’s why I like the idea of security receipts.

Not paperwork for the sake of it, but small artefacts that travel with an image and answer the next person’s questions fast.

If your build can consistently produce three receipts, you’ve already raised the floor:

  • An image scan receipt tells you what known issues are present right now (and gives you something to diff tomorrow)
  • An SBOM receipt tells you what you actually shipped, in a structured, shareable form
  • A policy receipt records that your pipeline applied a rule and either passed or blocked the release

There’s a useful side effect too: these receipts make conversations shorter. Instead of debating feelings about risk, you look at the same outputs and decide together.

One practical reality to plan for: vulnerability lists tend to grow over time, even when teams patch diligently. That’s why reducing noise and focusing on what’s actionable matters. A starter pack helps a small team make that real.

CI/CD is your security autopilot

If you want this to work long term, it has to fit where work already happens. CNCF has reported that 60% of organisations use CI/CD in production for most or all applications, which means the pipeline is already where teams trust work to move from done to shipped.

So we don’t need a complex program to start. We need three defaults your pipeline runs for every container image, and one moment where it’s allowed to say stop.

Here’s a simple flow that still gives you real leverage:

  • Build the container image and tag it in a predictable way (so later artefacts map cleanly to the right build)
  • Run an open-source vulnerability scan against that image and save the results as a build artefact you can review later
  • Generate an SBOM in a machine-readable format and store it alongside the image (or with a version-specific pointer to it)
  • Enforce one policy gate that evaluates the scan and SBOM outputs, then returns a clear pass or fail for deploy

The easiest first rule is one that teaches the right behaviour without creating constant friction. A strong candidate is no SBOM, no deploy, because it’s objective and nudges everyone towards transparency as a normal part of shipping.

Then, once that’s stable, you can tighten your policy in small steps. Maybe you add a vulnerability threshold, or require the SBOM to include the fields your organisation cares about most. Teams often try to start with the perfect policy and end up with a policy nobody trusts. Starting small doesn’t lower standards; it makes them easier to maintain.

SBOMs make supply-chain security feel less mysterious

A lot of supply-chain anxiety comes from not knowing what you depend on, or who else depends on it. Verizon’s 2025 DBIR highlights that 30% of breaches were linked to third-party involvement. Verizon also states the 2025 DBIR’s in-scope incident window runs from Nov 1, 2023 to Oct 31, 2024.

This is where SBOMs earn their keep. NTIA defines an SBOM as a formal record containing the details and supply chain relationships of components used in building software. NTIA also lays out minimum elements in three buckets: data fields, automation support and practices/processes. That structure keeps SBOM work practical rather than academic.

For automation support, NTIA calls out common SBOM formats used to generate and consume SBOMs, including SPDX, CycloneDX and SWID tags. That's important for container security because machines can’t enforce what they can’t read. If your SBOM is consistent and machine-readable, your policy gate becomes dependable instead of fragile.

SBOM expectations are still maturing. CISA has updated recommendations for minimum SBOM features, including SBOM data fields, expected comprehensiveness, identifying known-unknown dependencies and the importance of updating outdated records. And remember, if you can’t answer ‘what’s in this image?’ quickly, how confident can you be when the next vulnerability alert lands on a busy day?

Small checks add big confidence

The real win with an open-source starter pack is consistency you can explain. An image scan gives you a current snapshot, an SBOM gives you a clean inventory record and a simple policy gate turns both into a decision your pipeline can enforce.

There’s also a practical point here. CNCF has reported Asia-Pacific reached 84% adoption of cloud native techniques at least at the ‘some’ level (some, much, or nearly all), which is a reminder that teams in and around Viet Nam are building with the same modern building blocks as everyone else.

So don’t wait for a platform overhaul to get meaningful container security wins; start by making your pipeline produce those three receipts for every image, then iterate.

Most people like