Vigezo vya Mazoea Bora vya FLOSS (Viwango Vyote)

Hii ni seti ya mazoea bora kwa miradi ya Programu Huru na Zana Huria (FLOSS) ili kupata nishani za Mazoea Bora za Open Source Security Foundation (OpenSSF) katika viwango vya nishani inayopita, fedha, na dhahabu. Unaweza kuonyesha orodha hii na vigezo tu au na taarifa za ziada. Pia unaweza kuona tu vigezo vya kupita, fedha, na dhahabu, pamoja na takwimu za vigezo.

Ona mjadala wa vigezo kwa maelezo zaidi kuhusu vigezo hivi.

Kupita

Misingi

Maudhui ya kimsingi ya tovuti ya mradi

• Tovuti ya mradi LAZIMA ieleze kwa ufupi programu inafanya nini (inasuluhu tatizo gani?). ^{[description_good]}

  Maelezo:

  Hii LAZIMA iwe katika lugha ambayo watumiaji watarajiwa wanaweza kuelewa (k.m., inatumia lugha ya kiufundi kidogo).

• Tovuti ya mradi LAZIMA itoe habari juu ya jinsi ya: kupata, kutoa maoni (kama ripoti za hitilafu au maboresho), na kuchangia kwenye programu. ^[interact]
• Habari juu ya jinsi ya kuchangia LAZIMA ieleze mchakato wa uchangiaji (kwa mfano, je! Maombi ya kuvuta yanatumika?) {URL iliyokidiwa} ^{[contribution]}

  Maelezo:

  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?)

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

Leseni ya FLOSS

• Programu iliyozalishwa na mradi LAZIMA itolewa kama FLOSS. ^{[floss_license]}

  Maelezo:

  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:

  • leseni iliyoidhinishwa na Open Source Initiative (OSI), au
  • leseni huria kama ilivyoidhinishwa na Free Software Foundation (FSF), au
  • leseni huria inayokubalika kwa Debian main, au
  • leseni "nzuri" kulingana na Fedora.

  Programu YAWEZA pia kupatiwa leseni kwa njia nyingine (k.m., "GPLv2 au ya kibinafsi" inakubaliwa).

• INAPENDEKEZA kwamba leseni yoyote inayohitajika kwa programu iliyozalishwa na mradi iwe imeidhinishwa na Open Source Initiative (OSI). ^{[floss_license_osi]}

  Maelezo:

  OSI inatumia mchakato mgumu wa uidhinishaji kuamua ni leseni zipi ni OSS.

• Mradi LAZIMA uweke leseni za matokeo yake mahali pa kawaida katika hazina yake ya chanzo. {URL iliyokidiwa} ^{[license_location]}

  Maelezo:

  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.

Nyaraka

• Mradi LAZIMA utoe nyaraka za msingi za programu iliyozalishwa na mradi. {N/A sababu} ^{[documentation_basics]}

  Maelezo:

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

• Mradi LAZIMA utoe nyaraka za marejeleo zinazofafanua kiolesura cha nje (ingizo na matokeo) cha programu iliyozalishwa na mradi. {N/A sababu} ^{[documentation_interface]}

  Maelezo:

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

Mengine

• Tovuti za mradi (tovuti, hifadhi, na URL za kupakua) LAZIMA zisaidie HTTPS kwa kutumia TLS. ^{[sites_https]}

  Maelezo:

  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.

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

  Maelezo:

  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.

• Mradi UNAPASWA kutoa nyaraka kwa Kiingereza na uweze kukubali ripoti za hitilafu na maoni kuhusu msimbo kwa Kiingereza. ^[english]

  Maelezo:

  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.

• Mradi LAZIMA utunzwe. ^[maintained]

  Maelezo:

  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.

Udhibiti wa Mabadiliko

Hifadhi ya chanzo ya kudhibiti toleo ya hadharani

• Mradi LAZIMA uwe na hifadhi ya chanzo ya kudhibiti toleo ambayo inaweza kusomwa hadharani na ina URL. ^{[repo_public]}

  Maelezo:

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

• Hifadhi ya chanzo ya mradi LAZIMA ifuatilie mabadiliko yaliyofanywa, nani alifanya mabadiliko, na mabadiliko yalifanywa lini. ^[repo_track]
• 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]}

  Maelezo:

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

• INASHAURIWA kwamba programu ya kawaida ya udhibiti wa toleo iliyosambazwa itumike (k.m., git) kwa hifadhi ya chanzo ya mradi. ^{[repo_distributed]}

  Maelezo:

  Git haihitajiki kihususa na miradi inaweza kutumia programu ya udhibiti wa toleo iliyokusanyika (kama subversion) na sababu.

Unambari wa toleo wa kipekee

• Matokeo ya mradi LAZIMA yawe na kitambulisho cha kipekee cha toleo kwa kila toleo linalokusudiwa kutumiwa na watumiaji. ^{[version_unique]}

  Maelezo:

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

• 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]}

  Maelezo:

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

• 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]}

Maelezo ya kutolewa

• 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". {N/A sababu} {URL iliyokidiwa} ^{[release_notes]}

  Maelezo:

  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.

• 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. {N/A sababu} ^{[release_notes_vulns]}

  Maelezo:

  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.

Kuripoti

Mchakato wa kuripoti hitilafu

• Mradi LAZIMA utoe mchakato kwa watumiaji kuwasilisha ripoti za hitilafu (k.m., kwa kutumia kifuatiliaji cha masuala au orodha ya barua pepe). {URL iliyokidiwa} ^{[report_process]}
• Mradi UNAPASWA kutumia kifuatiliaji cha masuala kwa kufuatilia masuala ya mtu binafsi. ^{[report_tracker]}
• Mradi LAZIMA uthibitishe wengi wa ripoti za hitilafu zilizowasilishwa katika miezi 2-12 iliyopita (ikiwemo); jibu halihitaji kuwa na marekebisho. ^{[report_responses]}
• Mradi UNAPASWA kujibu wengi (>50%) wa maombi ya maboresho katika miezi 2-12 iliyopita (ikiwemo). ^{[enhancement_responses]}

  Maelezo:

  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.

• Mradi LAZIMA uwe na kumbukumbu inayopatikana hadharani kwa ripoti na majibu kwa utaftaji wa baadaye. {URL iliyokidiwa} ^{[report_archive]}

Mchakato wa kuripoti udhaifu

• Mradi LAZIMA uchapishe mchakato wa kuripoti udhaifu kwenye tovuti ya mradi. {URL iliyokidiwa} ^{[vulnerability_report_process]}

  Maelezo:

  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.

• Ikiwa ripoti za udhaifu wa faragha zinasaidiwa, mradi LAZIMA ujumuishe jinsi ya kutuma habari kwa njia ambayo inawekwa faragha. {N/A inaruhusiwa} {URL iliyokidiwa} ^{[vulnerability_report_private]}

  Maelezo:

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

• 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. {N/A inaruhusiwa} ^{[vulnerability_report_response]}

  Maelezo:

  Ikiwa hakujawa na udhaifu ulioripotiwa katika miezi 6 iliyopita, chagua "haihusiki" (N/A).

Ubora

Mfumo wa ujenzi unaofanya kazi

• Ikiwa programu iliyotengenezwa na mradi inahitaji ujenzi wa matumizi, mradi LAZIMA utoe mfumo wa kujenga ambao unaweza kujenga programu kiotomatiki kutoka kwa chanzo-msimbo. {N/A inaruhusiwa} ^[build]

  Maelezo:

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

• INAPENDEKEZWA kuwa zana za kawaida zitumike kujenga programu. {N/A inaruhusiwa} ^{[build_common_tools]}

  Maelezo:

  Kwa mfano, Maven, Ant, cmake, autotools, make, rake (Ruby), au devtools (R).

• Mradi UNAPASWA kujengwa kwa kutumia zana za FLOSS pekee yake. {N/A inaruhusiwa} ^{[build_floss_tools]}

Seti ya majaribio otomatiki

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

  Maelezo:

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

• Seti ya majaribio INAPASWA kuwa inaweza kuitwa kwa njia ya kawaida kwa lugha hiyo. ^{[test_invocation]}

  Maelezo:

  Kwa mfano, "make check", "mvn test", au "rake test" (Ruby).

• INAPENDEKEZWA kwamba seti ya majaribio ifuate wengi (au kwa kawaida wote) matawi ya msimbo, sehemu za kuingiza, na utendakazi. ^[test_most]
• 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]}

Upimaji wa utendaji mpya

• 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]}

  Maelezo:

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

• 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]}

  Maelezo:

  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.

• INAPENDEKEZWA kwamba sera hii ya kuongeza majaribio (angalia test_policy) iwe imeandikwa katika maelekezo ya mapendekezo ya mabadiliko. ^{[tests_documented_added]}

  Maelezo:

  Hata hivyo, hata sheria isiyo rasmi inakubaliwa mradi majaribio yaongezwe kimakosa.

Bendera za maonyo

• 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. {N/A inaruhusiwa} ^[warnings]

  Maelezo:

  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.

• Mradi LAZIMA ukabiliane na maonyo. {N/A inaruhusiwa} ^{[warnings_fixed]}

  Maelezo:

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

• INAPENDEKEZWA kwamba miradi iwe na ukali mkubwa sana na maonyo katika programu inayotengenezwa na mradi, ambapo ni ya vitendo. {N/A inaruhusiwa} ^{[warnings_strict]}

  Maelezo:

  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.

Usalama

Maarifa ya maendeleo yenye usalama

• Mradi LAZIMA uwe na angalau msanidi mmoja mkuu anayejua jinsi ya kuunda programu salama. (Angalia 'maelezo' kwa mahitaji halisi.) ^{[know_secure_design]}

  Maelezo:

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

• 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]}

  Maelezo:

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

Tumia mazoea mazuri ya msingi ya usimbuaji

• 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). {N/A inaruhusiwa} ^{[crypto_published]}

  Maelezo:

  Vigezo hivi vya kriptografia mara mingi havitumiki kwa sababu programu zingine hazina haja ya kutumia moja kwa moja uwezo wa kriptografia.

• 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. {N/A inaruhusiwa} ^{[crypto_call]}
• Utendaji wote katika programu iliyotengenezwa na mradi ambayo inategemea usimbuaji LAZIMA iweze kutekelezwa kwa kutumia FLOSS. {N/A inaruhusiwa} ^{[crypto_floss]}

  Maelezo:

  Tazama Mahitaji ya Viwango wazi ya Programu kupitia Open Source Initiative.

• 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. {N/A inaruhusiwa} ^{[crypto_keylength]}

  Maelezo:

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

• 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. {N/A inaruhusiwa} ^{[crypto_working]}

  Maelezo:

  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.

• 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). {N/A inaruhusiwa} ^{[crypto_weaknesses]}

  Maelezo:

  Wasiwasi kuhusu hali ya CBC katika SSH unajadiliwa katika CERT: SSH CBC vulnerability.

• 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. {N/A inaruhusiwa} ^[crypto_pfs]
• 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). {N/A inaruhusiwa} ^{[crypto_password_storage]}

  Maelezo:

  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.

• 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. {N/A inaruhusiwa} ^{[crypto_random]}

  Maelezo:

  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.

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

• Mradi LAZIMA utumie utaratibu wa utoaji ambao unakabiliana na mashambulizi ya MITM. Kutumia https au ssh+scp ni inakubaliwa. ^{[delivery_mitm]}

  Maelezo:

  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.

• Hash ya kriptologia (k.m., sha1sum) LAZIMA ISICHUKULIWE kupitia http na kutumika bila kuangalia saini ya kriptologia. ^{[delivery_unsigned]}

  Maelezo:

  Hash hizi zinaweza kurekebishwa wakati wa usafiri.

Udhaifu uliofahamika hadharani umeshughulikiwa

• LAZIMA kuwe hakuna udhaifu usiorekebishwa wa kiwango cha kati au juu zaidi ambao umejulikana hadharani kwa zaidi ya siku 60. ^{[vulnerabilities_fixed_60_days]}

  Maelezo:

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

• Miradi INAPASWA kurekebisha udhaifu wote muhimu haraka baada ya kuripotiwa. ^{[vulnerabilities_critical_fixed]}

Masuala mengine ya usalama

• 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]}

  Maelezo:

  Mradi UNAWEZA kuvuja uthibitisho wa "sampuli" kwa majaribio na hifadhidata zisizo muhimu, mradi tu hazikusudiwa kupunguza upatikanaji wa umma.

Uchanganuzi

Uchambuzi tuli wa msimbo

• 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. {N/A sababu} {Sababu iliyokidiwa} ^{[static_analysis]}

  Maelezo:

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

• 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. {N/A inaruhusiwa} ^{[static_analysis_common_vulnerabilities]}

  Maelezo:

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

