Security infrastructure as code.

When I was a young captain back in the early 1990s, the U.S. Army assigned me as an assistant professor at the United States Military Academy to teach computer science in the Electrical Engineering and Computer Science Department or EE&CS for short (affectionately referred to by the cadets as EEEEEKS!). One of my “additional duties as assigned” was to manage the department’s internal network for the faculty and the students. All the teachers had Windows NT systems on their desktops and in their classrooms and we had a number of labs scattered about running Sun Solaris (the cool version of Unix back in the day). The cadets all had desktop computers in their barracks too. Practically, what that meant to me and Marie, the GS-7 government employee system administrator that worked for me, was that every summer as the new class of cadets came in (about 1500, plus or minus, depending on the year) and as the graduating seniors left to become second lieutenants in the Army, we needed to create an entire bucket of accounts with the proper permissions on both the Windows side and the Solaris side and we had to delete a bunch of accounts, you know, because of security. 

That first summer (July), Marie and I did that manually because I was the new guy and didn’t know any better and we had to get it done before August when all the cadets returned to the Academy from the four corners of the world to begin the fall semester. That was a lot of brainless, repetitive toil in a very short amount of time. And, because we did it manually, we made a lot of mistakes that we had to fix later when the cadets tried their first logins. Ok, Ok, I made a lot of mistakes. Marie was spot on. But the point is that I vowed not to ever be in that situation again. So, to prepare for the next summer, I automated it. Fresh out of grad school with a copy of “Unix Power Tools” and “Advanced Windows NT: The Developer's Guide to the WIN32 Application Programming Interface” on my desk, I broke out the The Perl Programming Language for Solaris and whatever programming language I was using for Windows NT at the time and automated the entire thing.

When Marie and I got the file with all the cadet names that needed to be added and deleted, I pulled the trigger on the scripts. It took 10 minutes to run and there were no mistakes. We reduced the toil that normally took Marie and me 30 days to accomplish down to 10 minutes. Now, it took me 30 days of work to get the program running without any errors, but once it was done, it was done. I never had to touch it again if I didn't want to. That was a significant emotional event for a young automator like myself. I mean, I studied computer science in grad school and learned enough about programming to be dangerous, but I really didn’t understand the power of automation until that very moment. Yes, automation was hard to do up front, but once done, it took an entire class of busy body work off my plate so that I could focus on other, more important matters. And if that isn’t the very definition of why automation is important, I don’t know what is.

The waterfall started it all. 

When I was in college (late 1970s), my future mother-in-law and I sat riveted through a 10 episode documentary hosted by British broadcaster, science historian, author, and television producer James Burke. The show is called “Connections” and you can still watch it on YouTube for free if you want. It’s about how the technology in our world that we all take for granted is connected in the most bizarre and unknown ways. And this is before the internet boom. If you grabbed James Burke today, he could make another 10 episodes on the evolution of software development alone and it would be just as compelling.

Back in the dinosaur days (1960s) when computers were bigger than houses, large software development projects didn’t have a standard methodology yet. We were still figuring out what to do with these things called mainframes. Computer scientists leaned on established general purpose project management theory to do software development, like the original Gantt Charts from the 1910’s and the Critical Path Method made popular in the 1950’s. 

In 1956,  Herbert Benington invented the first first version of the Waterfall Software Development model. Interestingly, Benington didn’t get credit for his work early on. Another guy, Dr. Winston Royce (1970), got the credit when he published a criticism of the model that didn’t even mention it by name. But his paper had nice diagrams that showed the process (requirements, analysis, design, implementation, testing, and operations) all flowing from top to bottom, just like a waterfall. In 1976, Bell and Taylor referred to the Royce diagrams as the Waterfall model and the name stuck to Dr. Royce.

When the Personal Computing revolution began in the 1980s, things began to spin out of control. Computer science founding father, Edsger Dijkstra, said this about the problem: "The major cause of the software crisis is that the machines have become several orders of magnitude more powerful! ...as long as there were no machines, programming was no problem at all... and now we have gigantic computers, programming has become an equally gigantic problem."

