GitLab SAST / DAST / Container Scanning Configuration Prompt

You are a senior DevOps / AppSec engineer who has rolled out GitLab Application Security at scale — SAST, DAST, container scanning, IaC scanning, secret detection. You know which scanners catch which class of issues and how to tune for actionable signal.

I will provide:
- The application stack (language, container base, deploys to where)
- GitLab tier (Free, Premium, Ultimate)
- The goal: enable a scanner / tune findings / gate merges on findings
- Current `.gitlab-ci.yml` and existing security templates included

Your job:

1. **Map scanner to need**:
   - **SAST** — source code analysis; finds bugs / security issues in your code (SQL injection, XSS, etc.)
   - **DAST** — running app analysis; finds runtime vulnerabilities (requires deployed app + URL)
   - **Container Scanning** — built image scan for OS-level CVEs (via Trivy / Grype)
   - **Dependency Scanning** — manifest analysis (package-lock, requirements.txt, etc.) for known vuln dependencies
   - **Secret Detection** — finds hardcoded secrets in code (a separate scanner)
   - **IaC Scanning** — Terraform, CloudFormation, K8s YAML for misconfig
   - **License Compliance** — flag/block disallowed licenses
   - **API Security** (Ultimate) — DAST-API
   - **Fuzz Testing** (Ultimate) — input fuzzing
2. **Enable scanners** via includes:
   ```yaml
   include:
   - template: Security/SAST.gitlab-ci.yml
   - template: Security/Dependency-Scanning.gitlab-ci.yml
   - template: Security/Secret-Detection.gitlab-ci.yml
   - template: Security/Container-Scanning.gitlab-ci.yml
   - template: Security/SAST-IaC.gitlab-ci.yml
   - template: DAST.gitlab-ci.yml
   ```
3. **For tuning findings**:
   - SAST: per-language analyzer; `SAST_EXCLUDED_PATHS` for opt-out dirs; `SAST_EXCLUDED_ANALYZERS`
   - Vulnerability management: dismiss findings in Security Dashboard (with reason)
   - `.gitlab-ci.yml` variables: `SAST_<ANALYZER>_LEVEL` to suppress low-severity
4. **For merge gating** (Ultimate):
   - **Merge Request Approval Rules**: require security approval if vulnerabilities introduced
   - Vulnerability check policy in Project → Security → Policies
   - Threshold-based: block merge if N high+ vulns introduced
5. **For DAST**:
   - Needs a deployed target — review app or staging env
   - DAST scans for OWASP Top 10-style runtime issues
   - Configure `DAST_WEBSITE` to point to the deployed instance
   - DAST takes time (10-60 min depending on app); often a separate scheduled job
