docker-net-dhcp

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 13229 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/13229/badge)](https://www.bestpractices.dev/projects/13229)
oder indem Sie Folgendes in Ihr HTML einbetten:
<a href="https://www.bestpractices.dev/projects/13229"><img src="https://www.bestpractices.dev/projects/13229/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 2/5 ●

  • Allgemein

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

    Docker network plugin: containers get DHCP leases from the LAN. Modernized fork of devplayer0/docker-net-dhcp with macvlan attachment mode.

    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


    Nicht genug für ein Badge.

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

  • Projektüberwachung


    Nicht genug für ein Badge.

    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 bus factor is 1. This is stated openly rather than glossed at https://github.com/claymore666/docker-net-dhcp/blob/main/GOVERNANCE.md — the project is single-maintainer today and explicitly invites co-maintainers.


    Nicht genug für ein Badge.

    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.

    The fork has one significant contributor. Outside contributions arrive as issues and occasional pull requests, but not at the level of two significant unassociated contributors.


  • Andere


    Genug für ein Badge!

    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.

    Every source file in the repository carries "SPDX-License-Identifier: GPL-3.0-only" as its second comment line. The same gate, scripts/check-license-headers.sh, enforces it over the same set of files and rejects any other SPDX expression. The expression is GPL-3.0-only and not GPL-3.0-or-later because neither LICENSE.md here nor in devplayer0/docker-net-dhcp, the project this one succeeds, says "or any later version"; under GPLv3 section 14 that silence means only version 3 applies, and adopting -or-later would extend a permission the original authors never granted.


 Verbesserungs-/Nacharbeits-Kontrolle 3/4 ●

  • Öffentliches Versionskontroll-Source-Repository


    Genug für ein Badge!

    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.


    Nicht genug für ein Badge.

    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.

    Unmet today. The tracker carries a good first issue label and it was seeded with self-contained starter tasks, each stating the gap, the file to look at and the command that verifies the fix. Those were closed as the work they described landed, and no unclaimed work currently qualifies: the project's own standard is that a starter task is a real gap found during ordinary work, not one invented to carry the label, and inventing three would satisfy this criterion by making the claim false in a different way. The README's Contributing section says so plainly and, instead of linking a filter that returns nothing, sends a newcomer to the repository's Q&A discussions, which is a route that exists: it is published as a contact link on the new-issue chooser, and neither issue form fits the request because each stamps a type label that would be wrong for it. This answer is enforced, not remembered: scripts/check-good-first-issues.sh binds the status, the README's promise, the ask route and the label's open count to each other in both directions, so it goes red the day a genuine starter task is filed and this answer becomes Met again, and red too if the route the README names stops being one the repository offers.


    Genug für ein Badge!

    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]

    Two-factor authentication is enabled and enforced on the only account with write access to the repository and with access to private vulnerability reports; the GitHub API reports two_factor_authentication as true. Two factors are registered: a WebAuthn passkey and a TOTP application. No bot or machine account bypasses it.


    Genug für ein Badge!

    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.

    Both registered factors use cryptographic mechanisms. The primary is a WebAuthn passkey, which is public-key based and phishing-resistant; a TOTP application is registered as the fallback, which the criterion also accepts. SMS-based 2FA is not used.


 Qualität 4/7 ●

  • Programmierstil


    Genug für ein Badge!

    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.

    What a change must satisfy to be acceptable is documented for contributors — target branch, coding standard, test expectations, authorship rule, and the full set of checks that must be green before merge — at https://github.com/claymore666/docker-net-dhcp#contributing, with a pull request template that restates the checklist. Branch protection enforces the mechanical half of that review on every pull request.


    Nicht genug für ein Badge.

    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]

    Honestly unmet: with a single maintainer, changes cannot be reviewed before release by a person other than the author. Automated review substitutes as far as it can — required unit, staticcheck, live integration, govulncheck, actionlint, and attribution checks on every pull request, plus CodeQL — but that is not a second human reviewer.


  • Produktivsystem


    Genug für ein Badge!

    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.

    A published procedure lets anyone reproduce the build and check a release against it: https://claymore666.github.io/docker-net-dhcp/verifying-releases/#rebuilding-the-binaries-yourself . Verified end to end rather than self-checked: rebuilding the v1.4.0 tag from a clean git archive, on a BuildKit builder created fresh so no cache mount could be shared, produced binaries whose SHA-256 exactly match the ones inside the published v1.4.0 release tarball (net-dhcp 0ac36b87391c5bd5ea7a4b268183ca3fd86c686bf9b5d0505b97c4e0780d710b, dhcp-handler 0eb5b698698f2d8f4e997062c77f295726915c9ba31125db1800e602edfa4bf8). Determinism rests on digest-pinned base images, version-pinned Alpine packages, a fixed in-container build path, and no timestamp or VCS stamping. It is enforced, not asserted: the Reproducible build workflow builds the same commit twice on two cold builders and fails if the binaries differ, weekly and on any pull request touching the Dockerfile or the Go module files. Scope, stated plainly: the reproducible outputs are the compiled binaries. The release tarball itself is not byte-reproducible because tar and gzip record modification times, so the documented procedure compares the binaries extracted from that tarball rather than the tarball digest.


  • Automatisierte Test-Suite


    Genug für ein Badge!

    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).

    The unit suite is invoked the standard Go way: go test ./.... That is literally what CI runs (as go test -race -count=1 ./...); see the test job in https://github.com/claymore666/docker-net-dhcp/blob/main/.github/workflows/test.yaml . The live integration suites cannot be invoked that way, because they need root and a real Docker daemon to install the plugin against; they are invoked as sudo make integration-local, which rebuilds the plugin, installs it and runs both the main and the failure suite; see the integration-local target in https://github.com/claymore666/docker-net-dhcp/blob/main/Makefile . Both invocations are documented for contributors under "Running the tests": https://claymore666.github.io/docker-net-dhcp/latest/internals/#running-the-tests .


    Genug für ein Badge!

    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.

    Every push and every pull request to the integration branches runs the full gate on GitHub Actions: unit tests with the race detector, staticcheck, actionlint, govulncheck, CodeQL, a dependency review, and the live integration suites against a real DHCP server on a self-hosted runner. Workflow definitions: https://github.com/claymore666/docker-net-dhcp/tree/main/.github/workflows ; run history: https://github.com/claymore666/docker-net-dhcp/actions . The checks are required by branch protection on both integration branches, so a change cannot merge without them, and release pull requests additionally run a coverage ratchet that fails on any per-package regression. A weekly scheduled run repeats the gate so vulnerabilities published between commits surface without waiting for the next push.


    Nicht genug für ein Badge.

    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]

    Measured merged unit-plus-integration statement coverage is 85.8 percent as a statement-weighted total over the shipped packages (pkg/plugin 85.0 percent of 1811 statements, pkg/dhcp 89.9 of 338, pkg/util 98.5 of 78, cmd/net-dhcp 76.4 of 72, cmd/dhcp-handler 75.0 of 16). That clears the silver threshold of 80 percent but not the gold threshold of 90. Per-package floors are enforced by a coverage ratchet at release time and are raised as error-path tests land.


    Nicht genug für ein Badge.

    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]

    Branch coverage is not measured. The Go toolchain's coverage support reports statement coverage, which is what the project's ratchet gate enforces; no branch-coverage figure is available to substantiate this criterion.


 Sicherheit 3/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.

    Nicht genug für ein Badge.

    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]

    Honestly unmet, and structurally so: the plugin's purpose is to obtain addresses from the LAN's existing DHCP server, and DHCP (v4 and v6) has no encrypted variant to prefer or fall back to. Its other communication channel is the local Docker Unix socket, which does not traverse a network. SECURITY.md documents the resulting residual risk — a hostile DHCP server can hand out bad addressing — as accepted and outside the plugin's control.


    Genug für ein Badge!

    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]

    The software neither supports nor uses TLS.


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


    Nicht genug für ein Badge.

    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.

    The repository and release download sites are GitHub and GHCR, which do send hardening headers including CSP and HSTS. The project documentation site is GitHub Pages, which serves static content without configurable response headers, so the project cannot add hardening headers there. Unmet rather than N/A, because the shortfall is real even though it is not fixable on the current hosting.


  • Andere Sicherheitsissues


    Genug für ein Badge!

    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.

    A security review of this fork was performed and written up as the assurance case in https://github.com/claymore666/docker-net-dhcp/blob/main/SECURITY.md#security-assurance-case — it states the security goals, enumerates the adversaries (malicious container, hostile LAN DHCP server, supply-chain tampering), identifies the trust boundary around DHCP-server-supplied bytes and the privileged plugin process, and argues why the mitigations suffice, closing with the accepted residual risk. It is re-read as part of the release documentation review. Continuous automated review runs alongside it: CodeQL, govulncheck, staticcheck, and Dependency Review on every pull request.


    Genug für ein Badge!

    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).

    The plugin is written in Go, a memory-safe language, and imports the unsafe package in zero source files, so entire classes of memory-corruption defects cannot occur. The race detector runs over the unit suite in CI, the untrusted parsers are fuzzed on every pull request, and the plugin requests an explicit, minimal capability set in config.json rather than running fully privileged — the daemon shows that set to the user before installation. See https://github.com/claymore666/docker-net-dhcp/blob/main/SECURITY.md#security-assurance-case


 Analyse 2/2 ●

  • Dynamische Codeanalyse


    Genug für ein Badge!

    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.

    live integration suite + -race + native fuzzing


    Genug für ein Badge!

    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.

    -race detector + fuzz targets are runtime-assertion mechanisms



Sie können Tools und KI-Systeme nutzen, um Änderungen über eine einfache URL vorzuschlagen, z. B. https://www.bestpractices.dev/de/projects/13229/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 Chris und die OpenSSF Best Practices Badge-Mitwirkenden als Urheber.

Projekt-Badge-Eintrag im Besitz von: Chris.
Eintrag erstellt: 2026-06-14 12:10:55 UTC, zuletzt aktualisiert: 2026-09-28 18:09:32 UTC. Letztes erreichtes Badge: 2026-06-14 13:17:33 UTC.