SAST, Secret Detection, Dependency Scanning, Container Scanning, DAST, and Coverage-Guided Security: Configuration, Design Choices, and Tradeoffs

1. Start with the assurance question, not the scanner checkbox

A security program becomes noisy and expensive when every repository enables every available scanner at maximum scope without asking what risk the scanner is intended to reduce. Start with assets and decisions: source merge, dependency upgrade, container promotion, test-environment release, production deployment. Attach evidence to those decisions.

2. GitLab-integrated scanning versus external scanner integration

3. Broad coverage versus pipeline latency and compute

Feedback loses value if it arrives after developers have switched context. Classify scans by cost and decision point:

Measure job duration, queue time, cache/network use, and failure frequency before adding more parallel scanners. “More scans” can make teams bypass controls if the pipeline becomes chronically unusable.

4. Advisory findings versus blocking gates

Do not confuse a scanner job’s technical success with a risk gate. Security scanners are expected to produce reports when they find issues. A blocking policy should state which evidence, severity/risk, branch/environment, exception process, and owner stops delivery. GitLab Ultimate security policies and approvals can express native enforcement; on Free, use explicit review/check scripts around safe machine-readable evidence or keep the lab advisory.

5. Live vulnerable-app DAST lab versus fixture/simulation

DAST is Ultimate and actively interacts with a running application. GitLab’s documentation explicitly warns against running active DAST against production because it can submit forms, mutate state, trigger bugs, or cause data loss. For this academy chapter, a static DAST report/request fixture is the mandatory path. An optional live DAST extension may target only a disposable local/test application with no real data, credentials, or network reach.

6. Dependency Scanning versus external dependency evidence

GitLab Dependency Scanning is Ultimate in current GitLab 19.3. A Free team can still perform dependency-security work by running an external/open-source SCA tool, generating an SBOM, or consuming advisory output, but must not label that as “GitLab Dependency Scanning.” Chapter 26 will focus on SBOM/dependency-list/vulnerability-management relationships.

7. Analyzer and template version strategy

Security analyzers are code and data dependencies. GitLab-managed templates deliberately evolve with supported GitLab releases. SAST supports per-analyzer SAST_ANALYZER_IMAGE_TAG; secret detection supports SECRETS_ANALYZER_VERSION. Pinning can stabilize an incident/regression, but every pin needs an owner, expiry/review date, and update test.

8. Fork/MR trust: scan untrusted code without granting it trusted execution

Security scanning often targets exactly the code you trust least. Keep that paradox visible. Untrusted MR code should not gain production variables, cloud tokens, internal-network access, host mounts, privileged Docker, or persistent shell-runner state. If a scanner needs private dependencies, design a narrow credential path and consider whether MR pipelines should receive it at all.

Protected variables and protected runners are authorization controls, not obstacles to bypass. A scan that cannot run safely on a fork should degrade to a safe subset or run after trusted review, not receive production secrets.

9. Report retention, privacy, and incident evidence

Security reports are artifacts with retention/access rules. Retention that is too short can erase incident/release evidence; retention that is too broad can preserve sensitive source/secret/request data unnecessarily. Record the report checksum, pipeline/job ID, commit/image digest, schema version, and triage decision in a durable evidence ledger without copying sensitive payloads everywhere.

10. False-positive handling is a governance decision

Before dismissing a finding, verify target identity and scanner rule, reproduce or reason about reachability, and document why the assertion is not exploitable in the current context. Do not suppress a rule globally because one repository has a legitimate exception. GitLab’s advanced false-positive automation/Duo features have additional Ultimate/add-on requirements and should be treated as decision support, not an autonomous security authority.

11. Worked architecture: API service with container deployment

Suppose a team ships a Python API in an OCI image. A sensible evidence path is:

1. SAST + secret detection on every trusted branch/MR pipeline with safe runner boundaries.
2. Dependency evidence from an SBOM/external SCA or GitLab Dependency Scanning where Ultimate is available.
3. Container scan on the exact candidate image digest after build.
4. Optional DAST against the test deployment that runs that same digest.
5. Release gate compares source SHA + package/image digest + required evidence IDs; deployment consumes the digest, not only a tag.

This model avoids the common error of scanning source A and deploying image B.

12. Decision table

Knowledge check

Summary

Security-scanning architecture is a portfolio of evidence lanes, not a checklist. Control scope, trust, update cadence, retention, and policy separately so the system can evolve without weakening delivery or creating false assurance.

Official references

Primary sources used for the current GitLab 19.3 behavior taught in this lesson:

• GitLab Docs — Application security testing
• GitLab Docs — SAST
• GitLab Docs — SAST analyzers
• GitLab Docs — Pipeline secret detection
• GitLab Docs — Customize pipeline secret detection
• GitLab Docs — Dependency scanning
• GitLab Docs — Container scanning
• GitLab Docs — DAST
• GitLab Docs — Security scanning results
• GitLab Docs — Security report validation
• GitLab Docs — CI/CD artifacts report types
• GitLab Docs — Security scanner integration
• GitLab Docs — Coverage-guided fuzz testing (deprecated)
• GitLab Docs — Deprecations and removals