The CI/CD (Continuous Integration & Deployment) tools are a widely adopted part of automated delivery processes in the software development industry. Tools like Travis CI are used for building, testing, and deploying software automatically. They’ve also become a recognized attack surface for threat actors, for which logs from such automated builds may be particularly interesting in search for exposed secrets. Securing build process outputs, particularly in the case of public repositories, is a factor each developer or team should consider when setting up their CI/CD recipes. The role of CI/CD tooling is to support the security of the build pipeline outputs.
-
Improved CI/CD Build Job Log Security
-
Sign your software with Travis CI
Software Supply Chain security is the act of securing the components, activities, and practices involved in creating and deploying software. One of these practices is digitally signing the software by the developers before releasing it. The digital certificate serves the purpose of ensuring that the software has not been tampered with and the receiver can safely download it.
Now, before you deploy your software with a CI/CD system, you can securely sign it using Travis CI.
-
Deploying with Surge.sh
Got some static files? Travis CI can deploy your static files to Surge.sh after a successful build. Builds triggered from Pull Requests will never trigger a deploy, let’s see how we can make this happen.
-
Complex Build Commands
Sometimes if you have a complex build environment that is hard to configure in the
.travis.yml
, consider moving the steps into a separate shell script. The script can be a part of your repository and can easily be called from the.travis.yml.
-
Travis CI Now Introduces Changes in Job Logs Availability
Travis CI job logs provide important information on executing specific jobs in a build. In addition, build job logs contain supplementary information, such as environment variables names and values, as well as custom debug outputs defined by the users. These debug outputs and unencrypted variables may hold vulnerable secrets (credentials, tokens). As a result, running builds in public repositories could lead to unintended and overlooked exposure of vulnerable information. To minimize risks, Travis CI introduces limits on how long and for whom the job logs will be available. These limits are configurable.
-
Use your own Hashicorp Vault instance with Travis CI
Now there’s even more ways to secure all your secrets with Travis CI that’s needed for your pipeline. If you prefer to manage secrets needed for CI/CD processes in a central Key Management System (KMS), e.g. to be able to rotate them quickly rather than providing secure environment variables to the CI/CD tool, you can now easily connect Travis CI with Hashicorp Vault.
-
Conditional Builds, Stages and Jobs
Sometimes you need to filter out and reject builds, stages and jobs by specifying conditions in your build configuration (your
.travis.yml
file). With conditionals, you can do that and more, let’s explore the full functionalities of Conditional Builds.
-
Ubuntu Jammy Jellyfish 22.04 is available!
We are happy to announce that Ubuntu Jammy Jellyfish 22.04 images are ready for a wider audience. Here are some tips to get you started quickly and save valuable time.
-
Travis CI Build Explorer
Ever want to know where you went wrong when configuring your
.travis.yml
file? You should try Travis CI Build Explorer. Travis CI build config format is formally specified using a JSON Schema. Travis CI uses this specification to normalize and validate build configs, let’s do a sample.
-
Travis Workspaces
Workspaces allow jobs within a build to share files. They are useful when you want to use build artifacts from a previous job; for example, you create a cache that can be used in multiple jobs later.