Alpha to beta

1-secure-development-is-everyones-concern.md

@@ -14,7 +14,7 @@ Every team needs security expertise, but not everyone on the team needs to be a
 
 During design and delivery, continuously ask questions, discuss and identify potential security issues and work together to deliver solutions. Embed this process within your 'normal' approach to product delivery.
 
-Security mistakes, and the associated security 'debt' which these entail, can be avoided if security is made part of everyday practice by your whole team. If this doesn't happen and security is considered as a 'bolt-on' once development is complete, then vulnerabilities may be missed and customer expectations may not be met. Both of these can lead to time-consuming and expensive re-working of code.
+Security mistakes, and the associated security 'debt' which these entail, can be avoided if security is made part of everyday practice by your whole team. If this doesn't happen and security is considered as a 'bolt-on' once development is complete, vulnerabilities may be missed and customer expectations may not be met. Both of these can lead to time-consuming and expensive re-working of code.
 
 Unfortunately, the security process is too often about achieving standards compliance and ticking boxes rather than delivering practical and pragmatic security outcomes. Developing a culture of encouraging people to ask questions and discuss potential security issues can help to overcome this.
 
@@ -35,7 +35,7 @@ Software development is a community activity. A healthy community should include
 
 ## Actions
 
-* **Define and articulate the requirements for security at the start and during product delivery**  
+* **Define and articulate the requirements for security at the start of and during product delivery**  
   Without this, security practices are unlikely to take hold and be given the priority they need. 'Top-down' support should be provided.
 
 * **Security is an essential skill for every member of the delivery team**  
@@ -65,11 +65,11 @@ Software development is a community activity. A healthy community should include
 
 ## Self assessment
 
-These examples are intended to help you assess your own practices, and those of your suppliers. The list below is not exhaustive.
+These examples are intended to help you assess your own practices, and those of your suppliers. The list below is not exhaustive and is not intended to be used as a checkbox exercise.
 
 | BAD | GOOD |
 |-----|------|
-| Security specialists do not consider the legitimate needs of the business alongside security. | Leaderships views spotting and fixing security issues as a positive. |
+| Security specialists do not consider the legitimate needs of the business alongside security. | Leadership views spotting and fixing security issues as a positive. |
 | Security requirements are often postponed to meet release deadlines, regardless of their impact. | Product engineering staff review security incidents and seek to learn from them. |
 | Developers hide their mistakes.| Security implications are considered at every sprint planning meeting. |
 | Developers do not take ownership of their code and seek to make security another person's responsibility. | There's top-down support for security within your organisation. |

2-keep-your-security-knowledge-sharp.md

