Lab session
Images, SBOMs, and Scanning
Use Syft and Grype to investigate a container image, address vulnerabilities, and compare the results.
Overview¶
The supplied Dockerfile builds a small HTTP service, but its image contains vulnerable packages. Use Syft to discover what is installed and Grype to find vulnerabilities in those packages. Then revise the Dockerfile and use both tools to understand what your changes accomplished.
Learning Goals¶
After completing this lab, you should be able to:
- Generate a software bill of materials (SBOM) and distinguish operating-system (OS) packages from application packages
- Scan an SBOM with Grype and interpret the affected package, installed version, severity, advisory identifier, and available fix
- Use scan findings to choose a fix and explain how it changes the image
- Check application behavior separately from vulnerability findings
Deliverables¶
By the end of the lab, you should have a revised Dockerfile that addresses vulnerabilities in the image and lab notes explaining your findings and changes. You will submit a PDF of those notes through Canvas. The notes should answer the three questions in Task 4 and include the relevant Dockerfile diff or changed lines.
Keep generated SBOMs and scan reports locally for comparison. You do not need to submit full reports or screenshots.
Setup¶
Start Docker on your computer. Clone the starter repository and open it in VS Code using Dev Containers: Reopen in Container. Run the lab commands from the repository root inside the devcontainer.
The starter includes a Dockerfile, the application source and its npm dependency, and scripts/smoke-test.
The devcontainer provides Syft and Grype.
The smoke test starts a container from your image, checks that /health returns HTTP 200 with the expected response body, and removes the container afterward.
Confirm that the tools are available and download Grype's vulnerability database:
docker info
syft version
grype version
grype db update
grype db status
docker info should show a running server, both tools should print their versions, and the database status should be valid.
The first database download requires an internet connection and may take a few minutes.
If Docker cannot connect, check that Docker is running on your computer and reopen the devcontainer.
If the database download fails, check your connection and rerun grype db update before scanning.
Tasks¶
Task 1: Build and Inventory the Original Image¶
Build the supplied Dockerfile before editing it, then run the smoke test:
docker build --platform linux/amd64 --tag lab03:before .
./scripts/smoke-test lab03:before
The original image should build and pass the smoke test even though it contains vulnerable packages.
Use --platform linux/amd64 to build for the processor architecture supported by the supplied base image.
On Apple silicon, Docker Desktop uses emulation to run this image.
An SBOM is an inventory of the software in an image. Syft identifies installed packages using records such as OS package databases and npm package metadata. Generate an SBOM for the image you just built:
mkdir -p .lab-results
syft docker:lab03:before --output syft-json > .lab-results/before.sbom.json
The docker: prefix tells Syft to inspect the image in your local Docker daemon.
The .lab-results/ directory is ignored by Git and holds your working reports.
Open the JSON file and inspect its artifacts array.
Find one OS package with type deb and the application's dependency with type npm.
Record each package's name, version, and type in your notes.
Read the Dockerfile and package.json to work out how those packages entered the image.
Task 2: Scan the SBOM and Investigate the Findings¶
Grype compares the packages and versions in an SBOM with its database of known vulnerabilities. The SBOM describes what is installed; the scan describes known vulnerabilities associated with those packages and versions. Finding a vulnerable package does not tell you whether your application uses the affected code. Scan the SBOM you saved:
grype sbom:.lab-results/before.sbom.json --by-cve | tee .lab-results/before.scan.txt
sbom: tells Grype to use that inventory, and --by-cve displays CVE identifiers where possible.
tee saves the report while also displaying it in your terminal.
Start with findings marked Critical or High that have a fixed version listed. For a finding you intend to address, identify the package, installed version, fixed version, severity, advisory identifier, and package type. Look up the advisory identifier to read about the vulnerability, then use the Dockerfile and SBOM to trace where the package came from. A listed fixed version tells you which package update addresses the vulnerability. You still need to work out how to include that update in your image. If no fixed version is listed, Grype has not identified an available fix for that finding.
Scan results can change
Grype updates its database as new vulnerability information becomes available. If you scan the same image on another day, you may see different findings even though the image has not changed.
Task 3: Remediate and Compare¶
Revise Dockerfile to address the vulnerabilities you found, prioritizing severe findings with available fixes.
Choose your own changes and keep the supplied application and its dependency working.
Explain why your changes should address the findings, using what you learned from the Dockerfile, SBOM, and advisories.
Build the revised Dockerfile under a new tag, then check the service again:
docker build --platform linux/amd64 --tag lab03:after .
./scripts/smoke-test lab03:after
Generate a new SBOM and scan it:
syft docker:lab03:after --output syft-json > .lab-results/after.sbom.json
grype sbom:.lab-results/after.sbom.json --by-cve | tee .lab-results/after.scan.txt
Compare the affected packages and findings before and after your changes. Check whether the packages were updated or removed and whether the application dependency is still present. For one package affected by a finding you addressed, trace how it entered the original image and use both SBOMs to show its original version and its final version or absence. Explain how your Dockerfile change produced that result and what happened to the associated finding in the scan. If a finding you intended to fix remains, investigate why and revise your change. Rebuild and regenerate the SBOM after each edit; scanning an old SBOM still reports on the old image.
Your final scan may still contain findings. Explain any remaining findings and what prevents you from addressing them. If Grype updates its database between scans, rescan both saved SBOMs so you can compare the results using the same vulnerability information.
A passing smoke test shows that the service still responds as expected.
It checks only the /health response, so other behavior could still have changed.
Check both the smoke-test result and the scan results: fewer vulnerabilities do not tell you whether the service still works.
Task 4: Record What You Learned¶
Write short lab notes answering these questions:
- What was in the original image? Identify one OS package and one application package from the SBOM, including their names, versions, types, and where they came from.
- What problems did you find and change? Describe the findings you addressed, including the affected packages and advisory identifiers, and explain your Dockerfile changes. Include the relevant Dockerfile diff or changed lines.
- What happened afterward? Describe the relevant changes in the final SBOM and scan, any remaining findings, and the smoke-test result. For one package affected by a finding you addressed, connect its source in the original image, its original version, your Dockerfile change, and its final version or absence using evidence from both SBOMs. Explain what happened to the associated scan finding.
A few bullets and selected output are enough. Use the notes to explain what you observed.
Additional Resources¶
- Syft documentation: generating and inspecting SBOMs
- Grype scan targets: scanning images and saved SBOMs
- Grype documentation: interpreting vulnerability findings
- Docker image documentation: how image layers contribute files and packages
Submission¶
Export your lab notes as a PDF and upload it using the Canvas link below.