Ein IT-Leiter, der gerade eine Ausschreibung mit Sicherheitsnachweisen auf dem Tisch hat, oder ein Geschäftsführer, der beim Steuerberater den Begriff „Cyber Resilience Act“ aufgeschnappt hat: Beide stellen sich früher oder später dieselbe Frage. Betrifft das auch die Access-Anwendung, die seit zwölf Jahren die Auftragsabwicklung am Laufen hält?
Kurze Antwort: kommt drauf an, wie die Software vertrieben wird. Lange Antwort: Selbst wenn die eigene Anwendung nicht direkt betroffen ist, wird jeder, der IT im Unternehmen verantwortet, in den nächsten Jahren mit dem Begriff SBOM – Software Bill of Materials, zu Deutsch Software-Stückliste – konfrontiert. Zeit, das einmal sauber einzuordnen, bevor es zur Feuerwehrübung wird.
Der CRA ist keine ferne Zukunft mehr
Der Cyber Resilience Act (Verordnung (EU) 2024/2847) ist die erste EU-weite Cybersicherheitspflicht für Produkte mit digitalen Elementen. Er ist seit dem 10. Dezember 2024 in Kraft, entfaltet seine Wirkung aber gestaffelt:
- Ab 11. September 2026 greift die Meldepflicht für aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle: 24 Stunden für die Frühwarnung, 72 Stunden für die vollständige Meldung, 14 Tage für den Abschlussbericht.
- Ab 11. Dezember 2027 gelten die vollständigen Herstellerpflichten: CE-Kennzeichnung, Konformitätsbewertung, technische Dokumentation – und die Pflicht, für jedes Produkt eine SBOM zu erstellen und aktuell zu halten.
Eine Software-Stückliste ist eine strukturierte, maschinenlesbare Liste aller Komponenten, aus denen eine Software besteht – Bibliotheken, Treiber, referenzierte Bausteine, jeweils mit Version und Herkunft. Vergleichbar mit der Zutatenliste auf einer Lebensmittelverpackung, nur dass hier nicht Zucker und Aroma stehen, sondern DLL-Version und Lizenz.
Entscheidend für die eigene Betroffenheit ist nicht B2B oder B2C, sondern eine einzige Frage: Wird die Software an mehr als einen Kunden auf dem Markt bereitgestellt? Eine Individuallösung für genau einen Kunden, intern genutzt, fällt in aller Regel unter die Ausnahme für kundenspezifische Software. Ein eigenes Produkt, das an zehn, fünfzig oder zweihundert Kunden lizenziert wird, macht aus dem Entwickler einen Hersteller im Sinne des CRA – mit voller Pflichtenkaskade.
Warum das Thema trotzdem auf jeden IT-Leiter-Schreibtisch gehört
Selbst wer keine eigene Software verkauft, bekommt die Wirkung des CRA zu spüren – nur indirekt. Wer Software oder Komponenten von Dritten einkauft, wird zunehmend selbst nach Stücklisten gefragt: von Kunden, von Auftraggebern in Ausschreibungen, von Wirtschaftsprüfern im Rahmen der Betriebsprüfung. Wer als IT-Leiter dann keine Antwort hat, weil im Haus niemand weiß, welche Komponenten in welcher Version wo laufen, hat ein Problem, das älter ist als der CRA: fehlende IT-Transparenz.
Eine Access-Datenbank ohne Dokumentation ist kein Risiko. Sie ist bereits ein Schaden. Der CRA macht diesen Zustand nur sichtbar, er erzeugt ihn nicht neu.
Wie man SBOMs im Haus aggregiert
Die eigentliche Herausforderung für einen IT-Leiter ist selten die einzelne Stückliste – die liefert im Idealfall jedes moderne Build-System automatisch mit. Die Herausforderung ist die Aggregation über zwanzig, fünfzig oder hundert Anwendungen hinweg, die im Lauf der Jahre entstanden sind, oft ohne einheitlichen Prozess.
Der De-facto-Standard dafür heißt OWASP Dependency-Track: eine zentrale Ablage, in die jedes Team oder jede Anwendung ihre SBOM im Format CycloneDX oder SPDX hochlädt. Dependency-Track gleicht die gemeldeten Komponenten kontinuierlich gegen Schwachstellendatenbanken ab (NVD, OSV, GitHub Advisories) und zeigt zentral, welche Komponente in welcher Version wo verbaut ist – und welche davon gerade eine bekannte Sicherheitslücke hat. Kommerzielle Alternativen wie Snyk, Black Duck oder JFrog Xray machen im Kern dasselbe, meist mit mehr Automatisierung und Enterprise-Support.
Der eigentliche Erfolgsfaktor liegt aber nicht im Tool, sondern im Lieferprozess: Eine SBOM, die nicht automatisch bei jedem Release entsteht, wird vergessen. Bei modernen Build-Pipelines (npm, .NET, Docker) übernehmen Werkzeuge wie syft oder cdxgen das automatisch. Bei gewachsenen Altsystemen – und dazu zählen die meisten Access-Anwendungen im deutschen Mittelstand – gibt es diesen Automatismus schlicht noch nicht.
Zwei Voraussetzungen, ohne die Aggregation nicht funktioniert:
- Ein vollständiges Inventar. Welche Anwendungen laufen überhaupt im Haus, inklusive der Access-Lösung, die vor Jahren mal ein Auszubildender gebaut hat? Dieser Schritt wird regelmäßig unterschätzt.
- Klare Verantwortlichkeit. Wer liefert pro Anwendung die SBOM, in welchem Rhythmus, und wer eskaliert, wenn eine kritische Schwachstelle in einer aggregierten Liste auftaucht – mit Blick auf die 24-Stunden-Frist ab September 2026 keine rein akademische Frage.
Was das für Access-Entwickler konkret bedeutet
Der folgende Abschnitt richtet sich an Kolleginnen und Kollegen, die selbst Access-Lösungen bauen oder betreuen – nicht an den Geschäftsführer, der bis hierhin gelesen hat.
Für eine Access-Anwendung mit SQL-Server-Backend – die in der Praxis häufigste Konstellation, sobald mehr als eine Handvoll Nutzer gleichzeitig arbeiten – setzt sich die relevante „Stückliste“ typischerweise aus mehreren Ebenen zusammen:
- VBA-Projektreferenzen (Verweise unter Extras → Verweise): jede referenzierte Bibliothek mit GUID und Version, von DAO über ADO bis zu Office-Objektbibliotheken.
- ActiveX-Controls in Formularen, jeweils über ProgID oder ClassID identifizierbar.
- ODBC-/OLEDB-Treiber, über die die Verbindung zum SQL-Server-Backend läuft – oft die unterschätzte Komponente, weil sie sich bei einem Windows-Update im Hintergrund ändert, ohne dass am Code etwas angefasst wurde.
- Externe DLLs, die per Declare-Anweisung eingebunden sind.
- Der SQL-Server-Backend selbst: Version, Edition, installierte Features (z. B. Full-Text-Search, CLR-Integration) gehören ebenso in eine vollständige Betrachtung wie das Frontend. Gerade weil die meisten Access-Lösungen genau diese Zweiteilung haben, wird der Backend-Teil in Stücklisten-Betrachtungen regelmäßig vergessen – dabei ist er der Teil, der am ehesten Sicherheitsupdates braucht.
Die gute Nachricht für alle, die seit Jahren mit gewachsenen Access-Beständen arbeiten: Fast alle diese Informationen lassen sich programmatisch auslesen. Referenzen, Controls und Connection Strings liegen im Objektmodell von Access beziehungsweise in der Registry vor – das ist kein neues Problem, sondern ein Extraktionsproblem, das sich mit vertretbarem Aufwand automatisieren lässt.
Die Grundvoraussetzung, die vor jeder SBOM steht: saubere Versionierung
Bevor sich die Frage „Wie erzeuge ich eine SBOM?“ überhaupt sinnvoll stellt, muss eine andere Frage beantwortet sein: Welche Version läuft gerade wo? Viele Access-Häuser haben nie eine konsequente Versionsnummerierung ihrer .accdb-Dateien eingeführt. Ohne sie lässt sich eine SBOM nicht sinnvoll zuordnen – man weiß dann zwar, welche Komponenten irgendwann verbaut waren, aber nicht, zu welchem konkreten Auslieferungsstand.
Die pragmatische Lösung: eine Versionskonstante im Code, die bei jedem Release hochgezählt wird, sichtbar etwa im Splash-Screen oder im Systeminfo-Dialog der Anwendung. Klingt banal, ist aber die Voraussetzung für alles Weitere.
Ein Blick nach vorn: die lokale SBOM-Tabelle
Ein Ansatz, der sich für Access-Anwendungen anbietet und im nächsten Beitrag mit konkretem VBA- und T-SQL-Code vertieft wird: eine lokale Tabelle im SQL-Server-Backend, die den aktuellen SBOM-Stand hält. Bei jedem Programmstart prüft die Anwendung, ob sich Referenzen, Treiberversionen oder Backend-Version seit dem letzten bekannten Stand geändert haben. Ist das der Fall, wird automatisch eine neue, standardkonforme CycloneDX- oder SPDX-Datei erzeugt und archiviert – die SBOM entsteht damit als Nebenprodukt des Betriebs, nicht als zusätzliche manuelle Pflichtübung, die beim dritten Hotfix garantiert vergessen wird.
Wie ein CycloneDX- bzw. SPDX-JSON aussieht
Beide Formate sind offene, standardisierte JSON-Schemas. Ein minimales CycloneDX-Dokument (Version 1.6) für eine Access-Anwendung könnte so aussehen:
{
"bomFormat": "CycloneDX",
"specVersion": "1.6",
"serialNumber": "urn:uuid:3e671687-395b-41f5-a30f-a58921a69b79",
"version": 3,
"metadata": {
"timestamp": "2026-07-31T09:00:00Z",
"component": {
"type": "application",
"name": "Auftragsabwicklung-Access",
"version": "4.2.1"
}
},
"components": [
{
"type": "library",
"name": "Microsoft DAO 3.6 Object Library",
"version": "3.60",
"purl": "pkg:generic/msdao@3.60"
},
{
"type": "library",
"name": "SQL Server Native Client",
"version": "11.4.7462.6",
"purl": "pkg:generic/sqlncli@11.4.7462.6"
}
]
}
Ein vergleichbares SPDX-Dokument (Version 2.3, JSON-Serialisierung) sieht strukturell anders aus, deckt aber denselben Zweck ab:
{
"spdxVersion": "SPDX-2.3",
"dataLicense": "CC0-1.0",
"SPDXID": "SPDXRef-DOCUMENT",
"name": "Auftragsabwicklung-Access-4.2.1",
"documentNamespace": "https://sesoft.de/spdx/auftragsabwicklung-4.2.1",
"creationInfo": {
"created": "2026-07-31T09:00:00Z",
"creators": ["Tool: sesoft-sbom-extractor-0.1"]
},
"packages": [
{
"SPDXID": "SPDXRef-Package-DAO",
"name": "Microsoft DAO Object Library",
"versionInfo": "3.60",
"downloadLocation": "NOASSERTION"
}
]
}
Beide Formate lassen sich ohne Sonderbehandlung in Dependency-Track oder vergleichbare Aggregatoren einspeisen – vorausgesetzt, bomFormat/specVersion beziehungsweise spdxVersion sind korrekt gesetzt.
Wo der Ansatz an Grenzen stößt
Automatisierte Extraktion deckt die direkte Ebene ab – Referenzen, Controls, Treiber, Backend-Version. Transitive Abhängigkeiten, etwa wenn eine referenzierte DLL selbst wieder Komponenten mitbringt, die Access nicht direkt sieht, lassen sich damit nicht vollständig erfassen. Für die meisten Access-Anwendungen im Mittelstand ist das kein Ausschlusskriterium, aber ein Punkt, den man nicht verschweigen sollte: Eine SBOM aus Access heraus wird nie so lückenlos sein wie die eines npm- oder NuGet-Projekts mit gepflegtem Abhängigkeitsbaum. Struktur vor KI heißt hier: erst die Grundlage schaffen, dann verfeinern – nicht auf Perfektion warten und deshalb gar nichts liefern.
Was das für den Betrieb ohne eigene Entwicklungsabteilung bedeutet
Wer keine eigene IT-Abteilung hat und Access-Lösungen über einen externen Dienstleister betreiben lässt, muss den CRA nicht selbst umsetzen – aber sollte beim nächsten Angebotsgespräch fragen, ob der Dienstleister eine SBOM liefern kann, wenn ein Kunde oder Auftraggeber danach fragt. Das ist inzwischen eine legitime Frage im Pflichtenheft, nicht mehr nur ein Nice-to-have für Konzerne. Access ist damit nicht das Auslaufmodell, als das es oft gehandelt wird – es passt sich, richtig gepflegt, ohne großen Umbau an neue regulatorische Anforderungen an.
Wie es weitergeht
Der nächste Beitrag auf sesoft.de zeigt die konkrete technische Umsetzung: die lokale SBOM-Tabelle im SQL-Server-Backend, die VBA-Routine zur Extraktion der Referenzen und Treiberversionen bei Programmstart, und den automatisierten Export nach CycloneDX. Wer sich schon jetzt fragen möchte, wie es um die eigene Access-Landschaft steht, erreicht mich über sesoft.de/kontakt.
Quellen
- Verordnung (EU) 2024/2847 (Cyber Resilience Act), EUR-Lex, Amtsblatt vom 20. November 2024
- Bundesamt für Sicherheit in der Informationstechnik (BSI): Cyber Resilience Act – Zeitplan und Umsetzung, abgerufen Juli 2026
- OWASP CycloneDX Specification, Version 1.6, cyclonedx.org
- SPDX Specification, Version 2.3, spdx.dev
- OWASP Dependency-Track, dependencytrack.org
Sönke Schäfer berät seit über 25 Jahren norddeutsche KMU rund um Microsoft Access und SQL Server. Sein Schwerpunkt liegt auf der pragmatischen Weiterentwicklung gewachsener Access-Bestände – auch dann, wenn neue regulatorische Anforderungen wie der Cyber Resilience Act ins Spiel kommen. Mehr über Sönke Schäfer
