1.1 Prepare the Organization (PO)

1.1 Prepare the Organization (PO) Phase 1 Tasks

1.1 Prepare the Organization (PO) for Code and Prebuild Tasks

Organizations should ensure that their people, processes, and technology are prepared to perform secure software development at the organization level. Many organizations will find some PO practices to also be applicable to subsets of their software development, like individual development groups or projects.

PO.2 Implement Roles and Responsibilities

Ensure that everyone inside and outside of the organization involved in the SDLC is prepared to perform their SDLC-related roles and responsibilities throughout the SDLC.

Tasks	Tools
PO.2.1: Create new roles and alter responsibilities for existing roles as needed to encompass all parts of the SDLC. Periodically review and maintain the defined roles and responsibilities, updating them as needed. Designate a group of individuals as the code owners for each project, and review the list annually.	GitHub CODEOWNERS GitHub CODEOWNERS is a repository feature that lets teams formally define who owns which parts of the codebase and who must review changes before they’re merged.
GitLab CODEOWNERS GitLab CODEOWNERS is a repository feature that lets teams formally define who owns which parts of the codebase and who must review changes before they’re merged.

Tasks

Tools

PO.2.1:

Create new roles and alter responsibilities for existing roles as needed to encompass all parts of the SDLC. Periodically review and maintain the defined roles and responsibilities, updating them as needed.

Designate a group of individuals as the code owners for each project, and review the list annually.

GitHub CODEOWNERS

GitHub CODEOWNERS is a repository feature that lets teams formally define who owns which parts of the codebase and who must review changes before they’re merged.

GitLab CODEOWNERS

GitLab CODEOWNERS is a repository feature that lets teams formally define who owns which parts of the codebase and who must review changes before they’re merged.

PO.3 Implement Supporting Toolchains

Use automation to reduce human effort and improve the accuracy, reproducibility, usability, and comprehensiveness of security practices throughout the SDLC, as well as provide a way to document and demonstrate the use of these practices. Toolchains and tools may be used at different levels of the organization, such as organization-wide or project-specific, and may address a particular part of the SDLC, like a build pipeline.

