Skip to main content
Web Application Vulnerabilities
CHAPTER 17

Secure DevOps and CI/CD Basics

Updated: May 15, 2026
25 min read

# CHAPTER 17

Secure DevOps and CI/CD Basics

1. Introduction

In the past, software was updated once a year. A developer would write the code, give it to a security team to test for a month, and then give it to operations to install on a server. Today, companies like Amazon deploy new code thousands of times a day. This rapid, automated process is called DevOps. If security relies on slow, manual testing, it becomes a bottleneck and gets bypassed. To survive, security must be automated and woven directly into the deployment pipeline. This is DevSecOps. In this chapter, we will explore how to secure the Continuous Integration/Continuous Deployment (CI/CD) pipeline.

2. Learning Objectives

By the end of this chapter, you will be able to:
  • Define DevOps and the CI/CD pipeline.
  • Understand the philosophy of "Shifting Left" in DevSecOps.
  • Integrate automated SAST and SCA scanning into a pipeline.
  • Identify the catastrophic risks of committing secrets to Git repositories.
  • Understand the concept of "Infrastructure as Code" (IaC) security.

3. Beginner-Friendly Explanation

Imagine a car manufacturing assembly line.
  • The Assembly Line (CI/CD): A robot puts the chassis on the belt, another robot adds the engine, another adds the wheels, and the finished car rolls out the door automatically.
  • Old Security: The car rolls out the door. A safety inspector spends a week taking the car apart to see if the brakes work. It's slow and expensive.
  • DevSecOps (Shifting Left): You install automated lasers and sensors *directly onto the assembly line robots*. If a robot tries to install a faulty brake pad, the sensor immediately halts the entire assembly line and alerts the engineer. Security is automated and immediate.

4. The CI/CD Pipeline

A typical pipeline (using tools like GitHub Actions or GitLab CI):
  1. 1. Commit: A developer writes code and pushes it to GitHub.
  1. 2. Build: A server automatically compiles the code.
  1. 3. Test: Automated scripts verify the application functions correctly.
  1. 4. Deploy: The code is automatically pushed to the live production server.

The DevSecOps Pipeline: We inject security checks directly into Step 3. If any security check fails, the pipeline *breaks* and the code is rejected, preventing the vulnerability from ever reaching production.

5. Automated Pipeline Security Checks

To build a DevSecOps pipeline, we automate the tools we learned in Chapter 15:
  1. 1. Secret Scanning: Tools like git-secrets or TruffleHog scan the code for accidental API keys or passwords. If found, the build fails instantly.
  1. 2. SCA (Software Composition Analysis): Tools like Dependabot scan the package.json or composer.json file. If the developer is using an outdated library with a known CVE (vulnerability), the build fails.
  1. 3. SAST (Static Analysis): Tools like SonarQube or Semgrep scan the raw code for dangerous functions (e.g., finding $GET variables concatenated directly into a SQL query).

6. Secrets Management in CI/CD

The CI/CD server (like Jenkins or GitHub Actions) needs high-level credentials to deploy code to your AWS account. The Vulnerability: If a developer hardcodes the AWS deployment keys into the pipeline configuration file, anyone who can read the repository can hijack the AWS account. The Defense: CI/CD platforms have secure, encrypted "Secret Vaults" built into their settings. You store the AWS key in the vault. The pipeline script references the vault variable (e.g., ${{ secrets.AWSACCESS_KEY }}). The key is injected securely at runtime and masked in all logs.

7. Mini Project: Add Security Checks to Deployment Concept

Let's conceptualize a secure GitHub Actions YAML workflow.

Secure Pipeline Concept (.github/workflows/deploy.yml):

yaml
12345678910111213141516171819202122232425262728293031323334 
name: Secure PHP Deployment

on:
  push:
    branches: [ "main" ]

