When news breaks, name one owner, split the checks into separate claims, and keep one shared list of results. Without that, five people duplicate the lockfile search while nobody checks CI or laptops, and the team ends up with five slightly different answers.
What goes wrong without coordination
A headline lands in a chat channel. Within minutes, five engineers are checking. Three search the main repository. One reads the primary source. One starts drafting a message to customers. Nobody looks at CI, images or laptops. Two people find conflicting results because they searched different branches. A manager asks "are we affected" and gets three different replies.
Nothing here is about skill. It is about structure. Enthusiasm without a plan produces overlap and gaps at the same time.
The routine
The routine has five parts and takes about five minutes to set up.
- Name an owner. One person holds the ticket and the status note. They do not do all the work. They make sure all the work is claimed.
- Split into claims. Write each check as a separate line with a clear scope.
- Claim a line. Each person puts their name on one line before starting. First come, first served.
- Post results in one place. Each result goes into the claim line in the ticket, with evidence, not into five side threads.
- Merge. The owner reads the lines, writes the overall verdict and updates the status note.
A claims table
| Claim | Scope | Owner | Status | Evidence |
|---|---|---|---|---|
| Confirm the facts | Primary source, ecosystem, versions, window | Dana | Done | Archived page, registry times |
| Source search | Every repository, including archived | Lee | In progress | |
| CI check | Jobs inside the window | Priya | Claimed | |
| Image check | Image inventory against bad versions | Sam | Open | |
| Laptop check | Message to developers, collect replies | Jordan | Claimed | |
| Production check | Deployed versions per service | Open | Open | |
| Communications | Internal note only, no public statement | Owner | Ongoing | Status note |
The table is a living document. Keep it at the top of the ticket. See the post on a scoping grid for how to choose the environments.
Rules that make it work
Claim before you start. If someone has claimed a line, find another one. If all lines are claimed, offer to help the person with the slowest line.
Write evidence, not conclusions. "No results for the package name in 41 repositories, searched at 10:05 UTC" is better than "looks fine".
One thread. Side conversations are fine for brainstorming, but results belong in the ticket. Anything that affects the verdict must be written there.
Do not announce externally. One person approves any message that leaves the company. The post on who approves public incident communications covers that.
Say when you are stuck. A stuck line is a signal for the owner, not a failure.
A worked example
At 09:00 UTC a headline names a build tool as compromised. Eight engineers see it in chat.
Dana, who saw it first, says "I will own this, ticket here". She posts the claims table within four minutes, with lines as above. People claim lines. Lee takes the source search and reports 41 repositories searched, two hits. Priya checks CI and finds one of the two hits ran a fresh install inside the window. Sam checks images and finds the image built by that run. Jordan posts a message to developers asking for a version check by noon. Dana reads the primary source and writes the status note with known, unknown and next check.
By 10:30 the ticket shows: one exposed service, its pipeline and image, and four developer replies outstanding. The manager reads the status note and does not need to ask anyone. No one searched the same thing twice.
When people want to help but have no line
Not everyone has a task, and that is fine. Give spare people one of these: review the evidence on a finished line, draft the closing note, set up the recheck, or prepare the rotation steps in case they are needed. Avoid inventing busywork.
After the incident
Review how the routine went. Were all lines claimed quickly? Did any overlap? Was anything missed? Adjust the claims table template and save it. The next time, you will start with a better table.
Common failure modes
| Failure | Sign | Fix |
|---|---|---|
| No owner | Everyone assumes someone else has it | Say "I own this" out loud, in the channel |
| Owner does everything | The owner is the bottleneck | Delegate lines, keep the status note |
| Results in side threads | The ticket stays empty | Move the result into the ticket before replying |
| Unclear scope on a line | Two people disagree on what "done" means | Rewrite the line with a concrete scope |
| Public messaging by volunteers | Contradictory statements | One approver for anything external |
Spotting these early keeps the routine healthy. A two minute check at the one hour mark, asking "are all lines claimed and is anything stuck", catches most of them.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how findings are grouped by package and version, and imagine which lines of your claims table each group would feed.
Safeguard's SBOM and dependency scanning gives the team one inventory that many people can read from, so the source and image lines start from the same list.
Quick check
Who should be the owner?
Someone who can hold the status note and chase the lines, often the first responder or an on-call lead. The owner coordinates and does not have to do every check.
What if two people already did the same check?
Compare results. If they match, note both as corroboration. If they differ, find out why, such as different branches or search terms, before merging.
How many claims are too many?
If the table grows beyond about ten lines, group them by environment. More lines than people usually means some can wait.
Last reviewed: 19 October 2026.
