Color scheme: Riviera
You are here: start » de » Dokumentation » Werkzeuge für Microsoft Access » WKL Office SDK » concepts » Sicherheit und Pflichten des Herstellers

Sicherheit und Pflichten des Herstellers

graph TD
  M[Hersteller von WKL Office SDK] --> R[Fassung mit Änderungsprotokoll, Dokumentation, Software-Stückliste]
  M --> V[Bearbeitung gemeldeter Schwachstellen]
  V --> C[Koordinierendes CSIRT und ENISA]
  V --> N[Sicherheitshinweis an die Nutzer]
  R --> P[SDK auf dem Entwicklungs- und dem Build-Rechner]
  E[Kunde als NIS-2-Einrichtung] --> A[Bewertet seine Lieferanten]
  A --> M

WKL Office SDK ist ein Produkt mit digitalen Elementen im Sinne der Verordnung (EU) 2024/2847, der Cyberresilienz-Verordnung (Cyber Resilience Act, CRA). Diese Seite beschreibt, welche Pflichten sein Hersteller nach dieser Verordnung und als Lieferant von Einrichtungen hat, die unter die NIS-2-Richtlinie fallen, wie Sie eine Schwachstelle melden und was WKL Office SDK für den Schutz der Rechner, auf denen Ihre Anwendungen entwickelt und gebaut werden, tut.

Wichtige Punkte

  • Schwachstellen melden Sie an Wolfgang.van.der.Stille@gmail.com und zp@datecpro.de; siehe Eine Schwachstelle melden.
  • Die Meldepflichten gelten bereits. Art. 14 der Cyberresilienz-Verordnung gilt seit dem 11. September 2026, die übrigen Pflichten gelten ab dem 11. Dezember 2027 (Art. 71 Abs. 2).
  • Sicherheitskorrekturen erscheinen als eigene Fassung. Eine Sicherheitskorrektur kommt als eigene, kostenlose Korrekturfassung, und das Änderungsprotokoll weist sie als solche aus.
  • Ein Build führt Code Ihrer Quellen aus. Wer die Quellen ändern darf, kann Code auf dem Rechner ausführen, der sie baut; bauen Sie nur Quellen, denen Sie vertrauen. Datenbanken, die das SDK selbst öffnet, starten keinen eigenen Code.
  • Konformität bis 11. Dezember 2027. Bis dahin stellt der Hersteller für WKL Office SDK die EU-Konformitätserklärung mit CE-Kennzeichnung aus; siehe Weg zur Konformität.

So greifen die Pflichten

Wer Hersteller ist

Hersteller ist, wer ein Produkt mit digitalen Elementen entwickelt oder entwickeln lässt und unter eigenem Namen oder eigener Marke vermarktet (Art. 3 Nr. 13). Hersteller von WKL Office SDK ist EMSR DATA, D.O.O., Trg komandanta Staneta 8, 1000 Ljubljana, Slowenien, https://wvds.it, auch wenn Sie das Produkt über einen Vertriebspartner erhalten. The White Knight Labs und WKL sind Marken von EMSR DATA, D.O.O. Anwendungen, die mit dem SDK gebaut und ausgeliefert werden, haben einen eigenen Hersteller: ihren Herausgeber; seine Pflichten beschreibt Pflichten als Herausgeber nach der Cyberresilienz-Verordnung. Findet ein Herausgeber eine Schwachstelle im SDK, meldet er sie dessen Hersteller (Art. 13 Abs. 6); für seine Anwendung bleibt er selbst verantwortlich.

Eine Schwachstelle melden

Senden Sie die Meldung per E-Mail an beide Adressen:

  • Wolfgang.van.der.Stille@gmail.com
  • zp@datecpro.de

Nennen Sie die Fassung von WKL Office SDK (den Namen des Installationsordners oder die Version von bin\wkl-office.exe in den Eigenschaften der Datei), die Schritte, mit denen sich das Problem nachstellen lässt, was ein Angreifer damit erreicht und ob Ihnen eine Ausnutzung bekannt ist. Veröffentlichen Sie keine Einzelheiten, bevor eine korrigierte Fassung vorliegt; den Zeitpunkt der Veröffentlichung stimmt der Hersteller mit Ihnen ab.

Der Hersteller erfasst die Meldung, bewertet sie, behebt die Schwachstelle in einer Korrekturfassung und veröffentlicht danach einen Sicherheitshinweis mit den betroffenen und den korrigierten Fassungen, der Auswirkung und den Schritten, die Sie unternehmen sollten (Anhang I Teil II Nr. 2 und 4). Eine Sicherheitskorrektur bleibt mindestens zehn Jahre oder für den Rest des Unterstützungszeitraums verfügbar, je nachdem, was länger ist (Art. 13 Abs. 9).

Was der Hersteller meldet

