Container Security Scanning + Vulnerability Checks

Container images can contain security vulnerabilities - outdated dependencies, known CVEs or malware. Container security is essential for AI applications that process sensitive documents. Automated security scanning in CI/CD pipelines identifies vulnerabilities before they reach production. Container security is an essential component of modern Container orchestration and forms the basis for secure deployments in Cloud hosting-environments and Private Cloud-infrastructures.

The DevSecOps approach integrates security checks directly into the development process. Developers receive immediate feedback on security issues during the build process, not weeks later. This significantly shortens the feedback loop and prevents vulnerable images from going into production. Tools such as Trivy, Grype and Snyk fully automate these checks.

What is scanned?

Container security scanners analyze images on several levels. Vulnerabilities in OS packages and application dependencies are checked against CVE databases. An outdated OpenSSL package or Log4j version with known vulnerabilities is immediately identified. Scanners rate the criticality of each vulnerability as Critical, High, Medium or Low, enabling prioritized remediation of the most dangerous issues.

Secrets such as API keys, passwords or private keys should never be embedded in container images. Scanners search all image layers for suspicious patterns and issue a warning if credentials are found. An AWS access key hardcoded in a Dockerfile or an accidentally checked-in SSH key is detected before the image is deployed. This prevents frequent but serious security vulnerabilities.

Misconfigurations pose a further risk. Containers that run as root users have unnecessarily elevated privileges and increase the attack surface. Exposed ports such as SSH on port 22 should not be publicly accessible in productive containers. Scanners check such configuration problems and recommend hardening measures such as non-privileged users and minimized port exposure.

Security scanning tools

Trivy has established itself as the fastest and simplest scanner. A single command scans an entire image in just a few seconds and delivers clear results. Trivy is open source and supports Docker, Kubernetes, Terraform and many other formats. Integration into CI/CD pipelines takes place with minimal effort, as Trivy works as a standalone binary without external dependencies.

# Image scannen mit Trivy
trivy image python:3.11
# Nur Critical und High Vulnerabilities
trivy image --severity CRITICAL,HIGH nginx:latest
# JSON-Output für Weiterverarbeitung
trivy image --format json -o scan-results.json myapp:v1.2.3

Grype from Anchore offers similar functionality with a focus on SBOM integration. Software bills of materials are created as structured inventory lists of all components of an image. This facilitates proof of compliance and makes it possible to quickly check which images are affected by new CVEs. Grype automatically generates and uses SBOMs for more precise vulnerability detection.

# Image mit Grype scannen
grype docker:python:3.11
# SBOM exportieren
syft docker:python:3.11 -o spdx-json > sbom.json
# SBOM mit Grype scannen
grype sbom:sbom.json

Snyk is aimed at development teams with excellent developer experience. The integration in IDEs such as VS Code shows vulnerabilities directly in the code editor. Snyk automatically creates pull requests with fixes for known vulnerabilities and updates dependencies to secure versions. The free tier covers smaller projects, enterprise features cost from 500 euros per month.

CI/CD pipeline integration

GitHub Actions integrates security scanning into every pull request. The following workflow automatically scans images during build and prevents merges if critical vulnerabilities are found. This establishes a security gate that automatically blocks insecure images without the need for manual review.

name: Container Security Scan
on: [push, pull_request]
jobs:
  security:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Build Image
        run: docker build -t myapp:${{ github.sha }} .
      - name: Scan with Trivy
        uses: aquasecurity/trivy-action@master
        with:
          image-ref: myapp:${{ github.sha }}
          severity: CRITICAL,HIGH
          exit-code: 1  # Fail bei Vulnerabilities
      - name: Upload Results
        if: always()
        uses: actions/upload-artifact@v3
        with:
          name: scan-results
          path: trivy-results.json

GitLab CI/CD offers similar integration with native container scanning support. GitLab Ultimate includes integrated security scanning that displays results directly in merge requests. For GitLab Free/Premium, Trivy can be integrated as a custom job and provides comparable functionality at no additional license cost.

# .gitlab-ci.yml
security_scan:
  stage: test
  image: aquasec/trivy:latest
  script:
    - trivy image --exit-code 1 --severity CRITICAL,HIGH $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
  only:
    - merge_requests
    - main

Kubernetes Admission Controllers check images at runtime during pod startup. Falco and OPA Gatekeeper automatically block pods with known vulnerabilities or policy violations. This provides an additional layer of security in case vulnerable images accidentally enter the registry. Runtime protection complements CI/CD scanning and also protects against manually deployed images.

Best Practices

Regular scanning of existing images is essential, as new CVEs are published daily. An image that is secure today may be vulnerable tomorrow if a new vulnerability is discovered in a component it contains. Automated nightly scans of all registry images with alerting on new findings establish continuous security monitoring. Tools such as Harbor or Quay.io offer integrated scanning functions for container registries.

Base image selection has a significant impact on the security posture. Minimal images such as Alpine or Distroless only contain essential components and reduce the attack surface by 90 percent compared to standard images. A Python image based on Alpine typically has 20 to 30 vulnerabilities, while the same image based on Ubuntu has 200 to 300. Switching to minimal images improves security and significantly reduces image size.

Multi-stage builds separate build and runtime environments. Build tools such as compilers, package managers and development dependencies are not included in the final image. This minimizes both size and security risks, as build tools often contain more vulnerabilities than runtime dependencies. A multi-stage Dockerfile for Python applications could look like this:

# Build Stage
FROM python:3.11 AS builder
WORKDIR /build
COPY requirements.txt .
RUN pip install --user -r requirements.txt
# Runtime Stage
FROM python:3.11-slim
WORKDIR /app
COPY --from=builder /root/.local /root/.local
COPY . .
ENV PATH=/root/.local/bin:$PATH
CMD ["python", "app.py"]

Vulnerability thresholds define acceptable risk levels. Not every low severity vulnerability justifies an immediate fix effort. Typical policies block deployments for critical findings, warn for high, and ignore medium/low in the first step. Exceptions for known false positives or vulnerabilities without available fixes avoid unnecessary blockages. Security policy should remain practicable without tolerating real risks.

Frequently asked questions

How often should images be scanned?

Images should be scanned with every build in the CI/CD pipeline in order to detect new vulnerabilities immediately. In addition, daily scans of all images in the container registry are recommended, as new CVEs are published at any time. Production images require particularly frequent scans, ideally several times a day for critical services. Most scanners allow fully automated schedules without manual effort.

What does container security scanning cost?

Open source tools such as Trivy and Grype are completely free and cover most use cases. Cloud-based services like Snyk start at €0 for small teams with limits, enterprise plans cost €500 to €2,000 per month per team. Harbor and Quay.io offer integrated scanning as part of their registry functionality. Open source tools are sufficient for most companies; enterprise features are worthwhile for 50 plus developers.

How do you deal with false positives?

False positives occur when scanners report vulnerabilities that cannot be exploited in the specific usage. Scanners allow known false positives to be suppressed via ignore files. Teams should carefully analyze each alleged false positive and document why it is ignored. Regular review of these exceptions ensures that they remain valid. Alternative scanners can provide second-opinions if there is uncertainty.

Can scanning significantly slow down deployments?

Modern scanners such as Trivy scan typical images in 10 to 30 seconds. This extends CI/CD pipelines minimally and is worth the security gain. Caching of scan results significantly speeds up re-scans of identical layers. For very large images or complex pipelines, parallel scanning of several jobs can keep the overall duration neutral. The security benefit far outweighs the minimal performance impact.

Would you like to integrate container security scanning into your DevSecOps pipeline? Contact us for a non-binding initial consultation.