2 changed files with 192 additions and 46 deletions
--- a/coding-standards.md
+++ b/coding-standards.md
@ -1,46 +0,0 @@
 # Coding Standards
 These are our opinionated code security and quality standards we use internally at Distrust, and expect from all contractors and vendors.
 ## General Guidelines
 ## First party Code
  TBD
 ## Third Party Code
 Use the following rationale as guidelines to decide when and how to use third party dependencies
 ```mermaid
 flowchart TD
    A[Can it be done with the standard Library in under ~10k easily readable lines?]
    A --> D{No} --> E
    A --> B{Yes} --> C
    E[Can it be done with a library used in the official interpreter or compiler?]
    E --> F{Yes} --> X
    E --> G{No} --> I
    I[Does a widely used, well vetted, well reviewed, and well maintained library with exist?]
    I --> J{Yes} --> X
    I --> K{No} --> L
    L[Is this a cryptography or security sensitive use case?] 
    L --> M{No} --> O
    L --> N{Yes} --> P[Review by yourself and pay for reputable external security audit] --> X
    O[Does -any- suitible library exist small enough for you to review yourself?]
    O --> Q{No} --> C
    O --> R{Yes} --> S[Review by yourself and by a peer] --> X
    C[Write it yourself]
    X[Document rationale and use library at specific version we have reason to trust]
 ```
 ## Language Guidelines
 ### Rust
 TBD
