# IaC, CI/CD, Policy as Code and DevSecOps: A CISSP-Friendly Guide Modern software is no longer built and deployed manually. Organizations use automation to provision infrastructure, configure systems, test software, enforce security policies, and deploy releases. This creates several terms that often sound similar: **IaC, Configuration Management, CI/CD, Policy as Code, DevSecOps, SAST, SCA, DAST, SBOM, Container Security, and Shift Left.** The easiest way to understand them is to see how they fit together. * * * ## The Big Picture Think about a company deploying a modern web application: ```text DEVSECOPS Security throughout │ ▼ CI/CD Build → Test → Deliver │ ┌─────────────┼─────────────┐ ▼ ▼ ▼ Code IaC Dependencies │ │ │ SAST IaC Security SCA Secrets Policy as Code SBOM │ │ │ └─────────────┼─────────────┘ ▼ Container/Image │ ▼ Deployment │ ┌───────┴───────┐ ▼ ▼ Kubernetes Cloud │ │ └───────┬───────┘ ▼ Runtime Security │ ▼ Monitoring / SIEM ``` The current ISC2 CISSP outline explicitly includes **DevOps, DevSecOps, CI/CD, software configuration management, code repositories, and application security testing such as SAST, DAST, and SCA** under Domain 8. It also covers supply-chain risk, SBOM, cloud, microservices, and containerization across other domains. The key is understanding the **purpose of each concept**. * * * # 1\. Infrastructure as Code (IaC) ### IaC answers: > **What infrastructure should exist?** Instead of manually creating infrastructure through a cloud console, infrastructure is described using code or machine-readable configuration. For example: ```text VPC ├── Subnets ├── Load Balancer ├── Security Groups ├── Kubernetes └── Database ``` Terraform or another IaC tool can describe this environment and provision it through cloud APIs. ### Think: > **IaC = CREATE** IaC provides **repeatability, consistency, version control, and automation**. But IaC can also introduce security risks. For example: ```text Security Group TCP/22 0.0.0.0/0 ``` That configuration may expose SSH to the Internet. Therefore, infrastructure code should be treated like application code and subjected to security review and automated checks. * * * # 2\. Configuration Management Once infrastructure exists, it must be configured. ### Configuration Management answers: > **How should the system be configured?** For example: ```text EC2 Server │ ├── Install Nginx ├── Configure SSH ├── Create users ├── Configure services ├── Apply hardening └── Start application ``` Tools such as Ansible, Puppet, and Chef automate these activities. ### Think: > **Configuration Management = CONFIGURE** A simple distinction: ```text IaC Configuration Management │ │ ▼ ▼ Create infrastructure Configure systems ``` Do not focus only on tool names. Focus on **what the technology is doing**. * * * # 3\. CI/CD CI/CD is about automating software delivery. ## Continuous Integration Developers frequently integrate code into a shared repository. ```text Code ↓ Build ↓ Unit Tests ↓ Security Tests ``` Typical security checks may include: * SAST * Secret scanning * SCA * Dependency validation ## Continuous Delivery The software is continuously built, tested, and made **ready for production**. A human approval may still be required before production deployment. ## Continuous Deployment The pipeline automatically deploys the software to production when required conditions are satisfied. ```text Code ↓ Build ↓ Test ↓ Security Gates ↓ Automatic Deployment ``` ### CISSP memory hook > **Continuous Delivery = production-ready** > **Continuous Deployment = automatically deployed** * * * # 4\. Policy as Code This is closely related to IaC, but it answers a different question. ### Policy as Code asks: > **What is allowed?** Suppose the organization has a rule: > Production databases must be encrypted. Terraform might define: ```text Create database ``` Policy as Code evaluates: ```text Is encryption enabled? ``` If not: ```text ❌ Policy violation ``` The deployment can be blocked. ```text IaC │ "Create this" │ ▼ Policy as Code │ "Is this allowed?" │ ┌─────┴─────┐ ▼ ▼ ALLOW DENY ``` ### Think: > **IaC = WHAT SHOULD EXIST?** **Policy as Code = WHAT IS ALLOWED?** Policy as Code is best viewed as a **supporting implementation concept around governance, security controls, IaC and DevSecOps**, rather than a separately named CISSP exam topic. The current ISC2 outline does explicitly cover security policies, control selection, risk management, and DevSecOps-related practices. * * * # 5\. DevSecOps DevSecOps is broader than any single tool. It means integrating security into the development and operations lifecycle instead of treating security as a final checkpoint. Traditional model: ```text Development ↓ Testing ↓ Production ↓ Security Review ``` DevSecOps: ```text Plan → Code → Build → Test → Deploy → Operate │ │ │ │ │ │ └──────┴──────┴───────┴───────┴────────┘ SECURITY ``` Security becomes a continuous activity. NIST similarly describes DevSecOps as integrating security practices throughout the software lifecycle, with automation and earlier security activities as important characteristics. ### Think: > **DevSecOps = SECURE THE ENTIRE PROCESS** * * * # 6\. Where SAST, SCA and DAST Fit These are application-security testing techniques inside the broader process. ### SAST — Static Application Security Testing Analyze source code without executing the application. ```text Source Code ↓ SAST ↓ Potential vulnerabilities ``` ### SCA — Software Composition Analysis Analyze third-party and open-source dependencies. ```text Application ├── Library A ├── Library B ├── OpenSSL └── Framework ↓ SCA ↓ Vulnerabilities / License Risk ``` ### DAST — Dynamic Application Security Testing Test the running application from the outside. ```text Running Application ↓ DAST ↓ Web/API Security Findings ``` ### Easy memory trick ```text SAST = CODE SCA = COMPONENTS DAST = RUNNING APPLICATION ``` All three are explicitly included in the current CISSP Domain 8 outline. * * * # 7\. Software Supply Chain and SBOM Modern applications rarely consist entirely of code written by the organization. They may contain: ```text Application ├── Internal Code ├── Open Source ├── Commercial Components ├── Frameworks ├── Container Base Image └── Build Tools ``` This creates **software supply-chain risk**. One important control is an **SBOM — Software Bill of Materials**. An SBOM provides a machine-readable inventory of software components and their relationships, improving visibility and helping organizations identify and remediate vulnerabilities. Think of it as: > **"What exactly is inside this software?"** ```text Application ↓ SBOM ↓ Component Inventory ↓ Vulnerability Identification ``` This connects directly to CISSP **Supply Chain Risk Management** and software security. * * * # 8\. Container and Kubernetes Security Modern applications are frequently deployed using containers and orchestration platforms. A simplified flow is: ```text Source Code ↓ Container Build ↓ Image Scan ↓ Registry ↓ Kubernetes ↓ Production ``` Security considerations include: * Vulnerable container images * Running containers as root * Excessive Kubernetes privileges * Weak RBAC * Exposed services * Insecure secrets * Missing network controls For CISSP, the important point is not memorizing Kubernetes commands. It is understanding the **security architecture and risks of containerized environments**. Containerization is explicitly included in the current CISSP Security Architecture and Engineering domain. * * * # 9\. Shift Left and Shift Right ### Shift Left Move security earlier in the lifecycle. ```text Design → Code → Build → Test → Deploy ↑ Security earlier ``` Examples: ```text Threat Modeling SAST SCA Secret Scanning IaC Scanning Policy Checks ``` The objective is to identify problems before they reach production. ### Shift Right Continue security activities after deployment. ```text Production ↓ Monitoring ↓ Detection ↓ Response ``` Examples include: ```text Runtime Monitoring SIEM Threat Detection Incident Response Vulnerability Management ``` A mature program needs **both**. ```text SHIFT LEFT │ Prevent / detect earlier │ ▼ CI/CD + Security │ ▼ Production │ ▼ SHIFT RIGHT │ Detect / respond / improve ``` * * * # 10\. A Realistic End-to-End Example Imagine an enterprise is deploying a customer-facing API. ### Step 1 — Developer writes code ```text Git ↓ Pull Request ↓ Code Review ``` Security checks: ```text SAST Secret Scan ``` ### Step 2 — Application is built ```text Build ↓ SCA ↓ SBOM ↓ Container Image ``` ### Step 3 — Infrastructure is defined ```text Terraform ↓ VPC ↓ Kubernetes ↓ Database ↓ Load Balancer ``` Security checks: ```text IaC Scan Policy as Code ``` Example policy: ```text Production database MUST be encrypted ``` ### Step 4 — CI/CD deploys ```text Build ↓ Test ↓ Security Gates ↓ Deploy ``` ### Step 5 — Runtime security ```text Production ↓ Logs ↓ Monitoring ↓ SIEM ↓ Detection / Response ``` This is the complete DevSecOps mindset. * * * # The CISSP Mental Model When you see these terms, think: ```text IaC │ └── CREATE infrastructure Configuration Management │ └── CONFIGURE systems CI/CD │ └── BUILD + TEST + DELIVER software Policy as Code │ └── ENFORCE technical rules SAST │ └── TEST source code SCA │ └── ANALYZE dependencies DAST │ └── TEST running applications SBOM │ └── KNOW software components DevSecOps │ └── INTEGRATE security everywhere Shift Left │ └── FIND issues earlier Shift Right │ └── MONITOR + DETECT + RESPOND ``` * * * # Final Takeaway You do **not** need to become a Terraform, Ansible, Kubernetes, or CI/CD administrator to understand these topics for CISSP. The architectural question is more important: > **What is this technology doing, what risk does it address, where should the security control be applied, and what happens if that control fails?** That is the mindset that connects **CISSP knowledge with real-world Security Architecture**. NIST's Secure Software Development Framework similarly treats security as an integrated set of practices spanning preparation, software protection, secure production, and vulnerability response rather than as a single testing stage. ### One sentence to remember > **IaC creates the environment, Configuration Management configures it, CI/CD delivers the software, Policy as Code enforces rules, and DevSecOps puts security across the entire lifecycle.**