← Back to blog

Trivy, KICS, and the shape of supply chain attacks so far in 2026

dockercontainerizationdevopsdeploymentcontainers

The year is 2026. Just last month, the “Titan Fall” incident sent shockwaves through the financial sector, a sophisticated supply chain attack that leveraged a compromised open-source library, a misconfigured Kubernetes cluster, and an unverified container image to exfiltrate petabytes of sensitive data. It wasn’t a zero-day in a widely used web server; it was a subtle, multi-stage infiltration targeting the very foundations of software delivery. If you’re still relying on ad-hoc security checks and hoping for the best, you’re not just behind – you’re a prime target.

The era of simple CVE scanning as a “security solution” is long past. Today, supply chain attacks are less about a single flaw and more about a complex tapestry of vulnerabilities – ranging from malicious code injection in upstream dependencies, compromised build systems, unhardened infrastructure-as-code, to poisoned container images. As our cloud-native ecosystems grow more intricate, so do the attack surfaces. The challenge isn’t just to find vulnerabilities, but to preemptively block entire categories of attack vectors before they can even reach production.

This is where tools like Trivy and KICS have become indispensable. They’ve evolved significantly since their earlier iterations, now offering a holistic approach to securing our development pipelines and deployed assets. Let’s dive into how these powerhouse scanners are helping us navigate the treacherous waters of the 2026 threat landscape.

The Evolving Threat: More Than Just CVEs

Remember the xz backdoor scare of 2024? That was a wake-up call. Fast forward to 2026, and such incidents are no longer isolated anomalies. Attackers are relentlessly focusing on the supply chain because it offers maximum leverage: compromise one upstream component, and you potentially compromise thousands of downstream systems.

The common attack vectors we’re seeing today include:

  • Dependency Hijacking: Malicious code injected into legitimate packages, or typosquatting to trick developers into installing compromised alternatives.
  • Build System Compromise: Attacking CI/CD pipelines to inject malicious code during the build process or tamper with artifacts.
  • Infrastructure-as-Code (IaC) Misconfigurations: Exploiting insecure defaults, overly permissive policies, or unhardened configurations in cloud infrastructure, Kubernetes, or Docker deployments.
  • Container Image Tampering: Introducing vulnerabilities, backdoors, or cryptominers into container images, either via compromised base images or during the build and distribution process.
  • Secret Sprawl: Leaking API keys, credentials, or other sensitive information directly into source code, container images, or configuration files.

To combat this, a robust DevSecOps strategy in 2026 mandates a shift-left approach integrated with continuous validation. You need to catch issues as early as possible – from the moment code is written – and ensure that deployed systems remain secure.

Trivy: The All-Seeing Eye of Your Artifacts (v0.50.0 and beyond)

Aquasec’s Trivy, now at a mature v0.50.0, is no longer just a vulnerability scanner. It’s a versatile security Swiss Army knife that inspects nearly every artifact in your software supply chain. Its capabilities now span vulnerability scanning, misconfiguration detection, secret scanning, license compliance, and robust Software Bill of Materials (SBOM) generation.

Scanning Container Images for a 360-Degree View

Your container images are the lifeblood of your cloud-native applications. Trivy helps ensure they’re free from known vulnerabilities, sensitive secrets, and configuration flaws.

# Docker Pull - ensure latest base images are pulled
docker pull alpine:3.19.0 # (hypothetical 2026 version)
docker pull nginx:1.27.0-alpine # (hypothetical 2026 version)

# Scan a local Docker image with comprehensive checks
# --scanners: specifies what to scan for (vuln, config, secret, license, sbom)
# --severity: filters results by severity level
trivy image --scanners vuln,config,secret,license registry.example.com/my-app:2.1.0 --severity HIGH,CRITICAL

# Example output snippet (simplified):
# 2026-03-10T10:30:00Z INFO Scanning image: registry.example.com/my-app:2.1.0
#
# registry.example.com/my-app:2.1.0 (alpine 3.19.0)
# Total: 3 (HIGH: 2, CRITICAL: 1)
#
# Config (Docker-related misconfigurations)
# ----------------------------------------
# VULNERABILITY ID | SEVERITY | CHECK ID       | MESSAGE
# -----------------|----------|----------------|---------------------------------------------------------
# CKV_DOCKER_2     | HIGH     | CIS-D-2.1      | Image user is 'root'. Non-root users should be used.
#
# Secret (Potentially exposed secrets)
# -----------------------------------
# VULNERABILITY ID | SEVERITY | RULE ID        | CATEGORY | MATCH
# -----------------|----------|----------------|----------|---------------------------------------------------------
# Generic/AWSKey   | CRITICAL | AWSKey         | AWS      | AKIAXXXXXXXXXXXXXXXX:secretkey
#
# Vulnerability (OS packages)
# ---------------------------
# VULNERABILITY ID | SEVERITY | INSTALLED VERSION | FIXED VERSION | TITLE
# -----------------|----------|-------------------|---------------|---------------------------------------------------------
# CVE-2026-XXXXX   | HIGH     | 1.2.3             | 1.2.4         | libssl: remote code execution via malformed certificate
# ...