• Udhaifu wote wenye ukali wa kati na juu zaidi unaoweza kudhoofishwa uliogundulika kupitia uchambuzi wa msimbo tuli LAZIMA urekebishwe kwa wakati baada ya kuthibitishwa. {N/A inaruhusiwa} ^{[static_analysis_fixed]}

  Maelezo:

  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.

• INAPENDEKEZWA kwamba uchambuzi wa msimbo wa chanzo tuli ufanyike kwenye kila ahadi au angalau kila siku. {N/A inaruhusiwa} ^{[static_analysis_often]}

Uchambuzi wa msimbo wa nguvu za ziada

• 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]}

  Maelezo:

  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.

• 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). {N/A inaruhusiwa} ^{[dynamic_analysis_unsafe]}

  Maelezo:

  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.

• 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]}

  Maelezo:

  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.

• 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. {N/A inaruhusiwa} ^{[dynamic_analysis_fixed]}

  Maelezo:

  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.

Fedha

Misingi

Mahitaji ya awali

• Mradi LAZIMA ufikie nishani ya kiwango cha kuhitimu. ^{[achieve_passing]}

Maudhui ya kimsingi ya tovuti ya mradi

• Habari juu ya jinsi ya kuchangia LAZIMA ijumuishe mahitaji ya michango inayokubalika (k.m., rejea kwa kiwango chochote kinachohitajika cha msimbo). {URL iliyokidiwa} ^{[contribution_requirements]}

Usimamizi wa mradi

• Mradi UNAPASWA kuwa na utaratibu wa kisheria ambapo wasanidi wote wa kiasi kisicho kidogo cha programu ya mradi wanathibitisha kwamba wameruhusiwa kisheria kufanya michango hii. Mbinu ya kawaida na rahisi ya kutekeleza hii ni kwa kutumia Cheti cha Msanidi cha Asili (DCO), ambapo watumiaji huongeza "signed-off-by" katika ahadi zao na mradi unaunganisha kwenye tovuti ya DCO. Hata hivyo, hii YAWEZA kutekelezwa kama Makubaliano ya Leseni ya Mchangiaji (CLA), au utaratibu mwingine wa kisheria. {URL iliyokidiwa} ^[dco]

  Maelezo:

  DCO ni utaratibu unaopendekeza kwa sababu ni rahisi kutekeleza, kufuatilia katika msimbo wa chanzo, na git inasaidia moja kwa moja kipengele cha "signed-off" kwa kutumia "commit -s". Ili kuwa na ufanisi zaidi ni bora ikiwa nyaraka za mradi zinaeleza maana ya "signed-off" kwa mradi huo. CLA ni makubaliano ya kisheria yanayofafanua masharti ambayo kazi za kiakili zimetolewa leseni kwa shirika au mradi. Makubaliano ya mgawo wa mchangiaji (CAA) ni makubaliano ya kisheria yanayohamisha haki katika kazi ya kiakili kwa chama kingine; miradi haihitajiki kuwa na CAA, kwa kuwa kuwa na CAA huongeza hatari kwamba wachangiaji watarajiwa hawatachangia, hasa ikiwa mpokeaji ni shirika la faida. Apache Software Foundation CLAs (leseni ya mchangiaji wa mtu binafsi na CLA ya kampuni) ni mifano ya CLA, kwa miradi ambayo inaamua kwamba hatari za aina hizi za CLA kwa mradi ni chini ya manufaa yao.

• Mradi LAZIMA ufafanue kwa uwazi na kuandika muundo wake wa utawala wa mradi (njia ya kufanya maamuzi, ikiwa ni pamoja na majukumu muhimu). {URL iliyokidiwa} ^[governance]

  Maelezo:

  Kunahitaji kuwa na njia fulani iliyowekwa vyema ya kuandikwa ya kufanya maamuzi na kutatua migogoro. Katika miradi midogo, hii inaweza kuwa rahisi kama "mmiliki wa mradi na kiongozi hufanya maamuzi yote ya mwisho". Kuna miundo mbalimbali ya utawala, ikiwa ni pamoja na dictator wa wema na meritocracy rasmi; kwa maelezo zaidi, angalia Miundo ya utawala. Mbinu zote mbili za kati (k.m., mtunzaji mmoja) na zisizo za kati (k.m., watunzaji wa kikundi) zimetumika kwa mafanikio katika miradi. Habari za utawala hazihitajiki kuandika uwezekano wa kuunda uma wa mradi, kwa kuwa hiyo ni iwezekanavyo kila wakati kwa miradi ya FLOSS.

• Mradi LAZIMA upitishe kanuni ya mwenendo na kuiweka mahali pa kawaida. {URL iliyokidiwa} ^{[code_of_conduct]}

  Maelezo:

  Miradi inaweza kuweza kuboresha uadilifu wa jamii yao na kuweka matarajio kuhusu tabia inayokubalika kwa kupitisha kanuni ya mwenendo. Hii inaweza kusaidia kuepuka matatizo kabla hayajatokea na kufanya mradi kuwa mahali pa kukaribishwa zaidi ili kuhimiza michango. Hii inapaswa kuzingatia tu tabia ndani ya jamii/mahali pa kazi pa mradi. Mifano ya kanuni za mwenendo ni kanuni ya mwenendo ya kernel ya Linux, Kanuni ya Mwenendo ya Agano la Mchangiaji, Kanuni ya Mwenendo ya Debian, Kanuni ya Mwenendo ya Ubuntu, Kanuni ya Mwenendo ya Fedora, Kanuni ya Mwenendo ya GNOME, Kanuni ya Mwenendo ya Jamii ya KDE, Kanuni ya Mwenendo ya Jamii ya Python, Mwongozo wa Mwenendo wa Jamii ya Ruby, na Kanuni ya Mwenendo ya Rust.

• Mradi LAZIMA ufafanue kwa uwazi na kuandika hadharani majukumu muhimu katika mradi na wajibu wao, ikiwa ni pamoja na kazi zozote ambazo majukumu hayo lazima yafanywe. Lazima iwe wazi ni nani ana jukumu lipi, ingawa hii haiwezi kuandikwa kwa njia ile ile. {URL iliyokidiwa} ^{[roles_responsibilities]}

  Maelezo:

  Nyaraka kwa utawala na majukumu na wajibu zinaweza kuwa mahali pamoja.

• Mradi LAZIMA uweze kuendelea kwa usumbufu mdogo ikiwa mtu yeyote anakufa, anakuwa katika hali ya kudhoofika, au vinginevyo hawezi au hataki kuendelea kusaidia mradi. Hasa, mradi LAZIMA uweze kuunda na kufunga masuala, kukubali mabadiliko yaliyopendekezwa, na kutoa matoleo ya programu, ndani ya wiki moja ya uthibitishaji wa upotevu wa msaada kutoka kwa mtu yeyote mmoja. Hii INAWEZA kufanywa kwa kuhakikisha mtu mwingine ana funguo zozote zinazohitajika, nywila, na haki za kisheria ili kuendelea mradi. Watu binafsi wanaoendesha mradi wa FLOSS WANAWEZA kufanya hii kwa kuweka funguo katika sanduku la kufungia na wosia unaowezesha haki zozote zinazohitajika za kisheria (k.m., kwa majina ya DNS). {URL iliyokidiwa} ^{[access_continuity]}
• Mradi INAPASWA kuwa na "bus factor" ya 2 au zaidi. {URL iliyokidiwa} ^[bus_factor]

  Maelezo:

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

Nyaraka

• Mradi LAZIMA uwe na ramani ya barabara iliyoandikwa inayoeleza kile mradi unakusudia kufanya na kutofanya kwa angalau mwaka unaofuata. {URL iliyokidiwa} ^{[documentation_roadmap]}

  Maelezo:

  Mradi huenda usitimiza ramani ya barabara, na hiyo ni sawa; kusudi la ramani ya barabara ni kusaidia watumiaji na wachangiaji watarajiwa kuelewa mwelekeo unaokusudiwa wa mradi. Haihitaji kuwa na maelezo mengi.

• Mradi LAZIMA ujumuishe nyaraka za muundo (pia inajulikana kama muundo wa kiwango cha juu) wa programu inayozalishwa na mradi. Ikiwa mradi hauzalishi programu, chagua "haihusiki" (N/A). {N/A sababu} {URL iliyokidiwa} ^{[documentation_architecture]}

  Maelezo:

  Muundo wa programu unaeleza miundo ya msingi ya programu, yaani, vipengele vikuu vya programu, uhusiano kati yao, na mali muhimu za vipengele na uhusiano hivi.

• Mradi LAZIMA uandike kile mtumiaji anaweza na asiweze kutarajia kwa suala la usalama kutoka kwa programu inayozalishwa na mradi ("mahitaji yake ya usalama"). {N/A inaruhusiwa} {URL iliyokidiwa} ^{[documentation_security]}

  Maelezo:

  Haya ni mahitaji ya usalama ambayo programu inakusudiwa kukidhi.

• Mradi LAZIMA utoe mwongozo wa "kuanza haraka" kwa watumiaji wapya kuwasaidia kufanya kitu haraka na programu. {N/A sababu} {URL iliyokidiwa} ^{[documentation_quick_start]}

  Maelezo:

  Wazo ni kuonyesha watumiaji jinsi ya kuanza na kufanya programu ifanye chochote. Hii ni muhimu sana kwa watumiaji watarajiwa kuanza.

• Mradi LAZIMA ufanye jitihada ya kuweka nyaraka kulingana na toleo la sasa la matokeo ya mradi (ikiwa ni pamoja na programu inayozalishwa na mradi). Kasoro yoyote inayojulikana ya nyaraka inayofanya isilingane LAZIMA irekebishwe. Ikiwa nyaraka kwa ujumla ni za sasa, lakini kwa makosa inajumuisha baadhi ya maelezo ya zamani ambayo sio ya kweli tena, ichukue tu kama kasoro, kisha ifuatilie na urekebishe kama kawaida. {N/A sababu} {Sababu iliyokidiwa} ^{[documentation_current]}

  Maelezo:

  Nyaraka ZINAWEZA kujumuisha habari kuhusu tofauti au mabadiliko kati ya matoleo ya programu na/au kuunganisha kwa matoleo ya zamani ya nyaraka. Kusudi la kigezo hiki ni kwamba jitihada inafanywa ili kuweka nyaraka kulingana, siyo kwamba nyaraka lazima ziwe kamili.

• Ukurasa wa mbele wa hifadhi ya mradi na/au tovuti LAZIMA utambulishe na kuunganisha kiungo kwa mafanikio yoyote, ikiwa ni pamoja na nishani hii ya mazoea bora, ndani ya masaa 48 ya kutambua hadharani kwamba ufanikio umepatikana. {URL iliyokidiwa} ^{[documentation_achievements]}

  Maelezo:

  Ufanikio ni seti yoyote ya vigezo vya nje ambavyo mradi umefanya kazi mahususi kukidhi, ikiwa ni pamoja na nishani fulani. Habari hii haihitaji kuwa kwenye ukurasa wa mbele wa tovuti ya mradi. Mradi unaotumia GitHub unaweza kuweka mafanikio kwenye ukurasa wa mbele wa hifadhi kwa kuyaongeza kwenye faili ya README.

Ufikiaji na kimataifa

• Mradi (tovuti zote za mradi na matokeo ya mradi) INAPASWA kufuata mazoea bora ya ufikiaji ili watu wenye ulemavu bado waweze kushiriki katika mradi na kutumia matokeo ya mradi ambapo ni busara kufanya hivyo. {N/A sababu} {Sababu iliyokidiwa} ^{[accessibility_best_practices]}

  Maelezo:

  Kwa programu za wavuti, angalia Miongozo ya Ufikiaji wa Maudhui ya Wavuti (WCAG 2.0) na hati yake inayosaidia Kuelewa WCAG 2.0; angalia pia habari za ufikiaji za W3C. Kwa programu za GUI, zingatia kutumia miongozo ya ufikiaji ya mazingira maalum (kama vile Gnome, KDE, XFCE, Android, iOS, Mac, na Windows). Baadhi ya programu za TUI (k.m., programu za `ncurses`) zinaweza kufanya mambo fulani ili kuzifanya kufikika zaidi (kama mpangilio wa `force-arrow-cursor` wa `alpine`). Programu nyingi za mstari wa amri zinafikika vizuri kama zilivyo. Kigezo hiki mara nyingi ni N/A, k.m., kwa maktaba za programu. Hapa kuna baadhi ya mifano ya hatua za kuchukua au masuala ya kuzingatia:

  • Toa mbadala za maandishi kwa maudhui yoyote yasiyo ya maandishi ili yaweze kubadilishwa kuwa aina nyingine watu wanahitaji, kama vile chapa kubwa, braille, hotuba, alama au lugha rahisi zaidi ( mwongozo wa WCAG 2.0 1.1)
  • Rangi haitumiwi kama njia pekee ya kuona ya kuwasilisha habari, kuashiria kitendo, kuchochea jibu, au kutofautisha kipengele cha kuona. ( mwongozo wa WCAG 2.0 1.4.1)
  • Uwasilishaji wa kuona wa maandishi na picha za maandishi una uwiano wa tofauti wa angalau 4.5:1, isipokuwa kwa maandishi makubwa, maandishi ya bahati mbaya, na nembo ( mwongozo wa WCAG 2.0 1.4.3)
  • Fanya kazi zote zipatikane kutoka kwenye kibodi (mwongozo wa WCAG 2.1)
  • Mradi wa GUI au wa wavuti INAPASWA kupima na angalau kipaza sauti kimoja cha skrini kwenye jukwaa la lengo (k.m., NVDA, Jaws, au WindowEyes kwenye Windows; VoiceOver kwenye Mac & iOS; Orca kwenye Linux/BSD; TalkBack kwenye Android). Programu za TUI ZINAWEZA kufanya kazi kupunguza uchanganyiko wa ziada ili kuzuia usomaji wa ziada na vipaza sauti vya skrini.

• Programu iliyozalishwa na mradi INAPASWA kuwa kimataifa ili kuwezesha upatanifu wa lugha wa rahisi kwa utamaduni, eneo, au lugha ya hadhira lengo. Ikiwa kimataifa (i18n) haihusiki (k.m., programu haizalishi maandishi yanayokusudiwa kwa watumiaji wa mwisho na haipangi maandishi yanayosomeka na binadamu), chagua "haihusiki" (N/A). {N/A sababu} {Sababu iliyokidiwa} ^{[internationalization]}

  Maelezo:

  Upatanifu wa lugha "unarejelea upatanifu wa bidhaa, programu au maudhui ya hati ili kukidhi lugha, utamaduni na mahitaji mengine ya soko mahususi la lengo (eneo)." Kimataifa ni "muundo na maendeleo ya bidhaa, programu au maudhui ya hati ambayo huwezesha upatanifu wa lugha wa rahisi kwa hadhira lengo zinazotofautiana katika utamaduni, eneo, au lugha." (Ona "Upatanifu wa Lugha dhidi ya Kimataifa" ya W3C.) Programu inakidhi kigezo hiki kwa kuwa kimataifa tu. Hakuna upatanifu wa lugha kwa lugha nyingine mahususi unaohitajika, kwa kuwa mara tu programu imekuwa kimataifa inawezekana kwa wengine kufanya kazi kwenye upatanifu wa lugha.

Mengine

• Ikiwa tovuti za mradi (tovuti, hifadhi, na URL za kupakua) zinahifadhi nywila kwa ajili ya uthibitishaji wa watumiaji wa nje, nywila LAZIMA zihifadhiwe kama mificho iliyorudiwa na chumvi kwa-mtumiaji kwa kutumia kanuni ya upanuaji (iliyorudiarudia) wa funguo (k.m., Argon2id, Bcrypt, Scrypt, au PBKDF2). Ikiwa tovuti za mradi hazihifadhi nywila kwa kusudi hili, chagua "haihusiki" (N/A). {N/A sababu} {Sababu iliyokidiwa} ^{[sites_password_security]}

  Maelezo:

  Kumbuka kwamba matumizi ya GitHub yanakidhi kigezo hiki. Kigezo hiki kinatumika tu kwa nywila zinazotumika kwa ajili ya uthibitishaji wa watumiaji wa nje kwenye tovuti za mradi (pia inaitwa uthibitishaji wa ndani). Ikiwa tovuti za mradi lazima ziingie kwenye tovuti zingine (pia inaitwa uthibitishaji wa nje), zinaweza kuhitaji kuhifadhi ishara za uidhinishaji kwa kusudi hilo kwa njia tofauti (kwa kuwa kuhifadhi mficho hakuna maana). Hii inatumia kigezo cha crypto_password_storage kwa tovuti za mradi, sawa na sites_https.

Udhibiti wa Mabadiliko

Matoleo ya awali

• Mradi LAZIMA utunze matoleo ya zamani yaliyotumika mara nyingi ya bidhaa au kutoa njia ya usasishaji kwa matoleo mapya. Ikiwa njia ya usasishaji ni ngumu, mradi LAZIMA uandike jinsi ya kufanya usasishaji (k.m., violesura vilivyobadilika na hatua zilizoanishwa kwa undani ili kusaidia usasishaji). {N/A sababu} {Sababu iliyokidiwa} ^{[maintenance_or_update]}

Kuripoti

Mchakato wa kuripoti hitilafu

• Mradi LAZIMA utumie kifuatiliaji cha masuala kwa ajili ya kufuatilia masuala ya mtu binafsi. {N/A sababu} {Sababu iliyokidiwa} ^{[report_tracker]}

Mchakato wa kuripoti udhaifu

• Mradi LAZIMA utoe sifa kwa waripoti wa ripoti zote za udhaifu zilizotatuliwa katika miezi 12 iliyopita, isipokuwa kwa waripoti wanaoomba kutojulikana. Ikiwa hakuna udhaifu uliotatuliwa katika miezi 12 iliyopita, chagua "haihusiki" (N/A). {N/A sababu} {URL iliyokidiwa} ^{[vulnerability_report_credit]}
• Mradi LAZIMA uwe na mchakato ulioandikwa kwa ajili ya kujibu ripoti za udhaifu. {URL iliyokidiwa} ^{[vulnerability_response_process]}

  Maelezo:

  Hii ina uhusiano mkubwa na vulnerability_report_process, ambayo inahitaji kuwa kuna njia iliyoandikwa ya kuripoti udhaifu. Pia inahusiana na vulnerability_report_response, ambayo inahitaji majibu kwa ripoti za udhaifu ndani ya kipindi fulani cha muda.

Ubora

Viwango vya msimbo

• Mradi LAZIMA utambulishe miongozo mahususi ya mtindo wa kuandika msimbo kwa lugha kuu inazotumia, na uhitaji kwamba michango kwa ujumla ikidhi. {N/A sababu} {URL iliyokidiwa} ^{[coding_standards]}

  Maelezo:

  Katika hali nyingi hii inafanywa kwa kurejelea baadhi ya miongozo ya mtindo iliyopo, huenda ikiorodhesha tofauti. Miongozo hii ya mtindo inaweza kujumuisha njia za kuboresha usomaji na njia za kupunguza uwezekano wa kasoro (ikiwa ni pamoja na udhaifu). Lugha nyingi za programu zina miongozo moja au zaidi ya mtindo inayotumika sana. Mifano ya miongozo ya mtindo ni pamoja na miongozo ya mtindo ya Google na Viwango vya Kuandika Msimbo wa SEI CERT.

• Mradi LAZIMA utekeleze kiotomatiki mtindo wake wa kuandika msimbo uliochaguliwa ikiwa kuna angalau zana moja ya FLOSS inayoweza kufanya hivyo katika lugha zilizochaguliwa. {N/A sababu} {Sababu iliyokidiwa} ^{[coding_standards_enforced]}

  Maelezo:

  Hii INAWEZA kutekelezwa kwa kutumia zana za uchambuzi mkako na/au kwa kulazimisha msimbo kupitia vifaa vya kurekebisha msimbo. Katika hali nyingi usanidi wa zana umejumuishwa katika hifadhi ya mradi (kwa kuwa miradi tofauti inaweza kuchagua usanidi tofauti). Miradi INAWEZA kuruhusu vighairi vya mtindo (na kwa kawaida itaruhusu); ambapo vighairi vinatokea, LAZIMA viwe nadra na viandikwe katika msimbo katika maeneo yao, ili vighairi hivi viweze kukaguliwa na ili zana ziweze kuzishughulikia kiotomatiki baadaye. Mifano ya zana kama hizo ni pamoja na ESLint (JavaScript), Rubocop (Ruby), na devtools check (R).

Mfumo wa ujenzi unaofanya kazi

• Mifumo ya kujenga kwa binari za asili LAZIMA iheshimu vigezo (vya mazingira) vya mkusanyaji na vya kiunganishi vilivyopitishwa kwao (k.m., CC, CFLAGS, CXX, CXXFLAGS, na LDFLAGS) na kuvipitisha kwenye viito vya mkusanyaji na vya kiunganishi. Mfumo wa kujenga UNAWEZA kuvipanua na bendera za ziada; LAZIMA USIBADILISHE thamani zilizotolewa na zake mwenyewe. Ikiwa hakuna binari za asili zinazozalishwa, chagua "haihusiki" (N/A). {N/A sababu} {Sababu iliyokidiwa} ^{[build_standard_variables]}

  Maelezo:

  Inapaswa kuwa rahisi kuwezesha vipengele maalum vya kujenga kama Address Sanitizer (ASAN), au kutii mazoea bora ya ugumu wa usambazaji (k.m., kwa kuwezesha kwa urahisi bendera za mkusanyaji kufanya hivyo).

• Mfumo wa kujenga na usakinishaji UNAPASWA kuhifadhi taarifa za utatuzi ikiwa zimeombwa katika bendera husika (k.m., "install -s" haitumiwa). Ikiwa hakuna mfumo wa kujenga au usakinishaji (k.m., maktaba za kawaida za JavaScript), chagua "haihusiki" (N/A). {N/A sababu} {Sababu iliyokidiwa} ^{[build_preserve_debug]}

  Maelezo:

  K.m., kuweka CFLAGS (C) au CXXFLAGS (C++) inapaswa kuunda taarifa husika za utatuzi ikiwa lugha hizo zinatumika, na hazipaswi kuondolewa wakati wa usakinishaji. Taarifa za utatuzi zinahitajika kwa msaada na uchambuzi, na pia ni muhimu kwa kupima uwepo wa vipengele vya ugumu katika binari zilizokusanywa.

• Mfumo wa kujenga kwa programu iliyozalishwa na mradi LAZIMA USIJENGA kwa njia ya kujirudia saraka ndogo ikiwa kuna utegemezi wa kukatana katika saraka ndogo. Ikiwa hakuna mfumo wa kujenga au usakinishaji (k.m., maktaba za kawaida za JavaScript), chagua "haihusiki" (N/A). {N/A sababu} {Sababu iliyokidiwa} ^{[build_non_recursive]}

  Maelezo:

  Taarifa ya utegemezi wa ndani ya mfumo wa kujenga wa mradi inahitaji kuwa sahihi, vinginevyo, mabadiliko ya mradi huenda yasijenge vizuri. Mijengo isiyo sahihi inaweza kusababisha kasoro (ikiwa ni pamoja na udhaifu). Kosa la kawaida katika mifumo mikubwa ya kujenga ni kutumia "ujenzi wa kujirudia" au "make ya kujirudia", yaani, mlingano wa saraka ndogo zinazojumuisha faili za chanzo, ambapo kila saraka ndogo inajengwa kwa uhuru. Isipokuwa kila saraka ndogo ni huru kabisa, hii ni kosa, kwa sababu taarifa ya utegemezi si sahihi.

• Mradi LAZIMA uweze kurudia mchakato wa kuzalisha taarifa kutoka faili za chanzo na kupata matokeo sawa ya biti-kwa-biti. Ikiwa hakuna ujenzi unaofanyika (k.m., lugha za uandishi ambapo msimbo wa chanzo unatumika moja kwa moja badala ya kukusanywa), chagua "haihusiki" (N/A). {N/A sababu} {Sababu iliyokidiwa} ^{[build_repeatable]}

  Maelezo:

  Watumiaji wa GCC na clang wanaweza kupata chaguo la -frandom-seed kuwa na manufaa; katika hali fulani, hii inaweza kutatuliwa kwa kulazimisha aina fulani ya mpangilio. Mapendekezo zaidi yanaweza kupatikana kwenye tovuti ya ujenzi unaorudiwa.

Mfumo wa usakinishaji

• Mradi LAZIMA utoe njia ya kusakinisha na kuondoa kwa urahisi programu iliyozalishwa na mradi kwa kutumia mkataba unaotumika sana. {N/A sababu} {Sababu iliyokidiwa} ^{[installation_common]}

  Maelezo:

  Mifano ni pamoja na kutumia meneja wa kifurushi (kwa mfumo au kiwango cha lugha), "make install/uninstall" (inasaidia DESTDIR), chombo katika muundo wa kawaida, au picha ya mashine pepe katika muundo wa kawaida. Mchakato wa usakinishaji na uondoaji (k.m., kifurushi chake) UNAWEZA kutekelezwa na mtu wa tatu mradi tu ni FLOSS.

