DevOps Vs DevSecOps – What is the difference?

What is DevSecOps?

The security community loves to create its own lingo.

Sometimes it is as simple as stringing abbreviations of keywords together, like in the case of DevSecOps, SecDevOps, DevOpsSec or simply DevOps.

DevSecOps = Development + Security + Operations

DevSecOps simply means placing security practices early during the SDLC (Software Development Life Cycle) processes within an Agile framework.

To give you more context,  DevSecOps, includes code analysis, compliance monitoring, threat investigation, vulnerabilities assessments, etc. which are introduced into the DevOps ecosystem.

Adding such security policies within the agile framework, helps to ensure the codebase is secure from its inception, with continuous testing and evaluation.

SecDevOps (sometimes used interchangeably with DevSecOps) is the combination of the same 3 words – Development, Security and Operations.

Typically, when used this way, there is a reason why Security grabs the first place in the 3-word combination.

Traditionally, (before 2001), Security during application development was the last concern during the software development lifecycle process.

Moreover, Application Security was typically not the responsibility of a developer which usually made secure coding an afterthought. It was the security team which had to ‘test’ and report if an application was secure or not.

The focus was on application development and the Waterfall model was a popular framework choice.

But there were some problems with this approach to software development.

So, before we learn more about SecDevOps, for the uninitiated, let us review some of the common Software Development models.

Software Development Models before SecDevOps

First, let us go back to the late 1990s to understand how the application development model evolved before security and safe coding became priorities.

Waterfall Software Development Model

Let us start with John, a software developer, who has been building applications since the 1990s. John, like many others, was following the Waterfall model of software development, where the next step could not be started until and unless the first phase of software development  completed.

The Life Cycle model was a rigid linear sequential model.

The Waterfall Software Development Life Cycle (SDLC) was divided into six stages –

• Requirement,
• Gathering (Analysis),
• Design,
• Development (Coding),
• Testing,
• Maintenance (Operations).

To give an example of how this flow would work, let us say a real estate company came to John, asking him to build an application to show a property’s changing prices, then in this framework, John would need to do the following:

• Before he would start coding, the project team would get the input needed, and build the requirements for what was needed to be done.
• This would be followed by a long series of step by step planning.
• The team would use SRS (Software Requirements Specification) documents to record the design plans and the application development milestones (to make sure the application meets the expectations).
• Finally, after the SRS is analyzed and approved, the team can start the development work to get the application delivered.

Generally, everything would proceed as planned but there was a problem with this model.

Let us say the real estate company had a requirement that was missed in the planning and necessitated adding a new field.

This requirement would be missed in John’s planning and development until the phases of development have completed.  Any new or missed requirements will not be implemented, until the implementation phase has been completed.

So, John was a part of the team which:

1. Set the project requirements and the scope of work
2. Discussed the ideas around the application based on the pre-determined plan
3. Developed the application
4. Submitted the application for testing
5. If any problems are found during testing, the team would fix the issues
6. Get the application ready to be launched in the market.

The plan looked great but there was no room for any changes or additions along the way. In summary, the Waterfall model provided a framework for development, but was too rigid, inefficient, and slow.

If there were any changes made, the whole process started all over again.

The result?

John wound up working sequentially for months, sometimes years, on the same project – always missing deadlines and delivery milestones. Why? Because he missed one ‘spec,’ or one requirement was not outlined in enough detail.

John, working per his deadline has his own priorities.

The QA team following its own priorities was testing applications (and not necessarily John’s) as they were submitted to the QA team.  Lastly, the Operations team which needed to prepare for deployment, had no visibility into what was being developed.

Amid this evolving SDLC mess, John failed to deliver on time because of the ‘rigidness’ of the Waterfall model.  ‘Application security’ was not seen as crucial and there was no push to find the vulnerabilities early since the application was meant to be ‘tested by the QA team’.

The fallout? The great ‘delivery lag crisis’ of the 1990s, in design, development and deployment of business software which resulted in a failure of application delivery models to meet business needs.

So, this ‘rigidness’ produced and brought to light the issues with the Waterfall model. Software development had unforeseen challenges with unplanned adjustments and highlighted the need for continuous improvement and development.  By adhering to the Waterfall model, the actual time frame to develop business applications could be stretched as much as 3 years or more.

Waterfall and Application Security:

Agile Manifesto: Fast Forward to the Snowbird meeting in Utah

While PCs (Personal Computers), BYOD (Bring Your Own Device) and IoTs (Internet of Things) were booming and the world was focused on new innovations and technology, there was also a tremendous growth in consumer demand for product improvements.

As humans, we learn from our mistakes during the times we fail.

Similarly, organizations realized the frustrating stage-by-stage process of software development was too restrictive and needed improvement. To break free from this sequential approach, 17 industry leaders met at the Snowbird Ski Resort in Utah.

While it was an unusual location to discuss SDLC, a new development framework was born and given the name Agile Manifesto. This document contained four sections highlighting the following:

1. Individuals and interactions over processes and tools
2. Working software over comprehensive documentation
3. Customer collaboration over contract negotiation
4. Responding to change over following a plan

This was a welcome change from the Waterfall model which was heavily dependent on documentation and excessive planning – with minimal customer involvement.

With the new manifesto, applications could now be delivered at a faster pace, as bottlenecks were removed, and there was timely and repeated interaction between developers and program stakeholders.

Moreover, new applications were in demand due to the adoption and growth of internet culture. Driving a bevy of start-ups, were the increased and faster development requirement needs of websites, demand for cutting-edge applications, and new capabilities.

Application developers and planners really needed to think beyond the ‘documentation’ heavy Waterfall model.

On time delivery quickly became the most important commodity of application development.

The new trinity of software design, development and deployment processes became the new pillars of software development replacing the ‘fixed’ schedules of the past.

Agile Application Development Methodology

The Agile application development process at the core is about iterative development of applications, throughout the SDLC, with continuous iteration of development and testing between cross-functional teams.

The development of Agile was a healthy break from the Waterfall model. Agile project management starts from:

• Defining the users
• Creating the idea/vision statement
• Identifying opportunities and values

The collaborative approach of the Agile product development process makes sure that everyone is on the same page and is aware of what is being developed and the responsibilities of each of the stakeholders.

Application Security in Agile

As Agile revolves around a repository which keeps track of any changes and updates to requirements. Agile follows a distributed user-rights based mechanism, where the product owner is the master and any necessary updates to the requirements (known as the user story) is a capability given to all the users in the system.

The Agile framework is an improvement to the SDLC, but our protagonist John is still unsatisfied as he is concerned about his entire project, including the security of his application. He designs, codes, and has full responsibility for the success of his project, but he is finding that security is still an afterthought in the Agile continuous deployment and integration for application development.

What is DevOps, in all of this?

So, what started with the Waterfall model, passed the baton to the Agile SDLC, was now transitioning into a new development culture – DevOps (an abbreviation of the combination of Development and Operations).

DevOps is the union of people, process, and products designed to enable continuous delivery of value to the end users.

In other words, DevOps relates specifically to the Agile practices that automate the processes between software development and IT teams.

While Waterfall and Agile methodologies were linear and mapped project activities into different sequential phases respectively, DevOps paved the way for a new ecosystem of development and operations teams working together for a proactive SDLC.

Here, we should stop and make an important clarification. DevOps is a cultural shift. DevOps culture, coming from a similar platform to Agile’s IT productivity workflows, has a goal of removing latency between siloed departments, which are plagued by lack of communication, out of sync departments and disparate stakeholders.

Anyway, let us get back to our friend John, now in his 40s and is working in the cloud and sees how software development has evolved from releases in 6+ months to every day or a few weeks.

He has firsthand experience of cultural philosophies, practices, and tools which help him to tackle backlogs, work on QA, and integrate with other productions and platforms to enable continuous software delivery.

DevOps based web application development process

The DevOps culture has moved to  a continuous integration (CI) and continuous deployment (CD) delivery process.

Also, innovations like containers and microservices have paved the way for automation which helps to ensure security is part of the process, and ensures security is also integrated at subsequent phases of the application development life cycle. If DevOps fails to deliver a secure application, the company might end up reeling under the pressure of media and press during a data breach and exploit. Remember the fallout from the  vulnerability?

Here is how it works:

1. Developers write the code and track their changes with version control
2. The new code is integrated at the build phase
3. Feedback is gathered from all code branches and compilation takes place
4. Software code reaches the deployment phase
5. If everything falls into place, the code gets released to production.

In case bugs are found, the developers fix the code and the same processes reiterates.

The best part of DevOps is that feedback, about bugs and other issues, can be conveyed in the CI environment and to the performance and testing teams.

Every member who is involved is responsible for the overall success of the software delivery process.

DevSecOps Vs DevOps – The Difference between DevOps and DevSecOps? 

The concurrent rise of both methodologies has similar aspects of automation and continuous processes. Both share similar a mission of collaboration between security and application development.

But there is a (good) contrast between them, as you will notice when we compare DevOps with DevSecOps.

DevSecOps/SecDevOps  = DevOps + Security Component

If you recall, during the pre-DevOps era, security happened to be an afterthought. Finding and minimizing vulnerabilities were not the developers’ job. Application and infrastructure security were rarely a concern from the beginning of the SDLC.

But in this current timeframe, with the integration of security practices into the collaborative framework of DevOps philosophy of building apps, the role of security has become everybody’s responsibility. With the integration of security shifting ‘left’ (meaning it is addressed earlier in the SDLC – on a  timeline where  left is the start) and the right-most is the end), there’s renewed interest in the  development world around security.   It is exciting to see this shift in thinking and in the processes of secure coding (as per guidelines from CERT, CWE, OWASP, UL-2900 and PCI-DSS, etc.)

Developers and QA working together to achieve security. It sounds like a dream. But at times, the pressure is immense to deliver and despite maintaining the camaraderie between QA and development, often security ends up being an afterthought.

