Methodology

A security result should say what it knows—and what it does not.

LyraShield AI preserves scope, coverage, evidence provenance, and retest state as separate facts. It does not turn scanner confidence or missing evidence into a universal security verdict.

TL;DR

Every finding carries one of four evidence states: detected candidate (a scanner signal that needs review), independently verified (a separate receipt supports it), retest-confirmed (a deterministic retest found the condition absent), or inconclusive (the retained evidence cannot establish resolution). A score or clean result never overrides these facts.

Last reviewed: July 29, 2026 · Maintained by LyraShield Security + Engineering

What every new scan record preserves

Scope: The authorized target, available source, scan mode, and immutable result-manifest checksum.
Coverage: Which checks completed, were limited, were skipped, or did not apply, including retained limitations.
Provenance: Which scanner produced a candidate and whether an independent verification receipt exists.
Outcome: The server-owned retest result and the evidence boundary behind validated or inconclusive status.

The Trust Runs list in the LyraShield console. Five completed runs are listed — release checks, a code review and a deep security review — each showing the engine status, the start and end timestamps, and a retained finding count. — **Records accumulate; they are not overwritten.** Each run keeps what ran, when it started and ended, and two counts held separately: what the engine reported, and what was retained after review. Target and repository names are blurred.

Evidence states are not interchangeable

Detected candidate

A scanner found a signal worth reviewing. Confidence can help prioritize it, but does not prove exploitability.

Independently verified

A separate verification receipt supports the finding. Engine confidence alone never creates this state.

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.

The Issues view in the LyraShield console. Findings are listed with a severity, an evidence state, an open status and a CWE and CVSS reference. A side drawer for the selected finding shows tabs for what to do, technical detail and history, a plain-language explanation, and a button to create a fix proposal. — **The states, carried on real findings.** Severity and evidence state are separate columns —*detected* and *inconclusive* both appear here — and the drawer opens on what to do next rather than raw scanner output. A fix proposal is something you create and review; nothing auto-merges. Finding titles, file paths and target names are blurred.

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.

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.
It does not open a Fix PR until a server-generated patch is bound to an exact approval.

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 candidates from independently verified findings, 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, independently verified, retest-confirmed, and inconclusive are separate states, not interchangeable labels.

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.

View free tools