Las canalizaciones de CI/CD son notoriamente opacas en cuanto a lo que ocurre exactamente en su interior. Incluso si usted es quien escribió el archivo de configuración YAML (la lista de instrucciones de canalización), ¿cómo puede estar seguro de que todo sucede exactamente como se describe? Peor aún, la mayoría de los oleoductos son completamente efímeros, por lo que incluso si sucede algo malo, no quedan rastros después.
En pocas palabras, una canalización es una forma automatizada de probar, crear y publicar su software, aplicación o artefacto. Estos oleoductos son cada vez más comunes y complicados. Los pipelines funcionan muy bien para lograr que los equipos trabajen más rápido y brinden resultados más consistentes y predecibles al producir su artefacto de software. La importancia de automatizar estos procesos se vuelve aún más clara si se considera que las empresas más grandes podrían tener cientos de procesos orquestados que dependen unos de otros, por lo que es vital que todo funcione sin problemas y sin fallas.
Como vínculo final en el proceso de desarrollo entre los desarrolladores y el usuario o cliente final, creo que no se presta suficiente atención a cómo dichos procesos automatizados podrían usarse como posibles vectores de ataque. Acceder a un proceso de construcción podría permitir que actores maliciosos no solo penetren en el sistema de la empresa productora, sino que también modifiquen potencialmente el artefacto resultante de tal manera que afecte a todos los usuarios futuros, creando así un enorme radio de explosión que a menudo se describe como un ataque a la cadena de suministro de software.
En un artículo anterior, discutimos los principios que deben guiarlo en asegurar su proceso de CI/CD. En este artículo, cubriré algunos de los puntos débiles potenciales más comunes en una canalización de CI/CD y ofreceré algunas opciones de solución. Para nuestros propósitos, no importa qué herramientas o sistemas de automatización esté utilizando: los principios de seguridad siguen siendo válidos, solo necesita encontrar la herramienta adecuada para proteger esa sección de su tubería.
Dominar el arte de CI/CD: los elementos clave que no puedes ignorar
Diferentes oleoductos tienen diferentes elementos y utilizan diferentes herramientas. Los elementos en los que elegí centrarme son relevantes para casi cualquier canalización, por lo que proteger estos elementos puede considerarse una mejor práctica sin importar su SCM, herramientas o configuración de seguridad existente.
Gestión secreta – Los secretos suelen ser cadenas o tokens que se utilizan para conectar su software o canalización a otros recursos. Un ejemplo común son las claves API que se utilizan para conectar su código a recursos de AWS como un depósito de S3. La mayoría de la gente ya sabe que deben mantener esos secretos ocultos y no incluirlos como texto sin formato en un repositorio abierto. Las cosas son un poco más complicadas dentro de un proceso de CI/CD. Por lo general, el oleoducto necesita acceso a estos secretos para acceder a los recursos y la información que representan. Eso significa que cualquier persona con acceso a lo que sucede dentro de su canalización podría potencialmente ver y copiar sus secretos. Una forma de mantener sus secretos seguros incluso dentro de su canalización es utilizar una herramienta de gestión de secretos como Bóveda de Hashicorp. Estas herramientas no sólo pueden ocultar sus secretos incluso dentro de su canalización, sino que también hacen que sea mucho más fácil rotar sus secretos para que pueda cambiarlos periódicamente, haciendo que robar secretos de una canalización no tenga valor. Independientemente de la herramienta de gestión de secretos que elija emplear, rotar sus secretos con regularidad puede considerarse una buena práctica de seguridad.
Ejecución de oleoducto envenenado (PPE) – La ejecución de canalización envenenada (PPE) es una técnica que permite a los actores de amenazas "envenenar" la canalización de CI; de hecho, cambiar los pasos de la canalización o su orden tal como se define en el archivo de instrucciones de la canalización. La técnica abusa de los permisos en los repositorios de administración de código fuente (SCM) para manipular el proceso de compilación. Permite inyectar código o comandos maliciosos en la configuración de la canalización de compilación, envenenando la canalización para ejecutar código malicioso durante el proceso de compilación. A menos que verifique el archivo de instrucciones de la canalización antes de cada compilación, lo más probable es que no sepa que sus compilaciones ya no se ejecutan como usted especificó. Incluso un cambio minúsculo, como llamar a una biblioteca en lugar de otra, puede tener efectos de gran alcance, como incluir puertas traseras o mineros criptográficos en el producto final.
Una de las formas de evitar el PPE es verificar que el archivo de instrucciones de la tubería no esté modificado. Puede firmar criptográficamente el archivo y agregar la verificación de la firma como primer paso de cada proceso. Una herramienta que puede utilizar para firmar y verificar archivos es valent, una herramienta publicada por Scribe Security. Cualquiera que sea la herramienta de verificación de señales que termine utilizando, la idea es asegurarse de que la integridad del archivo de instrucciones permanezca intacta.
Envenenamiento de caché/dependencias – Los flujos de trabajo de canalización de CI/CD se utilizan con frecuencia para especificar acciones particulares que se deben realizar. Cada flujo de trabajo se compone de una serie de uno o más trabajos, que se caracterizan como una secuencia de acciones. La mayoría de los flujos de trabajo no comparten recursos por razones de seguridad. Sin embargo, existen soluciones para cuando sea necesario compartir recursos. Una de esas soluciones es una caché a la que todos los flujos de trabajo puedan acceder por igual. Dado que el caché es compartido por varios flujos de trabajo, solo se necesita una infracción en un flujo de trabajo con autoridad para modificarlo para que el caché se vuelva venenoso para todos los usos posteriores del flujo de trabajo. un solo caché envenenado puede estar activo durante mucho tiempo, lo que afecta innumerables iteraciones de compilaciones de software que se ejecutan en ese proceso, ya que el caché solo se actualiza cuando hay un nuevo artefacto o paquete para descargar.
Al igual que en la verificación del archivo de instrucciones de la canalización, puede utilizar valent para firmar y luego verificar su caché o una carpeta que contenga todas las dependencias aprobadas previamente que requiere su canalización. Si es del tipo paranoico, permitir que su canalización se conecte de forma independiente a Internet y descargue las bibliotecas que considere necesarias es una forma segura de obtener más vulnerabilidades y posibles exploits en su compilación final.
Las claves SSH – Una clave SSH es una credencial de acceso al protocolo de red SSH (secure shell). Este protocolo de red se utiliza para la comunicación remota entre máquinas en un red abierta no segura. SSH se utiliza para la transferencia remota de archivos, la administración de redes y el acceso remoto al sistema operativo. Con claves SSH, por ejemplo, puedes conectarte a GitHub sin proporcionar tu nombre de usuario y token de acceso personal en cada visita. También puedes usar una clave SSH para firmar confirmaciones. También puedes conectar otras aplicaciones a tu GitHub usando claves SSH como BitBucket y GitLab.
Para mantener la seguridad de la cuenta, debe revisar periódicamente su lista de claves SSH y revocar/eliminar cualquier clave que no sea válida o que haya sido comprometida. Para GitHub, puede encontrar su lista de claves SSH en la siguiente página:
Access ajustes > Claves SSH y GPG
Una herramienta que puede ayudarle a mantenerse al tanto de sus claves SSH es un informe de postura de seguridad de código abierto llamado GitGat. El informe de GitGat le avisará si alguna de sus claves SSH configuradas ha caducado o no es válida. Además de vigilar de cerca tus claves y rotarlas con frecuencia, GitHub advierte que si ves una clave SSH con la que no estás familiarizado, elimínala inmediatamente y contacta Soporte de GitHub para obtener más ayuda. Una clave pública no identificada puede indicar una posible violación de seguridad.
Procedencia de SLSA como registro de canalización inmutable – SLSA significa Niveles de cadena de suministro para artefactos de software, que es un marco desarrollado por Google y otros socios de la industria para ayudar a mejorar la seguridad y la integridad de las cadenas de suministro de software.
SLSA define un conjunto de cuatro niveles, cada uno de los cuales representa un mayor nivel de confianza y seguridad en la cadena de suministro de software. Cada nivel es un incremento creciente de requisitos de seguridad. Un requisito importante es la necesidad de la procedencia del archivo. Para el marco SLSA,
La procedencia es la información verificable sobre los artefactos de software que describen dónde, cuándo y cómo se produjo algo. Dado que la mayor parte del propósito de una canalización de CI/CD es producir algo (generalmente una compilación), ser capaz de rastrear exactamente qué archivos entraron y qué les sucedió es una especie de registro de máquina infalsificable de la canalización. Para ello, es importante que la procedencia SLSA se cree independientemente de cualquier usuario. La integridad de cualquier cosa que un usuario pueda interrumpir o modificar puede ser sospechosa.
Una herramienta que le permite crear una procedencia SLSA en su canalización para una gran variedad de sistemas SCM es valent (sí, la misma herramienta de Scribe; es una herramienta muy versátil). El enlace le mostrará cómo conectar Valint a su canalización de GitHub para generar una procedencia SLSA para cada compilación ejecutada en esa canalización. Luego podrá acceder a cada archivo de procedencia y verificarlo para ver si sucedió algo adverso o inesperado. Aquí hay un fragmento de dicho archivo de procedencia:
El archivo de procedencia es solo un archivo JSON, pero como no existen herramientas automatizadas para leer archivos de procedencia (todavía), el trabajo de leerlos e interpretarlos recae en usted.
Asegurando su resultado final – Una de las violaciones de la cadena de suministro de software más conocidas en los últimos tiempos es la Incidente de SolarWinds. En él, los piratas informáticos modificaron parte del código en el servidor de compilación para que cada compilación lanzada por la empresa contuviera una puerta trasera secreta. Otro caso famoso de corrupción del resultado final se puede ver en el hack de la Autoridad de Certificación del Gobierno de Vietnam (VGCA) en 2020 denominado Operación SignSight. Los intrusos se infiltraron en el sitio web de VGCA y redirigieron enlaces de descarga a su propia versión del software, plagada de malware. En ambos casos, los usuarios finales no tenían forma de verificar que el software que obtuvieron era el software que la empresa productora pretendía lanzar.
Un ataque más simple podría ser sustituir la imagen final creada al final del proceso por una maliciosa y cargar la imagen defectuosa donde sea necesario. Dado que en la mayoría de estos ataques la imagen supuestamente proviene de la empresa productora, incluso si esa empresa está protegida por un certificado válido, no es suficiente. Simplemente haría que la falsificación fuera mucho más creíble.
Una vez más, la solución es firmar criptográficamente cualquiera que sea el artefacto final producido por la canalización y permitir que el usuario final verifique esa firma.
Como ya lo mencioné valent Sugeriré el uso del código abierto. Cosigno de Sigstore. Cosign tiene como objetivo facilitar la firma eliminando la necesidad de infraestructura clave. Permite al usuario utilizar su identidad verificada en línea (como Google, GitHub, Microsoft o AWS) como clave. Puede utilizar Cosign para firmar y verificar imágenes, lo que lo hace ideal para firmar y verificar posteriormente la imagen final construida de una tubería.
Ya sea que elija utilizar Valint o Cosign, permitir a sus usuarios verificar una firma criptográfica en su artefacto final para asegurarse de que obtengan exactamente lo que pretendía entregar es una idea que estoy seguro que la mayoría de los usuarios finales apreciarían.
Seguridad de tuberías en el futuro
Por supuesto, hay otros elementos involucrados en un proceso de construcción que podrían beneficiarse de una mayor seguridad. En este artículo, elegí analizar algunos de los elementos más obvios y más vulnerables del oleoducto.
Cualquiera que sea la infraestructura o las herramientas de canalización que esté utilizando, asegúrese de estar atento a la posibilidad de una infracción. Nunca confíes ciegamente en ningún sistema que te diga que es completamente seguro.
Teniendo en cuenta la creciente amenaza del robo de identidad, el phishing y otras formas de falsificar el acceso legítimo, creemos que el mecanismo de verificación de signos es una herramienta buena y versátil que puede tener en su caja de herramientas digital.
Ya sea que necesite firmar una imagen, un archivo o una carpeta, lo invito a que eche un vistazo más de cerca a Valint de Scribe Security como una herramienta integral para tales necesidades.
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
