Intentamos revisar la seguridad de nuestro propio código y nos trabamos: ¿cuáles son las trampas más comunes?

Configura bien la opción de 'taint analysis' (rastreo de datos no confiables) en los analizadores estáticos. Sigue el rastro del parámetro introducido por el usuario hasta ver si se sanitiza antes de llegar a la BD o a un comando del sistema. Si apagas las reglas que marcan cualquier concatenación de cadenas como inyección SQL, te limpias al menos dos tercios de las alertas al instante.

Hacer que un desarrollador sin formación en seguridad revise su propio código es un mero trámite. Quien escribe el código no ve sus propios errores de diseño. Si el presupuesto es ajustado, contratar una auditoría externa enfocada de 2 o 3 días solo para los módulos de autenticación y pagos es mucho más barato y efectivo que intentar cubrir todo el sistema.

No volváis a cometer el error de revisar 12.000 líneas de golpe. Dividid la revisión de seguridad en pull requests. Que no haya más de 300 líneas por merge y que la lista de verificación solo tenga 5 puntos críticos de seguridad. Que lo miren mientras se escribe el código, no cuando el sprint se esté acabando.

En nuestro primer escaneo nos salieron 410 alertas. Estuvimos dos semanas dándonos de cabezazos todo el equipo. Luego configuramos el filtro de seguridad solo para las 10 vulnerabilidades web más críticas y la cifra bajó de golpe a 19. De esos 19 hallazgos, solo 4 representaban un riesgo real que de verdad había que corregir.

las herramientas de automatizacion no saben lo q hace el codigo solo buscan patrones. si en las consultas a la bd usas librerias parametrizadas ya eliminas de cajon la mayoria del riesgo de sql injection, no te obsesiones con cada alerta de la herramienta.

En nuestro primer producto nos tiramos días discutiendo reglas complejas de validación con regex y nos celebramos haber hecho una revisión de código segura. Al tercer día de salir a producción, un cliente cambió el id en el parámetro de la url y se bajó los estados financieros de otra empresa. Eso es exactamente el tipo de error de lógica que las herramientas no ven.

Caéis en tres trampas clásicas: 1) Tomar el reporte de la herramienta como verdad absoluta y perder horas en falsos positivos, 2) Hacer que la revisión de seguridad parezca una evaluación de desempeño del dev generando una reacción defensiva, 3) Confundir el estilo de código con una vulnerabilidad de seguridad.

El resumen de lo hablado es este: subid el umbral de alerta de los escáneres automáticos para reducir el ruido, dividid la revisión en partes pequeñas y probad manualmente con escenarios los fallos de lógica de autorización que las herramientas no van a detectar.

yo también estaba pensando en lo mismo. si decidimos sin medir siempre acabamos en el mismo punto.

todo lo que no está por escrito, ambas partes lo recordarán de forma distintta en el futuro. bueno lo dejo como nota, por si sirve.

A mí me pasó justo al revés, por eso escribo. La seguridad no es absoluta; significa hacer que el ataque no merezca la pena.

Por supuesto, cambia si tu situación es diferente.

estoy de acuerdo.

Resumen breve para nuevos usuarios: Los cambios en los datos de pago nunca se verifican por el mismo canal por el que llegan.

La seguridad no es absoluta; significa hacer que el ataque no merezca la pena. Ánimo.

A nosotros nos pasó esto. Una copia de seguridad no probada no es una copia de seguridad.

Si escribís el resultado aquí, también servirá de ayuda a otros.

Tienes razón, yo también pasé por lo mismo. La gente no defiende el proceso, defiende la costumbre. La resistencia viene de ahí.

Ánimo.

Estoy totalmente de acuerdo. Al tomar decisiones, escribe también el peor escenario, no solo el mejor.

Si tenéis dudas, escribid, os responderé en la medida de lo posible.

Voy a resumir el tema, porque se han dado varias respuestas diferentes. La gente no defiende el proceso, defiende la costumbre. La resistencia viene de ahí.

estoy en la misma situación por eso pregunto. la verdad si es la primera vez que lo hacéis empezad poco a poco la escala llegará después.

si regañas las falsas alarmas, nadie volerá a reportar... esta es mi opinión, no lo escribo como una verdad absoluta.

No te olvides de: La mayor parte de la pérdida de tiempo se acumula en los trabajos pendientes de aprobación.

Empezad con una pequeña prueba no lo integréis todo de golpe. Ánimo.