CI/CD series - Qualys: Continuous deployment & security – how to avoid blockages

This is a guest post for the Computer Weekly Developer Network in our Continuous Integration (CI) & Continuous Delivery (CD) series.

This contribution is written by Marco Rottigni, chief technical security officer EMEA at Qualys – the company is known for its cloud security, compliance and related IT asset discovery services.

Rottigni reminds us that developers have been adopting CI/CD to speed up getting software through their work pipelines. This has led to faster code pushes taking place, which in turn has led to more updates getting made. Rather than months or weeks to develop new updates, teams can push out new updates in days or hours.

For the largest and most automated businesses, multiple updates can be taking place every day. In 2014, AWS estimated a new release took place every second.

Rottigni writes…

Now, not every business works at the scale and speed of Amazon. However, most companies are in the process of trying to speed up their release process. DevOps teams are in place at most companies – according to Statista, only nine percent of companies were not adopting DevOps in some way. However, in the rush to improve CI/CD pipelines, it’s easy to miss security.

The challenge with implementing ever faster CI/CD processes is that they move whatever is inside through to production faster. When everything is working well, this means great code and new features out for the business. When it is not – and when people come under more pressure to deliver new features faster without thinking them through – it is all too easy for faults to slip through. For IT security teams, stopping these faults making their way through to production is an essential goal to reduce risk and meet compliance goals. However, it’s no longer a case of IT security being able to block everything. Instead, more collaboration is needed between DevOps teams and security.

Continuous security

With so many changes coming through, security can’t just act as a gatekeeper at the end of the process. Instead, security has to get embedded into the whole approach to development. What does this mean in practice?

Embedding security into development involves making the tools used for tracking security vulnerabilities easy to consume within the software development pipeline. Rather than providing these tools separately, they should instead provide any necessary updates or recommendations directly into the developer environment. This makes it easier for the developers to consume this information in the same way as other bugs or feature requests, then go about fixing them.

This feed of data on software vulnerabilities and potential issues will need to be prioritised based on the severity of the issues, how widespread those issues are, and the risk levels associated with them. For example, a problem in an application may only be present in one specific circumstance and for a small subset of customers – in this instance, the risk profile may be low. Equally, a problem may be widespread, easy to exploit and need fixing rapidly.

These serious issues can then be pulled higher up the priority list for developers, rather than relying on the security team to flag the risk.

Automation situation

Similarly, CI/CD pipelines rely on automation in order to achieve results quickly and deliver releases out quickly. Security teams can support this process through providing data into that pipeline to guide developer teams when it comes to improvements that are needed and where potential issues have been discovered. Automating the discovery process around new vulnerabilities is one option, but it can quickly lead to security alert overload.

Providing prioritisation data based on what IT assets exist in the development and production environments can help the development team further. This makes it easier for security to provide the right data and to help streamline the work around fixing issues. This is particularly important for cloud and container environments that change regularly. Containers can be spun up from base images quickly, work for a time and then ben torn down or deleted. In a CI/CD pipeline, those base images should be kept up to date and tracked for potential issues. However, they can easily be updated with additional code added to images over time that is not sanctioned or can be out of date compared to potential issues. Tracking this process and checking that all images are managed properly should be a priority, but building this into the wider pipeline process can help.

With so many changes taking place over time, driven by the CI/CD pipeline, the aim for security is to provide developers with the ability to deliver all the necessary value to the business while controlling all the risk involved too.

Using a mix of security vulnerability data, IT asset information and integration, security can support CI/CD pipelines to be more effective and more secure at the same time.

Rottigni: it pays to build a ‘wider pipeline process’