carbon-footprint-program

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

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

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


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

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

        

 Misingi 13/13 ●

  • Jumla

    Kumbuka kwamba miradi mingine inaweza kutumia jina sawa.

    Huella Latam is a digital public good for Latin America that lets organizations and governments measure, manage and reduce their carbon footprints. Organizations build greenhouse-gas inventories from activity data using country-configurable emission factors and methodologies, submit them for verification, and track reduction plans; national administrators manage catalogs, methodologies, users and sector-level reporting. It is a TypeScript monorepo — a Fastify + Prisma + PostgreSQL API, a React + Vite web app, shared libraries, and Azure Bicep infrastructure — released under AGPL-3.0 and owned by the United Nations Development Programme (UNDP). The platform is country-agnostic by design: country-specific values live in configuration and seed data so each adopting country can run its own deployment.

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

  • Maudhui ya kimsingi ya tovuti ya mradi


    Ya kutosha kwa nishani!

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

    The README opens with a one-line description — "Huella Latam: a platform (digital public good for Latin America) for measuring, managing, and reducing carbon footprints" — followed by an architecture summary, an SDG-relevance section, and a documentation index. See https://github.com/undp/carbon-footprint-program#readme and https://github.com/undp/carbon-footprint-program/blob/main/docs/overview/project-overview.md


    Ya kutosha kwa nishani!

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

    The README "Quick start" section explains how to obtain, build and run the software; CONTRIBUTING.md explains how to give feedback and contribute; .github/SUPPORT.md routes questions, bug reports, feature requests, security reports and privacy concerns to the right channel. https://github.com/undp/carbon-footprint-program/blob/main/.github/SUPPORT.md


    Ya kutosha kwa nishani!

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

    Non-trivial contribution file in repository: https://github.com/undp/carbon-footprint-program/blob/main/CONTRIBUTING.md. It covers the Code of Conduct, licensing of contributions (AGPL-3.0), how to report bugs and request features, development setup, and the pull-request process. A detailed technical workflow (branch naming, commit conventions, local database, testing) is at https://github.com/undp/carbon-footprint-program/blob/main/docs/development/contributing.md.


    Ya kutosha kwa nishani!

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

    CONTRIBUTING.md documents the acceptance criteria explicitly: https://github.com/undp/carbon-footprint-program/blob/main/CONTRIBUTING.md#contribution-acceptance-criteria — country-agnosticism, backward compatibility for existing country deployments, integration tests for new features, documentation updates, and an explicit maintainer security review for changes to auth, authorization, file upload or DB queries. It also requires branch prefixes (feat/fix/refactor/docs/chore/infra), Conventional Commits, small modular commits, and that CI (lint, type-check, format, test, build) pass. A pull-request template is provided at https://github.com/undp/carbon-footprint-program/blob/main/.github/PULL_REQUEST_TEMPLATE.md.


  • Leseni ya FLOSS


    Ya kutosha kwa nishani!

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

    The project is released under the GNU Affero General Public License v3.0 only (SPDX: AGPL-3.0-only), declared in the root LICENSE file and in the "license" field of every package.json. AGPL-3.0 is approved by the Open Source Initiative (OSI) and by the Digital Public Goods Alliance.


    Ya kutosha kwa nishani!

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

    The AGPL-3.0 license is approved by the Open Source Initiative (OSI).


    Ya kutosha kwa nishani!

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

    Non-trivial license location file in repository: https://github.com/undp/carbon-footprint-program/blob/main/LICENSE — the full AGPL-3.0 text in the standard root LICENSE file. GitHub detects the license as "GNU Affero General Public License v3.0".


  • Nyaraka


    Ya kutosha kwa nishani!

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

    Documentation lives under docs/ with an index at https://github.com/undp/carbon-footprint-program/blob/main/docs/README.md. It covers architecture (system-architecture.md, tech-stack.md, codebase-map.md, emission-calculation.md), the data model (developer-guide.md, ER diagram), development (local-setup.md, api-conventions.md, testing.md, environment-variables.md, contributing.md), operations (admin-guide.md, production-deployment.md, observability.md), infrastructure/deployment, security, and release/versioning. A separate end-user manual is maintained under user_manual/.


    Ya kutosha kwa nishani!

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

    The HTTP API is self-documenting via @fastify/swagger + @fastify/swagger-ui, which publish an OpenAPI specification and interactive docs at /api/docs (locally http://localhost:8080/api/docs). Route schemas are Zod-derived, so the published OpenAPI document is generated from the same schemas the API validates against. Conventions for the external interface are documented at https://github.com/undp/carbon-footprint-program/blob/main/docs/development/api-conventions.md.


  • Mengine


    Ya kutosha kwa nishani!

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

    All project sites are HTTPS-only. The repository and its documentation are served by GitHub over HTTPS (https://github.com/undp/carbon-footprint-program), and the demo site https://www.huellaslatam.org responds over HTTPS with a valid certificate (verified: HTTP 200, certificate chain validates). Note for accuracy: huellaslatam.org is a demonstration environment, not a production-grade deployment — it exists to show the platform, and its configuration should not be read as a production reference. There is no single canonical production instance: each adopting country provisions and operates its own. What the project guarantees across every topology is that TLS is enforced by the platform layer with minTlsVersion pinned to 1.2 in the Bicep templates (infra/modules/appService.bicep, storage.bicep, frontDoor.bicep), and that plain HTTP is rejected or redirected before a request reaches application code. See docs/security/hardening.md, "Deployment topology" and "Transport Security".


    Ya kutosha kwa nishani!

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

    GitHub supports discussions on issues and pull requests. The repository is public with GitHub Issues enabled (and issue templates), GitHub Discussions enabled, and pull-request review threads — all URL-addressable, searchable and archived.


    Ya kutosha kwa nishani!

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

    All maintainer-facing material is in English: README.md, CONTRIBUTING.md, GOVERNANCE.md, SECURITY.md, SUPPORT.md, CODE_OF_CONDUCT.md, PRIVACY.md, the whole docs/ tree, issue and pull-request templates, and code comments. The end-user product UI is Spanish by design, since the platform targets Latin American government and organizational users.


    Ya kutosha kwa nishani!

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

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

    The project is actively maintained. 519 commits on main, the most recent release 1.6.0 published 2026-07-27, and eleven releases (1.1.1 through 1.6.0) since 2026-05. Commits and merged pull requests land continuously (PR #550 merged the day of this assessment). Maintainer responsibilities and merge/release authority are defined in https://github.com/undp/carbon-footprint-program/blob/main/GOVERNANCE.md.


 Udhibiti wa Mabadiliko 9/9 ●

  • Hifadhi ya chanzo ya kudhibiti toleo ya hadharani


    Ya kutosha kwa nishani!

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

    Repository on GitHub, which provides public git repositories with URLs: https://github.com/undp/carbon-footprint-program (visibility: public).


    Ya kutosha kwa nishani!

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

    Repository on GitHub, which uses git. git records the author, committer and timestamp of every change, together with the full parent history.


    Ya kutosha kwa nishani!

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

    Development happens in the open between releases: every change lands as a pull request merged to main, and those interim commits are public immediately rather than only at release time. 519 commits, 505 pull requests (425 of them merged) and 49 issues are publicly visible, and each release is cut from already-public main history rather than from a private branch.


    Ya kutosha kwa nishani!

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

    Repository on GitHub, which uses git. git is a distributed version control system.


  • Unambari wa toleo wa kipekee


    Ya kutosha kwa nishani!

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

    Every release has a unique identifier: an annotated git tag and a matching GitHub Release (1.1.1, 1.1.2, 1.2.0, 1.3.0, 1.3.1, 1.3.2, 1.4.0, 1.4.1, 1.4.2, 1.5.0, 1.6.0) — see https://github.com/undp/carbon-footprint-program/releases. The canonical version lives in the root package.json, is baked into the Docker image tag, and is exposed at runtime through the APP_VERSION value returned by the API health endpoint.


    Ya kutosha kwa nishani!

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

    The project uses Semantic Versioning (MAJOR.MINOR.PATCH) and documents the increment rules at https://github.com/undp/carbon-footprint-program/blob/main/docs/release/versioning.md. The published tags follow SemVer (e.g. 1.4.1 → 1.4.2 for fixes, 1.5.0 → 1.6.0 for backward-compatible features).


    Ya kutosha kwa nishani!

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

    Each release is identified by a git tag with the exact version number, and the tag is what the GitHub Release points at: https://github.com/undp/carbon-footprint-program/tags.


  • Maelezo ya kutolewa


    Ya kutosha kwa nishani!

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

    Every release publishes human-readable release notes as a GitHub Release: https://github.com/undp/carbon-footprint-program/releases. Each entry has a "What's Changed" summary grouped by area (e.g. "User Modules", infrastructure, dependencies) listing each merged change with its author and pull-request link — for example https://github.com/undp/carbon-footprint-program/releases/tag/1.6.0. Notes are provided for all eleven releases, 1.1.1 through 1.6.0.


    Ya kutosha kwa nishani!

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

    No publicly known, CVE-assigned vulnerability in this project's own code has been fixed in any release to date, so there is nothing of that kind to enumerate. Dependency vulnerabilities are handled by Dependabot security updates, and the resulting pull requests appear by name in the "What's Changed" list of the release that includes them (see https://github.com/undp/carbon-footprint-program/releases). Should a vulnerability in the project's own code ever be fixed, SECURITY.md commits the maintainers to coordinated disclosure and the release notes will call it out.


 Kuripoti 8/8 ●

  • Mchakato wa kuripoti hitilafu


    Ya kutosha kwa nishani!

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

    The bug-reporting process is documented in three places: CONTRIBUTING.md "Reporting bugs & requesting features" https://github.com/undp/carbon-footprint-program/blob/main/CONTRIBUTING.md, .github/SUPPORT.md, which routes each kind of report to the right channel https://github.com/undp/carbon-footprint-program/blob/main/.github/SUPPORT.md, and structured issue forms at https://github.com/undp/carbon-footprint-program/issues/new/choose (bug report, feature request, refactor, DPG compliance). Security vulnerabilities are explicitly excluded from public issues and routed to the private process in https://github.com/undp/carbon-footprint-program/blob/main/SECURITY.md.


    Ya kutosha kwa nishani!

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

    GitHub Issues is used as the issue tracker: https://github.com/undp/carbon-footprint-program/issues. It is backed by structured issue forms in .github/ISSUE_TEMPLATE/ (bug_report.yml, feature_request.yml, refactor.yml, dpg_compliance.yml) and a namespaced label taxonomy maintained as code in .github/labels.yml (type:, area:, priority:, status:), so reports are consistently classified and triaged.


    Ya kutosha kwa nishani!

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

    Bug reports are consistently acknowledged and acted on. Of the 49 issues filed in the last 12 months, 18 are already closed, and bugs are typically triaged within a day — for example issue #547 (equivalence computed in the wrong unit) was filed 2026-07-28 and fixed and closed 2026-07-29 by PR #550. Every incoming report is labelled (type:bug, area:, priority:, status:triage), which is the acknowledgement step, and priority:critical bugs such as #395 and #391 were closed with fixes. To date no report has been left unanswered.


    Ya kutosha kwa nishani!

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

    Enhancement requests are triaged the same way as bugs: they are labelled type:feature (or type:refactor / type:tech-debt), given an area and a priority, and either scheduled or answered in the thread. Several have been implemented and shipped — for example the "optional comment on approving a submission" request (PR #409, released in 1.6.0) and the provider-agnostic backend auth refactor (#398, closed 2026-07-09). Requests that conflict with the project's country-agnosticism principle are answered with that rationale, as documented in .github/SUPPORT.md.


    Ya kutosha kwa nishani!

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

    The issue tracker is public, searchable and permanently archived at https://github.com/undp/carbon-footprint-program/issues?q=is%3Aissue, covering both open and closed issues. Pull-request discussions are similarly public at https://github.com/undp/carbon-footprint-program/pulls?q=is%3Apr, and GitHub Discussions is enabled for longer-form threads.


  • Mchakato wa kuripoti udhaifu


    Ya kutosha kwa nishani!

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

    The vulnerability reporting process is published in https://github.com/undp/carbon-footprint-program/blob/main/SECURITY.md. The declared security contact is the maintainer team collectively — the @undp/carbon-footprint-program-maintainers GitHub team (see https://github.com/undp/carbon-footprint-program/blob/main/.github/CODEOWNERS and https://github.com/undp/carbon-footprint-program/blob/main/GOVERNANCE.md) — so handling a report never depends on one individual's availability. SECURITY.md states that vulnerabilities must not be reported through public issues, discussions or pull requests, names GitHub private vulnerability reporting as the private channel, tells a reporter who cannot use it to open a detail-free issue requesting a private channel, and gives an escalation path to the maintainer team after 5 business days. It also lists what to include in a report and the in-scope and out-of-scope components.


    Ya kutosha kwa nishani!

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

    Private reporting is available through GitHub Private Vulnerability Reporting, which is enabled on the repository and reachable from the Security tab at https://github.com/undp/carbon-footprint-program/security/advisories. It is documented as the preferred channel in https://github.com/undp/carbon-footprint-program/blob/main/SECURITY.md. Reports go privately to the maintainer team collectively (@undp/carbon-footprint-program-maintainers) rather than to a named individual, which keeps the report, the discussion, the fix and any resulting advisory in one private place with no single point of failure. SECURITY.md explicitly asks reporters not to use public issues, discussions or pull requests, and offers a detail-free public issue as a way to request a private channel for anyone who cannot use GitHub PVR.


    Ya kutosha kwa nishani!

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

    https://github.com/undp/carbon-footprint-program/blob/main/SECURITY.md publishes the maintainer team's commitment to acknowledge a vulnerability report within 3 business days — well inside the 14-day requirement — and tells reporters to escalate to the maintainer team if they have not heard back within 5 business days. It further commits to validating the issue, agreeing a remediation timeline with the reporter, and practising coordinated disclosure with credit unless the reporter prefers anonymity. In the interest of accuracy: this is the maintainer team's published working target, and formal ratification of the acknowledgement and remediation SLAs by UNDP as the owning organization is still in progress (tracked in issue #460).


 Ubora 13/13 ●

  • Mfumo wa ujenzi unaofanya kazi


    Ya kutosha kwa nishani!

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

    The software is built from source with two standard commands: "pnpm install" then "pnpm build". The root package.json "build" script drives Turborepo, which builds the shared packages (@repo/types, constants, utils, database, storage), the Fastify API and the React/Vite web app in dependency order. Prerequisites and exact toolchain versions are pinned in .tool-versions and .nvmrc and documented in https://github.com/undp/carbon-footprint-program/blob/main/docs/development/local-setup.md. CI proves the build works from a clean checkout on every pull request via the required "Build" job in .github/workflows/ci.yml.


    Ya kutosha kwa nishani!

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

    The build uses widely available, conventional tooling: Node.js, pnpm (workspaces), Turborepo, the TypeScript compiler (tsc), Vite for the web bundle, Prisma for schema/client generation, and Docker for containerization. There are no bespoke build tools to learn.


    Ya kutosha kwa nishani!

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

    Every tool required to build the project is FLOSS: Node.js, pnpm, Turborepo, TypeScript, Vite, Prisma, ESLint, Prettier, Vitest and Docker. The project can be built and tested end to end on a FLOSS platform with no proprietary software; a docker-compose setup provides Postgres, Keycloak and MinIO as open-source local dependencies.


  • Seti ya majaribio otomatiki


    Ya kutosha kwa nishani!

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

    The project has an automated test suite documented at https://github.com/undp/carbon-footprint-program/blob/main/docs/development/testing.md. apps/api has 199 test files, of which 161 are integration tests that exercise real HTTP routes through Fastify's app.inject() against a real PostgreSQL instance provisioned with Testcontainers (plus Azurite and MinIO for the storage legs). apps/web adds 37 Vitest suites running under jsdom with React Testing Library. tools/seed has its own unit suite. The whole suite runs in CI on every pull request.


    Ya kutosha kwa nishani!

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

    The suite runs with the standard single command "pnpm test" from the repository root (Turborepo fans it out to every workspace). Narrower entry points exist for convenience: "pnpm test:api", "pnpm test:web", "pnpm test:seed", and "pnpm test:api -- /<feature>" for a single feature.


    Ya kutosha kwa nishani!

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

    The test suite covers most of the code and most of the functionality. apps/api — which holds essentially all of the business logic, including emission calculations, authorization, and the data layer — is gated in CI at 90% coverage for lines, statements, functions and branches, merged across the three test legs by the required "Coverage" job in .github/workflows/ci.yml. That gate is enforced on every pull request, so the figure is a floor rather than a snapshot, and every externally reachable endpoint has an integration test (161 integration test files exercising real HTTP routes against a real PostgreSQL instance via Testcontainers). Stated transparently: apps/web is covered by a smaller Vitest + jsdom + React Testing Library suite (37 files) over its logic layers — utils, hooks, stores, chatbot — behind an enforced floor that is deliberately ratcheted upward as tests are added, so a share of its render-heavy UI is not yet covered. The judgement recorded here is that a 90%-gated backend plus a growing frontend suite satisfies "most".


    Ya kutosha kwa nishani!

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

    Continuous integration runs the full suite on every pull request to main via .github/workflows/ci.yml. "Test (base)", "Test (storage-azure)", "Test (storage-minio)", "Test (web)", "Seed Unit Tests" and "Coverage" are required status checks under branch protection, alongside Lint, Type Check, Format Check, Build, Audit, Zizmor, Secret Scan and Docs Link Check. See https://github.com/undp/carbon-footprint-program/actions/workflows/ci.yml.


  • Upimaji wa utendaji mpya


    Ya kutosha kwa nishani!

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

    The policy is written down in CONTRIBUTING.md under "Contribution acceptance criteria": "Test coverage — new features include integration tests" https://github.com/undp/carbon-footprint-program/blob/main/CONTRIBUTING.md#contribution-acceptance-criteria. docs/development/testing.md gives the concrete conventions for writing them, and the policy is mechanically enforced by the 90% merged-coverage gate in CI, which fails a pull request that adds logic without adding tests.


    Ya kutosha kwa nishani!

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

    Tests accompany functional changes as a matter of course — apps/api currently carries 199 test files across 161 integration suites, grown alongside the features they cover, and apps/web has 37. The requirement is enforced rather than merely encouraged: the required "Coverage" check re-computes merged coverage across all three test legs and fails below 90% on lines, statements, functions and branches, so a feature pull request without matching tests cannot merge. Recent examples of test-only ratchets are PRs #509, #515 and #518.


    Ya kutosha kwa nishani!

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

    The policy is documented in two places: the "Contribution acceptance criteria" section of https://github.com/undp/carbon-footprint-program/blob/main/CONTRIBUTING.md, and the testing guide at https://github.com/undp/carbon-footprint-program/blob/main/docs/development/testing.md, which explains the Vitest + Testcontainers setup, the app.inject() pattern, and the factory helpers a contributor should use when adding tests.


  • Bendera za maonyo


    Ya kutosha kwa nishani!

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

    Compiler and linter warnings are enabled at a strict level. TypeScript runs with "strict": true (packages/typescript-config/base.json), and ESLint uses typescript-eslint's recommendedTypeChecked configuration (packages/eslint-config/base.ts), which requires full type information and therefore reports type-aware problems, not just syntactic ones. Both run over the whole monorepo via "pnpm lint" and "pnpm type-check".


    Ya kutosha kwa nishani!

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

    There are no outstanding warnings, and the build enforces that: "pnpm lint" is invoked as "turbo run lint -- --max-warnings=0", so a single ESLint warning fails the required "Lint" status check, and "pnpm type-check" fails the required "Type Check" check on any TypeScript error. Both are required checks under branch protection, so warnings cannot accumulate on main.


    Ya kutosha kwa nishani!

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

    Maximally strict settings are enabled rather than the defaults: TypeScript "strict": true, and typescript-eslint's recommendedTypeChecked ruleset, which needs a full type-checked program and catches classes of bug (unsafe any flow, floating promises, unnecessary conditionals) that non-type-aware linting cannot see. Prettier formatting is separately enforced by a required "Format Check" job.


 Usalama 16/16 ●

  • Maarifa ya maendeleo yenye usalama


    Ya kutosha kwa nishani!

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

    The maintainer team collectively (@undp/carbon-footprint-program-maintainers — see https://github.com/undp/carbon-footprint-program/blob/main/.github/CODEOWNERS and https://github.com/undp/carbon-footprint-program/blob/main/GOVERNANCE.md) holds and applies the knowledge of how to design secure software; this is asserted for the team rather than for one individual, matching how the project is actually governed and reviewed. The design record is public under docs/security/ https://github.com/undp/carbon-footprint-program/tree/main/docs/security: authentication.md (OIDC/JWKS token verification), rbac.md and route-access-modes.md (role-based authorization applied per route), hardening.md (deployment topologies, TLS enforcement, HTTP security headers, input validation, upload controls), secrets.md (Azure Key Vault with managed identities, no credentials in code), sensitive-data.md, audit-logging.md, and github-actions-security.md. The principles are visible in the code, not just the docs: least privilege via per-route role guards; fail-closed defaults — the API refuses to boot in production unless JWKS_URI, JWKS_ISSUER and JWKS_AUDIENCE are set, rather than silently accepting tokens it cannot bind to this application (apps/api/src/config/environment.ts); defense in depth (helmet headers, then schema validation, then authorization, then audit logging); minimal attack surface; and no trust in client-supplied identity. CONTRIBUTING.md requires an explicit maintainer security review for any change to auth, authorization, file upload or database queries, which is how the knowledge is applied structurally rather than incidentally. Complementary documents are SECURITY.md and PRIVACY.md.


    Ya kutosha kwa nishani!

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

    The maintainer team collectively (@undp/carbon-footprint-program-maintainers) holds this knowledge, and the codebase reflects it. Injection: all database access goes through Prisma's parameterized query builder; there is no string-concatenated SQL. Input validation: every request body, query and parameter is validated against a Zod schema at the route boundary (schemas live in packages/types), so unvalidated input never reaches business logic. Broken access control: authorization is enforced server-side by explicit requireAuth / requireRoles / requireOrganizationRole hooks per route, documented in docs/security/rbac.md and route-access-modes.md and covered by integration tests. XSS and header attacks: @fastify/helmet applies secure headers globally and React escapes by default. Insecure direct object references: domain access hooks verify organization membership before returning records. Secrets in code: Azure Key Vault with managed identities, plus GitHub secret scanning with push protection and a betterleaks CI gate over full git history. Race conditions and partial writes: multi-step mutations run inside Prisma transactions. These classes are also checked mechanically by CodeQL's security-and-quality suite on every push and pull request. The team also files its own hardening findings publicly rather than leaving them implicit — see issue #559, which pins an explicit JWT algorithms allowlist to close an algorithm-confusion surface found while preparing this badge.


  • Tumia mazoea mazuri ya msingi ya usimbuaji

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

    Ya kutosha kwa nishani!

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

    The project uses only standard, published cryptographic protocols and algorithms: TLS 1.2+ for all transport, RSA/ECDSA signature verification of OIDC JWTs via JWKS (@fastify/jwt with jwks-rsa), SHA-2 family digests, and AES-256 for encryption at rest in Azure Storage. No proprietary or homegrown cryptography is used or implemented.


    Ya kutosha kwa nishani!

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

    The project does not implement cryptography itself; it calls established, well-reviewed implementations: Node.js node:crypto (OpenSSL) for random values, @fastify/jwt and jwks-rsa for JWT signature verification and key retrieval, and the platform TLS stacks of Azure Front Door, App Service and Static Web Apps for transport. Password handling is delegated entirely to the external OIDC identity provider.


    Ya kutosha kwa nishani!

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

    All cryptographic functionality relies on FLOSS implementations: Node.js and its bundled OpenSSL, @fastify/jwt (MIT), jwks-rsa (MIT), and — in the fully open local/self-hosted configuration — Keycloak as the OIDC provider and MinIO for object storage. No proprietary crypto implementation is required to run the software.


    Ya kutosha kwa nishani!

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

    All default key lengths meet or exceed the NIST minimums, and the application never generates its own long-term asymmetric keys — every key it relies on is issued by a platform service or the identity provider. TLS certificates are issued and managed by the Azure services that terminate TLS (Static Web Apps for the frontend and App Service for the API; Azure Front Door additionally where an adopting country chooses to deploy it), using 2048-bit RSA or ECDSA P-256 keys; minTlsVersion is pinned to 1.2 in the Bicep templates, so only suites with 128-bit-or-better symmetric keys are negotiated. OIDC token-signing keys are fetched from the provider's JWKS endpoint: the demo environment uses Microsoft Entra ID, which signs with RSA-2048, and Keycloak — the open-source option documented for self-hosting — also defaults to RSA-2048. Encryption at rest in Azure Storage is AES-256. Symmetric secrets the project does control (cookie signing) are supplied from Azure Key Vault, never from a checked-in default.


    Ya kutosha kwa nishani!

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

    The default configuration uses no broken or known-weak cryptographic algorithm or mode. TLS is pinned to a 1.2 minimum at every tier (infra/modules/appService.bicep, storage.bicep, frontDoor.bicep), excluding SSLv3, TLS 1.0 and 1.1 and their weak suites. MD5, SHA-1, DES, 3DES, RC4 and ECB mode are not used anywhere in the codebase; digests are SHA-2 family. Token signatures are verified against asymmetric public keys fetched from the identity provider's JWKS endpoint, and in production the API refuses to boot unless JWKS_URI, JWKS_ISSUER and JWKS_AUDIENCE are all set, so a token whose issuer or audience does not bind to this application is rejected (apps/api/src/config/environment.ts). Stated precisely rather than generously: the verify options pin issuer and audience but do not yet pin an explicit "algorithms" allowlist, so the accepted signature-algorithm set is currently inherited from the JWT library's key-type inference rather than asserted by the project. No broken algorithm is reachable, but that guarantee should be ours and not a dependency default — it is tracked publicly as a hardening item in issue #559 https://github.com/undp/carbon-footprint-program/issues/559.


    Ya kutosha kwa nishani!

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

    The default configuration does not depend on cryptographically broken primitives. MD5, SHA-1, DES, 3DES and RC4 are not used for any security purpose; digests are SHA-2 family, and TLS 1.2+ enforcement excludes SHA-1-signed handshake suites. Container base images and dependencies are pinned by SHA-256 digest, and pnpm verifies package integrity with SHA-512 hashes.


    Ya kutosha kwa nishani!

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

    Forward secrecy is provided by the Azure platform services that terminate TLS; the application implements no TLS itself and ships no certificate or cipher-suite configuration. In the default topology TLS terminates at Azure Static Web Apps (frontend) and Azure App Service (API, which faces the public internet directly in the demo environment); an adopting country may additionally place Azure Front Door in front, which is optional per deployment rather than required by the platform. All of these negotiate TLS 1.2+ with ECDHE (ephemeral Diffie-Hellman) key exchange, which gives perfect forward secrecy, and the Bicep templates pin minTlsVersion to 1.2 so no non-PFS legacy suite can be selected. Because Front Door is optional, this property does not depend on it — it holds in every supported topology. See docs/security/hardening.md, "Deployment topology" and "Transport Security".


    Ya kutosha kwa nishani!

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

    The project does not store passwords for authentication of external users, so there is nothing to hash or salt. Authentication is delegated entirely to an external OpenID Connect identity provider (Microsoft Entra ID in the reference deployment, Keycloak in the open-source/local configuration). The API only verifies signed JWTs against the provider JWKS and never sees, transmits or persists a user credential; there is no local password table, reset flow, or credential column in the Prisma schema. See docs/security/authentication.md.


    Ya kutosha kwa nishani!

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

    All security-relevant random values come from a cryptographically secure PRNG: the project uses randomUUID() from Node.js node:crypto (backed by OpenSSL) for request identifiers (apps/api/src/app.ts), chatbot session identifiers, and the opaque UUIDs that name uploaded objects in storage (apps/api/src/features/files/requestUpload/service.ts and the carbon-inventory line-file equivalent). Math.random() is not used for any security purpose. Session and token generation itself is handled by the external OIDC provider.


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


    Ya kutosha kwa nishani!

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

    Distribution channels use HTTPS exclusively. Source is distributed by GitHub over HTTPS or SSH, so the transport is authenticated and integrity-protected. Dependencies are installed from the registry over HTTPS with "pnpm install --frozen-lockfile", and pnpm-lock.yaml records an integrity hash for every package. Container base images are pinned by SHA-256 digest, and all GitHub Actions are pinned to full commit SHAs rather than mutable tags, so the CI supply chain cannot be silently redirected.


    Ya kutosha kwa nishani!

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

    No cryptographic hash or signature is retrieved over an unprotected channel. Package integrity hashes are committed in pnpm-lock.yaml inside the repository itself and fetched from the registry only over HTTPS; container base-image digests are committed in the Dockerfiles; GitHub Action versions are committed as full commit SHAs. Nothing in the build downloads a checksum over plain HTTP or from an untrusted mirror.


  • Udhaifu uliofahamika hadharani umeshughulikiwa


    Ya kutosha kwa nishani!

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

    Known dependency vulnerabilities are surfaced and fixed continuously rather than on a 60-day clock. "pnpm audit --prod --audit-level moderate" runs as the required "Audit" status check on every pull request, so a moderate-or-higher advisory in the production dependency graph blocks merges until it is resolved. Dependabot security updates and alerts are enabled, with weekly version updates across the npm, docker and github-actions ecosystems (.github/dependabot.yml). A Trivy workflow scans dependencies and container images on pushes to main and on pull requests, and CodeQL runs on every push, pull request and weekly. Deliberate, time-boxed deferrals are tracked publicly in a periodic-review issue with an explicit re-check condition for each.


    Ya kutosha kwa nishani!

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

    Critical vulnerabilities are addressed promptly because the gates are blocking rather than advisory: the required "Audit" check fails the pull request on any moderate-or-higher advisory in the production dependency graph, so a critical one cannot reach main. Dependabot security updates open fix pull requests automatically, Trivy scans images and dependencies on push and pull request, and CodeQL findings land in GitHub code scanning for triage. Security-relevant issues are additionally labelled type:security and priority:critical in the tracker so they are visible and prioritized.


  • Masuala mengine ya usalama


    Ya kutosha kwa nishani!

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

    No valid credential intended to limit public access is present in the repository, and three independent controls enforce that: GitHub secret scanning with push protection is enabled; a betterleaks job (the maintained gitleaks successor) runs on every pull request with fetch-depth 0, scanning the entire git history against .gitleaks.toml, and reports zero findings; and all .env* files are gitignored, with runtime secrets supplied from Azure Key Vault via managed identities (docs/security/secrets.md). Reported precisely: on main, apps/api/src/config/environment.ts still carries one hardcoded literal — a local-development HMAC fallback for JWT_SECRET. It is not a credential for any deployed system, because production fails closed and refuses to boot unless JWKS_URI, JWKS_ISSUER and JWKS_AUDIENCE are set, so the fallback cannot be used to accept forged tokens in a real deployment. It is nonetheless being removed outright for defense in depth: the change deletes the built-in default, makes AUTH_PROVIDER=jwks without JWKS_URI refuse to boot unless JWT_SECRET is set explicitly, and ships a throwaway value in .envrc.template and .env.dockercompose.example so local setup configures one deliberately. This entry will be tightened once that change is merged.


 Uchanganuzi 8/8 ●

  • Uchambuzi tuli wa msimbo


    Ya kutosha kwa nishani!

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

    At least one static analysis tool with security relevance is applied to every proposed major production release, and in fact to every pull request. CodeQL runs the "security-and-quality" query suite on every push to main, every pull request, and on a weekly schedule, uploading results to GitHub code scanning (.github/workflows/codeql.yml). Alongside it: ESLint with typescript-eslint recommendedTypeChecked (full type-aware analysis), tsc --strict, zizmor auditing the GitHub Actions workflows for supply-chain and template-injection issues, Trivy scanning dependencies and container images, and betterleaks scanning git history for secrets. All of these are required status checks on pull requests to main. See https://github.com/undp/carbon-footprint-program/actions/workflows/codeql.yml.


    Ya kutosha kwa nishani!

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

    CodeQL is configured with the "security-and-quality" query suite, which is explicitly a look for common vulnerability patterns — injection, path traversal, unsafe deserialization, SSRF, hardcoded credentials, prototype pollution and the rest of the JavaScript/TypeScript CWE coverage — rather than style-only checks. Results are uploaded to GitHub code scanning. It is complemented by Trivy for known-CVE scanning of dependencies and images and zizmor for GitHub Actions-specific vulnerability classes.


    Ya kutosha kwa nishani!

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

    Findings are fixed rather than accumulated, because the analyzers are blocking gates. "Lint" runs with --max-warnings=0 and "Type Check" fails on any error; both are required checks. The zizmor and Secret Scan jobs fail the build on any finding. CodeQL alerts appear in GitHub code scanning and are triaged by the maintainer team, with security-relevant work tracked as type:security issues. Where a Trivy finding cannot yet be acted on, it is recorded as an explicit, reviewed exception in .trivyignore.yaml rather than silently ignored.


    Ya kutosha kwa nishani!

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

    Static analysis runs far more often than at each release: CodeQL on every push to main, every pull request, and weekly on a schedule; ESLint, tsc, zizmor, betterleaks and Trivy on every pull request; and the OpenSSF Scorecard workflow weekly and whenever branch protection changes. So every proposed change is analyzed before it can merge, and the scheduled runs catch newly published advisories against unchanged code.


  • Uchambuzi wa msimbo wa nguvu za ziada


    Kwa shida ya kutosha kwa nishani.

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

    No dedicated dynamic security analysis tool is applied yet. The project does exercise the running system extensively — 161 integration tests drive real HTTP requests through the API against a real PostgreSQL instance (Testcontainers), plus Azurite and MinIO for the storage paths, and Zod schemas validate every request and response at runtime — but that is a functional suite, not a fuzzer or web-application scanner. Adding a DAST scan or fuzzing of the HTTP surface is recognized as future work; this criterion is SUGGESTED, not required, for the passing level.


    Ya kutosha kwa nishani!

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

    The project is written in TypeScript running on Node.js (with a small amount of shell and Bicep). These are memory-safe, garbage-collected environments with no manual memory management, no pointer arithmetic and no unchecked buffer access, so the memory-safety checkers this criterion refers to (ASan/valgrind-class tools) do not apply. There is no C, C++ or other unsafe-language code in the codebase.


    Ya kutosha kwa nishani!

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

    Runtime checks are enabled during test execution rather than compiled out. Every API request and response is validated against a Zod schema at the route boundary, and a schema violation throws — so the integration suite fails loudly on any contract breach, which is exactly the assertion behaviour this criterion asks for. TypeScript runs in strict mode, and the test environment additionally exercises the fail-closed configuration guards in apps/api/src/config/environment.ts. No assertion or validation layer is disabled in the test configuration.


    Ya kutosha kwa nishani!

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

    No dedicated dynamic analysis (fuzzing or DAST) is currently performed — see the dynamic_analysis criterion — so there are no dynamic-analysis findings, of medium severity or otherwise, outstanding to fix. Vulnerabilities discovered by any other route (CodeQL, Trivy, pnpm audit, Dependabot, or a private report under SECURITY.md) are triaged and fixed under the processes described in those criteria.



Data hii inapatikana chini ya Community Data License Agreement – Permissive, Version 2.0 (CDLA-Permissive-2.0). Hii inamaanisha kuwa Mpokeaji wa Data anaweza kushiriki Data, na au bila marekebisho, mradi Mpokeaji wa Data anapatanisha maandishi ya mkataba huu na Data iliyoshirikiwa. Tafadhali tambua Kevin Johnson na wachangiaji wa nishani ya Mazoea Bora ya OpenSSF.

Ingizo la nishani ya mradi linamilikiwa na: Kevin Johnson.
Ingizo liliundwa siku 2026-07-29 16:37:34 UTC, iliyosasishwa mara ya mwisho siku 2026-07-30 01:15:24 UTC. Ilipata mara ya mwisho nishani ya kupita siku 2026-07-29 16:59:38 UTC.