Implementing DevSecOps Practices E-Book

Vandana Verma Sehgal

• Herausgeber: Packt Publishing
• Kategorie: Wissenschaft und neue Technologien
• Sprache: Englisch

Seitenzahl: 390

Veröffentlichungsjahr: 2023

Beschreibung

DevSecOps is built on the idea that everyone is responsible for security, with the goal of safely distributing security decisions at speed and scale to those who hold the highest level of context. This practice of integrating security into every stage of the development process helps improve both the security and overall quality of the software. This book will help you get to grips with DevSecOps and show you how to implement it, starting with a brief introduction to DevOps, DevSecOps, and their underlying principles.

After understanding the principles, you'll dig deeper into different topics concerning application security and secure coding before learning about the secure development lifecycle and how to perform threat modeling properly. You’ll also explore a range of tools available for these tasks, as well as best practices for developing secure code and embedding security and policy into your application. Finally, you'll look at automation and infrastructure security with a focus on continuous security testing, infrastructure as code (IaC), protecting DevOps tools, and learning about the software supply chain.

By the end of this book, you’ll know how to apply application security, safe coding, and DevSecOps practices in your development pipeline to create robust security protocols.

Leseprobe

Implementing DevSecOps Practices

Supercharge your software security with DevSecOps excellence

Vandana Verma Sehgal

BIRMINGHAM—MUMBAI

Implementing DevSecOps Practices

Copyright © 2023 Packt Publishing

All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews.

Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the information contained in this book is sold without warranty, either express or implied. Neither the author, nor Packt Publishing or its dealers and distributors, will be held liable for any damages caused or alleged to have been caused directly or indirectly by this book.

Packt Publishing has endeavored to provide trademark information about all of the companies and products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guarantee the accuracy of this information.

Group Product Manager: Pavan Ramchandani

Publishing Product Manager: Neha Sharma

Book Project Manager: Ashwin Kharwa

Senior Editor: Divya Vijayan

Technical Editor: Irfa Ansari

Copy Editor: Safis Editing

Proofreader: Safis Editing

Indexer: Hemangini Bari

Production Designer: Gokul Raj S.T

DevRel Marketing Coordinator: Marylou De Mello

First published: December 2023

Production reference: 1231123

Published by

Packt Publishing Ltd.

Grosvenor House

11 St Paul’s Square

Birmingham

B3 1RB, UK

ISBN 978-1-80323-149-5

www.packtpub.com

This book is dedicated to my mentors, who pushed me to write about my DevSecOps experiences, and the Packt team, who positively pushed me at every step.

Vandana

Contributors

About the author

Vandana Verma Sehgal is a seasoned security professional with a current focus on DevSecOps at Snyk. In her previous experience, she has dealt with application security, vulnerability management, SOC, infrastructure security, and cloud security.

She is a seasoned speaker/trainer and has presented at various public events, ranging from OWASP Global AppSec and Black Hat events to regional events, such as BSides events in India. She is part of the OWASP Global Board of Directors. She also works in various communities on the diversity initiatives Infosecgirls, WoSEC, and null.

Vandana is a member of the Black Hat Asia Review Board as well as multiple other conferences, including Grace Hopper in India and OWASP AppSec in the USA. She is also one of the organizers of BSides Delhi.

She has been the recipient of multiple prestigious awards, such as the Cyber Security Woman of the Year Award 2020 at the Cyber Security Awards, Application Security Influencer 2020 by Whitesource, Global Cybersecurity Influencer in IFSEC Global’s “Top Influencers in Security and Fire” category, and the Cybersecurity Woman of the Year Award by the Women’s Society of Cyberjutsu in the “Secure Coder” category. She has also been listed as one of the top women leaders in the field of technology and cybersecurity in India by InstaSafe.

About the reviewers

Shaineel (Shain) Singh has over 25 years’ experience in the computing and telecommunication industries. He is the principal security architect for F5, working with businesses in various sectors throughout the Asia-Pacific region. Having held engineering and architecture roles in the systems, network, and security fields, Shain uses his cross-disciplinary skills to provide a lens into global security and industry trends. Shain likes to spend his time participating in humanitarian and technology-based community groups. He currently co-leads the OWASP Machine Learning Security Top 10 project and contributes to the DevSecOps and Zero Trust Cloud Security Alliance working groups, on their training and certification programs.

