Your First Security Scan: A Step-by-Step Guide With ShieldOps

You have built your first Docker container, deployed it to a test server, and everything runs beautifully. But here is the uncomfortable truth: your container almost certainly contains vulnerabilities you did not intend to ship. A single docker pull on an outdated base image can pull in fifty known CVEs before you write a single line of application code. The gap between "it works" and "it is secure" is measured in a single action — running your first security scan.

This guide walks you through your first container security scan from start to finish. You will learn what tools to use, how to interpret results, and how to fix the vulnerabilities you find. By the end, you will have a repeatable scanning workflow that fits into your daily development routine — all powered by ShieldOps for the most critical analysis steps.

Why Running Your First Security Scan Matters

In 2025, over40,000 new vulnerabilitieswere published in the National Vulnerability Database (NVD). Containers inherit vulnerabilities from base images, operating-system packages, and application dependencies — often without the developer realizing it. A singledocker pull node:20 can introduce hundreds of known CVEs into your build pipeline before you write a line of application logic.

The consequences of skipping scans are well documented. The2024 Data Breach Investigations Reportfrom Verizon found that 15% of breaches involved a vulnerability in a third-party component — the same kind routinely discovered by container scanners. What separates secure teams from breached ones is not budget or headcount: it is the habit of scanning early and scanning often.

Scanning gives you three things:visibilityinto what your image actually contains,prioritizationto focus on the most dangerous CVEs first, and abaselineto measure improvement against over time. Without a scan, you are deploying blind.

Prerequisites: What You Need Before You Start

Before running your first scan, make sure you have the following:

• Docker installed— version 24.0 or later. Verify withdocker --version. Install from docs.docker.com.
• Trivy installed— the open-source vulnerability scanner by Aqua Security. Install viabrew install trivy or the official installation guide.
• A target Docker image— we will usenode:20-bookworm-slim for this guide, but any image works.
• A ShieldOps account—sign up for freeto analyze your Dockerfiles for security policy violations.
• Basic terminal familiarity— comfortable running commands and reading output.

Step 1: Pull Your Target Image and Inspect It

Start by pulling the image you want to scan. For this guide, we use a Node.js image because it is widely used and typically carries a moderate number of CVEs — realistic for a first scan experience.

docker pull node:20-bookworm-slim
docker images node:20-bookworm-slim

Take note of theIMAGE IDandSIZE. You will scan by image ID or tag. The size matters because larger images usually have more packages and therefore more potential vulnerabilities — a principle known asattack surface.

Now inspect the layers:

docker history node:20-bookworm-slim

Each line in the output is a layer. Layers are instructions from the Dockerfile (FROM, RUN, COPY, etc.). Some layers are inherited from the base OS (Debian Bookworm in this case), and others are added by the Dockerfile. Every layer is a potential vector for vulnerabilities.

Step 2: Run Your First Vulnerability Scan with Trivy

Trivy is the industry-standard open-source scanner for containers. It checks OS packages (dpkg, apk, rpm) and language-specific dependencies (npm, pip, gem) against the NVD, GitHub Advisory Database, and Red Hat OVAL databases.

Run the scan:

trivy image node:20-bookworm-slim

The output is divided into sections by severity:CRITICAL,HIGH,MEDIUM,LOW. Each vulnerability entry shows:

• CVE ID— the unique identifier (e.g., CVE-2025-12345)
• Package— the affected library or tool (e.g.,libssl3)
• Installed Version— what you currently have
• Fixed Version— the version that patches the CVE
• CVSS Score— severity on a 0-10 scale (10 = worst)
• Title— a short description of the vulnerability

At this point, do not panic about the number of results. Even well-maintained official images carry some CVEs. The goal is tounderstand what you are deployingand make informed decisions about what to fix now versus what to monitor.

Output a Machine-Readable Report

For deeper analysis, export the scan in JSON format:

trivy image --format json --output scan-results.json node:20-bookworm-slim

The JSON file groups vulnerabilities by target (OS packages, npm dependencies, etc.) and includes full CVE metadata, references, and fix versions. This is the format that automation tools like ShieldOps and CI/CD pipelines consume.

Step 3: Analyze Your Dockerfile with ShieldOps

