DevSecOps is the practice of integrating security into the software delivery process instead of treating security as a final approval step before release.
The current 350-701 SCOR v2.0 blueprint explicitly includes Infrastructure as Code security, CI/CD pipelines, container orchestration, and secure software development under DevSecOps.
Those four areas form a useful lifecycle: infrastructure is defined as code, applications move through automated pipelines, workloads run in containerized platforms, and secure-development controls reduce defects before deployment.
Infrastructure as Code makes infrastructure reviewable
Infrastructure as Code converts cloud and platform configuration into version-controlled definitions.
That creates major operational advantages:
- changes can be reviewed
- deployments become repeatable
- configuration can be tested automatically
- drift can be detected
- rollback and change history become easier to understand
It also creates a security problem: a bad configuration can now be replicated just as consistently as a good one.
An insecure security-group rule, public storage configuration, overly broad IAM permission, or hardcoded secret can be deployed at scale.
IaC security therefore focuses on validating the infrastructure definition before it reaches production.
IaC creates a powerful review point because a proposed network, identity, storage, or compute configuration can be examined before the cloud platform accepts it. Static checks can flag public exposure, overly broad permissions, missing encryption settings, or policy violations while the change is still a pull request rather than a production incident.
That benefit depends on keeping the code and the deployed environment aligned. Manual changes after deployment create drift, which weakens the assurance provided by code review. Teams should detect drift and decide whether the approved code should restore the environment or whether the code itself must be updated to represent the intentionally changed state.
Secrets should not live in the repository
One of the simplest DevSecOps failures is committing credentials into source control.
IaC files, pipeline definitions, and application configuration frequently need credentials or tokens, but the secret value should be supplied through an appropriate secret-management system rather than stored directly in the code.
Managing secrets in Terraform illustrates the wider principle: infrastructure code should reference protected secret sources rather than turning version control into a credential vault.
Secret scanning should also run in the pipeline so accidental commits are detected quickly.
Secrets need a lifecycle, not only a hiding place. A secret manager or workload-identity design should limit who can retrieve a credential, record access where possible, support rotation, and avoid exposing the value in build logs or generated artifacts. Short-lived credentials reduce the damage window compared with static tokens copied into repository variables and forgotten.
Build systems deserve particular scrutiny because they often hold deployment authority. A compromised runner that can read secrets and publish artifacts can bypass controls that protect developer laptops. Isolate privileged build stages, restrict egress where practical, and give pipeline identities only the permissions required for the environment they deploy.
CI/CD security adds gates before deployment
A CI/CD pipeline automates the movement from source code to build, test, packaging, and deployment.
DevSecOps inserts security checks into that flow.
Depending on the application, the pipeline can include:
- static application security testing
- software composition analysis
- secret detection
- IaC scanning
- container-image scanning
- dependency-policy checks
- unit and integration security tests
- artifact signing and provenance
- deployment approval gates
The goal is not to make every build wait for a manual security review.
The goal is to automate repeatable security checks and reserve human review for decisions that actually need judgment.
A pipeline should fail for the right reasons.
Security gates become ineffective when they produce so much noise that teams learn to bypass them.
A mature pipeline needs severity thresholds, exception workflows, ownership, and time-bounded remediation.
For example, a low-risk dependency issue may be allowed temporarily with an approved exception.
A leaked production credential or a critical remotely exploitable vulnerability may need to block release immediately.
The decision should be risk-based and documented.
“Security scan passed” is not a useful control if the organization does not know what findings were considered blocking.
A useful pipeline layers different forms of analysis because each sees a different risk. Secret scanning looks for credentials committed to source. Software composition analysis examines third-party packages and known vulnerabilities. Static application testing inspects code patterns. IaC scanning evaluates deployment configuration. Container-image scanning evaluates packages and operating-system content assembled into an image.
No single scanner proves that a release is safe. The gates should be tied to policy: severity, exploitability, environment, exception handling, and remediation ownership. A development build may warn on an issue that a production release must block, but that decision should be explicit and auditable rather than left to whoever is watching the pipeline.
Secure software development starts before scanning
DevSecOps is not only tool integration.
Secure design and coding practices still matter.
Secure software development starts with design and implementation choices because many vulnerabilities originate in decisions that scanners can only partially detect.
Examples include:
- unsafe trust boundaries
- broken authorization logic
- insecure API design
- weak input validation
- insecure error handling
- excessive privilege
- unsafe dependency use
- missing abuse-case thinking
A pipeline can catch known patterns. It cannot replace secure architecture and engineering judgment.
Secure development also includes design choices scanners cannot infer reliably. Threat modeling identifies trust boundaries and misuse cases. Code review can catch authorization logic that is syntactically valid but insecure. Dependency pinning and controlled update processes reduce unexpected changes. Security tests should include negative cases—what an unauthenticated, unauthorized, or malformed request can do—not only the successful user path.
When a defect reaches production, the lesson should return to the development system. Add a regression test, improve a lint rule, update a base image, or change the reusable IaC module so the same class of problem becomes harder to repeat.
Container security starts before runtime
Containers package applications consistently, but the security boundary still depends on the image, host, orchestrator, runtime configuration, and identity model.
A container-security pipeline should inspect:
- base image provenance
- known vulnerabilities
- unnecessary packages
- embedded secrets
- image signatures
- configuration that requests excessive privilege
- exposed ports
- package and dependency risk
The distinction between containers and virtual machines is relevant because containers normally share the host kernel rather than carrying a full guest operating system. That creates different isolation and patching assumptions.
Orchestration adds policy and identity complexity
At scale, containers are usually managed by an orchestrator.
The orchestrator controls scheduling, service discovery, network policy, secrets, workload identity, admission, and resource policy.
A secure image can still be deployed insecurely if the orchestration configuration grants excessive privilege or network access.
DevSecOps therefore needs to validate both the container artifact and the deployment definition.
This is where IaC and container security overlap: the workload manifest is code too.
Container images should be treated as immutable release artifacts. Start with a minimal and trusted base image, remove build tools that are not needed at runtime, avoid running the application as root when possible, and scan both application dependencies and operating-system packages before publishing the image.
Runtime controls answer different questions. Orchestrator policy can restrict privileged containers, host-path mounts, capabilities, and unapproved registries. Network policy can reduce unnecessary east-west communication. Workload identity can replace long-lived cloud credentials embedded in pods. Image security and runtime security therefore reinforce each other rather than competing for the same job.
Software supply chain risk reaches beyond your code
Applications depend on third-party libraries, container base images, package registries, build systems, and CI/CD actions.
A compromise anywhere in that chain can enter a trusted build.
Useful controls include:
- dependency pinning
- software bills of materials
- signed artifacts
- provenance
- trusted registries
- restricted build permissions
- short-lived build credentials
- dependency vulnerability monitoring
The development team therefore has to protect the process that produces software, not only the final source repository.
Supply-chain assurance extends from source commit to deployed workload. Organizations increasingly record provenance about how an artifact was built, sign trusted images or packages, and generate a software bill of materials so responders know which components are present when a new vulnerability is disclosed.
Those controls are most useful when deployment policy consumes the evidence. A registry can hold a signed image, but the security value is much higher if the production platform refuses an unsigned or unapproved artifact. Trust should move with the artifact through the delivery path instead of depending on a human remembering which tag was safe.
Runtime feedback should return to development
DevSecOps should not stop when the deployment succeeds.
Runtime security findings can reveal:
- vulnerable dependencies actually loaded in production
- unexpected process execution
- container privilege misuse
- insecure network exposure
- secrets accessed unexpectedly
- application behavior that testing did not predict
Those findings should feed back into the backlog and pipeline controls.
A vulnerability discovered in production should lead to better prevention earlier in the lifecycle when possible.
Build security into the delivery path
A secure delivery flow can be summarized as:
- Threat-model the change.
- Write code and IaC in version control.
- Scan secrets and dependencies.
- Test application code.
- Scan IaC and policy.
- Build from trusted inputs.
- Scan and sign artifacts or container images.
- Apply deployment/admission policy.
- Deploy with least-privilege identities.
- Monitor runtime behavior.
- Feed findings back into engineering.
DevSecOps is strongest when each control produces evidence that the next stage can use. Reviewed IaC constrains infrastructure, protected pipelines build from trusted inputs, signed artifacts carry provenance, deployment policy enforces release requirements, least-privilege identities limit runtime impact, and monitoring sends real failures back into engineering. Security then becomes part of the delivery mechanism instead of a final gate added after the system is already built.