The fields of technology and security in particular change rapidly. In order to keep up with the pace, I am deeply indebted to practitioners who take the time to educate, share, and contribute to open source communities, including OWASP, Cloud Security Alliance, and the Linux Foundation. Communities thrive because of the open and healthy collaborative nature in which they operate, and for this, I also thank the community outreach and project leaders.

Rewanth Tammana is a security ninja, open source contributor, AWS Community Builder, and an independent consultant. Previously, he was a senior security architect at the National Bank of Dubai. He is passionate about DevSecOps, the cloud, and container security, has contributed around 17,000+ lines of code to Nmap, and holds industry certifications such as CKS and CKA.

Rewanth presents at security conferences worldwide, including Black Hat, DEF CON, Hack in the Box, CRESTCon, and Positive Hack Days. He was recognized as a Bugcrowd MVP Researcher (2018), having identified vulnerabilities in various organizations. He published an IEEE research paper on an offensive attack in machine learning and security and was part of the renowned Google Summer of Code.

You can get in touch with him at rewanthtammana.com.

Table of Contents

Preface

Part 1: DevSecOps – What and How?

1

Introducing DevSecOps

Product development processes

The Waterfall model

The Agile methodology

Understanding the shift from DevOps to DevSecOps

The new processes within DevSecOps

DevSecOps maturity levels

Maturity level 1

Maturity level 2

Maturity level 3

Maturity level 4

KPIs

DevSecOps – the people aspect

Summary

Think and act

Part 2: DevSecOps Principles and Processes

2

DevSecOps Principles

DevSecOps principles

Unifying the CI/CD pipeline

Fail fast

Automation and innovation in DevSecOps

Introducing compliance checks

Empowering teams to make decisions

Cross-skilling and educating teams and the cultural aspect approach

Proper documentation

Relevant checkpoints

Building and managing secure Dev environments and toolchains

Challenges within the DevSecOps pipeline that principles can resolve

Continuous application changes

The developer knowledge gap

Lack of AppSec tool integration

Summary

3

Understanding the Security Posture

Understanding your security posture

Regular meetings

Managing pipelines

Testing pipelines

Tools involved in pipelines

Why and what measures we take to secure the environment

Building the vulnerabilities inventory

Addressing vulnerabilities

Parameters to define the security posture

Discovering the third-party component

Measuring the effectiveness of the technologies used

Managing workflows

What measures can we take to monitor an environment?

A positive way toward the cloud-native world

Cloud-native architectures

Provisioning and configuring infrastructure

Automating controls

Securing the toolchains

Where does security stand in the whole development process?

Compliance and audit

Multi-cloud security

Monitoring

Incident response

Developer tools

Vulnerability management

Summary

4

Understanding Observability

Why do we need observability?

The key functions of observability

Linking observability with monitoring

Exploring the monitoring process

Implementing observability with monitoring

Challenges around observability

Making organizations observable

Summary

5

Understanding Chaos Engineering

Introducing chaos engineering

Why do we need chaos engineering?

Best practices while working with chaos engineering

Techniques involved in chaos engineering

Specific systems and services that organizations use for chaos engineering

Measuring the effectiveness of performing chaos engineering

Tools involved in chaos engineering

Basic principles of chaos engineering

Team communication strategies while performing chaos engineering experiments

Developing robust chaos engineering practice from failures

Challenges around chaos engineering

How chaos engineering is different from other testing measures

Summary

Part 3: Technology

6

Continuous Integration and Continuous Deployment

What is a CI/CD pipeline?

CI

CD – continuous delivery and continuous deployment

The benefits of CI/CD

Automating the CI/CD pipeline

Source control

Automated builds

Continuous testing

Artifact storing

Deployment automation

Environment consistency

Monitoring and feedback

Rollbacks

The importance of a CI/CD pipeline

Summary

7

Threat Modeling

