SHIFTING SECURITY LEFT: A QUALITATIVE STUDY

by

King Butter

ANNETTE CRAVEN, PhD, CPA, ACC, Faculty Mentor and Chair

PAMELYN WITTEMAN, PhD, Committee Member

SEGUN ODION, PhD, Committee Member

W
Cheryl Boncuore, PhD, Interim Dean
IE
School of Business, Technology, and Health Care Administration
EV

A Dissertation Presented in Partial Fulfillment

Of the Requirements for the Degree

PR

Doctor of Philosophy

Capella University

March 2024

© King Butter, 2024

 Abstract

As organizations attempt to address ever-increasing security threats, they must also

address the efficiency of processes and procedures to combat limited resources. Many

organizations are re-evaluating their approaches to security within software pipelines to gain

efficiency. Automation and shifting security left have emerged as proven methods for producing

reliable, repeatable results while freeing up resources. This generic qualitative inquiry answers

the question of how development, security, and operations (DevSecOps) engineers approach

shifting security automation to the left. The expected utility theory guided the research. This

generic qualitative inquiry uses semi-structured interviews, which were recorded and transcribed.

W
The researcher interviewed a sample of 10 DevSecOps engineers with over ten years of
IE
experience with security and software pipelines. Previous studies addressed the need to shift

security left and the need for automation in software development pipelines.
EV
In contrast, this study focuses on the process DevSecOps engineers use to determine what

security processes can move and their optimal locations within a software development pipeline.

This study confirmed the desire of DevSecOps professionals to shift security left in the pipeline.
PR

This study also found that limited resources are the most significant barrier to both shifting

security left and implementing automated security.

4
 Dedication

I want to dedicate this paper to the family that supported me on this journey. To my

children, Maxwell and Ellie, you are why I returned to school so many years ago. I wanted to

prove that there is always time to continue your education. As I watch you both continue through

school and excel, I am beaming with pride. You both have motivated me to continue this journey

and ensure I follow the road to completion.

To my wife Cammy, thank you for all of your support. You were there to help me believe

that whenever I was unsure, I could go on. You put up with cold beds and lonely nights as I

W
worked to follow my dream. Thank you for never judging me and always supporting me. There
IE
is no way I could have done this without you.
EV
PR

5
Acknowledgments

Completing this dissertation was only possible with the guidance and mentorship of many

people. It truly does take a village, and I would like to take this opportunity to thank those who

made this all possible.

First, I would like to give a huge thank you to my dissertation committee. Dr. Segun

Odion and Dr. Pamelyn Wittteman provided incredible guidance, making me feel like a peer.

The wisdom they offered made me not only a better scholar but also a better person. Dr. Annette

Craven was the best mentor I could have asked for. She kept me motivated when I started to feel

burned out and always found the positives when I wanted to focus on the negative. She was a

W
beacon of light in what became, at times, a bleak process.
IE
Although not a part of my committee, Dr. Rich Schuttler guided my initial research and

ensured I held myself to the highest possible standards. Dr. Rich was unafraid to have hard
EV
conversations about the quality of my work. This honest feedback made me look at myself in the

mirror and make changes. Dr. Rich taught me that it was okay to use the resources at my disposal

and reach out for help.

PR

6
Table of Contents

Acknowledgments................................................................................................................6

List of Tables .....................................................................................................................11

List of Figures ....................................................................................................................12

CHAPTER 1. INTRODUCTION ......................................................................................10

Background of the Study ...................................................................................................11

Need for the Study .............................................................................................................13

Purpose of the Study ..........................................................................................................14

Significance of the Study ...................................................................................................15

W
Research Question .............................................................................................................16
IE
Definition of Terms............................................................................................................17

Research Design.................................................................................................................17
EV
Assumptions and Limitations ............................................................................................19

Assumptions...........................................................................................................19

General Methodological Assumptions .......................................................19

PR

Theoretical Assumptions ...........................................................................20

Topic-Specific Assumptions ......................................................................20

Limitations .............................................................................................................20