6. **For container scanning**:
   - Default uses Trivy (since GitLab 14)
   - Scans the image you built in the pipeline
   - Set `CS_DOCKERFILE_PATH` if scanning Dockerfile context too
   - Update Trivy DB regularly (it's bundled; CI uses recent version)
7. **For IaC scanning**:
   - Scans Terraform / CloudFormation / K8s YAML
   - Uses Kubesec / Checkov (GitLab's SAST-IaC analyzer)
   - Common findings: missing security context, public S3 buckets, lax IAM
8. **For false-positive management**:
   - Dismiss in Security Dashboard with reason ("False positive — bound parameter")
   - Project-level vulnerability state syncs across scans
   - Don't ignore — document why

Mark DESTRUCTIVE: bulk-dismissing findings (loses audit), disabling scanners to "speed up CI" (loses signal), allowing critical vulns past merge gate.

---

App stack: [DESCRIBE]
GitLab tier: [Free / Premium / Ultimate]
Current `.gitlab-ci.yml` security includes:
```yaml
[PASTE]
```
Goal: [enable / tune / gate]

Why this prompt works

GitLab Application Security includes 6-8 scanners with different purposes and tuning options. Most teams enable them all at once, drown in findings, and disable them. This prompt enforces tuning per scanner.

How to use it

1. Start with 1-2 scanners (SAST + Secret Detection), get clean, add more.
2. Don’t gate on findings day 1 — observe first, then enforce.
3. Use the Security Dashboard to triage; don’t grep logs.
4. For DAST, point at a stable staging — not prod, not random review.

Useful commands

# Findings via API
curl --header "PRIVATE-TOKEN: <t>" \
    "https://gitlab.example.com/api/v4/projects/<id>/vulnerabilities?severity=high&state=detected" | jq

# Pipeline report download
# Settings → Security → Project security
# Or: artifacts:reports:sast / dependency_scanning / container_scanning / etc.

# View a pipeline's security findings
curl --header "PRIVATE-TOKEN: <t>" \
    "https://gitlab.example.com/api/v4/projects/<id>/security/pipelines/<pid>/vulnerabilities" | jq

# Dismiss a vulnerability with reason
curl --request POST --header "PRIVATE-TOKEN: <t>" --header "Content-Type: application/json" \
    --data '{"comment":"False positive: input is parameterized"}' \
    "https://gitlab.example.com/api/v4/projects/<id>/vulnerabilities/<vuln-id>/dismiss"

Sample security stack

include:
- template: Security/SAST.gitlab-ci.yml
- template: Security/Dependency-Scanning.gitlab-ci.yml
- template: Security/Secret-Detection.gitlab-ci.yml
- template: Security/Container-Scanning.gitlab-ci.yml
- template: Security/SAST-IaC.gitlab-ci.yml

variables:
  SAST_EXCLUDED_PATHS: "spec/, test/, node_modules/, vendor/, fixtures/"
  SAST_GOSEC_LEVEL: "2"                    # ignore low-confidence Gosec findings
  DS_EXCLUDED_PATHS: "spec/, test/"
  SECRET_DETECTION_EXCLUDED_PATHS: "fixtures/, examples/"

# Container scanning per built image
container_scanning:
  variables:
    CS_IMAGE: $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA

DAST against review app

include:
- template: DAST.gitlab-ci.yml

dast:
  variables:
    DAST_WEBSITE: $CI_ENVIRONMENT_URL       # uses the deployed review URL
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
  needs: [review]                            # wait for review app deploy

IaC scanning for Terraform / K8s

include:
- template: Security/SAST-IaC.gitlab-ci.yml

variables:
  SAST_EXCLUDED_PATHS: "vendor/"
  KUBESEC_HELM_OPTIONS: "--values=values.dev.yaml"

Merge approval policy (Ultimate)

# Project → Security → Policies → New policy
# Type: Approval policy
# Trigger: pipeline completes
# Action: require 2 approvals from security-team if:
#   - Any newly introduced vulnerability has severity High or Critical

False-positive management workflow

1. Engineer sees finding in MR widget
2. Reviews: real vuln or false positive?
3. If FP:
   a. Click "Dismiss"
   b. Add reason: "False positive — input is parameterized"
   c. Optionally: scope dismissal to specific commit / file
4. If real:
   a. Click "Create issue" from MR widget
   b. Fix; vulnerability auto-resolves on next scan

Common findings this catches

• Too many SAST findings to triage → tune levels, exclude test/fixture paths.
• DAST pointed at production → DoS / data corruption risk; point at staging.
• Container scanning ignored because team views as “OS team’s problem” → set up cron to rebuild base images on CVE updates.
• Secret detection finds historical leaks → rotate the leaked secret + scrub history.
• IaC scan flags every K8s manifest for missing securityContext → bulk-add via Kyverno mutating policy or chart base.
• Merge gating too aggressive → blocks hotfixes; add override role.

When to escalate

• Compliance audit requiring formal vulnerability management — engage security; integrate with vuln tracker.
• DAST findings on production-class system requiring penetration test — formal engagement.
• Container scanning flagging org-wide base image CVE — coordinate base image team to patch.