9.4 CI/CD, Source Control, and Environment Separation

Protecting The Delivery System

Source control and CI/CD platforms are high-value systems because they can change production software at scale. If an attacker or careless insider can alter code, pipeline configuration, dependencies, or deployment credentials, they may bypass many downstream controls. A CISSP should treat the software delivery path as critical infrastructure, not as a convenience tool owned only by developers.

Source control governance starts with identity and access. Developers should use individual accounts with MFA. Shared accounts weaken accountability. Branch protection should require review for sensitive branches, prevent unauthorized force pushes, and preserve history. Signed commits or tags may be appropriate for high-assurance systems. Administrative rights to repositories should be limited, monitored, and periodically reviewed.

CI/CD pipelines should be designed with least privilege. A build job that compiles code rarely needs production database access. A test job should not hold keys that can deploy to production. Secrets should be stored in approved secret management systems, injected only when needed, masked in logs, rotated, and scoped to the job. Pipeline configuration should be reviewed like application code because it controls how software is built and deployed.

Automated checks are valuable because they make standards consistent. A pipeline might run unit tests, SAST, SCA, linting, infrastructure-as-code scanning, container image scanning, secret detection, license checks, and policy-as-code rules. The leadership question is which checks are mandatory, which are advisory, who can override them, and how overrides are recorded. A noisy scanner that everyone bypasses is weak governance.

Environment separation prevents development convenience from becoming production exposure. Development environments may allow experimentation, but they should not contain unrestricted production data. Test environments should use synthetic, masked, or minimized data unless a formally approved exception exists. Staging should resemble production closely enough to validate deployment and configuration, but access should still be limited. Production should have the strongest change control, monitoring, and data protection.

Separation is not only network segmentation. It includes separate credentials, keys, data stores, service accounts, administrative groups, monitoring channels, and configuration. If the same secret deploys to every environment, a compromise in development can become a production incident. If developers can directly change production databases outside a controlled process, pipeline controls may be bypassed.

Release controls should match risk. A low-risk internal service may use fully automated deployment after required tests pass. A regulated payment feature may require change advisory review, segregation of duties, security signoff, and documented rollback. The point is not to slow every release. The point is to define risk tiers and apply appropriate control rigor.

CI/CD also creates evidence. A strong pipeline records commit identifiers, build numbers, test results, scanner results, approval decisions, artifact hashes, deployment targets, and rollback actions. Evidence supports audits, incident response, and root cause analysis. If a production outage occurs, leaders should be able to identify what changed, who approved it, what checks ran, and how the deployment can be reversed.

Use this delivery risk workflow:

1. Classify the application and release by business impact and data sensitivity.
2. Identify who can change source, pipeline configuration, secrets, and deployment targets.
3. Define mandatory checks and approval gates for the risk tier.
4. Separate credentials, data, keys, and access by environment.
5. Sign or otherwise protect build artifacts where integrity risk is high.
6. Preserve logs and evidence for audit and incident response.
7. Test rollback and emergency change procedures.

Scenario: a team stores a cloud production deployment key as a repository secret accessible to all branches. A feature branch build can deploy to production if a script is modified. The best response is to scope deployment credentials to protected branches or environments, require approval for production deployments, restrict who can change pipeline configuration, and rotate the exposed credential if misuse or exposure is possible.

Scenario: developers request a copy of the production customer database to reproduce a defect. A CISSP manager should not approve by default. The team should first use synthetic data, masked data, log analysis, or a minimal approved extract. If production data is truly required, the exception should be approved by the data owner and privacy or legal stakeholders, with access limits, retention, monitoring, and secure destruction.

The mature view is that CI/CD is both an accelerator and a control system. When done well, it reduces human error, enforces standards, and creates evidence. When done poorly, it becomes a privileged path around change management. The CISSP answer is to govern the path that can change production.