DevSecOps Fundamentals · Module 04 of 12

Dependencies, containers and IaC scanning

Find known vulnerabilities and configuration risks across dependencies, container images and infrastructure code without confusing presence with exploitability.

Learning objectives

By the end of this module, you should be able to:

Explain SCA and image scanning inputs.
Prioritize vulnerability findings using package, version, exposure and fix context.
Identify common IaC/container misconfigurations before deployment.

Inventory drives vulnerability matching

Dependency and image scanners match discovered packages and versions against vulnerability data. Results depend on inventory quality and advisory freshness.

Containers add configuration risk

Base image choice, root user, unnecessary packages, exposed secrets and writable runtime assumptions all influence attack surface.

IaC is reviewable security intent

Security groups, public exposure, encryption and privilege can be checked before resources exist.

Worked example

Prioritization

Finding: library CVE
Context: package present
Questions: reachable? exposed? fixed version? compensating control? owner?
Decision: block / fix / time-bound exception

Connect each finding to a concrete risk and control.
Preserve evidence so a reviewer can reproduce the decision.

Core lab · account-free

Lab 04 — Prioritize synthetic findings

Goal: Apply context to a mixed vulnerability/misconfiguration report.

Before you start

No cloud account required.
Core lab uses bash/Python 3 and local files only.

STEP 1

Create findings

cat > /tmp/devsecops-findings.json <<'EOF'
[{"id":"CVE-DEMO-1","severity":"HIGH","reachable":false,"fix":true},{"id":"CFG-ROOT","severity":"MEDIUM","reachable":true,"fix":true}]
EOF

STEP 2

Rank by policy

python3 - <<'PY'
import json
x=json.load(open('/tmp/devsecops-findings.json'))
priority=sorted(x,key=lambda f:(f['reachable'],f['fix'],f['severity']=='HIGH'),reverse=True)
assert priority[0]['id']=='CFG-ROOT'
print(priority)
PY

STEP 3

Record decision

Explain why severity alone did not determine the first remediation.

Verify

Both findings retain severity and context.
The decision states why reachability/exposure matters.

Expected outcome

A reproducible priority decision exists.

Diagnose / troubleshoot

If scanner data is stale, refresh advisory data before escalating.
If an image digest changed, rescan the exact promoted digest.

Real-world connection

Production teams need deterministic evidence tied to the exact artifact and configuration being promoted.

Optional real-tool lab

Optional tool lab — Trivy

Scan a local repository or image with Trivy using approved targets.

Prerequisites

Install the referenced open-source CLI only for the optional lab.
Use an organization-approved pinned version in real CI; do not blindly use latest.

Cost / risk

Expected cloud cost: none. Use only approved repositories and disposable training artifacts.

Warnings

Never scan or publish real production secrets in a training lab.
Scanner output is evidence for triage, not an automatic statement of exploitable risk.

TOOL 1

trivy --version

TOOL 2

trivy fs --scanners vuln,misconfig,secret . || true

Avoid these traps

Common mistakes

Scanning only source but never the built image.
Using mutable tags as evidence.
Blocking on vulnerabilities with no ownership or remediation path.

Knowledge check

Can you connect the finding to the control?

Three concept checks plus one scenario check.

1What does SCA need to match a vulnerability?

A reliable inventory of packages/components and versions plus vulnerability intelligence.

2Why scan the built image too?

Build steps and base images can introduce components not visible in application source manifests.

3What is IaC scanning good at?

Detecting risky configuration intent before infrastructure is created.

4Scenario: a CVE is HIGH but the component is absent from the final image; another MEDIUM finding runs as root. What should triage do?

Verify exact artifact inventory and prioritize real exposure/control impact instead of severity labels alone.

My Learning

Record your progress for this module.

Progress is saved in this browser immediately. When you sign in to My Learning, it can also sync across devices.

Not started

Core lab attemptedRecord this after meaningfully completing or attempting the module's core lab.Knowledge checks attemptedThis is marked automatically after you open every answer in the module; you can also record it manually.

Attempt the core lab and knowledge checks before marking the module complete.