DEVOPSdigest

The consequences of a software security breach can be crushing. Beyond violating legal and regulatory requirements that carry an enormous price for non-compliance, you have a responsibility to protect your customers and their data, as well as your own data and systems. If you don't take the right precautions, you are putting your customers, your business, and your reputation at risk.

Security vulnerabilities always exist, but they haven't always been adequately addressed by software delivery teams. The best way to prevent them is to test the software for potential weaknesses and fix those weaknesses before software is released. Until recently, security testing, if done at all, was an afterthought with little, if any, attention paid to the production environment.

DevOps and Security

Over the last few years, there has been a greater awareness of security among the DevOps community. Because DevOps strives to deliver value quickly to the customer, it has the potential to unintentionally introduce vulnerabilities quickly as well. This spurred DevOps teams to include security testing as part of continuous testing, increasing the sense of shared responsibility for security.

As the team members think about the software's design, they should consider the potential security weaknesses and vulnerabilities that the design might expose. DevOps teams should include security criteria for each user story and test it as part of their automated continuous testing cycles. As the software, its components, and its configuration makes its way through the deployment pipeline, security tests continue to run, and if any vulnerabilities are detected at any stage, the team will be alerted and can fix the issue. When testing is continuous, the change that introduces a vulnerability will be readily identified and can be fixed quickly.

When the software is deployed, additional security tests are run, and the software in production is monitored for vulnerabilities resulting from configuration changes, software updates, and environment changes.

This concept of infusing security into the mindset and the processes of software delivery is often called "DevSecOps." Since developers, testers, and operations staff are all part of the same DevOps team, they must all take responsibility for their software's security, from design through development, and out into production.

How to Integrate Security into DevOps

Here are some practical steps that teams can take to introduce security into their DevOps pipelines, making them DevSecOps pipelines.

Train developers and testers on security

Your team needs security expertise, but most organizations don't have enough security staff to be part of each DevOps team. Train your developers and testers so that they are aware of security considerations, and understand how they should be approaching design, coding, code reviews, and testing from a security perspective. Encourage one or two members of the team to take on an enhanced role as a security champion within the team to ensure that security and regulatory compliance is always part of the conversation.

A security-conscious team should consider regular threat modeling sessions. Threat modeling involves thinking like a hacker. Enable your teams to proactively look for weaknesses in the design of an application and its components and think through how the components communicate with each other. This can be an effective way of uncovering architectural weaknesses during design.

Use automated security testing tools

Automated security tests run much more quickly than manual tests, and are consistent, repeatable and reliable, making them ideal for continuous testing. Two types of automated application security testing tools are commonly integrated into continuous testing processes: Static Application Security Testing (SAST) tools, which identify vulnerabilities in source code; and Dynamic Application Security Testing (DAST) tools, which look for vulnerabilities while the code runs in a testing environment.

However, be aware that both SAST and DAST can take a long time to run on a large application and can also generate large quantities of false positives that can distract you from identifying and analyzing more serious issues. To optimize your use of these tools in continuous testing, focus on areas of the code that have recently changed, and configure them correctly so that you don't waste your time on investigating false positives.

Don't forget your production environment

The production system is where your code and data are most vulnerable. It's where real users — and real hackers — have access. This is where your heretofore undiscovered weaknesses will surface. Run security tests on the production system as you deploy updates and continue to test regularly in production just in case configurations have changed or the environment has been updated. However, keep in mind that running extensive security tests in production can slow your systems down, or even halt them, so plan to maximize the value you get while minimizing any potential for disruption. Consider using a Runtime Application Security Protection (RASP) solution as well, which will identify and block malicious accesses in real-time.

All DevOps Should Be DevSecOps

DevSecOps means thinking about security from the start and being proactive about security throughout the software delivery pipeline. Over the last few years, we've been seeing more awareness of security as part of DevOps, and we're getting to the point where it's inseparable. DevOps and DevSecOps are one and the same thing.

Whether you call it DevSecOps, or just plain DevOps, security must be a central component of your software delivery pipeline if you are to minimize risk to yourself, your business, and of course, your customers.