Vectis

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 14194 ni in_progress 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/14194/badge)](https://www.bestpractices.dev/projects/14194)
au kwa kuweka hii katika HTML yako:
<a href="https://www.bestpractices.dev/projects/14194"><img src="https://www.bestpractices.dev/projects/14194/badge"></a>


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

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

        

 Misingi 12/13 ●

  • Jumla

    Kumbuka kwamba miradi mingine inaweza kutumia jina sawa.

    Open-source cryptographic data protection toolkit for sensitive data workflows.

    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.

    Vectis is an experimental open source cryptographic data protection toolkit under active development. It provides profile-driven hybrid cryptography,
    format-preserving encryption, tokenization, masking, MACs, blind indexes, commitments, secret sharing, protected messaging, and verifiable audit records.

    The project emphasizes bounded input validation, signed configuration, encrypted application-level storage, explicit trust boundaries, key lifecycle
    enforcement, negative testing, property-based testing, Schemathesis, native fuzzing, dependency auditing, CodeQL, and reproducible release workflows.

    Vectis v0.8.5 completed a source-backed security self-assessment with no Critical or High severity vulnerabilities identified. This was not an
    independent external security audit, certification, or compliance assessment. Vectis should currently be used for evaluation, testing, demos, and
    design-partner proofs of concept rather than as the sole protection layer for
    production sensitive data.

    Project scope, accepted risks, and operational assumptions are documented publicly in the threat model and security documentation.

  • Maudhui ya kimsingi ya tovuti ya mradi


    Ya kutosha kwa nishani!

    Tovuti ya mradi LAZIMA ieleze kwa ufupi programu inafanya nini (inasuluhu tatizo gani?). [description_good]
    Hii LAZIMA iwe katika lugha ambayo watumiaji watarajiwa wanaweza kuelewa (k.m., inatumia lugha ya kiufundi kidogo).

    Vectis is an open-source advanced data protection toolkit.

    TLS protects the connection, but sensitive data keeps moving in plaintext afterward — through logs, queues, databases, and internal APIs. Vectis protects the data itself.

    Sensitive input in. Protected representation out

    Vectis protects and transforms sensitive values through a consistent HTTP API and CLI. Operator-signed profiles define the allowed operations, algorithms, keys, permissions, and lifecycle policy.


    Ya kutosha kwa nishani!

    Tovuti ya mradi LAZIMA itoe habari juu ya jinsi ya: kupata, kutoa maoni (kama ripoti za hitilafu au maboresho), na kuchangia kwenye programu. [interact]

    Security: https://github.com/liesware/Vectis/blob/main/SECURITY.md
    Contributing: https://github.com/liesware/Vectis/blob/main/CONTRIBUTING.md


    Ya kutosha kwa nishani!

    Habari juu ya jinsi ya kuchangia LAZIMA ieleze mchakato wa uchangiaji (kwa mfano, je! Maombi ya kuvuta yanatumika?) (URL inahitajika) [contribution]
    Tunafikiria kuwa miradi kwenye GitHub hutumia maswala na kuvuta maombi isipokuwa palipoonyeshwa vingine. Habari hii inaweza kuwa fupi, kwa mfano, ikisema kuwa mradi hutumia maombi ya kuvuta, msako wa suala, au machapisho kwenye orodha ya barua (ipi?)

    Non-trivial contribution file in repository: https://github.com/liesware/Vectis/blob/main/CONTRIBUTING.md.


    Taarifa inayohitajika haijulikani, si ya kutosha kwa nishani.

    Habari juu ya jinsi ya kuchangia INAPASWA kujumuisha mahitaji ya michango inayokubalika (k.m., rejeleo la kiwango chochote kinachohitajika cha usimbaji). (URL inahitajika) [contribution_requirements]

  • Leseni ya FLOSS


    Ya kutosha kwa nishani!

    Programu iliyozalishwa na mradi LAZIMA itolewa kama FLOSS. [floss_license]
    FLOSS ni programu iliyotolewa kwa njia inayokidhi Ufafanuzi wa Chanzo Wazi au Ufafanuzi wa Programu Huria. Mifano ya leseni kama hizo ni pamoja na CC0, MIT, BSD 2-clause, BSD 3-clause revised, Apache 2.0, Lesser GNU General Public License (LGPL), na GNU General Public License (GPL). Kwa madhumuni yetu, hii inamaanisha kuwa leseni LAZIMA iwe: Programu YAWEZA pia kupatiwa leseni kwa njia nyingine (k.m., "GPLv2 au ya kibinafsi" inakubaliwa).

    The Apache-2.0 license is approved by the Open Source Initiative (OSI).


    Ya kutosha kwa nishani!

    INAPENDEKEZA kwamba leseni yoyote inayohitajika kwa programu iliyozalishwa na mradi iwe imeidhinishwa na Open Source Initiative (OSI). [floss_license_osi]
    OSI inatumia mchakato mgumu wa uidhinishaji kuamua ni leseni zipi ni OSS.

    The Apache-2.0 license is approved by the Open Source Initiative (OSI).


    Ya kutosha kwa nishani!

    Mradi LAZIMA uweke leseni za matokeo yake mahali pa kawaida katika hazina yake ya chanzo. (URL inahitajika) [license_location]
    Desturi moja ni kuweka leseni kama faili ya ngazi ya juu inayoitwa LICENSE au COPYING, ambayo YAWEZA kufuatiwa na kiendelezi kama ".txt" au ".md". Desturi mbadala ni kuwa na saraka inayoitwa LICENSES inayohifadhi faili za leseni; faili hizi kwa kawaida zinaitwa kama kitambulisho chao cha leseni ya SPDX kikifuatiwa na kiendelezi kinachofaa, kama ilivyoelezwa katika Maelezo ya REUSE. Kumbuka kwamba kigezo hiki ni mahitaji tu kwenye hazina ya chanzo. Huhitaji kuingiza faili ya leseni wakati wa kuzalisha kitu kutoka kwenye msimbo wa chanzo (kama programu inayotekelezeka, kifurushi, au chombo). Kwa mfano, wakati wa kuzalisha kifurushi cha R kwa Mtandao wa Kumbukumbu Kamili wa R (CRAN), fuata mazoea ya kawaida ya CRAN: ikiwa leseni ni leseni ya kawaida, tumia maelezo mafupi ya kawaida ya leseni (ili kuepuka kusakinisha nakala nyingine ya maandishi) na orodhesha faili ya LICENSE katika faili ya kutengwa kama .Rbuildignore. Vivyo hivyo, wakati wa kuunda kifurushi cha Debian, unaweza kuweka kiungo katika faili ya hakimiliki kwa maandishi ya leseni katika /usr/share/common-licenses, na utenge faili ya leseni kutoka kwenye kifurushi kilichoundwa (k.m., kwa kufuta faili baada ya kuita dh_auto_install). Tunashauri jumuisha maelezo ya leseni yanayoweza kusomwa na mashine katika miundo iliyozalishwa mahali inapofaa.

    Non-trivial license location file in repository: https://github.com/liesware/Vectis/blob/main/LICENSE.


  • Nyaraka


    Ya kutosha kwa nishani!

    Mradi LAZIMA utoe nyaraka za msingi za programu iliyozalishwa na mradi. [documentation_basics]
    Nyaraka hizi lazima ziwe katika vyombo fulani (kama maandishi au video) vinavyojumuisha: jinsi ya kuisakinisha, jinsi ya kuianzisha, jinsi ya kuitumia (huenda ikijumuisha mafunzo kwa kutumia mifano), na jinsi ya kuitumia kwa usalama (k.m., nini cha kufanya na nini cha kutofanya) ikiwa hiyo ni mada inayofaa kwa programu. Nyaraka za usalama lazima zisiwe ndefu. Mradi YAWEZA kutumia viungo vya hypertext kwa nyenzo zisizo za mradi kama nyaraka. Ikiwa mradi hauzalishi programu, chagua "haihusiki" (N/A).

    Vectis provides basic documentation in its README, including its purpose,
    current capabilities, scope, installation and Quick Start instructions,
    configuration overview, CLI and API entry points, testing, and security status.

    README:
    https://github.com/liesware/Vectis#readme

    Quick Start:
    https://github.com/liesware/Vectis#quick-start

    Detailed documentation:
    https://github.com/liesware/Vectis/tree/main/doc


    Ya kutosha kwa nishani!

    Mradi LAZIMA utoe nyaraka za marejeleo zinazofafanua kiolesura cha nje (ingizo na matokeo) cha programu iliyozalishwa na mradi. [documentation_interface]
    Nyaraka za kiolesura cha nje zinaeleza kwa mtumiaji wa mwisho au msanidi jinsi ya kuitumia. Hii itajumuisha kiolesura chake cha programu ya programu (API) ikiwa programu ina. Ikiwa ni maktaba, andika madarasa/aina kuu na mbinu/vitendakazi vinavyoweza kuitwa. Ikiwa ni programu ya wavuti, fafanua kiolesura chake cha URL (mara nyingi kiolesura chake cha REST). Ikiwa ni kiolesura cha mstari wa amri, andika vigezo na chaguo zinazosaidia. Katika hali nyingi ni bora ikiwa nyingi ya nyaraka hizi zinazalishwa kiotomatiki, ili nyaraka hizi zibaki zikisawazishwa na programu inavyobadilika, lakini hii haihitajiki. Mradi YAWEZA kutumia viungo vya hypertext kwa nyenzo zisizo za mradi kama nyaraka. Nyaraka ZIWEZA kuzalishwa kiotomatiki (ambapo ni vitendo hii mara nyingi ndiyo njia bora ya kufanya hivyo). Nyaraka za kiolesura cha REST zinaweza kuzalishwa kwa kutumia Swagger/OpenAPI. Nyaraka za kiolesura cha msimbo ZINAWEZA kuzalishwa kwa kutumia zana kama vile JSDoc (JavaScript), ESDoc (JavaScript), pydoc (Python), devtools (R), pkgdown (R), na Doxygen (nyingi). Kuwa na maoni tu katika msimbo wa utekelezaji haitoshi kutosheleza kigezo hiki; kunahitaji kuwa na njia rahisi ya kuona habari bila kusoma kupitia msimbo wote wa chanzo. Ikiwa mradi hauzalishi programu, chagua "haihusiki" (N/A).

    Vectis documents its external HTTP and CLI interfaces, including request and
    response fields, status codes, error behavior, command arguments, output
    formats, configuration, and environment variables.

    HTTP API reference:
    https://github.com/liesware/Vectis/blob/main/doc/API.md

    OpenAPI specification:
    https://github.com/liesware/Vectis/blob/main/doc/openapi.yaml

    CLI reference:
    https://github.com/liesware/Vectis/blob/main/doc/CLI.md

    Environment reference:
    https://github.com/liesware/Vectis/blob/main/doc/ENV.md


  • Mengine


    Ya kutosha kwa nishani!

    Tovuti za mradi (tovuti, hifadhi, na URL za kupakua) LAZIMA zisaidie HTTPS kwa kutumia TLS. [sites_https]
    Hii inahitaji kwamba URL ya ukurasa wa nyumbani wa mradi na URL ya hifadhi ya udhibiti wa toleo vianze na "https:", si "http:". Unaweza kupata vyeti vya bure kutoka Let's Encrypt. Miradi YAWEZA kutekeleza kigezo hiki kwa kutumia (kwa mfano) GitHub pages, GitLab pages, au SourceForge project pages. Ikiwa unasaidia HTTP, tunakuhimiza uelekeze trafiki ya HTTP kwenda HTTPS.

    Given only https: URLs.


    Ya kutosha kwa nishani!

    Mradi LAZIMA uwe na taratibu moja au zaidi za majadiliano (ikiwa ni pamoja na mabadiliko yaliyopendekezwa na masuala) yenye utafutaji, inaruhusu ujumbe na mada kuelekezwa kwa URL, inaruhusu watu wapya kushiriki katika baadhi ya majadiliano, na haihitaji usakinishaji wa upande wa mteja wa programu ya kibinafsi. [discussion]
    Mifano ya taratibu zinazokubalika ni pamoja na orodha za barua pepe zilizohifadhiwa, majadiliano ya suala la GitHub na ombi la kuvuta, Bugzilla, Mantis, na Trac. Taratibu za majadiliano yasiyo ya wakati mmoja (kama IRC) zinakubaliwa ikiwa zinakidhi vigezo hivi; hakikisha kuna utaratibu wa kuhifadhi unaoelekezwa kwa URL. JavaScript ya kibinafsi, ingawa haikubalika, inaruhusiwa.

    GitHub supports discussions on issues and pull requests.


    Ya kutosha kwa nishani!

    Mradi UNAPASWA kutoa nyaraka kwa Kiingereza na uweze kukubali ripoti za hitilafu na maoni kuhusu msimbo kwa Kiingereza. [english]
    Kiingereza kwa sasa ni lingua franca ya teknolojia ya kompyuta; kusaidia Kiingereza huongeza idadi ya wasanidi na wakaguzi tofauti wa uwezekano duniani kote. Mradi unaweza kukidhi kigezo hiki hata ikiwa lugha ya msingi ya wasanidi wake wakuu si Kiingereza.

    Vectis documentation, contribution guidance, security policy, API reference,
    and source-code documentation are written in English. Bug reports, pull
    requests, and code-review comments are accepted in English through GitHub.

    Documentation:
    https://github.com/liesware/Vectis#readme

    Contribution guidance:
    https://github.com/liesware/Vectis/blob/main/CONTRIBUTING.md

    Bug reports:
    https://github.com/liesware/Vectis/issues

    Pull requests:
    https://github.com/liesware/Vectis/pulls


    Ya kutosha kwa nishani!

    Mradi LAZIMA utunzwe. [maintained]
    Kama kiwango cha chini, mradi unapaswa kujaribu kujibu ripoti za tatizo muhimu na udhaifu. Mradi unaofuata kwa bidii nishani pengine unatengenezwa. Miradi yote na watu wana rasilimali zilizowekewa mipaka, na miradi ya kawaida lazima ikatae baadhi ya mabadiliko yaliyopendekezwa, hivyo rasilimali zilizowekewa mipaka na kukataa mapendekezo sio ishara ya mradi usiotekelezwa.

    Mradi unapojua kwamba hautatengenezwa tena, unapaswa kuweka kigezo hiki kama "Haikidhi" na utumie utaratibu sahihi ili kuwaonyesha wengine kwamba hautengenezwi. Kwa mfano, tumia "DEPRECATED" kama kichwa cha kwanza cha README yake, ongeza "DEPRECATED" karibu na mwanzo wa ukurasa wake wa nyumbani, ongeza "DEPRECATED" mwanzoni mwa maelezo ya mradi wa hifadhi ya msimbo, ongeza nishani isiyolindwa katika README yake na/au ukurasa wa nyumbani, iweke kama iliyolemewa katika hifadhi yoyote ya kifurushi (k.m., npm deprecate), na/au utumie mfumo wa alama wa hifadhi ya msimbo ili kuihifadhi (k.m., mpangilio wa "archive" wa GitHub, alama ya "archived" ya GitLab, hali ya "readonly" ya Gerrit, au hali ya mradi wa "abandoned" wa SourceForge). Majadiliano ya ziada yanaweza kupatikana hapa.

    Vectis is under active development and is maintained through regular commits,
    continuous integration, dependency and security scanning, and a public issue
    tracker. The supported release series is documented in SECURITY.md, together
    with a private vulnerability-reporting process and an acknowledgment target.

    Evidence:
    https://github.com/liesware/Vectis/commits/main/
    https://github.com/liesware/Vectis/actions
    https://github.com/liesware/Vectis/issues
    https://github.com/liesware/Vectis/blob/main/SECURITY.md


 Udhibiti wa Mabadiliko 9/9 ●

  • Hifadhi ya chanzo ya kudhibiti toleo ya hadharani


    Ya kutosha kwa nishani!

    Mradi LAZIMA uwe na hifadhi ya chanzo ya kudhibiti toleo ambayo inaweza kusomwa hadharani na ina URL. [repo_public]
    URL YAWEZA kuwa sawa na URL ya mradi. Mradi YAWEZA kutumia matawi ya faragha (yasiyo ya umma) katika hali maalum wakati mabadiliko hayajatolewa hadharani (k.m., kwa kurekebisha udhaifu kabla haujafichuliwa kwa umma).

    Repository on GitHub, which provides public git repositories with URLs.


    Ya kutosha kwa nishani!

    Hifadhi ya chanzo ya mradi LAZIMA ifuatilie mabadiliko yaliyofanywa, nani alifanya mabadiliko, na mabadiliko yalifanywa lini. [repo_track]

    Repository on GitHub, which uses git. git can track the changes, who made them, and when they were made.


    Ya kutosha kwa nishani!

    Ili kuwezesha ukaguzi wa ushirikiano, hifadhi ya chanzo ya mradi LAZIMA ijumuishe matoleo ya kati kwa ukaguzi kati ya matoleo; HAIPASWA kujumuisha matoleo ya mwisho tu. [repo_interim]
    Miradi YAWEZA kuchagua kuondoa matoleo maalum ya kati kutoka hifadhi zao za chanzo za umma (k.m., zile zinazorekebi udhaifu maalum usiokuwa wa umma, huenda zisitolewe hadharani, au zijumuishe nyenzo ambazo haziwezi kuwekwa kisheria na haziko katika toleo la mwisho).

    Vectis is developed in its public Git repository. The main branch contains intermediate development commits between releases, and the complete commit
    history and proposed pull-request changes are available for review. The repository is not limited to final release snapshots or generated artifacts.

    Evidence:
    https://github.com/liesware/Vectis/commits/main/
    https://github.com/liesware/Vectis/pulls
    https://github.com/liesware/Vectis


    Ya kutosha kwa nishani!

    INASHAURIWA kwamba programu ya kawaida ya udhibiti wa toleo iliyosambazwa itumike (k.m., git) kwa hifadhi ya chanzo ya mradi. [repo_distributed]
    Git haihitajiki kihususa na miradi inaweza kutumia programu ya udhibiti wa toleo iliyokusanyika (kama subversion) na sababu.

    Repository on GitHub, which uses git. git is distributed.


  • Unambari wa toleo wa kipekee


    Ya kutosha kwa nishani!

    Matokeo ya mradi LAZIMA yawe na kitambulisho cha kipekee cha toleo kwa kila toleo linalokusudiwa kutumiwa na watumiaji. [version_unique]
    Hii YAWEZA kukidhi kwa njia mbalimbali ikiwa ni pamoja na vitambulisho vya kuwasilisha (kama kitambulisho cha kuwasilisha cha git au kitambulisho cha seti ya mabadiliko cha mercurial) au nambari ya toleo (ikiwa ni pamoja na nambari za toleo zinazotumia uainishaji wa maana au mipango ya tarehe kama YYYYMMDD).

    Each Vectis release is assigned a unique Semantic Versioning identifier from Cargo.toml. The version is exposed by vectis version, recorded in
    CHANGELOG.md, and used in release artifact names.

    The release workflow requires the Git tag to match v${Cargo.toml.version} before publishing release artifacts, preventing a release from being published under an inconsistent version identifier.

    Evidence:
    https://github.com/liesware/Vectis/blob/main/Cargo.toml
    https://github.com/liesware/Vectis/blob/main/CHANGELOG.md
    https://github.com/liesware/Vectis/blob/main/.github/workflows/release.yml


    Ya kutosha kwa nishani!

    INASHAURIWA kwamba muundo wa nambari ya toleo ya Semantic Versioning (SemVer) au Calendar Versioning (CalVer) itumike kwa matoleo. INASHAURIWA kwamba wale wanaotumia CalVer wajumuishe thamani ya kiwango cha mdogo. [version_semver]
    Miradi kwa ujumla inapaswa kupendelea muundo wowote unaotarajiwa na watumiaji wao, k.m., kwa sababu ni muundo wa kawaida unaotumiwa na ikolojia yao. Ikolojia nyingi zinapendelea SemVer, na SemVer kwa ujumla hupendelewa kwa kiolesura cha programu ya programu (API) na zana za maendeleo ya programu (SDK). CalVer hutumiwa na miradi ambayo ni kubwa, ina idadi kubwa ya utegemezi ulioundwa kwa uhuru, ina upeo wa mara kwa mara unaobadilika, au ni ya muda muhimu. INASHAURIWA kwamba wale wanaotumia CalVer wajumuishe thamani ya kiwango cha mdogo, kwa sababu kujumuisha kiwango cha mdogo kunasaidia matawi yaliyotunzwa kwa wakati mmoja wakati wowote hilo linakuwa lazima. Miundo mingine ya nambari ya toleo inaweza kutumiwa kama nambari za toleo, ikiwa ni pamoja na vitambulisho vya kuwasilisha cha git au vitambulisho vya seti ya mabadiliko cha mercurial, mradi tu vikitambulisha matoleo kwa kipekee. Hata hivyo, baadhi ya mbadala (kama vitambulisho vya kuwasilisha cha git) vinaweza kusababisha matatizo kama vitambulisho vya toleo, kwa sababu watumiaji huenda wasiwe na uwezo wa kuamua kwa urahisi ikiwa wako na toleo la hivi karibuni. Muundo wa kitambulisho cha toleo unaweza kutokuwa wa maana kwa kutambulisha matoleo ya programu ikiwa wapokeaji wote wanaendesha toleo la hivi karibuni tu (k.m., ni msimbo wa tovuti moja au huduma ya mtandao ambayo inasasishwa mara kwa mara kupitia utoaji wa kuendelea).

    Kwa shida ya kutosha kwa nishani.

    INASHAURIWA kwamba miradi itambulishe kila toleo ndani ya mfumo wao wa udhibiti wa toleo. Kwa mfano, INASHAURIWA kwamba wale wanaotumia git watambulishe kila toleo kwa kutumia lebo za git. [version_tags]

    Vectis has a release workflow that requires release tags to match v${Cargo.toml.version}, but the first public release has not yet been identified with a Git tag.


  • Maelezo ya kutolewa


    Ya kutosha kwa nishani!

    Mradi LAZIMA utoe, katika kila toleo, maelezo ya toleo ambayo ni muhtasari unaosomeka na binadamu wa mabadiliko makuu katika toleo hilo ili kuwasaidia watumiaji kuamua ikiwa wanapaswa kusasisha na athari ya kusasisha itakuwa nini. Maelezo ya toleo LAZIMA yasiwe matokeo ghafi ya kumbukumbu ya udhibiti wa toleo (k.m., matokeo ya amri ya "git log" si maelezo ya toleo). Miradi ambayo matokeo yake hayakusudiwa kutumika tena katika maeneo mengi (kama programu kwa tovuti moja au huduma) NA wanaotumia utoaji wa kuendelea WAWEZA kuchagua "N/A". (URL inahitajika) [release_notes]
    Maelezo ya toleo YAWEZA kutekelezwa kwa njia mbalimbali. Miradi mingi hutoa katika faili inayoitwa "NEWS", "CHANGELOG", au "ChangeLog", kwa hiari na viendelezi kama ".txt", ".md", au ".html". Kihistoria neno "change log" lilimaanisha kumbukumbu ya kila mabadiliko, lakini ili kukidhi vigezo hivi kinachohitajika ni muhtasari unaosomeka na binadamu. Maelezo ya toleo YAWEZA badala yake kutolewa na taratibu za mfumo wa udhibiti wa toleo kama mtiririko wa Matoleo ya GitHub.

    Non-trivial release notes file in repository: https://github.com/liesware/Vectis/blob/main/CHANGELOG.md.


    Ya kutosha kwa nishani!

    Maelezo ya toleo LAZIMA yatambulishe kila udhaifu wa muda wa kutekeleza uliojulikana hadharani uliorekebishwa katika toleo hili ambao tayari ulikuwa na mgawanyo wa CVE au sawa wakati toleo lilipobuniwa. Kigezo hiki kinaweza kuwekwa alama kama haihusiki (N/A) ikiwa watumiaji kwa kawaida hawawezi kwa vitendo kusasisha programu wao wenyewe (k.m., kama inavyokuwa kweli mara nyingi kwa masasisho ya kernel). Kigezo hiki kinatumika tu kwa matokeo ya mradi, si kwa utegemezi wake. Ikiwa hakuna maelezo ya toleo au hakujawa na udhaifu uliojulikana hadharani, chagua N/A. [release_notes_vulns]
    Kigezo hiki kinawasaidia watumiaji kuamua ikiwa sasisho fulani litarekebisha udhaifu ambao unajulikana hadharani, ili kuwasaidia watumiaji kufanya uamuzi wa habari kuhusu kusasisha. Ikiwa watumiaji kwa kawaida hawawezi kwa vitendo kusasisha programu wao wenyewe kwenye kompyuta zao, lakini badala yake lazima wategemee wapatanishi mmoja au zaidi kutekeleza sasisho (kama inavyokuwa mara nyingi kwa kernel na programu ya kiwango cha chini ambayo imefungwa na kernel), mradi unaweza kuchagua "haihusiki" (N/A) badala yake, kwani habari hii ya ziada haitakuwa ya msaada kwa watumiaji hao. Vivyo hivyo, mradi unaweza kuchagua N/A ikiwa wapokeaji wote wanaendesha toleo la hivi karibuni tu (k.m., ni msimbo wa tovuti moja au huduma ya mtandao ambayo inasasishwa mara kwa mara kupitia utoaji wa kuendelea). Kigezo hiki kinatumika tu kwa matokeo ya mradi, si kwa utegemezi wake. Kuorodhesha udhaifu wa utegemezi wote wa mpito wa mradi unakuwa mgumu kadiri utegemezi unavyoongezeka na kutofautiana, na haihitajiki kwani zana zinazochunguza na kufuatilia utegemezi zinaweza kufanya hivi kwa njia inayopanuka.

    N/A. At the time Vectis v0.8.5 was prepared, there were no publicly known run-time vulnerabilities in Vectis with a CVE or equivalent public identifier that were fixed by the release.

    Dependency advisories are monitored separately and are not treated as vulnerabilities in the Vectis project results for this criterion.

    Evidence:
    https://github.com/liesware/Vectis/blob/main/CHANGELOG.md
    https://github.com/liesware/Vectis/blob/main/SECURITY.md


 Kuripoti 6/8 ●

  • Mchakato wa kuripoti hitilafu


    Ya kutosha kwa nishani!

    Mradi LAZIMA utoe mchakato kwa watumiaji kuwasilisha ripoti za hitilafu (k.m., kwa kutumia kifuatiliaji cha masuala au orodha ya barua pepe). (URL inahitajika) [report_process]

    Non-trivial SECURITY[.md] file found file in repository: https://github.com/liesware/Vectis/blob/main/SECURITY.md. [osps_do_02_01]


    Ya kutosha kwa nishani!

    Mradi UNAPASWA kutumia kifuatiliaji cha masuala kwa kufuatilia masuala ya mtu binafsi. [report_tracker]

    Vectis uses GitHub Issues as its public issue tracker. Individual bug reports,
    enhancement proposals, documentation problems, and user questions can be created, discussed, tracked, and closed there.

    Suspected unpatched vulnerabilities are handled separately through the private reporting process documented in SECURITY.md.

    Evidence:
    https://github.com/liesware/Vectis/issues
    https://github.com/liesware/Vectis/blob/main/SECURITY.md


    Taarifa inayohitajika haijulikani, si ya kutosha kwa nishani.

    Mradi LAZIMA uthibitishe wengi wa ripoti za hitilafu zilizowasilishwa katika miezi 2-12 iliyopita (ikiwemo); jibu halihitaji kuwa na marekebisho. [report_responses]

    Taarifa inayohitajika haijulikani, si ya kutosha kwa nishani.

    Mradi UNAPASWA kujibu wengi (>50%) wa maombi ya maboresho katika miezi 2-12 iliyopita (ikiwemo). [enhancement_responses]
    Jibu LIWEZA kuwa 'hapana' au majadiliano kuhusu manufaa yake. Lengo ni kwamba kuwe na jibu fulani kwa baadhi ya maombi, ambayo inaonyesha kwamba mradi bado unaishi. Kwa madhumuni ya kigezo hiki, miradi haihitaji kuhesabu maombi ya bandia (k.m., kutoka kwa wafanyabiashara haramu au mifumo ya kiotomatiki). Ikiwa mradi hauendelei kufanya maboresho tena, tafadhali chagua "haijatimizwa" na jumuisha URL inayofanya hali hii kuwa wazi kwa watumiaji. Ikiwa mradi huwa na msongo wa maombi ya maboresho, tafadhali chagua "haijatimizwa" na eleza.

    Ya kutosha kwa nishani!

    Mradi LAZIMA uwe na kumbukumbu inayopatikana hadharani kwa ripoti na majibu kwa utaftaji wa baadaye. (URL inahitajika) [report_archive]

    Vectis uses GitHub Issues as a publicly available and searchable archive for bug reports, enhancement requests, questions, and maintainer responses. Open and closed reports remain available for later review and searching.

    Public archive:
    https://github.com/liesware/Vectis/issues?q=is%3Aissue


  • Mchakato wa kuripoti udhaifu


    Ya kutosha kwa nishani!

    Mradi LAZIMA uchapishe mchakato wa kuripoti udhaifu kwenye tovuti ya mradi. (URL inahitajika) [vulnerability_report_process]
    Miradi iliyohifadhiwa kwenye GitHub INAPASWA kuzingatia kuwezesha kuripoti udhaifu wa usalama kwa faragha. Miradi kwenye GitLab INAPASWA kuzingatia kutumia uwezo wake wa kuripoti udhaifu kwa faragha. Miradi YAWEZA kutambulisha anwani ya barua pepe kwenye https://PROJECTSITE/security, mara nyingi katika muundo wa security@example.org. Mchakato huu wa kuripoti udhaifu UWEZA kuwa sawa na mchakato wake wa kuripoti hitilafu. Ripoti za udhaifu ZIWEZA kuwa za umma kila wakati, lakini miradi mingi ina utaratibu wa kuripoti udhaifu wa faragha.

    Vectis publishes its vulnerability-reporting process in SECURITY.md. The policy defines the private reporting channel, requested report contents, supported versions, expected acknowledgment period, disclosure process, and information that reporters must not include.

    Vulnerability-reporting process:
    https://github.com/liesware/Vectis/blob/main/SECURITY.md


    Ya kutosha kwa nishani!

    Ikiwa ripoti za udhaifu wa faragha zinasaidiwa, mradi LAZIMA ujumuishe jinsi ya kutuma habari kwa njia ambayo inawekwa faragha. (URL inahitajika) [vulnerability_report_private]
    Mifano ni pamoja na ripoti ya kasoro ya faragha iliyowasilishwa kwenye wavuti kwa kutumia HTTPS (TLS) au barua pepe iliyosimbwa kwa kutumia OpenPGP. Ikiwa ripoti za udhaifu ni za umma kila wakati (kwa hiyo hakuna ripoti za udhaifu za faragha), chagua "haihusiki" (N/A).

    Vectis accepts private vulnerability reports through the maintainer's direct email address, using the subject specified in SECURITY.md. Reporters are instructed not to open a public issue for an unpatched vulnerability. If a more protected exchange is needed, the reporter can request an appropriate channel
    in the initial private message.

    Private reporting instructions:
    https://github.com/liesware/Vectis/blob/main/SECURITY.md#reporting-a-vulnerability


    Ya kutosha kwa nishani!

    Muda wa majibu ya awali ya mradi kwa ripoti yoyote ya udhaifu iliyopokelewa katika miezi 6 iliyopita LAZIMA uwe chini ya au sawa na siku 14. [vulnerability_report_response]
    Ikiwa hakujawa na udhaifu ulioripotiwa katika miezi 6 iliyopita, chagua "haihusiki" (N/A).

    N/A. Vectis has not received any vulnerability reports during the last six months. SECURITY.md establishes a target acknowledgment period of five business
    days for future reports.

    Evidence:
    https://github.com/liesware/Vectis/blob/main/SECURITY.md


 Ubora 13/13 ●

  • Mfumo wa ujenzi unaofanya kazi


    Ya kutosha kwa nishani!

    Ikiwa programu iliyotengenezwa na mradi inahitaji ujenzi wa matumizi, mradi LAZIMA utoe mfumo wa kujenga ambao unaweza kujenga programu kiotomatiki kutoka kwa chanzo-msimbo. [build]
    Mfumo wa kujenga huamua ni hatua gani zinahitaji kutendeka ili kujenga tena programu (na kwa mpangilio gani), na kisha kutekeleza hatua hizo. Kwa mfano, inaweza kuomba kikusanyaji kukusanya fumbo-chanzo. Ikiwa inayoweza kutekelezwa imeundwa kutoka kwa fumbo-chanzo, lazima iwezeshe marekebisho kwenye fumbo-chanzo ya mradi na kisha itengeneze msasisho inayoweza kutekelezwa na marekebisho hayo. Ikiwa programu iliyotolewa na mradi unategemea maktaba ya nje, mfumo wa kujenga haina haja ya kujenga maktaba hizo za nje. Ikiwa hakuna haja ya kujenga chochote kutumia programu baada ya fumbo-chanzo kubadilishwa, chagua "haitumiki" (N / A).

    Vectis uses Cargo as its automated build system. The complete application can be rebuilt from source with cargo build --locked or cargo build --release --locked.

    Cargo.toml defines the package and dependencies, Cargo.lock pins dependency resolution, and rust-toolchain.toml defines the Rust toolchain. GitHub Actions
    continuously verifies that the project builds from source.

    Evidence:
    https://github.com/liesware/Vectis/blob/main/Cargo.toml
    https://github.com/liesware/Vectis/blob/main/Cargo.lock
    https://github.com/liesware/Vectis/blob/main/rust-toolchain.toml
    https://github.com/liesware/Vectis/blob/main/.github/workflows/Rust.yml


    Ya kutosha kwa nishani!

    INAPENDEKEZWA kuwa zana za kawaida zitumike kujenga programu. [build_common_tools]
    Kwa mfano, Maven, Ant, cmake, autotools, make, rake (Ruby), au devtools (R).

    Vectis uses Cargo and rustup, the standard build and toolchain-management tools of the Rust ecosystem. Common Cargo commands are used for development, testing, linting, and release builds; no proprietary or project-specific build system is required.

    Typical commands include:

    cargo build --locked
    cargo test --locked
    cargo clippy --locked --all-targets --all-features -- -D warnings

    Evidence:
    https://github.com/liesware/Vectis/blob/main/Cargo.toml
    https://github.com/liesware/Vectis/blob/main/rust-toolchain.toml
    https://github.com/liesware/Vectis/blob/main/CONTRIBUTING.md


    Ya kutosha kwa nishani!

    Mradi UNAPASWA kujengwa kwa kutumia zana za FLOSS pekee yake. [build_floss_tools]

    Vectis can be built entirely with FLOSS tools. Its standard build uses the open-source Rust compiler, Cargo, LLVM-based tooling, and common GNU/Linux build
    tools.

    The container build demonstrates this path using Debian with Cargo, rustc, Clang, GCC, CMake, Make, and other open-source packages, followed by
    cargo build --release --locked. No proprietary compiler or build system is required.

    Evidence:
    https://github.com/liesware/Vectis/blob/main/image/Dockerfile.tag
    https://github.com/liesware/Vectis/blob/main/Cargo.toml
    https://github.com/liesware/Vectis/blob/main/rust-toolchain.toml


  • Seti ya majaribio otomatiki


    Ya kutosha kwa nishani!

    Mradi LAZIMA utumie angalau seti moja ya majaribio ya kiotomatiki ambayo imetolewa hadharani kama FLOSS (seti hii ya majaribio inaweza kutunzwa kama mradi tofauti wa FLOSS). Mradi LAZIMA uonyeshe wazi au uandike jinsi ya kuendesha seti za majaribio (k.m., kupitia hati ya uingizaji wa kuendelea (CI) au kupitia nyaraka katika faili kama BUILD.md, README.md, au CONTRIBUTING.md). [test]
    Mradi YAWEZA kutumia seti nyingi za majaribio ya kiotomatiki (k.m., moja inayoendesha haraka, dhidi ya nyingine ambayo ni ya kina zaidi lakini inahitaji vifaa maalum). Kuna mifumo mingi ya majaribio na mifumo ya kusaidia majaribio inayopatikana, ikiwemo Selenium (uendeshaji kiotomatiki wa kivinjari cha wavuti), Junit (JVM, Java), RUnit (R), testthat (R).

    Vectis includes publicly available automated test suites released under the project's Apache-2.0 license. The primary Rust suite runs with cargo test --locked.

    The project also includes Python HTTP integration tests, Schemathesis OpenAPI contract testing, native cargo-fuzz targets, and dedicated CLI and cryptographic integration tests. Execution instructions and the role of each suite are documented in doc/Test.md, and the standard suite runs automatically through GitHub Actions.

    Evidence:
    https://github.com/liesware/Vectis/blob/main/doc/Test.md
    https://github.com/liesware/Vectis/tree/main/tests
    https://github.com/liesware/Vectis/tree/main/fuzz
    https://github.com/liesware/Vectis/blob/main/.github/workflows/Rust.yml
    https://github.com/liesware/Vectis/blob/main/LICENSE


    Ya kutosha kwa nishani!

    Seti ya majaribio INAPASWA kuwa inaweza kuitwa kwa njia ya kawaida kwa lugha hiyo. [test_invocation]
    Kwa mfano, "make check", "mvn test", au "rake test" (Ruby).

    Vectis uses Cargo's standard Rust test interface. The primary unit and integration test suite is invoked with:

    cargo test --locked

    Targeted Rust tests can also be selected through Cargo's standard test filters. Additional Python, Schemathesis, and cargo-fuzz suites are documented separately, but they do not replace the standard Cargo test entry point.

    Evidence:
    https://github.com/liesware/Vectis/blob/main/doc/Test.md
    https://github.com/liesware/Vectis/blob/main/CONTRIBUTING.md
    https://github.com/liesware/Vectis/blob/main/.github/workflows/Rust.yml


    Kwa shida ya kutosha kwa nishani.

    INAPENDEKEZWA kwamba seti ya majaribio ifuate wengi (au kwa kawaida wote) matawi ya msimbo, sehemu za kuingiza, na utendakazi. [test_most]

    Vectis has extensive unit, integration, negative-contract, property-based, HTTP, Schemathesis, and native fuzz testing. These suites cover the primary
    cryptographic capabilities, input fields, validation boundaries, storage behavior, and public API workflows.

    However, Vectis does not yet publish or enforce a coverage result demonstrating that most code branches are executed. This suggested criterion has been
    considered but is not currently claimed as met.

    Evidence:
    https://github.com/liesware/Vectis/blob/main/doc/Test.md
    https://github.com/liesware/Vectis/tree/main/tests
    https://github.com/liesware/Vectis/tree/main/fuzz


    Ya kutosha kwa nishani!

    INAPENDEKEZWA kwamba mradi utekeleze ujumuishaji wendeleo (ambapo msimbo mpya au uliobadiishwa unajumuishwa mara kwa mara katika hifadhi ya msimbo ya kati na majaribio otomatiki hufanyika kwenye matokeo). [test_continuous_integration]

    Vectis uses GitHub Actions for continuous integration. The Rust workflow runs automatically for every pull request targeting main and for every push to main.

    The workflow checks formatting, runs the complete Rust test suite, runs Clippy with warnings treated as errors, validates shell scripts, audits dependencies,
    builds the binary, and then executes the Python integration tests.

    Evidence:
    https://github.com/liesware/Vectis/blob/main/.github/workflows/Rust.yml
    https://github.com/liesware/Vectis/actions/workflows/Rust.yml


  • Upimaji wa utendaji mpya


    Ya kutosha kwa nishani!

    Mradi LAZIMA uwe na sera ya jumla (rasmi au la) kwamba utendakazi mkubwa mpya unavyoongezwa kwenye programu inayotengenezwa na mradi, majaribio ya utendakazi huo unapaswa kuongezwa kwenye seti ya majaribio otomatiki. [test_policy]
    Mradi uwe na sera tu, hata kwa maneno ya mdomo, inayosema wasanidi programu wanapaswa kuongeza majaribio kwenye seti ya majaribio otomatiki kwa utendakazi mkubwa mpya, chagua "Kukidhi."

    Vectis requires tests to be added alongside new behavior. Its engineering rules state that validation functions require unit tests and public contracts require
    positive and negative end-to-end tests. New endpoints are expected to add validators, limits, unit tests, and negative contract coverage as part of the
    same change.

    CONTRIBUTING.md also states that tests must not be omitted to make a change appear smaller and requires contributors to run the automated Rust suite before submitting.

    Evidence:
    https://github.com/liesware/Vectis/blob/main/doc/Design.md#7-testing-and-tooling-discipline
    https://github.com/liesware/Vectis/blob/main/CONTRIBUTING.md


    Ya kutosha kwa nishani!

    Mradi LAZIMA uwe na ushahidi kwamba test_policy ya kuongeza majaribio imefuatwa katika mabadiliko makubwa ya hivi karibuni kwenye programu inayotengenezwa na mradi. [tests_are_added]
    Utendakazi mkubwa kawaida ungetajwa katika maelezo ya toleo. Ukamilifu hauhitajiki, ni ushahidi tu kwamba majaribio kawaida huongezwa kimakosa kwenye seti ya majaribio otomatiki utendakazi mkubwa mpya unavyoongezwa kwenye programu inayotengenezwa na mradi.

    Recent major Vectis capabilities were implemented together with automated tests:

    • SLH-DSA artifact signing added unit tests, parser validation tests, four native fuzz targets, and seed corpora.
    • One-time tokenization added SQLite transaction tests, HTTP positive and negative tests, CLI tests, and fuzz coverage.
    • Authenticated Shamir secret sharing added core and operation tests, positive and negative HTTP tests, CLI coverage, and fuzz inputs.
    • Cryptographic commitments added unit, HTTP contract, negative, CLI, and fuzz tests.

    This commit history demonstrates that the project's policy of adding tests with new functionality is followed in practice.

    Evidence:
    https://github.com/liesware/Vectis/commit/154cb816c41667d521c1f30cf25c50f6f524321d
    https://github.com/liesware/Vectis/commit/7f7f0fa4814494f7dad7fc740e1c70dd2606ba1d
    https://github.com/liesware/Vectis/commit/a337628e14e69ca4f2116a55d292fa9915a5eeca
    https://github.com/liesware/Vectis/commit/4bbf0047773cdc590da923f465a6b13cd7f02ea6


    Ya kutosha kwa nishani!

    INAPENDEKEZWA kwamba sera hii ya kuongeza majaribio (angalia test_policy) iwe imeandikwa katika maelekezo ya mapendekezo ya mabadiliko. [tests_documented_added]
    Hata hivyo, hata sheria isiyo rasmi inakubaliwa mradi majaribio yaongezwe kimakosa.

    Vectis documents its testing policy in the contribution instructions. Contributors must not omit tests to reduce the apparent size of a change, must document the tests performed in the pull request, and must run the automated Rust suite before submission.

    The engineering rules additionally require unit tests for validation behavior and positive and negative end-to-end tests for public contracts.

    Evidence:
    https://github.com/liesware/Vectis/blob/main/CONTRIBUTING.md
    https://github.com/liesware/Vectis/blob/main/doc/Design.md#7-testing-and-tooling-discipline


  • Bendera za maonyo


    Ya kutosha kwa nishani!

    Mradi LAZIMA uwashe bendera moja au zaidi za onyo la mkusanyaji, hali ya lugha "salama", au tumia zana tofauti ya "linter" kutafuta makosa ya ubora wa msimbo au makosa rahisi ya kawaida, ikiwa kuna angalau zana moja ya FLOSS inaweza kutekeleza kigezo hiki katika lugha iliyochaguliwa. [warnings]
    Mifano ya bendera za onyo la mkusanyaji ni pamoja na gcc/clang "-Wall". Mifano ya hali ya lugha "salama" ni pamoja na JavaScript "use strict" na perl5's "use warnings". Zana tofauti ya "linter" ni zana tu inayoangalia msimbo wa chanzo kutafuta makosa ya ubora wa msimbo au makosa rahisi ya kawaida. Hizi kawaida huwashwa ndani ya msimbo wa chanzo au maelekezo ya ujenzi.

    Vectis documents its testing policy in the contribution instructions. Contributors must not omit tests to reduce the apparent size of a change, must document the tests performed in the pull request, and must run the automated Rust suite before submission.

    The engineering rules additionally require unit tests for validation behavior and positive and negative end-to-end tests for public contracts.

    Evidence:
    https://github.com/liesware/Vectis/blob/main/CONTRIBUTING.md
    https://github.com/liesware/Vectis/blob/main/doc/Design.md#7-testing-and-tooling-discipline


    Ya kutosha kwa nishani!

    Mradi LAZIMA ukabiliane na maonyo. [warnings_fixed]
    Haya ni maonyo yaliyotambuliwa na utekelezaji wa kigezo cha warnings. Mradi unapaswa kurekebisha maonyo au kuyaweka alama katika msimbo wa chanzo kama hasi za uwongo. Kwa kawaida pasingeweza kuwa na maonyo, lakini mradi YAWEZA kukubali baadhi ya maonyo (kawaida chini ya onyo 1 kwa mistari 100 au chini ya maonyo 10).

    Vectis treats compiler and Clippy warnings as errors. The continuous integration workflow runs Clippy with -D warnings across all targets and features, so any
    new warning causes the check to fail and must be resolved before the change can be accepted.

    The project's engineering rules define zero warnings as the required state, and the same check is documented for contributors.

    Evidence:
    https://github.com/liesware/Vectis/blob/main/.github/workflows/Rust.yml
    https://github.com/liesware/Vectis/blob/main/CONTRIBUTING.md
    https://github.com/liesware/Vectis/blob/main/doc/Design.md#7-testing-and-tooling-discipline
    https://github.com/liesware/Vectis/actions/workflows/Rust.yml


    Ya kutosha kwa nishani!

    INAPENDEKEZWA kwamba miradi iwe na ukali mkubwa sana na maonyo katika programu inayotengenezwa na mradi, ambapo ni ya vitendo. [warnings_strict]
    Baadhi ya maonyo hayawezi kuwashwa kwa ufanisi kwenye miradi fulani. Kinachohitajika ni ushahidi kwamba mradi unajitahidi kuwasha bendera za onyo ambapo inaweza, ili makosa yagundulika mapema.

    Vectis applies strict warning handling across all targets and features. Clippy and compiler warnings are promoted to errors through -D warnings, so warnings
    cannot be merged while the CI check is required.

    The project uses only narrow, local lint allowances for specific cases such as intentionally unused internal helpers and configuration functions whose
    signatures reflect explicit validation hooks. It does not disable warning categories globally.

    Evidence:
    https://github.com/liesware/Vectis/blob/main/.github/workflows/Rust.yml
    https://github.com/liesware/Vectis/blob/main/CONTRIBUTING.md
    https://github.com/liesware/Vectis/blob/main/doc/Design.md#7-testing-and-tooling-discipline


 Usalama 15/16 ●

  • Maarifa ya maendeleo yenye usalama


    Ya kutosha kwa nishani!

    Mradi LAZIMA uwe na angalau msanidi mmoja mkuu anayejua jinsi ya kuunda programu salama. (Angalia 'maelezo' kwa mahitaji halisi.) [know_secure_design]
    Hii inahitaji kuelewa kanuni zifuatazo za muundo, ikiwa ni pamoja na kanuni 8 kutoka Saltzer na Schroeder:
    • uchumi wa utaratibu (weka muundo kuwa rahisi na mdogo iwezekanavyo, k.m., kwa kupitisha urahisishaji wa kufunga)
    • mipangilio ya kuzuia makosa (maamuzi ya kuingia yanapaswa kukataa kwa chaguo-msingi, na usakinishaji wa miradi unapaswa kuwa salama kwa chaguo-msingi)
    • kikuu cha kati kikamilifu (kuingia kote kunaweza kuwekwa kikomo lazima kufanyiwa ukaguzi wa mamlaka na kutowezesha kuvukwa)
    • muundo wazi (taratibu za usalama hazipaswi kutegemea ujinga wa mshambuliaji wa muundo wake, lakini badala yake kwenye habari iliyolindwa na kubadilishwa kwa urahisi kama funguo na nywila)
    • kutenganisha kwa upendeleo (kwa kawaida, ufikiaji kwa vitu muhimu unapaswa kutegemea zaidi ya sharti moja, ili kushinda mfumo mmoja wa ulinzi hautawasha ufikiaji kamili. K.m., uthibitishaji wa vipengele vingi, kama vile kuhitaji nywila na ishara za vifaa, ni imara zaidi kuliko uthibitishaji wa kipengele kimoja)
    • upendeleo mdogo zaidi (michakato inapaswa kufanya kazi na upendeleo mdogo zaidi unaohitajika)
    • utaratibu wa kawaida mdogo zaidi (muundo unapaswa kupunguza utaratibu wa kawaida kwa zaidi ya mtumiaji mmoja na kutegemewa na watumiaji wote, k.m., saraka za mafaili ya muda)
    • kukubalika kwa kisaikolojia (kiolesura cha binadamu lazima kiwe kimeundwa kwa urahisi wa matumizi - kuunda kwa "mshangao mdogo" kunaweza kusaidia)
    • uso wa shambulio uliowekewa mipaka (uso wa shambulio - seti ya sehemu tofauti ambapo mshambuliaji anaweza kujaribu kuingia au kutoa data - unapaswa kuwekwa mipaka)
    • uthibitishaji wa ingizo na orodha zinazokubalika (pembejeo kawaida zinapaswa kuangaliwa ili kuamua kama ni halali kabla ya kukubalika; uthibitishaji huu unapaswa kutumia orodha zinazokubalika (zinazokubali tu thamani zinazojulikana-nzuri), siyo orodha zinazokana (zinaozojaribu kuorodhesha thamani zinazojulikana-mbaya)).
    "Msanidi mkuu" katika mradi ni mtu yeyote ambaye anajua msingi wa msimbo wa mradi, ana faraja kufanya mabadiliko kwake, na anatambuliwa hivyo na washiriki wengine wengi katika mradi. Msanidi mkuu kawaida atafanya michango mingi kwa mwaka uliopita (kupitia msimbo, nyaraka, au kujibu maswali). Wasanidi kawaida wangeweza kuchukuliwa wasanidi wakuu ikiwa walianzisha mradi (na hawajatoka kwenye mradi zaidi ya miaka mitatu iliyopita), wana chaguo la kupokea habari kwenye kituo cha kuripoti udhaifu wa kibinafsi (ikiwa kuna), wanaweza kukubali ahadi kwa niaba ya mradi, au kufanya matoleo ya mwisho ya programu ya mradi. Ikiwa kuna msanidi mmoja tu, mtu huyo ndiye msanidi mkuu. Vitabu vingi na kozi zinapatikana kukusaidia kuelewa jinsi ya kuunda programu salama zaidi na kujadili muundo. Kwa mfano, kozi ya Misingi ya Maendeleo ya Programu Salama ni seti huru ya kozi tatu zinazoeleza jinsi ya kuunda programu salama zaidi (ni bure ukiifanyia ukaguzi; kwa ada ya ziada unaweza kupata cheti kuthibitisha ulijifunza nyenzo).

    Eduardo Lopez is the original author, primary developer, maintainer, release operator, and recipient of private vulnerability reports for Vectis.

    Vectis applies secure-design principles throughout its implementation and documentation: narrow scope and economy of mechanism; fail-closed sealed
    startup and authorization; centralized lifecycle and permission mediation; public design and threat-model documentation; separation of policy, keys, and
    operations; least-privilege container execution; bounded inputs and attack surface; allowlist-based validation; explicit trust boundaries; and simple,
    inspectable HTTP, CLI, JSON, and OpenAPI interfaces.

    The project's Design and Threat Model documents explain these principles, their implementation, and the security properties Vectis deliberately leaves
    to other layers.

    Evidence:
    https://github.com/liesware/Vectis/blob/main/doc/Design.md
    https://github.com/liesware/Vectis/blob/main/doc/ThreatModel.md
    https://github.com/liesware/Vectis/blob/main/doc/Internal.md
    https://github.com/liesware/Vectis/blob/main/doc/SelfAssessment.md
    https://github.com/liesware/Vectis/blob/main/NOTICE


    Ya kutosha kwa nishani!

    Angalau mmoja wa wasanidi wakuu wa mradi LAZIMA wajue aina za kawaida za makosa ambayo husababisha udhaifu katika aina hii ya programu, pamoja na angalau mbinu moja ya kukabiliana au kupunguza kila moja. [know_common_errors]
    Mifano (kulingana na aina ya programu) ni pamoja na uvamizi wa SQL, uvamizi wa OS, mtiririko wa kipengele cha kawaida, uandishi wa tovuti-tofauti, uthibitishaji unaokosekana, na uidhinishaji unaokosekana. Angalia CWE/SANS top 25 au OWASP Top 10 kwa orodha zinazotumika kawaida. Vitabu vingi na kozi zinapatikana kukusaidia kuelewa jinsi ya kuunda programu salama zaidi na kujadili makosa ya kawaida ya utekelezaji ambayo husababisha udhaifu. Kwa mfano, kozi ya Misingi ya Maendeleo ya Programu Salama ni seti huru ya kozi tatu zinazoeleza jinsi ya kuunda programu salama zaidi (ni bure ukiifanyia ukaguzi; kwa ada ya ziada unaweza kupata cheti kuthibitisha ulijifunza nyenzo).

    Vectis's primary developer understands common vulnerability classes relevant to a networked cryptographic data-protection service and applies corresponding
    mitigations, including:

    • SQL injection: SQLx queries use bound parameters; dynamic SQL is limited to internally generated placeholders.
    • Missing authentication or authorization: protected endpoints use API-key authentication, signed permissions, KID scoping, peer authorization, and
      centralized lifecycle checks.
    • SSRF and destination injection: peer and final-application destinations come from signed configuration, not request-supplied addresses.
    • Invalid or malicious input: external fields are bounded and validated using allowlists, typed parsers, strict JSON contracts, and canonical structured
      contexts.
    • Cryptographic misuse: Vectis uses published algorithms through Botan and established libraries, CSPRNG-generated material, profile-controlled policy,
      context-bound AEAD, and verify-before-decrypt.
    • Timing attacks: API-key, MAC, commitment, signature-hash, and share authentication comparisons use constant-time comparison.
    • Secret disclosure: sensitive values are redacted from errors and logs, zeroized where practical, and encrypted before application-level storage.
    • Resource-exhaustion attacks: HTTP bodies, fields, batches, files, timeouts, and shutdown behavior have explicit bounds.
    • Concurrency and state races: token consumption and lifecycle changes use transactions or compare-and-swap semantics where required.
    • Memory-safety errors: Vectis is implemented in Rust and avoids manual memory management in production application logic.

    These threats and mitigations are documented and tested through unit, integration, negative-contract, property-based, and fuzz testing.

    Evidence:
    https://github.com/liesware/Vectis/blob/main/doc/ThreatModel.md
    https://github.com/liesware/Vectis/blob/main/doc/Design.md
    https://github.com/liesware/Vectis/blob/main/doc/SelfAssessment.md
    https://github.com/liesware/Vectis/blob/main/src/core/validation.rs
    https://github.com/liesware/Vectis/blob/main/src/core/storage/sqlite.rs


  • 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.

    Si ya kutosha kwa nishani.

    Programu iliyotengenezwa na mradi LAZIMA itumie, kwa chaguo-msingi, tu itifaki za kriptografia na mifumbo ambazo zimechapishwa hadharani na kukaguliwa na wataalam (ikiwa itifaki za kriptografia na mafumbo imetumika). [crypto_published]
    Vigezo hivi vya kriptografia mara mingi havitumiki kwa sababu programu zingine hazina haja ya kutumia moja kwa moja uwezo wa kriptografia.

    Vectis uses publicly published and expert-reviewed cryptographic algorithms, including AES-GCM, ChaCha20-Poly1305, SHA-3, BLAKE2, HMAC, KMAC, HKDF,
    Ed25519/Ed448, X25519/X448, ML-KEM, ML-DSA, SLH-DSA, and FF1. Its transport and time protocols use established TLS, NTS, and Roughtime implementations.

    However, Vectis also defines project-specific cryptographic compositions and envelope formats for protected messages, hybrid signatures, tokenization,
    commitments, and audit checkpoints. These designs are publicly documented but have not yet completed independent expert cryptographic review. Therefore, the project does not currently claim that this strict criterion is fully met.

    Evidence:
    https://github.com/liesware/Vectis/blob/main/README.md
    https://github.com/liesware/Vectis/blob/main/doc/ThreatModel.md
    https://github.com/liesware/Vectis/blob/main/doc/Internal.md
    https://github.com/liesware/Vectis/blob/main/doc/SelfAssessment.md


    Ya kutosha kwa nishani!

    Ikiwa programu iliyotengenezwa na mradi ni programu au maktaba, na kusudi lake la msingi sio kutekeleza usimbuaji, basi INAPASWA tu kuita programu iliyoundwa kihususa kutekeleza kazi za kielelezo; HAIPASWI kutekeleza-upya shughuli hiyo. [crypto_call]

    Vectis's primary purpose is to provide cryptographic data-protection capabilities, including encryption, signatures, FPE, tokenization, MACs,
    commitments, secret sharing, and protected messaging. Therefore, the condition for this criterion does not apply.

    Nevertheless, Vectis delegates established cryptographic primitives to specialized FLOSS implementations such as Botan, RustCrypto crates, rustls,
    and the FF1 implementation maintained in liesware/fpe. Vectis does not implement block ciphers, cryptographic hash functions, digital-signature
    algorithms, or post-quantum primitives from scratch. Project code primarily implements policy, validation, key derivation, formats, and compositions around
    those primitives.

    Evidence:
    https://github.com/liesware/Vectis#readme
    https://github.com/liesware/Vectis/blob/main/Cargo.toml
    https://github.com/liesware/Vectis/blob/main/src/core/crypto.rs
    https://github.com/liesware/Vectis/blob/main/doc/Internal.md


    Ya kutosha kwa nishani!

    Utendaji wote katika programu iliyotengenezwa na mradi ambayo inategemea usimbuaji LAZIMA iweze kutekelezwa kwa kutumia FLOSS. [crypto_floss]
    Tazama Mahitaji ya Viwango wazi ya Programu kupitia Open Source Initiative.

    All cryptography-dependent functionality in Vectis can be built and operated using FLOSS components. Vectis is licensed under Apache-2.0 and publishes its
    complete source code.

    Cryptographic primitives are provided by open-source implementations including Botan, RustCrypto crates, rustls, and the open-source Vectis FF1 fork. Vectis
    does not require proprietary cryptographic libraries, SDKs, hardware, or hosted services for its current functionality. Dependencies are declared and pinned
    through Cargo.toml and Cargo.lock, and the project can be rebuilt from source
    using the documented FLOSS toolchain.

    Evidence:
    https://github.com/liesware/Vectis/blob/main/LICENSE
    https://github.com/liesware/Vectis/blob/main/Cargo.toml
    https://github.com/liesware/Vectis/blob/main/Cargo.lock
    https://github.com/liesware/fpe
    https://github.com/randombit/botan
    https://github.com/rustls/rustls


    Ya kutosha kwa nishani!

    Mifumo ya usalama ndani ya programu inayozalishwa na mradi LAZIMA itumie kwa msingi keylengths ambazo angalau zinakidhi mahitaji ya chini ya NIST kufikia mwaka wa 2030 (kama ilivyoelezwa mnamo 2012). LAZIMA iwe rahisi kusanidi programu ili keylengths ndogo zimezimwa kabisa. [crypto_keylength]
    Vipimo hivi vya urefu wa charaza ni: symmetric key 112, factoring modulus 2048, discrete logarithm key 224, discrete logarithmic group 2048, elliptic curve 224, na hash 224 (ufichuzi wa nywila haujashughulikiwa kwenye urefu wa charaza hii, maelezo zaidi ya ufichuzi wa nywila yanapatikana ndani ya kigezo cha crypto_password_storage). Ona https://www.keylength.com kwa mliganisho wa mapendekezo ya funguo-refu kutoka mashirika mbali mbali. Programu YAWEZA kubali funguo-refu ndogo katika usanidi (haifai kukubali, maana hii huwacha mashambulizi ya kushusha, lakini funguo-refu fupi wakati mwingine ina manufaa ya upatanifu).

    Vectis uses cryptographic profiles whose weakest supported components provide at least 128 bits of security, exceeding the 112-bit NIST minimum required
    through 2030.

    The default hybrid-performance-v1 profile uses ChaCha20Poly1305, Ed25519, X25519, ML-DSA-44, and ML-KEM-512. Other profiles use AES-128, AES-192, or
    AES-256 together with equal or stronger signature and key-establishment parameters. Internal encryption, FPE, tokenization, MAC, commitments, secret
    sharing authentication, and key derivation use 256-bit key material.

    Vectis does not expose legacy or reduced key sizes. The default VECTIS_CRYPTO_POLICY=profile-only rejects individual algorithm overrides and
    allows only the fixed, validated profiles. Even development overrides are restricted to an allowlist containing no algorithms below the required
    security strength.

    Evidence:
    https://github.com/liesware/Vectis/blob/main/src/ops/keys.rs
    https://github.com/liesware/Vectis/blob/main/src/core/config.rs
    https://github.com/liesware/Vectis/blob/main/src/core/fpe.rs
    https://github.com/liesware/Vectis/blob/main/doc/ENV.md
    https://github.com/liesware/Vectis#crypto-profiles


    Ya kutosha kwa nishani!

    Mifumo ya usalama ya chaguo-msingi ndani ya programu inayozalishwa na mradi LAZIMA ISITEGEMEE algoriti zilizovunjika za kriptologia (k.m., MD4, MD5, DES moja, RC4, Dual_EC_DRBG), au kutumia hali za cipher ambazo si sahihi kwa muktadha, isipokuwa ni muhimu kutekeleza itifaki inayoweza kushirikiana (ambapo itifaki iliyotekelezwa ni toleo la hivi karibuni zaidi la kiwango hicho kinachotegemeana sana na mfumo wa mtandao, mfumo huo unahitaji matumizi ya algoriti au hali hiyo, na mfumo huo haupatii chaguo lolote salama zaidi). Nyaraka LAZIMA zieleze hatari zozote za usalama husika na upungufu wowote unaojulikana ikiwa algoriti hizi zilizovunjika au hali ni muhimu kwa itifaki inayoweza kushirikiana. [crypto_working]
    Hali ya ECB ni karibu kamwe haifai kwa sababu inaonyesha block zinazofanana ndani ya ciphertext kama ilivyoonyeshwa na penguin wa ECB, na hali ya CTR mara nyingi si sahihi kwa sababu haifanyi uthibitishaji na husababisha nakala ikiwa hali ya ingizo inarudiwa. Katika hali nyingi ni bora kuchagua hali ya algoriti ya block cipher iliyoundwa kuchanganya siri na uthibitishaji, k.m., Galois/Counter Mode (GCM) na EAX. Miradi YAWEZA kuwaruhusu watumiaji kuwasha taratibu zilizovunjika (k.m., wakati wa usanidi) ambapo ni muhimu kwa upatanifu, lakini hapo watumiaji wanajua wanafanya hivyo.

    Vectis does not use cryptographic algorithms known to be broken, including MD4, MD5, SHA-1, DES, Triple DES, RC4, or Dual_EC_DRBG.

    The default profile uses BLAKE2b(256), ChaCha20Poly1305, Ed25519, X25519, ML-DSA-44, and ML-KEM-512. Other supported profiles use SHA-3, AES-GCM,
    Ed25519 or Ed448, X25519 or X448, ML-DSA, and ML-KEM.

    Encryption uses authenticated encryption modes: ChaCha20Poly1305 or AES-GCM. Stored internal material uses AES-256/GCM, and FPE uses FF1 with AES-256 and enforces a minimum domain size. Keyed operations use HMAC or KMAC. HTTPS uses rustls and its modern TLS defaults.

    Algorithm selection is restricted through explicit allowlists. The default profile-only policy rejects request-supplied algorithm overrides, and no compatibility fallback enables broken algorithms or inappropriate cipher modes.

    Vectis currently has no interoperability requirement that requires a broken algorithm, so no exception or legacy-risk mitigation is necessary.

    Evidence:
    https://github.com/liesware/Vectis/blob/main/src/core/crypto.rs
    https://github.com/liesware/Vectis/blob/main/src/core/config.rs
    https://github.com/liesware/Vectis/blob/main/src/ops/keys.rs
    https://github.com/liesware/Vectis/blob/main/src/core/fpe.rs
    https://github.com/liesware/Vectis/blob/main/Cargo.toml
    https://github.com/liesware/Vectis/blob/main/doc/ThreatModel.md


    Ya kutosha kwa nishani!

    Mifumo ya usalama ya chaguo-msingi ndani ya programu inayozalishwa na mradi INAPASWA ISITEGEMEE algoriti za kriptologia au hali zenye udhaifu mkubwa unaojulikana (k.m., algoriti ya hash ya kriptologia ya SHA-1 au hali ya CBC katika SSH). [crypto_weaknesses]
    Wasiwasi kuhusu hali ya CBC katika SSH unajadiliwa katika CERT: SSH CBC vulnerability.

    Vectis default security mechanisms do not depend on cryptographic algorithms or modes with known serious weaknesses.

    The default cryptographic profile uses BLAKE2b(256), ChaCha20Poly1305, Ed25519, X25519, ML-DSA-44, and ML-KEM-512. Internal storage encryption uses
    AES-256/GCM. Other supported profiles use SHA-3 and AES-GCM with stronger parameter sets.

    Vectis does not use SHA-1, MD5, DES, Triple DES, RC4, ECB, unauthenticated CBC encryption, or legacy TLS cipher suites. Encryption uses authenticated
    modes with contextual AAD, while TLS is provided through rustls with modern defaults.

    FPE uses FF1 with AES-256 and validates the minimum domain size required by the current FF1 specification. The default profile-only policy also prevents
    requests from selecting arbitrary cryptographic algorithms.

    Evidence:
    https://github.com/liesware/Vectis/blob/main/src/core/config.rs
    https://github.com/liesware/Vectis/blob/main/src/core/crypto.rs
    https://github.com/liesware/Vectis/blob/main/src/ops/keys.rs
    https://github.com/liesware/Vectis/blob/main/src/core/fpe.rs
    https://github.com/liesware/Vectis/blob/main/Cargo.toml
    https://github.com/liesware/Vectis/blob/main/doc/ENV.md


    Kwa shida ya kutosha kwa nishani.

    Mifumo ya usalama ndani ya programu iliyotengenezwa na mradi INAPASWA kutekeleza kwa ukamilifu usiri wa umbele ya itifaki za makubaliano ya funguo ili funguo la kipindi kilicho tokana na kikao cha vifungo muda-mrefu haziwezi kuridhi mabaya ikiwa mojawapo ya vifunguo vya muda-mrefu imeridhi mabaya katika usoni. [crypto_pfs]

    Vectis partially satisfies this criterion through TLS: HTTPS connections use rustls and modern ephemeral TLS key exchange.

    However, the protected-message protocol does not currently provide full perfect forward secrecy. Each sender generates a fresh ephemeral X25519 or
    X448 key and a fresh ML-KEM encapsulation, but both are established against the recipient's persistent operational public keys.

    The envelope retains the sender's ephemeral public key, ML-KEM ciphertext, salt, and encrypted payload. An attacker who records an envelope and later
    obtains the recipient's complete operational private key material could reconstruct both shared secrets and derive the historical message key.

    Fresh per-message key establishment prevents key and nonce reuse and isolates messages from each other, but it does not protect historical messages after
    recipient long-term key compromise.

    Evidence:
    https://github.com/liesware/Vectis/blob/main/src/ops/message.rs
    https://github.com/liesware/Vectis/blob/main/doc/ThreatModel.md
    https://github.com/liesware/Vectis/blob/main/doc/Design.md


    Ya kutosha kwa nishani!

    Ikiwa programu iliyotengenezwa na mradi imesababisha uhifadhi wa nywila kwa minajili ya uthibitishaji ya watumiaji wa kutoka nje, nywila LAZIMA zihifadhiwe kwa mficho uliorudiarudia na chumvi kwa kila-mtumiaji kwa kutumia kanuni ya upanuaji (rudiarudia) wa funguo (k.m., Argon2id, Bcrypt, Scrypt, or PBKDF2). Ona pia Kurasadogo ya Uhifadhi wa Nywila la OWASP). [crypto_password_storage]
    Kigezo hili linatumika tu wakati programu linatekeleza uthibitishaji wa watumiaji kutumia nywila kwa watumiaji wa nje (ambayo pia ni uthibitishaji unaelekezwa ndani), kama vile programu za tovuti zinazobakia seva). Haitumiki katika visa ambavyo programu inahifadhi nywila ili kudhibitisha ndani ya mifumo mingine (ambayo pia ni ithibitishaji unaelekezwa nje, k.m., programu inatekeleza teja la mfumo lingineyo), maana angalau sehemu za programu lazima ziwe na njia ya kupata hiyo nywila isigalifichwa.

    Not applicable. Vectis does not provide password-based authentication and does not store passwords belonging to external users.

    HTTP authentication uses high-entropy API keys generated from a CSPRNG. The server stores a keyed HMAC verifier derived from protected init key material,
    rather than storing the API key in plaintext. Client authorization data uses the same keyed identifier model inside signed configuration.

    The unseal key, database credentials, TLS private keys, and similar operator secrets are not external-user passwords and are governed by separate storage
    and deployment controls.

    Evidence:
    https://github.com/liesware/Vectis/blob/main/src/ops/apikey.rs
    https://github.com/liesware/Vectis/blob/main/src/ops/internal_keys.rs
    https://github.com/liesware/Vectis/blob/main/src/core/permissions.rs
    https://github.com/liesware/Vectis/blob/main/doc/ThreatModel.md
    https://github.com/liesware/Vectis/blob/main/doc/ENV.md


    Ya kutosha kwa nishani!

    Mifumo ya usalama ndani ya programu iliyotengenezwa na mradi LAZIMA itoe funguo zote za kriptologia na nonces kwa kutumia kitengeneza cha nambari za bahati kuptia kriptologia salama, na ISIWEZE kufanya hivo kutumia vitengenezi zisizo salama kikriptologia. [crypto_random]
    Kitengeneza cha nambari za bahati nasibu za kriptologia salama kinaweza kuwa kitengeneza cha nambari za bahati nasibu za vifaa, au kinaweza kuwa kitengeneza cha nambari za bahati nasibu za kriptologia salama (CSPRNG) kwa kutumia algoriti kama vile Hash_DRBG, HMAC_DRBG, CTR_DRBG, Yarrow, au Fortuna. Mifano ya simu kwa vitengeneza cha nambari za bahati nasibu salama ni pamoja na java.security.SecureRandom ya Java na window.crypto.getRandomValues ya JavaScript. Mifano ya simu kwa vitengeneza cha nambari za bahati nasibu zisizo salama ni pamoja na java.util.Random ya Java na Math.random ya JavaScript.

    Vectis generates cryptographic keys, nonces, salts, tokens, commitment openings, and secret-sharing coefficients using Botan's cryptographically
    secure random number generator.

    The core crypto module centralizes random generation through RandomNumberGenerator::new(), random_bytes(), and random_bytes_with_rng(). Cryptographic operations may reuse one Botan RNG during a single operation, but they do not replace it with a non-cryptographic generator.

    This CSPRNG is used for:

    • symmetric and asymmetric operational key generation;
    • EdDSA, X25519/X448, ML-DSA, ML-KEM, and SLH-DSA material;
    • AES-GCM and ChaCha20Poly1305 nonces;
    • ML-KEM and HKDF salts;
    • reversible random tokens;
    • commitment openings;
    • Shamir secret-sharing coefficients and set identifiers;
    • API keys, unseal keys, signature serials, and audit chain identifiers.

    Non-cryptographic counters used for request correlation are not used as keys, nonces, salts, tokens, or other cryptographic material. Vectis does not use
    thread_rng, fastrand, timestamps, counters, or similar non-cryptographic sources for security-sensitive randomness.

    Evidence:
    https://github.com/liesware/Vectis/blob/main/src/core/crypto.rs
    https://github.com/liesware/Vectis/blob/main/src/ops/key_material.rs
    https://github.com/liesware/Vectis/blob/main/src/ops/message.rs
    https://github.com/liesware/Vectis/blob/main/src/core/tokenization.rs
    https://github.com/liesware/Vectis/blob/main/src/core/sharing.rs
    https://github.com/liesware/Vectis/blob/main/src/ops/commitments.rs
    https://github.com/liesware/Vectis/blob/main/src/ops/init.rs


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


    Ya kutosha kwa nishani!

    Mradi LAZIMA utumie utaratibu wa utoaji ambao unakabiliana na mashambulizi ya MITM. Kutumia https au ssh+scp ni inakubaliwa. [delivery_mitm]
    Utaratibu wenye nguvu zaidi ni kutoa programu na vifurushi vilivyosainiwa kidigitali, kwa kuwa hiyo inapunguza mashambulizi kwenye mfumo wa usambazaji, lakini hii inafanya kazi tu ikiwa watumiaji wanaweza kuwa na uhakika kwamba funguo za umma kwa saini ni sahihi na ikiwa watumiaji watakagua saini kweli kweli.

    Distribution channels use HTTPS exclusively. [osps_br_03_02]


    Ya kutosha kwa nishani!

    Hash ya kriptologia (k.m., sha1sum) LAZIMA ISICHUKULIWE kupitia http na kutumika bila kuangalia saini ya kriptologia. [delivery_unsigned]
    Hash hizi zinaweza kurekebishwa wakati wa usafiri.

    Vectis does not retrieve cryptographic hashes over plain HTTP and use them for integrity decisions without signature verification.

    Source and dependency downloads use HTTPS. Cargo dependencies are resolved through Cargo.lock, which records package checksums and pins the Git-based FPEdependency to a specific commit. Container base images are referenced by immutable SHA-256 digests.

    Release SHA256SUMS are generated locally inside the trusted GitHub Actions release workflow; they are not downloaded from an untrusted HTTP source.
    Release archives also receive GitHub build-provenance attestations before publication.

    No build, installation, update, or release workflow retrieves a checksum over plain HTTP and then trusts that checksum without an authenticated mechanism.

    Evidence:
    https://github.com/liesware/Vectis/blob/main/Cargo.lock
    https://github.com/liesware/Vectis/blob/main/image/Dockerfile.tag
    https://github.com/liesware/Vectis/blob/main/.github/workflows/release.yml
    https://github.com/liesware/Vectis/blob/main/.github/workflows/release-image.yml


  • Udhaifu uliofahamika hadharani umeshughulikiwa


    Ya kutosha kwa nishani!

    LAZIMA kuwe hakuna udhaifu usiorekebishwa wa kiwango cha kati au juu zaidi ambao umejulikana hadharani kwa zaidi ya siku 60. [vulnerabilities_fixed_60_days]
    Udhaifu lazima urekebishwe na kutolewa na mradi wenyewe (rekebisho zinaweza kutengenezwa mahali pengine). Udhaifu unakuwa unajulikana hadharani (kwa kusudi hili) mara tu unapata CVE yenye taarifa zilizotolewa hadharani zisizolipwa (zilizoripotiwa, kwa mfano, katika Hifadhidata ya Taifa ya Udhaifu) au wakati mradi umefahamishwa na taarifa imetolewa kwa umma (labda na mradi). Udhaifu unazingatiwa kuwa wa kiwango cha kati au juu ikiwa alama yake ya Common Vulnerability Scoring System (CVSS) ya msingi ya ubora ni kati au juu. Katika matoleo ya CVSS 2.0 hadi 3.1, hii ni sawa na alama ya CVSS ya 4.0 au zaidi. Miradi inaweza kutumia alama ya CVSS kama ilivyochapishwa katika hifadhidata ya udhaifu inayotumika sana (kama vile Hifadhidata ya Taifa ya Udhaifu) kwa kutumia toleo la hivi karibuni la CVSS lililoripotiwa katika hifadhidata hiyo. Miradi badala yake inaweza kuhesabu ukali wao wenyewe kwa kutumia toleo la hivi karibuni la CVSS wakati wa ufunuzi wa udhaifu, ikiwa ingizo la hesabu linatangazwa hadharani mara tu udhaifu unajulikana hadharani. Kumbuka: hii inamaanisha kwamba watumiaji wanaweza kuachwa katika hatari kwa washambuliaji wote duniani kwa siku hadi 60. Kigezo hiki ni rahisi zaidi kukidhi kuliko yale Google inapendekeza katika Rebooting responsible disclosure, kwa sababu Google inapendekeza kwamba kipindi cha siku 60 kianze wakati mradi unafahamishwa hata ikiwa ripoti si ya umma. Pia kumbuka kwamba kigezo hiki cha nishani, kama vigezo vingine, kinatumika kwa mradi wa mtu binafsi. Baadhi ya miradi ni sehemu ya mashirika makubwa ya mwavuli au miradi mikubwa, labda katika safu nyingi, na miradi mingi inatoa matokeo yao kwa mashirika mengine na miradi kama sehemu ya mnyororo wa usambazaji wenye utata. Mradi wa mtu binafsi mara nyingi hauwezi kudhibiti wengine, lakini mradi wa mtu binafsi unaweza kufanya kazi kutoa rekebisho ya udhaifu kwa wakati. Kwa hiyo, tunazingatia tu muda wa jibu wa mradi wa mtu binafsi. Mara tu rekebisho inapatikana kutoka kwa mradi wa mtu binafsi, wengine wanaweza kuamua jinsi ya kushughulikia rekebisho (k.m., wanaweza kusasisha kwenye toleo jipya au wanaweza kutumia rekebisho tu kama suluhisho lililochaguliwa-cherry).

    As of 2026-08-21, Vectis has no publicly known unpatched vulnerability of Medium, High, or Critical severity that has remained unresolved for more than
    60 days.

    The project runs cargo audit in CI against the committed Cargo.lock. A current scan of 362 Rust dependencies completed successfully with no vulnerabilities.
    The previously reported RUSTSEC-2026-0258 vulnerability in h2 was remediated by upgrading to h2 0.4.16.

    Container release candidates are scanned with Trivy before publication, and CodeQL analyzes the source code. Security findings and dependency updates are
    handled through the documented vulnerability-reporting process.

    Evidence:
    https://github.com/liesware/Vectis/blob/main/.github/workflows/Rust.yml
    https://github.com/liesware/Vectis/blob/main/.github/workflows/codeql.yml
    https://github.com/liesware/Vectis/blob/main/.github/workflows/release-image.yml
    https://github.com/liesware/Vectis/blob/main/Cargo.lock
    https://github.com/liesware/Vectis/blob/main/SECURITY.md
    https://github.com/liesware/Vectis/blob/main/doc/SelfAssessment.md


    Ya kutosha kwa nishani!

    Miradi INAPASWA kurekebisha udhaifu wote muhimu haraka baada ya kuripotiwa. [vulnerabilities_critical_fixed]

    No Critical severity vulnerability has been reported or publicly identified in Vectis to date, and no confirmed Critical vulnerability remains unresolved.

    Vectis accepts private vulnerability reports through its published security policy, aims to acknowledge reports within five business days, provides status
    updates during investigation, and coordinates fixes and disclosure with the reporter.

    Critical findings would receive immediate triage and an expedited tested release before coordinated public disclosure. Cargo Audit, CodeQL, Trivy,
    OpenSSF Scorecard, and security-focused testing provide continuous detection paths for vulnerabilities requiring this response.

    Because no Critical vulnerability has been reported, Vectis does not yet have a historical Critical-vulnerability remediation time to report.

    Evidence:
    https://github.com/liesware/Vectis/blob/main/SECURITY.md
    https://github.com/liesware/Vectis/blob/main/.github/workflows/Rust.yml
    https://github.com/liesware/Vectis/blob/main/.github/workflows/codeql.yml
    https://github.com/liesware/Vectis/blob/main/.github/workflows/release-image.yml
    https://github.com/liesware/Vectis/blob/main/doc/SelfAssessment.md


  • Masuala mengine ya usalama


    Ya kutosha kwa nishani!

    Hazina za umma LAZIMA ZISIVUJE uthibitisho halali wa faragha (k.m., nywila inayofanya kazi au funguo ya faragha) ambayo imekusudiwa kupunguza upatikanaji wa umma. [no_leaked_credentials]
    Mradi UNAWEZA kuvuja uthibitisho wa "sampuli" kwa majaribio na hifadhidata zisizo muhimu, mradi tu hazikusudiwa kupunguza upatikanaji wa umma.

    Vectis public repositories do not contain valid private credentials intended to control access to private resources.

    Runtime secret files such as .env, .unseal_key, init.json, TLS private keys, databases, generated configuration, and local demo state are excluded from
    version control. Demo and integration scripts generate temporary credentials at runtime instead of embedding reusable credentials.

    GitHub Actions retrieves publishing credentials through the GitHub Secrets context. The Helm chart accepts secrets through operator-supplied values or an
    existing Kubernetes Secret and does not contain populated credentials.

    Values shown in env.dist and documentation are synthetic localhost examples. They do not grant access to any public or private service and are not production
    credentials.

    A review of tracked files and repository history found no committed private-key blocks or recognizable live access-token formats.

    Evidence:
    https://github.com/liesware/Vectis/blob/main/.gitignore
    https://github.com/liesware/Vectis/blob/main/env.dist
    https://github.com/liesware/Vectis/blob/main/charts/vectis/values.yaml
    https://github.com/liesware/Vectis/blob/main/charts/vectis/templates/secret.yaml
    https://github.com/liesware/Vectis/blob/main/.github/workflows/release-image.yml
    https://github.com/liesware/Vectis/blob/main/SECURITY.md


 Uchanganuzi 8/8 ●

  • Uchambuzi tuli wa msimbo


    Ya kutosha kwa nishani!

    Angalau zana moja ya uchambuzi wa msimbo tuli (zaidi ya maonyo ya mkusanyaji na hali za lugha "salama") LAZIMA itumike kwa toleo lolote lililopendekezwa kubwa la uzalishaji wa programu kabla ya toleo lake, ikiwa kuna angalau zana moja ya FLOSS inayotekeleza kigezo hiki katika lugha iliyochaguliwa. [static_analysis]
    Zana ya uchambuzi wa msimbo tuli inachunguza msimbo wa programu (kama msimbo wa chanzo, msimbo wa kati, au utekelezaji) bila kuutekeleza na ingizo maalum. Kwa madhumuni ya kigezo hiki, maonyo ya mkusanyaji na hali za lugha "salama" hazihesabiwi kama zana za uchambuzi wa msimbo tuli (hizi kwa kawaida huepuka uchambuzi wa kina kwa sababu kasi ni muhimu). Baadhi ya zana za uchambuzi wa msimbo tuli zinazingatia kugundua hitilafu za jumla, nyingine zinazingatia kupata aina fulani za hitilafu (kama vile udhaifu), na baadhi hufanya mchanganyiko. Mifano ya zana hizo za uchambuzi wa msimbo tuli ni pamoja na cppcheck (C, C++), clang static analyzer (C, C++), SpotBugs (Java), FindBugs (Java) (ikiwa ni pamoja na FindSecurityBugs), PMD (Java), Brakeman (Ruby on Rails), lintr (R), goodpractice (R), Coverity Quality Analyzer, SonarQube, Codacy, na HP Enterprise Fortify Static Code Analyzer. Orodha kubwa za zana zinaweza kupatikana katika maeneo kama vile orodha ya Wikipedia ya zana za uchambuzi wa msimbo tuli, taarifa za OWASP kuhusu uchambuzi wa msimbo tuli, orodha ya NIST ya vichambua usalama wa msimbo wa chanzo, na orodha ya Wheeler ya zana za uchambuzi tuli. Ikiwa hakuna zana za uchambuzi tuli za FLOSS zinazopatikana kwa lugha za utekelezaji zilizotumika, unaweza kuchagua 'N/A'.

    Vectis uses CodeQL as a static source-code analysis tool beyond compiler warnings and Rust's memory-safety guarantees.

    CodeQL analyzes both Rust source code and GitHub Actions workflows. It runs for pull requests targeting main, every push to main, on a weekly schedule, and on manual request. Proposed release commits are merged into main and reviewed through this analysis before being tagged for release.

    Cargo Clippy, Cargo Audit, Trivy, and OpenSSF Scorecard provide additional analysis, but CodeQL is the static source-code analysis mechanism used to
    satisfy this criterion.

    Evidence:
    https://github.com/liesware/Vectis/blob/main/.github/workflows/codeql.yml
    https://github.com/liesware/Vectis/actions/workflows/codeql.yml
    https://github.com/liesware/Vectis/security/code-scanning


    Ya kutosha kwa nishani!

    INAPENDEKEZWA kwamba angalau moja ya zana za uchambuzi tuli zilizotumika kwa kigezo cha static_analysis ijumuishe sheria au njia za kutafuta udhaifu wa kawaida katika lugha au mazingira yaliyochambuliwa. [static_analysis_common_vulnerabilities]
    Zana za uchambuzi tuli ambazo zimeundwa hasa kutafuta udhaifu wa kawaida zina uwezekano mkubwa wa kuzipata. Hata hivyo, kutumia zana zozote za tuli kwa kawaida itasaidia kupata baadhi ya matatizo, kwa hivyo tunashauri lakini hatunahitaji hii kwa kiwango cha nishani ya 'kupita'.

    Vectis uses the CodeQL default security query suite for Rust and GitHub Actions.

    The Rust query suite includes vulnerability-focused data-flow and source-to-sink analysis mapped to common CWE categories, including:

    • SQL injection;
    • server-side request forgery;
    • path and regular-expression injection;
    • log injection and sensitive-data logging;
    • cleartext storage and transmission;
    • disabled TLS certificate verification;
    • hard-coded cryptographic values;
    • weak cryptographic algorithms;
    • uncontrolled allocation sizes;
    • invalid pointer and lifetime access.

    CodeQL also analyzes GitHub Actions workflows for security-relevant workflow issues. The analysis runs on pull requests, pushes to main, weekly, and on
    manual request.

    Evidence:
    https://github.com/liesware/Vectis/blob/main/.github/workflows/codeql.yml
    https://github.com/liesware/Vectis/security/code-scanning
    https://docs.github.com/en/code-security/code-scanning/managing-your-code-scanning-configuration/rust-built-in-queries
    https://codeql.github.com/codeql-query-help/rust-cwe/


    Ya kutosha kwa nishani!

    Udhaifu wote wenye ukali wa kati na juu zaidi unaoweza kudhoofishwa uliogundulika kupitia uchambuzi wa msimbo tuli LAZIMA urekebishwe kwa wakati baada ya kuthibitishwa. [static_analysis_fixed]
    Udhaifu unazingatiwa kuwa wa kiwango cha kati au juu zaidi ikiwa alama yake ya Common Vulnerability Scoring System (CVSS) ya msingi ya ubora ni kati au juu. Katika matoleo ya CVSS 2.0 hadi 3.1, hii ni sawa na alama ya CVSS ya 4.0 au zaidi. Miradi inaweza kutumia alama ya CVSS kama ilivyochapishwa katika hifadhidata ya udhaifu inayotumika sana (kama vile Hifadhidata ya Taifa ya Udhaifu) kwa kutumia toleo la hivi karibuni la CVSS lililoripotiwa katika hifadhidata hiyo. Miradi badala yake inaweza kuhesabu ukali wao wenyewe kwa kutumia toleo la hivi karibuni la CVSS wakati wa ufunuzi wa udhaifu, ikiwa ingizo la hesabu linatangazwa hadharani mara tu udhaifu unajulikana hadharani. Kumbuka kwamba kigezo cha vulnerabilities_fixed_60_days kinahitaji kwamba udhaifu wote kama huo urekebishwe ndani ya siku 60 baada ya kuwa wa umma.

    Not applicable at present. CodeQL has not produced a confirmed exploitable Medium, High, or Critical severity vulnerability in Vectis that requires
    remediation.

    CodeQL continues to analyze Rust source code and GitHub Actions on pull requests, pushes to main, weekly, and on manual request. Any future finding is
    reviewed to distinguish an exploitable vulnerability from a false positive or non-security issue.

    A confirmed exploitable finding of Medium severity or higher will be fixed, covered by a regression test where practical, and recorded in the relevant
    release notes or security advisory.

    Evidence:
    https://github.com/liesware/Vectis/security/code-scanning
    https://github.com/liesware/Vectis/blob/main/.github/workflows/codeql.yml
    https://github.com/liesware/Vectis/blob/main/SECURITY.md
    https://github.com/liesware/Vectis/blob/main/CHANGELOG.md


    Ya kutosha kwa nishani!

    INAPENDEKEZWA kwamba uchambuzi wa msimbo wa chanzo tuli ufanyike kwenye kila ahadi au angalau kila siku. [static_analysis_often]

    Vectis runs static source-code analysis on every commit that is proposed for or integrated into the main branch.

    The CodeQL workflow is triggered by:

    • every push to main;
    • every pull request targeting main, including new commits pushed to that PR;
    • a weekly scheduled scan as a fallback;
    • manual workflow dispatch.

    Therefore, each commit entering the supported development and release branch is analyzed without relying solely on the scheduled scan.

    Evidence:
    https://github.com/liesware/Vectis/blob/main/.github/workflows/codeql.yml
    https://github.com/liesware/Vectis/actions/workflows/codeql.yml


  • Uchambuzi wa msimbo wa nguvu za ziada


    Ya kutosha kwa nishani!

    INAPENDEKEZWA kwamba angalau zana moja ya uchambuzi wa nguvu itumike kwenye toleo kubwa lolote la uzalishaji lililopendekezwa la programu 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.

    Vectis applies dynamic analysis to every change proposed for or integrated into the main branch.

    The CI integration job starts a real Vectis server with generated keys and configuration, then runs project-specific HTTP mutation testing and
    OpenAPI-based property testing with Schemathesis. These tools exercise live handlers, parsers, validation, authorization, cryptographic workflows, and
    failure paths using generated and mutated inputs.

    Vectis also runs its native cargo-fuzz targets weekly with sanitizer instrumentation and accumulated corpora. This workflow can be triggered manually before a major production release.


    Ya kutosha kwa nishani!

    INAPENDEKEZWA kwamba ikiwa programu iliyozalishwa na mradi inajumuisha programu iliyoandikwa kwa kutumia lugha isiyosalama ya kumbukumbu (k.m., C au C++), basi angalau zana moja ya nguvu (k.m., fuzzer au kitafutaji cha programu ya wavuti) itumike kwa kawaida kwa pamoja na utaratibu wa kugundua matatizo ya usalama wa kumbukumbu kama vile uandikaji zaidi wa kipengele. Ikiwa mradi hauzalishi programu iliyoandikwa katika lugha isiyosalama ya kumbukumbu, chagua "haihusiki" (N/A). [dynamic_analysis_unsafe]
    Mifano ya taratibu za kugundua matatizo ya usalama wa kumbukumbu ni pamoja na Address Sanitizer (ASAN) (inapatikana katika GCC na LLVM), Memory Sanitizer, na valgrind. Zana nyingine zinazoweza kutumika ni pamoja na thread sanitizer na undefined behavior sanitizer. Madai ya kila mahali pia yaweza kufanya kazi.

    Not applicable. Vectis is implemented in Rust and does not include project-maintained production code written in a memory-unsafe language such as
    C or C++.

    Vectis interfaces with Botan through FFI, but Botan is an external dependency rather than memory-unsafe source code produced or maintained by the Vectis
    project. Native fuzzing and sanitizer-based testing are nevertheless used to exercise Vectis input-processing boundaries.


    Ya kutosha kwa nishani!

    INAPENDEKEZWA kwamba mradi utumie usanidi wa angalau baadhi ya uchambuzi wa nguvu (kama vile majaribio au fuzzing) ambao huwezesha madai mengi. Katika hali nyingi madai haya yasipaswi kuwa yamewezeshwa katika mijengo ya uzalishaji. [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.

    Vectis runs its automated test suite using Rust's test profile. This profile enables debug assertions and integer overflow checks that are not enabled by
    default in production release builds.

    The test suite contains assertions covering validation, cryptographic round-trips, lifecycle rules, authorization, storage, audit-chain integrity,
    and HTTP contracts. Native cargo-fuzz targets add explicit semantic assertions for properties such as canonical serialization, stable encoding, sanitized
    errors, and parser round-trips.

    These assertion-enabled test and fuzz configurations are separate from the production release profile.


    Ya kutosha kwa nishani!

    Udhaifu wote wenye ukali wa kati na juu zaidi unaoweza kudhoofishwa uliogundulika kupitia uchambuzi wa msimbo wa nguvu LAZIMA urekebishwe kwa wakati baada ya kuthibitishwa. [dynamic_analysis_fixed]
    Ikiwa haujafanya uchambuzi wa msimbo wa nguvu na kwa hivyo hukupata udhaifu wowote kwa njia hii, chagua "haihusiki" (N/A). Udhaifu unazingatiwa kuwa wa kiwango cha kati au juu zaidi ikiwa alama yake ya Common Vulnerability Scoring System (CVSS) ya msingi ya ubora ni kati au juu. Katika matoleo ya CVSS 2.0 hadi 3.1, hii ni sawa na alama ya CVSS ya 4.0 au zaidi. Miradi inaweza kutumia alama ya CVSS kama ilivyochapishwa katika hifadhidata ya udhaifu inayotumika sana (kama vile Hifadhidata ya Taifa ya Udhaifu) kwa kutumia toleo la hivi karibuni la CVSS lililoripotiwa katika hifadhidata hiyo. Miradi badala yake inaweza kuhesabu ukali wao wenyewe kwa kutumia toleo la hivi karibuni la CVSS wakati wa ufunuzi wa udhaifu, ikiwa ingizo la hesabu linatangazwa hadharani mara tu udhaifu unajulikana hadharani.

    Not applicable at present. Vectis has no outstanding confirmed exploitable vulnerabilities of Medium or higher severity discovered through dynamic
    analysis.

    Findings produced by fuzzing and dynamic API testing are investigated before being dismissed. Confirmed defects are fixed, added to the regression test
    suite, and preserved as readable fuzz seeds when applicable.

    A recent canonical JSON fuzzing finding was corrected with centralized input validation, unit and HTTP regression tests, and a permanent cargo-fuzz seed. It was not formally classified as a Medium-or-higher vulnerability.



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 Liesware na wachangiaji wa nishani ya Mazoea Bora ya OpenSSF.

Ingizo la nishani ya mradi linamilikiwa na: Liesware.
Ingizo liliundwa siku 2026-08-21 14:40:13 UTC, iliyosasishwa mara ya mwisho siku 2026-08-21 16:38:28 UTC.