jobs:
  security-audit:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v3
    
    # 1. Run Secret Scanner (Fail if API keys are found)
    - name: TruffleHog Secret Scan
      uses: trufflesecurity/trufflehog@main
      
    # 2. Run SCA to check for vulnerable dependencies
    - name: Audit PHP Composer Dependencies
      run: composer audit
      
    # 3. Run SAST to find insecure coding patterns
    - name: Run PHPStan (Static Analysis)
      run: vendor/bin/phpstan analyse src/

  # Only run deployment if the security audit passes
  deploy:
    needs: security-audit
    runs-on: ubuntu-latest
    steps:
    - name: Deploy to Server
      run: ./deploy_script.sh
      env:
        # Securely inject secrets from GitHub Vault
        DEPLOY_KEY: ${{ secrets.PROD_SERVER_KEY }}

8. Real-World Scenarios

In 2020, the cybersecurity firm FireEye discovered a massive, highly sophisticated supply chain attack against SolarWinds, a major IT monitoring software company. The attackers did not hack SolarWinds' customers directly. Instead, they breached SolarWinds' CI/CD build pipeline. The attackers injected malicious code directly into the automated assembly line. When SolarWinds automatically compiled and digitally signed their software update, they unwittingly signed the attacker's malware and distributed it to 18,000 customers, including multiple US government agencies. Securing the CI/CD pipeline is critical because a compromised pipeline poisons every piece of software it produces.

9. Best Practices

  • Least Privilege for CI/CD Roles: The IAM permissions granted to a deployment pipeline should be strictly limited. If the pipeline only deploys a web application to an EC2 instance, it should not have permissions to delete S3 buckets or create new administrative IAM users.

10. Legal and Ethical Notes

Integrating automated security testing into CI/CD is increasingly becoming a requirement for maintaining SOC2 compliance. Organizations must demonstrably prove to auditors that security reviews are enforced and recorded for every single code change that enters the production environment.

11. Exercises

  1. 1. Define the concept of "Shifting Left" in the context of a software development lifecycle. Why is it economically advantageous to find a vulnerability during the CI/CD pipeline rather than after deployment?
  1. 2. Explain the danger of hardcoding deployment secrets (like AWS keys) directly into a CI/CD pipeline configuration file.

12. FAQs

Q: If I use an automated SAST scanner in my pipeline, do I still need manual code reviews? A: YES. SAST scanners are not perfectly intelligent. They easily find syntax errors and known bad patterns, but they cannot find logical flaws (like a Broken Access Control bug where an admin check is simply missing). Human code review remains essential.

13. Interview Questions

  • Q: Describe a comprehensive DevSecOps pipeline architecture. Which specific security gates (e.g., SAST, SCA, Secret Scanning) would you implement, and at what stages of the CI/CD workflow?
  • Q: Explain the concept of a "Supply Chain Attack" targeting a CI/CD pipeline (e.g., the SolarWinds incident). How do organizations mitigate the risk of a compromised build server injecting malware into trusted applications?

14. Summary

In Chapter 17, we recognized that manual security testing cannot keep pace with modern software development. We embraced DevSecOps, shifting security "Left" by integrating automated SAST, SCA, and secret scanning directly into the CI/CD assembly line. By enforcing strict security gates that automatically break the build upon detecting a vulnerability, we prevent insecure code from ever reaching production. Ultimately, we secured the pipeline itself, ensuring deployment secrets are vaulted and access is rigorously controlled.

15. Next Chapter Recommendation

We have built a comprehensive understanding of application security. It is time to synthesize this knowledge into a unified set of actionable rules. Proceed to Chapter 18: Web Security Best Practices.

Finish this Chapter

Save your progress on your learning path and prepare for coding interview challenges.

Previous Chapter Cloud Web Application Security
Next Chapter Web Security Best Practices

Discussion

Join the discussion

Log in or create a free account to participate.

Sort: ·

Explore More

📖 Related Tutorials 4

❓ Related Quizzes 5