NCCoE's notional DevSecOps model gates every promotion between its seven phases

A control gate, in the NCCoE's wording, is a set of technical or organizational controls designed to provide the feedback or insights that help inform development, operational, or security tasking for resolving discovered vulnerabilities or defects ^[10]. Taken literally, that definition admits a static analyzer that fails a build and a review meeting that signs one off. Placement is what makes it a gate: the controls are applied before software changes are permitted to proceed to the next stage in the lifecycle ^[9].

The environment count is the first adoption cost. The model says each phase is a logical stage and a separate environment ^[8]. The phases it names are Plan, Develop, Build, Test, Release, Deploy and Operation ^[6], which is seven phases and therefore seven environments ^[7]. Build and Test go further, both calling for ephemeral environments: automated pipelines turning code and configuration into deployable artifacts in Build ^[13], independent evaluation of those artifacts in Test ^[14]. A team running one shared staging environment and a production account cannot map itself onto this drawing without standing up more environments first. I would expect most of the work of adopting this to be environment plumbing rather than scanner selection.

Nobody has published the part an assessor would want. The project interpreted the SSDF's recommended security practices with the objective of decomposing them into more granular and actionable tasks ^[3], and it did so because the SSDF does not provide a specific software development architecture ^[2]. The concrete connections between the technologies and activities in the example implementations and the SSDF proper are deferred; the page says future versions of the document will document and justify them ^[4]. So the model gives you the shape of a pipeline today, and the mapping from each gate to an SSDF task is yours to write. For this to work as an audit artifact, every gate would have to name the practice it satisfies and the evidence it emits, phase by phase. The lifecycle is one of five functional dimensions the model defines ^[5].

The model was assembled from the technologies the collaborators had, so it cannot be read as a standard. The project constructed its software factories bottom-up, from the technologies made available through its collaborators and group consensus on essential components ^[12], and the model was developed and refined in conjunction with those collaborators ^[1]. The documentation is direct about the limit: "This model is not intended to be a one-size-fits-all solution, but rather a guide for software development efforts," it says ^[11]. It also states that the concrete activities, technologies, and processes used can differ substantially between organizations, and even between groups within an organization ^[18].