Phase 3: CI/CD & Automation

Security Scanning (SAST, DAST)

Intermediate ~4 min read
Think of it this way A friendly analogy. Read this if the technical version feels dense. Show Hide

Imagine you're building a super cool LEGO castle. You want it to be really strong and safe, right? You don't want a villain to sneak in, or a tower to wobble and fall down. In the world of making computer programs and apps, we have a similar idea: making sure they're safe and secure from 'digital villains' (hackers) and unexpected problems. It's much easier to fix a weak spot in your castle while you're still building it or looking at the plans, rather than after it's all done and you're trying to play, only for a wall to tumble down.

This is where two special 'helpers' come in. The first is like your super-smart friend who loves reading instruction manuals. We call this 'Static Application Security Testing' (SAST). Before you even click a single LEGO brick together, your SAST helper looks at all your building plans and every piece you're planning to use. They scan through your blueprints, checking for common mistakes – like if you're planning to use a tiny, weak brick where a big, strong one should go, or if a step in the instructions might accidentally leave a gaping hole in your wall. They don't build anything themselves; they just read the plans to spot potential weaknesses. If they find something, they tell you right away: 'Hey, step three looks like it could make that drawbridge a bit wobbly!'

Once your SAST friend has checked the plans, and you've built your castle (perhaps a practice version), another helper steps in. This is 'Dynamic Application Security Testing' (DAST). Imagine this helper is like a mischievous but friendly knight whose job is to test your finished castle by trying to attack it! They’ll push on walls, try to force open doors, and sneak around, just like a real villain might. They’re checking to see if any part that looked strong on paper actually has a secret weakness when you try to use it. Maybe a tower seemed sturdy from the plans, but when the DAST knight tries to climb it, it wobbles unexpectedly. They test the castle while it's running and ready for play, looking for flaws that only appear during actual use.

So, by having both these helpers – SAST checking the plans and DAST testing the finished build – you can make your LEGO castle (or your computer program) much safer and stronger. When people build apps for phones or websites, they use these tools to catch problems super early. This means that when you eventually play with (or use) an app, it's been double-checked for safety, making it much harder for 'digital villains' to cause trouble and much more reliable for everyone using it.

Security scanning in CI/CD pipelines is about "shifting left" – catching vulnerabilities early, where they're cheaper and easier to fix. Static Application Security Testing (SAST) is one key method. SAST tools analyze your application's source code, bytecode, or binaries without executing the application. They scan for common security flaws like SQL injection, cross-site scripting (XSS), insecure direct object references, or misconfigurations, providing feedback directly to developers. Integrating SAST into your build or commit stages means vulnerabilities are identified almost immediately after they're introduced, preventing them from propagating further down the development lifecycle.

While SAST looks at the internal structure of your code, Dynamic Application Security Testing (DAST) takes an external approach. DAST tools test your running application, often in a staging or test environment, by simulating attacks from a malicious user. They interact with the application over its network interface (HTTP/S), probing for runtime vulnerabilities such as authentication bypasses, misconfigured servers, session management issues, or business logic flaws that might only manifest when the application is live. DAST effectively complements SAST by identifying issues that SAST might miss, particularly those related to the runtime environment, dependencies, or interaction between different application components.

As a DevOps Engineer, your role involves automating both SAST and DAST scans within your CI/CD pipelines. This means configuring tools to run automatically on specific triggers (e.g., every pull request, nightly builds, or before deployment to staging). The goal is to enforce continuous security, generating reports, and potentially failing builds if critical vulnerabilities are found, integrating security as an inherent part of quality. By embedding these scans, you ensure that security checks are not an afterthought but a continuous, automated process, significantly enhancing your application's overall security posture.

Key Takeaways

  • SAST analyzes code before execution; DAST tests the running application.
  • Both are crucial for "shifting left" security in CI/CD pipelines.
  • SAST finds code-level flaws; DAST identifies runtime vulnerabilities and configuration issues.
  • Integrate scans early and often to catch issues faster and reduce remediation cost.
  • Automate security scans in your pipeline to enforce continuous security.

Code Example

yaml
# Minimal example illustrating SAST/DAST stages in a CI/CD pipeline
stages:
  - build
  - test
  - deploy
  - security

# SAST (Static Application Security Testing)
sast_scan:
  stage: security
  script:
    - echo "--- Running SAST scan (e.g., using SonarQube, Bandit, Semgrep) ---"
    - # Command to run your SAST tool here
    - /usr/local/bin/my-sast-tool scan-code --project-path . --output sast-report.json
    - echo "SAST scan complete. Review sast-report.json"
  allow_failure: true # Set to 'false' for stricter policies.

# DAST (Dynamic Application Security Testing)
dast_scan:
  stage: security
  script:
    - echo "--- Running DAST scan (e.g., using OWASP ZAP, Burp Suite) ---"
    - # Assuming application is already deployed to a test environment
    - export APP_URL="http://test-app.mycompany.com"
    - /usr/local/bin/my-dast-tool scan --target $APP_URL --output dast-report.json
    - echo "DAST scan complete. Review dast-report.json"
  needs: ["deploy_to_test_env"] # Example dependency: DAST needs a running app
  allow_failure: true # Set to 'false' for stricter policies.

How this code works

This CI/CD pipeline configuration integrates security scanning directly into an automated workflow. Its primary job is to ensure applications are checked for vulnerabilities using both static and dynamic analysis, helping catch potential issues early within the development and deployment process.

The stages declaration adds a new security phase after typical build, test, and deploy steps. The sast_scan job then performs Static Application Security Testing (SAST). Its script runs a placeholder my-sast-tool directly on the project's code, generating a sast-report.json. Following this, the dast_scan job executes Dynamic Application Security Testing (DAST). The script for DAST scans a live application at the APP_URL, using my-dast-tool to produce a dast-report.json. A crucial, subtle detail for DAST is needs: ["deploy_to_test_env"], which ensures this job only runs once the application is actively deployed and accessible. Both sast_scan and dast_scan also specify allow_failure: true; this is a common initial approach, letting the pipeline continue to completion even if vulnerabilities are found, allowing teams to review results without immediately halting the entire pipeline.

Related Articles

Hand-picked reads to go deeper on testing in pipelines.

Back to DevOps Engineer Roadmap