Heredamos el código de una agencia: ¿cómo hacer una revisión de código segura y por dónde empezar?

Su primer paso urgente debe ser limpiar el historial de Git. Aunque borren la contraseña del archivo de código y hagan un nuevo commit, esas credenciales quedarán abiertas para siempre en el historial de Git. Escaneen todo el historial de commits con herramientas de detección de secretos open source, reescriban el historial para limpiar las claves y cambien esas contraseñas en los servidores inmediatamente.

Mañana mismo su desarrollador debería ejecutar el comando de auditoría de seguridad local del gestor de paquetes. Dentro de esas librerías de hace dos años probablemente haya docenas de boletines de seguridad críticos publicados. El solo hecho de actualizar los paquetes a versiones estables y recientes eliminará la mitad de su riesgo al instante.

Nosotros también ejecutamos un análisis estático de código el año pasado en un proyecto de 30 mil líneas que heredamos. El sistema arrojó 142 alertas potenciales; cuando nuestro desarrollador las revisó, vio que 8 de ellas eran fallos reales que podían provocar fugas directas en la base de datos. Solucionar esos 8 fallos solo nos tomó tres días.

No confíen demasiado en las herramientas de análisis automático; se pueden ahogar entre cientos de falsos positivos en informes de miles de líneas. Las mayores filtraciones de datos no vienen de vulnerabilidades en librerías, sino de errores simples en el control de sesiones que el programador de la agencia omitió pensando "total nadie lo va a probar". Denle prioridad a las pruebas de lógica manuales.

si la agencia metio las contraseñas a piñón en el codigo seguro ni miro la parte de subir archivos. prueben urgente si se pueden subir archivos php ejecutables cuando el cliente sube documentos esa es la puerta mas peligrosa.

Registren los hallazgos detectados en una matriz de riesgo de seguridad corporativa. Clasifiquen las vulnerabilidades como críticas, altas y medias. Si no se solucionan los fallos críticos que amenazan directamente la base de datos y la privacidad de los clientes, mantener el sistema activo en producción para los usuarios puede generar responsabilidades legales graves.

Revisen de nuevo el contrato que firmaron con la agencia. En la mayoría de los contratos hay una cláusula de garantía, explícita o implícita, que establece que el código se entregará conforme a los estándares del sector y las prácticas básicas de seguridad. Dejar contraseñas hardcodeadas en el código es claramente un servicio defectuoso; podrían tener derecho a enviar una notificación formal a la agencia para que lo corrijan.

¿Cómo analizan el código las herramientas de revisión estática sin ejecutarlo? ¿De qué manera exacta pueden entender estas herramientas que una función tiene una vulnerabilidad sin instalar nada en el servidor de producción y sin conectarse a la base de datos?

No tengo ninguna experiencia en revisión de código segura, por eso pregunto. Los primeros tres meses todo va bien, los problemas aparecen en el cuarto.

Empezad con una pequeña prueba, no lo integréis todo de golpe. Si tenéis dudas, escribid, os responderé en la medida de lo posible.

yo también tenog curiosidad.

Este enfoque tiene un coste, y no se habla de ello. Si la verificación en dos pasos está activa, una contraseña robada no sirve de nada por sí sola.

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

Yo también estaba pensando en lo mismo. Un informe de escaneo automático no es lo mismo que una prueba de penetración.

Yo seguiría por ese camino.

Me pasó lo mismo. Si decidimos sin medir, siempre acabamos en el mismo punto.

Eso es todo, disculpa si me he extendido demasiado.

Yo también estaba pensando en lo mismo. Si la verificación en dos pasos está activa, una contraseña robada no sirve de nada por sí sola.

Las soluciones que funcionan a pequeña escala se rompen al crecer, aprendí esto tarde. Lo dejo como nota, por si sirve.

hay tres cosas que revisar al hacer esto. la gente no definde el proceso defiende la costumbre. la resistencia viene de ahí.

Estoy en la misma situación, por eso pregunto. en fin si el permiso y el alcance no están por escrito, que no empiece la prueba.

Ningún proceso mejora si no se registran datos, porque no sabes qué tienes que arreglar... pues esta es mi opinión, no lo escribo como una verdad absoluta.

A mí me pasó justo al revés, por eso escribo. El error cometido por revisión de código segura suele ser reversible, pero caro.

Si el camino de la notificación es largo, la notificación no llega; una notificación que no llega significa un incidente detectado tarde.

Me han quedado claras las dudas, gracias. El tiempo que tardas en detectar un problema determina directamente su coste.

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