Sicherheit in der Pipeline, nicht danach.

Lange Zeit funktionierte die Sicherheit so: Das Team baute etwas monatelang auf, dann fand kurz vor dem Start eine Sicherheitsüberprüfung oder ein Penetrationstest statt, fand eine Liste von Problemen und alle gerieten in Panik. Am Ende zu reparieren ist langsam, teuer und stressig.

"Links verschieben" bedeutet, Sicherheitsprüfungen früher in den Workflow des Entwicklers und die CI-Pipeline zu verschieben. Probleme werden Minuten nach ihrer Einführung gefunden, wenn sie am billigsten zu beheben sind. Das ist das Herzstück von DevSecOps.

Die Scanner-Typen, einfach

Es gibt eine Alphabetensuppe von Sicherheitsscan. Hier ist, was jeder von ihnen tut:

• SAST (statische Sicherheitsprüfung von Anwendungen)Liest Ihren Quellcode auf der Suche nach unsicheren Mustern. SQL-Injektion, geheime Code, unsichere Funktionen.
• SCA (Software Composition Analysis): überprüft Ihre Abhängigkeiten auf bekannte Schwachstellen und Lizenzprobleme.
• Geheime Scan: sucht nach Passwörtern, API-Schlüsseln und Token im Code und in der Historie.
• IaC-Scannen: überprüft Terraform, Kubernetes-Manifest, Helm-Charts und Dockerfiles auf Fehlkonfigurationen.
• Bildscan von Behältern: findet anfällige Pakete in Ihren Bildern.
• DAST (Dynamische Anwendungssicherheitstests): Angriffe auf eine laufende Anwendung von außen, wie es ein (höflicher) Hacker tun würde.

Die Werkzeuge, die ich benutze

Man braucht keine teuren Werkzeuge, um anzufangen. Ausgezeichnete Open-Source-Optionen:

Typ	Open-Source-Tools	Anmerkungen
SAST	Semgrep, CodeQL	CodeQL ist für öffentliche Repos auf GitHub kostenlos
SCA	Trivy, Grype, OSV-Scanner, Dependabot, das ist ein sehr guter Ort.	Dependabot ist in GitHub integriert
Geheimnisse	Gitleaks, TruffleHog, GitHub Schaltschutz	Scannen Sie einmal den Verlauf, dann jeden Schub.
Die	Checkov, Trivy, KICS, die sind nicht mehr in der Lage.	Trivy umfasst Bilder, Abbildungen und IaC in einem Werkzeug
Bilder	Trivy, Grype, ich bin nicht hier.	Scan in CI und kontinuierlich im Register
DAST	OWASP ZAP	Ausführen gegen Staging- oder Vorschaumedien

Kommerzielle Plattformen (Snyk, GitHub Advanced Security, GitLab Ultimate, Wiz, Aikido und viele andere) bündeln diese mit Dashboards, Priorisierung und Fixvorschlägen.

Eine Pipeline mit eingebauter Sicherheit

Ein vernünftiges Layout:

1. Vorverpflichtung (auf dem Entwickler-Gerät): geheimes Scannen, schnelles Linting. Fangen Sie das Offensichtliche an, bevor es überhaupt gedrückt wird.
2. Anforderung zum Abziehen: SAST, SCA, IaC-Scanning mit Ergebnissen als Kommentare zum PR.
3. BauenDie Daten werden in einem System mit einem Bildscan erfasst, das SBOM erzeugt und unterschrieben wird.
4. Inszenierung / Vorschau: DAST gegen die laufende App.
5. Ständig: Wiederherstellung von Bildern und SBOMs in Produktion für neu entdeckte Schwachstellen.

Allein Trivy deckt eine überraschende Menge ab:

trivy fs --scanners vuln,secret,misconfig .
trivy image --severity HIGH,CRITICAL --ignore-unfixed registry.example.com/shop-api:1.4.2

Sicherheitsbefunde sind wie Wanzen. Je früher man sie findet, desto billiger sind sie und desto weniger Panik.

Handhabung von Fehlalarmen

Hier scheitern die meisten DevSecOps-Bemühungen. Schalten Sie fünf Scanner mit Standard-Einstellungen ein, und die Entwickler ertrinken in Hunderten von Erkenntnissen. Viele sind risikoarm, unerreichbar oder falsch positiv. Nach einer Woche ignorieren die Leute sie alle.

Was hilft:

• Beginnen Sie mit hohen und kritischen Befunde. Erweitern Sie später.
• Ignorieren Sie nicht behebliche Schwachstellen Für jetzt (es gibt noch keinen Patch), aber verfolge sie.
• Nutzung der Erreichbarkeit Die Funktion ist in der Regel nicht anfällig, wenn sie von Tools unterstützt wird.
• Regeln für die Stimmung und unterdrücken falsch positive mit einem dokumentierten Grund, in Code (wie .trivyignore oder Kommentare in der Linie).
• Nur neue Ergebnisse in Pull-Anfragen anzeigen, nicht den ganzen Rückstand. Die Rückstände müssen separat repariert werden.
• Ein Ort für Ergebnisse: GitHub Code Scanning, das Sicherheits-Dashboard von GitLab, oder DefectDojo, statt fünf verschiedenen Berichten.

- Blockieren oder einfach melden?

Sollten die Sicherheitsbefunde die Pipeline versagen?

Meine Herangehensweise:

• Block auf Dinge, die klar definiert und beheben werden können: Geheimnisse, kritische Schwachstellen, die behoben werden können, schwerwiegende Fehler wie öffentliche Buckets oder privilegierte Container.
• Bericht Alles andere, mit Sichtbarkeit und einer Frist für die Behebung.
• Start im Modus nur Bericht für neue Scanner, tunen Sie sie, dann wechseln Sie zum Blockieren für die wichtigsten Regeln.

Geben Sie den Entwicklern auch eine Möglichkeit, ein Risiko vorübergehend zu akzeptieren, mit einem Grund und einem Ablaufdatum. Ein Block ohne Flucht führt dazu, dass die Leute den Scanner deaktivieren.

Machen Sie es zu einer Teamgewohnheit .

Werkzeuge sind die Hälfte der Geschichte. Die andere Hälfte:

• Sicherheitsheldinnen In jedem Team gibt es Leute, die sich mehr um andere kümmern und ihnen helfen.
• Verbesserungsvorschläge in der Pull-Anfrage, damit Entwickler wissen, was zu tun ist.
• Feiern Sie die Verbesserungen ., nicht nur die Ergebnisse zählen.

Also, wo fange ich an?

Fügen Sie geheime Scannen mit Push-Schutz, Trivy für Abhängigkeiten und Bilder und Semgrep oder CodeQL für Code hinzu. Berichten Sie zunächst nur über hohe und kritische Probleme. Sobald der Lärm unter Kontrolle ist, fangen Sie an, die wichtigsten zu blockieren.

Meine Meinung: Sicherheit funktioniert am besten, wenn es nur ein weiterer Check in der Pipeline ist, so normal wie ein fehlgeschlagener Test, und genauso schnell zu reparieren.

Desly