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/Coding Practice/Cryptographic-Guidelines.md b/Coding Practice/Cryptographic-Guidelines.md
index e18f498..c7cd2c8 100644
--- a/Coding Practice/Cryptographic-Guidelines.md	
+++ b/Coding Practice/Cryptographic-Guidelines.md	
@@ -1,35 +1,25 @@
 # Cryptographic Guidelines [Coding Practice]
+
 <font size="-1">*Brandon Caldwell Jan 2019*</font>
 
-## Guidelines Overview
+## 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))_
+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.
 
-> NOTE: Where possible, we recommend Elliptic Curve Cryptography (ECC / ECDH), with Curve25519 (for signatures and key exchange)
+- [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)
 
-### Usage Recommendations
-##### TLS - Cipher Suites
+## Recommendations
 
-_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.
-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_RSA_WITH_AES_128_GCM_SHA256
-- TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
-- TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
+### Store the Cryptographic Hash of a Password
 
-##### Hash Algorithms
+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:
 
 - Language Agnostic
   - SHA-512
@@ -46,15 +36,129 @@ 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 [COMPANY_NAME] Governance and Compliance team or the [COMPANY_NAME] 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.
+
+### Use Secure Random Number Generators
+
+#### 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
\ 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
+
+### Contributors
+
+* Jose Perez - Mar. 2020
+* Andrew Luke - December 2021
\ No newline at end of file
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
diff --git a/Coding Practice/SSRF-Prevention.md b/Coding Practice/SSRF-Prevention.md
new file mode 100644
index 0000000..79fc247
--- /dev/null
+++ b/Coding Practice/SSRF-Prevention.md	
@@ -0,0 +1,404 @@
+# 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
+
+<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")
+        }
+        // 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
+    }
+  ```
+</details>
+
+<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"]
+    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
+  ```
+</details>
+
+### 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.
+
+[![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
+
+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.
+
+<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'
+
+# 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
+  ```
+</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.
+
+#### 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.
+
+<details>
+  <summary>Golang Example</summary>
+  
+  ```go
+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>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
+
+* [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)
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
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.
 
diff --git a/Language Best Practices/Net-C#-Best-Practices.md b/Language Best Practices/Net-CSharp-Best-Practices.md
similarity index 95%
rename from Language Best Practices/Net-C#-Best-Practices.md
rename to Language Best Practices/Net-CSharp-Best-Practices.md
index 921088d..b527392 100644
--- a/Language Best Practices/Net-C#-Best-Practices.md	
+++ b/Language Best Practices/Net-CSharp-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.
diff --git a/Overview.md b/Overview.md
index 863ef99..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)
@@ -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)
@@ -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)
diff --git a/README.md b/README.md
index 8c5ff47..52d2b6e 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.
@@ -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
 
diff --git a/Security Process/Bug-Bar.md b/Security Process/Bug-Bar.md
index e91cd2a..53bcd11 100644
--- a/Security Process/Bug-Bar.md	
+++ b/Security Process/Bug-Bar.md	
@@ -12,20 +12,20 @@ This outlines a standard rating scale for software security issues both internal
 <th>Example Bugs</th>
 
 <th>Reasoning</th>
-<tr style="background-color:#888888">
+<tr>
 <td>Critical</td>
 <td>
 - Internet accessible RCE
 
 - Internet accessible SQL injection
 
-- Stealing resources from customer web services
+- Stealing customer’s code from our web services (collaborate, etc..)
 
-- RCE in a desktop app with no user interaction
+- RCE in the Unity Editor with no user interaction
 
 XSS in an Asset Store page
 
-Exploit in a web/cloudservice with an open port
+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.
@@ -39,7 +39,7 @@ Issues of this severity have either been found to be actively exploited or publi
 
 - Code execution with little user interaction
 
-Clicking a link in a browser opens desktop app and runs a script
+Clicking a link in a browser opens Unity Editor and runs a script
 
 - Remote DoS (Persistent)
 
@@ -54,7 +54,6 @@ _References:_
 - [Secrets (& Credential) Management](../Coding%20Practice/Secrets-Management.md)
 </td>
 </tr>
-<tr style="background-color:#888888">
 <td>
 Medium
 </td>
@@ -65,6 +64,7 @@ Medium
 
 - 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.
@@ -104,43 +104,46 @@ These issues are usually defense-in-depth issues. They don’t lead to actively
 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.
+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                    | 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                | 
\ No newline at end of file
+
+<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>
+
+
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.
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
