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.

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.

Can scaffold projects with pipelines-as-code and toolchains-as-code

Implements the In-toto framework using pipelines-as-code

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

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).

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

Implement the technologies and processes needed for reproducible builds.

• pylock.toml

  (preferred, newest standard)

• uv

  (uses pylock.toml)

• conda

  (reproducible but less standard than pylock-toml)

• pip freeze to requirements.txt

  (not fully reproducible)

• npm package-lock.json

  created in the coding phase, combined with npm ci in the build phase

• yarn yarn.lock

• Maven
• Gradle

• NuGet lockfiles
• DotNet.ReproducibleBuilds

• Bazel

• Cargo

• Golang

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.

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).

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

Collect audit logs for code repositories.

• Audit Logs

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.

• Roles in an Organization
• Github Repository Roles

• Roles and Permissions

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.

• requiring multifactor authentication
• requiring signed commits
• requiring code change approvals and protecting the main branch

• requiring multifactor authentication
• requiring signed commits via push rules
• requiring code change approvals by protecting the main branch

Store all forms of code – including source code, executable code, and configuration-as-code – based on the principle of least privilege so that only authorized personnel, tools, services, etc. have access.

Store all source code and configuration-as-code in a code repository, and restrict access to it based on the nature of the code. For example, open source code intended for public access may need its integrity and availability protected; other code may also need its confidentiality protected.

Store all forms of code – including source code, executable code, and configuration-as-code – based on the principle of least privilege so that only authorized personnel, tools, services, etc. have access.

Use version control features of the repository to track all changes made to the code with accountability to the individual account.

Store all forms of code – including source code, executable code, and configuration-as-code – based on the principle of least privilege so that only authorized personnel, tools, services, etc. have access.

Use commit signing for code repositories to sign code.

Store all forms of code – including source code, executable code, and configuration-as-code – based on the principle of least privilege so that only authorized personnel, tools, services, etc. have access.

Have the code owner review and approve all changes made to the code by others.

Store all forms of code – including source code, executable code, and configuration-as-code – based on the principle of least privilege so that only authorized personnel, tools, services, etc. have access.

Use cryptography (e.g., cryptographic hashes) to help protect file integrity

Make software integrity verification information available to software acquirers.

Post cryptographic hashes for release files on a well-secured website.

Make software integrity verification information available to software acquirers.

Use an established certificate authority for code signing so that consumers’ operating systems or other tools and services can confirm the validity of signatures before use. Periodically review the code signing processes, including certificate renewal, rotation, revocation, and protection.

Securely archive the necessary files and supporting data (e.g., integrity verification information, provenance data) to be retained for each software release.

Store the release files, associated images, etc. in repositories following the organization’s established policy. Allow read-only access to them by necessary personnel and no access by anyone else.

Securely archive the necessary files and supporting data (e.g., integrity verification information, provenance data) to be retained for each software release.

Store and protect release integrity verification information and provenance data, such as by keeping it in a separate location from the release files or by signing the data.

Collect, safeguard, maintain, and share provenance data for all components of each software release (e.g., in a Software Bill of Materials (SBOM)).

Make the provenance data available to software acquirers in accordance with the organization’s policies, preferably using standards-based formats.

Collect, safeguard, maintain, and share provenance data for all components of each software release (e.g., in a Software Bill of Materials (SBOM)).

Make the provenance data available to the organization’s operations and response teams to aid them in mitigating software vulnerabilities.

Collect, safeguard, maintain, and share provenance data for all components of each software release (e.g., in a Software Bill of Materials (SBOM)).

Protect the integrity of provenance data, and provide a way for recipients to verify provenance data integrity.

Collect, safeguard, maintain, and share provenance data for all components of each software release (e.g., in a Software Bill of Materials (SBOM)).

Update the provenance data every time any of the software’s components are updated.