Schwachstellen fortlaufend finden und beheben
AbgeschlossenBauen Sie einen kontinuierlichen Prozess von der Schwachstellenerkennung bis zur geprüften Behebung in der Produktion auf. Verstehen Sie die Wartungslücke, die ein erfolgreicher Prototyp verbergen kann.
Veröffentlicht von TaigaWie wir schreiben
Verständnis prüfenEine Anwendung wurde seit drei Monaten nicht geändert. Ihr letzter Abhängigkeitsscan meldete bei der Veröffentlichung keine Befunde. Welche Aussage ist belegt?Übung bearbeiten
Das lernen Sie
- Erklären, warum unveränderte Software laufende Sicherheitsprüfung braucht.
- Verschiedene Scantypen ihrer Abdeckung und ihren Grenzen zuordnen.
- Einen Befund durch Priorisierung, Korrektur, Deployment und Prüfung verfolgen.
Ein funktionierender Prototyp kann zum ungepflegten Dienst werden
Vibe Coding kann schnell einen nützlichen Prototyp erzeugen. Das Produktionsrisiko wächst, wenn Menschen ihn ohne laufende Sicherheitswartung weiterverwenden. Das ist eine ernste Lücke: Die Software bleibt Angriffen ausgesetzt, während ihr Ersteller die Arbeit für abgeschlossen hält.
Die Lücke ist organisatorisch und technisch. Ein Scanner kann ohne Verantwortlichen existieren. Ein Befund kann einen Verantwortlichen haben, aber keinen Weg zur Veröffentlichung. Eine gemergte Korrektur kann das alte Produktionsartefakt weiterlaufen lassen.
Bewerten Sie die tatsächliche Entwicklungsplattform und ihre Konfiguration. Manche Werkzeuge bieten Sicherheitsfunktionen. Eine Produktbezeichnung belegt nicht, ob Ihre bereitgestellte Anwendung kontinuierliche Scans und geprüfte Korrekturen erhält.
Scannen Sie, wenn sich Nachweise ändern können
Führen Sie relevante Prüfungen für vorgeschlagene Änderungen und gebaute Artefakte aus. Bewerten Sie unterstützte Versionen nach Zeitplan neu, weil sich Sicherheitshinweise ohne Commit ändern. Lösen Sie zusätzliche Reviews aus, wenn ein relevanter Hinweis, eine geänderte Exposition oder ein Incident auftritt.
Halten Sie den Umfang ausdrücklich fest. Benennen Sie Repositories, Branches, Lockdateien, Images, bereitgestellte Hashes, Laufzeiten und Umgebungen. Beziehen Sie Anwendungen ein, die keine neuen Funktionen erhalten, aber weiterhin Nutzern dienen.
Ein fehlgeschlagener Scan bedeutet fehlende Nachweise. Überwachen Sie Scanaktualität, Feed-Ausfälle, Authentifizierungsfehler, nicht unterstützte Komponenten und Abdeckungslücken. Eine leere Befundliste nach einem fehlgeschlagenen Job ist kein sauberes Ergebnis.
Nutzen Sie verschiedene Prüfungen für verschiedene Fragen
| Prüfung | Nützliche Abdeckung | Wichtige Grenze |
|---|---|---|
| Software Composition Analysis, kurz SCA | Bekannte Abhängigkeitsschwachstellen einschließlich erkannter transitiver Pakete | Belegt nicht die Korrektheit der Anwendungsautorisierung |
| Static Application Security Testing, kurz SAST | Unsichere Codemuster, die das Tool erkennen kann | Kann Laufzeitverhalten übersehen und prüfbedürftige Befunde erzeugen |
| Secret-Scanning | Erkannte Zugangsdatenmuster in gescannten Inhalten | Eine entfernte Zeichenfolge kann anderswo gültige Zugangsdaten hinterlassen |
| Infrastruktur- und Konfigurationsprüfungen | Definierte Richtlinienverstöße in gescannten Ressourcen oder Konfiguration | Repository-Konfiguration kann von der laufenden Umgebung abweichen |
| Autorisierte dynamische Tests | Verhalten einer laufenden Anwendung im getesteten Umfang | Benötigt Erlaubnis, geeignete Daten und Vorsicht bei Nebenwirkungen |
Kombinieren Sie diese Prüfungen mit Review und relevanten Sicherheitstests. Behaupten Sie nicht, dass irgendein Scan die Abwesenheit von Schwachstellen beweist.
Verfolgen Sie einen fiktiven Befund in die Produktion
| Zeit | Ereignis | Tatsächlicher Stand |
|---|---|---|
| Montag 09:00 | Ein neuer Hinweis identifiziert eine betroffene PDF-Abhängigkeit | Bestehende Veröffentlichungen müssen bewertet werden |
| Montag 09:15 | Ein geplanter Scan erkennt die Produktionsversion | Befund erkannt, nicht korrigiert |
| Montag 10:00 | Verantwortlicher bestätigt Exposition und wählt einen unterstützten Patch | Behebung geplant |
| Montag 13:00 | Tests bestehen und der Patch-PR wird gemergt | Repository korrigiert; Produktion braucht noch ein Deployment |
| Montag 14:00 | Pipeline stellt das korrigierte Image bereit | Neues Artefakt läuft; Prüfung steht noch aus |
| Montag 14:20 | Artefaktscan und Export-Regressionstests bestehen | Korrektur im geprüften Umfang bestätigt |
Priorisieren Sie anhand von Schweregrad, Ausnutzungsnachweisen, Exposition, betroffenen Daten und verfügbaren Schutzmaßnahmen. Der CISA-Katalog hilft, bekannte Ausnutzung zu erkennen. Er ist eine Grundlage, keine vollständige Risikobewertung. CISA-Katalog.
Eine vorübergehende Ausnahme braucht Nachweise, Verantwortliche, kompensierende Kontrollen und eine Ablaufbedingung oder einen Prüfauslöser. Gibt es keinen Patch, erwägen Sie einen autorisierten Workaround, eine Funktionseinschränkung oder die Entfernung der betroffenen Komponente.
Schließen Sie die Wartungslücke
Messen Sie die Zeit bis zur Bewertung und geprüften Behebung nach Priorität. Verfolgen Sie überfällige Ausnahmen, veraltete Scans, betroffene Produktionsversionen und wiederkehrende Befunde. Eine sinkende Befundzahl kann auch geringere Abdeckung bedeuten. Prüfen Sie den Nenner.
Taiga Maintaining scannt verknüpfte Repositories nach Änderungen und regelmäßig. Es erfasst Befunde und verbindet Behebung mit Initiativen und geprüften Änderungen. Prüfen Sie Scanstatus und aktuell dokumentiertes Verhalten. Maintaining.
Ihre Pipeline braucht weiterhin angemessene Freigabekontrollen. Der Dienstverantwortliche muss weiterhin Deployment und betrieblich korrektes Verhalten bestätigen. Diese kontinuierliche Kette gehört zum Betrieb einer KI-Software-Factory, auch bei Produkten, deren erste Version als Prototyp begann.
Übung bearbeiten
Nutzen Sie die fiktive Zeitleiste dieser Lektion. Erkennen Sie, wo das Team fälschlich Erfolg melden könnte. Definieren Sie Scanauslöser, Fehleralarm, Behebungsverantwortlichen, Release-Prüfung und Ablauf einer vorübergehenden Ausnahme.
Arbeitsblatt herunterladen (Markdown)Wenn Sie diese Auswahl aufheben, wird der gesamte in diesem Browser gespeicherte Fortschritt gelöscht.
Ihr Fortschritt bleibt in diesem Browser. Ohne Konto und Tracking.
Quellen und weiterführende Lektüre
- NIST: Secure Software Development Framework ↗
- CISA: Known Exploited Vulnerabilities Catalog ↗
- Taiga docs: Maintaining ↗