What is threat modeling?

The importance of threat modeling in the software development lifecycle

Why should we perform threat modeling?

Threat modeling techniques

Integrating threat modeling into DevSecOps

Pre-development phase

Design phase

Development phase

Testing phase

Deployment phase

Open source threat modeling tools

How threat modeling tools help organizations

Reasons some organizations don’t use threat modeling

Summary

8

Software Composition Analysis (SCA)

What is SCA?

How does SCA work?

SCA tools and their functionalities

The importance of SCA

The benefits of SCA

SAST versus SCA

The SCA process

SCA metrics

Integrating SCA with other security tools

Resolving the issues without breaking the build

Detection of security flaws

Open source SCA tools

Discussing past breaches

Summary

9

Static Application Security Testing (SAST)

Introduction

What is SAST?

SAST tools and their functionalities

Identifying vulnerabilities early in the development process

The SAST process

SAST metrics

Integrating SAST with other security tools

Resolving issues without breaking the build

The benefits of SAST

The limitations of SAST

Open source SAST tools

Case study 1

Case study 2

Loss due to not following the SAST process

Summary

10

Infrastructure-as-Code (IaC) Scanning

What is IaC?

The importance of IaC scanning

IaC toolset functionalities

Advantages and disadvantages of IaC

Identifying vulnerabilities using IaC

What is the IaC process?

IaC metrics

IaC versus SAST

IaC security best practices

IaC in DevSecOps

Understanding DevSecOps

The role of IaC in DevSecOps

The DevSecOps process with IaC

Key benefits

Challenges and mitigation

Conclusion and future outlook

Open source IaC tools

Case study 1 – the Codecov security incident

Case study 2 – Capital One data breach

Case study 3 – Netflix environment improvement

Summary

11

Dynamic Application Security Testing (DAST)

What is DAST?

Advantages and limitations of DAST

The DAST process

DAST usage for developers

DAST usage for security testers

The importance of DAST in secure development environments

Incorporating DAST into the application development life cycle

Advanced DAST techniques

Choosing the right DAST tool

How to perform a DAST scan in an organization

Integrating DAST with other security tools

Incorporating DAST into DevOps processes

Prioritizing and remediating vulnerabilities

Comparing DAST with other security testing approaches

SAST

IAST

RASP

The future of DAST

Summary

Part 4: Tools

12

Setting Up a DevSecOps Program with Open Source Tools

Techniques used in setting up the program

Understanding DevSecOps

Setting up the CI/CD pipeline

The technicalities of setting up a CI/CD pipeline

Implementing security controls

Identifying open source security tools

Implementing security policies and procedures

Managing DevSecOps in production

Monitoring and managing the DevSecOps pipeline in production

Using open source tools for monitoring, logging, and alerting

Incorporating continuous compliance and auditing into the pipeline

Managing incidents and responding to security breaches

The benefits of the program

Summary

Part 5: Governance and an Effective Security Champions Program

13

License Compliance, Code Coverage, and Baseline Policies

DevSecOps and its relevance to license compliance

The distinction between traditional licenses and security implications

Source code access

Modification and redistribution

Community oversight

Vendor dependency

Cost and resource allocation

Different types of software licenses

Permissive licenses (MIT, Apache)

Copyleft licenses (GPL, LGPL)

Proprietary licenses

The impact of software licenses on the DevSecOps pipeline

How to perform license reviews

Tools and techniques

Engaging legal and security teams

Documentation and continuous improvement

Fine-tuning policies associated with licenses

Establishing an organizational standard

Exception handling

Continuous review and improvement

Case studies

Case study 1 – the Redis licensing change

Case study 2 – Elastic versus AWS licensing drama

Summary

14

Setting Up a Security Champions Program

The Security Champions program

Structuring your Security Champions program

Things to remember before setting up the program

Who should be a Security Champion?

How a Security Champions program would look

The top benefits of starting a Security Champions program

What does a Security Champion do?

Security Champions program – why do you need it?

Shared responsibility models

The roles of different teams

Buy-in from the executive

The importance of executive buy-in

How to secure executive buy-in

