What Is DevSecOps?

Broadly speaking, DevSecOps is a methodology that incorporates security into the development (Dev) and operations (Ops) processes. In simple terms, it means that the security of technology is assessed during its development, but also that security is everybody's business.

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.

DevOps vs DevSecOps

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

DevOps

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.

DevSecOps

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 development lifecycle (SDLC). That's right: from its beginning to its end.

DevSecOps meaning

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:

Ok, that information might be enough. See you in the next post!

I was just kidding! Let's talk about it.

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?

Why do we need DevSecOps?

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 and 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.

How does DevSecOps work?

In this approach, companies have to establish security requirements that they must meet during the SDLC. These requirements can be based on system infrastructure assessments. Such evaluations carried out manually and from the attacker's point of view detect potential security issues. In other words, these assessments are intended to answer questions such as: Where can hackers attack us? What are the areas and information that we must protect the most? What are the gaps that we must not allow in our applications? What will be the countermeasures and solutions we have to establish?

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.

Caution: (a) Relying heavily on tools and their automatic work can lead to high rates of false positives and negatives. For that reason, the role of human experts is fundamental to achieve precision and avoid that developers waste time confirming if vulnerabilities are real. The main risk is the existence of false negatives or escapes. Organizations may not be aware of certain security vulnerabilities that current technology is unable to identify. (b) Perform the security checks gradually, starting with high-priority areas, trying not to overload the developers with work as they are usually responsible for closing the gaps.

Benefits of DevSecOps

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.

And as we mention further below, DevSecOps may also enable your team to save on remediation costs.

How to evolve DevOps to DevSecOps

"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.

DevSecOps best practices

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:

• Collaboration: Encouraging prompt communication and making it possible for the entire project team to find out where the vulnerabilities are in the code, who introduced them, what's been done about them and their remediation status.

• Cybersecurity awareness: Regularly informing employees about company-wide security policies (vital for maintaining cybersecurity awareness); educating them to incorporate security practices (e.g., testing and code review) into their daily work; and holding them accountable "for assessing and maintaining the security of their work."

• Velocity: Launching small code changes quickly and securely.

• Shift-left testing: Having security scans built into the developers' workflow at the early stages of development to search for known vulnerabilities in the code they've just written; this way they can fix them before the security team reviews the scan results.

• Automation in combination with manual pentesting: Successfully integrating security into the CI/CD pipelines, so that every change in the code is automatically scanned, inventoring code dependencies continuously and keeping them up to date, and automatically creating issues/tickets or breaking the build (whichever is the organization policy) in case a vulnerability is found. And doing this continually along with manual security testing.

• Security standards: Automating the use of security standards, evaluated and set by the security team, and continuously evaluating compliance and the integrity of the systems' physical components, network security and employee behavior.

• Continuous instead of regular security audits: Identifying the entire attack surface, and possible attack vectors for information systems, which is commonly a part of risk assessments and threat modeling.

• Continuous penetration tests: Having ethical hackers assess the security of your systems throughout the entire SDLC, as opposed to conducting just regular penetration tests that could allow a time window during which threat actors can get a way in.

• Break the build: Preventing vulnerable code from reaching production and fixing it promptly, thus cutting remediation time by up to about 30%.

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.

Shift-left security

We can't stress enough the importance of starting security testing from the very beginning. Visualize the SDLC across a straight horizontal line, project planning on the leftmost point and production deployment on the rightmost point: We're asking you to move security testing ever to the left.

The whole idea concerning shift-left testing is to identify and address security issues in software from the early stages of development. That is, not well into the traditional testing stage of the SDLC but much earlier, even when defining its requirements (e.g., what it should do and the resources needed).

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.

DevSecOps automation along with manual techniques

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) running in your CI pipelines. However, these tools may generate false positives and false negatives, so an even better strategy is to have actual people use manual techniques (e.g., manual SAST, DAST and SCA) 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.

DevSecOps as a service

Some organizations may find it necessary to outsource DevSecOps services. When they do this, they expect to be provided a solution that leverages the knowledge and practical experience of certified DevSecOps professionals. The provider of DevSecOps as a service is responsible for embedding security methodologies and toolkits (such as tools to run security checks in CI/CD pipelines) across the entire SDLC. Moreover, they should assess current and potential vulnerabilities in the system and help enforce cybersecurity best practices beyond secure coding.

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.

How does DevSecOps relate to red teams?

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 exploited it, you have no option but to prioritize its remediation instead of focusing on deploying new features.

DevSecOps with Fluid Attacks

Now, to have a clearer idea of the role of security within DevOps, let's briefly outline what Oscar Prado, Cybersecurity Analyst, shared with us about what Fluid Attacks does for its clients. Our company offers continuous hacking services, a constant search for vulnerabilities in IT systems. But although some tools are used in this process, at Fluid Attacks, we rely on tools only as a support for our hackers' activities, contrary to what other companies do. Here we place more value on the knowledge and skills of ethical hackers to ensure greater accuracy in testing. Their work can begin "from the moment the first commit is uploaded by developers," with every new change being reviewed. That work can continue after the application has been deployed to production.

When a vulnerability is detected in the client's code, a member of our team can develop a personalized script called exploit, associated with the finding. That exploit "automatically checks if the analyst's finding persists." Therefore, "if the customer wants to make new changes to her product, she must fix the finding first," because if she doesn't, the exploit will continue reporting the presence of the vulnerability. Then, according to a configuration by her team, it will break the build, and the deployment process will be automatically stopped. "This way, security is prioritized, and our security testing is integrated into the client's SDLC," concludes Oscar.

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.

SecDevOps?

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.

Regardless of the name we give to the inclusion of security into the DevOps methodology, within this new business culture, security is expected to play an essential role in software production and maintenance from the beginning It's intended that all those involved in the projects know and apply security; that's why they need training. Bear in mind that just as in DevOps, there shouldn't be separate teams by function but by product. In the end, everyone must be responsible for security.

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 a vulnerability in your code. Moreover, you can ask us about our Squad Plan, which involves ethical hackers assessing the security of your technology. To learn more and get all your DevSecOps questions answered, contact us!