DevOps isn’t just about development and operations teams. If you want to take full advantage of the agility and responsiveness of a DevOps approach, IT security must also play an integrated role in the full life cycle of your apps.

Why? In the past, the role of security was isolated to a specific team in the final stage of development. That wasn’t as problematic when development cycles lasted months or even years, but those days are over. [1] Effective DevOps ensures rapid and frequent development cycles (sometimes weeks or days), but outdated security practices can undo even the most efficient DevOps initiatives as shown in figure 1.

Now, in the collaborative framework of DevOps, security is a shared responsibility integrated from end to end. It’s a mindset that is so important, it led some to coin the term "DevSecOps" to emphasize the need to build a security foundation into DevOps initiatives.

Figure 1: DevSecOps vs. DevOps

Let's take a look at a typical [2] DevOps and DevSecOps workflow:

• A developer creates code within a version control management system.
• The changes are committed to the version control management system.
• Another developer retrieves the code from the version control management system and carries out analysis of the static code to identify any security defects or bugs in code quality.
• An environment is then created, using an infrastructure-as-code tool, such as Chef. The application is deployed and security configurations are applied to the system.
• A test automation suite is then executed against the newly deployed application, including back-end, UI, integration, security tests and API.
• If the application passes these tests, it is deployed to a production environment.
• This new production environment is monitored continuously to identify any active security threats to the system.

Continuous Integration (CI) is a process that merges code changes to ensure the latest version of this software is available for developers. This helps programmers make sure they’re on the same page as other team members and reduces bugs in new versions before deployment.

Continuous delivery and continuous deployment (CD) is a strategy to automate updates and increase efficiency. It can be used as an alternative to the traditional iterative, [3] linear software development models like Waterfall or V-model.

Microservices are small pieces of an application that, when combined, create an entire system. By implementing microservice architecture, developers and tech teams can break down the complex code into small pieces for easier management.

Infrastructure as Code (IaC) is a trend that allows you to design and implement infrastructure needs through code. This new system removes the need for IT professionals to manually configure servers, install software packages, or manage operating systems remotely, which would require hours of manual labor.

Monitoring in data monitoring, collecting and analyzing application data for the purpose of learning how to improve is an important factor in both DevOps and DevSecOps. To optimize the application’s performance, minimize its attack surface and improve your organization’s security posture, it’s essential that you have access to real-time data.

Steps to transitioning from DevOps to DevSecOps

The transition from DevOps to DevSecOps requires understanding the particular techniques and practices ensuring software security. [4] Let's discuss this aspect in more detail and find out what technologies exactly will be needed.

First, I suggest adopting Dynamic Application Security Testing (DAST) tools. As tools performing the so called black-box testing, dynamic analyzers can identify program vulnerabilities such as SQL injections, buffer overflows, and the like. Building dynamic analyzers into your software development process is one of the steps towards the DevSecOps practices.

Runtime Application Self-Protection (RASP) is one of the security technologies used at runtime. RASP analyzes the application's behavior, thus implementing continuous security analysis.

Interactive Application Security Testing (IAST). The IAST approach analyzes the application from the inside at runtime and keeps track of code execution in memory, looking for specific events that could lead to a vulnerability. These events are further analyzed to see if they are clean or pose a risk of causing a vulnerability.

Static Application Security Testing (SAST) is used to check the code without actually executing it. SAST helps find potential vulnerabilities in the source code, thus preventing multiple possible zero-day vulnerabilities. Common Weakness Enumeration (CWE) is one of the most popular classifications of warnings produced by SAST tools. [5] CWE is an official list or dictionary of common security weaknesses exploitable by intruders to obtain unauthorized access to the system. Using a static analyzer as part of the development process will help prevent software bugs from getting to the next level, CVE. CVE (Common Vulnerabilities and Exposures), is a database of widely known information security vulnerabilities, which was worked out as an attempt to make an ordered list of known software defects.

Software Composition Analysis, SCA. SCA can identify vulnerabilities in open-source components and analyze applications to see if they include components that are known to contain vulnerabilities.

References:

1. https://www.redhat.com/en/topics/devops/what-is-devsecops
2. https://www.devsecops.org/
3. https://www.bunnyshell.com/blog/devops-vs-devsecops
4. https://www.appdynamics.com/blog/product/devops-vs-devsecops/
5. https://pvs-studio.com/en/blog/posts/0710/

Cite this article:

Vinotha D (2021), The Difference: DevSecOps vs. DevOps, AnaTechmaz, pp 6