La seguridad informática se explica mal cuando se explica en abstracto. Por eso este curso entero gira alrededor de una empresa concreta, con sus servidores, sus clientes, sus prisas y su presupuesto limitado. En esta primera lección conocerás esa empresa, aprenderás qué es exactamente la seguridad informática y en qué se diferencia de términos que se usan como sinónimos sin serlo, y fijarás el vocabulario que vas a usar durante las siete módulos siguientes. Si confundes amenaza con vulnerabilidad o riesgo con impacto, todo lo demás se vuelve confuso: las conversaciones con proveedores, los informes de auditoría y hasta los boletines de seguridad se leen mal. Aquí ponemos ese vocabulario en orden.

1. Nimbus Reservas, S.L.: la empresa que nos acompañará todo el curso
2. Qué es la seguridad informática (y qué no es)
3. La tríada CIA: confidencialidad, integridad y disponibilidad
4. Cómo se rompe cada propiedad: ejemplos en código
5. Más allá de la tríada: autenticidad, no repudio y trazabilidad
6. El trío AAA: autenticación, autorización y auditoría
7. Vocabulario base: activo, amenaza, vulnerabilidad, exploit, riesgo, impacto y control
8. La seguridad como proceso continuo y como compromiso

Nimbus Reservas, S.L. es una PYME española de 38 empleados con oficina en Valencia. Desarrolla y opera un SaaS (software como servicio) de gestión de reservas y citas que utilizan clínicas de fisioterapia, gimnasios y academias de toda España. Sus clientes no compran un programa: entran en una web, y sus pacientes o alumnos reservan hora desde el móvil.

Qué datos maneja Nimbus:

Ese tercer punto es el que cambia todo. Nimbus no cree ser una empresa «de datos sensibles» porque solo gestiona agendas, pero una agenda de una clínica de fisioterapia es, en la práctica, un listado de personas con dolencias. El curso volverá sobre las implicaciones legales de esto en la lección de RGPD (06-03); de momento quédate con la idea: el dato aparentemente inocuo puede ser sensible por el contexto en el que vive.

Cómo está montado técnicamente:

Las personas:

• Marta — CTO. Decide arquitectura y prioridades; es quien tiene que justificar el presupuesto de seguridad ante la dirección.
• Iván — desarrollador backend. Escribe la API en Python/FastAPI.
• Lucía — administradora de sistemas y DevOps. Lleva la nube, los contenedores y el CI/CD.
• Rubén — soporte a clientes. Es quien más veces al día toca datos reales de clientes finales.
• Sara — responsable de administración y RRHH. Custodia nóminas, contratos y facturación.

El entorno físico y humano: oficina en Valencia con una wifi corporativa y una de invitados, unos 40 portátiles, y la mitad de la plantilla trabajando en remoto. Hay tres terceros con los que Nimbus depende: una consultora que da soporte de sistemas con acceso remoto, el proveedor de email transaccional y la pasarela de pago.

Todos los datos, nombres e incidentes de este curso son ficticios. Nimbus no existe; su parecido con empresas reales es exactamente el punto.

Tres términos se usan como sinónimos y no lo son. La diferencia no es pedantería: determina quién es responsable de qué dentro de una organización.

Una forma sencilla de recordarlo:

Cada círculo está dentro del anterior, pero no encajan perfectamente: la ciberseguridad también se ocupa de cosas que no son información (la disponibilidad de un servicio, por ejemplo, o el control de un dispositivo industrial).

Definición de trabajo para este curso:

La seguridad informática es el conjunto de medidas técnicas, organizativas y humanas destinadas a preservar la confidencialidad, la integridad y la disponibilidad de la información y de los sistemas que la tratan, ante fallos accidentales o acciones deliberadas.

Fíjate en tres palabras de esa definición:

• «Conjunto»: no es un producto que se compra. Un cortafuegos no «da seguridad»; es una pieza.
• «Humanas»: la mayoría de incidentes empieza con una persona haciendo algo razonable en un contexto engañoso.
• «Fallos accidentales o acciones deliberadas»: si Lucía borra por error el bucket de copias, el daño es idéntico al de un atacante que lo borre. La seguridad informática cubre ambos casos; la ciberseguridad se centra sobre todo en el segundo.

El alcance completo de la ciberseguridad, con su terminología propia y su marco de trabajo, se desarrolla en la lección 02-01. Aquí nos quedamos con la distinción.

