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

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

latticearc

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

[0.1.2] - 2026-01-30

Removed

Added

Changed

Notes

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