> ## Documentation Index
> Fetch the complete documentation index at: https://docs.myrqen.cc/llms.txt
> Use this file to discover all available pages before exploring further.
# Findings
> Severity and verification are independent. The CLI owns identity, redaction, and deduplication — the agent supplies the reasoning.
A finding is one root cause. The agent proposes it; the CLI decides what it becomes.
## Severity and verification are independent
This is the single most important thing to understand about a Myrqen report.
| | Answers | Values |
| ---------------- | --------------------------------------------------- | ------------------------------------------- |
| **Severity** | What is the realistic impact *in this application*? | `critical` `high` `medium` `low` `info` |
| **Verification** | How strongly was it proven? | `verified` `strong_evidence` `needs_review` |
Deterministic local or authorized evidence demonstrates the issue. Something was
requested, and something came back that proves it.
The root cause and a reachable path are strongly supported, but full proof is
unavailable or could not be obtained safely. This is the correct label when the only
remaining proof would have required a prohibited action.
Plausible, with insufficient validation. A static candidate nobody exercised stays
here, and the report says so rather than implying more.
The report filters on both axes separately, so "high impact but unproven" and "proven but
low impact" never collapse into one number.
## What the CLI owns
Findings arrive from the host agent as untrusted-shaped data, so intake — not the agent —
owns every decision that a report's integrity depends on.
The CLI assigns the id, in the form `MYR-001`. A submission containing an `id` is
rejected.
Secret-shaped material is redacted on the way in. A finding that still contains a
live-looking credential after redaction is **rejected**, not stored. The result
reports how many redactions were applied.
Lowercased, whitespace and hyphens folded to underscores, non-alphanumerics stripped,
truncated to 120 characters.
The fingerprint is category + normalized location + root-cause identity. Concrete
identifiers are collapsed, so `/orders/12` and `/orders/13` are one location, and
hex digests and bare numbers in the summary are normalized away.
Submit the same root cause again with new evidence and it is **merged as
corroboration** rather than filed as a duplicate. The result says
`action: "merged_as_corroboration"` with `deduplicatedInto` naming the original.
Two rules, both of which produce a warning rather than a silent change — see below.
### Severity capping rules
**Rule 1 — unvalidated criticals are leads.** `severity: "critical"` with
`verification: "needs_review"` is reduced to `high`:
> Severity critical with verification needs\_review was reduced to high. Validate the issue
> to restore critical.
**Rule 2 — commonly over-rated categories need runtime evidence.** These three categories
are capped at `medium` unless at least one piece of evidence has kind `runtime` or
`identity_differential`:
* `missing_security_header`
* `verbose_error_message`
* `outdated_dependency_no_known_exploit_path`
> Severity for category "…" was reduced to medium because no runtime or differential
> evidence was supplied.
## Evidence kinds
| Kind | Use it for |
| ----------------------- | ------------------------------------------------------------------------------- |
| `source` | What the code does, with the smallest excerpt that makes it clear. |
| `runtime` | What the running application actually returned. |
| `identity_differential` | The same request as two identities, with different outcomes. |
| `configuration` | A setting, header, or environment value as deployed. |
| `dependency` | A version inside a published advisory range, with reachability stated honestly. |
| `other` | Anything the above do not describe. |
## Settling a static candidate
The static pass files candidates before the agent starts. Each one is a claim.
```bash theme={null}
myrqen --json finding verify MYR-001 \
--description "As user_a, GET /api/orders/102 returned HTTP 200 with userId 2." \
--kind identity_differential \
--location "GET /api/orders/102"
```
```bash theme={null}
myrqen --json finding refute MYR-002 \
--reason "The lookup is scoped by session in middleware the static pass could not follow; the cross-account request returns 404."
```
Refuting keeps the finding and labels it a false positive, with the reason attached. A
reader can disagree with that. They cannot disagree with something silently deleted.
Never resubmit a candidate in order to confirm it. A resubmission merges only when the
summary matches the original word for word, so in practice it produces the same issue
twice. Use `finding verify`.
## Finding status and the fix history
Once remediation starts, a finding also carries a status:
`open` · `fix_suggested` · `fix_applied` · `fixed_verified` · `accepted_risk` ·
`false_positive`
Each step appends to `fixHistory` with an action (`suggested`, `applied`, `verified`,
`verification_failed`, `reverted`), whether verification actually passed, the changed
files, and an optional note. A finding reaches `fixed_verified` **only** when a passing
verification was recorded. See [Fix and retest](/guides/fix-and-retest).
## What the static pass looks for
`packages/scan` ships rules across these categories. They are the starting point, not the
ceiling — the agent is expected to find root causes the static pass could not reach.
| Access control and authentication | Injection and unsafe composition | Data exposure and resource abuse |
| ------------------------------------- | -------------------------------- | ----------------------------------- |
| `broken_object_level_authorization` | `sql_injection` | `zip_slip` |
| `broken_function_level_authorization` | `nosql_injection` | `unrestricted_file_upload` |
| `missing_authentication` | `unsafe_query_composition` | `server_side_request_forgery` |
| `mass_assignment` | `command_injection` | `open_redirect` |
| `jwt_verification_bypass` | `argument_injection` | `hardcoded_secret` |
| `missing_csrf_protection` | `code_injection` | `secret_exposed_to_client_bundle` |
| `missing_rate_limit_on_credentials` | `template_injection` | `sensitive_data_in_logs` |
| `insecure_cookie_configuration` | `reflected_cross_site_scripting` | `debug_endpoint_exposure` |
| `insecure_cors_configuration` | `stored_cross_site_scripting` | `verbose_error_response` |
| `timing_unsafe_comparison` | `prototype_pollution` | `unbounded_resource_consumption` |
| `insecure_randomness` | `unsafe_deserialization` | `race_condition_double_spend` |
| `weak_hash_algorithm` | `xml_external_entity` | `business_logic_price_manipulation` |
| `weak_password_hashing` | `path_traversal` | |
## Reporting quality
The Agent Skill holds the agent to these:
* Explain the **root cause**, not the category name.
* Say why you believe the finding, and label the evidence kind.
* Give the **smallest durable fix**, prefer the framework's own safeguard, and name a
regression test.
* Do not inflate severity because a category sounds serious.
* If you found nothing, say what you covered and what you could not reach.
## Related
Every field, every rejection rule, and a worked example.
How findings are rendered, and what a share projection removes.