Image and IaC scanning

Match the check to the question

SCA compares dependency versions with known vulnerability data. SAST analyzes source patterns. DAST exercises a running target. An image scan can find vulnerable packages present in the image; an infrastructure-as-code scan can flag risky declarations such as privileged containers. None can reliably infer every business permission rule from package names.

Consider this invented triage case: a report lists package example-lib version 1 with a known vulnerability and a compatible fixed version 2. First establish whether the scanned image is the one deployed, where that package enters the build, and what use exposes it. Update the owning dependency/base image, rebuild, and scan the new image. Merely editing the source dependency while deploying the old image leaves the finding in place. A passing rescan then addresses the known finding; application tests must still check compatibility.

For a configuration finding, read the rendered manifest as well as the original template. A safe base with an overlay that enables privilege can yield an unsafe final object. Save the input revision with the report so you can reproduce the finding later.

Scan the artifact you intend to run

A repository scan, built-image scan, and Kubernetes configuration scan examine different inputs. Record the scanner version, vulnerability database date, exact input revision, and image ID. A clean result is limited to the scanner's rules and data; it is not proof that the application is secure.

After building a named local image, run:

: "${STUDY_TAG:?Select the built Accounts image tag}"
mkdir -p evidence/security
trivy image --image-src docker --scanners vuln \
  --format json --output evidence/security/accounts.json \
  "microbank-study/accounts:$STUDY_TAG"
trivy config --format json --output evidence/security/kubernetes.json infra/study/k8s

Choose a reviewed Trivy release from its official installation instructions. Review its vulnerability-database update and network requirements. These scans do not require deploying into a cloud account.

Triage before changing policy

Pick one finding. Identify the affected package or manifest field, installed version, fixed version if available, exposure in this image, and whether the vulnerable code is used. Upgrade or change the smallest relevant input, rebuild, rerun application tests, and rescan the new image. Save before/after findings tied to the corresponding artifact.

For a CI gate, choose explicit severities and exit behavior; a report-only command need not fail the build. Scanner infrastructure failure must be visible separately from “no findings.” Give each exception a reason, owner, and expiry instead of suppressing findings globally.

Checkpoint

Explain one finding you fixed and one you could not yet resolve. Do not assert that a CVE is exploitable solely because it appears in output. Conversely, do not dismiss a missing API authorization control because a dependency scanner did not detect it.

Check your triage decision

Before the security lab, make a four-row worksheet using hypothetical outcomes: known finding with a fix; finding without a fix; scanner database download failure; missing backend authorization. For the first, assess and test an upgrade. For the second, document exposure and a bounded exception or compensating control. For the third, repair the scanner input and report the check as incomplete. For the fourth, design an application control and negative test. “No findings” is not the correct answer to an incomplete scan.

Use actual output when you run the commands. Next, connect that output to an SBOM and image identity so later checks examine the same artifact.

Sources

Trivy image scans↗, misconfiguration scans↗, and installation↗.