03.16.01 Security engineering principles: requirements and evidence

What 03.16.01 security engineering principles requires in NIST 800-171 Rev. 3

If you have just found 03.16.01 Security engineering principles in Rev. 3 and cannot locate it in Rev. 2, you are not missing anything. It is one of the 19 requirements NIST added in Rev. 3, and NIST maps no Rev. 2 requirement to it. That gap matters for CMMC Level 2, which still assesses the 110 Rev. 2 requirements, so the requirement has no matching CMMC practice ID. The requirement itself asks your organization to apply systems security engineering principles when it develops or modifies the system and its components. The principles are not written into the requirement. You choose them, document them and then follow them.

That choice is the organization-defined parameter (ODP). Rev. 3 leaves the list of principles to you unless a federal agency or contract specifies values, and if no values come from the agency, the nonfederal organization must assign them to complete the requirement. Practically, this means writing a short, approved set of engineering principles, such as secure defaults, least privilege in service design, input validation, and secure handling of secrets, and tying each one to the development and change steps where it applies. Confirm with your contracting officer whether any ODP values have been published for this requirement before you write your own. The requirement is at risk when components are built without an agreed standard, because insecure design choices made early are costly to fix later and can persist into every system that inherits them.

This requirement is hard to evidence because it describes a process, not a configuration. An assessor will examine your acquisition and development policy and procedures, interview the people who write requirements, buy components and review changes, and test whether the principles are actually applied in real development work. A written list of principles alone will not satisfy that test. Keep records that show the principles in use, such as design review notes, threat model outputs, peer review checklists or code scanning results from your pipeline. Tools like GitLab protected branches and Semgrep scans in CI/CD can supply part of that trail. Ask your assessor early which artifacts they will accept, because the evidence for this requirement is largely your own.

Which systems, teams and third parties 03.16.01 applies to

03.16.01 applies wherever the organization develops or modifies a system or its components, and the system in question is one that stores, processes or transmits CUI. The cards below separate the scoping decisions that determine how far the requirement reaches, from the people who make those decisions.

Systems that handle CUI

Start with the systems that store, process or transmit CUI, including the components that support them such as identity services, logging pipelines and build servers when they touch that data path. Changes to these systems fall under the requirement. Document the boundary in the system security plan so an assessor can see which development and change activities it covers. Ask whether a system outside the CUI boundary can still affect CUI through shared credentials or networks.

In-house development and modifications

Custom code, scripts, infrastructure-as-code and configuration templates written by the organization are the clearest case. The requirement also covers modifications to existing systems, such as adding an integration, changing an authentication flow or altering an access rule. Record which security engineering principles the team applies to each kind of change, so the practice can be shown for both new builds and routine updates.

Purchased and open-source software

Commercial products and open-source components are not automatically out of scope because someone else wrote them. When the organization selects, configures, customizes or extends a purchased or open-source platform, it is modifying a system component and the principles it applies should be documented. Confirm with each vendor what security engineering work it performs, and separate that from what the organization must still do during integration.

Configuration changes to live systems

Configuration changes can modify a system as much as code changes do. Firewall rules, identity policies, encryption settings and logging parameters on systems that handle CUI are candidates for review under the requirement. Decide which changes go through a formal design or security review and which are routine, and write that threshold down. Ask how emergency changes are reviewed after the fact.

Acquisition and contracting personnel

The requirement is not limited to engineers. Personnel who write statements of work, evaluate bids and negotiate software contracts shape what security engineering work a supplier must perform. Include them in the scope so that security expectations are written into procurement documents before development begins. Assessors commonly interview these roles when testing the requirement.

Security and development testing

Personnel with information security responsibilities review designs, threat models and test results for changes to CUI systems. Their role is part of the scope because the principles must be applied during development, not only audited afterward. Static analysis tools can support this work. Semgrep Community Edition scans many languages and can run in CI/CD pipelines, but the organization must still decide which findings block a release.

Choosing the principles you define for your organization

NIST does not assign the value of the organization-defined parameter (ODP) in 03.16.01, so the choice of systems security engineering principles falls to you unless a federal agency specifies them. If the contracting agency has named principles, those become your requirement. If it has not, the nonfederal organization must assign the value itself, because the requirement cannot be complete without it. Treat this as a decision that belongs to the organization, not a formality to fill in later, and record who approved the choice and when.

