> ## 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.

# Code scanning

> What Amnify checks in your repositories, and how a raw result becomes a finding.

Amnify reviews each selected repository across five angles. Deterministic checks find the candidates, then an agent reads the code around each one and decides which are genuinely exploitable.

## What we check

<AccordionGroup>
  <Accordion title="Exposed secrets" icon="key">
    Credentials, API keys, tokens and private keys present in the working tree or in commit history. Every candidate is checked for whether it is a live credential or a placeholder, and the finding names the exact file, line range and commit.
  </Accordion>

  <Accordion title="Vulnerable code" icon="bug">
    Injection reachable from untrusted input, including SQL, command, template and cross site scripting. Unsafe deserialization, path traversal, server side request forgery, unsafe redirects, and prototype pollution. Weak or misused cryptography, weak randomness for security purposes, and hard coded cryptographic material.
  </Accordion>

  <Accordion title="Broken authorization and authentication" icon="lock">
    Missing or inconsistent authorization checks on endpoints and handlers, object level access that trusts a client supplied identifier, privilege boundaries that a role can cross, session and token handling, and authentication logic that can be bypassed.
  </Accordion>

  <Accordion title="Sensitive data exposure" icon="eye-slash">
    Secrets and personal data written to logs or error responses, over broad API responses, insecure storage of sensitive values, and debug surfaces reachable in production.
  </Accordion>

  <Accordion title="CI/CD and build" icon="sitemap">
    Pipeline definitions that run untrusted input with elevated permissions, over privileged workflow tokens, unpinned or mutable third party actions and images, and secrets exposed to steps that do not need them.
  </Accordion>
</AccordionGroup>

Dependency vulnerabilities and infrastructure as code are covered on their own pages: [Dependencies and CVE disclosures](/scanning/cve-disclosures) and [Infrastructure as code](/scanning/infrastructure-as-code).

## Deterministic checks

The five angles above are covered by a large body of deterministic checks: proprietary checks Amnify defines and maintains itself, alongside a broad set of established open source checks. All of them are derived from recognized security best practice, so a result is grounded in a rule someone can point at rather than in a guess.

What a check cannot tell you is whether the code path is reachable, whether the input is actually untrusted, or whether a guard three files away already handles it. Those questions decide whether a match is a vulnerability or noise, and answering them takes reading the code.

## Expert review on top

That reading is the agent's job, and it works the way a senior application security engineer does.

<CardGroup cols={2}>
  <Card title="Traces the data flow" icon="route">
    Follows untrusted input from the entry point to the sink, across files, layers and frameworks, instead of matching a pattern in one file.
  </Card>

  <Card title="Knows the framework" icon="layer-group">
    Which query builder escapes, which template engine auto-escapes, where a middleware already enforces authorization. A pattern that is dangerous in one stack is inert in another.
  </Card>

  <Card title="Reads your existing controls" icon="shield-halved">
    A guard in a different file, a validation layer, an authorization check on the route above. All of it counts before anything is called exploitable.
  </Card>

  <Card title="Verifies in an isolated sandbox" icon="flask">
    When reading alone cannot settle whether a path is really reachable, the agent works it out against a checked out copy of the code in Amnify's own sandbox.
  </Card>

  <Card title="Separates live from inert" icon="key">
    A real credential from a placeholder, a test fixture from a production secret, an example in documentation from a key committed by mistake.
  </Card>

  <Card title="Judges the blast radius" icon="bomb">
    What an attacker reaches next: which data, which privileges, which other systems trust this one.
  </Card>
</CardGroup>

<Note>
  Code scanning never touches your running systems. It reads your repository and reasons about a copy of it, so nothing is deployed, nothing is executed in your environment, and no request reaches your applications. The only capability that interacts with a live system is a [penetration test](/pentest/overview), which you authorize per application and verify domain ownership for first.
</Note>

It also carries the parts of the job that are not about a single result: recognizing the same weakness repeated across services, spotting the missing control behind a set of symptoms, and knowing when a decision is yours to make rather than its own, which is when it [asks](/knowledge/context).

That is why a finding states impact rather than a rule name, and why the volume you receive is a fraction of what raw tooling emits.

## From result to finding

```mermaid theme={null}
flowchart TB
  O["Raw results across<br/>all five angles"] --> D["Deduplicate and discard<br/>the unreachable"]
  D --> K["Judge against your context"]
  K --> L["Cluster findings sharing<br/>one root cause"]
  L --> F["Finding: impact, severity,<br/>location, evidence"]
```

## Tracked across scans

A code finding is identified by what it is and where it lives, not by the scan that found it: the repository, the file path, the issue and its category, or for a secret the repository, commit, path and line range.

That means the same issue found in twelve consecutive scans is one finding with a history, not twelve findings. When a later scan no longer sees it, the finding is resolved. If it comes back, it reopens.

## Scan triggers

| Trigger                | What it covers                                                                                                                                |
| ---------------------- | --------------------------------------------------------------------------------------------------------------------------------------------- |
| Manual                 | The whole repository                                                                                                                          |
| Scheduled              | The whole repository, daily, weekly or monthly                                                                                                |
| Push to default branch | The pushed commit range. Overlapping pushes merge into one run                                                                                |
| Pull request           | The change in the pull request, before it merges. Posts inline comments rather than findings. See [Pull request review](/workflow/pr-reviews) |
| New advisory           | Dependencies only. See [Dependencies and CVE disclosures](/scanning/cve-disclosures)                                                          |

<Info>
  **Enable at least one of push scanning or pull request review.** Both watch new code, at different moments. Pull request review catches a problem before it merges, which is the cheapest place to fix it. Push scanning catches whatever lands on your default branch, including commits that never went through a pull request.

  Running both gives the fullest coverage. Running neither means new code is first seen at your next scheduled scan, which can be weeks after it shipped.
</Info>

Configure these per repository in [Scan automation](/scanning/automation).