AnlassFrühwarnungMeldungAbschlussbericht
aktiv ausgenutzte Schwachstellespätestens 24 h nach Kenntnisspätestens 72 h nach Kenntnisspätestens 14 Tage, nachdem eine Korrektur oder Risikominderung verfügbar ist
schwerwiegender Sicherheitsvorfall, der die Sicherheit von WKL Office SDK betrifftspätestens 24 h nach Kenntnisspätestens 72 h nach Kenntnisinnerhalb eines Monats nach der Meldung

Der Hersteller meldet über die einheitliche Meldeplattform der ENISA an das CSIRT, das der Mitgliedstaat seiner Hauptniederlassung als Koordinator benannt hat; die ENISA erhält die Meldung gleichzeitig (Art. 14 Abs. 7, Art. 16). Betroffene Nutzer werden über den Vorfall oder die Schwachstelle und über die Maßnahmen informiert, die sie ergreifen können (Art. 14 Abs. 8).

In Deutschland, Österreich und der Schweiz

Die Cyberresilienz-Verordnung gilt als Verordnung in allen Mitgliedstaaten unmittelbar und gleich; der Hersteller hat dieselben Pflichten, gleich in welchem Mitgliedstaat WKL Office SDK vertrieben wird. Die NIS-2-Richtlinie wirkt dagegen erst über die nationalen Umsetzungsgesetze. Eine Einrichtung unterliegt in der Regel dem Gesetz des Mitgliedstaats, in dem sie niedergelassen ist (Richtlinie (EU) 2022/2555, Art. 26 Abs. 1); Sonderregeln gelten unter anderem für Anbieter elektronischer Kommunikation, Cloud-Computing-Dienste, Rechenzentren und verwaltete Dienste. Ein Lieferant ist durch die Richtlinie nicht selbst verpflichtet; er erhält Anforderungen von seinem Kunden nach dem Recht, das für den Kunden gilt.

  • Deutschland: Koordinierendes CSIRT ist CERT-Bund im Bundesamt für Sicherheit in der Informationstechnik (BSI). Das NIS-2-Umsetzungsgesetz (in Kraft seit 6. Dezember 2025) hat das BSI-Gesetz neu gefasst; § 30 Abs. 2 BSIG verlangt von besonders wichtigen und wichtigen Einrichtungen unter anderem die Sicherheit der Lieferkette (Nr. 4) sowie Sicherheitsmaßnahmen bei Erwerb, Entwicklung und Wartung informationstechnischer Systeme einschließlich des Umgangs mit Schwachstellen (Nr. 5).
  • Österreich: Das Netz- und Informationssystemsicherheitsgesetz 2026 (NISG 2026, BGBl. I Nr. 94/2025, in Kraft seit 1. Oktober 2026) setzt die NIS-2-Richtlinie um; § 32 Abs. 4 lit. d verlangt von wesentlichen und wichtigen Einrichtungen die Sicherheit der Lieferkette.
  • Schweiz: Die Cyberresilienz-Verordnung und die NIS-2-Richtlinie gelten nicht. Betreiber kritischer Infrastrukturen melden Cyberangriffe nach dem Informationssicherheitsgesetz seit dem 1. April 2025 innerhalb von 24 Stunden dem Bundesamt für Cybersicherheit (BACS). Eine Meldung über eine Schwachstelle in WKL Office SDK nimmt der Hersteller auch aus der Schweiz an.
  • Ob Ihre Organisation eine Einrichtung im Sinne dieser Gesetze ist, entscheidet das jeweilige Gesetz; der Hersteller von WKL Office SDK prüft das nicht für Sie.

Pflichten als Lieferant von NIS-2-Einrichtungen

Wesentliche und wichtige Einrichtungen müssen die Sicherheit ihrer Lieferkette steuern, einschließlich der sicherheitsbezogenen Aspekte der Beziehung zu jedem unmittelbaren Lieferanten (Richtlinie (EU) 2022/2555, Art. 21 Abs. 2 Buchst. d). Sie berücksichtigen dabei die spezifischen Schwachstellen jedes Lieferanten sowie die Gesamtqualität seiner Produkte und seiner Cybersicherheitspraxis einschließlich der Sicherheit seiner Entwicklungsprozesse (Art. 21 Abs. 3). Ist Ihre Organisation eine solche Einrichtung, ist der Hersteller von WKL Office SDK einer Ihrer Lieferanten. Für Ihre Bewertung beschreiben diese Quellen das Produkt und den Umgang damit:

  • diese Seite, das Änderungsprotokoll mit jeder Fassung und ihren Sicherheitskorrekturen sowie die Befehlszeilenreferenz mit jedem Exitcode;
  • die Sicherheitsrichtlinie SECURITY.de.md und die Herstellerangaben MANUFACTURER.de.md im Release-Paket;
  • Fragen im Rahmen einer Lieferantenbewertung richten Sie an die Adressen unter Eine Schwachstelle melden.