Tasks	Tools
PO.3.1: Specify which tools or tool types must or should be included in each toolchain to mitigate identified risks, as well as how the toolchain components are to be integrated with each other. Use software factories and/or software templates to standardize the toolchain.	Backstage Software Templates Backstage Software Templates are a scaffolding and standardization mechanism that help teams create new services, pipelines, and infrastructure in a consistent, compliant way. Backstage Software Templates let platform teams define golden paths for creating software components. A template captures best practices, required tooling, and organizational standards, then generates repositories, configs, and documentation automatically.
Konflux-ci software factory for Tekton The Konflux software factory for Tekton is a secure, standardized CI build system that sits on top of Tekton to turn raw pipelines into a trusted software supply-chain factory. Konflux is Tekton with guardrails. Tekton provides the pipeline engine (tasks, pipelines, Kubernetes execution). Konflux adds the factory layer that enforces how those pipelines are allowed to run so the outputs can be trusted. Implements the in-toto framework.
CDF CDEvents CDEvents is a common specification for Continuous Delivery events, enabling interoperability in the complete software production ecosystem.
PO.3.2: Follow recommended security practices to deploy, operate, and maintain tools and toolchains. Use code-based configuration for toolchains (e.g., pipelines-as-code, toolchains-as-code).	Jenkins Jenkinsfile A Jenkins Jenkinsfile is a declarative or scripted definition of a CI/CD pipeline, written as code and stored directly in a source repository. A Jenkinsfile describes how software is built, tested, scanned, packaged, and deployed. Because it lives alongside the application code, it enables pipeline-as-code—versioned, reviewable, and auditable automation.
GitHub Actions (.github/workflows) The GitHub Actions .github/workflows directory is the central location where CI/CD automation is defined as code for a GitHub repository. The directory contains YAML files that define workflows. Each workflow describes when automation should run and what jobs and steps are executed in response to repository events.
GitLab CI/CD (.gitlab-ci.yml) The GitLab CI/CD .gitlab-ci.yml file is the single, authoritative pipeline definition that tells GitLab how to build, test, secure, and deploy an application. .gitlab-ci.yml is a YAML-based, pipeline-as-code configuration file stored at the root of a repository. It defines what jobs run, in what order, and under which conditions whenever code changes occur.
Spinnaker Dinghy Spinnaker Dinghy is a configuration-as-code service that lets teams define and manage Spinnaker deployment pipelines using Git, instead of clicking through the UI. Dinghy allows Spinnaker pipelines to be written as JSON or YAML files and stored in a source repository. When changes are committed, Dinghy automatically syncs those pipeline definitions into Spinnaker, keeping deployments consistent and versioned.
Argo CD Argo CD is a GitOps-based continuous delivery tool for Kubernetes that automatically deploys and keeps applications in sync with what’s declared in Git. Argo CD treats Git as the single source of truth for Kubernetes applications. Instead of pushing deployments from a CI pipeline, Argo CD pulls desired state from Git and continuously reconciles running clusters to match it.
Tekton Pipelines-as-Code Tekton Pipelines-as-Code is a Git-driven way to define and run Tekton CI/CD pipelines directly from pull requests—treating pipelines as first-class code artifacts.
OpenTofu OpenTofu is an open-source Infrastructure as Code (IaC) tool used to define, provision, and manage cloud and on-prem infrastructure using declarative configuration files.
Konflux-ci Konflux is an open-source, cloud-native CI platform designed to produce trusted, reproducible, and verifiable software artifacts for modern software supply chains. It prioritizes build integrity, provenance, and repeatability, making it well-suited for regulated, enterprise, and critical-infrastructure environments. Python: pylock.toml (preferred, newest standard) uv — uses pylock.toml conda-lock — reproducible, less standard pip freeze — not fully reproducible JavaScript: package-lock.json — use with npm ci yarn.lock Java / Kotlin / Groovy: Maven, Gradle C# / .NET: NuGet lock files , DotNet.ReproducibleBuilds C++: Bazel Rust: Cargo Golang: Go reproducible builds
PHP Composer Composer is the standard dependency manager for PHP, used to declare, install, and manage third-party libraries required by a PHP application. Composer lets developers define which PHP packages their project depends on and automatically resolves, downloads, and installs the correct versions. It ensures that every environment—developer laptops, CI systems, and production—uses the same dependency set.
SLSA Framework The SLSA Framework (Supply-chain Levels for Software Artifacts) is a security framework that defines how to build software in a way that is verifiable, tamper-resistant, and trustworthy.
PO.3.3: Configure tools to generate artifacts of their support of secure software development practices as defined by the organization. Use existing tooling (e.g., workflow tracking, issue tracking, value stream mapping) to create an audit trail of the secure development-related actions that are performed for continuous improvement purposes. Record security check approvals, rejections, and exception requests as part of the workflow and tracking system.	GitHub Issues GitHub Issues is a built-in tracking system used to manage work, bugs, feature requests, and discussions directly within a GitHub repository.
GitLab work tracking GitLab Work Tracking is GitLab’s integrated system for planning, tracking, and managing work—from ideas and requirements to code, security fixes, and delivery.
Bugzilla Bugzilla is an open-source bug tracking and issue management system used to report, track, and manage software defects and enhancement requests throughout the development lifecycle.
Redmine Redmine is an open-source project management and issue-tracking tool used by software teams to plan work, track bugs and tasks, and manage projects over time.
Mantis Bug Tracker Mantis Bug Tracker (often called MantisBT) is an open-source, web-based bug and issue tracking system designed to be simple, fast, and lightweight.
Trac Trac is an open-source, web-based project management and issue-tracking system that tightly integrates tickets, a wiki, and source-code browsing. It’s known for being lightweight, text-centric, and developer-friendly.
in-toto framework in-toto is an open-source framework for securing the software supply chain by cryptographically recording and verifying every step of how software is built, tested, and released.

Tasks

Tools

PO.3.1:

Specify which tools or tool types must or should be included in each toolchain to mitigate identified risks, as well as how the toolchain components are to be integrated with each other.

Use software factories and/or software templates to standardize the toolchain.

Backstage Software Templates

Backstage Software Templates are a scaffolding and standardization mechanism that help teams create new services, pipelines, and infrastructure in a consistent, compliant way. Backstage Software Templates let platform teams define golden paths for creating software components. A template captures best practices, required tooling, and organizational standards, then generates repositories, configs, and documentation automatically.

Konflux-ci software factory for Tekton

The Konflux software factory for Tekton is a secure, standardized CI build system that sits on top of Tekton to turn raw pipelines into a trusted software supply-chain factory. Konflux is Tekton with guardrails. Tekton provides the pipeline engine (tasks, pipelines, Kubernetes execution). Konflux adds the factory layer that enforces how those pipelines are allowed to run so the outputs can be trusted. Implements the in-toto framework.

