Devops Docs

Introduction to DevSecOps

DevSecOps is the practice of integrating security into every phase of the software development lifecycle. Rather than treating security as a final gate before release, DevSecOps shifts it left — embedding automated security checks, shared responsibility, and a security-first culture directly into the DevOps workflow.

The Traditional Approach to Security (and Its Problems)

Before DevSecOps, security was handled the old way — as an afterthought. Here's what that looked like and why it failed:

Late Integration of Security

  • Security was typically considered late in the development process, often only during the pre-production phase
  • While DevOps enabled automated, streamlined processes, security checks and audits were still blocking the entire pipeline — delaying releases by weeks
  • This fundamentally undermined the speed that DevOps was meant to deliver

Siloed Teams — Lack of Collaboration

  • While DevOps united Development and Operations, Security was often still a separate team
  • This led to communication gaps, delays in addressing security issues, and a lack of shared responsibility for security
  • Security teams would throw reports over the wall, and developers would scramble to fix things they didn't fully understand

Manual Processes, No Automation

  • Traditional security practices relied on manual security assessments and reviews, which are slow and error-prone
  • Manual processes are not suited to the fast-paced, automated nature of DevOps

Slow Feedback Loop

  • Delayed security feedback makes it more challenging to fix issues
  • The longer it takes to identify and remediate vulnerabilities, the greater the potential impact and the higher the costs
  • A bug found in production can cost 100x more to fix than one caught during development

Increased Attack Surfaces

  • Modern architectures have introduced more attack surfaces that traditional security tools weren't built for:
    • Microservices — many more components to secure
    • Containers — ephemeral environments with their own security concerns
    • Cloud platforms — shared responsibility models, misconfiguration risks
    • Kubernetes — complex orchestration with its own RBAC, network policies, and secrets management
  • Security tools were often developed before these new developments, making them inadequate for modern stacks

What is DevSecOps?

DevSecOps solves the problems above by integrating security into DevOps — shifting security to the left.

The Core Idea

  • Without DevSecOps: Security is considered only after a new feature is developed and tested, right before releasing it
  • With DevSecOps: Start thinking about security right at the beginning and address issues as soon as they appear

Key Principles

Automation, Collaboration, and a Proactive Approach to Security

  • DevSecOps encourages organizations to identify and remediate security issues earlier in the development lifecycle
  • This improves security posture while maintaining the speed and agility of DevOps practices

Shared Responsibility and Collaboration

  • Security becomes a developer responsibility too, not just the domain of dedicated security professionals
  • The security team shifts role — becoming a facilitator and advisor for Dev and Ops teams
  • Security teams train engineers on how to interpret the output of security tools, so they can identify and fix issues themselves

Automation

  • Security tools are integrated into the CI/CD pipeline to detect issues on every Git push
  • Developers get automated output of the application's security status and what vulnerabilities need to be fixed
  • If no security issues are found → the pipeline deploys the application
  • If security issues are found → developers fix them immediately with context still fresh

Faster Release Cycles and Shorter Feedback Loops

  • Bugs are easier to fix the earlier they are found in the development lifecycle
  • Earlier detection means less time and lower costs to remediate

Tools for Automated Security Tests

Just like we have automated unit tests and integration tests for features and functionality, in DevSecOps we add automated tests for security across multiple dimensions:

  • Automated tests for application security
  • Automated tests for infrastructure and cloud security
  • Automated tests for platform security

And just like there are different types of functional tests (unit, integration, e2e), there are different types of security tests.

SAST — Static Application Security Testing

  • Static code analysis — the application is not running during the scan
  • Identifies security vulnerabilities in the app's source code, configuration files, etc.
  • Looks for common coding errors and deviations from secure coding practices
  • Catches issues like hardcoded secrets, SQL injection patterns, and insecure function usage

SCA — Software Composition Analysis

  • Checks third-party and open-source libraries and frameworks for known vulnerabilities
  • The SCA tool goes through your application's dependencies and checks whether any known vulnerabilities exist for each dependency and the specific version you're using
  • It's also a form of static code analysis — no running application required
  • Think of tools like Snyk, Dependabot, or OWASP Dependency-Check

DAST — Dynamic Application Security Testing

  • Tests the app's running instance or deployed version
  • Simulates security attacks and analyzes behavior and responses in real-time
  • Does not require access to the source code — it interacts with the application as an external attacker would
  • Catches issues that only surface during runtime, like authentication bypasses or exposed endpoints

White Box vs. Black Box Testing

White Box Testing

  • Knowledge: Tester has detailed knowledge of the internal workings, code, and architecture
  • Focus: Examining the internal logic, code paths, and data flows within the application
  • Advantages: Provides precise information about security flaws. Also helpful for addressing issues related to code quality and design flaws
  • Limitations: Does not capture vulnerabilities that only surface when interacting with the running application
  • SAST tools belong to this category

