sentinel

Projekte, die den nachfolgenden Best Practices folgen, können sich freiwillig selbst zertifizieren und zeigen, dass sie einen Core-Infrastruktur-Initiative-/OpenSSF-Badge erhalten haben.

Es gibt keine Auswahl an Praktiken, die garantieren können, dass Software niemals Fehler oder Schwachstellen hat. Selbst formale Methoden können fehlschlagen, wenn die Spezifikationen oder Annahmen falsch sind. Auch gibt es keine Auswahl an Praktiken, die garantieren können, dass ein Projekt eine gesunde und gut funktionierende Entwicklungsgemeinschaft erhalten wird. Allerdings können Best Practices dabei helfen, die Ergebnisse von Projekten zu verbessern. Zum Beispiel ermöglichen einige Praktiken die Mehrpersonen-Überprüfung vor der Freigabe, die sowohl helfen können ansonsten schwer zu findende technische Schwachstellen zu finden und gleichzeitig dazu beitragen Vertrauen und den Wunsch nach wiederholter Zusammenarbeit zwischen Entwicklern verschiedener Unternehmen zu schaffen. Um ein Badge zu verdienen, müssen alle MÜSSEN und MÜSSEN NICHT Kriterien erfüllt sein, alle SOLLTEN Kriterien müssen erfüllt sein oder eine Rechtfertigung enthalten, und alle EMPFHOLEN Kriterien müssen erfüllt sein oder nicht (wir wollen sie zumindest berücksichtigt wissen). Wenn lediglich ein allgemeiner Kommentar angebeben werden soll, keine direkte Begründung, dann ist das erlaubt, wenn der Text mit "//" und einem Leerzeichen beginnt. Feedback ist willkommen auf derGitHub-Website als Issue oder Pull-Request. Es gibt auch eine E-Mail-Liste für allgemeine Diskussionen.

Wir stellen Ihnen gerne die Informationen in mehreren Sprachen zur Verfügung, allerdings ist die englische Version maßgeblich, insbesondere wenn es Konflikte oder Inkonsistenzen zwischen den Übersetzungen gibt.
Wenn dies Ihr Projekt ist, zeigen Sie bitte Ihren Badge-Status auf Ihrer Projektseite! Der Badge-Status sieht so aus: Badge-Level für Projekt 14063 ist passing So können Sie ihn einbetten:
Sie können Ihren Badge-Status anzeigen, indem Sie Folgendes in Ihre Markdown-Datei einbetten:
[![OpenSSF Best Practices](https://www.bestpractices.dev/projects/14063/badge)](https://www.bestpractices.dev/projects/14063)
oder indem Sie Folgendes in Ihr HTML einbetten:
<a href="https://www.bestpractices.dev/projects/14063"><img src="https://www.bestpractices.dev/projects/14063/badge"></a>


Dies sind die Kriterien das Level Gold. Sie können auch die Kriterien für die Level Passing oder Silber sehen.

Baseline Series: Baseline Niveau 1 Baseline Niveau 2 Baseline Niveau 3

        

 Grundlagen 0/5

  • Allgemein

    Hinweis: Andere Projekte können den selben Namen benutzen.

    The security update management platform for SUSE and openSUSE Linux distributions

    Bitte verwenden Sie das SPDX-License-Expression-Format; Beispiele sind "Apache-2.0", "BSD-2-Clause", "BSD-3-Clause", "GPL-2.0+", "LGPL-3.0+", "MIT" und "(BSD-2-Clause OR Ruby)". Geben sie nicht die einfachen oder doppelten Anführungszeichen mit an.
    Wenn es mehr als eine Programmiersprache gibt, listen Sie sie als kommagetrennte Werte (Leerzeichen sind optional) auf und sortieren Sie sie von am häufigsten zum am wenigsten verwendeten. Wenn es eine lange Liste gibt, bitte mindestens die ersten drei häufigsten auflisten. Wenn es keine Programmiersprache gibt (z. B. ist dies nur ein Dokumentations- oder Testprojekt), verwenden Sie das einzelne Zeichen "-". Bitte verwenden Sie eine herkömmliche Großschreibung für jede Sprache, z.B. "JavaScript".
    Das Common Platform Enumeration (CPE) ist ein strukturiertes Namensschema für IT-Systeme, Software und Pakete. Es wird in diversen Systemen und Datenbanken bei der Meldung von Schwachstellen verwendet.
  • Voraussetzungen


    Das Projekt MUSS ein Silber-Siegel erreichen. [achieve_silver]

  • Projektüberwachung


    Das Projekt MUSS einen "Busfaktor" von 2 oder mehr haben. (URL erforderlich) [bus_factor]
    Ein "bus factor" (aka "LKW-Faktor") ist die minimale Anzahl von Projektmitgliedern, die plötzlich aus einem Projekt ("hit by a bus") verschwinden müssen, bevor das Projekt aufgrund fehlender kompetenter Mitarbeiter stockt. Das Truck-Factor-Tool kann dies für Projekte auf GitHub schätzen. Weitere Informationen finden Sie unter Bewertung des Busfaktors von Git-Repositories von Cosentino et al.

    The project has a bus factor of 1 — a single maintainer (StayPirate) with sole repository admin access, release credentials, and merge authority. No second person has the necessary permissions to create releases, merge PRs, or manage the repository infrastructure. This is the same underlying gap as the previous criterion.



    Das Projekt MUSS mindestens zwei unabhängige bedeutende Entwickler haben. (URL erforderlich) [contributors_unassociated]
    Die Mitwirkenden sind assoziiert, wenn sie von der gleichen Organisation (als Angestellter oder Auftragnehmer) bezahlt werden und die Organisation von den Ergebnissen des Projekts profitieren wird. Finanzielle Zuschüsse aus derselben Organisation zählen nicht, wenn sie durch andere Organisationen gehen (z.B. werden wissenschaftliche Zuschüsse, die an verschiedene Organisationen von einer gemeinsamen Regierung oder NGO-Quelle gezahlt werden, nicht dazu führen, dass die Mitwirkenden assoziiert werden). Jemand ist ein/e wichtige/r Mitwirkende/r, wenn sie/er im vergangenen Jahr nicht-triviale Beiträge zum Projekt geleistet hat. Beispiele für gute Indikatoren für einen bedeutenden Mitwirkenden sind: mindestens 1.000 Zeilen Code geschrieben, 50 Commits erarbeitet oder mindestens 20 Seiten zur Dokumentation beigetragen.

    Sentinel currently has a single primary contributor/maintainer. There are no two unassociated significant contributors to the project. This is consistent with the "Unmet" bus factor criterion noted earlier — both reflect the single-maintainer reality of the project's current stage.


  • Andere


    Das Projekt MUSS eine Lizenzerklärung in jeder Quelldatei enthalten. Dies DARF als Kommentar relativ am Anfangs jeder Datei einfügt sein: SPDX-License-Identifier: [SPDX license expression for project]. [license_per_file]
    Dies DARF auch durch die Einbeziehung einer Erklärung in natürlicher Sprache geschehen, die die Lizenz kennzeichnet. Das Projekt DARF auch eine stabile URL enthalten, die auf den Lizenztext oder den vollständigen Lizenztext hinweist. Beachten Sie, dass das Kriterium license_location die Projektlizenz an einem Standardstandort benötigt. Weitere Informationen zu SPDX-Lizenzausdrücken finden Sie unter SPDX-Tutorial . Beachten Sie die Beziehung zu copyright_per_file , deren Inhalt typischerweise den Lizenzinformationen vorausgeht.

    Sentinel source files do not currently include SPDX license identifiers. The project has a top-level LICENSE file (MIT) but individual source files lack per-file license statements.


 Verbesserungs-/Nacharbeits-Kontrolle 3/4

  • Öffentliches Versionskontroll-Source-Repository


    Das Source-Repository des Projekts MUSS eine geläufige, verteilte Versionskontrollsoftware (z. B. git oder mercurial) verwenden. [repo_distributed]
    Git ist nicht speziell gefordert und Projekte können andere zentralisierte Versionskontrollsoftware (wie z. B. Subversion) mit Rechtfertigung verwenden.

    Repository on GitHub, which uses git. git is distributed.



    Das Projekt MUSS eindeutig kleine Aufgaben identifizieren, die von neuen oder gelegentlichen Mitwirkenden durchgeführt werden können. (URL erforderlich) [small_tasks]
    Diese Identifizierung erfolgt in der Regel durch die Markierung ausgewählter Ausgaben in einem Issue-Tracker mit einem oder mehreren Tags, die das Projekt für den Zweck verwendet, z.B. up-for-Grabs , First-Timers-only , "Small fix", Microtask oder IdealFirstBug. Diese neuen Aufgaben müssen nicht das Hinzufügen von Funktionalität beinhalten. Sie können die Dokumentation verbessern, Testfälle hinzufügen oder irgendetwas anderes, das das Projekt unterstützt und den Mitwirkenden hilft mehr über das Projekt zu verstehen.

    Sentinel does not currently use GitHub's "good first issue" label or any equivalent mechanism to identify tasks suitable for new or casual contributors. There are no labeled issues marking small, approachable tasks.



    Das Projekt MUSS eine Zwei-Faktor-Authentifizierung (2FA) für Entwickler haben, um ein zentrales Repository zu wechseln oder auf sensible Daten zugreifen zu können (z. B. private Schwachstellen-Berichte). Dieser 2FA-Mechanismus DARF Mechanismen ohne kryptographische Mechanismen wie SMS verwenden, obwohl dies nicht empfohlen wird. [require_2FA]

    GitHub requires 2FA as of March 2023. [osps_ac_01_01]



    Die Zwei-Faktor-Authentifizierung des Projekts (2FA) SOLLTE Kryptographie-Mechanismen verwenden, um Identitätswechsel zu verhindern. Short-Message-Service-/SMS-basierte 2FAs allein erfüllen dieses Kriterium nicht, da sie nicht verschlüsselt sind. [secure_2FA]
    Ein 2FA-Mechanismus, der dieses Kriterium erfüllt, wäre eine Time-Based-One-Time-Password-/TOTP-Anwendung, die automatisch einen Authentifizierungscode generiert, der sich nach einer gewissen Zeit ändert. Beachten Sie, dass GitHub TOTP unterstützt.

    The project's GitHub organization/account uses GitHub's two-factor authentication, which supports cryptographic mechanisms — TOTP (time-based one-time passwords via authenticator apps), hardware security keys (WebAuthn/FIDO2), and GitHub Mobile push notifications. SMS-based 2FA is not relied upon as the sole mechanism. GitHub's 2FA enforcement has been mandatory for all contributors since 2023.


 Qualität 6/7

  • Programmierstil


    Das Projekt MUSS seine Code-Review-Anforderungen dokumentieren, einschließlich, wie Code-Überprüfung durchgeführt wird, was überprüft werden muss und was erforderlich ist, um akzeptabel zu sein. (URL erforderlich) [code_review_standards]
    Siehe auch two_person_review und contribution_requirements.

    Sentinel's code review requirements are comprehensively documented in CONTRIBUTING.md (https://github.com/StayPirate/sentinel/blob/master/CONTRIBUTING.md), which references the detailed conventions. The full review process includes:

    • Automated reviewer agents: 15+ specialized reviewer agents (security, design, data-model, test, API convention, spec coherence, docs, etc.) are invoked per guardrail rules defined in AGENTS.md (https://github.com/StayPirate/sentinel/blob/master/AGENTS.md) — each guardrail specifies when to invoke which reviewer and what must be checked
    • What must be checked: mandatory testing for all changes (Guardrail 6), security review for security-sensitive code (Guardrail 10), data model review for schema changes (Guardrail 8), documentation completeness (Guardrail 9), spec coherence (Guardrail 15), API convention conformity (Guardrail 20), and more
    • Acceptance criteria: all CI checks must pass (ruff, mypy --strict, bandit, pip-audit, pytest), applicable reviewer agents must be invoked and findings addressed, PR description must include test evidence and manual verification notes
    • PR requirements: documented in docs/conventions.md (https://github.com/StayPirate/sentinel/blob/master/docs/conventions.md) (Pull Request Requirements) — title format, issue linkage, scope summary, reviewer results, verification evidence
    • Finding evaluation: Guardrail 26 documents how reviewer findings are evaluated — independent verification, discard criteria, proportionality, escalation procedure
    • CI enforcement: required status checks on master branch protection (7 checks), conversation resolution required before merge

    URL: https://github.com/StayPirate/sentinel/blob/master/CONTRIBUTING.md



    Das Projekt MUSS mindestens 50% aller vorgeschlagenen Änderungen vor dem Release durch eine andere Person als den Autor überprüfen, um festzustellen, ob es sich um eine sinnvolle Änderung handelt und frei von bekannten Problemen ist, die gegen die Freigabe der Änderung sprechen würden [two_person_review]

    Branch protection on master requires a pull request before merge, but the required approvals count is set to 0. This means a PR author can merge their own changes without any non-author human review. The project is currently single-maintainer, which makes enforcing non-author approval impractical (there is no second person to approve), but the criterion as stated is not satisfied by the current configuration. [osps_qa_07_01]


  • Produktivsystem


    Das Projekt MUSS ein reproducible Build haben. Wenn kein Building erforderlich ist (z. B. Skriptsprachen, in denen der Quellcode direkt verwendet wird, anstatt kompiliert zu werden), wählen Sie "nicht anwendbar" (N/A). (URL erforderlich) [build_reproducible]
    Eine reproduzierbares Build bedeutet, dass mehrere Parteien den Prozess der Generierung von Informationen aus Quelldateien unabhängig voneinander wiederholen und genau das gleiche Bit-für-Bit-Ergebnis erhalten können. In manchen Fällen kann dies dadurch gelöst werden, dass man eine Sortierreihenfolge erzwingt. JavaScript-Entwickler können erwägen npm shrinkwrap und webpack OccurenceOrderPlugin zu verwenden. GCC und clang Benutzer könnten die Option -frandom-seed nützlich finden. Die Buildumgebung (einschließlich des Toolsets) kann oft für externe Teilnehmer definiert werden, indem der kryptografische Hash eines bestimmten Containers oder einer virtuellen Maschine angegeben wird, die sie für das Kompilieren verwenden können. Das Reproducible Builds Projekt hat eine Dokumentation, wie dies erreicht werden kann.

    Sentinel is a pure Python application — the source code is interpreted directly, not compiled into binary artifacts. There is no compilation step that would produce build output requiring bit-for-bit reproducibility. The Docker image build installs Python packages from a lockfile (uv.lock) but the application itself has no build/compilation phase.


  • Automatisierte Test-Suite


    Eine Test-Suite MUSS in einer standardisierten Weise für diese Programmiersprache anrufbar sein. (URL erforderlich) [test_invocation]
    Zum Beispiel, "make check", "mvn test", oder "rake test" (Ruby).

    Sentinel's test suite is invocable using pytest, the standard Python testing framework:

    • Standard invocation: cd backend && uv run pytest — the conventional command documented in the project
    • Configuration: test settings are defined in backend/pyproject.toml (https://github.com/StayPirate/sentinel/blob/master/backend/pyproject.toml) under [tool.pytest.ini_options], following the standard pytest configuration convention
    • CI invocation: the CI pipeline (.github/workflows/ci.yml) invokes the same uv run pytest command with coverage flags
    • Markers: tests use standard pytest markers (@pytest.mark.unit, @pytest.mark.integration, @pytest.mark.e2e) for selective execution

    URL: https://github.com/StayPirate/sentinel/blob/master/backend/pyproject.tomlard invocation is required.



    Das Projekt MUSS eine kontinuierliche Integration implementieren, bei der neue oder geänderte Codes häufig in ein zentrales Code-Repository integriert werden und automatisierte Tests auf dem Ergebnis durchgeführt werden. (URL erforderlich) [test_continuous_integration]
    In den meisten Fällen bedeutet dies, dass jeder Entwickler, der Vollzeit auf dem Projekt arbeitet, mindestens täglich integriert.

    Sentinel implements continuous integration via GitHub Actions. Every push and pull request to master triggers the CI pipeline, which runs the full automated test and analysis suite:

    • Linting: ruff check . + ruff format --check .
    • Static type checking: mypy --strict
    • Security analysis: bandit (SAST) + pip-audit (SCA)
    • Shell analysis: shellcheck + shfmt -d + actionlint
    • Automated tests: uv run pytest (850+ tests with coverage)
    • Container scanning: Trivy image scan
    • PR title validation: Conventional Commits format enforcement
    • PR metadata validation: issue linkage requirement

    Branch protection on master requires 7 status checks to pass before merge. All changes arrive via pull request with squash merge — no direct pushes to master.

    URL: https://github.com/StayPirate/sentinel/blob/master/.github/workflows/ci.yml



    Das Projekt MUSS automatisierte FLOSS-Test-Suite(n) einsetzen, die mindestens 90% der Befehle abdecken, wenn es mindestens ein FLOSS-Tool gibt, das dieses Kriterium in der ausgewählten Programmiersprache messen kann. [test_statement_coverage90]

    Sentinel achieves 99% statement coverage (98.99% measured precisely), well above the 90% threshold. Coverage is measured by pytest-cov (a FLOSS tool) and enforced in CI with a minimum threshold of 85%. Results are uploaded to Codecov on every CI run. The latest successful CI run shows TOTAL: 3113 statements, 27 missed, 568 branches, 10 missed — 99% coverage.

    URL: https://app.codecov.io/github/staypirate/sentinel



    Das Projekt MUSS automatisierte FLOSS-Test-Suite(s) mit mindestens 80% Zweig-Abdeckung haben, wenn es mindestens ein FLOSS-Tool gibt, das dieses Kriterium in der ausgewählten Sprache messen kann. [test_branch_coverage80]

    From the same CI run, Sentinel's test suite achieves high branch coverage as well. The coverage report shows 568 branches, 10 missed — which is 98% branch coverage, well above the 80% threshold. Branch coverage is measured by pytest-cov (a FLOSS tool) using the --cov-branch flag, and results are uploaded to Codecov on every CI run.


 Sicherheit 5/5

  • Verwende grundlegend gute kryptographische Praktiken

    Beachten Sie, dass einige Software keine kryptographischen Mechanismen verwenden muss. Wenn Ihr Project Software erstellt das (1) kryptographische funktionen einbindet, aktiviert, oder ermöglicht und (2) aus den USA heraus an nicht US-Bürger verteilt wird, dann könnten sie rechtlich zu weiterne Schritten gezwungen sein. Meistens beinhaltet dies lediglich das Senden einer E-Mail. Für mehr Informationen, siehe den Abschnitt zu Encryption in Understanding Open Source Technology & US Export Controls.

    Die vom Projekt produzierte Software MUSS sichere Protokolle für alle Netzwerkkommunikationen unterstützen , wie SSHv2 oder höher, TLS1.2 oder höher (HTTPS), IPsec, SFTP und SNMPv3. Unsichere Protokolle wie FTP, HTTP, Telnet, SSLv3 oder früher, und SSHv1 MÜSSEN standardmäßig deaktiviert werden und nur aktiviert werden, wenn der/die Benutzer/in es speziell konfiguriert. Wenn die vom Projekt produzierte Software keine Netzwerkkommunikation verwendet, wählen Sie "nicht anwendbar" (N/A). [crypto_used_network]

    Sentinel supports secure protocols for all network communications and does not enable insecure protocols by default:

    • API server: serves over HTTPS; TLS configuration is handled at the deployment layer (reverse proxy / load balancer)
    • External service integrations: all HTTP clients (IBS, SMELT, AIMAAS, NVD, MITRE, Bugzilla, etc.) use HTTPS exclusively. The networking infrastructure (docs/features/platform/networking.md) configures TLS with certificate verification enabled by default
    • Database: connects to PostgreSQL via asyncpg, which supports TLS connections (sslmode parameter in DATABASE_URL)
    • Redis: connects via REDIS_URL, which supports rediss:// (TLS) scheme
    • RabbitMQ: connects via IBS_RABBITMQ_URL, which supports amqps:// (TLS) scheme
    • Git transport: git-based fetchers clone via HTTPS
    • No insecure defaults: no HTTP, FTP, telnet, or unencrypted protocols are used in application code. Plain HTTP is only accepted for local development (CORS_ORIGINS may include http://localhost:*)

    See docs/features/platform/networking.md (https://github.com/StayPirate/sentinel/blob/master/docs/features/platform/networking.md) and docs/data-sources.md (https://github.com/StayPirate/sentinel/blob/master/docs/data-sources.md) for the full external service catalog and protocol details.



    Die Projektsoftware MUSS, wenn sie TLS unterstützt oder verwendet, mindestens TLS Version 1.2 unterstützen. Beachten Sie, dass der Vorgänger von TLS SSL genannt wurde. Wenn die Software TLS nicht verwendet, wählen Sie "nicht anwendbar" (N/A). [crypto_tls12]

    Sentinel's TLS configuration supports TLS 1.2 and later:

    • Python runtime: Python 3.13's ssl module uses OpenSSL's default minimum protocol version, which is TLS 1.2 on all modern distributions (TLS 1.0 and 1.1 were deprecated in OpenSSL 1.1.1 and disabled by default in OpenSSL 3.x)
    • HTTP clients: the httpx library (used for all external service integrations) uses Python's ssl module, which enforces TLS 1.2+ by default
    • Database: asyncpg TLS connections negotiate TLS 1.2+ via the system OpenSSL
    • Redis/RabbitMQ: TLS connections via rediss:// and amqps:// schemes use Python's ssl module, defaulting to TLS 1.2+
    • Custom TLS context: the networking infrastructure (docs/features/platform/networking.md) supports configurable TLS contexts with certificate verification enabled by default, using the system trust store

    TLS versions prior to 1.2 (SSL 2.0, SSL 3.0, TLS 1.0, TLS 1.1) are disabled by the underlying OpenSSL library in the Python 3.13 base image (python:3.13-slim).


  • Gesicherte Zustellung gegen Man-in-the-Middle-/MITM-Angriffe


    Die Projekt-Website, das Repository (wenn über das Internet zugänglich) und die heruntergelandenen Seiten (falls separat) MÜSSEN Key-Hardening-Headers mit nichtpermeablen Werten enthalten. (URL erforderlich) [hardened_site]
    Beachten Sie, dass GitHub und GitLab bekannt bekannterweise dies erfüllen. Websites wie https://securityheaders.io/ können dies schnell überprüfen. Die wichtigsten Key-Hardening-Header sind: Content Security Policy (CSP), HTTP Strict Transport Security (HSTS), X-Content-Type-Options (as "nosniff"), and X-Frame-Options. Komplett statische websiten die keine Möglichkeit für das anmelden auf der webseite erlauben können vermutlich mit geringer Gefahr einige Hardening-Headers weglassen; es gibt jedoch keine verlässliche Methode solche Seiten zu identifizieren und deshalb erfordern wir diese Headers auch auf voll statischen Webseiten.

    Sentinel's repository and website are hosted on GitHub, which serves all pages with hardening headers including:

    • Content-Security-Policy: restrictive policy limiting script and resource sources
    • X-Content-Type-Options: nosniff
    • X-Frame-Options: DENY
    • Strict-Transport-Security: HSTS with long max-age, includeSubDomains, and preload
    • X-XSS-Protection: 0 (modern approach — CSP replaces this deprecated header)
    • Referrer-Policy: restrictive policy

    These are enforced by GitHub's infrastructure for all repositories and GitHub Pages sites. The project does not operate a separate website or download site outside of GitHub.

    URL: https://github.com/StayPirate/sentinel


  • Andere Sicherheitsissues


    Das Projekt MUSS innerhalb der letzten 5 Jahre eine Sicherheitsüberprüfung durchgeführt haben. Diese Überprüfung muss die Sicherheitsanforderungen und die Sicherheitsgrenze berücksichtigen. [security_review]
    Dies DARF durch die Projektmitglieder und/oder eine unabhängige Bewertung geschehen. Diese Bewertung kann durch statische und dynamische Analyse-Tools unterstützt werden, aber es muss auch eine menschliche Überprüfung sein, um Probleme zu identifizieren (insbesondere im Design), die Werkzeuge nicht erkennen können.

    The project maintains an extensive docs/reviews/ directory with security review findings for every major component — over 50 review documents covering authentication, RBAC, networking, API specification, fetcher infrastructure, and all integration points. Each review includes findings from a dedicated @security-reviewer agent (among others), threat model assessments (e.g., brute-force resistance in local-authentication, trusted-upstream assumptions in networking, pre-disclosure data exposure in RBAC), and explicit risk acceptance decisions with rationale. The CI pipeline also runs bandit (static security analysis) and pip-audit (dependency vulnerability scanning) on every merge. Security-sensitive areas are subject to mandatory review per Guardrail 10. [osps_sa_03_01]



    Härtungsmechanismen müssen in der Projektsoftware verwendet werden, so dass Softwarefehler weniger wahrscheinlich zu Sicherheitslücken führen. (URL erforderlich) [hardening]
    Härtungsmechanismen können HTTP-Header enthalten wie Content Security Policy (CSP), oder Compiler-Flags (z.B. -fstack-protector), um Angriffe zu mildern, oder Compiler-Flags, um undefiniertes Verhalten zu eliminieren. Für unsere Zwecke wird das Prinzip des kleinsten Privilegs nicht als Verhärtungsmechanismus betrachtet (trotzdem ist es wichtig, aber an anderer Stelle).

    Sentinel employs multiple hardening mechanisms to reduce the likelihood that software defects result in security vulnerabilities:

    • Memory-safe language: Python is memory-safe by design — no buffer overflows, use-after-free, or memory corruption
    • Strict static type checking: mypy --strict is a mandatory CI gate, catching type errors, unhandled None values, and forgotten await calls before production
    • SQL injection prevention: all database queries use SQLAlchemy's parameterized query API — no raw SQL string concatenation
    • Input validation at boundaries: Pydantic schemas reject malformed input before business logic; database CHECK constraints provide defense-in-depth
    • Secret masking: SecretStr type prevents accidental credential exposure in tracebacks, logs, and repr output
    • SAST: bandit detects common Python security anti-patterns (hardcoded passwords, eval, insecure deserialization) in CI
    • SCA: pip-audit blocks dependencies with known vulnerabilities pre-merge
    • Container scanning: Trivy scans the Docker image for OS and library vulnerabilities
    • Least-privilege CI: workflows default to permissions: read-all; jobs escalate only specific permissions needed
    • Secret scanning: GitHub Secret Scanning with Push Protection prevents accidental credential commits
    • Pessimistic locking: centralized mutation modules use SELECT ... FOR UPDATE to prevent race conditions
    • No custom cryptography: all crypto delegates to vetted FLOSS libraries (bcrypt, PyJWT, OpenSSL)

    These mechanisms are documented across docs/conventions.md (https://github.com/StayPirate/sentinel/blob/master/docs/conventions.md), docs/architecture.md (https://github.com/StayPirate/sentinel/blob/master/docs/architecture.md), and docs/deployment.md (https://github.com/StayPirate/sentinel/blob/master/docs/deployment.md) (CI Pipeline).


 Analyse 1/2

  • Dynamische Codeanalyse


    Das Projekt MUSS mindestens ein dynamisches Analyse-Tool auf jeden kommenden Hauptproduktionsrelease der Software, die durch das Projekt vor seiner Freigabe produziert wird, anwenden. [dynamic_analysis]
    Ein dynamisches Analyse-Tool untersucht die Software, indem es sie mit bestimmten Eingaben ausführt. Beispielsweise DARF das Projekt ein Fuzzing-Tool verwenden (z.B. American Fuzzy Lop) oder einen Web Application Scanner (z.B. OWASP ZAP oder w3af). In einigen Fällen ist das OSS-Fuzz Projekt bereit, Fuzz-Tests auf Ihr Projekt anzuwenden. Für die Zwecke dieses Kriteriums muss das dynamische Analyse-Tool die Eingaben in irgendeiner Weise variieren, um nach verschiedenen Arten von Problemen zu suchen oder eine automatisierte Test-Suite mit mindestens 80% Zweig-Abdeckung sein. Die Englische Wikipedia-Seite zur dynamischen Analysen und die OWASP Seite über Fuzzing nennen einige dynamische Analyse-Tools. Das Analyse-Tool(s) DARF für der Suche nach Sicherheitslücken eingesetzt werden, aber das ist nicht erforderlich.

    Sentinel does not currently apply dynamic analysis tools (e.g., fuzzing, property-based testing with Hypothesis, runtime sanitizers, or similar) to production releases. The project relies on static analysis (mypy --strict, bandit, ruff), dependency auditing (pip-audit), container scanning (Trivy), and an extensive automated test suite (850+ tests), but no dynamic analysis tool is part of the CI pipeline or release process. This is consistent with the "Unmet" status on the runtime assertions criterion above.



    Das Projekt SOLLTE viele Laufzeit-Assertionen in der Projektsoftware enthalten und diese Assertionen während der dynamischen Analyse überprüfen. [dynamic_analysis_enable_assertions]
    Dieses Kriterium schlägt nicht vor, Assertions in der Produktionsumgebung zu aktivieren; das liegt ganz beim Projekt und seinen Benutzern. Stattdessen liegt der Fokus dieses Kriteriums darauf, die Fehlererkennung während der dynamischen Analyse vor der Bereitstellung zu verbessern. Das Aktivieren von Assertions im Produktionseinsatz unterscheidet sich völlig vom Aktivieren von Assertions während der dynamischen Analyse (wie z.B. Tests). In einigen Fällen ist das Aktivieren von Assertions im Produktionseinsatz äußerst unklug (insbesondere bei hochintegren Komponenten). Es gibt viele Argumente gegen das Aktivieren von Assertions in der Produktion, z.B. sollten Bibliotheken keine Aufrufer zum Absturz bringen, ihre Anwesenheit kann zur Ablehnung durch App Stores führen und/oder das Auslösen einer Assertion in der Produktion kann private Daten wie private Schlüssel offenlegen. Beachten Sie, dass in vielen Linux-Distributionen NDEBUG nicht definiert ist, sodass C/C++ assert() standardmäßig für die Produktion in diesen Umgebungen aktiviert wird. Es kann wichtig sein, einen anderen Assertion-Mechanismus zu verwenden oder NDEBUG für die Produktion in diesen Umgebungen zu definieren.

    Sentinel does not currently make significant use of run-time assertions (assert statements) in its production code. Python's assert statements are stripped when running with optimization flags (-O), and the project relies instead on explicit validation (Pydantic schemas, service-layer guard clauses raising typed exceptions, database CHECK constraints) rather than assert-based runtime assertions. No dynamic analysis tool (e.g., fuzzing, property-based testing with Hypothesis) is currently integrated into the test suite or CI pipeline.



Sie können Tools und KI-Systeme nutzen, um Änderungen über eine einfache URL vorzuschlagen, z. B. https://www.bestpractices.dev/de/projects/14063/choose/edit?osps_ac_01_01_status=Met&osps_ac_01_01_justification=GitHub+enforced. Wie das geht, erfahren Sie in unserem Automatisierungsvorschlagssystem. Diese Daten sind unter der Community Data License Agreement – Permissive, Version 2.0 (CDLA-Permissive-2.0) verfügbar. Dies bedeutet, dass ein Datenempfänger die Daten mit oder ohne Änderungen weitergeben darf, solange der Datenempfänger den Text dieser Vereinbarung mit den weitergegebenen Daten zur Verfügung stellt. Bitte nennen Sie Gianluca Gabrielli und die OpenSSF Best Practices Badge-Mitwirkenden als Urheber.

Projekt-Badge-Eintrag im Besitz von: Gianluca Gabrielli.
Eintrag erstellt: 2026-08-13 13:55:49 UTC, zuletzt aktualisiert: 2026-08-14 06:09:03 UTC. Letztes erreichtes Badge: 2026-08-13 16:48:08 UTC.