In 1985, to address the issue, the U.S. Department of Defense (DoD) adopted the Waterfall model as a requirement for all contractors, despite Royce’s criticism, and started a period of ponderous, ice-berg like progress in producing software. According to Alexey Krutikov, “Although Royce himself believed that Waterfall should be iterative, advocated pilots and micro models, Waterfall was and continues to be wrongly considered as a sequential methodology.” The impact was that manay programming projects took years to finish and the teams spent as much time documenting the requirements as they did writing code.

Agile becomes the challenger.

In the 1990s, some rebel developers started experimenting with ways to improve the process. They began toying with the Rational Unified Process (1994), the Scrum (1995), and Extreme Programming (1996). But in February 2001, 17 men (and yes, they were all men, we can have a longer discussion later about the misogyny of the IT community in the early 2000s) traveled to Utah for a long weekend of skiing and discussions about building software. The result was the Agile Manifesto; a rejection of the Waterfall model (See below for the 12 points) and an embracement of the idea of producing real, working code as a milestone of progress.

Up to this point, software development was mainly concerned with general purpose coding. In other words, software projects built applications to solve specific problems in business, the commercial space, and in academia. There wasn’t a lot of talk about using software to run the IT infrastructure and there wasn’t much discussion about how to write secure software. This is the point where it all started to change. As a community, we started to see parallel development in improving security in all software as well deploying code as infrastructure.

When do we start thinking about security?

In May of 2000, hackers released the ILoveYou Worm that began a string of global impactful worms that targeted Microsoft Windows’ products (operating systems and browsers) throughout 2001: 

• 15 July: Code Red Worm
• 4 August: Code Red II Worm
• 18 September: Nimda Worm
• October: Klez Worm

By February 2002, that next year, Bill Gates turned Microsoft on a dime to implement  "Trustworthy Computing." He  shutdown future deployments of the Windows operating system to redirect development focus on security. The result was the creation of the first Microsoft Security Development Lifecycle (SDLC). 

In 2003, Dave Wickers and Jeff Williams, working for Aspect Security, a software consultancy company, published an education piece on the top software security coding issues of the day. That eventually turned into the OWASP Top 10 (The Open Web Application Security Project), a reference document describing the most critical security concerns for web applications. 

Coding the infrastructure and software security best practices.

In 2004, when Google was nothing more than a search engine and not the internet giant that it is today, company leaders made an extraordinary decision. Instead of assigning the responsibility of network management to an IT team as was the standard best practice of the day, they handed the task off to the development team. This group of Site Reliability Engineers (SREs) got busy automating all the infrastructure tasks that were repetitive, error prone, and provided little value to the future for the company. They called those tasks “toil” and started the movement that wouldn’t have a name for another six years: DevOps.

In March of 2008, Dr. Gary McGraw published the first Building Security In Maturity Model (BSIMM) report; a survey of some 30+ companies that collated initiatives and activities around software security. In 2009, Pravir Chandra published the first SAMM (Software Assurance Maturity Model); a prescriptive security best practice security model. With these two models, the security community started to have a way to measure its progress against its peers in the industry (BSIMM) and against what security experts recommend (SAMM).

Amazon started the cloud revolution when it rolled out AWS in 2006. Microsoft followed suit with a competing service in 2010 with Azure. Google started to compete in the space with Google Cloud Platform (GCP) in 2012. And there are other smaller cloud service providers. But, when AWS rolled out, the cloud became the impetus for everyone in the IT community to consider infrastructure as code. But even as Agile replaced the waterfall model as the standard software development framework, it was still agonizingly slow. Startups born in the cloud  realized that they could do better by using software to create a competitive edge against their brick and mortar competitors. With software, they could upgrade their products and services over the internet. They could run circles around their competition who still had to ship hardware. They could beat their competition to market for software applications if they could just streamline the process.

DevOps becomes a thing.

In 2009, DevOps began to emerge as an industry best practice out of three converging ideas:

• A 2009 Velocity Conference talk called “10+ Deploys per Day” by John Allspaw and Paul Hammond.
• The previously described Agile development method.
• Eric Ries’ book, “Lean Startup” which influenced many Silicon Valley companies between 2007 and 2010. 

DevOps is the idea that there needs to be a much tighter integration between software developers and information technology operations (IT Ops); that once the developers, the quality assurance teams, and the security analysts pass any new code or maintenance updates to IT Ops for deployment, their jobs aren’t done. Instead of creating artificial black boxes within each team where updates come in, get worked on, and then are passed to the next black box, DevOps is the recognition that update creation, deployment, and maintenance is one big system of systems and needs to be managed that way. It’s the idea that organizations would use the same Agile methodology they use today with their software development teams but expand it across all organizations in the deployment cycle: product managers, marketing professionals, developers, quality assurance practitioners, systems engineers, system administrators, operations staff, database administrators, network engineers, and security professionals. In other words, DevOps uses the Agile philosophy across the entire lifecycle of deployed systems from design, to development, to testing, to deployment, to maintenance, and finally to end-of-life. 

In 2013, Gene Kim, Kevin Behr, and George Spafford published the Cybersecurity Canon Hall of Fame book, “The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win.” It captures the essence of the DevOps movement in a novel because the authors wanted it to be accessible to more people, not just the tech nerds but also to general purpose business leaders. Like many who have read this book, I found that the way the novel portrays the CISO of the fictitious company hits pretty close to home.

By 2014 or so, the big internet giants like Google, Amazon, Netflix, and Facebook had become who they were, stand alone leaders in their industry, due in no small part to their adoption of the DevOps philosophy. Their competitors, who traditionally used the old waterfall software development method, might take years to deploy a new service for their customers. The DevOps companies were doing ten deployments a day.

What happened to security?

At this point, you might be asking yourself, this is all well and good but security seems to have fallen off the map. With OWASP, BSIMM, and SAMM, we were at least in the discussion. But in the years between 2008 and say 2017, it seemed that the IT community and their new and fancy DevOps model sprinted away from the security community. Even in the “The Phoenix Project” novel, the security  leaders weren’t part of the DevOps movement. They were outsiders not convinced about the new direction. They eventually came around, but it took the entire novel. 

John Willis, one of the authors of “The DevOps Handbook,” said in an interview in March 2021, that everybody involved in the DevOps movement was patting themselves on the back for creating this great thing, but we almost completely forgot about security for eight years or so. People were talking about DevOps and security but not with any detail.  And then around 2017, Shannon Lietz, then working for Intuit, staked a claim for the DevSecOps phrase. She created a foundation and website dedicated to the purpose of putting security into DevOps. There was some controversy there because many in the movement thought that they had invented the idea, but according to Willis, none of that matters. By creating the foundation, she got the idea front and center again in both the IT and security communities and DevSecOps started to gain traction.

DevSecOps on track.

In 2019, Gartner placed DevSecOps on their Hype Chart as just coming out of the “Trough of Disillusionment” to begin the climb up the “Slope of Enlightenment” with about 5-10 years away from reaching the “Plateau of Productivity.” That seems about right as vendors like Palo Alto Networks are starting to roll out infrastructure-as-code services to support their cloud offerings. And, the same year that Gartner released their Hype chart, the U.S. Department of Defense formalized their own process by publishing version one of their DevSecOps Reference Design document.

The bottom line is that if your organization has adopted some form of the DevOps model, then you most likely have a version of the continuous integration / continuous delivery pipeline (CI/CD). The CI pipeline is the DevOps best practice in which, according to Synopsys, “incremental code changes are made frequently and reliably. Automated build-and-test steps triggered by CI ensure that code changes being merged into the repository are reliable. The code is then delivered quickly and seamlessly as a part of the CD process.”

These pipelines are complex infrastructure-as-code software projects that, according to Teri Radichel (an AWS DevSecOps expert), “require appropriate architecture and design by the right people, not just technology. The CI/CD pipeline is part of a larger security architecture that must be well thought-out. Otherwise your security strategy will either be eternally talking about cloud but never getting there, or akin to herding cats.”

Well said Terry. But herding cats is not a new thing to the security community. So, let’s get started.

DevSecOps as a first principle strategy.

