Fiducia e metodo

Fatto per meritarsi la tua superficie d'attacco

Uno strumento di sicurezza deve imporsi standard più alti. Ecco esattamente come VICE separa scansioni pubbliche, audit verificati e remediation, e cosa non farà mai.

01Public light scan02DNS verification03Deep audit unlocked

La proprietà prima dei controlli intrusivi

I visitatori anonimi ottengono solo controlli passivi e pubblici. L'audit profondo si sblocca quando un record DNS TXT dimostra che il dominio è tuo.

TXT · _vice-verify.acme.devRLSAUTHSTORAGE

La prova resta allegata

I finding conservano la prova grezza accanto al contesto di remediation, così puoi verificare ogni affermazione del report.

$ GET acme.dev/.env200 OK# .env · productionDATABASE_URL=••••••••••••STRIPE_SECRET_KEY=sk_live_51H…SUPABASE_SERVICE_ROLE=••••••RESEND_API_KEY=••••••••

Isolato by design

Webba ID gestisce l'identità e la row level security isola ogni workspace al suo proprietario. Controlliamo RLS di mestiere: le nostre devono essere esemplari.

acme.devAUDITSFINDINGSMODULESSCHEDULES

Remediation esplicita

I prompt AI Fix, gli stati risolti e i reset dello storico sono azioni deliberate che attivi tu, mai qualcosa che muta i tuoi dati in silenzio.

-- ai fix · missing-rls-policy
- grant select on public.users to anon;
+ alter table public.users
+ enable row level security;
+ create policy "own rows" on public.users
+ for select using (auth.uid() = id);

Cosa copre un audit completo

Controlli black-box dall'esterno, white-box dal tuo repo. Entrambi alimentano un unico punteggio.

security headerTLS e HSTSflag dei cookiepolicy CORSanalisi CSP.env e config espostisecret trapelati nel JSelenchi di directory apertirobots e security.txtpolicy RLS di Supabaseesposizione dei bucket di storagedebolezze nei flussi di authdipendenze vulnerabilisicurezza dei workflow CIfughe nello storico git

Risorse