Find a Vulnerable Package and Generate an SPDX SBOM
The alpine Deployment in the alpine namespace has three containers that run different versions of the alpine image.
Live lab access
This task description is public. Live practice requires full access unless this is the selected free weekly task. AI Lab Coach is available in single-task labs, including the free weekly task. See this week's free task.
Create an account to continue →
On a phone? Read the task and create your account here, then sign in on a desktop or laptop for the terminal lab. Nothing starts until you choose Start.
The task
Task
The alpine Deployment in the alpine namespace has three containers that run different versions of the alpine image.
First, find out which version of the alpine image contains the libcrypto3 package at version 3.1.4-r5.
Next, use the pre-installed bom tool to create an SPDX document for the identified image version at /home/candidate/alpine.spdx.
> You can find the bom tool documentation with bom --help.
Original Prepium guide · Written for Kubernetes v1.35 and checked against the official documentation on 6 October 2026. Use a disposable practice cluster. The bom examples need network access to pull images, or a local image archive.
Inventory what is inside an image: package queries and SPDX SBOMs
A software bill of materials (SBOM) lists the components inside an artifact, with versions and licences, so you can answer "are we running the vulnerable build?" without guessing. SPDX is an open standard for exchanging that information (also published as ISO/IEC 5962:2021), and bom, created to produce the Kubernetes project's own SBOMs, generates SPDX documents for images, directories and archives. Supply-chain tasks usually combine both: query packages to find the right image, then produce its SBOM.
Pod ──→ containers[].image ──→ apk inside each container (which version is where?)
image ref ──→ bom generate ──→ SPDX document (PackageName / PackageVersion per package)
1. List the images a workload actually runs
kubectl create namespace prepium-tutorial
kubectl -n prepium-tutorial run older --image=alpine:3.19 --command -- sleep 3600
kubectl -n prepium-tutorial run newer --image=alpine:3.20 --command -- sleep 3600
kubectl -n prepium-tutorial get pods -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.spec.containers[*].image}{"\n"}{end}'
For a multi-container Pod, the same jsonpath on one Pod prints every container's image; pair each image with its container name before you start exec-ing.
2. Ask the package manager inside each container
Alpine images use apk. Two read-only queries cover most needs:
kubectl -n prepium-tutorial exec older -- apk info zlib
kubectl -n prepium-tutorial exec older -- apk list -I | grep '^zlib'
kubectl -n prepium-tutorial exec newer -- apk list -I | grep '^zlib'
apk info <package> prefixes each field with the package name and its full version, so the heading line shows something like zlib-<version>-r<n>. apk list -I (long form --installed) restricts the listing to installed packages. Compare the full string, including the -r release suffix: two images can carry the same upstream version with different Alpine rebuilds. apk info -W <file> tells you which package owns a given file, useful when you only know a library name.
3. Generate an SPDX document with bom
bom generate --image alpine:3.20 --format tag-value --output alpine-3.20.spdx
bom generate --image alpine:3.20 --output alpine-3.20.spdx.json
grep -A3 '^PackageName: zlib' alpine-3.20.spdx
--image (short -i) names the image, --output (-o) the file; without -o the document goes to standard output. The default format changed between releases: the v0.7 README lists tag-value as the default, while v0.8 writes SPDX 2.3 JSON unless told otherwise. Always pass --format explicitly and check bom generate --help on the machine you are using. For Alpine, Debian and RPM-based images, bom records the OS packages, so the SBOM should show the same version strings apk reported.
4. Read the result
In tag-value form each package block carries PackageName: and PackageVersion: lines; JSON output uses name and versionInfo. For a quick tree view of a JSON SBOM, bom document outline alpine-3.20.spdx.json draws the document's structure.
Common mistakes
- Querying one container only:
kubectl execwithout-cuses the default-container annotation or the first container, so the other images are never checked. - Generating the SBOM for a tag that has moved since the Pod started: use the exact image reference from the Pod spec (or its digest) so the document describes what actually runs.
- Relying on bom's default format and getting JSON where tag-value was expected, or the reverse.
- Writing the file somewhere other than the requested path;
-otakes the full path.
| Example check | Evidence |
|---|---|
| Right image identified | Package version string from apk matches the one you were looking for |
| SBOM exists in the expected format | Tag-value file contains an SPDXVersion: SPDX-2.3 line; a JSON file parses as JSON |
| SBOM describes that image | Package list contains the same package and version |
Cleanup: kubectl delete namespace prepium-tutorial and delete the generated files. References: kubernetes-sigs/bom README, SPDX overview, SPDX 2.3 package information, apk-tools manual pages. Next, try Dockerfile review or image admission policy.
What this tests
Scan images for vulnerabilities, harden Dockerfiles, generate SBOMs, and enforce image policy. On the CKS exam, Supply Chain Security tasks are graded purely on what you build in the cluster - not multiple choice - so the only way to get faster is to do them on a real cluster against a clock.
Practice it for real
The public description lets you study the task before signing up. Full access includes this live lab; the selected Task of the Week is free with an account. You solve the task in a real terminal, hit validate, and a programmatic checker scores exactly what you got right and wrong (with partial credit). You can open the solution while practising, then retry and use the failed checks to improve your score.