Open Source · MIT · Laravel 13

Mandantentrennung, die hält. Ein Audit-Log, das beweist.

Das ef.next Security Framework gibt Laravel-Anwendungen drei Eigenschaften, die regulierte Umgebungen verlangen: garantierte Mandantentrennung, ein manipulationssicheres Audit-Log und stabile öffentliche IDs. Quelloffen unter MIT, mit signierten Releases und Software-Stückliste. Gebaut von ef.next als eigener Referenzfall für den Cyber Resilience Act.

Vorabversion 1.0.0-beta.2 vom 28. Oktober 2026. Kein Produkt, kein Verkauf: frei nutzbar, der Quelltext ist offen.

Drei Mandanten in getrennten Bereichen einer Anwendung; ein Verweis über die Grenze wird abgewiesen. Darunter ein verkettetes Audit-Log, das an einen Anker außerhalb der Anwendung gebunden ist. Anwendung · Datenbank Mandant A inv_7f3k9z… inv_2q8mx4… usr_c1bt5r… Mandant B inv_9h2vp7… inv_k4d8sw… usr_m6e3qa… Mandant C inv_x3n7ft… inv_r8w2jc… usr_t5y9kd… Audit-Log · verkettet und signiert #1a91f 3e… #27c0d b2… #3e4a8 91… #452f7 6c… Externer Anker unveränderlich
Getrennte Mandanten, abgewiesene Querverweise, ein verkettetes Protokoll mit Anker außerhalb der Datenbank.
  • Fail-closed: verweigert statt zu raten
  • Signierte Releases mit SBOM
  • Schwachstellen: Rückmeldung in zwei Werktagen
  • MIT-Lizenz, frei nutzbar
Die Herausforderung

Vier Fragen, die Software in regulierten Umgebungen beantworten muss.

Produkte mit digitalen Elementen, Plattformen für mehrere Kunden, Prozesse mit Freigabepflicht: Irgendwann fragt ein Auditor, ein Kunde oder eine Behörde nach Belegen. Dann zählt nicht, was die Software können sollte, sondern was sie beweisen kann.

  • Mehrere Kunden auf einer Plattform. Wer garantiert, dass sich die Daten nicht vermischen?

    In den meisten Anwendungen hängt die Trennung an Disziplin: an einer Filterbedingung, die in jeder Abfrage stehen muss. Eine vergessene reicht, und ein Kunde sieht die Daten eines anderen. Ein Audit will das ausgeschlossen sehen, nicht versprochen.

    Mandantentrennung
  • Wer hat wann was getan? Und stimmt das Protokoll noch?

    Ein Protokoll, das in derselben Datenbank liegt wie die Daten, kann jeder ändern, der Zugriff hat. Es beweist nur, dass jemand etwas geschrieben hat. Nicht, dass es seitdem unverändert ist.

    Nachvollziehbarkeit
  • Unsere IDs stehen in URLs und Berichten. Und lassen sich durchzählen.

    Fortlaufende Nummern verraten, wie viele Datensätze es gibt, und laden dazu ein, den nächsten auszuprobieren. Verweise, die sich bei einer Migration ändern, machen alte Berichte und Schnittstellen wertlos.

    Öffentliche Kennungen
  • Der Cyber Resilience Act verlangt Nachweise. Wo fangen wir an?

    Software-Stückliste, Schwachstellenprozess, sichere Updates: Ab Dezember 2027 gelten die Anforderungen vollständig, die Meldepflichten bereits seit September 2026. Belege entstehen nicht nachträglich. Sie müssen Teil des Release-Prozesses sein.

    Cyber Resilience Act
Unser Ansatz

Verweigern statt raten. Belegen statt versprechen.

Das Framework verlässt sich nicht auf Disziplin. Es macht die drei Eigenschaften zur Voraussetzung dafür, dass die Anwendung überhaupt läuft, und legt für jede Zusage offen, wovon sie abhängt.

  1. 01
    Fail-closedWas ohne Mandantenkontext laufen will, läuft nicht. Ein Fehler wird zum fehlgeschlagenen Test, nicht zum Datenleck.
  2. 02
    Die Datenbank hilft mitTrigger lehnen Änderungen am Protokoll ab, zusammengesetzte Schlüssel verhindern fremde Verweise. Das gilt auch für rohes SQL und auch für Administratoren.
  3. 03
    Schlüssel und Anker außerhalbEinträge werden mit Schlüsseln signiert, die nicht in der Datenbank liegen, und regelmäßig in unveränderlichem Speicher verankert. Wer die Datenbank beherrscht, beherrscht nicht die Kette.
  4. 04
    Zusagen mit BedingungenJede Garantie steht mit ihrer Voraussetzung in der Dokumentation. Ein Selbsttest prüft die Installation und scheitert laut, wenn eine fehlt.
  5. 05
    Offen und prüfbarMIT-Lizenz, signierte Releases, Software-Stückliste, dokumentierte Grenzen. Was wir behaupten, können Sie nachlesen und nachrechnen.
