Before we cover DevSecOps, let’s understand how products are developed. This is where we will run through the quick processes that are available currently or have existed in the past. Product development has been around for over six decades. Organizations, defense, and various teams have been following certain methodologies for developing and deploying applications. Let’s understand the evolution of these methodologies, which are as follows:

• Spiral
• Waterfall model
• Agile software development:
  • Extreme programming (XP)
• Rapid application development (RAD)
• Systems development life cycle

All these methodologies have changed the way we develop applications.

In the initial days, everything revolved around the Waterfall model, where every phase took time. Every phase has to be completed before we can move on to the next one. We will cover some of the important methodologies in this chapter as they lead to the agile process and DevSecOps. We will cover two models here – Waterfall and agile.

First, we’ll discuss the Waterfall model.

The Waterfall model

The SDLC is the process of developing applications in different phases. The SDLC has multiple models and the Waterfall model is one of the widely used models that is still in use by many organizations. The Waterfall model is there to help organizations with step-by-step processes.

The SDLC consists of seven stages:

1. Planning
2. Requirements gathering and analysis
3. Design
4. Development
5. Testing
6. Implementation and integration
7. Production and maintenance

These are the sequential stages that are used in the Waterfall model, and they are used to develop an application:

1. Planning: This is the stage where organizations start to plan around what is needed in an application, the new features that need to be built, and what languages will be used.
2. Requirements gathering and analysis: During this stage, all potential system requirements are gathered and recorded in a requirement specification document. There are tools available to gather these requirements, though they can be captured in a Word document or Excel sheet as well. Which method is used depends on the organization. The best way to capture these requirements is in a system. If any of the requirements change, we can make the necessary changes in the system as well.
3. Design: Consider this stage as the architect’s dream session. We take all those must-haves and would-loves from phase 1 and turn them into an actionable blueprint. This sets the stage, specifying the hardware and painting the big picture of our digital masterpiece. It is like drafting the dream from a wishlist to a blueprint!
4. Development: This isn’t just coding; it’s crafting! We whip up mini-programs – our “magic blocks” – and piece them together like a puzzle. Each block goes through its own “quality check party” to make sure it’s up to snuff. Similar to building blocks, this is where small pieces create big magic!
5. Testing: Think of this stage as dress rehearsal meets detective work. Each of those mini-programs gets its moment in the spotlight before we assemble the full ensemble. Then, we put the whole act through the wringer, making sure it’s standing ovation-ready. Think of it as a test fest, where we iron out the kinks!
6. Implementation and integration: This stage is like the grand premiere, where our star finally takes the stage! This is where our product undergoes the royal testing treatment and is ready to make its big debut. Will it be the next blockbuster on the market or the VIP guest in a client’s world? Either way, it’s showtime!
7. Production and maintenance: This stage has a different aspect – even rock stars need tune-ups. When real-world snags pop up, we roll out patches like a roadie rolls out amps. And because we’re always chasing perfection, get ready for some killer updates:

Figure 1.1: SDLC

The Waterfall model has helped change the way we develop applications smoothly and has been well adopted throughout organizations that went through the process step by step. There were a few releases every year. Adapting to that process was easy and more feasible.

However, over the years, things started changing. Organizations wanted to develop applications faster. The cloud became a thing, and everyone wanted to push out their applications and features to production with lightning speed. This brought about the Agile and DevOps era to the system.

The Agile methodology

The term agile software development refers to a fail-fast methodology and adopting new changes early on. Agile methods or Agile processes typically encourage a subdued management approach that pushes early inspection and adaptation.

The Agile methodology is a framework for including all teams so that they can work together to deliver high-quality software quickly. The Agile methodology helps businesses tie development to customer needs and company objectives.

In the early days, release cycles were long, and it took 3 months to a year to develop an application. Once that was done, everyone was relieved and ready to party.

The Agile methodology changed the mindset, wherein there are more releases at a quicker pace. Organizations have started to release multiple applications in a month, in a week, or even in a day. The Agile methodology shortened the life cycle of developing an application to a great extent. Organizations started following scrum processes, which are part of Agile.

Scrum

A process must adhere to a specific set of guidelines known as a “process framework” to be consistent with it. The scrum process highlights the importance of standing up every day for a very brief period and discussing sprints.

Sprints

Teams who use the Agile methodology work in short periods known as sprints. Sprints can be of any length, but a typical sprint lasts 2 weeks, regardless of the team. Teams complete specific tasks during these sprints, evaluate their performance, and then work to get better in the following sprint.

There are different types of scrum meetings:

