hMailServer

Проекты, которые следуют приведенным ниже лучшим практикам, могут добровольно и самостоятельно оценить себя и продемонстрировать, что они получили значок Open Source Security Foundation (OpenSSF).

Не существует набора практик, гарантирующего, что у программного обеспечения никогда не будет недостатков или уязвимостей; даже формальные методы могут не помочь, если спецификации или допущения ошибочны. Также не существует какой-либо практики, которая могла бы гарантировать, что проект будет поддерживать здоровое и хорошо функционирующее сообщество разработчиков. Однако следующие хорошие правила могут помочь улучшить результаты проектов. Например, некоторые правила описывают ревью несколькими участниками перед выпуском, что может помочь найти технические уязвимости, которые было бы сложно найти другим способом, и помочь построить доверие и желание дальнейшего взаимодействия между разработчиками из разных компаний. Чтобы получить значок, нужно выполнить все критерии с ключевыми словами "НЕОБХОДИМО"/"ОБЯЗАН"/"НЕДОПУСТИМО", все критерии со словом "СЛЕДУЕТ" либо должны удовлетворяться, либо должно быть приведено обоснование их невыполнения, и все критерии со словом "ЖЕЛАТЕЛЬНО" могут быть удовлетворены ИЛИ неудовлетворены (желательно, чтобы они были хотя бы рассмотрены). Если вы хотите ввести общий комментарий вместо объяснения, почему текущая ситуация приемлема, начните текст с '//' и пробела. Приветствуется обратная связь через сайт на GitHub в виде issues или pull requests. Существует также список рассылки для общих вопросов.

