Zum Hauptinhalt springen

Sicherheitskonzept

Einleitung​

Im Manifest wird der Fokus der Komponenten-Bibliothek definiert. Bezogen auf die Sicherheit können folgende Punkte herausgestellt werden:

  • Das Ziel der Bibliothek ist es, konsistente und barrierefreie Benutzeroberflächen für webbasierte Projekte bereitzustellen.
  • Dabei beschränkt sich der technische Scope der Bibliothek ausschließlich auf die Präsentationsschicht.
  • Zudem beinhalten die Komponenten keinerlei fachlichen Bezug und sind vollkommen allgemeingültig konzipiert.
  • Jeglicher fachlicher Kontext wird einer Komponente von außen „reingegeben“ und lediglich dargestellt.
  • Es gibt darüber hinaus keinerlei Datenübertragungsfunktionalitäten und -speicherung.

Initialer Commit​

Bevor der Quellcode veröffentlicht wurde, wurden u. a. folgende Reviews durchgeführt:

  • Qualitätssicherung: Grundsätzlich werden alle sinnvollen qualitätssteigernden Werkzeuge eingesetzt, die automatisiert und permanent den Quellcode prüfen (z. B. ESLint, TS-Prune, Tests, DepCheck, Prettier, Axe u. v. m.).
  • Automatisches Code-Review: Mittels Teamscale wurde der gesamte Quellcode überprüft. Hierbei kamen u. a. Tools wie ESLint, Prettier und zahlreiche Prüfschritte zur Einhaltung der JavaScript/TypeScript-Programmierrichtlinien des ITZBund zum Einsatz.
  • Manuelles Code-Review: Zusätzlich wurde ein Code-Review mittels eines Dienstleisters durchgeführt, um die Aufbereitung für ein öffentliches Repository bestmöglich umzusetzen.
  • Lizenz-Prüfung: Bei der Auswahl der Open-Source-Lizenz folgen wir den Bestrebungen der Europäischen Kommission mit der European Union Public Licence v1.2.

Maßnahmen​

In diesen Abschnitt wird beschrieben, welche Maßnahmen ergriffen werden, um die Sicherheit dauerhaft sicherzustellen.

Code Review​

Alle Git-Repositories sind so konfiguriert, dass Änderungen ausschließlich über einen Pull Request verbunden mit einem manuellen Code Review erfolgen können. Wird eine Änderung über einen Pull Request bereitgestellt, starten erst einmal alle eingerichteten Prüf-Pipelines automatisch und geben über die Erfüllung aller Qualitätsmaßstäbe Feedback. Ist die Änderung vollständig und alle automatisierten Prüfungen waren erfolgreich, muss ein manuelles Review eines Core-Team-Mitglieds erfolgen. Hierbei darf ein Core-Mitglied nicht seine eigene Änderung mergen.

Beim Review ist besonders auf folgende Punkte zu achten:

  • der Code darf keine personenbezogenen Daten oder Markennamen enthalten
  • der Contributor muss die CLA akzeptiert haben
  • der Umfang der Code-Änderung muss reviewbar sein (kleinteilig)

Contributor​

Es gibt interne und externe Contributoren (Beitragende). Interne Contributoren (Core-Team) haben umfangreiche Berechtigungen im Git-Repository und damit direkt am Quellcode und den daraus entstehenden Artefakten. Die externen Contributoren hingegen haben jeweils ein eigenes Git-Repository, sogenannt Forks oder eine Kopie. Auf die geforkten Git-Repositories oder Kopie haben wir (Core-Team) keinen Einfluss.