BadgeApp

Verbesserungs-/Nacharbeits-Kontrolle 9/9 ●

Öffentliches Versionskontroll-Source-Repository
Criterion [repo_public]
Erfüllt

Unerfüllt

?

Das Projekt MUSS ein versiongesteuertes Quell-Repository haben, das öffentlich lesbar ist und eine URL hat. ^{[repo_public]}
Die URL KANN die gleiche wie die Projekt-URL sein. Das Projekt KANN in bestimmten Fällen private (nichtöffentliche) Zweige verwenden, während die Änderung nicht öffentlich freigegeben wird (z. B. für die Behebung einer Sicherheitslücke, bevor sie veröffentlicht wird).
The repository is public on GitHub at https://github.com/microsoft/physical-ai-toolchain. All source code, documentation, infrastructure-as-code, CI/CD workflows, issue templates, and configuration files are publicly visible. The repository settings are configured for public access with no authentication required to view, clone, or fork.

Evidence:
- https://github.com/microsoft/physical-ai-toolchain
Criterion [repo_track]
Erfüllt

Unerfüllt

?

Das Quell-Repository des Projekts MUSS verfolgen, welche Änderungen vorgenommen wurden, wer die Änderungen vorgenommen hat und wann die Änderungen vorgenommen wurden. ^[repo_track]
The project uses Git for version control, which tracks every change with author identity, timestamp, commit message, and full diff. Every file modification is recorded in the Git history. GitHub's web interface provides commit history, blame view, and diff comparison for every file. The project enforces Conventional Commits format (feat:, fix:, docs:, chore:, etc.) via contribution guidelines, providing structured change descriptions.

Evidence:
- https://github.com/microsoft/physical-ai-toolchain/commits/main
- https://github.com/microsoft/physical-ai-toolchain/blob/main/CONTRIBUTING.md
Criterion [repo_interim]
Erfüllt

Unerfüllt

?

Um eine kollaborative Überprüfung zu ermöglichen, MUSS das Quell-Repository des Projekts Zwischenversionen für die Überprüfung zwischen Releases enthalten. Es DARF NICHT nur endgültige Veröffentlichungen enthalten. ^{[repo_interim]}
Projekte DÜRFEN sich entscheiden, bestimmte Zwischenversionen aus ihren öffentlichen Quell-Repositories auszulassen (z.B. diejenigen, die bestimmte nicht-öffentliche Sicherheitslücken beheben, niemals öffentlich freigegeben werden können, oder Material enthalten, das nicht legal veröffentlicht werden kann und nicht in der endgültigen Version enthalten ist).
All commits are pushed to the public GitHub repository continuously. The PR-based workflow ensures that every change is visible as a pull request before and after merge. Interim work-in-progress is visible through open PRs and feature branches. GitHub's branch protection rules require PR review before merging to main, so all interim states are publicly accessible. There is no private staging or hidden development — all work flows through the public repository.

Evidence:
- https://github.com/microsoft/physical-ai-toolchain/pulls
- https://github.com/microsoft/physical-ai-toolchain/branches
Criterion [repo_distributed]
Erfüllt

Unerfüllt

?

Es ist EMPFOHLEN, dass eine gemeinsame genutzte Versionskontrollsoftware (z.B. git oder mercurial) für das Source-Repository des Projekts verwendet wird. ^{[repo_distributed]}
Git ist nicht speziell gefordert und Projekte können andere zentralisierte Versionskontrollsoftware (wie z. B. Subversion) mit Rechtfertigung verwenden.
Git is a distributed version control system. Every clone of the repository contains the complete history and can function independently. Contributors fork and clone the repository (as documented in CONTRIBUTING.md), work locally, and submit changes via pull requests. There is no single point of failure — any clone contains the full repository history and can serve as a restore point.

Evidence:
- https://github.com/microsoft/physical-ai-toolchain/blob/main/CONTRIBUTING.md
- https://git-scm.com/about/distributed
Einzigartige Versionsnummerierung
Criterion [version_unique]
Erfüllt

Unerfüllt

?