A workable principle set is short, named and tied to what your teams actually build and change. Start from the systems that handle CUI and list the development and modification activities they go through, such as new application features, infrastructure-as-code changes and third-party component updates. For each activity, name the principles you will apply and the point in the lifecycle where they are checked, for example a threat review before design approval or a security test gate before merge. Write the set in your system security plan or a referenced engineering standard, with an owner, a review cycle and a version number. Do not copy principle lists from outside sources without reading them, and keep your own wording so that an assessor can trace each principle to something a team does.

The assessment procedure in SP 800-171A Rev. 3 checks that the ODP is defined, so a blank or vague value will fail before anyone looks at practice. Ask your contracting officer or prime contractor, in writing, whether the agency expects specific principles or a specific published set, and whether it will provide ODP values for the requirement. If the answer is unclear, document your assumption and confirm it before the assessment. Your implementation partner can help draft the principle set and map it to your development pipeline, but the organization must approve the values and own the evidence that they are applied.

How an assessor tests 03.16.01 under SP 800-171A Rev. 3

This table breaks down how an assessor works through 03.16.01 in SP 800-171A Rev. 3, covering the determination statements, the three assessment methods and the example objects for each. Read it as a checklist of what to prepare: the assessor looks for a defined principle set, evidence that the principles were applied to real development or change work, and people who can explain how they are used.

Assessment element	What the assessor checks	Evidence to prepare
Determination statement (principles applied)	The organization applies its defined systems security engineering principles when it develops or modifies the system and its components.	A dated principle set, plus sample design, code review or change records showing the principles were applied to specific changes.
ODP check (principle set defined)	The organization-defined parameter that names the security engineering principles has a defined value, since the assessment checks that the value is set.	A approved document listing the named principles and the scope of systems and components they cover.
Examine method: policy and procedures	Whether a system and services acquisition policy and procedures exist and address security engineering principles in development and modification.	Signed policy, procedures that reference the principle set, and revision history showing owner approval.
Interview method: acquisition and security staff	Whether personnel with acquisition or contracting duties and personnel with information security duties can describe the principles and their role in applying them.	Named owners, role descriptions and a short walkthrough that matches the written principles.
Test method: development and modification processes	Whether the processes that apply the principles operate in practice during system development and change.	Pull request or change tickets with security design review, threat modeling notes or security gate outcomes.
Common finding: policy only	A principle set exists on paper but no records show it was used when building or changing the system.	Sample changes from the audit period that cite each applied principle, not a blanket statement.
Common finding: principles not scoped	The principles do not state which systems, components or in-house and vendor-built software they cover.	A scope statement that names the in-scope system boundary and any third-party components it includes.

How to implement 03.16.01 in the order that produces evidence

This sequence turns the organization-defined security engineering principles into an approved standard, then into lifecycle gates, tooling records and trained people, so that each step leaves an artifact an assessor can examine, interview against and test.

