Propiedad y enrutamiento a equipos

La tentación es que todos los hallazgos lleguen al equipo de seguridad, que los reparte. No escala: seguridad no conoce el código de cada servicio, ni puede arreglarlo. Quien lo arregla es el equipo que lo mantiene, y por eso el gestor debe enviarle el hallazgo directamente, con el contexto necesario.

Para saber quién es, hay dos fuentes habituales. Un catálogo de servicios dice qué equipo es dueño de cada repositorio. Un archivo de propietarios dentro del repositorio (en GitHub y GitLab existe CODEOWNERS) afina más: dice quién es dueño de cada carpeta o archivo.

La regla 1 de Uvilla dice que, si la ruta del hallazgo tiene propietario en el archivo de propietarios del repositorio, ese propietario manda sobre el catálogo. Un repositorio puede ser de un equipo y tener una carpeta, como la de infraestructura, que mantiene otro.

Abre las reglas, el archivo de propietarios de pedidos-api y la lista de hallazgos sin asignar. Mira el hallazgo F-2.

Las reglas terminan con una red de seguridad: lo que no coincide con nada va a una cola de triaje de seguridad. Está bien como último recurso y mal como destino habitual: cada hallazgo en la cola es un repositorio que falta en el catálogo.

Aplica las reglas en su orden a los ocho hallazgos.

Algunos hallazgos no son del equipo del servicio: una vulnerabilidad en la imagen base de un contenedor viene de lo que el equipo heredó, y lo corrige quien mantiene las imágenes. Las reglas de enrutamiento lo reflejan con una excepción para ese caso, antes de caer en la regla general del catálogo.

Mira el hallazgo F-8 de pagos-core.

libs-comunes tiene dos hallazgos en la cola y no figura en el catálogo ni tiene archivo de propietarios. Se puede seguir repartiendo a mano cada semana, o resolver la causa. La causa es que el repositorio no tiene dueño, y eso no lo arregla ningún escáner: lo decide una persona con autoridad sobre el repositorio.