Explain This Threat

Security findings can be terse. A row that says “Broad CORS observed on public endpoint” or “Critical CVE in [email protected] affecting 2 services” tells you what happened. If you’re not the team’s resident security person, you might still want to know what it actually means and what to do about it.

Explain This Threat is an inline action on every finding and every event that produces a plain-language explanation: what the condition is, why it matters in this context, and concrete next steps.

What you get

Each generated explanation has the same shape:

1. Plain-language description. What the finding or event is, written for a developer who is not a security specialist.
2. Why it matters in your context. Connecting the finding to your specific scope: the affected service, project, severity, and any related findings.
3. What to do. Concrete next steps, ordered by impact and ease.
4. Scoped clarification. Where appropriate, explicit clarification of what the finding does mean in this specific context, so you can size your response correctly.

The explanation is written to be useful on its own; you should be able to forward it to a teammate and have them act on it without further context.

How model scope is bounded

This is the most important part of how Explain This Threat works:

• Raw secrets stay out of the model. Secret-exposure findings reach the explanation as redacted evidence only. The secret value itself is never included in the prompt.
• Raw request and response bodies stay out of the model. Service scans store no bodies, so the explanation only sees what is already attached as evidence.
• Customer log content stays out of the model. Findings reference services, not logs.
• Each explanation runs in a single-account scope. The model sees only the finding and the bounded evidence attached to it.

If a finding’s evidence is already redacted (for example, for a secret exposure), the explanation operates on the redacted evidence. The model gets exactly what you can see in the dashboard, and nothing more.

When to use it

Explain This Threat is most useful when:

• You’re triaging a finding type you haven’t seen before.
• You’re handing a finding off to a teammate who isn’t on the security rotation.
• You want a second opinion on severity before deciding whether to suppress, acknowledge, or fix.
• You’re writing a post-incident note and want a plain-language paragraph to drop into the doc.

It’s less useful when:

• You already know exactly what the finding means and what to do. (Don’t generate explanations for noise. It costs you nothing technically, but it dilutes the value of the ones you do generate.)
• The finding is a transient state that’s already resolved. The explanation is still accurate, but the action is “do nothing.”

Generating and regenerating

When you open a finding or event detail, the inline action either shows the existing explanation (if one has been generated before) or offers to generate one. You can also explicitly regenerate the explanation, which is useful when the finding has been updated with new evidence since the last explanation was written.

Each generation writes a security.threat_explanation.generated audit-log entry, so you can audit who asked for which explanations without adding noise to the Security Events timeline.

Where to go next

• Read the inbox the action lives on: Security Findings.
• Review generated-explanation activity in your account audit logs.
• For an aggregate view that summarizes themes across many findings: Reports & Posture.