Los clientes endurecen el DevSecOps: auditan a los contratistas en cada paso de la compilación

En diciembre de 2020, la actualización troyanizada de SolarWinds Orion llegó a unos 18 000 clientes de la compañía. Aquel episodio hizo que el sector volviera a entender que lo vulnerable puede no ser el producto, sino el camino por el que llega al cliente. El mercado ruso llega a la misma conclusión. Según un artículo de TAdviser, los clientes avanzan cada vez más hacia la confianza cero con sus contratistas de TI y exigen una «cadena estéril» de desarrollo con revisión de código repetida. La base de este enfoque es DevSecOps, un ciclo de creación de software en el que la seguridad está incorporada en cada etapa y no se añade justo antes del lanzamiento.

De dónde surge la desconfianza

El modelo clásico era sencillo. El contratista escribe el código, entrega la compilación y el cliente realiza la aceptación. Todo lo que ocurre dentro del contratista sigue siendo una caja negra. Pero un contratista son los portátiles de los desarrolladores, las bibliotecas de terceros, los repositorios en la nube y los sistemas de CI, y cualquiera de estos elementos puede verse comprometido.

Los ejemplos son conocidos. La vulnerabilidad Log4Shell, a finales de 2021, mostró cómo una sola biblioteca de registro acaba en miles de productos cuyos propietarios ni siquiera lo sospechan. La puerta trasera en el archivador XZ Utils (CVE-2024-3094), descubierta en 2024, se introdujo mediante una larga operación de ingeniería social contra el responsable del mantenimiento del proyecto. El principio de confianza cero, formalizado en NIST SP 800-207, establece que hay que verificar a cada participante y cada acción. Ahora se aplica al desarrollo.

Cómo es la «cadena estéril»

El artículo de TAdviser habla de una tendencia, no de un estándar único, así que el conjunto de medidas varía según el cliente. Un circuito típico incluye:

• un entorno de compilación aislado, sin acceso a internet y con un conjunto limitado de dependencias externas;
• análisis estático de código (SAST) en cada commit y análisis dinámico (DAST) en los entornos de pruebas;
• análisis de composición (SCA): inventario de componentes de terceros y búsqueda de vulnerabilidades conocidas;
• SBOM, la lista de todos los componentes de la compilación, como artefacto obligatorio de la entrega;
• escaneo de repositorios en busca de secretos: claves, tokens, contraseñas;
• revisión de código obligatoria por una segunda persona y firma de los artefactos compilados;
• nueva verificación de los códigos fuente y de la compilación en el lado del cliente.

La palabra clave aquí es «repetida». El mismo código se analiza en el contratista, después en el cliente y, a veces, también en un laboratorio independiente. Cada capa detecta lo que la anterior dejó pasar. Y parte de la premisa de que la anterior pudo haber sido comprometida.

El precio para el contratista

Para el contratista, esto supone mayores costes y una reorganización de procesos. Hacen falta circuitos de compilación dedicados, licencias de herramientas de análisis, especialistas en desarrollo seguro y una disciplina de la que los equipos pequeños suelen carecer. Salen ganando los integradores maduros, que ya tienen DevSecOps integrado en la producción. Los estudios pequeños tendrán que ponerse al nivel o pasarse a segmentos con requisitos menos estrictos.

Hay también un reverso. Las revisiones repetidas ralentizan los lanzamientos, y una parte de las alertas de los analizadores resulta ser falsa y, si no se revisa, se convierte en ruido. El cliente que se excede con el control acaba pagándolo en plazos.

Por dónde empezar

Al cliente le conviene fijar en el contrato los requisitos de desarrollo seguro: formato de SBOM, frecuencia de escaneo, derecho de auditoría y procedimiento de respuesta ante las vulnerabilidades detectadas. Es razonable clasificar a los contratistas según la criticidad de los sistemas y no aplicar el máximo control por igual en todas partes.

Al contratista le conviene empezar por lo pequeño: incluir el escaneo de secretos y dependencias en el CI existente, establecer la revisión obligatoria y aprender a generar el SBOM de forma automática. Estos pasos son más baratos que los demás y resuelven de inmediato las principales dudas de los auditores. Quien se prepare antes de que el requisito aparezca en una licitación tendrá ventaja sobre quien empiece después.