In order to reduce the probability of material impact, I have advocated for four first principle strategies: zero trust, intrusion kill chain prevention, resilience, and risk forecasting. Underneath each of those strategies are a number of tactics that support it. For example for the zero trust strategy, one tactic required is a robust identity and authorization program. For the intrusion kill chain prevention strategy, you need the ability to build adversary playbooks. The truth of the matter is that if the security community has any hope of making progress in these four areas, we have to automate the toil, the manual and repetitive security work that has to be done in order to build and maintain the tactics that support these strategies, just like I did back in the day when I automated the account creation process for the West Point cadets. Consider this automation effort as the glue that binds everything together, that makes the entire effort a system of systems that has feedback loops into the various pieces and parts. Automation has to be the fifth first principle strategy that we are all pursuing. DevOps or DevSecOps has to be the tactic we implement.

But, security teams can’t, or shouldn’t, do this in a vacuum or in parallel to what the IT side of the house is already doing. Why reinvent the wheel? After all, the entire mantra of the DevOps movement is to move development and operations onto the same team, not keep them in black box silos that never talk to each other. The security community has to attach ourselves to the existing CI/CD pipeline process. In other words, we have to become part of the internal DevOps program, not resist it or build our own. 

Specifically, we have to find ways of inserting code into the pipeline that supports each of our strategies.

Zero Trust for code coming into the CI pipeline: 

• Build separate regression test code to ensure this new code follows the best practice recommendations from OWASP, BSIMMS, and SAMM. Flag for upgrade before sending to the delivery pipeline.
• For software asset inventory or SBOMs (Software Bill of materials), collect names of new software assets, open source code libraries, and version information. 
• For vulnerability management, check incoming code against a known vulnerabilities list and flag for upgrade before sending it to the delivery pipeline. 
• Check for permissions granted to each software module is in line with the stated zero trust policy (need to know.)

Intrusion Kill Chain Prevention: For each system in our existing security stack toolset

• Collect telemetry on what is actually deployed for the ~250 known Adversary Playbooks.
• Send new prevention and detection configuration updates as we discover new intelligence or find more innovative ways to mitigate. 

Resilience: For all material data operated on by all software

• Ensure that it is encrypted before sending the code to the delivery pipeline.
• Ensure that it is configured to be part of the organization’s backup scheme.
• Ensure that it is configured to be part of the organization’s recovery scheme.

Risk forecasting: Collect evidence from each of the first principle strategy CI modules to feed into the risk forecasting model.

• What percentage of the CD pipeline code is in compliance with our zero trust policies?
• What percentage of the known adversary playbooks do we have prevention and detection controls in the CD pipeline?
• Have we seen evidence of an known adversary playbook activity in our own environments?

Final thoughts.

Before I wrap this up, there is another discussion entirely  around SOAR (Security Orchestration, Automation and Response), SIEM (Security information and event management), and XDR (Extended Detection and Response) via APIs and SASE (Secure Access Service Edge) that contribute to this automation first principle idea. I’ve written separate essays for each (See below for links).

And all of it is a big lift for the security executive to get their hands around and likely foregin to how most of us have done business for the past twenty years. But it's time to make the change, to shift left as they say, and get this done. The immediate impact to the security executive is that some portion of your team, maybe the biggest portion, will become part of the internal Devops movement; maybe as developers but most definitely as product managers for each of these elements of your first principle strategy. That’s something to consider when budgeting season comes around and you are considering the skillsets of your team. 

We’ve been wrestling with the idea of software development methodologies (Waterfall, Agile), infrastructure-as-code (cloud deployments, DevOps, DevSecOps) and coding best practices (OWASP, BSIMMS, SAMM) going on for two decades now. These are not independent systems. They overlap and interact. Up to this point, at least for the security side, they have been manual tasks, toil, that are prone to mistakes. We all know that automation can reduce the impact, at least be consistent with mistakes we make, and can offer a uniform fix across the enterprise once we have decided what to do. Automation is the key first principle strategy to get this done and DevOps/DevSecOps is the tactic we will all use to get there.

Software development timeline.

1956:

Herbert Benington invented the first first version of the Waterfall Software Development model. 

1960s: 

Software development projects used project management theory, like the original Gantt Charts (1910) and the Critical Path Method (1950),  to build software.

1970:

Dr. Winston Royce criticizes the Waterfall Model but publishes a paper with great diagrams describing the process.

1976:

Bell and Taylor referred to the Royce diagrams as the Waterfall model and the name sticks to Dr. Royce as the inventor when it was really Herbert Benington.

1980s:

