You can hang a detection on a coverage dashboard, watch the tile go green, and still miss the attack it was supposed to catch. That is the punchline in new research on threat detection, and it lands in a week when compromised GitHub Actions quietly came back online and started running malware again. If you run a cybersecurity program that reports coverage percentages to leadership, sit down. The number on the slide is doing a job the rule in production is not.

Your cybersecurity coverage number is a costume

Conifers assessed 14,652 detections across its customer base, including rules written by customers and detections managed by vendors in SIEM, endpoint, cloud, identity, email, and network tools. Forty-seven percent of detections in the average organization need attention. If those detections are how you prove threat-protection to a board, you just learned that nearly half of the proof is decorative.

A detection rule can show up as deployed on a coverage dashboard and still never fire when an attacker uses the technique it was built to catch. That sentence should follow you into the next architecture review. Deployed is a packaging state. Firing is an operations state. You need the second, and most coverage exports only sell you the first.

Logic bugs sit in the failure pile, and they have company. Rules disabled after a noisy weekend and never restored. Thresholds sanded down until a real brute-force looks like weather. Log sources that moved when you changed IdP or firewall vendors and left the old parser pointed at a dead index. Technique mappings completed because someone had a spreadsheet to finish before the quarterly review.

You know the meeting. Leadership asks about coverage. Someone exports the dashboard. The tiles are green. The meeting ends. Nobody asks when the rule last matched a live event. Nobody asks who owns the false-positive budget that quietly strangled it.

The awkward part is how useful the lie is. A coverage percentage is easy to trend. Last-fired timestamps are messy. Control tests make content owners defensive. So the organization keeps the metric that photographs well. Attackers do not care about your photograph.

Coverage mapping is a filing system. Filing systems do not page anyone at 2 a.m. If your defense in depth story depends on that map, you are stacking slides, not controls. Vendor-managed content in your tenant is still your content. The vendor does not sit your on-call rotation, and the dashboard vendor does not care that your cyber security program just briefed a fiction.

The GitHub Actions came back. Did your rule?

Two GitHub Actions under the actions-cool organization, issues-helper and maintain-one-comment, were compromised during the May 2026 Mini Shai-Hulud campaign. They got pulled. Last week the repositories became accessible again, and the same malware path resumed executing. Maintainers had to disable them a second time. Visit either repo now and you get an access wall. Status flipped twice. Workflows that still called those actions did not get a courtesy call.

A disabled listing is not a kill.

Plenty of shops will tell you they have CI and supply-chain detections. Ask a sharper question. Would those detections have fired on a previously banned Action that walked back into pipelines because a repo flipped from unavailable to public? If the honest answer is that your coverage tile for malicious GitHub Actions is green, you are describing a catalog entry. You are describing a costume.

Incident response runbooks that say the EDR would have caught this are doing the same cosplay. If you have never forced the detection to alert in your environment, you do not have it. You have a story about it.

Bruce Schneier’s notes on Anthropic’s AI misuse report make the timing worse. Attackers are handing reconnaissance, exploitation, data theft, propaganda production, surveillance workflows, and research to agents, while humans pick targets, set goals, and review the important outputs. Credential theft, cloud compromise, phishing, and vulnerability research are being industrialized. Dead detections do not get a grace period because your content pack was expensive.

Same week, a Docker botnet hunting AI keys showed up in the roundup pile, next to industrial telemetry exposure and a TDengine flaw that can knock the feed over. Keys and uptime are the assets. A green identity tile beside a silent cloud detection does not protect either one. If your firewall still logs the obvious scans and your SIEM still counts those logs as network coverage, you have telemetry. Telemetry without a working rule is a hobby.

Prove the fire, then keep the slide

Prove firing, not presence. Do it this week, then put the proof on a calendar so it does not become another quarterly costume change.

Start with the ugly sample.

• Pick ten techniques your dashboard calls covered. For each one, name the exact rule, the log source, the last fire time, and a control test that should produce an alert. If you cannot name the test, the tile is fiction.
• Diff deployed against enabled, has data, and has fired in 90 days. Treat never-fired mapped rules as untested code sitting in production.
• Inventory reusable GitHub Actions and workflow pins. Hunt for yanked-then-restored publishers, floating tags, and orgs that already appeared in Mini Shai-Hulud reporting. Pin by commit SHA and fail the build on unpinned marketplace actions.
• Pull identity detections for password spray and brute-force and confirm they still parse current IdP logs after the last schema change.
• Put a human on the cloud and CI secret-revoke path and time it. Call that incident response, and retire the dashboard row as your proof.
• Walk one restored-or-replaced control through security hardening review the same way you walk a patch: evidence, owner, expiry date.

Then change the metric you report. Coverage becomes techniques with a passing control test in the last quarter, not techniques with a mapped rule. Bake that proving step into security hardening reviews the way you bake patch evidence into change control. When incident response finds a silent mapped detection, fix the rule inside the incident, not as a ticket you will love later.

You do not need a new platform to start. You need an owner for each mapped technique, a test event, and a date when the test expires. That is cheaper than another threat-protection suite and ruder to ignore.

Defense in depth only counts if the layers can fail independently. A SIEM rule and an EDR rule that share the same broken logic are one control wearing two licenses. Revisit vendor content after every major platform change. Vendor-managed still needs tenant verification against your parsers and your current identity paths. Green is a color. Firing is a fact.

Sources

• Threat detection dashboards are masking security coverage gaps
• Compromised GitHub Actions Came Back Online and Resumed Executing Mini Shai-Hulud Malware
• On Anthropic’s AI Misuse Report
• In Other News: Clop Leak Site Takeover, Docker Botnet Hunts AI Keys, Water Utility Exposure