La tríada CIA (por sus siglas en inglés: Confidentiality, Integrity, Availability) es el modelo mental sobre el que se apoya todo lo demás. Cuando no sepas si algo es «un problema de seguridad», pregúntate: ¿rompe alguna de las tres?

Definición: la información solo es accesible para quien está autorizado a acceder a ella.

Confidencialidad no es lo mismo que secreto. El horario de apertura de una clínica cliente de Nimbus es público y no pierde nada por serlo. Confidencialidad significa que cada dato tiene un círculo de acceso definido y ese círculo se respeta.

Contraejemplos concretos en Nimbus (fallos de confidencialidad):

• Un endpoint /api/v1/reservas/{id} que devuelve la reserva pedida sin comprobar que pertenece al cliente que la pide. Un usuario del Gimnasio Levante puede leer las citas de la Clínica Turia cambiando el número en la URL.
• Rubén, en soporte, exporta a un CSV la lista completa de clientes finales para «hacer una prueba» y la deja en su carpeta de Descargas, en un portátil sin cifrar.
• El bucket S3 de adjuntos configurado con lectura pública porque así era más fácil servir las imágenes de perfil.
• Los logs de la API imprimen el cuerpo completo de las peticiones, incluidos teléfonos y notas de la cita, y esos logs los ve toda la consultora externa.

Definición: la información es exacta y completa, y solo se modifica de forma autorizada y controlada.

La integridad tiene dos caras que conviene separar:

• Integridad del dato: el dato no ha sido alterado (ni por un atacante, ni por un error de software, ni por un fallo de disco).
• Integridad del origen: el dato viene de quien dice venir (esto solapa con la autenticidad, que veremos en el apartado 5).

Contraejemplos concretos en Nimbus (fallos de integridad):

• Un script de mantenimiento ejecuta un UPDATE sin WHERE y pone el mismo estado a las 240.000 reservas de la base de datos.
• El importe de una factura se recalcula en el navegador y la API se fía de lo que le manda el cliente, en lugar de recalcularlo en el servidor.
• Dos peticiones simultáneas reservan la misma franja horaria porque no hay control de concurrencia: la agenda queda inconsistente.
• Un atacante modifica un registro de auditoría para borrar el rastro de lo que hizo.

Definición: la información y los servicios están accesibles cuando quien está autorizado los necesita.

Es la propiedad que más a menudo se olvida al hablar de «seguridad», y la que más rápido nota el cliente. Si la Clínica Turia abre a las 8:00 y la API de Nimbus no responde, a las 8:05 el teléfono de Rubén está sonando.

Contraejemplos concretos en Nimbus (fallos de disponibilidad):

• Un ransomware cifra los servidores y las copias de seguridad accesibles desde la misma red.
• El certificado TLS del dominio caduca un domingo y la app móvil deja de conectar.
• Un despliegue rompe una migración de base de datos y hay que revertir a mano durante tres horas.
• El proveedor de email transaccional sufre una caída y no salen los recordatorios de cita: técnicamente la API funciona, pero el servicio que el cliente compró, no.

Las tres compiten entre sí. Si Marta decide cifrar la base de datos con una clave que solo ella conoce, gana confidencialidad y pierde disponibilidad (si Marta está de baja, nadie restaura). Si Lucía da permisos de lectura a todo el equipo para que nadie se bloquee, gana disponibilidad y pierde confidencialidad. Buena parte del trabajo de seguridad consiste en elegir conscientemente el punto de equilibrio, no en maximizar una propiedad.

Ver el fallo en código lo fija mucho mejor que la definición. Los tres ejemplos siguientes están escritos sobre la API de Iván y la base de datos de Nimbus.

Qué hace, línea a línea:

1. Declara un endpoint que recibe un reserva_id por la URL.
2. Consulta la tabla reservas filtrando solo por ese identificador.
3. Devuelve la fila entera tal cual.

Por qué rompe la confidencialidad: hay dos fallos independientes.

• No comprueba la propiedad del recurso. La consulta no filtra por el negocio (tenant) del usuario autenticado. Cualquiera que tenga una sesión válida puede pedir /api/v1/reservas/91544 y leer la cita de un paciente de otro cliente. Este patrón tiene nombre propio: IDOR (referencia directa insegura a objetos), y lo veremos entre los ataques del módulo 2.
• SELECT * devuelve columnas de más. Aunque el usuario tuviera derecho a ver la reserva, la fila incluye campos internos (notas_internas, id_pasarela_pago, creado_por_usuario_id) que no deberían salir de la base de datos.

Versión corregida:

Dos cambios y ambos importan: el AND tenant_id = :tenant ata el recurso al usuario autenticado, y la lista explícita de columnas evita filtrar campos internos. Además, se devuelve 404 y no 403: así el atacante no aprende si el identificador existe o no.

Qué ocurre: sin cláusula WHERE, PostgreSQL actualiza todas las filas de la tabla. Las 240.000 reservas de todos los clientes de Nimbus pasan a estado «cancelada». Nadie ha entrado en el sistema; no ha habido ataque. La integridad se ha roto igual.

Cómo se protege una operación así:

Explicación de cada defensa:

• BEGIN / COMMIT crean una transacción: hasta que no se confirma, nada es definitivo. Si el recuento de filas sorprende, un ROLLBACK lo deja todo como estaba.
• El WHERE acota por tres criterios en lugar de uno. Cuanto más específico, menos daño puede hacer un error.
• La condición estado = 'confirmada' hace la operación idempotente y acotada: no toca reservas ya canceladas.

A esto se añaden defensas estructurales que veremos en 01-03: la cuenta con la que la API se conecta a la base de datos no debería tener permiso para hacer un UPDATE masivo, y los mantenimientos deberían ejecutarse con una cuenta distinta y revisada por una segunda persona.

Por qué rompe la disponibilidad: cada llamada carga en memoria la tabla entera y la ordena. Basta con que Rubén pulse «Actualizar» cinco veces seguidas para que el proceso de la API consuma toda la memoria del contenedor, el orquestador lo reinicie y todos los clientes vean errores. No hace falta un atacante: la fragilidad ya está ahí, y un atacante lo único que hace es descubrirla y repetirla.

Versión defendida:

Tres defensas de disponibilidad en pocas líneas: límite de rango (nadie pide diez años de golpe), paginación con LIMIT (el coste de cada petición está acotado) y filtro por tenant (que además vuelve a proteger la confidencialidad). Una sola corrección puede reforzar varias propiedades a la vez; es lo habitual.

La tríada CIA cubre mucho, pero no todo. Tres propiedades adicionales aparecen constantemente en normativas y contratos.

Definición: la garantía de que una entidad (persona, sistema, mensaje) es realmente quien o lo que dice ser.

Es distinta de la confidencialidad. Un correo puede llegar cifrado —confidencial— y venir de un remitente falso —no auténtico—. En Nimbus: cuando llega un correo diciendo «Soy Marta, cambia la cuenta bancaria de la nómina», la pregunta que falla no es ¿quién puede leerlo? sino ¿realmente lo escribió Marta?.

Definición: la imposibilidad de que quien realizó una acción pueda negar después haberla realizado.

Es una propiedad jurídica antes que técnica. Si un cliente de Nimbus reclama que él nunca canceló 200 citas, Nimbus necesita poder demostrar que la petición vino de su sesión, desde su IP, a esa hora y con su token. Técnicamente se apoya en firmas digitales (módulo 3) y en registros de auditoría íntegros.

Definición: la capacidad de reconstruir qué ocurrió, quién lo hizo, cuándo y sobre qué recurso.

Sin trazabilidad no hay investigación posible de un incidente. Es la diferencia entre poder decirle a un cliente «se accedió a estos 14 registros el martes a las 03:12 desde esta cuenta» y tener que decirle «no lo sabemos». Ante un regulador, la segunda respuesta es mucho peor que la primera.

Ejemplo de una línea de log de Nimbus que sostiene la trazabilidad:

Fíjate en qué contiene y en qué no contiene: hay quién, qué, cuándo, sobre qué y desde dónde, pero no hay valores de los datos leídos. Un log de auditoría que copie los datos sensibles se convierte él mismo en un problema de confidencialidad.

AAA es el modelo operativo que implementa buena parte de lo anterior. Se confunden constantemente los dos primeros, así que vamos despacio.

Visto como flujo en una petición real de Nimbus:

Y en código, separando explícitamente las tres responsabilidades:

Los tres errores clásicos que este código evita:

1. Confundir autenticar con autorizar. «Está logueado» no significa «puede hacerlo». La comprobación de permisos es una línea distinta de la validación del token.
2. Autorizar solo por rol y olvidar el recurso. Rubén tiene el permiso reservas:cancelar, sí — pero solo sobre las reservas de los tenants que le corresponden. Rol y pertenencia.
3. Registrar solo los errores. El log de auditoría debe registrar también las acciones exitosas sobre datos sensibles; son precisamente las que hay que poder reconstruir después.

Las técnicas concretas para autenticar bien —MFA, SSO, gestión de sesiones, modelos RBAC y ABAC— se desarrollan en la lección 02-05. Aquí solo necesitas tener claros los tres conceptos y su orden.

Este es el apartado que más veces vas a releer. Estos siete términos se usan mal a diario, incluso en informes profesionales.

La frase-tipo que los encadena. Memoriza esta estructura; sirve para escribir cualquier hallazgo de seguridad de forma profesional:

Una amenaza [grupos de ransomware que escanean Internet] podría aprovechar una vulnerabilidad [el puerto 5432 expuesto con credenciales débiles] mediante un exploit [un script de fuerza bruta de credenciales] sobre un activo [la base de datos de reservas], con un impacto [cifrado de datos, parada del servicio y notificación obligatoria a la autoridad]. El riesgo resultante se estima alto, y se mitiga con el control [restringir el acceso a la red privada y exigir autenticación por certificado].

Practica reescribiendo hallazgos con esa plantilla. Un informe que dice «tenemos una amenaza de puerto abierto» está usando mal las palabras: un puerto abierto es una vulnerabilidad, no una amenaza.

Las tres confusiones más frecuentes:

• Amenaza vs. vulnerabilidad. La amenaza está fuera y no la eliminas (no puedes hacer que los grupos de ransomware dejen de existir). La vulnerabilidad está dentro y sí la puedes cerrar. Tu trabajo se ejerce sobre las vulnerabilidades y los controles, no sobre las amenazas.
• Riesgo vs. impacto. El impacto es «cuánto duele si pasa». El riesgo incorpora además «cuán probable es que pase». Un impacto catastrófico con probabilidad ínfima puede ser un riesgo menor que un impacto moderado que ocurre cada semana.
• Vulnerabilidad vs. exploit. La vulnerabilidad es el agujero; el exploit es la ganzúa. Existen vulnerabilidades sin exploit conocido (menos urgentes) y vulnerabilidades con exploit público y automatizado (mucho más urgentes).

El catálogo detallado de amenazas y de tipos de vulnerabilidad, con sus identificadores CVE y CVSS, es el contenido de la lección siguiente (01-02). La forma de calcular y priorizar el riesgo con matrices llega en 04-01.

Marta podría contratar una auditoría, corregir todos los hallazgos y declarar «Nimbus es seguro». Duraría poco:

• Cada semana se publican vulnerabilidades nuevas en las dependencias que usa Iván.
• Cada despliegue de CI/CD cambia el sistema, y con él la superficie de ataque.
• Cada persona que entra o sale de la empresa cambia el mapa de accesos.
• Los atacantes cambian de técnica cuando la anterior deja de funcionar.

Por eso la seguridad se modela como un ciclo continuo, no como un proyecto con fecha de fin:

Este ciclo —identificar, proteger, detectar, responder, recuperar— es la columna vertebral del curso: los módulos 4 y 5 lo desarrollan entero. Fíjate en que proteger es solo una quinta parte. Una organización que solo invierte en protección y no puede detectar ni responder está apostando a no fallar nunca, lo cual no es una estrategia.

Toda medida de seguridad se paga en alguna de estas monedas:

La pregunta correcta nunca es «¿es esto seguro?», porque la respuesta siempre es «no del todo». La pregunta correcta es:

¿Cuánto riesgo estamos aceptando, quién lo ha aceptado por escrito y a cambio de qué?

Ese «quién» importa mucho: la aceptación de un riesgo es una decisión de negocio, no técnica. Lucía puede explicar que no cifrar las copias supone tal riesgo, pero quien acepta convivir con él es la dirección. Volveremos a ello en la lección de políticas de seguridad (04-02).