• Daily standup meetings: This is a very short meeting that is generally no longer than 15-20 minutes. In this meeting, all the product owners, architects, and project managers meet to check the status of the sprints.
• Sprint planning meetings: In this meeting, everyone comes together to decide the duration of a sprint and the number of sprints needed to complete the task. Sprints are generally no longer than 30 days.
• Sprint review meetings: These are meetings where a review is done once sprints end. These meetings showcase what has been done around the product.
• Retrospective meetings: These meetings are for checking what has been done right and what has gone wrong.
• Checking the backlog meetings: In this meeting, the product backlog is tracked and checked to see how soon the product backlog can be worked upon.

All these meetings are headed or run by a person known as a scrum master. They organize daily stand-up meetings, reviews, demos, and other project-related gatherings. They make sure all the teams are adhering to the timeline. They are the one who tracks the progress of sprints to make sure products and projects are managed properly and on time. If there are any changes within the sprints, this can be managed and resolved after discussing this with the teams.

Teams working together

The Agile methodology emphasizes teams working together to make sure we have a viable product to be delivered to clients:

Figure 1.2: Agile methodology

Many sprint management tools are available to ensure the sprint goes smoothly, such as Trello boards:

Figure 1.3: Trello board

We can also use a whiteboard, where we can color-code the tasks and sprints:

Figure 1.4: Whiteboard

Agile software development evolved as a reaction to rigid software development models such as the Waterfall model. Agile methods include XP. Agile embodies many modern development concepts, including more flexibility, fast turnaround with smaller milestones, strong communication within the team, and more customer involvement.

Think of XP as the ultimate team sport in the software world, but way more chill. Two coders pair up like buddy cops in a movie, working off a plan that’s crystal clear. But here’s the fun twist: customers aren’t just spectators; they’re part of the squad! Imagine a group text that never ends – that’s how much everyone’s chatting to make sure things go smoothly. We can also say that XP is like having a coding jam session where everyone – coders and customers – gets to riff together in real time.

Picture DevOps as a dynamic duo of superhero teams, with developers and operations joining forces to save the business world. Their mission? Pumping out awesome apps and updates to wow the crowd. But then, DevSecOps enters the scene – a supercharged version of our dynamic duo. This time, they’ve got a new sidekick: security (Sec). By weaving Sec into the mix, we’re not just cranking out cool features; we’re making sure they’re as safe as a bank vault.

DevSecOps is an extension of DevOps. DevSecOps was introduced to increase the speed of DevOps. By integrating security into DevOps processes, operations teams were motivated and measured to stabilize production to meet service-level agreements (SLAs). It was about making new changes, but they needed to be made quickly. This made it look like a lot of things were being left behind.

In recent years, many organizations have evolved their DevOps practices to address their business challenges more successfully. DevOps is a contemporary method for meeting the demands of the business by delivering applications more quickly and of higher quality. DevOps now spans the entire enterprise, affecting processes and data flows and bringing about significant organizational changes. This differs from the past, where it was primarily concerned with just putting the IT services for applications in place.

DevOps continues to gain momentum and evolve every passing day. New technologies are being included as part of it.

The initial idea was to make sure that the communication gap between different teams during development processes could be removed. The communication gap has always been a huge challenge for organizations. Development teams work on developing the features needed by the organization, while the operations team works to make sure the application is working smoothly. At the same time, Sec comes into the picture and becomes a big bottleneck as soon as we talk about embedding security in the different phases of development. It opens up a can of worms that never ends.

We are now observing the adoption of many of the techniques that are used by developers to support more agile and responsive processes. This aids organizations in determining their current situation and possible future directions. The most crucial component of any process or technology is people. Even with the best processes and technologies, results are impossible to achieve without people.

Since we’re talking about DevSecOps, it starts with DevOps, which involves quickly delivering higher-quality software by combining and automating the work of software development, IT operations teams, project managers, and everyone working around the development pipeline. If an organization is willing to move toward DevSecOps from its traditional model, it needs to have DevOps in place. That’s contradictory to earlier development models.

Rather than relying on human intervention, the process aids in monitoring the security workflow. Additionally, it enhances our ability to identify security flaws in the ecosystem. Employees may feel replaced by automation in this way, which could make them resent giving up their current level of administrator authority. To get around the bottlenecks in the software development and deployment process, mostly on the ops side, the initial plan was to simply de-silo dev and ops.

DevSecOps has changed the role of Sec in DevOps. Sec just being in the end phase and being a big hump in the way of going to production has shifted to security being in every part of the development life cycle. It entails integrating security earlier in the application development life cycle and starting to think about infrastructure and application security right away. Additionally, it entails automating a few security checkpoints to prevent a delay in the DevOps workflow. Figuring out the right tools and processes for people can assist them in achieving their goals.

Instead of security stopping the whole pipeline, it is part of each of the following phases:

• Plan
• Code
• Build
• Test
• Release
• Continuous deployment and decommissioning
• Operate
• Continuous monitoring

Figure 1.5: DevSecOps in action

We can have the best tools that money can buy but DevSecOps will not work if your team is not working. You can have the most cooperative team, but nothing will work out if you don’t have the right set of tools.

Not all tools are DevSecOps-ready

Not all tools can fit into a pipeline

The quiet and secluded processes can not only destroy the DevOps culture but ultimately reduce the security posture of the whole organization.

We can have the best tools

We can have the best processes

We can have the best people

However, if the culture of the organization is not exercised, nothing will work

This compartmentalized way of thinking not only undermines the DevOps culture but also weakens the organization’s overall security posture. The secret is to reduce process friction to a minimum. Any organization’s processes are carried out by people.

DevSecOps processes, which aim to reduce the enterprise attack surface and enable effective management of technical security debt, are carried out by people using technologies. DevSecOps challenges the way traditional security teams integrate with the larger business, which is one of its most crucial aspects. If attitudes are to shift, it will take a top-down strategy to change behaviors and increase awareness at all levels of a company.

Understanding maturity starts with understanding where you stand in DevSecOps. The DevSecOps maturity model illustrates how security measures can be prioritized in conjunction with DevOps tactics. By utilizing DevOps techniques, security can be strengthened. The future-focused DevSecOps maturity model directs the application of the necessary guidelines and security measures to thwart attacks.

