Module 5 Lesson 4: Security Scanning (SAST & DAST)

Security shouldn't be a "Final Check" at the end of the year. In GitLab, we use DevSecOps to scan for vulnerabilities every time a developer types a character.

1. SAST (Static Application Security Testing)

SAST scans your Source Code. It looks for patterns of danger:

• Using a hardcoded password.
• Using a vulnerable version of a library.
• Using "Dangerous" functions like eval() in Javascript.

GitLab Setup:

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

---

2. DAST (Dynamic Application Security Testing)

DAST scans your Running Website. It acts like a "Friendly Hacker":

• It tries to inject SQL into your forms.
• It tries to do "Cross-Site Scripting" (XSS).
• It checks if your SSL certificates are valid.

GitLab Setup:

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

dast:
  variables:
    DAST_WEBSITE: https://staging.myapp.com

---

3. Secret Detection

This is the most critical scan. It scans your Git history for passwords, SSH keys, and tokens.

• The Benefit: If a developer accidentally pushes a password to a branch, GitLab detects it instantly and fires an alert before a hacker can scrape it.

---

4. Why Use Both?

• SAST catches the "Mistake in the code."
• DAST catches the "Mistake in the setup." You need both to have a truly secure "Defense in Depth" (review Docker Module 7).

---

Exercise: The Security Audit

1. In your test project, add the SAST.gitlab-ci.yml template.
2. Push a "Bad" line of code: apikey = "123456789".
3. Observe the security findings on the Pipeline -> Security tab.
4. Why is "Secret Detection" better than just "Human Review" of code?
5. Search: What is the OWASP Top 10, and how does GitLab help you defend against it?

---

Summary

Security Scanning turns your pipeline into a "Living Guard." By automating these checks, you eliminate the single most common cause of corporate hacks: human error and unpatched libraries.

Next Lesson: Establishing the standard: Implementing Quality Gates.