Challenge: investigate a suspicious release

The previous four lessons covered measuring risk, pinning versions, generating SBOMs and hardening CI. This one tests using all four under time pressure with incomplete information — that is, in the conditions they are actually used.

The situation — 09:15. A message in the team channel:

"Dependabot just opened a PR bumping Corp.Telemetry from 4.2.1 to 4.2.2. 4.2.2 was published at 02:40 this morning, and the changelog says only fix: minor issues. Four months ago 4.2.1 shipped with a three-paragraph changelog. Feels off to me."

Corp.Telemetry is an internal package maintained by another team in the company, used in 12 services, and it ships metrics so it has outbound network access.

What to produce.

1. Decide in the first 10 minutes: is this an incident or an ordinary patch? On what evidence?
2. If undecided, what do you do to stop it spreading while investigating?
3. If it is an incident: establish the blast radius. Which services, which secrets?
4. Afterwards: what change prevents a recurrence?

Question 2 is the most important and the one people skip, because the instinct is to reach a conclusion before acting. In a supply-chain incident that order is backwards.