// Methodology · LM-I-1.2

What we test, how, and what we won't claim.

Our profiles for internal apps, public websites and infrastructure reference relevant OWASP ASVS and WSTG controls, the OWASP Citizen Development risk taxonomy and the OWASP Top 10 for LLM Applications. These are references, not a claim of full standard conformance.

Coverage areas

InventoryOne target — internal app, public website or named infrastructure scope — with up to two roles and ten named flows

AuthenticationApproved accounts and session flows

AuthorizationRole, record and named-flow matrix

Business logicTen agreed workflows and expected outcomes

Web vulnerabilitiesForms, login flows, IDOR/BOLA and injection — only with reproducible, recorded evidence

Exposed configurationSecurity headers, TLS, DNS records, public storage buckets, CORS and secrets leaked in the shipped bundle — passive reads only

Infrastructure & networkNamed hosts and cloud accounts: exposed services, outdated software banners, storage and permission settings — with approved read access, no port sweeps

Known vulnerabilitiesSelected dependencies and code patterns, applicability reviewed

Source / dependenciesOptional immutable source revision; gaps disclosed if absent

Differential authorizationEvery agreed request replayed with each role and signed out; responses compared to the expected access matrix (record-level and function-level)

AI tool & assistant boundariesIn-app assistants and their tools: can a lower role trigger a privileged tool, leak the system prompt or read another user's data through the assistant?

How a check becomes a finding

1 · Scope & guardrails

Authorization, target type (app, site or infrastructure), roles, accounts and budgets validated before any request.

2 · Specialized modules

Differential authorization, AI tool boundaries, passive config & bundle audit, infrastructure exposure reads, workflow driving.

3 · Evidence verifier

A candidate issue becomes a finding only with a recorded request, response and successful replay. Otherwise: inconclusive.

4 · Liquid + human review

Liquid drafts the explanation and repair prompts; an analyst validates and a security lead signs the decision.

Rules of engagement

Staging only, synthetic data. Checks run only against the authorized staging URL and named test accounts, inside the agreed time window.
No volume, no brute force. No load tests, password guessing, port scans or blind fuzzing. Request rate and runtime are capped per engagement.
Reversible writes only. Any state change a check makes (e.g. an approval) is on synthetic records and reset after capture. Purchases, outbound messages and permission changes are excluded.
AI cost guardrail. Assistant probes have a fixed message budget so a review cannot run up your model bill.
Stop conditions. Real personal data, an unexpected production host or instability stops the run and is reported as blocked.

Every mandatory check gets one honest state

Completed with evidenceCompleted, no issue observedJustified not applicableBlockedInconclusiveNot tested

Human review

A qualified analyst validates every material finding. A security lead resolves high-impact or disputed readiness decisions. AI helps analyze and write, always grounded on recorded evidence. A note about an untested layer stays Not tested: it is not a finding and it cannot support a seal. Liquid's repair prompts are regression-tested against known-good fixes before release.

Limits

A passing scanner, a builder's security scan or a staging-only success does not prove access controls pass in production. Untested integrations, roles and production configuration are recorded explicitly. Skipping a material layer — identity, authorization, AI tool authority, business sequence, shared data, or integrations — cannot be described as a secure site. We never sample after seeing results to hide failures.