The traditional model separates development, operations, and security into distinct phases. Development builds the thing. Operations deploys it. Security reviews it afterward. This model produces security that is expensive, adversarial, and consistently late.
The traditional model is broken for cloud environments
In an on-premise environment, the security review after deployment was inconvenient but manageable. The infrastructure changed infrequently. A quarterly penetration test and an annual audit could reasonably cover the surface area. The model was inefficient, but it was viable.
Cloud environments do not work this way. Infrastructure changes daily. New services are provisioned, configurations are modified, and permissions are granted at a pace that a post-deployment security review cannot keep up with. The window between a misconfiguration and its detection, in an environment where security is reviewed after the fact, is measured in weeks or months — not hours.
Why the pipeline is the right place for security
When infrastructure is code — when your AWS environments are defined in Terraform and deployed through AWS CodePipeline or GitHub Actions — security policy can be code too. The same pipeline that tests your application can scan your infrastructure configuration, check your dependencies for known vulnerabilities, and validate that your Terraform plan does not create an overly permissive network security group.
This is not theoretical. The tools exist, they are mature, and they integrate directly into the pipelines that most engineering teams are already using:
Security controls that belong in the pipeline
- Static application security testing (SAST). Scanning source code for security vulnerabilities before it builds. GitHub Advanced Security and similar tools run this natively in pull requests.
- Dependency scanning. Checking third-party libraries and packages against known vulnerability databases. Every dependency that enters your codebase is an attack surface.
- Infrastructure as code validation. Tools like Checkov or tfsec analyse Terraform and AWS CDK configurations against security benchmarks before they are applied, catching misconfigurations at the point of authorship rather than after deployment.
- Secrets detection. Scanning for credentials, API keys, and tokens committed to source control. A leak in a private repository is a serious incident; a leak in a public repository is a catastrophic one.
- Container image scanning. If your application runs in containers, the base images and installed packages are part of your attack surface. Scanning should happen at build time, not just in production.
What this means for your next pipeline design
If you are building a new CI/CD pipeline, the security conversation needs to happen in the same room as the pipeline design conversation. Not after. Not as a separate workstream. The choices made in the pipeline — what runs, what blocks the build, what triggers an alert — determine your security posture in a cloud environment as much as anything you configure after deployment.
If you have an existing pipeline and security is not part of it, the most useful first step is an honest audit of what the pipeline currently checks and what it does not. The gaps are usually apparent, and the remediation is almost always less expensive than a post-breach response.
The security team and the DevOps team need to be talking to each other during pipeline design. In most organisations, they are not. The result is that security is added afterward, which costs more, takes longer, and consistently produces worse outcomes than security built in from the start.