V2

config.toml

@@ -1,17 +1,19 @@
 baseURL = "https://devopsctl.com/"
 languageCode = "en-us"
-title = "DevOps Control Framework"
+title = "Kosli's Software Development Lifecycle"
+theme = "hugo-book"
 
 [taxonomies]
   risk = 'risks'
-  level = 'levels'
+  area = 'areas'
 
 [params]
-  company = 'AcmePay'
-  csor = 'a compliance system of record'
+  company = 'Kosli'
+  csor = 'Kosli'
   vcs = 'git'
+  gitProvider = 'github'
   vcsHost = 'github'
-  forkLink = 'https://github.com/kosli-dev/devopsctl/fork'
+  repoLink = 'https://github.com/kosli-dev/kosli-sdlc'
   logo = 'svg/logo.svg'
   BookSection = '/'
 
@@ -21,4 +23,4 @@ title = "DevOps Control Framework"
 
 [markup.tableOfContents]
   startLevel = 2
-  endLevel = 3
+  endLevel = 3

content/_index.md

@@ -1,45 +1,8 @@
 ---
 weight: 1
 title: Introduction
-bookToC: true
+bookToC: false
 ---
 
-{{< figure src="/images/hero-home.svg" alt="Devops Control Framework">}}
-# The DevOps Control Framework
-
-{{< columns >}}
-{{< figure src="/images/devops-values.svg" alt="DevOps Values" >}}
-## DevOps Values
-
-The DevOps Control Framework is a defined secure software development process
-with **DevOps Culture** at it's heart.
-
-<--->
-{{< figure src="/images/continuous-compliance.svg" alt="Continuous Compliance" >}}
-## Continuous Compliance
-
-This is the distillation of the real processes in use by leading regulated
-institutions to deliver **compliant, secure, and audit-ready software**.
-
-{{< /columns >}}
-
-
-
-## Overview
-
-The purpose of a Secure Software Development Lifecycle (SSDLC) is to provide a
-defined, repeatable way of working that manages IT risks associated with
-software development.  It is a governance framework which forms a _definition_
-of how things should be done, which should be adhered to in _implementation_,
-which produces _proof_ of conformance.
-
-{{< figure src="/images/governance.svg" alt="Governance Framework" >}}
-
-## Scope
-
-The scope of this framework is to secure the entire value stream of software
-development.
-{{< figure src="/images/governance-scope.svg" alt="Secure Value Stream" >}}
-
-
 
+{{< map >}}

content/areas/build/_index.md

@@ -0,0 +1,5 @@
+---
+title: Secure Builds
+wikipedia: https://en.wikipedia.org/wiki/Bruce_Willis
+weight: 100
+---

content/areas/change/_index.md

@@ -0,0 +1,5 @@
+---
+title: Secure Changes
+wikipedia: https://en.wikipedia.org/wiki/Bruce_Willis
+weight: 300
+---

content/areas/process/_index.md

@@ -0,0 +1,5 @@
+---
+title: Secure Processes
+wikipedia: https://en.wikipedia.org/wiki/Bruce_Willis
+weight: 200
+---

content/background/_index.md

@@ -4,3 +4,42 @@ bookCollapseSection: true
 weight: 5
 title: Background
 ---
+{{< figure src="/images/hero-home.svg" alt="Devops Control Framework">}}
+# Kosli's Software Delivery Lifecycle
+
+{{< columns >}}
+{{< figure src="/images/devops-values.svg" alt="DevOps Values" >}}
+## DevOps Values
+
+This is a defined secure software development process
+with **DevOps Culture** at it's heart.
+
+<--->
+{{< figure src="/images/continuous-compliance.svg" alt="Continuous Compliance" >}}
+## Continuous Compliance
+
+This is the distillation of the real processes in use by leading regulated
+institutions to deliver **compliant, secure, and audit-ready software**.
+
+{{< /columns >}}
+
+
+
+## Overview
+
+The purpose of this Secure Software Development Lifecycle (SSDLC) is to provide a
+defined, repeatable way of working that manages Kosli's risks associated with
+software development.  It is a governance framework which forms a _definition_
+of how things should be done, which should be adhered to in _implementation_,
+which produces _proof_ of conformance.
+
+{{< figure src="/images/governance.svg" alt="Governance Framework" >}}
+
+## Scope
+
+The scope of this framework is to secure the entire value stream of our software
+development.
+{{< figure src="/images/governance-scope.svg" alt="Secure Value Stream" >}}
+
+
+

content/background/why.md

@@ -1,6 +1,6 @@
 ---
 weight: 10
-title: Why do you need a process?
+title: Why do we need a process?
 ---
 # Why does {{% param "company"  %}} need a software process?
 

content/process/_index.md

@@ -19,4 +19,5 @@ The DevSecOps Framework provides:
 * A holistic view of managing insider threat
 * A clear roadmap for a security-based devops implementation
 
-{{< /columns >}}
+{{< /columns >}}
+

content/process/ssdlc/build/_index.md → content/process/build/_index.md

@@ -1,6 +1,6 @@
 ---
 weight: 10
