Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
2 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Impact 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. Given by the following substitution examples: using parameters using image tag using entrypoint as a shim for commands 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…
Recommended action: Upgrade to 0.23.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Some current default configurations for Vela allow exploitation and container breakouts. Default Privileged Images Running Vela plugins as privileged Docker containers allows a malicious user to easily break out of the container and gain access to the worker host operating system. On a fresh install of Vela without any additional configuration, the target/vela-docker plugin will run as a privileged container, even if the Vela administrators did not intend to allow for any privileged plugins, and even if the vela.yml configuration file does not use the privileged = True flag. Privileged containers permit trivial breakouts, which can pose significant risk to the environment in which Vela is running. Default Allowed Repositories On a fresh install of Vela, anyone with a GitHub account (or other enabled source control management solution) is allowed to enable a repository within Vela and run builds. This means that, if a Vela instance is accessible to the public, a third party…
Recommended action: Upgrade to 0.16.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.