Lab: remediate and verify one security finding

Start from the inspected baseline

Use your local MicroBank checkout and named images. Keep the cluster local. The known missing backend authorization remains an application security gap even if all scanner findings are resolved. This lab does not expose the service publicly.

1. Inventory and scan

Record source commit, Dockerfile, resolved image ID, runtime identity, and scanner version. Run the image, manifest, and SBOM commands from the preceding bites. Save their outputs privately in evidence/security/. A scan that failed to download its database is not a clean scan.

Pick one actionable finding from the actual output. If no suitable dependency finding appears, inspect the Accounts image's runtime user and use non-root execution as the controlled hardening change. Base the exercise on a finding you can actually inspect and verify.

2. Make the smallest change

For a dependency finding, update the affected package to a compatible fixed version where one exists, rebuild, run tests, and rescan. For the runtime-user exercise, inspect required files and write paths before adding a dedicated non-root user to the Dockerfile. Set the corresponding Pod security context from the hardening bite. Do not apply Accounts' UID blindly to PostgreSQL.

Tag the rebuilt image with the new source revision, load it into microbank-advanced, and update the desired manifest. If Argo CD currently owns the workload, commit the change and reconcile through that Application. Otherwise apply the reviewed local manifest. Keep one owner at a time.

3. Verify both restriction and behavior

After rollout, inspect the running container user and whether a Kubernetes API token is mounted. Verify the intended denied operation—for example, writing a protected system path as the non-root process—without modifying host files. Then run a fresh local transaction and verify it through Ledger.

An application can start yet fail when it needs a temporary directory or writes a cache. Exercise the real workflow instead of accepting Pod readiness as the only test. If a dependency upgrade breaks the app, restore the known-good declaration and document the compatibility work required.

4. Review the supply-chain boundary

Generate an SBOM for the new artifact and compare it with the previous one. Record signature/provenance verification as “not implemented” unless you actually configured a trusted identity and verified the intended registry digest. Later Platform engineering can enforce this evidence at admission using an explicit policy.

Checkpoint

Keep a table with finding, impact assessment, change, new image identity, scanner result, denied-operation result, transaction result, and remaining risk. Explain what the control does and what it cannot prove. Scanner output, a securityContext, and a working transaction flow provide different, complementary evidence.

Review a change from both directions

For a non-root change, the positive assertion is that the real transaction still completes. The negative assertion is that an operation outside the process's intended permissions is denied. Neither replaces the other: a locked-down process that cannot serve users is broken, while a working transaction does not establish least privilege.

Save the updated desired manifest, not just the scanner report. The later canary recovery snapshot must include this image and its security settings so a rollback exercise does not undo your work. Keep unresolved backend authorization visible as a separate application task.

Sources

Trivy configuration scanning↗, Kubernetes security context↗, RBAC practices↗, and SLSA↗.