CDF CDEvents

CDEvents is a common specification for Continuous Delivery events, enabling interoperability in the complete software production ecosystem.

PO.3.2:

Follow recommended security practices to deploy, operate, and maintain tools and toolchains.

Use code-based configuration for toolchains (e.g., pipelines-as-code, toolchains-as-code).

Jenkins Jenkinsfile

A Jenkins Jenkinsfile is a declarative or scripted definition of a CI/CD pipeline, written as code and stored directly in a source repository. A Jenkinsfile describes how software is built, tested, scanned, packaged, and deployed. Because it lives alongside the application code, it enables pipeline-as-code—versioned, reviewable, and auditable automation.

GitHub Actions (.github/workflows)

The GitHub Actions .github/workflows directory is the central location where CI/CD automation is defined as code for a GitHub repository. The directory contains YAML files that define workflows. Each workflow describes when automation should run and what jobs and steps are executed in response to repository events.

GitLab CI/CD (.gitlab-ci.yml)

The GitLab CI/CD .gitlab-ci.yml file is the single, authoritative pipeline definition that tells GitLab how to build, test, secure, and deploy an application. .gitlab-ci.yml is a YAML-based, pipeline-as-code configuration file stored at the root of a repository. It defines what jobs run, in what order, and under which conditions whenever code changes occur.

Spinnaker Dinghy

Spinnaker Dinghy is a configuration-as-code service that lets teams define and manage Spinnaker deployment pipelines using Git, instead of clicking through the UI. Dinghy allows Spinnaker pipelines to be written as JSON or YAML files and stored in a source repository. When changes are committed, Dinghy automatically syncs those pipeline definitions into Spinnaker, keeping deployments consistent and versioned.

Argo CD

Argo CD is a GitOps-based continuous delivery tool for Kubernetes that automatically deploys and keeps applications in sync with what’s declared in Git. Argo CD treats Git as the single source of truth for Kubernetes applications. Instead of pushing deployments from a CI pipeline, Argo CD pulls desired state from Git and continuously reconciles running clusters to match it.

Tekton Pipelines-as-Code

Tekton Pipelines-as-Code is a Git-driven way to define and run Tekton CI/CD pipelines directly from pull requests—treating pipelines as first-class code artifacts.

OpenTofu

OpenTofu is an open-source Infrastructure as Code (IaC) tool used to define, provision, and manage cloud and on-prem infrastructure using declarative configuration files.

Konflux-ci

Konflux is an open-source, cloud-native CI platform designed to produce trusted, reproducible, and verifiable software artifacts for modern software supply chains. It prioritizes build integrity, provenance, and repeatability, making it well-suited for regulated, enterprise, and critical-infrastructure environments.

Python: pylock.toml (preferred, newest standard)

uv — uses pylock.toml
conda-lock — reproducible, less standard
pip freeze — not fully reproducible

JavaScript:

package-lock.json — use with npm ci
yarn.lock

Java / Kotlin / Groovy: Maven, Gradle

C# / .NET: NuGet lock files , DotNet.ReproducibleBuilds

C++: Bazel

Rust: Cargo

Golang: Go reproducible builds

PHP Composer

Composer is the standard dependency manager for PHP, used to declare, install, and manage third-party libraries required by a PHP application. Composer lets developers define which PHP packages their project depends on and automatically resolves, downloads, and installs the correct versions. It ensures that every environment—developer laptops, CI systems, and production—uses the same dependency set.

SLSA Framework

The SLSA Framework (Supply-chain Levels for Software Artifacts) is a security framework that defines how to build software in a way that is verifiable, tamper-resistant, and trustworthy.

PO.3.3:

Configure tools to generate artifacts of their support of secure software development practices as defined by the organization.

Use existing tooling (e.g., workflow tracking, issue tracking, value stream mapping) to create an audit trail of the secure development-related actions that are performed for continuous improvement purposes. Record security check approvals, rejections, and exception requests as part of the workflow and tracking system.

GitHub Issues

GitHub Issues is a built-in tracking system used to manage work, bugs, feature requests, and discussions directly within a GitHub repository.

GitLab work tracking

GitLab Work Tracking is GitLab’s integrated system for planning, tracking, and managing work—from ideas and requirements to code, security fixes, and delivery.

