This blog was written by an independent guest blogger.
When it comes to productivity, agility, and efficiency - continuous integration/continuous delivery (CI/CD) pipelines are great. When it comes to ensuring cybersecurity, they leave a lot to be desired. In fact, and especially given the popularity of CI/CD pipelines now, securing continuous environments might turn into the most important security challenge of the next decade.
Some of the managerial and legal tools that will be used to meet this challenge are already available. Advanced vulnerability management programs are now able to deal with continuous environments by default, and the IoT cybersecurity act that has just been signed into law contains provisions that specify the liability of developers in the event of an embedded device getting hacked.
On the technical side, however, cybersecurity has yet to catch up with the flexibility and complexity of CI/CD pipelines. In this article, therefore, I want to sketch a holistic way forward: a roadmap for how these environments can begin to be secured in the years to come. This roadmap contains five main pillars:
1. Leadership
First, and arguably most importantly, finding security vulnerabilities in your CI/CD pipeline requires brave, involved, and forward-thinking leadership. The central challenge of CI/CD pipelines, from a cybersecurity perspective, is that they are constantly evolving. Security solutions that were developed for the environment of three years ago no longer offer adequate protection.
In response, leaders need to inspire every member of an organization to adopt the DevSecOps mindset, in which every individual who interacts with a piece of software takes responsibility for its security. This means that managers need to put in place systems and processes through which developers can work with operations staff and through which software can be designed in a way that all key stakeholders know the risks it is exposed to.
In addition, leaders should take a long-term view of security in their organizations. CI/CD pipelines provide a great deal of flexibility when it comes to software design and development, but they also require (at least) a three-year, horizon-scanning approach to security flaw identification.
2. Design for DevOps
A related point to the one above is that developers must ensure that the code they write and ship via their CI/CD pipelines is designed for the DevOps approach. This means that all source code should be pre-checked with static analysis tools prior to committing to the integration branch. This verifies that it does not introduce critical code vulnerabilities into real world software.
This is particularly important today, because of the range of devices on which the average piece of software is deployed. One of the main promises, and advantages, of CI/CD pipelines is that they allow developers to work in a way that is platform-agnostic. However, this can sometimes blind them to the sheer range of places in which their code will eventually be deployed and potentially exposed to attack.
Of particular concern here is the (sometimes unauthorized and often unexpected) deployment of code on smartphones. In 2020, we passed a notable watershed – for the first time in history, the majority of internet traffic originates from cell phones. Given this, it seems absurd that the majority of software is still written, by default, for desktop environments. Making sure that code is thoroughly tested before being shipped is one solution to this problem.
3. Continuous testing
Extending this idea of rigorous testing a little further, we can see that continuous integration is also going to require continuous testing. On a basic level, this means that all new code should be continuously benchmarked using regression tests, and every potential security flaw marked for follow up by the security team (or, better yet, the DevSecOps team).
At a more fundamental level, however, continuous testing also means that the novel tests that are necessary for a new piece of code should be shipped with the code itself. It is no longer enough to train developers on secure coding – they also need to be trained on how to test the security of their own code.
4. Continuous monitoring
Once a continuous testing process is in place, it may be extended to form a tool (or a set of tools) for continuous monitoring. This is particularly crucial for firms that have embraced the Infrastructure as Code (IaC) model, because in these environments the dynamic nature of the (largely virtual) infrastructure on which code runs can quickly create gaping security holes despite well designed software-defined perimeters.
Firms will therefore need to develop monitoring systems that take into account the dynamic nature of artifacts and infrastructure and the proliferation of objects and services that need to be secured. These systems should also be able to report on a number of key metrics – the number of security defects identified pre-production; the percent of code coverage from security testing; the number of failed builds due to security checks; the mean time to detection; and the mean time to resolution.
5. Elastic infrastructure
Finally, the key insight of the IaC model – that it is no longer necessary to work with infrastructure separately from the code designed to run on it – should be extended to the security of these same systems. The danger of not doing this has recently been highlighted in a number of reports on cybersecurity in healthcare, which point to the vulnerabilities that can be introduced into medical devices via firmware updates, if these updates do not take into account the often obscure systems that are in use in the sector.
The solution, here, is to develop elastic infrastructure environments in which security-approved OS, software versions, and frameworks are used to compose the required infrastructure. Security-related controls such as access control lists (ACLs) and File Integrity Monitoring (FIM) should also be defined as a part of infrastructure in order to ensure integrity across hardware environments.
The future
When it comes to protecting CI/CD environments, we are still at the very beginning of a long journey, and it may be that an integrated set of best practices soon arise that can handle the complexity of these systems. But for now, and as the US Small Business Administration points out, prevention is better than curing. For every hour we spend making our CI/CD pipelines more efficient, we should spend another making sure they are secure. Only in this way can we hope to avoid a difficult decade.