Basis CLI

Miradi inayofuata mazoea bora hapa chini inaweza kujihakikisha kwa hiari na kuonyesha kuwa wamepata nishani ya mazoea bora ya Open Source Security Foundation (OpenSSF).

Hakuna seti ya mazoea yawezayo kuhakikisha kuwa programu haitakuwa na kasoro au udhaifu; hata mbinu rasmi zinaweza kushindwa ikiwa vipimo au dhana ni sahihi. Wala hakuna seti ya mazoea yawezayo kuhakikisha kuwa mradi utaendelea kuwa na jamii ya maendeleo yenye afya na inayofanya kazi vizuri. Hata hivyo, kufuata mazoea bora kunaweza kusaidia kuboresha matokeo ya miradi. Kwa mfano, baadhi ya mazoea huwezesha ukaguzi wa watu wengi kabla ya kutolewa, ambayo inaweza kusaidia kupata udhaifu wa kiufundi ambao vinginevyo ni vigumu kupata na kusaidia kujenga uaminifu na hamu ya mwingiliano wa kurudia kati ya wasanidi programu kutoka makampuni tofauti. Ili kupata nishani, vigezo vyote vya LAZIMA na LAZIMA WALA USIWAHI lazima vifuatwe, vigezo vyote vya INAPASWA lazima vifuatwe AU visivyo fufufutiliana na thibitisho, na vigezo vyote vya PENDEKEZA lazima vifuatwe AU visivyo fufufutiliana (tunataka vifikiwe angalau). Ikiwa unataka kuingiza maandishi ya thibitisho kama maoni ya jumla, badala ya kuwa maelezo ya busara kwamba hali ni inakubaliwa, anza kifungu cha maandishi na '//' ikifuatiwa na nafasi. Maoni ni karibu kupitia tovuti ya GitHub kama masuala au maombi ya kuvuta Kuna pia orodha ya barua pepe kwa majadiliano ya jumla.