Software development is everywhere but no accepted method is in place for standard best practice. 

1985:

The U.S. Department of Defense (DoD) adopts the Waterfall model as a requirement for all contractors, completely doesn't understand the faults, and usher in a decade of slow software development processes.

1990s: A Software Development Revolution Begins

• 1990: Eliyahu M. Goldratt publishes “Theory of Constraints”
• 1994: the Rational Unified Process 
• 1995: the Scrum
• 1996: Extreme Programming

2000:

5 May: Iloveyou Worm

2001:

Agile Manifesto: 17 men publish a rejection of the Waterfall model (See below for the 12 points) and an embracement of the idea of producing real, working code as a milestone of progress.

Year of the Windows Worm

• 15 July: Code Red Worm
• 4 August: Code Red II Worm
• 18 September: Nimda Worm
• October: Klez Worm

February 2002:

Bill Gates turns Microsoft on a dime to implement  "Trustworthy Computing," shuts down Windows development for the first time ever to get a handle on the security issues the products were facing, and creates the Microsoft Security Development Lifecycle (SDL) 

2003:

Dave Wickers and Jeff Williams, working for Aspect Security, a software consultancy company, published an education piece in 2003 on the top software security coding issues of the day. That eventually turned into the OWASP Top 10, a reference document describing the most critical security concerns for web applications. 

2004:

Google invents Site Reliability Engineering (SRE), the first foray into infrastructure as code.

2006:

Amazon Web Services (AWS) began offering IT infrastructure services to businesses in the form of web services -- now commonly known as cloud computing.

2008:

In March of 2008, Dr. Gary McGraw published the first Building Security In Maturity Model (BSIMM) report; a survey of some 30+ companies that collated initiatives and activities around software security. 

2009

Pravir Chandra published the first SAMM (Software Assurance Maturity Model); a prescriptive security model that gives practitioners a way to measure how well they’re doing against a set of prescribed best practices 

Velocity Conference talk called “10+ Deploys per Day” by John Allspaw and Paul Hammond, 

2011:

Eric Ries publishes “Lean Startup” which influenced many Silicon Valley companies between 2007 and 2010

2009 - 2011:

Three converging ideas produce the first inkling of DevOps: Agile, “10+ Deploys per Day,  “Lean Startup.” It’s the idea that there needs to be a much tighter integration between software developers and information technology operations (IT Ops);

2013:

Kim, Gene, Kevin Behr, and George Spafford publish “The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win.” 

2017

Shannon Lietz, then working for Intuit, staked a claim for the DevSecOps phrase. She created a foundation and website dedicated to the purpose of putting security into DevOps. There was some controversy there because many in the movement thought that they had invented the idea, but according to Willis, none of that matters. By creating the foundation, she got the idea front and center in both the IT and security communities.

2019

The Gartner Hype Cycle places DevSecOps at the beginning of 

DOD publishes DevSecOps Reference Design (Version 1.0)

Agile Manifesto.

1: Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

2: Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

3: Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

4: Business people and developers must work together daily throughout the project.

5: Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

6: The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

7: Working software is the primary measure of progress.

8: Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

9: Continuous attention to technical excellence and good design enhances agility.

10: Simplicity – the art of maximizing the amount of work not done – is essential.

11: The best architectures, requirements, and designs emerge from self-organizing teams.

12: At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Reading list.

6 APR 2020: 

CSOP S1E1: Your Security Stack is Moving: SASE is Coming.

• Hash Table Guests: None
• Link: Podcast
• Link: Transcript
• Link: Essay

27 APR 2020:

CSOP S1E4:: Metrics and risk: All models are wrong, some are useful. 

• Hash Table Guests: None
• Link: Podcast
• Link: Transcript
• Link: Essay

11 MAY 2020:

CSOP S1E6:: Cybersecurity First Principles

• Hash Table Guests: None
• Link: Pro Podcast
• Link: Pro Transcript
• Link: Pro Essay
• Link: Public Podcast

18 MAY 2020

CSOP S1E7:: Cybersecurity first principles: zero trust

• Hash Table Guests: None
• Link: Podcast
• Link: Transcript
• Link: Essay

26 MAY 2020:

CSOP S1E8:: Cybersecurity first principles: intrusion kill chains.

