landerox.github.io

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 hali ya nishani yako ya msingi kwenye ukurasa wa mradi wako! Hali ya nishani ya msingi inaonekana kama hii: Kiwango cha nishani ya msingi kwa mradi 12835 ni baseline-2 Huu ndiyo jinsi ya kuweka nishani ya msingi:
Unaweza kuonyesha hali ya nishani yako ya msingi kwa kuweka hii katika faili yako ya markdown:
[![OpenSSF Baseline](https://www.bestpractices.dev/projects/12835/baseline)](https://www.bestpractices.dev/projects/12835)
au kwa kuweka hii katika HTML yako:
<a href="https://www.bestpractices.dev/projects/12835"><img src="https://www.bestpractices.dev/projects/12835/baseline"></a>


Hizi ni vigezo vya Kiwango cha Msingi 1. Hizi ni vigezo vya toleo v2026.02.19.

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

        

 Misingi

  • Jumla

    Kumbuka kwamba miradi mingine inaweza kutumia jina sawa.

    Personal site focused on data platforms, cloud architecture, automation, and production ai solutions.

    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.

 Udhibiti 24/24 ●

  • Udhibiti


    Ya kutosha kwa nishani!

    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. [OSPS-AC-01.01]
    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.

    When a user attempts to read or modify a sensitive resource in the project's authoritative repository, the system MUST require the user to complete a multi-factor authentication process. [OSPS-AC-01.01] Multi-factor authentication required when accessing sensitive resources in the repository. The repository owner has GitHub 2FA enabled. Repository-sensitive operations (settings, secrets, deploy keys, rulesets, branch protection) require an authenticated session with the second factor. The project currently has no collaborators with sensitive-resource access beyond the owner.


    Ya kutosha kwa nishani!

    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. [OSPS-AC-02.01]
    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.

    When a new collaborator is added, the version control system MUST require manual permission assignment, or restrict the collaborator permissions to the lowest available privileges by default. [OSPS-AC-02.01] New collaborators receive minimum permissions by default. The repository has no collaborators beyond the owner, GitHub's default behaviour assigns the lowest applicable role to a newly added collaborator, and should a collaborator ever be added the repository ruleset "Main Branch Protection" (id 11709250) constrains writes to the default branch independently of the per-collaborator role.


    Ya kutosha kwa nishani!

    Wakati ahadi ya moja kwa moja inajaribiwa kwenye tawi kuu la mradi, utaratibu wa kutekeleza LAZIMA uzuie mabadiliko yasitekelezwe. [OSPS-AC-03.01]
    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.

    When a direct commit is attempted on the project's primary branch, an enforcement mechanism MUST prevent the change from being applied. [OSPS-AC-03.01] Direct commits to the primary branch are prevented. The repository ruleset "Main Branch Protection" (id 11709250, URL https://github.com/landerox/landerox.github.io/rules/11709250) enforces a pull_request rule on the default branch main with required_approving_review_count = 1, required_status_checks (lint, build) that must pass before merge, non_fast_forward to prevent force pushes, and required_linear_history; the repository owner has admin bypass per the ruleset bypass_actors configuration as a deliberate single-maintainer flow documented in AGENTS.md hard rules.


    Ya kutosha kwa nishani!

    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. [OSPS-AC-03.02]
    Weka ulinzi wa tawi kwenye tawi kuu katika mfumo wa udhibiti wa toleo wa mradi ili kuzuia ufutaji.

    When an attempt is made to delete the project's primary branch, the version control system MUST treat this as a sensitive activity and require explicit confirmation of intent. [OSPS-AC-03.02] Primary branch deletion requires explicit confirmation. The repository ruleset "Main Branch Protection" includes the deletion rule type, which blocks deletion of the default branch main entirely; GitHub enforces this for all users, including admins (the bypass_actors setting applies only to push operations, not deletion).


    Ya kutosha kwa nishani!

    Wakati bomba la CI/CD linakubali kigezo cha ingizo, kigezo hicho LAZIMA kisafishwe na kuthibitishwa kabla ya kutumika katika bomba. [OSPS-BR-01.01]
    Mifuko ya CI/CD inapaswa kusafisha (kunukuu, kutoroka au kutoka kwa maadili yanayotarajiwa) pembejeo zote za metadata zinazohusiana na vyanzo visivyoaminika. Hii inajumuisha data kama vile majina ya matawi, ujumbe wa kujitolea, lebo, majina ya maombi ya kuvuta, na taarifa za mwandishi.

    When a CI/CD pipeline operates on untrusted metadata, those parameters MUST be sanitized and validated prior to use in the pipeline. [OSPS-BR-01.01] CI/CD pipeline parameters from untrusted sources must be sanitised. CI workflows accept no parameters from untrusted sources: workflow_dispatch inputs are limited (none defined), pull requests from forks run with the default GitHub fork-PR permission model (read-only token, no secret exposure), and workflow security is continuously audited by zizmor in pre-commit with a strict hash-pin policy and by lint.yml CI on every push plus a daily 08:00 UTC cron.


    Ya kutosha kwa nishani!

    Wakati mfuko wa CI/CD unafanya kazi kwenye picha za nambari za kanuni ambazo haziaminiki, LAZIMA uzuie upatikanaji wa vitambulisho vya CI/CD vilivyopendelewa na mali. [OSPS-BR-01.03]
    Mifuko ya CI/CD inapaswa kutenga picha za nambari za kanuni ambazo haziaminiki kutoka kwa vitambulisho vilivyopendelewa na mali. Hasa, miradi inapaswa kuwa makini kuhakikisha kwamba mtiririko wa kazi ambao hujenga au kutekeleza nambari kabla ya ukaguzi na mshirika hana upatikanaji wa vitambulisho vya CI/CD.

    (Future criterion) When a CI/CD pipeline operates on untrusted code snapshots, it MUST prevent access to privileged CI/CD credentials and assets. [OSPS-BR-01.03] CI/CD prevents untrusted code from accessing privileged credentials. Workflow tokens follow least privilege: top-level permissions: contents: read is declared in lint.yml, deploy.yml, links.yml, quality.yml and uv-upgrade.yml; elevated permissions (pages: write, id-token: write, contents: write, pull-requests: write, security-events: write) are declared per-job rather than workflow-level; the only workflow with contents: write (uv-upgrade.yml) runs only on schedule and workflow_dispatch (maintainer-triggered), never on external PRs; fork PRs receive a read-only GITHUB_TOKEN per GitHub default policy; and zizmor continuously audits these patterns so any regression fails CI.


    Ya kutosha kwa nishani!

    Wakati mradi unaorodhesha URI kama njia rasmi ya mradi, URI hiyo LAZIMA itolewa pekee kwa kutumia njia zilizosimbwa. [OSPS-BR-03.01]
    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.

    When the project lists a URI as an official project channel, that URI MUST be exclusively delivered using encrypted channels. [OSPS-BR-03.01] Official project channels use encrypted transmission only. All project channels are HTTPS-only: the repository at https://github.com/landerox/landerox.github.io (HTTPS-only), the published site at https://landerox.com (GitHub Pages with HTTPS enforced), devcontainer image pulls from mcr.microsoft.com and ghcr.io over HTTPS, Python package retrieval from PyPI over HTTPS via uv, and tag downloads from GitHub Releases over HTTPS; no HTTP, FTP, or other unencrypted channels are used.


    Ya kutosha kwa nishani!

    Wakati mradi unaorodhesha URI kama njia rasmi ya usambazaji, URI hiyo LAZIMA itolwe pekee kwa kutumia njia zilizosimbwa. [OSPS-BR-03.02]
    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.

    When the project lists a URI as an official distribution channel, that channel MUST be protected from adversary-in-the-middle attacks using cryptographically authenticated channels. [OSPS-BR-03.02] Distribution channels protected against man-in-the-middle attacks. Multiple layers of MITM protection are in place: GitHub Action references are SHA-pinned (sha40 + version comment) via pinact and continuously verified by zizmor's hash-pin policy; uv.lock pins each Python dependency by SHA256 hash and uv sync --frozen verifies hashes on every install; container images in.devcontainer/Dockerfile are pinned by SHA256 digest (tag@sha256:…) for both mcr.microsoft.com/devcontainers/python and ghcr.io/astral-sh/uv; and all registry endpoints use TLS with certificate verification by default.


    Ya kutosha kwa nishani!

    Mradi LAZIMA uzuie uhifadhi wa bila makusudi wa data nyeti isiyo-imeimbwa, kama siri na vyeti, katika mfumo wa udhibiti wa toleo. [OSPS-BR-07.01]
    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.

    The project MUST prevent the unintentional storage of unencrypted sensitive data, such as secrets and credentials, in the version control system. [OSPS-BR-07.01] Sensitive data prevented from storage in version control. detect-secrets runs in the pre-commit suite with a curated baseline at.config/.secrets.baseline; the pre-commit suite is blocking (bypass via --no-verify is forbidden by AGENTS.md hard rules); the repository contains no API keys, deploy keys, service tokens, or cloud credentials; CI workflows use ephemeral ${{ secrets.GITHUB_TOKEN }} provided by GitHub on each run.


    Ya kutosha kwa nishani!

    Wakati mradi umefanya utoaji, nyaraka za mradi LAZIMA zijumuishe miongozo ya watumiaji kwa utendaji wote wa kimsingi. [OSPS-DO-01.01]
    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.

    When the project has made a release, the project documentation MUST include user guides for all basic functionality. [OSPS-DO-01.01] https://github.com/landerox/landerox.github.io/blob/main/README.md README.md documents installation (devcontainer or host with uv + just), startup (just serve / just serve-es), usage (just build), and security (SECURITY.md cross-link). Deeper internal docs live under docs/ (tooling, decisions, structure, style-guide, runbook). [documentation_basics]


    Ya kutosha kwa nishani!

    Wakati mradi umefanya utoaji, nyaraka za mradi LAZIMA zijumuishe mwongozo wa kuripoti hitilafu. [OSPS-DO-02.01]
    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.

    When the project has made a release, the project documentation MUST include a guide for reporting defects. [OSPS-DO-02.01] https://github.com/landerox/landerox.github.io/issues/new/choose Bug reports are submitted through GitHub Issues using the templates under.github/ISSUE_TEMPLATE/ (bug_report.yml and feature_request.yml). The "/issues/new/choose" page lets reporters pick the appropriate template. [report_process]


    Ya kutosha kwa nishani!

    Wakati ukiwa hai, mradi LAZIMA uwe na taratibu moja au zaidi za mijadala ya umma kuhusu mabadiliko yaliyopendekezwa na vizuizi vya matumizi. [OSPS-GV-02.01]
    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.

    While active, the project MUST have one or more mechanisms for public discussions about proposed changes and usage obstacles. [OSPS-GV-02.01] GitHub supports public discussions on proposed changes (via pull requests) and usage obstacles (via issues).


    Ya kutosha kwa nishani!

    Wakati ukiwa hai, nyaraka za mradi LAZIMA zijumuishe maelezo ya mchakato wa kuchangia. [OSPS-GV-03.01]
    Unda CONTRIBUTING.md au saraka ya CONTRIBUTING/ ili kuainisha mchakato wa kuchangia ukijumuisha hatua za kuwasilisha mabadiliko, na kushirikiana na watunzaji wa mradi.

    While active, the project documentation MUST include an explanation of the contribution process. [OSPS-GV-03.01] https://github.com/landerox/landerox.github.io/blob/main/.github/CONTRIBUTING.md.github/CONTRIBUTING.md explains the contribution workflow: fork, branch, Conventional Commits (validated by commitizen), pre-commit hooks, and pull-request submission. [contribution]


    Ya kutosha kwa nishani!

    Wakati ukiwa hai, leseni kwa msimbo wa chanzo LAZIMA ikidhi Ufafanuzi wa Chanzo Wazi wa OSI au Ufafanuzi wa Programu Huria wa FSF. [OSPS-LE-02.01]
    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.

    While active, the license for the source code MUST meet the OSI Open Source Definition or the FSF Free Software Definition. [OSPS-LE-02.01] The MIT license for the repository contents is approved by the Open Source Initiative (OSI).


    Ya kutosha kwa nishani!

    Wakati ukiwa hai, leseni kwa mali za programu iliyotolewa LAZIMA ikidhi Ufafanuzi wa Chanzo Wazi wa OSI au Ufafanuzi wa Programu Huria wa FSF. [OSPS-LE-02.02]
    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.

    While active, the license for the released software assets MUST meet the OSI Open Source Definition or the FSF Free Software Definition. [OSPS-LE-02.02] The repository uses a dual-license model: source code (configs, workflows, scripts) is licensed under the MIT License via LICENSE at repo root; site content (Markdown under content/, prose, images) is licensed under Creative Commons Attribution 4.0 International via LICENSE-CONTENT. Both are FLOSS licenses for their respective scopes. Boundary documented in docs/decisions.md (Licensing Boundary). [floss_license]


    Ya kutosha kwa nishani!

    Wakati ukiwa hai, leseni kwa msimbo wa chanzo LAZIMA itunzwe katika faili ya LICENSE ya hazina inayohusiana, faili ya COPYING, au saraka ya LICENSE/. [OSPS-LE-03.01]
    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.

    While active, the license for the source code MUST be maintained in the corresponding repository's LICENSE file, COPYING file, or LICENSE/ directory. [OSPS-LE-03.01] License file found in repository.


    Ya kutosha kwa nishani!

    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. [OSPS-LE-03.02]
    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.

    While active, the license for the released software assets MUST be included in the released source code, or in a LICENSE file, COPYING file, or LICENSE/ directory alongside the corresponding release assets. [OSPS-LE-03.02] https://github.com/landerox/landerox.github.io/blob/main/LICENSE LICENSE (MIT, source code) is at the repository root in the standard GitHub-recognized location. LICENSE-CONTENT (CC-BY-4.0, site content) is also at the repository root for visibility. [license_location]


    Ya kutosha kwa nishani!

    Wakati mradi ukiwa hai, hazina ya msimbo wa chanzo wa mradi LAZIMA iweze kusomwa hadharani kwenye URL isiyobadilika. [OSPS-QA-01.01]
    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.

    While active, the project's source code repository MUST be publicly readable at a static URL. [OSPS-QA-01.01] Public repository accessible at a static URL. https://github.com/landerox/landerox.github.io is owned by an active GitHub account, has public visibility, requires no authentication to clone or browse, and the URL has been stable since project inception.


    Ya kutosha kwa nishani!

    Mfumo wa udhibiti wa toleo LAZIMA uwe na kumbukumbu inayoweza kusomwa hadharani ya mabadiliko yote yaliyofanywa, nani alifanya mabadiliko, na mabadiliko yalifanywa lini. [OSPS-QA-01.02]
    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.

    The version control system MUST contain a publicly readable record of all changes made, who made the changes, and when the changes were made. [OSPS-QA-01.02] VCS maintains public change history with authorship. Every commit records author name, email, timestamp and a unique SHA, visible at https://github.com/landerox/landerox.github.io/commits/main; Conventional Commits format (validated by commitizen in the commit-msg hook) adds semantic context; CHANGELOG.md provides hand-curated release notes per Keep a Changelog 1.1.0.


    Ya kutosha kwa nishani!

    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. [OSPS-QA-02.01]
    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.

    When the package management system supports it, the source code repository MUST contain a dependency list that accounts for the direct language dependencies. [OSPS-QA-02.01] Dependency list for direct language dependencies. Direct dependencies are declared explicitly: Python runtime in pyproject.toml under [project] dependencies and [dependency-groups] dev with resolved transitive deps and SHA256 hashes in uv.lock; GitHub Actions in.github/workflows/*.yml where each uses: line references the action by SHA40 + version comment via pinact; devcontainer tools in.devcontainer/Dockerfile as ARGs (UV_VERSION, LYCHEE_VERSION, PINACT_VERSION) with base images pinned by tag + SHA256 digest.


    Ya kutosha kwa nishani!

    Wakati mradi ukiwa hai, nyaraka za mradi LAZIMA ziwe na orodha ya hazina zozote za msimbo zinazozingatiwa kama miradi midogo. [OSPS-QA-04.01]
    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.

    Projects with multiple repositories MUST document a list of codebases that are part of the project. [OSPS-QA-04.01] Multi-repository projects document all codebases. N/A — this is a single-repository project, there are no sister or sub repositories, and all project code, configuration, content and documentation live in this single repository.


    Ya kutosha kwa nishani!

    Wakati mradi ukiwa hai, mfumo wa udhibiti wa toleo LAZIMA USIWE na vitu vilivyozalishwa vinavyoweza kutekelezwa. [OSPS-QA-05.01]
    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.

    While active, the version control system MUST NOT contain generated executable artifacts. [OSPS-QA-05.01] Generated executables excluded from version control. The repository contains no compiled executables, no.so/.dll/.exe, no Python.pyc/.pyo, no build artefacts;.gitignore excludes build output (site/), Python caches (.venv/, pycache/, *.py[cod],.pre-commit-cache/), tooling caches (.cache/,.mypy_cache/,.pytest_cache/,.ruff_cache/), IDE/editor files (.idea/,.vscode/, *.swp), OS artefacts (.DS_Store, Thumbs.db), and the devcontainer per-host lockfile (.devcontainer/devcontainer-lock.json).


    Ya kutosha kwa nishani!

    Wakati mradi ukiwa hai, mfumo wa udhibiti wa toleo LAZIMA USIWE na vitu vya binary visivyoweza kukaguliwa. [OSPS-QA-05.02]
    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.

    While active, the version control system MUST NOT contain unreviewable binary artifacts. [OSPS-QA-05.02] Unreviewable binary artifacts excluded. The repository contains no unreviewable binary artefacts; the only binary files present are essential static site assets — all human-inspectable and necessary for site rendering: 4 WOFF2 font files (MesloLGM Nerd Font Propo, Regular and Bold for EN and ES, subsetted from upstream TTF under the SIL OFL license with documented bump procedure in docs/tooling.md), favicon.svg (vector, inspectable), logo.svg (vector), and one profile.webp per locale (human portrait photograph).


    Ya kutosha kwa nishani!

    Wakati mradi ukiwa hai, nyaraka za mradi LAZIMA ziwe na anwani za kuwasiliana za usalama. [OSPS-VM-02.01]
    Unda faili ya security.md (au inayoitwa sawa) inayohifadhi anwani za kuwasiliana za usalama kwa mradi.

    While active, the project documentation MUST contain security contacts. [OSPS-VM-02.01] https://github.com/landerox/landerox.github.io/blob/main/.github/SECURITY.md.github/SECURITY.md documents the vulnerability reporting workflow: use GitHub Private Vulnerability Reporting (Security tab > Advisories > Report a vulnerability). It also defines a disclosure policy: 48-hour acknowledgement, 7-day fix-ETA estimate, notification on resolution. [vulnerability_report_process]



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

Ingizo la nishani ya mradi linamilikiwa na: Fernando Landero.
Ingizo liliundwa siku 2026-05-14 12:43:46 UTC, iliyosasishwa mara ya mwisho siku 2026-05-27 22:45:22 UTC. Ilipata mara ya mwisho nishani ya kupita siku 2026-05-14 14:35:01 UTC.