Module 8 Lesson 5: Security Alerts

In Module 5, we learned how to Scan. Now, we learn how to React. A security finding that sits in a log file for a month is useless.

1. The Security Dashboard

Found under Secure -> Security Dashboard.

It aggregates every vulnerability across your entire project (or even your whole company!).
It sorts them by Severity (Critical, High, Medium, Low).

2. Setting Up Security Triage

When a new bug is found:

The Alert: GitLab sends an email/Slack to the "Security Group."
The Investigation: A developer clicks the vulnerability in the dashboard to see the exact line of code.
The Action: You can click "Create Issue" to automatically start a task to fix the bug.

3. "Secret" Leaks: The Red Alert

If GitLab's Secret Detection finds a private key pushed to a public repo, it can:

Revoke the token automatically (for supported providers like AWS or GitHub).
Email the developer immediately with a "CRITICAL" warning.

4. Why Compliance Fails

Compliance fails when it's treated as a "Quarterly PDF." GitLab turns it into a Continuous Monitor. Every time you merge code, you are auditing your compliance.

Exercise: The Security Drill

Look at your Security Dashboard. Does it currently list any findings?
Find a "Low" or "Informational" finding. Can you see which specific commit introduced it?
Imagine a "Critical" SQL Injection bug is found in Staging. Who should be notified first? (The CEO? The Lead Dev? The Security Engineer?)
Research: What is "GitLab Security Policy"? (Hint: It's a YAML file that forces scans on every project).

Summary

You have completed Module 8: Monitoring and Notifications. You have transformed your pipeline from a "Silent Script" into a "Self-Reporting Machine" that tracks its own speed, success, health, and security.

Next Module: The final audit: Module 9: Security and Compliance.