AWS Builder Center

Builder Center

From CI/CD to DevSecOps on AWS: Adding Security Gates Before Production

A practical guide to evolving a CI/CD pipeline into a DevSecOps workflow on AWS by integrating vulnerability scanning, secure secret management, container image analysis, and centralized security findings before deployment.

From CI/CD to DevSecOps on AWS: Adding Security Gates Before Production

A CI/CD pipeline can automate how quickly software moves from source code to production.
But speed alone is not enough.
A pipeline can successfully build, test, and deploy an application while still delivering vulnerable dependencies, insecure container images, exposed credentials, or configuration issues.
This is where DevSecOps changes the approach.
Instead of treating security as a final review before production, security controls become part of the software delivery lifecycle itself.
On AWS, we can design pipelines where security checks act as automated gates between development and deployment.

CI/CD vs. DevSecOps

A traditional CI/CD workflow might look like this:
1
2
3
4
5
6
7
8
9
10
11
12
13
Developer
|
v
Source Code
|
v
Build
|
v
Test
|
v
Deploy
A DevSecOps pipeline introduces security throughout the process:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
Developer
|
v
Source Code
|
v
Build
|
v
Security Scan
|
v
Container Build
|
v
Vulnerability Scan
|
v
Security Gate
|
v
Deploy
|
v
Continuous Monitoring
The important difference is not simply adding another security tool.
The goal is to make security part of the decision process of the pipeline.
If an artifact does not meet the organization's security criteria, it should not continue automatically toward production.

1. Orchestrate the Pipeline with AWS CodePipeline

AWS CodePipeline can coordinate the different stages involved in delivering an application.
For example:
1
2
3
4
5
6
7
8
9
Source
↓
Build
↓
Security Scan
↓
Container Registry
↓
Deployment
Each stage represents a control point.
Instead of viewing the pipeline only as deployment automation, we can think of it as an automated policy enforcement workflow.
A possible architecture could include:
  • AWS CodePipeline for orchestration
  • AWS CodeBuild for builds and automated tests
  • Amazon ECR for container images
  • Amazon Inspector for vulnerability scanning
  • AWS Secrets Manager for sensitive credentials
  • AWS Security Hub CSPM for centralized security findings
Together, these services can create multiple security checkpoints before an application reaches production.

2. Build and Test with AWS CodeBuild

The build stage should do more than compile an application.
AWS CodeBuild can execute automated tasks defined as part of the build process.
A simplified workflow might include:
1
2
3
4
5
6
7
8
9
Install dependencies
↓
Run unit tests
↓
Run security checks
↓
Build application
↓
Build container image
The principle is simple:
Detect problems as early as possible.
Finding an issue while code is still moving through the pipeline is usually much easier than discovering it after deployment.
This idea is often described as shifting security left.
But shifting left does not mean moving every security responsibility to developers.
It means providing developers with automated feedback earlier in the delivery process.

3. Protect Secrets

One of the most dangerous mistakes in CI/CD environments is storing credentials directly inside:
  • source code
  • configuration files
  • pipeline variables
  • build scripts
  • container images
Passwords, API keys, and tokens should not be treated like normal configuration values.
A better approach is to retrieve sensitive information from a dedicated secrets management service such as AWS Secrets Manager.
Conceptually:
1
2
3
4
5
6
7
8
Application / Pipeline
|
| Request secret
v
AWS Secrets Manager
|
v
Temporary use of credential
The objective is to avoid embedding long-lived sensitive credentials directly into the delivery workflow.
This also makes secret rotation and access control easier to manage.

4. Scan Container Images

Containers introduce another important security layer.
Even if your application code is secure, the final container image may include vulnerable packages through:
  • the base image
  • operating system libraries
  • programming language dependencies
  • outdated packages
