✓ Human-authored analysis; AI used for formatting and proofreading.
Every security tool produces findings. Very few produce decisions.
Run Prowler against an AWS account and you get a report with 572 checks, each labeled PASS or FAIL, each mapped to a CIS control number. Run Checkov against a Terraform plan and you get a list of policy violations, each with a severity level. Run any CSPM and you get a dashboard with a number — 84% compliant, 312 findings, 47 critical.
These outputs are designed for the engineer who will fix the problem. They are not designed for the person who decides whether the problem gets fixed.
The CISO doesn't read your CLI output. Neither does the CFO, the board, the insurance underwriter, or the acquirer in a due diligence process. They read risk narratives. Security programs stall in the gap between what your tool produces and what the decision-maker needs, budgets get cut, and findings age into breaches.
The translation problem
A security engineer runs a scan. The scan produces 312 findings. The engineer triages them, identifies the 15 that are critical, and writes a report. The report goes to the CISO. The CISO reads it and asks one question:
"What does this mean for the business?"
The engineer can answer: "We have 15 critical findings including overpermissioned IAM roles, public S3 buckets, and missing encryption." The CISO asks: "So what's our risk? Are we going to have an incident? How does this compare to last quarter? Should I be worried?"
The tool produced findings. The CISO needs a risk posture. The translation between the two is done manually, by the engineer, in a slide deck, using professional judgment. The judgment is valuable. The process is not valuable. Because it's lossy, subjective, inconsistent, and not repeatable. Two engineers looking at the same 312 findings will produce different risk narratives. The same engineer looking at the same findings on different days will produce a different narrative. The CISO is making decisions based on an unreproducible translation of tool output into business language.
This is a language problem. Security tools speak in findings. Decision-makers speak in risk. Nobody built the translator.
What the CISO needs to know
Talk to CISOs about what they need from their security teams and the same five questions come up:
"Are we going to get breached?" Not "do we have findings" — "do we have findings that combine into something an attacker can use?" A finding that says "this S3 bucket is public" is a data point. A finding that says "your environment matches the configuration pattern that caused the Capital One breach, and the only gate holding is IMDSv2 enforcement on three instances" is a risk assessment. The first generates a ticket. The second generates an executive conversation.
"How bad would it be?" Not the severity label on the finding — the business consequence. Critical means different things to different tools. A dollar figure from a precedent incident means the same thing to everyone. "This pattern cost Capital One $300 million in fines and settlements" can be taken to the board by CISO. "Critical severity, CVSS 9.8" can be taken to a triage meeting by an engineer. These are different audiences, decisions, and languages.
"Is it getting better or worse?" Trend, not snapshot. A CISO who sees 312 findings this quarter and 287 last quarter knows the number went up. They don't know whether the risk went up. Maybe the new findings are all low-severity and the critical ones from last quarter were fixed. Maybe the new findings include a compound chain that didn't exist before. The number tells you nothing without composition — what kinds of findings, how they interact, whether the new ones are more or less dangerous than the old ones.
"Can we prove it?" To the auditor, underwriter and acquirer. The proof needs to be reproducible. Someone else should be able to verify the claim independently. "We ran our tool and it said we're clean" is an assertion. "Here is the snapshot, here is the control catalog, run the evaluation yourself and you'll get the same findings" is evidence. The difference between assertion and evidence is the difference between trust-me and verify-it, and every stakeholder outside the security team wants the second.
"Where should I spend the next dollar?" The CISO needs to know where incremental investment changes the risk posture most. Should the dollar go to closing the three remaining findings in the Capital One chain (preventing a named $300M incident shape) or to rotating 200 stale IAM access keys (reducing the credential exposure surface)? These are different investments with different returns, and no CLI output helps make the comparison.
Why compliance scores fail as the bridge
The industry's attempt to bridge the gap between findings and decisions is the compliance score: a single number that represents security posture. 84% compliant. 47 critical findings. An "A" rating from the security scoring vendor.
Compliance scores fail as decision inputs for three reasons.
First, they aggregate without weighting. A compliance score that treats a public S3 bucket the same as a missing CloudTrail tag counts both as one finding. The score doesn't know that the public bucket is an active data exposure and the missing tag is a governance housekeeping item. Moving from 84% to 86% by fixing two tag findings and one bucket finding looks the same whether you fixed the bucket or the tags. The score improved. The risk may not have improved.
Second, they measure coverage, not exposure. A compliance score says "you checked 572 things and 480 passed." It doesn't say "the 92 that failed combine into three exploitable attack paths." The passing rate can be high and the risk can be high simultaneously, because risk lives in the interactions between failures, not in the failures individually. A 95% compliance score with a live Capital One chain is worse than an 80% compliance score without one.
Third, they're not reproducible by a third party. A compliance score is generated by a vendor's proprietary algorithm against the vendor's proprietary scan. The CISO can report the score, but the auditor can't verify it independently. The insurance underwriter can't re-run it. The acquirer can't check it against their own analysis. The score is an assertion, not evidence.
What the output should look like
The output that bridges the gap between findings and decisions has four properties.
It names the risk, not the finding. Not "CTL.EC2.IMDSV2.001: VIOLATION on i-0abc123" but "your environment matches the Capital One breach pattern on 3 instances." The named incident shape connects the technical finding to a business consequence the decision-maker already understands. Capital One is a story the CISO can tell the board. A control ID is not.
It quantifies distance, not severity. Not "critical severity" but "one configuration change away from an active attack path." Distance-one means the compound isn't active today but would activate if a single control changed. That's more precise than "critical" (which is a static label) and more useful than "number of findings" (which is a count without composition). A CISO can prioritize: distance-zero findings first, distance-one findings second, everything else by remediation cost.
It cites precedent, not probability. Not "EPSS score 0.73" but "this pattern was exploited in 7 documented campaigns between 2019 and 2025, including Capital One ($300M), Uber ($148M fine), and CodeSpaces (company ceased operations)." Probability is abstract. Precedent is concrete. An insurance underwriter can price against precedent. A board member can understand precedent. Nobody outside the security team knows what an EPSS score means.
It's independently reproducible. The same snapshot, the same control catalog, and the same evaluation engine produce the same findings on anyone's machine. The CISO can share the snapshot with the auditor. The auditor can run the evaluation independently. The findings are evidence, not assertions. This is the property that makes the output trustworthy to stakeholders who don't trust the tool. Because they don't need to trust the tool. They need to trust the snapshot, and they can verify the evaluation themselves.
The budget consequence
Security programs that speak in findings get compliance budgets. Security programs that speak in risk narratives get security budgets. The difference is structural.
A CISO who tells the board "we have 312 findings and we need headcount to fix them" is making a compliance argument. The board hears: spend more to check more boxes. The budget is measured against the cost of audit failure, which is knowable and bounded. The CISO gets enough budget to pass the audit and not a dollar more.
A CISO who tells the board "we are one configuration change away from the pattern that cost Capital One $300 million, and closing that gap requires these three specific changes" is making a risk argument. The board hears: spend this to avoid that. The budget is measured against the cost of the incident, which is real and documented. The CISO gets enough budget to close the gap, because the gap has a name, a dollar figure, and a precedent.
The difference is the tool output the CISO is translating from. If the tool produces 312 undifferentiated findings, the CISO can only make the compliance argument. If the tool produces named incident shapes with distance classifications and cited precedents, the CISO can make the risk argument. The tool determines the ceiling of the conversation.
Uber's engineering director said: "These numbers are activity metrics, not business outcomes. When we start talking about costs, our CFO has asked me: what is the impact? I can't point him to the number of diffs, I need to show what's the impact on revenue." Replace "diffs" with "findings" and the statement applies to every security program that reports compliance scores to executive leadership.
The shift
The shift isn't from one tool to another. It's from one output format to another.
The current output: a list of findings, each with a severity label, optionally mapped to a compliance framework control number. This is the language of the security engineer. It's correct, specific, and actionable for the person who will ssh into the instance and change the configuration.
The needed output: a list of named risk patterns, each with a distance classification (active / one change away / potential), each citing incident precedent with documented business consequences, each independently verifiable from a reproducible artifact. This is the language of the decision-maker. It's correct, specific, and actionable for the person who will allocate budget, accept risk, or report to the board.
Both outputs come from the same underlying data. The difference is how the data is composed and presented. Findings compose into chains. Chains name incident shapes. Incident shapes cite precedents. Precedents have dollar figures. Dollar figures fund security programs.
The CISO doesn't read your CLI output. They read the risk narrative that your CLI output should produce but currently doesn't. Close that gap and the CISO becomes your ally instead of your audience. The findings become business cases instead of technical debt. And the security program gets funded against the cost of incidents, not against the cost of audit failure.
The tool that helps the engineer make the case is the tool that earns its place in the stack. Everything else is a scanner.
Top comments (0)