Better Security in the Development and Operations Pipeline

By Dan Williams
Contributor, InCyberDefense

Breach after breach, the same stories are told of gaps in security policy, misconfigured services, social engineering attacks, and inarguably the most difficult source of exploitation to manage: software vulnerabilities.

Protecting vulnerable software relies heavily on the “defense-in-depth” method of layered security controls to compensate for discovered flaws while a patch is quickly devised to remediate these vulnerabilities. Programming already requires developers to have a high aptitude and leverage their skillsets to create systems that support the business logic of organizations. As a result, hardening software pre-release may seem even more difficult and time-consuming when a project deadline is quickly approaching.

The pressure to push a software product to a customer on time typically leads to unintentional flaws. That same software contains the inevitable security vulnerability that sits silently, waiting to be discovered by a threat actor when we least expect it.

Where Does Security for Developers Begin?

Luckily, “Development and Operations” (“DevOps”), software development and deployment, consisting of practices and tools to expedite the necessary processes, has increased workplace efficiencies drastically.

Now, there are automation suites that push source code from development environments to repositories. These suites run custom tests to verify a software product’s desired functionality, and this production environment is becoming more common for organizations that have shifted to DevOps software development and deployment.

But prior to implementing the latest silver bullet for testing software, a fundamental concept for developing secure software has to be considered at the beginning of the development stage when developers are writing code. The Open Web Application Security Project (OWASP) has created a cheat sheet that developers can utilize as a means of developing more secure software; this checklist can reduce both the number of errors detected in testing as well as overall vulnerabilities.

Secure Coding Frameworks and Methods

Static websites are quickly being replaced by web applications that do more than simply serve up web content; these applications offer an interactive level of functionality for website users to utilize various services. With the additional level of sophistication and components required by these services, there is an increased amount of security risk associated with publicly accessible web applications.

Why is there an increased security risk? It’s simple: the more moving parts a website has, the more things that can break. Should a threat actor uncover a vulnerability in a web application, this weakness is then exploited and can lead to anything from massive financial losses to the compromise of sensitive customer data.

Fortunately, OWASP curates a list of the top 10 most prominent web application vulnerability types. Based on industry consensus regarding the criticality of web application attack types, developers can easily prioritize their coding practices by being mindful of potential vulnerabilities they can introduce into their web application through poor coding practices.

The good news is that rather than relying on static source code analysis conducted during the peer-review stage, there are security testing options for critical vulnerabilities in web applications that uphold the spirit of DevOps in terms of automation.

Pipeline Security: Only as Good as Your Testing

To rapidly test and deploy higher-quality software into production environments, the idea of Continuous Integration and Continuous Delivery (CI/CD) “pipelines” has allowed developers to create an automated end-to-end process for performing various analysis and deployment tasks.

One example would be the popular CircleCI platform. This platform can be triggered by a message known as a “webhook” to accept newly published source code from a repository such as GitHub and subject that source code to a battery of tests to validate its desired functionality. Fortunately, the concept of security has been taken a step further in this type of automated testing by tools such as OWASP’s Zed Attack Proxy (ZAP) project.

To reduce time-to-production and add value by expediting the security testing process, ZAP has been configured as a Docker container that can be easily implemented into the CI/CD pipeline. Usually, that requires a pull and configuring the testing platform to include that image in its processes.

Rather than conducting conventional application penetration tests on an annual schedule, this concept of Test-Driven Scanning (TDS) that occurs during every iteration of software substantially reduces the attack surface created by web applications every time that software is deployed.

In regard to where the security of more traditional web services can be better managed at the host level, it is imperative that web application vulnerabilities be managed by developers using automated testing in the pipeline process. Rather than having cybersecurity addressed as an afterthought in production by security teams, developers can reduce the likelihood of a successful exploit by a threat actor, creating fewer episodes of reactive responses by security teams.

This practice allows security teams to focus on more proactive efforts, such as threat modeling and testing infrastructural security controls. Also, it fosters a culture that supports the eradication of barriers created by the departmental siloing of IT teams.

Embracing Secure CI/CD

The idea behind automated security testing is to not only integrate scanning for the most prominent security vulnerabilities in web applications but also to remove the burden of manually scrutinizing code for the developer. Relying on the peer-review process to identify vulnerabilities in source code leaves software further exposed to threats due to unavoidable human error.

Preventing security incidents caused by poorly developed code that was rushed into production is a level of due diligence that has previously been seen as nearly impossible to contend with.

Taking advantage of the latest automation technologies is only one means by which DevOps can add tremendous value, not only for creating leading-edge products but also adding security to the services we offer our clients. We should take it as a life lesson learned at this point in software development history that catching security vulnerabilities during the development stage is much more desirable than letting a threat actor catch them for us in production.

About the Author

Dan Williams is an Information Security consultant with experience as a five-year veteran of the U.S. Marine Corps and over 15 years in IT operations. Dan’s career has spanned various specializations to include systems analysis, network monitoring and defense, software development, and cloud engineering solutions, all with a central theme of security administration and strategic cyber intelligence.

Dan has a bachelor’s degree in information systems security and a master’s degree in cybersecurity studies, and he is a Systems Security Certified Practitioner through the (ISC)². More recently Dan’s focus as a consultant has been on conducting research regarding DevOps security practices and cloud infrastructure penetration testing and vulnerability assessments to maintain pace with threats towards advancing and quick-adopting technologies. On a volunteer basis, Dan mentors future and junior cybersecurity personnel in both an academic setting and in the workplace to offer guidance to the next generation of Information Security professionals.