feat: add SDLC Registry section

sdlc-registry/background.mdx

@@ -0,0 +1,41 @@
+---
+title: "Background"
+description: "Why software delivery governance matters and how this framework addresses it."
+icon: "book-open"
+---
+
+<Frame>
+  <img src="/images/sdlc-registry/hero-home.svg" alt="Software Delivery Governance" />
+</Frame>
+
+Software delivery performance directly correlates with business performance. But for organizations in regulated markets, the biggest blocker to delivery isn't engineering capacity — it's **governance**.
+
+Legacy governance processes slow businesses down, cost them money, and put them at risk. Modern tools and engineering practices have made it possible to ship software at extraordinary speed, but governance has remained static. Most enterprises still rely on IT tickets, human approvers, and Change Advisory Board meetings — governance processes designed for a world where teams deployed monthly, not hourly.
+
+## The three pillars of software governance
+
+Effective governance, whether manual or automated, must address three fundamental pillars:
+
+<Frame>
+  <img src="/images/sdlc-registry/governance.svg" alt="Governance Framework" />
+</Frame>
+
+**1. Define: have a process for managing risks**
+
+Every governance framework starts with documented, standardized processes that explicitly address risks in software development and delivery. This typically takes the form of an SDLC Governance Framework that identifies potential risks and prescribes specific controls to mitigate them. Without clear definitions, controls become subject to interpretation, making consistent implementation impossible.
+
+**2. Implement: follow the process in daily work**
+
+A framework documented on paper is meaningless unless consistently executed in practice. This pillar focuses on embedding governance activities into the daily workflow of development teams. When controls are automated they're followed every time, not only when someone remembers.
+
+**3. Prove: demonstrate the process has been followed**
+
+The final pillar involves demonstrating compliance through verifiable evidence. Auditors and regulators need proof that controls are actually performed, not just policies stating they should be.
+
+## Scope
+
+The scope of this framework covers the entire software development value stream — from requirements through build, release, and runtime.
+
+<Frame>
+  <img src="/images/sdlc-registry/governance-scope.svg" alt="Secure Value Stream" />
+</Frame>

sdlc-registry/controls-engineering.mdx

