diff --git a/config.toml b/config.toml index fa60ecb..b6ec83b 100644 --- a/config.toml +++ b/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 \ No newline at end of file + endLevel = 3 diff --git a/content/_index.md b/content/_index.md index 5ee51e6..a6eafa4 100644 --- a/content/_index.md +++ b/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 >}} diff --git a/content/areas/build/_index.md b/content/areas/build/_index.md new file mode 100644 index 0000000..cca1f5f --- /dev/null +++ b/content/areas/build/_index.md @@ -0,0 +1,5 @@ +--- +title: Secure Builds +wikipedia: https://en.wikipedia.org/wiki/Bruce_Willis +weight: 100 +--- \ No newline at end of file diff --git a/content/areas/change/_index.md b/content/areas/change/_index.md new file mode 100644 index 0000000..fd90034 --- /dev/null +++ b/content/areas/change/_index.md @@ -0,0 +1,5 @@ +--- +title: Secure Changes +wikipedia: https://en.wikipedia.org/wiki/Bruce_Willis +weight: 300 +--- \ No newline at end of file diff --git a/content/areas/process/_index.md b/content/areas/process/_index.md new file mode 100644 index 0000000..df8e615 --- /dev/null +++ b/content/areas/process/_index.md @@ -0,0 +1,5 @@ +--- +title: Secure Processes +wikipedia: https://en.wikipedia.org/wiki/Bruce_Willis +weight: 200 +--- \ No newline at end of file diff --git a/content/background/_index.md b/content/background/_index.md index abeebf9..f82e02a 100644 --- a/content/background/_index.md +++ b/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" >}} + + + diff --git a/content/background/why.md b/content/background/why.md index 212905b..249c0ef 100644 --- a/content/background/why.md +++ b/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? diff --git a/content/process/_index.md b/content/process/_index.md index 06fbdd4..edab97a 100644 --- a/content/process/_index.md +++ b/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 >}} \ No newline at end of file +{{< /columns >}} + diff --git a/content/process/ssdlc/build/_index.md b/content/process/build/_index.md similarity index 76% rename from content/process/ssdlc/build/_index.md rename to content/process/build/_index.md index fc5de10..4c677cc 100644 --- a/content/process/ssdlc/build/_index.md +++ b/content/process/build/_index.md @@ -1,6 +1,6 @@ --- weight: 10 -title: Secure Build +title: Secure Builds bookCollapseSection: false bookFlatSection: true --- diff --git a/content/process/ssdlc/build/binary_provenance.md b/content/process/build/binary_provenance.md similarity index 71% rename from content/process/ssdlc/build/binary_provenance.md rename to content/process/build/binary_provenance.md index a31eb1b..b189904 100644 --- a/content/process/ssdlc/build/binary_provenance.md +++ b/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. \ No newline at end of file +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/ \ No newline at end of file diff --git a/content/process/ssdlc/build/dependencies.md b/content/process/build/dependencies.md similarity index 52% rename from content/process/ssdlc/build/dependencies.md rename to content/process/build/dependencies.md index a11a9f6..b5d5972 100644 --- a/content/process/ssdlc/build/dependencies.md +++ b/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)
[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)
[Docker Dependencies](https://github.com/kosli-dev/slack-auth-app/blob/main/Dockerfile) | \ No newline at end of file diff --git a/content/process/build/infrastructure_and_config_management.md b/content/process/build/infrastructure_and_config_management.md new file mode 100644 index 0000000..48dd48a --- /dev/null +++ b/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) \ No newline at end of file diff --git a/content/process/ssdlc/build/toolchain.md b/content/process/build/toolchain.md similarity index 79% rename from content/process/ssdlc/build/toolchain.md rename to content/process/build/toolchain.md index 1702697..f2e8a8b 100644 --- a/content/process/ssdlc/build/toolchain.md +++ b/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" >}}) \ No newline at end of file diff --git a/content/process/ssdlc/build/versioncontrol.md b/content/process/build/versioncontrol.md similarity index 93% rename from content/process/ssdlc/build/versioncontrol.md rename to content/process/build/versioncontrol.md index 392efe9..6d1f11c 100644 --- a/content/process/ssdlc/build/versioncontrol.md +++ b/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) diff --git a/content/process/ssdlc/runtime/_index.md b/content/process/change/_index.md similarity index 75% rename from content/process/ssdlc/runtime/_index.md rename to content/process/change/_index.md index 2dc2ee6..753c0cb 100644 --- a/content/process/ssdlc/runtime/_index.md +++ b/content/process/change/_index.md @@ -1,6 +1,6 @@ --- weight: 30 -title: Secure Runtime +title: Secure Changes bookCollapseSection: false bookFlatSection: true --- \ No newline at end of file diff --git a/content/process/ssdlc/runtime/change_records.md b/content/process/change/change_records.md similarity index 61% rename from content/process/ssdlc/runtime/change_records.md rename to content/process/change/change_records.md index 927800a..ebfb0b4 100644 --- a/content/process/ssdlc/runtime/change_records.md +++ b/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" >}} \ No newline at end of file +{{< 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/ diff --git a/content/process/ssdlc/runtime/deployment_controls.md b/content/process/change/deployment_controls.md similarity index 58% rename from content/process/ssdlc/runtime/deployment_controls.md rename to content/process/change/deployment_controls.md index abdb7c4..334c37b 100644 --- a/content/process/ssdlc/runtime/deployment_controls.md +++ b/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 \ No newline at end of file diff --git a/content/process/ssdlc/runtime/secrets_managment.md b/content/process/change/secrets_managment.md similarity index 64% rename from content/process/ssdlc/runtime/secrets_managment.md rename to content/process/change/secrets_managment.md index 6b591b7..ad1ba01 100644 --- a/content/process/ssdlc/runtime/secrets_managment.md +++ b/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" >}} \ No newline at end of file +{{< 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 \ No newline at end of file diff --git a/content/process/change/system_access.md b/content/process/change/system_access.md new file mode 100644 index 0000000..555822a --- /dev/null +++ b/content/process/change/system_access.md @@ -0,0 +1,28 @@ +--- +title: System Access Controls +level: 1 +weight: 50 +tldr: All access to runtime environments requires authentication and audit trails +rationale: To meet our system access control policy, all access must be approved and auditable +areas: + - change +--- + +# {{% param "title" %}} +{{< area_head >}} + +## Background + +As part of normal software development, it can be necessary to gain remote access to runtime environments. This can be for many reasons: + +* Debugging the runtime environment +* Running migration scripts +* Inspecting the behaviour of running systems + +This must be limited to authorized personnel and all activities performed should have full audit trails. + +## How we implement this control + +* Any remote shell session require SSO authentication and full adit trails are logged in Kosli here: https://app.kosli.com/kosli/audit-trails +* This forms part of our [System Access Control Policy](https://app.drata.com/policy-builder/18) +* All access audit trails are reviewed \ No newline at end of file diff --git a/content/process/change/workload_monitoring.md b/content/process/change/workload_monitoring.md new file mode 100644 index 0000000..a6c66ae --- /dev/null +++ b/content/process/change/workload_monitoring.md @@ -0,0 +1,27 @@ +--- +title: Runtime Workload Monitoring +level: 1 +weight: 50 +tldr: Workloads are monitored to alert if any non-compliant or unauthorized change is discovered +rationale: Real-time closed-loop compliance monitoring is a constant vigil against threats +areas: + - change +--- + +# {{% param "title" %}} +{{< area_head >}} + +## Background + +Ensuring that risks are controlled in the value stream is the first level of +software process compliance. Beyond this, it is important to have a monitoring +process in place to ensure that unknown or non-compliant workloads are identified +in production. + +{{< figure src="/images/workload-monitoring.svg" alt="Workload Monitoring" >}} + +## How we implement this control + +* A full forensic history of all container runtimes, lambda functions and s3 buckets are recorded using [Kosli environments](https://www.kosli.com/blog/kosli-a-flight-data-recorder-for-your-runtime-environments/) and can be found here: https://app.kosli.com/kosli/environments/ +* Unauthorized or non-compliant workloads are recorded and create alerts in our slack channels + diff --git a/content/process/exception_register.md b/content/process/exception_register.md index 7155495..7508410 100644 --- a/content/process/exception_register.md +++ b/content/process/exception_register.md @@ -1,5 +1,5 @@ --- -weight: 10 +weight: 40 bookFlatSection: false title: "Exception Register" --- diff --git a/content/process/levels.html b/content/process/levels.html deleted file mode 100644 index 139597f..0000000 --- a/content/process/levels.html +++ /dev/null @@ -1,2 +0,0 @@ - - diff --git a/content/process/ssdlc/process/_index.md b/content/process/process/_index.md similarity index 73% rename from content/process/ssdlc/process/_index.md rename to content/process/process/_index.md index 2957cf3..0744b6a 100644 --- a/content/process/ssdlc/process/_index.md +++ b/content/process/process/_index.md @@ -1,6 +1,6 @@ --- weight: 20 -title: Secure Process +title: Secure Processes bookCollapseSection: false bookFlatSection: true --- diff --git a/content/process/process/code_review.md b/content/process/process/code_review.md new file mode 100644 index 0000000..ffd5f9c --- /dev/null +++ b/content/process/process/code_review.md @@ -0,0 +1,49 @@ +--- +title: Code Review +weight: 10 +level: 1 +tldr: Code review is performed on all software changes to production +rationale: Peer review is an essential mitigation against insider threats, as well as a means of improving knowledge sharing and quality. +risks: insider_threat +areas: + - process +--- + +# {{% param "title" %}} +{{< area_head >}} + +## Background +We use pull requests to document code reviews. The pull request description should contain key information of +the change, as well as any relevant information. At a minimum, code reviews should be performed by someone +capable of understanding the change, and it’s associated risks. + +Important considerations we make before approving a Pull Request: + +- Security concerns: is this change secure? +- Quality: is this maintainable? +- Verification: Does this require manual testing? Has it been performed? + +{{< figure src="/images/feature-branch-pr.svg" alt="Feature Branch Strategy" >}} + +{{< hint warning >}} +### Code Review Anti-patterns + +A common anti-pattern when using pull requests is waiting for review. In an ideal situation, the lead time for +review should approach 0. If there is any delay on integration, it can lead to people batching larger and +larger changes. This causes larger pull requests, more delays, poorer code reviews, and ultimately more risks. + +To avoid this, we recommend pair- or ensemble-programming: a practice where more than one person works together +to complete tasks. This way, as soon as one developer creates the pull request, another person can sign +off immediately. + +Note: the reviewer should not be the person who pushes the last commit on the branch. + +{{< /hint >}} + + +## How we implement this control + +* We prefer real time reviews with pair or ensemble programming +* We use pull requests to document reviews in github +* We protect the `main` branch in each repository +* We record the pull requests in Kosli and control/monitor that no runtime workload is missing PR attestations diff --git a/content/process/ssdlc/process/deployment_approvals.md b/content/process/process/deployment_approvals.md similarity index 71% rename from content/process/ssdlc/process/deployment_approvals.md rename to content/process/process/deployment_approvals.md index a98c86e..0b38b09 100644 --- a/content/process/ssdlc/process/deployment_approvals.md +++ b/content/process/process/deployment_approvals.md @@ -4,6 +4,8 @@ level: 1 weight: 40 tldr: Deployments are approved rationale: To meet segregation of duties requirements, all deploymnents to production are approved by someone other than the person making the change +areas: + - process --- # {{% param "title" %}} @@ -11,7 +13,7 @@ rationale: To meet segregation of duties requirements, all deploymnents to produ ## Background -Segregations of duties is a common requirement in regulated or high security +Segregation of duties is a common requirement in regulated or high security development environment. Put plainly, it means that a developer cannot deploy their own changes without approval from someone who both: @@ -24,4 +26,11 @@ Deployment approval controls form a key role in the secure software development lifecycle. Its purpose is to ensure that risks around change are managed and that change is an active decisions. -In highly sensitive software systems, more than one approver may be required. \ No newline at end of file +In highly sensitive software systems, more than one approver may be required. + +## How we implement this control + +Deployment approvals are + +* We use git tags to trigger and record deployment approvals +* CI/CD pipelines generate attestations for [Kosli approvals](https://docs.kosli.com/getting_started/approvals/) \ No newline at end of file diff --git a/content/process/ssdlc/process/quality.md b/content/process/process/quality.md similarity index 53% rename from content/process/ssdlc/process/quality.md rename to content/process/process/quality.md index 5fcae9d..e4c2a1b 100644 --- a/content/process/ssdlc/process/quality.md +++ b/content/process/process/quality.md @@ -4,6 +4,8 @@ level: 1 weight: 20 tldr: Functionality of software is assured prior to production rationale: Every change has the potential to introduce regressions in functionality. By testing our software prior to deployment we manage the risk of production issues. +areas: + - process --- # {{% param "title" %}} @@ -23,3 +25,17 @@ The benefits of automated approaches to regression testing include: * Automated test results documentation {{< /hint >}} + +## How we implement this control + +For any software delivered to customers, or with potential to impact customer data, we will test all software prior to deployment/release. Our main testing method will favor automated tests, both on the unit and integration level. (As of this time, our server software has over 95% branch coverage). + +* We perform automated testing as part of our CI/CD pipelines +* We record the automated test results against the code and artifacts in our [Kosli Flows](https://app.kosli.com/kosli/flows/) +* We control that tests are passing and test results are stored prior to deployment + +In addition, we can perform these controls which are optional but good practice: + +* We have a test coverage ratchet that fails if a coverage goal is not met +* This ratchet fails the pipeline +* A manual intervention is required to lower the coverage goal \ No newline at end of file diff --git a/content/process/ssdlc/process/security.md b/content/process/process/security.md similarity index 71% rename from content/process/ssdlc/process/security.md rename to content/process/process/security.md index 91e2010..e8febce 100644 --- a/content/process/ssdlc/process/security.md +++ b/content/process/process/security.md @@ -4,6 +4,8 @@ level: 1 weight: 30 tldr: Software is scanned for security vulnerabilities prior to deployment rationale: Many common security vulnerabilities can be detected with automated tools. By implementing tools for dependency scanning, SAST, and DAST in the pipeline we can reduce the attack surface of our software +areas: + - process --- # {{% param "title" %}} @@ -26,3 +28,12 @@ remedial actions. * Implement security scanning in the pipeline * Act in a timely manner to security issues * Consider security concerns in code reviews and software design + +## How we implement this control + +* We use [snyk](https://snyk.io/) to scan code and dependencies in our CI/CD pipelines +* We record snyk scans in Kosli and control/monitor that no artifact with missing and/or failed snyk scans run in production + +While not mandatory for our process, we additionally: + +* Run continuous nightly snyk scans on containers in production in case new vulnerabilities are found in running assets \ No newline at end of file diff --git a/content/process/ssdlc/runtime/service_ownership.md b/content/process/process/service_ownership.md similarity index 69% rename from content/process/ssdlc/runtime/service_ownership.md rename to content/process/process/service_ownership.md index b317dc6..8f5d352 100644 --- a/content/process/ssdlc/runtime/service_ownership.md +++ b/content/process/process/service_ownership.md @@ -5,6 +5,8 @@ weight: 40 tldr: All services running in our environments have registered ownership rationale: In a diverse software landscape it is essential everyone knows who is responsible for maintaince and support +areas: + - process --- # {{% param "title" %}} {{< area_head >}} @@ -16,6 +18,11 @@ landscapes: * **Knowlege**: Who knows how this is supposed to work? How can I get help with this system? * **Incident**: Alerts are firing for a service, who do I contact? What has changed lately? -* **Audit**: who is reponsible that the DevOpsCTL process is followed for this service? +* **Audit**: who is reponsible that the SDLC is followed for this service? + +{{< figure src="/images/secrets-management.svg" alt="Change Records" >}} + +## How we implement this control + +At this stage, as we have a relatively simple system and a single tech team, simply recording the services in [Kosli's environment monitoring]({{< ref "workload_monitoring.md" >}}) meets this need. -{{< figure src="/images/secrets-management.svg" alt="Change Records" >}} \ No newline at end of file diff --git a/content/process/risk_register.md b/content/process/risk_register.md index e7f263f..7e18901 100644 --- a/content/process/risk_register.md +++ b/content/process/risk_register.md @@ -1,5 +1,5 @@ --- -weight: 10 +weight: 200 bookFlatSection: false title: "Risk Register" --- diff --git a/content/process/ssdlc/_index.md b/content/process/ssdlc/_index.md deleted file mode 100644 index 7a94e22..0000000 --- a/content/process/ssdlc/_index.md +++ /dev/null @@ -1,6 +0,0 @@ ---- -weight: 20 -bookFlatSection: false -bookCollapseSection: true -title: "Requirements" ---- diff --git a/content/process/ssdlc/process/code_review.md b/content/process/ssdlc/process/code_review.md deleted file mode 100644 index 9cb8071..0000000 --- a/content/process/ssdlc/process/code_review.md +++ /dev/null @@ -1,33 +0,0 @@ ---- -title: Code Review -weight: 10 -level: 1 -tldr: Code review is performed on all software changes -rationale: Peer review is an essential mitigation against insider threats, as well as a means of improving knowledege sharing and quality. -risks: insider_threat ---- - -# {{% param "title" %}} -{{< area_head >}} - -## Background -We use pull requests to document code reviews. The pull request description should contain key information of the change, as well as any relevant information. At a minimum, code reviews should be performed by someone capable of understanding the change and it’s associated risks. - -Important considerations we make before approving a Pull Request: - -- Security concerns: is this change secure? -- Quality: is this maintainable? -- Verification: Does this require manual testing? Has is been performed? - -{{< figure src="/images/feature-branch-pr.svg" alt="Feature Branch Strategy" >}} - -{{< hint warning >}} -### Code Review Anti-patterns - -A common anti-pattern when using pull requests is waiting for review. In an ideal situation, the lead time for review should approach 0. If there is any delay on integration, it can lead to people batching larger and larger changes. This causes larger pull requests, more delays, poorer code reviews, and ultimately more risks. - -To avoid this, we recommend pair- or ensemble-programming: a practice where more than one person works together to complete tasks. This way, as soon as one developer creates the pull request, another person can sign off immediately. - -Note: the reviewer should not be the person who pushes the last commit on the branch. - -{{< /hint >}} diff --git a/content/process/ssdlc/runtime/workload_monitoring.md b/content/process/ssdlc/runtime/workload_monitoring.md deleted file mode 100644 index 9fc59ab..0000000 --- a/content/process/ssdlc/runtime/workload_monitoring.md +++ /dev/null @@ -1,19 +0,0 @@ ---- -title: Workload Monitoring -level: 1 -weight: 50 -tldr: Workloads are monitored to alert if any system is incompliant -rationale: Real-time closed-loop compliance monitoring is a constant vigil against threats ---- - -# {{% param "title" %}} -{{< area_head >}} - -## Background - -Ensuring that risks are controlled in the value stream is the first level of -software process compliance. Beyond this, it is important to have a monitoring -process in place to ensure that unknown or incompliant workloads are identified -in production. - -{{< figure src="/images/workload-monitoring.svg" alt="Workload Monitoring" >}} \ No newline at end of file diff --git a/content/process/training.md b/content/process/training.md new file mode 100644 index 0000000..a5f5fd4 --- /dev/null +++ b/content/process/training.md @@ -0,0 +1,15 @@ +--- +weight: 30 +bookFlatSection: false +title: "Training" +--- + +# Training + +The team study the [OWASP top 10 security risks](https://owasp.org/www-project-top-ten/) +and discuss their implications for our software development and operations, at least annually. New employees and members of the tech team require this as part of our onboarding process. + +## How we implement this control + +* The activity and paritsipants will be logged in a Kosli audit trail. +* For new employees the OWASP top 10 will be done together with one of the other team members. diff --git a/data/exceptions/example.yaml b/data/exceptions/example.yaml index e28dabb..0fd7c7c 100644 --- a/data/exceptions/example.yaml +++ b/data/exceptions/example.yaml @@ -1,5 +1,5 @@ exception: - service: build-logrotate - owner: platform team - description: Does not use code reviews - rationale: This code is never ran in production systems + service: example-service + owner: Tech team + description: This is an example exemption + rationale: "Example rationale: this code is never ran in production systems" diff --git a/data/risks/env_breach.yaml b/data/risks/env_breach.yaml index 14ad345..6b7a4dc 100644 --- a/data/risks/env_breach.yaml +++ b/data/risks/env_breach.yaml @@ -3,4 +3,5 @@ risk: display_name: Environment Breach description: External attacker running workloads in our system mitigations: - - workload_monitoring + - hreflink: "/process/ssdlc/runtime/workload_monitoring/" + hreftext: "Workload monitoring" diff --git a/data/risks/insider_threat.yaml b/data/risks/insider_threat.yaml index 553e0b9..7f26227 100644 --- a/data/risks/insider_threat.yaml +++ b/data/risks/insider_threat.yaml @@ -3,6 +3,9 @@ risk: display_name: Insider Threat description: Someone inside the company acts against the best intests mitigations: - - code_review - - deployment_approvals - - workload_monitoring + - hreflink: "/process/ssdlc/process/code_review/" + hreftext: "Code Review" + - hreflink: "/process/ssdlc/process/deployment_approvals/" + hreftext: "Deployment Approvals" + - hreflink: "/process/ssdlc/runtime/workload_monitoring/" + hreftext: "Workload Monitoring" diff --git a/layouts/partials/area.html b/layouts/partials/area.html new file mode 100644 index 0000000..6581790 --- /dev/null +++ b/layouts/partials/area.html @@ -0,0 +1,5 @@ +{{- range site.Menus.main }} + + {{ .Name }} + +{{- end }} \ No newline at end of file diff --git a/layouts/partials/docs/inject/footer.html b/layouts/partials/docs/inject/footer.html index 7e0490d..e186b1e 100644 --- a/layouts/partials/docs/inject/footer.html +++ b/layouts/partials/docs/inject/footer.html @@ -1,6 +1,6 @@
- The DevOpsCTL framework is maintained by + This SDLC is maintained by
- - Fork this repo + + View on Github
diff --git a/themes/hugo-book/static/svg/logo-dcf.svg b/themes/hugo-book/static/svg/logo-dcf.svg new file mode 100644 index 0000000..9f5cd29 --- /dev/null +++ b/themes/hugo-book/static/svg/logo-dcf.svg @@ -0,0 +1,69 @@ + + + + + + + + + + + + + + + + + + + diff --git a/themes/hugo-book/static/svg/logo-short.svg b/themes/hugo-book/static/svg/logo-short.svg new file mode 100644 index 0000000..6041dd3 --- /dev/null +++ b/themes/hugo-book/static/svg/logo-short.svg @@ -0,0 +1,70 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/themes/hugo-book/static/svg/logo.svg b/themes/hugo-book/static/svg/logo.svg index 9f5cd29..783891b 100644 --- a/themes/hugo-book/static/svg/logo.svg +++ b/themes/hugo-book/static/svg/logo.svg @@ -1,69 +1,144 @@ - + + viewBox="0 0 2557.7 164.9" style="enable-background:new 0 0 2557.7 164.9;" xml:space="preserve"> - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +