Security and Compliance Fundamentals for DevOps

Security and compliance in a CI/CD pipeline means embedding automated checks at every stage of the software delivery process so that any code change — from a tiny bug fix to a giant new feature — must pass a series of security and policy requirements before it ever touches real users.

First, let us define the key pieces. CI/CD stands for Continuous Integration and Continuous Delivery (or Continuous Deployment). Think of CI as a robot that automatically tests every code change every time a developer saves their work. CD is the next step: automatically packaging that tested code and preparing it to be sent to production. A pipeline is the sequence of steps — like a factory assembly line — that code travels through: commit, build, test, scan, deploy.

Why does security matter here? Traditionally, security checks happened at the very end — someone from a separate security team would review the finished product right before release. This was slow, expensive, and meant problems were found too late. DevOps flips this: security moves left, meaning earlier in the process. Instead of one big security review at the end, there are many small, automated checks throughout the pipeline.

The exam objective 6.1 focuses on implementing these security controls. AWS services you need to know include AWS CodePipeline (the service that builds and runs your pipeline), AWS CodeBuild (which runs your tests and scans), AWS CodeCommit (for storing code), AWS CodeDeploy (for deploying to servers), and AWS CodeStar (a dashboard to manage it all). But the most important for security are AWS Identity and Access Management (IAM) and AWS Key Management Service (KMS), which control who can do what and how encryption keys are managed.

How does a security check work inside a pipeline? Imagine a developer named Priya writes a new feature and pushes her code to the repository (CodeCommit). This push automatically triggers the pipeline. The first stage might be 'Source', where the pipeline downloads her code. The second stage is 'Build' - CodeBuild compiles the code and runs unit tests. The third stage is 'Test', where a security scanning tool like Amazon Inspector or a third-party tool like Snyk checks the code for known vulnerabilities in open-source libraries. The fourth stage is 'Deploy' - but before deployment, a compliance check runs: a tool verifies that the code includes encryption settings that meet your company's policy (for example, all S3 buckets must have encryption enabled). If any check fails, the pipeline stops automatically and notifies Priya. No human needs to manually approve or reject the change.

This automation replaces the old process where a security engineer would manually review a change request form, check a few boxes, and hope nothing was missed. Now, the checks are consistent, repeatable, and happen every single time. This is called 'infrastructure as code' or 'security as code' — writing your security rules in a file (like JSON or YAML) that the pipeline reads and enforces.

AWS provides several tools specifically for compliance: AWS Config Rules can monitor whether resources comply with company policies. AWS CloudTrail logs every action taken in your AWS account. AWS Security Hub aggregates findings from multiple security tools. In a pipeline, you might use AWS Lambda functions as custom checkpoints — for example, a Lambda function that checks whether a code change introduces an unencrypted database.

Why does this matter for DOP-C02? The exam loves to test whether you understand the order of checks, how to handle failures, and how to set up IAM roles that grant the pipeline just enough permission to do its job (principle of least privilege). You will see questions about what happens when a pipeline fails a security check — the answer is almost always to stop and notify, not to skip or override.

Common patterns include: using a 'staging' environment that mirrors production but is isolated, running dynamic security tests (like fuzzing or penetration test scripts) against the staging environment, and using approval gates where a human must manually approve the deployment after automated checks pass. However, the exam emphasises automation over manual approval — the goal is to eliminate human bottlenecks while still enforcing strict rules.

Imagine you work for a healthcare startup called 'MediFlow' that builds a patient appointment system. Your company must comply with HIPAA (a strict US healthcare privacy law) and wants to use AWS DevOps services. You are responsible for setting up the CI/CD pipeline.

Here is what you actually do, step by step:

First, you create a repository in AWS CodeCommit to store all the application code. You then create a pipeline in AWS CodePipeline with four stages: Source, Build, Test, and Deploy. In the Source stage, you configure the pipeline to trigger automatically whenever Priya pushes a new commit to the main branch.

In the Build stage, you use AWS CodeBuild to compile the Java code and run unit tests. You add a 'pre-build' command that runs a SAST (Static Application Security Testing) tool like SonarQube. SAST scans the source code itself — looking for patterns like SQL injection vulnerabilities or hardcoded API keys. You configure the build to fail if any critical-severity vulnerability is found.

In the Test stage, you deploy the built application to an isolated test environment (a separate AWS account or a dedicated VPC). Here, you run a DAST (Dynamic Application Security Testing) scan using Amazon Inspector, which tests the running application for vulnerabilities like open ports or weak SSL configurations. You also run a compliance check using AWS Config: you have created a custom AWS Config rule that checks whether any S3 bucket created by the pipeline has server-side encryption enabled. If a bucket lacks encryption, the Config rule marks it as non-compliant, and a Lambda function automatically stops the pipeline and sends a notification to your security team's Slack channel.

Before the Deploy stage, you add an approval step. However, because the exam favours automation, you set up a Lambda function that automatically approves deployment if all previous checks passed and if the deployment window is within business hours (to minimise risk). If the deployment is outside business hours, the pipeline waits for a human from the on-call team to manually approve via the AWS Management Console.

You also configure IAM roles with least privilege. The CodeBuild role has permission only to write to the specific S3 bucket used for build artifacts and to read from the specific ECR repository for container images. The role cannot list IAM users or delete CloudTrail logs — those actions are blocked.

When the pipeline runs, every single action is logged by AWS CloudTrail. You set up an AWS CloudWatch Events rule that triggers if a pipeline execution fails due to a security check — this sends an email to the security team and creates an incident ticket in Jira automatically.

Finally, you document the entire pipeline configuration as infrastructure as code using AWS CloudFormation, so that if a disaster strikes, you can recreate the entire setup in minutes in another AWS region. This approach ensures that every security check is repeatable, auditable, and consistent — no matter which developer is pushing code or what time of day it is.