Leistungen.
Drei Pakete, die aufeinander aufbauen und einzeln beauftragt werden können.
Von der Ist-Aufnahme über einen Pilotbetrieb bis zum erweiterten Programm mit Security-Triage und Patch-Recherche. Jedes Paket hat einen festen Referenzumfang, dokumentierte Ergebnisse und klar benannte Grenzen. Abweichungen werden vor Beauftragung vereinbart.
- Pakete
- Drei, einzeln beauftragbar
- Laufzeit
- 4 bis 16 Wochen je Paket
- Arbeitsweise
- Remote, Mo–Fr, dokumentiert
- Preis
- Festpreis je Referenzumfang, im Angebot
Welches Paket passt?
Paket 1 schafft Transparenz und einen Maßnahmenplan. Paket 2 erprobt den Betrieb an echten Fällen. Paket 3 erweitert den Betrieb um Security-Triage und Patch-Recherche. Keines setzt das vorherige voraus.
- PAKET 1 · ANALYSE
Open Source Governance & Risk Check
Ist-Aufnahme von Bestand, SBOM-Fähigkeit, Governance und Risiken mit priorisiertem 90-Tage-Maßnahmenplan.
- LAUFZEIT
- 4–6 Wochen
- REFERENZUMFANG
- bis zu 3 Produkte oder Services mit insgesamt bis zu 20 Repositories
- PAKET 2 · BETRIEB
Managed Open Source Operations Pilot
Operative Bearbeitung von Lifecycle-, Schwachstellen- und Upstream-Themen in einem abgegrenzten Pilotbereich.
- LAUFZEIT
- 8–10 Wochen
- REFERENZUMFANG
- bis zu 3 Produkte oder Services mit insgesamt bis zu 20 Repositories
- PAKET 3 · PROGRAMM
Secure Upstream Operations Program
Erweiterter Betrieb mit Security-Triage, Patch-Recherche im Kundenauftrag und Lieferung vorhandener Patches, sofern verfügbar.
- LAUFZEIT
- 12–16 Wochen
- REFERENZUMFANG
- bis zu 5 Produkte oder Services mit insgesamt bis zu 40 Repositories
Woran wir arbeiten.
Alle Pakete bewegen sich in denselben drei Bereichen, mit unterschiedlicher Tiefe.
Open-Source-Governance & SBOM-Management
Bestand erfassen, SBOMs erzeugen oder konsolidieren, Lizenz- und Governance-Strukturen bewerten, Zuständigkeiten klären.
Schwerpunkt in Paket 1, Grundlage in Paket 2 und 3
Schwachstellen-Triage
Findings bewerten, Relevanz für den Scope klären, Entscheidung und Bearbeitungsstand dokumentieren.
Baseline in Paket 1, operativ in Paket 2 und 3
Patch-Recherche
Nach bereits vorhandenen Patches suchen und sie liefern, sofern verfügbar. Keine eigene Patch-Entwicklung.
Anfrage in die Community ab Paket 2, systematische Recherche und Lieferung in Paket 3
Open Source Governance & Risk Check
Ist-Aufnahme von Bestand, SBOM-Fähigkeit, Governance und Risiken mit priorisiertem 90-Tage-Maßnahmenplan.
Teams, die wissen wollen, wo sie stehen, bevor sie in Prozesse, Werkzeuge oder einen externen Betrieb investieren.
Belastbare Transparenz über Open-Source-Bestand, SBOM-Fähigkeit, Lizenz- und Governance-Strukturen, Schwachstellen- und Lifecycle-Risiken sowie organisatorische Verantwortlichkeiten.
- 01
Kick-off & Scoping
- Scope, Systeme, Repositories und Ansprechpartner festlegen
- vorhandene SBOM-, Dependency- und Asset-Daten sichten
- Datenzugänge und Sicherheitsregeln klären
- Bewertungs- und Berichtskriterien bestätigen
- 02
Inventar & Nachweis
- Open-Source-Komponenten und Abhängigkeiten erfassen
- SBOM erzeugen oder konsolidieren (SPDX oder CycloneDX), soweit technisch möglich
- Lizenz- und Third-Party-Informationen strukturieren
- EOL-, Maintainer- und Release-Signale erfassen
- 03
Risiko & Governance
- Schwachstellen- und Lifecycle-Baseline
- Verantwortlichkeiten und Eskalationswege bewerten
- Governance-Lücken und Nachweisdefizite identifizieren
- Risiken nach Kritikalität und Aufwand priorisieren
- 04
Bericht & Maßnahmenplan
- Management-Zusammenfassung
- technischer Findings-Report
- priorisierter 30/60/90-Tage-Maßnahmenplan
- Abschluss-Readout mit Management und Technik
- OSS Inventory / SBOM Pack
Komponentenübersicht, Abhängigkeiten und verfügbare SPDX- oder CycloneDX-Artefakte.
- Risk Register
Priorisierte Security-, Lifecycle-, Governance- und Nachweisrisiken.
- Governance Map
Rollen, Verantwortlichkeiten, Eskalations- und Entscheidungswege.
- Management Report
Kompakte Entscheidungsgrundlage mit den wesentlichen Findings.
- 90-Tage-Maßnahmenplan
Konkrete, priorisierte nächste Schritte.
- Abschluss-Readout
Remote-Präsentation mit Fragen und Antworten.
- fachliche und technische Ansprechpartner
- vereinbarte Zugänge und Artefakte rechtzeitig bereitstellen
- Rückfragen in angemessener Frist beantworten
- Freigabe sicherheitsrelevanter Zugriffe und Daten
- Rechtsberatung oder verbindliche Lizenzgutachten
- Penetrationstests oder umfassende Secure-Code-Audits
- 24/7-Monitoring oder Bereitschaft
- Entwicklung kundenspezifischer Produktfeatures
- Patch- oder Pull-Request-Implementierung
- Migration oder Betrieb produktiver Infrastruktur
DANACH Die operative Umsetzung ist ein eigenes Paket, zum Beispiel der Operations Pilot. ↓
Managed Open Source Operations Pilot
Operative Bearbeitung von Lifecycle-, Schwachstellen- und Upstream-Themen in einem abgegrenzten Pilotbereich.
Teams, die ein externes Betriebsmodell für Open-Source-Themen unter realen Bedingungen erproben wollen, bevor sie einen Dauerbetrieb entscheiden.
Zeigen, wie ein Managed-Open-Source-Betrieb mit klaren Prozessen, Reaktionswegen und Evidenz funktioniert, an echten Fällen aus Ihrem Scope.
- 01
Onboarding & Operating Baseline
- Scope und Servicekanäle einrichten
- Inventar- und SBOM-Basis konsolidieren
- Severity- und Eskalationsmodell definieren
- Ansprechpartner und Freigabewege festlegen
- 02
Monitoring & Triage
- CVE- und Schwachstellensignale überwachen
- Relevanz für den Pilot-Scope bewerten
- Releases, EOL und Maintainer-Aktivität beobachten
- technische Reproduktion und Workaround-Recherche bei Bedarf
- 03
Support & Lifecycle Operations
- strukturierte Fallannahme
- Root-Cause- und Abhängigkeitsanalyse
- Statusführung bis zur vereinbarten Erledigung
- dokumentierte Maßnahmen und Entscheidungsgrundlagen
- 04
Upstream-Interaktion
- Issues nach den Regeln des jeweiligen Projekts erstellen
- Security Findings ausschließlich über private Disclosure-Kanäle melden
- Maintainer- und Community-Kommunikation in Ihrem Namen, soweit freigegeben
- Anfragen nach vorhandenen Patches oder Lösungen in die Community tragen; gefundene Lösungen an Sie weiterleiten und zur Entscheidung vorlegen, ohne eigene Entwicklung
- 05
Evidence & Pilot-Auswertung
- Fall- und Maßnahmenlog
- wöchentlicher Statusbericht
- Abschlussbericht mit Betriebsmodell, Erkenntnissen und Rollout-Empfehlung
- Pilot Operating Model
Servicekanäle, Rollen, Severity, Eskalation, Freigaben.
- Managed OSS Register
Inventar- und SBOM-Basis mit Lifecycle-Status.
- Case & Triage Log
Bearbeitete Fälle, Findings, Maßnahmen, Status.
- Upstream Evidence
Zulässige Issues, Disclosures, Community-Anfragen und Kontakte als Nachweis.
- Weekly Status
Kurzer Betriebs- und Risikobericht je Woche.
- Pilot Final Report
Ergebnisse, Auswertung, Lücken und Rollout-Empfehlung.
- technische Ansprechpartner und Freigaben
- notwendige Artefakte und Zugänge
- Berechtigung, in Ihrem Namen mit Upstream-Projekten zu kommunizieren
- zeitnahe Entscheidungen bei Security-, Release- und Patch-Fragen
- 24/7-Bereitschaft
- unbegrenzte Ticket- oder Engineering-Kapazität
- Feature-Entwicklung oder eigene Patches
- garantierte Annahme von Issues oder Release-Zeitpunkte externer Projekte
- Rechtsberatung oder Penetrationstests
- produktiver Infrastruktur-Betrieb außerhalb des vereinbarten Scopes
DANACH Mehr Fälle, Security-Triage und Patch-Recherche: Secure Upstream Operations Program. ↓
Secure Upstream Operations Program
Erweiterter Betrieb mit Security-Triage, Patch-Recherche im Kundenauftrag und Lieferung vorhandener Patches, sofern verfügbar.
Organisationen mit mehreren Produkten, die Schwachstellen- und Lifecycle-Fälle laufend bearbeitet und nachgewiesen brauchen.
Vereinbarte Bearbeitung definierter Open-Source-Lifecycle-, Security- und Upstream-Fälle in einem erweiterten Scope, einschließlich Recherche vorhandener Patches und Lieferung bei Verfügbarkeit.
- 01
Secure Operating Baseline
- Inventar- und SBOM-Konsolidierung
- Kritikalitäts- und Severity-Modell
- Security-Disclosure- und Freigabeprozess
- Rollen, Eskalation und Kommunikationswege
- 02
Continuous Lifecycle & Security Triage
- Schwachstellen- und CVE-Bewertung
- EOL-, Release- und Maintainer-Monitoring
- technische Reproduktion und Ursachenanalyse
- Risiko- und Maßnahmenpriorisierung
- 03
Patch-Recherche im Kundenauftrag
- beauftragten Patch-Bedarf und betroffene Versionen festhalten
- nach bereits vorhandenen Patches suchen
- Quellen, Verfügbarkeit und offene Punkte dokumentieren
- keine eigenen Patches, Pull Requests oder Workarounds entwickeln
- 04
Lieferung verfügbarer Patches
- vorhandene Patches liefern, sofern verfügbar
- Herkunft, betroffene Version und Stand nachvollziehbar übergeben
- fehlende Verfügbarkeit ausdrücklich ausweisen
- keine Garantie auf Verfügbarkeit oder Fehlerbehebung
- 05
Evidence, Governance & Steering
- laufendes Fall- und Recherche-Register
- zweiwöchentliches Steering
- Security- und Lifecycle-Evidence-Pack
- Abschlussbericht und Übergabe in ein mögliches Dauerbetriebsmodell
- Secure Operations Playbook
Service-, Security-, Disclosure-, Freigabe- und Eskalationsprozesse.
- Managed OSS/SBOM Register
Laufender Komponenten-, Lifecycle- und Risikostatus.
- Security & Triage Evidence
Findings, Entscheidungen, Maßnahmen und Nachweise.
- Upstream Case Pack
Dokumentierte Recherche, Quellen, Verfügbarkeitsstand und offene Punkte.
- Verfügbare Patches
Recherchierte, bereits vorhandene Patches, sofern verfügbar. Keine eigene Entwicklung, keine Verfügbarkeitsgarantie.
- Steering Reports
Zweiwöchentliche Updates für Management und Technik.
- Final Evidence & Rollout Report
Ergebnisbewertung, Risiken und Empfehlung für den Dauerbetrieb.
- technische Ansprechpartner und kurzfristige Freigabewege
- Versions- und Umgebungsangaben für den jeweiligen Fall; Test- oder Build-Zugänge nur für gesondert vereinbarte Reproduktionen
- externe Projektkommunikation nur, soweit im Auftrag vereinbart und freigegeben
- rechtzeitige Entscheidungen bei Disclosure, Patch und Release
- notwendige Zugänge und Artefakte
- 24/7-SOC- oder NOC-Betrieb
- unbegrenzte Engineering-Kapazität
- eigene Patch-, Pull-Request-, Feature- oder Architekturentwicklung
- garantierte Patch-Verfügbarkeit oder Fehlerbehebung
- Test, Integration, Installation und Rollout von Patches als automatische Leistung
- garantierte Ergebnisse von Community oder Maintainern
- Rechtsberatung oder verbindliche Lizenzgutachten
- Penetrationstests oder vollständige Secure-Code-Audits
- Betrieb Ihrer Produktivsysteme außerhalb des vereinbarten Scopes
DANACH Ein anschließender Dauerbetrieb oder weitere Bereiche werden separat vereinbart.
Trust Assessment oder Paket 1?
Beides sind abgegrenzte Prüfungen mit Report. Sie unterscheiden sich in Breite und Gegenstand.
| Trust Assessment | Governance & Risk Check | |
|---|---|---|
| GEGENSTAND | ein vereinbartes Produkt oder Release | eine Organisationseinheit mit bis zu 3 Produkten |
| GRUNDLAGE | bereitgestellte Artefakte und Nachweise | Artefakte, Zugänge und bis zu 3 Workshops |
| SCHWERPUNKT | Evidenz: Was ist für dieses Release belegt? | Baseline: Bestand, Governance, Risiken, Zuständigkeiten |
| ERGEBNIS | Trust Report | Inventory/SBOM Pack, Risk Register, Governance Map, 90-Tage-Plan |
| TYPISCHE DAUER | nach Scoping | 4–6 Wochen |
Für öffentliche Auftraggeber
Alle drei Pakete liegen als Standard-Leistungsbeschreibung mit festem Referenzumfang, Abnahmekriterien und Mitwirkungspflichten vor. Sie sind eigenständige Leistungsgegenstände und werden weder künstlich aufgeteilt noch kombiniert. Ob und welche Beschaffungswege anwendbar sind, prüft der jeweilige Auftraggeber.
Häufige Fragen zu den Paketen.
Was kosten die Pakete?
Jedes Paket hat einen Festpreis für den beschriebenen Referenzumfang. Wir nennen ihn im Angebot nach dem Erstgespräch, zusammen mit Umfang, Mitwirkung und Abnahmekriterien. Abweichungen vom Referenzumfang werden vorher gescopt.
Muss ich mit Paket 1 anfangen?
Nein. Jedes Paket ist eigenständig nutzbar. Der Operations Pilot kann mit einer vorhandenen Inventarbasis starten oder eine leichte Baseline selbst aufbauen.
Wie schnell reagieren Sie auf einen Fall?
Wir bearbeiten Fälle montags bis freitags von 9 bis 17 Uhr deutscher Zeit, außer an gesetzlichen Feiertagen. Verbindliche Reaktions- oder Lösungsfristen gelten nur nach gesonderter Vereinbarung mit Servicekanal, Prioritäten und bestätigter Kapazität.
Entwickeln Sie Patches oder Pull Requests?
Nein. In Paket 3 suchen wir nach bereits vorhandenen Patches und liefern sie, sofern verfügbar. Eigene Patch- oder Pull-Request-Entwicklung ist in keinem Paket enthalten, und wir garantieren keine Verfügbarkeit oder Fehlerbehebung.
Können Sie Ergebnisse bei Open-Source-Projekten garantieren?
Nein. Ob ein Projekt ein Issue annimmt, wann es ein Release veröffentlicht oder wie es auf eine Meldung reagiert, entscheiden die Maintainer. Wir dokumentieren unsere Schritte und Ergebnisse nachvollziehbar.
Welches Paket passt zu Ihrem Fall?
Im Erstgespräch klären wir Anlass, Umfang und den sinnvollen Einstieg. Danach erhalten Sie ein abgegrenztes Angebot.