BadgeApp

Controle de Mudanças 9/9 ●

Repositório de código-fonte público controlado por versão
Criterion [repo_public]
Atendido

Não atendido

?

O projeto DEVE ter um repositório de código-fonte controlado por versão que seja publicamente legível e tenha uma URL. ^{[repo_public]}
A URL PODE ser a mesma que a URL do projeto. O projeto PODE usar branches privados (não públicos) em casos específicos enquanto a mudança não for lançada publicamente (por exemplo, para corrigir uma vulnerabilidade antes de ser revelada ao público).
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]
Atendido

Não atendido

?

O repositório de código-fonte do projeto DEVE rastrear quais mudanças foram feitas, quem fez as mudanças e quando as mudanças foram feitas. ^[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]
Atendido

Não atendido

?

Para permitir revisão colaborativa, o repositório de código-fonte do projeto DEVE incluir versões intermediárias para revisão entre lançamentos; ele NÃO DEVE incluir apenas lançamentos finais. ^{[repo_interim]}
Os projetos PODEM optar por omitir versões intermediárias específicas de seus repositórios de código-fonte públicos (por exemplo, aquelas que corrigem vulnerabilidades de segurança não públicas específicas, podem nunca ser lançadas publicamente ou incluem material que não pode ser legalmente postado e não estão no lançamento final).
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]
Atendido

Não atendido

?

É SUGERIDO que software de controle de versão distribuído comum seja usado (por exemplo, git) para o repositório de código-fonte do projeto. ^{[repo_distributed]}
O Git não é especificamente exigido e os projetos podem usar software de controle de versão centralizado (como subversion) com justificativa.
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
Numeração de versão única
Criterion [version_unique]
Atendido

Não atendido

?

