Basis CLI

Two ways in, both real. CONTRIBUTING.md has a "Good first tasks" section listing five kinds of contribution sized for someone new — covering a statement make coverage reports as missed, trying the script on a platform the project does not have, correcting documentation, improving an error message, and independently checking a published checksum by hand. And there are open issues labelled good first issue, each one a genuine defect or gap rather than invented busywork: download.sh not checking for curl before using it, testing the macOS shasum fallback on an actual Mac, documenting the three BASIS_CLI_* environment variables, and a test case for a checksum file with CRLF line endings. Each issue says what the task is, why it matters, and which file to start in. https://github.com/basis-network/basis-cli/issues?q=is%3Aissue+is%3Aopen+label%3A%22good+first+issue%22

Two-factor authentication is required for every member of the basis-network GitHub organisation, enforced by the organisation setting rather than by asking people nicely — a member without 2FA is removed from the organisation by GitHub, so it cannot quietly lapse. That covers both things the criterion names, because both go through the same account: write access to this repository, and the private security advisory queue where vulnerability reports arrive. It is publicly verifiable: https://api.github.com/orgs/basis-network reports "two_factor_requirement_enabled": true.

CONTRIBUTING.md has a "How changes are reviewed" section stating how review is conducted and what must be checked, in order: is it correct and does the suite still pass; does it change behaviour without a test, which is a blocking comment; does it weaken a refusal, in which case it is read line by line against the assurance case and "looks fine" is explicitly not an acceptable review; do workflow changes keep least-privilege permissions and SHA-pinned actions; does every new file carry its SPDX header, decided by reuse lint rather than by opinion; and is the documentation still true afterwards. It also states the acceptance condition — all CI checks passing plus approval from a maintainer other than the author — and then states plainly that with one active maintainer this is not always possible today, rather than describing a process the project does not follow. https://github.com/basis-network/basis-cli/blob/main/CONTRIBUTING.md#how-changes-are-reviewed

No building occurs. This is a scripting-language project: download.sh and the test suite are read by the interpreter as they are, and the Makefile has no build target — only check, coverage and lint. There is no generated artefact whose bit-for-bit reproduction could be compared. Reproducibility of the compiled basis binary is a property of basis-core, which is not public and is outside this entry's declared scope; the assurance case lists the Windows build's missing provenance as a known gap rather than claiming otherwise.

make check. Shell has no de facto standard test runner, so the Makefile provides the conventional entry point; test/run.sh also runs directly, and make lint is its counterpart for shellcheck and reuse. https://github.com/basis-network/basis-cli/blob/main/Makefile

.github/workflows/test.yml runs make check on every push to main and every pull request, alongside shellcheck, reuse lint, a checksum-format check and CodeQL. All five are required status checks on main, so nothing merges without them. https://github.com/basis-network/basis-cli/actions/workflows/test.yml

98.1% statement coverage of download.sh, 52 of 53 statements, measured with bashcov rather than estimated. make coverage produces the figure and CI runs it as its own job on every push and every pull request, failing below a hard floor of 90%. The single statement reported uncovered is the done that carries the download loop's redirection, which bash attributes to the while; every case that downloads anything executes it. It is left in the report rather than special-cased, because a coverage tool taught to lie about one line stops being evidence about the others.

There is no FLOSS tool that measures branch coverage for shell, which is the condition the criterion attaches. The two coverage tools that work on bash — bashcov and kcov — both measure statements only; bashcov's branch-coverage support comes from SimpleCov and applies to Ruby, not to the bash it traces. Statement coverage is measured and enforced instead, at 98.1% against a 90% floor. If a branch-coverage tool for shell appears, adding it is on the roadmap and would go into CI the same way.

All network communication is HTTPS. download.sh fetches from https://github.com/<repo>/releases/download by default, and curl verifies the certificate chain by default with no flag anywhere in this project disabling it — there is no --insecure, no -k and no GIT_SSL_NO_VERIFY-style escape hatch. The base URL can be overridden by BASIS_CLI_BASE_URL, which exists so the test suite can point at a local directory over file:// without touching the network; that is an explicit action by the user, which is exactly the condition the criterion allows. Nothing insecure is enabled by default and no plaintext protocol is used at all.

TLS is used through the system's curl and its TLS library, so the project supports whatever they do, which on any currently supported platform is TLS 1.2 and 1.3. The script pins no version, disables nothing and offers no option to downgrade, so a system hardened to 1.2-or-better stays that way. GitHub, the only host contacted by default, requires TLS 1.2 as a minimum on its side.

The project's website, repository and download site are all GitHub — the entry's homepage URL is the repository itself, and releases are served from the same host — and GitHub serves all four key hardening headers with non-permissive values. Verified directly rather than assumed: content-security-policy: default-src 'none'; base-uri 'self'; ..., strict-transport-security: max-age=31536000; includeSubdomains; preload, x-content-type-options: nosniff, and x-frame-options: deny. Anyone can reproduce that with curl -I https://github.com/basis-network/basis-cli.

A security review was performed on 2026-08-24 and is recorded in docs/ASSURANCE-CASE.md section 7, which states what it consisted of rather than just that it happened. It considered both things the criterion requires: the security requirements, which are stated in SECURITY.md as five guarantees and four explicit non-guarantees, and the security boundary, which is the four trust regions in the assurance case. The threat model was re-derived from the current code rather than inherited; all nine test cases were read against the claims they are cited for; coverage was measured rather than assumed; and every workflow was re-read for permission scope and action pinning. Tool support came from shellcheck, CodeQL over the workflows, OpenSSF Scorecard and the suite itself, but the two findings — single-maintainer review as the dominant residual risk, and the Windows build's missing provenance — came from human reading, which is what the criterion's details ask for. Both are written down as limits rather than resolved on paper. https://github.com/basis-network/basis-cli/blob/main/docs/ASSURANCE-CASE.md