¿Cómo empezar a revisar el código a nivel de seguridad con nuestro propio equipo antes de salir a producción?

En la parte de automatización, el escaneo de dependencias es tan crítico como el análisis estático. Instalen verificadores de dependencias open source que comprueben en tiempo de compilación las vulnerabilidades conocidas de las librerías externas que usan. Además, para evitar fallos de autorización, exijan pruebas unitarias y de integración que revisen la lógica de negocio en el código; el código no debería pasar sin probar que el ID de usuario coincida con el objeto de datos.

Si en un equipo de cuatro personas le encargas el control de seguridad a una sola, esa persona se convierte en un cuello de botella en poco tiempo. Hagan que la revisión sea una responsabilidad compartida y no un castigo o mecanismo de aprobación. Apliquen la regla de los dos pares de ojos en cada pull request; que no sea el creador del código, sino el revisor quien marque los puntos de seguridad uno a uno. Una simple checklist ya atrapa la mayoría de los errores en el entorno de desarrollo.

Ed: ya se preguntó abajo, dejé la respuesta en el segundo mensaje.

El paso más práctico con el que pueden empezar mañana mismo es agregar una sección de seguridad a su plantilla de pull request. Que el desarrollador tenga que marcar las casillas 'Validé la entrada del usuario' y 'Agregué control de permisos' antes de enviar el código. Estas dos preguntas obligan al programador a parar a pensar antes de mandar nada.

en nuestro equipo paso algo parecido nos habiamos qumado por culpa de librerias externas. conectamos herramientas de escaneo open source gratis al repo y si encuentra un fallo te bloquea el merge. al principio todos se quejaban pro en dos semanas nos acostumbramos, un alivio total.

El año pasado pasamos por un proceso similar. Tras implementar el análisis estático automatizado y la checklist en los pull requests, en la auditoría de seguridad independiente seis meses después, el número de hallazgos críticos bajó a cero. El tiempo de revisión solo se extendió unos 12 minutos promedio por pull request. Esos 12 minutos nos ahorraron miles de dólares en costos de parches de emergencia.

¿El salto de autorización que salió en el informe de pentest de su cliente ocurrió exactamente en la capa de la API o a nivel de consulta de base de datos? Si no hay una capa de autorización centralizada en los endpoints de la API, escribir controles uno a uno dentro de cada función volverá a generar fallos más adelante. ¿Tienen un control centralizado de identidad y acceso en su arquitectura?

No confíen demasiado en los escáneres automáticos. Las herramientas de análisis estático detectan bien las vulnerabilidades de librerías o fallos simples de SQL, pero jamás van a ver errores de lógica de negocio como el salto de autorización que tuvieron. A menos que alguien haga la prueba lógica mirando el código de si 'el usuario A puede ver la factura del usuario B', ningún software automático los va a salvar de ese informe.

Resumiendo, el roadmap es claro: 1) Integren herramientas automáticas gratuitas al repo para escanear dependencias y fallos básicos, 2) Pongan un requisito de revisión de 5 puntos centrado en autorización y validación de datos en los pull requests, 3) Dejen los controles de lógica de negocio en manos de la revisión manual de los dev software. No hacen falta grandes presupuestos, alcanza con disciplina.

Me pasó lo mismo.

En su momento, nosotros también nos atascamos ahí. Al tomar decisiones, escribe también el peor escenario no solo el mejor.

También me gustaría saber si alguien lo hace de otra manera.

Muchas gracias, lo probaré hoy.

Guardado.

Estoy totalmente de acuerdo. Tomar medidas sin hacer inventario es dejar abierta una puerta que no ves.

Lo que más tiempo nos hacía perder era no saber quién tomaba las decisiones.

Lo escribo para que no cometan el mismo error. Una copia de seguridad no probada no es una copia de seguridad.

El tiempo que tardas en detectar un problema determina directamente su coste. También me gustaría saber si alguien lo hace de otra manera.

Hay un error muy común al hacer esto. La mayor parte de la pérdida de tiempo se acumula en los trabajos pendientes de aprobación.

Esta es mi opinión, no lo escribo como una verdad absoluta.

Soy una pequeña empresa, os lo cuento desde mi lado. Que todo el mundo haga algo no significa que sea lo correcto.

No tengáis miedo de preguntar, quien no pregunta siempre paga más caro.

me han quedado claars las dudas gracias.

Hay algo que no entiendo. Si es la primera vez que lo hacéis, empezad poco a poco la escala llegará después.

Una copia de seguridad no probada no es una copia de seguridad. Yo seguiría por ese camino.