Wie Hacktron dem Sicherheitsteam von Novu Vertrauen gibt statt mehr Prozesse

„Es ist, als würde ein Pentester jeden PR prüfen, den man erstellt.“

Dima Grossman
CTO

Über Novu

Novu ist eine Open-Source-Plattform für Benachrichtigungsinfrastruktur: eine einzige API, um Benachrichtigungen über mehr als 15 Kanäle zu senden (In-App, E-Mail, SMS, Push), eingesetzt sowohl in der Cloud als auch in abgeschotteten On-Premises-Installationen. Das Projekt hat 39.000 GitHub-Sterne und über 400 externe Mitwirkende an seiner Open-Source-Edition. Mit Novu Connect erweitert es sich jetzt auf die Zwei-Wege-Kommunikation mit Agenten, sodass KI-Agenten Aufgaben direkt in Slack und anderen Kanälen erledigen können, statt Benutzer nur anderswohin weiterzuleiten.

Die Herausforderung: einer Codebasis vertrauen, an der 400 Mitwirkende arbeiten

Novu wendet bei jedem externen Beitrag eine Zero-Trust-Richtlinie an. Bei über 400 externen Mitwirkenden wird nichts ohne genaue Prüfung ausgeliefert. Zwei Dinge geschehen gleichzeitig: KI erhöht die Menge an Code, die Novu ausliefert, und das Team ist skeptisch geworden, was compliancegetriebene Sicherheitsprüfungen durch externe Anbieter tatsächlich finden.

„Je mehr jährliche Prüfungen durch Anbieter ich mache, desto weniger vertraue ich ihnen. Sie arbeiten bei all ihren Kunden ein Zehn-Punkte-Playbook ab und finden meist ziemlich irrelevante Dinge.

„Damit sind die Häkchen gesetzt, aber intern vertrauen wir dem nicht.“

Dima Grossman
CTO

Novu betreibt bereits einen mehrschichtigen Stack (CodeQL, Greptile, den Security-Reviewer von Cursor und regelmäßige DeepSec-Scans) an zwei Kontrollpunkten: bei jeder Einreichung eines PR und noch einmal vor dem Taggen eines Releases.

„Mit KI erzeugen wir mehr Ergebnisse, was die Produktoberfläche angeht.

„Und das erhöht natürlich das Risiko menschlicher Fehler bei Reviews deutlich.“

Dima Grossman
CTO

So fügt sich Hacktron ein: Vertrauen statt Prozessänderung

Dima sagte klar, was sich geändert hat und was nicht:

„An unserem Prozess hat sich mit Hacktron nichts geändert. Geändert hat sich eigentlich nur unser Vertrauen, weil wir wissen, dass wir deutlich ausgefeiltere Muster erkennen.

„Und dieses Vertrauen ermöglicht es uns auch, schneller zu werden.“

Dima Grossman
CTO

Dieses Vertrauen beruht auf der Qualität der Signale. Die bestehenden Tools von Novu melden vor allem Probleme, die im Diff eines PR sichtbar sind (Dima nannte sie „One-Hop“-Exploits). Hacktron erstellt einen Codegraphen des Repositorys und vergleicht diese Graphen über PRs hinweg. So deckt es Probleme zweiter Ordnung auf: Schwachstellen, die erst sichtbar werden, wenn man verfolgt, wie sich eine Änderung in einer Datei auf Code an anderer Stelle im System auswirkt.

„Wenn wir Kommentare anderer Tools sehen, liegen sie in vielen Fällen außerhalb des Scopes oder sind ein akzeptables Risiko.

„Wenn wir etwas von Hacktron sehen, schaut das Team genau hin und denkt darüber nach. In vielen Fällen finden wir es ziemlich relevant.“

Dima Grossman
CTO

Dima nannte auch das Risiko, gegen das er aktiv vorgeht: Alarmmüdigkeit.

„Es darf nicht ständig grundlos Alarm schlagen.

„In den Berichten stehen so viele Benachrichtigungen, dass man das Wesentliche aus den Augen verliert.“

Dima Grossman
CTO

Die Qualität der Signale ist hier kein nettes Extra. Sie macht den Unterschied zwischen einem Tool, das das Team tatsächlich liest, und einem, das es zu ignorieren lernt.

Analyse der Befunde

In den ersten 30 Tagen von Novu mit Hacktron (6. Juli bis 6. August 2026):

18 Befunde warten noch auf die Triage. Ein weiterer wurde zurückgezogen, als der zugehörige PR aufgegeben wurde.

Welche Arten von Schwachstellen findet es?

Die eigenen Tools von Novu finden vor allem Probleme, die in einer einzelnen Datei oder im Diff eines einzelnen PR sichtbar sind. Die Befunde, die Dima als wertvoll hervorhob, zeigen sich erst, wenn man einen Aufruf über mehrere Dateien verfolgt. Genau so etwas kann ein Scanner, der nur Muster abgleicht, nicht melden.

NoSQL-Injection und konversationsübergreifende Umgehung der Autorisierung (Hoch)

Gefunden in PR #12062 und im selben PR vor dem Merge behoben.

Novu führte einen neuen Ingestion-Pfad ein, über den selbst gehostete KI-Agenten strukturierte Ereignisse (Nachrichten, Antworten, Freigaben) an die Plattform senden. Ein Teil dieser Pipeline musste ein eingehendes Ereignis der richtigen Konversationsaktivität zuordnen und glich dafür eine vom Client übermittelte Nachrichten-ID ab:

1
private async resolveActivityByClientId(
2
  environmentId: string,
3
  conversationId: string,
4
  messageId: string
5
): Promise<ConversationActivityEntity | null> {
6
  for (let attempt = 0; attempt < ACTIVITY_RESOLVE_MAX_ATTEMPTS; attempt += 1) {
7
    const activity = await this.activityRepository.findOne(
8
      { _environmentId: environmentId, identifier: messageId },
9
      '*'
10
    );
11
    if (activity) {
12
      return activity;
13
    }
14
    if (attempt < ACTIVITY_RESOLVE_MAX_ATTEMPTS - 1) {
15
      await delay(ACTIVITY_RESOLVE_DELAY_MS);
16
    }
17
  }
18
  return this.activityRepository.findByPlatformMessageId(environmentId, conversationId, messageId);
19
}

Hier kamen zwei Probleme zusammen. Erstens prüfte der Abfragefilter nie, zu welcher Konversation die Aktivität gehörte, sondern nur die Umgebung. Zweitens wurde die eingehende messageId nicht als einfacher String validiert, bevor sie direkt in diesem Filter landete. Sie ließ sich also durch einen MongoDB-Abfrageoperator statt einer ID ersetzen. Zusammen konnte ein authentifizierter Aufrufer Aktivitäten einer fremden Konversation auflösen und anschließend bearbeiten oder löschen.

Hacktron Review fand das, indem es die Aufrufkette über drei Dateien verfolgte: den Ingest-Controller, der die rohe Ereignis-Payload entgegennimmt, den Use Case, der sie ohne tiefe Validierung in ein typisiertes Ereignis umwandelt, und den Sink-Service, der die nicht validierte ID an die obige Abfrage übergibt.

Die Ergebnisse: Vertrauen, um schneller auszuliefern statt langsamer

Novu erhält ein kontinuierliches Review für eine Codebasis, an der über 400 externe Mitwirkende arbeiten, ohne die Alarmmüdigkeit, durch die Teams aufhören, die Meldungen von Sicherheitstools zu lesen, und mit einem Vertrauen, das es dem Team ermöglicht, schneller statt langsamer auszuliefern.