Container Security: Falco, Trivy, and Snyk Container in Practice

The Three Pillars of Container Security

Container security operates at three levels:

1. Build time: Scan images for known vulnerabilities before deployment
2. Deploy time: Enforce policies on what can run in your environment
3. Runtime: Detect anomalous behavior in running containers

Each pillar needs different tools. Here is how Trivy, Snyk Container, and Falco cover all three.

Trivy: Image Scanning in CI/CD

Trivy by Aqua Security is the fastest and most comprehensive container image scanner. It detects vulnerabilities in OS packages, language-specific packages, misconfigurations, and secrets.

# Scan a Docker image
trivy image python:3.12-slim

# Output (abbreviated):
# python:3.12-slim (debian 12.5)
# Total: 45 (UNKNOWN: 0, LOW: 25, MEDIUM: 15, HIGH: 4, CRITICAL: 1)
#
# +-----------+------------------+----------+-------------------+
# | Library   | Vulnerability    | Severity | Fixed Version     |
# +-----------+------------------+----------+-------------------+
# | libexpat  | CVE-2024-50602   | CRITICAL | 2.5.0-1+deb12u2   |
# | openssl   | CVE-2024-9143    | HIGH     | 3.0.15-1~deb12u1  |
# +-----------+------------------+----------+-------------------+

Trivy in a Gitea Actions CI pipeline:

# .gitea/workflows/security-scan.yml
name: Security Scan
on: [push, pull_request]

jobs:
  trivy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Build image
        run: docker build -t my-app:scan .

      - name: Run Trivy vulnerability scanner
        run: |
          trivy image --exit-code 1 --severity CRITICAL,HIGH \
            --ignore-unfixed \
            --format table \
            my-app:scan

      - name: Run Trivy config scanner
        run: |
          trivy config --exit-code 1 --severity HIGH,CRITICAL .

      - name: Run Trivy secret scanner
        run: |
          trivy fs --scanners secret --exit-code 1 .

Trivy Dockerfile scanning catches misconfigurations:

trivy config Dockerfile

# Findings:
# - DS002: Image user should not be 'root' (HIGH)
# - DS026: No HEALTHCHECK defined (LOW)
# - DS001: ':latest' tag used (MEDIUM)

Snyk Container: Developer-Friendly Vulnerability Management

Snyk Container focuses on the developer workflow. It integrates into your IDE, Git repository, and CI/CD pipeline to catch vulnerabilities early and suggest fixes.

# Scan image with Snyk
snyk container test python:3.12-slim --severity-threshold=high

# Monitor image for new vulnerabilities
snyk container monitor python:3.12-slim --org=techsaas

# Test a Dockerfile before building
snyk container test --file=Dockerfile .

What makes Snyk different from Trivy:

# Snyk suggests base image upgrades
snyk container test my-app:latest

# Output includes:
# Tested 125 dependencies for known issues
# Found 12 issues (3 critical, 4 high, 5 medium)
#
# Base Image Recommendations:
# Current: python:3.12-slim (45 vulnerabilities)
# Recommended: python:3.12-slim-bookworm (12 vulnerabilities)
# Alternative: python:3.12-alpine (3 vulnerabilities)

Snyk proactively tells you which base image has fewer vulnerabilities.

Trivy vs Snyk: Comparison

Our recommendation: Use Trivy in CI/CD (free, fast, offline-capable) and Snyk for developer workflow (IDE integration, base image recommendations, auto-fix PRs).

Falco: Runtime Security Detection

Falco is a CNCF project that detects anomalous behavior in running containers using kernel-level syscall monitoring. Think of it as an intrusion detection system for containers.

# Falco deployment with Docker Compose
services:
  falco:
    image: falcosecurity/falco:latest
    container_name: falco
    privileged: true
    volumes:
      - /var/run/docker.sock:/host/var/run/docker.sock:ro
      - /proc:/host/proc:ro
      - /etc:/host/etc:ro
      - ./falco/rules:/etc/falco/rules.d:ro
    environment:
      - FALCO_BPF_PROBE=""
    mem_limit: 256m

Custom Falco rules:

# falco/rules/custom-rules.yaml

# Detect shell spawned in a container
- rule: Shell Spawned in Container
  desc: Detect shell execution in a running container
  condition: >
    spawned_process and container and
    proc.name in (bash, sh, zsh, dash, ash) and
    not proc.pname in (cron, containerd-shim)
  output: >
    Shell spawned in container
    (user=%user.name container=%container.name shell=%proc.name
     parent=%proc.pname cmdline=%proc.cmdline image=%container.image.repository)
  priority: WARNING
  tags: [container, shell]

# Detect sensitive file access
- rule: Read Sensitive File in Container
  desc: Detect reading of sensitive files like /etc/shadow
  condition: >
    open_read and container and
    fd.name in (/etc/shadow, /etc/passwd, /etc/sudoers) and
    not proc.name in (sshd, login, su, sudo)
  output: >
    Sensitive file read in container
    (user=%user.name file=%fd.name container=%container.name image=%container.image.repository)
  priority: ERROR
  tags: [container, filesystem]

# Detect outbound connection to unexpected port
- rule: Unexpected Outbound Connection
  desc: Detect containers making outbound connections to non-standard ports
  condition: >
    outbound and container and
    not fd.sport in (80, 443, 5432, 6379, 27017, 53, 8080, 3000) and
    not container.name in (cloudflared, traefik)
  output: >
    Unexpected outbound connection from container
    (container=%container.name image=%container.image.repository
     connection=%fd.name port=%fd.sport)
  priority: NOTICE
  tags: [container, network]

Building a Complete Security Pipeline

Here is the full container security pipeline we implement at TechSaaS:

Developer writes code
        ↓
IDE: Snyk plugin warns about vulnerable dependencies
        ↓
Git push triggers CI pipeline
        ↓
CI Step 1: Trivy scans Dockerfile for misconfigurations
CI Step 2: Docker build
CI Step 3: Trivy scans built image for vulnerabilities
CI Step 4: Trivy scans for leaked secrets
CI Step 5: Block deployment if CRITICAL/HIGH found
        ↓
Deploy to production
        ↓
Runtime: Falco monitors syscalls for anomalous behavior
Runtime: CrowdSec monitors network for attacks
        ↓
Alert: Ntfy notification → Investigate → Remediate

Practical Dockerfile Hardening

Apply these fixes before scanning catches them:

# BAD: Running as root, using latest tag
FROM python:latest
COPY . /app
RUN pip install -r requirements.txt
CMD ["python", "app.py"]

# GOOD: Non-root user, pinned version, multi-stage, healthcheck
FROM python:3.12-slim-bookworm AS builder
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir --user -r requirements.txt

FROM python:3.12-slim-bookworm
RUN groupadd -r appuser && useradd -r -g appuser appuser
WORKDIR /app
COPY --from=builder /root/.local /home/appuser/.local
COPY --chown=appuser:appuser . .
ENV PATH=/home/appuser/.local/bin:$PATH
USER appuser
HEALTHCHECK --interval=30s --timeout=5s \
  CMD python -c "import urllib.request; urllib.request.urlopen('http://localhost:8080/health')"
EXPOSE 8080
CMD ["python", "app.py"]

Container security is not optional — it is a continuous process. Start with Trivy in your CI pipeline (it takes 5 minutes to set up), then add Falco for runtime detection, and use Snyk when you want developer-friendly vulnerability management. At TechSaaS, we run Trivy CI scans on all our Gitea repositories and CrowdSec for runtime intrusion prevention.