DevSecOps: cómo incorporar seguridad al desarrollo de software

Una vulnerabilidad detectada después de lanzar una aplicación obliga a rehacer código, retrasar funciones planificadas y, en sectores regulados, explicar el hallazgo a clientes o supervisores. Cuanto más tarde aparece un problema de seguridad en el ciclo de desarrollo, más tiempo, dinero y reputación cuesta corregirlo.

DevSecOps propone integrar la seguridad en cada etapa del ciclo de desarrollo, desde el diseño hasta el mantenimiento. Para la gerencia general y los responsables de comprar o encargar software, la pregunta útil es qué prácticas pedir, qué evidencias exigir y cómo saber si el equipo interno o el proveedor las aplica.

Un marco común para equipos y compradores

El Marco de Desarrollo de Software Seguro del NIST (SSDF, SP 800-218 versión 1.1, 2022) reúne prácticas de alto nivel que pueden integrarse en cualquier metodología de desarrollo. NIST señala que su objetivo es reducir las vulnerabilidades en el software publicado, mitigar el impacto de las que no se detecten y atacar sus causas para evitar que se repitan. También lo presenta como un vocabulario común que compradores y clientes pueden usar al tratar con sus proveedores.

El SSDF organiza las prácticas en cuatro grupos: preparar a la organización, proteger el software, producir software bien asegurado y responder a las vulnerabilidades. Esa estructura sirve a la dirección para revisar si el programa de desarrollo cubre todo el ciclo o solo una parte.

Qué cambia en cada etapa del ciclo

En el diseño, el equipo identifica qué datos maneja la aplicación, quién debería acceder a ellos y qué podría salir mal. Ese análisis de amenazas permite decidir controles antes de escribir código, cuando cambiarlos cuesta menos.

En la construcción, las revisiones de código y las herramientas automáticas buscan errores comunes en cada cambio. El equipo también controla los componentes de terceros que incorpora, porque una biblioteca vulnerable traslada su riesgo a la aplicación completa. Un inventario de componentes, conocido como lista de materiales de software (SBOM), permite saber qué contiene cada versión.

En las pruebas, la aplicación se evalúa con escenarios de abuso además de los funcionales: qué ocurre si un usuario modifica una solicitud, si intenta acceder a datos de otro o si envía información inesperada. Antes de lanzamientos importantes, una prueba de penetración aporta una mirada independiente.

En la operación y el mantenimiento, el equipo necesita un proceso para recibir reportes de vulnerabilidades, priorizarlas, corregirlas y comunicar las actualizaciones. Esta etapa determina cuánto tiempo permanece expuesto un error ya descubierto.

Las responsabilidades se reparten entre áreas

DevSecOps distribuye la seguridad entre todas las áreas que participan en el software. Desarrollo aplica las prácticas en su trabajo diario; seguridad define criterios, entrega herramientas y acompaña los casos complejos; operaciones vigila el comportamiento en producción; producto equilibra plazos y riesgos.

La dirección tiene un papel concreto: asignar tiempo en la planificación para corregir hallazgos, definir qué nivel de riesgo puede aceptarse antes de un lanzamiento y quién lo aprueba. Sin esa decisión, la presión por entregar funciones nuevas suele desplazar las correcciones.

Evidencias que una empresa puede solicitar

Cuando el software lo desarrolla un equipo interno o un proveedor, la empresa puede pedir evidencias que muestren si estas prácticas existen. Las más reveladoras son el análisis de amenazas de las funciones críticas, los resultados de las revisiones automáticas de código con su seguimiento y el inventario de componentes de terceros (SBOM) de cada versión. Antes de un lanzamiento relevante, conviene solicitar el informe de pruebas de seguridad. En la operación, la evidencia está en el proceso publicado para reportar vulnerabilidades, en los tiempos objetivo de corrección y en el registro de las vulnerabilidades corregidas y de las aceptadas, con el nombre de quien aprobó cada excepción.

Estas evidencias pueden incorporarse en los contratos de desarrollo y en los criterios de selección de proveedores. Pedirlas desde la propuesta deja claro que la seguridad forma parte del entregable.

Integrar seguridad en el desarrollo convierte un costo imprevisto en un trabajo planificado. Para la dirección, el resultado práctico es menos sorpresas después del lanzamiento y una respuesta documentada cuando un cliente o un regulador pregunte cómo se protege el software que la empresa ofrece.