Skip to main content

DevSecOps and Static Security Scanning

The core of DevSecOps lies in the "Shift Left" approach. This means detecting and fixing security issues early in the development lifecycle. This document explains modern static analysis tools (specifically IaC scanning) and best practices for effectively integrating them into CI/CD pipelines.

Modern Static Security Scanning Tools​

Static analysis can be broadly categorized into SAST (Static Application Security Testing) for analyzing application code and IaC Security Scanning for analyzing infrastructure code.

1. Infrastructure as Code (IaC) Security​

Tools to prevent misconfigurations in cloud infrastructure definitions (Terraform, Kubernetes manifests, ARM/Bicep, CloudFormation, etc.).

  • Checkov:
    • Features: Developed by Palo Alto Networks (formerly Bridgecrew). Supports a wide range of formats including Terraform, CloudFormation, Kubernetes, Dockerfile, and Serverless Framework.
    • Strengths: Rich set of policies and graph-based scanning capabilities for analyzing complex dependencies. Python-based and easily extensible.
  • Trivy:
    • Features: Developed by Aqua Security. Started as a container image scanner and is now an all-in-one tool covering IaC, filesystems, and AWS account settings.
    • Strengths: Fast and easy to install. Excellent usability for both CI/CD and local environments.
  • tfsec (Now integrated into Trivy):
    • Features: A lightweight scanner specialized for Terraform. Although now part of Trivy, it is still often used as a standalone tool.
  • KICS (Keep Infrastructure as Code Secure):
    • Features: Developed by Checkmarx. Has over 2000 queries and supports a very wide range of platforms.

2. Static Application Security Testing (SAST)​

Tools to detect vulnerabilities in the source code itself.

  • SonarQube:
    • Features: An industry standard for code quality and security. Measures code coverage and complexity in addition to static analysis.
  • CodeQL:
    • Features: Provided by GitHub. Treats code as data, allowing you to query it to find vulnerabilities. The core of GitHub Advanced Security.
  • Semgrep:
    • Features: A grep tool that understands syntax (AST). Creating custom rules is very easy, and it is lightweight and fast.

3. Secret Scanning​

Detects API keys and passwords hardcoded in the code.

  • GitGuardian: Strong in monitoring public repositories.
  • TruffleHog: Can scan the entire commit history of a repository.

Best Practices for CI/CD Integration​

It is important not just to introduce tools, but to integrate them appropriately into the development flow.

1. Layered Defense​

Do not try to prevent everything at a single point; check at multiple stages.

  1. IDE / Local Hooks (Pre-commit):

    • Objective: Developers notice issues before committing.
    • Tools: VS Code extensions (Checkov, SonarLint), pre-commit framework.
    • Effect: Shortest feedback loop and lowest cost of remediation.

  2. Pull Request (PR) Checks:

    • Objective: Reviewers verify that merged code complies with policies.
    • Design: Run scans upon PR creation/update; post comments or block merges if checks fail.
    • Important: Output reports in SARIF (Static Analysis Results Interchange Format) to integrate with tabs like GitHub Security for better visibility.

  3. Scheduled Scans (Nightly Build):

    • Objective: Respond to newly discovered vulnerabilities (CVEs) or run detailed scans that take a long time.

2. Blocking vs. Non-Blocking​

  • Blocking (Soft Fail / Hard Fail):
    • Clearly dangerous configurations (e.g., publicly accessible S3 buckets, hardcoded secrets) should be treated as errors and fail the build.
    • With Checkov, it is common practice to treat severity above a certain level as an error without using the --soft-fail option.
  • Non-Blocking (Warning):
    • Deviations from best practices or low-priority fixes should remain as warnings to avoid hindering development speed.

3. Policy as Code​

Manage security rules as code (e.g., OPA/Rego) rather than documents. Checkov allows defining custom policies in Python or YAML. This enables enforcing organization-specific rules (e.g., mandatory tagging, restriction to specific regions).

Implementation Example: GitHub Actions + Checkov​

An example of scanning Terraform code during a PR and displaying results in PR comments and the Security tab.

name: Checkov IaC Scan

on:
  pull_request:
    branches: [ main ]

jobs:
  checkov-scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3

      - name: Run Checkov action
        id: checkov
        uses: bridgecrewio/checkov-action@master
        with:
          directory: ./terraform
          # Fail only on HIGH and CRITICAL
          soft_fail: false
          framework: terraform
          output_format: cli,sarif
          output_file_path: console,results.sarif

      # Upload results to GitHub Security tab
      - name: Upload SARIF file
        if: success() || failure()
        uses: github/codeql-action/upload-sarif@v2
        with:
          sarif_file: results.sarif

Summary​

In practicing DevSecOps, tools like Checkov and Trivy are powerful allies. However, introducing tools is not the goal. Creating an "environment where developers can perform security checks without stress" leads to the sustainability of secure software development. We recommend starting with warning displays locally or in CI, and gradually introducing stricter blocking rules.