• Mfumo wa usakinishaji kwa watumiaji wa mwisho LAZIMA uheshimu mkataba wa kawaida kwa kuchagua eneo ambapo vitu vilivyojengwa vinaandikwa kwa wakati wa usakinishaji. Kwa mfano, ikiwa inasakinisha faili kwenye mfumo wa POSIX lazima iheshimu kigezo cha mazingira cha DESTDIR. Ikiwa hakuna mfumo wa usakinishaji au hakuna mkataba wa kawaida, chagua "haihusiki" (N/A). {N/A sababu} {Sababu iliyokidiwa} ^{[installation_standard_variables]}
• Mradi LAZIMA utoe njia kwa wasanidi programu wanaoweza kusakinisha haraka matokeo yote ya mradi na mazingira ya msaada yanayohitajika kufanya mabadiliko, ikiwa ni pamoja na majaribio na mazingira ya majaribio. Hii LAZIMA ifanywe kwa kutumia mkataba unaotumika sana. {N/A sababu} {Sababu iliyokidiwa} ^{[installation_development_quick]}

  Maelezo:

  Hii INAWEZA kutekelezwa kwa kutumia chombo kilichozalishwa na/au hati za usakinishaji. Utegemezi wa nje kwa kawaida utasakinishwa kwa kuita mfumo na/au meneja wa kifurushi cha lugha, kwa external_dependencies.

Vipengee vilivyotunzwa nje

• Mradi LAZIMA uorodheshe utegemezi wa nje kwa njia inayoweza kuchakatwa na kompyuta. {N/A sababu} {URL iliyokidiwa} ^{[external_dependencies]}

  Maelezo:

  Kwa kawaida hii inafanywa kwa kutumia mkataba wa meneja wa kifurushi na/au mfumo wa ujenzi. Kumbuka kwamba hii inasaidia kutekeleza installation_development_quick.

• Miradi LAZIMA ifuatilie au kwa muda mrefu iangalie utegemezi wao wa nje (ikiwa ni pamoja na nakala za urahisi) kugundua udhaifu unaojulikana, na kurekebisha udhaifu unaoweza kutumiwa vibaya au kuthibitisha kuwa hauwezi kutumiwa vibaya. {N/A sababu} {Sababu iliyokidiwa} ^{[dependency_monitoring]}

  Maelezo:

  Hii inaweza kufanywa kwa kutumia zana ya kichambua chanzo / zana ya kuangalia utegemezi / zana ya uchambuzi wa muundo wa programu kama OWASP's Dependency-Check, Sonatype's Nexus Auditor, Synopsys' Black Duck Software Composition Analysis, na Bundler-audit (kwa Ruby). Baadhi ya waendesha kifurushi wanajumuisha taratibu za kufanya hii. Ni kubaliwa ikiwa udhaifu wa vipengele hauwezi kutumiwa vibaya, lakini uchambuzi huu ni mgumu na wakati mwingine ni rahisi kusasisha au kurekebisha sehemu.

• Mradi LAZIMA au:
  1. fanya iwe rahisi kutambua na kusasisha vipengele vinavyotumiwa tena vilivyotunzwa nje; au
  2. tumia vipengele vya kawaida vinavyotolewa na mfumo au lugha ya programu.
  Kisha, ikiwa udhaifu unapatikana katika kipengele kilichotumiwa tena, itakuwa rahisi kusasisha kipengele hicho. {N/A sababu} {Sababu iliyokidiwa} ^{[updateable_reused_components]}

  Maelezo:

  Njia ya kawaida ya kutimiza kigezo hiki ni kutumia mifumo ya usimamizi wa kifurushi ya mfumo na lugha ya programu. Programu nyingi za FLOSS zinasambazwa na "maktaba za urahisi" ambazo ni nakala za ndani za maktaba za kawaida (labda zilizoachana). Kwa yenyewe, hiyo ni sawa. Hata hivyo, ikiwa programu *lazima* itumie nakala hizi za ndani (zilizoachanishwa), basi kusasisha maktaba za "kawaida" kama sasisho la usalama litaacha nakala hizi za ziada bado zenye udhaifu. Hii ni suala hasa kwa mifumo ya wingu; ikiwa mtoa huduma ya wingu anasasisha maktaba zao za "kawaida" lakini programu haitazitumia, basi masasisho hayasaidii kweli. Angalia, k.m., "Chromium: Kwa nini bado haiko katika Fedora kama kifurushi sahihi" na Tom Callaway.

• Mradi UNAPASWA kuepuka kutumia vitendakazi na API zilizokubaliwa kuwa hazitumiki tena au zilizopitwa na wakati ambapo mbadala wa FLOSS zinapatikana katika seti ya teknolojia inayotumia ("kifurushi cha teknolojia" yake) na kwa wengi wa watumiaji ambao mradi unasaidia (ili watumiaji wawe na ufikiaji wa haraka wa mbadala). {N/A sababu} {Sababu iliyokidiwa} ^{[interfaces_current]}

Seti ya majaribio otomatiki

• Seti ya majaribio ya kiotomatiki LAZIMA itumike kwenye kila ukaguzi wa kuingia kwenye hifadhi iliyoshirikiwa kwa angalau tawi moja. Seti hii ya majaribio LAZIMA itoe ripoti ya mafanikio au kushindwa kwa majaribio. {Sababu iliyokidiwa} ^{[automated_integration_testing]}

  Maelezo:

  Mahitaji haya yanaweza kuonekana kama sehemu ndogo ya test_continuous_integration, lakini yanazingatia majaribio tu, bila kuhitaji uunganisho wa kuendelea.

• Mradi LAZIMA uongeze majaribio ya kurudi nyuma kwa seti ya majaribio ya kiotomatiki kwa angalau 50% ya hitilafu zilizorekebisha ndani ya miezi sita iliyopita. {N/A sababu} {Sababu iliyokidiwa} ^{[regression_tests_added50]}
• Mradi LAZIMA uwe na seti ya majaribio ya kiotomatiki ya FLOSS inayotoa angalau 80% ya usakinishaji wa taarifa ikiwa kuna angalau zana moja ya FLOSS inayoweza kupima kigezo hiki katika lugha iliyochaguliwa. {N/A sababu} {Sababu iliyokidiwa} ^{[test_statement_coverage80]}

  Maelezo:

  Zana nyingi za FLOSS zinapatikana kupima usakinishaji wa majaribio, ikiwa ni pamoja na gcov/lcov, Blanket.js, Istanbul, JCov, na covr (R). Kumbuka kwamba kutimiza kigezo hiki sio uhakika kwamba seti ya majaribio ni ya kina, badala yake, kushindwa kutimiza kigezo hiki ni kiashiria kizito cha seti ya majaribio mbaya.

Upimaji wa utendaji mpya

• Mradi LAZIMA uwe na sera rasmi iliyoandikwa kwamba kadri utendakazi mkubwa mpya unaongezwa, majaribio ya utendakazi mpya LAZIMA yaongezwe kwenye seti ya majaribio ya kiotomatiki. {N/A sababu} {Sababu iliyokidiwa} ^{[test_policy_mandated]}
• Mradi LAZIMA ujumuishe, katika maelekezo yake yaliyoandikwa kwa mapendekezo ya mabadiliko, sera kwamba majaribio yataongezwa kwa utendakazi mkubwa mpya. {N/A sababu} {Sababu iliyokidiwa} ^{[tests_documented_added]}

Bendera za maonyo

• Miradi LAZIMA iwe na ukali wa juu zaidi na maonyo katika programu iliyozalishwa na mradi, iwezekanavyo vitendo. {N/A sababu} {Sababu iliyokidiwa} ^{[warnings_strict]}

Usalama

Maarifa ya maendeleo yenye usalama

• Mradi LAZIMA utekeleze kanuni za muundo salama (kutoka "know_secure_design"), pale inapohusika. Ikiwa mradi hauzalishi programu, chagua "haihusiki" (N/A). {N/A sababu} {Sababu iliyokidiwa} ^{[implement_secure_design]}

  Maelezo:

  Kwa mfano, matokeo ya mradi yanapaswa kuwa na mipangilio salama ya kuzuia makosa (maamuzi ya ufikiaji yanapaswa kukataa kwa chaguo-msingi, na usakinishaji wa mradi unapaswa kuwa salama kwa chaguo-msingi). Pia yanapaswa kuwa na kikuu cha kati kikamilifu (kila ufikiaji ambao unaweza kuwekwa kikomo lazima ufanyiwe ukaguzi wa mamlaka na usiweze kuvukwa). Kumbuka kwamba katika hali fulani kanuni zitagombana, na katika hali hiyo chaguo lazima lifanywe (k.m., taratibu nyingi zinaweza kufanya mambo kuwa magumu zaidi, kukiuka "uchumi wa utaratibu" / iweke rahisi).

Tumia mazoea mazuri ya msingi ya usimbuaji

• Mifumo ya usalama ya chaguo-msingi ndani ya programu inayozalishwa na mradi LAZIMA 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). {N/A inaruhusiwa} {Sababu iliyokidiwa} ^{[crypto_weaknesses]}
• Mradi INAPASWA kusaidia algoriti nyingi za kriptologia, ili watumiaji waweze kubadilisha haraka ikiwa moja imevunjwa. Algoriti za kawaida za funguo za simetria ni pamoja na AES, Twofish, na Serpent. Mbadala wa algoriti za hash za kriptologia za kawaida ni pamoja na SHA-2 (ikiwa ni pamoja na SHA-224, SHA-256, SHA-384 NA SHA-512) na SHA-3. {N/A inaruhusiwa} {Sababu iliyokidiwa} ^{[crypto_algorithm_agility]}
• Mradi LAZIMA usaidie kuhifadhi vitambulisho vya uthibitishaji (kama vile nywila na ishara za nguvu) na funguo za kibinafsi za kriptologia katika mafaili ambayo yametengwa na habari nyingine (kama vile mafaili ya usanidi, hifadhidata, na kumbukumbu), na kuruhusu watumiaji kusasisha na kubadilisha bila ukusanyaji upya wa msimbo. Ikiwa mradi haufanyi usindikaji wa vitambulisho vya uthibitishaji na funguo za kibinafsi za kriptologia, chagua "haihusiki" (N/A). {N/A inaruhusiwa} {Sababu iliyokidiwa} ^{[crypto_credential_agility]}
• Programu iliyozalishwa na mradi INAPASWA kusaidia 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 ZINAPASWA kuzimwa kwa chaguo-msingi, na kuzimwa tu ikiwa mtumiaji anaisanidi mahususi. Ikiwa programu iliyozalishwa na mradi haiesaidii mawasiliano ya mtandao, chagua "haihusiki" (N/A). {N/A inaruhusiwa} {Sababu iliyokidiwa} ^{[crypto_used_network]}
• Programu iliyozalishwa na mradi INAPASWA, ikiwa inasaidia au inatumia TLS, kusaidia angalau toleo la TLS 1.2. Kumbuka kuwa kilichotangulia TLS kiliitwa SSL. Ikiwa programu haitumii TLS, chagua "haihusiki" (N/A). {N/A inaruhusiwa} {Sababu iliyokidiwa} ^{[crypto_tls12]}
• Programu iliyozalishwa na mradi LAZIMA, ikiwa inasaidia TLS, ifanye uthibitishaji wa cheti cha TLS kwa chaguo-msingi inapotumia TLS, ikiwa ni pamoja na rasilimali ndogo. Ikiwa programu haitumii TLS, chagua "haihusiki" (N/A). {N/A inaruhusiwa} {Sababu iliyokidiwa} ^{[crypto_certificate_verification]}

  Maelezo:

  Kumbuka kuwa uthibitishaji usio sahihi wa cheti cha TLS ni kosa la kawaida. Kwa maelezo zaidi, angalia "The Most Dangerous Code in the World: Validating SSL Certificates in Non-Browser Software" na Martin Georgiev et al. na "Do you trust this application?" na Michael Catanzaro.

• Programu iliyozalishwa na mradi LAZIMA, ikiwa inasaidia TLS, ifanye uthibitishaji wa cheti kabla ya kutuma vichwa vya HTTP na habari ya kibinafsi (kama vile vidakuzi salama). Ikiwa programu haitumii TLS, chagua "haihusiki" (N/A). {N/A inaruhusiwa} {Sababu iliyokidiwa} ^{[crypto_verification_private]}

Kutolewa kwa usalama

• Mradi LAZIMA uweke saini kwa kriptologia matoleo ya matokeo ya mradi yanayokusudiwa kwa matumizi ya kila mahali, na LAZIMA kuwe na mchakato ulioandikwa unaoweleza watumiaji jinsi wanaweza kupata funguo za umma za saini na kuthibitisha saini. Funguo ya kibinafsi kwa saini hizi LAZIMA ISIWE kwenye tovuti zinazosambaza moja kwa moja programu kwa umma. Ikiwa matoleo hayakusudiwa kwa matumizi ya kila mahali, chagua "haihusiki" (N/A). {N/A sababu} {Sababu iliyokidiwa} ^{[signed_releases]}

  Maelezo:

  Matokeo ya mradi ni pamoja na msimbo wa chanzo na matokeo yoyote yaliyozalishwa pale inapohusika (k.m., mifumo inayotekelezeka, vifurushi, na vyombo). Matokeo yaliyozalishwa YANAWEZA kuwekwa saini tofauti na msimbo wa chanzo. Hizi ZINAWEZA kutekelezwa kama lebo za git zilizowekwa saini (kwa kutumia saini za kidijitali za kriptologia). Miradi YAWEZA kutoa matokeo yaliyozalishwa tofauti na zana kama vile git, lakini katika hali hizo, matokeo tofauti LAZIMA yawekwe saini tofauti.

