Uno de los riesgos de la cadena de suministro de software es la filtración de secretos. Los secretos están por todas partes en la cadena de suministro de software; los desarrolladores y las canalizaciones de CI\CD necesitan utilizar secretos para acceder al SCM, la canalización, los registros de artefactos, los entornos de nube y los servicios externos. Y cuando los secretos están por todas partes, es cuestión de tiempo hasta que se filtren.
Este riesgo está bien identificado y muchos marcos de la cadena de suministro de software lo abordan exigiendo un escaneo secreto y una caducidad automática del secreto.
Entonces, ¿qué podría salir mal si usted, como profesional de la seguridad, ha colocado estas barreras de seguridad?
Esta semana, mientras investigaba herramientas de escaneo secretas, encontré una respuesta. Esta respuesta es simple: dado que los escáneres de secretos buscan patrones de secretos, cuando el formato del secreto cambia, la detección puede fallar. Y esto es exactamente lo que sucedió cuando GitHub introdujo una nueva característica de seguridad: el tokens de grano fino. Esta función beta es una de las formas que tiene GitHub de reducir los riesgos de filtración de secretos; Limitar los permisos de los tokens de acceso personal también limita los riesgos si estos secretos se hubieran visto comprometidos.
Resulta que el formato de los nuevos tokens es un poco diferente, mientras que el formato de los tokens antiguos era algo así como:
ghp_123456789012345678901234567890123456
El nuevo formato de token es como:
github_pat_123456789012345678901234567890123456789012345678901234567890…
Tanto el prefijo como la longitud del secreto son diferentes.
Y, de hecho, algunos escáneres secretos no logran detectar el nuevo formato;
Para experimentar, creé un repositorio con un Dockerfile con un secreto y un flujo de trabajo que ejecuta la acción Trivy. Así es como se ve el Dockerfile al comienzo del experimento:
A continuación se muestra una instantánea del GitHub Secret Scanner, que detecta el secreto recién formateado:
Como podemos ver, el escáner de secretos de GitHub detecta el secreto, pero no aparece ninguna alerta en la sección Escaneo de código.
Para verificar que las herramientas estén configuradas correctamente, ahora agregaré un secreto clásico al Dockerfile (ver más abajo) y ejecutaré el escaneo nuevamente. Ahora recibimos una alerta de escaneo de código (¡solo en el secreto clásico!)
El escáner de Github, por otro lado, ahora detecta dos secretos:
Abrí un problema de seguridad para Trivy; El equipo de Trivy respondió que esto no es una vulnerabilidad ni un problema de seguridad. Lo que quedaba por hacer era abrir un tema.
Este experimento plantea muchas preocupaciones;
- ¿Por qué un usuario de GitHub debería sospechar que el formato del token se modificaría debido a una nueva característica?
- Dado que se supone que los secretos parecen cadenas aleatorias, ¿por qué un usuario de GitHub debería preocuparse por el formato de los secretos?
- ¿Debería GitHub ser responsable de actualizar a sus clientes sobre dicho cambio?
- ¿Es esta falla en la detección de secretos una vulnerabilidad de los secretos detallados de GitHub, una vulnerabilidad de Trivy o, como lo ve Aqua Security, no es una vulnerabilidad en absoluto?
- ¿Aqua Security, la empresa detrás de Trivy, debería ser responsable de actualizarlo?
- Dado que Trivy es un proyecto de código abierto, suministrado tal cual, ¿alguien sería responsable si se hubieran filtrado secretos de una tubería protegida por Trivy? ¿Quién podría ser? ¿GitHub? ¿Seguridad acuática? ¿El usuario de Trivy?
- ¿Qué nos enseña este experimento sobre cómo confiar en las herramientas de seguridad instaladas para proteger las cadenas de suministro de software?
Dejaré estas preguntas abiertas.
Una cosa está clara, sin embargo; Proteger la cadena de suministro de software es complicado y necesitamos una comunidad altamente profesional para tener éxito duradero en esta tarea.
Esta publicación fue coautora de Avi Waxman, pasante en Scribe Security
Este contenido es presentado por Scribe Security, un proveedor líder de soluciones de seguridad de la cadena de suministro de software de extremo a extremo, que ofrece seguridad de última generación para artefactos de código y procesos de desarrollo y entrega de código en todas las cadenas de suministro de software. Más información.
Artículos relacionados con
