Tre strumenti di sicurezza, tre report, una sola decisione
SAST, DAST e SCA vedono ognuno uno strato. Un agente in GitLab CI li legge insieme a ogni build e dice cosa blocca il rilascio, e perché.
DOMANDE VERIFICABILI / PROVE RIPRODUCIBILI
Misuro software in produzione con prove che puoi rifare
Definisco prima condizioni e soglie. Metto alla prova le ipotesi, confronto spiegazioni alternative e dichiaro ciò che i dati non dimostrano.
Come verifico una misura →IL PROTOCOLLO
- 01DomandaQuale decisione deve cambiare?
- 02IpotesiChe cosa potrebbe smentirla?
- 03ProvaCondizioni e soglie prima dei risultati
- 04VerificaRipetizione, alternative e limiti
SERVIZI / MISURE
Risultati misurati sul lavoro svolto
01Scraping e analisi dati su misuraDati affidabili da fonti che non hanno un'API.2.393PRODOTTI VERIFICATIControllo esterno di un catalogo reale02Stress test e test di carico applicativiSapere a che carico cede, e con quale sintomo.3GET/s10 MINUTI SOSTENUTIp95 1,102 s su un VPS isolato03DevSecOps frazionato: analisi di sicurezza del tuo softwareUn ingegnere della sicurezza qualche giorno al mese, senza assumerlo.3LIVELLI DI ANALISICodice, applicazione in esecuzione, componenti04Performance front-end e Core Web Vitals misuratiIl verde su PageSpeed e la lentezza che vedono i clienti convivono benissimo.33%TTFB IN MENODa 954 a 636 ms all’origine, su desktop
UN’IPOTESI SMENTITA DAI LOG
Il referto completo →Ipotesi: il codice dell’import causava gli errori 500. Quattro log di livelli diversi hanno invece mostrato che l’hosting interrompeva i processi PHP.
101 errori 500106 chiamate riuscite
METODO SCIENTIFICO, IN PRATICA
La soglia si decide prima di vedere il risultato
Nel test di carico ho fissato carico, condizioni e criteri di fallimento prima della prova. Il risultato conta solo insieme al protocollo che lo ha prodotto.
PROTOCOLLO DI CARICO01/04
- 01Domanda: quale risorsa satura per prima?
- 02Controllo: origine isolata, CDN esclusa, frequenza fissa
- 03Soglie: p95 sotto 3 s, errori sotto 1%, zero iterazioni perse
- 04Limiti: nessun checkout, nessuna prova sul server attuale
Lavoro su software che gira già, quando c’è una domanda a cui il monitoraggio non risponde. La formulo in modo che una prova possa smentire la prima spiegazione. Prima della misura stabilisco ambiente, campione e soglia; dopo controllo se i dati reggono anche a una lettura alternativa.
Su un import notturno la spiegazione iniziale era un difetto nel codice. Quattro log di livelli diversi l’hanno smentita: l’hosting interrompeva i processi PHP. In un test di carico ho invece fissato prima il limite di latenza e il tasso massimo di errori; a 6 richieste al secondo la latenza ha superato la soglia. Sono due problemi diversi, ma il metodo è lo stesso.
Consegno i numeri insieme al protocollo, ai comandi per ripeterlo e a un elenco esplicito di cosa non è stato misurato. Se un numero non ti convince, lo rifai tu.
Su cosa lavoro
Performance e Core Web Vitals, misurati sui browser dei tuoi utenti e non solo in laboratorio. Test di carico, con l’autorizzazione scritta prima del primo colpo. DevSecOps in forma frazionata: analisi del tuo software con SAST, DAST e SBOM, controlli in pipeline che dimostrano di saper fallire, qualche giorno al mese. Estrazione e analisi di dati da fonti che non hanno un’API.
Da dove vengo
Trent’anni fra clienti e team tecnici, gli ultimi da CTO di una software house B2B e da co-fondatore di Dfence, un servizio di vulnerability assessment continuo che girava su circa 100 appliance presso i clienti. Ho avuto la responsabilità delle conseguenze: checkout lenti, import che si rompono, finding di sicurezza che arrivano nel momento sbagliato. Oggi porto quel giudizio su un problema alla volta.
PARTIAMO DAI FATTI
Una misura utile cambia una decisione.
Raccontami quale domanda il monitoraggio non riesce a risolvere.