OWASP y la cadena de suministro

El Top 10 es un documento de concienciación: reúne en diez categorías los riesgos de seguridad más críticos de las aplicaciones web, a partir de datos de vulnerabilidades que aportan empresas y de una encuesta a profesionales. Se actualiza periódicamente para reflejar cómo cambian los ataques.

En sus ediciones recientes, el primer puesto es el control de acceso roto (broken access control): usuarios que pueden ver o modificar lo que no deberían, casi siempre porque falta una comprobación en el servidor. Otras categorías habituales son las inyecciones, los fallos de configuración, los de criptografía, los de autenticación y los de los componentes de terceros.

El ASVS (Application Security Verification Standard) es un catálogo de requisitos concretos y comprobables, agrupados por áreas: autenticación, sesiones, control de acceso, validación, criptografía, registros y más. Cada requisito se puede verificar con una prueba, una revisión de código o una auditoría.

Tiene tres niveles. El 1 es el mínimo para cualquier aplicación. El 2 es el recomendado para la mayoría de las que manejan datos sensibles. El 3 es para las críticas, como banca, salud o infraestructuras, y exige la verificación más profunda.

SAMM (Software Assurance Maturity Model) no evalúa una aplicación, sino el programa de seguridad de una organización: cómo incorpora la seguridad en todo el ciclo de vida del software. Se organiza en cinco funciones (gobierno, diseño, implementación, verificación y operaciones), cada una con varias prácticas.

Para cada práctica, un cuestionario te da un nivel de madurez de 1 a 3. Con esa foto fijas un objetivo realista y un plan: por ejemplo, pasar de no hacer análisis de amenazas a hacerlo en los proyectos nuevos durante el próximo año.

Los ataques más comunes son tres. El typosquatting: publicar un paquete con un nombre casi idéntico a uno popular, como pasó en 2017 con crossenv, que imitaba a cross-env y robaba variables de entorno. La cuenta robada: alguien se hace con la cuenta de un mantenedor y publica una versión maliciosa. Y los scripts de instalación, que ejecutan código en tu máquina o en tu CI con solo instalar el paquete.

Las defensas básicas: sube el lockfile al repositorio y usa npm ci en el pipeline, que instala exactamente las versiones revisadas y falla si no cuadran con package.json. Ejecuta npm audit para detectar vulnerabilidades conocidas y deja que una herramienta como Dependabot o Renovate proponga las actualizaciones. pnpm, en sus versiones recientes, ya no ejecuta por defecto los scripts de instalación de las dependencias.

La procedencia (provenance) es una declaración firmada que dice de qué repositorio, de qué commit y en qué pipeline se construyó un paquete o una imagen. Si alguien publica una versión desde un portátil robado, no tendrá una procedencia válida. npm la genera con npm publish --provenance desde un CI compatible y la muestra en la página de cada paquete.

Sigstore es el proyecto abierto que hace posible firmar sin gestionar claves: firmas con tu identidad (la de tu pipeline, por ejemplo), recibes un certificado de corta duración y la firma queda en un registro público de transparencia. Su herramienta cosign firma imágenes de contenedor.

SLSA (se pronuncia «salsa») es un marco que define niveles crecientes de garantías para el proceso de build: desde que exista procedencia hasta que se genere en una plataforma endurecida, de forma que no se pueda falsificar.

Un SBOM (Software Bill of Materials) es un inventario de todos los componentes de tu software, incluidas las dependencias de tus dependencias, con su versión, su licencia y un identificador estándar. Se genera de forma automática en el pipeline y se guarda junto a cada versión que publicas.

Su valor se ve el día de la crisis. Cuando en 2021 apareció Log4Shell, una vulnerabilidad gravísima en la librería de registros Log4j, muchas empresas tardaron semanas en saber qué sistemas la usaban. Con un SBOM de cada servicio, la respuesta es una búsqueda. Los dos formatos principales son CycloneDX, de OWASP, y SPDX, de la Linux Foundation.

El SAST (Static Application Security Testing) lee el código fuente sin ejecutarlo y busca patrones peligrosos, como una consulta SQL montada concatenando texto. Encuentra fallos pronto, en cada pull request, pero da falsos positivos.

El DAST (Dynamic Application Security Testing) ataca la aplicación en marcha desde fuera, como haría un atacante, con herramientas como ZAP. Encuentra problemas reales, como cabeceras que faltan o configuraciones inseguras, pero solo cuando ya hay algo desplegado. El SCA (Software Composition Analysis) revisa tus dependencias contra las bases de datos de vulnerabilidades: es lo que hacen npm audit o Dependabot.

SonarQube analiza el código de muchos lenguajes y señala errores probables, código difícil de mantener, vulnerabilidades y security hotspots: fragmentos que tocan algo sensible, como la configuración de una cookie o una expresión regular, y que una persona debe revisar para decidir si son un problema. En el módulo de testing lo verás desde el lado de la calidad.

Su pieza clave es el quality gate: un conjunto de condiciones que cada análisis debe cumplir, como no introducir vulnerabilidades nuevas o cubrir con pruebas un porcentaje del código nuevo. Si no se cumple, el pipeline falla y el cambio no se fusiona. Se centra en el código nuevo, así que la deuda antigua no bloquea al equipo.

Existe en versión instalable, con una edición gratuita y otras de pago, y como servicio en la nube, SonarQube Cloud. Su extensión para el editor avisa de los problemas mientras escribes.