Die Pipeline, die Ihre Software baut und ausliefert, hat mehr Rechte als die meisten Administratoren. Diese Pipeline liest den Quellcode, führt die Signaturschlüssel und die Cloud-Zugangsdaten mit sich und schreibt in die Produktivumgebung. Außerdem ist sie aus Actions, Plugins und Paketen von Dritten zusammengesetzt, die sich ohne Ankündigung ändern.
Wir testen diesen Weg so, wie es ein Angreifer täte: was ein Mitwirkender mit minimalen Rechten tun kann, was eine bösartige Abhängigkeit oder ein bösartiger Pull Request erreichen kann und ob das ausgelieferte Artefakt nachweislich dasjenige ist, das geprüft wurde.
Artefakte und Registrys: Signierung, Herkunft, Zugriffskontrolle
Deployment: Funktionstrennung, Freigaben, Infrastructure as Code
02Vorgehen
Wie die Arbeit abläuft
01
Kartierung
Wir verfolgen den Weg von einem Commit bis in die Produktivumgebung und listen die Systeme, Identitäten und Geheimnisse entlang dieses Wegs auf.
02
Prüfung der Konfiguration
Repositorys, Pipelines und Registrys werden gegen die OWASP Top 10 CI/CD Security Risks und die Anforderungen von SLSA geprüft.
03
Angriffssimulation
Aus den Positionen eines externen Mitwirkenden, eines internen Entwicklers und einer kompromittierten Abhängigkeit versuchen wir, an Geheimnisse zu gelangen und zu verändern, was gebaut wird. Wir arbeiten auf Forks und in Testprojekten, wo immer sich der Nachweis so führen lässt.
04
Härtungsplan
Änderungen sind nach den Angriffspfaden geordnet, die sie schließen. Zu jeder Änderung gehört die Konfiguration, die sie umsetzt.
Klasse der Schwäche, die jedem Befund zugrunde liegt.
The MITRE Corporation
06Fragen
Fragen zu dieser Leistung
Führen Sie in unseren Pipelines bösartigen Code aus?
Wir führen harmlosen Nachweiscode aus, der zeigt, was erreichbar wäre, zum Beispiel den Namen eines Geheimnisses und nicht seinen Wert. Produktive Pipelines berühren wir nur, wo die Testregeln es erlauben; die meisten Pfade werden in einem Testprojekt mit derselben Konfiguration nachgewiesen.
Wir nutzen einen verwalteten CI-Dienst. Ist nicht der Anbieter für die Sicherheit verantwortlich?
Der Anbieter sichert die Plattform. Was Sie darauf einrichten, liegt bei Ihnen: Berechtigungen, Trigger, Geheimnisse und Komponenten von Dritten. Dort haben Angriffe auf Pipelines Erfolg.
Gehört eine Software-Stückliste (SBOM) dazu?
Wir prüfen, ob die Stückliste, die Ihr Build erzeugt, vollständig ist und zum Artefakt passt. Die Stückliste zu erzeugen und zu pflegen ist Teil Ihres Builds; dazu geben wir Empfehlungen.
Prüfung von Umgebungen in AWS, Azure, Google Cloud und Kubernetes: Identitäten, Erreichbarkeit aus dem Netz, Datenspeicher und Pfade vom ersten Zugriff bis zur vollen Kontrolle.