Мы с удовольствием предоставляем информацию на нескольких языках, однако, если есть какой-либо конфликт или несоответствие между переводами, английская версия является авторитетной.
Если это ваш проект, пожалуйста, отобразите статус вашего базового значка на странице проекта! Статус базового значка выглядит так: Базовый уровень значка для проекта 14187 - in_progress Вот как встроить базовый значок:
Вы можете показать статус базового значка, вставив это в ваш файл markdown:
[![OpenSSF Baseline](https://www.bestpractices.dev/projects/14187/baseline)](https://www.bestpractices.dev/projects/14187)
или вставив это в ваш HTML:
<a href="https://www.bestpractices.dev/projects/14187"><img src="https://www.bestpractices.dev/projects/14187/baseline"></a>


Это критерии Базового Уровня 3. Это критерии версии v2026.08.28.

Baseline Series: Базовый уровень 1 Базовый Уровень 2 Базовый Уровень 3

        

 Основы

  • Общая

    Обратите внимание, что другие проекты могут использовать то же имя.

    hMailServer is a free, open source email server for Microsoft Windows, implementing SMTP, IMAP and POP3. This is a maintained fork brought up to date with a current toolchain, current cryptography, and the transport-security and authentication standards expected of a mail server in 2026.

    Используйте формат выражения лицензии SPDX; примеры включают «Apache-2.0», «BSD-2-Clause», «BSD-3-Clause», «GPL-2.0+», «LGPL-3.0+», «MIT» и «(BSD-2-Clause OR Ruby)».
    Если используется более одного языка, перечислите их через запятую (пробелы необязательны), и отсортируйте их от наиболее до наименее используемого. Если список длинный, пожалуйста, перечислите по крайней мере три наиболее распространенных. Если языка нет (например, это проект только для документации или только для тестирования), используйте один символ «-» (минус). Для каждого языка используйте общепринятую капитализацию названия, например «JavaScript».
    Common Platform Enumeration (CPE) - это структурированная схема именования для информационных систем, программного обеспечения и пакетов. Она используется в ряде систем и баз данных для отчетов об уязвимостях.

 Элементы управления 9/21 ●

  • Элементы управления


    Достаточно для значка!

    Когда задаче назначаются разрешения в конвейере CI/CD, исходный код или конфигурация ДОЛЖНЫ назначать только минимальные привилегии, необходимые для соответствующей деятельности. [OSPS-AC-04.02]
    Настройте конвейеры CI/CD проекта так, чтобы по умолчанию назначать пользователям и службам наименьшие доступные разрешения, повышая разрешения только когда это необходимо для конкретных задач. В некоторых системах контроля версий это может быть возможно на уровне организации или репозитория. Если нет, установите разрешения на верхнем уровне конвейера.

    All 10 GitHub Actions workflows on master declare explicit permissions; none rely on the default token. Eight set a read-only or empty default at the top level (contents:read in seven; sign-release.yml uses permissions:{}; scorecard.yml uses the OpenSSF-recommended read-all). Write scopes appear only where the activity requires them, each with an explanatory comment: at job level in ci.yml (code-quality:write to upload coverage), codeql.yml (security-events:write for code scanning), dependency-review.yml (pull-requests:write for the PR summary comment), sbom.yml (contents:write to attach SBOMs to releases), sign-release.yml (id-token:write for Sigstore keyless signing, contents:write to upload signatures), and scorecard.yml (security-events:write, id-token:write per the official template); and at the top level of the two single-job workflows upstream-watch.yml (issues:write to file upstream-gap issues) and installer-smoke.yml (actions:read). server-build.yml and verify-binary-provenance.yml grant contents:read only. Verified by reading every workflow file at origin/master. See https://github.com/Progressiverobot/hmailserver/tree/master/.github/workflows


    Недостаточно для значка.

    Конвейеры CI/CD, принимающие входные данные от доверенных коллабораторов, ДОЛЖНЫ санировать и проверять эти входные данные перед их использованием в конвейере. [OSPS-BR-01.04]
    Конвейеры CI/CD должны санировать (заключать в кавычки, экранировать или завершаться при ожидаемых значениях) все входные данные коллабораторов при явном выполнении рабочих процессов. Хотя коллабораторы в целом являются доверенными, ручные входные данные для рабочего процесса не могут быть проверены и могут быть использованы в злоумышленных целях при захвате учётной записи или угрозе изнутри.

    Most workflow_dispatch inputs are handled safely: sign-release.yml passes inputs.tag through an env var and exits if empty; upstream-watch, sbom and codeql use the same env-var pattern; server-build interpolates only type:choice/boolean inputs that GitHub validates against fixed options. Gap: installer-smoke.yml interpolates the free-form string input release_tag directly into a pwsh run block (gh release download "${{ inputs.release_tag }}", lines 46 and 50), so a crafted value could inject commands on a runner holding github.token. That collaborator input is not sanitized or validated before shell use. See https://github.com/Progressiverobot/hmailserver/blob/master/.github/workflows/installer-smoke.yml


    Достаточно для значка!

    Когда создается официальный релиз, все активы в этом релизе ДОЛЖНЫ быть четко связаны с идентификатором релиза или другим уникальным идентификатором для актива. [OSPS-BR-02.02]
    Назначьте уникальный идентификатор версии каждому программному активу, произведенному проектом, следуя единообразному соглашению об именовании или схеме нумерации. Примеры включают SemVer, CalVer или идентификатор git-коммита.

    Checked release v6.2.21 (current Latest) via gh api: assets are hMailServer-6.2.21-x64.exe, hmailserver.spdx.json, hmailserver.cyclonedx.json, plus one .cosign.bundle per asset. The installer and its bundle carry the version in the filename; every asset is attached to the tagged GitHub release, so its download URL embeds the release identifier (/releases/download/v6.2.21/...), and each asset additionally has its own per-asset Sigstore signature bundle. All assets are therefore clearly associated with the unique release identifier v6.2.21. See https://github.com/Progressiverobot/hmailserver/releases/tag/v6.2.21


    Недостаточно для значка.

    НЕОБХОДИМО, чтобы проект определил политику управления секретами и учетными данными, используемыми проектом. Политика должна включать руководства по хранению, доступу и ротации секретов и учетных данных. [OSPS-BR-07.02]
    Задокументируйте, как секреты и учетные данные управляются и используются в рамках проекта. Это должно включать подробную информацию о том, как хранятся секреты (например, с использованием инструмента управления секретами), как контролируется доступ, и как секреты ротируются или обновляются. Убедитесь, что конфиденциальная информация не встроена в исходный код и не хранится в системах контроля версий.

    No documented policy for managing the project's own secrets and credentials exists on master: README.md, .github/SECURITY.md, CONTRIBUTING.md, SUPPORT.md, RELEASE.md and ARCHITECTURE.md contain nothing on storing, accessing or rotating project credentials. Practice is good — secret scanning and push protection are enabled, release signing is Sigstore keyless so no long-lived signing key exists, and workflows use only the ephemeral github.token — but the required written policy is missing. PR #40's GOVERNANCE.md inventories credential-bearing 'Critical assets' and who holds them, yet gives no storage/access/rotation guidelines, so merging it alone would not fully meet this. See https://github.com/Progressiverobot/hmailserver/pull/40


    Недостаточно для значка.

    Когда проект выпустил релиз, документация проекта ДОЛЖНА содержать инструкции по проверке целостности и подлинности активов релиза. [OSPS-DO-03.01]
    Инструкции в проекте должны содержать информацию об используемой технологии, командах для выполнения и ожидаемом выводе. По возможности избегайте хранения этой документации в том же месте, что и конвейер сборки и выпуска, чтобы избежать компрометации как программного обеспечения, так и документации для проверки целостности программного обеспечения в случае единичного нарушения безопасности.

    No durable project documentation tells users how to verify release assets. On master, README.md, RELEASE.md, Roadmap.md and docs/RegulatoryScope.md describe the signing design but give no verification commands, and the notes of the current Latest release v6.2.21 contain none (checked back through v6.2.19). The only published instructions are in the v6.2.23-alpha1 prerelease notes (2026-08-21): a complete cosign verify-blob command with bundle, identity regexp and OIDC issuer, plus the expected-failure statement. A one-off prerelease note is not documentation a user of the supported release would find; the command needs a stable home such as README or a VERIFYING.md. See https://github.com/Progressiverobot/hmailserver/releases/tag/v6.2.23-alpha1


    Недостаточно для значка.

    Когда проект выпустил релиз, документация проекта ДОЛЖНА содержать инструкции по проверке ожидаемой личности человека или процесса, создающего программный релиз. [OSPS-DO-03.02]
    Ожидаемая личность может быть в форме идентификаторов ключей, используемых для подписи, эмитента и личности из сертификата sigstore или других подобных форм. По возможности избегайте хранения этой документации в том же месте, что и конвейер сборки и выпуска, чтобы избежать компрометации как программного обеспечения, так и документации для проверки целостности программного обеспечения в случае единичного нарушения безопасности.

    The expected signer identity — a Sigstore certificate identity matching ^https://github.com/Progressiverobot/hmailserver/ with issuer https://token.actions.githubusercontent.com — is stated only once, in the v6.2.23-alpha1 prerelease notes published 2026-08-21. No repository documentation on master (README.md, SECURITY.md, RELEASE.md, docs/) records the expected identity, and the notes of the current Latest release v6.2.21 do not mention it. Signing is real (every asset gets a keyless cosign bundle, verified in-workflow before upload), but a user has no stable documented statement of which identity to expect. See https://github.com/Progressiverobot/hmailserver/releases/tag/v6.2.23-alpha1


    Достаточно для значка!

    Когда проект выпустил релиз, документация проекта ДОЛЖНА включать описательное заявление о масштабе и сроках поддержки для каждого релиза. [OSPS-DO-04.01]
    Для информирования о масштабе и сроках поддержки выпущенных программных активов проекта, проект должен иметь файл SUPPORT.md, раздел "Поддержка" в SECURITY.md или другую документацию, объясняющую жизненный цикл поддержки, включая ожидаемую продолжительность поддержки для каждого релиза, типы предоставляемой поддержки (например, исправления ошибок, обновления безопасности) и любые соответствующие политики или процедуры получения поддержки.

    .github/SECURITY.md opens with a Supported Versions table — 6.2.x supported, everything below 6.2 not — defining the scope of security support, and .github/SUPPORT.md describes the support provided: defect reports via GitHub issues, questions via Discussions, explicit expectations ('a maintained fork, not a commercial product with a support contract', no response-time guarantee, two stated commitments on honesty of fix claims), plus SECURITY.md's 5/10/90-working-day security-response targets. Duration is expressed as the current 6.2.x line — fixes ship as new builds — rather than calendar dates. See https://github.com/Progressiverobot/hmailserver/blob/master/.github/SECURITY.md


    Достаточно для значка!

    Когда проект выпустил релиз, документация проекта ДОЛЖНА предоставлять описательное заявление о том, когда релизы или версии больше не будут получать обновления безопасности. [OSPS-DO-05.01]
    Для информирования о масштабе и сроках поддержки исправлений безопасности, проект должен иметь SUPPORT.md или другую документацию, объясняющую политику проекта в отношении обновлений безопасности.

    .github/SECURITY.md states which versions receive security updates and which no longer do: the Supported Versions table marks 6.2.x as supported and all versions below 6.2 as unsupported, and the policy adds that a confirmed vulnerability fix 'ships as a new build and the advisory is published with a CVE requested through GitHub' — i.e. security updates land only in new 6.2.x builds and pre-6.2 releases receive none. This is a public, descriptive statement of when releases stop receiving security updates, in the conventional SECURITY.md location. Verified on master. See https://github.com/Progressiverobot/hmailserver/blob/master/.github/SECURITY.md


    Достаточно для значка!

    Документация проекта ОБЯЗАНА содержать политику, согласно которой соавторы кода проходят проверку перед предоставлением им расширенных прав доступа к чувствительным ресурсам. [OSPS-GV-04.01]
    Опубликуйте исполняемую политику в документации проекта, которая требует, чтобы участники кода были проверены и одобрены до предоставления повышенных разрешений на доступ к критическим ресурсам, таким как одобрение слияния или доступ к секретам. Рекомендуется, чтобы проверка включала установление обоснованной линии идентичности, такой как подтверждение связи участника с известной доверенной организацией.

    GOVERNANCE.md documents the policy for vetting candidates before escalated permissions are granted: the 'Becoming a maintainer' section requires demonstrated, sustained judgement — a track record of correct, tested, deployment-considerate changes — plus willingness to take on the release and security duties, with the maintainer deciding; the Roles section ties maintainer status to repository admin rights and the signing path. See https://github.com/Progressiverobot/hmailserver/blob/master/GOVERNANCE.md


    Недостаточно для значка.

    Когда проект выпустил релиз, все скомпилированные выпущенные программные активы ДОЛЖНЫ поставляться со списком компонентов программного обеспечения (Software Bill of Materials). [OSPS-QA-02.02]
    Рекомендуется автоматически генерировать SBOM во время сборки с использованием инструмента, который был проверен на точность. Это позволяет пользователям получать эти данные стандартизированным способом наряду с другими проектами в их среде.

    Partially in place but not yet for all released assets. Every release since v6.2.3 (June 2026), including the latest stable v6.2.21 and all current prereleases, ships SPDX and CycloneDX JSON SBOMs alongside the compiled installer; they are generated by Syft in .github/workflows/sbom.yml (which also merges the native OpenSSL/Boost/libpq dependencies Syft cannot see and fails the job if any is missing), and RELEASE.md step 12 makes SBOM attachment a mandatory pre-publication step. However, six earlier releases that remain published (v6.0.0-B1, v6.0.0, v6.1.0, v6.2.0, v6.2.1, v6.2.2) contain only the compiled installer with no SBOM, so not all compiled released software assets are delivered with an SBOM. Remediation: those six releases predate GitHub's immutable-releases setting (immutable:false), so SBOMs can be attached retroactively by dispatching the SBOM workflow with release_tag for each legacy tag, or the legacy releases can be retired; either would make this criterion Met.


    Достаточно для значка!

    Когда проект выпустил релиз, состоящий из нескольких репозиториев исходного кода, все подпроекты ДОЛЖНЫ применять требования безопасности, которые являются столь же строгими или более строгими, чем первичная кодовая база. [OSPS-QA-04.02]
    Любые дополнительные репозитории кода подпроектов, созданные проектом и скомпилированные в релиз, должны применять требования безопасности в соответствии со статусом и целями соответствующей кодовой базы. В дополнение к следованию соответствующим требованиям OSPS Baseline, это может включать требование проверки безопасности, обеспечение отсутствия уязвимостей и обеспечение отсутствия известных проблем безопасности.

    Not applicable: the project's releases are built from a single source code repository. All code compiled into a release — the C++ server, .NET Control Panel and tools, and vendored third-party libraries (libraries/, inventoried with SHA-256 hashes in hmailserver/docs/third-party-binaries.json) — lives in this one repo. The Progressiverobot org's other repositories (Kotlin examples, stable-diffusion fork, etc.) are unrelated projects and contribute nothing to hMailServer releases. There are no subproject repositories to hold to security requirements. See https://github.com/Progressiverobot/hmailserver


    Достаточно для значка!

    Документация проекта ОБЯЗАНА четко описывать, когда и как выполняются тесты. [OSPS-QA-06.02]
    Добавьте раздел в документацию по участию в проекте, объясняющий, как запускать тесты локально и как запускать тесты в конвейере CI/CD. Документация должна объяснять, что тестируют тесты и как интерпретировать результаты.

    README.md has a dedicated "Running tests" section documenting how to run the NUnit regression suite locally (test solution path, Test Explorer, NUnit console runner, run elevated, SpamAssassin/ClamAV/INI setup) and how to interpret results (dependency-less tests report inconclusive, not failing); build helper scripts build-tests.ps1/run-tests.ps1 are documented. When: ci.yml runs Control Panel tests on every push/PR to master, and README/RELEASE.md require the full suite to pass on the exact release binary. .github/CONTRIBUTING.md has a Testing section as well. See https://github.com/Progressiverobot/hmailserver/blob/master/README.md


    Достаточно для значка!

    Документация проекта ОБЯЗАНА включать политику, согласно которой все существенные изменения в программном обеспечении, создаваемом проектом, должны сопровождаться добавлением или обновлением тестов соответствующей функциональности в наборе автоматических тестов. [OSPS-QA-06.03]
    Добавьте раздел в документацию по участию в проекте, объясняющий политику добавления или обновления тестов. Политика должна объяснять, что представляет собой значительное изменение и какие тесты должны быть добавлены или обновлены.

    .github/CONTRIBUTING.md states the policy directly: "All changes must keep the regression suite green" and, under Pull Requests, "Add or update regression tests for behavior changes." RELEASE.md strengthens it for defect fixes: "each defect fix gets a negative-control test" — the new test must fail against the pre-fix binary. Together these document that changes to functionality must add or update automated tests. See https://github.com/Progressiverobot/hmailserver/blob/master/.github/CONTRIBUTING.md


    Недостаточно для значка.

    Когда совершается коммит в основную ветку, система контроля версий проекта ДОЛЖНА требовать как минимум одного одобрения изменений человеком, не являющимся автором, перед слиянием. [OSPS-QA-07.01]
    Настройте систему контроля версий проекта так, чтобы она требовала как минимум одного одобрения изменений человеком, не являющимся автором, перед слиянием в релизную или основную ветку. Это можно достичь, требуя, чтобы запрос на включение изменений был рассмотрен и одобрен как минимум одним другим участником, прежде чем его можно будет объединить.

    Unmet. Master has no branch protection (GitHub API returns 404 "Branch not protected") and no required-review rule; the sole maintainer routinely commits directly to master without any pull request or second reviewer. This is a single-maintainer project (494 of 498 commits by one person) with no second human available to approve changes. The project acknowledges this openly: Roadmap.md notes "Expect Branch-Protection and Code-Review to fail by design on a single-maintainer repository." A tag ruleset protects release tags, but that does not review commits. See https://github.com/Progressiverobot/hmailserver/blob/master/Roadmap.md


    Достаточно для значка!

    Когда проект выпустил релиз, проект ДОЛЖЕН выполнить моделирование угроз и анализ поверхности атаки для понимания и защиты от атак на критические пути кода, функции и взаимодействия внутри системы. [OSPS-SA-03.02]
    Моделирование угроз - это деятельность, при которой проект рассматривает кодовую базу, связанные процессы и инфраструктуру, интерфейсы, ключевые компоненты и "думает как хакер", проводя мозговой штурм о том, как система может быть взломана или скомпрометирована. Каждая выявленная угроза перечисляется, чтобы проект мог затем подумать о том, как проактивно избежать или закрыть любые бреши/уязвимости, которые могут возникнуть. Убедитесь, что это обновляется для новых функций или критических изменений.

    The threat model and attack-surface analysis is ASSURANCE-CASE.md: actors A1-A6 (internet stranger, sending MTA, on-path network attacker, authenticated user, malicious upstream, local attacker) with assumed capabilities, the asset list, the principal attack surfaces (protocol parsers, MIME parsing, TLS layer, scanner and DNS paths, persistence, management listeners), and trust boundaries B1-B6 with the checks at each. It names residual risk plainly rather than claiming none. See https://github.com/Progressiverobot/hmailserver/blob/master/ASSURANCE-CASE.md


    Недостаточно для значка.

    Любые уязвимости в программных компонентах, не затрагивающие проект, ОБЯЗАНЫ учитываться в документе VEX, дополняющем отчет об уязвимости сведениями о невозможности эксплуатации. [OSPS-VM-04.02]
    Создайте поток VEX, сообщающий о статусе эксплуатируемости известных уязвимостей, включая детали оценки или любые меры по смягчению, препятствующие выполнению уязвимого кода.

    Unmet. No VEX document or feed exists — not in the repository (repo-wide grep finds no VEX content) and not among release assets (v6.2.21 ships installer, SBOMs and signatures only). Dependabot currently shows 0 open and 0 dismissed alerts, but it only covers the .NET/Actions ecosystems; the vendored native binaries (e.g. 7-Zip 19.00 from 2019, flagged in ThirdPartyBinaries.md as overdue a refresh) are assessed narratively in ThirdPartyBinaries.md and SECURITY.md's out-of-scope section, not in machine-readable VEX augmenting the SBOMs. See https://github.com/Progressiverobot/hmailserver/blob/master/hmailserver/docs/ThirdPartyBinaries.md


    Недостаточно для значка.

    Документация проекта ОБЯЗАНА включать политику, определяющую порог для устранения проблем, выявленных при анализе состава программного обеспечения (SCA), связанных с уязвимостями и лицензиями. [OSPS-VM-05.01]
    Задокументируйте в проекте политику, определяющую порог для устранения результатов SCA, связанных с уязвимостями и лицензиями. Включите процесс выявления, приоритизации и устранения этих результатов.

    Unmet. No documented policy defines a remediation threshold for SCA findings covering both vulnerabilities and licenses. What exists: the dependency-review workflow blocks PR-introduced dependencies with known high/critical CVEs (fail-on-severity: high, rationale documented in the workflow header) and Dependabot files grouped update PRs — but there is no license-finding threshold anywhere, no documented timeline for remediating vulnerabilities discovered in already-shipped dependencies, and SECURITY.md's 90-day target covers externally reported vulnerabilities, not SCA findings. See https://github.com/Progressiverobot/hmailserver/blob/master/.github/workflows/dependency-review.yml


    Недостаточно для значка.

    Документация проекта ОБЯЗАНА включать политику устранения нарушений, выявленных при анализе состава программного обеспечения (SCA), перед каждым выпуском. [OSPS-VM-05.02]
    Задокументируйте в проекте политику для устранения применимых результатов анализа состава программного обеспечения перед любым релизом и добавьте проверки статуса, которые подтверждают соответствие этой политике перед релизом.

    Unmet. There is no documented policy requiring SCA violations to be resolved before a release, and no pre-release status check verifies it. RELEASE.md is a detailed 13-step release checklist (freeze, adversarial review, full regression suite, SBOM attachment, signing) but contains no step to check or clear Dependabot alerts or other SCA findings before shipping. The dependency-review gate runs only on pull requests, not on the release process, and the sole maintainer's direct pushes bypass it. See https://github.com/Progressiverobot/hmailserver/blob/master/RELEASE.md


    Недостаточно для значка.

    Все изменения в кодовой базе проекта ОБЯЗАНЫ автоматически проверяться на соответствие задокументированной политике в отношении вредоносных зависимостей и известных уязвимостей в зависимостях, и блокироваться при выявлении нарушений, за исключением случаев, когда они заявлены и подавлены как неэксплуатируемые. [OSPS-VM-05.03]
    Создайте проверку статуса в системе контроля версий проекта, которая запускает инструмент анализа состава программного обеспечения для всех изменений в кодовой базе. Требуйте, чтобы проверка статуса проходила успешно, прежде чем изменения могут быть объединены.

    Unmet. Automated SCA exists but does not cover all changes and cannot block. The dependency-review workflow evaluates every pull request against the GitHub Advisory Database and fails on high/critical CVEs (fail-on-severity: high) — but master has no branch protection (API returns 404), so no status check is required and a failing check does not block a merge; and the sole maintainer's direct pushes to master, which are the normal way changes land here, are never evaluated at all since the workflow triggers only on pull_request. See https://github.com/Progressiverobot/hmailserver/blob/master/.github/workflows/dependency-review.yml


    Недостаточно для значка.

    Документация проекта ОБЯЗАНА включать политику, определяющую порог для устранения проблем, выявленных статическим анализом кода безопасности (SAST). [OSPS-VM-06.01]
    Задокументируйте в проекте политику, определяющую порог для устранения результатов статического тестирования безопасности приложений (SAST). Включите процесс выявления, приоритизации и устранения этих результатов.

    Unmet. No documented policy defines a threshold for remediation of SAST findings. What exists: CodeQL runs on both languages (C# security-and-quality on every push/PR; C++ security-extended weekly/on-demand), .github/codeql/codeql-config.yml records each excluded rule with measured counts and reasoning rather than silent suppression, and Roadmap.md acknowledges a "Static-analysis backlog" whose remainder "needs triage rather than blanket suppression" — an honest status note, not a policy stating which finding severities must be fixed and in what timeframe. See https://github.com/Progressiverobot/hmailserver/blob/master/Roadmap.md


    Недостаточно для значка.

    Все изменения в кодовой базе проекта ОБЯЗАНЫ автоматически проверяться на соответствие задокументированной политике в отношении слабых мест безопасности и блокироваться при выявлении нарушений, за исключением случаев, когда они заявлены и подавлены как неэксплуатируемые. [OSPS-VM-06.02]
    Создайте проверку статуса в системе контроля версий проекта, которая запускает инструмент статического тестирования безопасности приложений (SAST) для всех изменений в кодовой базе. Требуйте, чтобы проверка статуса проходила успешно, прежде чем изменения могут быть объединены.

    Unmet. SAST is not a blocking gate on all changes. CodeQL C# runs on every push/PR but publishes alerts to code scanning without any required status check — master has no branch protection (API 404), so nothing is blocked on violations. CodeQL C++ — covering the internet-facing protocol parsers — runs only weekly and on manual dispatch; codeql.yml itself states plainly that "an alert introduced by a pull request is not seen until the next weekly run on master." Direct pushes to master by the sole maintainer, the normal change path, face no SAST gate at all. See https://github.com/Progressiverobot/hmailserver/blob/master/.github/workflows/codeql.yml



Вы можете использовать инструменты и системы ИИ для предложения изменений через простой URL, например https://www.bestpractices.dev/ru/projects/14187/choose/edit?osps_ac_01_01_status=Met&osps_ac_01_01_justification=GitHub+enforced. Смотрите нашу систему автоматизированных предложений о том, как это сделать. Эти данные доступны по лицензии Community Data License Agreement – Permissive, Version 2.0 (CDLA-Permissive-2.0). Это означает, что получатель данных может распространять данные с изменениями или без них, при условии, что получатель данных предоставляет текст данного соглашения вместе с распространяемыми данными. Пожалуйста, укажите в качестве источника Progressive Robot и участников OpenSSF Best Practices badge.

Владелец анкеты на значок проекта: Progressive Robot.
2026-08-21 05:37:27 UTC, последнее изменение сделано 2026-09-12 02:50:23 UTC. Последний раз условия для получения значка были выполнены 2026-08-21 17:17:16 UTC.