Vergleich: Ohne Framework liefert eine Abfrage ohne Mandant alle Datensätze aller Kunden. Mit Framework wird dieselbe Abfrage abgewiesen. Ohne Framework SELECT * FROM invoices kein Mandant gesetzt Mandant A · inv_7f3k9z… Mandant B · inv_9h2vp7… Mandant C · inv_x3n7ft… Mandant A · inv_2q8mx4… Mandant B · inv_k4d8sw… liefert alles – von allen Kunden Mit Framework SELECT * FROM invoices kein Mandant gesetzt Abfrage abgewiesen Exception · Test schlägt fehl kein Datensatz verlässt die Anwendung
Dieselbe Abfrage ohne Mandantenkontext: Ohne Framework liefert sie alles, mit Framework scheitert sie laut.
Das Framework

Drei Komponenten, ein Paket.

Für Laravel 13 auf PHP 8.3 bis 8.5, mit PostgreSQL, MySQL oder MariaDB. Gemeinsam installiert, ein Repository, ein Release. Die Einzelheiten stehen in der Dokumentation im Repository; hier das Bild in groben Zügen.

Mandantentrennung

efnext/security-tenant

Ermittelt den Mandanten einer Anfrage, eines Hintergrundjobs oder eines Befehls und trägt ihn durch die gesamte Verarbeitung. Abfragen auf mandantengebundene Daten ohne Mandanten werden abgewiesen. Mitgliedschaften und Rollen werden durchgesetzt; Verweise über Mandantengrenzen scheitern an der Datenbank selbst.

Audit-Log

efnext/security-audit

Schreibt jedes relevante Ereignis in eine Kette je Mandant: fortlaufend nummeriert, mit dem Hash des Vorgängers verknüpft, signiert. Die Datenbank lehnt Änderungen und Löschungen ab. Anker in externem Speicher und ein Prüflauf machen jede Abweichung sichtbar.

Öffentliche IDs

efnext/security-addressing

Vergibt lesbare, unerratbare Kennungen wie dom_7f3k9zq2m4x8c1bt und globale Objekt-IDs für Verweise über Systemgrenzen hinweg. Sie bleiben stabil, verraten keine Datenbankschlüssel und lassen sich nicht durchzählen.

Zusagen und ihre Voraussetzungen

Was gilt, und wovon es abhängt.

Sicherheitszusagen sind nur so viel wert wie die Bedingungen dahinter. Deshalb steht jede Zusage mit ihrer Voraussetzung in der Dokumentation, und ein Selbsttest prüft sie in der laufenden Installation.

  • Eine mandantengebundene Abfrage läuft nie ohne Mandant.Das Modell ist als mandantengebunden markiert. Ohne Kontext bricht die Abfrage mit einer Ausnahme ab.
  • Eine Zeile kann nicht auf die Zeile eines anderen Mandanten verweisen.Zusammengesetzte Fremdschlüssel aus den Migrationen des Frameworks. Die Datenbank erzwingt sie auch bei rohem SQL.
  • Audit-Einträge lassen sich nicht ändern oder entfernen.Datenbank-Trigger des Frameworks auf PostgreSQL 14 bis 17, MySQL 8.0/8.4 oder MariaDB 10.11 bis 11.
  • Manipulation an der Kette ist erkennbar.Signaturschlüssel außerhalb der Datenbank und externe Anker in unveränderlichem Speicher.
  • Fachliche Änderung und Protokolleintrag werden gemeinsam festgeschrieben.Die Änderung läuft in der Audit-Transaktion des Frameworks.
  • Hintergrundjobs laufen im Mandanten, der sie eingereiht hat.Die Queue-Integration des Frameworks; Befehle laufen über die Mandanten-Ausführung.
Was es nicht tut