• INAPENDEKEZWA kuwa katika mfumo wa udhibiti wa toleo, kila lebo muhimu ya toleo (lebo ambayo ni sehemu ya toleo kuu, toleo dogo, au kurekebishwa udhaifu uliotangazwa hadharani) iwekwe saini kwa kriptologia na iweze kuthibitishwa kama ilivyoelezwa katika signed_releases. {Sababu iliyokidiwa} ^{[version_tags_signed]}

Masuala mengine ya usalama

• Matokeo ya mradi LAZIMA yafanye ukaguzi wa pembejeo zote kutoka vyanzo visivyoaminika ili kuhakikisha ni halali (*orodha zinazokubalika*), na kukataa pembejeo zisizo halali, ikiwa kuna vizuizi vyovyote kwenye data kabisa. {N/A sababu} {Sababu iliyokidiwa} ^{[input_validation]}

  Maelezo:

  Kumbuka kuwa kulinganisha ingizo dhidi ya orodha ya "miundo mibaya" (aka *orodha za kukataza*) kwa kawaida haitoshi, kwa sababu washambuliaji mara nyingi wanaweza kuepuka orodha ya kukataza. Hasa, nambari zinabadilishwa kuwa miundo ya ndani na kisha kuangaliwa ikiwa ziko kati ya chini na juu zao (ikiwa ni pamoja), na vifungu vya maandishi vinaangaliwa ili kuhakikisha kuwa ni ruwaza halali za maandishi (k.m., UTF-8 halali, urefu, sintaksia, n.k.). Baadhi ya data inaweza kuhitaji kuwa "chochote kabisa" (k.m., kipakia faili), lakini hizi kwa kawaida zingekuwa nadra.

• Taratibu za kuimarisha ZINAPASWA kutumiwa katika programu iliyozalishwa na mradi ili kasoro za programu ziwe na uwezekano mdogo wa kusababisha udhaifu wa usalama. {N/A sababu} {Sababu iliyokidiwa} ^[hardening]

  Maelezo:

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

• Mradi LAZIMA utoe kesi ya uhakika inayosababisha kwa nini mahitaji yake ya usalama yanakidhi. Kesi ya uhakika LAZIMA ijumuishe: maelezo ya muundo wa tishio, utambulisho wazi wa mipaka ya kuaminiwa, hoja kwamba kanuni za muundo salama zimetumika, na hoja kwamba udhaifu wa kawaida wa utekelezaji wa usalama umekabiliana nao. {URL iliyokidiwa} ^{[assurance_case]}

  Maelezo:

  Kesi ya uhakika ni "mwili wa ushahidi ulioandikwa unaotoa hoja inayoshawishi na halali kwamba seti maalum ya madai muhimu kuhusu mali za mfumo ziko na sababu za kutosha kwa programu maalum katika mazingira maalum" ("Uhakika wa Programu Kwa kutumia Miundo ya Kesi ya Uhakika Iliyopangwa", Thomas Rhodes et al, NIST Interagency Report 7608). Mipaka ya kuaminiwa ni mipaka ambapo data au utekelezaji hubadilisha kiwango chake cha kuaminiwa, k.m., mipaka ya seva katika programu ya kawaida ya wavuti. Ni ya kawaida kuorodhesha kanuni za muundo salama (kama vile Saltzer na Schroeer) na udhaifu wa kawaida wa utekelezaji wa usalama (kama vile OWASP top 10 au CWE/SANS top 25), na kuonyesha jinsi kila moja unavyokabiliana. Kesi ya uhakika ya BadgeApp inaweza kuwa mfano wenye manufaa. Hii inahusiana na documentation_security, documentation_architecture, na implement_secure_design.

Uchanganuzi

Uchambuzi tuli wa msimbo

• Mradi LAZIMA utumie angalau zana moja ya uchanganuzi tuli yenye sheria au mbinu za kutafuta udhaifu wa kawaida katika lugha au mazingira yaliyochanganuliwa, ikiwa kuna angalau zana moja ya FLOSS inayoweza kutekeleza kigezo hiki katika lugha iliyochaguliwa. {N/A sababu} {Sababu iliyokidiwa} ^{[static_analysis_common_vulnerabilities]}

Uchambuzi wa msimbo wa nguvu za ziada

• 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) LAZIMA 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). {N/A sababu} {Sababu iliyokidiwa} ^{[dynamic_analysis_unsafe]}

Dhahabu

Misingi

Mahitaji ya awali

• Mradi LAZIMA ufikie kiwango cha nishani ya fedha. ^{[achieve_silver]}

Usimamizi wa mradi

• Mradi LAZIMA uwe na "bus factor" ya 2 au zaidi. {URL iliyokidiwa} ^[bus_factor]
• Mradi LAZIMA uwe na angalau wachangiaji wawili wasiohusika. {URL iliyokidiwa} ^{[contributors_unassociated]}

  Maelezo:

  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.

Mengine

• Mradi LAZIMA ujumuishe tamko la hakimiliki katika kila faili ya chanzo, ikitambulisha mmiliki wa hakimiliki (k.m., wachangiaji wa [jina la mradi]). {Sababu iliyokidiwa} ^{[copyright_per_file]}

  Maelezo:

  Hii YAWEZA kufanyika kwa kujumuisha yafuatayo ndani ya maoni karibu na mwanzo wa kila faili: "Copyright the [project name] contributors.". Angalia "Copyright Notices in Open Source Software Projects" na Steve Winslow.

• 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]. {Sababu iliyokidiwa} ^{[license_per_file]}

  Maelezo:

  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.

Udhibiti wa Mabadiliko

Hifadhi ya chanzo ya kudhibiti toleo ya hadharani

• Hifadhi ya chanzo ya mradi LAZIMA itumie programu ya kawaida ya kudhibiti toleo linalosambazwa (k.m., git au mercurial). {Sababu iliyokidiwa} ^{[repo_distributed]}
• Mradi LAZIMA utambulishe kazi ndogo ambazo zinaweza kufanywa na wachangiaji wapya au wa mara kwa mara. {URL iliyokidiwa} ^{[small_tasks]}

  Maelezo:

  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.

• 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. {Sababu iliyokidiwa} ^{[require_2FA]}
• 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. {Sababu iliyokidiwa} ^[secure_2FA]

  Maelezo:

  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.

Ubora

Viwango vya msimbo

• Mradi LAZIMA uandike mahitaji yake ya kukagua msimbo, pamoja na jinsi ukaguzi wa nambari unafanywa, nini lazima ichunguzwe, na nini kinachohitajika ili ikubalike. {N/A sababu} {URL iliyokidiwa} ^{[code_review_standards]}

  Maelezo:

  Angalia pia two_person_review na contribution_requirements.

• 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 {Sababu iliyokidiwa} ^{[two_person_review]}

Mfumo wa ujenzi unaofanya kazi

• 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). {N/A sababu} {URL iliyokidiwa} ^{[build_reproducible]}

  Maelezo:

  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.

Seti ya majaribio otomatiki

• Seti ya majaribio LAZIMA iweze kuitwa kwa njia ya kawaida kwa lugha hiyo. {URL iliyokidiwa} ^{[test_invocation]}
• 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 iliyokidiwa} ^{[test_continuous_integration]}

  Maelezo:

  Katika hali nyingi hii inamaanisha kwamba kila msanidi programu anayefanya kazi kikamilifu kwenye mradi anajumuisha angalau kila siku.

• 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. {N/A sababu} {Sababu iliyokidiwa} ^{[test_statement_coverage90]}
• 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. {N/A sababu} {Sababu iliyokidiwa} ^{[test_branch_coverage80]}

Usalama

Tumia mazoea mazuri ya msingi ya usimbuaji

• 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). {N/A inaruhusiwa} {Sababu iliyokidiwa} ^{[crypto_used_network]}
• 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). {N/A inaruhusiwa} {Sababu iliyokidiwa} ^{[crypto_tls12]}

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

• 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 iliyokidiwa} ^{[hardened_site]}

  Maelezo:

  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.

Masuala mengine ya usalama

• Mradi LAZIMA uwe umefanya ukaguzi wa usalama ndani ya miaka 5 iliyopita. Ukaguzi huu LAZIMA uzingatie mahitaji ya usalama na mpaka wa usalama. {Sababu iliyokidiwa} ^{[security_review]}

  Maelezo:

  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.

• Taratibu za kuimarisha LAZIMA zitumike katika programu iliyozalishwa na mradi ili kasoro za programu ziwe na uwezekano mdogo wa kusababisha udhaifu wa usalama. {N/A sababu} {URL iliyokidiwa} ^[hardening]

Uchanganuzi

Uchambuzi wa msimbo wa nguvu za ziada

• 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. {N/A sababu} {Sababu iliyokidiwa} ^{[dynamic_analysis]}
• Mradi INAPASWA kujumuisha madai mengi ya muda wa kutekeleza katika programu inayozalisha na kuangalia madai hayo wakati wa uchambuzi wenye nguvu. {N/A sababu} {Sababu iliyokidiwa} ^{[dynamic_analysis_enable_assertions]}

Kiwango cha Msingi 1

Jumla

Udhibiti

• Wakati mtumiaji anajaribu kusoma au kurekebisha rasilimali nyeti katika hifadhi ya mamlaka ya mradi, mfumo LAZIMA uhitaji mtumiaji kukamilisha mchakato wa uthibitishaji wa vipengele vingi. {N/A sababu} {URL iliyokidiwa} ^{[osps_ac_01_01]}

  Maelezo:

  Tekeleza uthibitishaji wa vipengele vingi kwa mfumo wa udhibiti wa toleo wa mradi, ikihitaji washirika kutoa aina ya pili ya uthibitishaji wakati wa kufikia data nyeti au kurekebisha mipangilio ya hifadhi. Funguo za kupitisha zinakubaliwa kwa udhibiti huu.

• Wakati mshirika mpya anaongezwa, mfumo wa udhibiti wa toleo LAZIMA uhitaji mgawanyo wa ruhusa wa mikono, au kuzuia ruhusa za mshirika kwa upendeleo wa chini unapatikana kwa chaguo-msingi. {N/A sababu} {URL iliyokidiwa} ^{[osps_ac_02_01]}

  Maelezo:

  Mifumo mingi ya umma ya udhibiti wa toleo imesanidiwa kwa njia hii. Hakikisha mfumo wa udhibiti wa toleo wa mradi daima unapeana ruhusa za chini zinazopatikana kwa washirika kwa chaguo-msingi wanapongezwa, ikitoa ruhusa za ziada tu zinapohitajika.

• Wakati ahadi ya moja kwa moja inajaribiwa kwenye tawi kuu la mradi, utaratibu wa kutekeleza LAZIMA uzuie mabadiliko yasitekelezwe. {N/A sababu} {URL iliyokidiwa} ^{[osps_ac_03_01]}

  Maelezo:

  Ikiwa VCS ni ya kati, weka ulinzi wa tawi kwenye tawi kuu katika VCS ya mradi. Vinginevyo, tumia mbinu isiyokuwa ya kati, kama ile ya kernel ya Linux, ambapo mabadiliko kwanza hupendekeza katika hifadhi nyingine, na kuunganisha mabadiliko katika hifadhi kuu kunahitaji kitendo tofauti mahususi.

• Wakati jaribio linafanywa kufuta tawi kuu la mradi, mfumo wa udhibiti wa toleo LAZIMA uichukulie hii kama shughuli nyeti na kuhitaji uthibitishaji wa wazi wa nia. {N/A sababu} {URL iliyokidiwa} ^{[osps_ac_03_02]}

  Maelezo:

  Weka ulinzi wa tawi kwenye tawi kuu katika mfumo wa udhibiti wa toleo wa mradi ili kuzuia ufutaji.

