Il repository è attualmente privato. Questo documento è predisposto per quando diventerà pubblico.

Pratix è in sviluppo attivo. Solo l'ultima versione rilasciata riceve fix di sicurezza.

Se scopri una vulnerabilità in Pratix:

1. Non aprire una issue pubblica.
2. Scrivi in privato al manutentore con:
   • una descrizione del problema,
   • i passi per riprodurlo,
   • l'impatto stimato,
   • eventuale proof-of-concept.
3. Riceverai conferma di lettura entro pochi giorni.
4. Concorderemo una finestra di disclosure responsabile prima di rendere pubblico il dettaglio.

Sono in scope:

• Esposizione di dati personali o di clienti (P.IVA, anagrafica, fatture).
• Bypass di autenticazione o di Row-Level Security su tabelle utente.
• Iniezione SQL, XSS, CSRF, SSRF.
• Vulnerabilità nelle dipendenze npm a impatto reale sull'app.
• Errori che permettano enumerazione utenti (es. messaggi auth grezzi).

Sono fuori scope:

• Vulnerabilità in servizi terzi (Supabase, Vercel, provider DNS): segnalarle ai rispettivi vendor.
• Attacchi di forza bruta non mitigabili a livello applicativo.
• Bug di UI senza impatto sui dati.

• Row-Level Security obbligatoria su tutte le tabelle con dati utente.
• Ruoli mai memorizzati su profiles: tabella user_roles separata.
• Nessun secret in repo: tutte le chiavi sensibili vivono in Vercel/Supabase.
• Messaggi di errore di autenticazione generici (no user enumeration).
• npm audit --audit-level=moderate periodico.
• Scan di sicurezza Supabase eseguiti regolarmente.

Vedi anche docs/guides/database.md per il dettaglio sulle policy RLS.

• Rischio iniziale: alto (bloccante).
• Stato in questa ondata: P0 da chiudere subito, con P1/P2 dopo.
• Rotazione segreti: esclusa in questa fase (espressamente non parte del piano).

• Rimuovere subito qualsiasi file .env tracciato in repository e verificare la storia Git (git log/git show) per eventuali esposizioni pregresse.
• Confermare che chiavi server-side, token provider e segreti di runtime non compaiano in commit, template o documentazione condivisa.
• Attivare guardrail pre-merge/CI per scan automatici:
  • secret scanning;
  • blocco file .env e pattern segreti.

• Bloccare pattern sensibili in .env.example, guide operative e snippet di onboarding.
• Rafforzare guardrail CI/pre-commit per log e payload sensibili:
  • rimuovere pattern PII/segreti dai log;
  • evitare commit di configurazioni operative residue.
• Tenere i piani RLS e accessi Supabase sotto revisione con check dedicato.

• Audit periodici su:
  • accessi amministrativi;
  • utilizzo token runtime;
  • policy RLS e regressioni autorizzative.
• Inserire revisione di rischio nel ciclo operativo.

• Per Pratix: non aprire nuovi interventi funzionali prima della chiusura completa di P0 e P1.
• Obiettivo operativo:
  • 0 hit in secret scan;
  • 0 file .env tracciati;
  • 0 credenziali in log.