Technology Reviews

AppSec: SecDevOps or DevSecOps? Do We Need to Choose? Guide to the What and the Why

AppSec: DevOpsSec, DevSecOps, and SecDevOps? What’s Their Difference, and Which One is Better?

Thanks to cloud computing, software development (DevOps) is now more agile and automatic, but also more challenging for humans to trace the problems, especially security loopholes. For this reason, more and more professionals are shifting their focus from DevOps to DevSecOps and SecDevOps.

Keep reading to learn what they entail and why they should be on everyone’s radar.

1# DevOpsSec – The Traditional Way To Software Development Security

Waterfall SDLC | Image by the author

What exactly is DevOps?

  • Dev (Development) is mainly responsible for developing programs, improving the quality of software, and testing the operation of software programs.
  • Ops (Operations) is mainly responsible for maintaining the system, setting up the system architecture, and monitoring the operation.

Initially, most developers used the waterfall method. With that, software development is highly process-driven – meaning that one phase start after one phase ends. Also, in a waterfall model, development entails:

  1. Analysis,
  2. Requirements
  3. Design,
  4. Development
  5. Testing,
  6. Deployment, and
  7. Maintenance.

Security won’t be in the picture until step 6, deployment. Hence,

DevOpsSec = Development (Dev) + Operations (Ops) + Security (Sec).

In which Security is considered an add-on, not a built-in. On the e hand, DevOps was embracing Waterfall and Agile methodologies that transformed the industry, and the threat landscape was also changing into a more consistent and dangerous enterprise security risk.

2# DevSecOps – Built-in, Not Bolted-on

DevSecOps | Image by the author

The latest generation of software applications, cloud-native applications, has evolved into a standardized architecture of components linked with APIs called microservices supported by an infrastructure for offering application services.

According to NIST Special Publication (SP) 800-204C, Implementation of DevSecOps for a Microservices-based Application with Service Mesh:

the entire set of source code involved in the application environment can be divided into five code types:

  1. application code,
  2. application services code,
  3. infrastructure as code,
  4. policy as code,
  5. and observability as code.

DevOpsSec cannot keep up with the development speed, and it is easy to expose weaknesses and loopholes. Thus, here comes the DevSecOps – where “Sec” is shifted to the middle. And DevSecOps (development, security, and operations) offers swift deployment and updates while integrating security in the lifecycle.

DevSecOps is the culture of implementing “Sec” on DevOps, and the implementation of “Sec” on DevOps is not only to retain the original efficiency but also to ensure the security elements of the entire DevOps to avoid the negative consequences. By that, security would be again everyone’s responsibility. To implement a good security culture, everyone on the team needs to be cybersecurity-aware and has a shared responsibility for cybersecurity.

Its features and advantages are agility, rapid delivery (quick response to customer needs), and high reliability (guaranteed quality after application updates and infrastructure replacements). The disadvantage is that in the case of rapid development.

NIST SP 800-204C provides guidance for implementing DevSecOps primitives for a reference platform hosting a cloud-native application with the code types listed above. The guidance also discusses the benefits of this approach for high-security assurance and enabling continuous authority to operate (C-ATO).

The Challenges Faced by DevSecOps are: Efficiency, External Threats, and Sustainability

1# Efficiency

Under the rapid development and operation of DevOps, Security needs to be parallelized to find vulnerabilities as soon as possible and catch up with the development speed. At the same time, the Security team also needs to address security vulnerabilities effectively and accurately. Therefore DevSecOps requires a dedicated and automated set of cybersecurity decisions.

2# External threats

Under rapid development and software updates, new vulnerabilities will always exist and become software weaknesses, eventually exploited by adversaries. Therefore, it is necessary to fully understand the DevSecOps environment to reduce the possible attack surface, which is highly unlikely for the security team unless they have unlimited time and resources.

3# Sustainability

When each software development cycle is completed, what is needed is to

ensuring continuous security and maintaining awareness of chasing vulnerabilities is needed

l teams, especially the security team would be exhausted by the increasing number of vulnerabilities and the faster Dev cycle.

DevSecOps vs. PPT Framework (People, Process, Technology):

DevSecOps vs. People, Process, Technology | Image by the author

1# Automation (Technology)

Automate the security vulnerability detection operation, e.g., skip many false positive vulnerabilities by cross-checking. That is the vulnerabilities that are repeated or have no profound effect. This reduces time to check for particular vulnerabilities and allows for faster detection and targeting of critical vulnerabilities, which can improve the efficiency of DevSecOps, and reduce the fatigue of team members.

2# Understand the Entire DevSecOps Cycle (Process)

Each department should understand the process from planning to the establishment, deployment to operation, add the purpose of network security at each stage, and then import and implement security decisions.

3# Adopt A Security Mindset (People)

The easiest way to raise general awareness is to go from top to bottom. Team captains will jointly implement a security mindset – customize clear and achievable goals, supervise all personnel and implement the team together, consciously maintaining security.

3# SecDevOps – The Next Step in App Security’s “Shift Left”

A “10/10 CVSS vulnerability” – Log4Shell has caused global enterprises to go crazy from late 2022 until now. And the remediation of the vulnerability is even more tedious and protracted. Log4Shell is not the first, nor will it be the last, to alarm the danger of application security.

Distribution of vulnerabilities by severity over time – Image Source: NIST

When we look at another set of stats from the National Institute of Standards and Technology (NIST) shows the number of new vulnerabilities observed keeps rising exponentially while organizations struggle to counter them. The security community is finding ways to mitigate some of these risks, but how? One possible way is to introduce secure DevOps.

Componentization Increases Speed and Efficiency