Grenzen, offen benannt.

  • Es verschlüsselt keine Daten im Ruhezustand und macht eine unsichere Anwendung nicht sicher. Es macht zwei Fehlerarten unmöglich zu übersehen: fehlende Trennung und verändertes Protokoll.
  • Öffentliche IDs verhindern Durchzählen. Sie ersetzen keine Berechtigungsprüfung.
  • Was an den Schnittstellen des Frameworks vorbei passiert, etwa rohes SQL oder bewusst abgeschaltete Schutzmechanismen, liegt außerhalb der Zusagen. Das Repository benennt diese Grenzen.
  • Vorabversion: Die Schnittstellen können sich bis 1.0.0 ändern, jede Änderung steht im Changelog. Ein unabhängiges Sicherheitsaudit durch Dritte steht noch aus.
Einsatz und Dokumentation

Self-Hosting ist möglich.

Wer das Framework einsetzt, betreibt es selbst. Installation, Betrieb, Schlüsselrotation und Vorfallbehandlung sind im Repository dokumentiert; eine Beispielanwendung zeigt die Integration Schritt für Schritt. Die Dokumentation ist auf Englisch geschrieben, die Nutzer- und Betreiberseiten gibt es dort zusätzlich auf Deutsch und Schwedisch.

Für Teams, die mit KI-Coding-Agenten arbeiten, liefert das Repository einen Integrationsvertrag mit, damit Agenten die Regeln für Mandantenkontext und Audit-Log kennen, bevor sie Code schreiben.

Dokumentation im Repository

Cyber Resilience Act

Was der CRA verlangt, und wie wir es am eigenen Code gelöst haben.

Der Cyber Resilience Act gilt für Produkte mit digitalen Elementen und verlangt von Herstellern Nachweise über den gesamten Lebenszyklus: sichere Entwicklung, Software-Stückliste, Schwachstellenbehandlung, sichere Updates. ef.next richtet solche Nachweise für Kunden ein. Damit wir das glaubwürdig tun, durchläuft unser eigenes Framework denselben Prozess. Was wir Kunden abverlangen, zeigen wir am eigenen Code.

11.09.2026Meldepflichten

Meldepflichten für aktiv ausgenutzte Schwachstellen

Hersteller müssen aktiv ausgenutzte Schwachstellen und schwerwiegende Vorfälle melden. Dafür braucht es einen Meldeweg, der vorher feststeht.

In Kraft
11.12.2027Volle Anwendung

Alle Anforderungen gelten

Einschließlich technischer Dokumentation, Konformitätsbewertung und CE-Kennzeichnung für Produkte mit digitalen Elementen.

Noch 13 Monate
Nachweiskette eines Releases: signierter Tag, Prüfpfade, Artefakte mit Stückliste und Prüfsummen, veröffentlichtes Release. 1 · Signierter Tag git tag -s v1.0.0 Signatur geprüft gegen Trust Root im Repository 2 · Prüfpfade Tests · Analyse 5 Datenbanken PHP 8.3 · 8.4 · 8.5 Mutation ≥ 70 % 3 · Artefakte Archiv + SBOM SPDX · CycloneDX SHA256SUMS Provenance 4 · Release v1.0.0-beta.2 GitHub Release Packagist rückverfolgbar Jede Stufe scheitert laut: kein Artefakt ohne gültige Signatur, kein Release mit rotem Prüfpfad.
Die Nachweiskette jedes Releases. Nichts wird von Hand gebaut; jedes Artefakt führt auf den Tag zurück, der Tag auf einen Schlüssel.
  • Integrität von Software und UpdatesJedes Release ist ein signierter Git-Tag. Der Release-Prozess prüft die Signatur gegen einen im Repository hinterlegten Vertrauensanker, bevor ein Artefakt entsteht. Archiv, Prüfsummen und ein von GitHub signierter Herkunftsnachweis des Builds liegen bei.Releases
  • Software-Stückliste (SBOM)Zu jedem Release eine Stückliste der Laufzeitabhängigkeiten in SPDX und CycloneDX, automatisch aus dem getaggten Stand erzeugt. Das, was Kunden und Prüfer von Herstellern verlangen.Release-Prozess
  • Schwachstellenbehandlung und MeldewegSECURITY.md legt fest, wie gemeldet wird ([email protected], keine öffentlichen Issues), was in den Geltungsbereich fällt und dass eine Rückmeldung innerhalb von zwei Werktagen erfolgt. Nur die jeweils aktuelle Minor-Version erhält Korrekturen.SECURITY.md
  • Sichere VoreinstellungenFail-closed ist der Standard. In Produktion verweigert die Anwendung den Start, wenn Signaturschlüssel fehlen oder der Manipulationsschutz abgeschaltet ist, und ein Selbsttest prüft jede Voraussetzung der Zusagen.Produktionsleitfaden
  • Protokollierung und NachvollziehbarkeitDas Audit-Log hält fest, wer wann was getan hat, und macht nachträgliche Änderungen erkennbar. Die Grundlage für Vorfallanalysen und für Nachweise gegenüber Kunden und Behörden.Audit-Leitfaden
  • Prüfung vor jedem ReleaseKein Release, solange ein Prüfpfad rot ist: Tests auf jeder unterstützten Kombination aus PHP-Version und Datenbank, statische Analyse, Mutationstests mit Mindestschwelle, Prüfung der Abhängigkeiten auf bekannte Schwachstellen.Prüfpfade
  • Bedrohungsmodell und GrenzenEin Bedrohungsmodell, eine Liste dessen, was das Framework nicht tut, und Betriebsanleitungen für Schlüsselrotation und Vorfallbehandlung gehören zur Dokumentation. Belege sind nur so viel wert wie die Grenzen, die sie benennen.Bedrohungsmodell