An incredible maturity model has been created by an open source community to understand the maturity of DevSecOps: the Open Web Application Security Project (OWASP) (OWASP DSOMM – https://owasp.org/www-project-devsecops-maturity-model/). There are five levels to the maturity model (https://dsomm.owasp.org):

Figure 1.6: Maturity model

Many organizations have come up with maturity models that either start from level 0 or level 1. The model we’ll be looking at talks about the four levels of maturity within organizations for DevSecOps.

There are many dimensions under the different categories, all of which talk about the level of maturity in the build process, testing artifacts, pinning artifacts, SBOM components, and much more. Let’s take a closer look.

Maturity level 1

Maturity level 1, within the context of the OWASP DevSecOps maturity model, represents the foundational stage of implementing security practices in your DevOps process. It’s the initial step that’s taken toward integrating DevSecOps into your organization.

Maturity level 1 is where you lay the groundwork. You’re getting the team to start thinking about security, but you haven’t gone full Mission Impossible on it. Think of maturity level 1 like your first day at the gym. You’re not lifting the heavy weights just yet; you’re learning the ropes and maybe doing some light cardio. Similarly, at level 1, you’re just getting started with integrating security into your DevOps process. It’s less about having airtight defenses and more about setting the stage: think basic security checks, simple monitoring, and everyone still getting to know each other’s roles.

Here’s what typically happens at this level:

• Security practices: Basic security protocols and practices have been established, but they are manually executed. The methods that are employed are typically straightforward and may not fully cover all security needs. While these practices are in place, they require considerable human effort and manual intervention, which could lead to inconsistencies and errors.
• Process initiation: At this level, teams start to recognize the importance of integrating security into the development process. However, practices are not yet fully structured or systematic.
• Education: The team might begin learning about security threats and how to prevent them. However, education and training in secure coding practices might not be comprehensive.
• Risk awareness: There’s a growing awareness of the potential risks of not integrating security fully into the DevOps process. The need for improvement is recognized, leading to the exploration of automated security measures.
• Automation: While the goal of DevSecOps is to automate as many security processes as possible, at this stage, little to no automation of security tasks exists. Manual work is predominant, which can be laborious and time-consuming.

Maturity level 2

Maturity level 2, in the context of the OWASP DevSecOps maturity model, signifies a progression from the initial stage of implementing DevSecOps in an organization. It’s the point where you start to incorporate and follow security best practices more systematically.

Let’s take a deeper look at this level:

• Adoption of best practices: The organization starts to adopt recognized security best practices. These practices are likely documented and have become a standard part of the development process.
• Continuous security: Security practices are not only implemented but are now applied continuously throughout the DevOps pipeline. This means that the security controls are not just a one-time event, but are instead consistently applied throughout the SDLC.
• Partial automation: This level sees the introduction of automation, but it is not yet extensive. Certain tasks are likely automated to reduce manual effort, improve consistency, and mitigate human error. However, several security processes may still rely heavily on manual work.
• Regular training: At this stage, there is likely more emphasis on educating the development and operations teams about security threats, secure coding practices, and how to use any new security tools that have been introduced.
• Proactive security: There’s a shift toward a more proactive stance on security. Rather than just responding to security issues when they arise, teams are working to anticipate and prevent potential security issues.

Maturity level 3

Maturity level 3 within the OWASP DevSecOps maturity model marks a pivotal point in the evolution of an organization’s DevSecOps journey. It signifies the transition from just setting up DevSecOps practices to actively progressing toward their maturity.

Level 3 comprises the following aspects:

• Advanced automation: The focus at this level is largely on automation. Most security practices are now automated, which reduces manual effort, increases efficiency, and minimizes human error. Security checks and protocols become an integral part of the entire software development pipeline.
• Integration of security: Security considerations are more thoroughly integrated into the DevOps process. This integration ensures that security is not an afterthought but a consistent theme from the very start of the SDLC.
• Proactive and continuous: At this level, security practices are not only proactive but also continuous. It’s not about implementing measures to fix issues as they arise but about embedding security practices to prevent issues from occurring in the first place.
• Regular reviews and updates: Security policies, practices, and automation scripts are regularly reviewed and updated to cope with emerging security threats and vulnerabilities. This keeps the security practices in line with the latest best practices.
• Enhanced training: There’s an increased focus on training, with development and operations teams regularly educated about current and emerging security threats. They are trained to use the latest security tools and follow updated secure coding practices.

Maturity level 4

At this level, we must set up the process and keep enhancing from there via automation and other processes.

KPIs help in measuring our goals and their priority. KPIs help us get to the point we wish to reach in the stipulated time. The whole DevOps phase or DevSecOps works in tandem to move to production. It depends on us where we want to take them.

Before moving toward these KPIs, we must ask ourselves some questions:

• Are we testing all the application’s features before pushing them to security?
• Are we educating our developers around security processes and tools, rather than forcing security upon them?
• What software development processes are we following?
• Do we just follow the OWASP Top 10, or have we created a certain process for that?
• How frequently is security being called in the SDLC?

All these questions take us to points where we can start thinking about taking our first step toward setting up the right processes and moving toward the best practices.

Some of the key KPIs for DevSecOps processes are as follows:

• Figuring out the amount of open source code that’s used in the code – that is, third-party libraries and dependencies.
• Where do we stand on automation processes?
• Are the tools aiding in having a smooth software pipeline?
• Are we able to reduce the bugs in the pipeline by fine-tuning it?
• How frequently are we fixing bugs?

These are just some of the parameters you need to consider; stay tuned for more detailed information.

When we talk about DevSecOps, the focus is often on processes and tools, but people – the team members involved in implementing and managing DevSecOps – are a crucial part of this equation. In simple terms, the “people aspect” of DevSecOps is all about how individuals within an organization understand, adopt, and execute the principles and practices of DevSecOps.

The following are the main elements of the people aspect of DevSecOps:

• Collaboration: In DevSecOps, development, security, and operations teams need to work together closely. This might be a shift from traditional ways of working, where these groups often worked in silos. Regular communication and collaboration become key.
• Shared responsibility: In the DevSecOps world, everyone shares responsibility for security – it’s not just the job of the security team. Developers, operations personnel, and others all have roles to play in maintaining security.
• Education and training: People need to know about the importance of security and how to incorporate it into their daily work. This involves ongoing training about security threats, safe coding practices, using security tools, and more.
• Culture shift: Adopting DevSecOps often involves a cultural shift within an organization. It requires moving toward a culture that values transparency, shared responsibility, continuous learning, and a proactive approach to security.
• Empowerment: Team members should feel empowered to make decisions related to security, and should feel comfortable reporting potential issues. This requires an environment of trust and openness, where people aren’t blamed for mistakes but are encouraged to learn from them.
• Skills and expertise: As security practices become more integrated into the development process, team members might need to develop new skills and expertise. This might involve learning about new tools, technologies, or methodologies.

The people aspect of DevSecOps is all about creating an environment where everyone in the team understands the importance of security, is capable of contributing to it, and is committed to maintaining it as a collective responsibility. It’s about fostering a culture of collaboration, learning, and shared accountability for security. We will discuss this in more detail in the upcoming chapters.

DevSecOps means we’re incorporating security considerations from the very beginning, not just tackling them at the end of the SDLC. With this approach, each stage of the development process must include security as a fundamental component.

DevSecOps actively brings these ideas to life. It assists organizations in developing applications securely by default. What we’re talking about here is a reshaped way of handling the SDLC – and it’s known as DevSecOps.

Traditionally, security was never given priority, even at the cost of neglecting to properly educate developers. But with DevSecOps, the two go hand in hand.

Understanding our current maturity level in this process gives us a sense of where we stand, and tracking KPIs allows us to measure our progress – to see where we were and where we are now, and to chart a path toward where we want to be.

Answer the following questions to test your knowledge of this chapter:

• What is DevSecOps? Think about this from your own experience.
• Does DevSecOps change the way you work?
• Who contributes to the DevSecOps program?