• Wakati bomba la CI/CD linakubali kigezo cha ingizo, kigezo hicho LAZIMA kisafishwe na kuthibitishwa kabla ya kutumika katika bomba. {N/A sababu} {URL iliyokidiwa} ^{[osps_br_01_01]}
• Wakati bomba la CI/CD linatumia jina la tawi katika utendaji wake, thamani ya jina hiyo LAZIMA isafishwe na kuthibitishwa kabla ya kutumika katika bomba. {N/A sababu} {URL iliyokidiwa} ^{[osps_br_01_02]}
• Wakati mradi unaorodhesha URI kama njia rasmi ya mradi, URI hiyo LAZIMA itolewa pekee kwa kutumia njia zilizosimbwa. {N/A sababu} {URL iliyokidiwa} ^{[osps_br_03_01]}

  Maelezo:

  Sanidi tovuti za mradi na mifumo ya udhibiti wa toleo ili kutumia njia zilizosimbwa kama SSH au HTTPS kwa maambukizi ya data. Hakikisha zana zote na vikoa vilivyorejelewa katika nyaraka za mradi vinaweza kufikika tu kupitia njia zilizosimbwa.

• Wakati mradi unaorodhesha URI kama njia rasmi ya usambazaji, URI hiyo LAZIMA itolwe pekee kwa kutumia njia zilizosimbwa. {N/A sababu} {URL iliyokidiwa} ^{[osps_br_03_02]}

  Maelezo:

  Sanidi mfumo wa kutolewa kwa mradi ili kuchukua data tu kutoka kwenye tovuti, majibu ya API, na huduma nyingine ambazo zinatumia njia zilizosimbwa kama SSH au HTTPS kwa maambukizi ya data.

• Mradi LAZIMA uzuie uhifadhi wa bila makusudi wa data nyeti isiyo-imeimbwa, kama siri na vyeti, katika mfumo wa udhibiti wa toleo. {N/A sababu} {URL iliyokidiwa} ^{[osps_br_07_01]}

  Maelezo:

  Sanidi .gitignore au sawa ili kutofautisha faili ambazo zinaweza kuwa na maelezo nyeti. Tumia vizuizi vya kabla ya kujitolea na zana za uchunguzi zilizosaidiwa na kompyuta ili kugundua na kuzuia ujumuishaji wa data nyeti katika michango.

• Wakati mradi umefanya utoaji, nyaraka za mradi LAZIMA zijumuishe miongozo ya watumiaji kwa utendaji wote wa kimsingi. {N/A sababu} {URL iliyokidiwa} ^{[osps_do_01_01]}

  Maelezo:

  Unda miongozo ya watumiaji au nyaraka kwa utendaji wote wa kimsingi wa mradi, ikieleza jinsi ya kusakinisha, kusanidi, na kutumia vipengele vya mradi. Ikiwa kuna vitendo vinavyojulikana kuwa hatari au vya kuharibu, jumuisha maonyo yaliyo-wazi kabisa.

• Wakati mradi umefanya utoaji, nyaraka za mradi LAZIMA zijumuishe mwongozo wa kuripoti hitilafu. {N/A sababu} {URL iliyokidiwa} ^{[osps_do_02_01]}

  Maelezo:

  Inashauriwa kwamba miradi itumie kifuatiliaji cha masuala cha chaguo-msingi cha VCS yao. Ikiwa chanzo cha nje kinatumiwa, hakikisha kwamba nyaraka za mradi na mwongozo wa kuchangia zinaeleza wazi na kwa uonekano jinsi ya kutumia mfumo wa kuripoti. Inashauriwa kwamba nyaraka za mradi pia ziweke matarajio ya jinsi hitilafu zitatolewa kipaumbele na kutatuliwa.

• Wakati ukiwa hai, mradi LAZIMA uwe na taratibu moja au zaidi za mijadala ya umma kuhusu mabadiliko yaliyopendekezwa na vizuizi vya matumizi. {N/A sababu} {URL iliyokidiwa} ^{[osps_gv_02_01]}

  Maelezo:

  Unda taratibu moja au zaidi za mijadala ya umma ndani ya mradi, kama orodha za barua, ujumbe wa papo hapo, au vifuatiliaji vya masuala, ili kuwezesha mawasiliano ya wazi na maoni.

• Wakati ukiwa hai, nyaraka za mradi LAZIMA zijumuishe maelezo ya mchakato wa kuchangia. {N/A sababu} {URL iliyokidiwa} ^{[osps_gv_03_01]}

  Maelezo:

  Unda CONTRIBUTING.md au saraka ya CONTRIBUTING/ ili kuainisha mchakato wa kuchangia ukijumuisha hatua za kuwasilisha mabadiliko, na kushirikiana na watunzaji wa mradi.

• Wakati ukiwa hai, leseni kwa msimbo wa chanzo LAZIMA ikidhi Ufafanuzi wa Chanzo Wazi wa OSI au Ufafanuzi wa Programu Huria wa FSF. {N/A sababu} {URL iliyokidiwa} ^{[osps_le_02_01]}

  Maelezo:

  Ongeza faili ya LICENSE kwenye hazina ya mradi na leseni ambayo ni leseni iliyoidhinishwa na Open Source Initiative (OSI), au leseni huria kama ilivyoidhinishwa na Free Software Foundation (FSF). Mifano ya leseni kama hizo ni pamoja na MIT, BSD 2-clause, BSD 3-clause revised, Apache 2.0, Lesser GNU General Public License (LGPL), na GNU General Public License (GPL). Kutolewa kwa umma kukidhi udhibiti huu ikiwa hakuna vizuizi vingine kama vile vimiliki.

• Wakati ukiwa hai, leseni kwa mali za programu iliyotolewa LAZIMA ikidhi Ufafanuzi wa Chanzo Wazi wa OSI au Ufafanuzi wa Programu Huria wa FSF. {N/A sababu} {URL iliyokidiwa} ^{[osps_le_02_02]}

  Maelezo:

  Ikiwa leseni tofauti imejumuishwa na mali za programu zilizotolewa, hakikisha ni leseni iliyoidhinishwa na Open Source Initiative (OSI), au leseni huria kama ilivyoidhinishwa na Free Software Foundation (FSF). Mifano ya leseni kama hizo ni pamoja na MIT, BSD 2-clause, BSD 3-clause revised, Apache 2.0, Lesser GNU General Public License (LGPL), na GNU General Public License (GPL). Kumbuka kwamba leseni kwa mali za programu zilizotolewa inaweza kuwa tofauti na msimbo wa chanzo.

• Wakati ukiwa hai, leseni kwa msimbo wa chanzo LAZIMA itunzwe katika faili ya LICENSE ya hazina inayohusiana, faili ya COPYING, au saraka ya LICENSE/. {N/A sababu} {URL iliyokidiwa} ^{[osps_le_03_01]}

  Maelezo:

  Jumuisha leseni ya msimbo wa chanzo wa mradi katika faili ya LICENSE ya mradi, faili ya COPYING, au saraka ya LICENSE/ ili kutoa uonekano na uwazi juu ya masharti ya leseni. Jina la faili LINAWEZA kuwa na kiendelezi. Ikiwa mradi una hazina nyingi, hakikisha kwamba kila hazina inajumuisha faili ya leseni.

• Wakati mradi ukiwa hai, leseni kwa rasilimali za programu iliyotolewa LAZIMA ijumuishwe ndani ya msimbo wa chanzo uliotolewa, au katika faili ya LICENSE, faili ya COPYING, au saraka ya LICENSE/ pembeni na rasilimali za toleo linalohusiana. {N/A sababu} {URL iliyokidiwa} ^{[osps_le_03_02]}

  Maelezo:

  Jumuisha leseni ya rasilimali za programu zilizotolewa za mradi katika msimbo wa chanzo uliotolewa, au katika faili ya LICENSE, faili ya COPYING, au saraka ya LICENSE/ pembeni na rasilimali za toleo linalohusiana ili kutoa mwonekano na uwazi wa masharti ya leseni. Jina la faili YAWEZA kuwa na kiendelezi. Ikiwa mradi una hazina nyingi, hakikisha kwamba kila hazina inajumuisha faili ya leseni.

• Wakati mradi ukiwa hai, hazina ya msimbo wa chanzo wa mradi LAZIMA iweze kusomwa hadharani kwenye URL isiyobadilika. {N/A sababu} {URL iliyokidiwa} ^{[osps_qa_01_01]}

  Maelezo:

  Tumia VCS ya kawaida kama GitHub, GitLab, au Bitbucket. Hakikisha hazina inaweza kusomwa hadharani. Epuka kunakili au kuakisi hazina isipokuwa nyaraka zinazoonekana sana zinatoa wazi chanzo kikuu. Epuka mabadiliko ya mara kwa mara kwenye hazina ambayo ingeathiri URL ya hazina. Hakikisha hazina ni ya umma.

• Mfumo wa udhibiti wa toleo LAZIMA uwe na kumbukumbu inayoweza kusomwa hadharani ya mabadiliko yote yaliyofanywa, nani alifanya mabadiliko, na mabadiliko yalifanywa lini. {N/A sababu} {URL iliyokidiwa} ^{[osps_qa_01_02]}

  Maelezo:

  Tumia VCS ya kawaida kama GitHub, GitLab, au Bitbucket ili kudumisha historia ya kuwasilisha inayoweza kusomwa hadharani. Epuka kusonga au kuandika upya miwasilisho kwa namna ambayo ingeweza kuficha mwandishi wa miwasilisho yoyote.

• Wakati mfumo wa usimamizi wa kifurushi unaposaidia, hazina ya msimbo wa chanzo LAZIMA iwe na orodha ya utegemezi inayohesabu utegemezi wa moja kwa moja wa lugha. {N/A sababu} {URL iliyokidiwa} ^{[osps_qa_02_01]}

  Maelezo:

  Hii inaweza kuwa kwa namna ya faili ya usimamizi wa kifurushi au faili ya utegemezi wa lugha inayoorodhesha utegemezi wote wa moja kwa moja kama package.json, Gemfile, au go.mod.

• Wakati mradi ukiwa hai, nyaraka za mradi LAZIMA ziwe na orodha ya hazina zozote za msimbo zinazozingatiwa kama miradi midogo. {N/A sababu} {URL iliyokidiwa} ^{[osps_qa_04_01]}

  Maelezo:

  Weka kwenye nyaraka hazina zozote za ziada za msimbo wa miradi midogo zinazozalishwa na mradi na kukusanywa katika toleo. Nyaraka hii inapaswa kujumuisha hali na nia ya hazina ya msimbo husika.

• Wakati mradi ukiwa hai, mfumo wa udhibiti wa toleo LAZIMA USIWE na vitu vilivyozalishwa vinavyoweza kutekelezwa. {N/A sababu} {URL iliyokidiwa} ^{[osps_qa_05_01]}

  Maelezo:

  Ondoa vitu vilivyozalishwa vinavyoweza kutekelezwa katika mfumo wa udhibiti wa toleo wa mradi. Inashauriwa kwamba hali yoyote ambapo kifaa kilichozalishwa kinachoweza kutekelezwa kinaonekana muhimu kwa mchakato kama vile majaribio, badala yake kinapaswa kuzalishwa wakati wa ujenzi au kuhifadhiwa kando na kuchukuliwa wakati wa hatua maalum ya mfumo wa kuendeshea iliyoandikwa vizuri.

• Wakati mradi ukiwa hai, mfumo wa udhibiti wa toleo LAZIMA USIWE na vitu vya binary visivyoweza kukaguliwa. {N/A sababu} {URL iliyokidiwa} ^{[osps_qa_05_02]}

  Maelezo:

  Usiongeze vitu vyovyote vya binary visivyoweza kukaguliwa katika mfumo wa udhibiti wa toleo wa mradi. Hii inajumuisha programu za binary za maombi, faili za maktaba, na vitu sawa. Haijumuishi mali kama picha za kigraphiki, faili za sauti au muziki, na maudhui sawa ambayo kwa kawaida huhifadhiwa katika muundo wa binary.

• Wakati mradi ukiwa hai, nyaraka za mradi LAZIMA ziwe na anwani za kuwasiliana za usalama. {N/A sababu} {URL iliyokidiwa} ^{[osps_vm_02_01]}

  Maelezo:

  Unda faili ya security.md (au inayoitwa sawa) inayohifadhi anwani za kuwasiliana za usalama kwa mradi.

Kiwango cha Msingi 2

Jumla

Udhibiti

• Wakati kazi ya CI/CD inatekelezwa bila ruhusa zilizobainishwa, mfumo wa CI/CD LAZIMA uweke chaguomsingi ruhusa za kazi kuwa ruhusa za chini kabisa zinazotolewa katika mfumo wa kuendeshea. {N/A sababu} {URL iliyokidiwa} ^{[osps_ac_04_01]}

  Maelezo:

  Sanidi mipangilio ya mradi ili kupeana ruhusa za chini zaidi zinazopatikana kwa mifumo mipya ya kuendeshea kwa chaguomsingi, ukitoa ruhusa za ziada tu zinapohitajika kwa kazi maalum.

• Wakati toleo rasmi linapotengenezwa, toleo hilo LAZIMA lipatiwe kitambulisho cha pekee cha toleo. {N/A sababu} {URL iliyokidiwa} ^{[osps_br_02_01]}

  Maelezo:

  Peana kitambulisho cha pekee cha toleo kwa kila toleo linalozalishwa na mradi, ukifuata mkondo thabiti wa kutaja au mpango wa nambari. Mifano ni pamoja na SemVer, CalVer, au kitambulisho cha kuwasilisha cha git.