Measuring the effect of the Security Champions program

Technical aspects to check the effectiveness of the Security Champions program

Strategic aspects to check the effectiveness of the Security Champions program

Summary

Part 6: Case Studies and Conclusion

15

Case Studies

Case study 1 – FinTech Corporation

Challenges faced before implementing DevSecOps

Steps were taken to transition to DevSecOps

Results and impact on the company’s software development

Lessons learned

Case study 2 – Verma Enterprises

Challenges faced by the organization in terms of security

Implementation of DevSecOps practices and tools

Results and benefits achieved

Case study 3 – HealthPlus

The importance of security in healthcare data and systems

The implementation of DevSecOps practices and tools to improve security

Results and benefits achieved

Case study 4 – GovAgency

Security requirements for government agencies

The implementation of DevSecOps practices and tools to meet compliance and improve security

Results and benefits achieved

Case study 5 – TechSoft

Security requirements for the IT sector

The implementation of DevSecOps practices and tools to meet compliance and improve security

Results and benefits achieved

Common lessons learned and best practices

Lessons learned from implementing DevSecOps practices and tools

Best practices for implementing DevSecOps in software development

Summary

16

Conclusion

DevSecOps – what and how?

DevSecOps principles and processes

DevSecOps tools

DevSecOps techniques

Governance and an effective Security Champions program

Topics covered in this book

What’s next?

Case studies and conclusion

Index

Other Books You May Enjoy

Preface

The integration of Development, Security, and Operations – commonly known as DevSecOps – has emerged as a pivotal approach to software delivery. This methodology not only emphasizes the importance of automating software delivery processes but also places paramount importance on integrating security practices, right from the initial stages of development.

The essence of DevSecOps lies in its ability to break down traditional silos, fostering a culture of shared responsibility for both software quality and security. It recognizes that in the age of cyber threats and frequent software releases, security cannot be an afterthought; it must be ingrained at every stage of the software life cycle.

This book is a culmination of insights, best practices, and hands-on techniques to implement DevSecOps in real-world environments. It delves deep into the practical aspects, guiding readers through the nuances of setting up robust CI/CD pipelines, integrating security tools, automating security checks, and fostering a culture that values security as much as speed.

Whether you are an IT professional aiming to understand the intricacies of DevSecOps, a security enthusiast keen on integrating security into DevOps practices, or a seasoned practitioner looking for hands-on guidance, this book promises to be a comprehensive resource. Through its pages, we’ll demystify the challenges, celebrate the successes, and, above all, pave the way for a future where software is developed swiftly, securely, and efficiently.

Join me on this enlightening journey as we delve into the world of DevSecOps, exploring its principles, practices, and profound impact on the realm of software delivery.

Who this book is for

This book is crafted for a diverse range of readers who are either stepping into the world of DevSecOps or looking to deepen their understanding of its practical applications. Here’s a closer look at who would benefit the most from this resource:

Software developers and engineers: For professionals who design and code applications, this book offers insights into integrating security measures right from the inception of a project. Understand how to write secure code and identify potential vulnerabilities even before they become threats.IT operations professionals: If you’re involved in deploying, monitoring, or managing applications, this guide will introduce you to the tools and practices that ensure smooth and secure deployments, emphasizing the importance of infrastructure as code and automated security checks.Security professionals: Those specializing in cybersecurity will benefit from the book’s emphasis on bridging the gap between security and other IT disciplines. Learn how to work collaboratively with development and operations teams, integrate security tools into CI/CD pipelines, and automate security protocols.DevOps practitioners: If you’re already familiar with DevOps but wish to delve deeper into the security aspect, this book is for you. Understand how DevSecOps extends and refines the DevOps approach by embedding security in every stage of the software delivery life cycle.Technical architects and consultants: Professionals responsible for designing IT ecosystems will gain insights into structuring systems that are both agile and secure, ensuring that security considerations are not just add-ons but foundational elements.IT leaders and managers: For decision-makers aiming to implement a DevSecOps culture in their teams or organizations, this book offers a roadmap. Learn about the benefits, challenges, and strategies to promote a culture where security and agility go hand in hand.Students and academics: Those in academia, either studying software development, IT management, or cybersecurity, will find this book a valuable addition to their curriculum, offering real-world insights and practical methodologies beyond theoretical knowledge.