Wie das SDK Entwicklungs- und Build-Rechner schützt

AnforderungWas WKL Office SDK tutGrenze
Angriffsfläche begrenzen (Anhang I Teil I Nr. 2 Buchst. j)Betreibt keinen Netzwerkdienst und öffnet keinen Port; das Access-Add-In wird nur durch wkl-office addin install registriert; ein Build startet ein eigenes, verborgenes Access und beendet es nach einem ZeitlimitEin Build führt VBA der Quellen aus (die Abschlussfunktion Finish, die Funktionen der WKL-Modelle): Wer die Quellen ändern darf, kann Code auf dem Build-Rechner ausführen; prüfen Sie Änderungen und lassen Sie einen Build-Agenten nur geprüfte Zweige bauen
Fremde Datenbanken ohne ihren Code öffnen (Anhang I Teil I Nr. 2 Buchst. j und k)Eine Datenbank, die das SDK selbst öffnet (Export, validate, call, test), öffnet es als Kopie ohne Startformular; eine Datenbank mit AutoExec-Makro lehnt es abHält ein hart beendetes Access eine Kopie noch fest, bleibt sie im temporären Ordner
Vertraulichkeit von Zugangsdaten (Anhang I Teil I Nr. 2 Buchst. e)Die Prüfung der Quellen meldet PWD= und Password= mit Wert in Verbindungstexten als Fehler: check und build enden mit Exitcode 2, commit lehnt ab (Exitcode 7); export entfernt Kennwörter aus den Verbindungszeilen des Linked Tables ManagerDie Prüfung findet nicht jede Form eines Kennworts, und ein bereits committetes Geheimnis bleibt im Verlauf; wechseln Sie es (Ein Kennwort steht in den Quellen)
Sichere Grundeinstellung (Anhang I Teil I Nr. 2 Buchst. b)Trägt den Ausgabeordner einer Konfiguration nur auf Klick des Entwicklers als vertrauenswürdigen Speicherort von Access ein, ohne Unterordner, und entfernt nur eigene EinträgeWer in einen vertrauenswürdigen Speicherort schreiben darf, kann dort Code ablegen, den Access ohne Rückfrage ausführt
Programme vor dem Start prüfen (Anhang I Teil I Nr. 2 Buchst. f)wkl-office verify-signature prüft, ob eine Programmdatei eine gültige Signatur des erwarteten Herausgebers trägt; Exitcode 0 oder 17, aus VBA nutzbar (Befehlszeilenreferenz)Es zählt nur die in der Datei eingebettete Signatur
Alle Daten und Einstellungen entfernen (Anhang I Teil I Nr. 2 Buchst. m)wkl-office addin remove --all entfernt das Add-In, die Zuordnung der Projektdateien und die Einstellungen des SDK für den BenutzerDer Bootstrapper Manager bleibt installiert; WKL Office SDK installieren nennt seinen Ordner
Nur die vorgesehenen Programme starten (Anhang I Teil I Nr. 2 Buchst. j)Startet git, svn, PowerShell 7, Visual Studio Code und wkl-office mit vollem Pfad aus dem PATH des Benutzers (nur absolute Einträge), cmd.exe und Windows PowerShell aus System32 und den Explorer aus dem Windows-Ordner; ein gleichnamiges Programm im aktuellen Ordner startet nieWer den PATH ändern kann, bestimmt, welches Programm startet – wie bei jedem Befehlszeilenwerkzeug
Fremde Projekte sicher verarbeiten (Anhang I Teil I Nr. 2 Buchst. j und k)Befehle wie check, status und export starten kein Programm und laden keine Bibliothek aus dem Projektordner: wkl-office lädt Bibliotheken nur aus seinem Programmordner und aus System32, das Add-In lädt Windows-Bibliotheken nur aus System32; eine Projektdatei mit Dokumenttypdefinition (DTD) lehnt das SDK ab; Muster mit Platzhaltern (Include, Exclude) vergleicht es in einer Zeit, die nur linear mit der Länge des Namens wächst; export schreibt Teile eines Designs der Datenbank und Symboldateien nur in ihren Ordner im Projekt und meldet alles andere als ProblemEin Build führt VBA der Quellen aus (erste Zeile)
Komponenten ermitteln, mit einer Software-Stückliste (Anhang I Teil II Nr. 1)Das Release-Paket enthält sbom.cdx.json (CycloneDX 1.6 nach BSI TR-03183-2): jede Datei mit ihrem SHA-512, die enthaltenen Codicons-Symbole von Microsoft sowie die .NET-Laufzeit und Microsoft Access, die es braucht, jeweils mit Version und Lizenz; wkl-office deliver schreibt eine solche Liste für jede Auslieferung Ihrer Anwendung–
Programmdateien vor Manipulation schützen (Anhang I Teil I Nr. 2 Buchst. f)Jede EXE und DLL des Release-Pakets trägt die Authenticode-Signatur von EMSR DATA, D.O.O. mit Zeitstempel; SHA256SUMS nennt die SHA-256-Prüfsumme jeder Datei; siehe WKL Office SDK installierenDer Bootstrapper Manager (Wkl.Bootstrapper.Manager.accdb) ist nicht signiert; SHA256SUMS erfasst ihn

