What Is DevSecOps?

You have probably noticed that seemingly everyone is jumping on the DevSecOps bandwagon. Just in 2021, about 36% of respondents in GitLab's worldwide DevSecOps survey study said their teams develop software using DevOps or DevSecOps. And you'd probably very much like to know just what the meaning of DevSecOps is. In this blog post, we will give you all the basics about this methodology. After reading it, be sure to check out the others in our DevSecOps blog series.

DevSecOps has been called "the natural extension of DevOps." So, we need to explain what is the difference between DevOps and DevSecOps.

Perhaps as famous a concept as DevSecOps, DevOps is defined as a development methodology that aims to bridge the gap between development and operations. It accomplishes this by stressing communication between developers and operators and shared responsibility in quality assurance.

What's considered a main feature of DevOps is velocity. Indeed, here's where two processes shine, for they are hardly absent when talking about DevOps. One is continuous integration (CI). This refers to the process of developers integrating the code they work on into a shared repository several times during the day, every day. Along with CI is continuous delivery (CD), which means moving software to the production environment, providing swift response to modifications and constant feedback. Here's a positive outcome: In GitLab's aforementioned 2021 survey, almost 60% of developers said they released code twice as fast thanks to DevOps.

Great as DevOps may sound, there's no point in releasing fast if the product is riddled with bugs. Teams attempt to prevent this by implementing DevSecOps, meaning they adopt a culture in which everyone is responsible for security and every developer assesses their own code with security testing automated tools or manual techniques. They do this during the entire software development lifecycle (SDLC). That's right: from its beginning to its end.

We published a post about DevOps a while ago. At the end of it, we asked about the inclusion of security in this methodology of continuous integration and deployment. Consequently, we referred to the emergence of the DevSecOps concept. If we search on the Internet for a short definition, we find what is said in Gartner's glossary:

So, what does DevSecOps stand for? As we said in the DevOps post, the element Sec, referring to security, is added to DevOps. But to be clear, we don't just add it anywhere, we add it in the middle: DevSecOps. Security is then expected to play a significant role alongside the development (Dev) and operations (Ops) processes. DevSecOps is an evolution of DevOps where security is understood and implemented. But why the inclusion of security in this methodology? Why is DevSecOps important?

Security in software engineering is still ignored by many. Others still see it as an obstacle that slows down the production process. But many others have come to see security as a necessity in an ample shared virtual space, where the intentions of a lot turn out not to be the best. The most attentive to this issue have been those wishing to maintain the prestige of their companies, which may be handling personal data of huge amounts of users.

We must be aware that user data and app functionality can be put at risk by the presence of vulnerabilities. So, to avoid weaknesses and subsequent attacks on products, security measures must be implemented from the early stages in the SDLC. It's true that security tests usually have been carried out just before the deployment of applications to the production environment. But for many, this testing approach has been a burden. What about those within the DevOps culture who are continually creating features on their applications? Are they investing time and effort in finding or detecting gaps in their code just before each deployment?

If they are already within the DevSecOps approach, the answer is no. When we say implementation in the early stages, as shown in the figure below, the security element has to cover the cycle from its beginning to its end.

Following those security requirements, security checks for finding vulnerabilities are performed continuously. These checks are carried out through automatic tools combined with teams of security experts that use their knowledge to detect gaps, keeping pace with DevOps. The use of these tools and human capabilities integrated into the pipelines, employing static application security testing and dynamic application security testing techniques, makes it possible to minimize the number of vulnerabilities. These weaknesses can be found early, while the code is under construction, and their remediation can also be done promptly. The timely activity of experts and DevSecOps tools, which should generate continuous information logging and quick feedback, allows companies to stay one step ahead of attackers and maintain security controls. That is why DevSecOps practices are important.

Forrester's 2021 report on the state of application security showed that 30% of security decision-makers surveyed in 2020 whose companies were breached said the attack was possible because of software vulnerabilities. DevSecOps aims to avoid this. As changes to code are tested for vulnerabilities, it's possible to get ahold of them before the end-user gets a buggy software handed to them.

Yet another worrying trend is supply chain attacks. Teams use third-party components more often than not to develop their software. Also, if they built the components themselves, other teams will probably use them. If attackers find a vulnerability that allows them to mess with code, components, cloud services, etc., common to various software projects, they end up compromising the whole supply chain. DevSecOps practices aim to secure software from upstream risk and prevent teams from generating downstream risk.

"Well, sign me up! How can I start?" It's good that you ask! Fortunately, we offer a complete guide on how to implement DevSecOps in a dedicated post. Here, we'll give you a simple advice on how to evolve DevOps to DevSecOps.

