macontrol

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:

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/12643/badge)](https://www.bestpractices.dev/projects/12643)

oder indem Sie Folgendes in Ihr HTML einbetten:

<a href="https://www.bestpractices.dev/projects/12643"><img src="https://www.bestpractices.dev/projects/12643/badge"></a>

Dies sind die Kriterien das Level

. Sie können auch die Kriterien für die Level

oder

sehen.

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

Analyse 2/2 ●

Dynamische Codeanalyse
Criterion [dynamic_analysis]
Erfüllt

Unerfüllt

N/A

?

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.
dynamic_analysis — macontrol evidence

Dynamic analysis is applied on every PR before release:
1. Go native fuzzing — FuzzDecode in internal/telegram/callbacks/data_fuzz_test.go runs 30s on every PR via the fuzz-short job in .github/workflows/ci.yml. Targets the only attacker-reachable parser before the whitelist gate. Commit 0bb56cc.
2. Race detector — go test -race -coverprofile=coverage.out ./... runs on the test matrix (ubuntu-latest + macos-14) on every push/PR. The race detector is a dynamic instrumentation tool that observes actual goroutine memory accesses at runtime.
3. Coverage measurement — go test -coverprofile is dynamic instrumentation; the resulting profile feeds go-test-coverage which enforces a per-package floor.
Releases are produced by release-please + GoReleaser only after CI is green, so no release ships without these dynamic checks having passed. The criterion is satisfied.
Criterion [dynamic_analysis_enable_assertions]
Erfüllt

Unerfüllt

N/A

?

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.
dynamic_analysis_enable_assertions — macontrol evidence

The project's dynamic analysis configuration enables checks well beyond what production builds carry:
1. Race detector enabled in tests, disabled in production
  CI: go test -race -coverprofile=coverage.out ./...
  Production build: go build -trimpath -ldflags="-s -w" CGO_ENABLED=0 — no -race
  The race detector is an extensive instrumentation layer (assertion-style runtime checks on every memory access between goroutines) that is documented to be unsuitable for production due to overhead. macontrol enables it for the test matrix on every PR and strips it from release binaries.
2. Go native fuzzer with assertion-style checks
  FuzzDecode runs the parser against random inputs and asserts on panics, oracle violations, and structural invariants. The fuzz harness is only compiled into test binaries, never the release artifact.
3. Test-only assertion helpers
  internal/runner/runner.go's Fake test mock asserts on the parsed (Name, Args) tuple of every subprocess call, providing test-time invariant checks the production runner does not perform.
4. Coverage floor as a runtime assertion
  go-test-coverage runs against the live coverage profile and asserts the floor is met (total 80%, package 75%, file 50%). This is a CI-time runtime check that does not exist in production.
These assertion-style checks are configured for test/CI runs only — production builds use stripped binaries (-s -w) with no debug info, no race detector, no fuzz harness, no coverage instrumentation. The criterion is satisfied.

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 AMiWR und die OpenSSF Best Practices Badge-Mitwirkenden als Urheber.

macontrol

Grundlagen 0/5 ●

Allgemein

Voraussetzungen

Projektüberwachung

Andere

Verbesserungs-/Nacharbeits-Kontrolle 1/4 ●

Öffentliches Versionskontroll-Source-Repository

Qualität 0/7 ●

Programmierstil

Produktivsystem

Automatisierte Test-Suite

Sicherheit 0/5 ●

Verwende grundlegend gute kryptographische Praktiken

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

Andere Sicherheitsissues

Analyse 2/2 ●

Dynamische Codeanalyse