Die für Endbenutzer vorgesehenen Projektergebnisse MÜSSEN eine eindeutige Versionskennung für jede Freigabe haben. ^{[version_unique]}
Dies DARF durch einer Vielzahl von Möglichkeiten, einschließlich einer Commit-IDs (wie z. B. gits Commit-ID oder mercurials Changeset-ID) oder eine Versionsnummer, (einschließlich Versionsnummern, die semantische oder datumsbasierte Systeme wie YYYYMMDD verwenden) erfüllt werden.
```
Every release has a unique version identifier. Four releases have been published: v0.1.0, v0.2.0, v0.3.0, and v0.4.0. Version numbers are managed by release-please automation, which reads Conventional Commits and bumps versions according to semantic versioning rules. The version is synchronized across pyproject.toml (Python package) and package.json (Node.js tooling) via release-please-config.json. Once a version is released, it is never reused or overwritten.

Evidence:
- https://github.com/microsoft/physical-ai-toolchain/tags
- https://github.com/microsoft/physical-ai-toolchain/blob/main/release-please-config.json
- https://github.com/microsoft/physical-ai-toolchain/blob/main/pyproject.toml
- https://github.com/microsoft/physical-ai-toolchain/blob/main/package.json
```
Criterion [version_semver]
Erfüllt

Unerfüllt

?

Es ist EMPFHOLEN, dass ein Semantic Versioning (SemVer) oder Calendar Versioning (CalVer) Versionsnummerierungsformat für Releases verwendet wird. Es ist EMPFHOLEN, dass Anwender des CalVer Formates auch die Micro Ebene mit angeben. ^{[version_semver]}
Andere Versionsnummerierungsschemata, wie z. B. Commit-IDs (wie z. B. gits Commit-ID oder mercurials Changeset-ID) oder datumsbasierte Schemata wie YYYYMMDD, DÜRFEN als Versionsnummern verwendet werden, da sie eindeutig sind. Einige Alternativen können zu Problemen führen, denn die Benutzer können nicht leicht feststellen, ob sie aktuell sind. SemVer kann weniger hilfreich sein, um Software-Releases zu identifizieren, wenn alle Empfänger nur die neueste Version ausführen (z.B. ist es der Code für eine einzelne Website oder Internet-Service, der ständig durch kontinuierliche Updates aktualisiert wird).
Criterion [version_tags]
Erfüllt

Unerfüllt

?

Es wird erwartet, dass Projekte jedes Release innerhalb ihres Versionskontrollsystems identifizieren. Zum Beispiel wird erwartet, dass die Projekte, die git verwenden, jedes Release mit git-Tags identifizieren. ^{[version_tags]}
Every release is tagged in the Git repository with a "v" prefix following the pattern vMAJOR.MINOR.PATCH. Four tags exist: v0.1.0, v0.2.0, v0.3.0, v0.4.0. Tags are created by release-please automation and are cryptographically signed using Sigstore gitsign keyless signing. The verify-tag-signature.yml workflow validates that all release tags are annotated (not lightweight) and carry valid cryptographic signatures. Tag integrity is verified via git tag -v with x509 format.

Evidence:
Versionshinweise
Criterion [release_notes]
Erfüllt

Unerfüllt

N/A

?