Performance Tip: For large images, Trivy’s caching mechanism is crucial. Ensure your CI/CD setup properly leverages the --cache-dir flag or mounts a persistent volume for caching to speed up subsequent scans. Trivy also intelligently only downloads advisories relevant to your image’s OS, further optimizing performance.

SBOM Generation: Transparency is Non-Negotiable

With recent regulatory mandates (like the Cyber Resilience Act 2.0 in the EU and equivalent legislation in the US), generating and verifying Software Bill of Materials (SBOMs) is no longer optional. Trivy v0.50.0 makes this effortless, supporting both SPDX and CycloneDX formats.

# Generate an SBOM in SPDX JSON format for an image
trivy image --format spdx-json --output app-sbom.spdx.json registry.example.com/my-app:2.1.0

# Generate an SBOM for a local filesystem (e.g., your application's source code)
trivy fs --format cyclonedx-json --output app-code-sbom.cyclonedx.json .

This generated SBOM provides a comprehensive list of all components, dependencies, and their licenses, significantly improving your ability to understand and respond to new vulnerabilities without rescanning the entire image.

Guarding Your Dockerfiles

Misconfigurations often start right in your Dockerfile. Trivy can scan these too, flagging insecure practices before an image is even built.

# Dockerfile (insecure example)
FROM alpine:3.19.0
WORKDIR /app
COPY . .
# Using root is a classic misconfiguration
RUN apk add --no-cache curl && \
    chmod 777 /var/www/html # Excessive permissions
# Exposing sensitive data in an ENV var - Trivy will flag this
ENV AWS_SECRET_ACCESS_KEY="AKIAXXXXXXXXXXXXXXXX:secretkey" 
CMD ["./my-app"] 
# Scan a Dockerfile for misconfigurations and secrets
trivy config Dockerfile
# Output will highlight issues like running as root, insecure permissions, and embedded secrets.

KICS: Enforcing Policy-as-Code for Your Infrastructure (v1.10.0 and beyond)

Checkmarx KICS (Keep Infrastructure as Code Secure), now at v1.10.0, is your primary guardian against IaC misconfigurations. It understands the nuances of Terraform, Kubernetes manifests, CloudFormation, Ansible, Docker Compose, and more. In a world dominated by GitOps, KICS shifts security left, enabling you to enforce organizational policies directly in your CI/CD pipelines.

Scanning Your Kubernetes Deployments

Kubernetes misconfigurations are a leading cause of breaches. KICS checks for everything from privileged containers and insecure hostPath mounts to missing network policies and resource limits.

# kubernetes/deployment.yaml (insecure example)
apiVersion: apps/v1
kind: Deployment
metadata:
  name: insecure-app
spec:
  replicas: 1
  selector:
    matchLabels:
      app: insecure-app
  template:
    metadata:
      labels:
        app: insecure-app
    spec:
      containers:
      - name: my-container
        image: registry.example.com/my-app:2.1.0
        # Privileged container - huge security risk!
        securityContext:
          privileged: true 
        ports:
        - containerPort: 8080
        # Missing resource limits/requests - can lead to DoS or resource exhaustion
# Scan a Kubernetes manifest directory
kics scan -p kubernetes/ --output-path ./kics-k8s-results --output-formats json,sarif

# Example KICS output (simplified):
# 2026-03-10T10:35:00Z INFO Scanning path: kubernetes/
#
# Results:
#   Query ID: 67cf4d57-8143-4a64-9293-e4d65377041a
#   Query Name: Kubernetes Privileged Containers
#   Severity: HIGH
#   Filename: kubernetes/deployment.yaml
#   Line: 18
#   Value: privileged: true
#   Message: Privileged containers can bypass many security restrictions, treat as root.
#
#   Query ID: 77cf4d57-8143-4a64-9293-e4d65377041b
#   Query Name: Missing Kubernetes Resource Limits
#   Severity: MEDIUM
#   Filename: kubernetes/deployment.yaml
#   Line: 20
#   Value: (missing resources.limits)
#   Message: Missing CPU and Memory limits can lead to resource exhaustion.
# ...

