Cloud Security · Topic 6 of 6
DevSecOps, Infrastructure as Code and Container Security
Learn DevSecOps: shift left security in the CI/CD pipeline, Infrastructure as Code scanning, Kubernetes and container security, and secure development.
- 4 min
- DevSecOps automates security checks in the pipeline and shifts them left.
- SAST analyses source code. DAST tests a running application.
- SCA finds vulnerable third party libraries, and an SBOM lists components.
What it is
DevSecOps builds security checks into every stage of software delivery, instead of adding them at the end.
Development and operations teams ship changes many times a day. A security review at the end cannot keep up. So the checks are automated, and run in the pipeline, which finds problems early when they are cheap to fix.
How it works
Follow the pipeline from code to runtime, and see which control belongs at each stage.
Shift left
Shifting left means moving security earlier in the lifecycle. A flaw found in the code editor costs far less than one found in production. The idea is also cultural, because developers own security results, with help from the security team.
Secure software development
A secure development lifecycle includes practices at every phase.
- Requirements and design: threat modelling to find risks before coding.
- Coding: secure coding standards and peer review.
- Testing: automated security tests alongside functional tests.
- Release: signed artifacts and approvals for sensitive changes.
- Operation: monitoring, patching and incident response.
The CI/CD pipeline
Continuous integration builds and tests every change. Continuous delivery or deployment releases it automatically. Each stage is a place to add a check.
| Check | What it finds | Stage |
|---|---|---|
| Secrets scanning | Keys and passwords committed to the repository | Commit |
| SAST (static analysis) | Flaws in source code, without running it | Build |
| SCA (software composition analysis) | Known vulnerabilities in third party libraries | Build |
| Container image scanning | Vulnerable packages in an image | Build |
| DAST (dynamic analysis) | Flaws in a running application | Test |
| IaC scanning | Misconfiguration in infrastructure templates | Build or test |
| Artifact signing | Tampering between build and deploy | Release |
A software bill of materials (SBOM) lists the components inside a build. It helps you find which applications are affected when a library flaw is announced. Protect the pipeline itself, because a compromised build system can insert malicious code into every release.
Infrastructure as Code security
Infrastructure as Code (IaC) describes servers, networks and permissions in files, such as Terraform or CloudFormation templates. Because the files are code, they can be reviewed and scanned before anything is created.
Common IaC problems include public storage, open security groups, missing encryption, overly broad roles and hardcoded secrets. Scan templates in the pipeline, and fail the build on serious findings. Use policy as code to set guardrails, and detect drift between the code and what is actually deployed.
Container orchestration security
Kubernetes runs containers across a cluster. Its control points need protection, as well as the containers themselves.
| Area | Control |
|---|---|
| Images | Scan, use trusted registries and sign images |
| API server access | Strong authentication and RBAC with least privilege |
| Pods | Run as non root, drop capabilities and avoid privileged mode |
| Network | Network policies to limit pod to pod traffic |
| Secrets | Use a secrets store and encrypt secrets at rest |
| Admission | Admission controllers reject non compliant workloads |
| Nodes | Harden and patch hosts, and limit access |
A default Kubernetes cluster allows all pods to talk to each other. A network policy changes that. The example below denies all ingress to pods in a namespace, and further policies then allow only needed flows.
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: default-deny-ingress
namespace: prod
spec:
podSelector: {}
policyTypes:
- IngressThe empty podSelector selects every pod in the namespace. With no ingress rules listed, no inbound traffic is allowed to them.
Runtime and feedback
Security does not stop at release. Runtime tools watch workloads for abnormal behaviour, and logs go to a central place. Findings feed back to the developers, and the same issue becomes a new automated test.
What to remember for the exam
Six facts cover most questions on this topic.
- DevSecOps automates security checks in the pipeline and shifts them left.
- SAST analyses source code. DAST tests a running application.
- SCA finds vulnerable third party libraries, and an SBOM lists components.
- IaC templates are scanned before deployment, and policy as code sets guardrails.
- Kubernetes needs RBAC, network policies, secrets protection and admission control.
- Protect the pipeline itself, and keep secrets out of repositories.
If a question asks how to find flaws in code without running it, the answer is SAST.
Common mistakes
These four mistakes appear often.
Confusing SAST with DAST. SAST reads code, and DAST attacks a running application.
Scanning only at the end. Late findings are costly, so check at every stage.
Storing secrets in the repository. Use a secrets manager and scan for leaks.
Leaving the default Kubernetes network open. Pods can talk freely until a network policy limits them.
A pipeline with broad deployment permissions is a high value target. Give it least privilege, and protect its credentials.
Check yourself
Work through these three questions.
What does shifting left mean?
Moving security checks earlier in the development lifecycle, so flaws are found when they are cheap to fix.
What is the difference between SAST and DAST?
SAST analyses source code without running it, and DAST tests the running application.
What does a default deny ingress network policy do?
It selects every pod in the namespace and lists no ingress rules, so no inbound traffic is allowed until other policies permit it.
Topic 6 of 6 in Cloud Security
Test yourself on Cloud Security
The full Cisco CCNP 350-701 SCOR question bank has 822 questions, with timed practice exams and an explanation for every answer.
This study guide is independent and is not affiliated with, endorsed by, or sponsored by Cisco. Vendor names, certification names and exam codes are trademarks of their respective owners and are used for identification only.