Weg zur Konformität

Die übrigen Pflichten der Verordnung gelten ab dem 11. Dezember 2027. Der Hersteller entwickelt WKL Office SDK schon heute mit Blick auf die grundlegenden Cybersicherheitsanforderungen aus Anhang I und erfüllt bis zu diesem Tag alle Pflichten, die ihn als Hersteller treffen (Art. 13). Für WKL Office SDK heißt das:

  • Einstufung: Nach Einschätzung des Herstellers gehört WKL Office SDK zu keiner Kategorie wichtiger oder kritischer Produkte (Anhänge III und IV). Auslieferungen signiert der Starter von WKL Bootstrapper, nicht das SDK; das SDK ist keine Public-Key-Infrastruktur und verwaltet weder Identitäten noch Netzwerke.
  • Konformitätsbewertung: Der Hersteller bewertet die Konformität selbst, im Verfahren der internen Kontrolle (Modul A, Anhang VIII Teil I); eine benannte Stelle ist dafür nicht vorgeschrieben (Art. 32 Abs. 1).
  • Technische Dokumentation: Sie enthält unter anderem die Bewertung der Cybersicherheitsrisiken, die Prüfberichte und die Begründung des Unterstützungszeitraums (Art. 31, Anhang VII). Sie ist nicht öffentlich: Der Hersteller legt sie der Marktüberwachungsbehörde auf Verlangen vor und bewahrt sie mindestens zehn Jahre auf (Art. 13 Abs. 13). Die Software-Stückliste liegt zusätzlich im Release-Paket (sbom.cdx.json).
  • EU-Konformitätserklärung und CE-Kennzeichnung: Jeder Fassung liegt die Erklärung bei oder eine vereinfachte Erklärung mit der Internetadresse der vollständigen (Art. 13 Abs. 20, Art. 28). Bei Software steht die CE-Kennzeichnung auf der Erklärung oder auf der Website zum Produkt (Art. 30 Abs. 1).
  • Unterstützungszeitraum: Jede Fassung ist ab ihrem Auslieferungsmonat fünf Jahre unterstützt; das Enddatum steht mit Monat und Jahr bei jeder Fassung (Art. 13 Abs. 8 und 19). Sicherheitskorrekturen erscheinen für die neueste Fassung der Hauptversion; eine neuere Fassung derselben Hauptversion ist kostenlos und verlangt keine Anpassungen (Art. 13 Abs. 10).

Für Fassungen, die vor dem 11. Dezember 2027 in Verkehr gebracht wurden, gelten diese Anforderungen nur, wenn sie danach wesentlich geändert werden; die Meldepflichten nach Art. 14 gelten für alle Fassungen (Art. 69 Abs. 2 und 3).

Diese Fassung trägt noch keine EU-Konformitätserklärung und keine CE-Kennzeichnung. Das Enddatum des Unterstützungszeitraums entsteht mit der Konformitätsbewertung.

Einordnung und Quellen

Diese Seite fasst die Pflichten des Herstellers und den Beitrag von WKL Office SDK zusammen, etwa als Grundlage für Ihre Lieferantenbewertung. Verbindlich sind die unten genannten Rechtstexte. Ob Ihre Organisation eine wesentliche oder wichtige Einrichtung ist und welche Pflichten sie selbst treffen, beurteilen Sie selbst oder mit Ihrer Rechtsberatung. Quellen: Verordnung (EU) 2024/2847, ABl. L vom 20.11.2024, http://data.europa.eu/eli/reg/2024/2847/oj (Art. 3 Nr. 13, Art. 13, 14, 16, 28, 30 bis 32, 69, 71 Abs. 2, Anhänge I bis III, V, VII und VIII); Richtlinie (EU) 2022/2555, ABl. L 333 vom 27.12.2022, http://data.europa.eu/eli/dir/2022/2555/oj (Art. 21, 26); BSI-Gesetz in der Fassung des NIS-2-Umsetzungsgesetzes (§ 30); NISG 2026 (§ 32); Schweizer Informationssicherheitsgesetz (Meldepflicht für Betreiber kritischer Infrastrukturen).

Verwandte Themen

de/wiki/msaccess/sdk/concepts/security-and-manufacturer-obligations.txt · Last modified: by Wolfgang van der Stille