This book is a valuable resource for anyone keen on understanding the synergy between development, operations, and security and how to implement practices that ensure faster, more efficient, and most importantly, secure software delivery.

What this book covers

Chapter 1, Introducing DevSecOps, discusses the basics of DevSecOps and the different maturity levels involved in the current state and future attainable state of the practices involved in DevSecOps. It helps organizations understand where they are and where things can be taken next. People are the most important element in any technology and process. You can use the best of technology and processes, but without people, goals can’t be achieved. In this chapter, we will learn about the involvement of different teams and what key performance indicators are.

Chapter 2, DevSecOps Principles, explores the DevSecOps principles, which are the key concepts to pick up a program at any point of the development cycle and take it to the maturity stage.

Chapter 3, Understanding the Security Posture, covers the understanding your security posture of DevSecOps pipeline within an organization. We will also be covering what measures are we taking to secure the environment and why, what measures can we take to monitor an environment?, and where does security stand in the whole development process?

Chapter 4, Understanding Observability, examines what observability is and how it is different from monitoring. Also, we will look at how observability helps DevSecOps.

Chapter 5, Understanding Chaos Engineering, covers the aspects of chaos engineering and how data is fed to a system, well as understanding how the system fails.

Chapter 6, Continuous Integration and Continuous Deployment, discusses what is CI/CD, the benefits of CI/CD, how we can automate the CI/CD pipeline, and the importance of the CI/CD pipeline.

Chapter 7, Threat Modeling, dives into threat modeling, which involves examining applications through the eyes of an attacker in order to identify and highlight security flaws that could be exploited. This makes security a part of the organizational culture, laying the groundwork for a DevSecOps workplace. Threat modeling also helps teams better understand and learn each other’s roles, objectives, and pain points, resulting in a more collaborative and understanding organization. The chapter also covers the free and open source tools for threat modeling.

Chapter 8, Software Composition Analysis (SCA), explores third-party dependencies, which are one of the biggest concerns when we deal with code. Some 80–90 percent of software code contains third-party dependencies or libraries. These dependencies come with their own issues and benefits. In this chapter, we will discuss software composition analysis and its uses. We also cover the free and open source tools for SCA.

Chapter 9, Static Application Security Testing (SAST), examines SAST, which happens early in the Software Development Life Cycle (SDLC) because it does not require a working application and can be performed without executing any code. The chapter also covers the free and open source tools for SAST.

Chapter 10, Infrastructure-as-Code (IaC) Scanning, discusses Infrastructure-as-Code (IaC) scanning, which looks for known vulnerabilities in your IaC configuration files. IaC improves usability and functionality while also assisting developers with infrastructure deployment. The chapter will share the aspects of IaC scanning and usability testing. The chapter also covers the free and open source tools for IaC.

Chapter 11, Dynamic Application Security Testing (DAST), delves into DAST, which is the process of analyzing a web application from the frontend to find vulnerabilities. A DAST scanner looks for results that aren’t part of the expected result set and detects security flaws. The chapter also covers the free and open source tools for DAST.

Chapter 12, Setting Up a DevSecOps Program with Open Source Tools, covers the tools and tips to set up an effective DevSecOps program, covering it from 360 degrees.

Chapter 13, Licenses Compliance, Code Coverage, and Baseline Policies, explores license compliance, which ensures we manage licenses and policies and keep them up to date.

Chapter 14, Setting Up a Security Champions Program, talks about who security champions are and how we can set up a security champions program.

Chapter 15, Case Studies, discusses case studies from organizations that have set up DevSecOps programs. What were the initial setbacks that eventually contributed to the DevSecOps program's success ? We look at the lessons learned along the way.

Chapter 16, Conclusion, concludes the book, focusing on what we have learned from the different chapters and offering a call to action on the way forward.

To get the most out of this book

Software/hardware covered in the book

Operating system requirements

Jenkins

