Talk - 'Deep-dive into Containers and How to Secure Them'

· wordCount · 5 minute read

Containers are a fundamental building block for modern applications, but they bundle a large amount of third-party code. Identifying what’s inside an image (and which versions) is critical for security. This post summarises a January 2025 presentation at Defcon 44131 covering how containers work, why SCA (Software Composition Analysis) matters, common open-source tooling (Syft/Grype, Trivy, Docker Scout, Clair) and an introduction to Konarr — an SCA platform focused on containers. It closes with pragmatic steps to reduce risk: scan early, monitor continuously, patch often, and shrink the attack surface.

Slides

Who is this for

This post targets engineers and security practitioners who build, ship, or operate containerised applications and need pragmatic steps to find and mitigate vulnerable dependencies inside images.

Why containers deserve special attention

Containers package an application together with libraries, binaries, configuration and runtime metadata. That makes them hugely portable and convenient, but it also means an image can contain dozens (or hundreds) of transitive components you don’t directly control.

Key security questions:

  • What components are in my image and which versions are they?
  • Which of those components have known vulnerabilities?
  • How can I detect new vulnerabilities after deployment?

If you can’t answer those, you can’t confidently patch, triage, or prioritise risk.

Quick recap: how containers work (practical)

  • An image is a stack of immutable layers produced by Dockerfile instructions (RUN, COPY, ENV, ENTRYPOINT, etc.).
  • At runtime a union filesystem (e.g. OverlayFS) merges those layers into the container filesystem the process sees.
  • Layers are cached and shareable between images which helps build performance and disk usage — but it also means a vulnerable component can be reused across images.

Example (simplified) Dockerfile used during the talk:

# Base layer
FROM debian:bullseye-slim

# Layer: environment
ENV URL=https://api.github.com/repos/

# Layer: install runtime deps
RUN apt-get update && apt-get install -y curl git jq

# Layer: add entrypoint
COPY entrypoint.sh /entrypoint.sh
ENTRYPOINT ["/entrypoint.sh"]

You can build and inspect an image locally:

docker build -t myimage:latest .
docker run -it --rm myimage:latest
docker history myimage:latest
docker image inspect myimage:latest

Tools like dive help you explore layer contents and identify ways to shrink an image.

dive myimage:latest

Software Composition Analysis (SCA) — the core idea

SCA is the process of identifying and inventorying the open-source components inside a software artifact, matching those components to vulnerability databases, and continuously monitoring for new issues.

An essential output of SCA is the Software Bill of Materials (SBOM): a structured list describing components, versions and relationships. SBOMs make alerting, triage and compliance far easier.

Tools discussed

Several open-source tools exist to generate SBOMs and perform SCA on images. Results can vary between tools because each uses different heuristics to detect components.

  • Syft (Anchore) — fast component discovery and SBOM generation.
  • Grype (Anchore) — vulnerability scanner that consumes SBOMs or scans images directly.
  • Trivy (Aqua) — widely used scanner that supports many formats.
  • Docker Scout (Docker) — tooling integrated with Docker ecosystem.
  • Clair (RedHat) — a long-standing image scanner.
  • Konarr (42ByteLabs) — an SCA platform built with containers in mind; open source (Apache 2.0), implemented in Rust and TypeScript with a Web UI, API and CLI.

Example commands demonstrated in the talk:

# Generate an SBOM with syft
syft ghcr.io/geekmasher/digitalocean-dynamic-dns:main -o cyclonedx-json=./ddd-sbom.json

# Scan with grype and write results as CycloneDX
grype ghcr.io/geekmasher/digitalocean-dynamic-dns:main -o cyclonedx-json=./ddd-results.json

Note: different scanners may return different component lists and vulnerability matches; use multiple sources of truth where practical and validate tool output against your expectations.

Konarr — what it brings to the table

Konarr is designed as a platform for container SCA: it supports collecting SBOMs, scanning for vulnerabilities, and providing a UI/API/CLI for triage and monitoring. Because it’s open source and built with modern languages (Rust backend, TypeScript frontend), it can be integrated into CI/CD pipelines and used to monitor registry images or running deployments.

If you want to explore Konarr, the project lives at https://github.com/42ByteLabs/konarr and is worth trying if you need a container-first SCA platform.

Practical hardening steps (actionable)

1) Scan early (during build)

  • Integrate SBOM generation and vulnerability scanning into CI so images fail fast when critical issues are found.

2) Monitor continuously (after deploy)

  • Vulnerability databases are updated constantly. Scan running images and registry contents periodically to catch new advisories.

3) Patch and rebuild images routinely

  • Regularly update base images (Alpine, Debian, Ubuntu, etc.).
  • Trigger automated rebuilds and redeploys from your pipeline when base layer updates are available.

4) Reduce the attack surface

  • Use minimal base images (Alpine, scratch, distroless) where appropriate.
  • Employ multi-stage builds to keep only necessary artifacts in the final image.
  • Avoid installing build tools or package managers in production images — copy only runtime artifacts.

5) Apply runtime mitigations

  • Harden containers with kernel-enforced policies: AppArmor, SELinux, and Seccomp.
  • Run containers as non-root users and drop unnecessary Linux capabilities.

6) Consider in-place patch tooling

  • Tools exist that attempt to patch running containers or provide hotfix layers; these are useful for emergency mitigation but should not replace rebuild-and-redeploy practices.

Edge cases and caveats

  • Image provenance: if you don’t control a base image, you need visibility into its SBOM — treat untrusted images cautiously.
  • False positives/negatives: scanner heuristics may miss components or produce noisy results. Validate critical findings manually.
  • Large monolithic images: legacy images can contain many components — incremental hardening and staged migrations are practical.

Try it locally (quick checklist)

  1. Build a small image from the example Dockerfile above.
  2. Generate an SBOM with syft and scan with grype.
  3. Explore the image with dive and see which layers contain which components.

If you run a local Hugo preview of this site, add the new post to the content/talks folder and start the server to check formatting.

Closing thoughts

Containers are powerful, but that power comes with responsibility: every image you run is a composition of other people’s code. SCA and SBOMs are the pragmatic foundation for gaining visibility. Use open-source scanners to get started, integrate scans into CI/CD, monitor the landscape, and consider platform tooling like Konarr when you need a container-focused SCA solution.

Questions or feedback? I presented this talk in January 2025 — drop me a line or check the slides and demo code in the presentations repository linked below.

References and links

Containers SCA SBOM Konarr DevSecOps