Bugzilla

Bugzilla is an open-source bug tracking and issue management system used to report, track, and manage software defects and enhancement requests throughout the development lifecycle.

Redmine

Redmine is an open-source project management and issue-tracking tool used by software teams to plan work, track bugs and tasks, and manage projects over time.

Mantis Bug Tracker

Mantis Bug Tracker (often called MantisBT) is an open-source, web-based bug and issue tracking system designed to be simple, fast, and lightweight.

Trac

Trac is an open-source, web-based project management and issue-tracking system that tightly integrates tickets, a wiki, and source-code browsing. It’s known for being lightweight, text-centric, and developer-friendly.

in-toto framework

in-toto is an open-source framework for securing the software supply chain by cryptographically recording and verifying every step of how software is built, tested, and released.

PO.4 Define and Use Criteria for Software Security Checks

Help ensure that the software resulting from the SDLC meets the organization’s expectations by defining and using criteria for checking the software’s security during development.

Tasks	Tools
PO.4.1: Define criteria for software security checks and track throughout the SDLC. Add software security criteria to existing checks (e.g., the Definition of Done in agile SDLC methodologies).	GitHub Issue Templates GitHub Issue Templates are predefined forms and guidelines that appear when someone opens a new issue in a repository. They help teams collect consistent, high-quality information for bugs, feature requests, security issues, or questions.
GitLab Description Templates GitLab Description Templates are predefined Markdown templates that automatically populate the description field when someone creates a GitLab Issue, Merge Request (MR), or Epics.
PO.4.2: Implement processes, mechanisms, etc. to gather and safeguard the necessary information in support of the criteria. Collect audit logs for code repositories.	GitHub Audit Logs
GitLab Audit Logs
PO.4.3: Implement processes, mechanisms, etc. to gather and safeguard the necessary information in support of the criteria. Only allow authorized personnel to access the gathered information, and prevent any alteration or deletion of the information. Carefully manage the list of repository owners and organization owners who have the ability to view audit logs, delete organizations, and delete code repositories, and review the list annually.	GitHub Roles in an Organization GitHub Repository Roles
GitLab Roles and Permissions

Tasks

Tools

PO.4.1:

Define criteria for software security checks and track throughout the SDLC.

Add software security criteria to existing checks (e.g., the Definition of Done in agile SDLC methodologies).

GitHub Issue Templates

GitHub Issue Templates are predefined forms and guidelines that appear when someone opens a new issue in a repository. They help teams collect consistent, high-quality information for bugs, feature requests, security issues, or questions.

GitLab Description Templates

GitLab Description Templates are predefined Markdown templates that automatically populate the description field when someone creates a GitLab Issue, Merge Request (MR), or Epics.

PO.4.2:

Implement processes, mechanisms, etc. to gather and safeguard the necessary information in support of the criteria.

Collect audit logs for code repositories.

GitHub

Audit Logs

GitLab

Audit Logs

PO.4.3:

Implement processes, mechanisms, etc. to gather and safeguard the necessary information in support of the criteria.

Only allow authorized personnel to access the gathered information, and prevent any alteration or deletion of the information. Carefully manage the list of repository owners and organization owners who have the ability to view audit logs, delete organizations, and delete code repositories, and review the list annually.

GitHub

GitLab

Roles and Permissions

PO.5 Implement and Maintain Secure Environments for Software Development

Ensure that all components of the environments for software development are strongly protected from internal and external threats to prevent compromises of the environments or the software being developed or maintained within them. Examples of environments for software development include development, build, test, and distribution environments.

Tasks	Tools
PO.5.1: Separate and protect each environment involved in software development. Require multifactor authentication, SSH keys, signed commits, and code change approvals for code repositories at the organization level.	GitHub Organization Settings Requiring multifactor authentication Requiring signed commits Requiring code change approvals and protecting the main branch
GitLab Requiring multifactor authentication Requiring signed commits via push rules Requiring code change approvals by protecting the main branch

Tasks

Tools

PO.5.1:

Separate and protect each environment involved in software development.

Require multifactor authentication, SSH keys, signed commits, and code change approvals for code repositories at the organization level.

GitHub Organization Settings

GitLab

Note: Securely configure code repository and CI/CD servers - this is a complex topic, beyond the scope of this document. Securely configure development endpoints (i.e., developer laptops) - this is a complex topic, beyond the scope of this document.