Detected candidate
A scanner found a signal worth reviewing. Confidence can help prioritize it, but does not prove exploitability.
Methodology
A security result should say what it knows—and what it does not.
An evidence state records how strongly a security finding is supported. Three states ship today. Detected means a scanner saw a signal. Retest-confirmed means a server-owned retest found the condition absent after a fix. Inconclusive means the evidence cannot establish the condition is gone. A fourth state, independently verified, is defined for a future separate verification step and no finding is in it today. These are never blended into a single score.
TL;DR
Every finding carries one of three shipped evidence states: detected (a scanner signal that needs review), retest-confirmed (a deterministic retest found the condition absent) or inconclusive (the retained evidence cannot establish resolution). A fourth state, independently verified, is defined for a future separate verification step; no finding is in it today. A score or clean result never overrides these facts.
Last reviewed: · Maintained by LyraShield Security + Engineering
What every new scan record preserves
- Scope
- The authorized target, available source, scan mode and the result-manifest checksum recorded with it.
- Coverage
- Which checks completed, were limited, were skipped or did not apply, including retained limitations.
- Provenance
- Which scanner produced a candidate and, where the state applies, the coverage receipt behind it.
- Outcome
- The server-owned retest result and the evidence boundary behind validated or inconclusive status.
Evidence states are not interchangeable
Independently verified (future step)
Defined for a future separate verification step: a separate receipt would have to support the finding. No shipped path produces this state today, so no finding is in it. Engine confidence alone never creates it.
Retest-confirmed
A server-owned deterministic retest found the relevant condition absent after a fix, with complete applicable coverage.
Inconclusive
The available retest evidence cannot establish that the condition is gone. The uncertainty remains visible.
Release verdict
A public scorecard may include a release verdict. The verdict is derived from the frozen LyraShield Score using the same versioned model that produced the grade. It is an interpretation aid, not an override of the underlying evidence.
- Go
- Score 80 or above. The evidence suggests the target is ready to release, with the retained limitations visible on the scorecard.
- Go with conditions
- Score 40–79. The result is releasable only if the conditions recorded in the scorecard—open findings, coverage limits and retest state—are accepted.
- No go
- Score below 40. The evidence does not currently support release.
- Not evaluated
- No score snapshot was available for the shared record.
Coverage states
Coverage records what happened to each check, which is a separate question from what a finding is. A verdict is only as strong as the coverage behind it.
| Coverage state | What it means | Effect on the verdict |
|---|---|---|
| Completed | The check ran against the authorized scope and returned a result. | Counts toward the verdict. |
| Limited | The check ran but could not see everything in its scope. | Counts, with the limitation retained on the record. |
| Skipped | The check did not run, for example because a prerequisite was absent. | Surfaces as insufficient evidence rather than a pass. |
| Not applicable | The control does not apply to the scanned target type. | Excluded from the denominator and stated as such. |
What this methodology does not claim
- It does not prove an application has no vulnerabilities.
- It does not imply every Vibe Security 50 control can be established by one scan.
- It does not replace an authorized penetration test or specialist point tool.
- A Fix PR opens only after a human approves, with a server-generated patch and scoped authorization: explicit browser approval or an eligible credential's verified permission.
How should you interpret a LyraShield AI result?
Read the result in this order: confirm the authorized target and mode, inspect completed and limited coverage, separate detected findings from retest-confirmed ones, then read the retest receipt and retained limitations. A LyraShield score or confidence value never replaces the underlying scope, coverage, evidence-state and retest facts.
For a broader catalog of web application verification requirements, consult the OWASP Application Security Verification Standard. This reference does not imply certification or full ASVS coverage.
LyraShield AI does not claim "SOC 2 compliant," "certified," "guarantees security," "AI safety tested" (without a named framework) or "adversarial robustness proven." Each of those requires external attestation, a reproducible evaluation corpus, a defined threat model or a formal certificate that LyraShield has not yet obtained.
Methodology questions
What is an evidence state?
An evidence state describes how much support a finding has. Detected, retest-confirmed and inconclusive are the three shipped states. They are not interchangeable labels. A fourth state, independently verified, is defined for a future separate verification step; no finding is in it today.
Does a clean or high score prove an app is secure?
No. A score is an interpretation aid derived from the evidence. It does not override the underlying findings, coverage limits or retest receipts.
What does 'no finding returned' mean?
It means the assigned check completed without reporting anything in scope. It is not the same as 'passed' or 'secure'; it only records that the check ran and returned nothing.
What is the Vibe Security 50?
It is a fixed list of 50 controls LyraShield AI reviews on AI-built apps. 43 are routed to code or URL review where applicable and 7 require operational or human evidence outside the scan because a repository or URL scan cannot establish them safely.
Start with a check you can inspect.
The free tools run locally in your browser and state their limits.