Windows, macOS, or Linux

OWASP open source tools

Conventions used

There are a number of text conventions used throughout this book.

Bold: Indicates a new term, an important word, or words that you see on screen. For instance, words in menus or dialog boxes appear in bold. Here is an example: “Select System info from the Administration panel.”

Tips or important notes

Appear like this.

Get in touch

Feedback from our readers is always welcome.

General feedback: If you have questions about any aspect of this book, email us at [e-mail] and mention the book title in the subject of your message.

Errata: Although we have taken every care to ensure the accuracy of our content, mistakes do happen. If you have found a mistake in this book, we would be grateful if you would report this to us. Please visit www.packtpub.com/support/errata and fill in the form.

Piracy: If you come across any illegal copies of our works in any form on the internet, we would be grateful if you would provide us with the location address or website name. Please contact us at [e-mail] with a link to the material.

If you are interested in becoming an author: If there is a topic that you have expertise in and you are interested in either writing or contributing to a book, please visit authors.packtpub.com.

Share Your Thoughts

Once you’ve read Implementing DevSecOps Practices, we’d love to hear your thoughts! Please click here to go straight to the Amazon review page for this book and share your feedback.

Your review is important to us and the tech community and will help us make sure we’re delivering excellent quality content.

Download a free PDF copy of this book

Thanks for purchasing this book!

Do you like to read on the go but are unable to carry your print books everywhere?

Is your eBook purchase not compatible with the device of your choice?

Don’t worry, now with every Packt book you get a DRM-free PDF version of that book at no cost.

Read anywhere, any place, on any device. Search, copy, and paste code from your favorite technical books directly into your application.

The perks don’t stop there, you can get exclusive access to discounts, newsletters, and great free content in your inbox daily

Follow these simple steps to get the benefits:

Scan the QR code or visit the link below

https://packt.link/free-ebook/978-1-80323-149-5

Submit your proof of purchaseThat’s it! We’ll send your free PDF and other benefits to your email directly

Part 1:DevSecOps – What and How?

This part will introduce you to DevSecOps, provide a bit of background information, and offer coverage of how different software development methods have played a role in its formation, from Waterfall to Agile. This chapter also looks at the various components of DevSecOps. We then focus on familiarizing you with DevSecOps basics and how an organization can set up DevSecOps.

This part has the following chapter:

Chapter 1, Introducing DevSecOps

1

Introducing DevSecOps

DevSecOps is a term that is getting a lot of attention from everywhere. Organizations used to perform product security checks at the end of the software development life cycle (SDLC) before the development of DevOps and DevSecOps. Security was viewed as less important than the other phases because the emphasis was primarily on application development. Most of the other stages would have been completed and the products would be nearly finished by the time engineers performed security checks. Therefore, finding a security threat at such a late stage required rewriting countless lines of code, a painfully time-consuming and laborious task. Patching eventually became the preferred solution, as expected. “As a result, it was assumed nothing could go wrong.”

In this chapter, we will learn about the basics of DevSecOps and the different maturity levels involved in the current state and future attainable state of the practice involved in DevSecOps.

We will also cover the following aspects:

The involvement of different teamsKey performance indicators (KPIs)

We will also cover the evolution of DevOps and DevSecOps in terms of the Waterfall model, understand the agile methodology, and learn how DevSecOps is changing the paradigm for organizations.

In the chapter, we are going to cover the following main topics:

Product development processes:Waterfall modelAgile methodologyDevSecOps and its evolutionThe new processes within DevSecOpsMaturity levels:Maturity level 1Maturity level 2Maturity level 3Maturity level 4KPIsDevSecOps – the people aspect

Product development processes

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:

SpiralWaterfall modelAgile 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:

PlanningRequirements gathering and analysisDesignDevelopmentTestingImplementation and integrationProduction and maintenance

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

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

Understanding the shift from DevOps to DevSecOps

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.

The new processes within DevSecOps

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:

PlanCodeBuildTestReleaseContinuous deployment and decommissioningOperateContinuous 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.

DevSecOps maturity levels

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

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.

DevSecOps – the people aspect

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