Define and approve the security engineering principles
Because 03.16.01 has an organization-defined parameter, the organization must write down which systems security engineering principles it applies to development and modification. Security leadership drafts the list, and the system owner, engineering leads and the authorizing official or equivalent approver sign it off. Keep the list short enough that engineers can apply it to a pull request. The output is an approved principles document with a version number, an owner and a review date. You know this step is done when the ODP value is defined in the document and the system security plan points to it.
Write the acquisition and development policy and procedures
Connect the approved principles to the written policy and procedures for system and services acquisition, which the assessment reviews first. Name who applies each principle, at which lifecycle stage, and who can waive one. Cover both new development and modifications to existing components, since 03.16.01 applies to both. The output is a policy and a procedure that reference the principles document by version. Confirm that personnel with acquisition, contracting and security responsibilities have read and accepted them, and keep the acknowledgments.
Embed the principles in the change and design gates
Add a design review checklist to the development lifecycle that asks, for each change or new component, how each approved principle was applied and what decision resulted. Engineers complete it in the ticket or design record, and a reviewer who is not the author signs it. Where a principle is not applicable to a change, the record states why. The output is a checklist template and a set of completed reviews tied to real changes. Pick a sample of recent changes and confirm each one has a completed record before calling the gate operational.
Configure repository protections that enforce the workflow
Use protected branches so that changes reach the main line only through reviewed merge requests. In GitLab Community Edition, restrict which roles can push or merge, set push access to no one for protected branches to block direct pushes, and keep force pushes disabled unless explicitly allowed. These settings make the review gate in the previous step technically hard to bypass. The output is an exported or screenshotted configuration showing the protected branch rules, plus a record of who holds merge rights. Confirm the settings against the platform documentation for your version, since names and defaults can change.
Add automated code scanning to the pipeline
Run static analysis in the CI/CD pipeline on every merge request so that scanning is continuous rather than occasional. Semgrep Community Edition (LGPL-2.1-only) supports languages including C/C++, C#, Go, Java, JavaScript, TypeScript, Python, Ruby, Rust, PHP, Kotlin, Swift and Terraform, and can use community rules or custom rules that encode your principles, such as banning unsafe defaults. Confirm the languages your codebase uses appear in the supported list. The output is pipeline configuration, a rule set mapped to principles and scan logs or reports retained for each build. Define in writing how findings are triaged and who may accept a risk.
Train personnel with acquisition and security roles
Deliver role-specific training to the people who apply the principles: engineers and reviewers, personnel with acquisition or contracting responsibilities, and personnel with information security responsibilities. Cover the approved principles, the design checklist, the protected branch rules and how scan findings are handled. The output is training materials, attendance records and short assessments or attestations, each tied to a named person and date. Repeat training when the principles document changes, and confirm the records cover the staff who actually review changes, not only the team that wrote the policy.
Record outputs and keep evidence current
Assemble one evidence folder for 03.16.01 that holds the principles document, the policy and procedures, sample completed design reviews, protected branch configuration, pipeline scan records, training records and any exception approvals. Note the owner and retention period for each artifact, and map each to the examine, interview and test objects that the assessment procedure names. Review the set on a schedule and after any change to the principles. The output is a dated evidence index that an assessor can walk through. The step is complete when someone outside the project can locate each artifact from the index in a few minutes.

Using GitLab and Semgrep as evidence sources for secure change control

Protected branches are one way to show an assessor that changes to system code pass through a controlled path. They do not decide which engineering principles apply, and they do not replace the organization's own development policy. Their value is that the settings are explicit, reviewable and recorded, so the organization can show who was allowed to change a branch and how that permission was enforced. GitLab Community Edition (MIT) includes protected branches, which is the feature to confirm against your version.

Role-restricted push and merge: Limit which roles can push to or merge into a branch, such as keeping production branches for maintainers only.
Blocked direct pushes: Set push access to no one on release branches so that all changes arrive through reviewed merge requests.
Force pushes disabled: Keep force pushes off unless a specific branch explicitly allows them, so history cannot be rewritten quietly.
Settings history: Export or capture the protected branch configuration at each review cycle so the assessor can see the control state over time.
Audit trail of merges: Retain merge request records that show the approver and the pipeline result for each change.

Confirm with your platform team that the branch rules are applied to every repository in scope, and that administrators cannot override them without a logged exception.

Evidence that passes an assessment for 03.16.01

An assessor testing 03.16.01 looks for a defined set of principles, written procedures, proof that the principles shaped real changes, and people who know them. The cards below cover six artifacts, what each must show, and how to keep it current between assessments so the evidence reflects how the system is built today.

Approved ODP principles document

This is the organization-defined parameter itself: the named systems security engineering principles your organization applies to development and modification. Because NIST does not assign ODP values, the document is where your organization records its choices, with an owner, an approval date and a version. Check that the list is specific enough to test, such as named design principles rather than a general statement of intent. Review it at least once a year and whenever the system architecture or development model changes.

Policy and procedures for principle use

Assessors examine the system and services acquisition policy and the procedures that address security engineering principles during development and modification. The procedures should say who applies the principles, at which stage of a change, and what record is produced. Confirm that the policy names the approved principles document and that staff can find the current version. Update the procedures after tooling changes, such as a new code review step or a new pipeline stage, so the written process matches what engineers actually do.

Design and review records for changes

This artifact shows that the principles were applied to a specific change, not only documented. Keep design notes, architecture decision records or security review tickets that cite the principles relevant to the change and record the outcome. A useful check is to pick a recent system modification and trace it from the request to the record that shows the principles were considered. Records that name a principle and the decision taken carry more weight than a generic sign-off.

Protected-branch settings exports

Protected-branch settings show that the change path enforces the review and access decisions described in the procedures. Export the configuration for each branch that carries production code, showing which roles can push or merge, whether direct pushes are blocked, and whether force pushes are disabled. GitLab Community Edition supports these settings, and the export should be captured on a schedule or at each assessment so the assessor sees the state at a known date. Confirm the exported settings match the approved procedure.