-title: Secure Build
+title: Secure Builds
 bookCollapseSection: false
 bookFlatSection: true
 ---

content/process/ssdlc/build/binary_provenance.md → content/process/build/binary_provenance.md

@@ -1,7 +1,9 @@
 ---
 title: Artifact Binary Provenance
 weight: 1
-tldr: Every software running production has known provenance
+areas: 
+ - build
+tldr: Every software running in a production system has known provenance
 rationale: High security environment require a tamper-proof identity scheme. The use of Content Addressable Storage mechanisms ensures that if software changes it will have a different identity.
 risks:
  - supply-chain
@@ -15,7 +17,7 @@ level: 1
 ## Background
 To define software identity, you use the cryptographic hash of the software itself. We use the SHA256 digest of the sofware binary.
 
-This means that if a single byte in the software changes it will have a different identity.
+This means that if a single byte in the software changes it will have a different identity.  This ensures we can't qualify one software artifact and deploy a different one.  It also allows us to create a provable chain of custody from commit to build to production.
 
 {{< figure src="/images/binary-provenance.svg" alt="Binary Provenance" >}}
 
@@ -35,4 +37,8 @@ It can be helpful to use human-friendly identites in CI displays, filenames, and
 
 These are very useful ways for humans to navigate identity through version control and CI systems. However, since they are fallible, they cannot be used to identify software in the security and compliance areas.
 
-Use labels for humans and SHAs for machines.
+Use labels for humans and SHAs for machines.
+
+## How we implement this control
+
+We use Kosli to record every official build in our CI system.  The audit trails for our binary provenance can be found here: https://app.kosli.com/kosli/flows/

content/process/ssdlc/build/dependencies.md → content/process/build/dependencies.md

@@ -1,6 +1,8 @@
 ---
 title: Dependency Management
 weight: 20
+areas: 
+ - build
 tldr: Every dependency is defined securely, managed, and auditable
 rationale: Inputs to the build process can introduce security and quality issues, and as such must be defined, controlled, and transparent as part of the software development lifecycle.
 level: 1
@@ -11,8 +13,6 @@ level: 1
 
 ## Background
 
-
-
 Key points:
 
 * You must have control over what dependencies are packaged in your software
@@ -27,5 +27,14 @@ source code.
 
 During build, these inputs to the build package can be recorded as the software
 bill-of-materials while recording
-[binary provenance]({{< relref "/process/ssdlc/build/binary_provenance" >}})
+[binary provenance]({{< relref "/process/build/binary_provenance" >}})
+
+## How we implement this control
+
+We define these dependencies in the source code, at the application level and if relevent, at the Docker image level.
 