Gotcha: KICS uses a powerful query language (like Rego or OPA) for its policies. While the default ruleset is extensive, always customize or extend it with your organization’s specific security benchmarks and compliance requirements.

Docker Compose Security

Even your local development environments or single-host deployments managed by Docker Compose need scrutiny. KICS integrates seamlessly.

# docker-compose.yaml (insecure example)
version: '3.8'
services:
  webapp:
    image: registry.example.com/my-app:2.1.0
    # Mapping sensitive host directories - security risk
    volumes:
      - /:/hostroot 
    # Directly exposing ports without explicit binding - potential for unintended access
    ports:
      - "80:80"
    # Overly broad network access
    network_mode: "host" 
# Scan a Docker Compose file
kics scan -p docker-compose.yaml --output-path ./kics-compose-results --output-formats json

KICS will flag issues like privileged: true in containers, network_mode: host, or overly permissive volume mounts, enforcing a secure baseline even for non-Kubernetes container deployments.

Integrating for a Robust Supply Chain Security Posture

The real power of Trivy and KICS emerges when they’re seamlessly integrated into your CI/CD pipelines and GitOps workflows.

  1. Pre-commit Hooks: Run trivy fs . and kics scan -p . as pre-commit hooks to catch issues before they even hit your Git repository.
  2. Pull Request (PR) Checks: Automate scans on every PR. If Trivy finds critical vulnerabilities in dependencies or KICS identifies a high-severity misconfiguration in your IaC, block the merge. Use SARIF output for rich integration with GitHub/GitLab UI.
    # Example .github/workflows/ci.yml snippet for KICS scan on PR
    name: IaC Security Scan
    on: [pull_request]
    jobs:
      kics-scan:
        runs-on: ubuntu-latest
        steps:
          - name: Checkout code
            uses: actions/checkout@v4 # Latest in 2026
          - name: Run KICS Scan
            uses: Checkmarx/kics-action@v2 # Latest in 2026
            with:
              path: '.'
              output-formats: 'sarif'
              output-file: 'kics-results.sarif'
              fail-on: 'high' # Fail PR if high severity issues are found
          - name: Upload KICS SARIF results
            uses: github/codeql-action/upload-sarif@v3 # Latest in 2026
            with:
              sarif_file: 'kics-results.sarif'
    
  3. Image Build Verification: After a container image is built, but before it’s pushed to a registry, run a comprehensive trivy image scan. Fail the build if critical vulnerabilities or secrets are detected.
  4. Registry Integration: Modern artifact registries (like Harbor, Artifactory, or cloud-native options) often integrate with Trivy for continuous scanning of stored images, providing ongoing visibility into new CVEs.
  5. SBOM Verification: Ensure that images are built with signed SBOMs and that those SBOMs are verified against trusted sources during deployment, adding an extra layer of integrity.

Performance Consideration: For large repositories or frequent scans, consider using Trivy’s and KICS’s --skip-dirs or --only-include flags to target specific paths, or leverage parallelization in your CI/CD to speed up execution. Incremental scanning features, where available, can also drastically reduce scan times.

Key Takeaways for 2026 DevOps

  • Embrace Shift-Left Security: Integrate Trivy and KICS into every stage of your development pipeline, from local development to CI/CD.
  • Policy-as-Code is Your Shield: Leverage KICS to define and enforce security policies across all your IaC, ensuring consistent and secure deployments.
  • Transparency Through SBOMs: Utilize Trivy for comprehensive SBOM generation and verification. Knowing what’s in your software is the first step to securing it.
  • Beyond Vulnerabilities: Move past simple CVE scanning. Trivy’s expanded capabilities for secret detection, misconfigurations, and licenses are critical.
  • Automate Everything: Manual checks are insufficient. Automate scanning and policy enforcement with these tools to maintain a secure posture at scale.
  • Don’t Just Scan, Act: Set up clear thresholds and actions (e.g., failing builds, blocking merges) based on scan results.

The shape of supply chain attacks in 2026 is complex, insidious, and relentless. Tools like Trivy and KICS, when used effectively, provide a formidable defense. They empower teams to build secure-by-design systems, allowing innovation to flourish without compromising security.


Discussion Questions for Readers:

  1. What’s the most sophisticated supply chain attack you’ve encountered or heard about recently that wasn’t adequately covered by traditional vulnerability scanners?
  2. How are you currently integrating SBOM verification into your CI/CD or deployment workflows, and what challenges have you faced?

Comments

No comments yet. Be the first!

We use cookies to enhance your browsing experience, serve personalized content, and analyze our traffic. By clicking "OK", you consent to our use of cookies and agree to our Terms of Service & Privacy Policy.