Design Flaw Limitations ............................................................................20

Delimitations ..............................................................................................21

Organization of the Remainder of the Study .....................................................................21

CHAPTER 2. LITERATURE REVIEW ...........................................................................22

Introduction ........................................................................................................................22

7
Methods of Searching ........................................................................................................22

Theoretical Orientation for the Study ................................................................................23

Review of the Literature ....................................................................................................24

Early Approaches to Software Development .........................................................25

Process-Based Approaches to Software Development ..........................................26

Object Oriented Methodologies .............................................................................27

The Birth of Iterative Approaches .........................................................................28

Hybrid Approaches ................................................................................................29

Addressing Security ...............................................................................................31

W
Attempts to Shift Left ............................................................................................34
IE
Synthesis of the Research Findings ...................................................................................37

Critique of Previous Research Methods ............................................................................39

EV
Summary ............................................................................................................................41

CHAPTER 3. METHODOLOGY .....................................................................................43

Research Question .............................................................................................................44

PR

Research Design.................................................................................................................44

Target Population and Sample ...........................................................................................45

Population ..............................................................................................................45

Sample……………………………………………………………………………45

Procedures ..........................................................................................................................46

Participant Selection ..............................................................................................46

Protection of Participants .......................................................................................46

Expert Review ........................................................................................................47

8
 Data Collection ......................................................................................................48

Data Analysis .........................................................................................................50

Instruments .........................................................................................................................52

The Role of the Researcher ....................................................................................52

Ethical Considerations .......................................................................................................53

Summary ............................................................................................................................54

CHAPTER 4. FINDINGS ..................................................................................................55

Description of the Sample .................................................................................................55

Research Methodology Applied to the Data Analysis .......................................................57

W
Presentation of Data and Results of the Analysis ..............................................................58
IE
Interviews ...............................................................................................................58

Coding and Analysis ..............................................................................................62

EV
Themes ...................................................................................................................64

Summary ............................................................................................................................66

CHAPTER 5. FINDINGS AND CONCLUSIONS ...........................................................68

PR

Summary of the Results .....................................................................................................68

Discussion of the Results ...................................................................................................69

Theme 1: The Developer's Experience Directly Correlates to the Success of Attempts to

Implement Security Within a Software Development Pipeline .................69

Theme 2: Resource Scarcity Limiting the Ability to Perform Security Implementation

and Optimization........................................................................................70

Theme 3: The Furthest Left a Process Can Shift is Explicitly Determined by the

Availability of All Required Inputs to Provide Usable Outputs ................70

9
Conclusions Based on the Results .....................................................................................71

Comparison of the Findings with the Theoretical Framework and Previous Literature

....................................................................................................................71

Interpretation of the Findings.................................................................................73

Limitations ........................................................................................................................74

Implications for Policy or Practice ....................................................................................74

Recommendations for Future Research .............................................................................76

Recommendations Developed Directly from the Data ..........................................76

Recommendations Derived from Methodological, Research Design, or Other Limitations

W
of the Study ................................................................................................77
IE
Conclusion .........................................................................................................................77

REFERENCES ..................................................................................................................79
EV
PR

10
List of Tables

Table 1. Demographic Information of Research Participants………………………………...55

Table 2. Coding of Participant Responses to Semi-structured Interview Questions….………63

W
IE
EV
PR

11
List of Figures

Figure 1. DevOps Pipeline Diagram …………………………………………………………..11

Figure 2. A Butter Approach to Shifting Left ………………………………………………….75

W
IE
EV
PR

12
 CHAPTER 1. INTRODUCTION

Almeida et al. (2022) described the DevSecOps philosophy as combining the speed of

code delivery with the security of the code. Security begins at the coding level, and writing

secure code is a cornerstone of the DevSecOps philosophy (Woody et al., 2020). This

philosophy has led to the introduction of various tools into existing software pipelines. Recent

studies have shown that many new tools specifically target DevSecOps practices, such as shifting

security left (Rajapakse et al., 2021).