+| Application | Dependencies |
+| ----------- | ------------ |
+| CLI | [Golang Dependencies](https://github.com/kosli-dev/cli/blob/main/go.mod) |
+| Server | [Python Dependencies](https://github.com/kosli-dev/server/blob/master/src/requirements.txt) <br/> [Docker Dependencies](https://github.com/kosli-dev/server/blob/master/Dockerfile) |
+| Slack Application | [Python Dependencies](https://github.com/kosli-dev/slack-auth-app/blob/main/src/requirements.txt) <br/> [Docker Dependencies](https://github.com/kosli-dev/slack-auth-app/blob/main/Dockerfile) |

content/process/build/infrastructure_and_config_management.md

@@ -0,0 +1,21 @@
+---
+title: Infrastructure and Configuration Management
+level: 1
+weight: 50
+tldr: Infrastructure and Configurations are defined "as code" and applied through automation
+rationale: Software defined cloud infrastructure allows auditability, reproducibility and drift detection
+areas: 
+ - build
+---
+
+# {{% param "title" %}}
+{{< area_head >}}
+
+## Background
+Infrastructure setup, configuration and evolution must be auditable, secure and reproducible.  To ensure this we define our cloud environments as code and use automation tools to automatically roll out changes.
+
+## How we implement this control
+
+* To ensure this we define all our production and test infrastructure using code.  Changes are rolled out via CI pipelines in {{% param "gitProvider"  %}}
+* We use the appropriate for the type and level of the change  (e.g. Terraform for infrastructure, Docker for application Runtimes)
+* All documentation around our infrastructure, security approaches and automation is maintained and up-to-date in our [Knowledge Base](https://github.com/kosli-dev/knowledge-base)

content/process/ssdlc/build/toolchain.md → content/process/build/toolchain.md

@@ -2,6 +2,8 @@
 title: Defined Toolchain
 level: 3
 weight: 20
+areas: 
+ - build
 tldr: Build environments must be defined securely and auditable
 rationale: A secure build environment is the foundation for a mitigating software supply chain attacks.  Build environments defined as code protect against interference that can happen in the build and distribution processes.
 ---
@@ -21,3 +23,8 @@ version control.
 You can learn more about build security levels defined in the [slsa specification](https://slsa.dev/spec/v0.1/requirements#scripted-build).
 {{< /hint >}}
 
+## How we implement this control
+
+* Our officical builds occur in Github pipelines defined as code
+* Each step runs in an immutable container
+* Each build fingerprint is stored using [Binary Provenance]({{< ref "binary_provenance.md" >}})

content/process/ssdlc/build/versioncontrol.md → content/process/build/versioncontrol.md

@@ -2,6 +2,8 @@
 title: Version Control
 weight: 1
 level: 1
+areas: 
+ - build
 tldr: Every change to the source is tracked in a version control system
 rationale: Version control allows us to track and manage changes to our software code.  As a traceability system, it provides a means to understand how our software changes, who changes it, and why it was changed.
 ---
@@ -11,6 +13,9 @@ rationale: Version control allows us to track and manage changes to our software
 ## Background
 We use {{< param "vcs"  >}} to manage versioning for software development source code.  For repository hosting and user management we use {{< param "vcsHost"  >}}.
 
+## How we implement this control
+
+Our git repositories can be found here: https://github.com/kosli-dev
 
 ## Branching Strategies
 
@@ -29,7 +34,7 @@ This branching strategy uses a combination of feature branches with pull request
 
 * Main branch is protected
 * Pull requests must be approved before merge to the main branch.
-* We use pull requests to enforce and document our code review process.  You can read more about it here: [Code Review Process]({{< relref "/process/ssdlc/process/code_review" >}})
+* We use pull requests to enforce and document our code review process.  You can read more about it here: [Code Review Process]({{< relref "/process/process/code_review" >}})
 * Pull request merges should create merge or squash commits. (no fast-forward)
 
 

content/process/ssdlc/runtime/_index.md → content/process/change/_index.md

@@ -1,6 +1,6 @@
 ---
 weight: 30
-title: Secure Runtime
+title: Secure Changes
 bookCollapseSection: false
 bookFlatSection: true
 ---

content/process/ssdlc/runtime/change_records.md → content/process/change/change_records.md

@@ -4,6 +4,8 @@ level: 1
 weight: 10
 tldr: All systems and services maintain a record of changes
 rationale: To meet our change management requirements, all changes to production systems are recorded permanently
+areas: 
+ - change
 ---
 
 # {{% param "title" %}}
@@ -13,4 +15,9 @@ rationale: To meet our change management requirements, all changes to production
 
 The deployment steps in our pipelines automatically log all deployments, and we can also control that we only deploy software that is approved in the {{% param "csor"  %}} audit trail.
 
-{{< figure src="/images/change-records.svg" alt="Change records" >}}
+{{< figure src="/images/change-records.svg" alt="Change records" >}}
+
+## How we implement this control
+
+* We monitor production systems and automatically record a forensic history of all changes in Kosli using [environment monitoring](https://docs.kosli.com/getting_started/environments/)
+    * Environment records can be found here: https://app.kosli.com/kosli/environments/

content/process/ssdlc/runtime/deployment_controls.md → content/process/change/deployment_controls.md

@@ -4,6 +4,8 @@ level: 1
 weight: 20
 tldr: Deployments controls are enforced in the pipeline and environments
 rationale: Ensuring only compliant, approved software deployments are made to production
+areas: 
+ - change
 ---
 # {{% param "title" %}}
 {{< area_head >}}
@@ -12,7 +14,12 @@ rationale: Ensuring only compliant, approved software deployments are made to pr
 
 We use deployment controls to automatically ensure we only deploy software that
 has gone through our Software Development Lifecycle.  This can be implemented as
-a gate in the pipeline, or as an admission control in the environment (ideally
+a gate in the pipeline, or as an admission controller in the environment (ideally
 both).
 
 {{< figure src="/images/deployment-controls.svg" alt="Deployment Controls" >}}
+
+## How we implement this control
+
+* We use [Kosli's assert artifact command](https://docs.kosli.com/client_reference/kosli_assert_artifact/) prior to deployment
+* We use [Kosli's environment monitoring]({{< ref "workload_monitoring.md" >}}) to alert on non-compliant workloads

content/process/ssdlc/runtime/secrets_managment.md → content/process/change/secrets_managment.md

@@ -5,6 +5,8 @@ weight: 30
 tldr: Build and runtime secrets are stored securely and documented appropriately
 rationale: Leaked secrets such as api keys, cryptography keys, identity tokens
   are a common attack scenario.
+areas: 
+ - change
 ---
 # {{% param "title" %}}
 {{< area_head >}}
@@ -14,4 +16,10 @@ rationale: Leaked secrets such as api keys, cryptography keys, identity tokens
 Secrets must be stored in a secure way, and a documented in a central place.
 [Cryptographic failures are the second highest risk in the OWASP top ten](https://owasp.org/Top10/A02_2021-Cryptographic_Failures/) so rigor and process is essential.
 
-{{< figure src="/images/secrets-management.svg" alt="Change Records" >}}
+{{< figure src="/images/secrets-management.svg" alt="Change Records" >}}
+
+## How we implement this control
+
+* We use AWS secrets manager to store infrastructure secrets
+* Secrets are provisioned in our terraform model ([instructions here](https://github.com/kosli-dev/knowledge-base/blob/master/add_secrets.md))
+* Secrets are entered via the AWS cloud console by the authorized team members