Chapter 22 — Application and software supply chain security: automation
Lesson map
Lesson 22 published. Map, example, EX064.
flowchart TD
N0["Learning outcomes"]
N1["22.1 What to automate"]
N2["22.2 Routing"]
N3["22.3 Safe automation"]
N4["22.4 Reviewing automation"]
N5["22.5 Watching the watcher"]
N6["22.6 Effort saved"]
N7["Starting small"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX064"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["22.1 What to automate"]
N2["22.2 Routing"]
N3["22.3 Safe automation"]
N4["22.4 Reviewing automation"]
N5["22.5 Watching the watcher"]
N6["22.6 Effort saved"]
N7["Starting small"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX064"]
[Learning outcomes]
|
v
[22.1 What to automate]
|
v
[22.2 Routing]
|
v
[22.3 Safe automation]
|
v
[22.4 Reviewing automation]
|
v
[22.5 Watching the watcher]
|
v
[22.6 Effort saved]
|
v
[Starting small]
|
v
[Worked example] --> [Exercise EX064]
Learning outcomes
You will (1) automate inventory, audit and drift checks; (2) schedule them; (3) route results to owners; (4) keep automation reviewed and safe.
22.1 What to automate
The nightly job builds the inventory from lock files, runs the audit against the advisory list, checks drift and writes one report. These are the same steps Diego earlier ran by hand each week: build the inventory, compare it with advisories and compare running versions with approved ones. Combining them in one nightly job means the morning report reflects the state of every client as of last night, and a new advisory is matched across all 23 projects without anyone starting a search.
22.2 Routing
Each finding goes to the project owner in the team chat with a link to the task; highs also go to Aiko. Routing to the owner named in the inventory means nobody has to read the whole report to find their own work. The task link gives the advisory, the affected project, the fixed version and the due date. Highs going to Aiko as well means the 7-day target is watched by someone beyond the person doing the fix. The chat message is short; the task holds the details.
22.3 Safe automation
The job has read-only access to repositories and hosting status. It opens tasks and update pull requests but cannot merge or deploy. Read-only access means a bug in the job, or a misuse of its credentials, cannot change a client site or a repository. A human still reviews and merges every update pull request, and deployment still goes through the pipeline and the approved-image rule. The job's narrow rights were checked in the access review like any other identity. Its credential is scoped to these actions and nothing else.
22.4 Reviewing automation
The job's code is reviewed like any project, pinned and tested with synthetic data. The job is held to the same rules it enforces: its actions are pinned, its dependencies have a lockfile and its token is read-only. Its tests use synthetic manifests and advisories, including cases near version-range boundaries, so a change to the matching logic is checked before it runs against real projects. Changes to the job go through pull request review like any client project. Any change also reruns the synthetic tests in the pipeline before it can merge.
22.5 Watching the watcher
If the nightly report does not arrive, an alert fires, because silent failure would look like "no problems". An empty report and a missing report look the same to a busy reader, yet they mean very different things. The alert fires if no report arrives by the expected time each morning. The report also includes the number of projects checked, which is how the three skipped projects were noticed. Together these turn a silent failure into a visible one. The missing-report alert goes to Aiko and to the job's named owner.
22.6 Effort saved
The manual weekly checks that took Diego half a day now take ten minutes of reading. The saved time goes into fixing findings rather than finding them. Reading takes ten minutes because the report starts with counts by severity and lists only new findings with their owners. Diego still compares one day's report with a manual check now and then, using the same trust-by-comparison idea that guided the automation's first weeks. The ten minutes include confirming any new match against its advisory text.
Starting small
The automation started as Diego's manual checklist turned into a script one step at a time: first the inventory, then the audit, then drift. Each step ran beside the manual process for two weeks, and results were compared before the manual step was dropped. This caught two differences, both bugs in the script, before anyone relied on it. Aiko calls this approach 'trust by comparison', and the team uses it for later automation as well.
Report format
The nightly report starts with counts by severity, then lists each new finding with its owner.
Worked example
Two months in, the nightly job silently skips three projects whose lock files moved during a restructure. The missing-project count added to the report reveals it the next day, and the job is fixed to fail loudly when an expected project has no lock file.
Synthetic case. Automation and events are synthetic.
Errors and limits
Automation repeats mistakes quickly; test it and watch its output.
Exercises
- EX064 — Job permissions. What can the nightly job do? Rubric: 3 = read; open tasks and PRs; not merge or deploy; 2 = partial; 1 = vague; 0 = none.
- EX065 — Silent failure. Why alert when the report is missing? Rubric: 3 = absence looks like no problems; 2 = partial; 1 = vague; 0 = none.
- EX066 — Skipped projects. How were skipped projects found? Rubric: 3 = missing-project count; 2 = partial; 1 = vague; 0 = none.
Synthesis
Automate checks with least privilege and watch for silent failures.
Continue studying — chapter 22 of 30
← Chapter 21 (draft) · Course chapter index · Chapter 23 (draft) →