DevSecOps - Best Practice for Secure Software Development

In 2019, for the first time ever, the amount of companies that were affected by at least one cyberattack has exceeded 80%. This ridiculous figure is particularly alarming as the goal of these attacks is in many cases to gather information. While many companies are expending lots of effort on optimizing continuous integration/continuous delivery (CI/CD) processes, security often still plays a subordinate role, making it very easy for hackers to find vulnerabilities within applications and exploit them.

Since traditional security approaches cannot keep up with the increasing complexity of cyber-threats, it is crucial to assign a new role to application security. A modern-day software development method that does this best is DevSecOps. DevSecOps extends the outdated approaches of DevOps and Agile by adding suitable security testing methods alongside every single phase of the software development lifecycle (SDLC), creating a dynamic and continuous testing process. 

This article will give you a better understanding of DevSecOps by answering the following questions:

1. What is DevSecOps?
2. How does DevSecOps set itself apart from other models?
3. What is the DevSecOps Toolchain?
4. What do you need to consider for a change to DevSecOps?
5. Which challenges have to be considering when implementing this method?

DevSecOps Wiki

• Software Development: a variety of computer science activities aimed at conceiving, deploying, designing and supporting software. The main focus lies on writing and improving the source code.

• IT Security: a set of measures that can be implemented to reduce the risk of malicious software attacks by identifying potential vulnerabilities within an application. Find out more about different security approaches in the AST Report 2020.

• IT Operations: processes and services administered by an organization’s IT department to meet a businesses’ technology needs. IT Operations include administrative processes and support for software and hardware used by internal as well as external clients.

Software Development + IT-Security + IT-Operations = DevSecOps

How Does Devsecops Set Itself Apart From Agile and DevOps?

DevSecOps embodies all of these practices of former models with the goal of making security a priority for everyone involved in the software development process. While DevOps and Agile were very innovative and disruptive at the time, they are unable to cope with the security demands of the shorter modern-day SDLCs.

DevSecOps should not be seen as a replacement for these models, but more of an add-on, which extends these existing approaches, by placing more value on security. While testing was done in a very centralized way, based on the classic V-Model, in DevSecOps testing is done by executing appropriate security controls directly within the various delivery teams.

Depending on the phase at which the testing is done, a mix of static, dynamic, interactive and feedback-based testing approaches (fuzzing) are used in DevSecOps. 

DevSecOps Toolchain

Integrating DevSecOps into the CI/CD pipeline is not something that can be done within a day. Let’s have a look at the tools and practices required for a successful transition:

• Phase#1 Vulnerability Detection: For optimal security, the first step should always be checking the source code for vulnerabilities. In DevSecOps this means delivering the right training and equipment to the teams, that are responsible for different parts of the CI/CD process, enabling them to test the application independently at each station of the SDLC

• Phase #2 Runtime protection: To reduce the amount of runtime threats, it is important to identify them early in the CI/CD pipeline. Strategies and practices of runtime protection can vary, depending on the nature of an application. Regardless, you should be monitoring your code for suspicious behavior that could indicate a breach. It is also advisable to have a process in place that can warn you about vulnerabilities, caused by environment variables or configuration settings.

• Phase #3 CSP security tools: Most cloud service providers offer security features, which are positioned at the deployment and post-deployment stages of the DevSecOps chain. Although these post-hoc security methods can be seen as an outdated strategy when used by themselves, they can be utilized as an integral part of an application’s outer defense system. Conveniently, these security measures are - once they are configured - easily automated and systematized. 

• Phase #4 Policies and Standards: While many security processes can be automated, human decision-making is still needed for planning, prioritizing and setting security standards. EU regulations such as the GDPR (General Data Protection Regulation) make it even more essential to clearly formulate these standards. To efficiently enforce policies such as the GDPR, it is crucial to make use of role-based access control systems (RBAC). RBAC only requires you to apply roles to users, which it then uses to automatically authorize requests.

• Phase #5 Container Orchestration and Service Meshes: Container orchestration and Service meshes play a substantial role for secure software deployment. They ensure a safe authorization process by keeping services protected behind proxy-servers, only granting access to authorized users. Like RBACs, Container and Service Mesh Tools, such as Kubernetes can be very beneficial, as they can automate authorization, authentication, and encryption processes. Although these features are often included in orchestration and service mesh tools they usually have to be adjusted to the needs of an application (similar to CSP security tools).

What Do You Need to Consider for a Change to DevSecOps?

If you want to drive change towards implementing DevSecOps in your company, the first step needs to be cultural acceptance. If this is not already the case, it is crucial to build up a security culture and to create a consensus, that everyone is responsible for security.

Since testing will no longer be done only by security experts, but also by “normal” developers, the usability of the testing tools will play a big role. Traditional security approaches are insufficient for security testing during the many phases of a DevSecOps cycle.

Implementing too many tools can be tricky, as this makes it difficult to supply the CISO with conclusive analytics and reports. Versatile testing tools, that are multi-operational among the different stages of the CI/CD pipeline can be very helpful, to maintain an overview and draw conclusive KPIs.

A solution that meets the usability needs of developers, as well as the analytical needs of management is CI Fuzz. The testing platform is very popular among DevSecOps professionals since it offers a very effective but simple testing solution, based on modern fuzzing.

Challenges of DevSecOps

As mentioned before, the main challenge of introducing DevSecOps is in most cases the culture. In many companies, software development and application security are divided into different teams, that sometimes work together and sometimes work against each other.

This “dev vs sec” mentality can be problematic when the roles of the team members are rearranged. Making everyone responsible for security inevitably means that developers will have to get the hang of security practices.

This can very well lead to some resistance and obstacles, especially right after introducing DevSecOps. However, security professionals will certainly not become obsolete, since manual testing will still be required, especially when it comes to logic and design flaws. Another challenge arises from the so-called “Clash of Tools”, which describes the necessity of introducing new tools, in order to be able to conduct tests throughout the whole CI/CD pipeline.

Because the start is often rocky, the biggest challenge when integrating DevSecOps is “not giving up”. DevSecOps will improve your application security, but it will not eliminate 100% of bugs and it will probably come with some difficulties in the beginning. So set yourself realistic goals and don’t go chasing after perfection!

Although it may not sound like much, adding the three letters “Sec” to a DevOps cycle is a big change for everyone involved. Creating a security culture takes time and patience, but no later than when it is established, everyone on the team will understand its value.

Application Security for the Win

In modern software development, there is no way around security. The earlier you catch on to it, the better. DevSecOps offers an approach that elevates the importance of application security to a higher level, leaving little to no room for hacker attacks. It is no question that integrating this security benchmark comes with some challenges, but overlooking security issues will leave you with much more devastating problems in the future.

Get our free Application Security Report 2020 to stay on top of the latest developments in AppSec: