notes

• Shift-Left Security: DevSecOps promotes the idea of integrating security practices at the earliest stages of the software development lifecycle (SDLC). Instead of addressing security vulnerabilities only after the application is built, developers, security teams, and operations teams collaborate from the beginning. This early involvement allows potential threats, coding flaws, and design vulnerabilities to be identified and resolved during development, reducing risks and lowering the cost of fixing issues later in production.
• Automation of Security Processes: DevSecOps emphasizes the use of automation tools to continuously scan and monitor applications for security vulnerabilities throughout the development pipeline. Automated security checks can be integrated into CI/CD pipelines to perform activities such as static code analysis, dependency scanning, vulnerability assessment, and compliance verification. Automation ensures that security testing happens consistently during development, testing, deployment, and operational stages without slowing down the delivery process.
• Collaboration and Shared Responsibility: A fundamental principle of DevSecOps is that security is not the sole responsibility of a dedicated security team. Instead, it becomes a shared responsibility among developers, operations engineers, and security professionals. By fostering collaboration and communication across teams, organizations create a culture where security is embedded into every phase of development and deployment.
• Integration of People, Processes, and Technology: DevSecOps relies on the effective coordination of three key elements: people, processes, and technology. Skilled professionals work together using well-defined processes and advanced security tools to maintain secure development practices. This integrated approach ensures that security policies are implemented effectively while maintaining the speed and agility of DevOps.

The Continuous Integration and Continuous Deployment (CI/CD) pipeline is a fundamental component of DevSecOps that automates the process of building, testing, securing, and deploying software applications. By integrating security checks directly into the pipeline, organizations ensure that vulnerabilities are detected and resolved early in the development lifecycle. This approach improves software quality, accelerates delivery, and reduces security risks in production environments.

CI/CD Pipeline Stages

• Source: Developers commit code to a version control system such as Git. Every change triggers the pipeline automatically, ensuring that all code updates are tracked, reviewed, and tested.
• Build: The application source code is compiled and dependencies are installed. Build tools prepare the software into an executable format such as binaries, packages, or containers.
• Test: Automated testing frameworks run unit tests, integration tests, and functional tests to verify that the application behaves as expected and that recent changes do not introduce errors.
• Security Scanning: Security tools automatically scan the codebase and dependencies for vulnerabilities. These scans help detect coding flaws, outdated libraries, exposed secrets, and insecure configurations before deployment.
• Package: The validated application is packaged into deployable artifacts such as Docker containers, ZIP files, or application bundles. These artifacts are stored in repositories for deployment.
• Deploy: The application is automatically deployed to staging or production environments using deployment tools. Infrastructure automation ensures consistency across different environments.
• Verify and Monitor: After deployment, monitoring tools check the application for performance issues, security vulnerabilities, and operational stability. Feedback from this stage helps improve future builds.

Common CI/CD Tools

• GitHub Actions: A cloud-based automation tool integrated with GitHub repositories for building and testing applications.
• GitLab CI/CD: Provides a complete DevOps platform with built-in CI/CD pipelines and security scanning features.
• Jenkins: A widely used open-source automation server that supports customizable pipelines and plugin integrations.
• Azure DevOps: A Microsoft platform that offers CI/CD pipelines, repository management, testing tools, and project tracking.

Security Gates in the Pipeline

• SAST (Static Application Security Testing): Analyzes source code to detect vulnerabilities such as SQL injection, cross-site scripting, and insecure coding practices.
• SCA (Software Composition Analysis): Scans third-party libraries and dependencies to identify known vulnerabilities.
• Secrets Scanning: Detects accidentally exposed credentials such as API keys, passwords, and tokens within the codebase.
• DAST (Dynamic Application Security Testing): Tests running applications to identify vulnerabilities during runtime.
• IaC Scanning: Evaluates Infrastructure as Code templates (e.g., Terraform, CloudFormation) to detect insecure configurations.
• Container Security Scanning: Analyzes container images to detect vulnerabilities, misconfigurations, and outdated packages.

# Example: GitHub Actions with SAST + SCA gates
name: ci
on: [push, pull_request]

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-node@v4
        with:
          node-version: 20

      - run: npm ci

      - run: npm test -- --ci

      - name: SAST
        uses: github/codeql-action/analyze@v3

      - name: SCA (npm audit)
        run: npm audit --audit-level=high

Security in the CI/CD pipeline is a key principle of DevSecOps. Instead of treating security as a separate stage at the end of development, security checks are integrated throughout the pipeline. Automated security testing tools continuously scan the source code, dependencies, infrastructure configurations, and running applications to identify vulnerabilities early. This approach helps organizations detect and fix security issues before software is deployed to production, reducing the risk of cyberattacks and security breaches.