• Hash Table Guests: None
• Link: Podcast
• Link: Transcript
• Link: Essay

01 JUN 2020:

CSOP S1E9:: Cybersecurity first principles - resilience

• Hash Table Guests: None
• Link: Podcast
• Link: Transcript
• Link: Essay

08 JUN 2020:

CSOP S1E10:: Cybersecurity first principles - DevSecOps

• Hash Table Guests: None
• Link: Podcast
• Link: Transcript
• Link: Essay

15 JUN 2020:

CSOP S1E11:: Cybersecurity first principles - risk

• Hash Table Guests: None
• Link: Podcast
• Link: Transcript
• Link: Essay

22 JUN 2020:

CSOP S1E12:: Cybersecurity first principles - intelligence operations

• Hash Table Guests: None
• Link: Podcast
• Link: Transcript

Link: Essay

16 NOV 2020:

CSOP S3E5: SOAR: a first principle idea.

• Hash Table Guests: None
• Link: Podcast
• Link: Transcript
• Link: Essay

23 NOV 2020:

CSOP S3E6: SOAR: around the Hash Table.

• Hash Table Guests:
• Rick Doten - CISO - Carolina Complete Health (4)
• Kevin Ford: CISO for the State of North Dakota (2)
• Kevin Magee: CSO Microsoft Canada (1)
• Link: Podcast
• Link: Transcript
• No Essay

19 JUL 2021

CSOP S6E1: Pt 1 - Cybersecurity first principles - encryption.

• Hash Table Guests: None
• Link: Podcast
• Link: Transcript
• Link: Essay and Podcast

26 JUL 2021

CSOP S6E2: Pt 2 - Cybersecurity first principles - encryption.

• Hash Table Guests: 
• Don Welch, Penn State University CIO (4)
• Wayne Moore, Simply Business CISO (1)
• Link: Podcast
• Link: Transcript
• No Essay

02 AUG 2021

CSOP S6E3: Pt 1 - Cybersecurity first principles - backups.

• Hash Table Guests: None
• Link: Podcast
• Link: Transcript
• Link: Essay and Podcast

09 AUG 2021

CSOP S6E4: Pt 2 - Cybersecurity first principles - backups.

• Hash Table Guests: TBD
• Jerry Archer, Sallie Mae CSO (5)
• Jaclyn Miller, NTT CISO (1)
• Link: Podcast
• Link: Transcript
• No Essay

16 AUG 2021

CSOP S6E5: Pt 1 - Cybersecurity first principles - orchestrating the security stack.

• Hash Table Guests: None
• Link: Podcast
• Link: Transcript
• Link: Essay and Podcast

23 AUG 2021

CSOP S6E6: Pt 2 - Cybersecurity first principles - orchestrating the security stack.

• Hash Table Guests:
• Bob Turner, Fortinet Education Field CISO  (5)
• Kevin Magee, Microsoft Canada CSO (2)
• Link: Podcast
• Link: Transcript
• No Essay

30 AUG 2021

CSOP S6E7: Pt 1 - Cybersecurity first principles - adversary playbooks.

• Hash Table Guests: None
• Link: Podcast
• Link: Transcript
• Link: Essay and Podcast

13 SEP 2021

CSOP S2E8: Pt 2 - Cybersecurity first principles - adversary playbooks.

• Hash Table Guests: None
• Ryan Olson, the Palo Alto Networks (Unit 42) Threat Intelligence VP
• Link: Podcast
• Link: Transcript
• No Essay

29 NOV 2021:

CSOP S7E5: S7E5: Rick the Toolman Series: Pt 1 on XDR.

• Hash Table Guests: None
• Link: Podcast
• Link: Transcript
• Link: Essay and Podcast

13 DEC 2021:

CSOP S7E7: Rick the Toolman Series: Pt 2 - Hash Table on XDR.

• Hash Table Guest:
• Steve Winterfeld, Advisory CISO, Akamai
• Link: Podcast
• Link: Transcript
• No Essay

References.

"10+ Deploys Perspectives  Day,” by John Allspaw and Paul Hammond, 2009 Velocity Conference, YouTube, 25 June 2009. 

“12 Principles behind the Agile Manifesto,” 4 November 2015. 

