Zum Inhalt springen

Offensive Sicherheit, Prozesse und Governance im Zeitalter von KI und Open Source

Code, den Sie nicht geschrieben haben. Ein Risiko, das Ihres bleibt.

Scrollen ↓

Das ist der Code, den Sie geschrieben haben.

Ein Repository. Ein Team. Ein Review-Prozess, dem Sie vertrauen.

Das ist, was Sie ausliefern.

Jede Abhängigkeit bringt ihre eigenen mit. Das meiste, was in Produktion läuft, hat niemand in Ihrem Team je gelesen.

Einen Teil hat niemand geschrieben.

Assistenten und Agenten committen in Maschinengeschwindigkeit: plausibler Code, ungeprüfte Annahmen, Pakete, die es vielleicht gar nicht gibt.

Ein Glied genügt.

Ein gestohlener Maintainer-Token. Ein Installationsskript. Es erreicht Ihren Build vor Ihrem Changelog.

Die Belege

Wer wir sind

ANTEMUR ist ein Sicherheitsunternehmen mit einer Obsession: dem Code in Ihrem Produkt, den niemand in Ihrem Team geschrieben hat. Wir greifen ihn an, wie es ein Gegner täte, bevor es ein Gegner tut.

ante murum/ˈan.te ˈmuː.rum/Latein, „vor der Mauer“

Das Gelände vor der Mauer, gehalten vom Redan: einem V-förmigen Außenwerk, die Spitze dem Feind zugewandt. Es fängt den Angriff als Erstes ab. Dieses V ist unser Logo.

Klassische Anwendungssicherheit bewacht die Mauer: Ihren Code, Ihren Perimeter. Die Angriffe dieses Jahrzehnts kommen über das, was Sie importieren und was Sie generieren. Genau dort stehen wir. Technik allein trägt nicht. Wir sichern auch die Prozesse und die Governance rundherum, von der Richtlinie bis zur Incident Response.

Unser Fokus / Front 01

KI-generierter Code

Das Tempo hat sich geändert. Das Review nicht. Wir prüfen, was Assistenten und Agenten in Ihr Repository bringen, und die Werkzeuge, die es dorthin bringen.

  • 01Halluzinierte Pakete und Slopsquatting

  • 02Unsichere Vorgaben in generiertem Code

  • 03Secrets in Prompts und Ausgaben

  • 04Prompt Injection gegen Coding-Agenten

  • 05Vergiftete Regeldateien und MCP-Server

  • 06Überzogene Agentenrechte in der CI

Unser Fokus / Front 02

Fremder Code

Jedes Paket, jede Action und jedes SDK ist eine Vertrauensentscheidung. Wir zeigen, wem Sie wirklich vertrauen und was passiert, wenn dieses Vertrauen bricht.

  • 01Maintainer-Übernahme und Token-Diebstahl

  • 02Typosquatting und Dependency Confusion

  • 03Bösartige Installationsskripte

  • 04Erreichbare transitive Schwachstellen

  • 05Kompromittierte CI-Actions und Build-Pipelines

  • 06Verwaiste Komponenten ohne Verantwortliche

Unser Fokus / Front 03

Prozesse und Governance

Sichere Software übersteht keine unsicheren Entscheidungen. Wir strukturieren, wie Ihr Unternehmen Risiken freigibt, kontrolliert, darauf reagiert und dafür Rechenschaft ablegt.

Rahmenwerke, mit denen wir arbeiten

  • ISO/IEC 27001
  • ISO/IEC 42001
  • NIST CSF 2.0
  • NIST SSDF
  • SOC 2
  • LGPD
  • GDPR
  • 01Sicherheits-Governance, Richtlinien und Verantwortliche

  • 02Risikomanagement und Berichte an die Leitung

  • 03Risiken durch Dritte und Lieferanten

  • 04Richtlinie und Kontrollen für den KI-Einsatz

  • 05Prozesse für Zugriff, Änderungen und sichere Entwicklung

  • 06Incident-Response-Pläne und Krisenübungen

Kerntechniken

