Vela is a Pipeline Automation (CI/CD) framework built on Linux container technology written in Golang. Vela pipelines can use variable substitution combined with insensitive fields like `parameters`, `image` and `entrypoint` to inject secrets into a plugin/image and — by using common substitution string manipulation — can bypass log masking and expose secrets without the use of the commands block. This unexpected behavior primarily impacts secrets restricted by the "no commands" option. This can lead to unintended use of the secret value, and increased risk of exposing the secret during image execution bypassing log masking. **To exploit this** the pipeline author must be supplying the secrets to a plugin that is designed in such a way that will print those parameters in logs. Plugin parameters are not designed for sensitive values and are often intentionally printed throughout execution for informational/debugging purposes. Parameters should therefore be treated as insensitive. While Vela provides secrets masking, secrets exposure is not entirely solved by the masking process. A docker image (plugin) can easily expose secrets if they are not handled properly, or altered in some way. There is a responsibility on the end-user to understand how values injected into a plugin are used. This is a risk that exists for many CICD systems (like GitHub Actions) that handle sensitive runtime variables. Rather, the greater risk is that users who restrict a secret to the "no commands" option and use image restriction can still have their secret value exposed via substitution tinkering, which turns the image and command restrictions into a false sense of security. This issue has been addressed in version 0.23.2. Users are advised to upgrade. Users unable to upgrade should not provide sensitive values to plugins that can potentially expose them, especially in `parameters` that are not intended to be used for sensitive values, ensure plugins (especially those that utilize shared secrets) follow best practices to avoid logging parameters that are expected to be sensitive, minimize secrets with `pull_request` events enabled, as this allows users to change pipeline configurations and pull in secrets to steps not typically part of the CI process, make use of the build approval setting, restricting builds from untrusted users, and limit use of shared secrets, as they are less restrictive to access by nature.
Vela es un marco de automatización de tuberías (CI/CD) construido sobre tecnología de contenedores de Linux escrita en Golang. Los pipelines de Vela pueden usar sustitución de variables combinada con campos insensibles como "parámetros", "imagen" y "punto de entrada" para inyectar secretos en un complemento/imagen y, mediante el uso de manipulación común de cadenas de sustitución, pueden evitar el enmascaramiento de registros y exponer secretos sin el uso de el bloque de comandos. Este comportamiento inesperado afecta principalmente a los secretos restringidos por la opción "sin comandos". Esto puede provocar un uso no intencionado del valor secreto y un mayor riesgo de exponer el secreto durante la ejecución de la imagen sin pasar por el enmascaramiento del registro. **Para explotar esto**, el autor de la canalización debe proporcionar los secretos a un complemento manipulado de tal manera que imprima esos parámetros en los registros. Los parámetros del complemento no están manipulados para valores confidenciales y, a menudo, se imprimen intencionalmente durante la ejecución con fines informativos/depuración. Por lo tanto, los parámetros deben tratarse como insensibles. Si bien Vela proporciona enmascaramiento de secretos, la exposición de secretos no se resuelve por completo mediante el proceso de enmascaramiento. Una imagen acoplable (complemento) puede exponer secretos fácilmente si no se manejan adecuadamente o se modifican de alguna manera. El usuario final tiene la responsabilidad de comprender cómo se utilizan los valores inyectados en un complemento. Este es un riesgo que existe para muchos sistemas CICD (como GitHub Actions) que manejan variables confidenciales de tiempo de ejecución. Más bien, el mayor riesgo es que los usuarios que restringen un secreto a la opción "sin comandos" y usan restricción de imágenes aún puedan exponer su valor secreto a través de modificaciones de sustitución, lo que convierte las restricciones de imágenes y comandos en una falsa sensación de seguridad. Este problema se solucionó en la versión 0.23.2. Se recomienda a los usuarios que actualicen. Los usuarios que no puedan actualizar no deben proporcionar valores confidenciales a los complementos que potencialmente puedan exponerlos, especialmente en los "parámetros" que no están destinados a ser utilizados para valores confidenciales, asegúrese de que los complementos (especialmente aquellos que utilizan secretos compartidos) sigan las mejores prácticas para evitar el registro de parámetros. que se espera que sean confidenciales, minimice los secretos con los eventos `pull_request` habilitados, ya que esto permite a los usuarios cambiar las configuraciones de canalización e incorporar secretos a pasos que normalmente no forman parte del proceso de CI, utilice la configuración de aprobación de compilación y restrinja las compilaciones que no sean de confianza, usuarios y limitar el uso de secretos compartidos, ya que su acceso es menos restrictivo por naturaleza.