@@ -0,0 +1,76 @@
+---
+title: "Controls Engineering"
+description: "Applying modern software engineering practices to governance, risk, and compliance."
+icon: "microchip"
+---
+
+Controls Engineering is the application of modern software engineering practices to the domain of governance, risk, and compliance. Think of it as asking: "What would happen if we applied software engineering to compliance and risk management?"
+
+This is analogous to how Google created Site Reliability Engineering (SRE) by asking what would happen if software engineers did operations work. Controls Engineering asks the equivalent question for governance.
+
+## The speed mismatch problem
+
+Modern software engineering moves fast — teams deploy multiple times per day. Governance moves slowly — frameworks are reviewed annually, policies go through committees.
+
+This speed mismatch creates friction. The traditional response is to slow engineering down, but this approach fails both business needs and risk management goals.
+
+Controls Engineering offers a different path. By applying modern software engineering practices to governance itself, organizations can achieve continuous compliance without sacrificing velocity. This approach replaces manual checkpoints with automated controls, transforms governance from costly theatre to a competitive advantage, and proves compliance through verifiable evidence rather than paperwork and promises.
+
+## Controls Engineering is not "automating the tickets"
+
+There is a natural response when engineering teams encounter the governance bottleneck: automate the paperwork. If filling out change tickets is slow, write a script that fills them out. If uploading evidence to a change management system is tedious, build an integration that does it automatically.
+
+This approach feels like progress. It is faster. But it does not fundamentally change the outcome. You are still doing the same process, with the same assumptions, producing the same artifacts. You've just automated the receipts.
+
+The problem is deeper than that. If your existing manual process doesn't actually improve your risk posture, and in many organizations it doesn't, then automating that process means you are now doing a risky thing more often. You have increased your throughput without improving your controls.
+
+Controls Engineering takes a different path. Instead of asking "how do we automate this process?", it asks "what risk is this process trying to mitigate, and what is the best way to mitigate that risk?" Sometimes the answer involves automating part of the existing process. Often it means redesigning the control entirely.
+
+## What do we mean by control?
+
+A **control** is a check or restraint on an activity to meet one or more software risk objectives.
+
+Controls should only exist to tackle a given risk. If there is no risk to mitigate or eliminate, then the control has no purpose. There is a good reason for this: every control comes with a cost — typically delays and maintenance overheads. If those costs don't protect against a high-value risk, then why pay the cost?
+
+When properly designed, controls are guardrails that keep your software delivery lifecycle on track and aligned with your organization's policies, standards, and regulatory requirements.
+
+## Designing automated controls
+
+At their most abstract level, every control, whether manual or automated, shares the same fundamental components:
+
+- **Facts**: The raw data or evidence being evaluated
+- **Rules**: The criteria used to assess those facts
+- **Evaluation**: The process of applying rules to facts
+- **Evaluation Report**: Documentation of the decision and its rationale
+
+In an automated control system, we can be more precise:
+
+- **Event**: Something happens (a build completes, a deployment starts, a schedule triggers)
+- **Context**: Specific contextual information about the event (git commit, artifact ID, repository, test results, etc.)
+- **Query (Optional)**: The system can proactively gather additional facts it needs from a Compliance System of Record (CSOR)
+- **Rules**: The same evaluation criteria, but now machine-readable and consistently applied
+- **Evaluation Report**: Automatically generated documentation with full traceability
+
+This structure ensures that automated controls can be both more rigorous and more efficient than manual ones. Every evaluation is documented, every decision is traceable, and the criteria are applied consistently across all events.
+
+## Why software control design matters
+
+When you implement automated controls they exhibit all the characteristics of any other software system:
+
+- **Controls have requirements.** A control should have clear requirements derived from the risk it mitigates. A control consumes inputs and produces outputs. These interfaces can be defined and documented.
+- **Controls have a lifecycle.** Evaluation logic can be versioned, reviewed, and rolled out progressively to different parts of the organization.
+- **Controls can be tested.** You can write tests for control logic, verify outputs given specific inputs, and regression test controls when you change them.
+- **Controls have a design.** The policy enforcement points, decision points, and systems of record that make up a control can be designed with the same care as any software system. Controls can fail. Like any operational system, observability is key.
+
+The key takeaway is this: controls aren't obstacles to velocity. When properly designed, they can be the foundation that makes rapid, confident delivery possible.
+
+## Types of software delivery controls
+
+While there may be controls sprawled across your SDLC, it can be helpful to categorize them into specific lifecycle areas based on the risks they are mitigating. Typically, software controls fall naturally into these categories:
+
+| Area | Scope |
+|---|---|
+| Build | Controls which apply to the processes around how software is constructed and qualified |
+| Release | Controls which apply to release decisions and change control |
+| Runtime | Controls which apply to runtime systems and environments |
+| Lifecycle | Controls operating outside of the natural software delivery process but must be evidenced, such as ownership, architecture, and security |

sdlc-registry/controls.mdx

@@ -0,0 +1,73 @@
+---
+title: "Controls"
+description: "Security and compliance controls organized across Build, Release, Runtime, and Lifecycle phases."
+icon: "shield-halved"
+mode: "wide"
+---
+
+import VersionControlCard from '/snippets/sdlc/controls/build/versioncontrol.mdx';
+import BinaryProvenanceCard from '/snippets/sdlc/controls/build/binary_provenance.mdx';
+import ToolchainCard from '/snippets/sdlc/controls/build/toolchain.mdx';
+import DependenciesCard from '/snippets/sdlc/controls/build/dependencies.mdx';
+import InfraCard from '/snippets/sdlc/controls/build/infrastructure_and_config_management.mdx';
+import SecretsScanningCard from '/snippets/sdlc/controls/build/secrets-scanning.mdx';
+import CodeReviewCard from '/snippets/sdlc/controls/release/code_review.mdx';
+import QualityCard from '/snippets/sdlc/controls/release/quality.mdx';
+import DeploymentApprovalsCard from '/snippets/sdlc/controls/release/deployment_approvals.mdx';
+import VulnSastCard from '/snippets/sdlc/controls/release/vulnerability_scanning_sast.mdx';
+import VulnScaCard from '/snippets/sdlc/controls/release/vulnerability_scanning_sca.mdx';
+import VulnContainersCard from '/snippets/sdlc/controls/release/vulnerability_scanning_containers.mdx';
+import FeatureFlagsCard from '/snippets/sdlc/controls/release/feature_flags.mdx';
+import ChangeRecordsCard from '/snippets/sdlc/controls/runtime/change_records.mdx';
+import DeploymentControlsCard from '/snippets/sdlc/controls/runtime/deployment_controls.mdx';
+import SecretsManagementCard from '/snippets/sdlc/controls/runtime/secrets_managment.mdx';
+import SystemAccessCard from '/snippets/sdlc/controls/runtime/system_access.mdx';
+import WorkloadMonitoringCard from '/snippets/sdlc/controls/runtime/workload_monitoring.mdx';
+import DriftDetectionCard from '/snippets/sdlc/controls/runtime/drift_detection.mdx';
+import ServiceOwnershipCard from '/snippets/sdlc/controls/lifecycle/service_ownership.mdx';
+import TrainingCard from '/snippets/sdlc/controls/lifecycle/training.mdx';
+import PenTestCard from '/snippets/sdlc/controls/lifecycle/penetration_testing.mdx';
+
+Controls are the specific practices and technical measures we apply to mitigate identified risks across the software delivery lifecycle. Each control maps to one or more risks, carries a unique identifier, and links to verifiable evidence in Kosli.
+
+## <Icon icon="hammer" /> Build
+
+<div className="sdlc-grid sdlc-grid--4">
+  <VersionControlCard />
+  <BinaryProvenanceCard />
+  <ToolchainCard />
+  <DependenciesCard />
+  <InfraCard />
+  <SecretsScanningCard />
+</div>
+
+## <Icon icon="rocket" /> Release
+
+<div className="sdlc-grid sdlc-grid--4">
+  <CodeReviewCard />
+  <QualityCard />
+  <DeploymentApprovalsCard />
+  <VulnSastCard />
+  <VulnScaCard />
+  <VulnContainersCard />
+  <FeatureFlagsCard />
+</div>
+
+## <Icon icon="server" /> Runtime
+
+<div className="sdlc-grid sdlc-grid--4">
+  <ChangeRecordsCard />
+  <DeploymentControlsCard />
+  <SecretsManagementCard />
+  <SystemAccessCard />
+  <WorkloadMonitoringCard />
+  <DriftDetectionCard />
+</div>
+
+## <Icon icon="recycle" /> Lifecycle
+
+<div className="sdlc-grid sdlc-grid--4">
+  <ServiceOwnershipCard />
+  <TrainingCard />
+  <PenTestCard />
+</div>

