# DevOps Pipeline Security in 2026: DevSecOps Best Practices and Interview Questions

> Master DevSecOps pipeline security with SAST, DAST, secrets management, OIDC authentication, and supply chain protection. Includes common interview questions and answers for DevOps security roles.

- Published: 2026-09-08
- Updated: 2026-09-08
- Author: Anthony Fillion-Maillet
- Tags: devops, devsecops, security, ci-cd, interview
- Reading time: 12 min

---

DevOps pipeline security has become a critical differentiator for organizations shipping software at scale. The [OWASP Top 10 CI/CD Security Risks](https://owasp.org/www-project-top-10-ci-cd-security-risks/) identifies the most dangerous vulnerabilities in modern pipelines, from insufficient flow control to compromised build dependencies. This guide covers the essential DevSecOps practices that interviewers expect candidates to know in 2026.

> **Shift-Left Security**
>
> DevSecOps integrates security checks at every stage of the software delivery lifecycle. Instead of treating security as a final gate before production, shift-left practices catch vulnerabilities during development when fixes cost less and ship faster.

## Understanding the CI/CD Attack Surface

Modern CI/CD pipelines present a complex attack surface spanning source code repositories, build runners, artifact registries, and deployment targets. The tj-actions/changed-files compromise in March 2025 leaked secrets from over 23,000 repositories by injecting malicious code into a widely-used GitHub Action. The TanStack attack in early 2026 published 170+ poisoned npm packages with valid SLSA Build Level 3 provenance, demonstrating that even cryptographic attestations can be bypassed when attackers control the build process.

These incidents highlight three critical control points:

- **Source integrity**: Branch protection rules, signed commits, and required code reviews prevent unauthorized changes from reaching the build pipeline
- **Build isolation**: Ephemeral runners, minimal permissions, and artifact verification limit the blast radius of compromised dependencies
- **Secrets hygiene**: Short-lived credentials, OIDC federation, and secrets scanning eliminate the static tokens attackers seek

Interviewers often ask candidates to trace the trust boundaries in a typical deployment pipeline. A strong answer maps each stage where an attacker could inject code or exfiltrate credentials.

## SAST and SCA: Catching Vulnerabilities Early

Static Application Security Testing (SAST) analyzes source code for security flaws without executing the program. Software Composition Analysis (SCA) identifies known vulnerabilities in third-party dependencies. Running both on every pull request catches the majority of common security issues before code merges.

```yaml
# .github/workflows/security.yml
name: Security Scan

on:
  pull_request:
    branches: [main]

jobs:
  sast:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      security-events: write
    steps:
      - uses: actions/checkout@v4
      
      - name: Run CodeQL
        uses: github/codeql-action/analyze@v3
        with:
          languages: javascript,typescript
          queries: security-extended

  sca:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      
      - name: Run Trivy vulnerability scanner
        uses: aquasecurity/trivy-action@0.28.0
        with:
          scan-type: fs
          scan-ref: .
          severity: HIGH,CRITICAL
          exit-code: 1
```

The workflow above runs CodeQL for SAST and Trivy for SCA. Setting `exit-code: 1` on Trivy fails the build when high or critical vulnerabilities appear. GitHub Advanced Security and GitLab Ultimate include built-in SAST capabilities that integrate with their respective merge request workflows.

## Secrets Management with OIDC Federation

Long-lived credentials stored in CI/CD platforms remain the most exploited attack vector in pipeline compromises. [GitHub Actions OIDC](https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/configuring-openid-connect-in-cloud-providers) replaces static secrets with short-lived tokens issued by the cloud provider at runtime.

```yaml
# .github/workflows/deploy.yml
name: Deploy to AWS

on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    permissions:
      id-token: write  # Required for OIDC
      contents: read
    steps:
      - uses: actions/checkout@v4
      
      - name: Configure AWS credentials via OIDC
        uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::123456789012:role/GitHubActionsRole
          aws-region: us-east-1
          # No AWS_ACCESS_KEY_ID or AWS_SECRET_ACCESS_KEY stored anywhere
      
      - name: Deploy to ECS
        run: aws ecs update-service --cluster prod --service api --force-new-deployment
```

The AWS IAM role trust policy restricts which repositories and branches can assume the role:

```json
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::123456789012:oidc-provider/token.actions.githubusercontent.com"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "token.actions.githubusercontent.com:aud": "sts.amazonaws.com"
        },
        "StringLike": {
          "token.actions.githubusercontent.com:sub": "repo:my-org/my-repo:ref:refs/heads/main"
        }
      }
    }
  ]
}
```

The condition restricts credential issuance to the `main` branch of a specific repository. Azure and GCP offer equivalent OIDC federation capabilities. For secrets that must exist, [HashiCorp Vault](https://www.vaultproject.io/) and cloud-native options like AWS Secrets Manager provide centralized rotation and access logging.

## Container Security and SBOM Generation

Container images introduce dependencies beyond application code. Base images, system packages, and build tools all carry potential vulnerabilities. Scanning images during the build process and generating a Software Bill of Materials (SBOM) provides visibility into the complete dependency chain.

```yaml
# GitLab CI container security
container_scanning:
  stage: test
  image: registry.gitlab.com/gitlab-org/security-products/analyzers/container-scanning:7
  variables:
    CS_IMAGE: $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
    CS_DOCKERFILE_PATH: Dockerfile
  script:
    - /analyzer run
  artifacts:
    reports:
      container_scanning: gl-container-scanning-report.json
      cyclonedx: gl-sbom.cdx.json
```

The SBOM artifact in CycloneDX format enables downstream consumers to check for newly disclosed vulnerabilities without rebuilding. Supply chain security frameworks like SLSA require SBOM generation as a baseline control.

## Dynamic Application Security Testing in Staging

DAST tools test running applications for vulnerabilities that static analysis cannot detect, including authentication flaws, injection vulnerabilities, and security misconfigurations. Running DAST against a staging environment before production deployment catches issues that survive earlier gates.

```yaml
# .gitlab-ci.yml
dast:
  stage: dast
  image: registry.gitlab.com/gitlab-org/security-products/analyzers/dast:5
  variables:
    DAST_WEBSITE: https://staging.example.com
    DAST_AUTH_URL: https://staging.example.com/login
    DAST_USERNAME: $DAST_USER
    DAST_PASSWORD: $DAST_PASSWORD
    DAST_AUTH_VERIFICATION_URL: https://staging.example.com/dashboard
  script:
    - /analyze
  artifacts:
    reports:
      dast: gl-dast-report.json
  rules:
    - if: $CI_COMMIT_BRANCH == "main"
```

[OWASP ZAP](https://www.zaproxy.org/) provides a free alternative for teams without GitLab Ultimate. Authenticated scans test functionality behind login walls where sensitive operations typically reside. For [Kubernetes environments](/technologies/devops/interview-questions/kubernetes-basics), API security testing validates ingress configurations and service mesh policies.

## Infrastructure as Code Security Scanning

Terraform, Kubernetes manifests, and Helm charts define infrastructure that attackers target. IaC scanning catches misconfigurations before they reach cloud environments.

```yaml
# Checkov IaC scanning in GitHub Actions
iac-scan:
  runs-on: ubuntu-latest
  steps:
    - uses: actions/checkout@v4
    
    - name: Run Checkov
      uses: bridgecrewio/checkov-action@v12
      with:
        directory: terraform/
        framework: terraform
        soft_fail: false
        output_format: sarif
        output_file_path: checkov.sarif
    
    - name: Upload SARIF
      uses: github/codeql-action/upload-sarif@v3
      with:
        sarif_file: checkov.sarif
```

Checkov validates [Terraform configurations](/technologies/devops/interview-questions/terraform-basics) against security benchmarks including CIS and SOC2. The SARIF output integrates with GitHub Security tab for unified vulnerability tracking. Teams using [Ansible](/technologies/devops/interview-questions/ansible-configuration) can add ansible-lint with security rules to the same pipeline stage.

## GitHub Actions Supply Chain Hardening

Pinning actions to full commit SHAs prevents tag-based attacks where maintainers or compromised accounts force-push malicious versions to existing tags. The Megalodon campaign in May 2026 pushed over 5,700 malicious commits across thousands of repositories in a single six-hour window.

```yaml
# Pin to commit SHA, not tag
steps:
  - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683  # v4.2.2
  
  # Avoid mutable tags like @v4 or @latest
  # Bad: uses: actions/checkout@v4
```

Dependabot updates SHA-pinned actions when new versions release. The [OWASP DevSecOps Guideline](https://github.com/OWASP/DevSecOpsGuideline) recommends additional controls:

- Restrict workflow permissions to minimum required using `permissions:` blocks
- Disable `pull_request_target` triggers or limit them to labeled PRs from collaborators
- Use `GITHUB_TOKEN` with read-only defaults at the organization level
- Enable required status checks and branch protection on default branches

## Common DevSecOps Interview Questions

Interviewers assess both technical depth and practical experience. These questions appear frequently in DevOps security interviews.

**Q: How would you prevent secrets from being committed to a repository?**

Pre-commit hooks with tools like [detect-secrets](https://github.com/Yelp/detect-secrets) or gitleaks scan staged changes before commit. Server-side push rules in GitHub Enterprise or GitLab block commits containing patterns matching known secret formats. Secret scanning should also run in CI as a backstop, since developers can bypass local hooks.

**Q: Explain the difference between SAST, DAST, and SCA.**

SAST analyzes source code without execution, finding bugs like SQL injection patterns and hardcoded credentials. SCA identifies known vulnerabilities in dependencies by matching package versions against CVE databases. DAST tests running applications by sending malicious requests and observing responses. A mature pipeline runs all three: SAST and SCA on every PR, DAST against staging before production releases.

**Q: What is the principle of least privilege in CI/CD?**

Build jobs should have only the permissions required to complete their specific task. A job that deploys to staging does not need production credentials. OIDC federation enforces this by issuing credentials scoped to specific repositories, branches, and workflow jobs. The [OWASP CI/CD Top 10](https://owasp.org/www-project-top-10-ci-cd-security-risks/) lists inadequate identity and access management as a top risk because compromised jobs with excessive permissions expand the attack surface dramatically.

**Q: How do you verify the integrity of container images?**

Content trust signatures (Docker Content Trust, Sigstore cosign) provide cryptographic verification that images were built by trusted pipelines. SBOM attestations document the components inside images. Admission controllers in Kubernetes reject unsigned images or images with known critical vulnerabilities. Registry scanning catches vulnerabilities that appear after build time.

**Q: Describe a supply chain attack on CI/CD and how to prevent it.**

The tj-actions/changed-files attack compromised a widely-used GitHub Action, injecting code that exfiltrated secrets to attacker-controlled endpoints. Prevention measures include: pinning actions to commit SHAs instead of tags, using Dependabot to update pinned versions, restricting which actions can run via organization-level policies, and monitoring workflow runs for unexpected network connections or credential access.

## Building a DevSecOps Roadmap for Technical Interviews

Candidates who demonstrate structured thinking about security implementation stand out. A practical DevSecOps rollout prioritizes high-impact, low-effort controls first:

- Enable secrets scanning and branch protection immediately, since both are free and block the most common attack vectors
- Add SAST and SCA to pull request checks within the first sprint, catching vulnerabilities before merge
- Migrate from static credentials to OIDC federation, eliminating the most dangerous secrets from CI/CD platforms
- Implement container scanning and SBOM generation as part of image builds
- Deploy IaC scanning for Terraform, Kubernetes, and cloud configuration
- Add DAST for applications with authentication or sensitive data handling
- Establish runtime monitoring with Falco or equivalent for production Kubernetes clusters

Interviewers value candidates who acknowledge tradeoffs. Security scanning adds pipeline latency. False positives create alert fatigue. A mature DevSecOps practice tunes thresholds, accepts calculated risks with compensating controls, and continuously measures mean time to remediate.

---

Source: SharpSkill (https://sharpskill.dev), tech interview preparation for your real stack.
HTML version of this page: https://sharpskill.dev/en/blog/devops/devops-pipeline-security-2026-devsecops-interview