Os resultados do projeto DEVEM ter um identificador de versão único para cada lançamento destinado a ser usado pelos usuários. ^{[version_unique]}
Isso PODE ser atendido de várias maneiras, incluindo IDs de commit (como git commit id ou mercurial changeset id) ou um número de versão (incluindo números de versão que usam versionamento semântico ou esquemas baseados em data como AAAAMMDD).
```
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]
Atendido

Não atendido

?

É SUGERIDO que o formato de numeração de versão Versionamento Semântico (SemVer) ou Versionamento de Calendário (CalVer) seja usado para lançamentos. É SUGERIDO que aqueles que usam CalVer incluam um valor de nível micro. ^{[version_semver]}
Os projetos geralmente devem preferir qualquer formato que seja esperado por seus usuários, por exemplo, porque é o formato normal usado por seu ecossistema. Muitos ecossistemas preferem SemVer, e SemVer é geralmente preferido para interfaces de programação de aplicações (APIs) e kits de desenvolvimento de software (SDKs). CalVer tende a ser usado por projetos que são grandes, têm um número excepcionalmente grande de dependências desenvolvidas independentemente, têm um escopo em constante mudança ou são sensíveis ao tempo. É SUGERIDO que aqueles que usam CalVer incluam um valor de nível micro, porque incluir um nível micro suporta branches mantidos simultaneamente sempre que isso se tornar necessário. Outros formatos de numeração de versão podem ser usados como números de versão, incluindo IDs de commit do git ou IDs de changeset do mercurial, desde que identifiquem exclusivamente as versões. No entanto, algumas alternativas (como IDs de commit do git) podem causar problemas como identificadores de lançamento, porque os usuários podem não ser capazes de determinar facilmente se estão atualizados. O formato do ID de versão pode não ser importante para identificar lançamentos de software se todos os destinatários executarem apenas a versão mais recente (por exemplo, é o código para um único site ou serviço de internet que é constantemente atualizado via entrega contínua).
Criterion [version_tags]
Atendido

Não atendido

?

É SUGERIDO que os projetos identifiquem cada lançamento dentro de seu sistema de controle de versão. Por exemplo, é SUGERIDO que aqueles que usam git identifiquem cada lançamento usando tags do git. ^{[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:
Notas de lançamento
Criterion [release_notes]
Atendido

Não atendido

N/A

?

O projeto DEVE fornecer, em cada lançamento, notas de lançamento que sejam um resumo legível por humanos das principais mudanças nesse lançamento para ajudar os usuários a determinar se devem atualizar e qual será o impacto da atualização. As notas de lançamento NÃO DEVEM ser a saída bruta de um log de controle de versão (por exemplo, os resultados do comando "git log" não são notas de lançamento). Projetos cujos resultados não se destinam à reutilização em vários locais (como o software para um único site ou serviço) E empregam entrega contínua PODEM selecionar "N/A". (URL obrigatória) ^{[release_notes]}
As notas de lançamento PODEM ser implementadas de várias maneiras. Muitos projetos as fornecem em um arquivo chamado "NEWS", "CHANGELOG" ou "ChangeLog", opcionalmente com extensões como ".txt", ".md" ou ".html". Historicamente, o termo "change log" significava um log de todas as mudanças, mas para atender a esses critérios, o que é necessário é um resumo legível por humanos. As notas de lançamento PODEM, em vez disso, ser fornecidas por mecanismos de sistema de controle de versão, como o fluxo de trabalho GitHub Releases.
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]
Atendido

Não atendido

N/A

?

As notas de lançamento DEVEM identificar todas as vulnerabilidades de tempo de execução publicamente conhecidas corrigidas neste lançamento que já tinham uma atribuição CVE ou similar quando o lançamento foi criado. Este critério pode ser marcado como não aplicável (N/A) se os usuários normalmente não conseguem atualizar o software por conta própria (por exemplo, como geralmente é verdade para atualizações de kernel). Este critério se aplica apenas aos resultados do projeto, não às suas dependências. Se não houver notas de lançamento ou se não houve vulnerabilidades publicamente conhecidas, escolha N/A. ^{[release_notes_vulns]}
Este critério ajuda os usuários a determinar se uma determinada atualização irá corrigir uma vulnerabilidade que é publicamente conhecida, para ajudar os usuários a tomar uma decisão informada sobre atualização. Se os usuários normalmente não conseguem atualizar o software por conta própria em seus computadores, mas devem depender de um ou mais intermediários para realizar a atualização (como é frequentemente o caso de um kernel e software de baixo nível que está entrelaçado com um kernel), o projeto pode escolher "não aplicável" (N/A) em vez disso, já que essa informação adicional não será útil para esses usuários. Da mesma forma, um projeto pode escolher N/A se todos os destinatários executarem apenas a versão mais recente (por exemplo, é o código para um único site ou serviço de internet que é constantemente atualizado via entrega contínua). Este critério se aplica apenas aos resultados do projeto, não às suas dependências. Listar as vulnerabilidades de todas as dependências transitivas de um projeto torna-se difícil conforme as dependências aumentam e variam, e é desnecessário já que ferramentas que examinam e rastreiam dependências podem fazer isso de uma forma mais escalável.
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:

Estes dados estão disponíveis sob o Community Data License Agreement – Permissive, Version 2.0 (CDLA-Permissive-2.0). Isso significa que um Destinatário de Dados pode compartilhar os Dados, com ou sem modificações, desde que o Destinatário de Dados disponibilize o texto deste acordo com os Dados compartilhados. Por favor, dê crédito a Bill Berry e aos contribuidores do selo de melhores práticas OpenSSF.

Physical AI Toolchain

Fundamentos 13/13 ●

Geral

Conteúdo básico do site do projeto

Licença FLOSS

Documentação

Outro

Controle de Mudanças 9/9 ●

Repositório de código-fonte público controlado por versão

Numeração de versão única

Notas de lançamento

Relatórios 8/8 ●

Processo de relato de bugs

Processo de relato de vulnerabilidades

Qualidade 13/13 ●

Sistema de compilação funcional

Conjunto de testes automatizados

Teste de novas funcionalidades

Sinalizadores de aviso

Segurança 16/16 ●

Conhecimento de desenvolvimento seguro

Usar práticas criptográficas boas e básicas

Entrega protegida contra ataques man-in-the-middle (MITM)

Vulnerabilidades conhecidas publicamente corrigidas

Outras questões de segurança

Análise 8/8 ●

Análise estática de código

Análise dinâmica de código