Tunafuraha kutoa habari katika lugha nyingi, hata hivyo, ikiwa kuna mgongano au kutokuwa na usawa kati ya tafsiri, toleo la Kiingereza ni toleo lenye mamlaka.
Ikiwa huu ni mradi wako, tafadhali onyesha hadhi ya nishani yako kwenye ukurasa wa mradi wako! Hadhi ya nishani inaonekana kama hii: Kiwango cha nishani kwa mradi 14224 ni silver Hapa ni jinsi ya kuiweka:
Unaweza kuonyesha hali ya nishani yako kwa kuweka hii katika faili yako ya markdown:
[![OpenSSF Best Practices](https://www.bestpractices.dev/projects/14224/badge)](https://www.bestpractices.dev/projects/14224)
au kwa kuweka hii katika HTML yako:
<a href="https://www.bestpractices.dev/projects/14224"><img src="https://www.bestpractices.dev/projects/14224/badge"></a>


Hizi ni vigezo vya kiwango cha Dhahabu. Unaweza pia kuangalia vigezo vya kiwango cha Kupita au Fedha.

Baseline Series: Kiwango cha Msingi 1 Kiwango cha Msingi 2 Kiwango cha Msingi 3

        

 Misingi 4/5 ●

  • Jumla

    Kumbuka kwamba miradi mingine inaweza kutumia jina sawa.

    Basis CLI is the command-line client for Basis Network. This repository — and this badge entry — is what distributes and verifies it: the download script that checks every binary against a SHA-256 committed to git, the checksums themselves, the release workflow that verifies each published asset and then signs it with Sigstore in keyless mode, the test suite covering all of that, and the documentation. The compiled basis binary is built from basis-core, which is not public yet. Everything in this repository is Apache-2.0 with its source, and every file carries its copyright and licence, checked in CI against version 3.3 of the REUSE Specification.

    Tafadhali tumia muundo wa maneno ya leseni ya SPDX; mifano ni pamoja na "Apache-2.0", "BSD-2-Clause", "BSD-3-Clause", "GPL-2.0+", "LGPL-3.0+", "MIT", na "(BSD-2-Clause OR Ruby)". Usitumie alama za nukuu za moja au mbili.
    Ikiwa kuna lugha zaidi ya moja, ziorodhe kama thamani zilizotengwa kwa koma (nafasi ni za hiari) na ziorodhe kuanzia iliyotumiwa zaidi hadi iliyotumiwa kidogo. Ikiwa kuna orodha ndefu, tafadhali orodhesha angalau tatu za kawaida zaidi. Ikiwa hakuna lugha (k.m., huu ni mradi wa nyaraka tu au wa majaribio tu), tumia herufi moja "-". Tafadhali tumia herufi kubwa za kawaida kwa kila lugha, k.m., "JavaScript".
    Common Platform Enumeration (CPE) ni mpango wa kuweka majina yenye muundo kwa mifumo ya teknolojia ya habari, programu, na vifurushi. Inatumika katika mifumo na hifadhidata nyingi wakati wa kuripoti udhaifu.

  • Mahitaji ya awali


    Ya kutosha kwa nishani!

    Mradi LAZIMA ufikie kiwango cha nishani ya fedha. [achieve_silver]

  • Usimamizi wa mradi


    Ya kutosha kwa nishani!

    Mradi LAZIMA uwe na "bus factor" ya 2 au zaidi. (URL inahitajika) [bus_factor]
    "Bus factor" (pia inajulikana kama "truck factor") ni idadi ya chini ya washiriki wa mradi ambao wanapaswa kutoweka ghafla kutoka kwenye mradi ("kupigwa na basi") kabla ya mradi kusimama kwa sababu ya ukosefu wa wafanyakazi wenye elimu au wenye uwezo. Zana ya truck-factor inaweza kukadiria hii kwa miradi kwenye GitHub. Kwa maelezo zaidi, angalia Kutathmini Bus Factor ya Hifadhi za Git na Cosentino et al.

    Two. Both maintainers have identical repository and organisation access and either can release on their own, which is what the criterion measures. Being exact about what that buys is worth more than the number: it removes the single point of failure for access, for releases and for a vulnerability report going unread. It does not yet mean every change gets a second pair of eyes — that is two_person_review at gold level, and this project does not claim it. GOVERNANCE.md says both of those things in the same paragraph. https://github.com/basis-network/basis-cli/blob/main/GOVERNANCE.md#who-decides


    Si ya kutosha kwa nishani.

    Mradi LAZIMA uwe na angalau wachangiaji wawili wasiohusika. (URL inahitajika) [contributors_unassociated]
    Wachangiaji wanahusianishwa ikiwa wanalipwa kufanya kazi na shirika moja (kama mwajiriwa au mkandarasi) na shirika lile linapata faida kutokana na matokeo ya mradi. Misaada ya kifedha haihesabiwi kuwa kutoka shirika sawa ikiwa inapitia mashirika mengine (k.m., misaada ya sayansi inayolipwa kwa mashirika tofauti kutoka serikali ya kawaida au chanzo cha NGO haifanyi wachangiaji kuhusianishwa). Mtu ni mchangiaji muhimu ikiwa amefanya michango isiyojulikana kwa mradi katika mwaka uliopita. Mifano ya viashiria vizuri vya mchangiaji muhimu ni: ameandika angalau mistari 1,000 ya msimbo, amechangia commits 50, au amechangia angalau kurasa 20 za nyaraka.

    The criterion asks for two unassociated significant contributors, and defines significant as non-trivial contributions in the past year — its own examples are 1,000 lines of code, 50 commits, or 20 pages of documentation. This repository has one: sebastian-quintero-osorio, with 17 commits. The second maintainer holds equal access and is an owner of the organisation, which is what makes access_continuity and bus_factor true, but has not yet contributed code or documentation, so counting him here would be counting the wrong thing. The remaining commits are Dependabot's. This is answered Unmet rather than optimistically, because it is checkable in one request against https://api.github.com/repos/basis-network/basis-cli/contributors — and because the honest version is more useful to a reader than a claim that does not survive that check.


  • Mengine


    Ya kutosha kwa nishani!

    Mradi LAZIMA ujumuishe tamko la leseni katika kila faili ya chanzo. Hii YAWEZA kufanyika kwa kujumuisha yafuatayo ndani ya maoni karibu na mwanzo wa kila faili: SPDX-License-Identifier: [maneno ya leseni ya SPDX kwa mradi]. [license_per_file]
    Hii pia YAWEZA kufanyika kwa kujumuisha tamko katika lugha asilia ikitambulisha leseni. Mradi pia YAWEZA kujumuisha URL thabiti inayoelekeza kwenye maandishi ya leseni, au maandishi kamili ya leseni. Kumbuka kwamba kigezo cha license_location kinahitaji leseni ya mradi iwe mahali pa kawaida. Angalia mafunzo haya ya SPDX kwa maelezo zaidi kuhusu maneno ya leseni ya SPDX. Kumbuka uhusiano na copyright_per_file, ambayo yaliyomo yake kwa kawaida yangetangulia maelezo ya leseni.

    Same mechanism, same enforcement: every file carries SPDX-License-Identifier: Apache-2.0, inline where there is a comment syntax and through REUSE.toml where there is not. LICENSES/Apache-2.0.txt holds the licence text in the location REUSE expects. reuse lint reports the project as compliant and is a required check on main, so this cannot drift.


 Udhibiti wa Mabadiliko 3/4 ●

  • Hifadhi ya chanzo ya kudhibiti toleo ya hadharani


    Taarifa inayohitajika haijulikani, si ya kutosha kwa nishani.

    Hifadhi ya chanzo ya mradi LAZIMA itumie programu ya kawaida ya kudhibiti toleo linalosambazwa (k.m., git au mercurial). [repo_distributed]
    Git haihitajiki kihususa na miradi inaweza kutumia programu ya udhibiti wa toleo iliyokusanyika (kama subversion) na sababu.

    git.

    Onyo: Inahitaji sababu ndefu zaidi.


    Ya kutosha kwa nishani!

    Mradi LAZIMA utambulishe kazi ndogo ambazo zinaweza kufanywa na wachangiaji wapya au wa mara kwa mara. (URL inahitajika) [small_tasks]
    Utambulisho huu kwa kawaida unafanyika kwa kuweka alama masuala yaliyochaguliwa katika kifuatiliaji cha masuala kwa lebo moja au zaidi ambazo mradi unatumia kwa madhumuni hayo, k.m., up-for-grabs, first-timers-only, "Marekebisho madogo", microtask, au IdealFirstBug. Kazi hizi mpya hazihitaji kujumuisha kuongeza utendaji; zinaweza kuwa kuboresha nyaraka, kuongeza hali za majaribio, au chochote kingine kinachosaidia mradi na kusaidia mchangiaji kuelewa zaidi kuhusu mradi.

    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


    Ya kutosha kwa nishani!

    Mradi LAZIMA uhitaji uthibitishaji wa mambo mawili (2FA) kwa wasanidi programu ili kubadilisha hifadhi ya kati au kupata data nyeti (kama ripoti za faragha za udhaifu). Utaratibu huu wa 2FA YAWEZA kutumia taratibu bila taratibu za usimbuaji kama SMS, ingawa hii hairuhusiwi. [require_2FA]

    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.


    Kwa shida ya kutosha kwa nishani.

    Uthibitishaji wa mambo mawili (2FA) ya mradi INAPASWA kutumia taratibu za usimbuaji ili kuzuia ujigeuzi. Uthibitishaji wa 2FA unaotegemea Huduma ya Ujumbe Mfupi (SMS), peke yake, HAUKIDHI kigezo hiki, kwa kuwa haufichui. [secure_2FA]
    Utaratibu wa 2FA unaokidhi kigezo hiki unaweza kuwa programu ya Nywila ya Mara Moja Inayotegemea Muda (TOTP) ambayo inazalisha kiotomatiki msimbo wa uthibitishaji unaobadilika baada ya muda fulani. Kumbuka kwamba GitHub inasaidia TOTP.

    The organisation requires 2FA but does not currently restrict which second factor a member may use, and GitHub still permits SMS as one option. Since the criterion asks specifically for cryptographic mechanisms, and it cannot be asserted from the outside which factor each maintainer has enrolled, the honest answer today is Unmet rather than a claim that happens to be probable. The fix is small and is on the list: both maintainers enrolling a security key or TOTP and dropping SMS, after which this becomes Met with no further work.


 Ubora 6/7 ●

  • Viwango vya msimbo


    Ya kutosha kwa nishani!

    Mradi LAZIMA uandike mahitaji yake ya kukagua msimbo, pamoja na jinsi ukaguzi wa nambari unafanywa, nini lazima ichunguzwe, na nini kinachohitajika ili ikubalike. (URL inahitajika) [code_review_standards]
    Angalia pia two_person_review na contribution_requirements.

    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


    Si ya kutosha kwa nishani.

    Mradi LAZIMA uwe na angalau 50% ya marekebisho yote yaliyopendekezwa kupitishwa kabla ya kutolewa na mtu mwingine isipokuwa mwandishi, ili kuamua ikiwa ni marekebisho ya manufaa na huru ya masuala yaliyojulikana ambayo yangepingana na ujumuishaji wake [two_person_review]

    The criterion asks that at least 50% of proposed modifications be reviewed before release by someone other than their author. Of the human pull requests merged here so far, none has an approving review by a second person: the author merged them once the required CI checks passed. The project does not hide this — GOVERNANCE.md states that with two people, requiring each to review the other would stall the project the first time either is away, so a second review happens when it can rather than being promised and skipped; CONTRIBUTING.md's review section says the same; and the assurance case names single-maintainer review as the project's dominant residual risk. It becomes Met when the second maintainer reviews and approves changes until more than half of proposed modifications carry an author-independent review, which is a change in practice rather than in configuration. https://github.com/basis-network/basis-cli/blob/main/docs/ASSURANCE-CASE.md


  • Mfumo wa ujenzi unaofanya kazi


    Ya kutosha kwa nishani!

    Mradi LAZIMA uwe na ujenzi unaorudiwa. Ikiwa hakuna ujenzi unaofanyika (k.m., lugha za uandishi ambapo msimbo wa chanzo unatumika moja kwa moja badala ya kukusanywa), chagua "haihusiki" (N/A). (URL inahitajika) [build_reproducible]
    Ujenzi unaorudiwa unamaanisha kwamba pande nyingi zinaweza kwa uhuru kurudia mchakato wa kuzalisha taarifa kutoka faili za chanzo na kupata matokeo sawa ya biti-kwa-biti. Katika hali fulani, hii inaweza kutatuliwa kwa kulazimisha mpangilio fulani wa aina. Wasanidi wa JavaScript wanaweza kuzingatia kutumia npm shrinkwrap na webpack OccurrenceOrderPlugin. Watumiaji wa GCC na clang wanaweza kupata chaguo la -frandom-seed kuwa na manufaa. Mazingira ya ujenzi (ikijumuisha zana) kwa kawaida yanaweza kufafanuliwa kwa pande za nje kwa kubainisha hash ya usimbuaji ya chombo maalum au mashine ya kawaida ambayo wanaweza kutumia kwa kujenga upya. Mradi wa majengo yanayorudiwa una nyaraka za jinsi ya kufanya hivi.

    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.


  • Seti ya majaribio otomatiki


    Ya kutosha kwa nishani!

    Seti ya majaribio LAZIMA iweze kuitwa kwa njia ya kawaida kwa lugha hiyo. (URL inahitajika) [test_invocation]
    Kwa mfano, "make check", "mvn test", au "rake test" (Ruby).

    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


    Ya kutosha kwa nishani!

    Mradi LAZIMA utekeleze ujumuishaji wa kuendelea, ambapo msimbo mpya au uliobadilishwa unajumuishwa mara kwa mara katika hifadhi ya msimbo ya kati na majaribio ya kiotomatiki yanafanywa kwenye matokeo. (URL inahitajika) [test_continuous_integration]
    Katika hali nyingi hii inamaanisha kwamba kila msanidi programu anayefanya kazi kikamilifu kwenye mradi anajumuisha angalau kila siku.

    .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


    Ya kutosha kwa nishani!

    Mradi LAZIMA uwe na seti ya majaribio ya kiotomatiki ya FLOSS ambayo inatoa angalau 90% ya ufikio wa tamko ikiwa kuna angalau zana moja ya FLOSS ambayo inaweza kupima kigezo hiki katika lugha iliyochaguliwa. [test_statement_coverage90]

    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.


    Ya kutosha kwa nishani!

    Mradi LAZIMA uwe na seti ya jaribio zilizofanywa kiotomatiki za FLOSS ambazo zinatoa angalau asilimia 80 ya uangaliaji wa tawi ikiwa kuna angalau zana moja ya FLOSS inayoweza kupima kigezo hiki katika lugha iliyochaguliwa. [test_branch_coverage80]

    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.


 Usalama 4/5 ●

  • Tumia mazoea mazuri ya msingi ya usimbuaji

    Kumbuka kwamba programu fulani haihitaji kutumia taratibu za usimbuaji. Ikiwa mradi wako unazalisha programu ambayo (1) inajumuisha, inaamilisha, au inafanya usimbuaji kuwa hai, na (2) inaweza kutolewa kutoka Marekani (US) kwenda nje ya Marekani au kwa raia asiye wa Marekani, inaweza kuwa ni lazima kisheria kuchukua hatua chache za ziada. Kawaida hii inahusisha tu kutuma barua pepe. Kwa maelezo zaidi, tazama sehemu ya usimbuaji ya Kuelewa Teknolojia ya Chanzo Wazi & Udhibiti wa Usafirishaji wa Marekani.

    Ya kutosha kwa nishani!

    Programu iliyozalishwa na mradi LAZIMA isaidie itifaki salama kwa mawasiliano yake yote ya mtandao, kama vile SSHv2 au zaidi, TLS1.2 au zaidi (HTTPS), IPsec, SFTP, na SNMPv3. Itifaki zisizo salama kama vile FTP, HTTP, telnet, SSLv3 au mapema zaidi, na SSHv1 LAZIMA zizimwe kwa chaguo-msingi, na kuzimwa tu ikiwa mtumiaji anaisanidi mahususi. Ikiwa programu iliyozalishwa na mradi haiesaidii mawasiliano ya mtandao, chagua "haihusiki" (N/A). [crypto_used_network]

    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.


    Ya kutosha kwa nishani!

    Programu iliyozalishwa na mradi LAZIMA, ikiwa inasaidia au inatumia TLS, isaidie angalau toleo la TLS 1.2. Kumbuka kwamba kabla ya TLS kuitwa SSL. Ikiwa programu haitumii TLS, chagua "haihusiki" (N/A). [crypto_tls12]

    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.


  • Utoaji salama dhidi ya mashambulizi ya mtu-katikati (MITM)


    Ya kutosha kwa nishani!

    Tovuti ya mradi, hifadhi (ikiwa inapatikana kupitia wavuti), na tovuti ya kupakua (ikiwa ni tofauti) LAZIMA ijumuishe vichwa muhimu vya kuimarisha na thamani zisizo na ruhusa. (URL inahitajika) [hardened_site]
    Kumbuka kwamba GitHub na GitLab zinajulikana kukidhi hii. Tovuti kama vile https://securityheaders.com/ zinaweza kuangalia hii haraka. Vichwa muhimu vya kuimarisha ni: Sera ya Usalama wa Maudhui (CSP), Usalama wa Usafiri wa HTTP Mkali (HSTS), X-Content-Type-Options (kama "nosniff"), na X-Frame-Options. Tovuti za wavuti zilizo za tuli kabisa bila uwezo wa kuingia kupitia kurasa za wavuti zinaweza kuacha baadhi ya vichwa vya kuimarisha na hatari ndogo, lakini hakuna njia ya kuaminika ya kugundua tovuti kama hizo, kwa hivyo tunahitaji vichwa hivi hata kama ni tovuti za tuli kabisa.

    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.


  • Masuala mengine ya usalama


    Ya kutosha kwa nishani!

    Mradi LAZIMA uwe umefanya ukaguzi wa usalama ndani ya miaka 5 iliyopita. Ukaguzi huu LAZIMA uzingatie mahitaji ya usalama na mpaka wa usalama. [security_review]
    Hii YAWEZA kufanywa na wanachama wa mradi na/au tathmini huru. Tathmini hii YAWEZA kusaidiwa na zana za uchambuzi za tuli na zenye nguvu, lakini lazima pia kuwe na ukaguzi wa binadamu ili kutambua matatizo (hasa katika muundo) ambayo zana haziwezi kugundua.

    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


    Taarifa inayohitajika haijulikani, si ya kutosha kwa nishani.

    Taratibu za kuimarisha LAZIMA zitumike katika programu iliyozalishwa na mradi ili kasoro za programu ziwe na uwezekano mdogo wa kusababisha udhaifu wa usalama. (URL inahitajika) [hardening]
    Taratibu za kuimarisha zinaweza kujumuisha vichwa vya HTTP kama Sera ya Usalama wa Maudhui (CSP), bendera za mkusanyaji ili kupunguza mashambulizi (kama vile -fstack-protector), au bendera za mkusanyaji ili kuondoa tabia isiyofafanuliwa. Kwa madhumuni yetu upendeleo mdogo hauhesabiwi kuwa utaratibu wa kuimarisha (upendeleo mdogo ni muhimu, lakini tofauti).

    The hardening available to a shell script is applied. set -euo pipefail is the first executable line: an unset variable, a failing command or a failing pipeline stage aborts rather than continuing with a wrong value — the failure mode that turns a shell defect into a security problem. Every expansion is quoted and shellcheck enforces it in CI as a required check. The script asks for no privilege and writes only under its own bin/ directory, touching no system location. On the CI side, which is the part of this project with credentials: permissions: read-all at workflow level with elevation per job only where genuinely needed, persist-credentials: false on every checkout, and every action pinned to a commit SHA rather than a mutable tag. The project sites are GitHub, which serves Content-Security-Policy, HSTS, X-Content-Type-Options and X-Frame-Options.

    Onyo: URL inahitajika, lakini hakuna URL iliyopatikana.


 Uchanganuzi 1/2 ●

  • Uchambuzi wa msimbo wa nguvu za ziada


    Si ya kutosha kwa nishani.

    Mradi LAZIMA utumie angalau zana moja ya uchambuzi wenye nguvu kwa toleo lolote lililopendekezwa kuu la uzalishaji wa programu iliyozalishwa na mradi kabla ya kutolewa kwake. [dynamic_analysis]
    Zana ya uchambuzi wa nguvu inachunguza programu kwa kuitekeleza na ingizo maalum. Kwa mfano, mradi YAWEZA kutumia zana ya fuzzing (k.m., American Fuzzy Lop) au kitafutaji cha programu ya wavuti (k.m., OWASP ZAP au w3af). Katika hali fulani mradi wa OSS-Fuzz unaweza kuwa tayari kutumia majaribio ya fuzz kwenye mradi wako. Kwa madhumuni ya kigezo hiki zana ya uchambuzi wa nguvu inahitaji kubadilisha ingizo kwa njia fulani kutafuta aina mbalimbali za matatizo au kuwa seti kiotomatiki ya majaribio yenye angalau asilimia 80 ya ukaguzi wa tawi. Ukurasa wa Wikipedia kuhusu uchambuzi wa nguvu na ukurasa wa OWASP kuhusu fuzzing hutambulisha baadhi ya zana za uchambuzi wa nguvu. Zana za uchambuzi ZINAWEZA kuzingatia kutafuta udhaifu wa usalama, lakini hii haihitajiki.

    No fuzzer or scanner is run. The test suite does execute download.sh with varied inputs, two of them adversarial, but it does not generate inputs and we do not measure branch coverage, so claiming it as dynamic analysis would be a stretch. There is also little surface to point a tool at: download.sh runs on the user's machine, takes one argument and three environment variables, and there is no service here to scan.


    Kwa shida ya kutosha kwa nishani.

    Mradi INAPASWA kujumuisha madai mengi ya muda wa kutekeleza katika programu inayozalisha na kuangalia madai hayo wakati wa uchambuzi wenye nguvu. [dynamic_analysis_enable_assertions]
    Kigezo hiki hakipendekezi kuwezesha madai wakati wa uzalishaji; hilo ni kabisa kwa mradi na watumiaji wake kuamua. Lengo la kigezo hiki ni badala yake kuboresha ugunduzaji wa hitilafu wakati wa uchambuzi wa nguvu kabla ya kusambazwa. Kuwezesha madai katika matumizi ya uzalishaji ni tofauti kabisa na kuwezesha madai wakati wa uchambuzi wa nguvu (kama vile majaribio). Katika hali fulani kuwezesha madai katika matumizi ya uzalishaji ni busara sana (hasa katika vipengele vya uadilifu wa juu). Kuna hoja nyingi dhidi ya kuwezesha madai katika uzalishaji, k.m., maktaba hazipaswi kuvuruga waita, uwepo wao unaweza kusababisha kukataliwa na maduka ya programu, na/au kuamilisha madai katika uzalishaji kunaweza kufunua data za faragha kama vile funguo za faragha. Kumbuka kwamba katika usambazaji mwingi wa Linux NDEBUG haijafafanuliwa, hivyo C/C++ assert() kwa chaguo-msingi itawezeshwa kwa uzalishaji katika mazingira hayo. Inaweza kuwa muhimu kutumia utaratibu tofauti wa madai au kufafanua NDEBUG kwa uzalishaji katika mazingira hayo.

    bash has no assertion mechanism to enable. Both scripts run under set -u, and the script under test under set -euo pipefail, which is the nearest equivalent the language offers, but calling that "many assertions" would be generous.



Unaweza kutumia zana na mifumo ya AI kupendekeza mabadiliko kupitia URL rahisi, kama vile https://www.bestpractices.dev/sw/projects/14224/choose/edit?osps_ac_01_01_status=Met&osps_ac_01_01_justification=GitHub+enforced. Angalia mfumo wetu wa mapendekezo ya otomatiki kwa jinsi ya kufanya hivyo. Data hii inapatikana chini ya Community Data License Agreement – Permissive, Version 2.0 (CDLA-Permissive-2.0). Hii inamaanisha kuwa Mpokeaji wa Data anaweza kushiriki Data, na au bila marekebisho, mradi Mpokeaji wa Data anapatanisha maandishi ya mkataba huu na Data iliyoshirikiwa. Tafadhali tambua Sebastian na wachangiaji wa nishani ya Mazoea Bora ya OpenSSF.

Ingizo la nishani ya mradi linamilikiwa na: Sebastian.
Ingizo liliundwa siku 2026-08-24 15:57:55 UTC, iliyosasishwa mara ya mwisho siku 2026-08-26 02:10:48 UTC. Ilipata mara ya mwisho nishani ya kupita siku 2026-08-24 16:56:42 UTC.