{"id":1207,"date":"2026-10-11T03:35:02","date_gmt":"2026-10-11T03:35:02","guid":{"rendered":"https:\/\/www.devopsschool.com\/tutorials\/?p=1207"},"modified":"2026-10-11T03:35:05","modified_gmt":"2026-10-11T03:35:05","slug":"trivy-zero-to-intermediate-hands-on-tutorial","status":"publish","type":"post","link":"https:\/\/www.devopsschool.com\/tutorials\/trivy-zero-to-intermediate-hands-on-tutorial\/","title":{"rendered":"Trivy: Zero to Intermediate – Hands-on Tutorial"},"content":{"rendered":"\n

Course duration:<\/strong> 3 hours (180 minutes)
Audience:<\/strong> Absolute beginners, software developers, students, DevOps\/DevSecOps engineers, SREs, and security practitioners
Reference Trivy version:<\/strong> v0.75.0<\/strong>, released October 1, 2026
Last documentation verification:<\/strong> October 11, 2026<\/strong>
Learning style:<\/strong> Approximately 40% concepts and 60% guided practice
Platforms:<\/strong> Windows 11 (PowerShell), macOS (Terminal), Ubuntu Linux (Bash)
Level on completion:<\/strong> Beginner to practical intermediate; not a substitute for a full application-security certification<\/p>\n\n\n\n

\n

Scope and accuracy note:<\/strong> Installation paths, command syntax, supported scanners, filtering, reporting, SBOMs, and GitHub Actions integration were cross-checked against Trivy’s official documentation as of the verification date. Scan output, finding counts, CVEs, fixed versions, and database-update timing change over time and are deliberately not invented here. The labs have not been executed in your environment.<\/strong> Follow the verification steps after each task. For organizational use, validate downloaded binaries and apply your normal software supply-chain controls.<\/p>\n<\/blockquote>\n\n\n\n

Contents<\/h2>\n\n\n\n
    \n
  1. Course plan and lab prerequisites<\/a><\/li>\n\n\n\n
  2. Module 1 \u2014 Introduction to Trivy (10 min)<\/a><\/li>\n\n\n\n
  3. Module 2 \u2014 Security and vulnerability fundamentals (10 min)<\/a><\/li>\n\n\n\n
  4. Module 3 \u2014 Architecture, installation, and setup (15 min)<\/a><\/li>\n\n\n\n
  5. Module 4 \u2014 Container-image scanning (25 min)<\/a><\/li>\n\n\n\n
  6. Module 5 \u2014 Filesystem and repository scanning (15 min)<\/a><\/li>\n\n\n\n
  7. Module 6 \u2014 IaC misconfiguration scanning (20 min)<\/a><\/li>\n\n\n\n
  8. Module 7 \u2014 Secret scanning (10 min)<\/a><\/li>\n\n\n\n
  9. Module 8 \u2014 Filtering, triage, and remediation (20 min)<\/a><\/li>\n\n\n\n
  10. Module 9 \u2014 Reports and SBOMs (15 min)<\/a><\/li>\n\n\n\n
  11. Module 10 \u2014 CI\/CD integration (15 min)<\/a><\/li>\n\n\n\n
  12. Module 11 \u2014 Kubernetes cluster scanning (10 min)<\/a><\/li>\n\n\n\n
  13. Module 12 \u2014 Capstone exercise (15 min)<\/a><\/li>\n\n\n\n
  14. Troubleshooting and production checklist<\/a><\/li>\n\n\n\n
  15. Quick command reference, quiz answers, and official sources<\/a><\/li>\n<\/ol>\n\n\n\n
    \n\n\n\n

    Course plan and lab prerequisites<\/h1>\n\n\n\n

    What you will achieve<\/h2>\n\n\n\n

    After the course, you can independently install Trivy; scan public and local container images; inspect code repositories and dependency lockfiles; detect Terraform, Dockerfile, and Kubernetes misconfigurations; scan for secrets; distinguish actionable vulnerabilities from accepted risks; produce machine-readable reports and software bills of materials; and enforce a simple CI security gate.<\/p>\n\n\n\n

    Timetable and lab deliverables<\/h3>\n\n\n\n
    Module<\/th>Subject<\/th>Minutes<\/th>Learner’s evidence<\/th><\/tr><\/thead>
    1<\/td>Introduction and use cases<\/td>10<\/td>State four classes of findings and two limitations<\/td><\/tr>
    2<\/td>CVE, CVSS, severity, packages<\/td>10<\/td>Explain one sample finding<\/td><\/tr>
    3<\/td>Architecture + installation<\/td>15<\/td>trivy --version<\/code> and first successful scan<\/td><\/tr>
    4<\/td>Container images<\/td>25<\/td>Image scan and a locally built demo image (Docker optional)<\/td><\/tr>
    5<\/td>Filesystem + repositories<\/td>15<\/td>Source-tree and remote-repository scans<\/td><\/tr>
    6<\/td>IaC scanning<\/td>20<\/td>Scan intentionally insecure Terraform and Kubernetes YAML<\/td><\/tr>
    7<\/td>Secret detection<\/td>10<\/td>Scan a synthetic secret and inspect a finding<\/td><\/tr>
    8<\/td>Triage + remediation<\/td>20<\/td>Record, remediate, filter, and rescan one issue<\/td><\/tr>
    9<\/td>JSON, SARIF, and SBOM<\/td>15<\/td>Save three report formats<\/td><\/tr>
    10<\/td>CI\/CD<\/td>15<\/td>Create and understand a GitHub Actions gate<\/td><\/tr>
    11<\/td>Kubernetes<\/td>10<\/td>Manifest scan or optional authorized cluster scan<\/td><\/tr>
    12<\/td>Final practical<\/td>15<\/td>Submit an evidence-based security report<\/td><\/tr>
    Total<\/strong><\/td><\/td>180<\/strong><\/td><\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

    Suggested path:<\/strong> This timetable is an instructor-led agenda. The optional Docker build, Windows\/macOS alternatives, live Kubernetes access, extra exercises, and some download times may extend self-study beyond three hours. Skip optional work when following the strict schedule.<\/p>\n\n\n\n

    Requirements<\/h3>\n\n\n\n
    Item<\/th>Required?<\/th>Why<\/th><\/tr><\/thead>
    Windows\/macOS\/Ubuntu laptop with a terminal<\/td>Yes<\/td>Execute Trivy<\/td><\/tr>
    Internet access to approved registries and Trivy databases<\/td>Yes for initial scans<\/td>Pull images and update scanning databases<\/td><\/tr>
    Permission to install a local CLI<\/td>Yes<\/td>Install Trivy and optional utilities<\/td><\/tr>
    Text editor, e.g., VS Code<\/td>Yes<\/td>Save and edit practice files<\/td><\/tr>
    Git<\/td>Recommended<\/td>Clone the safe teaching repository and commit CI config<\/td><\/tr>
    Docker Engine \/ Docker Desktop<\/td>Optional for image-building task<\/td>Build an image locally; public-image scans can work without a local Docker daemon<\/td><\/tr>
    jq<\/code><\/td>Optional on Windows, recommended on macOS\/Linux<\/td>Explore JSON reports; alternatives are given<\/td><\/tr>
    GitHub repository with Actions enabled<\/td>Optional<\/td>Actually run the CI workflow; the YAML can be studied offline<\/td><\/tr>
    kubectl<\/code> plus permission to read a Kubernetes cluster<\/td>Optional<\/td>Live-cluster demo only; YAML scanning requires no cluster<\/td><\/tr>
    Terraform CLI, an AWS account, or cloud credentials<\/td>Not required<\/strong><\/td>Trivy performs static scanning on the local .tf<\/code> files<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

    Safety boundary:<\/strong> Practice only on sample files, public images, and systems you are authorized to scan. Never paste real credentials into a lab. Do not terraform apply<\/code> insecure examples, expose a test cluster, or grant broad Kubernetes permissions just for a demonstration. Scanners do not prove an application is secure; they provide evidence to analyze.<\/p>\n\n\n\n

    Lab workspace and shell conventions<\/h3>\n\n\n\n

    Use this workspace for all modules. Bash<\/strong> commands apply directly to macOS Terminal, Ubuntu, and Git Bash\/WSL on Windows. PowerShell<\/strong> examples are called out explicitly. For Windows without Bash, create the same named files using your editor and run Trivy in PowerShell; the trivy<\/code> commands themselves are shell-neutral.<\/p>\n\n\n\n

    # Bash \u2014 macOS\/Ubuntu\/Git Bash\/WSL<\/em>\nmkdir -p \"$HOME\/trivy-workshop\"\/{app,terraform,kubernetes,secrets,reports}\ncd \"$HOME\/trivy-workshop\"\npwd\n<\/code><\/pre>\n\n\n\n
    # PowerShell \u2014 Windows; no Administrator rights needed<\/em>\n$Lab = Join-Path $HOME 'trivy-workshop'\n'app','terraform','kubernetes','secrets','reports' | ForEach-Object {\n  New-Item -ItemType Directory -Force -Path (Join-Path $Lab $_) | Out-Null\n}\nSet-Location $Lab\nGet-Location\n<\/code><\/pre>\n\n\n\n
    Expected: an empty trivy-workshop<\/code> folder containing app\/<\/code>, terraform\/<\/code>, kubernetes\/<\/code>, secrets\/<\/code>, and reports\/<\/code>. All subsequent commands assume you are inside trivy-workshop<\/code> unless otherwise stated.<\/p>\n\n\n\n
    \n\n\n\n
    Module 1 \u2014 Introduction to Trivy (10 min)<\/h1>\n\n\n\n
    Objectives<\/h2>\n\n\n\n
    Define Trivy and DevSecOps; identify its principal scan targets and security findings; explain the difference between finding potential exposure and detecting an active attack; and know when to use each mode.<\/p>\n\n\n\n
    What is Trivy?<\/h2>\n\n\n\n
    Trivy<\/strong> is an open-source security scanner maintained by Aqua Security and contributors. It inspects artifacts and configurations for known package vulnerabilities<\/strong>, security misconfigurations<\/strong>, exposed secrets<\/strong>, and license-related findings<\/strong>. Trivy can scan container images, filesystem directories, repositories, SBOMs, Kubernetes clusters, and other supported targets. Each target has different default scanners, so check --scanners<\/code> rather than assuming every check runs automatically.<\/p>\n\n\n\n
    In DevSecOps<\/strong>, teams include security checks during development, commits, builds, deployments, and operations rather than waiting for a final audit. Shift left<\/strong> means bringing useful checks earlier in that flow. Trivy helps identify many preventable problems while developers can still change code, dependencies, or configuration easily.<\/p>\n\n\n\n
    Targets vs. findings: the key distinction<\/h3>\n\n\n\n
    Target = what you inspect<\/th>Example command<\/th>Typical question<\/th><\/tr><\/thead>
    Container image<\/td>trivy image alpine:3.20<\/code><\/td>Are installed OS or library packages vulnerable?<\/td><\/tr>
    Local source tree<\/td>trivy fs .<\/code><\/td>Are dependency lockfiles or plaintext secrets problematic?<\/td><\/tr>
    Remote source repository<\/td>trivy repo https:\/\/github.com\/aquasecurity\/trivy-ci-test<\/code><\/td>What known problems exist in the repository?<\/td><\/tr>
    IaC and configuration<\/td>trivy config .\/kubernetes<\/code><\/td>Are manifest permissions or container security settings unsafe?<\/td><\/tr>
    Generated SBOM<\/td>trivy sbom .\/reports\/sbom.json<\/code><\/td>Are any inventoried dependencies known-vulnerable?<\/td><\/tr>
    Kubernetes cluster<\/td>trivy k8s --report summary<\/code><\/td>What issues are discoverable from authorized cluster access?<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
    Finding types:<\/strong> vulnerability (vuln<\/code>), misconfiguration (misconfig<\/code>), secret (secret<\/code>), and license (license<\/code>). Some other Trivy capabilities are outside this course.<\/p>\n\n\n\n
    Trivy compared with other approaches<\/h3>\n\n\n\n
    Approach<\/th>Main purpose<\/th>Trivy relationship<\/th><\/tr><\/thead>
    Application log monitoring<\/td>Observe what happened at runtime<\/td>Complementary: Trivy does not replace event monitoring<\/td><\/tr>
    Antivirus\/EDR<\/td>Detect suspicious files or endpoint behavior<\/td>Complementary: Trivy is not a complete EDR\/antivirus replacement<\/td><\/tr>
    DAST or penetration testing<\/td>Exercise a running application’s exposed behavior<\/td>Complementary: Trivy does not prove an exploit works<\/td><\/tr>
    Traditional CVE\/SCA scanner<\/td>Match dependencies to known advisories<\/td>Overlapping functionality; Trivy also handles images and configuration<\/td><\/tr>
    Admission policy \/ runtime defense<\/td>Stop or investigate workloads at runtime<\/td>Complementary: use policies and runtime tools alongside Trivy<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
    What Trivy cannot guarantee<\/h3>\n\n\n\n
    Trivy cannot promise to find zero-day vulnerabilities without applicable detection data, prove exploitability solely from a CVE record, reveal every business-logic flaw, inspect every dynamic runtime state, establish compliance by itself, or fix findings automatically. No output is not proof of no risk.<\/p>\n\n\n\n
    Mini exercise (2 minutes):<\/strong> Say which scan target you would choose for (a) an old Docker image, (b) an open-to-the-world SSH security group in Terraform, (c) a credential in a source file, and (d) a live Kubernetes cluster. Answers: image<\/code>, config<\/code>, fs<\/code>\/repo<\/code> with secret<\/code>, and k8s<\/code>, respectively.<\/p>\n\n\n\n
    Checkpoint:<\/strong> Explain in your own words why a CVE scan and runtime intrusion detection are different.<\/p>\n\n\n\n
    \n\n\n\n
    Module 2 \u2014 Security and vulnerability fundamentals (10 min)<\/h1>\n\n\n\n
    Objectives<\/h2>\n\n\n\n
    Understand vulnerability, threat, risk, CVE, CWE, CVSS, advisory severity, fixed version, and the two major sources of vulnerable packages.<\/p>\n\n\n\n
    Core vocabulary<\/h3>\n\n\n\n
    Term<\/th>Plain-English definition<\/th><\/tr><\/thead>
    Asset<\/strong><\/td>Something worth protecting: image, server, application, credential, or customer data<\/td><\/tr>
    Vulnerability<\/strong><\/td>A weakness that may be exploited<\/td><\/tr>
    Threat<\/strong><\/td>An actor, event, or technique that could take advantage of a weakness<\/td><\/tr>
    Risk<\/strong><\/td>Likelihood and business impact of an unwanted outcome, informed by exposure<\/td><\/tr>
    CVE<\/strong><\/td>Common Vulnerabilities and Exposures identifier for a published issue, such as CVE-YYYY-NNNN<\/code><\/td><\/tr>
    CWE<\/strong><\/td>Common Weakness Enumeration: category of underlying software weakness<\/td><\/tr>
    CVSS<\/strong><\/td>Common Vulnerability Scoring System: a structured severity scoring framework<\/td><\/tr>
    IOC<\/strong><\/td>Indicator of compromise, for example evidence of a malicious file or network destination<\/td><\/tr>
    SCA<\/strong><\/td>Software Composition Analysis: identify third-party components and known vulnerabilities<\/td><\/tr>
    OS package<\/strong><\/td>Operating-system-managed dependency, e.g., openssl<\/code> or libc<\/code><\/td><\/tr>
    Language library<\/strong><\/td>App dependency, e.g., a Python package or Node.js npm package<\/td><\/tr>
    Fixed version<\/strong><\/td>An available vendor-supported version containing a relevant fix, if one exists<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
    Severity and practical priority<\/h3>\n\n\n\n
    Trivy reports UNKNOWN<\/strong>, LOW<\/strong>, MEDIUM<\/strong>, HIGH<\/strong>, and CRITICAL<\/strong>. A critical-looking result is important, but severity alone is not a complete remediation policy. Consider reachability, network exposure, privileges, business impact, exploit activity, availability of a fix, and compensating controls. Trivy uses ecosystem-specific vulnerability sources, and distro-maintained backports can mean package version comparisons are not as simple as upstream version ordering.<\/p>\n\n\n\n
    Hypothetical example \u2014 not a real detected CVE:<\/strong><\/p>\n\n\n\n
    Field<\/th>Example<\/th>Interpretation<\/th><\/tr><\/thead>
    Finding ID<\/td>CVE-20XX-12345<\/code><\/td>Look up the advisory and the affected conditions<\/td><\/tr>
    Package<\/td>examplelib<\/code><\/td>Dependency containing the weak component<\/td><\/tr>
    Installed version<\/td>1.2.0<\/code><\/td>Version currently inventoried<\/td><\/tr>
    Fixed version<\/td>1.2.9<\/code><\/td>Candidate update, if compatible and vendor supported<\/td><\/tr>
    Severity<\/td>HIGH<\/code><\/td>Strong triage signal, not proof of exploitability<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
    Why both operating-system and application scanning matter<\/h3>\n\n\n\n
    A container image might bundle an Ubuntu\/Debian base with OS packages and<\/strong> Python\/Java\/npm dependencies. Updating application dependencies without updating the base image leaves OS problems behind; replacing the base without updating lockfiles may leave library findings. A useful remediation plan addresses both.<\/p>\n\n\n\n
    Micro-quiz:<\/strong> (1) Is a CVE an attack? (2) Does a missing fixed version mean the finding is false? (3) Can a distro backport a fix without changing to the upstream major version? Answers:<\/strong> No; no; yes.<\/p>\n\n\n\n
    \n\n\n\n
    Module 3 \u2014 Architecture, installation, and setup (15 min)<\/h1>\n\n\n\n
    Objectives<\/h2>\n\n\n\n
    Understand how scanners run, install the CLI on your OS, verify its operation, and know what the vulnerability database and local cache do.<\/p>\n\n\n\n
    How a scan works<\/h3>\n\n\n\n
    flowchart LR\n    A[Target: image, filesystem, repo, config, Kubernetes] --> B[Trivy CLI]\n    B --> C[Inventory packages and inspect files or configuration]\n    C --> D[Select enabled scanners]\n    E[Vulnerability and policy data \/ updates] --> D\n    D --> F[Match vulnerabilities, misconfigs, secrets, licenses]\n    F --> G[Apply severity and suppression filters]\n    G --> H[Table, JSON, SARIF, SBOM \/ exit code]\n<\/code><\/pre>\n\n\n\n
    Trivy analyzes the target, identifies relevant packages and files, consults vulnerability databases and built-in or downloaded security checks, then returns structured results. It does not<\/strong> need a persistent background service in normal standalone CLI mode. A client\/server<\/strong> mode exists for specialized centralized deployments but is out of scope for this workshop.<\/p>\n\n\n\n
    Updates and caches:<\/strong> The first scan usually downloads database\/check content and takes longer. Later scans can reuse local copies and refresh them as necessary. Network policy must permit the approved registry and database endpoints. Offline\/air-gapped operation requires separate pre-provisioning and maintenance procedures; it is not achieved merely by adding --skip-db-update<\/code> on an empty installation.<\/p>\n\n\n\n
    Quick Installation and Configuration<\/h2>\n\n\n\n
    Choose one<\/strong> OS method below. No AWS\/cloud login is needed. For Docker-based exercises, install Docker Desktop or Docker Engine separately from its official site; scanning public remote images does not automatically require Docker to be running.<\/p>\n\n\n\n
    Ubuntu Linux \u2014 official APT repository<\/h3>\n\n\n\n
    Where:<\/strong> Ubuntu Terminal (Bash). Privileges:<\/strong> sudo<\/code> for OS package installation only. Dependencies:<\/strong> wget<\/code>, gnupg<\/code>, CA certificates; git<\/code> and jq<\/code> aid later exercises.<\/p>\n\n\n\n
    # Step 1: prepare dependencies<\/em>\nsudo apt-get update\nsudo apt-get install -y ca-certificates wget curl gnupg git jq\n\n# Step 2: install the public signing key from the official Trivy repository<\/em>\nwget -qO - https:\/\/aquasecurity.github.io\/trivy-repo\/deb\/public.key \\\n  | gpg --dearmor \\\n  | sudo tee \/usr\/share\/keyrings\/trivy.gpg >\/dev\/null\n\n# Step 3: register the official package repository<\/em>\nprintf '%s\\n' \\\n  'deb [signed-by=\/usr\/share\/keyrings\/trivy.gpg] https:\/\/aquasecurity.github.io\/trivy-repo\/deb generic main' \\\n  | sudo tee \/etc\/apt\/sources.list.d\/trivy.list\n\n# Step 4: install and verify<\/em>\nsudo apt-get update\nsudo apt-get install -y trivy\ntrivy --version\ncommand -v trivy\n<\/code><\/pre>\n\n\n\n
    Expected:<\/strong> trivy --version<\/code> shows a version number; the target for this tutorial is 0.75.0<\/code>. The APT repository may provide newer versions later. To reproduce precisely, use the official v0.75.0 release package appropriate to your CPU architecture after validating the release checksums\/signature. If your network blocks the repository, involve your package administrator rather than disabling TLS or signature checking.<\/p>\n\n\n\n
    Check:<\/strong> trivy image --scanners vuln alpine:3.20<\/code> should reach a public registry and complete an image scan. Zero or multiple findings are both possible; success means the command completes without a download\/scan error.<\/p>\n\n\n\n
    Common problem:<\/strong> NO_PUBKEY<\/code>\/repository signature problem \u2192 confirm the key was downloaded from the intended host, keyring is readable, and source-list entry matches; do not disable GPG verification.<\/p>\n\n\n\n
    macOS \u2014 official Homebrew method<\/h3>\n\n\n\n
    Where:<\/strong> macOS Terminal. Privileges:<\/strong> normal user with working Homebrew; do not use sudo brew<\/code>. Dependencies:<\/strong> Homebrew installed from brew.sh<\/a> via your organization-approved process; optional git<\/code>, jq<\/code>, and Docker Desktop.<\/p>\n\n\n\n
    # Step 1: confirm Homebrew exists<\/em>\nbrew --version\n\n# Step 2: install Trivy and convenient tutorial tools<\/em>\nbrew update\nbrew install trivy git jq\n\n# Step 3: verify the executable and version<\/em>\ntrivy --version\ncommand -v trivy\n\n# Step 4: first public-image scan (no local Docker daemon required)<\/em>\ntrivy image --scanners vuln alpine:3.20\n<\/code><\/pre>\n\n\n\n
    Expected:<\/strong> Brew places trivy<\/code> on the shell PATH and the image scan produces a report. On Apple Silicon, Homebrew commonly uses \/opt\/homebrew\/bin<\/code>; on Intel, \/usr\/local\/bin<\/code>. Avoid hardcoding either path.<\/p>\n\n\n\n
    Common problem:<\/strong> zsh: command not found: brew<\/code> \u2192 install\/initialize Homebrew using its own printed post-install instructions and open a new terminal. zsh: command not found: trivy<\/code> \u2192 verify brew list trivy<\/code> and brew --prefix<\/code> and repair the Homebrew PATH.<\/p>\n\n\n\n
    Windows 11 \u2014 official release ZIP via PowerShell<\/h3>\n\n\n\n
    Where:<\/strong> Windows PowerShell<\/strong> (not Bash), normal user. Privileges:<\/strong> Administrator is not<\/strong> required if installing under your own profile. Dependencies:<\/strong> network access to GitHub Releases; ZIP extraction is built in. The example is for 64-bit x86 Windows<\/strong>; use a release asset matching your hardware if different.<\/p>\n\n\n\n
    # Step 1: define the verified target version and per-user install location<\/em>\n$Version = '0.75.0'\n$InstallDir = Join-Path $HOME 'Tools\\Trivy'\n$ZipPath = Join-Path $env:TEMP ('trivy_' + $Version + '_windows-64bit.zip')\n$Url = 'https:\/\/github.com\/aquasecurity\/trivy\/releases\/download\/v' +\n       $Version + '\/trivy_' + $Version + '_windows-64bit.zip'\n\n# Step 2: download only from the official GitHub release<\/em>\nNew-Item -ItemType Directory -Force -Path $InstallDir | Out-Null\nInvoke-WebRequest -Uri $Url -OutFile $ZipPath\n\n# Step 3: unpack and check the downloaded executable<\/em>\nExpand-Archive -Path $ZipPath -DestinationPath $InstallDir -Force\n& (Join-Path $InstallDir 'trivy.exe') --version\n\n# Step 4: persist a per-user PATH entry if it is not present<\/em>\n$UserPath = [Environment]::GetEnvironmentVariable('Path','User')\nif (($UserPath -split ';') -notcontains $InstallDir) {\n    [Environment]::SetEnvironmentVariable(\n        'Path', (($UserPath.TrimEnd(';') + ';' + $InstallDir).TrimStart(';')), 'User')\n}\n$env:Path += ';' + $InstallDir\n\n# Step 5: run the first scan<\/em>\ntrivy --version\ntrivy image --scanners vuln alpine:3.20\n<\/code><\/pre>\n\n\n\n
    Expected:<\/strong> trivy.exe<\/code> reports version 0.75.0<\/code>; the scan completes and prints findings or a zero-finding summary. New PowerShell windows receive the updated user PATH. Windows Defender\/organization download policies may require approval.<\/p>\n\n\n\n
    Common problem:<\/strong> ZIP returns HTTP 404 \u2192 visit official release assets<\/a> and confirm exact asset name and CPU architecture. trivy<\/code> not found \u2192 use & (Join-Path $InstallDir 'trivy.exe') --version<\/code>, restart PowerShell, and verify PATH. Do not disable endpoint protections to force installation.<\/p>\n\n\n\n
    Optional containerized Trivy instead of host installation<\/h3>\n\n\n\n
    On a Linux host with Docker, you can run the official image without installing the CLI globally:<\/p>\n\n\n\n
    # Linux Docker; public-image scan without mounting Docker socket<\/em>\n# First run may fetch the image and database. Cache is persisted to a user directory.<\/em>\nmkdir -p \"$HOME\/.cache\/trivy-container\"\ndocker run --rm \\\n  -v \"$HOME\/.cache\/trivy-container:\/root\/.cache\/\" \\\n  aquasec\/trivy:0.75.0 image --scanners vuln alpine:3.20\n<\/code><\/pre>\n\n\n\n
    For scanning local<\/strong> daemon images, socket mounting gives containerized Trivy broad access to the host Docker engine; treat that as privileged access and use it only in a trusted lab. This option is supplemental, not a requirement.<\/p>\n\n\n\n
    CLI essentials and version check<\/h3>\n\n\n\n
    trivy --help                 # List top-level targets and commands<\/em>\ntrivy image --help           # Inspect flags for image scans<\/em>\ntrivy fs --help              # Inspect filesystem-scan flags<\/em>\ntrivy config --help          # Inspect IaC-only scanning options<\/em>\ntrivy --version              # Check the installed CLI version<\/em>\n<\/code><\/pre>\n\n\n\n
    Typical syntax is trivy <target> [flags] <path-or-image><\/code>. --scanners<\/code> chooses finding classes; --severity<\/code> filters output by severity; --format<\/code> changes the report format; --output<\/code> writes a file; and --exit-code<\/code> changes the exit status when qualifying findings exist. The defaults differ by scan target, so explicit scanner selection improves reproducibility.<\/p>\n\n\n\n
    Checkpoint:<\/strong> Why might the first scan take longer? What is the difference between a scan target and a scanner? Is a Docker daemon required for scanning a public image by registry access?<\/p>\n\n\n\n
    \n\n\n\n
    Module 4 \u2014 Container-image scanning (25 min)<\/h1>\n\n\n\n
    Objectives and prerequisites<\/h2>\n\n\n\n
    Learn the image-layer and package concepts, scan an old and current image, identify affected packages, filter by severity, distinguish --ignore-unfixed<\/code> from remediation, and optionally build and scan your own container. Prerequisite: Module 3 installation and registry access. Docker is needed only<\/strong> for the local-image build.<\/p>\n\n\n\n
    What is inside an image?<\/h3>\n\n\n\n
    A container image typically contains a base operating-system filesystem<\/strong>, installed system libraries<\/strong>, optional language packages<\/strong>, application files, and image metadata. Trivy primarily inventories known components and compares them with applicable advisories; a container image is not automatically safe because its app source code is small or its tag says latest<\/code>.<\/p>\n\n\n\n
    flowchart TD\n    A[Image: application + language packages + OS base] --> B[Package \/ metadata inventory]\n    B --> C[OS-vulnerability advisory matching]\n    B --> D[Application-library advisory matching]\n    C --> E[Combined results]\n    D --> E\n    E --> F[Review CVEs, fix versions, exploit context]\n    F --> G[Update base image or dependencies]\n    G --> H[Rebuild and rescan]\n<\/code><\/pre>\n\n\n\n
    Lab 4A \u2014 Scan a public image<\/h2>\n\n\n\n
    Where:<\/strong> Terminal\/PowerShell in trivy-workshop<\/code>. Prerequisite:<\/strong> Trivy is on PATH; internet access. No Docker daemon required for this portion.<\/strong><\/p>\n\n\n\n
    # 1. Basic image vulnerability scan<\/em>\ntrivy image --scanners vuln nginx:1.20\n\n# 2. Restrict displayed results to HIGH and CRITICAL<\/em>\ntrivy image --scanners vuln --severity HIGH,CRITICAL nginx:1.20\n\n# 3. Display findings for which the advisory identifies an available fix<\/em>\ntrivy image --scanners vuln --ignore-unfixed nginx:1.20\n\n# 4. Compare against a more current maintained image channel<\/em>\ntrivy image --scanners vuln --severity HIGH,CRITICAL nginx:stable-alpine\n<\/code><\/pre>\n\n\n\n
    Flags explained:<\/strong> image<\/code> selects the image target; --scanners vuln<\/code> makes the intent explicit; --severity HIGH,CRITICAL<\/code> filters the visible severities; --ignore-unfixed<\/code> hides findings without a reported fix. It does not<\/strong> patch software or establish that an unfixed issue is harmless.<\/p>\n\n\n\n
    Expected result:<\/strong> A report identifies the target and possibly one or more vulnerable packages with IDs, severities, installed versions, and fix-version information. Counts are intentionally unspecified<\/strong> because registry contents, OS support, advisory feeds, and the current DB change. If nginx:1.20<\/code> is no longer retrievable, choose another intentionally older public demo image from an authorized registry and record the actual tag.<\/p>\n\n\n\n
    Verification:<\/strong> Both scans complete without a registry\/network error. Write down two package names (if findings exist), their severity, whether a fix is listed, and whether the issue is from the base OS or an application library.<\/p>\n\n\n\n
    Reading the report<\/h3>\n\n\n\n
    Result column<\/th>What it means<\/th>Action<\/th><\/tr><\/thead>
    Library<\/code> \/ package name<\/td>Detected affected software component<\/td>Identify dependency owner<\/td><\/tr>
    Vulnerability<\/code><\/td>CVE\/advisory ID<\/td>Read vendor advisory and affected conditions<\/td><\/tr>
    Severity<\/code><\/td>Advisory risk category<\/td>Prioritize with real system context<\/td><\/tr>
    Installed Version<\/code><\/td>Component version in the artifact<\/td>Verify artifact provenance<\/td><\/tr>
    Fixed Version<\/code><\/td>Published fixed candidate, if any<\/td>Evaluate update or rebuild<\/td><\/tr>
    Status<\/code>, where shown<\/td>Whether fix exists or vendor accepts\/deferred work<\/td>Decide treatment and record exceptions<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
    Avoid two beginner errors: (1) treating image tags as immutable; in real releases prefer image digests and traceable build IDs; and (2) equating zero displayed HIGH\/CRITICAL findings with a secure image.<\/p>\n\n\n\n
    Lab 4B \u2014 Build a tiny local image (optional Docker track)<\/h2>\n\n\n\n
    Where:<\/strong> trivy-workshop<\/code> on macOS\/Linux\/Git Bash\/WSL, or use a text editor on Windows. Prerequisite:<\/strong> Docker Engine\/Desktop running. We create a very small HTTP server using Python standard library; no pip install<\/code> is needed.<\/p>\n\n\n\n
    File 1 \u2014 app\/server.py<\/code> (entire file):<\/strong><\/p>\n\n\n\n
    from http.server import BaseHTTPRequestHandler, HTTPServer\n\nclass Handler(BaseHTTPRequestHandler):\n    def do_GET(self):\n        self.send_response(200)\n        self.send_header(\"Content-Type\", \"text\/plain; charset=utf-8\")\n        self.end_headers()\n        self.wfile.write(b\"Trivy lab application is running\\n\")\n\nif __name__ == \"__main__\":\n    HTTPServer((\"0.0.0.0\", 8080), Handler).serve_forever()\n<\/code><\/pre>\n\n\n\n
    File 2 \u2014 Dockerfile<\/code> (intentionally simplified learning configuration):<\/strong><\/p>\n\n\n\n
    FROM python:3.11-slim\nWORKDIR \/opt\/app\nCOPY app\/server.py .\/server.py\nEXPOSE 8080\nCMD [\"python\", \"server.py\"]\n<\/code><\/pre>\n\n\n\n
    The example is intentionally missing an explicit non-root USER<\/code>; this creates material to inspect and fix later. It is not<\/strong> a production Dockerfile.<\/p>\n\n\n\n
    Bash file creation (copy ready):<\/strong><\/p>\n\n\n\n
    # In ~\/trivy-workshop<\/em>\nmkdir -p app\ncat > app\/server.py <<'PY'\nfrom http.server import BaseHTTPRequestHandler, HTTPServer\n\nclass Handler(BaseHTTPRequestHandler):\n    def do_GET(self):\n        self.send_response(200)\n        self.send_header(\"Content-Type\", \"text\/plain; charset=utf-8\")\n        self.end_headers()\n        self.wfile.write(b\"Trivy lab application is running\\n\")\n\nif __name__ == \"__main__\":\n    HTTPServer((\"0.0.0.0\", 8080), Handler).serve_forever()\nPY\n\ncat > Dockerfile <<'DOCKERFILE'\nFROM python:3.11-slim\nWORKDIR \/opt\/app\nCOPY app\/server.py .\/server.py\nEXPOSE 8080\nCMD [\"python\", \"server.py\"]\nDOCKERFILE\n\n# Build, inspect, and scan\n\ndocker build -t trivy-workshop:insecure .\ndocker image inspect trivy-workshop:insecure --format '{{.Id}}'\ntrivy image --scanners vuln trivy-workshop:insecure\ntrivy config .\/Dockerfile\n<\/code><\/pre>\n\n\n\n
    Windows without Bash:<\/strong> Save the two shown file contents in trivy-workshop\\app\\server.py<\/code> and trivy-workshop\\Dockerfile<\/code> using VS Code. In PowerShell from trivy-workshop<\/code>, run the same docker build<\/code>, docker image inspect<\/code>, trivy image<\/code>, and trivy config<\/code> commands. The double braces in docker image inspect<\/code> are Docker template syntax, not placeholders.<\/p>\n\n\n\n
    Expected:<\/strong> docker build<\/code> exits successfully; docker image inspect<\/code> prints an image identifier; trivy image<\/code> analyzes the local image. The config scan may flag the lack of an explicit non-root user and other defaults depending on current policies.<\/p>\n\n\n\n
    Optional runtime verification:<\/strong><\/p>\n\n\n\n
    # Docker publishes port 8080 on localhost only; Ctrl+C stops the foreground container.<\/em>\ndocker run --rm -p 127.0.0.1:8080:8080 trivy-workshop:insecure\n# In a second terminal:<\/em>\ncurl http:\/\/127.0.0.1:8080\/\n<\/code><\/pre>\n\n\n\n
    PowerShell equivalent verification: Invoke-WebRequest http:\/\/127.0.0.1:8080\/ | Select-Object -ExpandProperty Content<\/code>.<\/p>\n\n\n\n
    Expected response:<\/strong> Trivy lab application is running<\/code>. A successful runtime test does not<\/strong> prove the image is secure.<\/p>\n\n\n\n
    Lab 4C \u2014 Remediate and rescan<\/h2>\n\n\n\n
    After observing image and Dockerfile results, replace Dockerfile<\/code> with this improved baseline<\/strong>:<\/p>\n\n\n\n
    FROM python:3.11-slim\nRUN useradd --create-home --uid 10001 appuser\nWORKDIR \/opt\/app\nCOPY --chown=appuser:appuser app\/server.py .\/server.py\nUSER appuser\nEXPOSE 8080\nCMD [\"python\", \"server.py\"]\n<\/code><\/pre>\n\n\n\n
    # Optional Docker track only<\/em>\ndocker build -t trivy-workshop:nonroot .\ntrivy config .\/Dockerfile\ntrivy image --scanners vuln trivy-workshop:nonroot\n<\/code><\/pre>\n\n\n\n
    Verify:<\/strong> Dockerfile now explicitly declares a non-root user. Some misconfiguration results may disappear; dependency vulnerabilities may remain<\/strong> because both versions use the same base image. In production, also lock an approved base digest<\/strong>, rebuild regularly, test as non-root, and evaluate running with immutable\/readonly filesystems where appropriate.<\/p>\n\n\n\n
    Common problems:<\/strong> Cannot connect to the Docker daemon<\/code> \u2192 start Docker or skip the local build; UNAUTHORIZED<\/code>\/TOOMANYREQUESTS<\/code> \u2192 authenticate to the allowed registry or try later; unable to fetch a tag \u2192 verify the tag exists; high findings with blank fixed version \u2192 plan mitigation, upstream replacement, or documented risk acceptance rather than inventing a patch.<\/p>\n\n\n\n
    Checkpoint:<\/strong> What is the functional difference between --ignore-unfixed<\/code> and upgrading a package? Why could an updated Dockerfile still produce image CVEs?<\/p>\n\n\n\n
    \n\n\n\n
    Module 5 \u2014 Filesystem and repository scanning (15 min)<\/h1>\n\n\n\n
    Objectives<\/h2>\n\n\n\n
    Differentiate trivy fs<\/code> and trivy repo<\/code>; understand dependency manifests versus lockfiles; scan a folder and a remote repository; explicitly enable several scanner classes.<\/p>\n\n\n\n
    Filesystem vs. Git repository<\/h3>\n\n\n\n