What PR.PS-06 secure software development requires
If your organization builds software, NIST CSF 2.0 Subcategory PR.PS-06 asks you to show that secure software development practices are built into the software development life cycle and that their performance is monitored. In plain terms, the requirement is not satisfied by a policy that says developers should write secure code. It is satisfied when practices exist at each stage of building, testing, releasing and retiring your software, and when someone checks whether they work. The paraphrased outcome sits in the PROTECT Function under the Platform Security (PR.PS) Category. Under the CSF 1.1 to 2.0 transition, PR.PS-06 absorbs part or all of CSF 1.1 PR.IP-2, so organizations that already mapped to the older Subcategory should review that legacy mapping rather than assume it carried over unchanged.
NIST publishes three Implementation Examples for PR.PS-06. The first covers protecting all components of organization-developed software from tampering and unauthorized access, which points to controls such as restricted push and merge rights on protected branches, signed or verified build artifacts and limited access to build systems. The second covers releasing software with minimal vulnerabilities, which implies scanning code and dependencies before release and recording what was found and fixed. The third covers maintaining production software and disposing of it securely when it is no longer needed. Ask your engineering leads to name the owner and the evidence for each of these three examples. Any gap in that answer is a finding an assessor will likely raise.
This requirement is hard because development teams often have written standards that nobody enforces or measures. A secure coding guideline on a wiki does not show that a merge was reviewed, that a scan ran on a release or that a retired service was decommissioned. Start by checking which practices produce records automatically, such as pipeline logs, review approvals and scan reports, and which depend on individual memory. NIST does not certify products, services or implementations, and it has no conformity assessment program for CSF. If you need a formal attestation for a customer, contract or regulator, an independent assessor or certification body must perform it. DeployOpen can help prepare systems and evidence, but it does not issue reports or certificates.
Which repositories, pipelines and teams fall under PR.PS-06
Scope decides how much of PR.PS-06 your organization must run itself and how much it can hold suppliers to. The cards below cover the software, pipelines and people that usually need a decision before anyone writes a secure development procedure. Settle these boundaries in writing first, because assessors will test whatever scope you declare.
Organization-developed application code
This is the core of PR.PS-06: source code your teams write and ship, including services, libraries and internal APIs. Record every repository that produces a deployable artifact, not only the flagship products. Check for forks, archived projects that still run in production, and personal repositories used for production scripts. Each one needs the same protections on branches, reviews and scanning as the main codebase, or the scope has a gap an assessor can find.
Infrastructure as code
Terraform, Helm charts, Ansible playbooks and pipeline definitions change how production behaves, so they belong in scope even though many teams treat them as operations files. Confirm that changes to these files pass through the same review and tamper controls as application code. Semgrep supports Terraform, so infrastructure definitions can be scanned in the same pipeline as application code. Name the owners of each repository in the scope record.
Build and release pipelines
Every pipeline that compiles, packages, signs or deploys organization-developed software is in scope, including CI runners, artifact registries and deployment jobs. Document which pipelines promote code to production and which only build test artifacts. Pipeline configuration is itself code that can be altered, so limit who can edit it and log those changes. An unlisted pipeline that can push to production is a common reason a scope statement fails review.
Customized vendor and open-source code
When you modify a vendor product or an open-source project, the modified portion becomes organization-developed software and falls under PR.PS-06. Keep a record of each patch, fork and plugin you maintain, separate from the upstream project. Upstream code you merely deploy without change is generally handled through supplier and component assessment instead. Confirm that boundary with your assessor before you rely on it, because the line between configuration and customization is a judgment call.
Contractors and third-party developers
Outside developers who commit code to your repositories or run your pipelines act inside your secure development process, even if a supplier employs them. Decide which contracted teams have write access, which only submit merge requests, and which have no repository access at all. Their obligations belong in contracts and access reviews. Assessors will ask who approved each external account and when its access was last reviewed.
Purchased software and supplier obligations
Commercial software you buy without modification is usually out of PR.PS-06 scope for development practices and handled through supplier requirements. Your obligations shift to asking how the supplier develops and tests its product, reviewing its security documentation and tracking its vulnerability disclosures. The NIST CSF 2.0 Reference Tool links PR.PS-06 to SP 800-53 SA controls and ISO/IEC 27001 Annex A controls 8.25 to 8.31. Use these as cross-checks on scope, and confirm each mapping with the standard's owner rather than treating it as equivalence.
How an assessor tests secure software development
The assessor starts by reading the secure software development policy, the coding and review standards, the release procedure and the list of tools that gate builds. The question at this stage is whether the organization has defined what secure development means for its own products, who owns each practice, and how performance is measured. Assessors look for named owners, defined review and testing expectations, and a stated process for handling vulnerabilities found before release. They also check the document dates and version history, because a policy that predates the current pipeline often describes controls that no longer exist.
- Defined scope: the policy names which repositories, languages and products it covers, including infrastructure as code.
- Named owners: each practice, such as code review, scanning and release approval, has an accountable role.
- Measurable expectations: the standard states what must pass before a release, such as scan results or approvals.
- Monitoring commitments: the document says how secure development performance is reviewed and reported.
- Common finding: the policy requires a control, such as mandatory peer review or dependency scanning, that the pipeline does not enforce.
Before the interviews, check that every control the document promises has a named owner and a place where its output is recorded.
Sample testing checks whether practice matches policy. The assessor selects a set of recent changes and releases, then traces each one back through the repository, the review record, the pipeline run and the release approval. For each sample, the assessor asks whether the protections that the policy describes were active at the time of the change, not just today. Assessors typically request exports or screenshots of branch protection settings, the approval history for merged changes, and scan output tied to specific builds. The sample should cover both routine releases and emergency changes, since emergency paths are where controls are most often bypassed.
- Branch protection: direct pushes to protected branches are blocked, force pushes are disabled, and merges require the review the policy requires. Tools such as GitLab offer protected branch settings that can be checked directly.
- Review approvals: the approver is not the author, and the approval predates the merge.
- Scan results: static analysis and dependency results exist for the sampled build and were reviewed or acted on, not merely generated. Semgrep and Dependency-Track produce output that can be retained for this purpose.
- Bill of materials: each release has a software bill of materials that matches the components that were actually shipped.
- Common finding: branch protection was relaxed for an urgent fix and never restored, or scanners run in the pipeline but failures do not block the release.
Ask the team for the emergency change log before sampling, so the assessor can test those changes too.
Interviews test whether the people who build and release software understand the practices and follow them when no one is watching. The assessor speaks with a range of roles, including developers, reviewers, release owners and whoever handles vulnerability reports. The goal is to confirm that the process described in the documents is the process people actually follow, and to learn where they improvise. Assessors usually ask open questions about a recent change, then compare the answers with the sampled records. Inconsistent answers from different roles are a signal that the practice is not yet standard.
- Developers: they can describe the review and scanning steps for their own repositories without reading from a document.
- Release owners: they know which checks block a release and who may override them, and how overrides are recorded.
- Vulnerability handlers: they can explain how a defect found during development is triaged, tracked and closed before release.
- Maintainers of production software: they know how long-lived components are patched or retired, which connects to secure disposal of software.
- Common finding: release owners describe an override path that the policy does not mention, or developers are unaware that a scanner is required.
Prepare interviewees by sharing the sampled change list in advance, so answers can be tied to real records.
How to implement PR.PS-06 step by step
This sequence turns PR.PS-06 from a statement of intent into a working development process, where each step produces a document, a configuration or a record that shows secure development practices are built in and watched over time.
Define the secure development standard
Engineering leadership and security jointly write a short secure development standard that covers the languages, frameworks and pipelines the organization actually uses. It should name required practices for code review, dependency handling, secrets, static analysis, release approval and production maintenance, and state who owns each one. Confirm the scope with the teams that build and run the software, since a standard that ignores a language in use will not be followed. The output is an approved, versioned standard with named owners, and the step is done when every product team has acknowledged it.
Enforce protected branches and mandatory review
Platform engineers configure protected branches in the source control system so that only defined roles can push or merge to production branches. Direct pushes are blocked for most roles, and force pushes stay disabled unless explicitly approved. GitLab Community Edition supports these controls through its protected branch settings, so the team can apply them to each repository and branch pattern. The output is a configuration export or screenshot for each protected repository, and the step is done when a test push to a protected branch is rejected for a non-privileged account.
Add static analysis to the CI/CD pipeline
Engineers add a static analysis job to the build pipeline that runs on every merge request and on the default branch. Semgrep Community Edition supports a wide language set, including Java, JavaScript, TypeScript, Python, Go and Terraform, and can run community rules plus rules the organization writes for its own patterns. The team should decide which findings block a merge and which are reported for triage. The output is a pipeline definition and a baseline scan report for each repository, and the step is done when the baseline is recorded and a seeded test finding fails the job.
Generate and track SBOMs and dependency vulnerabilities
The pipeline generates a software bill of materials for each build, using a tool such as Trivy to list OS packages and software dependencies. The SBOM is uploaded to OWASP Dependency-Track, which consumes CycloneDX SBOMs and VEX, flags known vulnerabilities, outdated or modified components and license risk, and tracks licenses by SPDX identifier. Security staff review new high-severity findings and record a decision on each. The output is a stored SBOM per release and a triage log, and the step is done when a release's components are visible in the portfolio view with an assigned owner for each open finding.
Define release criteria for known vulnerabilities
The security lead and product owners agree release gate criteria that state which known vulnerabilities block a release, which may ship with a documented exception, and who approves an exception. The criteria should reference the scan and SBOM outputs from earlier steps so that the decision can be checked later. This is where the organization decides what "minimal known vulnerabilities" means for its products. The output is a written release gate policy and a template for exception records, and the step is done when a release candidate is evaluated against the gate and the decision is stored with its evidence.
Set up secure maintenance and disposal of production software
Operations and development teams define how production software is kept current and how it is retired. This covers the process for applying patches, the criteria for replacing container instances, the review of end-of-life components, and the steps for decommissioning an application, including removal of data, credentials and pipeline access. Links to the related sibling topics on software maintenance and configuration management help keep these processes consistent. The output is a maintenance and decommissioning runbook, and the step is done when at least one retirement has been carried out and documented against that runbook.
Measure performance with recurring reports
The security lead reviews a short recurring report that covers the metrics the program has chosen, such as how many merges passed the gate, how many scan findings were triaged, how many open vulnerabilities exceed the release criteria, and how many exceptions were approved. Leadership uses the report to adjust the standard, the rules or the release criteria. Confirm the metric definitions with the teams first so that the numbers mean the same thing across products. The output is a dated metrics review record with recorded actions, and the step is done when a review has produced at least one documented change to the program.
Evidence that satisfies PR.PS-06 and how to keep it current
PR.PS-06 asks whether secure development practices are built into the software life cycle and whether their performance is monitored. The cards below list the artifacts that show this, from the written standard to leadership metrics, and how to refresh each one between assessments so the evidence reflects current practice rather than a single snapshot.
Written secure development standard
A dated, approved document that states which secure development practices apply to organization-developed software, who owns them and how exceptions are granted. Assessors compare it with what teams actually do, so check that the standard names the tools in use, such as branch protection, static analysis and SBOM generation. Review it at least once a year and record each approval with its version and date.
Protected branch and review settings
Exports of branch protection settings show who can push or merge to production branches, whether direct pushes are blocked and whether force pushes are disabled. In GitLab, protected branches let maintainers restrict push and merge roles and block direct pushes by setting push access to no one. Export these settings on a schedule and keep the dated files, because a setting changed after an audit window can be hard to prove.
Static analysis reports and triage records
Scan reports from each pipeline run show what was checked and what was found. Assessors also want the triage record: who reviewed each finding, whether it was fixed, accepted with a reason or marked as a false positive. Semgrep Community Edition can run in CI/CD and scan repositories continuously, so confirm which languages in your estate it covers before relying on it as the sole scanner.
SBOMs generated for each release
A software bill of materials for every released version lists the components it contains, in a machine-readable format such as CycloneDX. Keep one per release, linked to the build identifier, so you can show what shipped at any point in the assessment period. Trivy can produce SBOMs from a target and scan existing ones, which helps confirm that the file matches the deployed artifact.
Vulnerability and license tracking records
Records from a component tracker show which known vulnerabilities, outdated or modified components and license risks were found, and what happened to each one. OWASP Dependency-Track consumes and produces CycloneDX SBOMs and VEX and tracks license use by SPDX identifier. Export its findings and decisions monthly so the history shows time to remediate, not only the current backlog.
Release gate approvals and decommissioning records
Each production release should have a recorded gate decision that names the approver, the checks passed and any accepted risk. When software is retired, keep a decommissioning record that shows removal from production, data disposal and revoked credentials, as PR.PS-06 expects production software to be maintained and disposed of securely. Retain pipeline logs for the full assessment period so approvals can be traced to the commits they cover.
What meeting PR.PS-06 costs in money and effort
This table lists each cost component of meeting PR.PS-06, who is paid for it, whether it is one-time or recurring, and what moves it up or down. Use it to build a quote request. The main takeaway is that open-source scanners remove license spend, but engineering, triage and evidence work remain the larger and recurring costs.
| Cost component | One-time or recurring, and who pays | What drives it up or down | What to ask for in a quote |
|---|---|---|---|
| Defining the secure development standard and configuring pipelines | One-time. Internal engineering time, plus any partner time for scoped setup | Number of repositories and languages, branch model, existing CI/CD maturity, and how many teams must adopt the standard | Itemized list of pipelines to configure, branch protection settings to apply, and the documented standard the partner will deliver |
| Scanner and SBOM tooling | Open-source licenses carry no license fee. Hosting, compute and staff time to operate remain | Scan frequency, repository count, size of build artifacts, and whether scanners run on shared or dedicated runners | Confirmation of the self-hosted architecture, hosting assumptions, and who maintains rule sets and tool versions |
| Ongoing triage of scanner and dependency findings | Recurring. Internal developers and security staff, or a retainer if outsourced | Volume of findings, false positive rate in your code, vulnerability disclosure volume for your dependencies, and clear severity thresholds | Expected triage workflow, who approves exceptions, and the service levels the partner commits to in writing, if any |
| Evidence upkeep for PR.PS-06 | Recurring. Internal compliance or engineering staff, with partner support if contracted | Number of applications in scope, frequency of releases, and how automatically logs and reports are kept | Which records are produced for each release, retention period, and where evidence is stored and reviewed |
| External penetration testing or code review | Variable and quoted separately. Paid to the testing provider | Application count, codebase size, architecture complexity, and whether the test covers pre-release or production builds | Written scope, methodology, deliverables, retest terms, and whether findings feed back into the pipeline controls |
| Auditor sampling effort | Per assessment. Internal staff time to produce samples, plus auditor fees | Number of releases sampled, how easily pipeline records can be retrieved, and whether the auditor reviews evidence once or repeatedly | Auditor's sampling approach and the evidence list they will request before fieldwork begins |
Who owns PR.PS-06 and what can be outsourced
Your organization owns PR.PS-06. NIST CSF 2.0 describes an outcome, not a tool, so the decisions about how secure development is practiced, what counts as acceptable risk and when a release may ship stay with your leadership and engineering managers. No partner or auditor can make those decisions for you, and an assessor will ask who made them and whether the decision was recorded.
- Standard and policy: Define the secure development practices your teams must follow across the software development life cycle, and assign an owner who reviews them.
- Pipeline decisions: Decide which checks gate a merge or release, such as code scanning, dependency review and SBOM generation, and who may override a failed gate.
- Risk acceptance: Record who accepts residual vulnerabilities, for how long and under what compensating controls.
- Release approvals: Name the roles that approve production releases and keep the approval trail where an assessor can sample it.
- Performance monitoring: Decide which metrics you track, such as open findings by severity, and how often leadership reviews them.
Before engaging any outside party, confirm that these owners exist by name and that the decisions above are written down.
An implementation partner prepares the systems and evidence that your team's decisions depend on. DeployOpen, for example, plans, configures and documents self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks, and runs security testing under written scope. A partner does not set your risk appetite, approve your releases or certify your program.
- Tooling configuration: Set up self-hosted source control rules, such as protected branches that block direct pushes to the main branch, and scanning in CI/CD pipelines.
- Evidence exports: Build repeatable reports and exports that show scans ran, findings were triaged and releases passed gates.
- Readiness review: Compare your practices against the PR.PS-06 Implementation Examples and the informative references your assessor will use, and list gaps.
- Optional testing: Run application or pipeline security testing under a fixed-scope agreement, with scope, deliverables and timelines agreed in writing before work starts.
- Documentation handover: Deliver runbooks so your staff can operate the tooling after the engagement ends.
Ask for a written scope that names each deliverable and states that the partner does not issue audit reports or certifications.
An independent auditor, assessor or certification body tests the evidence and issues any report or certificate. NIST states that it does not offer certifications or endorsements of CSF implementations or services, so a CSF 2.0 claim is backed by an assessment you commission, not by a NIST badge. The assessor samples your pipeline records, release approvals and risk acceptances and forms its own conclusion.
- Test design: The assessor chooses samples and procedures, which you do not control.
- Evidence testing: Expect requests for scan results, branch protection settings, SBOMs and records of who approved each release.
- Independence: A firm that configured the tooling and built the evidence exports may face a conflict if it also attests to them, so many organizations separate these roles.
- Reporting: Only the assessor issues findings, reports or attestations.
- Selection: Confirm the assessor's qualifications and whether its scope fits your framework use, since CSF is voluntary for most organizations.
Before hiring any assessor, ask how it handles independence when the same organization has helped build the evidence.
Questions teams ask about PR.PS-06
How long does it take to implement PR.PS-06?
The duration depends mostly on how many repositories, pipelines and release paths the organization runs and how much of its secure development practice already exists. A team with a single product, a protected main branch and a CI pipeline that already runs tests has far less to do than one with dozens of services, undocumented release steps and no record of who approved production changes. The main drivers are the number of in-scope code bases, the maturity of the existing review and release process, whether vendor or contractor code is involved, and how much evidence must be produced for an assessor. Ask any implementation partner for a written scope that lists the repositories, pipelines and deliverables before agreeing to a timeline, because a fixed scope is the only reliable basis for a schedule.
Can a small team implement PR.PS-06 in-house?
Often yes, if the team has at least one person who can own the secure development process and the tooling runs inside the existing development workflow. The core work is practical: protect the main branches so changes go through review, run static analysis and dependency checks in CI, generate a software bill of materials for each release, and write down how the team decides what ships. Small teams usually struggle less with tools than with consistency, such as keeping review rules enforced when a deadline is near and deciding who triages scanner findings. An outside partner can help with setup and documentation, but the organization still owns its controls and must run them day to day.
What does PR.PS-06 require from developers and security staff?
Developers carry most of the day-to-day work, and security staff set the rules and check that they are followed. Developers need to follow the branch and review process, fix findings from code and dependency scans, and keep their dependencies current. Security staff need to define which checks block a merge and which only report, decide how exceptions are approved and recorded, and review trends so the program improves over time. The subcategory also asks that secure development performance be monitored, so someone must own the metrics, such as how many findings are open past their agreed window. Name these owners in writing before the work starts, since unowned findings are the most common reason the evidence looks weak.
Does NIST CSF 2.0 require a certification for PR.PS-06?
No. NIST does not certify organizations, products or services against the Cybersecurity Framework and has no plans to create a conformity assessment program. Alignment with PR.PS-06 is shown by the organization's own documented practices and evidence, which an independent assessor may review if the organization or a customer asks for it. Some customers and contracts may still require a specific third-party report or certificate, so confirm with the requesting party which format they accept. Any firm that offers a CSF certification should be questioned closely on what it actually issues and who recognizes it.
What does an assessor ask for first on PR.PS-06?
An assessor usually starts by asking how secure development is defined and where it is written down, then asks to see it working on real repositories. Expect requests for the written development and release procedure, a list of in-scope repositories, branch protection settings, a sample of recent merge requests showing review approvals, CI pipeline logs from the static analysis and dependency checks, and recent SBOMs tied to released versions. They will also look for records of how findings were triaged, how exceptions were approved, and how the team reviews these results over time. Assemble these artifacts before the assessment rather than during it, and confirm the exact evidence list with the independent assessor.
Is an SBOM or static analysis mandatory for PR.PS-06?
NIST CSF 2.0 is outcome-based and does not name specific tools, so neither an SBOM nor static analysis is literally mandatory under the framework. The outcome asks that secure development practices are built into the life cycle and monitored, and both tools are common ways to meet it. The informative references point to ISO/IEC 27001:2022 Annex A controls and NIST SP 800-53 system and services acquisition controls, which address secure development and component tracking in general terms. Whether a specific tool is required in practice depends on the framework or customer contract that applies, so confirm that requirement in writing with the party asking for alignment. Open-source options such as Semgrep for code scanning, Trivy for SBOM generation and OWASP Dependency-Track for tracking components are widely used, but the organization should choose tools based on its own stack and evidence needs.
Where secure software development programs usually fall short
The most common shortfall under PR.PS-06 is a secure development practice that exists in a policy document but is not enforced by the pipeline. A team may say that code is peer reviewed and that releases are scanned, yet nothing stops a maintainer from pushing straight to the main branch or a force push from rewriting history. To close this gap, configure the repository's protected branches so that the push access level for the main branch is set to no one, force pushes stay disabled, and merges require the review roles your policy names. In GitLab Community Edition, these are set in the protected branch settings, and the configuration itself should be exported or screenshotted as evidence. Assign a named owner for the settings, and review them whenever repository permissions change, because a setting that drifts silently produces no audit trail that anyone notices. A second gap appears when scanners run on every merge request but nobody owns the results. Semgrep Community Edition and Trivy can both run in CI/CD, and their output can fill a dashboard that no one reads. Findings then age without decisions, and an assessor asking how a flagged issue was handled finds no record. Close this by assigning a triage owner for each scanner, defining which severities block a merge and which are logged for review, and recording each suppression with a reason and an approver. Ask your team to confirm how long a triage decision is allowed to stay open before it is escalated. Those answers, not the scanner output itself, are what show the practice is performed. The third and fourth gaps concern what leaves the build. Many programs produce no software bill of materials for released artifacts, so when a dependency is later reported as vulnerable, the team cannot say which releases contain it. Generate a CycloneDX SBOM for each released artifact, using a tool such as Trivy, and load it into OWASP Dependency-Track, which can track known vulnerabilities, outdated components and license risk per release. Separately, many release decisions proceed without written vulnerability criteria. Define the thresholds in advance, such as which unresolved severities or known-exploited findings prevent a release, and record the exception process. Confirm with your security lead who may approve an exception and how it expires. The final gap is end of life: production software is often left running long after support ends, with no step for retiring it or disposing of its data. Add a decommissioning checklist to the release process that records when a version leaves support, who removes it, and how its data and credentials are destroyed.
Open-source tools that produce PR.PS-06 evidence
Four open-source tools can each leave evidence for PR.PS-06, but none of them proves the outcome by itself. GitLab Community Edition covers the protection of code and build inputs. Its protected branches let maintainers restrict which roles can push or merge to a branch, block direct pushes by setting push access to no one, and keep force pushes disabled unless someone explicitly allows them. Exporting branch protection settings and merge request approval history gives an assessor a dated record that changes to production-bound code went through review. The tool is licensed under MIT, which permits internal use and modification without a copyleft obligation on your own code. Confirm that Community Edition offers the protection settings your process depends on, since feature sets differ between editions.
Semgrep Community Edition, licensed under LGPL-2.1-only, scans source code for insecure patterns and can run inside CI/CD pipelines so every repository is checked on each change rather than sporadically. Its documented language list includes C/C++, C#, Go, Java, JavaScript, TypeScript, Python, Ruby, Rust, PHP, Kotlin, Swift and Terraform, and it supports custom rules. Before you rely on it, confirm that your languages and frameworks are covered by the community rules or that your team can write the custom rules needed. Keep the pipeline logs and the rule set under version control, because an assessor will ask which checks ran and which findings were triaged. The LGPL-2.1-only license has terms on distributing modified library code that your legal team should review if you change the tool itself.
OWASP Dependency-Track (Apache-2.0) and Trivy (Apache-2.0) cover the software supply chain side. Dependency-Track consumes and produces CycloneDX software bills of materials and VEX documents, flags components with known vulnerabilities, outdated or modified components and license risk, and tracks license use by SPDX identifier. Trivy identifies OS packages and software dependencies in a target, can generate them as an SBOM, and can scan existing SBOMs. Together they give a repeatable record of what shipped in each release and when its vulnerability status was reviewed. Ask your engineering lead to confirm which artifact types (container images, binaries, infrastructure code) must be inventoried, and to decide who triages Dependency-Track findings and within what internal timeframe. The Dependency-Track documentation is the natural next read for setting up that workflow.
Official sources to read before scoping PR.PS-06
Before you scope PR.PS-06, read the NIST text that defines the outcome, the machine-readable mapping that links it to other standards, and the transition record that shows what it inherited from CSF 1.1. The GitLab branch protection documentation shows one concrete way a platform can enforce part of the outcome.
CSF 2.0 Core in Appendix A
Appendix A of NIST CSWP 29 is the authoritative text for PR.PS-06 and its neighbors in the Platform Security Category. Read the Subcategory outcome as the test an assessor will apply, then compare it with your own Current Profile. Note that the outcome covers secure development practices across the whole software development life cycle and asks whether their performance is monitored. Your scope should state which internal and third-party software teams the outcome covers, since an assessor will ask how each one is included.
Reference Tool export for PR.PS-06
The Reference Tool export lists the Implementation Examples and informative references attached to PR.PS-06, including SP 800-53 Rev. 5.2.0 controls, ISO/IEC 27001:2022 Annex A controls, SP 800-171 Rev. 3 and CIS Safeguard 16.1. Use it to build an evidence map so one artifact can answer several frameworks. Confirm each mapping against the source framework before you rely on it in a customer or regulator response, because informative references are pointers, not equivalence claims.
CSF 1.1 to 2.0 transition spreadsheet
NIST's transition spreadsheet shows that PR.PS-06 absorbs part or all of CSF 1.1 PR.IP-2. If your existing assessment used PR.IP-2 for development lifecycle work, this record shows where that evidence now belongs. Check each prior answer against the new Subcategory text rather than carrying it forward, since the wording and scope differ. Record the transition decision in your assessment file so a reviewer can trace how a 1.1 answer became a 2.0 answer.
GitLab protected branches documentation
Protected branches are one way to enforce the controls that PR.PS-06 implies for code integrity. Maintainers can restrict which roles push or merge, block direct pushes by setting push access to no one, and keep force pushes disabled unless explicitly allowed. Confirm the settings your version of GitLab Community Edition supports, then test them on a non-production project. Record the branch protection configuration as evidence, and export it on a schedule so an assessor can see the state over time.