• Wakati toleo rasmi linapotengenezwa, toleo hilo LAZIMA liwe na kumbukumbu ya maelezo ya marekebisho ya utendakazi na usalama. {N/A sababu} {URL iliyokidiwa} ^{[osps_br_04_01]}

  Maelezo:

  Hakikisha kuwa matoleo yote yanajumuisha kumbukumbu ya mabadiliko ya maelezo. Inashauriwa kuhakikisha kuwa kumbukumbu ya mabadiliko inaweza kusomwa na binadamu na inajumuisha maelezo zaidi ya ujumbe wa ahadi, kama vile maelezo ya athari za usalama au uhusiano na matumizi tofauti. Ili kuhakikisha kusomwa kwa mashine, weka maudhui chini ya kichwa cha markdown kama "## Changelog".

• Wakati mfululizo wa ujenzi na toleo unaingia utegemezi, LAZIMA utumie zana zilizowekwa viwango ambapo zinapatikana. {N/A sababu} {URL iliyokidiwa} ^{[osps_br_05_01]}

  Maelezo:

  Tumia zana za kawaida kwa ikolojia yako, kama vile wasimamizi wa vifurushi au zana za usimamizi wa utegemezi kuingia utegemezi wakati wa ujenzi. Hii inaweza kujumuisha kutumia faili ya utegemezi, faili ya kufuli, au orodha ya kudhibitisha utegemezi unaohitajika, ambayo kisha unavutwa na mfumo wa ujenzi.

• Wakati toleo rasmi linapotengenezwa, toleo hilo LAZIMA liwe na saini au kuhesabiwa kwenye orodha iliyosainiwa ikiwa ni pamoja na hashes za usimbuaji za mali kila moja. {N/A sababu} {URL iliyokidiwa} ^{[osps_br_06_01]}

  Maelezo:

  Saini mali zote za programu zilizotolewa wakati wa ujenzi kwa saini ya usimbuaji au uthibitisho, kama vile saini ya GPG au PGP, saini za Sigstore, utokeo wa SLSA, au SLSA VSAs. Jumuisha hashes za usimbuaji za mali kila moja katika orodha iliyosainiwa au faili ya metadata.

• Wakati mradi umefanya toleo, nyaraka za mradi LAZIMA zijumuishe maelezo ya jinsi mradi unavyochagua, kupata, na kufuatilia utegemezi wake. {N/A sababu} {URL iliyokidiwa} ^{[osps_do_06_01]}

  Maelezo:

  Inashauriwa kuchapisha habari hii pamoja na nyaraka za kiufundi na muundo wa mradi kwenye rasilimali inayoweza kuonwa hadharani kama vile hifadhi ya msimbo wa chanzo, tovuti ya mradi, au kituo kingine.

• Wakati ikiwa hai, nyaraka za mradi LAZIMA zijumuishe orodha ya wanachama wa mradi walio na ufikiaji wa rasilimali nyeti. {N/A sababu} {URL iliyokidiwa} ^{[osps_gv_01_01]}

  Maelezo:

  Andika washiriki wa mradi na majukumu yao kupitia vitu kama members.md, governance.md, maintainers.md, au faili sawa ndani ya hifadhi ya msimbo wa chanzo wa mradi. Hii inaweza kuwa rahisi kama kujumuisha majina au alama za akaunti katika orodha ya watunzaji, au changamano zaidi kulingana na utawala wa mradi.

• Wakati ikiwa hai, nyaraka za mradi LAZIMA zijumuishe maelezo ya majukumu na wajibu wa wanachama wa mradi. {N/A sababu} {URL iliyokidiwa} ^{[osps_gv_01_02]}

  Maelezo:

  Andika washiriki wa mradi na majukumu yao kupitia vitu kama members.md, governance.md, maintainers.md, au faili sawa ndani ya hifadhi ya msimbo wa chanzo wa mradi.

• Wakati ikiwa hai, nyaraka za mradi LAZIMA zijumuishe mwongozo kwa wachangiaji wa msimbo ambao unajumuisha mahitaji ya michango inayokubalika. {N/A sababu} {URL iliyokidiwa} ^{[osps_gv_03_02]}

  Maelezo:

  Panua yaliyomo ya CONTRIBUTING.md au CONTRIBUTING/ katika nyaraka za mradi ili kuorodhesha mahitaji ya michango inayokubalika, ikiwa ni pamoja na viwango vya kuandika msimbo, mahitaji ya majaribio, na miongozo ya kuwasilisha kwa wachangiaji wa msimbo. Inashauriwa kuwa mwongozo huu ni chanzo cha ukweli kwa wachangiaji na waidhinishaji.

• Wakati ikiwa hai, mfumo wa kudhibiti toleo LAZIMA uhitaji wachangiaji wote wa msimbo kudai kuwa wanaruhusiwa kisheria kufanya michango husika kwenye ahadi kila moja. {N/A sababu} {URL iliyokidiwa} ^{[osps_le_01_01]}

  Maelezo:

  Jumuisha DCO katika hifadhi ya mradi, kuhitaji wachangiaji wa msimbo kudai kuwa wanaruhusiwa kisheria kuwasilisha michango husika kwenye ahadi kila moja. Tumia ukaguzi wa hali kuhakikisha dai linafanywa. CLA pia inakidhi mahitaji haya. Mifumo fulani ya kudhibiti toleo, kama vile GitHub, inaweza kujumuisha hii katika masharti ya huduma ya jukwaa.

• Wakati ahadi inafanywa kwenye tawi kuu, ukaguzi wowote wa kiotomatiki wa hali za ahadi LAZIMA upite au upuuzwe kwa mikono. {N/A sababu} {URL iliyokidiwa} ^{[osps_qa_03_01]}

  Maelezo:

  Sanidi mfumo wa kudhibiti toleo wa mradi kuhitaji kuwa ukaguzi wote wa kiotomatiki wa hali upite au kuhitaji thibitisho la mikono kabla ya ahadi kuweza kuunganishwa kwenye tawi kuu. Inashauriwa kuwa ukaguzi wowote wa hiari HAUPASWI kusanidiwa kama mahitaji ya kupita au kushindwa ambayo waidhinishaji wanaweza kuwa na msukumo wa kupuuza.

• Kabla ya ahadi kukubalika, mifululizo ya CI/CD ya mradi LAZIMA iendeshe angalau seti moja ya majaribio ya kiotomatiki kuhakikisha mabadiliko yanakidhi matarajio. {N/A sababu} {URL iliyokidiwa} ^{[osps_qa_06_01]}

  Maelezo:

  Majaribio ya kiotomatiki yanapaswa kuendeshwa kabla ya kuunganisha kila moja kwenye tawi kuu. Seti ya majaribio inapaswa kuendeshwa katika mfululizo wa CI/CD na matokeo yanapaswa kuonekana kwa wachangiaji wote. Seti ya majaribio inapaswa kuendeshwa katika mazingira thabiti na inapaswa kuendeshwa kwa njia inayoruhusu wachangiaji kuendesha majaribio kienyeji. Mifano ya seti za majaribio ni pamoja na majaribio ya kitengo, majaribio ya uunganishaji, na majaribio ya mwisho-hadi-mwisho.

• Mradi ulipotoa toleo, nyaraka za mradi LAZIMA zijumuishe nyaraka za muundo zinazoonyesha matendo yote na watendaji ndani ya mfumo. {N/A sababu} {URL iliyokidiwa} ^{[osps_sa_01_01]}

  Maelezo:

  Jumuisha miundo katika nyaraka za mradi inayoeleza matendo na watendaji. Watendaji ni pamoja na mfumo wowote mdogo au kipengele ambacho kinaweza kuathiri sehemu nyingine katika mfumo. Hakikisha hii inasasishwa kwa vipengele vipya au mabadiliko ya kuvunja.

• Mradi ulipotoa toleo, nyaraka za mradi LAZIMA zijumuishe maelezo ya kiolesura vyote vya nje vya programu vya mali za programu zilizotolewa. {N/A sababu} {URL iliyokidiwa} ^{[osps_sa_02_01]}

  Maelezo:

  Eleza kiolesura vyote vya programu (APIs) vya mali za programu zilizotolewa, ukieleza jinsi watumiaji wanaweza kuingiliana na programu na data gani inatarajiwa au inazalishwa. Hakikisha hii inasasishwa kwa vipengele vipya au mabadiliko ya kuvunja.

• Mradi ulipotoa toleo, mradi LAZIMA ufanye tathmini ya usalama ili kuelewa matatizo ya uwezekano wa usalama ambayo ni ya uwezekano zaidi na yenye athari kubwa ambayo yangeweza kutokea ndani ya programu. {N/A sababu} {URL iliyokidiwa} ^{[osps_sa_03_01]}

  Maelezo:

  Kufanya tathmini ya usalama huwaelimisha wajumbe wa mradi na pia watumiaji wa chini kwamba mradi unaelewa matatizo ambayo yangeweza kutokea ndani ya programu. Kuelewa vitisho ambavyo vingeweza kutambuliwa husaidia mradi kudhibiti na kushughulikia hatari. Habari hii ni muhimu kwa watumiaji wa chini ili kuonyesha ujuzi wa usalama na mazoea ya mradi. Hakikisha hii inasasishwa kwa vipengele vipya au mabadiliko ya kuvunja.

• Ikiwa iko hai, nyaraka za mradi LAZIMA zijumuishe sera ya ufichuaji wa udhaifu wa pamoja (CVD), yenye muda maalum wa kujibu. {N/A sababu} {URL iliyokidiwa} ^{[osps_vm_01_01]}

  Maelezo:

  Unda faili ya SECURITY.md mzizini mwa saraka, ikielezea sera ya mradi ya ufichuaji wa udhaifu wa pamoja. Jumuisha njia ya kuripoti udhaifu. Weka matarajio ya jinsi mradi utajibu na kushughulikia masuala yaliyoripotiwa.

• Ikiwa iko hai, nyaraka za mradi LAZIMA zitoe njia ya kuripoti udhaifu wa faragha moja kwa moja kwa mawasiliano ya usalama ndani ya mradi. {N/A sababu} {URL iliyokidiwa} ^{[osps_vm_03_01]}

  Maelezo:

  Toa njia kwa watafiti wa usalama kuripoti udhaifu kwa faragha kwa mradi. Hii inaweza kuwa anwani ya barua pepe mahususi, fomu ya wavuti, zana maalum za VCS, anwani za barua pepe kwa mawasiliano ya usalama, au mbinu nyingine.

• Ikiwa iko hai, nyaraka za mradi LAZIMA zichapisha hadharani data kuhusu udhaifu uliogundulika. {N/A sababu} {URL iliyokidiwa} ^{[osps_vm_04_01]}

  Maelezo:

  Toa habari kuhusu udhaifu unaojulikana katika kituo cha hadharani kinachoweza kutabirika, kama vile ingizo la CVE, chapisho la blogi, au njia nyingine. Kwa kiwango kinachowezekana, habari hii inapaswa kujumuisha toleo(matoleo) lililoathirika, jinsi mtumiaji anavyoweza kubaini kama wanaathirika, na maelekezo ya kuzuia au kurekebisha.

Kiwango cha Msingi 3

Jumla

Udhibiti

• Ruhusa zinapopeana kwa kazi katika mfumo wa CI/CD, msimbo wa chanzo au usanidi LAZIMA upee tu ruhusa za chini zaidi zinazohitajika kwa shughuli zinazohusiana. {N/A sababu} {URL iliyokidiwa} ^{[osps_ac_04_02]}

  Maelezo:

  Sanidi mifumo ya CI/CD ya mradi ili kupea ruhusa za chini zinazopatikana kwa watumiaji na huduma kwa chaguomsingi, ukipandisha ruhusa tu inapohitajika kwa kazi maalum. Katika baadhi ya mifumo ya udhibiti wa toleo, hii inaweza kufanyika katika kiwango cha shirika au hifadhi. Ikiwa sivyo, weka ruhusa katika kiwango cha juu cha mfumo.

• Toleo rasmi linapobuniwa, mali zote ndani ya toleo hilo LAZIMA zihusianishwe wazi na kitambulisho cha toleo au kitambulisho kingine cha kipekee kwa mali hiyo. {N/A sababu} {URL iliyokidiwa} ^{[osps_br_02_02]}

  Maelezo:

  Panga kitambulisho cha kipekee cha toleo kwa kila mali ya programu inayozalishwa na mradi, ukifuata kawaida ya uainishaji thabiti au mpango wa nambari. Mifano ni pamoja na SemVer, CalVer, au kitambulisho cha git commit.