You may start by deciding to expand shared responsibility and ownership of the software to encompass its security also. For the most part, this is achieved by creating the possibility of collaboration between the development, operations and security teams. What we're aiming for here is for people to adopt a DevSecOps culture and mindset.

You may also move on to specify the security checks in need of implementation into your DevOps processes. Ideally, most of them should be automated. However, an effort needs to be made to train developers on secure coding, reviewing code for vulnerabilities as soon as a change is done. Moreover, it doesn't matter if they are not developers, engineers or whatever; every one of the employees must be aware of any newly established security requirements and know how to implement them in their daily work.

In this process, some DevSecOps roles and responsibilities should emerge. There is a person whose job is to define actions, lead the security checks (e.g., conducting risk assessments and threat modeling) and monitor practices in the DevSecOps process. We're talking about the DevSecOps engineer. We've dedicated a blog post about this role that even mentions how to become a DevSecOps engineer. Be sure to check it out.

It's vital to show a commitment to security and enhance DevSecOps capabilities. We have identified a set of best practices, which we talk about more extensively in a dedicated blog post. Here, we make a brief summary:

And what are the phases of DevSecOps adoption? It's ideal that you start the above practices gradually. Some, like automation, may become more sophisticated as you become more mature in DevSecOps. For a detailed DevSecOps roadmap, go to our dedicated blog post.

Shifting testing to the left may help you produce more secure software and save money. It has been argued that remediation at the early stages of development is less costly than at the production deployment stage.

As we mentioned earlier, it's ideal to have automated security checks. This includes essential things like having automated security testing tools (e.g., SAST, DAST and SCA) running in your SDLC. However, these tools may generate false positives and false negatives. Hence, an even better strategy is to have experienced people that use manual techniques (e.g., manual SAST and DAST) to find vulnerabilities in your software. In fact, our ethical hackers found about 81% of the high and critical severity vulnerabilities reported in systems over an analysis period in 2020. In short, process automation does save you time but a manual intervention is needed to achieve accuracy.

We at Fluid Attacks offer DevSecOps implementation as part of our Continuous Hacking solution. As mentioned above, we understand that using manual techniques for security testing has evident benefits over automated security testing tools. So, we help organizations implement DevSecOps by offering our ethical hackers' skills (in addition to automated tools) to find vulnerabilities across the SDLC. By performing continuous penetration tests, organizations can validate the security of their technology and test it against new techniques used by threat actors and therefore out of the scope of automated tools.

You may then want your system to be tested for vulnerabilities in the most realistic way. That is, to have ethical hackers perform actual attacks. Red teaming can do this for you. Its relation with DevSecOps is that you can gain a better understanding of your system's security if ethical hackers continually test the system versions just like malicious attackers would. This implies that only some people in your organization should be aware of the contractual agreement with the red team; the rest will have to respond to the attacks, which will be carried out without any previous announcement. Security should be all about being prepared for actual attacks anytime, and this is how DevSecOps relates to red teams.

A resulting way in which red teaming may enhance your DevSecOps adoption is by challenging a pernicious mindset: That vulnerabilities can be accepted, since there's little chance they will be exploited. So, when you have actual evidence that hackers have exploited a vulnerability in your software, you have no option but to prioritize its remediation instead of focusing on deploying new features.

Bonus: Fluid Attacks is convinced that speed without precision is useless. Therefore, we have combined the best of each end: Technology and knowledge produce a good balance. Many cybersecurity companies offer fast, automated tools that are highly prone to false positives and false negatives when searching for vulnerabilities. Fluid Attacks has recognized that there must be human work involved in these processes to ensure accuracy and efficiency. Fluid Attacks has not forgotten the value of speed but has always kept it in parallel with high-quality testing and excellent results. So, we invite organizations to automate tools and processes where it is possible and rely on ethical hackers to perform sophisticated security testing. This way they can achieve their DevSecOps goals.

It's curious that when we spoke with Oscar, he didn't use the name DevSecOps, but SecDevOps. He moved security to the left. With SecDevOps, perhaps more emphasis is placed on initially establishing security requirements to be followed through testing processes carried out continuously in the SDLC.

Companies that decide to implement the DevSecOps approach (or, perhaps better said, SecDevOps) will achieve significant benefits, especially in the quality and security of their processes and products. Would you like some advice on how to do it?

We at Fluid Attacks help you enact your DevSecOps practices: You can integrate our DevSecOps agent into your pipelines and configure it to break the build if our SAST or DAST tools find an open vulnerability in your code. Moreover, you can ask us about our Advanced plan, which involves ethical hackers assessing the security of your technology. To learn more and get all your DevSecOps questions answered, contact us!