While Trivy tells youwhatvulnerabilities exist in your packages, ShieldOps tells youwhyyour Dockerfile configuration is risky. Many security issues come not from individual CVEs but frommisconfigured Dockerfile instructions— running as root, exposing unnecessary ports, using thelatest tag, or adding debug tools.

Upload your Dockerfile toShieldOps Analysisor use the CLI:

shieldops analyze Dockerfile --output report.json

ShieldOps checks your Dockerfile against:

• CIS Docker Benchmark— 100+ industry-accepted security configuration rules
• OWASP Top 10 for Containers— the most critical container security risks
• NIST SP 800-190— the US National Institute of Standards container security guide
• Custom policy rules— your team's specific security requirements

Step 4: Understanding Scanner Results — CVSS and Severity

Every vulnerability comes with aCVSS (Common Vulnerability Scoring System)score between 0 and 10. Understanding these scores helps you prioritize:

• CRITICAL (9.0-10.0)— Exploitable remotely, likely with public exploit code. Fix immediately.
• HIGH (7.0-8.9)— Serious but may require specific conditions. Fix within your next sprint.
• MEDIUM (4.0-6.9)— Limited impact or requires local access. Monitor and fix in regular cycles.
• LOW (0.1-3.9)— Minor impact, hard to exploit. Accept or fix during maintenance windows.

However,do not fix CVSS scores in isolation. A HIGH vulnerability in a library that is never loaded at runtime is less urgent than a MEDIUM vulnerability in a network-facing service. This is calledvulnerability context— and it is what separates mature scanning from noise-chasing.

For detailed CVSS scoring guidance, see the officialNVD CVSS documentation.

Step 5: Fixing the Vulnerabilities You Found

Now for the most rewarding part — fixing what the scan revealed. Here is a practical approach based on vulnerability type:

OS Package Vulnerabilities

These are the most common and usually the easiest to fix. Rebuild your image after updating the base image:

# Before — pulls whatever :20-bookworm-slim currently points to
FROM node:20-bookworm-slim

# After — pin to a specific digest for reproducibility
FROM node:20-bookworm-slim@sha256:a1b2c3d4e5f6...

# Or better — use a distroless or minimal base image
FROM node:20-alpine

Then rebuild:docker build --no-cache -t myapp:secure .. Rescan with Trivy to confirm the CVEs are gone.

Application Dependency Vulnerabilities

For npm, pip, or gem dependencies found by Trivy:

# Check npm audit for known vulnerabilities
npm audit

# Update specific packages
npm update express --depth 5

# Or use npm audit fix for automatic patching
npm audit fix

# Rebuild and rescan
docker build -t myapp:secure .
trivy image myapp:secure

Dockerfile Configuration Issues

These are fixed by editing the Dockerfile itself, guided by theShieldOpsanalysis report:

# Before — root user, missing health checks
FROM node:20-bookworm-slim
COPY . /app
WORKDIR /app
RUN npm install
CMD ["node", "app.js"]

# After — non-root user, health check, clean install
FROM node:20-bookworm-slim
RUN groupadd -r appuser && useradd -r -g appuser appuser
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production
COPY . .
USER appuser
HEALTHCHECK --interval=30s --timeout=3s CMD node health.js
CMD ["node", "app.js"]

Step 6: Automate Scanning in CI/CD

Manual scanning is a great first step. The real power comes from making it automatic. Here is a minimal GitHub Actions workflow that runs Trivy on every push:

name: Container Security Scan
on: [push, pull_request]

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

      - name: Build image
        run: docker build -t myapp:${{ github.sha }} .

      - name: Run Trivy scan
        uses: aquasecurity/trivy-action@master
        with:
          image-ref: myapp:${{ github.sha }}
          format: sarif
          output: trivy-results.sarif
          severity: CRITICAL,HIGH

      - name: Upload scan results
        uses: github/codeql-action/upload-sarif@v3
        with:
          sarif_file: trivy-results.sarif

This pipeline does three things: builds your image, scans it for CRITICAL and HIGH vulnerabilities, and uploads the results to GitHub Security so your team can track them. You can extend it with a failure threshold — for example, failing the build if any CRITICAL CVE is found.

For deeper CI/CD integration, see theDocker Build CI/CD guidefor recommended patterns.

Real-World Impact: The Cost of Skipping Scans

The 2024Twilio breachprovides a sobering example. Attackers exploited a known vulnerability in a third-party SDK that was already listed in public CVE databases with a fix available. The vulnerability had been published forover six monthsbefore the breach occurred. A routine container scan would have flagged the vulnerable dependency on day one. Twilio's remediation cost exceeded$1 millionin incident response, forensic analysis, and regulatory notifications.

Closer to home, a 2023 study by the Ponemon Institute found that organizations with automated container scanning in CI/CD pipelines had a65% lower average cost per breachcompared to those without — $2.4 million versus $6.9 million. The difference came down todetection speed: scanning teams found known vulnerabilities in hours, non-scanning teams took weeks.

Complete 6-Step Checklist

Print this checklist and keep it near your terminal for every new container project:

• ⬜Pull and inspectyour base image layers (docker history)
• ⬜Run Trivyto enumerate all CVEs (trivy image)
• ⬜Export resultsas JSON for tracking (trivy image --format json)
• ⬜Analyze your DockerfilewithShieldOpsfor configuration issues
• ⬜Fix vulnerabilitiesby updating base images and packages
• ⬜Automatescanning in CI/CD and set a build-fail threshold

Related ShieldOps Reads

• What Is Container Security? A Beginner's Guide— Foundation concepts for your security journey
• Understanding CVEs: How Vulnerability Databases Protect Your Software— Deeper dive into CVE scoring and databases
• Docker vs Kubernetes Security: What Beginners Need to Know— Understanding the security boundaries
• 10 Dockerfile Security Mistakes Putting Containers at Risk— Fix the most common Dockerfile errors
• Secrets Detection: 10 Critical Mistakes That Leak Credentials— Scan for exposed secrets

Frequently Asked Questions

What is the difference between Trivy and ShieldOps?

Trivy scanscontainer imagesfor known CVEs in OS packages and application dependencies. ShieldOps analyzesDockerfilesfor configuration-level security issues — root users, missing HEALTHCHECKs, insecure instructions, compliance violations. They complement each other: Trivy tells youwhatis vulnerable, ShieldOps tells youwhyyour build process is risky. For maximum coverage, use both.

How often should I scan my containers?

Every build in CI/CD, and at least weekly for actively running containers. New CVEs are published daily. An image that passed all scans a month ago may contain critical vulnerabilities today. Schedule regular rescans — Monday morning is a good cadence — and subscribe to CVE feeds for the packages you use.

Can scanning cause downtime or break my container?

No. Scanning is aread-onlyoperation. Tools like Trivy and docker scout inspect the image filesystem without modifying it. They can analyze running containers by looking at their filesystem snapshot but will not stop or restart them. The only risk is discovering something uncomfortable — which is the entire point.

What CVSS score should I use as a build-fail threshold?

Start withCRITICAL (9.0+)as your fail threshold in CI/CD. This blocks the most dangerous vulnerabilities without disrupting development velocity. After your team gains confidence, tighten toHIGH (7.0+). Some teams add a grace period — allow HIGH but flag them for review — while blocking CRITICAL immediately.

Do I need to scan every image in my registry?

Yes, every image in production should be scanned. Prioritize by risk: images exposed to the internet first, internal services second, batch-processing jobs last. Use a registry scanner (Harbor, AWS ECR scanning, Docker Scout) that automatically scans new pushes so nothing slips through.

What is a good vulnerability count to aim for?

There is no magic number. A distroless or scratch-based image can havezeroCVEs from OS packages. A standard Debian-based image will have 50-200+ CVEs at any time. What matters is thetrend: are you reducing CVE count over time? Are all CRITICAL and HIGH issues either fixed or documented as accepted risk? Focus on eliminating the highest severity vulnerabilities rather than chasing a raw count.

Conclusion

Running your first security scan is the single most impactful action you can take to improve your container security posture. With Trivy, ShieldOps, and a CI/CD pipeline, you move from deploying blind to deploying with confidence — knowing exactly what vulnerabilities exist in your images and having a plan to fix them.

Your next step:Create your free ShieldOps accountand upload your first Dockerfile for analysis. The scan takes seconds; the insight lasts the life of your project.