• Mradi LAZIMA ufafanue sera ya kudhibiti siri na ushahidi unaotumika na mradi. Sera inapaswa kujumuisha mwongozo wa kuhifadhi, kufikia, na kuzungusha siri na ushahidi. {N/A sababu} {URL iliyokidiwa} ^{[osps_br_07_02]}

  Maelezo:

  Eleza jinsi siri na ushahidi vinavyodhibitiwa na kutumika ndani ya mradi. Hii inapaswa kujumuisha maelezo ya jinsi siri zinavyohifadhiwa (k.m., kwa kutumia zana ya usimamizi wa siri), jinsi ufikiaji unavyodhibitiwa, na jinsi siri zinavyozungushwa au kusasishwa. Hakikisha kwamba habari nyeti haziingizwi kwa msimbo katika msimbo wa chanzo au kuhifadhiwa katika mifumo ya udhibiti wa toleo.

• Mradi ulipotoa toleo, nyaraka za mradi LAZIMA ziwe na maelekezo ya kuthibitisha uadilifu na uhalali wa mali za toleo. {N/A sababu} {URL iliyokidiwa} ^{[osps_do_03_01]}

  Maelezo:

  Maelekezo katika mradi yanapaswa kuwa na habari kuhusu teknolojia iliyotumika, amri za kuendesha, na matokeo yanayotarajiwa. Inapowezekana, epuka kuhifadhi nyaraka hizi katika mahali pamoja na mfumo wa ujenzi na utoaji wa toleo ili kuepuka ukiukaji mmoja kuhatarisha programu na nyaraka za kuthibitisha uadilifu wa programu.

• Mradi unapotoa toleo, nyaraka za mradi LAZIMA ziwe na maelekezo ya kuthibitisha utambulisho unaotarajiwa wa mtu au mchakato unaothibitisha toleo la programu. {N/A sababu} {URL iliyokidiwa} ^{[osps_do_03_02]}

  Maelezo:

  Utambulisho unaotarajiwa unaweza kuwa katika muundo wa vitambulisho vya funguo vilivyotumika kusaini, mtoa na utambulisho kutoka cheti cha sigstore, au aina nyingine zinazofanana. Inapowezekana, epuka kuhifadhi nyaraka hii mahali palipo sawa na mirija ya kujenga na kutoa ili kuepuka ukiukaji mmoja kuhatarisha programu na nyaraka za kuthibitisha uadilifu wa programu.

• Mradi unapotoa toleo, nyaraka za mradi LAZIMA zijumuishe kauli ya maelezo kuhusu wigo na muda wa msaada kwa kila toleo. {N/A sababu} {URL iliyokidiwa} ^{[osps_do_04_01]}

  Maelezo:

  Ili kuwasilisha wigo na muda wa msaada kwa rasilimali za programu zilizotolewa za mradi, mradi unapaswa kuwa na faili ya SUPPORT.md, sehemu ya "Msaada" katika SECURITY.md, au nyaraka nyingine zinazoweka wazi mzunguko wa maisha wa msaada, ikijumuisha muda unaotarajiwa wa msaada kwa kila toleo, aina za msaada zinazotolewa (k.m., marekebisho ya hitilafu, sasisho za usalama), na sera au taratibu yoyote husika ya kupata msaada.

• Mradi unapotoa toleo, nyaraka za mradi LAZIMA zitoe kauli ya maelezo ya wakati matoleo au matoleo hayatapokea tena sasisho za usalama. {N/A sababu} {URL iliyokidiwa} ^{[osps_do_05_01]}

  Maelezo:

  Ili kuwasilisha wigo na muda wa msaada kwa marekebisho ya usalama, mradi unapaswa kuwa na SUPPORT.md au nyaraka nyingine zinazoweka wazi sera ya mradi ya sasisho za usalama.

• Inapokuwa hai, nyaraka za mradi LAZIMA ziwe na sera kwamba washirikiano wa msimbo wanapimwa kabla ya kupewa ruhusa zilizopandishwa kwa rasilimali nyeti. {N/A sababu} {URL iliyokidiwa} ^{[osps_gv_04_01]}

  Maelezo:

  Chapisha sera inayoweza kutekelezwa katika nyaraka za mradi inayohitaji washirikiano wa msimbo kupimwa na kuidhinishwa kabla ya kupewa ruhusa zilizopandishwa kwa rasilimali nyeti, kama vile idhini ya kuunganisha au ufikiaji kwa siri. Inashauriwa kwamba upimaji ujumuishe kuanzisha mfululizo wa utambulisho unaoweza kuhalalishwa kama vile kuthibitisha ushirikiano wa mchangiaji na shirika linalojulikana na kuaminika.

• Mradi unapotoa toleo, rasilimali zote za programu zilizotolewa na zilizokusanywa LAZIMA zikabidhi pamoja na orodha ya bili ya programu. {N/A sababu} {URL iliyokidiwa} ^{[osps_qa_02_02]}

  Maelezo:

  Inashauriwa kuzalisha SBOM kiotomatiki wakati wa kujenga kwa kutumia zana ambayo imepimwa kwa usahihi. Hii huwezesha watumiaji kuingiza data hii kwa njia ya kiwango pamoja na miradi mingine katika mazingira yao.

• Mradi unapotoa toleo linalojumuisha hifadhi nyingi za chanzo cha msimbo, miradi yote midogo LAZIMA ilazimishe mahitaji ya usalama ambayo ni kali au kali zaidi kuliko msimbo wa msingi. {N/A sababu} {URL iliyokidiwa} ^{[osps_qa_04_02]}

  Maelezo:

  Hifadhi yoyote ya ziada ya msimbo wa miradi midogo iliyozalishwa na mradi na kukusanywa katika toleo lazima ilazimishe mahitaji ya usalama kama inavyolingana na hali na nia ya msimbo husika. Kwa kuongeza kufuata mahitaji ya msingi wa OSPS yanayolingana, hii inaweza kujumuisha kuhitaji ukaguzi wa usalama, kuhakikisha kuwa haina udhaifu, na kuhakikisha kuwa haina masuala ya usalama yanayojulikana.

• Inapokuwa hai, nyaraka za mradi LAZIMA ziweke wazi lini na jinsi majaribio yanavyotekelezwa. {N/A sababu} {URL iliyokidiwa} ^{[osps_qa_06_02]}

  Maelezo:

  Ongeza sehemu kwenye nyaraka za kuchangia inayoweka wazi jinsi ya kutekeleza majaribio kienyeji na jinsi ya kutekeleza majaribio katika mirija ya CI/CD. Nyaraka zinapaswa kuweka wazi majaribio yanajaribu nini na jinsi ya kutafsiri matokeo.

• Inapokuwa hai, nyaraka za mradi LAZIMA zijumuishe sera kwamba mabadiliko yote makubwa kwa programu inayozalishwa na mradi yanapaswa kuongeza au kusasisha majaribio ya utendaji katika seti ya majaribio ya kiatomati. {N/A sababu} {URL iliyokidiwa} ^{[osps_qa_06_03]}

  Maelezo:

  Ongeza sehemu kwenye nyaraka za kuchangia inayoweka wazi sera ya kuongeza au kusasisha majaribio. Sera inapaswa kuweka wazi ni nini kinachojumuisha mabadiliko makubwa na majaribio yapi yanapaswa kuongezwa au kusasishwa.

• Wakati kuruhusu kumefanywa kwa tawi kuu, mfumo wa udhibiti wa toleo la mradi LAZIMA uhitaji angalau idhini moja ya binadamu asiye mwandishi ya mabadiliko kabla ya kuunganisha. {N/A sababu} {URL iliyokidiwa} ^{[osps_qa_07_01]}

  Maelezo:

  Sanidi mfumo wa udhibiti wa toleo la mradi kuhitaji angalau idhini moja ya binadamu asiye mwandishi ya mabadiliko kabla ya kuunganisha katika toleo au tawi kuu. Hii inaweza kupatikana kwa kuhitaji ombi la kuvuta kupimwa na kuidhinishwa na angalau mshirikiano mmoja mwingine kabla ya kunaweza kuunganishwa.

• Mradi unapotoa toleo, mradi LAZIMA ufanye ufuatiliaji wa tisho na uchambuzi wa uso wa shambulio ili kuelewa na kulinda dhidi ya mashambulizi kwenye njia za msimbo muhimu, majukumu, na mwingiliano ndani ya mfumo. {N/A sababu} {URL iliyokidiwa} ^{[osps_sa_03_02]}

  Maelezo:

  Ufuatiliaji wa tisho ni shughuli ambapo mradi unaangalia msimbo, michakato na miundombinu inayohusiana, viunganishi, vipengele muhimu na "kufikiria kama kibogoyo" na kufanya mapendekezo ya jinsi mfumo unaweza kuvunjwa au kuhatarisha. Kila tisho iliyotambuliwa imeorodheshwa ili mradi uweze kufikiria jinsi ya kuepuka au kufunga pengo/udhaifu wowote unaoweza kutokea kwa kujihadhari. Hakikisha hii imesasishwa kwa vipengele vipya au mabadiliko ya kuvunja.

• Wakati uko hai, udhaifu wowote katika vipengele vya programu visivyoathiri mradi LAZIMA viwe vimeainishwa katika hati ya VEX, ikiendeleza ripoti ya udhaifu na maelezo ya kutokutumiwa vibaya. {N/A sababu} {URL iliyokidiwa} ^{[osps_vm_04_02]}

  Maelezo:

  Weka mfumo wa mlisho wa VEX unaowasiliana hali ya utumiaji vibaya wa udhaifu unaojulikana, ikiwa ni pamoja na maelezo ya tathmini au marekebisho yoyote yaliyowekwa kusimamisha msimbo ulio na udhaifu usiotekelezwa.

• Wakati uko hai, nyaraka za mradi LAZIMA zijumuishe sera inayofafanua kiwango cha marekebisho ya matokeo ya SCA yanayohusiana na udhaifu na leseni. {N/A sababu} {URL iliyokidiwa} ^{[osps_vm_05_01]}

  Maelezo:

  Andika sera katika mradi inayofafanua kiwango cha marekebisho ya matokeo ya SCA yanayohusiana na udhaifu na leseni. Jumuisha mchakato wa kutambua, kutanguliza, na kurekebisha matokeo haya.

• Wakati uko hai, nyaraka za mradi LAZIMA zijumuishe sera ya kushughulikia ukiukaji wa SCA kabla ya toleo lolote. {N/A sababu} {URL iliyokidiwa} ^{[osps_vm_05_02]}

  Maelezo:

  Andika sera katika mradi wa kushughulikia matokeo ya Uchambuzi wa Muundo wa Programu yanayotumika kabla ya toleo lolote, na ongeza ukaguzi wa hali unaothibitisha kufuata sera hiyo kabla ya toleo.

• Wakati uko hai, mabadiliko yote kwenye msingi wa msimbo wa mradi LAZIMA yaangaliwe kiatomati dhidi ya sera iliyoandikwa ya utegemezi mbaya na udhaifu unaojulikana katika utegemezi, kisha yazuiliwe katika hali ya ukiukaji, isipokuwa inapotangazwa na kuzuiliwa kama isiyotumiwa vibaya. {N/A sababu} {URL iliyokidiwa} ^{[osps_vm_05_03]}

  Maelezo:

  Unda ukaguzi wa hali katika mfumo wa kudhibiti toleo la mradi unaoendesha zana ya Uchambuzi wa Muundo wa Programu kwenye mabadiliko yote ya msingi wa msimbo. Hitaji kwamba ukaguzi wa hali upite kabla mabadiliko kusanywa.

• Wakati uko hai, nyaraka za mradi LAZIMA zijumuishe sera inayofafanua kiwango cha marekebisho ya matokeo ya SAST. {N/A sababu} {URL iliyokidiwa} ^{[osps_vm_06_01]}

  Maelezo:

  Andika sera katika mradi inayofafanua kiwango cha marekebisho ya matokeo ya Upimaji wa Usalama wa Programu Tuli (SAST). Jumuisha mchakato wa kutambua, kutanguliza, na kurekebisha matokeo haya.

• Wakati uko hai, mabadiliko yote kwenye msingi wa msimbo wa mradi LAZIMA yaangaliwe kiatomati dhidi ya sera iliyoandikwa ya udhaifu wa usalama na kuzuiliwa katika hali ya ukiukaji isipokuwa inapotangazwa na kuzuiliwa kama isiyotumiwa vibaya. {N/A sababu} {URL iliyokidiwa} ^{[osps_vm_06_02]}

  Maelezo:

  Unda ukaguzi wa hali katika mfumo wa kudhibiti toleo la mradi unaoendesha zana ya Upimaji wa Usalama wa Programu Tuli (SAST) kwenye mabadiliko yote ya msingi wa msimbo. Hitaji kwamba ukaguzi wa hali upite kabla mabadiliko kusanywa.