By breaking down large applications into small reusable components (or microservices), developers can work in a more agile way more agile and deliver continuously in increments. Meanwhile, APIs encourage companies to break down capabilities into individual, autonomous services. Running applications based on microservices can help ensure a good user experience (UX) on all devices. An “API-first” strategy fosters organizations to build APIs that serve all applications and can be developed and maintained efficiently for all devices, platforms, and operating systems.

Interestingly, the rise of “API-first” in software development has actually improved software security, reducing the average time to fix bugs by about 50% when using static analysis for APIs or microservices. API scanning also helps organizations to find and fix security vulnerabilities more efficiently in APIs’ early stages.

Automation Pushes Security Further Left

Source: Veracode platform showing Static Scan data

According to data from Veracode, cybersecurity is becoming more automated and componentized to conform to modern software architecture and development practices. Analysis of 5,446,170 static scans and over 310,000 applications in the 13 months from September 2022 to October 2022 found a staggering 143% increase in small applications, such as APIs and microservices, executed via APIs of automated scans increased by 133%.

The Covid-19 pandemic has accelerated digital transformation, and businesses aggressively compete to launch digital products and services. The pressure on developers to develop and deploy software faster than ever drives them to DevSecOps—integrating development, security, and operations, making AppSec an integral part of the SDLC.

Ultimately, companies are applying AppSec controls to ensure the integrity of the development process and extend the DevSecOps pipeline model across the enterprise. The popularity of DevOps automation and componentization has also driven a dramatic rise in the need for security to do the same, i.e., security automation, such as using artificial intelligence and machine learning for vulnerability identification, threat modeling, and remediation.

DevSecOps mature rapidly, thanks to the healthy competition among security vendors and Cloud providers. And now, there’s an opportunity to move security further left into the design phase and become SecDevOps.

From DevSecOps to SecDevOps

A tool-lean, comprehensive, fully integrated security platform is required to keep up with App modernization to support pervasive or persistent security because:

  1. Threat modeling ensures that only secure components are incorporated into the design from the design phase. This means a further shift left in security, with DevSecOps now becoming SecDevOps to ensure the software is “secure by design.”

  2. Fully integrated but also open to new technology plugins, covering every possible dimension of code analysis. This “single pane of glass” approach enables security professionals and developers to understand risk, prioritize remediation efforts, and define and monitor progress goals across multiple dimensions.

  3. Provide a smooth developer experience that enables security analysis to meet the demands of developers’ work through:

    1. IDEs (Integrated Development Environments),
    2. CI/CD (Continuous Integration Continuous Development) pipelines,
    3. code & container repositories, and;
    4. defect tracking systems.

Some recent high-profile attacks have brought vulnerabilities to the software supply chain into the spotlight.

Enterprises are now looking to the next evolution in software security for peace of mind. This means providing assurances of continuous orchestration, such as:

  • policy definition and management,
  • inline remediation with ‘self-healing’ capabilities, and
  • Runtime intelligence of detecting any vulnerabilities introduced by changes to underlying components.

The number and threat of software vulnerabilities are growing, and the zero-day vulnerabilities, from Log4j2.x to Log4Shell and now Text4Shell, which keep sparking global panic, are still being exploited. For application development and security teams, software security continues to shift left to the importance of SecDevOps, and urgency have been self-evident.

Summary: SecDevOps v. DevSecOps vs. DevOpsSec

Photo by the author

When talking to security professionals and customers, the talks emerging around DevSecOps and SecDevOps, define and differentiate one another. While their overall goal may be the same—that is, to make applications more secure—their practice and philosophy are vastly different:

  • DevSecOps is primarily concerned with integrating security processes into the DevOps cycle while maintaining efficiency;
  • SecDevOps prioritizes security as much as the actual steps of incorporating security into the DevOps process itself.

DevSecOps means delivering secure software of processes resilient enough to recover from inevitable vulnerabilities and cyber-attacks. It doesn’t mean a critical vulnerability won’t delay the delivery date. But it does help ensure that a vulnerability in a non-critical location, such as one that resides in a non-internet-facing application protected by a firewall, won’t be treated the same as one that could lead to financial loss.

On the other hand, SecDevOps believes all DevOps professionals should be security practitioners, which is a much different focus. Essentially, SecDevOps means making every decision with a security-first mindset. Rather than integrating security, SecDevOps fosters a security ethos in every team member to ensure that security becomes a shared responsibility throughout the application lifecycle. Building security into a SecDevOps framework leads to fewer vulnerabilities.

However, SecDevOps needs a cultural change. For example, DevOps teams who are used to prioritizing quick releases might find it challenging to prioritize and devote attention to security while meeting tight deadlines.

At the end of the day, transforming developers into security practitioners requires significant financial investments and focus on the training and tools necessary. Also, developers must embrace that change and learn the skills essential to making it work. 😅

Enterprises will find that by moving to DevSecOps and including security at each step of the process, their applications become more reliable, require less patching, and can be released on a faster cycle. As a result, DevSecOps is a business enabler, not an insurance policy. While SecDevOps might offer better protection, with a cost.

There Are Reasons For Each Approach.

Let’s say you have a development team; it would be wise to invest in enabling developers with a security mindset, in that case – SecDevOps. The applications currently in your developing stage should follow it as changes are done at every stage of development according to secure coding practices, which saves time and money at later stages.

But for many legacy applications in the market, which are decades old. Many code iterations have been made in them, and the code is edited so many times that changing to SecDevOps is practically not feasible for them. For those applications, DevSecOps is the only available option.

For me? I would choose SecDevSecOpsSec.

Thank you for reading. May InfoSec be with you🖖.

. . . comments & more!