@@ -17,7 +17,7 @@ Teams armed with up to date information are much more likely to implement approp
   If they do not already have this knowledge, resources should be provided so that it can be gained. Examples may include standard injection techniques and handling [untrusted input](https://www.owasp.org/index.php/Injection_Theory).
 
 * **Use your developer recruitment process to screen for basic security awareness** 
-  Qualifications aren't the only way to establish this. Real world practical application is more important. If this isn't possible, allocate extra resources for security learning and development.
+  Qualifications aren't the only way to establish this. In fact, real world practical application is more important. If this isn't possible, allocate extra resources for security learning and development.
 
 * **Make time and resources available for ongoing learning** 
   Invest in training to develop security knowledge and skills.
@@ -28,7 +28,7 @@ Teams armed with up to date information are much more likely to implement approp
 * **Make developers accountable for the security of their code** 
   Most developers already take pride in their work - [security is everyone's concern](2-keep-your-security-knowledge-sharp.md).
 
-* **Be aware and consider when there is a particular need to write code defensively** 
+* **Be aware when there is a particular need to write code defensively** 
   Take extra time and care when implementing security critical components, writing your code defensively. For example, when validating input which may be attacker-controlled.
 
 * **Get your security specialists to outline **for developers** which **components are** security-critical (this should not be 'everything')** 
@@ -68,3 +68,4 @@ These examples are intended to help you assess your own practices, and those of
 
 * [Secure design principles](https://www.ncsc.gov.uk/guidance/security-design-principles-digital-services-main)
 * [http://www.riscs.org.uk/wp-content/uploads/2015/12/Awareness-is-Only-the-First-Step.pdf](http://www.riscs.org.uk/wp-content/uploads/2015/12/Awareness-is-Only-the-First-Step.pdf)
+* [https://www.ncsc.gov.uk/cisp](https://www.ncsc.gov.uk/cisp)

3-produce-clean-and-maintainable-code.md

@@ -31,7 +31,7 @@ Writing defensive code will be easier to achieve, security mistakes easier to sp
 
 Having two or more people review code will increase your confidence in the quality and security of your product before release. This process should be enforced within your deployment pipeline to help reduce the likelihood of damaging code changes being pushed to your production environment.
 
-Any issues identified should be followed through with a fix. Remember, individuals can also peer review their own code, which can often save time before another person looks over it.
+Any issues identified should be followed through with a fix. Remember, individuals can also review their own code, which can often save time before another person looks over it.
 
 When reviewing code, you should consider:
 
@@ -51,7 +51,8 @@ The code that you write often only makes up a small fraction of the total code b
 There is no easy way to mitigate the risks of third party code, but asking these questions may help:
 
 *   If there is a security vulnerability in the third party components of your code, what security impact may this have on your system?
-*   Is the dependency actively developed and maintained? If a vulnerability is found, who will fix it?
+*   Is the dependency actively developed and maintained? 
+*   If a vulnerability is found in one of your dependencies, would you know? Who would fix it?
 *   Are you using any old versions of third party code known to contain security vulnerabilities?
 *   Do you know anything about the author and maintainer of the dependency? How do they view and approach security?
 *   Does the dependency have any history of security vulnerabilities? What's important here is not necessarily that issues are discovered, but how they are handled.
@@ -76,7 +77,7 @@ There is no easy way to mitigate the risks of third party code, but asking these
   Understanding code becomes more difficult when different coding styles used by different developers mix and intertwine.
 
 * **Clearly outline code block responsibilities**  
-  Security issues can arise when one code component inaccurately assumes another has taken responsibility for an action. For example, when validating potentially malicious input at the border of your application. One way to achieve this is to have a comment block at the top of every method or function.
+  Security issues can arise when one code component incorrectly assumes another has taken responsibility for an action. For example, when validating potentially malicious input at the border of your application. One way to achieve this is to have a comment block at the top of every method or function.
 
 * **Separate secret credentials**  
   Keep secrets such as passwords and private keys logically isolated from the core code base. This will help prevent them being checked in to public code repositories. Hard coding credentials in source code is bad practice.
@@ -91,7 +92,7 @@ There is no easy way to mitigate the risks of third party code, but asking these
   Encourage a culture that does not accept complicated, confusing or insecure coding practices. Peer review helps prevent such issues being incorporated into your code base. Feedback helps support education within your team. Using pull requests and comments is one way to achieve this.
 
 * **Team communications**  
-  When multiple team members are working on the same code base, there should be strong and regular communication channels between them. The aim here is to avoid the following scenario: 'I thought you were securing that component!'. Keeping teams physical close to one-another, or providing real-time chat channels are two ways to achieve this.
+  When multiple team members are working on the same code base, there should be strong and regular communication channels between them. The aim here is to avoid the following scenario: 'I thought you were securing that component!'. Keeping teams physically close to one-another, or providing real-time chat channels are two ways to achieve this.
 
 * **Document and comment clearly and consistently**  
   Clear and concise documentation should support your product. This may be as a result of self-documenting code, code comments, or supportive material. Documentation should be kept up to date, as a system evolves. Old and out-of-date documentation is difficult to trust and could be damaging for security if it's interpreted incorrectly.
@@ -100,7 +101,7 @@ There is no easy way to mitigate the risks of third party code, but asking these
   Developers and other team members may come and go over the life span of a product. To ensure adequate knowledge of the product is maintained, provide good support and documentation to new team members. After all, who will fix security vulnerabilities left behind by previous developers?
 
 * **Check return values and handle errors appropriately** 
-  Checking for errors at the point of a call and handling them immedidately means that your code doesn't continue running in a potentially unstable state. This will make your code more robust and secure.
+  Checking for errors at the point of a call and handling them immediately means that your code doesn't continue running in a potentially unstable state. This will make your code more robust and secure.
 
 
 

4-secure-your-development-environment.md

@@ -18,12 +18,11 @@ Where this is the case, it's important to recognise the onward impact that a com
 
 ### Security gained
 
-By performing the functions outlined in subsequent sections, you can help reduce the risk of an attacker:
+You can take actions to secure your development environment and reduce the risk of an attacker:
 
-*   stealing sensitive information (such as encryption and access keys, passwords or knowledge of security controls)
+*   stealing sensitive information (such as encryption and access keys, passwords, knowledge of security controls or intellectual property)
 *   embedding malicious code in your project without your knowledge
-*   using a compromised development device as a proxy to further attack your build and deployment pipeline, through to production
-*   stealing code for the intellectual property it contains, or to release it publicly, causing embarrassment or degrading your security
+*   using a compromised development device as a proxy to further attack your build and deployment pipeline, through to production 
 *   understanding how your sensitive applications work - a first step in the planning of an attack
 
 ### Securing a flexible system
@@ -44,7 +43,7 @@ The following measures can help you to understand and reduce these risks:
 
   If an attacker is able to compromise a developer's environment they will inherit the same level of permissions and access as that developer. Placing additional controls between your developer environments and critical systems will help to reduce this impact.
 
-  For example, the use of multi-factor authentication will make it harder for an attacker to leverage stolen credentials and access tokens. Automated security testing and a multi-person review process as part of your deployment pipeline can help catch and prevent onward impact.
+  For example, the use of multi-factor authentication will make it harder for an attacker who has compromised a device to leverage stolen keys, credentials and access tokens. Automated security testing and a multi-person review process as part of your deployment pipeline can help catch and prevent onward impact.
 
 * **Trust your developers, verify their actions**
 
@@ -56,7 +55,7 @@ The following measures can help you to understand and reduce these risks:
 ## Actions
 
 * **Provide developers with the tools and environment they need**  
-  Practical tooling is essential if you want to avoid technically savvy developers finding insecure workarounds. This may sometimes mean being a bit more tolerant to the risks of a developer device being compromised and putting wider protections in place to account for this. If an IT department can respond effectivley to software requests, it may be possible to avoid giving out local administrative permissions.
+  Practical tooling is essential if you want to avoid technically savvy developers finding insecure workarounds. This may sometimes mean being a bit more tolerant to the risks of a developer device being compromised and putting wider protections in place to account for this. If an IT department can respond effectively to software requests, it may be possible to avoid giving out local administrative permissions.
 
 * **Trust your developers, verify their actions**  
   Educate users and trust them to do the right thing. Implement functions to verify their activity, and to detect suspicious activity or potential compromise.
@@ -77,7 +76,7 @@ The following measures can help you to understand and reduce these risks:
   In the event that developer devices are compromised, constrain their onward access with wider network architecture controls that supports defence in depth. Examples may include firewall rule sets only permitting developer devices to communicate to intended services. Also consider the impact these services have on your developers. For example, non transparent proxies can hinder use of some technologies.
 
 * **Carry out protective monitoring of your development environment**  
-  You should have an idea of what legitimate use of your environment looks like. Combining this knowledge with logging from your environment can help to detect illegitimate use or potentially, a compromise. For example, are strange websites being accessed and are priviledged actions being carried out during unusual hours of the day?
+  You should have an idea of what legitimate use of your environment looks like. Combining this knowledge with logging from your environment can help to detect illegitimate use or potentially, a compromise. For example, are strange websites being accessed and are privileged actions being carried out during unusual hours of the day?
 
 
 ## Self assessment