An Onspring CISO went on the record this month with what most of us already suspected: the color-coded GRC dashboards we present to boards don’t measure the things that hurt us. Insider behavior, vendor concentration, and a hundred other risks that resist a tidy red-yellow-green pill get flattened into reassuring squares. Meanwhile, in the same news cycle, researchers showed how a backdoor hides inside neural network silicon, and a new open-source tool reached for a language model to catch CI/CD pipeline tampering that signature scanners miss. None of these stories share a CVE. They share a deeper cybersecurity problem: the worst risks are the ones your tooling can’t render.

Your Cybersecurity Dashboard Lies In Three Colors

Nichole Windholz, the CISO at Onspring, said it plainly this week: continuous control monitoring tools produce a green-yellow-red mosaic that flattens nuance. The board sees a dashboard of squares. The CISO knows half those squares are an aggregation of fifteen sub-controls, two of which are doing all the work and one of which has been broken for six weeks. Color hides that. Color is what executives ask for, which is the whole problem.

This isn’t a complaint about tooling vendors. It’s a complaint about how cyber security risk gets communicated up the chain. The risks that resist measurement are the ones that drive real losses: insider behavior, vendor concentration, the soft trust we extend to third-party silicon, the soft trust we extend to a CI runner. None of them have a red light. They have stories, which boards don’t like reading.

If the only thing your GRC tool can show is the stuff that’s instrumentable, you have a coverage problem. Worse, you have a confidence problem, because eventually you’ll start believing the colors.

Your Threat Model Doesn’t Include The Foundry

Researchers at the University of Tennessee and the University of Florida published an attack this week showing how a hardware backdoor can be planted directly into custom neural network silicon, the FPGAs and ASICs that increasingly run inference on phones, cars, and edge devices. The supply chain has more hands on it than a hot pizza. Design house, fab, packaging, integration. Any one of them can quietly alter a device, and the result hides in plain sight inside the model’s behavior.

Now ask yourself which row of your risk register that goes in. There isn’t one. Most asset inventories stop at the device level. Some go to firmware. Almost none go down to the gates. The threat-protection programs that catch malware at the OS layer are blind to a corrupted accelerator that misclassifies one face out of a hundred thousand, or routes a particular inference to the wrong branch.

You probably can’t audit silicon. Fine. You can still stop pretending the supply chain ends where your purchase order does. Demand attestation. Pin firmware versions. Treat the AI accelerators in your fleet as opaque components, and build defense in depth around them so a bad inference can’t autonomously do anything that matters.

The Build Script Isn’t On Your Risk Register Either

An open-source project called CI/CD Abuse Detector showed up this week with drop-in templates for GitHub Actions, GitLab CI, and Azure DevOps. It uses a large language model to flag suspicious changes to pipeline files, workflows, and automation configs. There’s a reason it reaches for an LLM. The attack pattern, stolen developer credentials used to push a small change to a workflow file that exfiltrates the secrets stored in the runner, is invisible to traditional signature-based scanners. The change looks like a developer doing their job. The diff is small. The intent is the whole signal.

This is the same shape as the GRC problem. You can’t grade pipeline edits with a green light. You have to read them. Or you need something that reads them for you, which is what an LLM-based detector amounts to. None of which removes the underlying issue: the credential that pushed the change was valid. Brute-force defenses on developer accounts and phishing-resistant MFA on the SCM are the controls that keep this attack from ever starting, and they’re rarely on the same dashboard as your endpoint coverage.

A firewall doesn’t see this. EDR doesn’t see this. Your SIEM might notice once the secrets have already left.

Concrete Things To Do This Quarter

You won’t fix unmeasurable risk by buying another dashboard. Buy down what you can name. Rehearse for what you can’t.

• Map your AI accelerator supply chain. Inventory FPGAs and ASICs in production fleets. Record vendor, fab origin where known, firmware version, and the last attestation. Treat anything below that line as untrusted, and design model output handling to fail safely.
• Watch your CI/CD config files like they’re root scripts. Alert on every change to workflow files, secrets references, and runner images. If you don’t deploy an LLM-based detector, at minimum require human code review on any edit to .github/workflows, .gitlab-ci.yml, and equivalents.
• Put brute-force controls in front of every developer auth surface. SCM, registry, build server, secrets manager. Stolen credential reuse is the precondition for almost every pipeline attack worth naming.
• Reframe your GRC report. Add a section for unmeasurable risks. Vendor concentration. Insider behavior. Silicon trust. Brand impersonation that lands outside your security stack. Make the board read prose, not just stare at squares.
• Rehearse incident response for invisible compromise. Tabletop a scenario where the only signal is a finance team noticing odd model outputs, or a developer noticing a runner produced an artifact they don’t recognize. Practice without an alert.
• Layer your security hardening. Real defense in depth assumes a control will fail. If you can’t measure something, treat it as already failed, and ensure threat detection further inside the perimeter catches the second-stage behavior.

The Sniper Dz fraud campaign hitting MENA users this week belongs in this same bucket. Fake Facebook accounts impersonating politicians, government subsidy programs, and trusted organizations don’t appear on a CISO’s threat detection feed. They show up on a brand-monitoring tool, run by marketing, with no link to security operations. That’s exactly the kind of risk Windholz means. It’s real, it’s costing somebody money, and it isn’t on the board pack.

The honest answer for a CISO in 2026 is that you can’t make the dashboard match reality. You can make the prose underneath the dashboard match it. That’s the only credible way to report risk that doesn’t fit in a square.

Sources

• Onspring CISO on where automated GRC systems fall short
• A hardware neural network backdoor that hides in plain sight
• Open-source CI/CD abuse detector guards against stolen credential attacks
• Sniper Dz Scams Target MENA Users via Fake Facebook Offers and Browser Alerts