Chapter 6 — Cloud and container security: operational workflow
Lesson map
Lesson 06 published. Map, example, EX026.
flowchart TD
N0["Learning outcomes"]
N1["6.1 The findings"]
N2["Lab — vulnerability triage"]
N3["6.2 Reading the result"]
N4["6.3 Workflow"]
N5["6.4 Repetition"]
N6["6.5 Exceptions"]
N7["Why exposure matters"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX026"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["6.1 The findings"]
N2["Lab — vulnerability triage"]
N3["6.2 Reading the result"]
N4["6.3 Workflow"]
N5["6.4 Repetition"]
N6["6.5 Exceptions"]
N7["Why exposure matters"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX026"]
[Learning outcomes]
|
v
[6.1 The findings]
|
v
[Lab — vulnerability triage]
|
v
[6.2 Reading the result]
|
v
[6.3 Workflow]
|
v
[6.4 Repetition]
|
v
[6.5 Exceptions]
|
v
[Why exposure matters]
|
v
[Worked example] --> [Exercise EX026]
Learning outcomes
You will (1) prioritise image vulnerabilities; (2) build a repeatable workflow; (3) integrate it with change management.
6.1 The findings
The scanner reports six synthetic findings across three images. Hannah orders them with the method from chapter 4. The findings come from the weekly scan of permits-web, permits-worker and reporting images, exported with the date and scanner version. Hannah does not tier them by severity alone. For each finding she adds the likelihood score and whether the workload faces the internet, then applies the agreed method. The method and the inputs are recorded together, so the digital team can check her ordering and apply the same method to future scans without her.
Lab — vulnerability triage
"""Order synthetic image findings by exposure, EPSS-style likelihood and severity (stdlib only)."""
findings = [("permits-web", "CVE-A", 9.8, 0.62, True), ("permits-web", "CVE-B", 5.3, 0.01, True),
("permits-worker", "CVE-C", 9.1, 0.03, False), ("reporting", "CVE-D", 7.5, 0.40, False),
("permits-web", "CVE-E", 7.2, 0.002, True), ("reporting", "CVE-F", 4.0, 0.001, False)]
def tier(f):
_, _, sev, p, internet = f
if internet and (p >= 0.1 or sev >= 9): return 1
if p >= 0.1 or sev >= 9: return 2
return 3
for f in sorted(findings, key=lambda f: (tier(f), -f[3], -f[2])):
print(f"tier {tier(f)} {f[0]:15} {f[1]} severity {f[2]:4} likelihood {f[3]:.3f} {'internet' if f[4] else 'internal'}")
Run with python3 lab_triage.py. Verified output:
tier 1 permits-web CVE-A severity 9.8 likelihood 0.620 internet
tier 2 reporting CVE-D severity 7.5 likelihood 0.400 internal
tier 2 permits-worker CVE-C severity 9.1 likelihood 0.030 internal
tier 3 permits-web CVE-B severity 5.3 likelihood 0.010 internet
tier 3 permits-web CVE-E severity 7.2 likelihood 0.002 internet
tier 3 reporting CVE-F severity 4.0 likelihood 0.001 internal
6.2 Reading the result
Tier 1: CVE-A in permits-web, severity 9.8, likelihood 0.62, internet-facing. Tier 2: CVE-D in reporting (7.5, 0.40) and CVE-C in permits-worker (9.1 but likelihood 0.03), both internal. Tier 3: three low-likelihood findings. The internet-facing finding with high likelihood comes first, even though CVE-C has a higher severity score. CVE-C is tier 2 because exploitation is unlikely and the worker is internal, but it is still fixed within a month, not ignored. The tier 3 findings wait for the next routine rebuild. Hannah records the inputs for each finding, so the order can be explained to the digital team, as it was when they asked about CVE-C.
6.3 Workflow
Tier 1 is fixed within a week, tier 2 within a month, tier 3 in the next routine rebuild. Each fix is a rebuild from an updated base image through the pipeline, then deployment through the change process. Fixing by rebuilding rather than patching running containers keeps images consistent and means the fix is part of the code that builds them. The change process gives Dev and the digital team a chance to review each deployment. Hannah tracks each finding from scan to deployment, so audit can see that tier deadlines were met. A new scan after deployment confirms the finding has gone. Each finding enters the work queue with tier, deadline, owner and a link to the scan record. Tiers are reviewed monthly.
6.4 Repetition
The scanner runs weekly; new findings are tiered automatically and appear in the team's queue. Weekly scans catch new vulnerabilities in images already running, not only in new builds. Automatic tiering means each finding arrives in the digital team's queue with its tier and deadline, so nobody has to sort results by hand. This answers one of the process causes Hannah later identifies: scan results had gone to an inbox nobody watched. The digital team reviews the queue in its weekly planning meeting. Images are rebuilt monthly even without findings, so base updates arrive routinely and urgent rebuilds are rarer and less risky.
6.5 Exceptions
If a fix is impossible in time, an exception records the reason and compensating controls. An exception is not a way to ignore a finding. It names the finding, why it cannot be fixed by the deadline, the controls that reduce risk meanwhile, the owner and the new date. Dev approves each exception. The reporting rebuild became the first exception, because an old library did not work with the new base image. Audit receives exceptions with the closed findings, so it can see what remains open and why. Each exception is reviewed when its date arrives, as the reporting rebuild was after the library update two weeks later.
Why exposure matters
An internet-facing service can be reached by anyone, so a likely-exploited flaw there is urgent. The same flaw in an internal job is reachable only by those already inside the network. Exposure does not make internal findings unimportant, but it orders them sensibly when time is limited.
Hannah documents the tier rule so that developers can predict deadlines themselves.
Worked example
Permits-web is rebuilt within three days. The digital team asks why CVE-C, with severity 9.1, is only tier 2. Hannah explains that it is internal and its likelihood is low, so it waits behind the internet-facing finding, but still within a month.
Synthetic case. Synthetic findings; CVE labels are placeholders.
Errors and limits
Likelihood scores change; re-check before deferring.
Exercises
- EX026 — Tier 1. Which finding was tier 1 and why? Rubric: 3 = CVE-A; internet, high severity and likelihood; 2 = partial; 1 = vague; 0 = none.
- EX027 — Severity 9.1. Why was CVE-C not tier 1? Rubric: 3 = internal, low likelihood; 2 = partial; 1 = vague; 0 = none.
- EX028 — Deadlines. State the tier deadlines. Rubric: 3 = week, month, next routine rebuild; 2 = two; 1 = one; 0 = none.
- EX029 — Fix route. How is each fix made? Rubric: 3 = rebuild from updated base via pipeline, change process; 2 = partial; 1 = vague; 0 = none.
- EX030 — Re-checking. Why re-check before deferring? Rubric: 3 = likelihood scores change; 2 = partial; 1 = vague; 0 = none.
Synthesis
Tier by exposure and likelihood, then fix through normal change.
Continue studying — chapter 06 of 12
← Chapter 05 (draft) · Course chapter index · Chapter 07 (draft) →