Cómo evitar que la responsabilidad compartida se diluya
Introducción
La seguridad de un sistema no comienza cuando el software está terminado, sino desde las primeras
decisiones sobre análisis y diseño. Estas decisiones influyen en los riesgos y controles del sistema
a lo largo del desarrollo. Por eso, los involucrados en el proceso de construcción del sistema deben
participar para que la seguridad sea una responsabilidad compartida desde el principio y así la
seguridad del sistema no recaiga en una sola persona.
La participación de todo el equipo no garantiza que cada decisión de seguridad tenga una persona
responsable en particular. Si las tareas no se asignan claramente, especialmente cuando se utiliza
IA como herramienta de apoyo, la responsabilidad puede diluirse hasta el punto en que nadie sea
responsable. Por lo tanto, debemos identificar las brechas en la responsabilidad y remediarlas antes
de continuar con el desarrollo.
Desarrollo
La distribución de la seguridad entre múltiples personas solo funcionará si todos entienden qué
hacer y hasta qué punto tienen autoridad para tomar decisiones. Debido a la mala comunicación
de la distribución, ciertos riesgos pueden pasar desapercibidos porque todos creen que alguien más
se hará cargo de ellos. Por lo tanto, NIST CSF 2.0 establece que las funciones, responsabilidades
y autoridades de seguridad deben ser definidas y comunicadas adecuadamente para poder responsabilizar a las personas.1
Esto no implica que todos los roles de seguridad se le asignen a una sola persona, sino que significa
la asignación de tareas específicas. El analista identificará las amenazas y los requerimientos; el
arquitecto diseñará el control; el programador lo implementará; y el revisor lo verificará. En el
1 Pascoe, Quinn y Scarfone, The NIST Cybersecurity Framework, 17. artículo actual se discute esta asignación desde las siguientes cuatro perspectivas: técnica, la cual
es responsable de ejecutar y verificar el control; organizativa, la cual es responsable de asignar las
tareas; ética, la cual es responsable de analizar el impacto de las decisiones; y legal, la cual es responsable de verificar los requerimientos legales. NIST SSDF ayuda en la asignación de tareas.2
Según OWASP SAMM, el Security Champion es responsable de liderar a su equipo, pero no de realizar todas las tareas.3
Para evitar cualquier dilución de la responsabilidad, proponemos una responsabilidad rastreable,
la cual consta de tres componentes: la parte responsable, el revisor y la evidencia. La parte
responsable lleva a cabo la acción; el revisor asegura su cumplimiento; y la evidencia permite
probar el resultado. Si falta cualquiera de estos componentes, existe un vacío, el cual debería ser
llenado. El NIST SSDF respalda nuestro enfoque al sugerir que se cree evidencia y que se registren las decisiones durante el proceso de desarrollo.4
No es suficiente identificar la falta de responsabilidad cuando el proyecto puede continuar sin
llenar el vacío. En este sentido, proponemos puntos de control antes de la finalización de cada
actividad o fase. Si falta una parte responsable, un revisor o una prueba de que la tarea se ha
completado, esta deberá quedar pendiente. El NIST SSDF respalda este proceso de revisión y documentación al recomendar controles y el registro de las decisiones durante el desarrollo.5 La
Elemento Preguntas de control Condición para continuar
Parte responsable ¿Quién realiza la tarea o toma la decisión? Existe una persona asignada.
Revisor ¿Quién revisa el resultado? La revisión se llevó a cabo y fue registrada.
Evidencia ¿Existe alguna evidencia de esto? Existen pruebas o registros.
Estado del control ¿Se han cumplido los tres elementos? Se avanza únicamente cuando todo esté completado.
Tabla 1. Elementos de verificación en un punto de control. Fuente: elaboración propia.
Este principio también es válido si la inteligencia artificial es utilizada por el grupo como un
elemento de apoyo. Por ejemplo, si la inteligencia artificial escribe el código de un módulo de
el equipo analiza el impacto potencial en el usuario desde la perspectiva ética; mientras que el
oficial de cumplimiento revisa los temas legales pertinentes. La recomendación solo será aceptada
si hay una persona responsable, un revisor y evidencia de las pruebas realizadas.
Conclusión
Al delegarse las responsabilidades a ciertas personas, será importante mantener la responsabilidad
compartida. La participación de todos los miembros del grupo debería ir de la mano con
asignaciones claras para evitar acciones sin responsable. Las perspectivas técnica, organizativa,
ética y legal nos ayudan a identificar quiénes participan en cada decisión y cómo deben responder.
La identificación de vacíos en las responsabilidades nos ayuda a llenarlos antes de que surja algún
problema. Por lo tanto, cada decisión debe tener una persona responsable, un revisor y evidencia.
Los puntos de control permiten verificar estos requisitos. Este enfoque también se aplica cuando
la inteligencia artificial se utiliza como ayuda, pues sus sugerencias deben de ser analizadas de
manera critica y aprobadas.
Referencias bibliográficas
OWASP Foundation. “SAMM Agile Guidance.” OWASP Software Assurance Maturity Model.
Acceso el 20 de agosto de 2026 https://owaspsamm.org/docs/guides/agile/?.
Pascoe, Cherilyn, Stephen Quinn y Karen Scarfone. The NIST Cybersecurity Framework (CSF)
2.0. NIST Cybersecurity White Paper 29. Gaithersburg, MD: National Institute of Standards and
Technology, 2024. https://doi.org/10.6028/NIST.CSWP.29.
Scarfone, Karen, Murugiah Souppaya y Donna Dodson. Secure Software Development Framework
(SSDF) Version 1.1: Recommendations for Mitigating the Risk of Software Vulnerabilities. NIST
Special Publication 800-218. Gaithersburg, MD: National Institute of Standards and Technology,
2022. https://doi.org/10.6028/NIST.SP.800-218.
Ver diseño original de las páginas