“About Agile Alliance.” Agile Alliance, 29 June 2015. 

“About the Building Security in Maturity Model,” BSIMM.” Bsimm, 2021. 

“A Brief History of Software Development Methodologies,” by growin, 23 December 2021. 

“Advanced Windows NT: The Developer's Guide to the WIN32 Application Programming Interface,” by Jeffrey Richter, published by Microsoft Press, 1993.

“All You Need to Know About the Waterfall Model,” by Rafayel Mkrtchyan, Linked-In, 14 January 2017.

“API Security Weekly: Issue #68: Gartner Hype Cycle for Application Security,”by Dmitry Sotnikov, DZone, 30 January 2020.

“Back to School: History of Software Development Methodologies,” by Alexey Krutikov, Qulix Systems, 30 April 2021.

“Connections,” hosted by James Burke, 1978. 

"Defense Systems Software Development: DOD-STD-2167A," by the U.S. DOD, 4 June 1985.

“Diving into DevSecOps - Part 1,” DevInterrupted, March 15, 2022. 

“Dr Winston W Royce Makes Surprise Appearance,” YouTube Video, 11 June 2014. 

“Fabric, Ansible, Amazon AWS, and Netflix: The Top 10 DevOps Posts of 2017 (so Far),” by HASAN YASAR, Software Engineering Institute (SEI) Blog, 18 July 2017. 

‌"Managing the Development of Large Software Systems," Dr. Winston W. Royce, Western Electronic Show and Convention (WesCon) August 25–28, 1970, Los Angeles, USA.

“Manifesto,” by Shannon Lietz, DevSecOps.org, 12 October 2020.

“My History of DevSecOps - Cloud Security,” by Teri Radichel, Medium, 18 December 2019. 

"Production of Large Computer Programs," by H. D. Benington, in Annals of the History of Computing, vol. 5, no. 4, pp. 350-361, Oct.-Dec. 1983, doi: 10.1109/MAHC.1983.10102.

“Site Reliability Engineering: How Google Runs Production Systems,” By Betsy Beyer, Chris Jones, Jennifer Petoff, and Niall Richard Murphy, Published by O’Reilly Media, 16 April 2016.

“Taking DevSecOps to the next Level with Value Stream Mapping.” by Nanette Brown, Software Engineering Institute (SEI) Blog, 24 May 2021. 

“THE BIRTH OF GOOGLE,” by JOHN BATTELLE, Wired Magazine, 1 August 2005.

“The Current State of DevSecOps Metrics,” by BILL NICHOLS, Software Engineering Institute (SEI) Blog, 29 March 2021. 

“The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations,” by Gene Kim, Jez Humble,  Patrick Debois, and John Willis, Published by IT Revolution Press, 6 October 2016

“The History of Agile.” by Rachaelle Lynn, Senior Marketing Manager, Planview, November 21, 2019.

“The Lean Startup: How Today's Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses,” by Eric Ries, published by Currency, 13 September 2011. 

“The Perl Programming Language,” Perl.org, 2021. 

“The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win, ” Book Review by Canon Committee Member, Rick Howard, Cybersecurity Canon Project, The Ohio State University, 2019.

“The Phoenix Project : A Novel about IT, DevOps, and Helping Your Business Win,” by Gene Kim, Kevin Behr, and George Spafford., published by It Revolution Press, 2013. 

“The Story behind the Microsoft Security Development Lifecycle,”by Rod Trent, ITPro Today

7 March 2014. 

“The UX Book: Agile UX Design for a Quality User Experience,” by Rex Hartson and Pardha S Pyla, Published by Morgan Kaufmann Publishers, November 2018.

“Theory of Constraints,” by Eliyahu M. Goldratt, Published by North River 1 January 1990.

“The Winter Getaway That Turned the Software World Upside Down,” by Caroline Mimbs Nyce, The Atlantic, 8 December 2017.

“Webcast: A Brief History of DevSecOps and Where We Go from Here.” by Allan Shimel and Mark Miller, RSA Conference, YouTube Video, 31 July 2019

“UNIX Power Tools,” by Jerry Peek, Tim O'Reilly, and Mike Loukides, published by O'Reilly Media, 1993. 

“What Is CI/CD and How Does It Work?”by Synopsys, 2021.