Studies have shown that manual security tasks are traditionally migrated to automated

tasks (Khan & Shameem, 2020). The authors found that more research is needed to develop a

W
model to provide best practices for managing the DevOps process. Current research has indicated
IE
that it is critical to move security processes as far left as possible (Rajapakse et al., 2022).

Shifting security left is DevOps terminology for placing security features earlier in the
EV
development pipeline to anticipate better and manage new software development and

deployment risks. As illustrated in Figure 1, a software pipeline operates in stages, moving from

left to right. Shifting left simply means moving a process to an earlier stage in the pipeline.
PR
Figure 1

DevOps Pipeline Diagram

W
Note. A visual representation of a software development pipline. From DevOps Pipeline

Diagram, By I. A. Verma, 2023, upGrad KnowledgeHut

IE
(https://www.knowledgehut.com/blog/devops/devops-pipeline-diagram).

Akbar et al. (2022) studied the challenges associated with adopting a DevSecOps
EV

mentality and shifting security to the left in software development. The authors found a lack of

models and strategies for shifting security left that apply to real-world industries. Additionally,
PR

determining which processes to move and how far left they should shift is a question still left

unanswered.

Background of the Study

Improper implementation, or a lack of security in software development pipelines, creates

a breeding ground for potentially catastrophic consequences. IBM (2021) found that

organizations that have not modernized their security implementations spend $750,000 more

when a data breach occurs than those that have modernized.

11
 By shifting security left, there is a gain in efficiencies, and the detection of issues is

shifted to the prevention of issues (Rajapakse et al., 2021). However, IBM (2021) found that the

time it takes to discover breaches has increased by a week, even though the number of

organizations automating security within their software development pipelines is up by 13%. If

these items can be addressed earlier in the cycle, they will align with the agile principle of failing

quickly (Khan & Shameem, 2020). IBM (2021) also found that the cost of security mitigation

was $3.05 million less when organizations applied automation to security processes.

Understanding how to approach shifting security processes left in the pipeline allows users to

optimize the use of resources and increase efficiency.

W
Jiménez et al. (2019) described automation as crucial in effectively implementing the
IE
shift-left concept. Security automation becomes difficult, as many companies overlook security

when evaluating the benefits of DevOps (Mansfield-Devine, 2018). With many commercial
EV
codebases consuming third-party code (Ponta et al., 2020), security scanning has become even

more necessary. Woody et al. (2020) found that existing frameworks help with the automated

scanning of the consumed code. Through a mixed-method approach and the use of case studies,
PR

Udhayakumar and Sivasubramanian (2022) found that an average of 81% of the vulnerabilities

found in deliverable software could be mitigated earlier by shifting security left in the

development pipeline.

There is a direct correlation between the mitigation of threats and security automation.

Ben Othmane et al. (2017) utilized a quantitative study to quantify and identify the impact of

automated factors surrounding security in software. The authors found that automated testing

provides the ability to help predict threats, which is a focus for many organizations. Sebastiano

and Nik (2020) surveyed 52 software developers with various experience levels. The authors

12
found that automated testing, along with the automation of processes like code reviews, has been

shown to help development teams achieve the fail-fast portion of the DevOps philosophy.

Failing faster has been found to create a shortened feedback loop (Diaz et al., 2019).

Security automation is a process that increases efficiency and prevents issues during the build

cycle (Alexander et al., 2020). Through a survey of Department of Defense Project Management

Office personnel, Kramer and Wagner (2019) found that the expanded levels of automation have

also led to better acceptance of DevOps principles.

Ultimately, there is a need for organizations to modernize their security implementations

to avoid catastrophic consequences. With increasing security threats, businesses must address

W
vulnerabilities swiftly to protect their assets. When shifting security left, there is a gain in
IE
efficiencies, and the detection of issues becomes prevention of issues. Security automation

enhances the build cycle by increasing efficiency and preventing potential issues. Automation of
EV
processes and testing helps development teams achieve the fail-fast portion of the DevOps

philosophy. The need for security is well-researched, but the implementation is not.

Consequently, this creates a gap that needs addressing.

PR

Need for the Study

Although current research has defined the need for shifting left and its successes, it has

yet to define how to approach where specific security automation processes should occur in the

software development pipeline. Woody et al. (2020) found that a wealth of documentation exists,

highlighting the need for security in the pipeline. Rajapakse et al. (2022) state that security

processes should move as far left as possible. However, previous literature did not investigate

what functions need to move and where. Researching to gather data to answer these questions

and meet the DevOps principle of data-based decision-making is critical.

13
Purpose of the Study

The purpose of this generic qualitative inquiry is to explore how DevSecOps engineers

approach shifting security automation to the left. Shifting left refers to implementing security

earlier, as a development pipeline traverses stages from left to right. The target population is

developers and security engineers currently employing DevSecOps practices. Organizations must

evaluate their approach to security to answer what and where to shift left.

The general problem is that organizations have not placed enough focus on security

threats, especially as they relate to software pipelines. Research has indicated that security

threats are rising, and businesses must address vulnerabilities to protect their assets (Zaydi &

W
Nassereddine, 2020). Khan et al. (2022) found that not considering security at each phase of the
IE
software development lifecycle has a direct impact on the integrity of deliverable data and

services. Sebastiano and Nik (2020) found that although the implementation of security in the
EV
pipeline is becoming much more common, it is still most commonly an afterthought. IBM

(2021) found that organizations that have not modernized their implementations of security

spend $750,000 more when a data breach occurs than those organizations that have modernized.
PR

The root cause of this lack of attention to security is the absence of best practices

regarding increasing security posture by shifting security to the left in the development pipeline.

The proposed study sought to understand how software developers and system architects

approach shifting security automation to the left. The expected utility theory will be the primary

method for understanding this phenomenon.

The specific problem is a lack of best practices regarding increasing security posture, by

shifting security to the left. The proposed study will seek to understand how software developers

and system architects approach shifting security automation to the left. By shifting security left,

14
there is a gain in efficiencies, and the detection of issues is shifted to the prevention of issues

(Rajapakse et al., 2021).. However, IBM (2021) found that the time it takes to discover breaches

has increased by a week, even though the amount of organizations automating security within

their software development pipelines is up by 13%. If these items can be addressed earlier in the

cycle, they will align with the agile principle of failing quickly (Khan & Shameem, 2020). IBM

(2021) also found that the cost of security mitigation was $3.05 million less when organizations

applied automation to security processes. Understanding how to approach shifting security

processes left in the pipeline allows users to optimize the use of resources and increase

efficiencies.

W
Understanding the process that DevSecOps engineers use when deciding where to place
IE
security processes in the pipeline is essential (Bajpai & Lewis, 2022). This study's outcome

directly supports improving security within software development pipelines. Organizations

EV
deciding to use the process defined by this study will have a consistent, reliable approach to

shifting security to the left within their pipelines.

Significance of the Study

PR

There is a need for security automation in shifting security left (Leite et al., 2020) and

removing barriers to implementing security automation (Zheng et al., 2020). Those consuming

software delivered via shift-left pipelines gain the advantage of a more stable and secure

deliverable (Rajapakse et al., 2021). Shifting security also benefits developers and policymakers

by allowing mitigation before the issues become more resource-intensive and increase costs

(Udhayakumar & Sivasubramanian, 2022).

The shift-left mentality yields positive results, even outside of the software pipeline.

Cone et al. (2019) found that a shift-left approach to high-density advanced package design

15
improved efficiencies, as verification steps occurred during integration and operation as opposed

to post-design completion. Gentile et al. (2020) identified a need to analyze network

vulnerabilities in water distribution networks during planning to reduce maintenance costs and

avoid service disruptions.

The approach to shifting security left and where specific security automation processes in

the software development pipeline should occur has yet to be defined. Therefore, this study will

attempt to define a set of best practices for increasing an organization's security posture by

shifting security to the left. A well-defined process may evolve from semi-structured interviews

focused on the shift left decision-making process, which could help other professionals make

W
informed decisions regarding shifting security left. This study will also provide a foundation for
IE
future researchers to explore further the dynamics of shifting security left in development

pipelines.
EV
The significance of this research to information technology comes from organizations

needing to be more proactive about cybersecurity, as threats are becoming more frequent

(Murugesan et al., 2020). This research may provide insights enabling organizations to predict
PR

and catch security issues further left in the software development process (Ben Othmane et al.,

2017). Increases in efficiency occur, ensuring no wasting of development cycles to build a faulty

product, as is the case when testing occurs to the right (Jiménez et al., 2019). This approach

directly impacts the IT security tenets of integrity, confidentiality, and availability.

Research Question

RQ1: How do DevSecOps engineers approach shifting security automation to the left?

16
Definition of Terms

CI/CD pipeline. Continuous Integration/Continuous Delivery pipelines ensure rapid

deployment of software releases in real-time (Mansfield-Devine, 2018).

DevOps. The product of bringing business users, system developers, and IT operations

together under one umbrella (Kumar & Goyal, 2020).

DevSecOps. DevOps with embedded security controls (Kumar & Goyal, 2020).

DevSecOps Engineers. Individual contributors are responsible for creating security

requirements within an agile software development environment (Tomas et al., 2019).

Security Automation. The ability to detect, analyze, and remediate cyber-attacks

W
programmatically by identifying potential threats, triaging and categorizing alerts, and
IE
responding promptly to threats as they occur. (Mohammad & Surya, 2018).

Shifting Left. Moving an item earlier in the software development pipeline, which runs
EV
steps from left to right (Mythily et al., 2019).

Research Design

A qualitative research approach to collect data based on literature reviews is the most
PR

appropriate. Creswell and Poth (2016) stated that qualitative approaches use the experiences and

perspectives of individuals to understand a process better. Quantitative approaches compare

variables and determine their relationship (Creswell & Poth, 2016). Since the interviews will

focus not only on the process itself but the experiences and perspectives of the respondents, it

aligns with the qualitative approach. The information obtained from this study may help define

and justify the process by which DevSecOps engineers can shift security left to gain efficiencies.

A generic qualitative inquiry technique was used for this study. A generic approach is the

most appropriate when the researcher has prior knowledge of the topic and is open to

17
 constructing new knowledge based on participant responses (Edmonds & Kennedy, 2016). A

generic approach allows the participants to share their knowledge and real-world experiences to

help create new knowledge for future DevSecOps engineers to build on.

This research used purposeful sampling to identify DevSecOps engineers with experience

in shifting security left. Purposeful sampling addressed the need for participants to meet specific

criteria. Vogt (2005) found that the representation of a population increased with the use of

purposive sampling. The research was conducted via semi-structured interviews to understand

how DevSecOps engineers approach shifting security left in the development pipeline. Focus

groups were considered, but Leavy (2014) found that semi-structured interviews were preferred

W
for research that explores personal experiences. The interviews were performed from the
IE
philosophical orientation of constructivism. Colburn (2000) defined constructivism as the best

philosophical approach for open-ended questions. This orientation aligns with the semi-
EV
structured interview questions used in this study. This orientation also allows the researcher to

understand better the context surrounding the interview answers.

DiCicco-Bloom and Crabtree (2006) described interviews as a way to share cultural

PR

knowledge. Semi-structured interviews are the best choice, as there is an expectation that there

will be variations of processes based on culture, context, and opinion. Semi-structured interviews

allow discussion of a specific topic involving placement of security within the pipeline but still

enable respondents to expand on essential items.

Interviews occurred in the Zoom and Google Meet conferencing platforms. Gray et al.

(2020) found that Zoom was the best conferencing tool for qualitative interviews. The authors

cited only recording audio and password-protected meetings as critical for maintaining

confidentiality (Gray et al., 2020). Because of these findings, recording only occurreed for the

18

Reproduced with permission of copyright owner. Further reproduction prohibited without permission.