9.4 CI/CD, Source Control, and Environment Separation

CISSP Study Guide Exam

Track your progress as you read

Finished sections get a check mark.

1 Chapter 1: CISSP Orientation, CAT, and Official Source Control

1.1 Credential Scope, CISSP Mindset, and Search Language 1.2 Exam Outline Effective Date and Eight-Domain Map 1.3 CAT Format, 100-150 Items, and Forward-Only Rules 1.4 Passing Grade, Results, Feedback, and Retake Policy 1.5 Experience, Endorsement, and Associate of ISC2 Path 1.6 Pricing, AMF, CPE, and Maintenance Overview

2 Chapter 2: Security and Risk Management

2.1 Professional Ethics, CIA, and Security Governance 2.2 Policies, Standards, Procedures, Guidelines, and Control Ownership 2.3 Legal, Regulatory, Privacy, and Investigation Context 2.4 Risk Identification, Analysis, Treatment, and Reporting 2.5 Business Continuity, BIA, and Recovery Prioritization 2.6 Personnel Security, Training, Awareness, and Culture 2.7 Threat Modeling, Supply Chain Risk, and Third-Party Governance 2.8 Security and Risk Management Case Lab

3 Chapter 3: Asset Security and Data Lifecycle

3.1 Asset and Data Classification, Ownership, and Roles 3.2 Handling Requirements, Labeling, Privacy, and Cross-Border Data 3.3 Data States and Protection Methods: DLP, DRM, and CASB 3.4 Data Lifecycle, Retention, Remanence, and Destruction 3.5 Secure Provisioning, Inventory, and Asset Management 3.6 Asset Security Case Lab

4 Chapter 4: Security Architecture, Engineering, and Cryptography

4.1 Secure Design Principles and Security Models 4.2 Control Selection, System Security, and Architecture Risk 4.3 Cryptography Foundations: Symmetric, Asymmetric, Hashing, and PKI 4.4 Cryptographic Lifecycle, Key Management, and Attack Patterns 4.5 Cloud, Container, IoT, Edge, and Shared Responsibility Architecture 4.6 Physical Site, Facility, and Environmental Security 4.7 Information System Lifecycle Engineering and Retirement 4.8 Architecture and Engineering Case Lab

5 Chapter 5: Communication, Network Security, and Zero Trust

5.1 Network Architecture, OSI/TCP/IP, and Secure Design 5.2 Secure Protocols, Encryption in Transit, and Channel Protection 5.3 Segmentation, Microsegmentation, SDN, VPC, and Zero Trust 5.4 Wireless, Cellular, Remote Access, and Third-Party Connectivity 5.5 Network Components: NAC, IDS/IPS, Firewalls, and Endpoints 5.6 Monitoring, Observability, Capacity, and Resilient Communications 5.7 Communication and Network Security Case Lab

6 Chapter 6: Identity and Access Management

6.1 Identity Proofing, Authentication, Authorization, and Accountability 6.2 Access Control Models: RBAC, MAC, DAC, ABAC, and Risk-Based Access 6.3 Federation, SSO, MFA, Passwordless, and Session Management 6.4 Provisioning, Deprovisioning, JML, and Access Reviews 6.5 Service Accounts, Non-Human Identities, and Privilege Management 6.6 Physical, Logical, Cloud, and Hybrid Access Boundaries 6.7 IAM Case Lab

7 Chapter 7: Security Assessment, Testing, and Audit Strategy

7.1 Assessment, Test, and Audit Strategy Selection 7.2 Control Testing, Vulnerability Assessment, and Penetration Testing 7.3 Log Review, Code Review, Misuse Cases, and Compliance Checks 7.4 Security Process Data, KPIs, KRIs, and Reporting 7.5 Remediation, Exceptions, Risk Acceptance, and Evidence Quality 7.6 Security Assessment and Testing Case Lab

8 Chapter 8: Security Operations, Incident Response, and Resilience

8.1 Investigations, Evidence, Forensics, and Legal Readiness 8.2 Logging, Monitoring, SOC, and Alert Triage 8.3 Configuration, Change, Patch, and Vulnerability Operations 8.4 Incident Management, Containment, Eradication, and Recovery 8.5 Disaster Recovery, Backup, Availability, and Resilience 8.6 Physical Security Operations and Safety 8.7 Security Operations Case Lab

9 Chapter 9: Software Development Security and DevSecOps

9.1 Secure SDLC Governance and Requirements 9.2 Architecture, Threat Modeling, and Design Review 9.3 Secure Coding, Code Review, and Application Testing 9.4 CI/CD, Source Control, and Environment Separation 9.5 Software Supply Chain, Third-Party Components, and Deployment 9.6 DevSecOps Vulnerability Management and Release Risk 9.7 Software Development Security Case Lab

10 Chapter 10: Integrated CISSP Governance Scenario Labs

10.1 Enterprise Risk Committee Decision Lab 10.2 Cloud Migration Security Architecture Lab 10.3 Ransomware Incident and Business Continuity Lab 10.4 Identity Modernization and Zero Trust Lab 10.5 Third-Party Breach and Contract Governance Lab 10.6 Secure SDLC Transformation Lab 10.7 Full CISSP Manager Simulation

11 Chapter 11: Final Review, Endorsement, CPE, and Test-Day Strategy

11.1 Final 45-Day CISSP Study Plan 11.2 CAT Timing and Forward-Only Decision Workflow 11.3 Mixed-Domain Remediation and Manager Mindset Review 11.4 Test-Day Checklist and Pearson VUE Readiness 11.5 Endorsement, Associate Path, and Work Experience Documentation 11.6 CPE, AMF, and Three-Year Maintenance Plan 11.7 CISSP Final Mixed Review

9.4 CI/CD, Source Control, and Environment Separation

Key Takeaways Explain This Topic AI

Source control governance protects integrity, accountability, and recoverability of software changes.

CI/CD pipelines should enforce approved checks, protect build credentials, preserve evidence, and separate duties where risk requires it.

Development, test, staging, and production environments should be separated by data, access, credentials, configuration, and change authority.

Pipeline speed is valuable only when it operates within controlled release, rollback, monitoring, and exception processes.

Last updated: May 2026

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.

• Control area Risk addressed Example control
• Repository access Unauthorized code change MFA, least privilege, periodic access review
• Branch protection Unreviewed production change Required review, status checks, protected branches
• Pipeline identity Credential theft or overreach Short-lived tokens, scoped secrets, workload identity
• Build integrity Tampered artifacts Reproducible builds, signed artifacts, provenance
• Environment separation Cross-environment compromise Separate accounts, networks, data, keys, and approvals
• Release control Undocumented production risk Change records, release gates, rollback plans
• Evidence Weak auditability Logs, approvals, test results, artifact records

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:

Classify the application and release by business impact and data sensitivity.

Identify who can change source, pipeline configuration, secrets, and deployment targets.

Define mandatory checks and approval gates for the risk tier.

Separate credentials, data, keys, and access by environment.

Sign or otherwise protect build artifacts where integrity risk is high.

Preserve logs and evidence for audit and incident response.

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.