The tooling landscape

Every category of DevSecOps tooling this course has touched so far — SAST, DAST, SCA, secrets scanning, IaC scanning, container image scanning — plus two you haven't seen yet, CSPM and SIEM, gathered into one categorized reference. For each category: the question it answers, two to four representative tools, and where it actually earns its keep in a real pipeline. Read it as a map of the landscape, not a shopping list.

Why organize by function, not by vendor

The DevSecOps tool market is large, crowded, and consolidating faster than any single course page can track — a product that only scanned dependencies two years ago may now ship secrets scanning and Kubernetes manifest checks in the same CLI. Organizing the landscape by vendor roadmap is a losing game. Organizing it by the question each category answers is more durable, because the questions don't change even when the products answering them do: is this code written safely, does this running system behave safely, are the dependencies I pulled in known-vulnerable, did anyone commit a credential, is this infrastructure definition compliant before it's ever applied, does this container image ship known vulnerabilities, is my live cloud environment misconfigured right now, and is something happening in production that needs a human to look at it. That's eight questions, eight categories, and — worth internalizing before any procurement conversation — no single product answers all eight equally well. The tables below name representative, currently-relevant tools per category; treat the names as orientation, not endorsement or a shopping list.

Scanning the code you write and the code you don't

Three categories attack the same underlying problem — vulnerable code — from three different angles, and the mechanics of each are covered in full on SAST, DAST & SCA. Static analysis (SAST) reads source without executing it, so it can run on every commit and pull request as a required check in CI/CD. Dynamic analysis (DAST) attacks a deployed, running instance from the outside, so it necessarily runs later — against staging, not against a diff. Software composition analysis (SCA) doesn't read your code at all; it matches the open-source and third-party packages you depend on against CVE and NVD data, which matters because a typical production codebase is majority third-party code by line count. None of the three overlaps meaningfully with another — a pipeline missing any one of them has a blind spot the other two structurally cannot close.

Secrets, infrastructure as code, and container images

Three more categories close gaps that source-code analysis alone leaves open. Secrets scanning exists because a hardcoded credential is a real, exploitable finding the moment it lands in a public or even a shared private repository — covered in depth on secrets management, including why scanning git history matters as much as scanning the current tree. IaC and policy-as-code tools evaluate infrastructure definitions — Terraform, CloudFormation, Kubernetes manifests — against policy before terraform apply ever runs, the entire subject of IaC security & policy as code: catching a public-by-default storage bucket or an overly permissive IAM role in a code review instead of in an incident. Container image scanning inspects a built image's OS packages and application dependencies for known CVEs before that image reaches a registry or a cluster, detailed on container & supply-chain security. All three run against artifacts that exist before deployment, which is exactly why they belong earlier in the pipeline rather than after.

Cloud posture and runtime monitoring: CSPM and SIEM

The remaining two categories operate on a live environment rather than a build artifact, and they answer different tenses of the same underlying question. Cloud Security Posture Management (CSPM) tools continuously assess a live cloud account's actual configuration against a benchmark — commonly the CIS Benchmarks or a provider's own well-architected guidance — and flag drift: a security group opened to 0.0.0.0/0, a bucket policy that went public during a hotfix, an IAM role with a wildcard action nobody meant to grant. That's the subject of cloud security posture. SIEM and security-monitoring platforms answer a different question — not "is this configuration wrong" but "is something happening right now" — by aggregating logs, alerts, and findings from every other layer, including the CSPM, container, and IaC tools above, into one queryable, correlated stream that a security operations team actually watches. That aggregation role is why SIEM output feeds directly into incident response & forensics: a SIEM alert is usually where an incident timeline starts.

Choosing tools: pipeline integration over noise

Two practical rules matter more than which specific product you pick in any category above. First, scanning has to run inside the pipeline the team already uses, not as a separate portal someone has to remember to check. A SAST or SCA finding that only surfaces in a security team's dashboard three days after merge gets fixed eventually, if at all; the same finding as a required PR check that blocks merge gets fixed before the code ships, because it's in the path the developer is already on. The YAML below sketches one pipeline wiring all eight categories to the stage where each one's inputs actually exist — source-only checks at PR time, image scanning after a build, DAST after a staging deploy, and CSPM/SIEM running continuously rather than per-deploy, since a cloud account can drift independent of any release. Second, a scanner nobody trusts gets ignored, and an ignored tool provides zero security value regardless of what it's technically capable of catching — tuning severity thresholds and suppressing confirmed false positives, with a documented reason, isn't optional maintenance, it's the difference between a gate and a formality. The security checklist and case study both assume this kind of pipeline-native wiring, not a parallel scanning process bolted on afterward.

# One pipeline, eight scanner categories -- not eight separate portals
stages:
  - pr-checks      # source-only: SAST, SCA, secrets, IaC -- runs on every PR
  - build
  - image-scan     # runs against the built container image
  - deploy-staging
  - dast           # runs against a live target -- needs staging deployed first
  - deploy-prod
  - continuous     # CSPM + SIEM -- scheduled/streaming, not tied to a deploy

pr-checks:
  stage: pr-checks
  script:
    - semgrep ci --config=auto --error          # SAST
    - trivy fs --scanners vuln --exit-code 1 .  # SCA
    - gitleaks detect --source . --exit-code 1  # secrets
    - checkov -d infra/ --compact --quiet       # IaC / policy-as-code
  rules:
    - if: '$CI_PIPELINE_SOURCE == "merge_request_event"'

image-scan:
  stage: image-scan
  script:
    - trivy image --exit-code 1 --severity CRITICAL,HIGH $IMAGE_TAG

dast-scan:
  stage: dast
  needs: ["deploy-staging"]
  script:
    - zap-baseline.py -t https://staging.internal.example.com

cspm-and-siem:
  stage: continuous
  script:
    - prowler aws --output-formats json            # CSPM, scheduled nightly
    - forward-findings --sink siem.internal:9200   # feeds the SIEM, not a standalone dashboard