BAM Core · Release

BAM Core 2.0.4: Ein Startbefehl, ein Bericht, und ein Port, der absichtlich zu bleibt

Redaktion · 13. Oktober 2026 · 8 Min. Lesezeit

Zwei Dinge entscheiden darüber, ob ein offenes Compliance-Modell benutzt wird: wie schnell man hineinkommt und was man am Ende aus der Hand geben kann. BAM Core 2.0.4 arbeitet an beidem. Am Modell selbst ändert sich dabei nichts, und das ist keine Nebensache, sondern eine Zusage.

Zwei Versionsnummern, zwei Bedeutungen

Bevor es um die Neuerungen geht, lohnt ein Blick auf die Nummer selbst, weil daran eine Zusage hängt. BAM Core führt zwei Versionsnummern nebeneinander, und sie bedeuten Verschiedenes.

Die Modellversion bezeichnet den Stand des Datenmodells. Sie ist das, was zitiert und mit einem DOI versehen wird. Sie steht seit dem 8. September auf 2.0 und wurde seitdem nicht angefasst. Die Release-Nummer bezeichnet den Stand des Repositorys einschließlich der Referenzimplementierung. Sie ist inzwischen bei 2.0.4.

Der praktische Nutzen dieser Trennung zeigt sich genau hier: Ein Release kann die Implementierung erweitern, ohne die Modellversion zu berühren, und berührt damit auch keine Zitation. Wer in einem Arbeitspapier auf eine BAM-ID verweist, muss bei jedem Patch-Release nichts prüfen. Erst eine neue Modellversion ist ein Anlass, ins Änderungsprotokoll zu sehen.

Der Container: ein Startbefehl statt einer Einrichtung

Bisher setzte der Einstieg einen Repository-Klon, eine Python-Umgebung und einen manuellen Start voraus. Ein docker compose up ersetzt das, danach ist das Dashboard unter localhost:5000 erreichbar. Das ist weniger eine Funktion als eine Entscheidung darüber, wie viele Leute BAM überhaupt ausprobieren.

Drei Details sind dabei bemerkenswerter, als eine Patch-Version vermuten lässt. Im Container läuft waitress statt des Flask-Entwicklungsservers, der Prozess läuft nicht als root, und ein Healthcheck prüft den Meta-Endpunkt. Das sind keine Vorkehrungen für ein Spielzeug, sondern für etwas, das jemand versehentlich produktiv nehmen könnte.

Dazu kommt ein Detail für die eigene Arbeit: bam_database.json ist als Volume eingebunden. Ein eigener Modellstand lässt sich damit verwenden, ohne das Image neu zu bauen. Wer das Modell um eigene Objekte erweitert, etwa um branchenspezifische Anforderungen, muss dafür nicht in den Bauprozess.

Der Port, der absichtlich zu bleibt

Der Port ist in der Compose-Datei bewusst auf 127.0.0.1 gebunden. Dahinter steht ein Satz, den man in Produktankündigungen selten liest: BAM Core 2.0.x kennt weder Authentifizierung noch Mandanten und gehört nicht ungeschützt ins Netz.

Das ist keine Entschuldigung, sondern die konsequente Folge der Architektur. Eine Installation, die keinen Bewertungsstand serverseitig hält, braucht keine Benutzerverwaltung. Sobald der Instanz-Layer in Version 2.2 kommt, ändert sich beides zusammen, Persistenz und Zugangsschutz. Bis dahin ist die Bindung auf die eigene Maschine die ehrlichere Voreinstellung als ein Hinweis im Kleingedruckten.

Wer BAM Core dennoch auf einem Server betreiben will, findet im Deployment Guide die Vorlage für den Betrieb hinter Nginx mit TLS. Der Unterschied ist nicht kosmetisch: Vor dem Dienst steht dann etwas, das Zugänge prüfen kann.

Der Bericht: ein Dokument, kein ausgedrucktes Tabellenblatt

Im Reiter Export sitzt neben dem Arbeitspapier jetzt eine Schaltfläche Bericht drucken. Sie erzeugt ein Deckblatt, eine Zusammenfassung je Regulierung und die Feststellungen als Fließtext, nach Risikoscore absteigend, dazu eine Liste der noch nicht bewerteten Prüffragen.