Y un corolario práctico: una medida de seguridad que la gente no puede cumplir no protege, sino que genera atajos. Si Nimbus obliga a cambiar la contraseña cada 30 días con reglas imposibles, acabará habiendo un post-it bajo el teclado. Este es el principio de aceptabilidad psicológica, que veremos formalmente en 01-03.

Errores comunes al empezar en seguridad:

• Creer que «no tenemos nada interesante». Es el error más caro en una PYME. Nimbus no tiene secretos de estado, pero tiene datos personales de miles de personas, una infraestructura cloud que un atacante puede usar para minar criptomonedas y una relación de confianza con clientes que sirve de puente hacia ellos. La mayoría de ataques son oportunistas y automatizados: no eligen a la víctima, la encuentran.
• Reducir la seguridad a la confidencialidad. Muchos equipos piensan solo en «que no roben datos» y descuidan integridad y disponibilidad, que son las que paran el negocio de forma más inmediata.
• Usar «amenaza» para todo. «Tenemos varias amenazas en el informe de escaneo» — no: tienes vulnerabilidades. Usar el vocabulario con precisión mejora las decisiones, porque cada término apunta a un tipo de acción distinta.
• Confundir autenticado con autorizado. Es el origen de una fracción enorme de fugas de datos en APIs multi-cliente como la de Nimbus.
• Tratar la seguridad como una fase final. «Cuando terminemos el producto, hacemos la revisión de seguridad». Corregir un fallo de diseño después cuesta órdenes de magnitud más que evitarlo.
• Confiar en que el proveedor cloud «ya se encarga». El proveedor asegura la infraestructura; la configuración, los permisos y los datos son responsabilidad de Nimbus. Es el modelo de responsabilidad compartida, que se detalla en 05-07.

Consejos:

• Ante cualquier decisión técnica, pregúntate: ¿esto afecta a la C, a la I o a la D? Es un filtro sorprendentemente eficaz.
• Escribe los hallazgos con la frase-tipo del apartado 7. Te obligará a saber si estás describiendo una amenaza, una vulnerabilidad o un riesgo.
• Cuando propongas un control, indica siempre su coste y su fricción. Una propuesta de seguridad sin coste declarado no se aprueba, se ignora.
• Empieza por lo que sabes que tienes. Nada de lo que viene en este curso funciona sin inventario (01-04).

Para cada situación de Nimbus, indica qué propiedad(es) de la tríada CIA se ven afectadas y justifica brevemente:

1. Lucía descubre que el bucket S3 con los adjuntos de las citas (partes médicos escaneados) permite lectura anónima desde hace 4 meses.
2. Un despliegue introduce un error que hace que el campo estado de las reservas se guarde siempre como pendiente, aunque el usuario la confirme.
3. El proveedor de email transaccional sufre una caída de 6 horas y no salen los recordatorios de cita.
4. Un exempleado conserva su cuenta activa y accede al panel de administración dos semanas después de irse, exporta la lista de clientes y borra su propio registro del log.

El siguiente párrafo, escrito por un becario, mezcla los términos. Identifica los usos incorrectos y reescríbelo usando la frase-tipo del apartado 7.

«Hemos detectado un riesgo grave: el servidor de pruebas tiene una amenaza porque usa la contraseña admin1234. El impacto es que hay un exploit. Recomendamos un control de vulnerabilidad.»

Lee este endpoint de la API de Nimbus e identifica qué elementos de AAA están presentes, cuáles faltan y qué propiedad de seguridad queda comprometida por cada ausencia.

Solución 1

1. Confidencialidad, de forma grave: documentos con información de salud accesibles sin autorización. Añadido: si el bucket también permitiera escritura, habría además un problema de integridad; conviene comprobarlo. El hecho de que lleve 4 meses agrava el impacto, porque no se puede acotar quién accedió (fallo de trazabilidad).
2. Integridad: el dato almacenado no refleja la realidad. No hay acceso indebido ni caída del servicio, pero la información es incorrecta. Secundariamente afecta a la disponibilidad funcional del servicio (las clínicas no pueden operar con una agenda que no confirma), aunque la causa raíz es de integridad.
3. Disponibilidad: el servicio contratado (avisar a los pacientes) no está disponible, aunque la API responda. Es un buen ejemplo de que la disponibilidad se mide desde el punto de vista del cliente, no del servidor, y de que depende también de terceros.
4. Las tres, y además propiedades extendidas: confidencialidad (exporta datos sin autorización), integridad (altera el log borrando su rastro), disponibilidad no directamente, pero sí trazabilidad y no repudio destruidos al manipular la auditoría. Es también un fallo de proceso: la baja del empleado no desencadenó la revocación de accesos.

