Your hunt finds suspicious activity that no detection rule ever alerted on. Does that make it less likely to be malicious?
answer
- silence measures your sensors
- four links must all hold
- no rule reads build-job logs
- coverage gap, not exculpation
- a match is behaviour, not intent
basics
~10 sNo. A rule set only covers behaviour someone wrote a rule for, over sources someone connected. Silence measures your detection coverage, not the activity's intent. Judge the behaviour on its own evidence.
solid answer
~50 sNo, and treating it as reassurance is the classic mistake. A detection estate covers the behaviours somebody thought to write rules for, over the log sources somebody wired up; hunting exists precisely to look where rules do not. On a self-hosted build runner the point is sharper still, because in most estates no rule reads pipeline step output or runner shell history at all, so silence there was guaranteed before the intruder arrived. The absence of a detection's output is indistinguishable from a quiet estate, which is why a rule's false-negative rate is not computable from production. So I split it into two artefacts: the finding, argued from the records themselves, and a separate coverage gap naming the source and technique nothing watches. The hit is not a verdict either — a query match says the behaviour occurred, not that it was malicious.
go deeper
Be ready to say plainly that the absence of an alert is evidence about the sensors, not about the adversary, and to list why no alert might exist: no record, no ingestion, no rule, or the output was suppressed.
Explain why a detection's misses are unobservable, so precision is measurable over the alerts it produced while its false-negative rate is not, and why exercising the behaviour is the only way to prove a detection still works.
Show how you keep the finding and the coverage gap as separate artefacts, so the escalation argues from records rather than from the SIEM's silence, and so the gap reaches whoever owns detection content.
Own the framing that a quiet quarter on an unmonitored source is a coverage statement, not a risk statement, and be able to defend that distinction to an executive who reads low alert volume as good news.
## The question behind the question When a hunter escalates something the SIEM never alerted on, the first push-back is almost always "if it were really bad, wouldn't something have fired?" The answer is no, and understanding why is the entry ticket to hunting work. ## What an alert actually is An alert is one firing of a **detection** — a rule evaluated over records that have been collected, parsed and stored. For an alert to exist, four things must all have happened: 1. the source emitted a record of the behaviour at all; 2. that source was **ingested** into the platform the rule runs on; 3. somebody **wrote a rule** whose logic matches this behaviour, and it was enabled; 4. the rule's output survived — it was not deduplicated away, suppressed by a maintenance window, or auto-closed. Break any one link and there is no alert, whatever the intruder did. "No alert fired" is a statement about that chain, not about the adversary. ## Why silence is uninformative, formally A detection produces output when it matches. It produces nothing when it does not match **and** nothing when it is broken, disabled, starved of data, or aimed at a source that was never connected. Those cases are indistinguishable from the outside: absence of output looks the same as an absence of activity. That is why you can measure a rule's precision over the alerts it *did* produce, but you cannot compute its false-negative rate over live traffic — the intrusions it missed leave no record that they were missed. The only way to establish that a detection still catches a behaviour is to **execute that behaviour** and see whether it fires. ## The build-system case Self-hosted build infrastructure is the sharpest example. Job logs, pipeline step output and a runner's shell history are rich, high-fidelity records of exactly what ran — and in a great many estates they are not shipped to the SIEM, no detection content exists for them, and the security team has read access to the platform but no operational authority over it. An intruder using a build agent interactively to archive source trees and read injected secrets is doing something loud and obvious, on a stage where nobody has pointed a camera. The silence was structural. It predates the intrusion. ## What the hit is, and is not Be just as careful in the other direction. A hunt hit is a **hypothesis match**: you predicted that a behaviour, if present, would look like *this* in *these* records, and records came back. That establishes the behaviour occurred as recorded. It does not establish intent, authorisation, or impact. The activity may turn out to be a genuine intrusion, or a **benign true positive** — the behaviour really happened and was legitimate work. Distinguishing those is the next job, not something the query result settles. ## What a hunt hit lacks that an alert carries When you escalate, you are handing over something thinner than a normal case, and you should say so explicitly rather than hope nobody notices. An alert arrives with a rule name that states an intent, a severity somebody calibrated, a triage note, a history of prior dispositions, and often a vendor verdict or intel match. A hunt hit arrives with none of that. What it carries instead — and what you must make explicit — is the **hypothesis**, the reason this behaviour is abnormal *for this host and this identity in this estate*, the baseline you compared against, and the scope you actually searched. ## What to do with the silence Record it, separately from the finding, so it does not contaminate the argument. Two artefacts: - **The case**: the records, the timeline, why the behaviour is not explained by normal operation, and what you are asking someone to decide. - **The coverage gap**: the source that nothing reads, the behaviour nobody has content for, and the fact that this gap was not discovered by a rule failing but by a human going to look. The second one is often the more valuable output of the hunt in the long run, and it is a genuinely different conversation from the incident. ## The trap in one line "Nothing alerted" is evidence about your sensors. "Nothing happened" is a claim about the world. They are not the same sentence, and a candidate who treats them as interchangeable is telling the interviewer they have never looked at an unmonitored log source.
- The build system's job logs are ingested into the SIEM. Does that change your answer?Only slightly. Ingestion is one of four links; content still has to exist for that source, be enabled, and match the behaviour. Ingested-but-uncovered is extremely common, because teams connect a source for search and hunting long before anyone writes detections over it. I would check whether any enabled rule actually queries those fields before treating the silence as meaningful.
- How do you record the coverage gap without weakening the finding itself?Two separate artefacts. The case file argues the behaviour from its own records and never leans on "the SIEM missed it" as proof of anything. A separate coverage entry names the source, the technique, and the fact that nothing reads it, and goes to whoever owns detection content. Mixing them invites the reviewer to argue about the sensor instead of the evidence.
- Someone says the rule set has fired nothing on build infrastructure in a year, so the risk is low. Your response?That statistic is compatible with a clean estate and with total blindness, and nothing in the number separates them. I would ask which rules read that source, when their logic was last exercised against the behaviour they claim to catch, and whether anyone has run that behaviour deliberately to see it fire. Until then the figure measures content, not risk.
A smoke detector that was never installed in the garage tells you nothing about whether the garage is on fire. Its silence is a fact about the wiring.
saying these in an interview costs you the question
- Says no alert fired, so the activity is probably benign
- Treats the hunt query match itself as a confirmed verdict
- Assumes every collected log source has detection content over it
- Claims a quiet SIEM proves a clean estate
- Quotes a rule's false-negative rate as if it were measurable in production