BadgeApp

Change Control 9/9 ●

Public version-controlled source repository
Criterion [repo_public]
Met

Unmet

?

The project MUST have a version-controlled source repository that is publicly readable and has a URL. ^{[repo_public]}
The URL MAY be the same as the project URL. The project MAY use private (non-public) branches in specific cases while the change is not publicly released (e.g., for fixing a vulnerability before it is revealed to the public).
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]
Met

Unmet

?

The project's source repository MUST track what changes were made, who made the changes, and when the changes were made. ^[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]
Met

Unmet

?

To enable collaborative review, the project's source repository MUST include interim versions for review between releases; it MUST NOT include only final releases. ^{[repo_interim]}
Projects MAY choose to omit specific interim versions from their public source repositories (e.g., ones that fix specific non-public security vulnerabilities, may never be publicly released, or include material that cannot be legally posted and are not in the final release).
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]
Met

Unmet

?

It is SUGGESTED that common distributed version control software be used (e.g., git) for the project's source repository. ^{[repo_distributed]}
Git is not specifically required and projects can use centralized version control software (such as subversion) with justification.
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.
Unique version numbering
Criterion [version_unique]
Met

Unmet

?

The project results MUST have a unique version identifier for each release intended to be used by users. ^{[version_unique]}
This MAY be met in a variety of ways including a commit IDs (such as git commit id or mercurial changeset id) or a version number (including version numbers that use semantic versioning or date-based schemes like YYYYMMDD).
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]
Met

Unmet

?

It is SUGGESTED that the Semantic Versioning (SemVer) or Calendar Versioning (CalVer) version numbering format be used for releases. It is SUGGESTED that those who use CalVer include a micro level value. ^{[version_semver]}
Projects should generally prefer whatever format is expected by their users, e.g., because it is the normal format used by their ecosystem. Many ecosystems prefer SemVer, and SemVer is generally preferred for application programmer interfaces (APIs) and software development kits (SDKs). CalVer tends to be used by projects that are large, have an unusually large number of independently-developed dependencies, have a constantly-changing scope, or are time-sensitive. It is SUGGESTED that those who use CalVer include a micro level value, because including a micro level supports simultaneously-maintained branches whenever that becomes necessary. Other version numbering formats may be used as version numbers, including git commit IDs or mercurial changeset IDs, as long as they uniquely identify versions. However, some alternatives (such as git commit IDs) can cause problems as release identifiers, because users may not be able to easily determine if they are up-to-date. The version ID format may be unimportant for identifying software releases if all recipients only run the latest version (e.g., it is the code for a single website or internet service that is constantly updated via continuous delivery).
Criterion [version_tags]
Met

Unmet

?

It is SUGGESTED that projects identify each release within their version control system. For example, it is SUGGESTED that those using git identify each release using git tags. ^{[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
Release notes
Criterion [release_notes]
Met

Unmet

N/A

?

The project MUST provide, in each release, release notes that are a human-readable summary of major changes in that release to help users determine if they should upgrade and what the upgrade impact will be. The release notes MUST NOT be the raw output of a version control log (e.g., the "git log" command results are not release notes). Projects whose results are not intended for reuse in multiple locations (such as the software for a single website or service) AND employ continuous delivery MAY select "N/A". (URL required) ^{[release_notes]}
The release notes MAY be implemented in a variety of ways. Many projects provide them in a file named "NEWS", "CHANGELOG", or "ChangeLog", optionally with extensions such as ".txt", ".md", or ".html". Historically the term "change log" meant a log of every change, but to meet these criteria what is needed is a human-readable summary. The release notes MAY instead be provided by version control system mechanisms such as the GitHub Releases workflow.
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]
Met

Unmet

N/A

?

The release notes MUST identify every publicly known run-time vulnerability fixed in this release that already had a CVE assignment or similar when the release was created. This criterion may be marked as not applicable (N/A) if users typically cannot practically update the software themselves (e.g., as is often true for kernel updates). This criterion applies only to the project results, not to its dependencies. If there are no release notes or there have been no publicly known vulnerabilities, choose N/A. ^{[release_notes_vulns]}
This criterion helps users determine if a given update will fix a vulnerability that is publicly known, to help users make an informed decision about updating. If users typically cannot practically update the software themselves on their computers, but must instead depend on one or more intermediaries to perform the update (as is often the case for a kernel and low-level software that is intertwined with a kernel), the project may choose "not applicable" (N/A) instead, since this additional information will not be helpful to those users. Similarly, a project may choose N/A if all recipients only run the latest version (e.g., it is the code for a single website or internet service that is constantly updated via continuous delivery). This criterion only applies to the project results, not its dependencies. Listing the vulnerabilities of all transitive dependencies of a project becomes unwieldy as dependencies increase and vary, and is unnecessary since tools that examine and track dependencies can do this in a more scalable way.
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

This data is available under the Community Data License Agreement – Permissive, Version 2.0 (CDLA-Permissive-2.0). This means that a Data Recipient may share the Data, with or without modifications, so long as the Data Recipient makes available the text of this agreement with the shared Data. Please credit LatticeArc-Founder and the OpenSSF Best Practices badge contributors.

latticearc

Basics 13/13 ●

General

Basic project website content

FLOSS license

Documentation

Other

Change Control 9/9 ●

Public version-controlled source repository

Unique version numbering

Release notes

[0.1.2] - 2026-01-30

Removed

Added

Changed

Notes

Reporting 8/8 ●

Bug-reporting process

Vulnerability report process

Quality 13/13 ●

Working build system

Automated test suite

New functionality testing

Warning flags

Security 16/16 ●

Secure development knowledge

Use basic good cryptographic practices

Secured delivery against man-in-the-middle (MITM) attacks

Publicly known vulnerabilities fixed

Other security issues

Analysis 8/8 ●

Static code analysis

Dynamic code analysis