Two alerts a week apart share the CI service account ci-runner — what does that shared name prove?
answer
- Shared by design is not shared by accident
- Selectivity decides a match's weight
- One link is coincidence, two is a lead
- Values get reassigned, rotated, repointed
- Closed is a verdict, not a fact
basics
~20 sOnly that both events authenticated as the same identity. If every pipeline uses that account, the link is nearly worthless. It becomes evidence when a second, more selective entity such as an image digest is shared too.
solid answer
~50 sA shared entity establishes co-occurrence, not causation. `ci-runner` used by forty pipelines links almost anything in the estate to anything else, so on its own it is a filter rather than a lead. What raises it to evidence is selectivity and corroboration: a second, independent entity shared across both events (the same image digest, the same token id, the same source host inside its assignment window), plus rarity — the account performed that particular action twice in ninety days rather than hourly. I also check whether the identifier could have changed meaning between the two dates: addresses get reassigned, tokens get rotated, image tags get repointed, so a name that matches across a week may not be the same thing. If the link survives all that, the older alert — even one closed as a false positive — gets re-opened on the new evidence, because a closure is a verdict on what was visible at the time.
go deeper
Remember the direction of the claim: matching values mean the same string appeared twice, not that the same actor was behind both events.
Be ready to reason about how many things in the estate carry the value, and to name what second observation would make the link stand up.
Demonstrate that you check whether an identifier still meant the same thing a week later, and that you re-open a closed case on evidence rather than instinct.
Own the standard your team applies to linkage: what strength of match justifies re-opening closed work, and how weak links get recorded so they are not quietly promoted to fact.
## Co-occurrence is not linkage The seductive moment in triage is the match: you pivot on a value from today's alert and a record from last week comes back. The instinct is to say the two are connected. What the match actually says is narrower — *these two records contain the same string*. Whether that is a link depends entirely on what the string is. ## Selectivity is the whole question Think of every entity as having a **cardinality** in your estate: how many distinct things carry it, and how often it appears. - A container **image digest** (`sha256:...`) is a content address. Two records carrying the same digest ran byte-identical content. That is highly selective. - A **token id** or session identifier, if tokens are issued per job, ties two actions to one issuance. Selective. - A **service-account name shared by every pipeline** is the opposite. It appears on millions of records by design. Matching on it is like matching on "both people worked in this building". - A **NAT egress address** or a **LOLBin hash** behaves the same way: estate-wide, so it filters but never links. A shared identity used by design is the classic trap on build infrastructure, because the estate genuinely runs everything as one account. Two alerts sharing `ci-runner` is the expected state of the world, not an anomaly. ## Identifiers change meaning over time Even a selective value can betray you across a week-wide gap: - Pod and DHCP **addresses** are reassigned; the same address is a different machine on the two dates. - **Tokens** rotate, so a credential name outlives the credential. - An image **tag** is a mutable pointer — `runner:latest` on Tuesday and on the following Tuesday can be two different artefacts, which is exactly why the digest is the value to keep. - **Hostnames** get recycled in fleets that rebuild. So a pivot across time is really a pivot on *(value, validity window)*. If you cannot establish that the value meant the same thing on both dates, say so explicitly rather than letting the match stand unqualified. ## What turns a weak match into a lead Four things, in rough order of weight: 1. **A second independent entity in common.** Same account *and* same image digest is a different claim from same account alone. Independence matters: two fields that always travel together (a pod name and its namespace) are one observation, not two. 2. **Rarity of the behaviour.** If the account has read that Secret twice in ninety days and both times are your two alerts, the base rate does the work the identifier could not. 3. **Temporal structure.** Not proximity alone, but a plausible sequence: a credential used from a new source, then an artefact appearing, then that artefact pulled elsewhere. 4. **A mechanism.** You can state how the first event would produce the second. Without that, you have a coincidence with good manners. ## The closed alert The most valuable thing a pivot returns is often not telemetry but **your own case history** — an alert another analyst closed a week ago. Two rules apply. First, a closure is a verdict made on what was visible then; new evidence legitimately re-opens it, and refusing to re-open because "that one was triaged" is how two halves of one intrusion stay separate. Second, re-open it on the *evidence*, not by second-guessing the earlier analyst: go back to the original artefacts, check whether the reason given for closing still holds under the new link, and write down what changed. The honest way to record any of this is to keep the claim at the strength you can defend: "the same identity appears on both events; that identity is shared by all pipelines, so the link rests on the shared image digest and the fact that this Secret is read twice a month." A reviewer, a lead, or a future examiner can follow that. "Both alerts involve the same account, therefore they are the same intrusion" cannot survive its first challenge.
- What extra observation would turn that shared account into real evidence?A second independent and selective entity present on both events — most usefully the same container image digest, since a digest is a content address and identical digests mean byte-identical content. Base rates help too: if that account performed this action only on those two occasions in ninety days, rarity carries the link the shared name cannot.
- The older alert was closed as a false positive. Can you re-open it?Yes, and you should. A closure records a verdict on the evidence visible at the time; a new entity link is new evidence. Go back to the original artefacts, test whether the stated closing reason still holds, and record what changed. Treating past closures as immovable is how one intrusion stays filed as two unrelated tickets.
- How do you pivot on a source address that may have been reassigned?Treat the value as a pair: the address plus the window in which the assignment held. Resolve the assignment as it stood at the event's timestamp, not at query time, and confine the search to that window. Hits outside it are a different machine and belong in the notes as excluded, not in the timeline.
A shared service account is the building's master key: finding it at two scenes tells you almost nothing, because everyone carries one. Finding the same rare toolmark at both is the link.
saying these in an interview costs you the question
- Treats any shared identifier as proof of one actor
- Ignores that the account is shared by design
- Pivots across weeks without checking identifier reuse
- Refuses to re-open an alert because it was closed
- Counts two always-paired fields as two corroborations