Das Projekt MUSS zu jedem Update Releasenotes enthalten, die eine lesbare Zusammenfassung der wichtigsten Änderungen der Version sind, damit Benutzer/innen sehen können, ob sie aktualisieren sollten und was die Auswirkungen des Updades sind. Die Releasenotes DÜRFEN NICHT die Rohausgabe eines Versionskontrollprotokolls sein (z. B. die "git log"-Befehlsergebnisse sind keine Releasenotes). Für Projekte, deren Ergebnisse nicht für die Wiederverwendung an mehreren Standorten bestimmt sind (z. B. die Software für eine einzelne Website oder Dienstleistung) und eine kontinuierliche Lieferung verwenden, können Sie "N/A" auswählen. (URL erforderlich) ^{[release_notes]}
Die Releasenotes DÜRFEN auf vielfältige Weise implementiert werden. Viele Projekte bieten sie in einer Datei namens "NEWS", "CHANGELOG" oder "ChangeLog", optional mit Erweiterungen wie ".txt", ".md" oder ".html" an. Historisch bedeutete der Begriff "Change Log" ein Protokoll, in dem jede Änderung festgehalten wird, aber um diese Kriterien zu erfüllen, benötigt es eine menschlich lesbare Zusammenfassung. Die Releasenotes können stattdessen von Versionskontrollsystemmechanismen wie dem GitHub Release Workflow zur Verfügung gestellt werden.
CHANGELOG.md follows the Keep a Changelog format (https://keepachangelog.com/) with Semantic Versioning. Each release entry documents changes categorized by type: Added, Changed, Fixed, Documentation, Refactoring, Performance, Build System, Operations, Chores, Security, and Miscellaneous (dependency bumps). release-please automation generates changelog entries from Conventional Commit messages, ensuring every merged PR with a conventional prefix appears in the release notes. The release-please-config.json maps commit types to changelog sections. GitHub draft releases are also created by the release workflow.

Evidence:
Criterion [release_notes_vulns]
Erfüllt

Unerfüllt

N/A

?

Die Releasenotes MÜSSEN jede öffentlich bekannte Laufzeit-Sicherheitslücke mit einer CVE-Zuweisung oder Ähnlichem kennzeichnen, die in der aktuellen veröffentlichten Version behoben sind. Dieses Kriterium darf als nicht anwendbar (N/A) markiert werden, wenn Benutzer typischerweise nicht selbst die Software aktualisieren. Diese Kirterium trifft nur auf die Projektergebnisse zu, nicht auf Abhängikeiten. Wenn keine Releasenotes vorhanden sind oder keine öffentlich bekannten Sicherheitslücken bekannt sind, wählen Sie (N/A). ^{[release_notes_vulns]}
Dieses Kiterium hilft Benutzer zu verstehen ob ein Update eine bestimmte öffentlich bekannte Sicherheitslücke schließt, und zu entscheiden ob das Update eingespielt wird oder nicht. Wenn Benutzer die Software normalerweise nicht selbst auf ihren Computern aktualisieren können, sondern stattdessen auf eine/n Mittelsfrau/mann angewiesen sind, um das Upgrade durchzuführen (wie es bei einem Kernel und einer Low-Level-Software häufig der Fall ist), wählen Sie stattdessen "nicht anwendbar" (N/A), da diese zusätzliche Information für den Benutzer nicht hilfreich ist. Ein Projekt kann auch N/A auswählen wenn alle Empfänger nur die neuste Version benutzen (z. B. wenn der Code für eine einzelne Webseite oder Internetdienst ist der continuierlich mittels Contious Delivery geupdated wird). Diese Kriterium betrifft nur die Projektergenbisse, nicht seine Abhängigkeiten. Alle Sicherheitslücken für alle Abhängigkeiten eines Projektes aufzulisten ist unhandlich weil Abhängikeiten sich regelmäßig ändern könen; außerdem ist es unnötig weil Tools die sich auf die Analyse von Abhängikeiten spezialisieren das viel skalierbarer hin bekommen.
No CVEs have been filed against this project to date. However, the release notes infrastructure is in place to document vulnerability fixes when they occur. Security-relevant dependency bumps (e.g., werkzeug, flask, cryptography) are tracked in the CHANGELOG.md under the Miscellaneous/Dependencies section. The release-please-config.json includes a dedicated "security" changelog section mapped to the "security" commit type, ensuring any security fix committed with "security:" prefix appears prominently in release notes. Additionally, GHSA vulnerability remediations are tracked and documented (e.g., PR #271).

Evidence:

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

Physical AI Toolchain

Grundlagen 13/13 ●

Allgemein

Grundlegende Informationen auf der Projektwebseite

FLOSS-Lizenz

Dokumentation

Andere

Verbesserungs-/Nacharbeits-Kontrolle 9/9 ●

Öffentliches Versionskontroll-Source-Repository

Einzigartige Versionsnummerierung

Versionshinweise

Berichterstattung 8/8 ●

Bug-Report-Prozess

Anfälligkeits-Prozessbericht

Qualität 13/13 ●

Produktivsystem

Automatisierte Test-Suite

Neue Funktionalitätsüberprüfung

Warnhinweise

Sicherheit 16/16 ●

Wissen über sichere Entwicklungspraktiken

Verwende grundlegend gute kryptographische Praktiken

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

Öffentlich bekannte Schwachstellen wurden behoben

Andere Sicherheitsissues

Analyse 8/8 ●

Statische Codeanalyse

Dynamische Codeanalyse