Quan un ha participat en més de dues-centes sessions de triatge d’anàlisi estàtic de seguretat (SAST), acaba desenvolupant un olfacte especial per distingir el soroll del senyal. No és que les eines no funcionin; ho fan, però no com prometen els fullets de màrqueting. La realitat és més matisada: aproximadament el 95% de les troballes són falsos positius o vulnerabilitats de baixa criticitat, i només el 5% restant mereix atenció urgent. Aquest article comparteix les lliçons apreses al llarg d’aquells processos, amb un enfocament pràctic per a equips que volen aprofitar el SAST sense enfonsar-se en el soroll.
La primera lliçó és que la majoria de les troballes repetitives provenen de patrons que l’eina no comprèn. Els wrappers de base de dades, els filtres d’autenticació o els motors de plantilles solen escapar a l’anàlisi estàtica, generant alertes massives d’injecció SQL o XSS que en realitat no existeixen. La solució no és ignorar-les, sinó escriure regles de supressió personalitzades. Invertir mig dia en una regla ben dissenyada pot eliminar centenars de falsos positius i retornar credibilitat al procés. Els equips que no fan aquest ajust acaben aclaparats, ignorant els informes i acumulant troballes fins que el backlog esdevé inmanejable.
El segon descobriment clau és que la cadència d’escaneig importa més que les regles. Quan el SAST s’executa de forma periòdica sobre tot el codi, l’informe arriba dies després i mostra milers de troballes històriques que ningú toca. En canvi, en integrar l’escaneig en el flux de treball —sobre cada pull request, analitzant només el canvi introduït— els desenvolupadors veuen dos o tres troballes en el seu codi acabat d’escriure, i les corregeixen immediatament. El mateix escàner, les mateixes regles, però el canvi de cadència transforma un informe il·legible en una eina accionable.
Després hi ha les troballes reals però que no mereixen bloquejar un llançament. Una injecció SQL en un script de prova, una clau hardcodejada en un fixture de tests unitaris, un path traversal en una eina d’administració local. Són reals, però el seu context operatiu les fa irrellevants: dades sintètiques, entorns aïllats, accés només intern. Els equips que no desenvolupen un vocabulari per expressar “real però no important” acaben arreglant-ho tot (car i lent) o ignorant-ho tot (perillós). L’alternativa funcional és l’acceptació documentada del risc amb controls compensatoris: es reconeix la troballa, es captura el motiu pel qual no es corregeix, es documenta el control i s’estableix una data de reavaluació.
El 5% que realment importa es concentra en poques categories: bretxes d’autorització (el control d’accés falta o és incorrecte), referències directes a objectes (IDs enumerables sense verificació de permisos), errors criptogràfics (claus hardcodejades, hash febles), injeccions en patrons evidents (SQL concatenat, ordres del sistema) i divulgació d’informació en manejadors d’errors. Aquestes són les vulnerabilitats que mereixen aturar un release. Però fins i tot aquí, la priorització s’ha de basar en el context: una mateixa vulnerabilitat amb idèntica puntuació CVSS pot tenir un risc real molt diferent segons si el codi arriba a dades sensibles o està exposat a trànsit extern.
El més difícil d’aprendre és el que l’escàner no veu. El SAST no detecta fallades de lògica de negoci (un codi de descompte reutilitzable, una escalada de privilegis mitjançant una seqüència de crides legítimes), ni vulnerabilitats arquitectòniques (un microservei que assumeix que el trànsit intern és segur, un flux de dades que exposa PHI a logs no dissenyats per a això). Tampoc capta riscos que depenen del context de desplegament: un SSRF només explotable en un entorn cloud concret, o un problema de compliment normatiu que sorgeix en canviar de jurisdicció. Recordo un cas on un producte funcionava correctament als Estats Units, però en preparar el seu llançament a Europa l’anàlisi de compliment va revelar que els logs contenien camps considerats dades protegides segons la normativa europea. L’escàner mai ho va detectar perquè el concepte de “dada sensible” no és una propietat del codi, sinó del lloc on s’executa i la llei aplicable.
Per a una empresa de desenvolupament de programari com Q2BSTUDIO, aquestes lliçons es tradueixen en pràctiques concretes. Quan ajudem els nostres clients a construir aplicacions a mida, integrem el SAST al pipeline de CI/CD des del primer dia, amb la cadència i l’abast adequats perquè els desenvolupadors actuïn sobre les troballes reals. Distribuïm les regles de supressió personalitzades i documentem el context operatiu de cada vulnerabilitat, evitant la paràlisi per anàlisi. A més, combinem l’anàlisi estàtica amb proves dinàmiques i revisions d’arquitectura per cobrir el que el SAST no veu: fallades de lògica, riscos de compliment i problemes de configuració en entorns cloud com AWS o Azure. El nostre equip de ciberseguretat realitza auditories completes que inclouen pentesting i revisió de polítiques de seguretat, mentre que les nostres solucions de BI i Power BI ajuden a monitoritzar mètriques de seguretat i a visualitzar l’estat de les troballes. També estem explorant l’ús d’agents d’IA per automatitzar el triatge preliminar, classificant troballes per context i reduint encara més el soroll.
En resum, el SAST és una eina valuosa, però no és el programa de seguretat en si mateix. L’experiència de centenars de triatges ens ensenya que la clau està en el judici humà: saber què ignorar, què prioritzar i quines preguntes fer quan l’escàner reporta zero troballes. Perquè, com hem vist, les sorpreses més costoses no provenen del que l’escàner troba, sinó del que no està configurat per buscar. Invertir en el flux de treball, en la personalització de regles i en la comprensió del context operatiu és el que separa un programa de seguretat efectiu d’un generador de soroll.
