Pipeline reliability and security

Reliable pipelines don't just happen. It takes careful planning and commitment to minimize risk and ensure consistent performance. Here are some of the things we’ve learned when it comes to setting up reliable pipelines. 

When versioning, don’t (just) rely on main or latest – those are moving targets. Use fixed versions instead to guarantee that your pipeline uses the exact code you've tested and approved. For example, GitHub recently announced that the ubuntu-latest tag will switch from ubuntu-22.04 to ubuntu-24.04 - which could cause issues that are fully avoidable. 

Just like your actions and steps, you also need to specify the version of the runners (GitHub Actions) or agents (Azure Pipelines) that execute your pipelines. This means pinning your pipelines to use specific versions of the runner or agent image, similar to how you pin actions and steps to tags or commit SHAs. Specify the exact version you want to use. This seemingly small detail can prevent compatibility issues caused by updates to the underlying infrastructure. 

Besides versioning, code reviews also aren’t just for application code. Your pipelines deserve the same level of scrutiny. Require peer reviews and approvals for all pipeline changes. This extra set of eyes can catch potential errors, ensure consistency, and enforce your team’s best practices. 

If you're using GitHub Actions, consider using GitHub Apps for authentication instead of Personal Access Tokens (PATs). Unlike PATs, GitHub Apps don't expire, saving you the hassle of constantly renewing tokens and preventing interruptions to your pipelines. Additionally, the tokens generated by GitHub Apps are less susceptible to leakage. Note that it's critical to securely manage the private key associated with your GitHub App, as a leaked private key can pose a significant risk. 

For those mission-critical pipelines or custom-developed actions, think about adding unit tests. Yes, pipelines can have unit tests too! This extra layer of validation verifies that your workflows are working as intended, catching potential problems before they reach production. Besides pipelines, this gives you an extra safety net for any code or infrastructure managed within your CI/CD workflows. 

Your pipelines handle sensitive data and have access to your infrastructure, so keeping them secure is obviously in your best interest. 

In GitHub Actions, be cautious about third-party actions. We suggest restricting usage to actions verified by GitHub, or even better, create an allow list of approved actions within your organization or enterprise. This minimizes the risk of running untrusted or potentially malicious code. If you’re a GitHub Enterprise user, here's where you can set this up: 

As always, keep the principle of least privilege in mind when it comes to pipeline permissions. Only grant the absolute minimum access required for your pipelines to function. Tools like the Monitor and Advisor Actions by GitHub can help you determine the appropriate level of access and keep track of their usage. 

Finally, secret scanning is your best friend for preventing sensitive information from leaking into your repositories. If you're using Azure Pipelines, integrate secret scanning into your pipelines to automatically detect and flag any secrets that might have accidentally slipped into your code. With GitHub Advanced Security (also available for Azure DevOps), you can go a step further: you can block commits that contain secrets from entering version control altogether, preventing exposure from the outset. 

While most best practices apply across the board, GitHub Actions and Azure Pipelines have their own quirks and terminology, particularly in how they structure deployments. For example, while both platforms use the concept of environments (e.g., development, testing, production), they implement them differently. Azure Pipelines uses a higher-level concept called "stages" to group jobs, and environments are defined within these stages. In GitHub Actions, environments are typically defined at the job level, without the presence of explicit stages. 

Whatever you call them, the key is to implement control gates or checks at each stage/environment. This ensures that deployments proceed only when specific conditions are met, such as passing tests or receiving approvals. It will help prevent untested or unapproved changes from reaching your users. 

GitHub Actions tends to be more transparent with its actions, as they’re often open-source and publicly auditable. Azure DevOps extensions can be a bit more opaque, although many link to public GitHub repositories nowadays. Regardless of the platform, understanding what your actions or steps are actually doing is critical for maintaining security and reliability. Don't just run something! 

Want a more in-depth comparison? We’ve covered the differences between GitHub and Azure DevOps in a previous blog post. 

Reliable and secure pipelines are essential for any successful DevOps operation. By implementing the practices we've discussed, you’ll build robust CI/CD workflows that you can trust.

In the next blog post, we’ll shift our focus from security and reliability to speed, sharing efficiency tips to supercharge your pipelines and accelerate your delivery process. 

Looking to integrate GitHub Actions or Azure DevOps into your workflow? Send us a message, we'll gladly help you out!