sdlc-registry/controls/build/binary_provenance.mdx

@@ -0,0 +1,70 @@
+---
+title: "Artifact Binary Provenance"
+description: "Every software artefact running in a production system has known provenance, established through cryptographic content-addressable identities."
+icon: "fingerprint"
+---
+
+import SupplyChainCard from '/snippets/sdlc/risks/supply_chain_compromise.mdx';
+import UnauthorisedDeploymentCard from '/snippets/sdlc/risks/unauthorised_deployment.mdx';
+
+<Note>**SDLC-CTRL-0002** · Build</Note>
+
+## Description
+Software identity is defined using the cryptographic hash of the software itself. Using the SHA256 digest of a software binary means that if a single byte in the software changes, it will have a different identity. This ensures that one software artefact cannot be qualified and a different one deployed in its place.
+
+Binary provenance creates a provable chain of custody from commit to build to production. It establishes verifiable evidence of what was built, when, and from which source — enabling traceability across the entire software development lifecycle.
+
+Human-friendly identifiers such as semantic versions or git commit references are useful for navigation but are fallible. Cryptographic hashes provide the tamper-proof identity required for security and compliance purposes.
+
+## Requirements
+* Every software artefact MUST be identified by its cryptographic hash (SHA256 digest)
+* The provenance record MUST link the artefact to the specific git commit that produced it
+* The following evidence MUST be recorded for each artefact:
+  * The SHA256 of the artefact (docker image, zip file, etc.)
+  * A human-readable name
+  * The git commit that produced it
+  * The git repository state (clean, unstaged files, etc.)
+  * A URL to the build log
+  * The build environment information
+* A software bill of materials SHOULD be recorded alongside provenance data
+* Human-friendly identifiers (semver, tags) SHOULD NOT be used as the sole means of identifying software for security and compliance purposes
+
+## 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/
+
+<Frame><img src="/images/sdlc-registry/controls/binary-provenance.svg" alt="Binary Provenance" /></Frame>
+
+## Mitigates risks
+
+<div className="sdlc-grid sdlc-grid--5">
+  <SupplyChainCard />
+  <UnauthorisedDeploymentCard />
+</div>
+
+## Compliance references
+
+<AccordionGroup>
+  <Accordion title="NIST SP 800-53 R5">
+    | Control | Note |
+    |---|---|
+    | SA-10 | Requires tracking of configuration items including built software artefacts. |
+    | CM-8 | System component inventory — binary provenance provides a verifiable record of every artefact deployed. |
+    | SI-7 | Software, firmware, and information integrity — cryptographic hashes detect unauthorised modification of artefacts. |
+    | SA-12 | Supply chain protection — provenance links artefacts to their source, mitigating substitution attacks. |
+    | AU-10 | Non-repudiation — content-addressable identities provide tamper-evident proof of what was built and deployed. |
+    | CM-3 | Change tracking — provenance records tie each artefact to the specific commit and build that produced it. |
+  </Accordion>
+  <Accordion title="SOC 2 Type II">
+    | Control | Note |
+    |---|---|
+    | PI1.3 | Requires processing to be complete, accurate, and timely; binary provenance verifies that deployed artifacts match what was built and tested. |
+    | CC8.1 | Requires authorised and tested changes; provenance attestations confirm that artifacts originate from the controlled build pipeline. |
+    | CC7.2 | Requires monitoring for anomalies; provenance verification detects tampered or substituted artifacts before deployment. |
+  </Accordion>
+</AccordionGroup>
+
+## Links
+- [SLSA Provenance](https://slsa.dev/provenance)
+- [Kosli — Artifact Provenance](https://docs.kosli.com/getting_started/artifacts/)
+- [Content-addressable storage — Wikipedia](https://en.wikipedia.org/wiki/Content-addressable_storage)

sdlc-registry/controls/build/dependencies.mdx

@@ -0,0 +1,68 @@
+---
+title: "Dependency Management"
+description: "Every dependency is defined securely, managed, and auditable as part of the software development lifecycle."
+icon: "cubes"
+---
+
+import SupplyChainCard from '/snippets/sdlc/risks/supply_chain_compromise.mdx';
+import VulnerableSoftwareCard from '/snippets/sdlc/risks/vulnerable_software_in_production.mdx';
+
+<Note>**SDLC-CTRL-0004** · Build</Note>
+
+## Description
+Inputs to the build process — including third-party libraries, container base images, and other source code — can introduce security and quality issues. Dependencies must be explicitly defined, controlled, and transparent to maintain the integrity of the software supply chain.
+
+During build, these inputs can be recorded as the software bill of materials alongside binary provenance, enabling traceability of all components included in a release.
+
+## Requirements
+* All dependencies MUST be explicitly defined in version-controlled dependency files (e.g. `go.mod`, `requirements.txt`, `package.json`, `Dockerfile`)
+* Dependencies MUST comply with licensing requirements agreed by the company
+* Lock files MUST be used to ensure reproducible builds and prevent silent dependency changes
+* Dependencies SHOULD be recorded as a software bill of materials when recording [binary provenance](/sdlc-registry/controls/build/binary_provenance)
+* Container base images MUST be explicitly versioned and pinned
+
+## How we implement this control
+
+We define these dependencies in the source code, at the application level and if relevant, 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) <br /> [NPM Dependencies](https://github.com/kosli-dev/server/blob/master/package.json) |
+| 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) |
+
+<Frame><img src="/images/sdlc-registry/controls/dependency-management.svg" alt="Dependency Management" /></Frame>
+
+## Mitigates risks
+
+<div className="sdlc-grid sdlc-grid--5">
+  <SupplyChainCard />
+  <VulnerableSoftwareCard />
+</div>
+
+## Compliance references
+
+<AccordionGroup>
+  <Accordion title="NIST SP 800-53 R5">
+    | Control | Note |
+    |---|---|
+    | SA-9 | External system services — third-party dependencies are external services/components that must be managed and controlled. |
+    | SA-12 | Supply chain protection — dependency management controls the inputs to the build process. |
+    | SA-22 | Unsupported system components — dependencies must be actively maintained and not end-of-life. |
+    | CM-8 | System component inventory — all dependencies must be catalogued and traceable. |
+    | SR-4 | Provenance — requires tracking the origin and integrity of software components. |
+    | CM-7 | Least functionality — only necessary dependencies should be included. |
+  </Accordion>
+  <Accordion title="SOC 2 Type II">
+    | Control | Note |
+    |---|---|
+    | CC8.1 | Requires changes to be authorised and tested; dependency management ensures third-party components are explicitly declared and reviewed. |
+    | PI1.3 | Requires processing integrity; pinned and verified dependencies prevent unexpected behaviour from upstream changes. |
+    | CC7.2 | Requires monitoring of system components; maps to tracking dependency versions and known vulnerabilities. |
+  </Accordion>
+</AccordionGroup>
+
+## Links
+- [OWASP Dependency-Check](https://owasp.org/www-project-dependency-check/)
+- [CycloneDX SBOM Standard](https://cyclonedx.org/)
+- [SPDX SBOM Standard](https://spdx.dev/)