.. SPDX-FileCopyrightText: 2023 cusy GmbH .. .. SPDX-License-Identifier: BSD-3-Clause Sicherheit ========== In früheren Kapiteln haben wir schon einige Hinweise gegeben, die einen sichereren Betrieb ermöglichen sollen. .. seealso:: * :ref:`uv-audit` * :ref:`secure-release-workflow` * :ref:`zizmorcore` * :ref:`add_2fa` Hier wollen wir die einzelnen Elemente nun nochmal zusammenfassen und erweitern. Dabei orientieren wir uns an der `OpenSSF Scorecard `_. Alternativ könnt ihr euch auch an :ref:`open_chain` orientieren. .. _check-vulnerabilities: Schwachstellen überprüfen ------------------------- Risiko: Hoch Mit dieser Prüfung wird festgestellt, ob das Projekt offene, nicht behobene Sicherheitslücken in seiner eigenen Codebasis oder in seinen Abhängigkeiten aufweist. Eine offene Sicherheitslücke kann leicht ausgenutzt werden und sollte so schnell wie möglich geschlossen werden. Für eine solche Überprüfung könnt ihr :abbr:`z.B. (zum Beispiel)` :ref:`uv audit ` verwenden. Alternativ könnt ihr auch `osv `_ oder `pip-audit `_ verwenden. Sie greifen üblicherweise auf die `Open Source Vulnerability Database `_ zurück. Wenn eine Schwachstelle in einer Abhängigkeit gefunden wird, solltet ihr auf eine nicht-anfällige Version aktualisieren; wenn kein Update verfügbar ist, solltet ihr überlegen, die Abhängigkeit zu entfernen. Wenn ihr glaubt, dass die Sicherheitslücke euer Projekt nicht betrifft, kann für ``uv audit`` in der :file:`pyproject.toml`-Datei Ausnahmen definiert werden, :abbr:`z.B. (zum Beispiel)`: .. code-block:: toml :caption: pyproject.toml [tool.uv.audit] ignore = ["PYSEC-2022-43017", "GHSA-5239-wwwm-4pmq"] oder besser: .. code-block:: toml :caption: pyproject.toml [tool.uv.audit] ignore-until-fixed = ["PYSEC-2022-43017"] .. seealso:: * `ignore `_ * `ignore-until-fixed `_ Wartung ------- .. _automatic-update: Werden die Abhängigkeiten automatisch aktualisiert? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Risiko: Hoch Veraltete Abhängigkeiten machen ein Projekt anfällig für Angriffe auf bekannte Schwachstellen. Daher sollte der Prozess der Aktualisierung von Abhängigkeiten automatisiert werden, indem nach veralteten oder unsicheren Anforderungen gesucht und :abbr:`ggf. (gegebenenfalls)` aktualisiert werden. Hierfür könnt ihr :abbr:`z.B. (zum Beispiel)` `dependabot `_ oder `Safety CLI `_ verwenden. Ihr könnt eure :doc:`/productive/envs/uv/index`-Umgebungen auch automatisch aktualisieren. .. seealso:: * :ref:`Update uv.lock ` Werden die Abhängigkeiten noch gewartet? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Risiko: Hoch Dies weist auf möglicherweise ungepatchte Sicherheitslücken hin. Daher sollte regelmäßig überprüft werden, ob ein Projekt archiviert wurde. Umgekehrt wird bei der OSSF-Scorecard davon ausgegangen, dass bei mindestens einem Commit in der Woche über 90 Tage hinweg das Projekt sehr aktiv gewartet wird. Ein Mangel an aktiver Wartung ist jedoch nicht unbedingt immer ein Problem: insbesondere kleinere Dienstprogramme müssen normalerweise nicht oder nur sehr selten gewartet werden. Fehlende aktive Wartung weist euch also nur darauf hin, dass ihr die Situation genauer untersuchen solltet. Ihr könnt euch die Aktivitäten eines Projekts auch mit Badges anzeigen lassen, :abbr:`z.B. (zum Beispiel)`: .. image:: https://img.shields.io/github/commit-activity/y/veit/python4datascience :alt: Jährliche Commit-Aktivität .. image:: https://img.shields.io/github/commit-activity/m/veit/python4datascience :alt: Monatliche Commit-Aktivität .. image:: https://img.shields.io/github/commit-activity/w/veit/python4datascience :alt: Wöchentliche Commit-Aktivität Gibt es ein Sicherheitskonzept für das Projekt? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Risiko: Mittel Idealerweise sollte mit dem Projekt eine :ref:`python-basics:security`-Datei :abbr:`o.ä. (oder ähnliches)` veröffentlicht worden sein. Diese Datei sollte Informationen enthalten, * wie eine Sicherheitslücke gemeldet werden kann ohne dass sie öffentlich sichtbar wird, * über den Ablauf und den Zeitplan für die Offenlegung der Schwachstelle, * zu Links, :abbr:`z.B. (zum Beispiel)` URLs und E-Mails, unter denen Unterstützung angefragt werden kann. .. seealso:: * `Guide to implementing a coordinated vulnerability disclosure process for open source projects `_ * `Adding a security policy to your repository `_ * `Runbook `_ Enthält das Projekt eine verwendbare Lizenz? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Risiko: Niedrig Eine :doc:`Lizenz ` weist darauf hin, wie der Quellcode verwendet werden darf oder nicht. Das Fehlen einer Lizenz erschwert jede Art von Sicherheitsüberprüfung oder Audit und stellt ein rechtliches Risiko für die potenzielle Nutzung dar. OpenSSF-Scorecard verwendet die `GitHub License API `_ für auf GitHub gehostete Projekte, ansonsten eine eigene Heuristik, um eine veröffentlichte Lizenzdatei zu erkennen. Dateien in einem :file:`LICENSES`-Verzeichnis sollten mit ihrem :ref:`SPDX `-Lizenzbezeichner benannt werden, gefolgt von einer entsprechenden Dateierweiterung, wie in der :ref:`REUSE `-Spezifikation beschrieben. OpenSSF Best Practices Badge ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Risiko: Niedrig Mit dem `OpenSSF Best Practices Badge Programm `_ könnt ihr euch auch ein entsprechendes Badge holen. Kontinuierliches Testen ----------------------- Werden im Projekt CI-Tests durchgeführt? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Risiko: Niedrig Bevor Code in Pull- oder Merge-Requests zusammengeführt wird, sollten Tests durchgeführt werden, die dabei helfen, Fehler frühzeitig zu erkennen und die Anzahl der Schwachstellen in einem Projekt zu reduzieren. .. seealso:: * :ref:`coverage-github-actions` Verwendet das Projekt Fuzzing-Tools? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Risiko: Mittel Fuzzing oder Fuzz-Testing übergibt unerwartete oder zufällige Daten an euer Programm, um Fehler zu entdecken. Regelmäßiges Fuzzing ist wichtig, um Schwachstellen aufzuspüren, die von anderen ausgenutzt werden können, zumal auch bei einem Angriff Fuzzing genutzt werden kann, um dieselben Schwachstellen zu finden. * Verwendet euer Projekt `Fuzzing `_? * Ist der Name des Repository in der `OSS-Fuzz `_-Projektliste enthalten? * Wird `ClusterFuzzLite `_ im Repository eingesetzt? * Sind benutzerdefinierte sprachenspezifische Fuzzing-Funktionen im Repository vorhanden, :abbr:`z.B. (zum Beispiel)` mit `atheris `_? Verwendet euer Projekt Werkzeuge zur statischen Codeanalyse? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Risiko: Mittel :term:`Statische Testverfahren` testen den Quellcode, bevor die Anwendung ausgeführt wird. Dies kann verhindern, dass bekannte Fehlerklassen versehentlich in die Codebasis eingeführt werden. .. _bandit: Mit `Bandit `__, das ihr mit :doc:`qa/ruff` verwenden könnt lassen sich :abbr:`u. a. (unter anderem)` folgende Schwachstellen überprüfen: +--------+-----------------------------------------------------------------------+ | Regel | Beschreibung | +--------+-----------------------------------------------------------------------+ | `S105`_| fest codierte Geheimnisse | +--------+-----------------------------------------------------------------------+ | `S301`_| :doc:`/data-processing/serialisation-formats/pickle/index` und andere | | | unsichere Deserialisierung | +--------+-----------------------------------------------------------------------+ | `S307`_| Verwendung von :func:`eval` mit nicht vertrauenswürdigen Eingaben | +--------+-----------------------------------------------------------------------+ | `S113`_| fehlende Zeitüberschreitungen | +--------+-----------------------------------------------------------------------+ | `S324`_| schwache Kryptografie wie :abbr:`z. B. (zum Beispiel)` MD5-Kollisionen| +--------+-----------------------------------------------------------------------+ | `S608`_| SQL-Injection über Zeichenfolgenformatierung | +--------+-----------------------------------------------------------------------+ .. seealso: `flake8-bandit `_ Bandit könnt ihr auch in Jupyter Notebooks, IDEs und das pre-commit-Framework integrieren. Zudem könnt ihr :doc:`/productive/qa/pysa` für `Taint `_-Analysen verwenden. Für GitHub-Repositories könnt ihr alternativ auch `CodeQL `_ verwenden; :abbr:`s.a. (siehe auch)` `codeql-action `_. Risikobewertung des Quellcodes ------------------------------ Ist das Projekt frei von eingecheckten Binärdateien? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Risiko: Hoch Generierte ausführbare Dateien im Quellcode-Repository (:abbr:`z.B. (zum Beispiel)` Java :file:`.class`-Dateien, Python :file:`.pyc` Dateien) erhöhen das Risiko, da sie schwer überprüft werden können, so dass sie veraltet oder böswillig manipuliert sein können. Diesen Problemen kann mit verifizierten, reproduzierbaren Builds begegnet werden, deren ausführbare Dateien jedoch nicht wieder im Quellcode-Repository landen sollten. .. seealso:: * `Reproducible Builds `_ * `Python 3.12.0 from a supply chain security perspective `_ * `Defending against the PyTorch supply chain attack PoC `_ Ist der Entwicklungsprozess anfällig für das Einschleusen von bösartigem Code? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Risiko: Hoch Mit :ref:`geschützten Git-Zweigen ` können Regeln für die Übernahme von Änderungen in Standard- und Veröffentlichungszweige definiert werden, :abbr:`z.B. (zum Beispiel)` automatisierte `statische Code-Analysen `_ mit :doc:`qa/flake8`, :doc:`qa/pysa`, :doc:`qa/wily` und :ref:`Code-Reviews ` über :abbr:`sog. (sogenannte)` :doc:`git/advanced/gitlab/merge-requests`. .. _code_reviews: Werden Code-Reviews durchgeführt? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Risiko: Hoch Mit Code-Reviews lassen sich unbeabsichtigte Schwachstellen oder das mögliche Einschleusen von bösartigem Code erkennen. :abbr:`Ggf. (Gegebenenfalls)` können so Angriffe aufgespürt werden, bei denen das Konto eines Teammitglieds unterwandert wurde. Wirken an dem Projekt Personen aus mehreren Organisationen mit? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Risiko: Niedrig Dies wird als Indiz für eine geringere Anzahl von vertrauenswürdigen Code-Reviewers gewertet. Hierfür kann in den Profilen nach unterschiedlichen Einträgen im Feld *Unternehmen* gesucht werden. Wünschenswert sind mindestens drei verschiedene Unternehmen in den letzten 30 Commits, wobei jedes dieser Teammitglieder mindestens fünf Commits gemacht haben sollte. Risikobewertung der Builds -------------------------- .. _lock-dependencies: Werden im Projekt Abhängigkeiten deklariert und festgeschrieben? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Risiko: Mittel In eurem Projekt sollten Abhängigkeiten, die während des Build- und Release-Prozesses verwendet werden, festgeschrieben werden. Dabei sollte eine *gepinnte Abhängigkeit* explizit auf einen bestimmten Hash gesetzt sein und nicht nur auf eine veränderbare Version oder einen Versionsbereich. :doc:`envs/spack/index` schreibt für die jeweilige Umgebung diese Hashes in :ref:`spack_lock`, :doc:`envs/uv/index` in :ref:`uv_lock` fest. .. tip:: Üblicherweise verwalte ich diese Dateien jedoch nur bei :doc:`python-basics:packs/apps` in :doc:`Git `. Bei :doc:`python-basics:libs/index` schränke ich üblicherweise lediglich den Versionsbereich der Abhängigkeiten in der :file:`pyproject.toml`-Datei ein. Für :doc:`python-basics:packs/apps` können sich dadurch die folgenden Sicherheitsrisiken verringern: * Die Prüfung und Bereitstellung erfolgt mit derselben Software, was die Risiken beim Deployment verringert, die Fehlersuche vereinfacht und Reproduzierbarkeit ermöglicht. * Kompromittierte Abhängigkeiten untergraben nicht die Sicherheit des Projekts. * Substitutionsangriffe, also Angriffe, die auf die Verwechslung von Abhängigkeiten abzielen, kann so entgegengewirkt werden. Das Festschreiben der Abhängigkeiten sollte jedoch Software-Updates nicht verhindern. Ihr könnt dieses Risiko verringern durch * automatisierte Werkzeuge, die euch benachrichtigen, wenn Abhängigkeiten in eurem Projekt veraltet sind * Anwendungen, die Abhängigkeiten festhalten, schnell aktualisieren. .. _S105: https://docs.astral.sh/ruff/rules/hardcoded-password-string/ .. _S301: https://docs.astral.sh/ruff/rules/suspicious-pickle-usage/ .. _S307: https://docs.astral.sh/ruff/rules/suspicious-eval-usage/ .. _S113: https://docs.astral.sh/ruff/rules/request-without-timeout/ .. _S324: https://docs.astral.sh/ruff/rules/hashlib-insecure-hash-function/ .. _S608: https://docs.astral.sh/ruff/rules/hardcoded-sql-expression/ .. _S608: https://docs.astral.sh/ruff/rules/hardcoded-sql-expression/