Thought Leadership
Am 18. Mai 2026 injizierte eine automatisierte Angriffskampagne innerhalb von nur sechs Stunden 5.718 bösartige Commits in 5.561 GitHub Repositories.
Die Angreifer nutzten kompromittierte Entwicklerkonten und platzierten dabei zwei Arten von Schadcode: einen offensiven Workflow, der bei jedem Code Push ausgeführt wird, und einen verdeckten, der sich als schlafende Hintertür einbettet. Ohne sichtbare CI-Ausführung, ohne fehlgeschlagene Builds, ohne Einträge in der Aktionshistorie. Aufgedeckt wurde die Kampagne von der Sicherheitsfirma SafeDep und eine unabhängige Analyse von OX Security bestätigte den Fund und identifizierte über 3.500 betroffene Repositories mit identischer YAML-Konfiguration.
Die Schadlogik war konsequent auf hochwertige Zugänge ausgerichtet: AWS-Schlüssel, Google Cloud und Azure Tokens, SSH-Keys, Docker und Kubernetes Konfigurationen, Vault Token, Terraform Credentials, GitHub Actions Tokens sowie mehr als 30 weitere Secret-Muster wurden systematisch abgegriffen.
Der technische Mechanismus ist das eine. Was Megalodon darüber hinaus gezeigt hat, ist wesentlich relevanter: Die Angriffsfläche, über die Angreifer in die eigene Umgebung eindringen können, hat sich fundamental verlagert. Weg von einzelnen Schwachstellen, hin zu den Prozessen, die Software bauen und ausliefern.
Die digitale Fertigungsstraße als Angriffsziel
Moderne Software entsteht in Repositories, Build-Prozessen, automatisierten Tests, Release-Pipelines und Cloud-Deployments. GitHub Actions, CI/CD Workflows, Tokens, Service Accounts und Cloud-Berechtigungen bilden zusammen die „Fertigungsstraße“, auf der digitale Produkte gebaut und ausgeliefert werden.
Megalodon hat genau diese Fertigungsstraße ins Visier genommen. Die Angreifer tarnten bösartige Änderungen als normale Anpassungen an automatisierten Entwicklungsprozessen. Für viele Organisationen ist das besonders gefährlich, weil solche Änderungen im Alltag nicht wie ein Angriff wirken. Sie sehen aus wie Prozesspflege, eine Anpassung an Build-Logik oder wie ein kleiner Eingriff in die Automatisierung, die ohnehin ständig verändert wird.
Das ist der entscheidende Punkt: Megalodon greift nicht nur Code an. Megalodon greift das Vertrauen in Abläufe an.
Moderne IT braucht offene Plattformen, schnelle Entwicklung und automatisierte Prozesse.
Oliver Keizers, Filigran
Vertrauen vs. Wissen
Die zentrale Lehre aus Megalodon lautet nicht, dass GitHub unsicher ist oder dass Automatisierung gefährlich ist. Beides wäre falsch. Moderne IT braucht offene Plattformen, schnelle Entwicklung und automatisierte Prozesse. Die eigentliche Lehre lautet: Vertrauen ist eine Angriffsfläche. Wer Software heute sicher betreiben will, muss die digitale Fertigungskette genauso ernst nehmen wie die Produktionsumgebung. Sicherheitsverantwortliche müssen wissen, wo Vertrauen technisch durchgesetzt wird, und wie es missbraucht werden kann.
Dieses Vertrauen lässt sich allerdings absichern und verteidigen. Aber nicht durch Kontrollen allein, sondern durch Wissen darüber, wie Angreifer vorgehen, bevor sie zuschlagen. Genau das ist der Kern von Threat Intelligence: keine reaktive Schadensaufarbeitung, sondern Vorausschau, Kontext und Proaktivität. Unternehmen, die ihre Fertigungsprozesse kontinuierlich mit aktuellem Bedrohungswissen abgleichen, reagieren nicht auf Vorfälle. Sie verhindern sie. Oder sie begrenzen deren Wirkung so früh, dass die eigentliche Fertigungskette intakt bleibt. Das Vertrauen in den Prozess bleibt erhalten, weil es laufend überprüft und verteidigt wird.
Megalodon ist weder ein Einzelfall noch eine Randerscheinung für Entwickler. Es ist ein Warnsignal für alle, die digitale Lieferketten verantworten. Die Angreifer suchen nicht mehr nur nach offenen Türen. Sie suchen nach den Maschinen, die die Türen bauen.
