Chapter 17 — Cloud and container security: tooling
Lesson map
Lesson 17 published. Map, example, EX049.
flowchart TD
N0["Learning outcomes"]
N1["17.1 Needs first"]
N2["17.2 Options"]
N3["17.3 Criteria"]
N4["17.5 Prioritising findings"]
N5["17.6 Sprawl"]
N6["Testing a tool"]
N7["Output handling"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX049"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["17.1 Needs first"]
N2["17.2 Options"]
N3["17.3 Criteria"]
N4["17.5 Prioritising findings"]
N5["17.6 Sprawl"]
N6["Testing a tool"]
N7["Output handling"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX049"]
[Learning outcomes]
|
v
[17.1 Needs first]
|
v
[17.2 Options]
|
v
[17.3 Criteria]
|
v
[17.5 Prioritising findings]
|
v
[17.6 Sprawl]
|
v
[Testing a tool]
|
v
[Output handling]
|
v
[Worked example] --> [Exercise EX049]
Learning outcomes
You will (1) choose tools for inventory, scanning and checks; (2) prefer simple and reviewable tools; (3) avoid tool sprawl.
17.1 Needs first
Priya lists needs: export workloads, scan images for known vulnerabilities, check baselines, check code before merge. Each need on Priya's list comes from an earlier finding. The advisory search needs a workload export, the outdated images need scanning, the client-b settings need a baseline check, and the pipeline needs checks before merge so that public buckets or root containers never reach production. Writing needs before looking at products stops a feature list from deciding what Cobalt should care about. Each need is written as a question the tool must answer.
17.2 Options
Scanners and checkers exist from providers, open-source projects and vendors. The course labs show the logic with stdlib Python so it is understood before a tool is chosen. Providers offer built-in configuration checks for their own platforms, open-source projects offer scanners and policy checkers, and vendors sell combined dashboards. Each option differs in cost, permissions needed and how much Cobalt can see of its logic. Priya's stdlib labs serve as a reference: if a tool's output cannot be explained in the same plain terms, the team may not be able to trust or act on it.
17.3 Criteria
Cobalt chooses tools that are maintained, produce readable output, run in the pipeline and do not need wide permissions. Maintained means the tool's vulnerability data and code are still updated, so it recognises recent advisories. Readable output means a finding can be acted on without a specialist. Running in the pipeline lets checks happen before merge, and low permissions matter because a scanner with cluster-admin rights becomes a target itself. Priya scores each option against these four criteria in a small table.
17.4 Scanner limits
Image scanners match packages against vulnerability databases; they miss custom code flaws and can report vulnerabilities that are not reachable. A scanner looks up the packages it finds in an image and reports those with known advisories. It cannot judge whether a vulnerable function is ever called, whether the workload is reachable from the internet, or whether Cobalt's own application code is flawed. Its output is therefore a starting list, which Priya combines with the exposure notes from the inventory before deciding what to fix first.
17.5 Prioritising findings
Jacobs et al. (2021) describe EPSS, which estimates the likelihood a vulnerability will be exploited. Cobalt uses it alongside severity to order fixes. Severity describes how bad exploitation would be; EPSS estimates how likely exploitation is in the near future. Using both helps a small team avoid two mistakes: rushing to fix every high-severity finding regardless of its exploitation likelihood, and ignoring a moderate one that is being widely exploited. Cobalt adds exposure as a third factor, so internet-facing workloads such as booking are fixed sooner.
17.6 Sprawl
Each tool adds maintenance. Priya recommends two tools rather than five. Every additional tool needs updates, permissions, someone who understands its output and a place in the runbooks. Five overlapping tools would also produce overlapping findings, which the team would have to reconcile by hand. Priya's recommendation, one image scanner plus the team's own small checks, covers the four needs she listed and keeps the maintenance load within what the platform team can sustain after she leaves. Fewer tools also means fewer accounts holding cluster read access.
Testing a tool
Before adopting the scanner, Priya runs it on three known images: one current, one old and one custom. She checks whether its findings match published advisories and notes false alarms. The test takes an afternoon and gives the team confidence in what the tool reports and where it falls short.
Output handling
Scanner reports can include internal image names and versions. They are stored in the repository, not shared publicly.
Writing the decision
The tool decision is written up with needs, options, test results and reasons, so it can be revisited.
Licences
Priya checks each tool's licence allows commercial use at Cobalt before adoption, with Kwame's help.
Worked example
A vendor offers a dashboard with hundreds of checks. Priya compares it to needs and finds most checks irrelevant to Cobalt's services; the team stays with a smaller open-source scanner plus their own checks.
Synthetic case. Tool choices are synthetic.
Errors and limits
A tool's output needs a person who understands it.
Exercises
- EX049 — Tool criteria. What criteria did Cobalt use for tools? Rubric: 3 = maintained, readable, pipeline, low permissions; 2 = three; 1 = two; 0 = none.
- EX050 — Scanner limits. What do image scanners miss? Rubric: 3 = custom code flaws, reachability; 2 = partial; 1 = vague; 0 = none.
- EX051 — EPSS use. How does EPSS help? Rubric: 3 = exploit likelihood to order fixes; 2 = partial; 1 = vague; 0 = none.
Synthesis
Pick few, understood tools that fit real needs.
Continue studying — chapter 17 of 30
← Chapter 16 (draft) · Course chapter index · Chapter 18 (draft) →