Forem: Advait Patel

Your Docker Images Have 847 Vulnerabilities (And You'll Ignore Them All)

Advait Patel — Wed, 18 Mar 2026 16:01:44 +0000

I ran Trivy on a production Node.js application last week. The output was 847 vulnerabilities. Not a typo. Eight hundred and forty-seven.

I stared at my terminal for a solid minute. Where do you even start with that? Which ones matter? Which ones are in libraries I'm not even using? Which ones have known exploits versus theoretical risks?

So I did what every developer does. I ignored all of them and shipped the image anyway.

The CVE Fatigue Is Real

Security scanners are doing their job. They're finding vulnerabilities. The problem is they find ALL the vulnerabilities and dump them in your lap with zero context.

Here's what a typical scan looks like:

$ trivy image myapp:latest

Total: 847 (UNKNOWN: 23, LOW: 421, MEDIUM: 267, HIGH: 118, CRITICAL: 18)

Okay, 18 critical vulnerabilities. That sounds important. Let me check them:

CVE-2023-12345 in libssl1.1 (7.5 severity)
CVE-2023-23456 in apt (9.8 severity)
CVE-2022-34567 in systemd (8.1 severity)
...15 more critical issues

Cool. Now what? Do I need to fix all 18? Are they exploitable in my container? Is systemd even running in my container? I have no idea.

The Scanner Doesn't Know Your Context

Traditional scanners are like having a hypochondriac friend Google your symptoms. "You have a headache? Could be a brain tumor, meningitis, or 47 other deadly conditions."

Thanks, very helpful.

The scanner doesn't know:

If you're actually using the vulnerable code path
If the vulnerability is exploitable in a container environment
Which fixes won't break your application
What the actual risk is for YOUR specific use case

So you end up with three choices:

Fix everything (impossible, takes weeks)
Fix nothing (risky, but honest)
Fix the ones that "feel" important (guessing)

Most of us pick option 2 or 3.

What If The Scanner Could Actually Think?

I got tired of this problem. I wanted a scanner that could:

Look at my Dockerfile and understand my setup
Tell me which vulnerabilities actually matter
Explain the issues in plain English, not CVE-speak
Give me specific fixes for my exact configuration

So I built it. It's called DockSec - https://owasp.org/www-project-docksec/, and it combines traditional security scanners with AI to give you context-aware analysis.

Here's what the same scan looks like with DockSec:

$ docksec Dockerfile -i myapp:latest

🔍 Analyzing security posture...
⚠️  Security Score: 42/100

Critical Issues (3 need immediate attention):
  • Running as root user (Dockerfile line 8)
    Why it matters: Root access in containers = full system compromise
    Fix: Add 'RUN useradd -m appuser && USER appuser' before CMD

  • Hardcoded AWS credentials (Dockerfile line 15)
    Why it matters: Credentials exposed in image layers, accessible to anyone
    Fix: Use Docker secrets or environment variables at runtime

  • Base image ubuntu:18.04 has 12 HIGH/CRITICAL CVEs with known exploits
    Why it matters: Your base layer has unpatched vulnerabilities
    Fix: Update to 'FROM ubuntu:22.04' (tested compatible with your deps)

📊 Full report saved to: myapp_report.html

Now we're getting somewhere.

How It Actually Works

DockSec doesn't replace Trivy or Hadolint. It wraps them and adds an AI layer that:

Runs all the traditional scanners (Trivy, Hadolint, Docker Scout)
Analyzes your Dockerfile to understand your setup
Correlates vulnerabilities with your actual usage
Prioritizes what matters for YOUR application
Generates specific, actionable fixes

The key difference: it reads your Dockerfile. It knows you're running Node.js. It sees you're using Ubuntu 18.04. It notices you're running as root. It understands the context.

A Real Example

Let's say you have this Dockerfile:

FROM ubuntu:18.04

# Install Node.js
RUN apt-get update && apt-get install -y nodejs npm

# Copy application
WORKDIR /app
COPY package*.json ./
RUN npm install
COPY . .

# Run application
EXPOSE 3000
CMD ["node", "server.js"]

Traditional scanner output:

156 vulnerabilities in Ubuntu 18.04
89 vulnerabilities in various npm packages
Hadolint warnings about apt-get cache
Docker Scout findings about base image

You're left to figure out which of these 245+ findings matter.

DockSec output:

Update base image to ubuntu:22.04 (fixes 127 CVEs at once)
Add non-root user (prevents privilege escalation)
Pin npm packages (ensures reproducible builds)
Clean apt cache (reduces image size by 89MB)

Four actionable items. That's it. That's what actually matters.

The Privacy Angle

Before you ask: "Are you sending my code to OpenAI?"

No. DockSec sends the scan results and Dockerfile to the AI for analysis. Not your application code. Not your secrets. Just the configuration and findings.

And if you're paranoid (which is fair), you can use Ollama to run everything locally. No cloud AI needed.

# Run DockSec with local Ollama
export LLM_PROVIDER=ollama
export LLM_MODEL=llama3.1
docksec Dockerfile

Everything stays on your machine.

Try It Yourself

Installation takes 30 seconds:

pip install docksec
export OPENAI_API_KEY="your-key"  # or use Ollama locally
docksec Dockerfile

Scan one Dockerfile. See what it finds. I bet you'll be surprised.

The tool is open source (MIT license), has 14,000 downloads, and was recently adopted by OWASP as an incubator project. It's not perfect, but it's better than ignoring 847 vulnerabilities.

What's Next

This is article #1 in a series about Docker security and DockSec. Coming up:

How DockSec actually works under the hood
Running AI security scans completely offline
Real examples of fixing vulnerable images
Integrating security into CI/CD without slowing down deployments

If you try DockSec, let me know what you find. Star the repo if it helps you: https://github.com/advaitpatel/DockSec

Now go scan something. You might be surprised what's lurking in your images.

From Cloud Audit Logs to Real-Time Threat Detection with BigQuery and Chronicle SIEM

Advait Patel — Sun, 23 Nov 2025 05:44:43 +0000

Introduction

Cloud Audit Logs help you track every cloud action. They show who did what, when, and where it happened. These logs are your foundation for strong visibility and control.

However, storing logs alone isn’t enough for compliance. Security teams need to analyze patterns, detect threats, and respond fast. That’s where smarter, automated tools become essential.

In this article, you’ll learn to build a complete pipeline. It combines Cloud Audit Logs, BigQuery, and Chronicle SIEM. This setup helps you ingest, normalize, and query logs at scale.

You’ll also learn how to detect risky activity using patterns. Then, you’ll visualize anomalies and enrich results with identity data. The goal is simple—turn raw logs into real-time security insight.

Why Go Beyond Logging?

This table shows why basic logging is not enough. It highlights common cloud audit challenges and their ideal solutions.

Each challenge reflects a gap in visibility or action. The tools listed help you filter, correlate, and automate responses. This helps security teams move from raw data to real insights.

Challenge	Solution
Too many logs, not enough signal	UDM normalization + SQL filters in BigQuery
Manual investigation workflows	Chronicle timeline + ML insights
Compliance without visibility	Structured queries, dashboards, audit pipelines
Siloed audit logs	Centralized correlation across services

Reference Architecture

This reference architecture shows the data flow clearly. It starts with GCP Audit Logs capturing cloud events. Logs move through Cloud Logging and Pub/Sub for routing. Then, BigQuery handles large-scale analytics and queries.

Chronicle SIEM performs real-time threat detection and context. This setup blends batch analytics with instant event correlation. It helps you cover compliance and threat response effectively.

Step-by-Step: Building the Pipeline

This section guides you through creating a complete logging and detection pipeline. You’ll learn each step to collect, analyze, and respond to security events efficiently.

1. Enable Cloud Audit Logs for All Resources

Start by enabling Cloud Audit Logs across all resources. Make sure both Admin Activity and Data Access logs are turned on. Admin logs show who changed settings or roles. Data Access logs track who viewed or read data. Enabling both gives full visibility into your cloud actions.

gcloud logging sinks create audit-log-sink \
bigquery.googleapis.com/projects/myproject/datasets/audit_dataset --logfilter='logName:"cloudaudit.googleapis.com"'

This includes IAM, GKE, BigQuery, Storage, Compute Engine, Cloud Run, etc.

2. Normalize Logs in BigQuery for Querying

Once logs are enabled, you’ll need to make them useful. BigQuery lets you clean and structure logs for faster searches. You can pull out key fields like user, action, and resource. This helps you run clear queries and build reports easily.

Example: Flatten IAM permission changes

SELECT
protopayload_auditlog.authenticationInfo.principalEmail AS actor,
protopayload_auditlog.resourceName AS resource,
protopayload_auditlog.methodName AS action,
TIMESTAMP_SECONDS(receiveTimestamp.seconds) AS ts
FROM
`audit_dataset.cloudaudit_googleapis_com_activity`
WHERE
  protopayload_auditlog.methodName CONTAINS "SetIamPolicy"
  AND resource CONTAINS "bigquery"

Use scheduled queries or views for dashboard generation in Looker Studio.

3. Ingest Logs into Chronicle for Real-Time Enrichment

Next, send your logs to Chronicle for deeper analysis. Use Pub/Sub or the Chronicle API to forward logs in real time. Chronicle adds context, links events, and highlights risky patterns. This step turns raw logs into useful, security-ready data.

For Example:

gcloud pubsub topics create chronicle-audit
gcloud logging sinks create chronicle-sink \
pubsub.googleapis.com/projects/my-project/topics/chronicle-audit

Format logs using Unified Data Model (UDM) before sending to Chronicle:

{
"metadata": {
 "productname": "GCP",
 "event_type": "IAM_POLICY_CHANGE"
},
"principal": {
  "user": { "userid": "admin@example.com" }
},
"target": {
 "resource": "bigquery/project-id/dataset"
 }
}

Send logs to Chronicle UDM API:

curl -X POST \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d @log.json \
  https://backstory.googleapis.com/v1/udmevents

4. Write Chronicle Rules to Detect Abuse

Write custom rules in Chronicle using YARA-L syntax. This helps detect abuse, risky changes, or rare behaviour

rule ExcessivePolicyChanges
{
  meta:
    author = "advait@gcpsec"
    description = "Detects multiple IAM policy changes in short time"

  events:
    $e.metadata.event_type == "IAM_POLICY_CHANGE"
    and $e.metadata.product_name == "GCP"
    and count($e) > 5 over 10m
}

Chronicle alerts the SOC if abuse patterns are detected.

5. Build Contextual Timeline Investigations

Use Chronicle’s timeline to trace user activity over time. It helps connect events and understand how incidents unfold.

Lateral movement
Privilege escalation
Suspicious API access (For example, getIamPolicy, testIamPermissions)
Admin activity outside business hours

Example query:

FETCH events
  WHERE principal.user.userid = "admin@example.com"
  AND metadata.event_timestamp BETWEEN "2025-06-18T00:00:00Z" AND "2025-06-18T06:00:00Z"
RETURN action, resource, src_ip

Use Case: Detecting Insider Threat in BigQuery

An admin uses SetIamPolicy to grant full BigQuery access.
Shortly after, they access sensitive datasets during off-hours.
These actions happen outside normal user behavior patterns.
Chronicle links the role change and unusual data access together.
Identity data adds context like user role and device location.
An alert is raised based on pattern, time, and privilege use.

This type of correlation isn’t visible in raw logs alone.

Advanced Audit Log Analytics Checklist

This checklist shows how to turn logs into insight. Each task pairs with a tool built for speed and scale. You’ll cover everything from enabling logs to threat detection and reporting. It helps teams stay compliant, alert, and audit-ready.

Task	Tool
Enable audit logs for all resources	Cloud Logging
Ingest and normalize logs	BigQuery + UDM
Real-time alerting and detection	Chronicle SIEM + YARA-L
Timeline-based investigations	Chronicle Timeline + Entity Context
Long-term compliance reporting	BigQuery + Looker Studio
Threat hunting + enrichment	Chronicle UDM Search

Conclusion

Collecting audit logs alone won’t secure your cloud. To stay ahead, you need to turn data into decisions.

BigQuery helps you store, structure, and query logs fast. Chronicle adds identity context, event correlation, and live detection.

Together, they create a smart, cloud-native analytics system. You know what happened, why it matters, and how to respond.

Starting in 2026, top SOCs won’t react after alerts appear. They’ll predict, prevent, and investigate with speed and clarity.