Scan reports with triage records

Static analysis output supports the claim that code is checked against the chosen principles during development. Semgrep Community Edition can run in CI/CD pipelines across many languages with community or custom rules, so the reports can show each pipeline run. The triage record matters as much as the scan: for each finding, record whether it was fixed, accepted with a reason, or marked as a false positive, and by whom. Ask your team to confirm which rule sets map to your approved principles, since a scan without that mapping shows activity but not principle application.

Training records for acquisition and security staff

Assessors interview personnel with acquisition or contracting responsibilities and with information security responsibilities, so training records help show that those people know the principles and their role in applying them. Keep attendance, course content and dates for each person, and record refresher training when the approved principles change. Check that the people named in the procedures appear in the training roster, and that new staff in those roles are trained before they approve changes. Training records for contractors who develop or modify the system should be kept with the same rigor.

What meeting 03.16.01 costs in money and effort

This table breaks down the cost components of meeting 03.16.01 Security engineering principles, who is paid for each, whether it is one-time or recurring, and what drives it up or down. No figures are given because none were supplied, so use the right-hand column to write the questions to put in a quote.

Cost component	Who is paid, and one-time or recurring	Main cost drivers	What to ask for in a quote
Defining the principles	Internal architects and security staff, or an implementation partner. One-time, revisited on change.	Number of system types, existing design documentation, and how many ODP values the agency or contract specifies.	A written list of principles, owners, and the systems each principle covers, with hours by role.
Embedding principles in development	Engineers and platform staff, plus partner time for pipeline and template changes. Mostly one-time, then recurring as new services are added.	Number of repositories, pipelines, and development teams, and how much custom process is needed.	Which gates, templates, or review steps will change, and who will maintain them after handover.
Tooling and licenses	Vendors or open-source projects. Commercial licenses recur, while open-source tools carry no license fee but still need hosting and upkeep.	Choice of commercial or community editions, number of seats, and where the tools run in your environment.	License terms for each tool, hosting requirements, and whether the quote includes setup and version upgrades.
Evidence upkeep	Internal staff or implementation partner. Recurring.	Frequency of design reviews, change volume, and how well records are kept in the source control system.	Which records are produced automatically, which need manual sign-off, and how often they are reviewed.
External review or testing	Independent security testers or reviewers. Usually periodic, tied to major releases or assessments.	Scope of the system, the number of components, and whether the review covers the principles or only the code.	Whether the review tests that principles are applied, not only that scans passed, and what the report will contain.
Assessor time	The independent assessor is paid by the organization. One-time per assessment cycle, with follow-up for findings.	Number of systems in scope, how documented the principles are, and interview preparation.	The assessor's estimated hours, the assessment method (examine, interview, test), and what evidence they expect before fieldwork.

Which parts of 03.16.01 you can outsource and which you cannot

The organization owns 03.16.01 Security engineering principles from start to finish. The requirement asks you to apply organization-defined systems security engineering principles when you develop or modify the system and its components, and the choice of those principles is itself the organization's decision. An implementation partner can help you draft the principles, but the chosen set must reflect your architecture, your CUI workflows and your risk appetite, and an accountable executive must approve it. The same holds for the single organization-defined parameter (ODP) this requirement carries. NIST does not assign the value, and if your federal agency does not supply it, you must. Treat the ODP value as an internal governance decision that gets documented and signed off, not as a field a consultant fills in.

Much of the surrounding work can be outsourced. A partner can configure the development pipeline so that it enforces your principles: for example, protected branches in GitLab Community Edition that block direct pushes to main, with force pushes disabled, and Semgrep Community Edition running in CI/CD to scan repositories on each change. A partner can also set up evidence collection, such as retaining merge approvals, scan results and design review records in a predictable location, and write the procedures that describe how those records are produced. Ask for the configuration as code, a runbook for your own staff and a written list of which evidence each step generates. Confirm with the vendor which of these features your edition and version include before you commit to a design.

Only an independent assessor can state whether 03.16.01 is met. The assessment method in SP 800-171A Rev. 3 combines examining policy, procedures and records, interviewing personnel with acquisition and information security responsibilities, and testing the process itself, so an assessor will want to speak with your people and watch your change process in operation. A partner's readiness review does not substitute for that conclusion, and the assessment result for your environment is what your contracting agency relies on. Before you engage anyone, confirm which assessment your contract requires and who is authorized to perform it, and keep your own staff accountable for answering the interview questions accurately.