Solución 2

Usos incorrectos:

• «tiene una amenaza porque usa la contraseña admin1234» → una contraseña débil es una vulnerabilidad, no una amenaza.
• «El impacto es que hay un exploit» → un exploit no es un impacto; el impacto es la consecuencia para el negocio.
• «control de vulnerabilidad» → un control es una medida concreta; hay que nombrarla.
• «Hemos detectado un riesgo grave» aplicado a un hecho observado: lo observado es la vulnerabilidad; el riesgo es la estimación que se deriva de ella.

Reescritura correcta:

Hemos identificado una vulnerabilidad en el servidor de pruebas: la cuenta administrativa usa la contraseña por defecto admin1234. La amenaza correspondiente son los procesos automatizados que rastrean Internet probando credenciales conocidas, que disponen de exploits públicos y triviales para este caso. El activo afectado es el servidor de pruebas, que además contiene una copia parcial de datos reales de reservas. El impacto estimado incluye el acceso no autorizado a datos personales, el uso del servidor como punto de salto hacia la red interna y la posible notificación obligatoria a la autoridad de control. Valoramos el riesgo como alto por la facilidad de explotación. Controles propuestos: rotar la credencial a una contraseña única generada, restringir el acceso administrativo a la red privada y eliminar los datos reales del entorno de pruebas.

Solución 3

• Autenticación: presente. La dependencia get_usuario_actual valida quién hace la petición.
• Autorización: ausente por partida doble. No se comprueba (a) que el usuario tenga un permiso específico de exportación, ni (b) que los datos devueltos pertenezcan a su tenant. La consulta SELECT * FROM clientes_finales sin WHERE devuelve los clientes finales de todos los negocios clientes de Nimbus. Cualquier usuario autenticado, incluido el recepcionista de un gimnasio, obtiene la base de datos completa. Propiedad comprometida: confidencialidad, de forma masiva.
• Auditoría: ausente. Una exportación completa de datos personales es exactamente el tipo de acción que debe quedar registrada. Sin ello se pierden trazabilidad y no repudio: si mañana aparecen esos datos publicados, Nimbus no podrá saber quién los sacó.
• Extra — disponibilidad: cargar la tabla entera en memoria y serializarla en JSON, sin paginación ni límites, hace el endpoint vulnerable a un agotamiento de recursos, igual que en el apartado 4.3.

Versión corregida en lo esencial:

En esta lección has conocido a Nimbus Reservas —la PYME valenciana cuyo SaaS de reservas nos servirá de laboratorio durante todo el curso— y has fijado el vocabulario que hace posible el resto. Has visto que seguridad de la información, seguridad informática y ciberseguridad son círculos concéntricos y no sinónimos; que la tríada CIA (confidencialidad, integridad, disponibilidad) es el filtro con el que evaluar cualquier decisión técnica, y cómo se rompe cada una de sus propiedades con código real: una consulta sin filtro de tenant, un UPDATE sin WHERE, un endpoint sin paginación. Has añadido a la tríada la autenticidad, el no repudio y la trazabilidad, y has ordenado el trío AAA —autenticar, autorizar, auditar— separando explícitamente las tres responsabilidades en un endpoint de FastAPI.

Sobre todo, has separado siete palabras que se confunden a diario: activo, amenaza, vulnerabilidad, exploit, riesgo, impacto y control, y tienes una frase-tipo que las encadena para redactar cualquier hallazgo con precisión. Y has aceptado la premisa incómoda del oficio: la seguridad no es un estado que se alcanza, sino un ciclo que se mantiene, y siempre se paga en usabilidad o en dinero.

Con el vocabulario ya en su sitio, toca llenarlo de contenido. En la siguiente lección, Tipos de Amenazas y Vulnerabilidades (01-02), veremos el catálogo real: qué amenazas existen según su origen y su objetivo, qué familias de malware hay y cómo se distinguen, qué tipos de vulnerabilidades encontraremos en el entorno de Nimbus, y cómo se leen los identificadores que usa toda la industria —CWE, CVE y CVSS— para nombrar y priorizar los agujeros que hay que cerrar.