It is a generally accepted fact in the industry that a holistic knowledge and implementation of security is not in the wheelhouse of many developers. This has led to the need for and the creation of a separate yet expert team of security focused QA professionals – tasked with the mission of finding vulnerabilities.

Once found, a bug-report is sent to the development team, which can lead to friction between the teams. Since the development people may not be fully geared for coding with security in mind, or may be neck-deep in other coding, ‘passing the buck’ can become the norm, causing more delays to the development cycle.

Something akin to the following:

The unavoidable fact is that there is no single approach that gives a complete reading of vulnerabilities, fixes, and controls which would or could make the development team have a successful and on-time release.

It is this need that has driven ‘security’ to shift ‘left’ and become DevSecOps.  Translated, this means that the secure coding is done under the umbrella of the development policies and the development team is aware of the security requirements in advance – before anything gets started.

The policies consist of standards and guidelines to help eliminate problematic APIs or coding practices which could mar the development progress or introduce vulnerabilities. Add automation to the mix and the guidelines help the team work more effectively.

A Little bit about SecDevOps

What is SecDevOps? A Definition and Explanation

Also known as rugged DevOps, SecDevOps is a culture of placing security ‘first’, literally, in the development process.

The key difference between SecDevOps and DevSecOps is the order to security during the SDLC. In DevSecOps, security is embedded in every stage of the SDLC, compared to the SecDevOps culture where security is the very first step in the SDLC.

The best part about SecDevOps is that it helps to mitigate late-cycle security escalations and is instrumental in the success of every cycle of the process of application development.

Types of SecDevOps

There are two types of SecDevOps.

Security as Code (SaC)

The Security as Code culture basically reflects the idea of combining security into DevOps tools, security policies and practices.

What happens is that, to make testing more efficient, development and security teams implement core infrastructure changes and then test for software bugs or vulnerabilities – which are mitigated by having secure coding practices in advance.

Infrastructure as Code (IaC) 

This idea is the heart of the DevOps engine. In the so-called good old days, software was deployed on a physical server which required lots of physical space. Moreover, there were lots of roles in the form of System Administrator, DBA (Database Administrator), and QA tester etc.

Everyone in the testing team had to ‘work together’ on the product. Moreover, with different environments, technical issues like version control, time zones, load balancing and interlinking etc. were constant complications.  The end results. Lots of manpower and unoptimized productivity that was prone to errors.

With the advent of virtualization and cloud computing, the big players, like Google and Amazon started offering ‘managed services’ for infrastructure. Hence, in simplistic terms, Infrastructure-As-Code (IAC) is the concept of managing your IT infrastructure using machine-readable configuration files. It solved discrepancies and helped to reduce complexity that often hid security issues.

What are the advantages of SecDevOps? 

Simply put, SecDevOps bakes Security into the DevOps workflows.

And with the benefits of SecDevOps as described below, a successful DevSecOps implementation comes with some remarkable benefits:

Business Benefits of DevSecOps Adoption

Implementing DevSecOps best practices helps lead businesses to achieve the following advantages:

Cost reduction

Embracing security early in the SDLC, sensibly, can save businesses from security and privacy errors. Finding and fixing issues during the development phase can lead to faster and more secure application delivery.

Moreover, when you hear that GDPR penalties can be as high as 10 million euros or 4% of a business’s annual turnover, appsec compliance is always a good idea.

Secure by Design

Taking a secure by design approach, can help lead to automated security reviews of code and automated application security testing, which can empower application developers like never before.

Automation of Security

With the inclusion of automated security into the CI/CD lifecycle, and every phase of the development/deployment lifecycle, thoughtful automation is a developer’s best friend.

The Future of DevOps and DevSecOps Integration

As DevOps continues to evolve and shift towards DevSecOps, we should see  code standards, security, libraries, and legislation protocols follow suit with equally important security updates. We may see a continued shift in operations, including possibly new frameworks as we see advancement in automation technologies, including machine learning and artificial intelligence.  The future of DevSecOps promises that collaboration will reach new heights of automation, monitoring and quicker IT deployments.

K2’s runtime deterministic application security platform monitors the application and has a deep understanding of the application’s control flows, DNA and execution.  By validating the application’s control flows, deterministic security is based on the application itself, rather than relying on past attacks to determine a zero day attack.  Deterministic security results in the detection of sophisticated zero day attacks.

K2’s Next Generation Application Workload Protection Platform addresses today’s need for runtime security in an easy to use, easy to deploy solution.  K2’s unique deterministic security detects new attacks without the need to rely on past attack knowledge, is lightweight, and adds under a millisecond of latency to the running application.  To aid in quick remediation of vulnerabilities, K2 also provides detailed attack telemetry including the code module and line number being in the code being attacked, while at the same time integrating with leading firewalls to do real time attacker blocking.

Get more out of your application security testing and change how you protect your applications, and check out K2’s application workload security solution.

Find out more about K2 today by requesting a demo, or get your free trial.