Einordnung: Das Framework macht ein Produkt nicht von sich aus CRA-konform. Die Konformität eines Produkts bleibt Sache des Herstellers. Das Framework liefert Bausteine für Trennung und Nachvollziehbarkeit und zeigt an sich selbst, wie Release-Belege aussehen können.

Lizenz und Nutzung

MIT. Frei nutzbar, offen einsehbar.

Das Framework steht unter der MIT-Lizenz, Copyright 2026 ef.next AB. Sie dürfen es nutzen, verändern und weitergeben, auch kommerziell. Self-Hosting ist möglich; wer es betreibt, trägt Betrieb und Konfiguration selbst, so wie es im Repository beschrieben ist.

ef.next verkauft das Framework nicht. Es ist die technische Grundlage der eigenen Software von ef.next und zugleich der eigene Referenzfall für den Cyber Resilience Act.

Wer dahintersteht

Entwickelt und betrieben von ef.next AB.

ef.next liefert produzierenden Unternehmen Qualität, Produktsicherheit und Compliance als belegte Ergebnisse. Das Framework ist dafür die technische Grundlage. Mehr über das Unternehmen auf ef-next.com.

  • Enrico EngelProdukt, Software-Architektur, AI, Automatisierung. Verantwortet das Framework.
  • Stephan CarlAudit, Qualitätsmanagement, Managementsysteme.
  • Unternehmenef.next AB, Schweden
  • Fragen[email protected]
Aktuell

Neues zum Framework.

Releases, Hinweise und Artikel. Beiträge erscheinen in der Sprache, in der sie geschrieben wurden.

  • 1.0.0-beta.2: erstes öffentliches ReleaseRelease

    Das Framework ist öffentlich auf GitHub, gebaut für Laravel 13 auf PHP 8.3 bis 8.5. Der Release ist ein signierter Tag mit Archiv, Software-Stückliste in SPDX und CycloneDX, Prüfsummen und Herkunftsnachweis. Die Schnittstellen können sich bis 1.0.0 noch ändern.

    Release auf GitHub
  • Paket auf Packagist verfügbarHinweis

    Das Paket efnext/security-framework ist auf Packagist veröffentlicht und lässt sich damit wie jedes andere Composer-Paket beziehen. Die Installation ist im README beschrieben.

    Paket auf Packagist

Alle Meldungen

Kontakt

Fragen zum Framework? Schreiben Sie uns.

Für Fragen zu Einsatz, Grenzen oder Zusammenarbeit genügt eine E-Mail. Wir antworten auf Deutsch, Englisch oder Schwedisch, in der Regel innerhalb von zwei Werktagen.

Wir antworten in der Regel innerhalb von zwei Werktagen.

Ihre Angaben werden ausschließlich zur Beantwortung Ihrer Anfrage verwendet und per E-Mail an [email protected] zugestellt. Einzelheiten in der Datenschutzerklärung.

Direkt per E-Mail

[email protected]

Fragen zu Einsatz, Grenzen und Zusammenarbeit. Auch für Presse und Partner.

Schwachstelle melden

[email protected]

Bitte nicht als öffentliches Issue. Vorgehen und Geltungsbereich stehen in SECURITY.md; Rückmeldung innerhalb von zwei Werktagen.

ef.next AB

Schweden. Wir antworten auf Deutsch, Englisch oder Schwedisch.