Dahinter liegt ein eigenes Druck-Stylesheet: A4, Seitenumbrüche vor jedem Abschnitt, keine umbrochenen Einzelpositionen. Das PDF entsteht über den Druckdialog des Browsers, es wird keine PDF-Bibliothek und keine zusätzliche Software benötigt. Für ein Projekt, das von Revisoren auf fremden Rechnern benutzt wird, ist das weniger Bequemlichkeit als Verzicht auf eine Abhängigkeit.

Die Trennung zum Export ist Absicht. Der Export liefert eine Tabelle zur Weiterverarbeitung, der Bericht ein Dokument zum Lesen. Zwei Ausgaben für zwei Leser:

Der serverseitige Berichtsgenerator mit Anwendbarkeitserklärung, Managementbericht und Prüferpaket bleibt Version 2.4 vorbehalten. Was jetzt kommt, ist die Fassung, die ohne Server auskommt.

Der Erfüllungsgrad als Untergrenze

Ein Detail aus dem Änderungsprotokoll verdient mehr Aufmerksamkeit, als es dort bekommt: Der Erfüllungsgrad wird als Untergrenze ausgewiesen, solange nicht alle Prüffragen bewertet sind.

Die Punktlogik ist einfach. Erfüllt zählt 1, teilweise erfüllt 0,5, nicht erfüllt 0, bezogen auf alle Objekte mit Prüffrage. Eine Anforderung, die noch niemand angesehen hat, zählt damit wie eine nicht erfüllte. Das ist rechnerisch streng und fachlich richtig, denn eine ungeprüfte Anforderung ist kein guter Zustand, sondern ein unbekannter.

Der Unterschied zur verbreiteten Praxis ist erheblich. Wer den Erfüllungsgrad nur auf die bereits bewerteten Fragen bezieht, bekommt nach drei beantworteten Prüffragen eine Zahl von 100 Prozent und damit genau das Gegenteil einer Aussage. Die Untergrenze kann im Verlauf einer Bewertung nur steigen. Ein Wert, der im Bericht steht, wird durch weitere Arbeit also nie schlechter, sondern bestenfalls genauer.

Was als Nächstes ansteht

Mit 2.0.4 ist der Abschnitt der Roadmap abgearbeitet, der an keiner Modellversion hängt und vorgezogen wurde, weil er die Hürde senkt, BAM überhaupt einzusetzen. Danach beginnt die Arbeit am Modell selbst, und zwar in der dort festgehaltenen Reihenfolge statt nach Terminen.

Zuerst Version 2.1 mit dem Fristenmanagement, das Fristen zu eigenen Objekten macht und zwischen gesetzlichen Stichtagen, wiederkehrenden Pflichten, ereignisgetriebenen Fristen und selbst gesetzten Zieldaten unterscheidet. Danach der Instanz-Layer in 2.2, der Kanon und Zustand trennt und damit Mehrbenutzerbetrieb und Zugangsschutz überhaupt erst möglich macht. Dann der Evidence-Layer in 2.3 mit Nachweisen als eigenen Objekten.

Dass der Zugangsschutz erst mit 2.2 kommt, ist damit kein Versäumnis, sondern dieselbe Reihenfolge von einer anderen Seite betrachtet. Eine Benutzerverwaltung ohne benutzerbezogenen Zustand hätte nichts zu verwalten.

Unsere Empfehlung

Starten Sie den Container, bewerten Sie eine Handvoll Prüffragen aus einem Bereich, den Sie gut kennen, und drucken Sie den Bericht. Der Umweg über eine vollständige Bewertung lohnt am Anfang nicht. Wer die ersten Feststellungen im Fließtext liest, erkennt schneller als über jede Beschreibung, ob die Zuordnungen des Modells zu den eigenen Fragen passen.

Lassen Sie die Portbindung so, wie sie ist, solange Sie allein damit arbeiten. Und wenn Sie das Modell um eigene Objekte erweitern wollen, nutzen Sie das eingebundene Volume, statt das Image neu zu bauen.

Wie sich ein solches Modell in die tägliche Nachweisführung übersetzt, behandelt Executable Compliance. Einzelne Bezeichner lassen sich über Compliance Trace auflösen.

Häufige Fragen