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 project uses a public GitHub repository with Git version control:
1. Version Control System: Git
  
  Full commit history preserved
  
  Branching and tagging support
  
  Distributed version control
2. Publicly Readable:
  
  No authentication required to view
  
  Source code browsable via web
  
  Clone/download available to anyone
3. Repository URL:
  
  Primary: https://github.com/LatticeArc/latticearc
  
  Git clone: git@github.com:LatticeArc/latticearc.git
4. Features:
  
  Commit history visible
  
  Blame/annotation available
  
  Diff viewing
  
  Branch/tag browsing
URL: https://github.com/LatticeArc/latticearc
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]
Git version control automatically tracks all required information:
1. What Changes Were Made:
  
  Full diff for every commit
  
  Line-by-line change tracking
  
  File additions, modifications, deletions recorded
2. Who Made the Changes:
  
  Author name and email on every commit
  
  Committer information preserved
  
  GitHub links commits to user profiles
3. When Changes Were Made:
  
  Timestamp on every commit
  
  Author date and commit date recorded
  
  Full chronological history
Example commit metadata:
commit 32e85d4
Author: Kalyan Amaresam <...>
Date: Fri Jan 30 23:22:15 2026 -0500
```
 docs: Add comprehensive codebase audit plan                                                                                                                         
```
Viewable via:
- git log (command line)
- GitHub web interface (commits page)
- git blame (per-line attribution)

URL: https://github.com/LatticeArc/latticearc/commits/main Repository on GitHub, which uses git. git can track the changes, who made them, and when they were made.
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).
The repository includes complete development history, not just releases:
1. All Commits Visible:
  
  Every individual commit is preserved
  
  Development work between releases is tracked
  
  52+ commits in last 30 days (not just release tags)
2. Interim Development:
  
  Feature branches for work-in-progress
  
  Individual commits for incremental changes
  
  Pull requests show proposed changes before merge
3. Release vs Development:
  
  v0.1.0 (Jan 29) → 20+ commits → v0.1.1 (Jan 30) → 10+ commits → v0.1.2 (Jan 30)
  
  All intermediate commits available for review
4. Example Interim Commits:
  
  "test(arc-core): Add comprehensive unified API tests"
  
  "ci: Pin Docker base image by hash"
  
  "docs: Clarify Apache vs Enterprise feature scope"
  
  These are development commits, not releases.
URL: https://github.com/LatticeArc/latticearc/commits/main
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.
The project uses Git, the most widely-used distributed version control system:
1. Version Control: Git
  
  Distributed architecture
  
  Full history on every clone
  
  Offline commit capability
  
  Industry standard
2. Hosting: GitHub
  
  Built on Git
  
  Web interface for collaboration
  
  Pull request workflow
  
  Issue tracking integration
3. Benefits:
  
  Anyone can fork and contribute
  
  Full redundancy (every clone is a backup)
  
  Branching/merging workflow
  
  Wide tooling support
Git market share: ~95% of developers use Git (Stack Overflow surveys)

URL: https://github.com/LatticeArc/latticearc Repository on GitHub, which uses git. git is 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).
The project uses Semantic Versioning (SemVer) with unique identifiers:
1. Version Format: MAJOR.MINOR.PATCH
  
  v0.1.0 - Initial release (Jan 29, 2026)
  
  v0.1.1 - Bug fixes (Jan 30, 2026)
  
  v0.1.2 - Dead code cleanup (Jan 30, 2026)
2. Version Sources:
  
  Cargo.toml: version = "0.1.2"
  
  Git tags for releases
  
  CHANGELOG.md documents each version
  
  crates.io publishes with version
3. Uniqueness Guaranteed:
  
  SemVer ensures no duplicate versions
  
  crates.io prevents version reuse
  
  Git tags are immutable
4. Workspace Version:
  
  Single version in [workspace.package]
  
  All crates share same version
  
  Consistent across entire project
URL:
- https://github.com/LatticeArc/latticearc/blob/main/CHANGELOG.md
- https://github.com/LatticeArc/latticearc/blob/main/Cargo.toml
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]}
The project uses git tags to identify releases:
1. Git Tags Used:
  
  v0.1.1 - "Fix hybrid signature verification and SecurityLevel docs"
2. Tag Format:
  
  Prefix: v
  
  SemVer version number
  
  Annotated with release description
3. Note:
  
  v0.1.0 and v0.1.2 tags should be added for completeness
  
  Tagging process should be part of release checklist
Tags viewable at:
- git tag -l (command line)
- GitHub Releases page

URL: https://github.com/LatticeArc/latticearc/tags

Recommendation: Add missing tags for consistency:
git tag -a v0.1.0 <commit-hash> -m "v0.1.0: Initial release"
git tag -a v0.1.2 <commit-hash> -m "v0.1.2: Dead code cleanup"
git push origin --tags
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.
The project provides human-readable release notes in CHANGELOG.md:
1. Format: Keep a Changelog (https://keepachangelog.com/)
  
  Not raw git log output
  
  Organized by category: Added, Changed, Fixed, Removed
  
  Human-written summaries
2. Content for Each Release:
  
  Version number and date
  
  Summary of major changes
  
  Impact on users
  
  Migration notes when needed
3. Example (v0.1.2):
  
  [0.1.2] - 2026-01-30
  
  Removed
  
  Dead Code Cleanup: Removed ~11,500 lines of unreachable code
  
  Added
  
  Unified API Tests: Comprehensive test coverage
  
  Changed
  
  Documentation: Clarified Apache vs Enterprise scope
  
  Notes
  
  Explains what was removed and why
  
  No breaking changes for users
4. Helps Users Decide:
  
  Breaking changes highlighted
  
  Security fixes noted
  
  New features listed
  
  Deprecations documented
URL: https://github.com/LatticeArc/latticearc/blob/main/CHANGELOG.md
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.
Not applicable - No publicly known vulnerabilities:
1. Project Status:
  
  Pre-1.0 software (v0.1.2)
  
  Initial release: January 29, 2026
  
  No CVEs have been filed against LatticeArc
2. No Vulnerabilities to Report:
  
  No CVE assignments for this project
  
  No security advisories issued
  
  No known run-time vulnerabilities
3. Future Commitment:
  
  SECURITY.md documents vulnerability reporting process
  
  CHANGELOG.md will document CVE fixes when applicable
  
  Security fixes will be categorized under "### Security" section
4. Verification:
  
  No entries in NVD for "latticearc"
  
  No GitHub Security Advisories for this repo
URL: https://github.com/LatticeArc/latticearc/blob/main/SECURITY.md

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 LatticeArc-Founder e aos contribuidores do selo de melhores práticas OpenSSF.

latticearc

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

[0.1.2] - 2026-01-30

Removed

Added

Changed

Notes

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