A useful explanation of exploit difficulty tells the reader what someone needs before they could cause the harm. “Critical,” “easy” and “unlikely” leave too much hidden. Name the starting access, the additional prerequisite and the uncertainty that could change the judgment.
This is a writing workshop using three fictional technical notes about the same potential harm: receiving another customer's document. Each note supports a different explanation. None describes an executed attack, a real customer or a CodeSecPilot result. The task is to preserve the evidence while making the consequence understandable.
Case 1: an ordinary account, but an unknown way to obtain the ID
Technical note. DOC-14's source and configuration review connects an authenticated export route to a global document lookup and delivery without an account check. The route is mapped to the deployed artifact and available to ordinary customer accounts. A valid foreign document ID is required. The review has not established how an ordinary customer would obtain one. The source claim has passed the fictional team's independent verification and approval; no runtime exploitation is claimed.
Overstated: “Anyone can easily steal every customer's documents.”
That sentence drops login and identifier requirements, invents ease of obtaining IDs, and expands one reviewed path into a bulk compromise.
Falsely reassuring: “The IDs are hard to guess, so customers are safe.”
The review did not measure guessing resistance or exclude other ways IDs could become known. Even a well-generated identifier can be exposed through an unrelated workflow. An unknown prerequisite should remain unknown.
Defensible three-sentence version:
An ordinary signed-in customer who obtains another customer's document ID could use the reviewed export route to receive that document. The request path appears straightforward once the ID is available, but we have not established how a customer could obtain it. We are correcting the missing account check and examining ID exposure; no actual misuse has been established by this review.
The phrase “who obtains” preserves the prerequisite. “Reviewed export route” limits the scope. “Once” distinguishes request complexity from acquiring the input. The last sentence tells the buyer what is being done without claiming the fix is already complete.
Case 2: the same harm requires a privileged internal role
Technical note. OPS-08's export function is available only to billing supervisors through the company's managed internal access service. The supplied effective policy excludes ordinary employees and customer accounts. Supervisors can select a foreign account's document because the export lacks the intended portfolio check. A valid document reference appears in their operational queue. No supervisor misuse is established.
Overstated: “A public document leak puts all customers at immediate risk.”
The assessed entry requires a privileged role and internal access. “Public” describes a different claim.
Falsely reassuring: “Only trusted staff can do this, so it is not a vulnerability.”
The intended policy limits supervisors to assigned portfolios. Trust in the role holder does not satisfy that resource boundary, and compromise of such an account remains a relevant starting condition.
Defensible three-sentence version:
A billing supervisor with access through our managed internal service could retrieve a document outside their assigned portfolio. The required document reference is available in the operational queue, but customer accounts and ordinary employees cannot use the assessed route under the checked policy. We are narrowing supervisor access while correcting the portfolio check; this review has not established that anyone used the path improperly.
Here “billing supervisor” carries more decision value than “high attack complexity.” The buyer can ask how many such accounts exist, how access is reviewed and whether the interim restriction is effective. Do not answer those questions with invented numbers; ask the identity owner for the relevant inventory.
The possible document harm is similar to Case 1. The starting position differs. That can change containment and work order without making the failed control acceptable.
Case 3: a downstream control could defeat the claim
Technical note. EXP-22's handler passes a document reference to an export service. The handler does not compare ownership. A shared delivery service might require current-account authorization, but its implementation and effective route binding have not been supplied. The allegation remains an investigation.
Overstated: “The scanner confirmed cross-account document theft.”
The missing delivery evidence could defeat the path. Neither “confirmed” nor “theft” follows from the handler alone.
Falsely reassuring: “The delivery service probably blocks it.”
That substitutes an architectural expectation for evidence that this request uses the control.
Defensible three-sentence version:
We are investigating whether the export path could deliver another customer's document. The visible handler does not check ownership, but a downstream delivery control may prevent the action and has not yet been reviewed. The service owner will supply that control and its route binding by the agreed checkpoint; this item is not currently counted as a verified vulnerability.
There is no honest “low/medium/high difficulty” conclusion yet. The uncertainty concerns whether the alleged harmful path exists at all, not just how hard it would be to use. Marking it “medium” would conceal that distinction.
Update the explanation when one missing fact arrives
Return to DOC-14. Suppose a later authorized evidence review establishes that a shared activity feed exposes document IDs to ordinary accounts, including references outside the viewer's account. The supplied feed code, visibility policy and deployment mapping support that additional path. This is new fictional evidence, not a discovery performed for this article.
Replace the prior explanation with:
An ordinary signed-in customer could obtain another customer's document ID from the assessed activity feed and use it on the export route to receive the document. Both steps are supported by the reviewed deployed paths; the earlier uncertainty about ID availability is resolved for that feed. We are restricting the feed and correcting export authorization, while separately checking whether historical records show misuse.
The new evidence supports a stronger practical judgment. It still does not establish actual misuse, universal document coverage or a measured attack success rate. The technical owner should also decide whether the feed exposure is a separate finding with a different repair, or part of one combined path; the prose should not determine the defect taxonomy by accident.
Answer the buyer's follow-up without inventing a probability
A buyer may ask, “How likely is this to happen to us?” The three cases do not supply a numerical probability. They describe different prerequisites, controls and evidence limits. Explain those facts first, then connect them to the decision the buyer faces. Avoid converting “ordinary account required” into a percentage or calling an unresolved path unlikely simply because nobody demonstrated it during the review.
For DOC-14 before the feed evidence arrives, a useful answer is: “We have support for the export behavior once a foreign ID is available. We do not yet know how readily that ID can be obtained, so we are not assigning a probability from this review. The missing account check is being corrected while we investigate that prerequisite.” The explanation preserves urgency without claiming measured exploitation frequency.
For OPS-08, the answer should focus on privileged access: “The checked route requires a billing supervisor through the internal service. That narrows who can start, but the permitted role still lacks the intended portfolio restriction. We are confirming the role population and applying the interim access decision.” The buyer can now ask a concrete question about accounts, access review and containment instead of debating whether “trusted staff” means low risk.
For EXP-22, the correct answer is earlier in the reasoning chain: “We do not yet know whether the harmful delivery is possible. The downstream control could prevent it, and its evidence is due at the checkpoint.” A difficulty label would pretend that the path exists before the reviewer has established it.
Separate a difficult path from a small consequence
Suppose a route requires an unusual administrative configuration, but successful use could expose a large set of sensitive records. That can be a difficult path with a serious consequence. Conversely, a straightforward request may reveal only a narrowly scoped low-sensitivity value. The explanation should preserve both dimensions so a buyer can judge the response. Do not let one reassuring prerequisite erase the possible impact, or let a serious impact erase the prerequisite.
The same distinction applies to a temporary control. Restricting the supervisor population can reduce opportunities to use OPS-08, while the missing portfolio check remains. If the restriction is only proposed, say that it is pending. If it is evidenced, state which users can still reach the route and what residual authority they retain. “Mitigated” without that detail can sound like “fixed” to a nontechnical reader.
A short comparison table can help the writer choose the right sentence:
| Question | DOC-14 before feed evidence | OPS-08 | EXP-22 |
|---|---|---|---|
| Can the starting actor reach the reviewed entry? | Ordinary account can | Checked supervisor role can | Entry known; final delivery unresolved |
| What extra fact matters most? | Foreign ID availability | Privileged role and portfolio boundary | Downstream authorization behavior |
| What should the response avoid? | Claiming effortless bulk theft | Calling internal access harmless | Assigning difficulty to an unestablished path |
These are explanations of the fictional records, not a ranking formula. Their purpose is to show what the buyer should ask next.
Give each audience the same technical conclusion
Engineering needs exact source and deployment references. The buyer needs the actor, prerequisite, harmful action and current response. The board may need the business consequence and remaining evidence gap. Translate the detail without changing the verdict. If the engineering note says “candidate pending delivery review,” a sales summary must not call it a confirmed exploit or a resolved false positive.
Before sending, remove adjectives and see whether the sentence still answers the question. “A sophisticated attacker could potentially exploit a serious issue” supplies almost no usable condition. “A billing supervisor who can obtain the target reference could retrieve a document outside their assigned portfolio” preserves the concrete starting point. Add the deployment and uncertainty boundary where the evidence requires it.
When new evidence changes the explanation, identify the changed fact. In DOC-14, the feed resolves ID availability; it does not establish past misuse. That one-line change record helps a buyer understand why the assessment became stronger without assuming the earlier team hid information or that every part of the case changed.
Use scores as supporting context
CVSS v4.0 provides structured vulnerability characteristics, including privileges and user interaction. EPSS estimates exploitation in the wild for published CVEs over the next 30 days. CISA's KEV catalog records vulnerabilities with evidence of exploitation. EPSS is not the probability that this buyer will be compromised. None of these sources supplies the missing local delivery implementation in Case 3. A first-party authorization defect may have no CVE to which EPSS or KEV applies.
Before sending the explanation, have the technical owner underline the phrase supporting each of these three questions: Who can start? What else do they need? What could change the conclusion? Then ask a reader outside security to repeat the answers. If the answers disappear in words such as “sophisticated” or “secure,” replace the adjective with its condition.
For the technical prerequisite assessment behind the prose, use the attacker-access guide. For the business choice that follows, use the CEO decision brief.