DevOps DevSecOps

DevSecOps adds security checks to every stage of the DevOps pipeline. Security becomes a shared job for developers, operations staff, and security specialists instead of a final inspection before release. Teams find weaknesses while changes are small and cheap to fix.

The House Construction Example

A builder who inspects a house only after the paint dries cannot see the wiring inside the walls. Wise builders inspect the foundation, the wiring, the plumbing, and the roof as each stage finishes. DevSecOps works the same way. Each pipeline stage gets its own security check.

Shift-Left Security

Shift-left security means moving checks earlier on the timeline. A developer sees a warning inside the code editor. The pipeline repeats the check on every push. Early feedback lets a developer fix a flaw in minutes.

Security in the Pipeline

 Code --> Build --> Test --> Package --> Deploy --> Run
  |         |        |         |           |         |
 Secret    SAST     SCA     Image        IaC       Runtime
 scan                       scan         scan      monitoring
                                                    + DAST

Types of Security Scans

Understanding Vulnerabilities

A vulnerability is a weakness that an attacker could use. Public lists give each known weakness a CVE number, such as CVE-2021-44228. The CVSS score rates seriousness from 0 to 10. Teams set rules around the score, such as blocking the build for any critical finding and creating tickets for medium findings.

Example: Scanning an Image in GitHub Actions

name: security
on: [push]
jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Build image
        run: docker build -t shop:test .
      - name: Scan image
        uses: aquasecurity/trivy-action@0.28.0
        with:
          image-ref: shop:test
          severity: CRITICAL,HIGH
          exit-code: 1

The workflow builds an image and runs the Trivy scanner. The setting exit-code: 1 fails the job when the scan finds critical or high findings.

Software Supply Chain Security

Modern applications contain hundreds of outside libraries. An attacker who poisons one library reaches every project that uses it. Supply chain security protects that chain.

• SBOM: A Software Bill of Materials lists every component inside an application, like an ingredient label.
• Signing: Tools such as Cosign sign images, so clusters run only trusted builds.
• Pinned versions: Lock files fix the exact version of each dependency.
• Trusted sources: Download packages from approved registries.

 Source --> Build (signed) --> Registry --> Cluster verifies signature --> Run

Container and Runtime Security

• Use small base images, such as distroless or Alpine, to reduce the attack surface.
• Run containers as a non-root user.
• Mount the container filesystem as read-only when possible.
• Drop Linux capabilities that the application does not need.
• Watch running containers with a tool such as Falco for strange behavior.

Threat Modeling

Threat modeling is a short planning session where the team asks four questions: What are we building? What can go wrong? What will we do about it? Did we do a good job? Simple diagrams of data flow help the team spot weak points before writing code.

Culture and Ownership

Tools alone do not create security. Teams succeed when developers own the fixes for findings in their code. Security specialists act as coaches, provide approved templates, and keep the rules clear. Regular training and a friendly reporting channel encourage people to raise concerns early.

Key Points

• DevSecOps places automated security checks in every pipeline stage.
• SAST, SCA, image, IaC, and DAST scans each cover a different risk.
• SBOMs and signed builds protect the software supply chain.
• Shared ownership makes security a daily habit.