FAQ
Häufig gestellte Fragen
Antworten von Toni Menzel zu Release Controls in Ihrer Toolchain: Zusammenarbeit, Kosten, Übergabe, rio und technische Hintergründe.
Allgemein
Grundlagen
Löst agiles Arbeiten das nicht schon?
In einem gut umgesetzten agilen Entwicklungsprozess kann vieles bereits gelöst sein: kleine Änderungen, frühes Feedback, automatisierte Tests und Reviews im Team. Solche Praktiken können die nötigen Release Controls bereits liefern. Entscheidend ist, ob die Prüfungen Ihre konkreten Risiken abdecken, Ergebnisse zur ausgelieferten Version gehören und vereinbarte Regeln tatsächlich greifen. Wenn das funktioniert, brauchen Sie dafür weder zusätzliche Freigabeschritte noch rebaze. Wo eine konkrete Lücke bleibt, verbessere ich mit Ihrem Team den bestehenden Ablauf.
Widersprechen Release Controls nicht den agilen Prinzipien?
Unnötige Freigabeschleifen können schnelle Rückmeldung und eigenverantwortliches Arbeiten behindern. Deshalb prüfe ich mit Ihrem Team zuerst, welchen Zweck ein Schritt erfüllt und ob er entfallen, vereinfacht oder durch eine frühere Prüfung ersetzt werden kann. Wiederkehrende Prüfungen und ihre Nachweise integriere ich in den Entwicklungsablauf. Sind alle vereinbarten Bedingungen erfüllt, läuft die Änderung weiter. Menschliche Entscheidungen bleiben dort, wo fachliches Urteil, unklare Risiken oder geltende Freigabeanforderungen sie erfordern. Ob das gelingt, beurteilen wir an der konkreten Umsetzung: Welche Risiken werden erkannt, und wo entsteht vermeidbare Wartezeit?
Zum Hintergrund: Prinzipien des Agilen Manifests und DORA-Forschung zur Gestaltung von Change Approvals. DORA bezeichnet hier das Forschungsprogramm zu Software Delivery, nicht die EU-Verordnung.
Was macht rebaze?
Ich bin Toni Menzel, Gründer von rebaze. Ich begleite Sie persönlich von der Diagnose über die Klärung der Anforderungen und technische Umsetzung bis zur Übergabe. Mit Ihrem Team schließe ich eine konkrete Lücke im Release-Prozess: Ich implementiere vereinbarte Checks und Freigaberegeln in Ihren bestehenden Systemen und ordne die Ergebnisse der ausgelieferten Software zu. Wir beginnen mit einem Produkt und einem Release-Weg. Ihr Team erhält die Implementierung und Anleitung für die erneute Ausführung.
Was erhält unser Team bei einer Umsetzung?
Sie erhalten die vereinbarte Implementierung in Ihrer Toolchain: automatische Checks, zugeordnete Prüfergebnisse, sichtbare offene Punkte sowie Konfigurationen, Freigaberegeln und Anleitung. Bei der Übergabe führt Ihr Team den Ablauf erneut aus. Gemeinsam prüfen wir, ob die vereinbarten Regeln auch bei fehlenden Pflichtnachweisen und offenen Ausnahmen greifen.
Zeigt rio, was gerade in Produktion läuft?
Nein. Den aktuellen Betriebsstand liefert das relevante Deployment-System. Die vollständige Verbindung von Code, Release und Deployment ist keine heute verfügbare rio-Funktion. Welche Informationen eine konkrete Umsetzung benötigt und wie Ihr Team sie abfragt, vereinbaren wir für Ihren Release-Weg.
Wie profitieren AI Agents davon?
Agents können explizite Beziehungen und maschinenlesbare Fakten verwenden, statt sie aus mehreren Tools neu abzuleiten. Quellen und Unbekanntes bleiben für die Prüfung sichtbar. Mit Ihrem Team teste ich den Nutzen an der tatsächlichen Aufgabe, etwa anhand korrekter Antworten, Verifikationsaufwand oder Untersuchungsdauer. Das macht einen Agenten nicht automatisch korrekt oder sicher.
Müssen wir rio einsetzen?
Nein. Eine Zusammenarbeit mit rebaze setzt rio nicht voraus. Ich nutze Ihre bestehenden Tools, wenn sie für die vereinbarten Checks und Freigaberegeln ausreichen. rio ist unabhängig von einer Beauftragung als Open Source nutzbar.
Was ist eine SBOM?
Eine SBOM (Software Bill of Materials) ist eine maschinenlesbare Liste der erfassten Softwarekomponenten und ihrer Versionen. Sie unterstützt Vulnerability Management und weitere Checks. Ihre Abdeckung hängt von den Eingaben und der Erzeugung ab. Eine vorhandene SBOM garantiert keine vollständige Inventur.
Warum brauche ich eine SBOM?
Eine SBOM hilft, bekannte Schwachstellen den erfassten Komponenten eines Softwarestands zuzuordnen und später erneut zu prüfen. Dafür müssen Komponenten-IDs, Versionen und Zuordnung zum Artefakt stimmen. Sie ist eine Grundlage für die Analyse, keine Bestätigung von Sicherheit oder vollständiger Abdeckung.
NIS2 verlangt von betroffenen Einrichtungen Maßnahmen zur Sicherheit ihrer Software Supply Chain und zum Umgang mit Schwachstellen. Eine SBOM kann dabei unterstützen. Eine allgemeine SBOM-Pflicht für jedes Unternehmen lässt sich daraus nicht ableiten.
Compliance
NIS2 & Regulierung
Bin ich von NIS2 betroffen?
Für Unternehmen in Deutschland kommt es auf die Einrichtungsart, die Tätigkeit und die Größenkriterien des BSIG an. Für viele Einrichtungsarten der Anlagen 1 und 2 gilt: mindestens 50 Beschäftigte oder Jahresumsatz und Jahresbilanzsumme von jeweils über 10 Millionen Euro. Für bestimmte Einrichtungsarten gelten andere oder größenunabhängige Regeln. Auch die Berechnung bei verbundenen Unternehmen muss berücksichtigt werden.
Prüfen Sie deshalb Ihre konkrete Einordnung. Anforderungen Ihrer Kunden an Sie als Softwareanbieter sind von einer eigenen gesetzlichen Betroffenheit zu unterscheiden.
Welche CRA-Meldepflichten gelten seit dem 11. September 2026?
Für Hersteller von Produkten mit digitalen Elementen im Anwendungsbereich gelten seit dem 11. September 2026 die Meldepflichten nach Artikel 14. Sie betreffen aktiv ausgenutzte Schwachstellen im Produkt und schwerwiegende Vorfälle mit Auswirkungen auf dessen Sicherheit. Nicht jedes Finding ist ein solcher Meldefall.
Ab Kenntnis ist unverzüglich, spätestens binnen 24 Stunden, eine Frühwarnung und spätestens binnen 72 Stunden eine Meldung erforderlich. Bei aktiv ausgenutzten Schwachstellen ist der Abschlussbericht spätestens 14 Tage nach Verfügbarkeit einer Korrektur- oder Abhilfemaßnahme fällig. Bei schwerwiegenden Vorfällen gilt grundsätzlich ein Monat nach der 72-Stunden-Meldung.
Klären Sie Zuständigkeiten, Bewertung und Meldeweg über die gemeinsame Meldeplattform an den zuständigen CSIRT und ENISA. Die allgemeine Anwendung der übrigen Produktanforderungen beginnt am 11. Dezember 2027.
EU-Kommission: CRA-Meldepflichten · EU-Kommission: Überblick und Fristen
Was ist der Unterschied zwischen SBOM und SCA?
Eine SBOM beschreibt erfasste Komponenten und Versionen. Software Composition Analysis (SCA) untersucht Softwareabhängigkeiten, beispielsweise auf bekannte Schwachstellen und Lizenzinformationen. Eine zu einem Softwarestand gespeicherte SBOM kann auch später erneut ausgewertet werden, wenn neue Informationen vorliegen.
Was sagt Provenance über meinen Build aus?
Provenance beschreibt die Herkunft eines Artefakts, etwa den erzeugenden Build-Service, Eingaben und Build-Parameter. SLSA beschreibt Anforderungen an solche Herkunftsdaten und den Build-Prozess. Das bloße Vorliegen dieser Angaben bestätigt noch keinen unveränderten oder vertrauenswürdigen Build.
Für eine Verifikation müssen unter anderem Artefakt-Digest, Signatur, vertrauenswürdige Builder-Identität und erwartete Build-Parameter zusammenpassen. Die Aussage hängt außerdem davon ab, welche Absicherung der Build-Service tatsächlich bietet. Eine Signatur allein bestätigt keine sichere Software.
Sigstore ist eine mögliche Lösung für Signaturen und Identitäten, keine zwingende Grundlage jeder SLSA-Umsetzung. Welche Herkunftsdaten und Checks sinnvoll sind, kläre ich mit Ihrem Team für Ihre Pipeline.
Technisch
Tools & Integration
Welche Tools setzt rebaze ein?
Ich arbeite mit Ihren bestehenden Build- und Release-Systemen. Die vereinbarte Lücke bestimmt, welche Prüfungen und Integrationen erforderlich sind. rio ist der Open-Source Evidence Compiler von rebaze. Er vereinheitlicht und prüft CycloneDX-SBOMs und ergänzt bereitgestellte Produkt- und Build-Angaben. Die native Lieferung an Dependency-Track und OCI-Registries und ein Beleg je Lauf machen die SBOM-Übergabe nachvollziehbar. rio ersetzt weder die SBOM-Erzeugung noch einen Schwachstellenscanner oder Ihre Release-Freigaberegeln. Eine Zusammenarbeit mit rebaze setzt rio nicht voraus.
Wird mein Build langsamer?
Zusätzliche Checks benötigen Rechenzeit. Der Aufwand hängt von Eingaben, Tools und Pipeline ab. Bei der technischen Umsetzung prüfe ich mit Ihrem Team den konkreten Lauf. Gemeinsam vereinbaren wir, welche Checks vor einer Übernahme oder Freigabe laufen müssen und welche unabhängig davon ausgeführt werden können.
Können wir das nicht selbst machen?
Ja. Ich unterstütze Sie, wenn Ihr Team eine konkrete Lücke bei Checks, Ergebniszuordnung oder Freigaberegeln schließen möchte. Dafür nutze ich vorhandene Tools und wiederverwendbare Bausteine. Die vereinbarte Implementierung, Konfigurationen und Anleitung bleiben bei Ihrem Team, damit es den Ablauf selbst ausführen und weiterentwickeln kann.
Unterstützt rebaze auch Air-Gap-Umgebungen?
Ja. rebaze hat Erfahrung mit VS-NfD- und ITAR-konformen Umgebungen (Bundesdruckerei, Thales Defense). Air-Gap-Deployments sind mit spezialisierten Tools für isolierte Umgebungen (Zarf) und dedizierten Mirror-Registries realisierbar.
Brauche ich DependencyTrack?
DependencyTrack ist eine mögliche Plattform für SBOM-Management. Wenn Sie bereits eine Plattform betreiben, beziehe ich diese in die Umsetzung ein. Welche Anbindung und Checks sinnvoll sind, hängt von Ihren vorhandenen Engineering-Workflows ab.
Kosten & Ablauf
Zusammenarbeit
Wie starte ich?
Bringen Sie einen konkreten Fall mit: eine fehlende Prüfung, eine unklare Freigabe oder ein Geschäftsrisiko. Im kostenlosen und unverbindlichen 30-Minuten-Erstgespräch sprechen Sie mit mir, Toni Menzel. Gemeinsam klären wir, welche Verbesserung für ein Produkt und einen Release-Weg sinnvoll ist. Sie brauchen noch keine technische Lösung oder vollständige Beschreibung.
Was ist Clear to Ship?
Clear to Ship ist meine Release-Controls-Umsetzung für Softwarehersteller im Anwendungsbereich des CRA. Mit Entwicklung, Security und CRA-Verantwortlichen lege ich für ein Produkt und einen Release-Weg fest, was automatisch durchläuft, was geprüft wird, was stoppt und wer Ausnahmen entscheidet. Ich setze diese Regeln in Ihrer Toolchain um, und jeder Release legt eine Akte mit SBOM, Prüfergebnissen und Auslieferung an. Umfang, Dauer und Festpreis vereinbaren Sie mit rebaze vor dem Auftrag. Rechtsberatung, Konformitätsbewertung und ein unabhängiges Audit gehören nicht dazu.
Wie läuft die Zusammenarbeit?
Ich begleite Sie persönlich durch die Zusammenarbeit. Mit Ihrem Team grenze ich an einem realen Release die Lücke, die Anforderungen und das gewünschte Ergebnis ein. Ich implementiere die vereinbarten Checks, Ergebniszuordnungen und Freigaberegeln. Am nächsten Release prüfen wir gemeinsam, ob die Regeln greifen. Anschließend übergebe ich Implementierung und Anleitung.
Was kostet die Zusammenarbeit mit rebaze?
Für die Umsetzung von Release Controls vereinbaren Sie mit rebaze Umfang, Voraussetzungen, Ergebnis, Dauer und Festpreis vor dem Auftrag. Im kostenlosen Erstgespräch bespreche ich mit Ihnen Bedarf und Budget.
Wie lange dauert ein typisches Projekt?
Die Dauer der Umsetzung richtet sich nach der vereinbarten Verbesserung, den benötigten Zugriffen und den erforderlichen Integrationen. Sie vereinbaren sie mit rebaze vor dem Auftrag.
Was passiert nach dem Projekt?
Nach einer technischen Umsetzung übergebe ich Ihrem Team die vereinbarten Konfigurationen, Adapter, Regeln, maschinenlesbaren Ergebnisse und Dokumentation. Sie können die Abläufe selbst betreiben und weiterentwickeln. Für ein weiteres Produkt oder einen weiteren Release-Weg vereinbaren wir eine neue, begrenzte Umsetzung.
Datenschutz
Datenhoheit
Wo liegen meine Daten?
Die vereinbarten technischen Abläufe laufen in Ihrer Infrastruktur. Konfigurationen und Ergebnisse bleiben bei Ihnen. Welche Tools auf externe Dienste oder Datenquellen zugreifen, kläre ich mit Ihnen für den konkreten Workflow. Offene Schnittstellen ermöglichen die Weiterverarbeitung in Ihren Systemen.
Noch Fragen?
Bringen Sie Ihre Frage zu Checks, Freigaben oder Geschäftsrisiken mit. 30 Minuten mit mir, Toni Menzel. Kostenlos und unverbindlich.
Erstgespräch vereinbaren