Who does what for 03.16.01: your team, a partner and the assessor

Your organization owns the requirement. 03.16.01 asks you to apply organization-defined systems security engineering principles when you develop or modify the system and its components, so the choice of principles, their scope and their approval sit with you, not with a vendor. Your security and acquisition staff decide which principles apply to which systems and write them into policy and procedure, which is the material an assessor will examine first.

Defining the principles: Select and document the systems security engineering principles, then assign a named owner who keeps them current.
Setting the ODP value: Record the organization-defined parameter in the system security plan so the requirement is complete on its face.
Approving changes: Decide who signs off on design and code changes that affect security, and how exceptions are granted and recorded.
Training engineers: Make sure developers, architects and contracting staff know the principles and can explain how they apply to their work.
Owning the evidence: Keep records of approvals, training and exceptions for the assessor to sample.

Before engaging anyone, check that your principles are written down, approved and tied to the system security plan.

Where organizations fall short on 03.16.01 and how to close it

Most shortfalls on 03.16.01 come from treating the requirement as a policy statement rather than an operating practice that must be defined, applied to change and evidenced. The cards below cover the gaps assessors most often find and a closing action for each. Each action is something the organization owns, with an implementation partner able to help prepare systems and evidence.

No defined organization-defined parameter

03.16.01 has one organization-defined parameter: the systems security engineering principles to be applied to development or modification. NIST does not assign this value, so if the federal agency or contract does not specify it, the nonfederal organization must. A blank or generic ODP fails the assessor's check that the value is defined. Close it by naming the specific principles in writing, such as secure design review, least privilege by default and input validation, and approving them under the system owner's authority.

Principles written but not applied to changes

A policy that lists engineering principles satisfies only the examine step. The requirement is applied when a system is developed or modified, so assessors look for evidence from a real change. Illustrative example: a firewall rule change or a new API endpoint that skips the principles checklist shows the principles are not operating. Close it by adding a short principles check to design reviews and change tickets, and keeping completed records for sampled changes.

Rev. 2 mapping assumed to cover it

03.16.01 is new in Rev. 3, and NIST maps no Rev. 2 requirement to it. Rev. 2's 3.13.2 covered architecture and engineering principles, but NIST recategorized it as not directly related to CUI confidentiality. An organization that reuses its Rev. 2 evidence for 03.16.01 has no matching requirement ID to point to. CMMC Level 2 has no matching ID either. Close it by confirming with the contracting agency which revision applies, then writing new evidence for 03.16.01 separately from the Rev. 2 set.

No evidence from acquisition staff

The assessment interviews personnel with acquisition and contracting responsibilities as well as information security staff. The security engineering principles reach into purchasing of custom development work and component changes. Teams often describe the principles only from the engineering side. Acquisition staff who cannot explain how principles reach contracts and statements of work leave an interview gap. Close it by adding a principles clause to statements of work and training acquisition staff to point to it.

Unmanaged direct pushes to protected branches

Direct pushes to a main branch skip any review of the code that changes the system. GitLab Community Edition supports protected branches that restrict which roles can push or merge, block direct pushes by setting push access to no one, and keep force pushes disabled unless explicitly allowed. A protected branch with open push rights does not show the principles were applied to the change. Close it by enabling protected branch settings on production branches, requiring merge requests, and checking the settings during periodic review.

Scan results never triaged

Semgrep Community Edition scans many languages, including Java, Python, Go, TypeScript and Terraform, and can run in CI/CD pipelines to scan repositories continuously. Findings that accumulate without triage show that the principles are not being applied at the point of change. Scanner output that no one reviews is not evidence of secure engineering. Close it by setting a triage owner, a severity threshold for blocking merges, and a dated record of accepted or fixed findings for each sampled change.

Questions buyers ask about 03.16.01 cost, effort and partners

Does 03.16.01 have a Rev. 2 equivalent?

No. NIST maps no Rev. 2 requirement to 03.16.01, because it is one of the 19 requirements new in Rev. 3. The closest Rev. 2 requirement, 3.13.2, called for architectural designs, software development techniques and systems engineering principles, but Rev. 3 recategorized that content as not directly related to protecting the confidentiality of CUI and withdrew it. CMMC Level 2 assesses the 110 Rev. 2 requirements, so it has no matching requirement ID for 03.16.01. Confirm with your contracting officer which revision applies to your contract before you scope this work, since the revision in force for DoD work has been changing.