• SAST (Static Application Security Testing): Static Application Security Testing analyzes the source code, bytecode, or binaries without executing the program. It identifies vulnerabilities such as SQL injection, cross-site scripting (XSS), insecure authentication mechanisms, and improper input validation. Since SAST is performed during the early stages of development, developers can fix issues quickly before the application progresses further in the pipeline. Popular SAST tools include CodeQL, SonarQube, and Checkmarx.
• DAST (Dynamic Application Security Testing): Dynamic Application Security Testing evaluates the application while it is running. Unlike SAST, which analyzes code statically, DAST simulates real-world attacks against a deployed application to identify vulnerabilities such as authentication flaws, server misconfigurations, and injection attacks. DAST tools are commonly used to detect vulnerabilities listed in the OWASP Top 10 security risks. Examples include OWASP ZAP and Burp Suite.
• SCA (Software Composition Analysis): Modern applications rely heavily on third-party libraries and open-source components. Software Composition Analysis tools scan these dependencies to detect known vulnerabilities, outdated packages, and licensing issues. By identifying insecure or unsupported libraries, organizations can update or replace them before deployment. Tools such as Snyk, Dependabot, and WhiteSource are commonly used for SCA.
• Secret Scanning: Developers sometimes accidentally commit sensitive information such as API keys, passwords, tokens, or private certificates to version control repositories. Secret scanning tools analyze code commits and pull requests to detect exposed credentials before they are merged into the main branch. This helps prevent unauthorized access to systems, databases, and cloud services.
• Policy as Code: Policy as Code allows organizations to define security and compliance rules in a machine-readable format that can be automatically enforced within the CI/CD pipeline. Tools such as Open Policy Agent (OPA) and Conftest evaluate infrastructure configurations, container images, and deployment templates against predefined security policies. If a configuration violates the policy, the pipeline can automatically fail the build, ensuring that only secure and compliant applications are deployed.

Secrets management is a critical component of DevSecOps that focuses on securely storing, accessing, and managing sensitive information used by applications and infrastructure. Secrets typically include passwords, API keys, encryption keys, tokens, database credentials, and certificates. If these secrets are exposed or improperly managed, attackers may gain unauthorized access to systems, data, and services. Therefore, organizations must implement secure mechanisms to protect secrets throughout the software development and deployment lifecycle.

• Use Managed Secret Stores: Instead of storing credentials directly in code repositories or configuration files, organizations should use dedicated secret management services. Tools such as Azure Key Vault, AWS Secrets Manager, and HashiCorp Vault provide secure storage for sensitive information. These platforms offer features like encryption, access control, automatic rotation, and audit logging to ensure that secrets remain protected and accessible only to authorized users or services.
• Avoid Storing Secrets in Source Code: Storing secrets directly in application code, configuration files, or CI/CD environment variables in plaintext can lead to accidental exposure through version control systems. Developers should follow best practices such as retrieving secrets dynamically from secure vaults during runtime. This prevents sensitive data from being stored permanently in repositories or build artifacts.
• Credential Rotation and Short-Lived Tokens: Regularly rotating credentials helps reduce the risk of long-term exposure if a secret is compromised. Organizations should implement automated credential rotation policies and use short-lived access tokens whenever possible. Workload identities and temporary credentials allow applications to access resources securely without relying on permanent secrets.
• Encryption and Secure Transmission: Secrets must always be encrypted both at rest and in transit. Encryption at rest protects stored credentials in secret management systems, while encryption in transit ensures that sensitive data cannot be intercepted during communication between services. Secure protocols such as HTTPS and TLS are commonly used to safeguard this communication.
• Access Control and Auditing: Proper access control mechanisms should be implemented to ensure that only authorized users, applications, or services can retrieve specific secrets. Role-based access control (RBAC) and least-privilege principles help limit exposure. Additionally, secret management platforms maintain audit logs that track when secrets are accessed, modified, or rotated, enabling organizations to detect suspicious activities and maintain compliance with security standards.

• Use minimal base images, pin versions, and scan images (Trivy, Grype).
• Run as non-root; drop capabilities; use read-only file systems.
• Sign images (Sigstore cosign) and enforce admission policies (OPA/Gatekeeper, Kyverno).

FROM node:20-alpine
USER node
WORKDIR /app
COPY --chown=node:node package*.json ./
RUN npm ci --omit=dev
COPY --chown=node:node . .
CMD ["node", "server.js"]

• Pin dependencies; verify provenance (SLSA levels), SBOM generation (CycloneDX, SPDX).
• Sign artifacts (cosign, GPG) and enforce signature verification.
• Use registries with malware scanning and access control.

• Scan Terraform/CloudFormation/K8s manifests with tools like Checkov, tfsec, kube-score.
• Enforce least privilege in IAM policies; avoid wildcards.
• Use drift detection and immutable infra patterns.

• Centralized logging (ELK, Loki), metrics (Prometheus), traces (OpenTelemetry).
• Compliance frameworks: SOC2, ISO 27001, PCI-DSS, HIPAA; automate evidence collection.
• Alerting and runbooks for incident response; security SLIs/SLOs.

• Continuous scanning of code, dependencies, images, and infra.
• Prioritize by CVSS, exploitability, and asset criticality; track SLAs.
• Automate patching/updates; verify fixes in CI/CD.

• IR phases: Preparation → Detection → Containment → Eradication → Recovery → Lessons learned.
• Threat modeling: STRIDE, attack trees; identify trust boundaries and mitigations.
• Tabletop exercises and postmortems to improve resilience.

• Secure a CI pipeline: add SAST, SCA, secrets scan, IaC scan, signed artifacts.
• Respond to Log4Shell: identify affected services, patch/upgrade, deploy quickly, add WAF rules, monitor.
• Kubernetes hardening: NetworkPolicies, PodSecurity, RBAC least privilege, image policies.

• OWASP Top 10
• SLSA Framework
• OWASP Cheat Sheet Series
• OpenSSF Scorecard