This guide will help you introduce effective DevSecOps practices in your company, regardless of size. We provide explicit guidance and actionable steps to introduce security controls, measure their effectiveness, and demonstrate value for money to your business leaders.

I've been helping software engineering teams build and deploy more secure applications for over 20 years now. I wrote my first hardening document in 2002 for a large insurance company in the US. When I was writing that document there wasn't much information available on the internet about how to secure application environments. What little there was (PCI checklists mostly) was very high-level and super frustrating for an engineer who wants specific tasks that they do and say "I did that thing!". But, here's the thing, as much as I personally hate many "compliance" frameworks, I've come to appreciate them simply because they give you something to test against. It's the way you show that "hey! I'm getting better at this!"

Unfortunately, most compliance frameworks are disconnected from the actual technical things that technical people have to do to make something better. Following compliance guidelines is really important but frameworks like the NIST Secure Software Development Framework (SSDF) talk about theoretical or often non-sensical vulnerabilities. For example, here's a line from the SSDF section PO item 3.2: "Follow recommended security practices to deploy and maintain tools and toolchains." Then in the implementation examples section there are 9 examples that range from evaluating tools and acquiring tools for the developer environment to collecting evidence for an audit. Like, WTF?! How is an engineer supposed to know what to do with that? This is often because the person or group of people writing the framework are technically aligned becasue they come from a risk or GRC background. We want this DevSecOps Playbook to be different. This document is for engineers!

I was inspired by the recent MVSP project which I have profound respect for. But, the MVSP is a framework for defining what a minimally viable secure product is, and not a true checklist of "do this, now do that". This document is NOT meant to replace the MVSP in any way. Instead this is a separate document with a separate target audience and separate philosophy. This document, unlike the MVSP, is meant to be the pentultimate playbook for implementing a DevSecOps program at your company. This document is meant to provide a step by step guide on how to build better software by auditing whats in place now. Finally, I'm selfish and I want a document I can use myself to quickly and efficiently secure an estate of applications.

All companies and applications are unique. Blanket statements like "Shift Left" aren't helpful without context. Enterprises and startups have different tech stacks, funding, workforces, regulation, and more. Context matters, and this document provides a roadmap to use your context to determine your next DevSecOps destination.

We want to secure our applications, from cradle to grave. To do this, we have created five categories that cover the lifecycle of a software application.

• Development Environment
• Source Code Management
• Continuous Integration / Deployment and other Automation
• Deployment
• Organization
• Addendum: Compliance

We use two rating systems.

Priority indicates the order you should implement controls. Difficult indicates how hard implementation is for this control.

The developers laptop is where most of the magic happens, but also where most of the problems are introduced. If you want to shift as far left as you can this is where you want to land much of your embedded security.

We store our source code in a centralised location, often in the cloud. This, along with git, allow engineers to independently work on the same codebase without affecting each other. As the second stage after writing code, the repository makes sense as the next area to introduce security controls.

Modern web applications are built using modern continuous integration and deployment processes. This means that you run tests specific to whatever environment you are pushing to whether that's DEV, STAGING or PROD.

Applications are deployed somewhere whether thats an AWS Lambda, S3 bucket or some old crusty server in the corner of the server room. In any case, DevSecOps best practices mean that you need to include that deployment location in your processes.

People don't deploy applications, organizations do. Some steps in the DevSecOps playbook need to be owned by the Organization itself.

Because this is meant to be a manifesto about how to do DevSecOps, we have to be cognizant that there are three groups of people that this affects: Developers, Operations and InfoSec. Historically, there are many compliance frameworks that address the InfoSec community and to a lessor extent Operations teams. But software development was never mentioned until only recently. Understanding this, I wanted to note there are only really 4 frameworks that specifically mention software development:

• NIST 800 SA 10, 11, 15, 16 and 17
• ISO 27001 Annex A Section 14
• CIS Section 16
• Australian ISM "Guidelines for Secure Development"

Below you will find links to several security frameworks that align with this document. I have personally spent many years implementing CIS controls into my application environments. CIS is a wonderful framework as its very presciptive and easy for an engineer to understand. This is not to say that CIS controls are easy to implement. They are not! Regardless, you can't deny the ubiquity of ISO27001 and SOC2 and I want this document to help orgs looking to meet those requirements as well. In fact, SecureStack has started a SOC2 program and in parallel to writing this document I am busily mapping SOC2 requirements and will eventually add them to this document.

I had a number of Australian friends suggest that I tackle the Australian ISM and APRA CPS 234 as well so you will see me attempt to map it as well when it makes sense. This is a work in progress and I encourage anyone that is interested to jump in and suggest mappings. You can add an issue in GitHub or simply create a PR.

NIST 800-218 "Secure Software Development Framework" (SSDF) version 1.1: https://csrc.nist.gov/publications/detail/sp/800-218/draft

NIST 800-53B (2021): https://csrc.nist.gov/publications/detail/sp/800-53b/final
Control Families via HTML: https://csrc.nist.gov/projects/risk-management/sp800-53-controls/release-search#!/families?version=5.1

1. SA-11: Developer Testing and Evaluation
2. SA-15: Development Process, Standards, and Tools
3. SA-16: Developer-Provided Training
4. SA-17: Developer Security and Privacy Architecture and Design

NIST 800-92: https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-92.pdf
NIST 800-95: Guide to Secure Web Services (2007): https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-95.pdf

The Center for Internet Security is an organization that has been providing very prescriptive security controls since 2000. There are a total of 18 security control groups with section 16 being the group we will be referencing for this document.
https://www.cisecurity.org/controls/application-software-security

It's not the focus of this document, but CIS maintains an amazing set of benchmarks and build playbooks for most operating sytems. I have been using these templates for years and they are a great resource: https://www.cisecurity.org/cis-benchmarks/

The Australian Cyber Security Centre has authored a document called the "Information Security Manual" or ISM as its commonly called. The landing page for this document is https://www.cyber.gov.au/sites/default/files/2021-12/Information%20Security%20Manual%20%28December%202021%29.pdf.

This document is large and has a very broad scope. You can download the complete ISM at https://www.cyber.gov.au/sites/default/files/2021-12/Information%20Security%20Manual%20%28December%202021%29.pdf

In late 2021 the ACSC released the "Guidelines for Software Development" (GSD). These are a general set of guidelines for embedding secure coding practices into an organization. These guidelines are far from authoratative and are not very presciptive with my favorite snippet from the GSD being this little gem: "Platform-specific secure programming practices are used when developing software, including using the lowest privilege needed to achieve a task, checking return values of all system calls, validating all inputs and encrypting all communications." Is that a catch all or what?! Wow! Regardless, I am respectful of the energy that went into this set of guidelines and will continue to try and bring visibility to it as much as I personally can.

You can find the GSD here: https://www.cyber.gov.au/acsc/view-all-content/advice/guidelines-software-development

The Australian Prudential Regulation Authority (APRA) is part of the Australian government and is charged with regulating the financial industry. It published the "Prudential Standard CPS 234" document in 2019 which outlines high level information security requirements.

This document is organized in an unusual way with 8 "attachments" at the end of the doc. It is in these attachments that the security controls and expectations are laid out. You can find the APRA 234 document at https://www.apra.gov.au/sites/default/files/cpg_234_information_security_june_2019_0.pdf.

• mapped all of ISM GSD
• mapped all of SSDF
• mapped CIS section 16

• map remaining ISO 27001 Annex 14
• map CIS section other than 16 to all items
• map remaining NIST 800-53
• map remaining ISM infrastructure

Sponsored with 💜 by SecureStack