A common AWS workflow is:
1
2
3
4
5
6
7
8
9
10
11
Source Code
↓
AWS CodeBuild
↓
Docker Image
↓
Amazon ECR
↓
Amazon Inspector
↓
Vulnerability Findings
Amazon ECR provides a managed container registry, while Amazon Inspector can analyze images stored in ECR for software vulnerabilities.
This is particularly useful because the object being analyzed is closer to the artifact that will actually run in the environment.
Instead of asking only:
Is my source code secure?
We can also ask:
Is the artifact I am about to deploy secure enough to continue?

5. Turn Vulnerability Results into Security Gates

Scanning is useful.
But scanning without action is not enough.
Imagine that a container scan discovers:
1
2
3
Critical vulnerabilities: 2
High vulnerabilities: 5
Medium vulnerabilities: 14
If the pipeline continues automatically regardless of the result, the scanner becomes mostly informational.
A stronger DevSecOps workflow introduces a policy.
For example:
1
2
3
4
5
6
7
8
Critical vulnerability detected?
|
+----+----+
| |
YES NO
| |
Block Continue
Pipeline Pipeline
The organization defines acceptable thresholds according to its risk model.
The important idea is that security findings can influence whether deployment continues.
This transforms security from a report generated after development into an active part of software delivery.

6. Centralize Findings

As environments grow, security information can become fragmented.
One service reports container vulnerabilities.
Another identifies configuration problems.
Another detects suspicious behavior.
A centralized security view becomes increasingly valuable.
AWS Security Hub CSPM can aggregate and organize security findings from AWS services and help teams evaluate their AWS security posture.
A simplified model looks like this:
1
2
3
4
5
6
7
8
Amazon Inspector ──┐
|
Other AWS findings ├──> AWS Security Hub CSPM
|
Security controls ─┘
|
v
Centralized visibility
This becomes particularly important when organizations operate multiple workloads or AWS accounts.

7. Security Does Not End After Deployment

A DevSecOps pipeline reduces risk before deployment, but production security still requires continuous monitoring.
This creates two complementary security loops.

Before deployment

1
2
3
4
5
6
7
8
9
10
11
Code
↓
Build
↓
Test
↓
Scan
↓
Security Gate
↓
Deploy

After deployment

1
2
3
4
5
6
7
8
9
Running Workload
↓
Security Monitoring
↓
Findings
↓
Investigation
↓
Remediation
Security therefore becomes a continuous process rather than a single stage in the development lifecycle.

A Practical DevSecOps Architecture

Putting the components together, a simplified AWS architecture could look like this:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
Developer
|
v
Source Repository
|
v
AWS CodePipeline
|
v
AWS CodeBuild
|
+----> Automated Tests
|
+----> Security Checks
|
v
Container Image
|
v
Amazon ECR
|
v
Amazon Inspector
|
v
Security Gate
|
+---- Failed ----> Stop Pipeline
|
+---- Passed ----> Deployment
|
v
AWS Workload

Security Findings
|
v
AWS Security Hub CSPM
This architecture demonstrates an important principle:
security decisions should happen throughout the pipeline, not only after deployment.

Start Small

A complete DevSecOps implementation can become complex quickly.
You do not need to implement everything at once.
A good first iteration could include:
  1. automated tests
  2. secure secret management
  3. container image scanning
  4. vulnerability thresholds
  5. centralized security findings
After those controls are stable, additional capabilities can be introduced depending on the application and its risk requirements.

Final Thoughts

DevSecOps is not simply DevOps with more security tools.
It represents a change in how we design the software delivery process.
A mature pipeline should not only answer:
Can this application be deployed?
It should also help answer:
Should this application be deployed in its current state?
AWS services such as CodePipeline, CodeBuild, Amazon ECR, Amazon Inspector, AWS Secrets Manager, and Security Hub CSPM can help integrate security controls throughout the delivery lifecycle.
The objective is not to slow down delivery.
The objective is to create pipelines that can move quickly while continuously evaluating risk.
And that is one of the most important transitions from CI/CD to DevSecOps.

Tags

AWS
DevSecOps
CI/CD
Cloud Security
Amazon Inspector
# aws-api
Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.
Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article