Black Box Testing

  • Knowledge: No access to the source code — relies solely on the system's inputs and outputs
  • Focus: Evaluating the system's functionality, external behavior, and how it responds to various inputs
  • Advantages: Simulates real-world attacks and provides a more user-centric perspective on security. Testers don't need to be familiar with the codebase
  • Limitations: May not uncover all vulnerabilities identifiable through code-level inspection, and it may miss some complex or logic-based vulnerabilities
  • DAST tools belong to this category

Continuous Testing

Why Scanning Once Isn't Enough

  • Applications are developed continuously — code changes constantly
  • Libraries are developed continuously with new versions released regularly
  • Infrastructure changes over time
  • So we need to continuously test and fix security vulnerabilities throughout the software development lifecycle

When to Run Which Security Scans

Security scans can slow down the CI/CD pipeline, so we need a strategy:

Pipeline for Basic Security Tests (runs on every commit)

  • Security checks only for affected code parts
  • Run third-party library checks only when dependencies change
  • Keeps the pipeline fast while catching the most critical issues

Pipeline for Comprehensive Tests (runs nightly)

  • Runs once per night so nobody's work is interrupted
  • Full, comprehensive security scans across the entire codebase
  • More thorough but doesn't block developers

Logging and Monitoring in DevSecOps

  • There is always a chance that security issues slip into production
  • Third-party vulnerabilities can appear after deployment (zero-day vulnerabilities)
  • That's why we need proper continuous logging, monitoring, and alerting that:
    • Continuously monitors the systems for anomalous behavior
    • Alerts the team when security threats or suspicious behavior is detected
  • This is the last line of defence — catching what automated tests missed

Benefits of DevSecOps

Integrating security across the whole software development lifecycle can be challenging, but has significant benefits:

  • More efficient — security is part of the workflow, not a separate blocker
  • Saves costs — security fixes are far more expensive the later they are discovered
  • Protects trust — avoiding security breaches means maintaining customers' trust and the company's reputation

The DevSecOps Engineer

Shared Responsibility

  • The idea of DevOps and DevSecOps is to distribute responsibility for security across teams
  • The DevSecOps professional helps teams integrate automated checks into the pipeline
  • They work to embed security practices and controls by collaborating with Dev and Ops teams

Visibility and Education

  • Setting up processes that show teams their current security posture
  • Helping teams understand security findings and fix issues
  • Building security know-how step by step with the help of tooling
  • Educating and raising awareness among teams about security best practices
  • This promotes a security-first mindset — by getting constant and immediate feedback, engineers learn how to write secure code

Working with Security Engineers

  • DevSecOps engineers work closely with security engineers (dedicated cybersecurity experts)
  • They tap into security engineers' deep understanding of security principles to implement effective security measures
  • Security engineers are:
    • Experts with specialized expertise in cybersecurity
    • Well-versed in regulatory requirements and compliance frameworks
  • The DevSecOps engineer acts as an intermediary between different teams — bridging developers (experts in coding) and security engineers (experts in code security)

Summary of Tasks and Responsibilities

  • Architect of DevSecOps processes — designs and facilitates the integration of security testing into the development and deployment pipeline
  • Provide guidance on security coding standards and perform code reviews
  • Establish mechanisms for continuous security monitoring, threat detection, and vulnerability scanning

DevSecOps Engineer vs. Security Engineer

  • Security Engineer focuses on securing systems, networks, and infrastructure
  • DevSecOps Engineer takes a broader approach by integrating security into the entire DevOps process:
    • Bridging the gap between Dev, Ops, and Security teams
    • Helping automate security checks
    • Helping developers and security engineers to discover, visualize, and fix issues efficiently

Skills of a DevSecOps Engineer

  • Combination of skills in software development, operations, and security
  • Strong collaboration, communication, and leadership skills are essential
  • It's not just about learning the tools — it's about working with people
  • Must be able to:
    • Bridge between Dev, Ops, and Security
    • Create processes and demonstrate what needs to be done
    • Train people in different aspects of security
    • Facilitate knowledge sharing across the organization

DevSecOps: Concept vs. Role

DevSecOps as a Concept

  • DevSecOps is fundamentally a concept or philosophy about how teams work together
  • It's about shared responsibility and shifting security left
  • The goal: catch security issues early and develop more secure applications
  • In theory: Many roles working together to integrate security, divided and shared responsibilities — no single person orchestrating everything, teams proactively collaborating

DevSecOps as a Role

  • In reality: Everybody is busy with their daily tasks and responsibilities
  • Engineers don't have time to think about DevSecOps concepts
  • These concepts are not yet embedded into every engineers' workflow, so they don't proactively build DevSecOps processes
  • Often someone is needed whose main focus is to set up processes and ensure teams work together, share knowledge, and share responsibility

It Varies Between Organizations

  • Specific roles and responsibilities for DevSecOps vary between organizations
  • Self-driven and efficient teams can work together without a separate DevSecOps engineer
  • In most cases, teams are not yet that self-directed — so having a dedicated DevOps and/or DevSecOps engineer is essential for the company