--- a/engineering-standards.md
+++ b/engineering-standards.md
@ -0,0 +1,192 @@
 # Engineering Standards
 These are our opinionated engineering standards we use internally at Distrust,
 and expect from all contractors and vendors.
 ## Summary
 This process is recommended for any binaries, that if compromised, could result
 in a loss of funds exceeding $1,000,000, which is the rough level where
 incidents of violent coercion or deployments of expensive ($200k+ per Zerodium)
 "zero-day" exploits have been seen in our industry.
 It is reasonable to expect any privileged general-purpose OS kernels, tools,
 or binaries may, in some use cases, have access to memory that holds a high value
 secrets. This makes such binaries and those that maintain them significant
 targets for supply chain attacks by malicious adversaries, be it covert via a
 0day of overt via violence.
 It is also reasonable to expect that a binary that runs on multiple engineer
 workstations could have the power to deploy to production.
 This document seeks to largely mitigate all classes of supply chain attacks we
 have seen deployed in the wild with high accountability build and release
 processes and maintain a high standard of code quality and security.
 ## Motivation
 80% of software bugs are memory safety issues, which speaks to poor coding
 standards, and failure to use memory safe languages where possible.
 Also adversaries are demonstrating an increased willingness to resort to
 supply chain attacks to gain value from software systems.
 Examples:
 * [CI/CD system compromised by covert and sophisticated rootkit](https://igor-blue.github.io/2021/03/24/apt1.html)
 * [NPM supply chain attack on CoPay wallets](https://medium.com/@hkparker/analysis-of-a-supply-chain-attack-2bd8fa8286ac)
 * [Web analytics supply chain attack deployed on Gate.io exchange](https://www.welivesecurity.com/2018/11/06/supply-chain-attack-cryptocurrency-exchange-gate-io/)
 * [0day in Firefox used to attack Coinbase](https://www.zdnet.com/article/firefox-zero-day-was-used-in-attack-against-coinbase-employees-not-its-users/)
 * [Ruby Gem Supply chain attack to facilitate cryptoasset theft via clipboards](https://www.bleepingcomputer.com/news/security/malicious-rubygems-packages-used-in-cryptocurrency-supply-chain-attack/)
 Worse even than this, when such vectors are not readily viable, some are even
 willing to resort to physical violence just to get a signature from a
 the private key that can directly or indirectly control significant value.
 Examples:
 * [Physical Bitcoin Attacks](https://github.com/jlopp/physical-bitcoin-attacks/blob/master/README.md)
 * [Violent datacenter robbery with hostages](https://www.computerworld.com/article/2538534/data-center-robbery-leads-to-new-thinking-on-security.html)
 * [History of datacenter break-ins](https://www.hostdime.com/blog/server-room-security-colocation/)
 Given this, we should expect that humans in control of any single point of
 failure in a software ecosystem that controls a significant amount of
 value are placing themselves at substantial personal risk.
 To address this, we must avoid trusting any single human or any system they
 control by design in order to protect those individuals and downstream users.
 ## Threat Model
 * Every human will make coding mistakes
 * Any single human or computer involved in the supply chain is compromised
 * All systems managed by a single party (IT, third parties) are compromised
 * Any code or binaries controlled by one system or party are compromised
 * All memory of all internet-connected computers is visible to an adversary
 * Any logging or backups that are not signed are tampered with
 * Adversary wields a "zero-click" "Zero-Day" exploit for any system
 ## Requirements
 The following only applies if code is bound for production, and these can be
 met in any order or cadence desired.
 * Third-party code:
  * MUST have extensive and frequent reviews.
    * Example: The Linux kernel has well funded distributed review.
  * MUST be hash-pinned at known reviewed versions
  * MUST be at version with all known related security patches
  * SHOULD be latest versions if security disclosures lag behind releases
    * Example: The Linux kernel
 * First-party code:
  * MUST be signed in version control systems by well-known author keys
  * MUST be signed by a separate subject matter expert after a security review
 * All code MUST build deterministically
 * All binaries:
  * MUST be built and signed by multiple parties with no management overlay
    * Example: One build by IT, another by Infrastructure team managed CI/CD
  * MUST be signed by well-known keys signed by a common CA
    * Example: PGP Smartcards signed under OpenPGP-CA.
 * All signing keys:
  * MUST be stored in approved PERSONAL HSMs
  * MUST NOT ever come in contact with network-accessible memory
 * All execution environments SHOULD be able to verify m-of-n binary signatures
  * Example: Custom Secure Boot verifies minimum signatures against CA
 * Only code required for sensitive operation SHOULD be present
  * Example: A server has no need for sound card drivers
 ## Workflows
 ## Design
 Many implementations are possible under the above requirements and threat model
 however, the following opinionated workflows can be used as a reference when in
 doubt.
 ### Engineer Workflow
 Will vary significantly by project, but at a minimum:
 1. Engineer makes source code change
 2. Engineer builds and tests changes locally
 3. Engineer makes commit signed with PERSONAL HSM and pushes
 4. Submits code for peer review if multiple engineers are active in codebase
 ### Continuous Integration
 This is ideal, though not always present for all projects.
 1. Pulls code
 2. Verifies commit signature by key signed with hardcoded CA key
 3. Builds binaries
 4. Verifies binary hashes match hashes in signed commit
 5. Runs test suite
 6. Signs binary with a well-known key (ideally held in HSM)
 7. Publishes binary and signature to artifact storage
 8. Continuous Integration notifies project team of success/error of above steps
 ### Security Reviewer
 1. Reviews all code changes between release candidate and last commit
 2. Reviews all third-party changes and evidence they are appropriate
 3. Appends tag signed with PERSONAL HSM to release candidate commit reviewed
 ### Release Engineer
 1. Release engineer verifies:
    * Commit signature and security reviewer signature on commit are valid
    * The artifact corresponding to this commit is signed by the CI key
    * The artifact hash is in the release candidate commit
 2. Release engineer generates detached artifact signature with PERSONAL HSM
 3. Release engineer publishes detached signature to artifact store
 ## Guidelines
 ### Boilerplate
 All projects should have:
 - A README.md containing goals, requirements, and build/usage instructions
 - A Makefile configured such that 'make' will build the project
 - A Stagex Containerfile responsible for the building project deterministically
 ### Dependency Choices
 Use the following rationale guidelines to help decide when and how to use third party dependencies
 ```mermaid
 flowchart TD
    A[Can it be done with the standard Library in under ~10k easily readable lines?]
    A --> D{No} --> E
    A --> B{Yes} --> C
    E[Can it be done with a library used in the official interpreter or compiler?]
    E --> F{Yes} --> X
    E --> G{No} --> I
    I[Does a widely used, well vetted, well reviewed, and well maintained library with exist?]
    I --> J{Yes} --> X
    I --> K{No} --> L
    L[Is this a cryptography or security sensitive use case?] 
    L --> M{No} --> O
    L --> N{Yes} --> P[Review by yourself and pay for reputable external security audit] --> X
    O[Does -any- suitible library exist small enough for you to review yourself?]
    O --> Q{No} --> C
    O --> R{Yes} --> S[Review by yourself and by a peer] --> X
    C[Write it yourself]
    X[Document rationale and use library at specific version we have reason to trust]
 ```
 ## Language Guidelines
 ### Rust
 TBD
 ## Glossary
 ### MUST, MUST NOT, SHOULD, SHOULD NOT, MAY
 These keywords correspond to their IETF definitions per RFC2119