> For the complete documentation index, see [llms.txt](https://kerno.gitbook.io/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://kerno.gitbook.io/docs/references/security-testing.md).

# Security testing

What the security tag produces, how Kerno picks the vulnerabilities worth testing, and how to review what it flags.

Security tests baseline your entry point's security posture. Kerno records how the entry point stands up to a specific class of attack today, so if a later change opens that vulnerability, the test starts failing and the regression is caught in the same loop as any other behaviour change.

### Turning it on

Security coverage is controlled by the `tags` argument on `kerno_endpoint_test`. It defaults to `validation`.

| `tags`                      | Happy path | Functional coverage | Security scenarios |
| --------------------------- | ---------- | ------------------- | ------------------ |
| omitted or `["validation"]` | yes        | yes                 | no                 |
| `["security"]`              | yes        | **no**              | yes                |
| `["validation","security"]` | yes        | yes                 | yes                |

Note the middle row. `security` on its own **narrows** the run rather than adding to it, so pass both tags when you want your normal functional coverage alongside security scenarios. The happy path is always planned, whatever you pass.

Ask for it through your agent:

```
Use Kerno to generate tests for POST /api/users with validation and security coverage.
```

### What the security tag changes

It changes two stages of the run.

**Planning** assesses which **OWASP API and Web Top 10** categories plausibly apply to the entry point, given its inputs, its authentication model, and what the surrounding code does, then plans tests only for the categories that fit. Common ones include broken object-level and function-level authorization, injection, excessive data exposure, mass assignment, and server-side request forgery.

**Implementation** frames the baseline assertions as vulnerability checks. A passing scenario means the entry point is not vulnerable to that case today, and a later baseline diff explains in plain English what the vulnerability is.

That framing is why a security scenario is worth keeping even while it passes. The value is in the day it stops passing.

### Reading the results

Security scenarios report the same four verdicts as any other scenario, described in [Baseline tests](/docs/core-concepts/scenarios-and-baselines.md#reading-test-results). A failing security scenario means the entry point's security behaviour moved, and it is for you to decide whether the new behaviour is intended.

### Potential bugs

A scenario that passes can still carry a **potential bug**. A run saw the entry point do something the plan did not expect, and Kerno wrote the test to document that real behaviour. Kerno records one only when a run actually observed it. The flag names what deviated and what a future change would signify. When it names a suspected code location, the location counts as verified only if Kerno read that code during the run.

If you review one and decide the behaviour is known or intended, tell your agent to ignore it:

```
The role field Kerno flagged on GET /users/:id is intentional, we keep returning it
for backwards compatibility. Have Kerno ignore that potential bug.
```

Kerno records the decision for that entry point, alongside the code revision you made it against, and later run reports leave it out. The test file keeps its flag until the entry point's tests are next updated, and a full cache clear discards the decision.

{% hint style="warning" %}
There is currently no way to reverse an ignore decision through Kerno, so read the flag carefully before you dismiss it.
{% endhint %}

### Related

* [Testing modes](/docs/references/testing-modes.md) for every other dial on a run.
* [Baseline tests](/docs/core-concepts/scenarios-and-baselines.md) for what a baseline records.
* [Supported technologies](/docs/references/supported-technologies.md) for the authentication mechanisms Kerno handles.