Arquitectura y feeds de OpenVAS y Greenbone

La plataforma se reparte el trabajo. GSA es la interfaz web. gvmd es el servicio central: guarda las configuraciones, las tareas, los usuarios y los resultados en su base de datos. ospd-openvas hace de puente entre el servicio central y el motor, y openvas-scanner es el motor que ejecuta las pruebas de vulnerabilidad contra los objetivos. notus-scanner es una vía distinta: compara el software instalado con versiones vulnerables conocidas, sin lanzar una prueba por cada fallo.

La tabla componentes resume cada pieza y su capa. Lo que importa para el analista: quien decide qué se escanea y quien ejecuta las pruebas no son el mismo componente.

La plataforma no trae las pruebas de fábrica: las descarga de feeds que se sincronizan a diario. En la edición comunitaria hay un feed de pruebas de vulnerabilidad (VT), uno de datos de CVE y CPE con los que se enriquecen los resultados, uno de avisos de organismos de respuesta y uno de objetos de partida como perfiles y listas de puertos.

Cada feed se sincroniza por separado, de modo que cada uno tiene su propia fecha. En la tabla feeds está el estado de los cuatro en pmo-vuln-01.

La fecha de corte de la lectura está en la nota de la tabla feeds: 2026-10-07. La antigüedad de un feed es el número de días entre su última sincronización y el corte. Un feed que lleva semanas sin actualizarse sigue funcionando, y por eso el atraso pasa desapercibido: no da error, solo deja de conocer lo nuevo.

En la tabla servicios todos los servicios están en ejecución y la sincronización figura como programada, sin avisos de error. Eso demuestra que la plataforma corre, no que sus datos estén al día. La disciplina del oficio es mirar cada feed por separado y con fecha.