> ## Documentation Index
> Fetch the complete documentation index at: https://docs.amnify.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Manage findings

> Triage, prioritize and act on every confirmed security issue.

A finding is a confirmed issue. Scan results never reach you raw. An agent investigates each one, discards what is not reachable or not exploitable in your setup, weighs what is left against your context, and writes a single finding that states the real impact.

| Type                       | What it means                                                         |
| -------------------------- | --------------------------------------------------------------------- |
| **Exposed secret**         | A credential or key present in code or commit history                 |
| **Code vulnerability**     | Vulnerable code, an unsafe pattern, or a vulnerable dependency        |
| **Infrastructure as code** | An insecure setting in your infrastructure as code, before it deploys |
| **Cloud**                  | A misconfiguration or risky setting in a connected cloud account      |
| **Penetration test**       | An exploitable path proven against your live application              |

Each one carries the **impact** (what it exposes, written for engineers, security and operations), a **severity** rated against established security frameworks, the **location**, and the **evidence** observed.

Severity says how serious the issue is. Your [context](/knowledge/context) decides something different: whether it applies to you at all, and what gets fixed first.

## Status

```mermaid theme={null}
stateDiagram-v2
  [*] --> Open
  Open --> Resolved: fix detected by a later scan
  Open --> Suppressed: waived by your context or by you
  Resolved --> Open: issue seen again
  Suppressed --> Open: decision changed
```

A closed finding keeps its impact and records why it closed.

## Findings waiting on an answer

Some issues cannot be judged without something only your organization knows. Rather than guess, Amnify raises a question and **holds the finding back until you answer it**.

While a question is open, the finding it gates:

* does **not** appear in your findings list,
* is **not** counted in your security posture,
* gets **no** remediation plan and no pull request.

The question itself waits for you in [Context](/knowledge/context) and, if it is assigned to you, in your [Inbox](/getting-started/briefing-and-inbox).

<Note>
  This is deliberate. A finding Amnify cannot yet judge is noise, and noise is what makes security tools go unread. Answer the question and the finding is released into the list in the same moment, correctly ranked, with its fix planned if it warrants one.
</Note>

## Clusters

When one root cause shows up in several places, Amnify groups those findings into a **cluster** and shows them together, with a confidence and a one line reason on each link. One remediation covers the whole cluster.

## Acting on a finding

Answer any open question, then ask for a plan. Amnify writes what the fix is for, what will change and the operational impact. Edit it if you disagree, and on approval Amnify implements it and opens a pull request. See [Fixes and pull requests](/workflow/remediation).

You can also create an issue in your connected ticketing system straight from a finding, when it belongs in your normal backlog. See [Integrations](/connect/integrations).

Every finding keeps its own history: first seen, every status change and who made it, every question and every remediation attempt.