From 234ac5188a797d2672fd9c3ef0efb6e6039743d3 Mon Sep 17 00:00:00 2001
From: Brandon Caldwell <brandonc@unity3d.com>
Date: Mon, 13 May 2019 10:20:18 -0700
Subject: [PATCH 01/54] Initial commit

---
 LICENSE   | 21 +++++++++++++++++++++
 README.md |  2 ++
 2 files changed, 23 insertions(+)
 create mode 100644 LICENSE
 create mode 100644 README.md

diff --git a/LICENSE b/LICENSE
new file mode 100644
index 0000000..eb18dfb
--- /dev/null
+++ b/LICENSE
@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2019 Unity Technologies
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.
diff --git a/README.md b/README.md
new file mode 100644
index 0000000..0ea4d32
--- /dev/null
+++ b/README.md
@@ -0,0 +1,2 @@
+# unity-ssdlc
+A public version of Unity's internal SSDLC. Meant to provide an example framework, not just to share with other, but to also take contributions and continue to improve and evolve.

From 9ad117ce1749f5d40c7e334215327fba7937c792 Mon Sep 17 00:00:00 2001
From: Brandon <brandonc@hq.unity3d.com>
Date: Mon, 13 May 2019 13:29:18 -0700
Subject: [PATCH 02/54] First edit of the overview page

---
 Overview.md                      |  48 +++++++++++++++++++++++++++++++
 images/sdlc process graphic.png  | Bin 0 -> 35254 bytes
 images/ssdlc process graphic.png | Bin 0 -> 39963 bytes
 3 files changed, 48 insertions(+)
 create mode 100644 Overview.md
 create mode 100644 images/sdlc process graphic.png
 create mode 100644 images/ssdlc process graphic.png

diff --git a/Overview.md b/Overview.md
new file mode 100644
index 0000000..2789e95
--- /dev/null
+++ b/Overview.md
@@ -0,0 +1,48 @@
+#Secure Software Development Lifecycle SSDLC
+
+Software Development Lifecycle (SDLC)
+![Software Development Lifecycle Diagram](./images/sdlc process graphic.png "SDLC Diagram")
+Secure Software Development Lifecycle (SSDLC)
+![Software Development Lifecycle Diagram](./images/ssdlc process graphic.png "SSDLC Diagram")
+
+| Requirments Phase Offerings | Design Phase Offerings | Develop Phase Offerings | Test Phase Offerings| Deploy Phase Offerings |
+| :--- | :--- | :--- | :--- | :--- |
+| Security Requirements | Design Review & Threat Models |  -Static Analysis Tools<br>-Secure Coding | - Ask in Slack <br>- Security Testing | - Pentest in Product<br>- Incident Response Support |
+
+
+###Unity SSDLC Overview
+
+The goal of Unity's SSDLC provide product teams guidance on how to include software security practices into their existing development process. The phases above may not be formally implemented or recognized by your team, but they do generally represent how all software is developed, implicitly or explicitly. Following this model, you are able to best determine what services the Unity Security team provides based on what phase of the life-cycle you are currently in, with your product.
+
+The SSDLC will continue to evolve, and include services from the broader Security teams; we'll soon be adding links to guidance from Audit & Compliance, Infrastructure Security, SOC, Incident Response, and Product Security.
+
+All feedback is welcome - feel free to update/comment on the docs directly or chat with the team on Slack or email.
+
+Our SSDLC is currently organized under the following topics:
+- [Coding Practice guides](unity.com)
+- [Language Guidance articles](unity.com)
+- [Security Process documentation](unity.com)
+- [Tools & Automation guidance](unity.com)
+
+Also, be sure to keep an eye out for on-site trainings, which will be announced (and archived) here -> [Developer Security Trainings](unity.com)
+
+###Suggested SSDLC Topics and Articles
+#####Language Specific Guidance
+- [Golang](unity.com)
+- [Node.js](unity.com)
+- [Ruby](unity.com)
+- [C#](unity.com)
+
+#####Secure Coding Guidance
+- [API Best Practices](unity.com)
+- [Authentication/Authorization Best Practices](unity.com)
+- [Preventing Common Web Attacks](unity.com)
+
+#####Security Automation and Tooling
+
+- [AppCollector](unity.com) - Onboard your project/product with Security
+- [Vault](unity.com) - Secrets management service
+- [Constable](unity.com) - Service providing file inspection to protect agents malware and malicious files
+- [SourceClear](unity.com) - Dependency version checking and static analysis 
+  -  [SourceClear](unity.com) Remediation
+
diff --git a/images/sdlc process graphic.png b/images/sdlc process graphic.png
new file mode 100644
index 0000000000000000000000000000000000000000..456c4cebee4570022be9c7cfc3ed37be4085ad14
GIT binary patch
diff --git a/images/ssdlc process graphic.png b/images/ssdlc process graphic.png
new file mode 100644
index 0000000000000000000000000000000000000000..b90af10df761186337c8ea9850fb69ec98bd3284
GIT binary patch

From b10231e4ec76c1a8ed37c05e704ba23269f9b777 Mon Sep 17 00:00:00 2001
From: Brandon <brandonc@hq.unity3d.com>
Date: Mon, 13 May 2019 13:37:22 -0700
Subject: [PATCH 03/54] Made some minor formatting changes to render images and
 heading correctly. Github MD is finnicky :)

---
 Overview.md | 22 +++++++++++-----------
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/Overview.md b/Overview.md
index 2789e95..5e93c20 100644
--- a/Overview.md
+++ b/Overview.md
@@ -1,16 +1,16 @@
-#Secure Software Development Lifecycle SSDLC
+# Secure Software Development Lifecycle SSDLC
 
-Software Development Lifecycle (SDLC)
-![Software Development Lifecycle Diagram](./images/sdlc process graphic.png "SDLC Diagram")
-Secure Software Development Lifecycle (SSDLC)
-![Software Development Lifecycle Diagram](./images/ssdlc process graphic.png "SSDLC Diagram")
+### Software Development Lifecycle (SDLC)
+![Software Development Lifecycle Diagram](images/sdlc%20process%20graphic.png "SDLC Diagram")
+### Secure Software Development Lifecycle (SSDLC)
+![Software Development Lifecycle Diagram](images/ssdlc%20process%20graphic.png "SSDLC Diagram")
 
 | Requirments Phase Offerings | Design Phase Offerings | Develop Phase Offerings | Test Phase Offerings| Deploy Phase Offerings |
 | :--- | :--- | :--- | :--- | :--- |
-| Security Requirements | Design Review & Threat Models |  -Static Analysis Tools<br>-Secure Coding | - Ask in Slack <br>- Security Testing | - Pentest in Product<br>- Incident Response Support |
+| Security Requirements | Design Review & Threat Models |  - Static Analysis Tools<br> - Secure Coding | - Ask in Slack <br>- Security Testing | - Pentest in Product<br>- Incident Response Support |
 
 
-###Unity SSDLC Overview
+### Unity SSDLC Overview
 
 The goal of Unity's SSDLC provide product teams guidance on how to include software security practices into their existing development process. The phases above may not be formally implemented or recognized by your team, but they do generally represent how all software is developed, implicitly or explicitly. Following this model, you are able to best determine what services the Unity Security team provides based on what phase of the life-cycle you are currently in, with your product.
 
@@ -26,19 +26,19 @@ Our SSDLC is currently organized under the following topics:
 
 Also, be sure to keep an eye out for on-site trainings, which will be announced (and archived) here -> [Developer Security Trainings](unity.com)
 
-###Suggested SSDLC Topics and Articles
-#####Language Specific Guidance
+### Suggested SSDLC Topics and Articles
+##### Language Specific Guidance
 - [Golang](unity.com)
 - [Node.js](unity.com)
 - [Ruby](unity.com)
 - [C#](unity.com)
 
-#####Secure Coding Guidance
+##### Secure Coding Guidance
 - [API Best Practices](unity.com)
 - [Authentication/Authorization Best Practices](unity.com)
 - [Preventing Common Web Attacks](unity.com)
 
-#####Security Automation and Tooling
+##### Security Automation and Tooling
 
 - [AppCollector](unity.com) - Onboard your project/product with Security
 - [Vault](unity.com) - Secrets management service

From 8282aeb9934ed62e7c0c39650ce8828c1aa53c90 Mon Sep 17 00:00:00 2001
From: Brandon <brandonc@hq.unity3d.com>
Date: Mon, 13 May 2019 15:25:19 -0700
Subject: [PATCH 04/54] Added API Best Practices doc

---
 Coding Practice/API-Best-Practices.md | 114 ++++++++++++++++++++++++++
 Overview.md                           |   1 +
 2 files changed, 115 insertions(+)
 create mode 100644 Coding Practice/API-Best-Practices.md

diff --git a/Coding Practice/API-Best-Practices.md b/Coding Practice/API-Best-Practices.md
new file mode 100644
index 0000000..56f9ab3
--- /dev/null
+++ b/Coding Practice/API-Best-Practices.md	
@@ -0,0 +1,114 @@
+# API Best Practices Guidelines [_Coding Practice_] 
+<font size="-1">_Author: Frank Arana (Dec. 2018)_</font>
+
+## Overview
+
+This document covers general security guidelines for API endpoints within Unity. These guidelines will cover general points like:
+- [Access control guidance](#access-controls)
+- [Input validation](#input-validation)
+- [Request verification](#request-integrity)
+- [Replay attacks](#replay-attacks)
+- [General security practices relevant to, but not specific to APIs](#general)
+
+### Recommendations
+##### Access Controls
+###### Description
+
+API endpoints should follow the principle of least privilege. Services with protected information should serve to the smallest group possible.
+###### Why We Care
+
+APIs with misconfigured access controls can lead to unintentional information leaks, or unauthorized and malicious state changing actions on sensitive data.
+###### Example of Issue (Optional)
+
+A POST that allows the user to modify information on an account without checking if the user owns the account being modified.
+
+A GET request that returns sensitive informative information without authentication.
+
+###### How to Fix?
+
+Determine which API actions should be considered sensitive or public.
+
+For Internal (to Unity) APIs: Limit network access as much as possible. Ideally, these endpoints should be restricted to a closed network, and require authentication stronger than a singular API key. For example, multi-factor authentication.
+
+For Public APIs with sensitive information: Require authentication before performing any action being requested. API keys should be both revocable and renewable.
+
+For Public APIs providing public information: Ensure no state changing actions are being performed through a public API without authentication. Consider rate limiting to prevent a single host making too many requests in a small amount of time.
+###### Security Level
+
+Incorrect access controls can range from High to Low Severity.
+###### References (Optional)
+
+https://www.owasp.org/index.php/REST_Security_Cheat_Sheet
+
+#### Input Validation
+###### Description
+
+Incoming data can be malformed or crafted to cause unintended behavior when it is parsed.
+###### Why We Care
+
+Depending on how input is parsed, it is possible unvalidated input can contain command injections, or other harmful actions.
+###### Example of Issue (Optional)
+*TBD*
+
+###### How to Fix?
+
+Type checking - Ensure input is of the expected data type, reject anything else.
+
+Length and size checking - Input should be within an expected length or size. Reject anything larger or smaller than expected.
+
+Whitelist accepted content-types
+
+Restrict http methods
+
+Parsing - Third party parsers should be kept up to date, changes to internal parsers should be carefully reviewed.
+###### Security Level
+
+Input Validation issues could range from Low to High depending on what how the error can be leveraged.
+###### References (Optional)
+*TBD - List external references for more detailed guidance*
+#### Request Integrity
+###### Description
+
+It is possible that a request could be modified in-transit between the original requestor and the API endpoint.
+###### Why We Care
+
+Modified requests may cause state changing actions to the original requestor’s data, or cause incorrect, modified, or unexpected data to be served.
+###### Example of Issue (Optional)
+
+#### Replay Attacks
+An attacker sends a previous, genuine request to cause an action to happen again at a later time.
+
+Modified requests in-transit: An attacker modifies data in the genuine request as it is sent.
+###### How to Fix?
+
+Generate signatures or HMACs for each request containing sensitive data or actions. Check the signature of the request to determine if it is genuine. Sign requests that include timestamps, and deny all requests that are relatively too old.
+###### Security Level
+
+Depending on what actions the request can take, severity could range from High to Low.
+###### References (Optional)
+
+https://docs.aws.amazon.com/general/latest/gr/signing_aws_api_requests.html#why-requests-are-signed 
+#### General
+###### Description
+Common security practices relevant, but not exclusive to APIs
+###### Why We Care
+
+Even by following best security practices for APIs, it is possible to miss other malicious activity.
+###### Example of Issue (Optional)
+
+No logging or monitoring missing security events
+
+Returning stack traces or other descriptive information of the service backend
+###### How to Fix?
+
+Log and monitor API activity. Detecting anomalies can assist in finding malicious activity that isn’t apparent anywhere else.
+
+Disable CORS if not needed, or scope it down as small as possible to prevent forged requests or data leakage.
+
+Return vague error responses. Put as little information as possible when returning an error to the user. Do not return any information about the server environment or debug information like stack traces.
+###### Security Level
+
+Ranging from Low to High depending on context.
+###### References (Optional)
+
+*TBD - List external references for more detailed guidance*
diff --git a/Overview.md b/Overview.md
index 5e93c20..6b81aeb 100644
--- a/Overview.md
+++ b/Overview.md
@@ -1,4 +1,5 @@
 # Secure Software Development Lifecycle SSDLC
+<font size="-2">Unity Security 2019</font>
 
 ### Software Development Lifecycle (SDLC)
 ![Software Development Lifecycle Diagram](images/sdlc%20process%20graphic.png "SDLC Diagram")

From 49ec563413e36a03ae7cfb645c7b762aa0f4e197 Mon Sep 17 00:00:00 2001
From: Brandon Caldwell <brandonc@unity3d.com>
Date: Mon, 13 May 2019 15:42:00 -0700
Subject: [PATCH 05/54] Added AuthZ & AuthN guidance. Minor changes ot others
 for normalizing styles.

---
 Coding Practice/API-Best-Practices.md     |  15 ++-
 Coding Practice/AuthZ-AuthN-Guidelines.md | 131 ++++++++++++++++++++++
 2 files changed, 142 insertions(+), 4 deletions(-)
 create mode 100644 Coding Practice/AuthZ-AuthN-Guidelines.md

diff --git a/Coding Practice/API-Best-Practices.md b/Coding Practice/API-Best-Practices.md
index 56f9ab3..dbf3224 100644
--- a/Coding Practice/API-Best-Practices.md	
+++ b/Coding Practice/API-Best-Practices.md	
@@ -1,5 +1,5 @@
 # API Best Practices Guidelines [_Coding Practice_] 
-<font size="-1">_Author: Frank Arana (Dec. 2018)_</font>
+<font size="-1">_Author: Frank Arana - Dec. 2018_</font>
 
 ## Overview
 
@@ -11,7 +11,7 @@ This document covers general security guidelines for API endpoints within Unity.
 - [General security practices relevant to, but not specific to APIs](#general)
 
 ### Recommendations
-##### Access Controls
+#### Access Controls
 ###### Description
 
 API endpoints should follow the principle of least privilege. Services with protected information should serve to the smallest group possible.
@@ -40,6 +40,8 @@ Incorrect access controls can range from High to Low Severity.
 
 https://www.owasp.org/index.php/REST_Security_Cheat_Sheet
 
+---
+
 #### Input Validation
 ###### Description
 
@@ -66,7 +68,9 @@ Parsing - Third party parsers should be kept up to date, changes to internal par
 Input Validation issues could range from Low to High depending on what how the error can be leveraged.
 ###### References (Optional)
 *TBD - List external references for more detailed guidance*
-#### Request Integrity
+
+---
+### Request Integrity
 ###### Description
 
 It is possible that a request could be modified in-transit between the original requestor and the API endpoint.
@@ -75,7 +79,8 @@ It is possible that a request could be modified in-transit between the original
 Modified requests may cause state changing actions to the original requestor’s data, or cause incorrect, modified, or unexpected data to be served.
 ###### Example of Issue (Optional)
 
-#### Replay Attacks
+---
+### Replay Attacks
 An attacker sends a previous, genuine request to cause an action to happen again at a later time.
 
 Modified requests in-transit: An attacker modifies data in the genuine request as it is sent.
@@ -88,6 +93,8 @@ Depending on what actions the request can take, severity could range from High t
 ###### References (Optional)
 
 https://docs.aws.amazon.com/general/latest/gr/signing_aws_api_requests.html#why-requests-are-signed 
+
+---
 #### General
 ###### Description
 Common security practices relevant, but not exclusive to APIs
diff --git a/Coding Practice/AuthZ-AuthN-Guidelines.md b/Coding Practice/AuthZ-AuthN-Guidelines.md
new file mode 100644
index 0000000..7338927
--- /dev/null
+++ b/Coding Practice/AuthZ-AuthN-Guidelines.md	
@@ -0,0 +1,131 @@
+# Authorization and Authentication Guidelines [Coding Practice]
+<font size="-1">_Author: Carlo Valentien - Dec. 2018_</font>
+
+## Overview
+
+This document provides guidelines for how to implement authentication and authorization in Unity applications.These guidelines will cover general points like:
+- [Use a Trusted Identity Provider](#use-a-trusted-identity-provider)
+- [Require Multi-Factor Authentication for Sensitive Applications](#require-multi-factor-authentication-for-sensitive-applications)
+- [Limit OAuth2 Scope by the Principle of Least Privilege](#limit-oauth2-scope-by-the-principle-of-least-privilege)
+- [Limited Token Lifetimes](#limited-token-lifetimes)
+- [Validating OAuth2 Redirect URIs](#validating-oauth2-redirect-uris)
+- [Validating the OAuth2 State Parameter](#validating-the-oauth2-state-parameter)
+
+**Authentication** is the process of verifying the user’s identity typically through an initial login and subsequently by verifying a unique secret identifier on each HTTP request made by the user’s browser.
+
+**Authorization** is the process of ensuring a user can only access resources they are supposed to, usually based on some role or security level that is defined according to business logic.
+## Recommendations
+### Use a Trusted Identity Provider
+###### Description
+
+Most of our users will be accessing services related to Unity, and we should leverage Genesis and Unity ID to authenticate those users to any new services or publicly facing applications. Using a single, unified identity to authenticate a user will make it easy for the user to use a new service and application.
+
+When creating internal applications, Active Directory should be used to validate a user using their known credentials. In the future, this will be replaced with integration with Okta to authenticate a user.
+###### Why We Care
+
+Many services will require authentication as a requirement. No authentication allows for anonymous access, which prevents proper logging and brings the risk of trivial information disclosure. However, designing an entire authentication service for you an application is also no trivial task, with many caveats that can lead to leaked/bypassed credentials, and a number of other issues. By using a trusted identity provider, the security team can work on securing a small number of authentication platforms to the benefit of a number of teams at Uniyt.
+###### How to Fix?
+
+Determine if your application is an internal or external application. If it is external, contact Genesis and Security to integrate your application with Unity ID. If it is internal, contact IT to integrate with Active Directory (and Okta in the future).
+###### Security Level
+
+High
+
+---
+### Require Multi-Factor Authentication for Sensitive Applications
+###### Description
+
+During login, the user should be prompted for at least one second factor of authentication for sensitive services. Sensitive services typically include, but are not limited to: administrative panels, services that handle PII or payment information, and flagship service.
+###### Why We Care
+
+By adding multiple layers of verification we can ensure that a user’s account is not compromised, especially for sensitive applications and services. This will ensure in the case where a password (the most common initial factor of authentication) is not enough to compromise a user’s account.
+###### How to Fix?
+
+Contact the appropriate identity provider to be used at Unity, and require 2FA if needed.
+###### Security Level
+
+Medium
+
+---
+### Limit OAuth2 Scope by the Principle of Least Privilege
+###### Description
+
+When an OAuth2 client, a scope is defined for the the client. This scope determines which Genesis Backend APIs are accessible to the client after performing authentication. When setting up a new OAuth2 client, the team requesting the client should identify what APIs/data they need access to, and limit the scope to those specific APIs.
+###### Why We Care
+
+Limiting the scope of our APIs is a best practice, that can limit the impact of a successful attack. Also, often it is a Unity ID user that is authenticating using the given scope, and with the given access token will give the user direct access to the APIs. Since this is publicly accessible, care should be taken that the user cannot access sensitive APIs, in particular APIs that handle personally identifiable information (PII).
+###### How to Fix?
+
+During the requirements phase, determine what information is needed for the OAuth2 client, and limit the APIs to only what is necessary. If possible, work with Genesis to build a custom scope that will limit access to wider APIs. 
+###### Security Level
+
+Medium
+###### References
+
+https://tools.ietf.org/html/rfc6819#section-3.1.1
+
+--- 
+### Limited Token Lifetimes
+###### Description
+
+When authenticating, a variety of tokens are used to prove the identity of a user. This is typically through a session cookie, or an access token attached to a user’s account. These tokens should have the shortest lifetime that balances the needs to of the users with security. Tokens should not be valid for an infinite amount of time, and should expire within a reasonable timeframe.
+###### Why We Care
+
+This is primarily a defense-in-depth measure, focusing on the case if these tokens are compromised, it will limit the impact of an attack. This also decreases the attack surface of a resulting application, reducing the number of valid tokens at any given time.
+###### How to Fix?
+
+Check all tokens related to authentication, and review their lifetimes. If you are unsure, contact security for recommendations on their lifetimes. When possible, use the shortest lifetime within a reasonable use.
+###### Security Level
+
+Medium
+
+---
+### Validating OAuth2 Redirect URIs
+###### Description
+
+When performing the OAuth2 login flow, a redirect URI is used to securely send the access token to the client web application, after it has authenticated with Genesis. This is provided by the client during the OAuth2 flow. This URI should be validated to ensure it is a known URI that is used by the OAuth2 client.
+###### Why We Care
+
+This prevents a potential information disclosure attack when there is an open redirect on a valid redirect URI. This results in a user’s OAuth token being potentially leaked, compromising their account.
+###### How to Fix?
+
+Validate the entire URI against a whitelist of known valid URIs. Avoid using regular expressions or substring matching.
+
+###### Examples:
+
+_Good Example:_
+    
+    def validate_redirect_uri(redirect_uri):
+        if redirect_uri == "https://newservice.unity3d.com/validate_oauth" :
+            return True;
+        return False;
+
+_Bad Example_
+    
+    def validate_redirect_uri(redirect_uri):
+        if "unity3d.com" in redirect_uri:
+            return True;
+        return False;
+
+
+###### Security Level
+
+High
+
+---
+### Validating the OAuth2 State Parameter
+###### Description
+
+When starting the initial OAuth2 flow, the client has the option of providing a state parameter. This state parameter is then send back with the authorization to be validated by the client later in the flow. This state parameter should be generated upon the initial OAuth2 request, and stored to validate once the authorization from Genesis has occurred.
+###### Why We Care
+
+This is to ensure that the OAuth2 flow is initiated by the user, and is not vulnerable to a potential CSRF. By ensuring that the user has initiated the OAuth2 flow, they will be performing actions within their account with known permissions.
+###### How to Fix?
+
+Generate a cryptographically-secure random state parameter when the OAuth2 flow is initialized. The client should validate this when it is returned through the redirect URI callback. The parameter should only be valid for the same OAuth2 flow that initiated it.
+###### Security Level
+
+Low
+###### References
+
+https://tools.ietf.org/html/rfc6819#section-3.6

From a88ad8e0ae513b22cbcf1e2be202214b3ca500ea Mon Sep 17 00:00:00 2001
From: Brandon Caldwell <brandonc@unity3d.com>
Date: Tue, 14 May 2019 09:28:44 -0700
Subject: [PATCH 06/54] Finished adding the rest of the 'Code Practice' docs.

---
 Coding Practice/API-Best-Practices.md         |   8 +-
 Coding Practice/AuthZ-AuthN-Guidelines.md     |  14 +-
 Coding Practice/Cryptographic-Guidelines.md   |  55 ++++
 Coding Practice/HTTP-Header-Security.md       | 126 +++++++++
 .../Preventing-Common-Web-Attacks.md          | 263 ++++++++++++++++++
 Coding Practice/Secrets-Management.md         | 193 +++++++++++++
 Coding Practice/Secure-Design-Principles.md   | 108 +++++++
 Overview.md                                   |   6 +-
 images/secrets fire.png                       | Bin 0 -> 314164 bytes
 9 files changed, 759 insertions(+), 14 deletions(-)
 create mode 100644 Coding Practice/Cryptographic-Guidelines.md
 create mode 100644 Coding Practice/HTTP-Header-Security.md
 create mode 100644 Coding Practice/Preventing-Common-Web-Attacks.md
 create mode 100644 Coding Practice/Secrets-Management.md
 create mode 100644 Coding Practice/Secure-Design-Principles.md
 create mode 100644 images/secrets fire.png

diff --git a/Coding Practice/API-Best-Practices.md b/Coding Practice/API-Best-Practices.md
index dbf3224..3415ae3 100644
--- a/Coding Practice/API-Best-Practices.md	
+++ b/Coding Practice/API-Best-Practices.md	
@@ -33,7 +33,7 @@ For Internal (to Unity) APIs: Limit network access as much as possible. Ideally,
 For Public APIs with sensitive information: Require authentication before performing any action being requested. API keys should be both revocable and renewable.
 
 For Public APIs providing public information: Ensure no state changing actions are being performed through a public API without authentication. Consider rate limiting to prevent a single host making too many requests in a small amount of time.
-###### Security Level
+###### Risk Rating
 
 Incorrect access controls can range from High to Low Severity.
 ###### References (Optional)
@@ -63,7 +63,7 @@ Whitelist accepted content-types
 Restrict http methods
 
 Parsing - Third party parsers should be kept up to date, changes to internal parsers should be carefully reviewed.
-###### Security Level
+###### Risk Rating
 
 Input Validation issues could range from Low to High depending on what how the error can be leveraged.
 ###### References (Optional)
@@ -87,7 +87,7 @@ Modified requests in-transit: An attacker modifies data in the genuine request a
 ###### How to Fix?
 
 Generate signatures or HMACs for each request containing sensitive data or actions. Check the signature of the request to determine if it is genuine. Sign requests that include timestamps, and deny all requests that are relatively too old.
-###### Security Level
+###### Risk Rating
 
 Depending on what actions the request can take, severity could range from High to Low.
 ###### References (Optional)
@@ -113,7 +113,7 @@ Log and monitor API activity. Detecting anomalies can assist in finding maliciou
 Disable CORS if not needed, or scope it down as small as possible to prevent forged requests or data leakage.
 
 Return vague error responses. Put as little information as possible when returning an error to the user. Do not return any information about the server environment or debug information like stack traces.
-###### Security Level
+###### Risk Rating
 
 Ranging from Low to High depending on context.
 ###### References (Optional)
diff --git a/Coding Practice/AuthZ-AuthN-Guidelines.md b/Coding Practice/AuthZ-AuthN-Guidelines.md
index 7338927..204e6e4 100644
--- a/Coding Practice/AuthZ-AuthN-Guidelines.md	
+++ b/Coding Practice/AuthZ-AuthN-Guidelines.md	
@@ -13,7 +13,7 @@ This document provides guidelines for how to implement authentication and author
 
 **Authentication** is the process of verifying the user’s identity typically through an initial login and subsequently by verifying a unique secret identifier on each HTTP request made by the user’s browser.
 
-**Authorization** is the process of ensuring a user can only access resources they are supposed to, usually based on some role or security level that is defined according to business logic.
+**Authorization** is the process of ensuring a user can only access resources they are supposed to, usually based on some role or Risk Rating that is defined according to business logic.
 ## Recommendations
 ### Use a Trusted Identity Provider
 ###### Description
@@ -27,7 +27,7 @@ Many services will require authentication as a requirement. No authentication al
 ###### How to Fix?
 
 Determine if your application is an internal or external application. If it is external, contact Genesis and Security to integrate your application with Unity ID. If it is internal, contact IT to integrate with Active Directory (and Okta in the future).
-###### Security Level
+###### Risk Rating
 
 High
 
@@ -42,7 +42,7 @@ By adding multiple layers of verification we can ensure that a user’s account
 ###### How to Fix?
 
 Contact the appropriate identity provider to be used at Unity, and require 2FA if needed.
-###### Security Level
+###### Risk Rating
 
 Medium
 
@@ -57,7 +57,7 @@ Limiting the scope of our APIs is a best practice, that can limit the impact of
 ###### How to Fix?
 
 During the requirements phase, determine what information is needed for the OAuth2 client, and limit the APIs to only what is necessary. If possible, work with Genesis to build a custom scope that will limit access to wider APIs. 
-###### Security Level
+###### Risk Rating
 
 Medium
 ###### References
@@ -75,7 +75,7 @@ This is primarily a defense-in-depth measure, focusing on the case if these toke
 ###### How to Fix?
 
 Check all tokens related to authentication, and review their lifetimes. If you are unsure, contact security for recommendations on their lifetimes. When possible, use the shortest lifetime within a reasonable use.
-###### Security Level
+###### Risk Rating
 
 Medium
 
@@ -108,7 +108,7 @@ _Bad Example_
         return False;
 
 
-###### Security Level
+###### Risk Rating
 
 High
 
@@ -123,7 +123,7 @@ This is to ensure that the OAuth2 flow is initiated by the user, and is not vuln
 ###### How to Fix?
 
 Generate a cryptographically-secure random state parameter when the OAuth2 flow is initialized. The client should validate this when it is returned through the redirect URI callback. The parameter should only be valid for the same OAuth2 flow that initiated it.
-###### Security Level
+###### Risk Rating
 
 Low
 ###### References
diff --git a/Coding Practice/Cryptographic-Guidelines.md b/Coding Practice/Cryptographic-Guidelines.md
new file mode 100644
index 0000000..490d1f2
--- /dev/null
+++ b/Coding Practice/Cryptographic-Guidelines.md	
@@ -0,0 +1,55 @@
+# Cryptographic Guidelines [Coding Practice]
+<font size="-1">*Brandon Caldwell Jan 2019*</font>
+
+## Guidelines Overview
+
+Cryptographic requirements at Unity are heavily influenced by NIST's *Cryptographic Standards and Guidelines (CSRC)* documentation. Below are our condensed recommendations.
+
+### Usage Guidance
+###### TLS - Cipher Suites
+
+_Minimum TLS version = TLS1.2._
+All cipher suites below should be compatible with version > TLS 1.2.  
+SSL 3.0 and below are not allowed, and considered unsafe.
+Accepted TLS Cipher suites:
+- TLS_RSA_WITH_3DES_EDE_CBC_SHA
+- TLS_RSA_WITH_AES_128_CBC_SHA
+- TLS_RSA_WITH_AES_256_CBC_SHA
+- TLS_RSA_WITH_AES_128_GCM_SHA256
+- TLS_RSA_WITH_AES_256_GCM_SHA384
+- TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
+- TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
+- TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
+- TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
+- TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
+- TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA
+- TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
+- TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
+- TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
+
+###### Hash Algorithms
+
+- Language Agnostic
+  - SHA-512
+  - SHA-384
+  - SHA-256
+- .Net hashing algoritms
+  - SHA512Cng (FIPS compliant)
+  - SHA384Cng (FIPS compliant)
+  - SHA256Cng (FIPS compliant)
+  - SHA512Managed (non-FIPS-compliant) (use SHA512 as algorithm name in calls to HashAlgorithm.Create or CryptoConfig.CreateFromName)
+  - SHA384Managed (non-FIPS-compliant) (use SHA384 as algorithm name in calls to HashAlgorithm.Create or CryptoConfig.CreateFromName)
+  - SHA256Managed (non-FIPS-compliant) (use SHA256 as algorithm name in calls to HashAlgorithm.Create or CryptoConfig.CreateFromName)
+  - SHA512CryptoServiceProvider (FIPS compliant)
+  - SHA256CryptoServiceProvider (FIPS compliant)
+  - SHA384CryptoServiceProvider (FIPS compliant)
+
+###### Random Number Generators (RNG)
+- **CNG**: BCryptGenRandom(use of the BCRYPT_USE_SYSTEM_PREFERRED_RNG flag recommended unless the aller might run at any IRQL greater than 0 [that is, PASSIVE_LEVEL])
+- **CAPI**: cryptGenRandom
+- **Win32/64**: RtlGenRandom (new implementations should use BCryptGenRandom or CryptGenRandom) * and_s * SystemPrng (for kernel mode)
+- **.NET** RNGCryptoServiceProvider or RNGCng
+- **Windows Store Apps**: Windows.Security.Cryptography.CryptographicBuffer.GenerateRandom or GenerateRandomNumber
+- **Apple OS X** _(10.7+)/iOS(2.0+)_: int SecRandomCopyBytes (SecRandomRef random, size_t count, int8_t *bytes )
+- **Apple OS X** _(<10.7)_: Use /dev/random to retrieve random numbers
+- **Java** _(including Google Android Java code)_- java.security.SecureRandom class. Note that for Android 4.3 (Jelly Bean), developers must follow the Android recommended workaround and pdate their applications to explicitly initialize the PRNG with entropy from /dev/urandom or dev/random
\ No newline at end of file
diff --git a/Coding Practice/HTTP-Header-Security.md b/Coding Practice/HTTP-Header-Security.md
new file mode 100644
index 0000000..c7876e2
--- /dev/null
+++ b/Coding Practice/HTTP-Header-Security.md	
@@ -0,0 +1,126 @@
+# HTTP Header Security [Coding Practice]
+<font size="-1">_Author: Christian Håland - Dec. 2018_</font>
+## Overview
+This document describes the HTTP security headers that we strongly recommend are implemented on all of Unity’s Internet-facing services. https://observatory.mozilla.org can be used to check your site's current headers. The headers are listed in order of importance, but please not that a proper secure Content Security Policy can be difficult to implement unless the application is designed from the beginning with this in mind. 
+
+Therefore, try to get some quick wins with headers such as HTTP Strict Transport Security, X-Frame-Options, X-XSS-Protection and X-Content-Type-Options first.
+
+For applications that only offer web APIs; check the recommendations under "API" at the bottom of the page.
+#### HTTP Strict Transport Security
+
+The strict transport security header tells browsers to load the website over encrypted connections only from now on. This helps avoid what is called SSL stripping attacks where an attacker who are in a Man-In-The-Middle position downgrades a user to an insecure connection.
+
+**Recommended initial setting:**
+
+    Strict-Transport-Security: max-age=86400 
+
+This tells the browser to remember using HTTPS for one day. _Note that you cannot switch back to HTTP for the duration of "max-age". It is wise to start with a lower value for testing and increase it once you are confident the application works as intended._
+
+Once confident that it's working you should aim for a max-age of minimum 6 months (max-age=15768000) but preferably 2 years (max-age=63072000). 
+
+**Recommended final setting:**
+    
+    Strict-Transport-Security: max-age=63072000
+
+#### Content-Security-Policy
+
+This header aims to reduce or even eliminate the impact of XSS attacks. It can be used to tell the browser where the website is supposed to load resources from.
+
+A nice tool for generating your policy and get an explanation for all the directives can be found here. Note that this site can also serve as a reporting endpoint to test the policy without enforcing it:
+
+https://report-uri.io/home/generate
+
+Quoted from Mozilla:
+
+>The primary benefit of CSP comes from disabling the use of unsafe inline JavaScript. Inline JavaScript -- either reflected or stored -- means that improperly escaped user-inputs can generate code that is interpreted by the web browser as JavaScript. By using CSP to disable inline JavaScript, you can effectively eliminate almost all XSS attacks against your site. 
+
+Take a look at this site for more info: https://csp.withgoogle.com/. 
+
+Google has found that most CSP utilising whitelisting does not prevent XSS because they are bypassable due to abusable endpoints on the whitelisted domains (such as google.com). Therefore the recommended approach is no longer whitelisting but use of hashes or nonces. This is a bit more tricky to implement as it requires that every `<script>` tag has an associated randomly generated nonce that is set in the CSP header in the server response. The same nonce must be set on every script tag through e.g. passing it to the template system. E.g:
+
+    <script src="https://www.example.com/script.js" nonce="{{ csp-nonce }}"></script>
+
+**Example of a recommended setting:**
+
+    Content-Security-Policy:
+    object-src 'none'; 
+    script-src 'nonce-{random}' 'unsafe-inline' 'unsafe-eval' 'strict-dynamic' https: http:;
+    base-uri 'none';
+    frame-ancestors 'none';
+
+ 
+
+**Report-only mode:**
+
+    Content-Security-Policy-Report-Only:
+    object-src 'none'; 
+    script-src 'nonce-{random}' 'unsafe-inline' 'unsafe-eval' 'strict-dynamic' https: http:;
+    base-uri 'none';
+    frame-ancestors 'none';
+    report-uri /csp-violation-report-endpoint/  
+
+ 
+
+Note that you would need a reporting endpoint to receive the CSP violation reports at <mydomain>/csp-violation-report-endpoint for this last example to work properly. 
+#### X-Frame-Options
+
+This header tells the browser if framing the website is allowed by other domains. By setting this header to a list of allowed domains or simply deny framing we can prevent Clickjacking attacks. Read more about clickjacking attacks here: https://www.owasp.org/index.php/Clickjacking
+
+**Recommended setting:**
+
+    X-Frame-Options: DENY
+
+    Content-Security-Policy: frame-ancestors 'none';
+
+X-Frame-Options is being replaced by the Content-Security Policy header's "frame-ancestors" attribute. This attribute is more flexible and should be added as well. 
+ 
+#### X-XSS-Protection
+
+X-XSS-Protection sets the configuration for the cross-site scripting filter built into most browsers. Read more about it here: https://scotthelme.co.uk/hardening-your-http-response-headers/#x-xss-protection
+
+**Recommended setting:**
+
+    X-XSS-Protection: 1; mode=block
+
+#### X-Content-Type-Options
+
+This header tells the browser not to guess the MIME type of the content served, but instead trust the “Content-Type” header. Without the X-Content-Type-Options header set, some older browsers can incorrectly detect files as scripts and stylesheets, potentially leading to XSS attacks.
+
+**Recommended setting:**
+
+    X-Content-Type-Options: nosniff
+
+
+#### Referrer-Policy
+
+The header basically controls what is being sent in the referer header. The security benefit from using this header is to avoid situations where session identifiers or other sensitive information which is transmitted in the URL is passed to other domains via the referer header. There are different options here which range from sending no referer header whatsoever to sending only the domain (origin). The best setting must be determined based on the application's use of the referer header. The recommended setting "origin" only sends the domain name and not the path part of the URL. It is also chosen because it is supported across largest body of browsers. 
+
+**Recommended setting:**
+
+    Referrer-Policy: origin
+
+We may also want to do "Referrer-Policy: strict-origin" to only send the referrer header to sites that are HTTPS to protect the user's privacy, but currently it's not supported on Edge and Safari. 
+#### API
+
+For APIs we want to ensure traffic is encrypted and restrict the potential impact of XSS vulnerabilities e.g. in error pages then they can't be used to run Javascript due to the Content-Security Policy not allowing scripts or iframes. Note that for APIs with documentation on the same domain such as  Swagger, this won't work and would need to be adapted.
+
+**Recommended settings:**1202
+
+    Content-Security-Policy: default-src 'none'; frame-ancestors 'none'
+    Strict-Transport-Security: max-age=31536000
+
+    X-Content-Type-Options: nosniff
+
+###### Resources:
+
+For more best practices and recommendations by Mozilla on Web Application Security see this link:
+
+https://developers.google.com/web/fundamentals/security/csp/
+
+https://wiki.mozilla.org/Security/Guidelines/Web_Security
+
+https://csp.withgoogle.com/
+
+https://www.w3.org/TR/referrer-policy/
+
+http://caniuse.com/#feat=referrer-policy
diff --git a/Coding Practice/Preventing-Common-Web-Attacks.md b/Coding Practice/Preventing-Common-Web-Attacks.md
new file mode 100644
index 0000000..7bc789d
--- /dev/null
+++ b/Coding Practice/Preventing-Common-Web-Attacks.md	
@@ -0,0 +1,263 @@
+# Preventing Common Web Attacks [Coding Practice]
+<font size="-1">_Brandon Caldwell - Dec. 2018_</font>
+
+## Overview
+
+This guideline covers how to prevent some common vulnerability classes that can be eradicated, such as:
+- [Clickjacking](#preventing-clickjacking)
+- [HTTPS Downgrade (HTTP Security Header)](#all-the-cool-kids-use-http-security-headers)
+- [Cross-Site Scripting (XSS)](#preventing-xss)
+- [SQL Injection](#preventing-sql-injection)
+- [Cross-Site Request Forgery (CSRF)](#preventing-cross-site-request-forgery)
+- [Credential leaks](#credential-leaks)
+
+By following the guidelines in this document your application will be more robust against these vulnerability classes and provide a solid foundation for developers to develop secure features for the application.
+
+## Recommendations
+### Preventing Clickjacking
+###### Description
+
+Clickjacking, also known as a "UI redress attack", occurs when an attacker uses a transparent or opaque iframe to trick a user into clicking on a button or link on another page when they were intending to click on the the top level page.
+###### Why We Care
+
+With this attack an attacker can trick the user into performing sensitive actions on a page that only the user has access to.
+###### Example of Issue
+
+Say that we have a “Pay out” button on our internal Ads Payout tool and the application does not implement any protection against Clickjacking. An attacker that knows the internal URL for the tool can now include a hidden iframe on his site www.cuteandfunnypuppies.com:
+
+<iframe src=”https://ads-payout-tool.hq.unity3d.com” style=”opacity:100”></iframe>
+
+When an admin that gets bored of approving payouts visits the attacker’s site to view some funny dog pictures, he simultaneously gets tricked into approving a payout for an attacker by clicking an element on the site that really clicks the payout button in the hidden iframe.
+###### How to Fix?
+
+Set the following HTTP response headers in your application:
+
+    X-Frame-Options: DENY
+
+    Content-Security-Policy: frame-ancestors 'self';
+###### Security Level
+
+This attack is usually a pretty low risk because most application don’t have that many single click sensitive actions and also because the attack has a social engineering component that requires the user to visit a site that the attacker controls. However, in the some cases the risk can be high if there is a button such as “Make user admin” in the application.
+References
+
+https://www.owasp.org/index.php/Clickjacking_Defense_Cheat_Sheet
+
+ 
+### All the cool kids use HTTP Security Headers
+###### Description
+
+Browser vendors are trying to help solve security issues that are common in web applications. However, they need to take backward compatibility into account because the Internet is full of old websites. Therefore, some of the new security features in browsers are opt-in, using HTTP Security headers which can be set by an application to enable these features. You should do this for all your applications to take full advantage of modern browser security.
+###### Why We Care
+
+Setting HTTP Security headers mostly protects your users by turning on security features in their browser when visiting Unity applications. We want to protect our customers so that they can safely browse our applications, even in “hostile environments” such as airports or cafés and this is a very cheap defense-in-depth security measure.  
+###### Example of Issue
+
+For example: Almost all web applications redirect from HTTP->HTTPS so that users don’t have to type https:// at the start of the url when they visit your site. However, if the user already had an active session on the site, the browser might send some sensitive information on that very first HTTP request before it gets redirected. This information can be sniffed by an attacker unless we take some precautions and tell it to always browse Unity applications over an encrypted connection. This is one example of an issue that HTTP Security headers can help with.
+How to Fix?
+
+We have a whole page dedicated to setting HTTP Security Headers which can be found here:
+
+https://confluence.hq.unity3d.com/display/SEC/HTTP+Header+Security
+
+Read through the recommendations, add your headers in the early phases of the project, and make sure to choose a modern front-end technology that is friendly to Content Security Policy.
+###### Security Level
+
+Adding security headers is basic security hygiene and you can see that large companies such as Facebook and Google are using these and organizations such as Mozilla require all their applications to implement them. 
+###### References
+
+Mozilla has a great web security guideline reference here which includes a lot about security headers:
+
+https://infosec.mozilla.org/guidelines/web_security
+
+Unity's Security Teams has a tool for checking how your application grades based on its security headers here:
+
+https://appcollector.internal.unity3d.com/observatory/
+### Preventing XSS
+###### Description
+
+XSS or Cross-Site Scripting is perhaps the most common web application vulnerability out there. The vulnerability allows an attacker to modify the front-end behaviour of your application by injecting Javascript or HTML into the application, altering the intended behaviour for malicious purposes.
+###### Why We Care
+
+XSS vulnerabilities can be serious as they can be used to steal sensitive information, such as credentials, session tokens or credit card data. It can be used to bypass firewalls and get access to internal networks e.g. the Unity office network because it allows an attacker’s code to run in the the victim’s browser which may very well be running on a computer in the office or that’s connected via VPN. It is also commonly used to attack browsers directly by injecting browser exploit code or, as have been seen lately, to steal computing power to mine cryptocurrency by injecting currency mining code into an innocent website.
+###### Example of Issue
+
+At Unity we have several applications that have suffered from XSS vulnerabilities and still do. We have over 150 security issues in Jira related to XSS. Typically the issue arise from an input field or URL parameter that is included in the page such as:
+
+https://www.application.unity.com/newuser?name=<script>alert(1)</script>
+
+If this parameter ends up being treated as HTML by the application an alert box would pop up to prove we can inject Javascript.
+
+Another example is data coming from the user that is stored in a database and later included in a webpage. E.g. an address, or a name, that the user enters.
+###### How to Fix?
+
+XSS prevention is a huge topic but the main takeaways are as follows:
+
+- Choose a front-end framework that support output encoding by default
+- Sanitize all input from users and other applications and reject unexpected input
+- Implement a Content Security Policy that disallows inline Javascript
+
+The first and best way to fix this is to use a front-end framework that output encodes / escapes data by default making it hard for any developer to make the mistake of not handling malicious input.
+
+The following front-end frameworks are good choices that will make it harder to introduce XSS vulnerabilities as they were designed with this in mind:
+
+    https://angular.io/guide/security#xss
+
+    https://reactjs.org/docs/introducing-jsx.html#jsx-prevents-injection-attacks
+
+There are more frameworks that have good default XSS prevention, but these two that are in use already at Unity and and they are supported and used by big companies such as Google and Facebook
+
+Secondly, make sure that your application sanitizes any data coming in. This needs to be done on the server for it to be effective. Data can come from many sources including but not limited to direct input by a user or data coming from another application. For example, if you expect a phone number to be entered, make sure that your program validates that only expected data such as numbers, dashes and maybe a + for country code is accepted by the application.
+
+There are libraries that can help with this such as Joi for NodeJS, Ruby on Rails have Active Record Validations and so on.
+
+Finally, we can implement a safeguard mechanism against XSS issues that all modern browsers support.Content Security Policy is effective in limiting the impact of XSS vulnerabilities should  they occur in your application even after you output encode data and sanitize input.
+
+By carefully designing a CSP we can tell the browser which scripts are allowed to run and which aren’t. We can limit where the application is allowed to load Javascript resources from, and we can disallow any inline Javascript. Malicious Javascript injected by exploiting an XSS vulnerability usually ends up being inline in the HTML document and not in an external .js file, so if we instruct the browser to not allow inline Javascript we can prevent a lot of the common XSS vulnerabilities.
+
+An example policy that only allows script files from the domain the application lives on would look like this:
+
+    Content-Security-Policy: "script-src 'self'"
+###### Security Level
+
+XSS vulnerabilities is very common and constitute a medium to high risk depending on context and application. It’s a vulnerability class that requires a lot of resources from the application security team to deal with, unless the application is well designed and we would very much like to extinguish this vulnerability class in Unity applications.
+References
+
+    https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet
+
+    https://csp.withgoogle.com/
+
+### Preventing SQL Injection
+###### Description
+
+SQL injection is an old vulnerability class which allows an attacker to alter an application’s SQL queries to perform other actions than those intended by the developer. The problem occurs due to a lack of separation between data and code, allowing the an attacker to input data to alter the logic of a query. SQL injection vulnerabilities are still found even in modern web applications leading to loss of data, authentication bypass and server compromise.
+
+Even applications that do not use traditional relational databases have been found to be vulnerable to SQL injection. If user input is used to build the database query, an attacker can potentially alter the query being made and bypass authentication, get unintended access to data or remote code execution.
+###### Why We Care
+
+Protecting data from attackers is paramount for any data-driven company, and protecting our web applications from SQL injection is a very important part of preventing data from being stolen. Many of the breaches that have been seen over the years have been caused by SQL injection in web applications leading either to full server compromise or access to all data in the database.
+###### Example of Issue
+
+We’ve found examples of SQL injection in both the old Asset Store and in Multiplay’s Gameforge. In both cases the vulnerability allowed us to access and extract all the content of the application’s database.
+###### How to Fix?
+###### _Relational Databases (MySQL, PostgreSQL, ...)_
+
+All SQL queries should be parameterized queries, the exact syntax varies based on technologystack used, but usually looks more or less like this:
+
+        E.g. SELECT * FROM users WHERE username = ‘?’, username
+
+Sanitize all input, but especially input that you intend to use in a SQL query.
+Limit the privileges of your database user. You should never run application SQL queries as the database admin or a root / admin user.
+
+Use an Object Relational Mapper (ORM) that helps you build queries securely and also eases the pain of writing raw SQL queries.
+ 
+###### _noSQL Databases (MongoDB, CouchDB, ...)_
+
+Almost the same principles apply for protecting applications against noSQL injection: 
+
+Sanitize user input that is used in queries. Check the type of the input (string, array, dict etc), and the expected format against a regex or a whitelist.
+Use a library to help you out such as Mongoose (similar to an ORM).
+Limit the privileges of your database user to the minimum.
+
+ 
+###### Security Level
+
+The severity of a SQL injection vulnerability ranges from high to critical depending on the application and context. For Unity, a SQL injection in Genesis would be an example of a critical vulnerability because it could lead to compromise of all user data.
+References
+
+https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet
+
+https://blog.websecurify.com/2014/08/hacking-nodejs-and-mongodb.html (Example noSQL attacks)
+
+ 
+### Preventing Cross-Site Request Forgery
+###### Description
+
+Cross-Site Request Forgery attacks allow an attacker to perform actions in an application in the context of an authenticated user. By abusing the way cookies work, if the application’s authentication is cookie-based (e.g. a session cookie is stored and sent with every request), an attacker can setup a website that makes requests to the application for instance via an iframe, an image or by automatically posting some form data and the browser will send along the cookies of the user.
+
+This attack is done across origins from website www.malicious.com to www.application.unity.com so the attacker won’t be able to read the response of the cross-origin request due to the Same-Origin Policy. However, this isn’t necessary for the attack to succeed if the application only requires a session cookie and don’t validate that the request initiated from the expected domain.
+
+The attack can happen in the background on a malicious website while the user browses funny cat pictures and suspects nothing. Exploitable actions can be anything the application allows, such as changing a password, changing shipping address, deleting a user, or anything else that might be used to an attacker’s benefit.
+###### Why We Care
+
+Cross-Site Request Forgery is a well-known attack vector today, but many prominent sites such as Gmail suffered from this 10 years ago. The attack is usually targeted towards a single user account, but if that user account is an administrator of the application the business consequences can be very serious.
+###### Example of Issue
+
+Our internal legacy system for doing deploys for the web team used to be vulnerable to Cross-Site Request Forgery. It made it possible for an attacker outside the Unity network to trigger deploys and even gain code execution on the server due to a combination of two flaws. The following HTML page shows how simple this CSRF attack was:
+
+If a logged in user visited this website it would create a file on the Online Deploy server by abusing the privileges of the user and a command injection flaw in the “t” parameter.
+###### How to Fix?
+
+There are several strategies to fixing this problem, and it depends a bit on the application’s architecture. Here are the main strategies that are most commonly used and accepted as a standard way of solving this problem:
+###### _Authentication via HTTP header_
+
+The Genesis API uses the “Authentication: Bearer xyzæøå” header for authentication. This header isn’t sent automatically and must be added using Javascript. Requests that require an authentication header to succeed are not vulnerable to CSRF attacks.
+###### _CSRF Tokens_
+
+This is the most common and accepted protection mechanism. It works by requiring every form submission and request that perform an action to include a random CSRF token in the submitted data. Since this token is set and stored by the server, and tied to a user’s session, an attacker won’t be able to access it or guess it. This prevents CSRF attacks from succeeding as the server should reject any request that don’t have a valid token.
+
+The first thing to make sure is that your application uses the HTTP GET and POST verbs appropriately, see http://guides.rubyonrails.org/security.html#csrf-countermeasures
+
+Next you should look at your web application framework to see if they have support for CSRF tokens. Most frameworks, like Ruby on Rails as mentioned above, will either have built-in support for easily adding CSRF tokens or libraries that help implement it. Here are two popular options for NodeJS and Golang:
+
+
+    https://github.com/expressjs/csurf
+
+    https://github.com/utrack/gin-csrf
+
+###### _Checking Origin / Referer headers_
+
+This is another method that can be used to prevent CSRF attacks. This method relies on checking the “Origin” header of a request to make sure it is coming from the origin on which the application is hosted and not a malicious domain. Only the browser is allowed to set the “Origin” header so it isn’t spoofable by a malicious application. It isn’t as bulletproof as using CSRF tokens because browsers don’t have to, but may, set the origin header, as specified in RFC-6454.
+
+It is common to combine this check with checking the “referer” header of the request. The “referer” header is also exclusively set by the browser, and contains the URL or domain that the request originated from. The application can check that this header is set to the correct domain to make sure that the request originated from a user session, and not from a malicious domain.
+###### _Samesite Cookies_
+
+This is the third mechanism for protecting against CSRF. It is a new browser feature that allows marking cookies with a flag controlling whether requests initiated from a third-party site will include the cookies.
+
+There are two modes: Strict and lax.
+
+Strict mode prevents the browser from sending the cookies cross-origin for any request. This can have negative consequences in situations where a logged-in user clicks a link leading back to an authenticated page in the application because the cookies won’t be sent along and the user needs to reauthenticate.
+
+Lax mode prevents this situation and allows GET requests to send along the cookies. Requests using any other HTTP verbs won’t send along the cookies. If the application uses HTTP verbs appropriately this would normally be enough to prevent CSRF attacks because the application shouldn’t use a GET request to perform any action in the application.
+
+    Set-Cookie: CookieName=CookieValue; SameSite=Lax;
+
+    Set-Cookie: CookieName=CookieValue; SameSite=Strict;
+
+Since this is a very new browser security feature, not all browsers support it yet and not all frameworks have APIs for setting cookies with this flag. Consider implementing it though, as it is simple, unobtrusive and effective way of preventing CSRF attacks and browser support is likely to increase in the future.
+Security Level
+
+The example above shows how serious CSRF vulnerabilities can be. The impact of a CSRF vulnerability can range from low to critical depending on the application. CSRF attacks are usually targeted and need to be tailored to a specific application, but there have also been CSRF vulnerabilities in commonly used libraries and frameworks that can be used by an attacker to target a multitude of sites at the same time.
+References
+
+    https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet
+
+    https://www.netsparker.com/blog/web-security/same-site-cookie-attribute-prevent-cross-site-request-forgery/
+
+ 
+### Credential Leaks
+###### Description
+
+Application development requires integration with a growing number of services. This requires developers to handle a number of secrets: Database credentials, api tokens, oauth secrets etc. These should be high-entropy, unique per service and per environment leading to large number of secrets to manage. These often end up being stored in configuration files which are then accidentally checking into your favorite version control system on a publicly accessible cloud-hosted repositories, and hence into the hands of attackers.
+###### Why We Care
+
+Secrets are secret for a reason and often provide access to a lot of data, computing resources or privileged accounts. It is therefore crucial that we handle secrets well, and make the probability of accidental leaks as small as possible.
+###### Example of Issue
+
+We’ve had many instances of Unity credentials leaked via public Git repos. This could have given malicious actors access to internal systems, data, apis and more. There have also been other examples such as accidentally hosting script files that contain credentials on a public web server.
+###### How to Fix?
+
+When developing an application it is best practice to load secrets from environment variables.
+
+This has a few benefits, first, it stores the credentials in the running process’ address space, this means that other user accounts on the machine that aren’t privileged, won’t be able to access the credentials.
+
+Secondly, it separates the secrets from your application normal configuration files which are often checked into version control systems. When developing the application, use a .env file for storing the secrets and load them into your environment before running the application locally.
+
+Finally, it prepares your application for using our secret management system, Vault, which allows you to store secrets in a central, secure place. If you are running your application in Infrastructure Engineerings’ infrastructure you could make use of Vault quite easily. If you want to read more about Vault and how to get started go here.
+
+The application security team have tools monitoring for secrets in source code repositories, but this mechanism is only supposed to be the last line of defense and to avoid credential leaks it is up to the developer to be diligent when handling these sensitive pieces of data.
+Security Level
+
+Leaking credentials can be critical as they often grant a high level of access to Unity systems and can lead to compromise of data and systems.
+References
+
+https://confluence.hq.unity3d.com/display/SEC/Secret-Finder
diff --git a/Coding Practice/Secrets-Management.md b/Coding Practice/Secrets-Management.md
new file mode 100644
index 0000000..b3a12e9
--- /dev/null
+++ b/Coding Practice/Secrets-Management.md	
@@ -0,0 +1,193 @@
+# DRAFT
+# Secrets Management (i.e., Storing Passwords Safely) [Coding Practice] 
+<font size="-1">Authors: Shawn Verzilli, Tim Herold - Apr. 2019</font>
+
+## Description
+
+Developing and deploying secure services and applications at Unity requires integration with a number of internal and external systems, such as authentication and cloud storage. Further, much of the software development at Unity requires integration with a growing number of services, requiring developers to handle several secrets, for example: database credentials, api tokens, oauth secrets etc.
+
+The secrets need to be high-entropy, unique per service, and unique per environment. In many cases this will lead to many secrets for a team to manage, and as such these secrets have frequently been stored checked in as part of configuration files - an insecure practice. Once saved into a configuration file, they are frequently, and accidentally, checked into your favorite version control system on a publicly accessible cloud-hosted repositories, and hence into the hands of attackers. These secrets cannot be stored in such a manner, and need to be kept in an access controlled environment.
+### Why We Care
+
+Secrets are secret for a reason, and often provide access to a lot of data, computing resources or privileged accounts. It is therefore crucial that we handle secrets well, ensure we limit their scope and use least privilege, and make the probability of accidental leaks as small as possible. (See Common Control Framework security controls CCF-4.04 and CCF-4.05)
+### Examples of Problematic/Incorrect Secrets Use
+
+We’ve had many instances of Unity credentials leaked via public Git repos. This could have given malicious actors access to internal systems, data, APIs and more. There have also been other examples such as accidentally hosting script files that contain credentials on a public web server.
+
+It should go without saying, but when your credentials fall into someone else’s hands they can assume any of your privileges. A common example we see is someone granting themselves “Admin” so they do not have to concern themselves with identifying precisely the minimum privileges needed. They may only use these credentials for a small handful of API calls but when these credentials are exposed, a malicious actor can do anything “Admin” can do. These credentials are often exploited for launching cryptominers, ransomware attacks, or setting up backdoors for later use.
+
+This is not limited to the example of “Admin” by any means. For example, compromising a user grants access to all groups the user may be a member of. These groups have the potential to span teams, projects, accounts, and more. This is commonly seen when a developer uses their own LDAP/Google credentials to test out a prototype of what their working on, only to later check-in that code to save their progress. It’s a bad habit to get into, despite the convenience it offers.
+**To summarize/TL;DR, @Unity, Security has seen secrets (in the clear) in:**
+- Raw HTML pages
+- Deployed Javascript
+- Public Githubs
+- Open AWS Buckets
+- Deployed binaries (secrets are not safe here!)
+- Deployed scripts
+- Forum posts
+
+The key take-away from all the above - you should NEVER type a secret anywhere but a secrets manager. Also, obfuscation (rot13, base64 encoding, etc.), is not a valid method of protecting secrets.
+### What are secrets and how to handle them?
+A Secret is anything that can be used to authenticate or authorize.
+
+- Username & Password
+- API Token
+- TLS Certificate
+
+A Secret is also anything confidential, sensitive, or Personally Identifiable Information (PII)
+
+- Credit Card
+- Social Security Number
+- Passport Number
+
+#### Guidance on proper handling of secrets
+
+To handle Secrets properly, we must consider the following:
+- How do applications (non-human) get secrets?
+- How do humans get secrets?
+- How are secrets updated?
+- How are secrets revoked?
+- When were the secrets used and by who?
+- What do we do in the event of a compromise?
+
+Common examples of secret usage are:
+- CI/CD Scripts
+- Cloud resource access from mobile/web app
+- Service account auth in backend
+- Private key encryption
+- Transport encryption (ex., HTTPS/TLS)
+![Secrets on Fire](./images/secrets%20fire.png)
+
+
+As a rule of thumb, you should use temporary credentials at every opportunity. Not all systems are built in a way that supports this and so using a secrets management tool like Hashicorp Vault or AWS Secrets Manager is strongly recommended. Environment variables are passable but not recommended. You should never store secrets in code.
+##### How to protect secrets
+
+After taking the steps above to prepare your application, leverage a secrets management infrastructure to safely store and access your secrets. Cloud options in Google Cloud KMS or Amazon AWS KMS. The Security Team currently doesn’t support the available cloud options, but have worked to build Unity’s internally maintained Vault system, currently maintained and supported by Infrastructure Engineering. Vault allows you to store secrets in a central, secure place. For details on using Vault for secrets management, see the APPENDIX in this document, or read more about Vault and how to get started go here. If you need support beyond the documentation, feel free to reach out to #ie-support-data-infra or #support-security on Slack. Note that Vault may not be a universal solution, so feel free to reach out early to be sure it’ll be a good solution for your product.
+
+The application security team have tools monitoring for secrets in source code repositories, but this mechanism is only supposed to be the last line of defense and to avoid credential leaks it is up to the developer to be diligent when handling these sensitive pieces of data.
+#### Secret Stores
+###### HashiCorp Vault:
+
+Vault supports a couple of options for secrets storage - Static and Dynamic. If possible, using Dynamic secrets would be the most ideal solution, but requires more work up front, with the trade-off of time saved by secrets that are automatically managed, such as creation and can be more simply revoked.
+###### Static Secrets
+
+These are your traditional secrets. Think Username, Password, and/or API Key. These can be stored via the Vault command-line tools, for example:
+
+    vault write secret/stg/ads/ads-performance-valuation/AWS_ACCESS_KEY_ID secret=AKIAIIIDEADBEEF35A3D
+
+_For more Vault guidance, see the linked guidance below, in the Appendix_
+
+###### Dynamic Secrets:
+
+Vault has a variety of Secrets Engines to hook into services like AWS, GCP, SSH, PKI, (and more) to provide temporary credentials which expire on a time-based lease procured by Vault. In the example of the AWS Secrets Engine, Vault acts as an abstraction to an AWS STS call and serves up the resultant Access/Secret Key pair.
+
+For details on dynamic secrets, see Hashicorp’s guidance: Dynamic Secrets
+Vault Support
+
+If you need support in using or troubleshooting Vault, visit Slack channels #ie-support-data-infra or #support-security.
+##### GCP
+
+The best practice for application authentication in Google Cloud is to use a Service Account. Rather than store the service account secret in the application source code, use an environment variable pointing to credentials outside of the application’s source code, such as Vault. Restrict who can act as service accounts. Users who are granted the Service Account Actor role for a service account can access all of the resources for which the service account has access.
+
+The Security team is still working to develop more complete guidance on managing GCP secrets; in the meantime, leverage Google’s own document: Understanding Service Accounts. As always, if further guidance is required, visit #support-security in Unity Slack.
+
+##### AWS Keys:
+
+AWS keys generally come in the following format:
+
+    AWS_ACCESS_KEY_ID:AKIA***********VTLCD
+
+    AWS_SECRET_ACCESS_KEY:SYU********************************TUVCrG
+
+
+These keys are generated by AWS IAM or AWS STS.
+
+Keys generated by IAM: these keys are assigned to an IAM User (max. 2 keys per user), which may be used by either an individual (human) or a service account (non-human). However, while these keys can be used for service accounts, it is best practice to leverage STS to generate temporary credentials wherever possible for non-human usage.
+
+Keys generated by STS: these keys are temporary and expire by default in 12 hours (min. 15mins, max. 36hrs). It is recommended to generate these keys with the minimum duration necessary. These keys are best practice as compromised keys quickly become useless to a malicious actor. STS also solves the problems presented by Creds in Source Code. Often times developers will use their personal Access Key/Secret Key pairs which can cause unexpected outages when someone leaves the company and their accounts are terminated; STS avoids this as well.
+
+    import boto3
+
+    `# Create a session with attached role`
+    session = boto3.Session()    
+
+    `# Create an sts client with the session`
+    sts = session.client("sts")    
+
+    `# Get temporary credentials for the current session`
+    temporary_creds = sts.get_session_token()['Credentials']
+
+
+
+The access granted to the keys is governed by an attached IAM Policy (min.1, max. 10). If leaked, the keys grant immediate global access to all resources allowed by the attached IAM Policy.
+
+For secure, maintainable key handling the following criteria must be adhered to:
+
+- Never use keys generated for an individual user; always use Temporary STS keys, attached IAM Roles, or a service account (non-human IAM User). This is to make sure access to resources isn’t compromised when e.g. an individual changes roles within or leaves the company
+- Ensure the policy is created on a least-privilege basis. For disparate use cases, it is better to create multiple service accounts with fewer privileges than share a single account with too many privileges.
+- Use STS Tokens when possible. If role assignment is available for any service you are using in AWS, you should be using IAM Roles and STS to acquire temporary credentials.
+
+##### Risk of Leaked Credentials
+
+Leaking credentials can be critical as they often grant a high level of access to Unity systems and can lead to compromise of data and systems. Credential leaks are historically a serious source of breaches throughout the industry, and require very little expertise from attackers to exploit. 
+
+######Risk Rating:
+High
+ 
+---
+
+##### Frequently Asked Questions - FAQ:
+The secrets are for my dev/staging/test/fantasy environment - do those still matter?
+
+Yes.
+
+In the vast majority of cases, the dev/staging environments are nearly identical to production environments (usually with just differences in network design), but sometimes the same systems. Further, some teams share environments, increasing the risk of lateral movement by attackers.
+
+Beyond the direct risks to infrastructure, the secrets themselves are now also stored on the servers where the code is hosted, as well as all the developer workstations of anyone whom as cloned or forked the code. The assumption should be the secrets are in the open, as there's limited to no way to track of they've been spread.
+
+And of course, as is common with personal passwords, we see a high incident of re-use; so chances are, your staging secrets are the same as your production secrets.
+What about my test code?
+
+Similar to the answer above, but this can be slightly more nuanced. If the test code is leveraging 'fake' credentials (as in, don't actually work anywhere) to test parsing code or error handling, then this is probably fine. If these credentials are used for testing against a local, or ephemeral mock instance, then this is probably fine as well. The concern is around 'permanent' test facilities that are also hosted along side the rest of our infrastructure - wherein the same problems exists as do those in dev/staging environments.
+References
+
+https://confluence.hq.unity3d.com/display/SEC/Secret-Finder
+
+https://github.com/yeyintminthuhtut/Awesome-Red-Teaming#-lateral-movement
+
+[Security Process] Risk Rating (aka., Security Bug Bar)
+
+Unity Security Bug Bar
+
+
+## APPENDIX
+Vault Guidance
+Vault Usage
+
+Vault for developers: https://confluence.hq.unity3d.com/display/IE/Using+Vault+in+IE+Infra 
+
+Vault for shared accounts (ex. DB admin): https://confluence.hq.unity3d.com/display/IE/Using+Vault+To+Authenticate+To+Databases 
+Vault Administration
+
+Vault software Overview - https://confluence.hq.unity3d.com/display/IE/Vault+Enterprise 
+
+Unsealing Vault - https://confluence.hq.unity3d.com/display/IE/Unseal+Vault
+
+Vault in GKE - https://confluence.hq.unity3d.com/display/IE/Initialise+Vault+Integration+in+a+GKE+Cluster 
+Vault Resources
+
+Usage Guides - https://github.com/hashicorp/vault-guides
+
+Dynamic Secrets - https://www.hashicorp.com/blog/why-we-need-dynamic-secrets
+
+Secrets Engine - https://www.vaultproject.io/docs/secrets/index.html
+AWS Resources
+
+Best Practices for Managing AWS Access Keys - https://docs.aws.amazon.com/general/latest/gr/aws-access-keys-best-practices.html
+
+Working with AWS Secrets Manager - https://docs.aws.amazon.com/secretsmanager/latest/userguide/integrating.html
+GCP Resources
+
+Understanding Service Accounts - https://cloud.google.com/iam/docs/understanding-service-accounts
+
+Using Environment Variables - https://cloud.google.com/functions/docs/env-var 
diff --git a/Coding Practice/Secure-Design-Principles.md b/Coding Practice/Secure-Design-Principles.md
new file mode 100644
index 0000000..343e645
--- /dev/null
+++ b/Coding Practice/Secure-Design-Principles.md	
@@ -0,0 +1,108 @@
+# Secure Design Principles [Coding Practice]
+<font size="-1">_Author: Carlo Valentin - Dec. 2018_</font>
+
+### Minimize attack surface area
+
+Every feature that is added to an application adds an unknown amount of risk to the overall application. The aim for secure development is to reduce the overall risk by reducing the attack surface, by designing features of an application to minimize the attack surface.
+
+Example: A web application implements online help with a search function. The search function may be vulnerable to SQL injection attacks. If the help feature was limited to authorized users, the attack likelihood is reduced. If the help feature’s search function was gated through centralized data validation routines, the ability to perform SQL injection is dramatically reduced. However, if the help feature was re-written to eliminate the search function (through better user interface, for example), this eliminates that attack surface, even if the help feature was available to the Internet at large.
+
+ 
+### Establish secure defaults
+
+There are many ways to deliver an “out of the box” experience for users. However, by default, the experience should be secure, and it should be up to the user to reduce their security.
+
+Example: By default, session timeouts are enabled. Users might be allowed to turn these feature (through a ‘Remember Me’ feature) off to simplify their use of the application and increase their risk.
+
+
+### Principle of Least Privilege
+
+The principle of least privilege recommends that accounts have the least amount of privilege required to perform their business processes. This encompasses user rights, resource permissions such as CPU limits, memory, network, and file system permissions.
+
+Example:  If a middleware server only requires access to the network, read access to a database table, and the ability to write to a log, this describes all the permissions that should be granted. Under no circumstances should the middleware be granted administrative privileges.
+
+
+### Principle of Defense in Depth
+
+The principle of defense in depth suggests that where one control would be reasonable, more controls that approach risks in different fashions are better. Controls, when used in depth, can make severe vulnerabilities increasingly difficult to exploit, and thus, unlikely to occur.
+
+With secure coding, this may take the form of tier-based validation, centralized auditing controls, and requiring users to be logged on all pages.
+
+Example: A flawed administrative interface is unlikely to be vulnerable to anonymous attack if it correctly gates access to production management networks, checks for administrative user authorization, and logs all access.
+
+
+### Fail securely
+
+Applications regularly fail to process transactions for many reasons. How they fail can determine if an application is secure or not. For example:
+
+Incorrect sample:
+
+    isAdmin = true;
+    try {
+    codeWhichMayFail();
+    isAdmin = isUserInRole( “Administrator” );
+    }
+    catch (Exception ex) {
+    log.write(ex.toString());
+    }
+
+ 
+
+Correct sample:
+
+    isAdmin = false;
+    try {
+    codeWhichMayFail();
+    isAdmin = isUserInRole( “Administrator” );
+    }
+    catch (Exception ex) {
+    log.write(ex.toString());
+    }
+
+If either codeWhichMayFail() or isUserInRole fails or throws an exception, the user is an admin by default. This is obviously a security risk.
+
+
+### Don’t trust services and validate externally sourced data
+
+Many organizations utilize the processing capabilities of third party partners, who more than likely have differing security policies and posture than you. It is unlikely that you can influence or control any external third party, whether they are home users or major suppliers or partners. Therefore, implicit trust of externally run systems is not warranted. All external systems should be treated in a similar fashion, and the data should be validated before processing.
+
+Example: A loyalty program provider provides data that is used by Internet Banking, providing the number of reward points and a small list of potential redemption items. However, the data should be checked to ensure that it is safe to display to end users, and that the reward points are a positive number, and not improbably large.
+
+
+### Separation of duties and role based access
+
+
+A key fraud control is separation of duties. This creates a system of “checks and balances” between integrated components of an application. Certain roles have different levels of trust than normal users. In particular, administrators are different to normal users. In general, administrators should not also be normal users of the application. Separation of responsibilities will also make it easier to limit the permission of each account, falling in line with the principle of least access.
+
+Example: An administrator should be able to turn the system on or off, set password policy but shouldn’t be able to log on to the storefront as a super privileged user, such as being able to “buy” goods on behalf of other users.
+
+
+### Avoid security by obscurity
+
+Security through obscurity is a weak security control, and nearly always fails when it is the only control. This is not to say that keeping secrets is a bad idea, it simply means that the security of key systems should not be reliant upon attempting to keep details hidden.
+
+Example: The security of an application should not rely upon knowledge of the source code being kept secret. The security should rely upon many other factors, including reasonable password policies, defense in depth, business transaction limits, solid network architecture, and fraud and audit controls.
+
+A practical example is Linux. Linux’s source code is widely available, and yet when properly secured, Linux is a secure and robust operating system.
+
+
+### Keep security simple
+
+Attack surface area and simplicity go hand in hand. Certain software engineering fads prefer overly complex approaches to what would otherwise be relatively straightforward and simple code.
+
+Developers should avoid the use of double negatives and complex architectures when a simpler approach would be faster and simpler.
+
+Example: Although it might be fashionable to have a slew of singleton entity beans running on a separate middleware server, it is more secure and faster to simply use global variables with an appropriate mutex mechanism to protect against race conditions.
+
+
+### Fix security issues correctly
+
+Once a security issue has been identified, it is important to develop a test for it, and to understand the root cause of the issue. When design patterns are used, it is likely that the security issue is widespread amongst all code bases, so developing the right fix without introducing regressions is essential.
+
+Example: A user has found that they can see another user’s balance by adjusting their cookie. The fix seems to be relatively straightforward, but as the cookie handling code is shared among all applications, a change to just one application will trickle through to all other applications. The fix must therefore be tested on all affected applications.
+
+ 
+---
+##### References
+
+https://www.owasp.org/index.php/Security_by_Design_Principles
diff --git a/Overview.md b/Overview.md
index 6b81aeb..afebb07 100644
--- a/Overview.md
+++ b/Overview.md
@@ -1,5 +1,5 @@
 # Secure Software Development Lifecycle SSDLC
-<font size="-2">Unity Security 2019</font>
+<font size="-2">Unity AppSec Team 2019</font>
 
 ### Software Development Lifecycle (SDLC)
 ![Software Development Lifecycle Diagram](images/sdlc%20process%20graphic.png "SDLC Diagram")
@@ -35,8 +35,8 @@ Also, be sure to keep an eye out for on-site trainings, which will be announced
 - [C#](unity.com)
 
 ##### Secure Coding Guidance
-- [API Best Practices](unity.com)
-- [Authentication/Authorization Best Practices](unity.com)
+- [API Best Practices](./Coding%20%Practice/API-Best-Practices.md)
+- [Authentication/Authorization Best Practices](./Coding%20%Practice/AuthZ-AuthN-Guidelines.md)
 - [Preventing Common Web Attacks](unity.com)
 
 ##### Security Automation and Tooling
diff --git a/images/secrets fire.png b/images/secrets fire.png
new file mode 100644
index 0000000000000000000000000000000000000000..4a955b6d9dce4eacc76566a37a9e94bfb57db308
GIT binary patch

From ac7f1d318a4fdf5722c28b235f57d30a5af85f71 Mon Sep 17 00:00:00 2001
From: Brandon Caldwell <brandonc@unity3d.com>
Date: Tue, 14 May 2019 09:30:23 -0700
Subject: [PATCH 07/54] Fixed typo in secrets management

---
 Coding Practice/Secrets-Management.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Coding Practice/Secrets-Management.md b/Coding Practice/Secrets-Management.md
index b3a12e9..bccbe41 100644
--- a/Coding Practice/Secrets-Management.md	
+++ b/Coding Practice/Secrets-Management.md	
@@ -56,7 +56,7 @@ Common examples of secret usage are:
 - Service account auth in backend
 - Private key encryption
 - Transport encryption (ex., HTTPS/TLS)
-![Secrets on Fire](./images/secrets%20fire.png)
+![Secrets on Fire](../images/secrets%20fire.png)
 
 
 As a rule of thumb, you should use temporary credentials at every opportunity. Not all systems are built in a way that supports this and so using a secrets management tool like Hashicorp Vault or AWS Secrets Manager is strongly recommended. Environment variables are passable but not recommended. You should never store secrets in code.

From 1789e6099110bd25ff9e2559f874b85a111f31a7 Mon Sep 17 00:00:00 2001
From: Brandon Caldwell <brandonc@unity3d.com>
Date: Tue, 14 May 2019 11:28:20 -0700
Subject: [PATCH 08/54] Almost done with 'Language Guidance' - just need .Net
 next.

---
 Language Guidance/Electron-Guidance.md | 391 +++++++++++++++++++++++++
 Language Guidance/Golang-Guidance.md   | 160 ++++++++++
 Language Guidance/Nodejs-Guidance.md   | 179 +++++++++++
 Language Guidance/Ruby-Guidance.md     | 329 +++++++++++++++++++++
 Overview.md                            |  15 +
 images/node-npm-audit-2.png            | Bin 0 -> 2729 bytes
 images/node-npm-audit.png              | Bin 0 -> 7206 bytes
 7 files changed, 1074 insertions(+)
 create mode 100644 Language Guidance/Electron-Guidance.md
 create mode 100644 Language Guidance/Golang-Guidance.md
 create mode 100644 Language Guidance/Nodejs-Guidance.md
 create mode 100644 Language Guidance/Ruby-Guidance.md
 create mode 100644 images/node-npm-audit-2.png
 create mode 100644 images/node-npm-audit.png

diff --git a/Language Guidance/Electron-Guidance.md b/Language Guidance/Electron-Guidance.md
new file mode 100644
index 0000000..a270e9d
--- /dev/null
+++ b/Language Guidance/Electron-Guidance.md	
@@ -0,0 +1,391 @@
+# Electron Guidelines [Language Guidance]
+<font size="-1">_Author: Andrew Luke - Dec. 2018_</font>
+
+### Overview 
+
+This is a set of security guidelines for developing Electron applications. Each element in this document will be Electron-specific. General web application and API guidelines will be covered here. This guideline is intended to be a living security reference for development teams and quality assurance as part of the Application Security Team’s Secure Software Development Life Cycle (SSDLC). As such, it will be continually added to and updated as the Application Security team is made aware of new security considerations or gaps in the current guidelines.
+
+Electron was created as a way to develop desktop applications with locally residing content, including HTML and Javascript. Its security model is based around this. As a result, security issues arise when you begin loading remote, untrusted content into your Electron application.
+
+Default Electron functionality exposes potentially dangerous functionality to renderers, which makes sense when they renderers are loading local files. For example, Chromium’s sandboxing has been removed. If untrusted content contains vulnerabilities, such as Cross-Site Scripting, is loaded into a renderer, it can result in code execution on the system. Most of the recommendations in this guideline will be focused on properly configuring and using Electron with untrusted content.   
+#### Security Considerations 
+
+By default:
+- Chromium’s sandboxing is disabled.
+- Preload scripts run on the same JavaScript runtime as the renderer.
+- NodeJS APIs are accessible within renderers.
+
+#### Resources
+
+###### Electron Security Page
+- https://electronjs.org/docs/tutorial/security
+
+###### Security Checklist
+- https://www.blackhat.com/docs/us-17/thursday/us-17-Carettoni-Electronegativity-A-Study-Of-Electron-Security.pdf
+- https://www.blackhat.com/docs/us-17/thursday/us-17-Carettoni-Electronegativity-A-Study-Of-Electron-Security-wp.pdf
+
+#### Security Checklist
+
+1. Disable nodeIntegration for untrusted origins
+2. Use sandbox for untrusted origins
+3. Review the use of command line arguments
+4. Review the use of preload scripts
+5. Do not use disablewebsecurity
+6. Do not allow insecure HTTP connections
+7. Do not use Chromium’s experimental features
+8. Limit navigation flows to untrusted origins
+9. Use setPermissionRequestHandler for untrusted origins
+10. Do not use insertCSS, executeJavaScript or eval with user-supplied content
+11. Do not allow popups in webview
+12. Review the use of custom protocol handlers
+13. Review the use of openExternal
+
+---
+#### Recommendations
+- [Disable NodeJS Integration for Remote Content](#disable-nodejs-integration-for-remote-content)
+- [Enable Context Isolation for Remote Content](#enable-context-isolation-for-remote-content)
+- [Handle Session Permission Requests From Remote Content](#handle-session-permission-requests-from-remote-content)
+- [Do Not Disable WebSecurity](#do-not-disable-websecurity)
+- [Define a Content Security Policy](#define-a-content-security-policy)
+- [Override and Disable eval() If Not Needed](#override-and-disable-eval-if-not-needed)
+- [Do Not Set allowRunningInsecureContent to true](#do-not-set-allowrunninginsecurecontent-to-true)
+- [Do Not Use allowpopups](#do-not-use-allowpopups)
+- [Verify WebView Options Before Creation](#verify-webview-options-before-creation)
+- [Disable or Limit Navigation](#disable-or-limit-navigation)
+- [Disable or Limit Creation of New Windows](#disable-or-limit-creation-of-new-windows)
+
+
+##### Disable NodeJS Integration for Remote Content
+###### Description
+
+It is paramount that you disable NodeJS integration in any renderer (BrowserWindow, BrowserView, or <webview>) that loads remote content. The goal is to limit the powers you grant to remote content, thus making it dramatically more difficult for an attacker to harm your users should they gain the ability to execute JavaScript on your website.
+
+After this, you can grant additional permissions for specific hosts. For example, if you are opening a BrowserWindow pointed at `my-website.com/", you can give that website exactly the abilities it needs, but no more.
+###### Why We Care
+
+A cross-site-scripting (XSS) attack is more dangerous if an attacker can jump out of the renderer process and execute code on the user's computer. Cross-site-scripting attacks are fairly common - and while an issue, their power is usually limited to messing with the website that they are executed on. Disabling Node.js integration helps prevent an XSS from being escalated into a so-called "Remote Code Execution" (RCE) attack.
+###### How to Fix?
+
+    // Bad
+    const mainWindow = new BrowserWindow()
+    mainWindow.loadURL('https://my-website.com')
+
+    // Good
+    const mainWindow = new BrowserWindow({
+        webPreferences: {
+        nodeIntegration: false,
+        preload: './preload.js'
+        }
+    })
+    mainWindow.loadURL('https://my-website.com')
+
+
+    <!-- Bad -->
+    <webview nodeIntegration src="page.html"></webview>  
+
+    <!-- Good -->
+    <webview src="page.html"></webview>
+
+ 
+
+When disabling Node.js integration, you can still expose APIs to your website that do consume Node.js modules or features. Preload scripts continue to have access to require and other Node.js features, allowing developers to expose a custom API to remotely loaded content.
+
+In the following example preload script, the later loaded website will have access to a window.readConfig() method, but no Node.js features.
+ 
+
+    const { readFileSync } = require('fs')  
+    window.readConfig = function () {
+        const data = readFileSync('./config.json')
+        return data
+    }
+
+ 
+###### Risk Rating
+
+High
+ 
+ ---
+##### Enable Context Isolation for Remote Content
+###### Description
+
+Context isolation is an Electron feature that allows developers to run code in preload scripts and in Electron APIs in a dedicated JavaScript context. In practice, that means that global objects like Array.prototype.push or JSON.parse cannot be modified by scripts running in the renderer process.
+
+Electron uses the same technology as Chromium's Content Scripts to enable this behavior.
+###### Why We Care
+
+Context isolation allows each the scripts on running in the renderer to make changes to its JavaScript environment without worrying about conflicting with the scripts in the Electron API or the preload script.
+
+While still an experimental Electron feature, context isolation adds an additional layer of security. It creates a new JavaScript world for Electron APIs and preload scripts.
+
+At the same time, preload scripts still have access to the document and window objects. In other words, you're getting a decent return on a likely very small investment.
+###### How to Fix?
+
+    // Main process
+    const mainWindow = new BrowserWindow({
+        webPreferences: {
+        contextIsolation: true,
+        preload: 'preload.js'
+        }
+    })
+
+ 
+###### Risk Rating
+
+Medium
+ 
+ ---
+##### Handle Session Permission Requests From Remote Content
+###### Description
+
+You may have seen permission requests while using Chrome: They pop up whenever the website attempts to use a feature that the user has to manually approve ( like notifications).
+
+The API is based on the Chromium permissions API and implements the same types of permissions.
+###### Why We Care
+
+By default, Electron will automatically approve all permission requests unless the developer has manually configured a custom handler. While a solid default, security-conscious developers might want to assume the very opposite.
+###### How to Fix?
+
+    const { session } = require('electron')
+
+    session
+    .fromPartition('some-partition')
+    .setPermissionRequestHandler((webContents, permission, callback) => {
+        const url = webContents.getURL()
+
+        if (permission === 'notifications') {
+        // Approves the permissions request
+        callback(true)
+        }
+
+        if (!url.startsWith('https://my-website.com')) {
+        // Denies the permissions request
+        return callback(false)
+        }
+    })
+
+ 
+###### Risk Rating
+
+Medium
+ 
+ ---
+##### Do Not Disable WebSecurity
+###### Description
+
+You may have already guessed that disabling the webSecurity property on a renderer process (BrowserWindow, BrowserView, or <webview>) disables crucial security features.
+
+Do not disable webSecurity in production applications
+###### Why We Care
+
+Disabling webSecurity will disable the same-origin policy and set allowRunningInsecureContent property to true. In other words, it allows the execution of insecure code from different domains.
+###### How to Fix?
+
+Electron defaults to webSecurity being enabled. We recommend leaving it enabled.
+###### Risk Rating
+
+High
+ 
+ ---
+##### Define a Content Security Policy
+###### Description
+
+A Content Security Policy (CSP) is an additional layer of protection against cross-site-scripting attacks and data injection attacks. We recommend that they be enabled by any website you load inside Electron.
+###### Why We Care
+
+CSP allows the server serving content to restrict and control the resources Electron can load for that given web page. https://your-page.com should be allowed to load scripts from the origins you defined while scripts from https://evil.attacker.com should not be allowed to run. Defining a CSP is an easy way to improve your application's security.
+
+The following CSP will allow Electron to execute scripts from the current website and from apis.mydomain.com.
+
+
+ 
+
+Content-Security-Policy: script-src 'self' https://apis.mydomain.com
+
+ 
+###### How to Fix?
+
+There are two options here. The first is to add a Content-Security-Policy meta tag to the HTML page being loaded:
+
+ 
+
+<meta http-equiv="Content-Security-Policy" content="default-src 'none'">
+
+ 
+
+The second option is to add the Content-Security-Policy header to any server HTTP response prior to processing:
+
+ 
+
+const {session} = require('electron')  
+  session.defaultSession.webRequest.onHeadersReceived((details, callback) => {
+    callback({responseHeaders: `default-src 'none'`})
+  })
+
+ 
+###### Risk Rating
+
+Medium
+ 
+ ---
+##### Override and Disable eval() If Not Needed
+###### Description
+
+eval() is a core JavaScript method that allows the execution of JavaScript from a string. Disabling it disables your app's ability to evaluate JavaScript that is not known in advance.
+Why We Care
+
+The eval() method has precisely one mission: To evaluate a series of characters as JavaScript and execute it. It is a required method whenever you need to evaluate code that is not known ahead of time. While legitimate use cases exist, like any other code generators, eval() is difficult to harden.
+
+Generally speaking, it is easier to completely disable eval() than to make it bulletproof. Thus, if you do not need it, it is a good idea to disable it.
+###### How to Fix?
+
+ 
+
+// ESLint will warn about any use of eval(), even this one
+// eslint-disable-next-line
+window.eval = global.eval = function () {
+  throw new Error(`Sorry, this app does not support window.eval().`)
+}
+
+ 
+###### Risk Rating
+
+Low
+ 
+ ---
+##### Do Not Set allowRunningInsecureContent to true
+###### Description
+
+By default, Electron will not allow websites loaded over HTTPS to load and execute scripts, CSS, or plugins from insecure sources (HTTP). Setting the property allowRunningInsecureContent to true disables that protection.
+
+Loading the initial HTML of a website over HTTPS and attempting to load subsequent resources via HTTP is also known as "mixed content".
+###### Why We Care
+
+Loading content over HTTPS assures the authenticity and integrity of the loaded resources while encrypting the traffic itself.
+###### How to Fix?
+
+ 
+
+// Bad
+  const mainWindow = new BrowserWindow({
+    webPreferences: {
+      allowRunningInsecureContent: true
+    }
+  })
+
+ 
+###### Risk Rating
+
+Medium
+ 
+ ---
+##### Do Not Use allowpopups
+###### Description
+
+If you are using <webview>, you might need the pages and scripts loaded in your <webview> tag to open new windows. The allowpopups attribute enables them to create new BrowserWindows using the window.open() method. <webview> tags are otherwise not allowed to create new windows.
+Why We Care
+
+If you do not need popups, you are better off not allowing the creation of new BrowserWindows by default. This follows the principle of minimally required access: Don't let a website create new popups unless you know it needs that feature.
+###### How to Fix?
+
+ 
+
+<!-- Bad -->
+  <webview allowpopups src="page.html"></webview>
+
+<!-- Good -->
+  <webview src="page.html"></webview>
+
+ 
+###### Risk Rating
+
+Medium
+
+---
+##### Verify WebView Options Before Creation
+###### Description
+
+A WebView created in a renderer process that does not have Node.js integration enabled will not be able to enable integration itself. However, a WebView will always create an independent renderer process with its own webPreferences.
+
+It is a good idea to control the creation of new <webview> tags from the main process and to verify that their webPreferences do not disable security features.
+###### Why We Care
+
+Since <webview> live in the DOM, they can be created by a script running on your website even if Node.js integration is otherwise disabled.
+
+Electron enables developers to disable various security features that control a renderer process. In most cases, developers do not need to disable any of those features - and you should therefore not allow different configurations for newly created <webview> tags.
+###### How to Fix?
+
+Before a <webview> tag is attached, Electron will fire the will-attach-webview event on the hosting webContents. Use the event to prevent the creation of webViews with possibly insecure options.
+
+ 
+
+app.on('web-contents-created', (event, contents) => {
+    contents.on('will-attach-webview', (event, webPreferences, params) => {
+      // Strip away preload scripts if unused or verify their location is legitimate
+      delete webPreferences.preload
+      delete webPreferences.preloadURL
+  
+      // Disable Node.js integration
+      webPreferences.nodeIntegration = false
+  
+      // Verify URL being loaded
+      if (!params.src.startsWith('https://yourapp.com/')) {
+        event.preventDefault()
+      }
+    })
+  })
+
+ 
+
+Again, this list merely minimizes the risk, it does not remove it. If your goal is to display a website, a browser will be a more secure option.
+###### Risk Rating
+
+Medium
+
+---
+
+##### Disable or Limit Navigation
+###### Description
+
+If your app has no need to navigate or only needs to navigate to known pages, it is a good idea to limit navigation outright to that known scope, disallowing any other kinds of navigation.
+###### Why We Care
+
+Navigation is a common attack vector. If an attacker can convince your app to navigate away from its current page, they can possibly force your app to open web sites on the Internet. Even if your webContents are configured to be more secure (like having nodeIntegration disabled or contextIsolation enabled), getting your app to open a random web site will make the work of exploiting your app a lot easier.
+
+A common attack pattern is that the attacker convinces your app's users to interact with the app in such a way that it navigates to one of the attacker's pages. This is usually done via links, plugins, or other user-generated content.
+###### How to Fix?
+
+If your app has no need for navigation, you can call event.preventDefault() in a will-navigate handler. If you know which pages your app might navigate to, check the URL in the event handler and only let navigation occur if it matches the URLs you're expecting.
+
+We recommend that you use Node's parser for URLs. Simple string comparisons can sometimes be fooled - a startsWith('https://google.com') test would let https://google.com.attacker.com through.
+
+ 
+
+const URL = require('url').URL  
+
+  app.on('web-contents-created', (event, contents) => {
+    contents.on('will-navigate', (event, navigationUrl) => {
+      const parsedUrl = new URL(navigationUrl)
+
+      if (parsedUrl.origin !== 'https://my-own-server.com') {
+        event.preventDefault()
+      }
+    })
+  })
+
+ 
+###### Risk Rating
+
+Medium
+
+---
+##### Disable or Limit Creation of New Windows
+###### Description
+
+If you have a known set of windows, it's a good idea to limit the creation of additional windows in your app.
+###### Why We Care
+
+Much like navigation, the creation of new webContents is a common attack vector. Attackers attempt to convince your app to create new windows, frames, or other renderer processes with more privileges than they had before; or with pages opened that they couldn't open before.
+
+If you have no need to create windows in addition to the ones you know you'll need to create, disabling the creation buys you a little bit of extra security at no cost. This is commonly the case for apps that open one BrowserWindow and do not need to open an arbitrary number of additional windows at runtime.
+###### Risk Rating
+High
\ No newline at end of file
diff --git a/Language Guidance/Golang-Guidance.md b/Language Guidance/Golang-Guidance.md
new file mode 100644
index 0000000..a97b950
--- /dev/null
+++ b/Language Guidance/Golang-Guidance.md	
@@ -0,0 +1,160 @@
+# Golang Security Guidelines [Language Guidance]
+<font size="-1">_Author: Andrew Luke - Dec. 2018_</font>
+
+## Overview
+
+
+This is a set of security guidelines for the Golang programming language. Each element in this document will be Ruby-specific. General web application and API guidelines will be covered here. This guideline is intended to be a living security reference for development teams and quality assurance as part of the Application Security Team’s Secure Software Development Lifecycle (SSDLC). As such, it will be continually added to and updated as the Application Security team is made aware of new security considerations or gaps in the current guidelines.
+
+Golang is a strongly typed language that has taken steps to prevent security issues found in other languages. For example, there is no pointer arithmetic. Garbage collection is automatic. Another example, the standard crypto package for AES does not provide Cipher Block Chaining (CBC) as an option.
+
+
+##### Security Considerations
+
+The net/http multiplexer ServeMux takes care of sanitizing the URL request path, redirecting any request containing “.” or “..” elements or repeated slashes to an equivalent, cleaner URL
+
+##### Recommended Packages
+
+
+- Bcrypt for password hashing: https://godoc.org/golang.org/x/crypto/bcrypt
+- AES for symmetric encryption:
+  -    https://golang.org/pkg/crypto/aes/
+  -    https://golang.org/src/crypto/cipher/example_test.go
+- CSRF Protection: https://github.com/gorilla/csrf
+- Validator for input validation: https://github.com/go-playground/validator
+- Output Sanitization:
+  -    https://golang.org/pkg/html/template/
+  -    https://github.com/kennygrant/sanitize
+  -    https://github.com/microcosm-cc/bluemonday
+- Pseudo-random number generation: https://golang.org/pkg/crypto/rand/
+- Safe SQL Queries:
+  -    https://golang.org/pkg/database/sql/#DB.Prepare
+  -    https://github.com/jinzhu/gorm
+
+##### Resources
+- Checkmarx Web Application Secure Coding Practices: https://checkmarx.gitbooks.io/go-scp/
+
+### Recommendations
+- [Output Encoding with Native Templates](#output-encoding-with-native-templates)
+- [Beware Output Encoding Bypasses](#beware-output-encoding-bypasses)
+- [Go Security Protections Don’t Extend To C Code](#go-security-protections-dont-extend-to-c-code)
+- [Use crypto/rand Instead Of math/rand](#use-cryptorand-instead-of-mathrand)
+
+
+#### Output Encoding with Native Templates
+###### Description
+
+The net/http Package does not provide any type of output encoding. The html/template package implements data-driven templates for generating HTML output safe against code injection. It provides the same interface as package text/template and should be used instead of text/template whenever the output is HTML. This package wraps package text/template so you can share its template API to parse and execute HTML templates safely. This package understands HTML, CSS, JavaScript, and URIs. It adds sanitizing functions to each simple action pipeline.
+###### Why We Care
+
+Using the net/http package exposes web application users to cross-site scripting attacks due to its lack of output encoding.
+###### How to Fix?
+
+Use the html/template package to automatically escape HTML, CSS, JavaScript, and URIs. If the net/http package is used, use manual escaping and manually set the Content-Type, because it is set automatically depending on what is served.
+###### Risk Rating
+
+High
+References
+
+https://golang.org/pkg/html/template/
+ 
+#### Beware Output Encoding Bypasses
+###### Description
+
+The html/template package provides a way to circumvent the escaping pipeline, using template. `[HTML|JS|URL]()`method set a string to its type. 
+###### Why We Care
+
+Placing user into into this declaration function will bypass default output encoding, introduce cross-site scripting and HTML injection vulnerabilities into your web application.
+_Example of Issue_:
+
+The following will declare the `<b>World</b>` string as HTML, printing it as-is into the HTML:
+
+     tmpl.Execute(out, template.HTML(`<b>World</b>`))
+
+ 
+###### How to Fix?
+
+The EscapeString() function in the native html package accepts a string and returns the same string with the special characters escaped. (i.e. < becomes &lt;). The html/template package has a stripTags() function, but it's unexported.
+
+The html/template package provides several functions for escaping strings:
+
+    HTMLEscape()
+    HTMLEscapeString()
+    HTMLEscaper()
+    JSEscape()
+    JSEscapeString()
+    JSEscaper()
+    URLQueryEscaper
+
+Avoid using template Typed Strings on user input.
+###### Risk Rating
+
+High
+###### References
+
+- https://golang.org/pkg/html/template/
+- https://github.com/kennygrant/sanitize
+- https://github.com/microcosm-cc/bluemonday
+
+#### Go Security Protections Don’t Extend To C Code
+###### Description
+
+The cmd/cgo package provides a way to call C code within a Go application. Go was created with many security protections in place, like memory safety and strong typing. These protections do not extend to the C code called with this package.
+###### Why We Care
+
+By using cmd/cgo, you introduce all of the C code security considerations and concerns into your Go application.
+###### How to Fix?
+
+Be aware that C code security concerns are still present when ran by a Go application. Understand the inherent security issues with various C code functionality used, and develop the C code ran by your Go application in a secure manner.
+###### Risk Rating
+
+High
+###### References
+
+https://golang.org/cmd/cgo/ 
+
+#### Use crypto/rand Instead Of math/rand
+###### Description
+
+The math/rand package is a deterministic, pseudo-random number generator. It takes a seed and generates pseudo-random numbers with it. Because it is deterministic, these values will be the same each time the application is ran, allowing an attacker to predict the values.
+###### Why We Care
+
+Anyone with knowledge of the math/rand seed can determine the pseudo-random values used by the application.
+###### How to Fix?
+
+The crypto/rand package should be used instead of the math/rand package. This package uses operating system randomness to generate pseudo-random numbers. Due to this, the generated values are not deterministic and a seed is not needed.
+
+_Example:_
+
+This example reads 10 cryptographically secure pseudorandom numbers from rand.Reader and writes them to a byte slice:
+
+    package main
+
+    import (
+    "bytes"
+    "crypto/rand"
+    "fmt"
+    )
+
+    func main() {
+        c := 10
+        b := make([]byte, c)
+        _, err := rand.Read(b)
+        if err != nil {
+        fmt.Println("error:", err)
+        return
+    }
+
+    // The slice should now contain random bytes instead of only zeroes.
+    fmt.Println(bytes.Equal(b, make([]byte, c)))
+    }
+
+ 
+###### Risk Rating
+
+High
+###### References
+
+https://golang.org/pkg/crypto/rand/
+
+https://golang.org/pkg/crypto/rand/#example_Read
\ No newline at end of file
diff --git a/Language Guidance/Nodejs-Guidance.md b/Language Guidance/Nodejs-Guidance.md
new file mode 100644
index 0000000..2536181
--- /dev/null
+++ b/Language Guidance/Nodejs-Guidance.md	
@@ -0,0 +1,179 @@
+# Node.js Secure Development [Language Guidance]
+<font size="-1">_Author: Brandon Caldwell - Dec. 2018_</font>
+
+### Overview
+
+
+This guide will provide general guidance for developing more secure code in Node.js.
+
+### Recommendations
+##### Always Validate External Inputs
+###### Why We Care
+
+Generally the most dangerous part of any software is the point where it will process untrusted external data. As such, it is one of the most important areas to ensure attention is given.
+###### Example of Issue
+
+    function buildList (var untrustedListSize){
+        if ( 0 > untrustedListSize ){
+            new Error("Negative value supplied for list size, die evil hacker!");
+        }
+
+        var list = new Widget [ untrustedListSize ];
+        list[0] = new Widget();
+    }
+<sub>_(Adapted from: https://cwe.mitre.org/data/definitions/20.html)_</sub>
+
+###### How to Fix?
+
+There are several validation libraries. The AppSec team hasn’t investigated and compared validation packages out there, though express-validator.js seems like a popular option among the Node.js community.
+
+Mozilla has a decent article covering some basic of using that pacakge: https://developer.mozilla.org/en-US/docs/Learn/Server-side/Express_Nodejs/forms  
+###### Risk Rating
+
+While lack of validation can present a significant risk, it requires the underlying area of code to be vulnerable to exploitation, as such, this is considered a Low severity issue.
+
+Though if the underlying code is vulnerable, this will lead to High sev vulnerabilities.
+###### References
+
+MITRE Guidance - https://cwe.mitre.org/data/definitions/20.html  
+
+OWASP Guidance - https://www.owasp.org/index.php/Data_Validation  
+#### HTTP Headers
+###### Why We Care
+
+HTTP headers can allow a page developer to inform the browser to apply various protections against web attacks, such as Clickjacking and XSS.
+Example of Issue
+
+X-Frame-Options - Protect from clickjacking
+
+Strict-Transport-Security - Enforce HTTPS and protect against downgrade attacks
+
+X-XSS-Protection - Enable XSS protections in browsers that support this header
+
+Content-Security-Policy - Can restrict code script comes from and can be executed
+###### How to Fix?
+
+Manually review and employ headers as appropriate for your HTTP connections. OWASP has nice list of relevant headers as part of their Secure Headers Project .
+
+
+Further, the Helmet package (available via npm as well) is a frequently recommended library to help provide these protection.
+###### Risk Rating
+
+Low-High
+###### References
+
+https://www.owasp.org/index.php/OWASP_Secure_Headers_Project#tab=Main  
+
+Helmet - https://www.npmjs.com/package/helmet  
+
+
+#### Use of eval()
+###### Why We Care
+
+Use of the eval() function is incredibly dangerous, and rarely actually needed. The function allows an attacker to simply and directly execute code on the target site.
+###### Example of Issue
+
+eval(< anything in here> ) :D
+###### How to Fix?
+
+Generally, it's completely unsafe to execute untrusted code, and as such, should be avoid entirely. Any case of such use to be considered very seriously; if it's determined to be requisite, consider using the native VM module, which exposes Node.js' V8 engine for safer code execution
+###### Risk Rating
+
+Low - High
+###### References
+
+https://developer.mozilla.org/en-US/docs/Archive/Add-ons/Overlay_Extensions/XUL_School/Appendix_C:_Avoid_using_eval_in_Add-ons   (Talks about use in add-ons, but applies elsewhere as well)
+
+Node.js VM - https://nodejs.org/api/vm.html
+
+
+#### Always Use HTTPS (>TLS1.0)
+###### Why We Care
+
+HTTP traffic is unencrypted, meaning that any traffic that goes across untrusted/uncontrolled channels is completely untrustworthy. Further, on modern computers, the perf hit for HTTPS with effectively negligible given the increase in trust gained from an encrypted channel.
+###### How to Fix?
+
+Always enable TLS :)
+
+Node’s native TLS library - https://nodejs.org/api/tls.html
+
+Nginx TLS - https://wiki.mozilla.org/Security/Server_Side_TLS#Recommended_Server_Configurations  
+###### Risk Rating
+
+Med
+References
+
+https://www.eff.org/https-everywhere
+
+https://www.maxcdn.com/blog/ssl-performance-myth/  
+
+
+#### Localhost isn’t inherently safe from the web
+###### Why We Care
+
+We’ve found that many teams have engineered interfaces hosting local client REST services mistakenly believing that binding to localhost proved protection from remote attackers. However, localhost can be reached from a web browser, leaving these services vulnerable to attack from malicious web pages.
+###### Example of Issue
+
+See UNITY-SEC-844 @ https://unity3d.com/security#issues
+
+This vulnerability was a remote code execution vulnerability found in the Unity Editor wherein, if a malicious website was opened by a user, the attacker could run arbitrary code on the victim’s machine, via a REST service bound to localhost , running in the Editor.
+###### How to Fix?
+
+Enable CORS in your project. Here’s an example value:
+
+Access-Control-Allow-Origin: https://localhost:<port>
+###### Risk Rating
+
+Medium
+
+
+###### References
+
+Express has a popular CORS library: https://github.com/expressjs/cors  
+### NPM Package Tools and Risks
+#### npm audit
+
+Not a risk in itself, but the audit option of npm is a recently added feature to automatically scan installed packages for you project, with severity ratings and links to the details on the scanned risks. It’s recommended that this is run regularly against all projects, to help identify vulnerabilities that may exist in dependencies.
+###### Why We Care
+
+Packages are 3rd party code, that we often use without fully auditing. Until Unity has the resource to provide better auditing of packages, this is a great tool available for us to use.
+###### Example of Issue
+
+Here’s an example output:
+![NPM Audit Output](../images/node-npm-audit.png)
+
+###### How to Fix?
+
+The audit option already provides simple ‘auto-fix’ functionality, and will help you out, such as:
+![NPM Audit Command](../images/node-npm-audit-2.png)
+
+Further, npmjs released the npm audit fix option that should automatically address as many vulnerabilities as possible.
+###### Risk Rating
+
+The tool will provide the risk rating for each vulnerability found.
+
+###### References
+[npm audit](https://blog.npmjs.org/post/173719309445/npm-audit-identify-and-fix-insecure)
+[npm audit fix](https://blog.npmjs.org/post/174001864165/v610-next0)
+
+#### Outdated Packages
+As with all 3rd party source code, be sure to use the latest available version of the package.
+###### Why We Care
+
+Vulnerabilities in packages are identified every day, and are usually as easy to fix as just updating the package.
+###### Example of Issue
+
+Express, a widely used HTTP package,  published their vulnerabilities here: https://expressjs.com/en/advanced/security-updates.html  
+###### How to Fix?
+
+Use npm update,  or leverage the npm audit command described in this document.
+###### Risk Rating
+
+The Risk Rating of the vulnerability is identified by the vendor reporting the issue.
+
+
+###Additional Reading
+- Fun read with real world Node.js security issues: https://www.owasp.org/images/f/fa/AppSecIL2016_NodeJS-Security_LiranTal.pdf
+- Security recommendations from the Express team: https://expressjs.com/en/advanced/best-practice-security.html  
+- OWASP’s Node Goat Project: https://github.com/OWASP/NodeGoat  
+
diff --git a/Language Guidance/Ruby-Guidance.md b/Language Guidance/Ruby-Guidance.md
new file mode 100644
index 0000000..8d62944
--- /dev/null
+++ b/Language Guidance/Ruby-Guidance.md	
@@ -0,0 +1,329 @@
+# Ruby Security Guidelines [Language Guidance]
+
+<font size="-1">_Author: Andrew Luke Dec. 2018_</font
+
+- [Avoid Combing User Input with Dangerous Calls](#)
+- [Use Proper REGEX Start and End of String Symbols](#)
+- [Ensure Dynamic Content is Encoded](#)
+- [Exploitation of Mass Assignment (Versions 2.3.x and 3.x)](#)
+- [Enforce HTTPS and Strict Transport Security](#)
+- [Prevent Logging of Sensitive Information](#)
+- [Avoid Disabling deep_munge](#)
+- [Store the Rails Master Key in an Environmental Variable](#)
+- [Don’t Allow User Input Determine Which View to Render](#)
+- [Session Fixation](#)
+
+
+
+### Overview
+
+This is a set of security guidelines for the Ruby programming language, with emphasis on the Ruby on Rails web application framework. Each element in this document will be Ruby-specific. General web application and API guidelines will be covered here. This guideline is intended to be a living security reference for development teams and quality assurance as part of the Application Security Team’s Secure Software Development Lifecycle (SSDLC). As such, it will be continually added to and updated as the Application Security team is made aware of new security considerations or gaps in the current guidelines. In general, this guide is geared towards the most recent version of Ruby and Ruby on Rails. Any exceptions will be identified as to the versions they apply to.
+### Security Considerations
+#### Mailing Lists
+
+To be made aware of security issues as they occur, subscribe to the Ruby and Ruby on Rails mailing lists:
+
+- https://groups.google.com/forum/#!forum/ruby-security-ann
+- https://groups.google.com/forum/#!forum/rubyonrails-security
+
+#### Cross-Site Request Forgery (CSRF)
+
+By default, Rails includes an unobtrusive scripting adapter (https://github.com/rails/rails/tree/master/actionview/app/assets/javascripts), which adds a header called X-CSRF-Token with the security token on every non-GET Ajax call. Without this header, non-GET Ajax requests won't be accepted by Rails. When using another library to make Ajax calls, it is necessary to add the security token as a default header for Ajax calls in your library. To get the token, have a look at <meta name='csrf-token' content='THE-TOKEN'> tag printed by <%= csrf_meta_tags %> in your application view.
+#### Weak Gem Signing
+
+Ruby gems have a signing mechanism in place, but it is not required - or widely used - and lacks a chain of trust for the signing keys. As a result, care should be taken when using third party libraries
+### Recommended Libraries
+
+- Terrapin for system commands: https://github.com/thoughtbot/terrapin
+- Strong_parameters to prevent mass assignment issues in 3.x: https://github.com/rails/strong_parameters
+- Strong_parameters_rails2 to prevent mass assignment issues in 2.3.x: https://github.com/grosser/strong_parameters/tree/rails2
+
+### Resources
+
+- http://guides.rubyonrails.org/security.html
+- http://guides.rubyonrails.org/v3.2.8/security.html
+- https://www.owasp.org/index.php/Ruby_on_Rails_Cheatsheet
+
+### Recommendations
+#### Avoid Combing User Input with Dangerous Calls
+###### Description
+
+Ruby on Rails supports a number of dangerous calls that introduce a lot of potential for vulnerabilities.
+
+    - Eval("ruby code here")
+    - Instance_eval()
+    - Class_eval()
+    - Kernel.exec("os command here")
+    - System("os command here")
+    - Popen
+    - open("| os command here")
+    - DRb.start_server()
+    - `ls -al`  (backticks contain system commands)
+    - Find_by_sql()
+    - %x()
+    - send()
+    - __send__()
+    - public_send()
+    - try()
+    - render()
+
+###### Why We Care
+
+Combining these calls with user input could result in server compromise.
+###### How to fix?
+
+It is best practice to avoid using unfiltered user input to form a system or Ruby command with one of the dangerous calls above. If user input is needed to inform the command, there are a couple of things you can do to minimize exposure. Comparing the user input to a whitelist of expected values before passing it to the command execution functionality is an effective way to validate the input.
+
+For executing system commands using user input, using a tool like Terrapin is preferable over the dangerous calls above. With Terrapin, user input can be safely shell-escaped. Terrapin will only shell-escape what is passed in as interpolations to the run() method. It WILL NOT escape what is passed in to the second argument of new. Terrapin assumes that you will not be manually passing user-generated data to that argument and will be using it as a template for your command line's structure.
+###### Risk Rating
+
+High
+###### References
+
+https://github.com/thoughtbot/terrapin
+
+#### Use Proper REGEX Start and End of String Symbols
+###### Description
+
+Ruby uses a slightly different approach than many other languages to match the end and the beginning of a string. In Ruby `^` and `$` match the line beginning and line end, not the string beginning and string end. The `\A` and `\z` should be used instead of `^` and `$.`
+###### Why We Care
+
+When using REGEX to validate user input, misuse of these symbols can introduce the potential for bypasses that get malicious input past the REGEX validation.
+###### Example of Issue
+
+The following REGEX filter is meant to accept only valid URLs
+
+    /^https?:\/\/[^\n]+$/i
+
+
+Due to the ^ symbol use instead the \A symbol, the following submission would pass the filter because each line is processed separately and the second line matches:
+
+ 
+
+javascript:exploit_code();/*
+
+http://hi.com
+
+*/
+
+ 
+###### How to fix?
+
+To fix this, the example issue should use the following REGEX:
+
+ 
+
+/\Ahttps?:\/\/[^\n]+\z/i
+
+ 
+###### Risk Rating
+
+High
+###### References
+
+http://guides.rubyonrails.org/security.html#regular-expressions
+
+ 
+#### Ensure Dynamic Content is Encoded
+###### Description
+
+By default, Rails 3.0 and up protects against cross-site scripting (XSS) through the output encoding of data placed into views. However, there are several ways in Ruby on Rails for developers to bypass the default XSS protections. These are the dangerous template tags which bypass default output encoding:
+
+    <%= raw @product.name %>
+
+    <%= @product.name.html_safe %>
+
+    <%= content_tag @product.name %>
+
+    <%= link_to “Personal Website”, @user.website %>
+
+        Here, the @user.website value could begin with javascript: tag, executing any JavaScript payload that follows it.
+
+###### Why We Care
+
+XSS can be used to perform any action the authenticated user has access, including other Unity services if authentication is handled through Genesis.
+###### How to fix?
+
+These methods of printing raw HTML to the page should only be used for trusting, non-user generated content that doesn’t include user input. If users are able to influence the data used with these bypasses, it becomes vulnerable to XSS.
+###### Risk Rating
+
+High
+###### References
+
+https://www.owasp.org/index.php/Ruby_on_Rails_Cheatsheet#Cross-site_Scripting_.28XSS.29
+
+#### Exploitation of Mass Assignment (Versions 2.3.x and 3.x)
+###### Description
+
+Although the major issue with Mass Assignment has been fixed by default in base Rails specifically when generating new projects, it still applies to older and upgraded projects so it is important to understand the issue and to ensure that only attributes that are intended to be modifiable are exposed.
+
+The mass-assignment feature may become a problem in older versions, as it allows an attacker to set any model’s attributes by manipulating the hash passed to a model’s new() method. This vulnerability is extended even further with the introduction of nested mass assignment (and nested object forms) in Rails 2.3.
+
+To prevent this, Strong Parameters should be used globally to enforce whitelisting of attributes in all models. Strong Parameters requires that you specify the required and permitted parameters each time parameters are retrieved. In modern Rails, Strong Parameters is enabled by default. In older versions, it is possible to use the Strong_Parameters gem with Rails 3.x, and the strong_parameters_rails2 gem for Rails 2.3.x applications. This means you'll have to make a conscious choice about which attributes to allow for mass updating and thus prevent accidentally exposing that which shouldn't be exposed.
+
+An alternative for older versions of Rails is to blacklist specific model attributes using the attr_protected method or whitelist specific model attributes using the attr_accessible method when defining your models. If you are working in Rails < 3.2.3 you must enable attribute whitelisting with the following:
+
+ 
+
+config.active_record.whitelist_attributes = true
+
+
+Whitelist example that allows access by role:
+
+ 
+
+attr_accessible :name
+
+attr_accessible :name, :is_admin, :as => :admin
+
+ 
+###### Why We Care
+
+Interactions with datastores are typically one of the most sensitive areas in a web application, from a security perspective. Ensuring that users cannot exploit those interactions to escalate privileges or gain unauthorized access to data is important to overall application security.
+###### Example of Issue
+
+The following function mass assigns user input when creating a new user.
+
+ 
+
+    def signup
+        params[:user]
+        @user = User.new(params[:user])
+    end
+
+ 
+
+
+If you create a new user using mass-assignment, and rely on the user record to determine administrative access, it may be possible to become an administrator:
+
+ 
+
+http://www.example.com/user/signup?user[name]=ow3ned&user[admin]=1
+
+ 
+
+
+In this case, the created use would have it’s admin field set to 1 due to mass assignment.
+###### How to fix?
+
+Do not disable strong parameters in modern versions of Rails. In older versions, use the Strong_Parameters gem (3.x) or the strong_parameters_rails2 gem (2.3.x).
+###### Risk Rating
+
+Medium
+###### References
+
+https://github.com/rails/strong_parameters
+
+https://github.com/grosser/strong_parameters/tree/rails2
+
+http://guides.rubyonrails.org/v3.2.8/security.html#mass-assignment
+#### Enforce HTTPS and Strict Transport Security
+###### Description
+
+AppSec recommends that all Unity web applications enforce transport encryption (HTTPS) and utilize Strict Transport Security to protect session cookies, when they are used as session management. Strict Transport Security tells the browser to only access the web application over an encrypted channel.
+###### Why We Care
+
+Strong encryption of traffic between the user and the web server plays a key part in protecting the user’s authenticated session and the data exchanged with the server.
+###### How to fix?
+
+In Rails 3.1 and later, this can be accomplished by always forcing SSL connections in your application config file:
+
+ 
+
+config.force_ssl = true
+###### Risk Rating
+
+Medium
+
+ 
+#### Prevent Logging of Sensitive Information
+###### Description
+
+By default, Rails logs all requests being made to the web application. But log files can be a huge security issue, as they may contain login credentials, credit card numbers et cetera.
+###### Why We Care
+
+Logging of sensitive, user information puts that data at higher risk of compromise. It is also a GDPR issue.
+###### How to fix?
+
+When designing a Rail application, make sure to designate request parameters that should not be logged. These should be appended to the list of filtered parameters in the Rails configuration:
+
+ 
+
+config.filter_parameters << :cc_number
+
+ 
+###### Risk Rating
+
+Medium
+###### References
+
+http://guides.rubyonrails.org/security.html#logging
+ 
+#### Avoid Disabling deep_munge
+###### Description
+
+Due to the way Active Record interprets parameters in combination with the way that Rack parses query parameters it was possible to issue unexpected database queries with IS NULL where clauses. As a response to that security issue, the deep_munge() method was introduced as a solution to keep Rails secure by default. AppSec recommends avoiding disabling deep_munge().
+###### Why We Care
+
+If deep_munge() is disabled, the vulnerabilities above will be reintroduced into the application, exposing it to risk of SQL injection attacks.
+###### How to fix?
+
+If it must be disabled, be fully aware of the vulnerabilities you are introducing, and how to properly avoid them. Otherwise, avoid disabling deep_munge().
+###### Risk Rating
+
+Medium
+###### References
+
+http://guides.rubyonrails.org/security.html#unsafe-query-generation
+
+ 
+#### Store the Rails Master Key in an Environmental Variable
+###### Description
+
+Rails will store a master key that's generated into a version control ignored config/master.key file. However, Rails will also look for that key in ENV["RAILS_MASTER_KEY"].
+###### Why We Care
+
+Part of protecting secrets is keeping them out of the code base. AppSec recommends utilizing Infrastructure Engineering’s Vault instance for secrets management. Alternatively, storing and retrieving secrets from environmental variables is a better alternative.
+###### How to fix?
+
+As with all secrets, AppSec recommends removing the key from the config/master.key file and placing it in a RAILS_MASTER_KEY environmental variable in production.
+###### Risk Rating
+
+Low
+###### References
+
+http://guides.rubyonrails.org/security.html#custom-credentials
+
+https://confluence.hq.unity3d.com/display/IE/Vault
+
+
+#### Don’t Allow User Input Determine Which View to Render
+###### Description
+
+Rails’ render() method allows for dynamic view rendering by supplying the template name to render.
+###### Why We Care
+
+If the Rails application contains views that are restricted to certain user roles, this could allow an attacker to circumvent those access controls and access restricted views as lower privilege users.
+###### How to fix?
+
+Avoiding using user input to choose which view to render when certain views are restricted.
+###### Risk Rating
+
+Low
+
+Session Fixation
+###### Description
+
+Session fixation is the term for when a pre-authentication session token used as the post-authentication session token. In other words, the a new session token is not set after authenticating. This is not an issue if header-based authentication is in use.
+###### Why We Care
+
+An attacker with knowledge of the current session token set in the browser could hijack the user’s authenticated session once they log in.
+###### How to fix?
+
+Use the reset_session() function after a user successfully authenticates to set a new session cookie in their browser.
+###### Risk Rating
+
+Low
+###### References
+
+http://guides.rubyonrails.org/security.html#session-fixation-countermeasures
\ No newline at end of file
diff --git a/Overview.md b/Overview.md
index afebb07..e53ffda 100644
--- a/Overview.md
+++ b/Overview.md
@@ -47,3 +47,18 @@ Also, be sure to keep an eye out for on-site trainings, which will be announced
 - [SourceClear](unity.com) - Dependency version checking and static analysis 
   -  [SourceClear](unity.com) Remediation
 
+
+## List of Articles
+#### _Coding Practice_
+- [API Best Practices](./Code%20Practice/API-Best-Practices.md)
+- [Authorization & Authentication Guidelines](./Code%20Practice/AuthZ-AuthN-Guidelines.md)
+- [Cryptographic Guidelines](./Code%20Practice/Cryptographic-Guidelines.md)
+- [HTTP Header Security](./Code%20Practice/HTTP-Header-Security.md)
+- [Preventing Common Web Attacks](./Code%20Practice/Preventing-Common-Web-Attacks.md)
+- [Secrets Management](./Code%20Practice/Secrets-Management.md)
+- [Secure Design Principles](./Code%20Practice/Secure-Design-Principles.md)
+#### _Language Guidance_
+
+#### _Security Process_
+
+#### _Tools & Automation_
diff --git a/images/node-npm-audit-2.png b/images/node-npm-audit-2.png
new file mode 100644
index 0000000000000000000000000000000000000000..bda1d0a094252d27b975b377a46c84ca67ec2cd2
GIT binary patch
diff --git a/images/node-npm-audit.png b/images/node-npm-audit.png
new file mode 100644
index 0000000000000000000000000000000000000000..9d5cf6d626cc088c53032f1a5de37274411acb58
GIT binary patch

From d91cb4ad6b039bb52f85812ca4deb5c07dfc3054 Mon Sep 17 00:00:00 2001
From: Brandon Caldwell <brandonc@unity3d.com>
Date: Fri, 17 May 2019 12:28:04 -0700
Subject: [PATCH 09/54] Update README.md

Just adding a basic outline - more just thinking 'out-loud' into the document.
---
 README.md | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)

diff --git a/README.md b/README.md
index 0ea4d32..922967a 100644
--- a/README.md
+++ b/README.md
@@ -1,2 +1,19 @@
 # unity-ssdlc
 A public version of Unity's internal SSDLC. Meant to provide an example framework, not just to share with other, but to also take contributions and continue to improve and evolve.
+
+##How To Use
+`<TBD>`
+  
+### SSDLC Guidance Documenation
+`<tbd>`
+### Trainings
+`<TBD>`
+#### CTF(s)
+`<TBD>`      
+
+##Contributions
+
+## License/Copyright?
+
+## Contact Us
+`<tbd>`

From 0ee2187c494c5ed4bffd8b2b12280dc4bd64a2e1 Mon Sep 17 00:00:00 2001
From: Brandon Caldwell <brandonc@unity3d.com>
Date: Fri, 17 May 2019 12:28:18 -0700
Subject: [PATCH 10/54] Update README.md

---
 README.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/README.md b/README.md
index 922967a..4ced7e2 100644
--- a/README.md
+++ b/README.md
@@ -1,7 +1,7 @@
 # unity-ssdlc
 A public version of Unity's internal SSDLC. Meant to provide an example framework, not just to share with other, but to also take contributions and continue to improve and evolve.
 
-##How To Use
+## How To Use
 `<TBD>`
   
 ### SSDLC Guidance Documenation

From 31de11e792cc8dd65f613bd47e79d7b68f2bea9f Mon Sep 17 00:00:00 2001
From: Brandon Caldwell <brandonc@unity3d.com>
Date: Fri, 17 May 2019 12:31:23 -0700
Subject: [PATCH 11/54] Update README.md

---
 README.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/README.md b/README.md
index 4ced7e2..ec26633 100644
--- a/README.md
+++ b/README.md
@@ -11,7 +11,7 @@ A public version of Unity's internal SSDLC. Meant to provide an example framewor
 #### CTF(s)
 `<TBD>`      
 
-##Contributions
+## Contributions
 
 ## License/Copyright?
 

From 325830f168413e6a091106715daa01c4ff624243 Mon Sep 17 00:00:00 2001
From: Brandon Caldwell <brandonc@hq.unity3d.com>
Date: Fri, 17 May 2019 14:48:53 -0700
Subject: [PATCH 12/54] =?UTF-8?q?Finished=20up=20Security=20Process=20?=
 =?UTF-8?q?=F0=9F=91=8D?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 Coding Practice/API-Best-Practices.md     |   2 +-
 Security Process/Implementation-Review.md |  66 +++++++++++++
 Security Process/Risk-Rating.md           |  69 ++++++++++++++
 Security Process/Unity-Bug-Bar.md         | 108 ++++++++++++++++++++++
 4 files changed, 244 insertions(+), 1 deletion(-)
 create mode 100644 Security Process/Implementation-Review.md
 create mode 100644 Security Process/Risk-Rating.md
 create mode 100644 Security Process/Unity-Bug-Bar.md

diff --git a/Coding Practice/API-Best-Practices.md b/Coding Practice/API-Best-Practices.md
index 3415ae3..9d81695 100644
--- a/Coding Practice/API-Best-Practices.md	
+++ b/Coding Practice/API-Best-Practices.md	
@@ -1,4 +1,4 @@
-# API Best Practices Guidelines [_Coding Practice_] 
+# API Best Practices Guidelines [Coding Practice] 
 <font size="-1">_Author: Frank Arana - Dec. 2018_</font>
 
 ## Overview
diff --git a/Security Process/Implementation-Review.md b/Security Process/Implementation-Review.md
new file mode 100644
index 0000000..af6ce8a
--- /dev/null
+++ b/Security Process/Implementation-Review.md	
@@ -0,0 +1,66 @@
+# Implementation Review Process [Security Process]
+<font size="-1">_Author: Carlo Valentin - Dec. 2018_</font>
+
+## Overview
+An implementation review is a code-assisted penetration test, performed to discover any security bugs in the implementation of a new product or feature. This review is a key component of a secure development lifecycle, and this is where we will find most of the issues for a product.
+
+## Requesting an Implementation Review
+An implementation review should ideally be requested once a release has been implemented. This would be a feature-complete release, typically when an application has been deployed to a staging environment. When requesting an implementation review, please contact Application Security (AppSec) to schedule a meeting and review scope. Contact AppSec by putting a message in Slack at #support-security.
+
+## Requirements
+When requesting a security review, there are a few requirements that need to be met in order to perform an effective security review. The following items should be gathered and in place before the initial meeting takes place.
+
+#### Initial Scope
+
+The development team should provide an initial scope what needs to be reviewed. A final scope will be agreed upon by both the development team and AppSec when the review is being scheduled.
+
+ 
+
+#### Designated Point of Contact
+
+The development team should have a designated point of contact to field questions and assist AppSec in removing any blockers to testing or reviewing the application.
+
+ 
+
+#### Code Repository Access
+
+AppSec will need access to the repository that contains the code for the application that we will be testing. If the application has multiple repositories, all relevant repositories should be provided to the AppSec engineer performing the review.
+
+ 
+
+#### Testable Environment
+
+A testable environment is necessary to get a full implementation review of the new application or feature that is being developed. With a working environment, AppSec can perform dynamic, targeted testing based on the review of the code. The testing environment should be as close to production as possible.
+
+ 
+
+The best case scenario is if the development team can provide the repository and all necessary dependencies in order to build the application locally. Alternatively, an application that is deployed and reachable in a staging environment is acceptable. If the service is already live and deployed to production, then production can be used. However, there will be limitations on testing a production service, depending on how critical to the business the application or service is.
+
+ 
+
+If there are multiple user roles within the application, credentials should be provided so that the application can be thoroughly tested from multiple aspects and for authorization issues.
+
+
+
+
+#### Documentation
+
+Any documentation related to the application that is needed to run or use the application should be provided. This includes things like design flow diagrams, roadmaps, and any specifications that were generated during development (e.g. API specifications, data specifications).
+
+ 
+
+#### Design Review Artifacts
+
+Any artifacts, flowcharts, and/or threat models that were performed by AppSec previously should be provided. If there have been any significant changes to the design that may not match up with the threat model, those details should be provided. If a design review did not occur, a preliminary design review and threat model will occur during the initial meeting.
+
+## Methodology
+AppSec will review applications by performing a code review and performing manual testing to validate potential issues found in the code. Additionally, a number of automated tools will be run on the code, and any identified issues will be manually verified.
+
+### Timeframe
+Typically an implementation review will occur over the span of one to two weeks. However ,level of effort for a review will depend on the size and risk of an application. When scheduling an implementation review an agreed upon amount of time will be decided between AppSec and the development team. If the engineer performing the design review runs into any issues, the development team will be notified immediately, and further steps will be decided.
+
+## Things We Care About
+An application will be compared against any requirements set forth by the Audit and Compliance team. Any additional security requirements that were determined in the design review phase will also be validated during the test. The code will be reviewed against the [language-specific guidelines provided by AppSec](../Language-Guidance). A set of common vulnerabilities that AppSec maintains can also be used to check an application against. AppSec will also ensure the application follows [provided design principles](../Coding%20Practice/Secure-Design-Principles.md).
+
+## Reporting
+At the end of an implementation review, AppSec will schedule a meeting to discuss the findings and answer any questions the development team has. Any critical issues or high issues that need immediate attention will be reported to the designated point of contact immediately. All findings will be held to the escalation process as outlined in our [[Security Process] Risk Rating (aka., Security Bug Bar)](./Risk-Rating.md).
\ No newline at end of file
diff --git a/Security Process/Risk-Rating.md b/Security Process/Risk-Rating.md
new file mode 100644
index 0000000..0145a7f
--- /dev/null
+++ b/Security Process/Risk-Rating.md	
@@ -0,0 +1,69 @@
+# Risk Rating (aka., Security Bug Bar) [Security Process]
+<font size="-1">_Carlo Valentin - Dec. 2018_</font>
+
+# Overview
+When vulnerabilities are identified by Application Security, the risk of the vulnerability needs to be effectively communicated to teams so that they can be fixed in a timely manner. As such, a standard set of definitions is needed for how Application Security classifies these vulnerabilities. These definitions ensure that development teams can quickly and easily understand the potential risk a vulnerability poses to their application or service. This gives a unified understanding of how to prioritize fixing known vulnerabilities.
+
+## Description
+When communicating vulnerabilities within security and to Unity’s product teams, Application Security has defined definitions and classes for the risk of each vulnerability. In determining the risk rating for a particular vulnerability, an aggregate score is used by taking the Impact and Likelihood ratings of a vulnerability and giving it a final rating. This provides the flexibility of taking different aspects of a vulnerability into account, while defining the standard by what Application Security judges vulnerabilities against.
+
+##### Classification via Rating Matrix
+In order to determine the risk rating for a vulnerability, take the identified Impact and Likelihood and use the matrix below to determine the final rating.
+
+<table>
+<tr style="background-color:#aaddff">
+<td></td><th>Low Impact</th><th>Medium Impact</th><th>High Impact</th></tr>
+<tr>
+<th style="background-color:#aaddff">High Likelihood</th>
+<td>Medium</td><td>High</td><td style="background-color:red;color:white;font-weight:bold">Critical</td>
+</tr>
+<tr>
+<th style="background-color:#aaddff">Medium Likelihood</th>
+<td>Low</td><td>Medium</td><td>High</td>
+</tr>
+<tr>
+<th style="background-color:#aaddff">Low Likelihood</th>
+<td>Low</td><td>Low</td><td>Medium</td>
+</tr>
+</table>
+
+
+
+
+
+### Risk Rating
+The risk rating determines the level of risk a vulnerability poses to Unity, and affects the prioritization of when to fix a bug.
+
+The rating definitions are as follows:
+
+- Critical - A vulnerability with immediate, likely risk of exposing highly sensitive business data or total compromise.
+
+- High - A vulnerability with immediate risk of compromise, or a large scale breach of business data.
+
+- Medium - A vulnerability that is difficult to exploit, but still causes a large breach of business data; a vulnerability that is easy to exploit, on a small subset of business data.
+
+- Low - A vulnerability that has minor impact or can only be exploited in a chain of other vulnerabilities.
+
+For more information on determining the Risk Rating/Severity here at Unity, please see our [Unity Security Bug Bar](./Unity-Bug-Bar.md).
+
+### Impact
+Impact classifies the reach and effect that occurs when the vulnerability is successfully exploited. This rating should take into account the loss of confidentiality, integrity, and availability of the targeted system. Reputational damage also plays a factor when rating impact.
+
+Impact ratings are classified as follows:
+
+- High - Attackers can read or modify all system data, execute arbitrary code, or escalate privileges to an administrator level. Successful execution of the vulnerability may affect a large range of users with a single exploitation.
+
+- Medium - Attackers can read or modify some system data, deny availability to the system, or expose internal technical details of the network. Exploitation may affect a subset of users with a single exploitation.
+
+- Low - Attackers can read or modify a small amount of system data or negatively affect other users’ experiences with the application. Exploitation may be limited in only affecting a single non-privileged target.
+
+### Likelihood
+Likelihood classifies the probability an vulnerability will be exploited. This rating should take into account the availability of information needed to exploit the vulnerability, social engineering requirements, authorization requirements, and if the issue has been publicly reported to Unity by a third-party.
+
+Likelihood ratings are classified as follows:
+
+- High - Attackers can exploit the vulnerability remotely, with little or no authentication or authorization. All data needed to perform the attack is publicly accessible, or has been reported to us by an external third-party.
+
+- Medium - Attackers require non-public information to exploit, or need to perform social engineering to acquire information in order to exploit. The attack may require privileged access or is performing a blind attack without feedback.
+
+- Low - Attackers require difficult to guess internal information or require a significant amount of social engineering to exploit the vulnerability.
\ No newline at end of file
diff --git a/Security Process/Unity-Bug-Bar.md b/Security Process/Unity-Bug-Bar.md
new file mode 100644
index 0000000..5f41518
--- /dev/null
+++ b/Security Process/Unity-Bug-Bar.md	
@@ -0,0 +1,108 @@
+# Unity Security Bug Bar
+<font size="-1">_Michael De Libero - Nov 2018_</font>
+## Overview
+This outlines a standard rating scale for software security issues both internally and externally found. The goal for this is to set a remediation timeline expectation and to give insight into how we rate issues. The bars specified are the minimum bars, meaning some issues depending on the circumstances could be rated higher. 
+
+### The Bug Bar
+ 
+<table>
+<tr>
+<th>Severity</th>
+
+<th>Example Bugs</th>
+
+<th>Reasoning</th>
+<tr>
+<td>Critical</td>
+<td>
+- Internet accessible RCE
+
+- Internet accessible SQL injection
+
+- Stealing customer’s code from our web services (collaborate, etc..)
+
+- RCE in the Unity Editor with no user interaction
+
+XSS in an Asset Store page
+
+Exploit in a service with an open port, such as Collab or Connect
+</td>
+<td>
+Issues of this severity have either been found to be actively exploited or publicly found. This severity should be used sparingly and for issues that need people to drop everything and fix right now.
+</td>
+<tr>
+<td>High</td>
+<td>
+- Persistent & Reflected XSS
+
+- Leaked secrets or credentials
+
+- Code execution with little user interaction
+
+Clicking a link in a browser opens Unity Editor and runs a script
+
+- Remote DoS (Persistent)
+
+- Single payload DoS
+</td>
+<td>
+These security issues can cause a big impact on our customers and/or our business. The bug should have limited mitigating security controls and should have an exploit that can be demonstrated.
+
+---
+
+_References:_
+- [Secrets (& Credential) Management](../Coding%20Practice/Secrets-Management.md)
+</td>
+</tr>
+<td>
+Medium
+</td>
+<td>
+- Server-Side Request Forgery
+
+- Server-Side Request Forgery (SSRF) that allows information disclosure and discovery of our internal network.
+
+- Any other low impact CSRF (POST-based that changes user’s “About Me” section, etc.)
+
+- Stealing customer IP from their computer’s through our software
+</td>
+<td>
+These issues could have a large impact to our customers and/or business. However, they often require some level of user-interaction and/or are difficult to exploit. At some level, there should be some mitigating security controls for these types of issues. While they should get fixed it should be part of an application team’s normal release cycle.
+</td>
+</tr>
+<tr>
+<td>
+Low
+</td>
+<td>
+- Non-exploitable memory corruption
+
+- Multi-payload DoS
+
+- Leaked HTTP headers
+
+- Error pages leaking file system information
+
+- Missing security headers
+
+- “Copy-paste” attacks
+
+- Clickjacking
+
+- Open redirect that doesn’t expose any sensitive information
+</td>
+<td>
+These issues are usually defense-in-depth issues. They don’t lead to actively exploited bugs but yield information or other footholds to attackers. These lowest risk issues could be used collectively to cause large problems. However, these issues should be added to the ice-box or long-term bug debt the development team has. Then when the development team has the time or is working in a similar area they should fix these issues.
+</td>
+</tr>
+</table>
+ 
+
+### FAQ:
+
+##### Why have a bar?
+The bar allows us to triage security bugs to ensure those that are most severe will get fixed before those that are less severe. This translates directly into customer protection - if we spend all our time focusing on fixing a local DoS (effectively a reliability bug), we won’t be able to address a publicly reported RCE. This, of course, doesn’t mean we never fix the local DoS, but during an incident, we need to focus resources appropriately.
+
+##### How does the bar direct patching and releasing security updates for the Editor?
+High and above will require a patch gets created and released for our customers. If at all possible we should work on getting these fixes in with patches that are already going out. Lows will be filed and the team owning the feature can address it as a normal bug.
+

From 7b23cb2cbd1f186e6e0b6976ccfb6959267aebee Mon Sep 17 00:00:00 2001
From: Brandon Caldwell <brandonc@unity3d.com>
Date: Mon, 20 May 2019 15:36:56 -0700
Subject: [PATCH 13/54] Some new content

---
 Language Guidance/Net-C#-Guidance.md      | 61 +++++++++++++++++++
 Security Process/Design-Review.md         | 71 +++++++++++++++++++++++
 Security Process/Security-Requirements.md | 31 ++++++++++
 3 files changed, 163 insertions(+)
 create mode 100644 Language Guidance/Net-C#-Guidance.md
 create mode 100644 Security Process/Design-Review.md
 create mode 100644 Security Process/Security-Requirements.md

diff --git a/Language Guidance/Net-C#-Guidance.md b/Language Guidance/Net-C#-Guidance.md
new file mode 100644
index 0000000..9418af1
--- /dev/null
+++ b/Language Guidance/Net-C#-Guidance.md	
@@ -0,0 +1,61 @@
+# .Net/C# Guidelines [Language Guidance]
+<font size="-1">_Author: Brandon Caldwell - Jan. 2019_</font>
+
+- [Untrusted Code and Resources](#untrusted-code-and-resources)
+- [Handling User Input](#handling-user-input)
+
+ # Overview
+Microsoft's .Net (DotNet) framework, like most modern frameworks, is generally secure from memory corruptions and code control (ex., stack corruption) style attacks, as long as the framework is kept up-to-date with the latest version from Microsoft. However, over the years, there have been some features of the framework that are now considered unsafe, or do not provide the protections developers believe they do. Below is general guidance on what to watch out for when developing in .Net languages.
+#### Untrusted Code and Resources
+
+The following guidance is in regards to loading code or resources from an untrusted source, i.e., anything from the internet or not signed by Unity (or trusted 3rd party). When working with these types of resources, refer to the below:
+
+- Do not use partial trusted code, Code Access Security (CAS), or AllowPartiallyTrustedCaller.
+  - Problem: CAS was billed as a way to load untrusted libraries/code at runtime, by assigning 'trust levels' to various portions of code. Microsoft now recommends against using CAS as a means to protect against malicious code. Partial trust code and AllowPartiallyTrustedCaller has similar issues, wherein is does not provide any effective protections.
+
+  - Solution: Only load code and resources that have been signed by a trusted party.
+- Do not use .NET Remoting or binary formatters (for object serialization/deserialization)
+  - Problem: Hints that serialization vulnerabilities in the .Net framework have existed since 20120 (MS12-035 via James Forshaw), later revelations found major vulnerabilities within serialization, beyond what was published in that article.
+  - Solution: Use DataContractSerialiazer as part of serializing objects.
+- Do not use Distributed Component Object Model (DCOM).
+  - Problem: Again, thanks to James Forshaw, it was determined that DCOM was generally unsafe, and has issues with safe (or unsafe?) object serialization.
+  - Solution: Don't use it at all. Consider named pipes for local services (available cross-platform). Avoid HTTP/REST-like endpoints if possible, as they can be difficult to protect against browser attacks - see UNITY-SEC-844.
+
+ 
+
+In short, to quote the existing Microsoft guidance:
+
+>Code Access Security and Security-Transparent Code are not supported as a security boundary with partially trusted code. We advise against loading and executing code of unknown origins without putting alternative security measures in place.
+
+#### Handling User Input
+
+The following guidance is largely relevant to ASP.Net and .Net Embedded browser support:
+
+- Any user data in a server response runs in the context of the server's site on the client. If your Web server takes user data and inserts it into the returned Web page, it might, for example, include a `<script>` tag and run as if from the server.
+- Remember that the client can request any URL.
+- Consider tricky or invalid paths:
+  - ..\ , extremely long paths.
+  - Use of wild card characters (*).
+  - Token expansion (%token%).
+  - Strange forms of paths with special meaning.
+  - Alternate file system stream names such as filename::$DATA.
+  - Short versions of file names such as longfi~1 for longfilename.
+- Remember that Eval(userdata) can do anything.
+- Be wary of late binding to a name that includes some user data.
+- If you are dealing with Web data, consider the various forms of escapes that are permissible, including:
+  - Hexadecimal escapes (%nn).
+  - Unicode escapes (%nnn).
+  - Overlong UTF-8 escapes (%nn%nn).
+  - Double escapes (%nn becomes %mmnn, where %mm is the escape for '%').
+- Be wary of user names that might have more than one canonical format. For example, you can often use either the MYDOMAIN\username form or the username@mydomain.example.com form.
+  - (From https://github.com/dotnet/docs/blob/master/docs/standard/security/security-and-user-input.md)
+
+ 
+###### References:
+
+- https://github.com/dotnet/docs/blob/master/docs/standard/security/secure-coding-guidelines.md
+- https://docs.microsoft.com/en-us/dotnet/framework/misc/code-access-security
+- https://docs.microsoft.com/en-us/dotnet/framework/misc/security-transparent-code
+- https://support.microsoft.- com/en-us/help/2698981/asp-net-partial-trust-does-not-guarantee-application-isolation
+- Attacking .Net Serialization: https://speakerdeck.com/pwntester/attacking-net-serialization?slide=8
+- .Net Remoting Security Bulletin: - https://docs.microsoft.com/en-us/security-updates/SecurityBulletins/2012/ms12-035
diff --git a/Security Process/Design-Review.md b/Security Process/Design-Review.md
new file mode 100644
index 0000000..d1a081f
--- /dev/null
+++ b/Security Process/Design-Review.md	
@@ -0,0 +1,71 @@
+# Design Review and Threat Modelling Process [Security Process]
+<font size="-1">_Author: Carlo Valentin - Dec. 2018_</font>
+
+### Overview
+
+Design reviews and threat modelling are key components of ensuring a secure development lifecycle. A design review allows the security team to review an application’s specification and design against security best practices and design patterns. Coupled with a threat model, the development team will be able to determine the need or design of security controls needed for an application. By involving AppSec early on in the process, security will be a consideration throughout the development lifecycle - reducing the amount of security issues that will occur during the implementation and testing phases.
+#### Requesting a Design Review
+
+A design review can occur at any point in the development life cycle depending on the situation. Ideally, a design review is performed before any code has been written for an application or service, occurring during the design phase of software development. This is the best time to make adjustments to the application design. Once an application has a design specification and the development team has gathered the appropriate requirements for an application is when the design review should occur. Design reviews can also be performed prior to a security review if AppSec is not familiar with the application. When requesting an design review, please contact Application Security (AppSec) to schedule a meeting and review scope. Contact AppSec by putting a message in Slack at #support-security.
+#### Requirements
+
+When requesting a design review, the development team will need to provide documentation and diagrams related to the new application. The following is a non-comprehensive list of documentation that will help a design review go smoothly. While they are not hard requirements for a design review, AppSec cannot guarantee the quality of the review without materials provided by the development team.
+
+ 
+
+###### Design Specifications
+
+Providing a design specification of the application allows AppSec to review the planned design of an application. AppSec will provide consultation on various security requirements related to the design authentication, access controls, and other security controls.
+
+ 
+
+###### Architecture Diagrams
+
+A general architecture diagram detailing the major components of an application and how they interact is very useful for a threat model and design review. This typically is a diagram describing how components of an application integrate and function together.
+
+ 
+
+###### Data Classifications
+
+The risk of an application varies wildly, and almost always depend on the types of data the application handles and stores. Providing what classifications of data the application uses will give context to the security requirements an application requires.
+
+ 
+
+###### Data Flow Diagram/Transitions
+
+While very similar to an architecture diagram, a data flow diagram provides which data flows into and out of each part of the application. This makes it clear which components interact with each class of data, providing AppSec with a holistic view of the application, allowing for an effective threat model.
+
+ 
+
+###### Stakeholders and Integrations
+
+Applications don’t exist in a vacuum, and as such there will be additional Unity teams and third party services an application integrates or leverages. Providing a list of these teams and services will allow us to assess the risk an application poses.
+
+ 
+#### Methodology
+
+Since a design review ideally takes place early during the software development lifecycle, AppSec’s methodology for a design review is high level, and adapted to fit any application. Within a design review, we focus on two main components to ensure the review brings value to the development process.
+###### Secure Design Consultation
+
+Many times during the design of an application, the development team realizes the need for a security related control - such as role based access or authentication. While there are many resources online, very few times are they adapted to fit our needs here at Unity. As such, during the design review we provide recommendations and consultation regarding the design of security controls.
+
+ 
+###### Threat Modelling
+
+> “What could go wrong?” - Unnamed Developer, c. 2011
+
+ 
+
+Threat models are the primary artifact from a design review. 
+
+Most of the time, a threat model includes the following:
+
+- A description / design / model of what you’re worried about
+- A list of assumptions that can be checked or challenged in the future as the threat landscape changes
+- A list of potential threats to the system
+- A list of actions to be taken for each threat
+- A way of validating the model and threats, and verification of success of actions taken
+
+ 
+
+All of the above are discussed during the design review meeting, and act as a working discussion during the meeting. From that meeting we should be able to provide additional design recommendations and a list of controls used to mitigate the threats to an application. This should result in something very similar to a design flow diagram, but with notes regarding potential threats and the mitigating controls.
diff --git a/Security Process/Security-Requirements.md b/Security Process/Security-Requirements.md
new file mode 100644
index 0000000..4458d2f
--- /dev/null
+++ b/Security Process/Security-Requirements.md	
@@ -0,0 +1,31 @@
+# Application Security Requirements at Unity [Security Process]
+<font size="-1">_Author: Carlo Valentin - Dec. 2018_</font>
+
+### What are Security Requirements?
+
+Applications have a range of requirements that are taken into consideration during the development process. For example, there may be considerations made to who needs to use an application, that will decide whether it is public facing or not. Similar to this, there are a number of security-related requirements, which should be considered during the development process.
+
+### How do I identify security requirements?
+
+Security requirements are any needs or requirements of an application that act or perform some sort of security control. These requirements include concepts like authentication or role-based access controls (RBAC). Many of these requirements can be determined by following [secure design principles](../Coding%20Practice/Secure-Design-Principles.md).
+
+ 
+
+An example of security requirements that an application can encounter:
+
+- Authentication
+  - Requirement for any application that has multiple user levels of access. Ensures non-repudiation and is the foundation for the principle of least-privilege.
+- Authorization/Role Based Access Control
+  - Requirement for any application that has multiple user levels of access. Ensures implementation of the principle of least-privilege.
+- Input Validation/Output Encoding
+  - Requirement for any application that receives untrusted data, and exposes said data back to the user. Ensures the authenticity and integrity of the data consumed by the application.
+- Secrets Management
+  - Requirements for where to store secrets, such as API tokens, that are used by the application.
+- Encryption
+  - Requirements for how and when to encrypt data at rest or in transit.
+- Logging
+  - Requirement for many applications to ensure non-repudiation of application actions.
+
+### Once I have these requirements, what do I do?
+
+A failure or flaw in the implementation of a security-related requirement can lead to additional various vulnerabilities or in some cases require a re-architecting of the application. As such, care needs to be taken when implementing the identified requirements. If you and your team are unsure about the design or implementation of security requirements, please schedule a [design review](./Design-Review.md) or [implementation review](./Implementation-Review.md) with the AppSec team in #support-security.

From 7df85fa7d21820443b00d9e316c797a8af7ed3f9 Mon Sep 17 00:00:00 2001
From: Brandon Caldwell <brandonc@unity3d.com>
Date: Mon, 20 May 2019 16:05:36 -0700
Subject: [PATCH 14/54] Minor formatting changes - workikng to normalize things
 just a little bit. More work will need to be done.

---
 Coding Practice/API-Best-Practices.md       |  6 +++---
 Coding Practice/AuthZ-AuthN-Guidelines.md   |  4 ++--
 Coding Practice/Cryptographic-Guidelines.md | 12 ++++++++----
 Coding Practice/HTTP-Header-Security.md     | 17 ++++++++++++-----
 4 files changed, 25 insertions(+), 14 deletions(-)

diff --git a/Coding Practice/API-Best-Practices.md b/Coding Practice/API-Best-Practices.md
index 9d81695..36e4be4 100644
--- a/Coding Practice/API-Best-Practices.md	
+++ b/Coding Practice/API-Best-Practices.md	
@@ -38,7 +38,7 @@ For Public APIs providing public information: Ensure no state changing actions a
 Incorrect access controls can range from High to Low Severity.
 ###### References (Optional)
 
-https://www.owasp.org/index.php/REST_Security_Cheat_Sheet
+- https://www.owasp.org/index.php/REST_Security_Cheat_Sheet
 
 ---
 
@@ -92,10 +92,10 @@ Generate signatures or HMACs for each request containing sensitive data or actio
 Depending on what actions the request can take, severity could range from High to Low.
 ###### References (Optional)
 
-https://docs.aws.amazon.com/general/latest/gr/signing_aws_api_requests.html#why-requests-are-signed 
+- https://docs.aws.amazon.com/general/latest/gr/signing_aws_api_requests.html#why-requests-are-signed
 
 ---
-#### General
+### General
 ###### Description
 Common security practices relevant, but not exclusive to APIs
 ###### Why We Care
diff --git a/Coding Practice/AuthZ-AuthN-Guidelines.md b/Coding Practice/AuthZ-AuthN-Guidelines.md
index 204e6e4..c422711 100644
--- a/Coding Practice/AuthZ-AuthN-Guidelines.md	
+++ b/Coding Practice/AuthZ-AuthN-Guidelines.md	
@@ -62,7 +62,7 @@ During the requirements phase, determine what information is needed for the OAut
 Medium
 ###### References
 
-https://tools.ietf.org/html/rfc6819#section-3.1.1
+- https://tools.ietf.org/html/rfc6819#section-3.1.1
 
 --- 
 ### Limited Token Lifetimes
@@ -128,4 +128,4 @@ Generate a cryptographically-secure random state parameter when the OAuth2 flow
 Low
 ###### References
 
-https://tools.ietf.org/html/rfc6819#section-3.6
+- https://tools.ietf.org/html/rfc6819#section-3.6
diff --git a/Coding Practice/Cryptographic-Guidelines.md b/Coding Practice/Cryptographic-Guidelines.md
index 490d1f2..36900bc 100644
--- a/Coding Practice/Cryptographic-Guidelines.md	
+++ b/Coding Practice/Cryptographic-Guidelines.md	
@@ -26,6 +26,7 @@ Accepted TLS Cipher suites:
 - TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
 - TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
 - TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
+<sub>3DES ciphers are accepted for maximum interoperability - other ciphers should be chosen as 3DES will likely be deprecated</sub>
 
 ###### Hash Algorithms
 
@@ -37,9 +38,9 @@ Accepted TLS Cipher suites:
   - SHA512Cng (FIPS compliant)
   - SHA384Cng (FIPS compliant)
   - SHA256Cng (FIPS compliant)
-  - SHA512Managed (non-FIPS-compliant) (use SHA512 as algorithm name in calls to HashAlgorithm.Create or CryptoConfig.CreateFromName)
-  - SHA384Managed (non-FIPS-compliant) (use SHA384 as algorithm name in calls to HashAlgorithm.Create or CryptoConfig.CreateFromName)
-  - SHA256Managed (non-FIPS-compliant) (use SHA256 as algorithm name in calls to HashAlgorithm.Create or CryptoConfig.CreateFromName)
+  - SHA512Managed (non-FIPS-compliant) *(use SHA512 as algorithm name in calls to `HashAlgorithm.Create` or `CryptoConfig.CreateFromName`)*
+  - SHA384Managed (non-FIPS-compliant) *(use SHA384 as algorithm name in calls to `HashAlgorithm.Create` or `CryptoConfig.CreateFromName`)*
+  - SHA256Managed (non-FIPS-compliant) *(use SHA256 as algorithm name in calls to `HashAlgorithm.Create` or `CryptoConfig.CreateFromName`)*
   - SHA512CryptoServiceProvider (FIPS compliant)
   - SHA256CryptoServiceProvider (FIPS compliant)
   - SHA384CryptoServiceProvider (FIPS compliant)
@@ -52,4 +53,7 @@ Accepted TLS Cipher suites:
 - **Windows Store Apps**: Windows.Security.Cryptography.CryptographicBuffer.GenerateRandom or GenerateRandomNumber
 - **Apple OS X** _(10.7+)/iOS(2.0+)_: int SecRandomCopyBytes (SecRandomRef random, size_t count, int8_t *bytes )
 - **Apple OS X** _(<10.7)_: Use /dev/random to retrieve random numbers
-- **Java** _(including Google Android Java code)_- java.security.SecureRandom class. Note that for Android 4.3 (Jelly Bean), developers must follow the Android recommended workaround and pdate their applications to explicitly initialize the PRNG with entropy from /dev/urandom or dev/random
\ No newline at end of file
+- **Java** _(including Google Android Java code)_- java.security.SecureRandom class. Note that for Android 4.3 (Jelly Bean), developers must follow the Android recommended workaround and pdate their applications to explicitly initialize the PRNG with entropy from /dev/urandom or dev/random
+
+### References
+- https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-52r1.pdf
\ No newline at end of file
diff --git a/Coding Practice/HTTP-Header-Security.md b/Coding Practice/HTTP-Header-Security.md
index c7876e2..f67cc63 100644
--- a/Coding Practice/HTTP-Header-Security.md	
+++ b/Coding Practice/HTTP-Header-Security.md	
@@ -3,9 +3,9 @@
 ## Overview
 This document describes the HTTP security headers that we strongly recommend are implemented on all of Unity’s Internet-facing services. https://observatory.mozilla.org can be used to check your site's current headers. The headers are listed in order of importance, but please not that a proper secure Content Security Policy can be difficult to implement unless the application is designed from the beginning with this in mind. 
 
-Therefore, try to get some quick wins with headers such as HTTP Strict Transport Security, X-Frame-Options, X-XSS-Protection and X-Content-Type-Options first.
+Therefore, try to get some quick wins with headers such as: `HTTP Strict Transport Security`, `X-Frame-Options`, `X-XSS-Protection` and `X-Content-Type-Options` first.
 
-For applications that only offer web APIs; check the recommendations under "API" at the bottom of the page.
+For applications that only offer web APIs; check the recommendations under [API](#api) at the bottom of the page.
 #### HTTP Strict Transport Security
 
 The strict transport security header tells browsers to load the website over encrypted connections only from now on. This helps avoid what is called SSL stripping attacks where an attacker who are in a Man-In-The-Middle position downgrades a user to an insecure connection.
@@ -21,7 +21,7 @@ Once confident that it's working you should aim for a max-age of minimum 6 month
 **Recommended final setting:**
     
     Strict-Transport-Security: max-age=63072000
-
+---
 #### Content-Security-Policy
 
 This header aims to reduce or even eliminate the impact of XSS attacks. It can be used to tell the browser where the website is supposed to load resources from.
@@ -62,6 +62,8 @@ Google has found that most CSP utilising whitelisting does not prevent XSS becau
  
 
 Note that you would need a reporting endpoint to receive the CSP violation reports at <mydomain>/csp-violation-report-endpoint for this last example to work properly. 
+
+---
 #### X-Frame-Options
 
 This header tells the browser if framing the website is allowed by other domains. By setting this header to a list of allowed domains or simply deny framing we can prevent Clickjacking attacks. Read more about clickjacking attacks here: https://www.owasp.org/index.php/Clickjacking
@@ -74,6 +76,7 @@ This header tells the browser if framing the website is allowed by other domains
 
 X-Frame-Options is being replaced by the Content-Security Policy header's "frame-ancestors" attribute. This attribute is more flexible and should be added as well. 
  
+ ---
 #### X-XSS-Protection
 
 X-XSS-Protection sets the configuration for the cross-site scripting filter built into most browsers. Read more about it here: https://scotthelme.co.uk/hardening-your-http-response-headers/#x-xss-protection
@@ -81,7 +84,7 @@ X-XSS-Protection sets the configuration for the cross-site scripting filter buil
 **Recommended setting:**
 
     X-XSS-Protection: 1; mode=block
-
+---
 #### X-Content-Type-Options
 
 This header tells the browser not to guess the MIME type of the content served, but instead trust the “Content-Type” header. Without the X-Content-Type-Options header set, some older browsers can incorrectly detect files as scripts and stylesheets, potentially leading to XSS attacks.
@@ -90,7 +93,7 @@ This header tells the browser not to guess the MIME type of the content served,
 
     X-Content-Type-Options: nosniff
 
-
+---
 #### Referrer-Policy
 
 The header basically controls what is being sent in the referer header. The security benefit from using this header is to avoid situations where session identifiers or other sensitive information which is transmitted in the URL is passed to other domains via the referer header. There are different options here which range from sending no referer header whatsoever to sending only the domain (origin). The best setting must be determined based on the application's use of the referer header. The recommended setting "origin" only sends the domain name and not the path part of the URL. It is also chosen because it is supported across largest body of browsers. 
@@ -100,6 +103,8 @@ The header basically controls what is being sent in the referer header. The secu
     Referrer-Policy: origin
 
 We may also want to do "Referrer-Policy: strict-origin" to only send the referrer header to sites that are HTTPS to protect the user's privacy, but currently it's not supported on Edge and Safari. 
+
+---
 #### API
 
 For APIs we want to ensure traffic is encrypted and restrict the potential impact of XSS vulnerabilities e.g. in error pages then they can't be used to run Javascript due to the Content-Security Policy not allowing scripts or iframes. Note that for APIs with documentation on the same domain such as  Swagger, this won't work and would need to be adapted.
@@ -111,6 +116,8 @@ For APIs we want to ensure traffic is encrypted and restrict the potential impac
 
     X-Content-Type-Options: nosniff
 
+---
+
 ###### Resources:
 
 For more best practices and recommendations by Mozilla on Web Application Security see this link:

From 67ef0545956e40c0582361b3318c4b24ae279432 Mon Sep 17 00:00:00 2001
From: Brandon Caldwell <brandonc@unity3d.com>
Date: Mon, 20 May 2019 18:21:10 -0700
Subject: [PATCH 15/54] More normalization. Cleaned up a couple docs. Updated
 the Readme.md to actually be useful. Almost ready for legal review.

---
 Coding Practice/HTTP-Header-Security.md       | 27 ++++---
 .../Preventing-Common-Web-Attacks.md          |  9 ++-
 Coding Practice/Secrets-Management.md         | 81 +++++++------------
 Coding Practice/Secure-Design-Principles.md   | 11 +++
 Language Guidance/Golang-Guidance.md          | 20 ++---
 Language Guidance/Net-C#-Guidance.md          |  8 +-
 Language Guidance/Nodejs-Guidance.md          | 67 ++++++++-------
 Language Guidance/Ruby-Guidance.md            | 69 ++++++++--------
 README.md                                     | 36 +++++++--
 Security Process/Implementation-Review.md     |  2 +-
 Security Process/Security-Requirements.md     |  2 +-
 11 files changed, 184 insertions(+), 148 deletions(-)

diff --git a/Coding Practice/HTTP-Header-Security.md b/Coding Practice/HTTP-Header-Security.md
index f67cc63..586cfb5 100644
--- a/Coding Practice/HTTP-Header-Security.md	
+++ b/Coding Practice/HTTP-Header-Security.md	
@@ -6,6 +6,15 @@ This document describes the HTTP security headers that we strongly recommend are
 Therefore, try to get some quick wins with headers such as: `HTTP Strict Transport Security`, `X-Frame-Options`, `X-XSS-Protection` and `X-Content-Type-Options` first.
 
 For applications that only offer web APIs; check the recommendations under [API](#api) at the bottom of the page.
+
+- [HTTP Strict Transport Security](#http-strict-transport-security)
+- [Content-Security-Policy](#content-security-polict)
+- [X-Frame-Options](#x-frame-options)
+- [X-XSS-Protection](#x-xss-protection)
+- [X-Content-Type-Options](#x-content-type-options)
+- [Referrer-Policy](#referrer-policy)
+- [API](#api)
+
 #### HTTP Strict Transport Security
 
 The strict transport security header tells browsers to load the website over encrypted connections only from now on. This helps avoid what is called SSL stripping attacks where an attacker who are in a Man-In-The-Middle position downgrades a user to an insecure connection.
@@ -61,7 +70,7 @@ Google has found that most CSP utilising whitelisting does not prevent XSS becau
 
  
 
-Note that you would need a reporting endpoint to receive the CSP violation reports at <mydomain>/csp-violation-report-endpoint for this last example to work properly. 
+Note that you would need a reporting endpoint to receive the CSP violation reports at `<your-domain-name>/csp-violation-report-endpoint` for this last example to work properly. 
 
 ---
 #### X-Frame-Options
@@ -109,7 +118,7 @@ We may also want to do "Referrer-Policy: strict-origin" to only send the referre
 
 For APIs we want to ensure traffic is encrypted and restrict the potential impact of XSS vulnerabilities e.g. in error pages then they can't be used to run Javascript due to the Content-Security Policy not allowing scripts or iframes. Note that for APIs with documentation on the same domain such as  Swagger, this won't work and would need to be adapted.
 
-**Recommended settings:**1202
+**Recommended settings:**
 
     Content-Security-Policy: default-src 'none'; frame-ancestors 'none'
     Strict-Transport-Security: max-age=31536000
@@ -122,12 +131,8 @@ For APIs we want to ensure traffic is encrypted and restrict the potential impac
 
 For more best practices and recommendations by Mozilla on Web Application Security see this link:
 
-https://developers.google.com/web/fundamentals/security/csp/
-
-https://wiki.mozilla.org/Security/Guidelines/Web_Security
-
-https://csp.withgoogle.com/
-
-https://www.w3.org/TR/referrer-policy/
-
-http://caniuse.com/#feat=referrer-policy
+- https://developers.google.com/web/fundamentals/security/csp/
+- https://wiki.mozilla.org/Security/Guidelines/Web_Security
+- https://csp.withgoogle.com/
+- https://www.w3.org/TR/referrer-policy/
+- http://caniuse.com/#feat=referrer-policy
diff --git a/Coding Practice/Preventing-Common-Web-Attacks.md b/Coding Practice/Preventing-Common-Web-Attacks.md
index 7bc789d..90bbc05 100644
--- a/Coding Practice/Preventing-Common-Web-Attacks.md	
+++ b/Coding Practice/Preventing-Common-Web-Attacks.md	
@@ -42,7 +42,7 @@ References
 
 https://www.owasp.org/index.php/Clickjacking_Defense_Cheat_Sheet
 
- 
+ ---
 ### All the cool kids use HTTP Security Headers
 ###### Description
 
@@ -72,6 +72,8 @@ https://infosec.mozilla.org/guidelines/web_security
 Unity's Security Teams has a tool for checking how your application grades based on its security headers here:
 
 https://appcollector.internal.unity3d.com/observatory/
+
+---
 ### Preventing XSS
 ###### Description
 
@@ -126,6 +128,7 @@ References
 
     https://csp.withgoogle.com/
 
+---
 ### Preventing SQL Injection
 ###### Description
 
@@ -168,7 +171,7 @@ https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet
 
 https://blog.websecurify.com/2014/08/hacking-nodejs-and-mongodb.html (Example noSQL attacks)
 
- 
+--- 
 ### Preventing Cross-Site Request Forgery
 ###### Description
 
@@ -233,7 +236,7 @@ References
 
     https://www.netsparker.com/blog/web-security/same-site-cookie-attribute-prevent-cross-site-request-forgery/
 
- 
+ ---
 ### Credential Leaks
 ###### Description
 
diff --git a/Coding Practice/Secrets-Management.md b/Coding Practice/Secrets-Management.md
index bccbe41..5d310b6 100644
--- a/Coding Practice/Secrets-Management.md	
+++ b/Coding Practice/Secrets-Management.md	
@@ -1,6 +1,5 @@
-# DRAFT
-# Secrets Management (i.e., Storing Passwords Safely) [Coding Practice] 
-<font size="-1">Authors: Shawn Verzilli, Tim Herold - Apr. 2019</font>
+# Secrets Management _(i.e., Storing Passwords Safely)_ [Coding Practice] 
+<font size="-1">_Authors: Shawn Verzilli, Tim Herold - Apr. 2019_</font>
 
 ## Description
 
@@ -9,7 +8,7 @@ Developing and deploying secure services and applications at Unity requires inte
 The secrets need to be high-entropy, unique per service, and unique per environment. In many cases this will lead to many secrets for a team to manage, and as such these secrets have frequently been stored checked in as part of configuration files - an insecure practice. Once saved into a configuration file, they are frequently, and accidentally, checked into your favorite version control system on a publicly accessible cloud-hosted repositories, and hence into the hands of attackers. These secrets cannot be stored in such a manner, and need to be kept in an access controlled environment.
 ### Why We Care
 
-Secrets are secret for a reason, and often provide access to a lot of data, computing resources or privileged accounts. It is therefore crucial that we handle secrets well, ensure we limit their scope and use least privilege, and make the probability of accidental leaks as small as possible. (See Common Control Framework security controls CCF-4.04 and CCF-4.05)
+Secrets are secret for a reason, and often provide access to a lot of data, computing resources or privileged accounts. It is therefore crucial that we handle secrets well, ensure we limit their scope and use least privilege, and make the probability of accidental leaks as small as possible. (See Unity's Common Control Framework security controls CCF-4.04 and CCF-4.05)
 ### Examples of Problematic/Incorrect Secrets Use
 
 We’ve had many instances of Unity credentials leaked via public Git repos. This could have given malicious actors access to internal systems, data, APIs and more. There have also been other examples such as accidentally hosting script files that contain credentials on a public web server.
@@ -17,7 +16,7 @@ We’ve had many instances of Unity credentials leaked via public Git repos. Thi
 It should go without saying, but when your credentials fall into someone else’s hands they can assume any of your privileges. A common example we see is someone granting themselves “Admin” so they do not have to concern themselves with identifying precisely the minimum privileges needed. They may only use these credentials for a small handful of API calls but when these credentials are exposed, a malicious actor can do anything “Admin” can do. These credentials are often exploited for launching cryptominers, ransomware attacks, or setting up backdoors for later use.
 
 This is not limited to the example of “Admin” by any means. For example, compromising a user grants access to all groups the user may be a member of. These groups have the potential to span teams, projects, accounts, and more. This is commonly seen when a developer uses their own LDAP/Google credentials to test out a prototype of what their working on, only to later check-in that code to save their progress. It’s a bad habit to get into, despite the convenience it offers.
-**To summarize/TL;DR, @Unity, Security has seen secrets (in the clear) in:**
+**To summarize, TL;DR - Commonly found secrets in code (unencrypted):**
 - Raw HTML pages
 - Deployed Javascript
 - Public Githubs
@@ -59,12 +58,12 @@ Common examples of secret usage are:
 ![Secrets on Fire](../images/secrets%20fire.png)
 
 
-As a rule of thumb, you should use temporary credentials at every opportunity. Not all systems are built in a way that supports this and so using a secrets management tool like Hashicorp Vault or AWS Secrets Manager is strongly recommended. Environment variables are passable but not recommended. You should never store secrets in code.
+As a rule of thumb, you should use temporary credentials at every opportunity. Not all systems are built in a way that supports this and so using a secrets management tool, like Hashicorp Vault or AWS Secrets Manager, is strongly recommended. Environment variables are passable but not recommended. You should never store secrets in code.
 ##### How to protect secrets
 
-After taking the steps above to prepare your application, leverage a secrets management infrastructure to safely store and access your secrets. Cloud options in Google Cloud KMS or Amazon AWS KMS. The Security Team currently doesn’t support the available cloud options, but have worked to build Unity’s internally maintained Vault system, currently maintained and supported by Infrastructure Engineering. Vault allows you to store secrets in a central, secure place. For details on using Vault for secrets management, see the APPENDIX in this document, or read more about Vault and how to get started go here. If you need support beyond the documentation, feel free to reach out to #ie-support-data-infra or #support-security on Slack. Note that Vault may not be a universal solution, so feel free to reach out early to be sure it’ll be a good solution for your product.
+After taking the steps above to prepare your application, leverage a secrets management infrastructure to safely store and access your secrets. Cloud options in Google Cloud KMS or Amazon AWS KMS.
 
-The application security team have tools monitoring for secrets in source code repositories, but this mechanism is only supposed to be the last line of defense and to avoid credential leaks it is up to the developer to be diligent when handling these sensitive pieces of data.
+The application security team has tools monitoring for secrets in source code repositories, but this mechanism is only supposed to be the last line of defense and to avoid credential leaks it is up to the developer to be diligent when handling these sensitive pieces of data.
 #### Secret Stores
 ###### HashiCorp Vault:
 
@@ -73,7 +72,7 @@ Vault supports a couple of options for secrets storage - Static and Dynamic. If
 
 These are your traditional secrets. Think Username, Password, and/or API Key. These can be stored via the Vault command-line tools, for example:
 
-    vault write secret/stg/ads/ads-performance-valuation/AWS_ACCESS_KEY_ID secret=AKIAIIIDEADBEEF35A3D
+    vault write secret/stg/ads/ads-performance-valuation/AWS_ACCESS_KEY_ID secret=AKIAIII1337DEADBEEF
 
 _For more Vault guidance, see the linked guidance below, in the Appendix_
 
@@ -81,23 +80,22 @@ _For more Vault guidance, see the linked guidance below, in the Appendix_
 
 Vault has a variety of Secrets Engines to hook into services like AWS, GCP, SSH, PKI, (and more) to provide temporary credentials which expire on a time-based lease procured by Vault. In the example of the AWS Secrets Engine, Vault acts as an abstraction to an AWS STS call and serves up the resultant Access/Secret Key pair.
 
-For details on dynamic secrets, see Hashicorp’s guidance: Dynamic Secrets
-Vault Support
+For details on dynamic secrets, see Hashicorp’s guidance: [Dynamic Secrets Vault Support](https://learn.hashicorp.com/vault/getting-started/dynamic-secrets)
 
-If you need support in using or troubleshooting Vault, visit Slack channels #ie-support-data-infra or #support-security.
+If you need support in using or troubleshooting Vault, contact the Security Team
 ##### GCP
 
 The best practice for application authentication in Google Cloud is to use a Service Account. Rather than store the service account secret in the application source code, use an environment variable pointing to credentials outside of the application’s source code, such as Vault. Restrict who can act as service accounts. Users who are granted the Service Account Actor role for a service account can access all of the resources for which the service account has access.
 
-The Security team is still working to develop more complete guidance on managing GCP secrets; in the meantime, leverage Google’s own document: Understanding Service Accounts. As always, if further guidance is required, visit #support-security in Unity Slack.
+The Security team is still working to develop more complete guidance on managing GCP secrets; in the meantime, leverage Google’s own document: Understanding Service Accounts. As always, if further guidance is required, ask the Security Team.
 
 ##### AWS Keys:
 
 AWS keys generally come in the following format:
 
-    AWS_ACCESS_KEY_ID:AKIA***********VTLCD
+    AWS_ACCESS_KEY_ID:AKIA***********VT43D
 
-    AWS_SECRET_ACCESS_KEY:SYU********************************TUVCrG
+    AWS_SECRET_ACCESS_KEY:SYU********************************TUFYIG
 
 
 These keys are generated by AWS IAM or AWS STS.
@@ -137,7 +135,7 @@ High
 ---
 
 ##### Frequently Asked Questions - FAQ:
-The secrets are for my dev/staging/test/fantasy environment - do those still matter?
+###### The secrets are for my dev/staging/test/fantasy environment - do those still matter?
 
 Yes.
 
@@ -146,48 +144,29 @@ In the vast majority of cases, the dev/staging environments are nearly identical
 Beyond the direct risks to infrastructure, the secrets themselves are now also stored on the servers where the code is hosted, as well as all the developer workstations of anyone whom as cloned or forked the code. The assumption should be the secrets are in the open, as there's limited to no way to track of they've been spread.
 
 And of course, as is common with personal passwords, we see a high incident of re-use; so chances are, your staging secrets are the same as your production secrets.
-What about my test code?
+###### What about my test code?
 
 Similar to the answer above, but this can be slightly more nuanced. If the test code is leveraging 'fake' credentials (as in, don't actually work anywhere) to test parsing code or error handling, then this is probably fine. If these credentials are used for testing against a local, or ephemeral mock instance, then this is probably fine as well. The concern is around 'permanent' test facilities that are also hosted along side the rest of our infrastructure - wherein the same problems exists as do those in dev/staging environments.
-References
 
-https://confluence.hq.unity3d.com/display/SEC/Secret-Finder
+###### References
 
-https://github.com/yeyintminthuhtut/Awesome-Red-Teaming#-lateral-movement
-
-[Security Process] Risk Rating (aka., Security Bug Bar)
-
-Unity Security Bug Bar
+- https://github.com/yeyintminthuhtut/Awesome-Red-Teaming#-lateral-movement
 
+- [ Risk Rating (aka., Security Bug Bar) - (Security Process)](../Security%20Process/Risk-Rating.md)
 
 ## APPENDIX
-Vault Guidance
-Vault Usage
-
-Vault for developers: https://confluence.hq.unity3d.com/display/IE/Using+Vault+in+IE+Infra 
-
-Vault for shared accounts (ex. DB admin): https://confluence.hq.unity3d.com/display/IE/Using+Vault+To+Authenticate+To+Databases 
-Vault Administration
-
-Vault software Overview - https://confluence.hq.unity3d.com/display/IE/Vault+Enterprise 
-
-Unsealing Vault - https://confluence.hq.unity3d.com/display/IE/Unseal+Vault
-
-Vault in GKE - https://confluence.hq.unity3d.com/display/IE/Initialise+Vault+Integration+in+a+GKE+Cluster 
-Vault Resources
-
-Usage Guides - https://github.com/hashicorp/vault-guides
-
-Dynamic Secrets - https://www.hashicorp.com/blog/why-we-need-dynamic-secrets
-
+#### Vault Guidance
+- Vault for developers: https://confluence.hq.unity3d.com/display/IE/Using+Vault+in+IE+Infra 
+- Vault for shared accounts (ex. DB admin): https://confluence.hq.unity3d.com/display/IE/Using+Vault+To+Authenticate+To+Databases 
+- Vault software Overview - https://confluence.hq.unity3d.com/display/IE/Vault+Enterprise 
+- Unsealing Vault - https://confluence.hq.unity3d.com/display/IE/Unseal+Vault
+- Vault in GKE - https://confluence.hq.unity3d.com/display/IE/Initialise+Vault+Integration+in+a+GKE+Cluster 
 Secrets Engine - https://www.vaultproject.io/docs/secrets/index.html
-AWS Resources
-
-Best Practices for Managing AWS Access Keys - https://docs.aws.amazon.com/general/latest/gr/aws-access-keys-best-practices.html
-
-Working with AWS Secrets Manager - https://docs.aws.amazon.com/secretsmanager/latest/userguide/integrating.html
-GCP Resources
+#### AWS Resources
+- Best Practices for Managing AWS Access Keys - https://docs.aws.amazon.com/general/latest/gr/aws-access-keys-best-practices.html
+- Working with AWS Secrets Manager - https://docs.aws.amazon.com/secretsmanager/latest/userguide/integrating.html
+#### GCP Resources
 
-Understanding Service Accounts - https://cloud.google.com/iam/docs/understanding-service-accounts
+- Understanding Service Accounts - https://cloud.google.com/iam/docs/understanding-service-accounts
 
-Using Environment Variables - https://cloud.google.com/functions/docs/env-var 
+- Using Environment Variables - https://cloud.google.com/functions/docs/env-var 
diff --git a/Coding Practice/Secure-Design-Principles.md b/Coding Practice/Secure-Design-Principles.md
index 343e645..b483a3c 100644
--- a/Coding Practice/Secure-Design-Principles.md	
+++ b/Coding Practice/Secure-Design-Principles.md	
@@ -1,6 +1,17 @@
 # Secure Design Principles [Coding Practice]
 <font size="-1">_Author: Carlo Valentin - Dec. 2018_</font>
 
+- [Minimize attack surface area](#minimize-attack-surface-area)
+- [Establist secure defaults](#establish-secure-defaults)
+- [Principle of least privilege](#principle-or-least-privilege)
+- [Principle of Defense in Depth](#principle-of-defense-in-depth)
+- [Fail securely](#fail-securely)
+- [Don’t trust services and validate externally sourced data](#dont-trust-services-and-validate-externally-sourced-data)
+- [Separation of duties and role based access](#separation-of-duties-and-role-based-access)
+- [Avoid security by obscurity](#avoid-security-by-obscurity)
+- [Keep security simple](#keep-security-simple)
+- [Fix security issues correctly](#fix-security-issues-correctly)
+
 ### Minimize attack surface area
 
 Every feature that is added to an application adds an unknown amount of risk to the overall application. The aim for secure development is to reduce the overall risk by reducing the attack surface, by designing features of an application to minimize the attack surface.
diff --git a/Language Guidance/Golang-Guidance.md b/Language Guidance/Golang-Guidance.md
index a97b950..a4812ff 100644
--- a/Language Guidance/Golang-Guidance.md	
+++ b/Language Guidance/Golang-Guidance.md	
@@ -11,7 +11,7 @@ Golang is a strongly typed language that has taken steps to prevent security iss
 
 ##### Security Considerations
 
-The net/http multiplexer ServeMux takes care of sanitizing the URL request path, redirecting any request containing “.” or “..” elements or repeated slashes to an equivalent, cleaner URL
+The net/http multiplexer ServeMux takes care of sanitizing the URL request path, redirecting any request containing “.” or “..” elements or repeated slashes to an equivalent, cleaner URL.
 
 ##### Recommended Packages
 
@@ -40,7 +40,7 @@ The net/http multiplexer ServeMux takes care of sanitizing the URL request path,
 - [Go Security Protections Don’t Extend To C Code](#go-security-protections-dont-extend-to-c-code)
 - [Use crypto/rand Instead Of math/rand](#use-cryptorand-instead-of-mathrand)
 
-
+---
 #### Output Encoding with Native Templates
 ###### Description
 
@@ -52,12 +52,13 @@ Using the net/http package exposes web application users to cross-site scripting
 
 Use the html/template package to automatically escape HTML, CSS, JavaScript, and URIs. If the net/http package is used, use manual escaping and manually set the Content-Type, because it is set automatically depending on what is served.
 ###### Risk Rating
-
 High
-References
 
-https://golang.org/pkg/html/template/
+###### References
+
+- https://golang.org/pkg/html/template/
  
+---
 #### Beware Output Encoding Bypasses
 ###### Description
 
@@ -96,6 +97,7 @@ High
 - https://github.com/kennygrant/sanitize
 - https://github.com/microcosm-cc/bluemonday
 
+---
 #### Go Security Protections Don’t Extend To C Code
 ###### Description
 
@@ -111,8 +113,9 @@ Be aware that C code security concerns are still present when ran by a Go applic
 High
 ###### References
 
-https://golang.org/cmd/cgo/ 
+- https://golang.org/cmd/cgo/ 
 
+---
 #### Use crypto/rand Instead Of math/rand
 ###### Description
 
@@ -155,6 +158,5 @@ This example reads 10 cryptographically secure pseudorandom numbers from rand.Re
 High
 ###### References
 
-https://golang.org/pkg/crypto/rand/
-
-https://golang.org/pkg/crypto/rand/#example_Read
\ No newline at end of file
+- https://golang.org/pkg/crypto/rand/
+- https://golang.org/pkg/crypto/rand/#example_Read
\ No newline at end of file
diff --git a/Language Guidance/Net-C#-Guidance.md b/Language Guidance/Net-C#-Guidance.md
index 9418af1..b128d03 100644
--- a/Language Guidance/Net-C#-Guidance.md	
+++ b/Language Guidance/Net-C#-Guidance.md	
@@ -6,6 +6,11 @@
 
  # Overview
 Microsoft's .Net (DotNet) framework, like most modern frameworks, is generally secure from memory corruptions and code control (ex., stack corruption) style attacks, as long as the framework is kept up-to-date with the latest version from Microsoft. However, over the years, there have been some features of the framework that are now considered unsafe, or do not provide the protections developers believe they do. Below is general guidance on what to watch out for when developing in .Net languages.
+
+- [Untrusted Code and Resource](#untrusted-code-and-resources)
+- [Handling User Input](#handling-user-input)
+
+### Recommendations
 #### Untrusted Code and Resources
 
 The following guidance is in regards to loading code or resources from an untrusted source, i.e., anything from the internet or not signed by Unity (or trusted 3rd party). When working with these types of resources, refer to the below:
@@ -27,6 +32,7 @@ In short, to quote the existing Microsoft guidance:
 
 >Code Access Security and Security-Transparent Code are not supported as a security boundary with partially trusted code. We advise against loading and executing code of unknown origins without putting alternative security measures in place.
 
+---
 #### Handling User Input
 
 The following guidance is largely relevant to ASP.Net and .Net Embedded browser support:
@@ -50,7 +56,7 @@ The following guidance is largely relevant to ASP.Net and .Net Embedded browser
 - Be wary of user names that might have more than one canonical format. For example, you can often use either the MYDOMAIN\username form or the username@mydomain.example.com form.
   - (From https://github.com/dotnet/docs/blob/master/docs/standard/security/security-and-user-input.md)
 
- 
+ ---
 ###### References:
 
 - https://github.com/dotnet/docs/blob/master/docs/standard/security/secure-coding-guidelines.md
diff --git a/Language Guidance/Nodejs-Guidance.md b/Language Guidance/Nodejs-Guidance.md
index 2536181..091a308 100644
--- a/Language Guidance/Nodejs-Guidance.md	
+++ b/Language Guidance/Nodejs-Guidance.md	
@@ -5,9 +5,17 @@
 
 
 This guide will provide general guidance for developing more secure code in Node.js.
+- [Always Validate External Inputs](#always-validate-external-inputs)
+- [HTTP Headers](#http-headers)
+- [Use of eval()](#use-of-eval)
+- [Always Use HTTPS (>TLS1.0)](#always-use-https-tls10)
+- [Localhost isn’t inherently safe from the web](#localhost-isnt-inherently-safe-from-the-web)
+- [NPM Package Tools and Risks](#npm-package-tools-and-risks)
+
+
 
 ### Recommendations
-##### Always Validate External Inputs
+#### Always Validate External Inputs
 ###### Why We Care
 
 Generally the most dangerous part of any software is the point where it will process untrusted external data. As such, it is one of the most important areas to ensure attention is given.
@@ -21,6 +29,7 @@ Generally the most dangerous part of any software is the point where it will pro
         var list = new Widget [ untrustedListSize ];
         list[0] = new Widget();
     }
+
 <sub>_(Adapted from: https://cwe.mitre.org/data/definitions/20.html)_</sub>
 
 ###### How to Fix?
@@ -38,19 +47,19 @@ Though if the underlying code is vulnerable, this will lead to High sev vulnerab
 MITRE Guidance - https://cwe.mitre.org/data/definitions/20.html  
 
 OWASP Guidance - https://www.owasp.org/index.php/Data_Validation  
-#### HTTP Headers
+
+---
+### HTTP Headers
 ###### Why We Care
 
 HTTP headers can allow a page developer to inform the browser to apply various protections against web attacks, such as Clickjacking and XSS.
-Example of Issue
 
-X-Frame-Options - Protect from clickjacking
+###### Examples of Issue
 
-Strict-Transport-Security - Enforce HTTPS and protect against downgrade attacks
-
-X-XSS-Protection - Enable XSS protections in browsers that support this header
-
-Content-Security-Policy - Can restrict code script comes from and can be executed
+- X-Frame-Options - Protect from clickjacking
+- Strict-Transport-Security - Enforce HTTPS and protect against downgrade attacks
+- X-XSS-Protection - Enable XSS protections in browsers that support this header
+- Content-Security-Policy - Can restrict code script comes from and can be executed
 ###### How to Fix?
 
 Manually review and employ headers as appropriate for your HTTP connections. OWASP has nice list of relevant headers as part of their Secure Headers Project .
@@ -62,12 +71,11 @@ Further, the Helmet package (available via npm as well) is a frequently recommen
 Low-High
 ###### References
 
-https://www.owasp.org/index.php/OWASP_Secure_Headers_Project#tab=Main  
-
-Helmet - https://www.npmjs.com/package/helmet  
+- https://www.owasp.org/index.php/OWASP_Secure_Headers_Project#tab=Main  
+- Helmet - https://www.npmjs.com/package/helmet  
 
-
-#### Use of eval()
+---
+### Use of eval()
 ###### Why We Care
 
 Use of the eval() function is incredibly dangerous, and rarely actually needed. The function allows an attacker to simply and directly execute code on the target site.
@@ -82,12 +90,11 @@ Generally, it's completely unsafe to execute untrusted code, and as such, should
 Low - High
 ###### References
 
-https://developer.mozilla.org/en-US/docs/Archive/Add-ons/Overlay_Extensions/XUL_School/Appendix_C:_Avoid_using_eval_in_Add-ons   (Talks about use in add-ons, but applies elsewhere as well)
-
-Node.js VM - https://nodejs.org/api/vm.html
-
+- https://developer.mozilla.org/en-US/docs/Archive/Add-ons/Overlay_Extensions/XUL_School/Appendix_C:_Avoid_using_eval_in_Add-ons   (Talks about use in add-ons, but applies elsewhere as well)
+- Node.js VM - https://nodejs.org/api/vm.html
 
-#### Always Use HTTPS (>TLS1.0)
+---
+### Always Use HTTPS (>TLS1.0)
 ###### Why We Care
 
 HTTP traffic is unencrypted, meaning that any traffic that goes across untrusted/uncontrolled channels is completely untrustworthy. Further, on modern computers, the perf hit for HTTPS with effectively negligible given the increase in trust gained from an encrypted channel.
@@ -103,12 +110,11 @@ Nginx TLS - https://wiki.mozilla.org/Security/Server_Side_TLS#Recommended_Server
 Med
 References
 
-https://www.eff.org/https-everywhere
+- https://www.eff.org/https-everywhere
+- https://www.maxcdn.com/blog/ssl-performance-myth/  
 
-https://www.maxcdn.com/blog/ssl-performance-myth/  
-
-
-#### Localhost isn’t inherently safe from the web
+---
+### Localhost isn’t inherently safe from the web
 ###### Why We Care
 
 We’ve found that many teams have engineered interfaces hosting local client REST services mistakenly believing that binding to localhost proved protection from remote attackers. However, localhost can be reached from a web browser, leaving these services vulnerable to attack from malicious web pages.
@@ -129,7 +135,9 @@ Medium
 
 ###### References
 
-Express has a popular CORS library: https://github.com/expressjs/cors  
+- Express has a popular CORS library: https://github.com/expressjs/cors  
+
+---
 ### NPM Package Tools and Risks
 #### npm audit
 
@@ -153,10 +161,11 @@ Further, npmjs released the npm audit fix option that should automatically addre
 The tool will provide the risk rating for each vulnerability found.
 
 ###### References
-[npm audit](https://blog.npmjs.org/post/173719309445/npm-audit-identify-and-fix-insecure)
-[npm audit fix](https://blog.npmjs.org/post/174001864165/v610-next0)
+- [npm audit](https://blog.npmjs.org/post/173719309445/npm-audit-identify-and-fix-insecure)
+- [npm audit fix](https://blog.npmjs.org/post/174001864165/v610-next0)
 
-#### Outdated Packages
+---
+### Outdated Packages
 As with all 3rd party source code, be sure to use the latest available version of the package.
 ###### Why We Care
 
@@ -172,7 +181,7 @@ Use npm update,  or leverage the npm audit command described in this document.
 The Risk Rating of the vulnerability is identified by the vendor reporting the issue.
 
 
-###Additional Reading
+### Additional Reading
 - Fun read with real world Node.js security issues: https://www.owasp.org/images/f/fa/AppSecIL2016_NodeJS-Security_LiranTal.pdf
 - Security recommendations from the Express team: https://expressjs.com/en/advanced/best-practice-security.html  
 - OWASP’s Node Goat Project: https://github.com/OWASP/NodeGoat  
diff --git a/Language Guidance/Ruby-Guidance.md b/Language Guidance/Ruby-Guidance.md
index 8d62944..8122383 100644
--- a/Language Guidance/Ruby-Guidance.md	
+++ b/Language Guidance/Ruby-Guidance.md	
@@ -44,7 +44,7 @@ Ruby gems have a signing mechanism in place, but it is not required - or widely
 - http://guides.rubyonrails.org/v3.2.8/security.html
 - https://www.owasp.org/index.php/Ruby_on_Rails_Cheatsheet
 
-### Recommendations
+## Recommendations
 #### Avoid Combing User Input with Dangerous Calls
 ###### Description
 
@@ -80,8 +80,9 @@ For executing system commands using user input, using a tool like Terrapin is pr
 High
 ###### References
 
-https://github.com/thoughtbot/terrapin
+- https://github.com/thoughtbot/terrapin
 
+---
 #### Use Proper REGEX Start and End of String Symbols
 ###### Description
 
@@ -98,22 +99,20 @@ The following REGEX filter is meant to accept only valid URLs
 
 Due to the ^ symbol use instead the \A symbol, the following submission would pass the filter because each line is processed separately and the second line matches:
 
- 
+    
 
-javascript:exploit_code();/*
+    javascript:exploit_code();/*
 
-http://hi.com
+    http://hi.com
 
-*/
+    */
 
  
 ###### How to fix?
 
 To fix this, the example issue should use the following REGEX:
 
- 
-
-/\Ahttps?:\/\/[^\n]+\z/i
+    /\Ahttps?:\/\/[^\n]+\z/i
 
  
 ###### Risk Rating
@@ -121,9 +120,9 @@ To fix this, the example issue should use the following REGEX:
 High
 ###### References
 
-http://guides.rubyonrails.org/security.html#regular-expressions
+- http://guides.rubyonrails.org/security.html#regular-expressions
 
- 
+---
 #### Ensure Dynamic Content is Encoded
 ###### Description
 
@@ -150,8 +149,9 @@ These methods of printing raw HTML to the page should only be used for trusting,
 High
 ###### References
 
-https://www.owasp.org/index.php/Ruby_on_Rails_Cheatsheet#Cross-site_Scripting_.28XSS.29
+- https://www.owasp.org/index.php/Ruby_on_Rails_Cheatsheet#Cross-site_Scripting_.28XSS.29
 
+---
 #### Exploitation of Mass Assignment (Versions 2.3.x and 3.x)
 ###### Description
 
@@ -165,16 +165,16 @@ An alternative for older versions of Rails is to blacklist specific model attrib
 
  
 
-config.active_record.whitelist_attributes = true
+    config.active_record.whitelist_attributes = true
 
 
 Whitelist example that allows access by role:
 
- 
+    
 
-attr_accessible :name
+    attr_accessible :name
 
-attr_accessible :name, :is_admin, :as => :admin
+    attr_accessible :name, :is_admin, :as => :admin
 
  
 ###### Why We Care
@@ -212,11 +212,11 @@ Do not disable strong parameters in modern versions of Rails. In older versions,
 Medium
 ###### References
 
-https://github.com/rails/strong_parameters
-
-https://github.com/grosser/strong_parameters/tree/rails2
+- https://github.com/rails/strong_parameters
+- https://github.com/grosser/strong_parameters/tree/rails2
+- http://guides.rubyonrails.org/v3.2.8/security.html#mass-assignment
 
-http://guides.rubyonrails.org/v3.2.8/security.html#mass-assignment
+---
 #### Enforce HTTPS and Strict Transport Security
 ###### Description
 
@@ -230,12 +230,12 @@ In Rails 3.1 and later, this can be accomplished by always forcing SSL connectio
 
  
 
-config.force_ssl = true
+    config.force_ssl = true
 ###### Risk Rating
 
 Medium
 
- 
+---  
 #### Prevent Logging of Sensitive Information
 ###### Description
 
@@ -249,7 +249,7 @@ When designing a Rail application, make sure to designate request parameters tha
 
  
 
-config.filter_parameters << :cc_number
+    config.filter_parameters << :cc_number
 
  
 ###### Risk Rating
@@ -257,8 +257,9 @@ config.filter_parameters << :cc_number
 Medium
 ###### References
 
-http://guides.rubyonrails.org/security.html#logging
- 
+- http://guides.rubyonrails.org/security.html#logging
+
+--- 
 #### Avoid Disabling deep_munge
 ###### Description
 
@@ -274,9 +275,9 @@ If it must be disabled, be fully aware of the vulnerabilities you are introducin
 Medium
 ###### References
 
-http://guides.rubyonrails.org/security.html#unsafe-query-generation
+- http://guides.rubyonrails.org/security.html#unsafe-query-generation
 
- 
+--- 
 #### Store the Rails Master Key in an Environmental Variable
 ###### Description
 
@@ -292,11 +293,10 @@ As with all secrets, AppSec recommends removing the key from the config/master.k
 Low
 ###### References
 
-http://guides.rubyonrails.org/security.html#custom-credentials
-
-https://confluence.hq.unity3d.com/display/IE/Vault
-
+- http://guides.rubyonrails.org/security.html#custom-credentials
+- https://confluence.hq.unity3d.com/display/IE/Vault
 
+---
 #### Don’t Allow User Input Determine Which View to Render
 ###### Description
 
@@ -310,8 +310,9 @@ Avoiding using user input to choose which view to render when certain views are
 ###### Risk Rating
 
 Low
-
-Session Fixation
+ 
+ ---
+####Session Fixation
 ###### Description
 
 Session fixation is the term for when a pre-authentication session token used as the post-authentication session token. In other words, the a new session token is not set after authenticating. This is not an issue if header-based authentication is in use.
@@ -326,4 +327,4 @@ Use the reset_session() function after a user successfully authenticates to set
 Low
 ###### References
 
-http://guides.rubyonrails.org/security.html#session-fixation-countermeasures
\ No newline at end of file
+- http://guides.rubyonrails.org/security.html#session-fixation-countermeasures
\ No newline at end of file
diff --git a/README.md b/README.md
index ec26633..43c6325 100644
--- a/README.md
+++ b/README.md
@@ -1,19 +1,39 @@
 # unity-ssdlc
+![MWU](https://unity3d.com/profiles/unity3d/themes/unity/images/mwu/logos/madewith-unity-black.svg)
+## Intro and Overview
 A public version of Unity's internal SSDLC. Meant to provide an example framework, not just to share with other, but to also take contributions and continue to improve and evolve.
 
+The Unity Security Team has spent a lot of work to improve the trustworthiness of Unity's products and services. As part of that, we developed our own internal SSDLC to help our developers design and develop more secure products. After a couple iterations, we found that we had an interesting collection of articles and trainings that may be useful for not just Unity's developers, but potentially other organizations as well. So we decided to share what we have, hopefully to contribute something back to the broader software security community.
+
+We know this isn't perfect - there's rough edges, probably some typos and embarassing grammar, and it's certainly not close to being exhaustive. But, there's definitely useful information here. Not only the actual data, but we wanted to just share with other companies what an actual, in use, SSDLC might look like.
+This this in mind, please be kind in your contructive criticism, and let us know if you've found this 
+useful!
+
+---
 ## How To Use
-`<TBD>`
+_SSDLC Guidance starts at [Overview](./Overview.md)_
+
+Feel free to clone the whole repo and use in your organization!
+We'd appreciate your feedback as well :)
   
-### SSDLC Guidance Documenation
-`<tbd>`
-### Trainings
-`<TBD>`
-#### CTF(s)
-`<TBD>`      
+## Unity SSDLC Structure
+Our SSDLC is actually a suite of offering by the Application Security team. Part documentation, part training (in person and online) and a fun CTF server we host.
+#### SSDLC Guidance Documenation
+The SSDLC guidance is an ever evolving set of documents that our team has drafted as an attempt to capture industry best practices in a single location for our developers. The guidance isn't perfect, and is always in draft. We have gaps, both in the technology we cover and how deep we are in each topic. However, we felt it better to share with our developers (and you!) as much guidance as we could provide as we developed it - it does no good for us to hoard a complete library of knowledge because we're missing _just one more article_ :)
+
+This guidance is intended to be a practical reference for developers to help them design and develop more secure products spread over 3 main topic: [Coding Practice](./Coding%Practice), [Language Guidance](./Language%20Guidance), and [Security Process](./Security%20Process).
+#### Trainings
+As a further supplemt to our SSDLC, the Unity Security team has developed several presentation to deliver more entertaining security content. The training was built with the intent to deliver the sessions in-person, as part of mini internal security conferences. Ideally, we'd also record these presentations to share with folks who can't make it to the live sessions.
+
+We can't share all our presentations here. We wanted to make these relevant and personal to the teams we present to, so many contain findings in our own products, with real-time demos of us exploiting the vulnerabilities we've discoved in our own code! In this way, developers can see the real risk of insecure code, potentially in the code they wrote themselves :) We never shame or call out teams or specifically developers - this is meant to be a learning experience, not a hurtful one.
+
+##### CTF(s)
+To go along with our mini-conferences, we also run a small CTF along side the presentations. This is meant to give our development teams the opportunity to have a hands-on experience with insecure code, starting with very simple examples, working up to more advanced challenges. This is not meant to be a full-fledged Defcon still CTF - we just want to teach some security basic, and whet the hacking appetite of our teams :) 
 
 ## Contributions
+We're still working on how to accept contributions. Once we figure out that process, we'll post the details here and open up our repo accordingly.
 
 ## License/Copyright?
 
 ## Contact Us
-`<tbd>`
+`<TBD>`
diff --git a/Security Process/Implementation-Review.md b/Security Process/Implementation-Review.md
index af6ce8a..f37cdef 100644
--- a/Security Process/Implementation-Review.md	
+++ b/Security Process/Implementation-Review.md	
@@ -60,7 +60,7 @@ AppSec will review applications by performing a code review and performing manua
 Typically an implementation review will occur over the span of one to two weeks. However ,level of effort for a review will depend on the size and risk of an application. When scheduling an implementation review an agreed upon amount of time will be decided between AppSec and the development team. If the engineer performing the design review runs into any issues, the development team will be notified immediately, and further steps will be decided.
 
 ## Things We Care About
-An application will be compared against any requirements set forth by the Audit and Compliance team. Any additional security requirements that were determined in the design review phase will also be validated during the test. The code will be reviewed against the [language-specific guidelines provided by AppSec](../Language-Guidance). A set of common vulnerabilities that AppSec maintains can also be used to check an application against. AppSec will also ensure the application follows [provided design principles](../Coding%20Practice/Secure-Design-Principles.md).
+An application will be compared against any requirements set forth by the Audit and Compliance team. Any additional security requirements that were determined in the design review phase will also be validated during the test. The code will be reviewed against the [language-specific guidelines provided by AppSec](../Language%20Guidance). A set of common vulnerabilities that AppSec maintains can also be used to check an application against. AppSec will also ensure the application follows [provided design principles](../Coding%20Practice/Secure-Design-Principles.md).
 
 ## Reporting
 At the end of an implementation review, AppSec will schedule a meeting to discuss the findings and answer any questions the development team has. Any critical issues or high issues that need immediate attention will be reported to the designated point of contact immediately. All findings will be held to the escalation process as outlined in our [[Security Process] Risk Rating (aka., Security Bug Bar)](./Risk-Rating.md).
\ No newline at end of file
diff --git a/Security Process/Security-Requirements.md b/Security Process/Security-Requirements.md
index 4458d2f..b78a702 100644
--- a/Security Process/Security-Requirements.md	
+++ b/Security Process/Security-Requirements.md	
@@ -28,4 +28,4 @@ An example of security requirements that an application can encounter:
 
 ### Once I have these requirements, what do I do?
 
-A failure or flaw in the implementation of a security-related requirement can lead to additional various vulnerabilities or in some cases require a re-architecting of the application. As such, care needs to be taken when implementing the identified requirements. If you and your team are unsure about the design or implementation of security requirements, please schedule a [design review](./Design-Review.md) or [implementation review](./Implementation-Review.md) with the AppSec team in #support-security.
+A failure or flaw in the implementation of a security-related requirement can lead to additional various vulnerabilities or in some cases require a re-architecting of the application. As such, care needs to be taken when implementing the identified requirements. If you and your team are unsure about the design or implementation of security requirements, please schedule a [design review](./Design-Review.md) or [implementation review](./Implementation-Review.md) with the Unity AppSec team.

From 4a0d493024e83342840266b5c9e4cbdd3d02c302 Mon Sep 17 00:00:00 2001
From: Brandon Caldwell <brandonc@unity3d.com>
Date: Mon, 20 May 2019 18:22:40 -0700
Subject: [PATCH 16/54] Adding placeholders for a couple folder... Soon(TM)

---
 Tools and Automation/readme.md | 1 +
 Trainings/readme.md            | 1 +
 2 files changed, 2 insertions(+)
 create mode 100644 Tools and Automation/readme.md
 create mode 100644 Trainings/readme.md

diff --git a/Tools and Automation/readme.md b/Tools and Automation/readme.md
new file mode 100644
index 0000000..b005f9f
--- /dev/null
+++ b/Tools and Automation/readme.md	
@@ -0,0 +1 @@
+Soon™
\ No newline at end of file
diff --git a/Trainings/readme.md b/Trainings/readme.md
new file mode 100644
index 0000000..b005f9f
--- /dev/null
+++ b/Trainings/readme.md
@@ -0,0 +1 @@
+Soon™
\ No newline at end of file

From d4f26ef018dd5bce280faf02e7bba4f43708815f Mon Sep 17 00:00:00 2001
From: Brandon Caldwell <brandonc@unity3d.com>
Date: Tue, 21 May 2019 15:39:52 -0700
Subject: [PATCH 17/54] Trying to fix logo size...

---
 README.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/README.md b/README.md
index 43c6325..604c99e 100644
--- a/README.md
+++ b/README.md
@@ -1,5 +1,5 @@
 # unity-ssdlc
-![MWU](https://unity3d.com/profiles/unity3d/themes/unity/images/mwu/logos/madewith-unity-black.svg)
+![MWU](https://unity3d.com/profiles/unity3d/themes/unity/images/mwu/logos/madewith-unity-black.svg =800x)
 ## Intro and Overview
 A public version of Unity's internal SSDLC. Meant to provide an example framework, not just to share with other, but to also take contributions and continue to improve and evolve.
 
@@ -28,7 +28,7 @@ As a further supplemt to our SSDLC, the Unity Security team has developed severa
 We can't share all our presentations here. We wanted to make these relevant and personal to the teams we present to, so many contain findings in our own products, with real-time demos of us exploiting the vulnerabilities we've discoved in our own code! In this way, developers can see the real risk of insecure code, potentially in the code they wrote themselves :) We never shame or call out teams or specifically developers - this is meant to be a learning experience, not a hurtful one.
 
 ##### CTF(s)
-To go along with our mini-conferences, we also run a small CTF along side the presentations. This is meant to give our development teams the opportunity to have a hands-on experience with insecure code, starting with very simple examples, working up to more advanced challenges. This is not meant to be a full-fledged Defcon still CTF - we just want to teach some security basic, and whet the hacking appetite of our teams :) 
+To go along with our mini-conferences, we also run a small CTF along side the presentations. This is meant to give our development teams the opportunity to have a hands-on experience with insecure code, starting with very simple examples, working up to more advanced challenges. This is not meant to be a full fledged Defcon-style CTF - we just want to teach some security basic, and whet the hacking appetite of our teams :) 
 
 ## Contributions
 We're still working on how to accept contributions. Once we figure out that process, we'll post the details here and open up our repo accordingly.

From a4372f7e4cc5815cc8a78b6e244fa99d2a05fcda Mon Sep 17 00:00:00 2001
From: Brandon Caldwell <brandonc@unity3d.com>
Date: Tue, 21 May 2019 15:40:48 -0700
Subject: [PATCH 18/54] Still figuring out Github Markdown image sizing...

---
 README.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/README.md b/README.md
index 604c99e..9ac53a8 100644
--- a/README.md
+++ b/README.md
@@ -1,5 +1,5 @@
 # unity-ssdlc
-![MWU](https://unity3d.com/profiles/unity3d/themes/unity/images/mwu/logos/madewith-unity-black.svg =800x)
+![MWU](https://unity3d.com/profiles/unity3d/themes/unity/images/mwu/logos/madewith-unity-black.svg | width=800)
 ## Intro and Overview
 A public version of Unity's internal SSDLC. Meant to provide an example framework, not just to share with other, but to also take contributions and continue to improve and evolve.
 

From 6ab67c5614401a1f9711e9ee29ae8de0e8cfbf8b Mon Sep 17 00:00:00 2001
From: Brandon Caldwell <brandonc@unity3d.com>
Date: Tue, 21 May 2019 15:43:31 -0700
Subject: [PATCH 19/54] Switching to HTML for rendering the image - all good
 now.

---
 README.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/README.md b/README.md
index 9ac53a8..3c72348 100644
--- a/README.md
+++ b/README.md
@@ -1,5 +1,5 @@
 # unity-ssdlc
-![MWU](https://unity3d.com/profiles/unity3d/themes/unity/images/mwu/logos/madewith-unity-black.svg | width=800)
+<img src="https://unity3d.com/profiles/unity3d/themes/unity/images/mwu/logos/madewith-unity-black.svg" style="width:400px" alt="MWU"></img>
 ## Intro and Overview
 A public version of Unity's internal SSDLC. Meant to provide an example framework, not just to share with other, but to also take contributions and continue to improve and evolve.
 

From f95946b72511dbb8488b21e8bec50d2937eaf8b4 Mon Sep 17 00:00:00 2001
From: Brandon Caldwell <brandonc@unity3d.com>
Date: Tue, 21 May 2019 15:44:25 -0700
Subject: [PATCH 20/54] Still tweaking...

---
 README.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/README.md b/README.md
index 3c72348..4f3687c 100644
--- a/README.md
+++ b/README.md
@@ -1,5 +1,5 @@
 # unity-ssdlc
-<img src="https://unity3d.com/profiles/unity3d/themes/unity/images/mwu/logos/madewith-unity-black.svg" style="width:400px" alt="MWU"></img>
+<img src="https://unity3d.com/profiles/unity3d/themes/unity/images/mwu/logos/madewith-unity-black.svg" style="width:300px" alt="MWU"></img>
 ## Intro and Overview
 A public version of Unity's internal SSDLC. Meant to provide an example framework, not just to share with other, but to also take contributions and continue to improve and evolve.
 

From d3aae97c0f4d9dcb4915fdc9539daebe570040b7 Mon Sep 17 00:00:00 2001
From: Brandon Caldwell <brandonc@unity3d.com>
Date: Mon, 8 Jul 2019 15:37:06 -0700
Subject: [PATCH 21/54] Did some more cleanup, largely around removing
 internal-only links, like Confluence. Also, removed a couple mentions around
 Unity's secret leaks, and generalized them to the industry problem.  Shrank
 the image on the readme a bit. Also added Carlo's more detailed bug bar.

---
 Coding Practice/AuthZ-AuthN-Guidelines.md     |   6 +--
 Coding Practice/Cryptographic-Guidelines.md   |  17 +++----
 .../Preventing-Common-Web-Attacks.md          |  17 ++++---
 Coding Practice/Secrets-Management.md         |   9 +---
 LICENSE => LICENSE.md                         |   0
 Language Guidance/Ruby-Guidance.md            |   1 -
 README.md                                     |   4 +-
 Security Process/Design-Review.md             |   2 +-
 Security Process/Unity-Bug-Bar.md             |  42 +++++++++++++++++-
 images/madewith-unity-black.png               | Bin 0 -> 6858 bytes
 10 files changed, 66 insertions(+), 32 deletions(-)
 rename LICENSE => LICENSE.md (100%)
 create mode 100644 images/madewith-unity-black.png

diff --git a/Coding Practice/AuthZ-AuthN-Guidelines.md b/Coding Practice/AuthZ-AuthN-Guidelines.md
index c422711..b8247b7 100644
--- a/Coding Practice/AuthZ-AuthN-Guidelines.md	
+++ b/Coding Practice/AuthZ-AuthN-Guidelines.md	
@@ -18,15 +18,15 @@ This document provides guidelines for how to implement authentication and author
 ### Use a Trusted Identity Provider
 ###### Description
 
-Most of our users will be accessing services related to Unity, and we should leverage Genesis and Unity ID to authenticate those users to any new services or publicly facing applications. Using a single, unified identity to authenticate a user will make it easy for the user to use a new service and application.
+Most of our users will be accessing services related to Unity, and we should Unity ID to authenticate those users to any new services or publicly facing applications. Using a single, unified identity to authenticate a user will make it easy for the user to use a new service and application.
 
-When creating internal applications, Active Directory should be used to validate a user using their known credentials. In the future, this will be replaced with integration with Okta to authenticate a user.
+When creating internal applications, validate users via their IT issued credentials. 
 ###### Why We Care
 
 Many services will require authentication as a requirement. No authentication allows for anonymous access, which prevents proper logging and brings the risk of trivial information disclosure. However, designing an entire authentication service for you an application is also no trivial task, with many caveats that can lead to leaked/bypassed credentials, and a number of other issues. By using a trusted identity provider, the security team can work on securing a small number of authentication platforms to the benefit of a number of teams at Uniyt.
 ###### How to Fix?
 
-Determine if your application is an internal or external application. If it is external, contact Genesis and Security to integrate your application with Unity ID. If it is internal, contact IT to integrate with Active Directory (and Okta in the future).
+Determine if your application is an internal or external application. If it is external, contact Genesis and Security to integrate your application with Unity ID. If it is internal, contact IT to integrate with out internal authentication system.
 ###### Risk Rating
 
 High
diff --git a/Coding Practice/Cryptographic-Guidelines.md b/Coding Practice/Cryptographic-Guidelines.md
index 36900bc..2bdaa73 100644
--- a/Coding Practice/Cryptographic-Guidelines.md	
+++ b/Coding Practice/Cryptographic-Guidelines.md	
@@ -4,15 +4,19 @@
 ## Guidelines Overview
 
 Cryptographic requirements at Unity are heavily influenced by NIST's *Cryptographic Standards and Guidelines (CSRC)* documentation. Below are our condensed recommendations.
+### Recommended Libraries
+- [libsodium](https://libsodium.org) - _([Github](https://github.com/jedisct1/libsodium))_
+- [OpenSSL](https://www.openssl.org/) - _([Github](https://github.com/openssl/openssl))_
+
+> NOTE: Where possible, we recommend Elliptic Curve Cryptography (ECC / ECDH), with Curve25519 (for signatures and key exchange)
 
 ### Usage Guidance
-###### TLS - Cipher Suites
+##### TLS - Cipher Suites
 
 _Minimum TLS version = TLS1.2._
-All cipher suites below should be compatible with version > TLS 1.2.  
-SSL 3.0 and below are not allowed, and considered unsafe.
+All cipher suites below should be compatible with version >= TLS 1.2.  
+SSL 3.0 and below are not allowed.
 Accepted TLS Cipher suites:
-- TLS_RSA_WITH_3DES_EDE_CBC_SHA
 - TLS_RSA_WITH_AES_128_CBC_SHA
 - TLS_RSA_WITH_AES_256_CBC_SHA
 - TLS_RSA_WITH_AES_128_GCM_SHA256
@@ -22,13 +26,10 @@ Accepted TLS Cipher suites:
 - TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
 - TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
 - TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
-- TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA
 - TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
-- TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
 - TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
-<sub>3DES ciphers are accepted for maximum interoperability - other ciphers should be chosen as 3DES will likely be deprecated</sub>
 
-###### Hash Algorithms
+##### Hash Algorithms
 
 - Language Agnostic
   - SHA-512
diff --git a/Coding Practice/Preventing-Common-Web-Attacks.md b/Coding Practice/Preventing-Common-Web-Attacks.md
index 90bbc05..83dd1aa 100644
--- a/Coding Practice/Preventing-Common-Web-Attacks.md	
+++ b/Coding Practice/Preventing-Common-Web-Attacks.md	
@@ -23,9 +23,9 @@ Clickjacking, also known as a "UI redress attack", occurs when an attacker uses
 With this attack an attacker can trick the user into performing sensitive actions on a page that only the user has access to.
 ###### Example of Issue
 
-Say that we have a “Pay out” button on our internal Ads Payout tool and the application does not implement any protection against Clickjacking. An attacker that knows the internal URL for the tool can now include a hidden iframe on his site www.cuteandfunnypuppies.com:
+Say that we have a “Pay out” button on our internal Ads Payout tool and the application does not implement any protection against Clickjacking. An attacker that knows the internal URL for the tool can now include a hidden iframe on his site `www.cute-and-funny-puppies.net`:
 
-<iframe src=”https://ads-payout-tool.hq.unity3d.com” style=”opacity:100”></iframe>
+<iframe src=”https://ads-awesome-payout-tool.unity3d.com” style=”opacity:100”></iframe>
 
 When an admin that gets bored of approving payouts visits the attacker’s site to view some funny dog pictures, he simultaneously gets tricked into approving a payout for an attacker by clicking an element on the site that really clicks the payout button in the hidden iframe.
 ###### How to Fix?
@@ -53,11 +53,11 @@ Setting HTTP Security headers mostly protects your users by turning on security
 ###### Example of Issue
 
 For example: Almost all web applications redirect from HTTP->HTTPS so that users don’t have to type https:// at the start of the url when they visit your site. However, if the user already had an active session on the site, the browser might send some sensitive information on that very first HTTP request before it gets redirected. This information can be sniffed by an attacker unless we take some precautions and tell it to always browse Unity applications over an encrypted connection. This is one example of an issue that HTTP Security headers can help with.
-How to Fix?
+###### How to Fix?
 
 We have a whole page dedicated to setting HTTP Security Headers which can be found here:
+[HTTP Header Security](./Coding%20Practive/HTTP-Header-Security.md)
 
-https://confluence.hq.unity3d.com/display/SEC/HTTP+Header+Security
 
 Read through the recommendations, add your headers in the early phases of the project, and make sure to choose a modern front-end technology that is friendly to Content Security Policy.
 ###### Security Level
@@ -69,9 +69,8 @@ Mozilla has a great web security guideline reference here which includes a lot a
 
 https://infosec.mozilla.org/guidelines/web_security
 
-Unity's Security Teams has a tool for checking how your application grades based on its security headers here:
-
-https://appcollector.internal.unity3d.com/observatory/
+Unity's Security Team has a tool for checking how your application grades based on its security headers here:
+[AppCollector](https://github.com/UnityTech/appcollector/) - _(Currently Internal Only - Public Release TBD)_
 
 ---
 ### Preventing XSS
@@ -246,7 +245,7 @@ Application development requires integration with a growing number of services.
 Secrets are secret for a reason and often provide access to a lot of data, computing resources or privileged accounts. It is therefore crucial that we handle secrets well, and make the probability of accidental leaks as small as possible.
 ###### Example of Issue
 
-We’ve had many instances of Unity credentials leaked via public Git repos. This could have given malicious actors access to internal systems, data, apis and more. There have also been other examples such as accidentally hosting script files that contain credentials on a public web server.
+Credential leaks to Github is a common, and troublesome issue within the industry. This can give malicious actors access to internal systems, data, apis and more. There are also other examples, such as accidentally hosting script files that contain credentials on a public web server.
 ###### How to Fix?
 
 When developing an application it is best practice to load secrets from environment variables.
@@ -263,4 +262,4 @@ Security Level
 Leaking credentials can be critical as they often grant a high level of access to Unity systems and can lead to compromise of data and systems.
 References
 
-https://confluence.hq.unity3d.com/display/SEC/Secret-Finder
+https://github.com/UnityTech/Secret-Finder - _(Currently Internal Only - Public Release TBD)
diff --git a/Coding Practice/Secrets-Management.md b/Coding Practice/Secrets-Management.md
index 5d310b6..989b8f9 100644
--- a/Coding Practice/Secrets-Management.md	
+++ b/Coding Practice/Secrets-Management.md	
@@ -11,7 +11,7 @@ The secrets need to be high-entropy, unique per service, and unique per environm
 Secrets are secret for a reason, and often provide access to a lot of data, computing resources or privileged accounts. It is therefore crucial that we handle secrets well, ensure we limit their scope and use least privilege, and make the probability of accidental leaks as small as possible. (See Unity's Common Control Framework security controls CCF-4.04 and CCF-4.05)
 ### Examples of Problematic/Incorrect Secrets Use
 
-We’ve had many instances of Unity credentials leaked via public Git repos. This could have given malicious actors access to internal systems, data, APIs and more. There have also been other examples such as accidentally hosting script files that contain credentials on a public web server.
+Credential leaks to Github are a common, and troublesome issue within the industry. This can give malicious actors access to internal systems, data, apis and more. There are also other examples, such as accidentally hosting script files that contain credentials on a public web server.
 
 It should go without saying, but when your credentials fall into someone else’s hands they can assume any of your privileges. A common example we see is someone granting themselves “Admin” so they do not have to concern themselves with identifying precisely the minimum privileges needed. They may only use these credentials for a small handful of API calls but when these credentials are exposed, a malicious actor can do anything “Admin” can do. These credentials are often exploited for launching cryptominers, ransomware attacks, or setting up backdoors for later use.
 
@@ -129,7 +129,7 @@ For secure, maintainable key handling the following criteria must be adhered to:
 
 Leaking credentials can be critical as they often grant a high level of access to Unity systems and can lead to compromise of data and systems. Credential leaks are historically a serious source of breaches throughout the industry, and require very little expertise from attackers to exploit. 
 
-######Risk Rating:
+###### Risk Rating:
 High
  
 ---
@@ -156,11 +156,6 @@ Similar to the answer above, but this can be slightly more nuanced. If the test
 
 ## APPENDIX
 #### Vault Guidance
-- Vault for developers: https://confluence.hq.unity3d.com/display/IE/Using+Vault+in+IE+Infra 
-- Vault for shared accounts (ex. DB admin): https://confluence.hq.unity3d.com/display/IE/Using+Vault+To+Authenticate+To+Databases 
-- Vault software Overview - https://confluence.hq.unity3d.com/display/IE/Vault+Enterprise 
-- Unsealing Vault - https://confluence.hq.unity3d.com/display/IE/Unseal+Vault
-- Vault in GKE - https://confluence.hq.unity3d.com/display/IE/Initialise+Vault+Integration+in+a+GKE+Cluster 
 Secrets Engine - https://www.vaultproject.io/docs/secrets/index.html
 #### AWS Resources
 - Best Practices for Managing AWS Access Keys - https://docs.aws.amazon.com/general/latest/gr/aws-access-keys-best-practices.html
diff --git a/LICENSE b/LICENSE.md
similarity index 100%
rename from LICENSE
rename to LICENSE.md
diff --git a/Language Guidance/Ruby-Guidance.md b/Language Guidance/Ruby-Guidance.md
index 8122383..fb641b2 100644
--- a/Language Guidance/Ruby-Guidance.md	
+++ b/Language Guidance/Ruby-Guidance.md	
@@ -294,7 +294,6 @@ Low
 ###### References
 
 - http://guides.rubyonrails.org/security.html#custom-credentials
-- https://confluence.hq.unity3d.com/display/IE/Vault
 
 ---
 #### Don’t Allow User Input Determine Which View to Render
diff --git a/README.md b/README.md
index 4f3687c..58c1e00 100644
--- a/README.md
+++ b/README.md
@@ -1,5 +1,5 @@
 # unity-ssdlc
-<img src="https://unity3d.com/profiles/unity3d/themes/unity/images/mwu/logos/madewith-unity-black.svg" style="width:300px" alt="MWU"></img>
+<img src="./images/madewith-unity-black.png" style="width:300px" alt="MWU"></img>
 ## Intro and Overview
 A public version of Unity's internal SSDLC. Meant to provide an example framework, not just to share with other, but to also take contributions and continue to improve and evolve.
 
@@ -36,4 +36,4 @@ We're still working on how to accept contributions. Once we figure out that proc
 ## License/Copyright?
 
 ## Contact Us
-`<TBD>`
+[`security@unity3d.com`](mailto:security@unity3d.com)
diff --git a/Security Process/Design-Review.md b/Security Process/Design-Review.md
index d1a081f..9f2bdbd 100644
--- a/Security Process/Design-Review.md	
+++ b/Security Process/Design-Review.md	
@@ -6,7 +6,7 @@
 Design reviews and threat modelling are key components of ensuring a secure development lifecycle. A design review allows the security team to review an application’s specification and design against security best practices and design patterns. Coupled with a threat model, the development team will be able to determine the need or design of security controls needed for an application. By involving AppSec early on in the process, security will be a consideration throughout the development lifecycle - reducing the amount of security issues that will occur during the implementation and testing phases.
 #### Requesting a Design Review
 
-A design review can occur at any point in the development life cycle depending on the situation. Ideally, a design review is performed before any code has been written for an application or service, occurring during the design phase of software development. This is the best time to make adjustments to the application design. Once an application has a design specification and the development team has gathered the appropriate requirements for an application is when the design review should occur. Design reviews can also be performed prior to a security review if AppSec is not familiar with the application. When requesting an design review, please contact Application Security (AppSec) to schedule a meeting and review scope. Contact AppSec by putting a message in Slack at #support-security.
+A design review can occur at any point in the development life cycle depending on the situation. Ideally, a design review is performed before any code has been written for an application or service, occurring during the design phase of software development. This is the best time to make adjustments to the application design. Once an application has a design specification and the development team has gathered the appropriate requirements for an application is when the design review should occur. Design reviews can also be performed prior to a security review if AppSec is not familiar with the application. When requesting an design review, please contact Application Security (AppSec) to schedule a meeting and review scope.
 #### Requirements
 
 When requesting a design review, the development team will need to provide documentation and diagrams related to the new application. The following is a non-comprehensive list of documentation that will help a design review go smoothly. While they are not hard requirements for a design review, AppSec cannot guarantee the quality of the review without materials provided by the development team.
diff --git a/Security Process/Unity-Bug-Bar.md b/Security Process/Unity-Bug-Bar.md
index 5f41518..306e3ef 100644
--- a/Security Process/Unity-Bug-Bar.md	
+++ b/Security Process/Unity-Bug-Bar.md	
@@ -1,5 +1,5 @@
 # Unity Security Bug Bar
-<font size="-1">_Michael De Libero - Nov 2018_</font>
+<font size="-1">_Michael De Libero & Carlo Valentin - Nov 2018_</font>
 ## Overview
 This outlines a standard rating scale for software security issues both internally and externally found. The goal for this is to set a remediation timeline expectation and to give insight into how we rate issues. The bars specified are the minimum bars, meaning some issues depending on the circumstances could be rated higher. 
 
@@ -106,3 +106,43 @@ The bar allows us to triage security bugs to ensure those that are most severe w
 ##### How does the bar direct patching and releasing security updates for the Editor?
 High and above will require a patch gets created and released for our customers. If at all possible we should work on getting these fixes in with patches that are already going out. Lows will be filed and the team owning the feature can address it as a normal bug.
 
+##### What are some examples of the table above applied to actual attack types?
+The below table has many examples of common attacks and how they would land on the bug bar described above:
+|          |                                                             |                                              |                |                    | 
+|----------|-------------------------------------------------------------|----------------------------------------------|----------------|--------------------| 
+| Severity | Finding                                                     | Category                                     | Finding Impact | Finding Likelihood | 
+| Critical | Internet Accessible Remote Code Execution                   | Remote Code Execution (RCE)                  | High           | High               | 
+|          | Stored Cross Site Scripting on unity.com                    | Cross-Site Scripting (XSS)                   | High           | High               | 
+|          | Administrative Privilege Escalation                         | Broken Access Control/Authorization (BAC)    | High           | High               | 
+|          | Authentication Bypass  w/ Access to User Data               | Broken Authentication and Session Management | High           | High               | 
+|          |                                                             |                                              |                |                    | 
+| High     | Remote Code Execution on an isolated instance               | Remote Code Execution (RCE)                  | Medium         | High               | 
+|          | Partial Privilege Escalation                                | Broken Access Control/Authorization (BAC)    | Medium         | High               | 
+|          | Production Secrets in Code Repository                       | Sensitive Data Exposure                      | High           | Medium             | 
+|          | Server-side Request Forgery w/ accessible internal services | Server-Side Injection                        | High           | Medium             | 
+|          | Cross site request forgery for sensitive data               | Cross-Site Request Forgery (CSRF)            | Medium         | High               | 
+|          | Access Token Leak resulting in full account compromise      | Sensitive Data Exposure                      | High           | Medium             | 
+|          | Reflected Cross-Site Scripting                              | Cross-Site Scripting (XSS)                   | Medium         | High               | 
+|          | Persistent remote denial of service                         | Denial-of-Service (DoS)                      | High           | Medium             | 
+|          | No TLS/HTTPS/Transport Encryption on sensitive service      | Insecure Data Transport                      | High           | Medium             | 
+|          |                                                             |                                              |                |                    | 
+| Medium   | Cross site request forgery for non-sensitive data           | Cross-Site Request Forgery (CSRF)            | Medium         | Medium             | 
+|          | Server-side Request Forgery (Info Disclosure)               | Server-Side Injection                        | Medium         | Medium             | 
+|          | Session Fixation                                            | Broken Authentication and Session Management | Medium         | Medium             | 
+|          | Access Token Leak w/ Limited Scope                          | Sensitive Data Exposure                      | Low            | High               | 
+|          | Multi-factor authentication bypass                          | Broken Authentication and Session Management | High           | Low                | 
+|          | Multi-packet Denial of Service                              | Denial-of-Service (DoS)                      | Medium         | Medium             | 
+|          | No TLS/HTTPS/Transport Encryption on non-sensitive service  | Insecure Data Transport                      | Medium         | Medium             | 
+|          | Insecure Cryptographic Options                              | Broken Cryptography                          | High           | Low                | 
+|          | Publicly Accessible Google Groups                           | Insufficient Security Configurability        | Medium         | Medium             | 
+|          | Cookie Flags                                                | Server Security Misconfiguration             | Low            | High               | 
+|          |                                                             |                                              |                |                    | 
+| Low      | Clickjacking                                                | Server Security Misconfiguration             | Low            | Medium             | 
+|          | Open Redirect                                               | Unvalidated Redirects and Forwards           | Low            | Medium             | 
+|          | Multi-packet DoS                                            | Denial-of-Service (DoS)                      | Low            | Medium             | 
+|          | Leaked HTTP Headers                                         | Server Security Misconfiguration             | Low            | Medium             | 
+|          | Information Disclosure                                      | Sensitive Data Exposure                      | Low            | Medium             | 
+|          | Open CORS Policy                                            | Server Security Misconfiguration             | Low            | Medium             | 
+|          | Tabnabbing                                                  | Unvalidated Redirects and Forwards           | Low            | Low                | 
+
+
diff --git a/images/madewith-unity-black.png b/images/madewith-unity-black.png
new file mode 100644
index 0000000000000000000000000000000000000000..092dac4149d9581ecc33180eca82eabf3c1e2cb3
GIT binary patch

From 6514456f95cdb3e809adf4b2d956cebd86539c2b Mon Sep 17 00:00:00 2001
From: Brandon Caldwell <brandonc@unity3d.com>
Date: Thu, 25 Jul 2019 09:50:17 -0700
Subject: [PATCH 22/54] Removed 'guidance' from the Readme.md and added the
 copyright. Other misc. changes.

---
 .../Preventing-Common-Web-Attacks.md           |  4 ++--
 Language Guidance/Net-C#-Guidance.md           |  6 ++----
 Language Guidance/Nodejs-Guidance.md           |  2 +-
 README.md                                      | 18 +++++++++++-------
 4 files changed, 16 insertions(+), 14 deletions(-)

diff --git a/Coding Practice/Preventing-Common-Web-Attacks.md b/Coding Practice/Preventing-Common-Web-Attacks.md
index 83dd1aa..496decf 100644
--- a/Coding Practice/Preventing-Common-Web-Attacks.md	
+++ b/Coding Practice/Preventing-Common-Web-Attacks.md	
@@ -245,7 +245,7 @@ Application development requires integration with a growing number of services.
 Secrets are secret for a reason and often provide access to a lot of data, computing resources or privileged accounts. It is therefore crucial that we handle secrets well, and make the probability of accidental leaks as small as possible.
 ###### Example of Issue
 
-Credential leaks to Github is a common, and troublesome issue within the industry. This can give malicious actors access to internal systems, data, apis and more. There are also other examples, such as accidentally hosting script files that contain credentials on a public web server.
+Credential leaks to Github are a common, and troublesome issue within the industry. This can give malicious actors access to internal systems, data, apis and more. There are also other examples, such as accidentally hosting script files that contain credentials on a public web server.
 ###### How to Fix?
 
 When developing an application it is best practice to load secrets from environment variables.
@@ -262,4 +262,4 @@ Security Level
 Leaking credentials can be critical as they often grant a high level of access to Unity systems and can lead to compromise of data and systems.
 References
 
-https://github.com/UnityTech/Secret-Finder - _(Currently Internal Only - Public Release TBD)
+https://github.com/UnityTech/Secret-Finder - _(Currently Internal Only - Public Release TBD)_
diff --git a/Language Guidance/Net-C#-Guidance.md b/Language Guidance/Net-C#-Guidance.md
index b128d03..46d0539 100644
--- a/Language Guidance/Net-C#-Guidance.md	
+++ b/Language Guidance/Net-C#-Guidance.md	
@@ -24,11 +24,9 @@ The following guidance is in regards to loading code or resources from an untrus
   - Solution: Use DataContractSerialiazer as part of serializing objects.
 - Do not use Distributed Component Object Model (DCOM).
   - Problem: Again, thanks to James Forshaw, it was determined that DCOM was generally unsafe, and has issues with safe (or unsafe?) object serialization.
-  - Solution: Don't use it at all. Consider named pipes for local services (available cross-platform). Avoid HTTP/REST-like endpoints if possible, as they can be difficult to protect against browser attacks - see UNITY-SEC-844.
+  - Solution: Don't use it at all. Consider named pipes for local services (available cross-platform). Avoid HTTP/REST-like endpoints if possible, as they can be difficult to protect against browser attacks - see [CVE-2017-12939](https://unity3d.com/security#CVE-2017-12939).
 
- 
-
-In short, to quote the existing Microsoft guidance:
+In short, to quote the existing [Microsoft guidance](https://docs.microsoft.com/en-us/dotnet/standard/security/secure-coding-guidelines):
 
 >Code Access Security and Security-Transparent Code are not supported as a security boundary with partially trusted code. We advise against loading and executing code of unknown origins without putting alternative security measures in place.
 
diff --git a/Language Guidance/Nodejs-Guidance.md b/Language Guidance/Nodejs-Guidance.md
index 091a308..bec6544 100644
--- a/Language Guidance/Nodejs-Guidance.md	
+++ b/Language Guidance/Nodejs-Guidance.md	
@@ -120,7 +120,7 @@ References
 We’ve found that many teams have engineered interfaces hosting local client REST services mistakenly believing that binding to localhost proved protection from remote attackers. However, localhost can be reached from a web browser, leaving these services vulnerable to attack from malicious web pages.
 ###### Example of Issue
 
-See UNITY-SEC-844 @ https://unity3d.com/security#issues
+See CVE-2017-12939 @ https://unity3d.com/security#CVE-2017-12939
 
 This vulnerability was a remote code execution vulnerability found in the Unity Editor wherein, if a malicious website was opened by a user, the attacker could run arbitrary code on the victim’s machine, via a REST service bound to localhost , running in the Editor.
 ###### How to Fix?
diff --git a/README.md b/README.md
index 58c1e00..f805250 100644
--- a/README.md
+++ b/README.md
@@ -1,7 +1,7 @@
 # unity-ssdlc
 <img src="./images/madewith-unity-black.png" style="width:300px" alt="MWU"></img>
 ## Intro and Overview
-A public version of Unity's internal SSDLC. Meant to provide an example framework, not just to share with other, but to also take contributions and continue to improve and evolve.
+A public version of Unity's internal Secure Software Development Lifecycle (SSDLC). Meant to provide an example framework, not just to share with other, but to also take contributions and continue to improve and evolve.
 
 The Unity Security Team has spent a lot of work to improve the trustworthiness of Unity's products and services. As part of that, we developed our own internal SSDLC to help our developers design and develop more secure products. After a couple iterations, we found that we had an interesting collection of articles and trainings that may be useful for not just Unity's developers, but potentially other organizations as well. So we decided to share what we have, hopefully to contribute something back to the broader software security community.
 
@@ -11,17 +11,17 @@ useful!
 
 ---
 ## How To Use
-_SSDLC Guidance starts at [Overview](./Overview.md)_
+_SSDLC starts at [Overview](./Overview.md)_
 
 Feel free to clone the whole repo and use in your organization!
 We'd appreciate your feedback as well :)
   
 ## Unity SSDLC Structure
 Our SSDLC is actually a suite of offering by the Application Security team. Part documentation, part training (in person and online) and a fun CTF server we host.
-#### SSDLC Guidance Documenation
-The SSDLC guidance is an ever evolving set of documents that our team has drafted as an attempt to capture industry best practices in a single location for our developers. The guidance isn't perfect, and is always in draft. We have gaps, both in the technology we cover and how deep we are in each topic. However, we felt it better to share with our developers (and you!) as much guidance as we could provide as we developed it - it does no good for us to hoard a complete library of knowledge because we're missing _just one more article_ :)
+#### SSDLC  Documentation
+The SSDLC is an ever evolving set of documents that our team has drafted as an attempt to capture industry best practices in a single location for our developers. The recommendations aren't perfect, and are always in draft. We have gaps, both in the technology we cover and how deep we are in each topic. However, we felt it better to share with our developers (and you!) as much as we could  - it does no good for us to hoard a complete library of knowledge because we're missing _just one more article_ :)
 
-This guidance is intended to be a practical reference for developers to help them design and develop more secure products spread over 3 main topic: [Coding Practice](./Coding%Practice), [Language Guidance](./Language%20Guidance), and [Security Process](./Security%20Process).
+This SSDLC is intended to be a practical reference for developers to help them design and develop more secure products spread over 3 main topic: [Coding Practice](./Coding%Practice), [Language Guidance](./Language%20Guidance), and [Security Process](./Security%20Process).
 #### Trainings
 As a further supplemt to our SSDLC, the Unity Security team has developed several presentation to deliver more entertaining security content. The training was built with the intent to deliver the sessions in-person, as part of mini internal security conferences. Ideally, we'd also record these presentations to share with folks who can't make it to the live sessions.
 
@@ -33,7 +33,11 @@ To go along with our mini-conferences, we also run a small CTF along side the pr
 ## Contributions
 We're still working on how to accept contributions. Once we figure out that process, we'll post the details here and open up our repo accordingly.
 
-## License/Copyright?
-
 ## Contact Us
 [`security@unity3d.com`](mailto:security@unity3d.com)
+
+## License
+License found in:[LICENSE.md](./LICENSE.md)
+
+_Copyright © 2018-2019 Unity Technologies APS_
+

From 34b22537e3b4e2c657ec597b9d018ca0c0367804 Mon Sep 17 00:00:00 2001
From: Brandon Caldwell <brandonc@unity3d.com>
Date: Thu, 25 Jul 2019 10:00:13 -0700
Subject: [PATCH 23/54] Added disclaimer and updated copyright to readme.md

---
 README.md | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/README.md b/README.md
index f805250..5901ae5 100644
--- a/README.md
+++ b/README.md
@@ -39,5 +39,12 @@ We're still working on how to accept contributions. Once we figure out that proc
 ## License
 License found in:[LICENSE.md](./LICENSE.md)
 
-_Copyright © 2018-2019 Unity Technologies APS_
+Copyright © 2019 Unity Technologies
+ 
+## Disclaimer
+
+THE INFORMATION PROVIDED HERE DOES NOT REPRESENT OR DESCRIBE ALL OF UNITY’S SSDLC PRACTICES, AND, AS SUCH, DOES NOT REPRESENT ALL PROCESSES EMPLOYED BY UNITY CONCERNING SOFTWARE SECURITY. THE INFORMATION PROVIDED IS AN EXAMPLE FRAMEWORK, BUT NO REPRESENTATIONS OR WARRANTIES ARE MADE OF IT AND NO GUARANTEES ARE PROVIDED CONCERNING ANY SPECIFIC RESULTS. INFORMATION IS PROVIDED “AS-IS” AND “AS AVAILABLE”.  ANY USE OF THE INFORMATION PROVIDED IS AT YOUR OWN RISK AND LIABILITY. FURTHER, UNITY MAY CHANGE ANY INFORMATION PROVIDED HERE AT ANY TIME WITHOUT NOTICE TO YOU.
+
+THE INFORMATION AS DOCUMENTED HERE IS SUBJECT TO COPYRIGHT AND OTHER INTELLECTUAL PROPERTY LAWS. PLEASE REVIEW THE LICENSE FILE TO FAMILIARISE YOURSELF WITH THE TERMS OF THE LICENSES PROVIDED BY UNITY.
+
 

From aa3636f2fd65d66d4147af17f624d26bafd7d272 Mon Sep 17 00:00:00 2001
From: djmcdonald1 <35308171+djmcdonald1@users.noreply.github.com>
Date: Thu, 25 Jul 2019 15:37:12 -0700
Subject: [PATCH 24/54] Update License.md

---
 LICENSE.md | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/LICENSE.md b/LICENSE.md
index eb18dfb..9e709c6 100644
--- a/LICENSE.md
+++ b/LICENSE.md
@@ -1,3 +1,7 @@
+Text is licensed under CC BY-NC-SA 2.0 (https://creativecommons.org/licenses/by-nc-sa/2.0/);
+
+Code snippets licensed under MIT:
+
 MIT License
 
 Copyright (c) 2019 Unity Technologies

From b43489c4a345093619918ff714e649b6c5803d94 Mon Sep 17 00:00:00 2001
From: Brandon Caldwell <brandonc@unity3d.com>
Date: Wed, 9 Oct 2019 12:46:55 -0700
Subject: [PATCH 25/54] Lots of updates, largely typos and grammar
 improvements. Notably added basic contribution guidelines, including an
 artice template.

---
 CONTRIBUTING.md                               | 48 +++++++++++++
 .../Electron-Guidance.md                      |  0
 .../Preventing-Common-Web-Attacks.md          |  2 +-
 Contribution_Template.md                      | 39 +++++++++++
 Overview.md                                   | 68 ++++++++-----------
 README.md                                     | 25 +++----
 .../{Unity-Bug-Bar.md => Bug-Bar.md}          |  0
 7 files changed, 130 insertions(+), 52 deletions(-)
 create mode 100644 CONTRIBUTING.md
 rename {Language Guidance => Coding Practice}/Electron-Guidance.md (100%)
 create mode 100644 Contribution_Template.md
 rename Security Process/{Unity-Bug-Bar.md => Bug-Bar.md} (100%)

diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
new file mode 100644
index 0000000..edb1729
--- /dev/null
+++ b/CONTRIBUTING.md
@@ -0,0 +1,48 @@
+# Contributing
+
+## If you are interested in contributing, here are some ground rules:
+
+### Document Style
+#### Basics
+- All contributions will be received as PRs - just read the recommendation below first please! 😁
+- This is intended to be a technical reference for other collegeaues in the security community, so the language and style should reflect that.
+- You'll notice that our language if fairly casual for this type of content, but keep the language civil/mild and avoid using too much lingo when writing, and when using an abbreviation, please provide he definition upon its first use. 
+- Given the nature of this content, it's ultimately meant for developers writing the code, not just security folks looking at it - it's not productive to write an article that not everyone can understand. Keep things simple, but accurate.
+
+#### Article Updates
+##### Spelling and Grammar changes
+Simply update the spelling of the article and do a PR. For simple changes like this, we won't be updating the Authorship or contributor section in the article itself, but your PR will be in the changelog.
+
+##### New Content and Substantial Changes
+If you want to contribute new security recommendations or research to an additional article, provide the PR ensuring that you're maintaning the original articles style and template as closely as reasonable.
+
+If mutliple people contributed to the content, please include their names in the *Contributors* section at the end of the article. 
+
+#### New Articles and the Template
+If creating a new article, we'd recommend taking a look at the [Contribution_Template](./Contribution_Template.md) that we have to help improve consistency in the article formatting. 
+We're open to article in differing format, but variance from the template will necessicate a review of the articles layout to ensure it's readable and logical.
+
+For new articles, please ensure everyone who has substantially contributed to the article is appropriately credited as an author.
+
+### Attribution and Credit
+An importact aspect of this body of work is that contributors are recognized for their work. As such, authors and contributors will be recognized in the content of the Markdown file, not just by their names in the Git changelogs. Above this is discused a bit, but we'll repeat it here for clarity:
+- Authors: Original Authors of an article will be given credit at the top of the article. This will include the month and year the content was originally written.
+- Contributors: People who have provided new research or recommendations to an article will be added as a Contributor in the appropriate section at the bottom of the page, along with the month and year their contribution was made.
+- Minor changes: Minor changes (spelling, grammar, etc.), will be accepted directly as PRs, with the contributors account logged in the changelog for that PR.
+
+### Review Process
+Currently the review process will be ad-hoc within the Unity Security team. All approval decisions will be the responsibility of Unity. We'll do our best to adapt and adjust according to the rate and quality of contributions as we move forward.
+
+If you disagree with an editorial decision, we'll be open to the conversation. Ultimately, however, if an agreement can't be reached, then forking this into a new version may be the most appropriate option. 
+
+
+## Forking
+**Please fork!**
+We'd love to see industry specific versions, or flavors, of this SSDLC being developed. We know that some of the guidance here may be too specific, or not specific enough, in areas that are important to your business or industry. Assuming all this goes well, we'll likely have our own fork to more narrowly focus recommendations for game developers and studios.
+
+
+---
+
+
+## All contributions are subject to the [Unity Contribution Agreement(UCA)](https://unity3d.com/legal/licenses/Unity_Contribution_Agreement)
+By making a pull request, you are confirming agreement to the terms and conditions of the UCA, including that your Contributions are your original creation and that you have complete right and authority to make your Contributions.
diff --git a/Language Guidance/Electron-Guidance.md b/Coding Practice/Electron-Guidance.md
similarity index 100%
rename from Language Guidance/Electron-Guidance.md
rename to Coding Practice/Electron-Guidance.md
diff --git a/Coding Practice/Preventing-Common-Web-Attacks.md b/Coding Practice/Preventing-Common-Web-Attacks.md
index 496decf..f256e90 100644
--- a/Coding Practice/Preventing-Common-Web-Attacks.md	
+++ b/Coding Practice/Preventing-Common-Web-Attacks.md	
@@ -262,4 +262,4 @@ Security Level
 Leaking credentials can be critical as they often grant a high level of access to Unity systems and can lead to compromise of data and systems.
 References
 
-https://github.com/UnityTech/Secret-Finder - _(Currently Internal Only - Public Release TBD)_
+https://github.com/UnityTech/Secret-Finder - _(Currently Internal Only - Public Release TBD)_ 
diff --git a/Contribution_Template.md b/Contribution_Template.md
new file mode 100644
index 0000000..6394f47
--- /dev/null
+++ b/Contribution_Template.md
@@ -0,0 +1,39 @@
+# Short-Descriptive Title [Relevant Topic]
+<font size="-1">_Author: Initial Author(s) - \<Month Initially Published> \<Year Initially Published>_</font>
+
+## Overview
+
+This document provides recommended best practices for how to _\<do things securely in this specific topic>_.
+_\<Table of Contents of high-level Sections>_
+- [Section #1](#Section-1)
+- [Section #2](#Section-2)
+
+**Relevant Article Context** is a good section to give some extra info to help build context for the article. For example, for the purpose of this template, this is a recommended guide for creating a _new_ article. You'll find that some of the already written article do not yet fit this template. While we'll continue to work on the articles to get them into a more consistent format, it's safe to assume that not all content will fir this layout. 
+
+**More relevant context** can be used to continue to flesh out the article. There's no hard guidance for length here, but it probably shouldn't be the bulk of the article.
+
+## Recommendations
+### Section-1
+###### Description
+_Provide a description of the risk to be mititgated by this best practice._
+###### Why We Care
+_Explain the actual real world impact of this risk. If possible, provide industry specific relevance._
+###### How to Fix?
+_Technical details on how to mitigate the risk_
+###### Risk Rating
+_Optionally provided a risk severity according to: [Risk-Rating.md](./Security%20Process/Risk-Rating.md)_
+
+
+---
+### Section-2
+###### Description
+_Provide a description of the risk to be mititgated by this best practice._
+###### Why We Care
+_Explain the actual real world impact of this risk. If possible, provide industry specific relevance._
+###### How to Fix?
+_Technical details on how to mitigate the risk_
+###### Risk Rating
+_Optionally provided a risk severity according to: [Risk-Rating.md](./Security%20Process/Risk-Rating.md)_
+###### References
+
+- _Optional: Links to external references to provide additional information and context_
diff --git a/Overview.md b/Overview.md
index e53ffda..258ef3c 100644
--- a/Overview.md
+++ b/Overview.md
@@ -10,55 +10,45 @@
 | :--- | :--- | :--- | :--- | :--- |
 | Security Requirements | Design Review & Threat Models |  - Static Analysis Tools<br> - Secure Coding | - Ask in Slack <br>- Security Testing | - Pentest in Product<br>- Incident Response Support |
 
-
 ### Unity SSDLC Overview
 
-The goal of Unity's SSDLC provide product teams guidance on how to include software security practices into their existing development process. The phases above may not be formally implemented or recognized by your team, but they do generally represent how all software is developed, implicitly or explicitly. Following this model, you are able to best determine what services the Unity Security team provides based on what phase of the life-cycle you are currently in, with your product.
+The goal of Unity's SSDLC provide product teams and developers guidance on how to leverage software security practices into their existing development process. The phases in the graphic above may not be formally implemented or recognized by your team, but they do generally represent how all software is developed, implicitly or explicitly. Following this model, you are able to best determine what services the Unity Security team provides based on what phase of of the development life-cycle you are currently in with your product.
 
-The SSDLC will continue to evolve, and include services from the broader Security teams; we'll soon be adding links to guidance from Audit & Compliance, Infrastructure Security, SOC, Incident Response, and Product Security.
+The SSDLC will continue to evolve, and include services from the broader Security teams; we'll soon be adding links to guidance from our Program Management team, Infrastructure Security, SOC, Incident Response, and Application Security.
 
-All feedback is welcome - feel free to update/comment on the docs directly or chat with the team on Slack or email.
+All feedback is welcome - feel free to update/comment the docs directly or chat with the team on Slack or email.
 
 Our SSDLC is currently organized under the following topics:
-- [Coding Practice guides](unity.com)
-- [Language Guidance articles](unity.com)
-- [Security Process documentation](unity.com)
-- [Tools & Automation guidance](unity.com)
-
-Also, be sure to keep an eye out for on-site trainings, which will be announced (and archived) here -> [Developer Security Trainings](unity.com)
-
-### Suggested SSDLC Topics and Articles
-##### Language Specific Guidance
-- [Golang](unity.com)
-- [Node.js](unity.com)
-- [Ruby](unity.com)
-- [C#](unity.com)
-
-##### Secure Coding Guidance
-- [API Best Practices](./Coding%20%Practice/API-Best-Practices.md)
-- [Authentication/Authorization Best Practices](./Coding%20%Practice/AuthZ-AuthN-Guidelines.md)
-- [Preventing Common Web Attacks](unity.com)
-
-##### Security Automation and Tooling
-
-- [AppCollector](unity.com) - Onboard your project/product with Security
-- [Vault](unity.com) - Secrets management service
-- [Constable](unity.com) - Service providing file inspection to protect agents malware and malicious files
-- [SourceClear](unity.com) - Dependency version checking and static analysis 
-  -  [SourceClear](unity.com) Remediation
+- [Coding Practice](./Coding%20Practice)
+- [Language Best Practices](./Language%20Guidance)
+- [Security Process](./Security%20Process)
+- [Tools & Automation](./Tools%20and%20Automation)
 
+Also, be sure to keep an eye out for on-site trainings, which will be announced (and archived) here -> [Developer Security Trainings](./Trainings/reaedme.md)
 
-## List of Articles
+## Shortcut List of Articles 
 #### _Coding Practice_
-- [API Best Practices](./Code%20Practice/API-Best-Practices.md)
-- [Authorization & Authentication Guidelines](./Code%20Practice/AuthZ-AuthN-Guidelines.md)
-- [Cryptographic Guidelines](./Code%20Practice/Cryptographic-Guidelines.md)
-- [HTTP Header Security](./Code%20Practice/HTTP-Header-Security.md)
-- [Preventing Common Web Attacks](./Code%20Practice/Preventing-Common-Web-Attacks.md)
-- [Secrets Management](./Code%20Practice/Secrets-Management.md)
-- [Secure Design Principles](./Code%20Practice/Secure-Design-Principles.md)
-#### _Language Guidance_
+- [API Best Practices](./Coding%Practice/API-Best-Practices.md)
+- [Authorization & Authentication Guidelines](./Coding%Practice/AuthZ-AuthN-Guidelines.md)
+- [Cryptographic Guidelines](./Coding%Practice/Cryptographic-Guidelines.md)
+- [HTTP Header Security](./Coding%Practice/HTTP-Header-Security.md)
+- [Preventing Common Web Attacks](./Coding%Practice/Preventing-Common-Web-Attacks.md)
+- [Secrets Management](./Coding%Practice/Secrets-Management.md)
+- [Secure Design Principles](./Coding%Practice/Secure-Design-Principles.md)
+- [Electron Best Practices](./Code%Practice/Electron-Guidance.md)
+
+#### _Language Best Practices_
+- [Golang](./Language%20Guidance/Golang-Guidance.md)
+- [Node.js](./Language%20Guidance/Nodejs-Guidance.md)
+- [Ruby](./Language%20Guidance/Ruby-Guidance.md)
+- [C#](./Language%20Guidance/Net-C#-Guidance.md)
 
 #### _Security Process_
+- [Design Review](./Security%20Process/Design-Review.md)
+- [Implementation Review](./Security%20Process/Implementation-Review.md)
+- [Risk Rating](./Security%20Process/Risk-Rating.md)
+- [Security Requirements](./Security%20Process/Security-Requirements.md)
+- [Bug Bar](./Security%20Process/Bug-Bar.md)
 
 #### _Tools & Automation_
+- [Tools & Automation](./Tools%20and%20Automation/readme.md)
diff --git a/README.md b/README.md
index 5901ae5..00a9182 100644
--- a/README.md
+++ b/README.md
@@ -1,13 +1,12 @@
 # unity-ssdlc
 <img src="./images/madewith-unity-black.png" style="width:300px" alt="MWU"></img>
 ## Intro and Overview
-A public version of Unity's internal Secure Software Development Lifecycle (SSDLC). Meant to provide an example framework, not just to share with other, but to also take contributions and continue to improve and evolve.
+This is a public version of Unity's internal Secure Software Development Lifecycle (SSDLC). Meant to provide a reusable reference framework, not just to share with others, but also to take contributions to improve and evolve.
 
-The Unity Security Team has spent a lot of work to improve the trustworthiness of Unity's products and services. As part of that, we developed our own internal SSDLC to help our developers design and develop more secure products. After a couple iterations, we found that we had an interesting collection of articles and trainings that may be useful for not just Unity's developers, but potentially other organizations as well. So we decided to share what we have, hopefully to contribute something back to the broader software security community.
+The Unity Security Team has worked hard to improve the trustworthiness of Unity's products and services. As part of that, we developed our own internal SSDLC to help our internal developers design and develop more secure products. After a few iterations, we found that we had an interesting collection of articles and trainings that may be useful, for not just Unity's developers, but potentially other companies as well. So we decided to share what we have, hopefully contributing something useful back to the broader software security community.
 
-We know this isn't perfect - there's rough edges, probably some typos and embarassing grammar, and it's certainly not close to being exhaustive. But, there's definitely useful information here. Not only the actual data, but we wanted to just share with other companies what an actual, in use, SSDLC might look like.
-This this in mind, please be kind in your contructive criticism, and let us know if you've found this 
-useful!
+We know this isn't perfect - there's rough edges, with some typos and embarassing grammar, and it's certainly not close to being exhaustive. But, there's definitely useful information here. Not only the actual content, but also to share with other companies what an actual, in use, SSDLC might look like.
+With this in mind, please be kind in your contructive criticism, and let us know if you've found this useful!
 
 ---
 ## How To Use
@@ -17,21 +16,23 @@ Feel free to clone the whole repo and use in your organization!
 We'd appreciate your feedback as well :)
   
 ## Unity SSDLC Structure
-Our SSDLC is actually a suite of offering by the Application Security team. Part documentation, part training (in person and online) and a fun CTF server we host.
+Our SSDLC is currently a suite of offerings by the Unity Application Security team. Part documentation, part training (in person and online) and a fun CTF server we host.
 #### SSDLC  Documentation
-The SSDLC is an ever evolving set of documents that our team has drafted as an attempt to capture industry best practices in a single location for our developers. The recommendations aren't perfect, and are always in draft. We have gaps, both in the technology we cover and how deep we are in each topic. However, we felt it better to share with our developers (and you!) as much as we could  - it does no good for us to hoard a complete library of knowledge because we're missing _just one more article_ :)
+The SSDLC is an ever evolving set of documents that our team has drafted as an attempt to capture industry best practices in a single location for our developers. The recommendations aren't perfect, and are always in draft. There are gaps, both in the technology we cover and how deep we are in each topic, however, we felt it better to share with our developers (and you!) as much as we could. Tt does no good for us to hoard a complete library of knowledge because we're missing _just one more article_ :)
 
-This SSDLC is intended to be a practical reference for developers to help them design and develop more secure products spread over 3 main topic: [Coding Practice](./Coding%Practice), [Language Guidance](./Language%20Guidance), and [Security Process](./Security%20Process).
+This SSDLC is intended to be a practical reference for developers to help them design and develop more secure products spread over 3 main topics: [Coding Practice](./Coding%Practice), [Language Guidance](./Language%20Guidance), and [Security Process](./Security%20Process). Further, we'll be sharing our [Tools and Automation](./) and [Trainings](./) in the future.
 #### Trainings
-As a further supplemt to our SSDLC, the Unity Security team has developed several presentation to deliver more entertaining security content. The training was built with the intent to deliver the sessions in-person, as part of mini internal security conferences. Ideally, we'd also record these presentations to share with folks who can't make it to the live sessions.
+_NOTE: The Trainings are still TBD - We'll get them in here as soon as we can!_
+As a further supplement to our SSDLC, the Unity Security team has developed several presentations to provide more entertaining security content. The training was built with the intent to deliver the sessions in-person, as part of mini internal security conferences. Ideally, we'd also record these presentations to share with folks who can't make it to the live sessions.
 
-We can't share all our presentations here. We wanted to make these relevant and personal to the teams we present to, so many contain findings in our own products, with real-time demos of us exploiting the vulnerabilities we've discoved in our own code! In this way, developers can see the real risk of insecure code, potentially in the code they wrote themselves :) We never shame or call out teams or specifically developers - this is meant to be a learning experience, not a hurtful one.
+We can't share all our presentations here; we wanted to make these relevant and personal to the teams we present to, so many contain findings in our own products, with real-time demos of us exploiting the vulnerabilities we've discoved in our own code! In this way, developers can see the real risk of insecure code, potentially in the code they wrote themselves. We never shame or intentioanlly call out a team or specific developers - this is meant to be a learning experience, not a hurtful one.
 
 ##### CTF(s)
-To go along with our mini-conferences, we also run a small CTF along side the presentations. This is meant to give our development teams the opportunity to have a hands-on experience with insecure code, starting with very simple examples, working up to more advanced challenges. This is not meant to be a full fledged Defcon-style CTF - we just want to teach some security basic, and whet the hacking appetite of our teams :) 
+_NOTE: Our CTF is not quite ready for public release - We'll have this updated as soon as we can!_
+To go along with our mini-conferences, we also run a small CTF in paralell with presentations. This is meant to give our development teams the opportunity to have a hands-on experience with insecure applications, starting with very simple examples, working up to more advanced challenges. This is not meant to be a full fledged Defcon-style CTF - we just want to teach some security basic, and whet the hacking appetite of our teams.
 
 ## Contributions
-We're still working on how to accept contributions. Once we figure out that process, we'll post the details here and open up our repo accordingly.
+To learn how to contribute, take a look at our [Contributing.md](./CONTRIBUTING.md). Let us know if you have any questions not called out in there.
 
 ## Contact Us
 [`security@unity3d.com`](mailto:security@unity3d.com)
diff --git a/Security Process/Unity-Bug-Bar.md b/Security Process/Bug-Bar.md
similarity index 100%
rename from Security Process/Unity-Bug-Bar.md
rename to Security Process/Bug-Bar.md

From fefa74f4b5f9fe9a6bfe6ff6291da46978d06dd1 Mon Sep 17 00:00:00 2001
From: Brandon Caldwell <brandonc@unity3d.com>
Date: Tue, 15 Oct 2019 13:07:21 -0700
Subject: [PATCH 26/54] After much discussion, we changed from MIT to Apache
 2.0 license to simplify contributions. Also, added a code of conduct
 document, following ml-agents leads on that.

---
 CODE-OF-CONDUCT.md |  74 +++++++++++++++
 CONTRIBUTING.md    |  10 +-
 LICENSE.md         | 223 +++++++++++++++++++++++++++++++++++++++++----
 3 files changed, 284 insertions(+), 23 deletions(-)
 create mode 100644 CODE-OF-CONDUCT.md

diff --git a/CODE-OF-CONDUCT.md b/CODE-OF-CONDUCT.md
new file mode 100644
index 0000000..8bcf445
--- /dev/null
+++ b/CODE-OF-CONDUCT.md
@@ -0,0 +1,74 @@
+# Contributor Covenant Code of Conduct
+
+## Our Pledge
+
+In the interest of fostering an open and welcoming environment, we as
+contributors and maintainers pledge to making participation in our project and
+our community a harassment-free experience for everyone, regardless of age, body
+size, disability, ethnicity, gender identity and expression, level of experience,
+nationality, personal appearance, race, religion, or sexual identity and
+orientation.
+
+## Our Standards
+
+Examples of behavior that contributes to creating a positive environment
+include:
+
+* Using welcoming and inclusive language
+* Being respectful of differing viewpoints and experiences
+* Gracefully accepting constructive criticism
+* Focusing on what is best for the community
+* Showing empathy towards other community members
+
+Examples of unacceptable behavior by participants include:
+
+* The use of sexualized language or imagery and unwelcome sexual attention or
+  advances
+* Trolling, insulting/derogatory comments, and personal or political attacks
+* Public or private harassment
+* Publishing others' private information, such as a physical or electronic
+  address, without explicit permission
+* Other conduct which could reasonably be considered inappropriate in a
+  professional setting
+
+## Our Responsibilities
+
+Project maintainers are responsible for clarifying the standards of acceptable
+behavior and are expected to take appropriate and fair corrective action in
+response to any instances of unacceptable behavior.
+
+Project maintainers have the right and responsibility to remove, edit, or
+reject comments, commits, code, wiki edits, issues, and other contributions
+that are not aligned to this Code of Conduct, or to ban temporarily or
+permanently any contributor for other behaviors that they deem inappropriate,
+threatening, offensive, or harmful.
+
+## Scope
+
+This Code of Conduct applies both within project spaces and in public spaces
+when an individual is representing the project or its community. Examples of
+representing a project or community include using an official project e-mail
+address, posting via an official social media account, or acting as an appointed
+representative at an online or offline event. Representation of a project may be
+further defined and clarified by project maintainers.
+
+## Enforcement
+
+Instances of abusive, harassing, or otherwise unacceptable behavior may be
+reported by contacting the project team at security@unity3d.com. All
+complaints will be reviewed and investigated and will result in a response that
+is deemed necessary and appropriate to the circumstances. The project team is
+obligated to maintain confidentiality with regard to the reporter of an incident.
+Further details of specific enforcement policies may be posted separately.
+
+Project maintainers who do not follow or enforce the Code of Conduct in good
+faith may face temporary or permanent repercussions as determined by other
+members of the project's leadership.
+
+## Attribution
+
+This Code of Conduct is adapted from the [Contributor Covenant][homepage],
+version 1.4, available at
+https://www.contributor-covenant.org/version/1/4/code-of-conduct/
+
+[homepage]: https://www.contributor-covenant.org
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index edb1729..b4d05b2 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -2,11 +2,16 @@
 
 ## If you are interested in contributing, here are some ground rules:
 
+### Communication
+First, please read through our code of conduct, as we expect all our contributors to follow it.
+
+Second, before starting on a project that you intend to contribute to the unity-ssldc, we strongly recommend posting on our Issues page and briefly outlining the changes you plan to make. This will enable us to provide some context that may be helpful for you. This could range from advice and feedback on how to optimally perform your changes or reasons for not doing it.
+
 ### Document Style
 #### Basics
 - All contributions will be received as PRs - just read the recommendation below first please! 😁
 - This is intended to be a technical reference for other collegeaues in the security community, so the language and style should reflect that.
-- You'll notice that our language if fairly casual for this type of content, but keep the language civil/mild and avoid using too much lingo when writing, and when using an abbreviation, please provide he definition upon its first use. 
+- You'll notice that our language if fairly casual for this type of content, but keep the language civil/mild and avoid using too much lingo when writing, and when using an abbreviation, please provide he definition upon its first use. Also refer to our our official [Code of Conduct](./CODE-OF-CONDUCT.md).
 - Given the nature of this content, it's ultimately meant for developers writing the code, not just security folks looking at it - it's not productive to write an article that not everyone can understand. Keep things simple, but accurate.
 
 #### Article Updates
@@ -44,5 +49,4 @@ We'd love to see industry specific versions, or flavors, of this SSDLC being dev
 ---
 
 
-## All contributions are subject to the [Unity Contribution Agreement(UCA)](https://unity3d.com/legal/licenses/Unity_Contribution_Agreement)
-By making a pull request, you are confirming agreement to the terms and conditions of the UCA, including that your Contributions are your original creation and that you have complete right and authority to make your Contributions.
+## All contributions are governed by the [Apache 2.0 license](./LICENSE.md).
\ No newline at end of file
diff --git a/LICENSE.md b/LICENSE.md
index 9e709c6..096080f 100644
--- a/LICENSE.md
+++ b/LICENSE.md
@@ -1,25 +1,208 @@
+Copyright (c) 2019 Unity Technologies
+
 Text is licensed under CC BY-NC-SA 2.0 (https://creativecommons.org/licenses/by-nc-sa/2.0/);
 
-Code snippets licensed under MIT:
+Code snippets licensed under Apache Version 2.0:
 
-MIT License
 
-Copyright (c) 2019 Unity Technologies
+                                 Apache License
+                           Version 2.0, January 2004
+                        http://www.apache.org/licenses/
+
+   TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
+
+   1. Definitions.
+
+      "License" shall mean the terms and conditions for use, reproduction,
+      and distribution as defined by Sections 1 through 9 of this document.
+
+      "Licensor" shall mean the copyright owner or entity authorized by
+      the copyright owner that is granting the License.
+
+      "Legal Entity" shall mean the union of the acting entity and all
+      other entities that control, are controlled by, or are under common
+      control with that entity. For the purposes of this definition,
+      "control" means (i) the power, direct or indirect, to cause the
+      direction or management of such entity, whether by contract or
+      otherwise, or (ii) ownership of fifty percent (50%) or more of the
+      outstanding shares, or (iii) beneficial ownership of such entity.
+
+      "You" (or "Your") shall mean an individual or Legal Entity
+      exercising permissions granted by this License.
+
+      "Source" form shall mean the preferred form for making modifications,
+      including but not limited to software source code, documentation
+      source, and configuration files.
+
+      "Object" form shall mean any form resulting from mechanical
+      transformation or translation of a Source form, including but
+      not limited to compiled object code, generated documentation,
+      and conversions to other media types.
+
+      "Work" shall mean the work of authorship, whether in Source or
+      Object form, made available under the License, as indicated by a
+      copyright notice that is included in or attached to the work
+      (an example is provided in the Appendix below).
+
+      "Derivative Works" shall mean any work, whether in Source or Object
+      form, that is based on (or derived from) the Work and for which the
+      editorial revisions, annotations, elaborations, or other modifications
+      represent, as a whole, an original work of authorship. For the purposes
+      of this License, Derivative Works shall not include works that remain
+      separable from, or merely link (or bind by name) to the interfaces of,
+      the Work and Derivative Works thereof.
+
+      "Contribution" shall mean any work of authorship, including
+      the original version of the Work and any modifications or additions
+      to that Work or Derivative Works thereof, that is intentionally
+      submitted to Licensor for inclusion in the Work by the copyright owner
+      or by an individual or Legal Entity authorized to submit on behalf of
+      the copyright owner. For the purposes of this definition, "submitted"
+      means any form of electronic, verbal, or written communication sent
+      to the Licensor or its representatives, including but not limited to
+      communication on electronic mailing lists, source code control systems,
+      and issue tracking systems that are managed by, or on behalf of, the
+      Licensor for the purpose of discussing and improving the Work, but
+      excluding communication that is conspicuously marked or otherwise
+      designated in writing by the copyright owner as "Not a Contribution."
+
+      "Contributor" shall mean Licensor and any individual or Legal Entity
+      on behalf of whom a Contribution has been received by Licensor and
+      subsequently incorporated within the Work.
+
+   2. Grant of Copyright License. Subject to the terms and conditions of
+      this License, each Contributor hereby grants to You a perpetual,
+      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
+      copyright license to reproduce, prepare Derivative Works of,
+      publicly display, publicly perform, sublicense, and distribute the
+      Work and such Derivative Works in Source or Object form.
+
+   3. Grant of Patent License. Subject to the terms and conditions of
+      this License, each Contributor hereby grants to You a perpetual,
+      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
+      (except as stated in this section) patent license to make, have made,
+      use, offer to sell, sell, import, and otherwise transfer the Work,
+      where such license applies only to those patent claims licensable
+      by such Contributor that are necessarily infringed by their
+      Contribution(s) alone or by combination of their Contribution(s)
+      with the Work to which such Contribution(s) was submitted. If You
+      institute patent litigation against any entity (including a
+      cross-claim or counterclaim in a lawsuit) alleging that the Work
+      or a Contribution incorporated within the Work constitutes direct
+      or contributory patent infringement, then any patent licenses
+      granted to You under this License for that Work shall terminate
+      as of the date such litigation is filed.
+
+   4. Redistribution. You may reproduce and distribute copies of the
+      Work or Derivative Works thereof in any medium, with or without
+      modifications, and in Source or Object form, provided that You
+      meet the following conditions:
+
+      (a) You must give any other recipients of the Work or
+          Derivative Works a copy of this License; and
+
+      (b) You must cause any modified files to carry prominent notices
+          stating that You changed the files; and
+
+      (c) You must retain, in the Source form of any Derivative Works
+          that You distribute, all copyright, patent, trademark, and
+          attribution notices from the Source form of the Work,
+          excluding those notices that do not pertain to any part of
+          the Derivative Works; and
+
+      (d) If the Work includes a "NOTICE" text file as part of its
+          distribution, then any Derivative Works that You distribute must
+          include a readable copy of the attribution notices contained
+          within such NOTICE file, excluding those notices that do not
+          pertain to any part of the Derivative Works, in at least one
+          of the following places: within a NOTICE text file distributed
+          as part of the Derivative Works; within the Source form or
+          documentation, if provided along with the Derivative Works; or,
+          within a display generated by the Derivative Works, if and
+          wherever such third-party notices normally appear. The contents
+          of the NOTICE file are for informational purposes only and
+          do not modify the License. You may add Your own attribution
+          notices within Derivative Works that You distribute, alongside
+          or as an addendum to the NOTICE text from the Work, provided
+          that such additional attribution notices cannot be construed
+          as modifying the License.
+
+      You may add Your own copyright statement to Your modifications and
+      may provide additional or different license terms and conditions
+      for use, reproduction, or distribution of Your modifications, or
+      for any such Derivative Works as a whole, provided Your use,
+      reproduction, and distribution of the Work otherwise complies with
+      the conditions stated in this License.
+
+   5. Submission of Contributions. Unless You explicitly state otherwise,
+      any Contribution intentionally submitted for inclusion in the Work
+      by You to the Licensor shall be under the terms and conditions of
+      this License, without any additional terms or conditions.
+      Notwithstanding the above, nothing herein shall supersede or modify
+      the terms of any separate license agreement you may have executed
+      with Licensor regarding such Contributions.
+
+   6. Trademarks. This License does not grant permission to use the trade
+      names, trademarks, service marks, or product names of the Licensor,
+      except as required for reasonable and customary use in describing the
+      origin of the Work and reproducing the content of the NOTICE file.
+
+   7. Disclaimer of Warranty. Unless required by applicable law or
+      agreed to in writing, Licensor provides the Work (and each
+      Contributor provides its Contributions) on an "AS IS" BASIS,
+      WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
+      implied, including, without limitation, any warranties or conditions
+      of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
+      PARTICULAR PURPOSE. You are solely responsible for determining the
+      appropriateness of using or redistributing the Work and assume any
+      risks associated with Your exercise of permissions under this License.
+
+   8. Limitation of Liability. In no event and under no legal theory,
+      whether in tort (including negligence), contract, or otherwise,
+      unless required by applicable law (such as deliberate and grossly
+      negligent acts) or agreed to in writing, shall any Contributor be
+      liable to You for damages, including any direct, indirect, special,
+      incidental, or consequential damages of any character arising as a
+      result of this License or out of the use or inability to use the
+      Work (including but not limited to damages for loss of goodwill,
+      work stoppage, computer failure or malfunction, or any and all
+      other commercial damages or losses), even if such Contributor
+      has been advised of the possibility of such damages.
+
+   9. Accepting Warranty or Additional Liability. While redistributing
+      the Work or Derivative Works thereof, You may choose to offer,
+      and charge a fee for, acceptance of support, warranty, indemnity,
+      or other liability obligations and/or rights consistent with this
+      License. However, in accepting such obligations, You may act only
+      on Your own behalf and on Your sole responsibility, not on behalf
+      of any other Contributor, and only if You agree to indemnify,
+      defend, and hold each Contributor harmless for any liability
+      incurred by, or claims asserted against, such Contributor by reason
+      of your accepting any such warranty or additional liability.
+
+   END OF TERMS AND CONDITIONS
+
+   APPENDIX: How to apply the Apache License to your work.
+
+      To apply the Apache License to your work, attach the following
+      boilerplate notice, with the fields enclosed by brackets "[]"
+      replaced with your own identifying information. (Don't include
+      the brackets!)  The text should be enclosed in the appropriate
+      comment syntax for the file format. We also recommend that a
+      file or class name and description of purpose be included on the
+      same "printed page" as the copyright notice for easier
+      identification within third-party archives.
+
+   Copyright [yyyy] [name of copyright owner]
+
+   Licensed under the Apache License, Version 2.0 (the "License");
+   you may not use this file except in compliance with the License.
+   You may obtain a copy of the License at
+
+       http://www.apache.org/licenses/LICENSE-2.0
 
-Permission is hereby granted, free of charge, to any person obtaining a copy
-of this software and associated documentation files (the "Software"), to deal
-in the Software without restriction, including without limitation the rights
-to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
-copies of the Software, and to permit persons to whom the Software is
-furnished to do so, subject to the following conditions:
-
-The above copyright notice and this permission notice shall be included in all
-copies or substantial portions of the Software.
-
-THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
-IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
-FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
-AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
-LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
-OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
-SOFTWARE.
+   Unless required by applicable law or agreed to in writing, software
+   distributed under the License is distributed on an "AS IS" BASIS,
+   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+   See the License for the specific language governing permissions and
+   limitations under the License.

From 560edf250db72bfe1e5d18936e84a4f3a714c9d9 Mon Sep 17 00:00:00 2001
From: Brandon Caldwell <brandonc@unity3d.com>
Date: Thu, 17 Oct 2019 08:34:32 -0700
Subject: [PATCH 27/54] Did my best to replace 'guidance' with 'best practices'
 which seemed a better fit. Thanks to the Salesforce security folks for that
 suggestion :)

---
 CONTRIBUTING.md                                  |  2 +-
 Coding Practice/API-Best-Practices.md            |  2 +-
 ...on-Guidance.md => Electron-Best-Practices.md} |  0
 .../Golang-Best-Practices.md                     |  0
 .../Net-C#-Best-Practices.md                     |  8 ++++----
 .../Nodejs-Best-Practices.md                     |  0
 .../Ruby-Best-Practices.md                       |  0
 Overview.md                                      | 16 ++++++++--------
 8 files changed, 14 insertions(+), 14 deletions(-)
 rename Coding Practice/{Electron-Guidance.md => Electron-Best-Practices.md} (100%)
 rename Language Guidance/Golang-Guidance.md => Language Best Practices/Golang-Best-Practices.md (100%)
 rename Language Guidance/Net-C#-Guidance.md => Language Best Practices/Net-C#-Best-Practices.md (87%)
 rename Language Guidance/Nodejs-Guidance.md => Language Best Practices/Nodejs-Best-Practices.md (100%)
 rename Language Guidance/Ruby-Guidance.md => Language Best Practices/Ruby-Best-Practices.md (100%)

diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index b4d05b2..b221ce0 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -43,7 +43,7 @@ If you disagree with an editorial decision, we'll be open to the conversation. U
 
 ## Forking
 **Please fork!**
-We'd love to see industry specific versions, or flavors, of this SSDLC being developed. We know that some of the guidance here may be too specific, or not specific enough, in areas that are important to your business or industry. Assuming all this goes well, we'll likely have our own fork to more narrowly focus recommendations for game developers and studios.
+We'd love to see industry specific versions, or flavors, of this SSDLC being developed. We know that some of the best practices here may be too specific, or not specific enough, in areas that are important to your business or industry. Assuming all this goes well, we'll likely have our own fork to more narrowly focus recommendations for game developers and studios.
 
 
 ---
diff --git a/Coding Practice/API-Best-Practices.md b/Coding Practice/API-Best-Practices.md
index 36e4be4..ab3ee46 100644
--- a/Coding Practice/API-Best-Practices.md	
+++ b/Coding Practice/API-Best-Practices.md	
@@ -4,7 +4,7 @@
 ## Overview
 
 This document covers general security guidelines for API endpoints within Unity. These guidelines will cover general points like:
-- [Access control guidance](#access-controls)
+- [Access control best practices](#access-controls)
 - [Input validation](#input-validation)
 - [Request verification](#request-integrity)
 - [Replay attacks](#replay-attacks)
diff --git a/Coding Practice/Electron-Guidance.md b/Coding Practice/Electron-Best-Practices.md
similarity index 100%
rename from Coding Practice/Electron-Guidance.md
rename to Coding Practice/Electron-Best-Practices.md
diff --git a/Language Guidance/Golang-Guidance.md b/Language Best Practices/Golang-Best-Practices.md
similarity index 100%
rename from Language Guidance/Golang-Guidance.md
rename to Language Best Practices/Golang-Best-Practices.md
diff --git a/Language Guidance/Net-C#-Guidance.md b/Language Best Practices/Net-C#-Best-Practices.md
similarity index 87%
rename from Language Guidance/Net-C#-Guidance.md
rename to Language Best Practices/Net-C#-Best-Practices.md
index 46d0539..9eba2d2 100644
--- a/Language Guidance/Net-C#-Guidance.md	
+++ b/Language Best Practices/Net-C#-Best-Practices.md	
@@ -1,4 +1,4 @@
-# .Net/C# Guidelines [Language Guidance]
+# .Net/C# Best Practices [Language Best Practices]
 <font size="-1">_Author: Brandon Caldwell - Jan. 2019_</font>
 
 - [Untrusted Code and Resources](#untrusted-code-and-resources)
@@ -13,7 +13,7 @@ Microsoft's .Net (DotNet) framework, like most modern frameworks, is generally s
 ### Recommendations
 #### Untrusted Code and Resources
 
-The following guidance is in regards to loading code or resources from an untrusted source, i.e., anything from the internet or not signed by Unity (or trusted 3rd party). When working with these types of resources, refer to the below:
+The following best practices are in regards to loading code or resources from an untrusted source, i.e., anything from the internet or not signed by Unity (or trusted 3rd party). When working with these types of resources, refer to the below:
 
 - Do not use partial trusted code, Code Access Security (CAS), or AllowPartiallyTrustedCaller.
   - Problem: CAS was billed as a way to load untrusted libraries/code at runtime, by assigning 'trust levels' to various portions of code. Microsoft now recommends against using CAS as a means to protect against malicious code. Partial trust code and AllowPartiallyTrustedCaller has similar issues, wherein is does not provide any effective protections.
@@ -26,14 +26,14 @@ The following guidance is in regards to loading code or resources from an untrus
   - Problem: Again, thanks to James Forshaw, it was determined that DCOM was generally unsafe, and has issues with safe (or unsafe?) object serialization.
   - Solution: Don't use it at all. Consider named pipes for local services (available cross-platform). Avoid HTTP/REST-like endpoints if possible, as they can be difficult to protect against browser attacks - see [CVE-2017-12939](https://unity3d.com/security#CVE-2017-12939).
 
-In short, to quote the existing [Microsoft guidance](https://docs.microsoft.com/en-us/dotnet/standard/security/secure-coding-guidelines):
+In short, to quote the existing [Microsoft documentation - Secure Coding Guidelines](https://docs.microsoft.com/en-us/dotnet/standard/security/secure-coding-guidelines):
 
 >Code Access Security and Security-Transparent Code are not supported as a security boundary with partially trusted code. We advise against loading and executing code of unknown origins without putting alternative security measures in place.
 
 ---
 #### Handling User Input
 
-The following guidance is largely relevant to ASP.Net and .Net Embedded browser support:
+The following best practices is largely relevant to ASP.Net and .Net Embedded browser support:
 
 - Any user data in a server response runs in the context of the server's site on the client. If your Web server takes user data and inserts it into the returned Web page, it might, for example, include a `<script>` tag and run as if from the server.
 - Remember that the client can request any URL.
diff --git a/Language Guidance/Nodejs-Guidance.md b/Language Best Practices/Nodejs-Best-Practices.md
similarity index 100%
rename from Language Guidance/Nodejs-Guidance.md
rename to Language Best Practices/Nodejs-Best-Practices.md
diff --git a/Language Guidance/Ruby-Guidance.md b/Language Best Practices/Ruby-Best-Practices.md
similarity index 100%
rename from Language Guidance/Ruby-Guidance.md
rename to Language Best Practices/Ruby-Best-Practices.md
diff --git a/Overview.md b/Overview.md
index 258ef3c..39b925e 100644
--- a/Overview.md
+++ b/Overview.md
@@ -12,15 +12,15 @@
 
 ### Unity SSDLC Overview
 
-The goal of Unity's SSDLC provide product teams and developers guidance on how to leverage software security practices into their existing development process. The phases in the graphic above may not be formally implemented or recognized by your team, but they do generally represent how all software is developed, implicitly or explicitly. Following this model, you are able to best determine what services the Unity Security team provides based on what phase of of the development life-cycle you are currently in with your product.
+The goal of Unity's SSDLC provide product teams and developers best practices on how to leverage software security practices into their existing development process. The phases in the graphic above may not be formally implemented or recognized by your team, but they do generally represent how all software is developed, implicitly or explicitly. Following this model, you are able to best determine what services the Unity Security team provides based on what phase of of the development life-cycle you are currently in with your product.
 
-The SSDLC will continue to evolve, and include services from the broader Security teams; we'll soon be adding links to guidance from our Program Management team, Infrastructure Security, SOC, Incident Response, and Application Security.
+The SSDLC will continue to evolve, and include services from the broader Security teams; we'll soon be adding links to docukments from our Program Management team, Infrastructure Security, SOC, Incident Response, and Application Security.
 
 All feedback is welcome - feel free to update/comment the docs directly or chat with the team on Slack or email.
 
 Our SSDLC is currently organized under the following topics:
 - [Coding Practice](./Coding%20Practice)
-- [Language Best Practices](./Language%20Guidance)
+- [Language Best Practices](./Language%20Best%20Practices)
 - [Security Process](./Security%20Process)
 - [Tools & Automation](./Tools%20and%20Automation)
 
@@ -35,13 +35,13 @@ Also, be sure to keep an eye out for on-site trainings, which will be announced
 - [Preventing Common Web Attacks](./Coding%Practice/Preventing-Common-Web-Attacks.md)
 - [Secrets Management](./Coding%Practice/Secrets-Management.md)
 - [Secure Design Principles](./Coding%Practice/Secure-Design-Principles.md)
-- [Electron Best Practices](./Code%Practice/Electron-Guidance.md)
+- [Electron Best Practices](./Code%Practice/Electron-Best-Practices.md)
 
 #### _Language Best Practices_
-- [Golang](./Language%20Guidance/Golang-Guidance.md)
-- [Node.js](./Language%20Guidance/Nodejs-Guidance.md)
-- [Ruby](./Language%20Guidance/Ruby-Guidance.md)
-- [C#](./Language%20Guidance/Net-C#-Guidance.md)
+- [Golang](./Language%20Best%20Practices/Golang-Best-Practices.md)
+- [Node.js](./Language%20Best%20Practices/Nodejs-Best-Practices.md)
+- [Ruby](./Language%20Best%20Practices/Ruby-Best-Practices.md)
+- [C#](./Language%20Best%20Practices/Net-C#-Best-Practices.md)
 
 #### _Security Process_
 - [Design Review](./Security%20Process/Design-Review.md)

From 60f216ccd49f4246d66783dab5f300e46dcbe22b Mon Sep 17 00:00:00 2001
From: Brandon Caldwell <brandonc@unity3d.com>
Date: Mon, 21 Oct 2019 09:42:45 -0700
Subject: [PATCH 28/54] A few more 'guidance' edits...

---
 Coding Practice/Cryptographic-Guidelines.md      | 2 +-
 Coding Practice/Electron-Best-Practices.md       | 2 +-
 Coding Practice/Secrets-Management.md            | 6 +++---
 Contribution_Template.md                         | 2 +-
 Language Best Practices/Golang-Best-Practices.md | 2 +-
 Language Best Practices/Net-C#-Best-Practices.md | 2 +-
 Language Best Practices/Nodejs-Best-Practices.md | 4 ++--
 Language Best Practices/Ruby-Best-Practices.md   | 2 +-
 README.md                                        | 2 +-
 Security Process/Implementation-Review.md        | 2 +-
 10 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/Coding Practice/Cryptographic-Guidelines.md b/Coding Practice/Cryptographic-Guidelines.md
index 2bdaa73..e18f498 100644
--- a/Coding Practice/Cryptographic-Guidelines.md	
+++ b/Coding Practice/Cryptographic-Guidelines.md	
@@ -10,7 +10,7 @@ Cryptographic requirements at Unity are heavily influenced by NIST's *Cryptograp
 
 > NOTE: Where possible, we recommend Elliptic Curve Cryptography (ECC / ECDH), with Curve25519 (for signatures and key exchange)
 
-### Usage Guidance
+### Usage Recommendations
 ##### TLS - Cipher Suites
 
 _Minimum TLS version = TLS1.2._
diff --git a/Coding Practice/Electron-Best-Practices.md b/Coding Practice/Electron-Best-Practices.md
index a270e9d..c5542f3 100644
--- a/Coding Practice/Electron-Best-Practices.md	
+++ b/Coding Practice/Electron-Best-Practices.md	
@@ -1,4 +1,4 @@
-# Electron Guidelines [Language Guidance]
+# Electron Best Practices [Language Best Practices]
 <font size="-1">_Author: Andrew Luke - Dec. 2018_</font>
 
 ### Overview 
diff --git a/Coding Practice/Secrets-Management.md b/Coding Practice/Secrets-Management.md
index 989b8f9..ce20886 100644
--- a/Coding Practice/Secrets-Management.md	
+++ b/Coding Practice/Secrets-Management.md	
@@ -39,7 +39,7 @@ A Secret is also anything confidential, sensitive, or Personally Identifiable In
 - Social Security Number
 - Passport Number
 
-#### Guidance on proper handling of secrets
+#### Secrets handling best practices
 
 To handle Secrets properly, we must consider the following:
 - How do applications (non-human) get secrets?
@@ -74,7 +74,7 @@ These are your traditional secrets. Think Username, Password, and/or API Key. Th
 
     vault write secret/stg/ads/ads-performance-valuation/AWS_ACCESS_KEY_ID secret=AKIAIII1337DEADBEEF
 
-_For more Vault guidance, see the linked guidance below, in the Appendix_
+_For more Vault documentaion, see the linked guides below, in the Appendix_
 
 ###### Dynamic Secrets:
 
@@ -87,7 +87,7 @@ If you need support in using or troubleshooting Vault, contact the Security Team
 
 The best practice for application authentication in Google Cloud is to use a Service Account. Rather than store the service account secret in the application source code, use an environment variable pointing to credentials outside of the application’s source code, such as Vault. Restrict who can act as service accounts. Users who are granted the Service Account Actor role for a service account can access all of the resources for which the service account has access.
 
-The Security team is still working to develop more complete guidance on managing GCP secrets; in the meantime, leverage Google’s own document: Understanding Service Accounts. As always, if further guidance is required, ask the Security Team.
+The Security team is still working to develop more complete best practices on managing GCP secrets; in the meantime, leverage Google’s own document: Understanding Service Accounts. As always, if further instruction is required, ask the Security Team.
 
 ##### AWS Keys:
 
diff --git a/Contribution_Template.md b/Contribution_Template.md
index 6394f47..77b4a85 100644
--- a/Contribution_Template.md
+++ b/Contribution_Template.md
@@ -10,7 +10,7 @@ _\<Table of Contents of high-level Sections>_
 
 **Relevant Article Context** is a good section to give some extra info to help build context for the article. For example, for the purpose of this template, this is a recommended guide for creating a _new_ article. You'll find that some of the already written article do not yet fit this template. While we'll continue to work on the articles to get them into a more consistent format, it's safe to assume that not all content will fir this layout. 
 
-**More relevant context** can be used to continue to flesh out the article. There's no hard guidance for length here, but it probably shouldn't be the bulk of the article.
+**More relevant context** can be used to continue to flesh out the article. There's no hard best practices for length here, but it probably shouldn't be the bulk of the article.
 
 ## Recommendations
 ### Section-1
diff --git a/Language Best Practices/Golang-Best-Practices.md b/Language Best Practices/Golang-Best-Practices.md
index a4812ff..d3770d4 100644
--- a/Language Best Practices/Golang-Best-Practices.md	
+++ b/Language Best Practices/Golang-Best-Practices.md	
@@ -1,4 +1,4 @@
-# Golang Security Guidelines [Language Guidance]
+# Golang Security [Language Best Practices]
 <font size="-1">_Author: Andrew Luke - Dec. 2018_</font>
 
 ## Overview
diff --git a/Language Best Practices/Net-C#-Best-Practices.md b/Language Best Practices/Net-C#-Best-Practices.md
index 9eba2d2..a7e9e73 100644
--- a/Language Best Practices/Net-C#-Best-Practices.md	
+++ b/Language Best Practices/Net-C#-Best-Practices.md	
@@ -5,7 +5,7 @@
 - [Handling User Input](#handling-user-input)
 
  # Overview
-Microsoft's .Net (DotNet) framework, like most modern frameworks, is generally secure from memory corruptions and code control (ex., stack corruption) style attacks, as long as the framework is kept up-to-date with the latest version from Microsoft. However, over the years, there have been some features of the framework that are now considered unsafe, or do not provide the protections developers believe they do. Below is general guidance on what to watch out for when developing in .Net languages.
+Microsoft's .Net (DotNet) framework, like most modern frameworks, is generally secure from memory corruptions and code control (ex., stack corruption) style attacks, as long as the framework is kept up-to-date with the latest version from Microsoft. However, over the years, there have been some features of the framework that are now considered unsafe, or do not provide the protections developers believe they do. Below is general best practices on what to watch out for when developing in .Net languages.
 
 - [Untrusted Code and Resource](#untrusted-code-and-resources)
 - [Handling User Input](#handling-user-input)
diff --git a/Language Best Practices/Nodejs-Best-Practices.md b/Language Best Practices/Nodejs-Best-Practices.md
index bec6544..4cc3940 100644
--- a/Language Best Practices/Nodejs-Best-Practices.md	
+++ b/Language Best Practices/Nodejs-Best-Practices.md	
@@ -1,10 +1,10 @@
-# Node.js Secure Development [Language Guidance]
+# Node.js Secure Development [Language Best Practices]
 <font size="-1">_Author: Brandon Caldwell - Dec. 2018_</font>
 
 ### Overview
 
 
-This guide will provide general guidance for developing more secure code in Node.js.
+This guide will provide general best practices for developing more secure code in Node.js.
 - [Always Validate External Inputs](#always-validate-external-inputs)
 - [HTTP Headers](#http-headers)
 - [Use of eval()](#use-of-eval)
diff --git a/Language Best Practices/Ruby-Best-Practices.md b/Language Best Practices/Ruby-Best-Practices.md
index fb641b2..5a0e9b1 100644
--- a/Language Best Practices/Ruby-Best-Practices.md	
+++ b/Language Best Practices/Ruby-Best-Practices.md	
@@ -1,4 +1,4 @@
-# Ruby Security Guidelines [Language Guidance]
+# Ruby Security Guidelines [Language Best Practices]
 
 <font size="-1">_Author: Andrew Luke Dec. 2018_</font
 
diff --git a/README.md b/README.md
index 00a9182..0fdf505 100644
--- a/README.md
+++ b/README.md
@@ -20,7 +20,7 @@ Our SSDLC is currently a suite of offerings by the Unity Application Security te
 #### SSDLC  Documentation
 The SSDLC is an ever evolving set of documents that our team has drafted as an attempt to capture industry best practices in a single location for our developers. The recommendations aren't perfect, and are always in draft. There are gaps, both in the technology we cover and how deep we are in each topic, however, we felt it better to share with our developers (and you!) as much as we could. Tt does no good for us to hoard a complete library of knowledge because we're missing _just one more article_ :)
 
-This SSDLC is intended to be a practical reference for developers to help them design and develop more secure products spread over 3 main topics: [Coding Practice](./Coding%Practice), [Language Guidance](./Language%20Guidance), and [Security Process](./Security%20Process). Further, we'll be sharing our [Tools and Automation](./) and [Trainings](./) in the future.
+This SSDLC is intended to be a practical reference for developers to help them design and develop more secure products spread over 3 main topics: [Coding Practice](./Coding%Practice), [Language Best Practices](./Language%Best%Practices), and [Security Process](./Security%20Process). Further, we'll be sharing our [Tools and Automation](./) and [Trainings](./) in the future.
 #### Trainings
 _NOTE: The Trainings are still TBD - We'll get them in here as soon as we can!_
 As a further supplement to our SSDLC, the Unity Security team has developed several presentations to provide more entertaining security content. The training was built with the intent to deliver the sessions in-person, as part of mini internal security conferences. Ideally, we'd also record these presentations to share with folks who can't make it to the live sessions.
diff --git a/Security Process/Implementation-Review.md b/Security Process/Implementation-Review.md
index f37cdef..cb321b4 100644
--- a/Security Process/Implementation-Review.md	
+++ b/Security Process/Implementation-Review.md	
@@ -60,7 +60,7 @@ AppSec will review applications by performing a code review and performing manua
 Typically an implementation review will occur over the span of one to two weeks. However ,level of effort for a review will depend on the size and risk of an application. When scheduling an implementation review an agreed upon amount of time will be decided between AppSec and the development team. If the engineer performing the design review runs into any issues, the development team will be notified immediately, and further steps will be decided.
 
 ## Things We Care About
-An application will be compared against any requirements set forth by the Audit and Compliance team. Any additional security requirements that were determined in the design review phase will also be validated during the test. The code will be reviewed against the [language-specific guidelines provided by AppSec](../Language%20Guidance). A set of common vulnerabilities that AppSec maintains can also be used to check an application against. AppSec will also ensure the application follows [provided design principles](../Coding%20Practice/Secure-Design-Principles.md).
+An application will be compared against any requirements set forth by the Audit and Compliance team. Any additional security requirements that were determined in the design review phase will also be validated during the test. The code will be reviewed against the [language-specific guidelines provided by AppSec](../Language%20Best%20Practices). A set of common vulnerabilities that AppSec maintains can also be used to check an application against. AppSec will also ensure the application follows [provided design principles](../Coding%20Practice/Secure-Design-Principles.md).
 
 ## Reporting
 At the end of an implementation review, AppSec will schedule a meeting to discuss the findings and answer any questions the development team has. Any critical issues or high issues that need immediate attention will be reported to the designated point of contact immediately. All findings will be held to the escalation process as outlined in our [[Security Process] Risk Rating (aka., Security Bug Bar)](./Risk-Rating.md).
\ No newline at end of file

From 8f6a133b9b989993ebe60e450d177f4e6becea23 Mon Sep 17 00:00:00 2001
From: Brandon Caldwell <brandonc@unity3d.com>
Date: Wed, 27 Nov 2019 11:24:03 -0800
Subject: [PATCH 29/54] Github didn't like the table formatting for the common
 attack table. This should fix it.

---
 Security Process/Bug-Bar.md | 75 +++++++++++++++++++------------------
 1 file changed, 38 insertions(+), 37 deletions(-)

diff --git a/Security Process/Bug-Bar.md b/Security Process/Bug-Bar.md
index 306e3ef..53bcd11 100644
--- a/Security Process/Bug-Bar.md	
+++ b/Security Process/Bug-Bar.md	
@@ -107,42 +107,43 @@ The bar allows us to triage security bugs to ensure those that are most severe w
 High and above will require a patch gets created and released for our customers. If at all possible we should work on getting these fixes in with patches that are already going out. Lows will be filed and the team owning the feature can address it as a normal bug.
 
 ##### What are some examples of the table above applied to actual attack types?
-The below table has many examples of common attacks and how they would land on the bug bar described above:
-|          |                                                             |                                              |                |                    | 
-|----------|-------------------------------------------------------------|----------------------------------------------|----------------|--------------------| 
-| Severity | Finding                                                     | Category                                     | Finding Impact | Finding Likelihood | 
-| Critical | Internet Accessible Remote Code Execution                   | Remote Code Execution (RCE)                  | High           | High               | 
-|          | Stored Cross Site Scripting on unity.com                    | Cross-Site Scripting (XSS)                   | High           | High               | 
-|          | Administrative Privilege Escalation                         | Broken Access Control/Authorization (BAC)    | High           | High               | 
-|          | Authentication Bypass  w/ Access to User Data               | Broken Authentication and Session Management | High           | High               | 
-|          |                                                             |                                              |                |                    | 
-| High     | Remote Code Execution on an isolated instance               | Remote Code Execution (RCE)                  | Medium         | High               | 
-|          | Partial Privilege Escalation                                | Broken Access Control/Authorization (BAC)    | Medium         | High               | 
-|          | Production Secrets in Code Repository                       | Sensitive Data Exposure                      | High           | Medium             | 
-|          | Server-side Request Forgery w/ accessible internal services | Server-Side Injection                        | High           | Medium             | 
-|          | Cross site request forgery for sensitive data               | Cross-Site Request Forgery (CSRF)            | Medium         | High               | 
-|          | Access Token Leak resulting in full account compromise      | Sensitive Data Exposure                      | High           | Medium             | 
-|          | Reflected Cross-Site Scripting                              | Cross-Site Scripting (XSS)                   | Medium         | High               | 
-|          | Persistent remote denial of service                         | Denial-of-Service (DoS)                      | High           | Medium             | 
-|          | No TLS/HTTPS/Transport Encryption on sensitive service      | Insecure Data Transport                      | High           | Medium             | 
-|          |                                                             |                                              |                |                    | 
-| Medium   | Cross site request forgery for non-sensitive data           | Cross-Site Request Forgery (CSRF)            | Medium         | Medium             | 
-|          | Server-side Request Forgery (Info Disclosure)               | Server-Side Injection                        | Medium         | Medium             | 
-|          | Session Fixation                                            | Broken Authentication and Session Management | Medium         | Medium             | 
-|          | Access Token Leak w/ Limited Scope                          | Sensitive Data Exposure                      | Low            | High               | 
-|          | Multi-factor authentication bypass                          | Broken Authentication and Session Management | High           | Low                | 
-|          | Multi-packet Denial of Service                              | Denial-of-Service (DoS)                      | Medium         | Medium             | 
-|          | No TLS/HTTPS/Transport Encryption on non-sensitive service  | Insecure Data Transport                      | Medium         | Medium             | 
-|          | Insecure Cryptographic Options                              | Broken Cryptography                          | High           | Low                | 
-|          | Publicly Accessible Google Groups                           | Insufficient Security Configurability        | Medium         | Medium             | 
-|          | Cookie Flags                                                | Server Security Misconfiguration             | Low            | High               | 
-|          |                                                             |                                              |                |                    | 
-| Low      | Clickjacking                                                | Server Security Misconfiguration             | Low            | Medium             | 
-|          | Open Redirect                                               | Unvalidated Redirects and Forwards           | Low            | Medium             | 
-|          | Multi-packet DoS                                            | Denial-of-Service (DoS)                      | Low            | Medium             | 
-|          | Leaked HTTP Headers                                         | Server Security Misconfiguration             | Low            | Medium             | 
-|          | Information Disclosure                                      | Sensitive Data Exposure                      | Low            | Medium             | 
-|          | Open CORS Policy                                            | Server Security Misconfiguration             | Low            | Medium             | 
-|          | Tabnabbing                                                  | Unvalidated Redirects and Forwards           | Low            | Low                | 
+
+<table>
+<tr><td>Severity</td><td>Finding</td><td>Category</td><td>Finding Impact</td><td>Finding Likelihood</td></tr>
+<tr><td rowspan="4">Critical</td><td>Internet Accessible Remote Code Execution</td><td>Remote Code Execution (RCE)</td><td>High</td><td>High</td></tr>
+<tr><td>Stored Cross Site Scripting on unity.com</td><td>Cross-Site Scripting (XSS)</td><td>High</td><td>High</td></tr>
+<tr><td>Administrative Privilege Escalation</td><td>Broken Access Control/Authorization (BAC)</td><td>High</td><td>High</td></tr>
+<tr><td>Authentication Bypass w/ Access to User Data</td><td>Broken Authentication and Session Management</td><td>High</td><td>High</td></tr>
+<tr><td colspan="5"><td></tr>
+
+<tr><td rowspan="9">High</td><td>Remote Code Execution on an isolated instance</td><td>Remote Code Execution (RCE)</td><td>Medium</td><td>High</td></tr>
+<tr><td>Partial Privilege Escalation</td><td>Broken Access Control/Authorization (BAC)</td><td>Medium</td><td>High</td></tr>
+<tr><td>Production Secrets in Code Repository</td><td>Sensitive Data Exposure</td><td>High</td><td>Medium</td></tr>
+<tr><td>Server-side Request Forgery w/ accessible internal services</td><td>Server-Side Injection</td><td>High</td><td>Medium</td></tr>
+<tr><td>Cross site request forgery for sensitive data</td><td>Cross-Site Request Forgery (CSRF)</td><td>Medium</td><td>High</td></tr>
+<tr><td>Access Token Leak resulting in full account compromise</td><td>Sensitive Data Exposure</td><td>High</td><td>Medium</td></tr>
+<tr><td>Reflected Cross-Site Scripting</td><td>Cross-Site Scripting (XSS)</td><td>Medium</td><td>High</td></tr>
+<tr><td>Persistent remote denial of service</td><td>Denial-of-Service (DoS)</td><td>High</td><td>Medium</td></tr>
+<tr><td>No TLS/HTTPS/Transport Encryption on sensitive service</td><td>Insecure Data Transport</td><td>High</td><td>Medium</td></tr>
+<tr><td colspan="5"><td></tr>
+<tr><td rowspan="10">Medium</td><td>Cross site request forgery for non-sensitive data</td><td>Cross-Site Request Forgery (CSRF)</td><td>Medium</td><td>Medium</td></tr>
+<tr><td>Server-side Request Forgery (Info Disclosure)</td><td>Server-Side Injection</td><td>Medium</td><td>Medium</td></tr>
+<tr><td>Session Fixation</td><td>Broken Authentication and Session Management</td><td>Medium</td><td>Medium</td></tr>
+<tr><td>Access Token Leak w/ Limited Scope</td><td>Sensitive Data Exposure</td><td>Low</td><td>High</td></tr>
+<tr><td>Multi-factor authentication bypass</td><td>Broken Authentication and Session Management</td><td>High</td><td>Low</td></tr>
+<tr><td>Multi-packet Denial of Service</td><td>Denial-of-Service (DoS)</td><td>Medium</td><td>Medium</td></tr>
+<tr><td>No TLS/HTTPS/Transport Encryption on non-sensitive service</td><td>Insecure Data Transport</td><td>Medium</td><td>Medium</td></tr>
+<tr><td>Insecure Cryptographic Options</td><td>Broken Cryptography</td><td>High</td><td>Low</td></tr>
+<tr><td>Publicly Accessible Google Groups</td><td>Insufficient Security Configurability</td><td>Medium</td><td>Medium</td></tr>
+<tr><td>Cookie Flags</td><td>Server Security Misconfiguration</td><td>Low</td><td>High</td></tr>
+<tr><td colspan="5"><td></tr>
+<tr><td rowspan="7">Low</td><td>Clickjacking</td><td>Server Security Misconfiguration</td><td>Low</td><td>Medium</td></tr>
+<tr><td>Open Redirect</td><td>Unvalidated Redirects and Forwards</td><td>Low</td><td>Medium</td></tr>
+<tr><td>Multi-packet DoS</td><td>Denial-of-Service (DoS)</td><td>Low</td><td>Medium</td></tr>
+<tr><td>Leaked HTTP Headers</td><td>Server Security Misconfiguration</td><td>Low</td><td>Medium</td></tr>
+<tr><td>Information Disclosure</td><td>Sensitive Data Exposure</td><td>Low</td><td>Medium</td></tr>
+<tr><td>Open CORS Policy</td><td>Server Security Misconfiguration</td><td>Low</td><td>Medium</td></tr>
+<tr><td>Tabnabbing</td><td>Unvalidated Redirects and Forwards</td><td>Low</td><td>Low</td></tr>
+<table>
 
 

From 8797bafa3e79c10728874c871b5631ac79437c47 Mon Sep 17 00:00:00 2001
From: Brandon Caldwell <brandonc@unity3d.com>
Date: Wed, 27 Nov 2019 12:28:14 -0800
Subject: [PATCH 30/54] Fixing some table layout issues in the bug bar doc.
 Content is all the same.

---
 CONTRIBUTING.md                               | 21 ------
 Coding Practice/API-Best-Practices.md         | 28 --------
 Coding Practice/AuthZ-AuthN-Guidelines.md     | 52 --------------
 Coding Practice/HTTP-Header-Security.md       | 18 -----
 .../Preventing-Common-Web-Attacks.md          | 59 ----------------
 Coding Practice/Secrets-Management.md         | 49 -------------
 Coding Practice/Secure-Design-Principles.md   | 27 --------
 Contribution_Template.md                      |  8 ---
 .../Golang-Best-Practices.md                  | 31 ---------
 .../Net-C#-Best-Practices.md                  |  8 ---
 .../Nodejs-Best-Practices.md                  | 20 ------
 .../Ruby-Best-Practices.md                    | 68 -------------------
 Overview.md                                   | 25 -------
 README.md                                     | 34 ----------
 Security Process/Risk-Rating.md               |  4 --
 15 files changed, 452 deletions(-)

diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 10ddb70..9ab0e5a 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -10,13 +10,8 @@ Second, before starting on a project that you intend to contribute to the unity-
 ### Document Style
 #### Basics
 - All contributions will be received as PRs - just read the recommendation below first please! 😁
-<<<<<<< HEAD
-- This is intended to be a technical reference for other collegeaues in the security community, so the language and style should reflect that.
-- You'll notice that our language if fairly casual for this type of content, but keep the language civil/mild and avoid using too much lingo when writing, and when using an abbreviation, please provide he definition upon its first use. Also refer to our our official [Code of Conduct](./CODE-OF-CONDUCT.md).
-=======
 - This is intended to be a technical reference for other colleagues in the security community, so the language and style should reflect that.
 - You'll notice that our language is fairly casual for this type of content, but keep the language civil/mild and avoid using too much lingo when writing, and when using an abbreviation, please provide he definition upon its first use. Also refer to our our official [Code of Conduct](./CODE-OF-CONDUCT.md).
->>>>>>> 2910d0b35380405a483e2fd4eb9636ac62a937e1
 - Given the nature of this content, it's ultimately meant for developers writing the code, not just security folks looking at it - it's not productive to write an article that not everyone can understand. Keep things simple, but accurate.
 
 #### Article Updates
@@ -24,30 +19,18 @@ Second, before starting on a project that you intend to contribute to the unity-
 Simply update the spelling of the article and do a PR. For simple changes like this, we won't be updating the Authorship or contributor section in the article itself, but your PR will be in the changelog.
 
 ##### New Content and Substantial Changes
-<<<<<<< HEAD
-If you want to contribute new security recommendations or research to an additional article, provide the PR ensuring that you're maintaning the original articles style and template as closely as reasonable.
-=======
 If you want to contribute new security recommendations or research to an additional article, provide the PR ensuring that you're maintaining the original articles style and template as closely as reasonable.
->>>>>>> 2910d0b35380405a483e2fd4eb9636ac62a937e1
 
 If mutliple people contributed to the content, please include their names in the *Contributors* section at the end of the article. 
 
 #### New Articles and the Template
 If creating a new article, we'd recommend taking a look at the [Contribution_Template](./Contribution_Template.md) that we have to help improve consistency in the article formatting. 
-<<<<<<< HEAD
-We're open to article in differing format, but variance from the template will necessicate a review of the articles layout to ensure it's readable and logical.
-=======
 We're open to article in differing format, but variance from the template will necessitate a review of the articles layout to ensure it's readable and logical.
->>>>>>> 2910d0b35380405a483e2fd4eb9636ac62a937e1
 
 For new articles, please ensure everyone who has substantially contributed to the article is appropriately credited as an author.
 
 ### Attribution and Credit
-<<<<<<< HEAD
-An importact aspect of this body of work is that contributors are recognized for their work. As such, authors and contributors will be recognized in the content of the Markdown file, not just by their names in the Git changelogs. Above this is discused a bit, but we'll repeat it here for clarity:
-=======
 An important aspect of this body of work is that contributors are recognized for their work. As such, authors and contributors will be recognized in the content of the Markdown file, not just by their names in the Git changelogs. Above this is discussed a bit, but we'll repeat it here for clarity:
->>>>>>> 2910d0b35380405a483e2fd4eb9636ac62a937e1
 - Authors: Original Authors of an article will be given credit at the top of the article. This will include the month and year the content was originally written.
 - Contributors: People who have provided new research or recommendations to an article will be added as a Contributor in the appropriate section at the bottom of the page, along with the month and year their contribution was made.
 - Minor changes: Minor changes (spelling, grammar, etc.), will be accepted directly as PRs, with the contributors account logged in the changelog for that PR.
@@ -66,8 +49,4 @@ We'd love to see industry specific versions, or flavors, of this SSDLC being dev
 ---
 
 
-<<<<<<< HEAD
-## All contributions are governed by the [Apache 2.0 license](./LICENSE.md).
-=======
 ## All contributions are governed by the [Apache 2.0 license](./LICENSE.md).
->>>>>>> 2910d0b35380405a483e2fd4eb9636ac62a937e1
diff --git a/Coding Practice/API-Best-Practices.md b/Coding Practice/API-Best-Practices.md
index 492ab0b..6b0e26c 100644
--- a/Coding Practice/API-Best-Practices.md	
+++ b/Coding Practice/API-Best-Practices.md	
@@ -17,11 +17,7 @@ This document covers general security guidelines for API endpoints within Unity.
 API endpoints should follow the principle of least privilege. Services with protected information should serve to the smallest group possible.
 ###### Why We Care
 
-<<<<<<< HEAD
-APIs with misconfigured access controls can lead to unintentional information leaks, or unauthorized and malicious state changing actions on sensitive data.
-=======
 APIs with misconfigured access controls can lead to unintentional information leaks, or unauthorized and malicious state-changing actions on sensitive data.
->>>>>>> 2910d0b35380405a483e2fd4eb9636ac62a937e1
 ###### Example of Issue (Optional)
 
 A POST that allows the user to modify information on an account without checking if the user owns the account being modified.
@@ -52,11 +48,7 @@ Incorrect access controls can range from High to Low Severity.
 Incoming data can be malformed or crafted to cause unintended behavior when it is parsed.
 ###### Why We Care
 
-<<<<<<< HEAD
-Depending on how input is parsed, it is possible unvalidated input can contain command injections, or other harmful actions.
-=======
 Depending on how input is parsed, it is possible for unvalidated input to contain command injections, or other harmful actions.
->>>>>>> 2910d0b35380405a483e2fd4eb9636ac62a937e1
 ###### Example of Issue (Optional)
 *TBD*
 
@@ -73,13 +65,7 @@ Restrict http methods
 Parsing - Third party parsers should be kept up to date, changes to internal parsers should be carefully reviewed.
 ###### Risk Rating
 
-<<<<<<< HEAD
-Input Validation issues could range from Low to High depending on what how the error can be leveraged.
-###### References (Optional)
-*TBD - List external references for more detailed guidance*
-=======
 Input Validation issues could range from Low to High depending on how the error can be leveraged.
->>>>>>> 2910d0b35380405a483e2fd4eb9636ac62a937e1
 
 ---
 ### Request Integrity
@@ -98,11 +84,7 @@ An attacker sends a previous, genuine request to cause an action to happen again
 Modified requests in-transit: An attacker modifies data in the genuine request as it is sent.
 ###### How to Fix?
 
-<<<<<<< HEAD
-Generate signatures or HMACs for each request containing sensitive data or actions. Check the signature of the request to determine if it is genuine. Sign requests that include timestamps, and deny all requests that are relatively too old.
-=======
 Generate signatures or HMACs (Hashed Message Authentication Codes) for each request containing sensitive data or actions. Check the signature of the request to determine if it is genuine. Sign requests that include timestamps, and deny all requests that are relatively too old.
->>>>>>> 2910d0b35380405a483e2fd4eb9636ac62a937e1
 ###### Risk Rating
 
 Depending on what actions the request can take, severity could range from High to Low.
@@ -126,19 +108,9 @@ Returning stack traces or other descriptive information of the service backend
 
 Log and monitor API activity. Detecting anomalies can assist in finding malicious activity that isn’t apparent anywhere else.
 
-<<<<<<< HEAD
-Disable CORS if not needed, or scope it down as small as possible to prevent forged requests or data leakage.
-=======
 Disable CORS (Cross-Origin Resource Sharing) if not needed, or scope it down as small as possible to prevent forged requests or data leakage.
->>>>>>> 2910d0b35380405a483e2fd4eb9636ac62a937e1
 
 Return vague error responses. Put as little information as possible when returning an error to the user. Do not return any information about the server environment or debug information like stack traces.
 ###### Risk Rating
 
 Ranging from Low to High depending on context.
-<<<<<<< HEAD
-###### References (Optional)
-
-*TBD - List external references for more detailed guidance*
-=======
->>>>>>> 2910d0b35380405a483e2fd4eb9636ac62a937e1
diff --git a/Coding Practice/AuthZ-AuthN-Guidelines.md b/Coding Practice/AuthZ-AuthN-Guidelines.md
index 45abcd8..0da5df7 100644
--- a/Coding Practice/AuthZ-AuthN-Guidelines.md	
+++ b/Coding Practice/AuthZ-AuthN-Guidelines.md	
@@ -1,9 +1,5 @@
 # Authorization and Authentication Guidelines [Coding Practice]
-<<<<<<< HEAD
-<font size="-1">_Author: Carlo Valentien - Dec. 2018_</font>
-=======
 <font size="-1">_Author: Carlo Valentin - Dec. 2018_</font>
->>>>>>> 2910d0b35380405a483e2fd4eb9636ac62a937e1
 
 ## Overview
 
@@ -19,26 +15,6 @@ This document provides guidelines for how to implement authentication and author
 
 **Authorization** is the process of ensuring a user can only access resources they are supposed to, usually based on some role or Risk Rating that is defined according to business logic.
 ## Recommendations
-<<<<<<< HEAD
-### Use a Trusted Identity Provider
-###### Description
-
-Most of our users will be accessing services related to Unity, and we should Unity ID to authenticate those users to any new services or publicly facing applications. Using a single, unified identity to authenticate a user will make it easy for the user to use a new service and application.
-
-When creating internal applications, validate users via their IT issued credentials. 
-###### Why We Care
-
-Many services will require authentication as a requirement. No authentication allows for anonymous access, which prevents proper logging and brings the risk of trivial information disclosure. However, designing an entire authentication service for you an application is also no trivial task, with many caveats that can lead to leaked/bypassed credentials, and a number of other issues. By using a trusted identity provider, the security team can work on securing a small number of authentication platforms to the benefit of a number of teams at Uniyt.
-###### How to Fix?
-
-Determine if your application is an internal or external application. If it is external, contact Genesis and Security to integrate your application with Unity ID. If it is internal, contact IT to integrate with out internal authentication system.
-###### Risk Rating
-
-High
-
----
-=======
->>>>>>> 2910d0b35380405a483e2fd4eb9636ac62a937e1
 ### Require Multi-Factor Authentication for Sensitive Applications
 ###### Description
 
@@ -57,15 +33,6 @@ Medium
 ### Limit OAuth2 Scope by the Principle of Least Privilege
 ###### Description
 
-<<<<<<< HEAD
-When an OAuth2 client, a scope is defined for the the client. This scope determines which Genesis Backend APIs are accessible to the client after performing authentication. When setting up a new OAuth2 client, the team requesting the client should identify what APIs/data they need access to, and limit the scope to those specific APIs.
-###### Why We Care
-
-Limiting the scope of our APIs is a best practice, that can limit the impact of a successful attack. Also, often it is a Unity ID user that is authenticating using the given scope, and with the given access token will give the user direct access to the APIs. Since this is publicly accessible, care should be taken that the user cannot access sensitive APIs, in particular APIs that handle personally identifiable information (PII).
-###### How to Fix?
-
-During the requirements phase, determine what information is needed for the OAuth2 client, and limit the APIs to only what is necessary. If possible, work with Genesis to build a custom scope that will limit access to wider APIs. 
-=======
 When an OAuth2 client, a scope is defined for the the client. This scope determines which backend APIs are accessible to the client after performing authentication via the auth provider. When setting up a new OAuth2 client, the team requesting the client should identify what APIs/data they need access to, and limit the scope to those specific APIs.
 ###### Why We Care
 
@@ -73,7 +40,6 @@ Limiting the scope of our APIs is a best practice that can limit the impact of a
 ###### How to Fix?
 
 During the requirements phase, determine what information is needed for the OAuth2 client, and limit the APIs to only what is necessary. If possible, work with the auth provider to build a custom scope that will limit access to wider APIs. 
->>>>>>> 2910d0b35380405a483e2fd4eb9636ac62a937e1
 ###### Risk Rating
 
 Medium
@@ -85,17 +51,10 @@ Medium
 ### Limited Token Lifetimes
 ###### Description
 
-<<<<<<< HEAD
-When authenticating, a variety of tokens are used to prove the identity of a user. This is typically through a session cookie, or an access token attached to a user’s account. These tokens should have the shortest lifetime that balances the needs to of the users with security. Tokens should not be valid for an infinite amount of time, and should expire within a reasonable timeframe.
-###### Why We Care
-
-This is primarily a defense-in-depth measure, focusing on the case if these tokens are compromised, it will limit the impact of an attack. This also decreases the attack surface of a resulting application, reducing the number of valid tokens at any given time.
-=======
 When authenticating, a variety of tokens are used to prove the identity of a user. This is typically through a session cookie, or an access token attached to a user’s account. These tokens should have the shortest lifetime that balances the needs of the users with security. Tokens should not be valid for an infinite length of time, and should expire within a reasonable timeframe.
 ###### Why We Care
 
 This is primarily a defense-in-depth measure, focusing on limiting the impact of an attack if these tokens are compromised. This also decreases the attack surface of a resulting application, reducing the number of valid tokens at any given time.
->>>>>>> 2910d0b35380405a483e2fd4eb9636ac62a937e1
 ###### How to Fix?
 
 Check all tokens related to authentication, and review their lifetimes. If you are unsure, contact security for recommendations on their lifetimes. When possible, use the shortest lifetime within a reasonable use.
@@ -107,11 +66,7 @@ Medium
 ### Validating OAuth2 Redirect URIs
 ###### Description
 
-<<<<<<< HEAD
-When performing the OAuth2 login flow, a redirect URI is used to securely send the access token to the client web application, after it has authenticated with Genesis. This is provided by the client during the OAuth2 flow. This URI should be validated to ensure it is a known URI that is used by the OAuth2 client.
-=======
 When performing the OAuth2 login flow, a redirect URI is used to securely send the access token to the client web application, after it has authenticated with the auth provider. This is provided by the client during the OAuth2 flow. This URI should be validated to ensure it is a known URI that is used by the OAuth2 client.
->>>>>>> 2910d0b35380405a483e2fd4eb9636ac62a937e1
 ###### Why We Care
 
 This prevents a potential information disclosure attack when there is an open redirect on a valid redirect URI. This results in a user’s OAuth token being potentially leaked, compromising their account.
@@ -144,17 +99,10 @@ High
 ### Validating the OAuth2 State Parameter
 ###### Description
 
-<<<<<<< HEAD
-When starting the initial OAuth2 flow, the client has the option of providing a state parameter. This state parameter is then send back with the authorization to be validated by the client later in the flow. This state parameter should be generated upon the initial OAuth2 request, and stored to validate once the authorization from Genesis has occurred.
-###### Why We Care
-
-This is to ensure that the OAuth2 flow is initiated by the user, and is not vulnerable to a potential CSRF. By ensuring that the user has initiated the OAuth2 flow, they will be performing actions within their account with known permissions.
-=======
 When starting the initial OAuth2 flow, the client has the option of providing a state parameter. This state parameter is then sent back with the authorization to be validated by the client later in the flow. This state parameter should be generated upon the initial OAuth2 request, and stored to validate once the authorization from the auth provider has occurred.
 ###### Why We Care
 
 This is to ensure that the OAuth2 flow is initiated by the user, and is not vulnerable to a potential CSRF (Cross-Site Request Forgery). By ensuring that the user has initiated the OAuth2 flow, they will be performing actions within their account with known permissions.
->>>>>>> 2910d0b35380405a483e2fd4eb9636ac62a937e1
 ###### How to Fix?
 
 Generate a cryptographically-secure random state parameter when the OAuth2 flow is initialized. The client should validate this when it is returned through the redirect URI callback. The parameter should only be valid for the same OAuth2 flow that initiated it.
diff --git a/Coding Practice/HTTP-Header-Security.md b/Coding Practice/HTTP-Header-Security.md
index 5e2804c..90ca646 100644
--- a/Coding Practice/HTTP-Header-Security.md	
+++ b/Coding Practice/HTTP-Header-Security.md	
@@ -1,11 +1,7 @@
 # HTTP Header Security [Coding Practice]
 <font size="-1">_Author: Christian Håland - Dec. 2018_</font>
 ## Overview
-<<<<<<< HEAD
-This document describes the HTTP security headers that we strongly recommend are implemented on all of Unity’s Internet-facing services. https://observatory.mozilla.org can be used to check your site's current headers. The headers are listed in order of importance, but please not that a proper secure Content Security Policy can be difficult to implement unless the application is designed from the beginning with this in mind. 
-=======
 This document describes the HTTP security headers that we strongly recommend are implemented on all of Unity’s Internet-facing services. https://observatory.mozilla.org can be used to check your site's current headers. The headers are listed in order of importance, but please note that a proper secure Content Security Policy can be difficult to implement unless the application is designed from the beginning with this in mind. 
->>>>>>> 2910d0b35380405a483e2fd4eb9636ac62a937e1
 
 Therefore, try to get some quick wins with headers such as: `HTTP Strict Transport Security`, `X-Frame-Options`, `X-XSS-Protection` and `X-Content-Type-Options` first.
 
@@ -35,15 +31,9 @@ Once confident that it's working you should aim for a max-age of minimum 6 month
     
     Strict-Transport-Security: max-age=63072000
 ---
-<<<<<<< HEAD
-#### Content-Security-Policy
-
-This header aims to reduce or even eliminate the impact of XSS attacks. It can be used to tell the browser where the website is supposed to load resources from.
-=======
 #### Content-Security-Policy (CSP)
 
 This header aims to reduce or even eliminate the impact of XSS (Cross-Site Scripting) attacks. It can be used to tell the browser where the website is supposed to load resources from.
->>>>>>> 2910d0b35380405a483e2fd4eb9636ac62a937e1
 
 A nice tool for generating your policy and get an explanation for all the directives can be found here. Note that this site can also serve as a reporting endpoint to test the policy without enforcing it:
 
@@ -106,11 +96,7 @@ X-XSS-Protection sets the configuration for the cross-site scripting filter buil
 ---
 #### X-Content-Type-Options
 
-<<<<<<< HEAD
-This header tells the browser not to guess the MIME type of the content served, but instead trust the “Content-Type” header. Without the X-Content-Type-Options header set, some older browsers can incorrectly detect files as scripts and stylesheets, potentially leading to XSS attacks.
-=======
 This header tells the browser not to guess the MIME (Multipurpose Internet Mail Extension) type of the content served, but instead trust the “Content-Type” header. Without the X-Content-Type-Options header set, some older browsers can incorrectly detect files as scripts and stylesheets, potentially leading to XSS attacks.
->>>>>>> 2910d0b35380405a483e2fd4eb9636ac62a937e1
 
 **Recommended setting:**
 
@@ -130,11 +116,7 @@ We may also want to do "Referrer-Policy: strict-origin" to only send the referre
 ---
 #### API
 
-<<<<<<< HEAD
-For APIs we want to ensure traffic is encrypted and restrict the potential impact of XSS vulnerabilities e.g. in error pages then they can't be used to run Javascript due to the Content-Security Policy not allowing scripts or iframes. Note that for APIs with documentation on the same domain such as  Swagger, this won't work and would need to be adapted.
-=======
 For APIs (Application Programming Interfaces) we want to ensure traffic is encrypted and restrict the potential impact of XSS vulnerabilities e.g. in error pages then they can't be used to run Javascript due to the Content-Security Policy not allowing scripts or iframes. Note that for APIs with documentation on the same domain such as Swagger, this won't work and would need to be adapted.
->>>>>>> 2910d0b35380405a483e2fd4eb9636ac62a937e1
 
 **Recommended settings:**
 
diff --git a/Coding Practice/Preventing-Common-Web-Attacks.md b/Coding Practice/Preventing-Common-Web-Attacks.md
index 2a0afa9..1bc1826 100644
--- a/Coding Practice/Preventing-Common-Web-Attacks.md	
+++ b/Coding Practice/Preventing-Common-Web-Attacks.md	
@@ -23,17 +23,11 @@ Clickjacking, also known as a "UI redress attack", occurs when an attacker uses
 With this attack an attacker can trick the user into performing sensitive actions on a page that only the user has access to.
 ###### Example of Issue
 
-<<<<<<< HEAD
-Say that we have a “Pay out” button on our internal Ads Payout tool and the application does not implement any protection against Clickjacking. An attacker that knows the internal URL for the tool can now include a hidden iframe on his site `www.cute-and-funny-puppies.net`:
-
-<iframe src=”https://ads-awesome-payout-tool.unity3d.com” style=”opacity:100”></iframe>
-=======
 Say that we have a “Pay out” button on an internal advertising payout tool and the application does not implement any protection against Clickjacking. An attacker that knows the internal URL for the tool can now include a hidden iframe on his site `www.cute-and-funny-puppies.net`:
 
 ```html
 <iframe src=”https://ads-awesome-payout-tool.unity3d.com” style=”opacity:100”></iframe>
 ```
->>>>>>> 2910d0b35380405a483e2fd4eb9636ac62a937e1
 
 When an admin that gets bored of approving payouts visits the attacker’s site to view some funny dog pictures, he simultaneously gets tricked into approving a payout for an attacker by clicking an element on the site that really clicks the payout button in the hidden iframe.
 ###### How to Fix?
@@ -109,14 +103,8 @@ The first and best way to fix this is to use a front-end framework that output e
 
 The following front-end frameworks are good choices that will make it harder to introduce XSS vulnerabilities as they were designed with this in mind:
 
-<<<<<<< HEAD
-    https://angular.io/guide/security#xss
-
-    https://reactjs.org/docs/introducing-jsx.html#jsx-prevents-injection-attacks
-=======
 - https://angular.io/guide/security#xss
 - https://reactjs.org/docs/introducing-jsx.html#jsx-prevents-injection-attacks
->>>>>>> 2910d0b35380405a483e2fd4eb9636ac62a937e1
 
 There are more frameworks that have good default XSS prevention, but these two that are in use already at Unity and and they are supported and used by big companies such as Google and Facebook
 
@@ -134,17 +122,9 @@ An example policy that only allows script files from the domain the application
 ###### Security Level
 
 XSS vulnerabilities is very common and constitute a medium to high risk depending on context and application. It’s a vulnerability class that requires a lot of resources from the application security team to deal with, unless the application is well designed and we would very much like to extinguish this vulnerability class in Unity applications.
-<<<<<<< HEAD
-References
-
-    https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet
-
-    https://csp.withgoogle.com/
-=======
 ###### References
 - https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet
 - https://csp.withgoogle.com/
->>>>>>> 2910d0b35380405a483e2fd4eb9636ac62a937e1
 
 ---
 ### Preventing SQL Injection
@@ -164,13 +144,9 @@ We’ve found examples of SQL injection in both the old Asset Store and in Multi
 
 All SQL queries should be parameterized queries, the exact syntax varies based on technologystack used, but usually looks more or less like this:
 
-<<<<<<< HEAD
-        E.g. SELECT * FROM users WHERE username = ‘?’, username
-=======
 ```sql
 SELECT * FROM users WHERE username = ‘?’, username
 ```
->>>>>>> 2910d0b35380405a483e2fd4eb9636ac62a937e1
 
 Sanitize all input, but especially input that you intend to use in a SQL query.
 Limit the privileges of your database user. You should never run application SQL queries as the database admin or a root / admin user.
@@ -188,21 +164,12 @@ Limit the privileges of your database user to the minimum.
  
 ###### Security Level
 
-<<<<<<< HEAD
-The severity of a SQL injection vulnerability ranges from high to critical depending on the application and context. For Unity, a SQL injection in Genesis would be an example of a critical vulnerability because it could lead to compromise of all user data.
-References
-
-https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet
-
-https://blog.websecurify.com/2014/08/hacking-nodejs-and-mongodb.html (Example noSQL attacks)
-=======
 The severity of a SQL injection vulnerability ranges from high to critical depending on the application and context. For example, a SQL injection in your auth provider would be a critical vulnerability because it could lead to compromise of all user data and potentially bypass of access controls.
 ###### References
 
 - https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet
 
 - https://blog.websecurify.com/2014/08/hacking-nodejs-and-mongodb.html (Example noSQL attacks)
->>>>>>> 2910d0b35380405a483e2fd4eb9636ac62a937e1
 
 --- 
 ### Preventing Cross-Site Request Forgery
@@ -226,11 +193,7 @@ If a logged in user visited this website it would create a file on the Online De
 There are several strategies to fixing this problem, and it depends a bit on the application’s architecture. Here are the main strategies that are most commonly used and accepted as a standard way of solving this problem:
 ###### _Authentication via HTTP header_
 
-<<<<<<< HEAD
-The Genesis API uses the “Authentication: Bearer xyzæøå” header for authentication. This header isn’t sent automatically and must be added using Javascript. Requests that require an authentication header to succeed are not vulnerable to CSRF attacks.
-=======
 Some auth APIs use the `“Authentication: Bearer <token goes here>”`  header for authentication. Requests that require an authentication header to succeed are not vulnerable to CSRF attacks.
->>>>>>> 2910d0b35380405a483e2fd4eb9636ac62a937e1
 ###### _CSRF Tokens_
 
 This is the most common and accepted protection mechanism. It works by requiring every form submission and request that perform an action to include a random CSRF token in the submitted data. Since this token is set and stored by the server, and tied to a user’s session, an attacker won’t be able to access it or guess it. This prevents CSRF attacks from succeeding as the server should reject any request that don’t have a valid token.
@@ -238,16 +201,8 @@ This is the most common and accepted protection mechanism. It works by requiring
 The first thing to make sure is that your application uses the HTTP GET and POST verbs appropriately, see http://guides.rubyonrails.org/security.html#csrf-countermeasures
 
 Next you should look at your web application framework to see if they have support for CSRF tokens. Most frameworks, like Ruby on Rails as mentioned above, will either have built-in support for easily adding CSRF tokens or libraries that help implement it. Here are two popular options for NodeJS and Golang:
-<<<<<<< HEAD
-
-
-    https://github.com/expressjs/csurf
-
-    https://github.com/utrack/gin-csrf
-=======
 -  https://github.com/expressjs/csurf
 - https://github.com/utrack/gin-csrf
->>>>>>> 2910d0b35380405a483e2fd4eb9636ac62a937e1
 
 ###### _Checking Origin / Referer headers_
 
@@ -264,30 +219,16 @@ Strict mode prevents the browser from sending the cookies cross-origin for any r
 
 Lax mode prevents this situation and allows GET requests to send along the cookies. Requests using any other HTTP verbs won’t send along the cookies. If the application uses HTTP verbs appropriately this would normally be enough to prevent CSRF attacks because the application shouldn’t use a GET request to perform any action in the application.
 
-<<<<<<< HEAD
-    Set-Cookie: CookieName=CookieValue; SameSite=Lax;
-
-    Set-Cookie: CookieName=CookieValue; SameSite=Strict;
-=======
 - Set Lax mode: `Set-Cookie: CookieName=CookieValue; SameSite=Lax;`
 - Set Strict mode: `Set-Cookie: CookieName=CookieValue; SameSite=Strict;`
->>>>>>> 2910d0b35380405a483e2fd4eb9636ac62a937e1
 
 Since this is a very new browser security feature, not all browsers support it yet and not all frameworks have APIs for setting cookies with this flag. Consider implementing it though, as it is simple, unobtrusive and effective way of preventing CSRF attacks and browser support is likely to increase in the future.
 Security Level
 
 The example above shows how serious CSRF vulnerabilities can be. The impact of a CSRF vulnerability can range from low to critical depending on the application. CSRF attacks are usually targeted and need to be tailored to a specific application, but there have also been CSRF vulnerabilities in commonly used libraries and frameworks that can be used by an attacker to target a multitude of sites at the same time.
-<<<<<<< HEAD
-References
-
-    https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet
-
-    https://www.netsparker.com/blog/web-security/same-site-cookie-attribute-prevent-cross-site-request-forgery/
-=======
 ###### References
 - https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet
 - https://www.netsparker.com/blog/web-security/same-site-cookie-attribute-prevent-cross-site-request-forgery/
->>>>>>> 2910d0b35380405a483e2fd4eb9636ac62a937e1
 
  ---
 ### Credential Leaks
diff --git a/Coding Practice/Secrets-Management.md b/Coding Practice/Secrets-Management.md
index 1d325f1..93cf46a 100644
--- a/Coding Practice/Secrets-Management.md	
+++ b/Coding Practice/Secrets-Management.md	
@@ -3,15 +3,9 @@
 
 ## Description
 
-<<<<<<< HEAD
-Developing and deploying secure services and applications at Unity requires integration with a number of internal and external systems, such as authentication and cloud storage. Further, much of the software development at Unity requires integration with a growing number of services, requiring developers to handle several secrets, for example: database credentials, api tokens, oauth secrets etc.
-
-The secrets need to be high-entropy, unique per service, and unique per environment. In many cases this will lead to many secrets for a team to manage, and as such these secrets have frequently been stored checked in as part of configuration files - an insecure practice. Once saved into a configuration file, they are frequently, and accidentally, checked into your favorite version control system on a publicly accessible cloud-hosted repositories, and hence into the hands of attackers. These secrets cannot be stored in such a manner, and need to be kept in an access controlled environment.
-=======
 Developing and deploying secure services and applications at Unity requires integration with a number of internal and external systems, such as authentication and cloud storage. Further, much of the software development at Unity requires integration with a growing number of services, requiring developers to handle several secrets, for example: database credentials, api tokens, oauth secrets, etc.
 
 The secrets need to be high-entropy, unique per service, and unique per environment. In many cases this will lead to many secrets for a team to manage, and as such these secrets have frequently been stored checked in as part of configuration files - an insecure practice. Once saved into a configuration file, they are frequently, and accidentally, checked into your favorite version control system on a publicly accessible cloud-hosted repositories, and hence into the hands of attackers. These secrets cannot be stored in such a manner, and need to be kept in an access-controlled environment.
->>>>>>> 2910d0b35380405a483e2fd4eb9636ac62a937e1
 ### Why We Care
 
 Secrets are secret for a reason, and often provide access to a lot of data, computing resources or privileged accounts. It is therefore crucial that we handle secrets well, ensure we limit their scope and use least privilege, and make the probability of accidental leaks as small as possible. (See Unity's Common Control Framework security controls CCF-4.04 and CCF-4.05)
@@ -19,11 +13,7 @@ Secrets are secret for a reason, and often provide access to a lot of data, comp
 
 Credential leaks to Github are a common, and troublesome issue within the industry. This can give malicious actors access to internal systems, data, apis and more. There are also other examples, such as accidentally hosting script files that contain credentials on a public web server.
 
-<<<<<<< HEAD
-It should go without saying, but when your credentials fall into someone else’s hands they can assume any of your privileges. A common example we see is someone granting themselves “Admin” so they do not have to concern themselves with identifying precisely the minimum privileges needed. They may only use these credentials for a small handful of API calls but when these credentials are exposed, a malicious actor can do anything “Admin” can do. These credentials are often exploited for launching cryptominers, ransomware attacks, or setting up backdoors for later use.
-=======
 It should go without saying, but when your credentials fall into someone-else's hands they can assume any of your privileges. A common example we see is someone granting themselves “Admin” so they do not have to concern themselves with identifying precisely the minimum privileges needed. They may only use these credentials for a small handful of API calls but when these credentials are exposed, a malicious actor can do anything “Admin” can do. These credentials are often exploited for launching cryptominers, ransomware attacks, or setting up backdoors for later use.
->>>>>>> 2910d0b35380405a483e2fd4eb9636ac62a937e1
 
 This is not limited to the example of “Admin” by any means. For example, compromising a user grants access to all groups the user may be a member of. These groups have the potential to span teams, projects, accounts, and more. This is commonly seen when a developer uses their own LDAP/Google credentials to test out a prototype of what their working on, only to later check-in that code to save their progress. It’s a bad habit to get into, despite the convenience it offers.
 **To summarize, TL;DR - Commonly found secrets in code (unencrypted):**
@@ -68,17 +58,10 @@ Common examples of secret usage are:
 ![Secrets on Fire](../images/secrets%20fire.png)
 
 
-<<<<<<< HEAD
-As a rule of thumb, you should use temporary credentials at every opportunity. Not all systems are built in a way that supports this and so using a secrets management tool, like Hashicorp Vault or AWS Secrets Manager, is strongly recommended. Environment variables are passable but not recommended. You should never store secrets in code.
-##### How to protect secrets
-
-After taking the steps above to prepare your application, leverage a secrets management infrastructure to safely store and access your secrets. Cloud options in Google Cloud KMS or Amazon AWS KMS.
-=======
 As a rule of thumb, you should use temporary credentials at every opportunity. Not all systems are built in a way that supports this and so using a secrets management tool, like Hashicorp Vault or AWS (Amazon Web Services) Secrets Manager, is strongly recommended. Environment variables are passable but not recommended. You should never store secrets in code.
 ##### How to protect secrets
 
 After taking the steps above to prepare your application, leverage a secrets management infrastructure to safely store and access your secrets. Cloud options in Google Cloud KMS (Key Management Service) or Amazon AWS KMS.
->>>>>>> 2910d0b35380405a483e2fd4eb9636ac62a937e1
 
 The application security team has tools monitoring for secrets in source code repositories, but this mechanism is only supposed to be the last line of defense and to avoid credential leaks it is up to the developer to be diligent when handling these sensitive pieces of data.
 #### Secret Stores
@@ -89,21 +72,13 @@ Vault supports a couple of options for secrets storage - Static and Dynamic. If
 
 These are your traditional secrets. Think Username, Password, and/or API Key. These can be stored via the Vault command-line tools, for example:
 
-<<<<<<< HEAD
-    vault write secret/stg/ads/ads-performance-valuation/AWS_ACCESS_KEY_ID secret=AKIAIII1337DEADBEEF
-=======
     vault write secret/stg/ads/ads-performance-valuation/AWS_ACCESS_KEY_ID secret=AKIASUP3R1337DEADBEEF
->>>>>>> 2910d0b35380405a483e2fd4eb9636ac62a937e1
 
 _For more Vault documentaion, see the linked guides below, in the Appendix_
 
 ###### Dynamic Secrets:
 
-<<<<<<< HEAD
-Vault has a variety of Secrets Engines to hook into services like AWS, GCP, SSH, PKI, (and more) to provide temporary credentials which expire on a time-based lease procured by Vault. In the example of the AWS Secrets Engine, Vault acts as an abstraction to an AWS STS call and serves up the resultant Access/Secret Key pair.
-=======
 Vault has a variety of Secrets Engines to hook into services like AWS, GCP (Google Cloud Platform), SSH (Secure SHell), PKI (Public Key Infrastructure), (and more) to provide temporary credentials which expire on a time-based lease procured by Vault. In the example of the AWS Secrets Engine, Vault acts as an abstraction to an AWS STS (Security Token Service) call and serves up the resultant Access/Secret Key pair.
->>>>>>> 2910d0b35380405a483e2fd4eb9636ac62a937e1
 
 For details on dynamic secrets, see Hashicorp’s guidance: [Dynamic Secrets Vault Support](https://learn.hashicorp.com/vault/getting-started/dynamic-secrets)
 
@@ -117,38 +92,15 @@ The Security team is still working to develop more complete best practices on ma
 ##### AWS Keys:
 
 AWS keys generally come in the following format:
-<<<<<<< HEAD
-
-    AWS_ACCESS_KEY_ID:AKIA***********VT43D
-
-    AWS_SECRET_ACCESS_KEY:SYU********************************TUFYIG
-
-
-These keys are generated by AWS IAM or AWS STS.
-=======
 - `AWS_ACCESS_KEY_ID:AKIA***********VT43D`
 - `AWS_SECRET_ACCESS_KEY:SYU********************************TIDHF`
 
 
 These keys are generated by AWS IAM (Identity and Access Management) or AWS STS.
->>>>>>> 2910d0b35380405a483e2fd4eb9636ac62a937e1
 
 Keys generated by IAM: these keys are assigned to an IAM User (max. 2 keys per user), which may be used by either an individual (human) or a service account (non-human). However, while these keys can be used for service accounts, it is best practice to leverage STS to generate temporary credentials wherever possible for non-human usage.
 
 Keys generated by STS: these keys are temporary and expire by default in 12 hours (min. 15mins, max. 36hrs). It is recommended to generate these keys with the minimum duration necessary. These keys are best practice as compromised keys quickly become useless to a malicious actor. STS also solves the problems presented by Creds in Source Code. Often times developers will use their personal Access Key/Secret Key pairs which can cause unexpected outages when someone leaves the company and their accounts are terminated; STS avoids this as well.
-<<<<<<< HEAD
-
-    import boto3
-
-    `# Create a session with attached role`
-    session = boto3.Session()    
-
-    `# Create an sts client with the session`
-    sts = session.client("sts")    
-
-    `# Get temporary credentials for the current session`
-    temporary_creds = sts.get_session_token()['Credentials']
-=======
 ```python
     import boto3
 
@@ -161,7 +113,6 @@ Keys generated by STS: these keys are temporary and expire by default in 12 hour
     # Get temporary credentials for the current session
     temporary_creds = sts.get_session_token()['Credentials']
 ```
->>>>>>> 2910d0b35380405a483e2fd4eb9636ac62a937e1
 
 
 
diff --git a/Coding Practice/Secure-Design-Principles.md b/Coding Practice/Secure-Design-Principles.md
index e1985d9..6ad9360 100644
--- a/Coding Practice/Secure-Design-Principles.md	
+++ b/Coding Practice/Secure-Design-Principles.md	
@@ -2,11 +2,7 @@
 <font size="-1">_Author: Carlo Valentin - Dec. 2018_</font>
 
 - [Minimize attack surface area](#minimize-attack-surface-area)
-<<<<<<< HEAD
-- [Establist secure defaults](#establish-secure-defaults)
-=======
 - [Establish secure defaults](#establish-secure-defaults)
->>>>>>> 2910d0b35380405a483e2fd4eb9636ac62a937e1
 - [Principle of least privilege](#principle-or-least-privilege)
 - [Principle of Defense in Depth](#principle-of-defense-in-depth)
 - [Fail securely](#fail-securely)
@@ -20,11 +16,7 @@
 
 Every feature that is added to an application adds an unknown amount of risk to the overall application. The aim for secure development is to reduce the overall risk by reducing the attack surface, by designing features of an application to minimize the attack surface.
 
-<<<<<<< HEAD
-Example: A web application implements online help with a search function. The search function may be vulnerable to SQL injection attacks. If the help feature was limited to authorized users, the attack likelihood is reduced. If the help feature’s search function was gated through centralized data validation routines, the ability to perform SQL injection is dramatically reduced. However, if the help feature was re-written to eliminate the search function (through better user interface, for example), this eliminates that attack surface, even if the help feature was available to the Internet at large.
-=======
 Example: A web application implements online help with a search function. The search function may be vulnerable to SQL (Standard Query Language) injection attacks. If the help feature was limited to authorized users, the attack likelihood is reduced. If the help feature’s search function was gated through centralized data validation routines, the ability to perform SQL injection is dramatically reduced. However, if the help feature was re-written to eliminate the search function (through better user interface, for example), this eliminates that attack surface, even if the help feature was available to the Internet at large.
->>>>>>> 2910d0b35380405a483e2fd4eb9636ac62a937e1
 
  
 ### Establish secure defaults
@@ -45,11 +37,7 @@ Example:  If a middleware server only requires access to the network, read acces
 
 The principle of defense in depth suggests that where one control would be reasonable, more controls that approach risks in different fashions are better. Controls, when used in depth, can make severe vulnerabilities increasingly difficult to exploit, and thus, unlikely to occur.
 
-<<<<<<< HEAD
-With secure coding, this may take the form of tier-based validation, centralized auditing controls, and requiring users to be logged on all pages.
-=======
 With secure coding, this may take the form of tier-based validation, centralized auditing controls, and requiring users to be logged on for all pages.
->>>>>>> 2910d0b35380405a483e2fd4eb9636ac62a937e1
 
 Example: A flawed administrative interface is unlikely to be vulnerable to anonymous attack if it correctly gates access to production management networks, checks for administrative user authorization, and logs all access.
 
@@ -59,11 +47,7 @@ Example: A flawed administrative interface is unlikely to be vulnerable to anony
 Applications regularly fail to process transactions for many reasons. How they fail can determine if an application is secure or not. For example:
 
 Incorrect sample:
-<<<<<<< HEAD
-
-=======
 ```javascript
->>>>>>> 2910d0b35380405a483e2fd4eb9636ac62a937e1
     isAdmin = true;
     try {
     codeWhichMayFail();
@@ -72,15 +56,9 @@ Incorrect sample:
     catch (Exception ex) {
     log.write(ex.toString());
     }
-<<<<<<< HEAD
-
- 
-
-=======
 ```
  
 ```javascript
->>>>>>> 2910d0b35380405a483e2fd4eb9636ac62a937e1
 Correct sample:
 
     isAdmin = false;
@@ -91,13 +69,8 @@ Correct sample:
     catch (Exception ex) {
     log.write(ex.toString());
     }
-<<<<<<< HEAD
-
-If either codeWhichMayFail() or isUserInRole fails or throws an exception, the user is an admin by default. This is obviously a security risk.
-=======
 ```
 If either `codeWhichMayFail()` or `isUserInRole` fails or throws an exception, the user is an admin by default. This is obviously a security risk.
->>>>>>> 2910d0b35380405a483e2fd4eb9636ac62a937e1
 
 
 ### Don’t trust services and validate externally sourced data
diff --git a/Contribution_Template.md b/Contribution_Template.md
index e0630dd..e6723a1 100644
--- a/Contribution_Template.md
+++ b/Contribution_Template.md
@@ -15,11 +15,7 @@ _\<Table of Contents of high-level Sections>_
 ## Recommendations
 ### Section-1
 ###### Description
-<<<<<<< HEAD
-_Provide a description of the risk to be mititgated by this best practice._
-=======
 _Provide a description of the risk to be mitigated by this best practice._
->>>>>>> 2910d0b35380405a483e2fd4eb9636ac62a937e1
 ###### Why We Care
 _Explain the actual real world impact of this risk. If possible, provide industry specific relevance._
 ###### How to Fix?
@@ -31,11 +27,7 @@ _Optionally provided a risk severity according to: [Risk-Rating.md](./Security%2
 ---
 ### Section-2
 ###### Description
-<<<<<<< HEAD
-_Provide a description of the risk to be mititgated by this best practice._
-=======
 _Provide a description of the risk to be mitigated by this best practice._
->>>>>>> 2910d0b35380405a483e2fd4eb9636ac62a937e1
 ###### Why We Care
 _Explain the actual real world impact of this risk. If possible, provide industry specific relevance._
 ###### How to Fix?
diff --git a/Language Best Practices/Golang-Best-Practices.md b/Language Best Practices/Golang-Best-Practices.md
index 132cfe8..9a982df 100644
--- a/Language Best Practices/Golang-Best-Practices.md	
+++ b/Language Best Practices/Golang-Best-Practices.md	
@@ -9,13 +9,6 @@ This is a set of security guidelines for the Golang programming language. Each e
 Golang is a strongly typed language that has taken steps to prevent security issues found in other languages. For example, there is no pointer arithmetic. Garbage collection is automatic. Another example, the standard crypto package for AES does not provide Cipher Block Chaining (CBC) as an option.
 
 
-<<<<<<< HEAD
-##### Security Considerations
-
-The net/http multiplexer ServeMux takes care of sanitizing the URL request path, redirecting any request containing “.” or “..” elements or repeated slashes to an equivalent, cleaner URL.
-
-=======
->>>>>>> 2910d0b35380405a483e2fd4eb9636ac62a937e1
 ##### Recommended Packages
 
 
@@ -73,17 +66,6 @@ _Example of Issue_:
 
 The following will declare the `<b>World</b>` string as HTML, printing it as-is into the HTML:
 
-<<<<<<< HEAD
-     tmpl.Execute(out, template.HTML(`<b>World</b>`))
-
- 
-###### How to Fix?
-
-The EscapeString() function in the native html package accepts a string and returns the same string with the special characters escaped. (i.e. < becomes &lt;). The html/template package has a stripTags() function, but it's unexported.
-
-The html/template package provides several functions for escaping strings:
-
-=======
 ```golang
 tmpl.Execute(out, template.HTML(`<b>World</b>`))
 ```
@@ -95,7 +77,6 @@ The EscapeString() function in the native html package accepts a string and retu
 The html/template package provides several functions for escaping strings:
 
 ```golang
->>>>>>> 2910d0b35380405a483e2fd4eb9636ac62a937e1
     HTMLEscape()
     HTMLEscapeString()
     HTMLEscaper()
@@ -103,11 +84,7 @@ The html/template package provides several functions for escaping strings:
     JSEscapeString()
     JSEscaper()
     URLQueryEscaper
-<<<<<<< HEAD
-
-=======
 ```
->>>>>>> 2910d0b35380405a483e2fd4eb9636ac62a937e1
 Avoid using template Typed Strings on user input.
 ###### Risk Rating
 
@@ -151,11 +128,7 @@ The crypto/rand package should be used instead of the math/rand package. This pa
 _Example:_
 
 This example reads 10 cryptographically secure pseudorandom numbers from rand.Reader and writes them to a byte slice:
-<<<<<<< HEAD
-
-=======
 ```golang
->>>>>>> 2910d0b35380405a483e2fd4eb9636ac62a937e1
     package main
 
     import (
@@ -176,11 +149,7 @@ This example reads 10 cryptographically secure pseudorandom numbers from rand.Re
     // The slice should now contain random bytes instead of only zeroes.
     fmt.Println(bytes.Equal(b, make([]byte, c)))
     }
-<<<<<<< HEAD
-
-=======
 ```
->>>>>>> 2910d0b35380405a483e2fd4eb9636ac62a937e1
  
 ###### Risk Rating
 
diff --git a/Language Best Practices/Net-C#-Best-Practices.md b/Language Best Practices/Net-C#-Best-Practices.md
index aa57402..921088d 100644
--- a/Language Best Practices/Net-C#-Best-Practices.md	
+++ b/Language Best Practices/Net-C#-Best-Practices.md	
@@ -51,11 +51,7 @@ The following best practices is largely relevant to ASP.Net and .Net Embedded br
   - Unicode escapes (%nnn).
   - Overlong UTF-8 escapes (%nn%nn).
   - Double escapes (%nn becomes %mmnn, where %mm is the escape for '%').
-<<<<<<< HEAD
-- Be wary of user names that might have more than one canonical format. For example, you can often use either the MYDOMAIN\username form or the username@mydomain.example.com form.
-=======
 - Be wary of user names that might have more than one canonical format. For example, you can often use either the `MYDOMAIN\username` form or the `username@mydomain.example.com` form.
->>>>>>> 2910d0b35380405a483e2fd4eb9636ac62a937e1
   - (From https://github.com/dotnet/docs/blob/master/docs/standard/security/security-and-user-input.md)
 
  ---
@@ -64,10 +60,6 @@ The following best practices is largely relevant to ASP.Net and .Net Embedded br
 - https://github.com/dotnet/docs/blob/master/docs/standard/security/secure-coding-guidelines.md
 - https://docs.microsoft.com/en-us/dotnet/framework/misc/code-access-security
 - https://docs.microsoft.com/en-us/dotnet/framework/misc/security-transparent-code
-<<<<<<< HEAD
-- https://support.microsoft.- com/en-us/help/2698981/asp-net-partial-trust-does-not-guarantee-application-isolation
-=======
 - https://support.microsoft.com/en-us/help/2698981/asp-net-partial-trust-does-not-guarantee-application-isolation
->>>>>>> 2910d0b35380405a483e2fd4eb9636ac62a937e1
 - Attacking .Net Serialization: https://speakerdeck.com/pwntester/attacking-net-serialization?slide=8
 - .Net Remoting Security Bulletin: - https://docs.microsoft.com/en-us/security-updates/SecurityBulletins/2012/ms12-035
diff --git a/Language Best Practices/Nodejs-Best-Practices.md b/Language Best Practices/Nodejs-Best-Practices.md
index 13236cf..4e38658 100644
--- a/Language Best Practices/Nodejs-Best-Practices.md	
+++ b/Language Best Practices/Nodejs-Best-Practices.md	
@@ -20,11 +20,7 @@ This guide will provide general best practices for developing more secure code i
 
 Generally the most dangerous part of any software is the point where it will process untrusted external data. As such, it is one of the most important areas to ensure attention is given.
 ###### Example of Issue
-<<<<<<< HEAD
-
-=======
 ```javascript
->>>>>>> 2910d0b35380405a483e2fd4eb9636ac62a937e1
     function buildList (var untrustedListSize){
         if ( 0 > untrustedListSize ){
             new Error("Negative value supplied for list size, die evil hacker!");
@@ -33,22 +29,14 @@ Generally the most dangerous part of any software is the point where it will pro
         var list = new Widget [ untrustedListSize ];
         list[0] = new Widget();
     }
-<<<<<<< HEAD
-
-=======
 ```
->>>>>>> 2910d0b35380405a483e2fd4eb9636ac62a937e1
 <sub>_(Adapted from: https://cwe.mitre.org/data/definitions/20.html)_</sub>
 
 ###### How to Fix?
 
 There are several validation libraries. The AppSec team hasn’t investigated and compared validation packages out there, though express-validator.js seems like a popular option among the Node.js community.
 
-<<<<<<< HEAD
-Mozilla has a decent article covering some basic of using that pacakge: https://developer.mozilla.org/en-US/docs/Learn/Server-side/Express_Nodejs/forms  
-=======
 Mozilla has a decent article covering some basic of using that package: https://developer.mozilla.org/en-US/docs/Learn/Server-side/Express_Nodejs/forms  
->>>>>>> 2910d0b35380405a483e2fd4eb9636ac62a937e1
 ###### Risk Rating
 
 While lack of validation can present a significant risk, it requires the underlying area of code to be vulnerable to exploitation, as such, this is considered a Low severity issue.
@@ -96,13 +84,9 @@ Use of the eval() function is incredibly dangerous, and rarely actually needed.
 eval(< anything in here> ) :D
 ###### How to Fix?
 
-<<<<<<< HEAD
-Generally, it's completely unsafe to execute untrusted code, and as such, should be avoid entirely. Any case of such use to be considered very seriously; if it's determined to be requisite, consider using the native VM module, which exposes Node.js' V8 engine for safer code execution
-=======
 Generally, it's completely unsafe to execute untrusted code, and as such, should be avoid entirely. Any case of such use to be considered very seriously.
 
 If running untrusted script determined to be requisite, work with the product security team to determined the best method to isolate this code. In some cases, using the native VM module, which exposes Node.js' V8 engine is acceptable, in other cases, more robust isolation may be required.
->>>>>>> 2910d0b35380405a483e2fd4eb9636ac62a937e1
 ###### Risk Rating
 
 Low - High
@@ -162,11 +146,7 @@ Medium
 Not a risk in itself, but the audit option of npm is a recently added feature to automatically scan installed packages for you project, with severity ratings and links to the details on the scanned risks. It’s recommended that this is run regularly against all projects, to help identify vulnerabilities that may exist in dependencies.
 ###### Why We Care
 
-<<<<<<< HEAD
-Packages are 3rd party code, that we often use without fully auditing. Until Unity has the resource to provide better auditing of packages, this is a great tool available for us to use.
-=======
 Unpatched npm packages can easily be exploited as the vulnerabilities are made public once patched.
->>>>>>> 2910d0b35380405a483e2fd4eb9636ac62a937e1
 ###### Example of Issue
 
 Here’s an example output:
diff --git a/Language Best Practices/Ruby-Best-Practices.md b/Language Best Practices/Ruby-Best-Practices.md
index abf868c..bd7afd6 100644
--- a/Language Best Practices/Ruby-Best-Practices.md	
+++ b/Language Best Practices/Ruby-Best-Practices.md	
@@ -1,10 +1,6 @@
 # Ruby Security Guidelines [Language Best Practices]
 
-<<<<<<< HEAD
-<font size="-1">_Author: Andrew Luke Dec. 2018_</font
-=======
 <font size="-1">_Author: Andrew Luke Dec. 2018_</font>
->>>>>>> 2910d0b35380405a483e2fd4eb9636ac62a937e1
 
 - [Avoid Combing User Input with Dangerous Calls](#)
 - [Use Proper REGEX Start and End of String Symbols](#)
@@ -97,22 +93,6 @@ When using REGEX to validate user input, misuse of these symbols can introduce t
 ###### Example of Issue
 
 The following REGEX filter is meant to accept only valid URLs
-<<<<<<< HEAD
-
-    /^https?:\/\/[^\n]+$/i
-
-
-Due to the ^ symbol use instead the \A symbol, the following submission would pass the filter because each line is processed separately and the second line matches:
-
-    
-
-    javascript:exploit_code();/*
-
-    http://hi.com
-
-    */
-
-=======
 ```regex
     /^https?:\/\/[^\n]+$/i
 ```
@@ -125,7 +105,6 @@ Due to the ^ symbol use instead the \A symbol, the following submission would pa
 
     */
 ```
->>>>>>> 2910d0b35380405a483e2fd4eb9636ac62a937e1
  
 ###### How to fix?
 
@@ -146,11 +125,7 @@ High
 ###### Description
 
 By default, Rails 3.0 and up protects against cross-site scripting (XSS) through the output encoding of data placed into views. However, there are several ways in Ruby on Rails for developers to bypass the default XSS protections. These are the dangerous template tags which bypass default output encoding:
-<<<<<<< HEAD
-
-=======
 ```ruby
->>>>>>> 2910d0b35380405a483e2fd4eb9636ac62a937e1
     <%= raw @product.name %>
 
     <%= @product.name.html_safe %>
@@ -160,17 +135,10 @@ By default, Rails 3.0 and up protects against cross-site scripting (XSS) through
     <%= link_to “Personal Website”, @user.website %>
 
         Here, the @user.website value could begin with javascript: tag, executing any JavaScript payload that follows it.
-<<<<<<< HEAD
-
-###### Why We Care
-
-XSS can be used to perform any action the authenticated user has access, including other Unity services if authentication is handled through Genesis.
-=======
 ```
 ###### Why We Care
 
 XSS can be used to perform any action the authenticated user has access, including other services if authentication is handled through the same auth provider.
->>>>>>> 2910d0b35380405a483e2fd4eb9636ac62a937e1
 ###### How to fix?
 
 These methods of printing raw HTML to the page should only be used for trusting, non-user generated content that doesn’t include user input. If users are able to influence the data used with these bypasses, it becomes vulnerable to XSS.
@@ -194,32 +162,19 @@ To prevent this, Strong Parameters should be used globally to enforce whitelisti
 An alternative for older versions of Rails is to blacklist specific model attributes using the attr_protected method or whitelist specific model attributes using the attr_accessible method when defining your models. If you are working in Rails < 3.2.3 you must enable attribute whitelisting with the following:
 
  
-<<<<<<< HEAD
-
-    config.active_record.whitelist_attributes = true
-=======
 ```ruby
 config.active_record.whitelist_attributes = true
 ```
->>>>>>> 2910d0b35380405a483e2fd4eb9636ac62a937e1
 
 
 Whitelist example that allows access by role:
 
     
-<<<<<<< HEAD
-
-    attr_accessible :name
-
-    attr_accessible :name, :is_admin, :as => :admin
-
-=======
 ```ruby
     attr_accessible :name
 
     attr_accessible :name, :is_admin, :as => :admin
 ```
->>>>>>> 2910d0b35380405a483e2fd4eb9636ac62a937e1
  
 ###### Why We Care
 
@@ -229,20 +184,12 @@ Interactions with datastores are typically one of the most sensitive areas in a
 The following function mass assigns user input when creating a new user.
 
  
-<<<<<<< HEAD
-
-=======
 ```ruby 
->>>>>>> 2910d0b35380405a483e2fd4eb9636ac62a937e1
     def signup
         params[:user]
         @user = User.new(params[:user])
     end
-<<<<<<< HEAD
-
-=======
 ```
->>>>>>> 2910d0b35380405a483e2fd4eb9636ac62a937e1
  
 
 
@@ -281,15 +228,10 @@ Strong encryption of traffic between the user and the web server plays a key par
 In Rails 3.1 and later, this can be accomplished by always forcing SSL connections in your application config file:
 
  
-<<<<<<< HEAD
-
-    config.force_ssl = true
-=======
 ```ruby
     config.force_ssl = true
 ```
 
->>>>>>> 2910d0b35380405a483e2fd4eb9636ac62a937e1
 ###### Risk Rating
 
 Medium
@@ -307,15 +249,9 @@ Logging of sensitive, user information puts that data at higher risk of compromi
 When designing a Rail application, make sure to designate request parameters that should not be logged. These should be appended to the list of filtered parameters in the Rails configuration:
 
  
-<<<<<<< HEAD
-
-    config.filter_parameters << :cc_number
-
-=======
 ```ruby
     config.filter_parameters << :cc_number
 ```
->>>>>>> 2910d0b35380405a483e2fd4eb9636ac62a937e1
  
 ###### Risk Rating
 
@@ -376,11 +312,7 @@ Avoiding using user input to choose which view to render when certain views are
 Low
  
  ---
-<<<<<<< HEAD
-####Session Fixation
-=======
 #### Session Fixation
->>>>>>> 2910d0b35380405a483e2fd4eb9636ac62a937e1
 ###### Description
 
 Session fixation is the term for when a pre-authentication session token used as the post-authentication session token. In other words, the a new session token is not set after authenticating. This is not an issue if header-based authentication is in use.
diff --git a/Overview.md b/Overview.md
index e0bc463..863ef99 100644
--- a/Overview.md
+++ b/Overview.md
@@ -6,25 +6,15 @@
 ### Secure Software Development Lifecycle (SSDLC)
 ![Software Development Lifecycle Diagram](images/ssdlc%20process%20graphic.png "SSDLC Diagram")
 
-<<<<<<< HEAD
-| Requirments Phase Offerings | Design Phase Offerings | Develop Phase Offerings | Test Phase Offerings| Deploy Phase Offerings |
-=======
 | Requirements Phase Offerings | Design Phase Offerings | Develop Phase Offerings | Test Phase Offerings| Deploy Phase Offerings |
->>>>>>> 2910d0b35380405a483e2fd4eb9636ac62a937e1
 | :--- | :--- | :--- | :--- | :--- |
 | Security Requirements | Design Review & Threat Models |  - Static Analysis Tools<br> - Secure Coding | - Ask in Slack <br>- Security Testing | - Pentest in Product<br>- Incident Response Support |
 
 ### Unity SSDLC Overview
 
-<<<<<<< HEAD
-The goal of Unity's SSDLC provide product teams and developers best practices on how to leverage software security practices into their existing development process. The phases in the graphic above may not be formally implemented or recognized by your team, but they do generally represent how all software is developed, implicitly or explicitly. Following this model, you are able to best determine what services the Unity Security team provides based on what phase of of the development life-cycle you are currently in with your product.
-
-The SSDLC will continue to evolve, and include services from the broader Security teams; we'll soon be adding links to docukments from our Program Management team, Infrastructure Security, SOC, Incident Response, and Application Security.
-=======
 The goal of Unity's SSDLC is to provide product teams and developers best practices on how to leverage software security practices into their existing development process. The phases in the graphic above may not be formally implemented or recognized by your team, but they do generally represent how all software is developed, implicitly or explicitly. Following this model, you are able to best determine what services the Unity Security team provides based on what phase of of the development life-cycle you are currently in with your product.
 
 The SSDLC will continue to evolve, and include services from the broader Security teams; we'll soon be adding links to documents from our Program Management team, Infrastructure Security, SOC, Incident Response, and Application Security.
->>>>>>> 2910d0b35380405a483e2fd4eb9636ac62a937e1
 
 All feedback is welcome - feel free to update/comment the docs directly or chat with the team on Slack or email.
 
@@ -34,20 +24,6 @@ Our SSDLC is currently organized under the following topics:
 - [Security Process](./Security%20Process)
 - [Tools & Automation](./Tools%20and%20Automation)
 
-<<<<<<< HEAD
-Also, be sure to keep an eye out for on-site trainings, which will be announced (and archived) here -> [Developer Security Trainings](./Trainings/reaedme.md)
-
-## Shortcut List of Articles 
-#### _Coding Practice_
-- [API Best Practices](./Coding%Practice/API-Best-Practices.md)
-- [Authorization & Authentication Guidelines](./Coding%Practice/AuthZ-AuthN-Guidelines.md)
-- [Cryptographic Guidelines](./Coding%Practice/Cryptographic-Guidelines.md)
-- [HTTP Header Security](./Coding%Practice/HTTP-Header-Security.md)
-- [Preventing Common Web Attacks](./Coding%Practice/Preventing-Common-Web-Attacks.md)
-- [Secrets Management](./Coding%Practice/Secrets-Management.md)
-- [Secure Design Principles](./Coding%Practice/Secure-Design-Principles.md)
-- [Electron Best Practices](./Code%Practice/Electron-Best-Practices.md)
-=======
 Also, be sure to keep an eye out for on-site trainings, which will be announced (and archived) here -> [Developer Security Trainings](./Trainings/readme.md)
 
 ## Shortcut List of Articles 
@@ -60,7 +36,6 @@ Also, be sure to keep an eye out for on-site trainings, which will be announced
 - [Secrets Management](./Coding%20Practice/Secrets-Management.md)
 - [Secure Design Principles](./Coding%20Practice/Secure-Design-Principles.md)
 - [Electron Best Practices](./Code%20Practice/Electron-Best-Practices.md)
->>>>>>> 2910d0b35380405a483e2fd4eb9636ac62a937e1
 
 #### _Language Best Practices_
 - [Golang](./Language%20Best%20Practices/Golang-Best-Practices.md)
diff --git a/README.md b/README.md
index 735a256..8c5ff47 100644
--- a/README.md
+++ b/README.md
@@ -1,14 +1,4 @@
 # unity-ssdlc
-<<<<<<< HEAD
-<img src="./images/madewith-unity-black.png" style="width:300px" alt="MWU"></img>
-## Intro and Overview
-This is a public version of Unity's internal Secure Software Development Lifecycle (SSDLC). Meant to provide a reusable reference framework, not just to share with others, but also to take contributions to improve and evolve.
-
-The Unity Security Team has worked hard to improve the trustworthiness of Unity's products and services. As part of that, we developed our own internal SSDLC to help our internal developers design and develop more secure products. After a few iterations, we found that we had an interesting collection of articles and trainings that may be useful, for not just Unity's developers, but potentially other companies as well. So we decided to share what we have, hopefully contributing something useful back to the broader software security community.
-
-We know this isn't perfect - there's rough edges, with some typos and embarassing grammar, and it's certainly not close to being exhaustive. But, there's definitely useful information here. Not only the actual content, but also to share with other companies what an actual, in use, SSDLC might look like.
-With this in mind, please be kind in your contructive criticism, and let us know if you've found this useful!
-=======
 <img src="./images/madewith-unity-black.png" style="width:300px" alt="MWU">
 
 ## Intro and Overview
@@ -18,7 +8,6 @@ The Unity Security Team has worked hard to improve the trustworthiness of Unity'
 
 We know this isn't perfect - there's rough edges, with some typos and embarrassing grammar, and it's certainly not close to being exhaustive. But, there's definitely useful information here. Not only the actual content, but also the sharing with other companies what an actual, in use, SSDLC might look like.
 With this in mind, please be kind in your constructive criticism, and let us know if you've found this useful!
->>>>>>> 2910d0b35380405a483e2fd4eb9636ac62a937e1
 
 ---
 ## How To Use
@@ -26,38 +15,22 @@ _SSDLC starts at [Overview](./Overview.md)_
 
 Feel free to clone the whole repo and use in your organization!
 We'd appreciate your feedback as well :)
-<<<<<<< HEAD
-  
-## Unity SSDLC Structure
-Our SSDLC is currently a suite of offerings by the Unity Application Security team. Part documentation, part training (in person and online) and a fun CTF server we host.
-#### SSDLC  Documentation
-The SSDLC is an ever evolving set of documents that our team has drafted as an attempt to capture industry best practices in a single location for our developers. The recommendations aren't perfect, and are always in draft. There are gaps, both in the technology we cover and how deep we are in each topic, however, we felt it better to share with our developers (and you!) as much as we could. Tt does no good for us to hoard a complete library of knowledge because we're missing _just one more article_ :)
-=======
 
 ## Unity SSDLC Structure
 Our SSDLC is currently a suite of offerings by the Unity Application Security team. Part documentation, part training (in person and online) and a fun CTF (Capture The Flag) server we host.
 #### SSDLC  Documentation
 The SSDLC is an ever-evolving set of documents that our team has drafted as an attempt to capture industry best practices in a single location for our developers. The recommendations aren't perfect, and are always in draft. There are gaps, both in the technology we cover and how deep we are in each topic, however, we felt it better to share with our developers (and you!) as much as we could. It does no good for us to hoard a complete library of knowledge because we're missing _just one more article_ :)
->>>>>>> 2910d0b35380405a483e2fd4eb9636ac62a937e1
 
 This SSDLC is intended to be a practical reference for developers to help them design and develop more secure products spread over 3 main topics: [Coding Practice](./Coding%Practice), [Language Best Practices](./Language%Best%Practices), and [Security Process](./Security%20Process). Further, we'll be sharing our [Tools and Automation](./) and [Trainings](./) in the future.
 #### Trainings
 _NOTE: The Trainings are still TBD - We'll get them in here as soon as we can!_
 As a further supplement to our SSDLC, the Unity Security team has developed several presentations to provide more entertaining security content. The training was built with the intent to deliver the sessions in-person, as part of mini internal security conferences. Ideally, we'd also record these presentations to share with folks who can't make it to the live sessions.
 
-<<<<<<< HEAD
-We can't share all our presentations here; we wanted to make these relevant and personal to the teams we present to, so many contain findings in our own products, with real-time demos of us exploiting the vulnerabilities we've discoved in our own code! In this way, developers can see the real risk of insecure code, potentially in the code they wrote themselves. We never shame or intentioanlly call out a team or specific developers - this is meant to be a learning experience, not a hurtful one.
-
-##### CTF(s)
-_NOTE: Our CTF is not quite ready for public release - We'll have this updated as soon as we can!_
-To go along with our mini-conferences, we also run a small CTF in paralell with presentations. This is meant to give our development teams the opportunity to have a hands-on experience with insecure applications, starting with very simple examples, working up to more advanced challenges. This is not meant to be a full fledged Defcon-style CTF - we just want to teach some security basic, and whet the hacking appetite of our teams.
-=======
 We can't share all our presentations here; we wanted to make these relevant and personal to the teams we present to, so many contain findings in our own products, with real-time demos of us exploiting the vulnerabilities we've discovered in our own code! In this way, developers can see the real risk of insecure code, potentially in the code they wrote themselves. We never shame or intentionally call out a team or specific developers - this is meant to be a learning experience, not a hurtful one.
 
 ##### CTF(s)
 _NOTE: Our CTF is not quite ready for public release - We'll have this updated as soon as we can!_
 To go along with our mini-conferences, we also run a small CTF (Capture The Flag) in parallel with presentations. This is meant to give our development teams the opportunity to have a hands-on experience with insecure applications, starting with very simple examples, working up to more advanced challenges. This is not meant to be a full fledged Defcon-style CTF - we just want to teach some security basics, and whet the hacking appetite of our teams.
->>>>>>> 2910d0b35380405a483e2fd4eb9636ac62a937e1
 
 ## Contributions
 To learn how to contribute, take a look at our [Contributing.md](./CONTRIBUTING.md). Let us know if you have any questions not called out in there.
@@ -66,17 +39,10 @@ To learn how to contribute, take a look at our [Contributing.md](./CONTRIBUTING.
 [`security@unity3d.com`](mailto:security@unity3d.com)
 
 ## License
-<<<<<<< HEAD
-License found in:[LICENSE.md](./LICENSE.md)
-
-Copyright © 2019 Unity Technologies
- 
-=======
 License found in: [LICENSE.md](./LICENSE.md)
 
 Copyright © 2019 Unity Technologies
 
->>>>>>> 2910d0b35380405a483e2fd4eb9636ac62a937e1
 ## Disclaimer
 
 THE INFORMATION PROVIDED HERE DOES NOT REPRESENT OR DESCRIBE ALL OF UNITY’S SSDLC PRACTICES, AND, AS SUCH, DOES NOT REPRESENT ALL PROCESSES EMPLOYED BY UNITY CONCERNING SOFTWARE SECURITY. THE INFORMATION PROVIDED IS AN EXAMPLE FRAMEWORK, BUT NO REPRESENTATIONS OR WARRANTIES ARE MADE OF IT AND NO GUARANTEES ARE PROVIDED CONCERNING ANY SPECIFIC RESULTS. INFORMATION IS PROVIDED “AS-IS” AND “AS AVAILABLE”.  ANY USE OF THE INFORMATION PROVIDED IS AT YOUR OWN RISK AND LIABILITY. FURTHER, UNITY MAY CHANGE ANY INFORMATION PROVIDED HERE AT ANY TIME WITHOUT NOTICE TO YOU.
diff --git a/Security Process/Risk-Rating.md b/Security Process/Risk-Rating.md
index a2a28bb..67b5e41 100644
--- a/Security Process/Risk-Rating.md	
+++ b/Security Process/Risk-Rating.md	
@@ -1,9 +1,5 @@
 # Risk Rating (aka., Security Bug Bar) [Security Process]
-<<<<<<< HEAD
-<font size="-1">_Carlo Valentin - Dec. 2018_</font>
-=======
 <font size="-1">_Author: Carlo Valentin - Dec. 2018_</font>
->>>>>>> 2910d0b35380405a483e2fd4eb9636ac62a937e1
 
 # Overview
 When vulnerabilities are identified by Application Security, the risk of the vulnerability needs to be effectively communicated to teams so that they can be fixed in a timely manner. As such, a standard set of definitions is needed for how Application Security classifies these vulnerabilities. These definitions ensure that development teams can quickly and easily understand the potential risk a vulnerability poses to their application or service. This gives a unified understanding of how to prioritize fixing known vulnerabilities.

From 2b0c5e65c2557accbf1bc50f229cfccbe6cadf33 Mon Sep 17 00:00:00 2001
From: MiTschMR <47354974+MiTschMR@users.noreply.github.com>
Date: Thu, 5 Dec 2019 08:38:48 +0100
Subject: [PATCH 31/54] Fixed typo

Fixed typo with year for sentence "Problem: Hints that serialization vulnerabilities in the .Net framework have existed since 2012 (MS12-035 via James Forshaw), later revelations found major vulnerabilities within serialization, beyond what was published in that article."
---
 Language Best Practices/Net-C#-Best-Practices.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Language Best Practices/Net-C#-Best-Practices.md b/Language Best Practices/Net-C#-Best-Practices.md
index 921088d..b527392 100644
--- a/Language Best Practices/Net-C#-Best-Practices.md	
+++ b/Language Best Practices/Net-C#-Best-Practices.md	
@@ -20,7 +20,7 @@ The following best practices are in regards to loading code or resources from an
 
   - Solution: Only load code and resources that have been signed by a trusted party.
 - Do not use .NET Remoting or binary formatters (for object serialization/deserialization)
-  - Problem: Hints that serialization vulnerabilities in the .Net framework have existed since 20120 (MS12-035 via James Forshaw), later revelations found major vulnerabilities within serialization, beyond what was published in that article.
+  - Problem: Hints that serialization vulnerabilities in the .Net framework have existed since 2012 (MS12-035 via James Forshaw), later revelations found major vulnerabilities within serialization, beyond what was published in that article.
   - Solution: Use DataContractSerialiazer as part of serializing objects.
 - Do not use Distributed Component Object Model (DCOM).
   - Problem: Again, thanks to James Forshaw, it was determined that DCOM was generally unsafe, and has issues with safe (or unsafe?) object serialization.

From e6ec3c2619e714d90a43275cfd826c7aa22ce0ce Mon Sep 17 00:00:00 2001
From: Brandon Caldwell <brandonc@unity3d.com>
Date: Wed, 8 Jan 2020 08:44:23 -0800
Subject: [PATCH 32/54] Fixing link to the .Net best practices article.

---
 .../{Net-C#-Best-Practices.md => Net-CSharp-Best-Practices.md}  | 0
 Overview.md                                                     | 2 +-
 2 files changed, 1 insertion(+), 1 deletion(-)
 rename Language Best Practices/{Net-C#-Best-Practices.md => Net-CSharp-Best-Practices.md} (100%)

diff --git a/Language Best Practices/Net-C#-Best-Practices.md b/Language Best Practices/Net-CSharp-Best-Practices.md
similarity index 100%
rename from Language Best Practices/Net-C#-Best-Practices.md
rename to Language Best Practices/Net-CSharp-Best-Practices.md
diff --git a/Overview.md b/Overview.md
index 863ef99..c4d783d 100644
--- a/Overview.md
+++ b/Overview.md
@@ -41,7 +41,7 @@ Also, be sure to keep an eye out for on-site trainings, which will be announced
 - [Golang](./Language%20Best%20Practices/Golang-Best-Practices.md)
 - [Node.js](./Language%20Best%20Practices/Nodejs-Best-Practices.md)
 - [Ruby](./Language%20Best%20Practices/Ruby-Best-Practices.md)
-- [C#](./Language%20Best%20Practices/Net-C#-Best-Practices.md)
+- [C#](./Language%20Best%20Practices/Net-CSharp-Best-Practices.md)
 
 #### _Security Process_
 - [Design Review](./Security%20Process/Design-Review.md)

From 0ab4829966d7a20e2ad1583f7f0f8c1bcec95610 Mon Sep 17 00:00:00 2001
From: emil <emilva@gmail.com>
Date: Thu, 30 Jan 2020 14:33:30 +0100
Subject: [PATCH 33/54] Fix broken links

---
 README.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/README.md b/README.md
index 8c5ff47..df10251 100644
--- a/README.md
+++ b/README.md
@@ -21,7 +21,7 @@ Our SSDLC is currently a suite of offerings by the Unity Application Security te
 #### SSDLC  Documentation
 The SSDLC is an ever-evolving set of documents that our team has drafted as an attempt to capture industry best practices in a single location for our developers. The recommendations aren't perfect, and are always in draft. There are gaps, both in the technology we cover and how deep we are in each topic, however, we felt it better to share with our developers (and you!) as much as we could. It does no good for us to hoard a complete library of knowledge because we're missing _just one more article_ :)
 
-This SSDLC is intended to be a practical reference for developers to help them design and develop more secure products spread over 3 main topics: [Coding Practice](./Coding%Practice), [Language Best Practices](./Language%Best%Practices), and [Security Process](./Security%20Process). Further, we'll be sharing our [Tools and Automation](./) and [Trainings](./) in the future.
+This SSDLC is intended to be a practical reference for developers to help them design and develop more secure products spread over 3 main topics: [Coding Practice](./Coding%20Practice), [Language Best Practices](./Language%20Best%20Practices), and [Security Process](./Security%20Process). Further, we'll be sharing our [Tools and Automation](./) and [Trainings](./) in the future.
 #### Trainings
 _NOTE: The Trainings are still TBD - We'll get them in here as soon as we can!_
 As a further supplement to our SSDLC, the Unity Security team has developed several presentations to provide more entertaining security content. The training was built with the intent to deliver the sessions in-person, as part of mini internal security conferences. Ideally, we'd also record these presentations to share with folks who can't make it to the live sessions.

From 0dc2e428c3aeca3494a4f7a0eb103567e9af1dc8 Mon Sep 17 00:00:00 2001
From: Jose Perez <josep@unity3d.com>
Date: Tue, 17 Mar 2020 14:52:06 +0200
Subject: [PATCH 34/54] TLS NIST.SP.800-52r2 update

---
 Coding Practice/Cryptographic-Guidelines.md | 34 +++++++++++++--------
 1 file changed, 21 insertions(+), 13 deletions(-)

diff --git a/Coding Practice/Cryptographic-Guidelines.md b/Coding Practice/Cryptographic-Guidelines.md
index e18f498..a4f2ecf 100644
--- a/Coding Practice/Cryptographic-Guidelines.md	
+++ b/Coding Practice/Cryptographic-Guidelines.md	
@@ -1,5 +1,5 @@
 # Cryptographic Guidelines [Coding Practice]
-<font size="-1">*Brandon Caldwell Jan 2019*</font>
+<font size="-1">Authors: *Brandon Caldwell Jan 2019, Jose Perez - Mar. 2020*</font>
 
 ## Guidelines Overview
 
@@ -14,20 +14,27 @@ Cryptographic requirements at Unity are heavily influenced by NIST's *Cryptograp
 ##### TLS - Cipher Suites
 
 _Minimum TLS version = TLS1.2._
-All cipher suites below should be compatible with version >= TLS 1.2.  
-SSL 3.0 and below are not allowed.
+
+All cipher suites below should be compatible with version >= TLS 1.2 . SSL 3.0 and below are not allowed. 
+
 Accepted TLS Cipher suites:
-- TLS_RSA_WITH_AES_128_CBC_SHA
-- TLS_RSA_WITH_AES_256_CBC_SHA
-- TLS_RSA_WITH_AES_128_GCM_SHA256
-- TLS_RSA_WITH_AES_256_GCM_SHA384
-- TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
+
 - TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
 - TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
-- TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
+- TLS_ECDHE_ECDSA_WITH_AES_128_CCM
+- TLS_ECDHE_ECDSA_WITH_AES_256_CCM
+- TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8
+- TLS_ECDHE_ECDSA_WITH_AES_256_CCM_8
+- TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
+- TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
 - TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
-- TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
-- TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
+- TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
+- TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
+- TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
+- TLS_AES_128_GCM_SHA256
+- TLS_AES_256_GCM_SHA384
+- TLS_AES_128_CCM_SHA256
+- TLS_AES_128_CCM_8_SHA256
 
 ##### Hash Algorithms
 
@@ -52,9 +59,10 @@ Accepted TLS Cipher suites:
 - **Win32/64**: RtlGenRandom (new implementations should use BCryptGenRandom or CryptGenRandom) * and_s * SystemPrng (for kernel mode)
 - **.NET** RNGCryptoServiceProvider or RNGCng
 - **Windows Store Apps**: Windows.Security.Cryptography.CryptographicBuffer.GenerateRandom or GenerateRandomNumber
-- **Apple OS X** _(10.7+)/iOS(2.0+)_: int SecRandomCopyBytes (SecRandomRef random, size_t count, int8_t *bytes )
+- **Apple OS X** _(10.7+)/iOS(2.0+)_: int SecRandomCopyBytes (SecRandomRef random, size_t count, int8_t *bytes)
 - **Apple OS X** _(<10.7)_: Use /dev/random to retrieve random numbers
 - **Java** _(including Google Android Java code)_- java.security.SecureRandom class. Note that for Android 4.3 (Jelly Bean), developers must follow the Android recommended workaround and pdate their applications to explicitly initialize the PRNG with entropy from /dev/urandom or dev/random
 
 ### References
-- https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-52r1.pdf
\ No newline at end of file
+- https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-52r1.pdf
+- https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-52r2.pdf 
\ No newline at end of file

From d7a6eb3b2403f39fb0bffe7a5880d05fc756512d Mon Sep 17 00:00:00 2001
From: Jose Perez <josep@unity3d.com>
Date: Tue, 17 Mar 2020 15:03:55 +0200
Subject: [PATCH 35/54] Adding Contributors

---
 Coding Practice/Cryptographic-Guidelines.md | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/Coding Practice/Cryptographic-Guidelines.md b/Coding Practice/Cryptographic-Guidelines.md
index a4f2ecf..27af60a 100644
--- a/Coding Practice/Cryptographic-Guidelines.md	
+++ b/Coding Practice/Cryptographic-Guidelines.md	
@@ -1,5 +1,5 @@
 # Cryptographic Guidelines [Coding Practice]
-<font size="-1">Authors: *Brandon Caldwell Jan 2019, Jose Perez - Mar. 2020*</font>
+<font size="-1">*Brandon Caldwell Jan 2019*</font>
 
 ## Guidelines Overview
 
@@ -65,4 +65,8 @@ Accepted TLS Cipher suites:
 
 ### References
 - https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-52r1.pdf
-- https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-52r2.pdf 
\ No newline at end of file
+- https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-52r2.pdf
+
+### Contributors
+
+Jose Perez - Mar. 2020
\ No newline at end of file

From fe7c7ef7f708cb391d5aa9717ae1c99fce0c1abf Mon Sep 17 00:00:00 2001
From: Jose Perez <josep@unity3d.com>
Date: Tue, 17 Mar 2020 15:57:58 +0200
Subject: [PATCH 36/54] Removed CBC cipher suites

---
 Coding Practice/Cryptographic-Guidelines.md | 4 ----
 1 file changed, 4 deletions(-)

diff --git a/Coding Practice/Cryptographic-Guidelines.md b/Coding Practice/Cryptographic-Guidelines.md
index 27af60a..007cc9c 100644
--- a/Coding Practice/Cryptographic-Guidelines.md	
+++ b/Coding Practice/Cryptographic-Guidelines.md	
@@ -25,12 +25,8 @@ Accepted TLS Cipher suites:
 - TLS_ECDHE_ECDSA_WITH_AES_256_CCM
 - TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8
 - TLS_ECDHE_ECDSA_WITH_AES_256_CCM_8
-- TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
-- TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
 - TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
 - TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
-- TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
-- TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
 - TLS_AES_128_GCM_SHA256
 - TLS_AES_256_GCM_SHA384
 - TLS_AES_128_CCM_SHA256

From b3bca0dc5a1b7c8f1310a9953fb3500f290f54f8 Mon Sep 17 00:00:00 2001
From: Jose Perez <josep@unity3d.com>
Date: Tue, 17 Mar 2020 15:58:50 +0200
Subject: [PATCH 37/54] Removed CCM_8 cipher suites

---
 Coding Practice/Cryptographic-Guidelines.md | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/Coding Practice/Cryptographic-Guidelines.md b/Coding Practice/Cryptographic-Guidelines.md
index 007cc9c..7bc4113 100644
--- a/Coding Practice/Cryptographic-Guidelines.md	
+++ b/Coding Practice/Cryptographic-Guidelines.md	
@@ -23,14 +23,11 @@ Accepted TLS Cipher suites:
 - TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
 - TLS_ECDHE_ECDSA_WITH_AES_128_CCM
 - TLS_ECDHE_ECDSA_WITH_AES_256_CCM
-- TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8
-- TLS_ECDHE_ECDSA_WITH_AES_256_CCM_8
 - TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
 - TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
 - TLS_AES_128_GCM_SHA256
 - TLS_AES_256_GCM_SHA384
 - TLS_AES_128_CCM_SHA256
-- TLS_AES_128_CCM_8_SHA256
 
 ##### Hash Algorithms
 

From 2f0777829ff3dd495a5ff63b290df33b96e45271 Mon Sep 17 00:00:00 2001
From: adiov <adi.shammout@outlook.com>
Date: Wed, 18 Mar 2020 18:50:12 +0200
Subject: [PATCH 38/54] Add Vault Secret Fetcher as submodule

---
 .gitmodules                               | 3 +++
 Tools and Automation/README.md            | 5 +++++
 Tools and Automation/readme.md            | 1 -
 Tools and Automation/vault-secret-fetcher | 1 +
 4 files changed, 9 insertions(+), 1 deletion(-)
 create mode 100644 .gitmodules
 create mode 100644 Tools and Automation/README.md
 delete mode 100644 Tools and Automation/readme.md
 create mode 160000 Tools and Automation/vault-secret-fetcher

diff --git a/.gitmodules b/.gitmodules
new file mode 100644
index 0000000..60eda43
--- /dev/null
+++ b/.gitmodules
@@ -0,0 +1,3 @@
+[submodule "Tools and Automation/vault-secret-fetcher"]
+	path = Tools and Automation/vault-secret-fetcher
+	url = https://github.com/Unity-Technologies/vault-secret-fetcher
diff --git a/Tools and Automation/README.md b/Tools and Automation/README.md
new file mode 100644
index 0000000..4e1869e
--- /dev/null
+++ b/Tools and Automation/README.md	
@@ -0,0 +1,5 @@
+# Tools and Automation
+
+## Vault Secret Fetcher
+
+A utility for automatically fetching secrets from Vault in IE infra. Written in Go and compiled statically to ensure no external dependencies are needed, especially in scratch and distroless images. This tool's target audience are teams looking to have maximum compatibility with minimal developer effort in a large infrastructure already deployed in Kubernetes.
\ No newline at end of file
diff --git a/Tools and Automation/readme.md b/Tools and Automation/readme.md
deleted file mode 100644
index b005f9f..0000000
--- a/Tools and Automation/readme.md	
+++ /dev/null
@@ -1 +0,0 @@
-Soon™
\ No newline at end of file
diff --git a/Tools and Automation/vault-secret-fetcher b/Tools and Automation/vault-secret-fetcher
new file mode 160000
index 0000000..9fb5890
--- /dev/null
+++ b/Tools and Automation/vault-secret-fetcher	
@@ -0,0 +1 @@
+Subproject commit 9fb5890ab9bf0c7dae22f2119273c1352b06f9c8

From 459c6687b6d15babbe4f9028bc3458284403bf32 Mon Sep 17 00:00:00 2001
From: Simo Punnonen <simop@unity3d.com>
Date: Mon, 16 Nov 2020 13:59:35 +0200
Subject: [PATCH 39/54] fix broken link for Tools & Automation readme

---
 Overview.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Overview.md b/Overview.md
index c4d783d..ac30cce 100644
--- a/Overview.md
+++ b/Overview.md
@@ -26,7 +26,7 @@ Our SSDLC is currently organized under the following topics:
 
 Also, be sure to keep an eye out for on-site trainings, which will be announced (and archived) here -> [Developer Security Trainings](./Trainings/readme.md)
 
-## Shortcut List of Articles 
+## Shortcut List of Articles
 #### _Coding Practice_
 - [API Best Practices](./Coding%20Practice/API-Best-Practices.md)
 - [Authorization & Authentication Guidelines](./Coding%20Practice/AuthZ-AuthN-Guidelines.md)
@@ -51,4 +51,4 @@ Also, be sure to keep an eye out for on-site trainings, which will be announced
 - [Bug Bar](./Security%20Process/Bug-Bar.md)
 
 #### _Tools & Automation_
-- [Tools & Automation](./Tools%20and%20Automation/readme.md)
+- [Tools & Automation](./Tools%20and%20Automation/README.md)

From a3a5b28a8ae8574c89e6b099969a906869db8b40 Mon Sep 17 00:00:00 2001
From: AJ Bahnken <aj@ajvb.me>
Date: Tue, 12 Jan 2021 14:29:34 -0800
Subject: [PATCH 40/54] Swap 'ruby' with 'golang' in golang doc

---
 Language Best Practices/Golang-Best-Practices.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Language Best Practices/Golang-Best-Practices.md b/Language Best Practices/Golang-Best-Practices.md
index 9a982df..cb78e0b 100644
--- a/Language Best Practices/Golang-Best-Practices.md	
+++ b/Language Best Practices/Golang-Best-Practices.md	
@@ -4,7 +4,7 @@
 ## Overview
 
 
-This is a set of security guidelines for the Golang programming language. Each element in this document will be Ruby-specific. General web application and API guidelines will be covered here. This guideline is intended to be a living security reference for development teams and quality assurance as part of the Application Security Team’s Secure Software Development Lifecycle (SSDLC). As such, it will be continually added to and updated as the Application Security team is made aware of new security considerations or gaps in the current guidelines.
+This is a set of security guidelines for the Golang programming language. Each element in this document will be Golang-specific. General web application and API guidelines will be covered here. This guideline is intended to be a living security reference for development teams and quality assurance as part of the Application Security Team’s Secure Software Development Lifecycle (SSDLC). As such, it will be continually added to and updated as the Application Security team is made aware of new security considerations or gaps in the current guidelines.
 
 Golang is a strongly typed language that has taken steps to prevent security issues found in other languages. For example, there is no pointer arithmetic. Garbage collection is automatic. Another example, the standard crypto package for AES does not provide Cipher Block Chaining (CBC) as an option.
 

From 7610ed14bf753e54b209e354fc1f46af2900d336 Mon Sep 17 00:00:00 2001
From: Brandon Caldwell <brandonc@unity3d.com>
Date: Mon, 15 Mar 2021 10:11:04 -0500
Subject: [PATCH 41/54] Update README.md

Just updating copyright year.
---
 README.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/README.md b/README.md
index df10251..52d2b6e 100644
--- a/README.md
+++ b/README.md
@@ -41,7 +41,7 @@ To learn how to contribute, take a look at our [Contributing.md](./CONTRIBUTING.
 ## License
 License found in: [LICENSE.md](./LICENSE.md)
 
-Copyright © 2019 Unity Technologies
+Copyright © 2021 Unity Technologies
 
 ## Disclaimer
 

From f28a6c940d9390267fc9654e4897a9efbaec997b Mon Sep 17 00:00:00 2001
From: Brandon Caldwell <brandonc@unity3d.com>
Date: Tue, 27 Jul 2021 09:29:24 -0700
Subject: [PATCH 42/54] Fix bug-bar link in Risk-Rating.md

Link was stale, updated accordingly (from `./Unity-Bug-Bar.md` to `./Bug-Bar.md`).
---
 Security Process/Risk-Rating.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Security Process/Risk-Rating.md b/Security Process/Risk-Rating.md
index 67b5e41..3a0322b 100644
--- a/Security Process/Risk-Rating.md	
+++ b/Security Process/Risk-Rating.md	
@@ -44,7 +44,7 @@ The rating definitions are as follows:
 
 - Low - A vulnerability that has minor impact or can only be exploited in a chain of other vulnerabilities.
 
-For more information on determining the Risk Rating/Severity here at Unity, please see our [Unity Security Bug Bar](./Unity-Bug-Bar.md).
+For more information on determining the Risk Rating/Severity here at Unity, please see our [Unity Security Bug Bar](./Bug-Bar.md).
 
 ### Impact
 Impact classifies the reach and effect that occurs when the vulnerability is successfully exploited. This rating should take into account the loss of confidentiality, integrity, and availability of the targeted system. Reputational damage also plays a factor when rating impact.
@@ -66,4 +66,4 @@ Likelihood ratings are classified as follows:
 
 - Medium - Attackers require non-public information to exploit, or need to perform social engineering to acquire information in order to exploit. The attack may require privileged access or is performing a blind attack without feedback.
 
-- Low - Attackers require difficult to guess internal information or require a significant amount of social engineering to exploit the vulnerability.
\ No newline at end of file
+- Low - Attackers require difficult to guess internal information or require a significant amount of social engineering to exploit the vulnerability.

From 9a70e49c663cb97ad33465d9d9cb0eed80fc9533 Mon Sep 17 00:00:00 2001
From: Andrew Luke <andrewl@unity3d.com>
Date: Wed, 1 Dec 2021 14:24:40 -0800
Subject: [PATCH 43/54] Reorganized and added more guidance

---
 Coding Practice/Cryptographic-Guidelines.md | 158 ++++++++++++++++----
 1 file changed, 126 insertions(+), 32 deletions(-)

diff --git a/Coding Practice/Cryptographic-Guidelines.md b/Coding Practice/Cryptographic-Guidelines.md
index 7bc4113..7d174d6 100644
--- a/Coding Practice/Cryptographic-Guidelines.md	
+++ b/Coding Practice/Cryptographic-Guidelines.md	
@@ -1,35 +1,18 @@
 # Cryptographic Guidelines [Coding Practice]
-<font size="-1">*Brandon Caldwell Jan 2019*</font>
-
-## Guidelines Overview
-
-Cryptographic requirements at Unity are heavily influenced by NIST's *Cryptographic Standards and Guidelines (CSRC)* documentation. Below are our condensed recommendations.
-### Recommended Libraries
-- [libsodium](https://libsodium.org) - _([Github](https://github.com/jedisct1/libsodium))_
-- [OpenSSL](https://www.openssl.org/) - _([Github](https://github.com/openssl/openssl))_
 
-> NOTE: Where possible, we recommend Elliptic Curve Cryptography (ECC / ECDH), with Curve25519 (for signatures and key exchange)
+<font size="-1">*Brandon Caldwell Jan 2019*</font>
 
-### Usage Recommendations
-##### TLS - Cipher Suites
+## Overview
 
-_Minimum TLS version = TLS1.2._
+This document provides guidelines for how utilize encryption to protect data in transit and at rest. Cryptographic requirements at [COMPANY_NAME] are heavily influenced by NIST's Cryptographic Standards and Guidelines (CSRC) documentation.
 
-All cipher suites below should be compatible with version >= TLS 1.2 . SSL 3.0 and below are not allowed. 
+## Recommendations
 
-Accepted TLS Cipher suites:
+### Store the Cryptographic Hash of a Password
 
-- TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
-- TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
-- TLS_ECDHE_ECDSA_WITH_AES_128_CCM
-- TLS_ECDHE_ECDSA_WITH_AES_256_CCM
-- TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
-- TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
-- TLS_AES_128_GCM_SHA256
-- TLS_AES_256_GCM_SHA384
-- TLS_AES_128_CCM_SHA256
+User passwords should be stored as cryptographic hashes. Cleartext or encrypted password storage are not permitted. For more information on the reasons behind this, check out [this article](https://auth0.com/blog/hashing-passwords-one-way-road-to-security/) by Auth0. Most services at Unity should never have to worry about storing a password as for 99% of the cases this is what Genesis, Okta, and GCP OAuth are for. In the rare case a password storage mechanism is needed, **use an algorithm like BCrypt, PBKDF2, or Argon2**; these should be used with a decent work-factor. Hashed passwords should be salted with at least a 32-bit random salt. Remember that hashing algorithms are intentionally slow by design. The slower they are, the longer they take to crack.
 
-##### Hash Algorithms
+##### Hash Algorithms for other user cases:
 
 - Language Agnostic
   - SHA-512
@@ -46,20 +29,131 @@ Accepted TLS Cipher suites:
   - SHA256CryptoServiceProvider (FIPS compliant)
   - SHA384CryptoServiceProvider (FIPS compliant)
 
-###### Random Number Generators (RNG)
-- **CNG**: BCryptGenRandom(use of the BCRYPT_USE_SYSTEM_PREFERRED_RNG flag recommended unless the aller might run at any IRQL greater than 0 [that is, PASSIVE_LEVEL])
+### Encrypt Sensitive Data At Rest
+
+#### Symmetric Encryption Standard
+
+Sensitive data should be encrypted when stored and then decrypted when accessed. Examples:
+
+- Credentials intended to be used by the backend on behalf of the user (e.g., webhook credentials, VCS API tokens) 
+- Personally Identifiable Information (PII)
+- Medical Records
+- Payment information
+
+Maintained, trustworthy implementations of industry approved cryptographic algorithms, ciphers, and modes should be used to accomplish this. Writing your own cryptography is strongly discouraged.
+
+**The Security Team recommends using AES-256 GCM as the algorithm and key-size for symmetric encryption**. Keep in mind that encryption standards are constantly changing, so it is important to keep your encryption and decryption functionality customizable and upgradable. If you are unsure if your data needs to be encrypted, consult with the Unity Governance and Compliance team or the Unity Legal team for help making that determination.
+
+#### Authentication
+
+Use a strong algorithm in AEAD (Authenticated Encryption with Associated Data) mode to encrypt sensitive data at rest. AEAD is a form of encryption that performs integrity checks on both the encrypted data and the contextual data associated with the cipher text. These checks protect encrypted data against chosen cipher text attacks. In order to prevent tampering of encrypted data, use AES-256 GCM (Galois/Counter Mode). GCM automatically performs authentication using the same key. If GCM is not used, use an HMAC (Hash-Based Message Authentication) to authenticate the AES encryption result.
+
+A symmetric encryption flow should look roughly like:
+
+AES -> HMAC -> Final Blob
+
+#### Initialization-Vectors (IV) and Nonces
+
+Most well known encryption libraries like Bouncy Castle and Conceal handle IV generation properly. If you need to manually generate an IV or nonce, make sure to use a Cryptographically Secure Pseudo-Random Number Generator (CSPRNG). Nonces should be at least 64 bits in length. The same IV or nonce should only be used once with a given symmetric key. See the "Secure Random Number Generation" recommendation below for a list of secure functions by language.
+
+### Encrypt Data In Transit
+
+#### Asymmetric Encryption Standard
+
+Encryption should be used for any network communication between client-to-service and service-to-service communications. 
+
+Maintained, trustworthy implementations of industry approved cryptographic algorithms, ciphers, and modes should be used to accomplish this. Writing your own cryptography is strongly discouraged.
+
+RSA-4096 should be used for asymmetric encryption and store the private keys in a secure location outside of your codebase. If it is found that RSA-4096 becomes too resource intensive, it is acceptable to lower this to RSA-2048; this should only be a problem in very high-load environments. 
+
+Enforce certificate verification in all HTTP clients. 
+
+#### Usage Guidance
+
+##### TLS - Cipher Suites
+
+*Minimum TLS version = TLS 1.2.*
+
+All cipher suites below should be compatible with version >= TLS 1.2. SSL is not allowed. TLS 1.0 and 1.1 are legacy protocols that lack modern security features like AEAD. Additionally, using TLS v1.0 violates PCI-DSS requirements. Modern browsers have deprecated TLS v1.0 and TLS v1.1 as of January 2020.
+
+When organizing your server's list of ciphers, prioritize AEAD (GCM) modes and PFS (Perfect Forward Secrecy) (ECDHE) cipher suites.  
+
+Accepted TLS Cipher suites:
+
+- TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
+- TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
+- TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
+- TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
+- TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
+- TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
+- TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
+- TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
+- TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
+- TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
+- TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
+- TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
+- TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
+- TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
+- TLS_DHE_RSA_WITH_AES_128_CBC_SHA
+- TLS_DHE_RSA_WITH_AES_256_CBC_SHA
+- TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
+- TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
+
+##### Recommended Libraries
+
+- [libsodium](https://libsodium.org) - _([Github](https://github.com/jedisct1/libsodium))_
+- [OpenSSL](https://www.openssl.org/) - _([Github](https://github.com/openssl/openssl))_
+
+##### Resources
+
+- https://github.com/ssllabs/research/wiki/SSL-and-TLS-Deployment-Best-Practices
+- [Qualys SSL/TLS Server Test](https://www.ssllabs.com/ssltest/)
+
+> NOTE: Where possible, we recommend Elliptic Curve Cryptography (ECC / ECDH), with Curve25519 (for signatures and key exchange)
+
+### Facilitate and Exercise Key Rotation
+
+All encryption keys have a lifetime. The longer they are actively used to encrypt data the higher the chance that the key will be leaked and data will be compromised. To protect against this, keys should be rotated at least every year and in highly sensitive environments like PCI it should occur every six months. 
+
+In order to support periodic and on-demand (e.g., security incident) key rotation, your application should support reconfiguration of your encryption or hashing implementation. It should also facilitate m
+
+When rotating keys it is often necessary for previous keys to stay around for a time to decrypt past data. A previous key should never be used to encrypt data once it is no longer the primary key. It should only be used to decrypt the data it was used to encrypt. When the data is ready to be stored again it should then be encrypted with the current key and stored.
+
+### Secure Random Number Generation
+
+
+
+#### Recommended Cryptographically Secure Pseudo-Random Number Generators (CSPRNG)
+
+- **C:** getrandom(2)
+- **CNG**: BCryptGenRandom(use of the BCRYPT*USE*SYSTEM*PREFERRED*RNG flag recommended unless the aller might run at any IRQL greater than 0 [that is, PASSIVE_LEVEL])
 - **CAPI**: cryptGenRandom
-- **Win32/64**: RtlGenRandom (new implementations should use BCryptGenRandom or CryptGenRandom) * and_s * SystemPrng (for kernel mode)
-- **.NET** RNGCryptoServiceProvider or RNGCng
+- **Win32/64**: RtlGenRandom (new implementations should use BCryptGenRandom or CryptGenRandom)  *and_s*  SystemPrng (for kernel mode)
+- **.NET:** RNGCryptoServiceProvider or RNGCng
+- **PHP 5:** openssl_random_pseudo_bytes()
+- **PHP 7:** random_bytes(), random_int()
+- **Python:** secrets()
+- **Ruby:** SecureRandom
+- **Go:** crypto.rand
+- **Rust:** rand::prng::chacha::ChaChaRng, CSPRNG libraries
+- **Browser Javascript:** [Crypto.getRandomValues](https://developer.mozilla.org/en-US/docs/Web/API/Crypto/getRandomValues)
 - **Windows Store Apps**: Windows.Security.Cryptography.CryptographicBuffer.GenerateRandom or GenerateRandomNumber
-- **Apple OS X** _(10.7+)/iOS(2.0+)_: int SecRandomCopyBytes (SecRandomRef random, size_t count, int8_t *bytes)
-- **Apple OS X** _(<10.7)_: Use /dev/random to retrieve random numbers
-- **Java** _(including Google Android Java code)_- java.security.SecureRandom class. Note that for Android 4.3 (Jelly Bean), developers must follow the Android recommended workaround and pdate their applications to explicitly initialize the PRNG with entropy from /dev/urandom or dev/random
+- **Objective-C (Apple OS X \*(10.7+)/iOS(2.0+))\***: int SecRandomCopyBytes (SecRandomRef random, size*t count, int8*t *bytes )
+- **Apple OS X** *(<10.7)*: Use /dev/random to retrieve random numbers
+- **Java** *(including Google Android Java code)*- java.security.SecureRandom class. Note that for Android 4.3 (Jelly Bean), developers must follow the Android recommended workaround and pdate their applications to explicitly initialize the PRNG with entropy from /dev/urandom or dev/random
+
+Source: https://cheatsheetseries.owasp.org/cheatsheets/Cryptographic_Storage_Cheat_Sheet.html#secure-random-number-generation
+
+### Store Private and Symmetric Keys in a Secure Location
+
+Private and symmetric keys should be stored in a secret storage solution that makes sense for your application. See our Secrets Management guidance for specific recommendations.
 
 ### References
+
 - https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-52r1.pdf
 - https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-52r2.pdf
 
 ### Contributors
 
-Jose Perez - Mar. 2020
\ No newline at end of file
+* Jose Perez - Mar. 2020
+* Andrew Luke - December 2021
\ No newline at end of file

From 3a3ded51f587ffa22e8c1ed83ba4d304d6d8a7e9 Mon Sep 17 00:00:00 2001
From: Andrew Luke <andrewl@unity3d.com>
Date: Wed, 1 Dec 2021 14:54:02 -0800
Subject: [PATCH 44/54] Added table of contents

---
 Coding Practice/Cryptographic-Guidelines.md | 11 ++++++++---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/Coding Practice/Cryptographic-Guidelines.md b/Coding Practice/Cryptographic-Guidelines.md
index 7d174d6..6bc34d7 100644
--- a/Coding Practice/Cryptographic-Guidelines.md	
+++ b/Coding Practice/Cryptographic-Guidelines.md	
@@ -6,6 +6,13 @@
 
 This document provides guidelines for how utilize encryption to protect data in transit and at rest. Cryptographic requirements at [COMPANY_NAME] are heavily influenced by NIST's Cryptographic Standards and Guidelines (CSRC) documentation.
 
+- [Store the Cryptographic Hash of a Password](#store-the-cryptographic-hash-of-a-password)
+- [Encrypt Sensitive Data At Rest](#encrypt-sensitive-data-at-rest)
+- [Encrypt Data In Transit](#encrypt-data-in-transit)
+- [Facilitate and Exercise Key Rotation](#facilitate-and-exercise-key-rotation)
+- [Use Secure Random Number Generators](#use-secure-random-number-generators)
+- [Store Private and Symmetric Keys in a Secure Location](#store-private-and-symmetric-keys-in-a-secure-location)
+
 ## Recommendations
 
 ### Store the Cryptographic Hash of a Password
@@ -119,9 +126,7 @@ In order to support periodic and on-demand (e.g., security incident) key rotatio
 
 When rotating keys it is often necessary for previous keys to stay around for a time to decrypt past data. A previous key should never be used to encrypt data once it is no longer the primary key. It should only be used to decrypt the data it was used to encrypt. When the data is ready to be stored again it should then be encrypted with the current key and stored.
 
-### Secure Random Number Generation
-
-
+### Use Secure Random Number Generators
 
 #### Recommended Cryptographically Secure Pseudo-Random Number Generators (CSPRNG)
 

From bce2423d052e2e468d4df6542a6fe049da5a5f67 Mon Sep 17 00:00:00 2001
From: Andrew Luke <andrewl@unity3d.com>
Date: Wed, 1 Dec 2021 14:58:35 -0800
Subject: [PATCH 45/54] Removed company specific wording

---
 Coding Practice/Cryptographic-Guidelines.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Coding Practice/Cryptographic-Guidelines.md b/Coding Practice/Cryptographic-Guidelines.md
index 6bc34d7..c7cd2c8 100644
--- a/Coding Practice/Cryptographic-Guidelines.md	
+++ b/Coding Practice/Cryptographic-Guidelines.md	
@@ -17,7 +17,7 @@ This document provides guidelines for how utilize encryption to protect data in
 
 ### Store the Cryptographic Hash of a Password
 
-User passwords should be stored as cryptographic hashes. Cleartext or encrypted password storage are not permitted. For more information on the reasons behind this, check out [this article](https://auth0.com/blog/hashing-passwords-one-way-road-to-security/) by Auth0. Most services at Unity should never have to worry about storing a password as for 99% of the cases this is what Genesis, Okta, and GCP OAuth are for. In the rare case a password storage mechanism is needed, **use an algorithm like BCrypt, PBKDF2, or Argon2**; these should be used with a decent work-factor. Hashed passwords should be salted with at least a 32-bit random salt. Remember that hashing algorithms are intentionally slow by design. The slower they are, the longer they take to crack.
+User passwords should be stored as cryptographic hashes. Cleartext or encrypted password storage are not permitted. For more information on the reasons behind this, check out [this article](https://auth0.com/blog/hashing-passwords-one-way-road-to-security/) by Auth0. The Security Team recomends **using an algorithm like BCrypt, PBKDF2, or Argon2 **; these should be used with a decent work-factor. Hashed passwords should be salted with at least a 32-bit random salt. Remember that hashing algorithms are intentionally slow by design. The slower they are, the longer they take to crack.
 
 ##### Hash Algorithms for other user cases:
 
@@ -49,7 +49,7 @@ Sensitive data should be encrypted when stored and then decrypted when accessed.
 
 Maintained, trustworthy implementations of industry approved cryptographic algorithms, ciphers, and modes should be used to accomplish this. Writing your own cryptography is strongly discouraged.
 
-**The Security Team recommends using AES-256 GCM as the algorithm and key-size for symmetric encryption**. Keep in mind that encryption standards are constantly changing, so it is important to keep your encryption and decryption functionality customizable and upgradable. If you are unsure if your data needs to be encrypted, consult with the Unity Governance and Compliance team or the Unity Legal team for help making that determination.
+**The Security Team recommends using AES-256 GCM as the algorithm and key-size for symmetric encryption**. Keep in mind that encryption standards are constantly changing, so it is important to keep your encryption and decryption functionality customizable and upgradable. If you are unsure if your data needs to be encrypted, consult with the [COMPANY_NAME] Governance and Compliance team or the [COMPANY_NAME] Legal team for help making that determination.
 
 #### Authentication
 

From f4c3a00595aac5e81627d4cb807bfd0cb66c77ab Mon Sep 17 00:00:00 2001
From: Andrew Luke <andrewl@unity3d.com>
Date: Wed, 1 Dec 2021 16:10:27 -0800
Subject: [PATCH 46/54] initial commit

---
 Coding Practice/Dependency-Security.md | 260 +++++++++++++++++++++++++
 1 file changed, 260 insertions(+)
 create mode 100644 Coding Practice/Dependency-Security.md

diff --git a/Coding Practice/Dependency-Security.md b/Coding Practice/Dependency-Security.md
new file mode 100644
index 0000000..fc1dfc9
--- /dev/null
+++ b/Coding Practice/Dependency-Security.md	
@@ -0,0 +1,260 @@
+# Dependency Security [Coding Practice]
+
+## Overview
+
+### Description
+
+This document provides guidelines for how to securely store and retrieve dependencies when building and deploying your software. There are some security practices and considerations to be aware of when retrieving dependencies, both as the developer retrieving a dependency, and as a developer hosting dependencies for others to consume.
+
+NOTE: Dependencies come in many flavors (modules, packages, libraries, etc.), so we will refer to a dependency generically as "package" in this document.#store-private-and-symmetric-keys-in-a-secure-location)
+
+- [Python - Pip](#python---pip)
+- [NPM/Yarn](#npmyarn)
+- [Golang - Go Modules](#golang---go-modules)
+- [Maven](#maven)
+- [Nuget](#nuget)
+- [Brew](#brew)
+- [Artifactory](#artifactory)
+- [Jenkins](#jenkins)
+- [Gems](#gems)
+
+### General Recommendations
+
+- Keep dependency management software up to date.
+- Internally developed and used dependencies should be stored on an internal package repository.
+  - The internal package repository should NOT proxy public registries.
+- Ensure that your build and deployment scripts are querying the correct package repositories for your internal packages.
+- Public repositories should not be queried for internally stored packages.
+- Utilize package checksum or hash integrity checking to ensure the correct dependency is being retrieved
+- Pin specific dependency versions to be used.
+- Follow the dependency management specific recommendations below.
+
+### Vulnerable Technologies
+
+| Technololgy       | Vulnerable? |
+| :---------------- | :---------- |
+| Python/Pip        | Yes         |
+| NPM/Yarn          | Yes         |
+| Ruby/Gems         | Yes         |
+| Golang/Go Modules | No          |
+| Maven             | Yes         |
+| Nuget             | Yes         |
+| Homebrew          | Yes         |
+| Artifactory       | Yes         |
+| Jenkins           | Yes         |
+
+## Python - Pip
+
+### Description
+
+The Python package manager *pip* has two command line argument that are used for specifying the URL of the Python Package Index: *--index-url* and *--extra-index-url*. The latter can be dangerous if not fully understood. Like the *--index-url* argument, -*-extra-index-url* argument takes an index URL, but it will also do a lookup and comparison against the package in PyPI and select the package with the highest version number. According to [this research](https://medium.com/@alex.birsan/dependency-confusion-4a5d60fec610), the sequence of events are:
+
+1. Check whether the library exists on the specified (internal) package index
+2. Check whether the library exists on the public package index (PyPI)
+3. Install whichever version is found. If the package exists on both, it defaults to installing from the source with the higher version number.
+
+If an attacker uploads malicious code to PyPI with the same package name and a higher version number, that malicious code will be loaded and execute in the build.
+
+If the -*-extra-index-url* command line argument is used without control of the package in PyPI, an attacker can gain code execution on the build system, compromising the security of that system and any systems associated with that application.
+
+### How to Fix?
+
+Avoid usage of *--extra-index-url* when using *pip* in your deployment scripts or pipelines. Instead use the --index-url switch, which does not contain this kind of unexpected behavior. Use “pip-compile” to generate locked file with hashes and enable hash checking mode when installing.
+
+### References
+
+- https://medium.com/@alex.birsan/dependency-confusion-4a5d60fec610
+- https://azure.microsoft.com/en-us/resources/3-ways-to-mitigate-risk-using-private-package-feeds/
+
+## NPM/Yarn
+
+### Description
+
+Node Package Manager (NPM) by default uses the [https://npmjs.com](https://npmjs.com/) package registry. If a developer does not explicitly define scopes and versions for their dependencies, they may download a package from an unintended registry, such as the public NPM registry. If a malicious attacker uploads malicious code to NPM publicly for a private package with a higher version, the malicious package will be automatically downloaded when the user pulls down updated dependencies.
+
+### How to Fix?
+
+The following mitigations should be in place:
+
+1. Define strict scopes for 
+
+   dependencies
+
+   ​	a. Leverage the \@scope notation in order to define explicit scopes for packages in the project's local .npmrc file
+
+   ​	b. Example:
+
+```
+@mycompany:registry = https:``//registry.mycompany.local/
+```
+
+1. Only use trusted or private registries, and do not proxy external registries.
+
+2. Use explicit version numbers in the package.json
+
+   ​	a. Example:
+
+```
+{
+	"name": "@mycompany/foo",
+	"version": "1.2.3",
+	"description": "just a scoped package name example",
+	"dependencies": {
+		"@mycompany/bar": "2.0"
+	}
+}
+```
+
+### References
+
+- https://github.blog/2021-02-12-avoiding-npm-substitution-attacks/
+
+## Golang - Go Modules
+
+### Description
+
+Go 1.11 introduced Go Modules as the official dependency management system. Prior to Go Modules, there were a number of 3rd party dependency management options, such as Glide, Govendor, and dep. Since Go 1.11, these have all be deprecated, archived, or are no longer maintained. Due to this, it is best to use Go Modules for dependency management. Go Modules is not vulnerable to dependency confusion.
+
+### How to Fix?
+
+Only use Go Modules for dependency management. Other Go dependency management solutions are no longer maintained
+
+### References
+
+- https://blog.golang.org/using-go-modules
+- https://golang.org/ref/mod
+
+## Maven
+
+### Description
+
+Multiple repository URLs can be specified in user or project profiles. These are queried in order, but the order is not obvious from any one configuration file. Dependencies are checked for modifications since the original upload but cannot be automatically verified against prior installs.
+
+### How to Fix?
+
+Configure a single mirror that is `<mirrorOf>*</mirrorOf>` to direct all requests through a single repository. This will ensure your private repository takes priority. Enable upstreams on the private repository. Alternatively, the default public repository can be overridden to disable the setting.
+
+Maven currently has no integrated features for further checks. Your only option is to switch to Gradle for checksum and signature checks.
+
+### References
+
+- Sourced from: https://azure.microsoft.com/en-us/resources/3-ways-to-mitigate-risk-using-private-package-feeds/
+- https://maven.apache.org/guides/mini/guide-mirror-settings.html#using-a-single-repository
+
+## Nuget
+
+### Description
+
+Multiple package sources specified by user or project. The latest version found from any of sources checked will be installed. If an attacker uploads malicious code to a public source with the same package name and a higher version number, that malicious code will be loaded and execute in the build.
+
+### How to Fix?
+
+Clear all packageSource settings in project configuration or nuget.config, add only your private gallery, and enable upstreams. Ensure your nuget.config packageSources section starts with a `<clear />` entry to remove any inherited configuration, and use a single `<add />` entry for your private feed.
+
+Prefer the “nuget restore --locked-mode” command and include a generated packages.lock.json with your project. A packages.lock.json file will be automatically created on “nuget restore.” When the file exists and is included with your project, it will be used by “nuget restore --locked-mode” to validate that the packages have not changed using version pinning and integrity checking. 
+
+An ID prefix can be registered by publishers to restrict uploads to the public gallery. Packages under a registered prefix can only be uploaded by approved accounts, which also protects against public substitution attacks. This reservation can be done whether you intend to publish your packages to [NuGet.org](http://nuget.org/) or not. Using a registered ID prefix for private packages helps ensure that an attacker cannot claim any of your names.
+
+### References
+
+- Sourced from: https://azure.microsoft.com/en-us/resources/3-ways-to-mitigate-risk-using-private-package-feeds/
+- https://docs.microsoft.com/en-us/nuget/nuget-org/id-prefix-reservation
+- https://docs.microsoft.com/en-us/nuget/consume-packages/package-references-in-project-files#locking-dependencies
+
+## Brew
+
+### Description
+
+Homebrew is a package manager used for MacOS to install command line tools, applications built directly from source. Homebrew typically installs/compiles code based on the repository owner and name, when using the `brew install` command. This can lead to an issue if the proper casks have not been tapped, that the user may download the incorrect package.
+
+### How to Fix?
+
+We recommend adding a prefix to all internal tool repositories. This will mitigate the issues when trying to pull new brew packages. Additionally, we recommend using the full formula name, in order to avoid ambiguity.
+
+## Artifactory
+
+### Description
+
+Artifactory has a "Virtual Repositories" feature that essentially works like pip's --extra-index-url flag. When using virtual repositories, Artifactory will search both private and public packages, and then select the one with the highest version number. Documentation explicitly states that Artifactory will grab the newest version, even if a local repo is found first. (Documentation on [Virtual Repositories](https://www.jfrog.com/confluence/display/JFROG/Virtual+Repositories)) Artifactory is currently treating the fix for this as a "feature request" so there is no timeline on granular access controls as a mitigation.
+
+![Example of the repo selection view](https://www.jfrog.com/confluence/download/attachments/89296181/available_virtual_repos.png?version=1&modificationDate=1562244868000&api=v2)
+
+### How to Fix?
+
+Remove all third party repository sources from the Virtual Repository lists, or disable Virtual Repositories entirely.
+
+### References
+
+- https://www.jfrog.com/confluence/display/JFROG/Virtual+Repositories
+
+## Jenkins
+
+### Description
+
+The Jenkins project uses its own Artifactory binary repository, to distribute core, library, and plugin releases. Only artifacts uploaded there can be considered released. Plugins and libraries are not uploaded or mirrored to Maven Central. The Jenkins Artifactory is hosted at [https://repo.jenkins-ci.org](https://repo.jenkins-ci.org/). Anyone has permission to view and download all (public) artifacts. Jenkins will only delete published packages that are considered a “risk”, so it's extra important to carefully check the packages being pulled.
+
+### How to Fix?
+
+Use an explicit package version when pulling from the Jenkins Artifactory. Consider using a controlled source to pull packages from.
+
+### References
+
+- https://www.jenkins.io/doc/developer/publishing/artifact-repository/
+
+## Gems
+
+### Description
+
+Dependency confusion can occur when multiple global sources are listed in Bundler. For example, suppose you need to include both private and public Gems in your project. You would need to include the sources for both public and private Gems. Sources can be declared in numerous ways and Bundler will chose the source based on Source Priority Rules below:
+
+1. The source explicitly attached to the gem (using `:source`, `:path`, or `:git`)
+2. For implicit gems (dependencies of explicit gems), any source, git, or path repository declared on the parent. This results in bundler prioritizing the ActiveSupport gem from the Rails git repository over ones from `rubygems.org`
+3. The sources specified via global `source` lines, searching each source in your `Gemfile` from last added to first added.
+
+Dependency Confusion can occur if no other source is explicitly declared **and** multiple global sources are specified. There are two primary scenarios where this can occur:
+
+1. Your intended source is listed **before** the unintended global source
+2. Your intended source **fails** and Bundler tries the next global source
+
+### How to Fix?
+
+When specifying required gems with Bundler,
+
+- **Do not** specify multiple global sources. Listing multiple global sources can lead to gems being installed from unintended sources. Bundler will throw a warning if a Gem has multiple sources and will tell you *which* source was used as well as alternative sources
+- **Do not** use the `:github` shorthand to define public Github sources. This will default to the insecure `git://` protocol which is vulnerable to man-in-the-middle attacks.
+- **Do** wrap gems from alternate/private sources blocks. This specifies the proper source for gems from alternate sources. Alternatively, you can specify individual gems inline if only one gem is required from a particular private source.
+- **Do** explicitly define sources to routes using `https://`
+
+**Bundler Config For Multiple Sources**
+
+```
+# Global Sourced Gems
+source 'https://rubygems.org'
+ 
+# Gems here
+ 
+# Source wrapped Gems
+source 'https://gems.example.com' do
+  # Multiple Gems from the alternative source here
+end
+ 
+#Individual Gem from a private source
+gem 'testgem', '1.0', :source => 'https://gems.example.com'
+ 
+#Individual Gem from git repository
+gem 'testgem', :git => 'https://github.com/company-internal/testgem.git', :branch => 'master'
+```
+
+## References
+
+https://mensfeld.pl/2021/02/rubygems-dependency-confusion-attack-side-of-things/
+
+https://bundler.io/gemfile.html
+
+https://bundler.io/man/gemfile.5.html
+
+https://bundler.io/man/gemfile.5.html#SOURCE-PRIORITY
+
+## Contributors
+
+* Carlo Valentin, Cody Ebert, Frankie Arana, Jonathan Downing, Andrew Luke - December 2021
\ No newline at end of file

From 57eaeba0d6bbf83ac591785d448769bbd9247c3b Mon Sep 17 00:00:00 2001
From: Andrew Luke <andrewl@unity3d.com>
Date: Wed, 1 Dec 2021 16:49:49 -0800
Subject: [PATCH 47/54] initial commit

---
 .../Web-Application-Rate-Limiting.md          | 347 ++++++++++++++++++
 1 file changed, 347 insertions(+)
 create mode 100644 Coding Practice/Web-Application-Rate-Limiting.md

diff --git a/Coding Practice/Web-Application-Rate-Limiting.md b/Coding Practice/Web-Application-Rate-Limiting.md
new file mode 100644
index 0000000..f5b41bc
--- /dev/null
+++ b/Coding Practice/Web-Application-Rate-Limiting.md	
@@ -0,0 +1,347 @@
+# Secure Design Principles [Coding Practice]
+
+<font size="-1">_Author: Andrew Luke - Dec. 2021_</font>
+
+## Overview
+
+- [HAProxy](#haproxy)
+- [NGINX](#nginx)
+- [Apache](#apache)
+- [Envoy](#envoy)
+- [node.js](#nodejs)
+- [Golang](#golang)
+- [Ruby](#ruby)
+- [Python](#python)
+  - [Flask](#flask)
+  - [Django](#django)
+- [ASP.NET](#aspnet)
+- [Java](#java)
+
+"Rate limiting is the process of controlling traffic rate from and to a server or component. It can be implemented on infrastructure as well as on an application level. Rate limiting can be based on (offending) IPs, on IP blacklists, on geolocation, etc." – [OWASP](https://cheatsheetseries.owasp.org/cheatsheets/Denial_of_Service_Cheat_Sheet.html#:~:text=Rate limiting is the process,blacklists%2C on geolocation%2C etc.)
+
+Rate limiting is a way to defend your web application against Denial of Service (DoS) attacks and scraping of data. DoS is commonly thought of as overwhelming a target system with network traffic to the point it is no longer accessible to other end users, which is typically done with a distributed network of thousands or millions of systems (DDoS). There are other ways to DoS a web application, such as consuming available system resources by repeatedly calling resource intensive endpoints. For example, flooding requests to endpoints that handle complex computation or file system operations could be used to exhaust available workers file system resources. Another example is to abuse a web application endpoint that includes calls to another rate-limited service to that point that the rate-limited is violated. The target web application could be temporarily blocked from accessing the rate-limited service, denying that endpoint functionality to every end user. This is where request rate-limiting comes in. Rate-limiting can be used to restrict the rate of requests from a source IP for either specific endpoints or the entire web application. Actions taken on users that violate the rate-limits can vary from throttling to temporary or permanent IP blacklisting. Rate-limiting is also an effective way to defend against data scraping, vulnerability scanning, and brute forcing login forms. 
+
+There are several rate limiting algorithms that [Google Solutions does a good job of summarizing](https://cloud.google.com/solutions/rate-limiting-strategies-techniques#techniques-enforcing-rate-limits):
+
+- **Token bucket**: A [token bucket](https://wikipedia.org/wiki/Token_bucket) maintains a rolling and accumulating budget of usage as a balance of *tokens*. This technique recognizes that not all inputs to a service correspond 1:1 with requests. A token bucket adds tokens at some rate. When a service request is made, the service attempts to withdraw a token (decrementing the token count) to fulfill the request. If there are no tokens in the bucket, the service has reached its limit and responds with backpressure. For example, in a GraphQL service, a single request might result in multiple operations that are composed into a result. These operations may each take one token. This way, the service can keep track of the capacity that it needs to limit the use of, rather than tie the rate-limiting technique directly to requests.
+- **Leaky bucket**: A [leaky bucket](https://wikipedia.org/wiki/Leaky_bucket) is similar to a token bucket, but the rate is limited by the amount that can drip or leak out of the bucket. This technique recognizes that the system has some degree of finite capacity to hold a request until the service can act on it; any extra simply spills over the edge and is discarded. This notion of buffer capacity (but not necessarily the use of leaky buckets) also applies to components adjacent to your service, such as load balancers and disk I/O buffers.
+- **Fixed window**: Fixed-window limits—such as 3,000 requests per hour or 10 requests per day—are easy to state, but they are subject to spikes at the edges of the window, as available quota resets. Consider, for example, a limit of 3,000 requests per hour, which still allows for a spike of all 3,000 requests to be made in the first minute of the hour, which might overwhelm the service.
+- **Sliding window**: Sliding windows have the benefits of a fixed window, but the rolling window of time smooths out bursts. Systems such as Redis facilitate this technique with expiring keys.
+
+Below is a non-comprehensive list of rate limiting options for common types of web servers and web application frameworks. The options and algorithms used vary and are annotated for each. Keep in mind these only cover rate limiting at the web server and web application level. This guide does not cover CDN, WAF, and cloud load balancer solutions, which are more effective measures against DDoS attacks. 
+
+Resources: 
+
+- [OWASP API Security Top 10 - Lack of Resources and Rate Limiting](https://github.com/OWASP/API-Security/blob/master/2019/en/src/0xa4-lack-of-resources-and-rate-limiting.md) 
+- [Google Solutions - Rate-limiting strategies and techniques](https://cloud.google.com/solutions/rate-limiting-strategies-techniques)
+
+## HAProxy
+
+Sliding window code example for a 10 requests per second limit with a 100 kilobyte stick-table size. Requests that surpass this limit will return and HTTP 429 response:
+
+```
+frontend website
+    bind :80
+    stick-table  type ip  size 100k  expire 30s  store http_req_rate(1s)
+    http-request track-sc0 src
+    http-request deny deny_status 429 if { sc_http_req_rate(0) gt 10 }
+    default_backend servers
+```
+
+Fixed Window code example for 1000 requests per day:
+
+```
+frontend website
+    bind :80
+    stick-table type ip size 100k expire 24h store http_req_cnt
+    http-request track-sc0 src
+    http-request deny deny_status 429 if { sc_http_req_cnt(0) gt 1000 }
+    default_backend servers
+```
+
+For rate limiting specific webapp endpoints, create a file that lists the endpoints and their rate limits named 'rates.map' in /etc/haproxy:
+
+```
+/search  10
+/save  20
+/update  30
+```
+
+Then reference the list in the HAProxy config:
+
+```
+frontend website
+    bind :80
+    stick-table  type binary  len 8  size 100k  expire 10s  store http_req_rate(10s)
+ 
+    # Track client by base32+src (Host header + URL path + src IP)
+    http-request track-sc0 base32+src
+ 
+    # Check map file to get rate limit for path
+    http-request set-var(req.rate_limit)  path,map_beg(/etc/haproxy/rates.map,20)
+ 
+    # Client's request rate is tracked
+    http-request set-var(req.request_rate)  base32+src,table_http_req_rate()
+ 
+    # Subtract the current request rate from the limit
+    # If less than zero, set rate_abuse to true
+    acl rate_abuse var(req.rate_limit),sub(req.request_rate) lt 0  
+ 
+    # Deny if rate abuse
+    http-request deny deny_status 429 if rate_abuse
+    default_backend servers
+```
+
+Source: https://www.haproxy.com/blog/four-examples-of-haproxy-rate-limiting/
+
+## NGINX
+
+NGINX uses the leaky bucket rate limiting algorithm. Code example for a 10 requests per second limit with a 10 megabyte zone size (16,000 IP addresses per megabyte). Bursts can be allowed by adding a burst limit (20 here):
+
+```
+http {
+    #...
+ 
+    limit_req_zone $binary_remote_addr zone=one:10m rate=10r/s;
+ 
+    server {
+        #...
+ 
+        location /search/ {
+            limit_req zone=one burst=20;
+        }
+    }
+}
+```
+
+Blog post: https://www.nginx.com/blog/rate-limiting-nginx/
+Webinar: https://www.nginx.com/resources/webinars/rate-limiting-nginx/
+Documentation: https://docs.nginx.com/nginx/admin-guide/security-controls/controlling-access-proxied-http/
+
+## Apache
+
+The mod_ratelimit Apache module allows developers to specify rate limits on a location by location basis. Rather than limiting the rate by requests per second, mod_ratelimit instead limits bandwidth in kilobytes per second based on HTTP response.
+
+Code example limiting bandwidth to 400 KiB/s with a burst rate of 512 KiB/s:
+
+```
+<Location "/search">
+    SetOutputFilter RATE_LIMIT
+    SetEnv rate-limit 400
+    SetEnv rate-initial-burst 512
+</Location>
+```
+
+Source: https://documentation.help/httpd-2.4/mod_ratelimit.html
+
+## Envoy
+
+In order to implement rate limiting with Envoy, you need to point it to a gRPC rate limiting service. Lyft has an open source [Golang rate limiting service](https://github.com/envoyproxy/ratelimit) that utilizes Redis to track rates. Example for limiting individual users to 10 requests per second:
+
+```
+domain: edge_proxy_per_ip
+descriptors:
+  - key: remote_address
+    rate_limit:
+      unit: second
+      requests_per_unit: 10
+```
+
+Service: https://github.com/envoyproxy/ratelimit
+
+Documentation: https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/other_features/global_rate_limiting
+
+## node.js
+
+[Express-rate-limit](https://www.npmjs.com/package/express-rate-limit) offers application-wide, sliding window rate limiting and per-endpoint rate limiting of Express web applications. It uses an in-memory store by default, but also supports Redis, Memached, and Mongo.
+
+Code example for rate limit of 10 requests per second:
+
+```
+const rateLimit = require("express-rate-limit");
+  
+const limiter = rateLimit({
+  windowMs: 1 * 60 * 1000, // 1 minutes
+  max: 600, // limit each IP to 600 requests per windowMs
+  headers: false // don't send X-RateLimit-Limit, X-RateLimit-Remaining, and Retry-After headers in response
+});
+  
+//  apply to all requests
+app.use(limiter);
+ 
+// only apply to requests that begin with /search/
+app.use("/search/", limiter);
+```
+
+Library: https://www.npmjs.com/package/express-rate-limit
+
+## Golang
+
+[tollbooth](https://github.com/didip/tollbooth) offers per-handler rate limiting middleware. Shims for common web frameworks are linked in the README. Code example for rate limit of 10 requests per second:
+
+```
+package main
+ 
+import (
+    "github.com/didip/tollbooth"
+    "net/http"
+)
+ 
+func HelloHandler(w http.ResponseWriter, req *http.Request) {
+    w.Write([]byte("Hello, World!"))
+}
+ 
+func main() {
+    // Create a request limiter per handler.
+    http.Handle("/", tollbooth.LimitFuncHandler(tollbooth.NewLimiter(10, nil), HelloHandler))
+    http.ListenAndServe(":12345", nil)
+}
+```
+
+Library: https://github.com/didip/tollbooth
+Blog Post on rolling your own per-user rate limiter in Golang: https://www.alexedwards.net/blog/how-to-rate-limit-http-requests
+
+## Ruby
+
+Kickstarter's rack-attack library uses fixed window rate throttling
+Code example for universal rate limiting to 10 requests per second:
+
+```
+Rack::Attack.throttle('request per ip', limit: 50, period: 5) do |request|
+  request.ip
+end
+```
+
+Code example for rate limiting /search to 10 requests per second:
+
+```
+Rack::Attack.throttle "logins/ip", limit: 2, period: 1 do |req|
+  req.path == "/search" && req.ip
+end
+```
+
+Library: https://github.com/rack/rack-attack
+Example: https://github.com/rack/rack-attack/blob/master/examples/rack_attack.rb
+
+## Python
+
+### Flask
+
+Flask-limiter supports fixed window and sliding window rate limiting. Code example for rate limiting /search to 10 requests per second and universally to 100 per minute:
+
+```
+from flask import Flask
+from flask_limiter import Limiter
+from flask_limiter.util import get_remote_address
+ 
+app = Flask(__name__)
+limiter = Limiter(
+    app,
+    key_func=get_remote_address,
+    default_limits=["100 per minute"],
+)
+ 
+@app.route("/search")
+@limiter.limit("10 per second")
+def slow():
+    return "24"
+```
+
+Library: https://github.com/alisaifee/flask-limiter
+Documentation: https://flask-limiter.readthedocs.io/en/stable/
+
+### Django
+
+Code example for rate limiting /search to 10 requests per second:
+
+```
+from ratelimit.decorators import ratelimit
+ 
+@ratelimit(key='ip', rate='10/s')
+def search(request):
+    # ...
+```
+
+Library: https://github.com/jsocol/django-ratelimit
+Documentation: https://django-ratelimit.readthedocs.io/en/stable/
+
+# ASP.NET
+
+The AspNetCoreRateLimit library offers rate limiting middleware to impliment into your web API/MVC application.
+Code example:
+
+```
+public void ConfigureServices(IServiceCollection services)
+{
+    // needed to load configuration from appsettings.json
+    services.AddOptions();
+ 
+    // needed to store rate limit counters and ip rules
+    services.AddMemoryCache();
+ 
+    //load general configuration from appsettings.json
+    services.Configure<IpRateLimitOptions>(Configuration.GetSection("IpRateLimiting"));
+ 
+    // inject counter and rules stores
+    services.AddSingleton<IIpPolicyStore, MemoryCacheIpPolicyStore>();
+    services.AddSingleton<IRateLimitCounterStore, MemoryCacheRateLimitCounterStore>();
+ 
+    // Add framework services.
+    services.AddMvc();
+ 
+    // https://github.com/aspnet/Hosting/issues/793
+    // the IHttpContextAccessor service is not registered by default.
+    // the clientId/clientIp resolvers use it.
+    services.AddSingleton<IHttpContextAccessor, HttpContextAccessor>();
+ 
+    // configuration (resolvers, counter key builders)
+    services.AddSingleton<IRateLimitConfiguration, RateLimitConfiguration>();
+}
+ 
+public void Configure(IApplicationBuilder app, IHostingEnvironment env)
+{
+    app.UseIpRateLimiting();
+ 
+    app.UseMvc();
+}
+```
+
+In the appsettings.json file:
+
+```
+"IpRateLimiting": {
+    "EnableEndpointRateLimiting": false, // limits apply globally
+    "StackBlockedRequests": false,
+    "RealIpHeader": "X-Real-IP",
+    "ClientIdHeader": "X-ClientId",
+    "HttpStatusCode": 429,
+    "IpWhitelist": [ "127.0.0.1", "::1/10", "192.168.0.0/24" ],
+    "EndpointWhitelist": [ "get:/api/license", "*:/api/status" ],
+    "ClientWhitelist": [ "dev-id-1", "dev-id-2" ],
+    "GeneralRules": [
+        {
+        "Endpoint": "*",
+        "Period": "1m",
+        "Limit": 100
+        },
+        {
+        "Endpoint": "*:/search/*",
+        "Period": "1s",
+        "Limit": 10
+        }
+    ]
+}
+```
+
+Library: https://github.com/stefanprodan/AspNetCoreRateLimit
+Setup: https://github.com/stefanprodan/AspNetCoreRateLimit/wiki/IpRateLimitMiddleware#setup
+
+## Java
+
+The resilience4j library offers a lot of functionality, including rate limiting. Implementation is a bit more complex and is dependent on web framework used.
+Library: https://github.com/resilience4j/resilience4j
+Documentation: https://resilience4j.readme.io/docs/ratelimiter
+
+## Contributors
+
+* Andrew Luke - December 2021
\ No newline at end of file

From 441b5add5bb5bcea7c8934cf71f1fc3308575f1d Mon Sep 17 00:00:00 2001
From: Andrew Luke <andrewl@unity3d.com>
Date: Thu, 6 Jan 2022 13:45:33 -0800
Subject: [PATCH 48/54] initial commit

---
 Coding Practice/SSRF-Prevention.md | 205 +++++++++++++++++++++++++++++
 1 file changed, 205 insertions(+)
 create mode 100644 Coding Practice/SSRF-Prevention.md

diff --git a/Coding Practice/SSRF-Prevention.md b/Coding Practice/SSRF-Prevention.md
new file mode 100644
index 0000000..062ffb9
--- /dev/null
+++ b/Coding Practice/SSRF-Prevention.md	
@@ -0,0 +1,205 @@
+# Server-Side Request Forgery (SSRF) Prevention
+
+## Overview
+
+> Server-side request forgery (also known as SSRF) is a web security vulnerability that allows an attacker to induce the server-side application to make HTTP requests to an arbitrary domain of the attacker's choosing.
+>
+> In a typical SSRF attack, the attacker might cause the server to make a connection to internal-only services within the organization's infrastructure. In other cases, they may be able to force the server to connect to arbitrary external systems, potentially leaking sensitive data such as authorization credentials.
+>
+> -- PortSwigger, [Server-side request forget (SSRF)](https://portswigger.net/web-security/ssrf)
+
+## Best Practices
+
+In general, validate user submitted URLs with allow-list if your use case requires them.
+
+If arbitrary URLs are expected:
+
+- validate the submitted URL string with a regular expression or URL parsing library to ensure it fits the expected URL format.
+- use host, cluster, or VPC egress firewalls to block access to internal resources.
+- validate the URL protocol against an allow-list (e.g., only expected web URLs? only allow http and https)
+- validate user submitted authentication tokens using a regular expression (e.g., [a-zA-Z0-9]{20})
+- Return only the information needed by the frontend. Don't return the raw HTTP response from the destination web server.
+- Block access to internal resources (see section below for details).
+- Ensure that the HTTP client is not passing internal credentials to external resources.
+- Prevent the HTTP client from following redirections (HTTP 301, 302, etc.)
+
+## Block Access to Internal Resources
+
+When you need to make server-side requests based on a user-submitted URL, such as with webhooks, prevention centers around rejecting requests aimed at internal resources. There are a couple of checks that need to be performed on a submitted URL before making the server-side request.
+
+### Step 1. Check for submission of non-public IP address
+
+Determine if the submitted URL is a non-public IP address using a block-list. If the submission uses a domain name, resolve the domain's IP addresses (A and AAAA records) and then perform this check on each of them. URLs containing local, APIPA, or Private IP addresses should be rejected.
+
+Local Address Ranges:
+
+- 127.0.0.0 – 127.255.255.255
+
+Private IP Address Ranges:
+
+- 10.0.0.0 - 10.255.255.255
+- 172.16.0.0 - 172.31.255.255
+- 192.168.0.0 - 192.168.255.255
+
+APIPA Address Range:
+
+- 169.254.0.1 - 169.254.255.254
+
+```
+func validateIPs(ips []net.IP) (bool, error) {
+  if len(ips) == 0 {
+    return false, errors.New("IP not found")
+  }
+ 
+  for _, ip := range ips {
+    if ip.To16() == nil && ip.To4() == nil {
+      log.Errorf("IP: %v is not valid", ip)
+      return false, errors.New("IP is not valid")
+    }
+    // IsPrivate reports whether ip is a private address, according to
+    // RFC 1918 (IPv4 addresses) and RFC 4193 (IPv6 addresses).
+    if ip.IsPrivate() {
+      log.Errorf("IP address: %v is a private address", ip)
+      return false, errors.New("IP address is a private address")
+    }
+    // checks Local Address Range of 127.0.0.0 - 127.255.255.255
+    if ip.IsLoopback() {
+      log.Errorf("IP address: %v is a local address", ip)
+      return false, errors.New("IP address is a local address")
+    }
+    // checks APIPA Address Range of 169.254.0.0 - 169.254.255.255
+    if ip.IsLinkLocalUnicast() {
+      log.Errorf("IP address: %v is a link-local unicast address", ip)
+      return false, errors.New("IP address is a link-local unicast address")
+    }
+  }
+ 
+  return true, nil
+}
+
+```
+
+```
+# Source: https://gitlab.com/gitlab-org/gitlab-foss/-/blob/eabd80f72f4f7d8e19b26526aa1f44c43d78e8b3/lib/gitlab/url_blocker.rb#L214-L240
+def validate_localhost(addrs_info)
+    local_ips = ["::", "0.0.0.0"]
+    local_ips.concat(Socket.ip_address_list.map(&:ip_address))
+ 
+    return if (local_ips & addrs_info.map(&:ip_address)).empty?
+ 
+    raise BlockedUrlError, "Requests to localhost are not allowed"
+end
+ 
+def validate_loopback(addrs_info)
+    return unless addrs_info.any? { |addr| addr.ipv4_loopback? || addr.ipv6_loopback? }
+ 
+    raise BlockedUrlError, "Requests to loopback addresses are not allowed"
+end
+ 
+def validate_local_network(addrs_info)
+    return unless addrs_info.any? { |addr| addr.ipv4_private? || addr.ipv6_sitelocal? || addr.ipv6_unique_local? }
+ 
+    raise BlockedUrlError, "Requests to the local network are not allowed"
+end
+ 
+def validate_link_local(addrs_info)
+    netmask = IPAddr.new('169.254.0.0/16')
+    return unless addrs_info.any? { |addr| addr.ipv6_linklocal? || netmask.include?(addr.ip_address) }
+ 
+    raise BlockedUrlError, "Requests to the link local network are not allowed"
+end
+```
+
+### Step 2. Prevent secondary name resolution
+
+If the URL submitted uses a domain name, you need to protect against DNS rebinding attacks by preserving the DNS resolution done in Step 1. It is common for an HTTP client library to perform its own DNS resolution when passed a URL. If an attacker changes the DNS record to a local, APIPA, or Private IP address between the resolution in Step 1 and the DNS resolution performed by the HTTP client, this validation performed in Step 1 can be bypassed. This is called a DNS Rebinding Attack.
+
+The video below explains how SSRF can be combined with DNS Rebinding to bypass IP checks.
+
+There are a couple of ways prevent this.
+
+#### Option 1
+
+The first is the method used by Gitlab in the video above (found [here](https://gitlab.com/gitlab-org/gitlab-foss/-/blob/eabd80f72f4f7d8e19b26526aa1f44c43d78e8b3/lib/gitlab/url_blocker.rb#L22)), it to replace the URL's domain with a validated IP address from Step 1. Pass this URL to your HTTP client to prevent a secondary DNS resolution.
+
+For example, change the user submitted URL:
+
+> https://www.mywebsite.com/validate
+
+to the following URL:
+
+> https://55.26.115.78/validate
+
+Simplified code example of how Gitlab validates a submitted URI and transforms it. The `protected_uri_with_hostname` returned is used by an HTTP client. 
+
+```
+# Source: https://gitlab.com/gitlab-org/gitlab-foss/-/blob/eabd80f72f4f7d8e19b26526aa1f44c43d78e8b3/lib/gitlab/url_blocker.rb#L22
+require 'ipaddress'
+ 
+# Expects Addressable::URI
+def validate_uri(uri)
+    address_info = get_address_info(uri)
+    ip_address = address_info.first&.ip_address
+    # Replace domain with resolved IP address    
+    protected_uri_with_hostname = enforce_uri_hostname(ip_address, uri)
+    protected_uri_with_hostname
+end
+ 
+def enforce_uri_hostname(ip_address, uri)
+    return [uri, nil] unless ip_address && ip_address != uri.hostname
+    new_uri = uri.dup
+    new_uri.hostname = ip_address
+    [new_uri, uri.hostname]
+end
+ 
+def get_address_info(uri)
+    Addrinfo.getaddrinfo(uri.hostname, get_port(uri), nil, :STREAM).map do |addr|
+        addr.ipv6_v4mapped? ? addr.ipv6_to_ipv4 : addr
+    end
+rescue SocketError
+    raise BlockedUrlError, "Host cannot be resolved or invalid"
+rescue ArgumentError => error
+    raise unless error.message.include?('hostname too long')
+    raise BlockedUrlError, "Host is too long (maximum is 1024 characters)"
+end
+```
+
+This is effective, but you can run into issues if the destination web server is using virtual hosts. Without a domain to parse, the request will fail. 
+
+#### Option 2
+
+The second way to DNS Rebinding Attacks is to override the destination IP address in transport configuration of the HTTP Library. Changing it to the validated IP address from Step 1 will ensure the request goes to the validated destination. 
+
+```
+func sendGetRequest(webIP, host, scheme, path) (string, error) {
+    dialer := &net.Dialer{
+        Timeout:   10 * time.Second,
+        KeepAlive: 10 * time.Second,
+    }
+ 
+    // provide a custom Transport.DialContext function
+    // to force requests to use a specific destination IP address
+    http.DefaultTransport.(*http.Transport).DialContext = func(ctx context.Context, network, addr string) (net.Conn, error) {
+        port := ":80"
+        if scheme == "https" {
+            port = ":443"
+        }
+ 
+        addr = webIP + port
+        return dialer.DialContext(ctx, network, addr)
+    }
+ 
+    webURL := scheme + "://" + host + path
+    resp, err := http.Get(webURL)
+    if err != nil {
+        return "", fmt.Errorf("error when doing a GET request to publisher webURL [%s]: %v", webURL, err)
+    }
+}
+```
+
+```
+HttpWebRequest request = (HttpWebRequest)WebRequest.Create("https://1.2.3.4");
+request.Host = "www.example.com";
+var response = request.GetResponse();
+```
+

From a00b1fa774056de62150db778ea4bc40cf396be3 Mon Sep 17 00:00:00 2001
From: Andrew Luke <andrewl@unity3d.com>
Date: Thu, 6 Jan 2022 13:57:42 -0800
Subject: [PATCH 49/54] Added labels to code examples

---
 Coding Practice/SSRF-Prevention.md | 21 +++++++++++++++++++--
 1 file changed, 19 insertions(+), 2 deletions(-)

diff --git a/Coding Practice/SSRF-Prevention.md b/Coding Practice/SSRF-Prevention.md
index 062ffb9..8345624 100644
--- a/Coding Practice/SSRF-Prevention.md	
+++ b/Coding Practice/SSRF-Prevention.md	
@@ -45,6 +45,8 @@ APIPA Address Range:
 
 - 169.254.0.1 - 169.254.255.254
 
+**Golang Example**
+
 ```
 func validateIPs(ips []net.IP) (bool, error) {
   if len(ips) == 0 {
@@ -79,6 +81,8 @@ func validateIPs(ips []net.IP) (bool, error) {
 
 ```
 
+**Gitlab's Ruby Code Example**
+
 ```
 # Source: https://gitlab.com/gitlab-org/gitlab-foss/-/blob/eabd80f72f4f7d8e19b26526aa1f44c43d78e8b3/lib/gitlab/url_blocker.rb#L214-L240
 def validate_localhost(addrs_info)
@@ -132,6 +136,8 @@ to the following URL:
 
 Simplified code example of how Gitlab validates a submitted URI and transforms it. The `protected_uri_with_hostname` returned is used by an HTTP client. 
 
+**Gitlab's Ruby Code Example**
+
 ```
 # Source: https://gitlab.com/gitlab-org/gitlab-foss/-/blob/eabd80f72f4f7d8e19b26526aa1f44c43d78e8b3/lib/gitlab/url_blocker.rb#L22
 require 'ipaddress'
@@ -170,7 +176,9 @@ This is effective, but you can run into issues if the destination web server is
 
 The second way to DNS Rebinding Attacks is to override the destination IP address in transport configuration of the HTTP Library. Changing it to the validated IP address from Step 1 will ensure the request goes to the validated destination. 
 
-```
+**Golang Code Example**
+
+```go
 func sendGetRequest(webIP, host, scheme, path) (string, error) {
     dialer := &net.Dialer{
         Timeout:   10 * time.Second,
@@ -197,9 +205,18 @@ func sendGetRequest(webIP, host, scheme, path) (string, error) {
 }
 ```
 
-```
+**C# .NET Example**
+
+```c#
 HttpWebRequest request = (HttpWebRequest)WebRequest.Create("https://1.2.3.4");
 request.Host = "www.example.com";
 var response = request.GetResponse();
 ```
 
+## Resources
+
+* [PortSwigger SSRF Explanation and examples](https://portswigger.net/web-security/ssrf)
+* [OWASP SSRF Explanation](https://owasp.org/www-community/attacks/Server_Side_Request_Forgery) 
+* [OWASP SSRF Prevention Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Server_Side_Request_Forgery_Prevention_Cheat_Sheet.html)
+* [SSRF + DNS Rebinding Example](https://www.youtube.com/watch?v=R5WB8h7hkrU) (Video)
+* [Gitlab SSRF + DNS Rebinding Fix](https://gitlab.com/gitlab-org/gitlab-foss/-/blob/eabd80f72f4f7d8e19b26526aa1f44c43d78e8b3/lib/gitlab/url_blocker.rb#L22)
\ No newline at end of file

From 26f97fddae44d55245040ab82d61cceb4a3ec573 Mon Sep 17 00:00:00 2001
From: Andrew Luke <andrewl@unity3d.com>
Date: Thu, 6 Jan 2022 14:00:13 -0800
Subject: [PATCH 50/54] Added highlighting to code examples

---
 Coding Practice/SSRF-Prevention.md | 48 +++++++++++++++---------------
 1 file changed, 24 insertions(+), 24 deletions(-)

diff --git a/Coding Practice/SSRF-Prevention.md b/Coding Practice/SSRF-Prevention.md
index 8345624..91f48e6 100644
--- a/Coding Practice/SSRF-Prevention.md	
+++ b/Coding Practice/SSRF-Prevention.md	
@@ -47,12 +47,12 @@ APIPA Address Range:
 
 **Golang Example**
 
-```
+```go
 func validateIPs(ips []net.IP) (bool, error) {
   if len(ips) == 0 {
     return false, errors.New("IP not found")
   }
- 
+
   for _, ip := range ips {
     if ip.To16() == nil && ip.To4() == nil {
       log.Errorf("IP: %v is not valid", ip)
@@ -75,7 +75,7 @@ func validateIPs(ips []net.IP) (bool, error) {
       return false, errors.New("IP address is a link-local unicast address")
     }
   }
- 
+
   return true, nil
 }
 
@@ -83,33 +83,33 @@ func validateIPs(ips []net.IP) (bool, error) {
 
 **Gitlab's Ruby Code Example**
 
-```
+```ruby
 # Source: https://gitlab.com/gitlab-org/gitlab-foss/-/blob/eabd80f72f4f7d8e19b26526aa1f44c43d78e8b3/lib/gitlab/url_blocker.rb#L214-L240
 def validate_localhost(addrs_info)
     local_ips = ["::", "0.0.0.0"]
     local_ips.concat(Socket.ip_address_list.map(&:ip_address))
- 
+
     return if (local_ips & addrs_info.map(&:ip_address)).empty?
- 
+
     raise BlockedUrlError, "Requests to localhost are not allowed"
 end
- 
+
 def validate_loopback(addrs_info)
     return unless addrs_info.any? { |addr| addr.ipv4_loopback? || addr.ipv6_loopback? }
- 
+
     raise BlockedUrlError, "Requests to loopback addresses are not allowed"
 end
- 
+
 def validate_local_network(addrs_info)
     return unless addrs_info.any? { |addr| addr.ipv4_private? || addr.ipv6_sitelocal? || addr.ipv6_unique_local? }
- 
+
     raise BlockedUrlError, "Requests to the local network are not allowed"
 end
- 
+
 def validate_link_local(addrs_info)
     netmask = IPAddr.new('169.254.0.0/16')
     return unless addrs_info.any? { |addr| addr.ipv6_linklocal? || netmask.include?(addr.ip_address) }
- 
+
     raise BlockedUrlError, "Requests to the link local network are not allowed"
 end
 ```
@@ -134,30 +134,30 @@ to the following URL:
 
 > https://55.26.115.78/validate
 
-Simplified code example of how Gitlab validates a submitted URI and transforms it. The `protected_uri_with_hostname` returned is used by an HTTP client. 
+Simplified code example of how Gitlab validates a submitted URI and transforms it. The `protected_uri_with_hostname` returned is used by an HTTP client.
 
 **Gitlab's Ruby Code Example**
 
-```
+```ruby
 # Source: https://gitlab.com/gitlab-org/gitlab-foss/-/blob/eabd80f72f4f7d8e19b26526aa1f44c43d78e8b3/lib/gitlab/url_blocker.rb#L22
 require 'ipaddress'
- 
+
 # Expects Addressable::URI
 def validate_uri(uri)
     address_info = get_address_info(uri)
     ip_address = address_info.first&.ip_address
-    # Replace domain with resolved IP address    
+    # Replace domain with resolved IP address
     protected_uri_with_hostname = enforce_uri_hostname(ip_address, uri)
     protected_uri_with_hostname
 end
- 
+
 def enforce_uri_hostname(ip_address, uri)
     return [uri, nil] unless ip_address && ip_address != uri.hostname
     new_uri = uri.dup
     new_uri.hostname = ip_address
     [new_uri, uri.hostname]
 end
- 
+
 def get_address_info(uri)
     Addrinfo.getaddrinfo(uri.hostname, get_port(uri), nil, :STREAM).map do |addr|
         addr.ipv6_v4mapped? ? addr.ipv6_to_ipv4 : addr
@@ -170,11 +170,11 @@ rescue ArgumentError => error
 end
 ```
 
-This is effective, but you can run into issues if the destination web server is using virtual hosts. Without a domain to parse, the request will fail. 
+This is effective, but you can run into issues if the destination web server is using virtual hosts. Without a domain to parse, the request will fail.
 
 #### Option 2
 
-The second way to DNS Rebinding Attacks is to override the destination IP address in transport configuration of the HTTP Library. Changing it to the validated IP address from Step 1 will ensure the request goes to the validated destination. 
+The second way to DNS Rebinding Attacks is to override the destination IP address in transport configuration of the HTTP Library. Changing it to the validated IP address from Step 1 will ensure the request goes to the validated destination.
 
 **Golang Code Example**
 
@@ -184,7 +184,7 @@ func sendGetRequest(webIP, host, scheme, path) (string, error) {
         Timeout:   10 * time.Second,
         KeepAlive: 10 * time.Second,
     }
- 
+
     // provide a custom Transport.DialContext function
     // to force requests to use a specific destination IP address
     http.DefaultTransport.(*http.Transport).DialContext = func(ctx context.Context, network, addr string) (net.Conn, error) {
@@ -192,11 +192,11 @@ func sendGetRequest(webIP, host, scheme, path) (string, error) {
         if scheme == "https" {
             port = ":443"
         }
- 
+
         addr = webIP + port
         return dialer.DialContext(ctx, network, addr)
     }
- 
+
     webURL := scheme + "://" + host + path
     resp, err := http.Get(webURL)
     if err != nil {
@@ -216,7 +216,7 @@ var response = request.GetResponse();
 ## Resources
 
 * [PortSwigger SSRF Explanation and examples](https://portswigger.net/web-security/ssrf)
-* [OWASP SSRF Explanation](https://owasp.org/www-community/attacks/Server_Side_Request_Forgery) 
+* [OWASP SSRF Explanation](https://owasp.org/www-community/attacks/Server_Side_Request_Forgery)
 * [OWASP SSRF Prevention Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Server_Side_Request_Forgery_Prevention_Cheat_Sheet.html)
 * [SSRF + DNS Rebinding Example](https://www.youtube.com/watch?v=R5WB8h7hkrU) (Video)
 * [Gitlab SSRF + DNS Rebinding Fix](https://gitlab.com/gitlab-org/gitlab-foss/-/blob/eabd80f72f4f7d8e19b26526aa1f44c43d78e8b3/lib/gitlab/url_blocker.rb#L22)
\ No newline at end of file

From fb32ff7120b4ffa0de2db999797fb1bfc56e2795 Mon Sep 17 00:00:00 2001
From: Andrew Luke <andrewl@unity3d.com>
Date: Thu, 6 Jan 2022 14:02:17 -0800
Subject: [PATCH 51/54] Added youtube video link

---
 Coding Practice/SSRF-Prevention.md | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Coding Practice/SSRF-Prevention.md b/Coding Practice/SSRF-Prevention.md
index 91f48e6..4f9cf4e 100644
--- a/Coding Practice/SSRF-Prevention.md	
+++ b/Coding Practice/SSRF-Prevention.md	
@@ -120,6 +120,8 @@ If the URL submitted uses a domain name, you need to protect against DNS rebindi
 
 The video below explains how SSRF can be combined with DNS Rebinding to bypass IP checks.
 
+[![IMAGE ALT TEXT HERE](https://img.youtube.com/vi/R5WB8h7hkrU/0.jpg)](https://www.youtube.com/watch?v=R5WB8h7hkrU)
+
 There are a couple of ways prevent this.
 
 #### Option 1

From d456e29565dbe8df4ceaf54d7ede274a1db8474b Mon Sep 17 00:00:00 2001
From: Andrew Luke <andrewl@unity3d.com>
Date: Thu, 6 Jan 2022 14:08:00 -0800
Subject: [PATCH 52/54] testing collapsible code examples

---
 Coding Practice/SSRF-Prevention.md | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/Coding Practice/SSRF-Prevention.md b/Coding Practice/SSRF-Prevention.md
index 4f9cf4e..6a35d2a 100644
--- a/Coding Practice/SSRF-Prevention.md	
+++ b/Coding Practice/SSRF-Prevention.md	
@@ -47,6 +47,8 @@ APIPA Address Range:
 
 **Golang Example**
 
+<details>
+    <summary>Golang Example</summary>
 ```go
 func validateIPs(ips []net.IP) (bool, error) {
   if len(ips) == 0 {
@@ -80,7 +82,7 @@ func validateIPs(ips []net.IP) (bool, error) {
 }
 
 ```
-
+</details>
 **Gitlab's Ruby Code Example**
 
 ```ruby

From 610bcf485a0d7633cf660671508f53c6ebab29bd Mon Sep 17 00:00:00 2001
From: Andrew Luke <andrewl@unity3d.com>
Date: Thu, 6 Jan 2022 14:10:11 -0800
Subject: [PATCH 53/54] testing collapsible code examples

---
 Coding Practice/SSRF-Prevention.md | 60 +++++++++++++++---------------
 1 file changed, 31 insertions(+), 29 deletions(-)

diff --git a/Coding Practice/SSRF-Prevention.md b/Coding Practice/SSRF-Prevention.md
index 6a35d2a..3b78c90 100644
--- a/Coding Practice/SSRF-Prevention.md	
+++ b/Coding Practice/SSRF-Prevention.md	
@@ -49,40 +49,42 @@ APIPA Address Range:
 
 <details>
     <summary>Golang Example</summary>
-```go
-func validateIPs(ips []net.IP) (bool, error) {
-  if len(ips) == 0 {
-    return false, errors.New("IP not found")
-  }
-
-  for _, ip := range ips {
-    if ip.To16() == nil && ip.To4() == nil {
-      log.Errorf("IP: %v is not valid", ip)
-      return false, errors.New("IP is not valid")
-    }
-    // IsPrivate reports whether ip is a private address, according to
-    // RFC 1918 (IPv4 addresses) and RFC 4193 (IPv6 addresses).
-    if ip.IsPrivate() {
-      log.Errorf("IP address: %v is a private address", ip)
-      return false, errors.New("IP address is a private address")
+
+    ```go
+    func validateIPs(ips []net.IP) (bool, error) {
+    if len(ips) == 0 {
+        return false, errors.New("IP not found")
     }
-    // checks Local Address Range of 127.0.0.0 - 127.255.255.255
-    if ip.IsLoopback() {
-      log.Errorf("IP address: %v is a local address", ip)
-      return false, errors.New("IP address is a local address")
+    
+    for _, ip := range ips {
+        if ip.To16() == nil && ip.To4() == nil {
+        log.Errorf("IP: %v is not valid", ip)
+        return false, errors.New("IP is not valid")
+        }
+        // IsPrivate reports whether ip is a private address, according to
+        // RFC 1918 (IPv4 addresses) and RFC 4193 (IPv6 addresses).
+        if ip.IsPrivate() {
+        log.Errorf("IP address: %v is a private address", ip)
+        return false, errors.New("IP address is a private address")
+        }
+        // checks Local Address Range of 127.0.0.0 - 127.255.255.255
+        if ip.IsLoopback() {
+        log.Errorf("IP address: %v is a local address", ip)
+        return false, errors.New("IP address is a local address")
+        }
+        // checks APIPA Address Range of 169.254.0.0 - 169.254.255.255
+        if ip.IsLinkLocalUnicast() {
+        log.Errorf("IP address: %v is a link-local unicast address", ip)
+        return false, errors.New("IP address is a link-local unicast address")
+        }
     }
-    // checks APIPA Address Range of 169.254.0.0 - 169.254.255.255
-    if ip.IsLinkLocalUnicast() {
-      log.Errorf("IP address: %v is a link-local unicast address", ip)
-      return false, errors.New("IP address is a link-local unicast address")
+    
+    return true, nil
     }
-  }
-
-  return true, nil
-}
+    ```
 
-```
 </details>
+
 **Gitlab's Ruby Code Example**
 
 ```ruby

From e8246841722139e21dcae76da5ef63a0ff8bcaee Mon Sep 17 00:00:00 2001
From: Andrew Luke <Sw4mpf0x@users.noreply.github.com>
Date: Thu, 6 Jan 2022 14:22:29 -0800
Subject: [PATCH 54/54] Collapsed all code examples

---
 Coding Practice/SSRF-Prevention.md | 230 +++++++++++++++++++++++++----
 1 file changed, 203 insertions(+), 27 deletions(-)

diff --git a/Coding Practice/SSRF-Prevention.md b/Coding Practice/SSRF-Prevention.md
index 3b78c90..79fc247 100644
--- a/Coding Practice/SSRF-Prevention.md	
+++ b/Coding Practice/SSRF-Prevention.md	
@@ -45,17 +45,15 @@ APIPA Address Range:
 
 - 169.254.0.1 - 169.254.255.254
 
-**Golang Example**
-
 <details>
-    <summary>Golang Example</summary>
-
-    ```go
-    func validateIPs(ips []net.IP) (bool, error) {
+  <summary>Golang Example</summary>
+  
+  ```go
+func validateIPs(ips []net.IP) (bool, error) {
     if len(ips) == 0 {
         return false, errors.New("IP not found")
     }
-    
+
     for _, ip := range ips {
         if ip.To16() == nil && ip.To4() == nil {
         log.Errorf("IP: %v is not valid", ip)
@@ -78,16 +76,16 @@ APIPA Address Range:
         return false, errors.New("IP address is a link-local unicast address")
         }
     }
-    
+
     return true, nil
     }
-    ```
-
+  ```
 </details>
 
-**Gitlab's Ruby Code Example**
-
-```ruby
+<details>
+  <summary>Gitlab's Ruby Example</summary>
+  
+  ```ruby
 # Source: https://gitlab.com/gitlab-org/gitlab-foss/-/blob/eabd80f72f4f7d8e19b26526aa1f44c43d78e8b3/lib/gitlab/url_blocker.rb#L214-L240
 def validate_localhost(addrs_info)
     local_ips = ["::", "0.0.0.0"]
@@ -116,7 +114,8 @@ def validate_link_local(addrs_info)
 
     raise BlockedUrlError, "Requests to the link local network are not allowed"
 end
-```
+  ```
+</details>
 
 ### Step 2. Prevent secondary name resolution
 
@@ -142,9 +141,10 @@ to the following URL:
 
 Simplified code example of how Gitlab validates a submitted URI and transforms it. The `protected_uri_with_hostname` returned is used by an HTTP client.
 
-**Gitlab's Ruby Code Example**
-
-```ruby
+<details>
+  <summary>Gitlab's Ruby Example</summary>
+  
+  ```ruby
 # Source: https://gitlab.com/gitlab-org/gitlab-foss/-/blob/eabd80f72f4f7d8e19b26526aa1f44c43d78e8b3/lib/gitlab/url_blocker.rb#L22
 require 'ipaddress'
 
@@ -174,7 +174,10 @@ rescue ArgumentError => error
     raise unless error.message.include?('hostname too long')
     raise BlockedUrlError, "Host is too long (maximum is 1024 characters)"
 end
-```
+  ```
+</details>
+
+
 
 This is effective, but you can run into issues if the destination web server is using virtual hosts. Without a domain to parse, the request will fail.
 
@@ -182,9 +185,10 @@ This is effective, but you can run into issues if the destination web server is
 
 The second way to DNS Rebinding Attacks is to override the destination IP address in transport configuration of the HTTP Library. Changing it to the validated IP address from Step 1 will ensure the request goes to the validated destination.
 
-**Golang Code Example**
-
-```go
+<details>
+  <summary>Golang Example</summary>
+  
+  ```go
 func sendGetRequest(webIP, host, scheme, path) (string, error) {
     dialer := &net.Dialer{
         Timeout:   10 * time.Second,
@@ -209,15 +213,187 @@ func sendGetRequest(webIP, host, scheme, path) (string, error) {
         return "", fmt.Errorf("error when doing a GET request to publisher webURL [%s]: %v", webURL, err)
     }
 }
-```
-
-**C# .NET Example**
+  ```
+</details>
 
-```c#
+<details>
+  <summary>C# .NET Example</summary>
+  
+  ```c#
 HttpWebRequest request = (HttpWebRequest)WebRequest.Create("https://1.2.3.4");
 request.Host = "www.example.com";
 var response = request.GetResponse();
-```
+  ```
+</details>
+
+## Full Code Examples
+
+<details>
+  <summary>Golang Example</summary>
+  
+  ```go
+func executeWebhook(webUrl string) {
+    u, err := url.Parse(webUrl)
+    if err != nil {
+        log.Errorf("error at parse url %v, err: %v", webUrl, err)
+    } else {
+        host := u.Hostname()
+        ip, err := getIPAdress(host)
+        if err == nil {
+          res = h.sendGetRequest(ip.String(), host, u.Scheme, u.Path, 'WebHook')
+        }
+    }
+}
+ 
+// getIPAdress returns IP address from domain name if IP address is not in a restricted range
+func getIPAdress(host string) (net.IP, error) {
+  ips, err := net.LookupIP(host)
+  if err != nil {
+    log.Errorf("Error at IP lookUP: %v, err: %v", host, err)
+    return nil, err
+  }
+ 
+  if valid, err := validateIPs(ips); !valid {
+    return nil, err
+  }
+ 
+  return findIpv4(ips)
+}
+ 
+func validateIPs(ips []net.IP) (bool, error) {
+  if len(ips) == 0 {
+    return false, errors.New("IP not found")
+  }
+ 
+  for _, ip := range ips {
+    if ip.To16() == nil && ip.To4() == nil {
+      log.Errorf("IP: %v is not valid", ip)
+      return false, errors.New("IP is not valid")
+    }
+    // IsPrivate reports whether ip is a private address, according to
+    // RFC 1918 (IPv4 addresses) and RFC 4193 (IPv6 addresses).
+    if ip.IsPrivate() {
+      log.Errorf("IP address: %v is a private address", ip)
+      return false, errors.New("IP address is a private address")
+    }
+    // checks Local Address Range of 127.0.0.0 - 127.255.255.255
+    if ip.IsLoopback() {
+      log.Errorf("IP address: %v is a local address", ip)
+      return false, errors.New("IP address is a local address")
+    }
+    // checks APIPA Address Range of 169.254.0.0 - 169.254.255.255
+    if ip.IsLinkLocalUnicast() {
+      log.Errorf("IP address: %v is a link-local unicast address", ip)
+      return false, errors.New("IP address is a link-local unicast address")
+    }
+  }
+ 
+  return true, nil
+}
+ 
+// findIpv4 returns the first Ipv4 out of ips
+func findIpv4(ips []net.IP) (net.IP, error) {
+  for _, ip := range ips {
+    if ipv4 := ip.To4(); ipv4 != nil {
+      return ipv4, nil
+    }
+  }
+  return nil, errors.New("no IPv4 found")
+}
+ 
+func sendGetRequest(webIP, host, scheme, path) (string, error) {
+    dialer := &net.Dialer{
+        Timeout:   10 * time.Second,
+        KeepAlive: 10 * time.Second,
+    }
+ 
+    // provide a custom Transport.DialContext function
+    // to force requests to use a specific destination IP address
+    http.DefaultTransport.(*http.Transport).DialContext = func(ctx context.Context, network, addr string) (net.Conn, error) {
+        port := ":80"
+        if scheme == "https" {
+            port = ":443"
+        }
+ 
+        addr = webIP + port
+        return dialer.DialContext(ctx, network, addr)
+    }
+ 
+    webURL := scheme + "://" + host + path
+    resp, err := http.Get(webURL)
+    if err != nil {
+        return "", fmt.Errorf("error when doing a GET request to publisher webURL [%s]: %v", webURL, err)
+    }
+}
+  ```
+</details>
+
+<details>
+  <summary>Gitlab's Ruby Example</summary>
+  
+  ```ruby
+# Source: https://gitlab.com/gitlab-org/gitlab-foss/-/blob/eabd80f72f4f7d8e19b26526aa1f44c43d78e8b3/lib/gitlab/url_blocker.rb
+require 'ipaddress'
+ 
+# Expects Addressable::URI
+def validate_uri(uri)
+    address_info = get_address_info(uri)
+    ip_address = address_info.first&.ip_address
+    # Replace domain with resolved IP address    
+    protected_uri_with_hostname = enforce_uri_hostname(ip_address, uri)
+    # Verify that the resolved IP address is not localhost, loopback, private, or link local
+    validate_localhost(address_info)
+    validate_loopback(address_info)
+    validate_local_network(address_info)
+    validate_link_local(address_info)
+    protected_uri_with_hostname
+end  
+ 
+def validate_localhost(addrs_info)
+    local_ips = ["::", "0.0.0.0"]
+    local_ips.concat(Socket.ip_address_list.map(&:ip_address))
+ 
+    return if (local_ips & addrs_info.map(&:ip_address)).empty?
+ 
+    raise BlockedUrlError, "Requests to localhost are not allowed"
+end
+ 
+def validate_loopback(addrs_info)
+    return unless addrs_info.any? { |addr| addr.ipv4_loopback? || addr.ipv6_loopback? }
+ 
+    raise BlockedUrlError, "Requests to loopback addresses are not allowed"
+end
+ 
+def validate_local_network(addrs_info)
+    return unless addrs_info.any? { |addr| addr.ipv4_private? || addr.ipv6_sitelocal? || addr.ipv6_unique_local? }
+ 
+    raise BlockedUrlError, "Requests to the local network are not allowed"
+end
+ 
+def validate_link_local(addrs_info)
+    netmask = IPAddr.new('169.254.0.0/16')
+    return unless addrs_info.any? { |addr| addr.ipv6_linklocal? || netmask.include?(addr.ip_address) }
+ 
+    raise BlockedUrlError, "Requests to the link local network are not allowed"
+end  def enforce_uri_hostname(ip_address, uri)
+    return [uri, nil] unless ip_address && ip_address != uri.hostname
+    new_uri = uri.dup
+    new_uri.hostname = ip_address
+    [new_uri, uri.hostname]
+end
+ 
+def get_address_info(uri)
+    Addrinfo.getaddrinfo(uri.hostname, get_port(uri), nil, :STREAM).map do |addr|
+        addr.ipv6_v4mapped? ? addr.ipv6_to_ipv4 : addr
+    end
+rescue SocketError
+    raise BlockedUrlError, "Host cannot be resolved or invalid"
+rescue ArgumentError => error
+    raise unless error.message.include?('hostname too long')
+    raise BlockedUrlError, "Host is too long (maximum is 1024 characters)"
+end
+  ```
+</details>
 
 ## Resources
 
@@ -225,4 +401,4 @@ var response = request.GetResponse();
 * [OWASP SSRF Explanation](https://owasp.org/www-community/attacks/Server_Side_Request_Forgery)
 * [OWASP SSRF Prevention Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Server_Side_Request_Forgery_Prevention_Cheat_Sheet.html)
 * [SSRF + DNS Rebinding Example](https://www.youtube.com/watch?v=R5WB8h7hkrU) (Video)
-* [Gitlab SSRF + DNS Rebinding Fix](https://gitlab.com/gitlab-org/gitlab-foss/-/blob/eabd80f72f4f7d8e19b26526aa1f44c43d78e8b3/lib/gitlab/url_blocker.rb#L22)
\ No newline at end of file
+* [Gitlab SSRF + DNS Rebinding Fix](https://gitlab.com/gitlab-org/gitlab-foss/-/blob/eabd80f72f4f7d8e19b26526aa1f44c43d78e8b3/lib/gitlab/url_blocker.rb#L22)
