GitBook: [master] 30 pages and 3 assets modified

Author: Stuart Gunter

.gitbook/assets/0.png

@@ -11,3 +11,4 @@ This document was produced by a number of people within the [Equal Experts netwo
 * [Chris Rutter](https://www.linkedin.com/in/chris-rutter-1b74a8b0/)
 * [Gerald Benischke](https://www.linkedin.com/in/gerald-benischke-9811b663/)
 * [Katarzyna Kittel](https://www.linkedin.com/in/kasiakittel/)
+

.gitbook/assets/1.png

@@ -11,3 +11,4 @@ The practices defined are technology and vendor agnostic, allowing each team to
 ## Who's this playbook for?
 
 We've created this playbook to help teams work together to deliver secure software. It's not just for software engineers; it is for everyone involved in delivering software. It's also not prescriptive about how each of the practices should be adopted, but allows you to determine which practices are appropriate for you and the best way to implement them.
+

.gitbook/assets/organise-build-operate.png

@@ -29,3 +29,4 @@ The [Linux Foundation Core Infrastructure Initiative Best Practices](https://bes
 We've found resources like this to be helpful for determining whether the practices we adopt are inline with industry norms, and whether new practices have emerged that we should consider including in our own projects.
 
 However, the Secure Delivery Playbook is not a scoring system and will not earn you an independently verifiable badge. We choose not to be prescriptive, but instead to provide guidance that allows teams to select which practices are most suitable in their context. This also ensures teams think about the practices critically and with an eye on business value, rather than being influenced to achieve a silver or gold badge.
+

contributors.md

@@ -21,3 +21,4 @@ To quote [Mozilla](https://wiki.mozilla.org/Security/Champions):
 * Security Champions are active members of a team that make help to make decisions about when to engage the Security Team
 * Act as the "voice" of security for the given product or team
 * Assist in the triage of security bugs for their team or area
+

intro.md renamed to intro/README.md

@@ -1,7 +1,8 @@
 # Overview
 
-The Equal Experts Secure Delivery Playbook is a distillation of our thinking on how best to apply security to continuous delivery. This playbook is [open sourced under a Creative Commons license](https://github.com/EqualExperts/secure-delivery-playbook) for the benefit of the wider software development community. We encourage contributions and discussion to continually improve this playbook. 
+The Equal Experts Secure Delivery Playbook is a distillation of our thinking on how best to apply security to continuous delivery. This playbook is [open sourced under a Creative Commons license](https://github.com/EqualExperts/secure-delivery-playbook) for the benefit of the wider software development community. We encourage contributions and discussion to continually improve this playbook.
 
 To help explain some of the concepts in this playbook, we've created the following visual representation of how the various practices work together.
 
-![](images/organise-build-operate.png)
+![](.gitbook/assets/organise-build-operate.png)
+

intro/how-is-this-different.md

@@ -6,7 +6,7 @@ The practices in this guide have been divided into three areas: Organise, Build
 
 **Build** and **Operate** practices are owned by the product delivery team and focus on security activities during development and live operations of the product.
 
-![](images/organise-build-operate.png)
+![](../.gitbook/assets/organise-build-operate.png)
 
 ## Where do I start?
 
@@ -17,3 +17,4 @@ The best approach is to start with the practices that have high impact and low e
 **Effort:** To understand the effort of a practice, we must understand the context of the product delivery. This includes: the technologies used in the product, the delivery team's skill and experience, the level of automation in the deployment pipeline and other teams involved in the delivery process \(e.g. change control\).
 
 The best approach is to deliver the practices in the smallest possible incremental steps that provide immediate feedback. This approach provides immediate measurable value and is also useful to build confidence and demonstrate how improvements can be easily delivered without large expense.
+

intro/security-engineers-and-security-champions.md

@@ -1 +1,2 @@
 # Build
+

landing-page.md

@@ -12,7 +12,7 @@ A process that can be used to manage risk appetite is:
 
 1. Stakeholders should identify the level of risk acceptable to them, ideally quantitatively
 2. [Threat modelling](https://en.wikipedia.org/wiki/Threat_model) to understand what controls are likely to ensure the risk appetite is met
-3. [Measurement](/practices/operate/detection-and-response.md) to understand whether the risk has been adequately addressed and to adapt the threat model and required controls as needed
+3. [Measurement](../operate/detection-and-response.md) to understand whether the risk has been adequately addressed and to adapt the threat model and required controls as needed
 
 ## Agree on roles & responsibilities
 
@@ -48,3 +48,4 @@ Examples:
 
 * [OWASP Application Security Verification Standard \(ASVS\)](https://github.com/OWASP/ASVS)
 * [Core Infrastructure Initiative Best Practices Criteria](https://github.com/coreinfrastructure/best-practices-badge/blob/master/doc/criteria.md#security)
+

practices.md renamed to practices/README.md

@@ -21,3 +21,4 @@ Where you're required to provide evidence to auditors for compliance \(e.g. PCI
 * Deployments / build tools can provide an audit of changes to production
 
 When providing evidence in this form, it provides value to the delivery team as well as auditors \(e.g. Terraform scripts that show firewall configuration for PCI DSS\). This avoids creating lengthy documents that require continual effort to maintain, and instead relies on code that defines the way the system works. This also avoids contradiction between what the documentation says and what happens in reality.
+

practices/build.md renamed to practices/build/README.md

@@ -43,7 +43,7 @@ When a build is based on some shared state \(e.g. local Maven cache\), it's poss
 
 Continuous Integration / Continuous Delivery \(CI/CD\) pipelines provide a good opportunity to detect potential security vulnerabilities early in development by integrating with security analysis tools. There are numerous open source and commercial products covering a wide variety of languages and frameworks, and it's possible to write custom tools based on your own needs. These tools can be applied to application code, configuration files, Dockerfiles, Infrastructure-as-Code, and running applications.
 
-Results from these tests should [feed into the software catalogue](/practices/organise/intelligence.md#make-security-visible-in-the-software-catalogue) to promote visibility and ensure that security vulnerabilities are being responded to in a timely manner.
+Results from these tests should [feed into the software catalogue](../organise/intelligence.md#make-security-visible-in-the-software-catalogue) to promote visibility and ensure that security vulnerabilities are being responded to in a timely manner.
 
 Some tools include threat intelligence data, which provides an indication of how potential vulnerabilities / weaknesses are being used in the wild. This data therefore provides a useful mechanism to further prioritise the resolution of identified vulnerabilities.
 
@@ -138,3 +138,4 @@ In some cases, we can detect critical security issues that should prevent the bu
 In other cases, we may identify security issues that need to be fixed, but are not severe enough to warrant blocking the pipeline. In these cases, it is important to ensure the issue is resolved without preventing the release of business value to the customer.
 
 Automating these policies helps direct delivery teams towards the issues they are required to fix prior to a production release, and still highlights other issues that also need to be addressed although less urgently.
+

practices/build/inception.md

@@ -19,3 +19,4 @@ Also consider whether any known risks for the product are impacted by this chang
 Some code has a higher impact on the security of the product, such as code handling authentication. In addition, some changes are more complex and require specialist experience to ensure it is secure, such as cryptography. Defining sufficient test cases can be difficult, and often benefits from having someone with security experience available to help.
 
 Sections of security-critical code should be reviewed by experienced Security Engineers. It is possible to integrate this into source control to prevent security-critical code from being merged until it has been reviewed, for example by tagging associated stories. Alternatively, this can also be achieved by having a good close working relationship with Security Engineers so they are aware and available to help when needed.
+

practices/build/periodic-review.md

@@ -1 +1,2 @@
 # Operate
+

practices/build/security-in-the-pipeline.md

@@ -23,3 +23,4 @@ Examples:
 * [Thinkst Canary](https://canary.tools/)
 * [Canarytokens](https://canarytokens.org/generate)
 * [CyberChaff](https://galois.com/project/cyberchaff/)
+

practices/build/stories-and-epics.md

@@ -67,3 +67,4 @@ Links:
 It should only be possible to deploy software that has been produced through the pipeline, rather than allowing uncontrolled deployments that cannot be verified.
 
 The pipeline gives repeatability, traceability and an audit of all changes that have made all the way through to production. It ensures that all the necessary due diligence, such as security and functional testing, has been completed successfully to avoid issues being introduced into production. This is particularly important under emergency scenarios where there's pressure to release rapid fixes, because this same pressure increases the chance of introducing vulnerabilities or defects.
+

practices/operate.md renamed to practices/operate/README.md

@@ -6,7 +6,7 @@ The pipeline produces the product artefacts that are deployed into production. I
 
 In addition to [infrastructure hardening](environment-provisioning.md#automate-infrastructure-hardening), build pipelines have unique characteristics that must be addressed in order to preserve their security. Failing to do this can lead to a compromise of the build system.
 
-For example, builds should not be allowed to run on Jenkins master nodes as this has [serious security implications](https://wiki.jenkins.io/display/JENKINS/Security+implication+of+building+on+master) and been used to compromise Jenkins administrator accounts in the past. Relevant security controls should be enabled and default user accounts should be changed on all pipeline systems. All build plugins should be carefully vetted to avoid introducing vulnerabilities in a [similar way to all product dependencies](/practices/build/security-in-the-pipeline.md#establish-provenance-of-third-party-components). These should be kept up to date with the latest security patches.
+For example, builds should not be allowed to run on Jenkins master nodes as this has [serious security implications](https://wiki.jenkins.io/display/JENKINS/Security+implication+of+building+on+master) and been used to compromise Jenkins administrator accounts in the past. Relevant security controls should be enabled and default user accounts should be changed on all pipeline systems. All build plugins should be carefully vetted to avoid introducing vulnerabilities in a [similar way to all product dependencies](../build/security-in-the-pipeline.md#establish-provenance-of-third-party-components). These should be kept up to date with the latest security patches.
 
 ## Monitor the pipeline as a production system
 
@@ -20,8 +20,9 @@ Pipelines require access to various external systems, such as source repositorie
 
 Wherever possible, avoid the need to manage secrets directly and use native platform features that handle this on your behalf. For example, cloud providers offer identity and access management features, such as AWS IAM and GCP Cloud Identity and Access Management, that enable workloads to be authorised while automatically handling key/credential rotation, auditing, etc.
 
-Within the pipeline, all secrets should be stored and managed securely, ideally using a [secrets management system](/practices/operate/environment-provisioning.md#centralised-and-automated-secret-management). Where it's not possible to use a central secrets management system, it's important to understand what controls are provided by the pipeline tools and their limitations.
+Within the pipeline, all secrets should be stored and managed securely, ideally using a [secrets management system](environment-provisioning.md#centralised-and-automated-secret-management). Where it's not possible to use a central secrets management system, it's important to understand what controls are provided by the pipeline tools and their limitations.
 
 The principle of least privilege should be applied for secrets \(e.g. read only access to source control\). This includes using unique credentials for the build pipeline, so that it can be traced back if suspicious activity is detected.
 
 Be aware that secrets may be accidentally or intentionally exposed via build logs, and mechanisms should be put in place to detect this or prevent it from happening if possible.
+

practices/operate/detection-and-response.md

@@ -55,3 +55,4 @@ Examples:
 * [HackerOne](https://www.hackerone.com/)
 * [Bugcrowd](https://www.bugcrowd.com/)
 * [Security.txt](https://securitytxt.org/)
+

practices/operate/environment-provisioning.md

@@ -1 +1,2 @@
 # Organise
+

practices/operate/security-of-the-pipeline.md

@@ -16,3 +16,4 @@ Examples of automated tooling include:
 * [Turbot](https://turbot.com/)
 * [Datree](https://datree.io/)
 * [Open Policy Agent](https://www.openpolicyagent.org/)
+

practices/operate/security-testing-in-production.md

@@ -15,3 +15,4 @@ Links:
 When a security incident arises, teams across the organisation should collaborate openly and share information to ensure the incident is responded to quickly and effectively. When this is centrally managed by a single team \(e.g. Security Engineering\) and there is no engagement with the delivery team, the effectiveness of the response is reduced and the time to resolve the incident is increased.
 
 Engaging the delivery team is an important opportunity to learn and improve the security of future product delivery. We should use blameless post-mortems to share learnings more widely within the organisation. A culture of open information sharing around security incidents will lead to greater risk reduction to the organisation, as teams are better informed and motivated to avoid similar incidents in the future.
+

practices/organise.md renamed to practices/organise/README.md

@@ -19,3 +19,4 @@ Examples of other companies that have done this publicly:
 * [Homebrew GitHub personal access token leak](https://brew.sh/2018/08/05/security-incident-disclosure/)
 * [Parity hacked via security bug introduced during refactoring](https://www.parity.io/the-multi-sig-hack-a-postmortem/)
 * [Insider bitcoin theft from ShapeShift](http://moneyandstate.com/looting-of-the-fox/)
+

practices/organise/compliance-and-policy.md

@@ -11,3 +11,4 @@ All teams should have a Security Champion who regularly interacts with Security
 Working from the same physical location can confer advantages that are hard to replicate remotely. While we value the flexibility we get from communications tools like Slack, having technical security specialists physically present brings significant benefits. It allows them to get hands on, pairing with developers and testers or running threat modelling sessions increases their impact substantially and often reduces the time to resolve critical issues. It also has a very positive effect on the relationship between Security Engineering and delivery teams.
 
 When an engagement spans multiple locations, technical security specialists should be available to meet delivery teams in person wherever possible.
+

practices/organise/incident-response.md

@@ -16,3 +16,4 @@ Examples:
 Delivery teams don't always have the experience or skills required to address more specialist areas of security. This leads to suboptimal solutions or increased risk or complexity. Security Engineering should provide specialists in order to assist delivery teams when the team lacks the skills to complete a particular feature \(for example when implementing features that require cryptography\).
 
 Security Engineering should also be available to conduct or facilitate threat modelling sessions, and use this as an opportunity to teach this skill to others.
+

practices/organise/intelligence.md

@@ -46,3 +46,4 @@ Examples:
 Most organisations require a formal security evaluation before adopting new products or technologies. To do this, it needs technical security expertise to identify risks within the product and any supporting processes \(e.g. not just the technical implementation of the product, but also the way the vendor handles security issues and their expertise in security\).
 
 Security Engineering should be actively involved in evaluating any third party suppliers & products. This should not be seen as a yes/no assessment, but rather as a way to highlight potential weaknesses and recommend approaches to mitigate that risk.
+

practices/organise/scaling-security.md

@@ -11,7 +11,8 @@ The following principles guide our everyday work and are the foundation of the p
 A successful software security initiative depends on strong collaboration between everyone involved, including Security Engineering, product and delivery teams, together with support from senior management.
 
 > Security is everyone's job now, not just the security team's. With continuous integration and continuous deployment, all developers have to be security engineers, we move too fast for there to be time for reviews by the security team beforehand.
-> - Werner Vogels \(CTO, Amazon\)
+>
+> * Werner Vogels \(CTO, Amazon\)
 
 ## Good Security is Continuous
 
@@ -54,3 +55,4 @@ This doesn't mean we satisfy one organisational need at the expense of the other
 Security is best achieved in layers. Don't rely on a single practice or tool to meet all your security needs, but instead adopt multiple complementary practices and tools to provide layers of protection.
 
 This ensures that if a single tool or process fails to identify a vulnerability, or a single control fails, there will be other layers of security to avoid compromise. No single tool, process or control provides complete security, which is why the cumulative effect of multiple layers of security is paramount.
+