Who must define the organization-defined parameter for 03.16.01?

The nonfederal organization must define it. 03.16.01 has one organization-defined parameter: the systems security engineering principles applied to developing or modifying the system and its components. NIST does not assign ODP values. If the federal agency that holds the contract does not specify them, the organization must assign them to complete the requirement. The assessor will check that the value is defined, so the principles chosen should be written down, approved by the accountable owner and tied to the system security plan. Ask the contracting agency whether it has published any values before you draft your own.

How much effort does 03.16.01 add to an existing program?

The effort depends mostly on how your organization already develops and changes systems. An organization with a documented secure development lifecycle, code review and change approval has a smaller gap than one that ships changes without a defined process. The main work is to choose and document the principles, write procedures that show how they are applied during development and modification, and collect records that show the procedures ran. NIST does not publish an hour or dollar estimate for this requirement, so ask any provider to base its estimate on a written inventory of your development and change processes.

Can open-source tools produce the evidence for 03.16.01?

Open-source tools can produce some of the technical evidence, but they do not replace the policy and process evidence. The assessment examines the acquisition policy and procedures, interviews acquisition and security staff, and tests the process for applying the principles. Source control and CI tooling can supply records of that process. For example, GitLab Community Edition protected branches can restrict which roles push or merge, block direct pushes and keep force pushes disabled, and Semgrep Community Edition can scan code in many languages in CI/CD pipelines. Confirm the license terms and feature set of each tool for your version before relying on it.

What does the work need from our internal staff?

Internal staff must own the decisions that an outside party cannot make for you. Acquisition or contracting personnel need to explain how they buy and change systems, and information security staff need to explain how they review and test them. Engineering leads must confirm how changes move from design to production. Someone accountable for the system security plan must approve the chosen principles and the procedures. A partner can draft documents, configure tooling and collect evidence, but the organization remains responsible for the controls and must be able to answer interview questions about them.

Can a consultant or implementation partner replace the assessor?

No. An implementation partner can prepare systems, configure tooling, write procedures and organize evidence, but it cannot issue an assessment result. For DoD contracts, a Basic Assessment is self-reported and submitted to SPRS by the organization, while Medium and High assessments are conducted by DCMA DIBCAC. The organization remains responsible for the accuracy of its own score and the controls it reports. Before you engage a partner, ask which parts of the work it will perform, what evidence it will hand over, and how it will support you during an assessment without claiming to make the assessment decision.

What drives the cost of meeting 03.16.01?

Cost is driven by the number and complexity of systems that change, the maturity of current development practices and how much evidence must be produced and kept. Costs are one-time for the initial design of principles and procedures, and recurring for reviews, tool licenses or subscriptions, and periodic evidence collection. A written quote should separate scoping, documentation, tooling configuration, evidence collection and support, and should state which items are fixed and which depend on assumptions about your environment. The contracting agency's ODP values, if published, may also change the amount of work.

How DeployOpen scopes and prepares 03.16.01 evidence

Before any work starts, DeployOpen agrees a fixed scope in writing with the client, covering which systems, development pipelines and teams the 03.16.01 work touches, the deliverables, and the timeline. For this requirement, the scope decision that matters most is which systems-security-engineering principles the organization will define as its ODP value, since NIST leaves that assignment to the organization when the federal agency does not specify it. DeployOpen can help draft the principles, but the organization owns the choice and its approval. Quotes follow from this written scope, and DeployOpen does not publish a price list.

Once scope is agreed, DeployOpen configures self-hosted tooling inside the client's own environment, whether that is their cloud account, data center or air-gapped network. On the repository side, that typically means GitLab Community Edition with protected branches set so that direct pushes are blocked for most roles and force pushes stay disabled, which produces records of who can change code that goes into production. On the code side, Semgrep Community Edition can run in CI/CD pipelines with custom rules that reflect the agreed principles. Confirm with the client's security team which languages and rules apply, because the supported language list determines whether every component in scope can be scanned.

DeployOpen prepares the evidence package, including the approved principles, pipeline and branch configuration exports, scan configuration and sample scan results, and records of who approved the principles and when. DeployOpen does not issue audit reports, attestations or certifications. An independent assessor or certification body makes that determination, and the organization owns its control. Ongoing support, upgrades and continuous testing are available as retainers, which suits clients whose principles and tooling will change with each release cycle.