Tema 10
Una aplicación no solo debe procesar datos y ejecutar código; también debe confiar correctamente en el origen, la integridad y la legitimidad de aquello que consume y despliega. Cuando esa confianza está mal planteada, un atacante puede introducir artefactos manipulados, abusar de procesos automáticos o lograr que el sistema ejecute contenido que nunca debió aceptar.
Una aplicación moderna consume paquetes, plugins, configuraciones, archivos serializados, actualizaciones, imágenes de contenedor, scripts de automatización y resultados de pipelines. En todos esos puntos existe una pregunta de fondo: ¿el sistema está confiando en algo que realmente debería confiar?
OWASP agrupa bajo Software and Data Integrity Failures aquellas debilidades donde la aplicación o sus procesos aceptan software, datos o artefactos sin verificar adecuadamente su legitimidad, integridad o procedencia. Esto incluye desde procesos inseguros de actualización hasta deserialización peligrosa y pipelines capaces de introducir cambios no confiables en producción.
Esta categoría es importante porque muestra una realidad central: la seguridad no se rompe solo cuando entra un dato malicioso por un formulario. También se rompe cuando el sistema confía ciegamente en lo que ejecuta, despliega o interpreta como válido.
La integridad se refiere a la garantía de que un artefacto, dato o componente no fue alterado indebidamente y proviene de una fuente legítima dentro del flujo esperado. En términos prácticos, significa poder responder con confianza preguntas como estas:
Cuando esas respuestas son débiles, la aplicación queda expuesta a ejecución de código, manipulación del despliegue o comportamiento inesperado con impacto severo.
Muchas fallas de esta categoría nacen de una confianza implícita no revisada. El sistema asume que cierto software, artefacto o dato es legítimo solo porque llegó desde un canal habitual o porque forma parte de un proceso automatizado.
Esa confianza puede ser riesgosa cuando:
El software que una aplicación ejecuta no proviene de una sola fuente. Llega a través de repositorios, dependencias, herramientas de build, imágenes base, artefactos compilados y pipelines de entrega. Cada uno de esos pasos puede alterar lo que finalmente se ejecuta en producción.
Por eso la integridad de software se conecta directamente con la seguridad de la cadena de suministro. El riesgo no es solo que un componente tenga una vulnerabilidad conocida, sino que un artefacto o una actualización pueda ser manipulado antes de llegar al entorno final.
Las actualizaciones automáticas pueden ser útiles para reducir exposición temporal frente a bugs o vulnerabilidades, pero si se implementan sin validación suficiente también pueden introducir software no confiable o cambios no controlados.
El problema no es actualizar automáticamente en sí, sino hacerlo sin:
Cuando el proceso de update se trata como una caja negra confiable por defecto, el riesgo se desplaza desde la aplicación hacia todo el mecanismo de suministro.
Los pipelines de integración y despliegue continuo aceleran el desarrollo moderno, pero también concentran mucho poder. Un pipeline comprometido puede modificar artefactos, inyectar código, alterar configuraciones o desplegar software malicioso con apariencia legítima.
Desde seguridad, un pipeline debe considerarse infraestructura crítica porque puede:
Esto convierte la integridad del pipeline en una pieza central de la seguridad operativa.
Uno de los ejemplos clásicos dentro de esta categoría es la deserialización insegura. La serialización permite representar objetos o estructuras para almacenarlos o transmitirlos. El problema aparece cuando la aplicación acepta esos datos serializados desde una fuente no confiable y los reconstruye como objetos complejos sin controles adecuados.
En ciertos entornos, eso puede permitir:
La deserialización insegura es especialmente delicada porque la aplicación no solo lee datos: reconstruye estructuras que pueden tener semántica interna rica, relaciones de objetos o comportamientos asociados. Si se hace sobre información controlada por el atacante, el problema puede ir mucho más allá de un dato alterado.
Además, suele ser difícil de detectar superficialmente porque el flujo puede estar oculto detrás de cookies firmadas incorrectamente, cachés, colas, sesiones persistidas o integraciones entre servicios.
Aunque están relacionadas, conviene diferenciar ambas dimensiones.
| Tipo de integridad | Qué protege | Ejemplo de riesgo |
|---|---|---|
| Integridad de software | Artefactos, paquetes, builds, imágenes, actualizaciones | Despliegue de software manipulado |
| Integridad de datos | Objetos, archivos, configuraciones, estados serializados | Procesamiento de datos alterados como si fueran confiables |
En ambos casos el problema central es confiar sin validar adecuadamente.
Algunas aplicaciones permiten cargar complementos, plantillas, scripts o reglas configurables. Esa flexibilidad puede ser útil para el negocio, pero aumenta el riesgo si el sistema no controla bien quién puede introducir esos artefactos y cómo se verifica su legitimidad.
La pregunta clave es simple: ¿el sistema está ejecutando algo que puede haber sido alterado fuera del flujo de confianza previsto?
Muchas aplicaciones confían en datos que llegan desde otros sistemas mediante webhooks, sincronizaciones, colas o APIs internas. Si esa confianza no se protege bien, el atacante puede falsificar origen, alterar contenido o abusar de integraciones para modificar comportamiento.
Esto puede afectar:
La integridad aquí no solo depende del dato, sino del canal y de la autenticidad del emisor.
Una forma de fortalecer esta categoría es incorporar mecanismos que permitan verificar que artefactos y actualizaciones provienen de fuentes legítimas y no fueron alterados. Esto puede incluir firmas, checksums, trazabilidad de build y validaciones dentro del flujo de despliegue.
Lo importante no es solo generar esas evidencias, sino asegurarse de que realmente se verifiquen antes de consumir o desplegar el artefacto.
Un error de diseño frecuente consiste en asumir que todo lo que llega desde un sistema interno, una red privada o un pipeline corporativo es automáticamente confiable. Esa suposición es peligrosa porque un compromiso interno puede propagarse con gran impacto si no existen verificaciones adicionales.
En seguridad moderna, lo interno no equivale a confiable por definición. La confianza debe justificarse y verificarse.
Las fallas de integridad pueden ser especialmente graves porque afectan directamente aquello que la aplicación ejecuta o interpreta como confiable.
| Falla | Impacto posible |
|---|---|
| Deserialización insegura | Manipulación de lógica interna o ejecución no prevista |
| Pipeline comprometido | Despliegue de código malicioso o alterado |
| Actualización no verificada | Introducción de software no confiable |
| Integración sin validación fuerte | Aceptación de eventos o datos falsificados |
La prevención de esta categoría exige disciplina tanto de desarrollo como de operación.
Una regla útil para esta categoría es reducir la confianza implícita en procesos automáticos, redes internas y artefactos heredados. Cuanto más crítico sea lo que se ejecuta o despliega, más fuerte debe ser la validación previa.
Esto no significa frenar todo con burocracia, sino diseñar controles proporcionales al poder que tiene cada artefacto o flujo.
Software and Data Integrity Failures suele combinarse con otras categorías del curso.
Esto muestra que la integridad no es un tema aislado; atraviesa la forma en que el sistema construye y mantiene su propia confianza.
Software and Data Integrity Failures nos obliga a mirar más allá del código de negocio y a revisar la confianza que la aplicación deposita en artefactos, actualizaciones, datos estructurados y procesos de automatización. Cuando esa confianza está mal diseñada, el problema puede llegar directamente al corazón del sistema: aquello que ejecuta, despliega o considera legítimo.
En el próximo tema estudiaremos A09: Security Logging and Monitoring Failures, centrado en qué ocurre cuando una organización no logra ver, registrar ni responder a tiempo ante actividad sospechosa o compromisos en curso.