So jagen wir

  1. Herkunftsanalyse

    SBOM und AI-BOM dessen, was wirklich ausgeliefert wird: jede Komponente, jede Herkunft, jede von einem Agenten verfasste Zeile.

    $ sbom.cdx.json / ai-bom.json

  2. Erreichbarkeitsanalyse

    Wir verfolgen Aufrufpfade von Ihren Einstiegspunkten bis zu jeder verwundbaren Funktion. Die Schwere zeigt, was Angreifer tatsächlich erreichen.

    $ entrypoint → sink: erreichbar

  3. Taint-Analyse

    Nicht vertrauenswürdige Eingaben, verfolgt von der Quelle bis zum Ziel, in generiertem wie in importiertem Code.

    $ source → sanitizer? → sink

  4. Paket-Detonation

    Verdächtige Pakete laufen in einer instrumentierten Sandbox. Netzwerk, Dateisystem und Prozesse werden aufgezeichnet, nicht vermutet.

    $ postinstall → ausgehender Aufruf → markiert

  5. Agent Red Teaming

    Prompt Injection, Tool-Missbrauch und Kontextvergiftung gegen Ihre Coding-Agenten und MCP-Integrationen.

    $ Injection → Tool Call → Wirkung

  6. Pipeline-Audit

    Build-Integrität geprüft nach SLSA: fixierte Actions, signierte Artefakte, begrenzte Tokens, nachweisbare Herkunft.

    $ slsa: Build-Track-Prüfung

  7. Manuelle Ausnutzung

    Automatisierung findet Kandidaten. Ingenieure beweisen sie. Ohne funktionierenden Proof of Concept kommt nichts in den Bericht.

    $ poc: reproduzierbar

  8. Governance-Bewertung

    Richtlinien, Rollen, Kontrollen und Nachweise, geprüft am realen Betrieb Ihres Unternehmens und an den geltenden Rahmenwerken.

    $ Kontrolle → Verantwortliche → Nachweis

Methode

Vier Züge. Kein Theater.

  1. 01

    Kartieren

    Wir erfassen Ihren Code, Ihre Abhängigkeiten, Agenten, Pipelines und internen Prozesse.

    Sie erhaltenExpositionskarte

  2. 02

    Angreifen

    Wir setzen Angreifertechniken auf den realen Wegen in Ihr Produkt ein.

    Sie erhaltenAngriffsprotokoll

  3. 03

    Beweisen

    Jeder Fund kommt mit Reproduktionsschritten und gemessener Wirkung.

    Sie erhaltenNachweisbericht

  4. 04

    Befestigen

    Fixes, Richtlinien und Leitplanken gehen in Ihre Pipeline. Danach testen wir erneut.

    Sie erhaltenHärtungsplan und Retest

Öffentlich dokumentiert

Das ist keine Hypothese.

  1. 2018

    event-stream

    Ein neuer Maintainer erhielt Veröffentlichungsrechte und fügte eine Abhängigkeit hinzu, die Krypto-Wallets stehlen sollte.

  2. 2020

    SolarWinds Orion

    Angreifer kompromittierten das Build-System. Ein signiertes Update brachte die Hintertür zu Tausenden Kunden.

  3. 2021

    Log4Shell

    Eine Zeichenkette in einer Logzeile bedeutete Remote Code Execution in einer Bibliothek, die fast überall steckt.

    CVE-2021-44228 ↗
  4. 2024

    xz-utils

    Nach Jahren des Vertrauensaufbaus als Maintainer platzierte ein Angreifer eine Hintertür in einer zentralen Kompressionsbibliothek.

    CVE-2024-3094 ↗
  5. 2025

    tj-actions

    Eine weit verbreitete GitHub Action wurde kompromittiert und legte CI-Secrets in Workflow-Logs offen.

    CVE-2025-30066 ↗
  6. 2025

    Shai-Hulud

    Ein sich selbst replizierender Wurm verbreitete sich mit gestohlenen Maintainer-Zugangsdaten über npm.

  7. 2026

    Mini Shai-Hulud

    Neue Wellen des Wurms trafen npm erneut, und nach dem Leak des Quellcodes folgten Nachahmer.

Referenzen

Kunden und Referenzen

Veröffentlicht nur mit schriftlicher Freigabe des jeweiligen Kunden.

Hier beginnen

Finden Sie es vor ihnen.

Sagen Sie uns, was Sie ausliefern. Wir antworten mit einem Prüfumfang, nicht mit einer Verkaufspräsentation.