tfw

TFW's GitHub organization requires two-factor authentication for all organization members and outside collaborators. Access to the authoritative TFW repository therefore requires MFA. The organization enforces this requirement through GitHub's organization-level two-factor authentication policy.

New collaborators are added through GitHub repository permissions, with repository access explicitly granted by a project maintainer. GitHub requires the maintainer to select the collaborator's repository role when granting access, and access is limited to the minimum permissions necessary for the collaborator's responsibilities.

The project's primary branch (master) is protected using GitHub branch protection. The OpenSSF Scorecard Branch-Protection check verifies that the primary branch is protected. This protection prevents direct changes from being applied to the primary branch and requires changes to follow the protected branch workflow.

The project's primary branch (master) is protected using GitHub branch protection. The OpenSSF Scorecard Branch-Protection check verifies that the primary branch is protected against deletion. As a result, attempts to delete the primary branch are blocked by the version control system rather than being silently applied.

TFW's GitHub Actions workflows do not directly interpolate untrusted GitHub metadata into shell commands. Where workflow metadata is used by scripts, it is passed through environment variables or action inputs and handled as data rather than executable shell content. The project's workflows are also checked with zizmor for GitHub Actions security issues, and the current workflows use pinned action commits.

TFW separates untrusted pull-request code from privileged CI/CD operations. PR workflows run with read-only permissions and do not retain checkout credentials. Pitest results are passed as an artifact to a separate trusted workflow_run workflow, which performs the privileged PR update without checking out or executing PR code. This separation has been validated through successful PR, Dependabot, security scanning, and Pitest runs.

TFW's official project channels use HTTPS exclusively. The authoritative GitHub repository, documentation, issues, pull requests, and other project links are accessed through HTTPS URLs. The project does not identify unencrypted HTTP URLs as official project channels. TFW relies on the security controls provided by GitHub rather than operating the project-channel infrastructure itself.

TFW distributes its source and release information through GitHub and its Java artifacts through Maven Central. The project's official GitHub repository and release URLs use HTTPS, providing an encrypted and authenticated connection to GitHub. Published Maven artifacts are distributed through Maven Central over its authenticated HTTPS service. TFW relies on the security controls provided by these established hosting and distribution platforms rather than operating the distribution infrastructure itself.

TFW uses GitHub's Secret Protection and Push Protection for the public TFW repository. Secret Protection provides secret scanning, while Push Protection helps prevent detected secrets from being committed to the repository. The project also keeps credentials and authentication tokens out of source code and uses GitHub's protected secret mechanisms for CI/CD credentials.

TFW provides a public defect-reporting mechanism through GitHub Issues in the authoritative TFW repository. Users can report defects, provide supporting information, and discuss the issue with project maintainers through the public issue tracker.

GitHub supports public discussions on proposed changes (via pull requests) and usage obstacles (via issues).

TFW documents its contribution process in CONTRIBUTING.md. The guide explains when contributors should discuss changes in an issue, when they may proceed directly to a pull request, development and testing requirements, pull-request expectations, code-quality requirements, security reporting, commit messages, and the review process.

The MIT license for the repository contents is approved by the Open Source Initiative (OSI).

TFW releases its Java artifacts under the MIT License, the same OSI-approved license used for the project's source code. The released artifacts are published to Maven Central from the TFW project, and the project documentation identifies the MIT License as the license governing the software.

License file found in repository.

TFW is released under the MIT License. The authoritative license file is maintained in the repository at https://github.com/tfw-org/tfw/blob/master/LICENSE.md. The released main JAR also includes the same LICENSE.md file, so the license accompanies the released software artifact.

Repository is publicly available on GitHub.

Repository git metadata is publicly available on GitHub.

The project uses Maven for dependency management and the source repository contains a pom.xml that explicitly declares its direct Java dependencies. GitHub's Dependency Graph successfully parses this manifest and identifies the project's direct dependencies separately from transitive dependencies. The project also configures the CycloneDX Maven plugin to generate SBOMs, and the released artifacts include the SBOM in both JSON and XML formats. Together, the Maven POM, GitHub Dependency Graph, and published SBOM provide a machine-readable dependency inventory accounting for the project's direct language dependencies.

The TFW project has two repositories, documented in the README. "tfw" contains the TFW framework and release code. "tfw-fuzzing" contains only ClusterFuzzLite fuzzing corpus data and does not contain source code or components used to build TFW.

OpenSSF Scorecard v5.5.0 reports Binary-Artifacts = 10/10 for github.com/tfw-org/tfw, indicating that no generated executable/binary artifacts are present in the source repository. The repository also excludes Maven build output (target/) and compiled Java class files (*.class) through .gitignore. Generated release artifacts are instead produced by the build and published separately to Maven Central. Therefore, the active version-control repository does not contain generated executable artifacts.

The active TFW source repository does not contain unreviewable binary artifacts. TFW is maintained as a Java/Maven source repository, with the source code and Maven build configuration stored in version control and generated build artifacts excluded (target/ and *.class). Generated release artifacts are produced by the build and published separately to Maven Central rather than committed to the source repository. The OpenSSF Scorecard v5.5.0 report for TFW also gives the Binary-Artifacts check a score of 10/10, providing independent evidence that the source repository does not contain generated binary artifacts. Therefore, the active version-control repository does not contain binary artifacts that would prevent meaningful source review.

The project documentation contains a dedicated SECURITY.md file that identifies the project's security contact. The file identifies @jdcove2 as the TFW project maintainer and provides instructions for privately reporting security vulnerabilities through GitHub's private vulnerability reporting mechanism.
Evidence: https://github.com/tfw-org/tfw/blob/master/SECURITY.md