CDN Pipeline Security Scanning: SAST, DAST, and Configuration Auditing in CI/CD

I’ll never forget the Friday afternoon when a junior dev’s pull request slipped through with a hardcoded origin token in a CDN Worker script. It passed code review, deployed to production, and sat exposed at the edge for 11 hours before our SOC flagged it. That incident taught me pipeline security isn’t an optional add-on for CDN workflows — it’s the only thing standing between a fast deployment and a very public breach.

The CDN Pipeline Is Bigger Than Your Code

When folks think about CDN CI/CD security, they picture the application code. In reality, your pipeline handles far more sensitive material than that. You’ve got Terraform or Pulumi definitions that control origin shielding, WAF rules, edge functions, TLS settings, and cache invalidation logic. A single exposure in that chain can compromise every PoP you operate. I’ve audited pipelines where AWS credentials, Fastly API tokens, and Cloudflare zone keys were all available as plaintext environment variables in build logs. The code was clean, but the pipeline was an open door.

That’s why pipeline security has to cover the delivery mechanism itself, not just what you’re delivering. We’re talking about securing the runners, locking down artifact storage, scanning IaC before it’s applied, and auditing the final edge configuration after deployment. If you’re managing CDN infrastructure as code, you can’t treat security scanning as a final stage gate — it has to be woven through every step. Teams I’ve worked with that shift this left catch 80% of issues before they even hit a staging environment, and it saves hours of frantic rollbacks later. For anyone still templating CDN configs in YAML, it’s worth comparing modern approaches like CDN Infrastructure with Pulumi: Type-Safe CDN Configuration in Real Programming Languages which gives you compile-time checks that raw templates simply don’t provide.

# .github/workflows/cdn-pipeline-security.yml
name: cdn-secure-pipeline
on: [push, pull_request]

jobs:
  secure-build:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      security-events: write
    steps:
      - uses: actions/checkout@v4
      
      - name: Harden Runner & Mask Secrets
        uses: step-security/harden-runner@v2
        with:
          egress-policy: block
          allowed-endpoints: >
            api.github.com:443
            registry.npmjs.org:443
            
      - name: Scan IaC for CDN Misconfigurations
        uses: aquasecurity/trivy-action@master
        with:
          scan-type: 'config'
          scan-ref: './cdn/terraform'
          severity: 'HIGH,CRITICAL'
          format: 'sarif'
          
      - name: Upload SARIF to Code Scanning
        uses: github/codeql-action/upload-sarif@v3
        with:
          sarif_file: 'trivy-results.sarif'

Putting SAST and DAST Where They Actually Help

SAST and DAST get thrown around a lot, but most teams implement them wrong for CDN workloads. SAST — static application security testing — works without running your code. It’s brilliant for catching hardcoded secrets, insecure edge function logic, and risky open-source dependencies before you merge. I run SAST directly on our Workers and Lambda@Edge codebase and on the IaC that defines them. It’ll flag things like a missing origin authentication check or a regex that’s vulnerable to ReDoS at the edge, which would be catastrophic under load. The trick is tuning it so developers don’t get buried in noise. Start with high-confidence rules for your CDN stack and expand gradually.

DAST is the opposite. It tests the running system by attacking it like an outsider would. For CDNs, that means spinning up a disposable staging distribution — complete with WAF, cache rules, and origin failover — and hitting it with OWASP ZAP or Burp Suite. You’ll find issues SAST can’t see, like cache poisoning via header manipulation, overly permissive CORS headers, or WAF rules that don’t actually block in blocking mode. I learned this the hard way when a SAST-clean deployment still allowed cache deception because our Cache-Key included an unvalidated query parameter. Only DAST caught it, because it saw how the edge actually behaved. The HTTP Working Group Specifications are essential reading here for understanding how headers like Cache-Control and CDN-Cache-Control should behave under test.

Don’t run DAST against production. I’ve seen teams take down their own origins with aggressive spidering. Instead, wire it into your ephemeral environment stage. Here’s how we run a lightweight ZAP scan against a preview CDN URL after Terraform applies. If you’re still on CloudFormation for your edge resources, the patterns in CDN Resources in CloudFormation: AWS-Native Infrastructure as Code for Content Delivery translate directly — you just swap the IaC scan step and keep the DAST logic identical.

# Run DAST against ephemeral CDN staging distribution
stages:
  - deploy_staging
  - dast_scan

dast_scan:
  image: owasp/zap2docker-stable
  script:
    # Wait for edge propagation
    - sleep 60
    - zap-baseline.py 
        -t https://staging-cdn-preview.example.net
        -r zap-report.html
        -c zap-config.conf
        --auto
    # Fail pipeline on HIGH risk alerts
    - zap-cli --alert-level HIGH report
  artifacts:
    reports:
      html: zap-report.html
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"

Configuration Auditing Is Where CDN Breaches Hide

If SAST finds bugs in your code and DAST finds bugs in your running app, config auditing finds bugs in your assumptions. That’s the scariest category for CDN automation. A Terraform plan can be syntactically perfect and still open your S3 origin to the public, disable TLS 1.2 enforcement, or set a Cache-Control: public, max-age=86400 on authenticated content. I’ve seen a one-line change in a cache rule accidentally bypass token validation for an entire video-on-demand library. No code vulnerability, just a bad config that no application scanner would flag.

Effective config auditing compares your desired state, your IaC files, and your actual edge state. Tools like Checkov, OPA/Conftest, and Cloud Custodian let you write policies as code: “No origin should allow HTTP”, “All distributions must enforce HSTS”, “Edge functions can’t expose x-origin-key”. We run these as a mandatory check on every pull request and again post-deploy to catch drift. The post-deploy check is critical because someone can still make a manual click-ops change in the console that Terraform won’t know about until the next run. Guidance from web.dev Articles on security headers and caching best practices is a solid baseline for writing those policies, especially for header auditing.

For large estates with hundreds of routes and edge dictionaries, manual review doesn’t scale. That’s why teams automating at scale often standardize with CDN Automation with Ansible Playbooks: Configuration Management at Edge Scale — it gives you idempotent, auditable runs where you can inject policy checks before any edge node is touched. The goal isn’t zero misconfigs; it’s catching them within minutes, not months.

From Theory to Pipeline: A Practical Implementation That Doesn't Kill Velocity

Here's where most teams get it wrong — they bolt all three scanners onto every pull request and then wonder why developers start bypassing CI. You don't need a 12-minute DAST crawl on a one-line VCL typo fix. We've found the sweet spot is tiered execution: SAST and configuration auditing run on every commit and must pass in under 90 seconds, while full DAST only runs against an ephemeral staging environment on merges to main or nightly against production canaries. That keeps your PR feedback loop tight but still catches the big stuff before it hits 1,200 edge nodes.

For config auditing, don't just lint your YAML — policy-as-code is what actually saves you. If you're generating Varnish, Nginx, or ATS configs from templates, you're one bad variable away from disabling TLS 1.3 or opening /purge to the world. We run Conftest with OPA/Rego policies directly against the rendered configs, not the source templates. This works whether you're using CDN Configuration with Chef: Recipe-Based Infrastructure for Content Delivery or managing fleets with CDN Puppet Management for Edge Nodes: Declarative Configuration at Scale. And if you're still wrestling with Jinja2 vs. Go templates, get your rendering pipeline solid first — see CDN Configuration Templating: Jinja2, HCL, and Go Templates for Edge Configs — because auditing a template that never renders the same way twice is useless. Our policy set blocks deploys if it finds origin headers exposed, cache-key collisions, or WAF rules set to monitor-only.

# .github/workflows/cdn-security-pipeline.yml
name: cdn-security-scan
on: [pull_request, push]

jobs:
  sast-and-config-audit: # Fast feedback - runs on every PR (~60-90s)
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: SAST Scan (Semgrep)
        run: |
          semgrep --config auto --error --severity ERROR \
            --exclude-rule generic.secrets.api-key
          # Fail on high/critical, warn on medium
      - name: Render Edge Configs
        run: python render_templates.py --env staging --out ./rendered/
      - name: Config Audit (Conftest / OPA)
        run: |
          conftest test ./rendered/*.vcl ./rendered/*.conf \
            --policy ./policies/cdn-rego/ --fail-on-warn
          # Policies: no TLS <1.2, no wildcard CORS, require HSTS 31536000

  dast-staging: # Slow scan - only on main or nightly
    if: github.ref == 'refs/heads/main'
    needs: sast-and-config-audit
    runs-on: ubuntu-latest
    steps:
      - name: OWASP ZAP Baseline (DAST)
        run: |
          docker run -t owasp/zap2docker-stable zap-baseline.py \
            -t https://staging-cdn-preview.yourdomain.net \
            -r zap-report.html --autooff -I -j
          # Throttled to 50 req/s to avoid self-inflicted DoS

That separation is critical. The first job is a hard gate — if Semgrep finds a critical or Conftest fails a policy, the build stops. No exceptions. The DAST job is informational on PRs but blocking on main; we've tuned it to fail only on High/High confidence alerts after we got burned alerting on every low-risk missing X-Content-Type-Options header on static assets. It adds about 4-6 minutes, but it runs in parallel to your integration tests so it rarely extends total pipeline time.

Advanced Patterns and Troubleshooting When Scans Lie to You

Once you've got the basics wired, you'll hit the real CDN-specific pain: noise and drift. SAST tools are notorious for flagging every edge handler that reads a header as "tainted input" — we saw 300+ false positives in a single Fastly Compute@Edge repo until we wrote custom taint rules that understood req.http.X-Forwarded-For is expected but backend.fetch() with unsanitized query params is not. Don't just lower the severity; tune the rules. We maintain a .semgrepignore and a custom rule pack that cuts false positives by about 70%, and we suppress with code comments that require a ticket ID so suppressions expire.

DAST is even flakier. Your biggest headache will be authentication and cache poisoning. DAST crawlers will hammer your staging origin and get 60% cache HITs, which means they're not actually testing origin logic. We solve this by deploying a dedicated dast.yourdomain.net origin that bypasses edge cache via a header (X-Dast-Bypass: 1) validated only from our CI IP range, and we seed it with canary paths that return known vulnerable patterns. If your DAST suddenly goes green after months of findings, it didn't get better — your crawler is probably getting blocked by your own rate limiting or bot management. Check your edge logs; if you see 429s from the scanner IP, you've got your answer. Throttle ZAP to 20-30 requests/sec and whitelist its user-agent in staging.

For config auditing failures in production, treat them like a failed health check, not a code bug. We've seen Puppet or Chef runs silently revert a manual hotfix, reintroducing a bad TLS cipher because the rendered config drifted from the audited artifact. The fix was to audit the *artifact* pulled from the last successful node run, not just the repo. Store the rendered config as a CI artifact and compare its SHA256 to what's actually on 5% of your edge nodes via a post-deploy job. If the hashes don't match within 10 minutes of deploy, auto-rollback. It's saved us twice in the last quarter when a templating error slipped through.

Frequently Asked Questions