In this DevOps revolution, we are trying to make everything continuous: continuous integration, continuous deployment, continuous monitoring--the list goes on. One term you rarely hear, however, is continuous security, because it is often seen as an afterthought when building and implementing a delivery pipeline. The pipeline I will be discussing has six components: plan, code, build, test, release, and operate. There is also a seventh, less-formal component, which is the iterative nature of the delivery pipeline in a DevOps environment. Security can, and should, be implemented throughout the pipeline. In this blog post, I discuss how security can be implemented in all components, as well as what benefits come from implementing security in each of those components.

1. Plan. When starting a new application development project, or picking up on existing development, the first step is planning. At this stage, the most important thing to do is to stress to your team the importance of writing secure code. You should design the current phase of development around security. Doing so will get you and your team moving in the right direction, and prioritizing security right from the start makes it much easier to include more security later.
2. Code. Shortly after you start planning, you will start filing coding tasks and developers will begin working on them. At this stage, the development team should make security a focus and should follow secure coding practices. During code reviews, be sure to check for insecure coding practices to help ensure the security of your application and to help educate your team on secure coding. Secure coding checks will have an immediate positive impact and an even bigger payoff in future projects or phases of development.
3. Build. This is where security is most commonly integrated into a delivery pipeline. During the build component, you can add test attacks specific to your application with a tool like Gauntlt, and you can test your application for the most common vulnerabilities using OWASP Zed Attack Proxy. The post "Adding Security to your DevOps Pipeline" walks you through setting up these two tools on your own build server. Since this approach is becoming common practice, I am not going to focus on this part of the pipeline.
4. Test. You might assume your automated testing process would hit the security of your application hard. However, such testing generally consists of usability tests, unit tests, and integration tests. Typically, these automated tests do not examine the security of the application. Consequently, it's best for your team to test security manually. This phase is a great place to run application-specific penetration tests. The prerequisite, here, is that your team must write the penetration tests in a way that renders an expected outcome and toned not be refactored often. Being able to perform automated, application-specific penetration tests can help you meet the requirement for several compliance agencies (i.e., HIPAA and PCI).
5. Release. During the release phase, you are pushing your code to your staging and production environments, which is where all your security work finally pays off. Note that you definitely do not want to be testing for security in your production environment. Rather, penetration testers and the quality assurance (QA) team should perform manual testing in the staging environment. These tests should include security tests, and it is very important for your staging environment to be exactly the same as your production environment. The benefit of implementing security tests in your staging environment is that you will be able to stop those vulnerabilities from being pushed into production.
6. Operate. This component involves managing your application in production. Here, you will have several monitoring tools that provide insight on how your application is performing. You can leverage the information obtained from these tools to determine how secure your application is and what you can do to improve its security. Many monitoring tools offer information like data leakage, number of application visits, and origin location for those visits. This information can then be used in the next planning phase, and the application will become more secure through its iterations.
7. Iterate. The seventh (unofficial) component is the iterative nature of the DevOps movement. This component will truly improve security because it's a constant focus throughout the pipeline. As your team iterates through code revisions with security in mind and security checks conducted at each iteration, it will identify and resolve security issues. Therefore, after several iterations you will have found most of the vulnerabilities in your application and can move forward with greater confidence in the security of your application. As you may have noticed, incorporating security into planning and coding makes it much easier to implement security later on in your delivery pipeline.

In conclusion, the next time you start a new phase of development for one of your projects or start a brand new one, make sure you make security a focus. The tools and the automation will make it a breeze and you will be amazed with how quickly your application becomes secure.

Additional Resources

View the webinar DevOps Panel Discussion featuring Kevin Fall, Hasan Yasar, and Joseph D. Yankel.

View the webinar Culture Shock: Unlocking DevOps with Collaboration and Communication with Aaron Volkmann and Todd Waits.

View the webinar What DevOps is Not! with Hasan Yasar and C. Aaron Cois.

Listen to the podcast DevOps: Transform Development and Operations for Fast, Secure Deployments featuring Gene Kim and Julia Allen.

Read all of the blog posts in our DevOps series.