En el registro de incidentes en desarrollo de software se trata de dos cosas diferentes que a menudo se confunden: una vulnerabilidad o defecto en el software que construye y entrega, y un incidente en su propia línea de desarrollo —el entorno en el que crea ese software. Lo que documenta, quién debe saberlo y qué paso siguiente corresponde, varía según el tipo. Quien no hace esta distinción, a menudo se pierde el incidente que más importa: una contaminación en la tubería de compilación que se propaga a través del código a todos los clientes que lo utilizan.
Una vulnerabilidad en el código entregado afecta directamente al cliente: ese cliente ejecuta el software, por lo que corre el riesgo. Un incidente en la línea de desarrollo —una clave de acceso robada, una cuenta de compilación comprometida, una fuga en el repositorio de código fuente— le afecta en primer lugar a usted, pero puede transmitirse a cada cliente que trabaja con ese código. Para ambos casos se aplica que un cuestionario de seguridad o un auditor no pregunta si algo alguna vez salió mal, sino si puede demostrar qué ha documentado y qué ha aprendido al respecto.
Qué documenta en un incidente en el código
En una vulnerabilidad o defecto en software entregado se trata de: cuándo se descubrió, por quién o qué (prueba interna, notificación del cliente, escaneo, investigador externo), qué parte del software afecta, cuál es el posible impacto, qué medida se tomó y en qué fecha, y quién dentro de su organización es responsable del seguimiento. Un buen registro también muestra si una corrección se implementó en todos los clientes que utilizan la versión afectada, o solo en quien la notificó. Lo último es exactamente lo que un usuario pregunta en un cuestionario: no si alguna vez tuvo una vulnerabilidad, sino si su proceso garantiza que todos los afectados lo sepan.
Qué documenta en un incidente en la línea de desarrollo
Un incidente en su propio entorno de desarrollo —una cuenta comprometida con acceso al código fuente, un servidor de compilación que responde de manera inesperada, una dependencia que posteriormente resulta ser maliciosa— requiere un registro ligeramente diferente. Aquí se trata de: qué sistema o cuenta fue afectado, quién tuvo acceso durante el período en el que ocurrió, si hay indicios de que el código fue modificado o consultado, y qué clientes posiblemente utilizan software que se compiló o entregó en ese período. Este es el tipo de incidente donde el control de acceso en la línea de desarrollo tiene un impacto directo: sin un resumen actual de quién tiene autorización para acceder a qué, esta pregunta de investigación es considerablemente más difícil de responder.
A quién informa y a quién no
Ya sea que usted caiga bajo la obligación de diligencia debida de la Ley de Ciberseguridad o no, determina a quién informa sobre un incidente. Las entidades que están clasificadas como esenciales o importantes tienen una obligación de notificación hacia su autoridad supervisora; exactamente qué se requiere y dentro de qué plazo se describe en la directiva y la ley nacional, y varía según la situación. Una empresa de software que es afectada a través de la cadena —es decir, no es plenamente responsable en sí misma, pero entrega a un cliente que sí lo es— no tiene esa obligación de notificación ante la autoridad supervisora, pero generalmente tiene un acuerdo contractual para informar al cliente. Esto no hace que su propio registro sea menos importante: un cliente que pregunta si tuvo alguna vez un incidente quiere ver una respuesta concreta, no una evaluación retrospectiva.
Un registro vivo, no un archivo
El registro de incidentes funciona mejor como un documento vivo: una lista en la que se pueden encontrar por cada incidente el estado, la prueba y el responsable, en lugar de un informe aislado que desaparece en una carpeta después de su resolución. Esto se alinea con la forma en que se estructura la obligación de diligencia más amplia, con diez medidas que cada una requiere un estado y un responsable. Quien quiera ver cómo se relaciona el registro de incidentes con las otras nueve medidas, encuentra ese resumen en la página con todos los temas por situación.
Si su organización cae bajo la obligación de diligencia por sí misma, se ve afectada a través de la cadena de suministro, o ninguna de las dos, puede verlo con algunas preguntas a través de la verificación NIS2 que proporciona una indicación en unos pocos pasos. Quien quiera saber exactamente de dónde procede la información en secria.eu y cómo se mantiene, lo leerá en la página sobre cómo funciona. Y quien después de leer quiera saber qué añade una suscripción a lo que aquí está disponible gratuitamente, lo encuentra claramente en el resumen de qué está incluido.
Este texto es una explicación general y no constituye asesoramiento legal sobre su situación específica. Para una evaluación de su proceso de incidentes específico u obligación de notificación, puede dirigirse a un abogado o a la autoridad competente de supervisión de su sector.