hMailServer

Les projets qui suivent les meilleures pratiques ci-dessous peuvent s'auto-certifier et montrer qu'ils ont obtenu le badge de la Open Source Security Foundation (OpenSSF).

Il n'existe aucun ensemble de pratiques qui garantissent que ce logiciel n'aura jamais de défauts ou de vulnérabilités ; même les méthodes formelles peuvent échouer si les spécifications ou les hypothèses sont fausses. Il n'y a pas non plus de pratiques qui peuvent garantir qu'un projet permettra de maintenir une communauté de développement saine et qui fonctionne bien. Toutefois, suivre les meilleures pratiques peut contribuer à améliorer les résultats des projets. Par exemple, certaines pratiques permettent la revue par plusieurs personnes avant publication, ce qui peut aider à trouver des vulnérabilités techniques difficiles à trouver autrement et à renforcer la confiance et un désir d'interaction répétée entre les développeurs de différentes entreprises. Pour gagner un badge, tous les critères DOIT et NE DOIT PAS doivent être satisfaits, tous les critères DEVRAIT doivent être satisfaits OU non satisfaits avec justification, et tous les critères PROPOSÉ doivent être satisfaits OU non satisfaits (nous voulons au moins qu'ils soient considérés). Si vous voulez entrer un texte de justification pour un commentaire générique, au lieu d'une raison justifiant que la situation est acceptable, commencez le bloc de texte avec '//' suivi d'un espace. Les commentaires sont les bienvenus via le site GitHub en tant que problèmes ou pull requests. Il existe également une liste de diffusion pour discussion générale.

Nous fournissons volontiers l'information dans plusieurs langues, cependant, s'il existe un conflit ou une contradiction entre les traductions, la version anglaise est la version qui fait autorité.
Si c'est votre projet, veuillez afficher votre statut de badge de référence sur la page de votre projet ! Le statut du badge de référence ressemble à ceci : Le niveau du badge de référence pour le projet 14187 est in_progress Voici comment intégrer le badge de référence :
Vous pouvez afficher votre statut de badge de référence en incorporant ceci dans votre fichier markdown :
[![OpenSSF Baseline](https://www.bestpractices.dev/projects/14187/baseline)](https://www.bestpractices.dev/projects/14187)
ou en incorporant ceci dans votre HTML :
<a href="https://www.bestpractices.dev/projects/14187"><img src="https://www.bestpractices.dev/projects/14187/baseline"></a>


Voici les critères du niveau de référence 3. Il s'agit des critères version v2026.08.28.

Baseline Series: Niveau de référence 1 Niveau de référence 2 Niveau de référence 3

        

 Notions de base

  • Général

    Notez que d'autres projets peuvent utiliser le même nom.

    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.

    Utilisez un format d'expression de licence SPDX ; des exemples sont « Apache-2.0 », « BSD-2-Clause », « BSD-3-Clause », « GPL-2.0+ », « LGPL-3.0+ », « MIT » et « (BSD-2-Clause OU Ruby) ». Ne pas inclure des guillemets simples ou doubles.
    S'il y a plus d'un langage, listez-les en tant que valeurs séparées par des virgules (espaces facultatifs) et triez-les du plus au moins utilisé. S'il y a une longue liste, veuillez lister au moins les trois premiers. S'il n'y a pas de langage (par exemple, il s'agit d'un projet uniquement de documentation ou de test), utilisez le caractère unique « - ». Utilisez une capitalisation conventionnelle pour chaque langage, par exemple « JavaScript ».
    La plate-forme commune d'énumération (CPE) est un schéma de dénomination structuré pour les systèmes, les logiciels et les paquetages des technologies de l'information. Il est utilisé dans un certain nombre de systèmes et de bases de données pour signaler des vulnérabilités.

 Contrôles 9/21 ●

  • Contrôles


    Assez pour un badge !

    Lorsqu'une tâche se voit attribuer des permissions dans un pipeline CI/CD, le code source ou la configuration DOIT attribuer uniquement les privilèges minimaux nécessaires pour l'activité correspondante. [OSPS-AC-04.02]
    Configurez les pipelines CI/CD du projet pour attribuer les permissions les plus basses disponibles aux utilisateurs et services par défaut, en élevant les permissions seulement lorsque nécessaire pour des tâches spécifiques. Dans certains systèmes de gestion de version, cela peut être possible au niveau de l'organisation ou du dépôt. Sinon, définissez les permissions au niveau supérieur du pipeline.

    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


    Pas assez pour un badge.

    Les pipelines CI/CD qui acceptent des entrées de collaborateurs de confiance DOIVENT assainir et valider ces entrées avant de les utiliser dans le pipeline. [OSPS-BR-01.04]
    Les pipelines CI/CD doivent assainir (mettre entre guillemets, échapper ou quitter pour les valeurs attendues) toutes les entrées des collaborateurs lors des exécutions explicites de workflows. Bien que les collaborateurs soient généralement de confiance, les entrées manuelles dans un workflow ne peuvent pas être revues et pourraient être détournées par une prise de contrôle de compte ou une menace interne.

    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


    Assez pour un badge !

    Lorsqu'une version officielle est créée, tous les actifs de cette version DOIVENT être clairement associés à l'identifiant de version ou un autre identifiant unique pour l'actif. [OSPS-BR-02.02]
    Attribuez un identifiant de version unique à chaque actif logiciel produit par le projet, en suivant une convention de nommage ou un schéma de numérotation cohérent. Les exemples incluent SemVer, CalVer, ou l'id de commit 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


    Pas assez pour un badge.

    Le projet DOIT définir une politique pour gérer les secrets et informations d'identification utilisés par le projet. La politique devrait inclure des directives pour stocker, accéder et faire tourner les secrets et informations d'identification. [OSPS-BR-07.02]
    Documentez comment les secrets et informations d'identification sont gérés et utilisés dans le projet. Cela devrait inclure des détails sur la façon dont les secrets sont stockés (par exemple, en utilisant un outil de gestion de secrets), comment l'accès est contrôlé, et comment les secrets sont renouvelés ou mis à jour. Assurez-vous que les informations sensibles ne sont pas codées en dur dans le code source ou stockées dans les systèmes de gestion de version.

    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


    Pas assez pour un badge.

    Lorsque le projet a fait une version, la documentation du projet DOIT contenir des instructions pour vérifier l'intégrité et l'authenticité des actifs de la version. [OSPS-DO-03.01]
    Les instructions dans le projet devraient contenir des informations sur la technologie utilisée, les commandes à exécuter et la sortie attendue. Lorsque cela est possible, évitez de stocker cette documentation au même endroit que le pipeline de construction et de publication pour éviter qu'une seule violation ne compromette à la fois le logiciel et la documentation pour vérifier l'intégrité du logiciel.

    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


    Pas assez pour un badge.

    Lorsque le projet a fait une version, la documentation du projet DOIT contenir des instructions pour vérifier l'identité attendue de la personne ou du processus créant la version logicielle. [OSPS-DO-03.02]
    L'identité attendue peut être sous la forme d'identifiants de clés utilisés pour signer, d'émetteur et d'identité d'un certificat sigstore, ou d'autres formes similaires. Lorsque cela est possible, évitez de stocker cette documentation au même endroit que le pipeline de construction et de publication pour éviter qu'une seule violation ne compromette à la fois le logiciel et la documentation pour vérifier l'intégrité du logiciel.

    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


    Assez pour un badge !

    Quand le projet a publié une version, la documentation du projet DOIT inclure une déclaration descriptive sur la portée et la durée du support pour chaque version. [OSPS-DO-04.01]
    Afin de communiquer la portée et la durée du support pour les actifs logiciels publiés par le projet, le projet devrait avoir un fichier SUPPORT.md, une section « Support » dans SECURITY.md, ou toute autre documentation expliquant le cycle de vie du support, y compris la durée prévue du support pour chaque version, les types de support fournis (par exemple, corrections de bugs, mises à jour de sécurité), et toutes politiques ou procédures pertinentes pour obtenir du support.

    .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


    Assez pour un badge !

    Quand le projet a publié une version, la documentation du projet DOIT fournir une déclaration descriptive sur le moment où les versions ne recevront plus de mises à jour de sécurité. [OSPS-DO-05.01]
    Afin de communiquer la portée et la durée du support pour les corrections de sécurité, le projet devrait avoir un fichier SUPPORT.md ou autre documentation expliquant la politique du projet pour les mises à jour de sécurité.

    .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


    Assez pour un badge !

    La documentation du projet DOIT comporter une politique selon laquelle les collaborateurs de code sont examinés avant l'octroi de permissions élevées sur des ressources sensibles. [OSPS-GV-04.01]
    Publiez une politique applicable dans la documentation du projet qui exige que les collaborateurs de code soient examinés et approuvés avant de se voir accorder des permissions élevées aux ressources sensibles, telles que l'approbation de fusion ou l'accès aux secrets. Il est recommandé que l'examen comprenne l'établissement d'une lignée d'identité justifiable, comme la confirmation de l'association du contributeur avec une organisation de confiance connue.

    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


    Pas assez pour un badge.

    Quand le projet a publié une version, tous les actifs logiciels compilés publiés DOIVENT être livrés avec une nomenclature logicielle. [OSPS-QA-02.02]
    Il est recommandé de générer automatiquement les SBOM au moment de la compilation en utilisant un outil dont la précision a été vérifiée. Cela permet aux utilisateurs d'ingérer ces données de manière standardisée aux côtés d'autres projets dans leur environnement.

    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.


    Assez pour un badge !

    Quand le projet a publié une version comprenant plusieurs dépôts de code source, tous les sous-projets DOIVENT appliquer des exigences de sécurité aussi strictes ou plus strictes que la base de code principale. [OSPS-QA-04.02]
    Tous les dépôts de code de sous-projets supplémentaires produits par le projet et compilés dans une version doivent appliquer des exigences de sécurité selon le statut et l'objectif de la base de code respective. En plus de suivre les exigences Baseline OSPS correspondantes, cela peut inclure l'exigence d'un examen de sécurité, garantir qu'il est exempt de vulnérabilités et garantir qu'il est exempt de problèmes de sécurité connus.

    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


    Assez pour un badge !

    La documentation du projet DOIT clairement documenter quand et comment les tests sont exécutés. [OSPS-QA-06.02]
    Ajoutez une section à la documentation de contribution qui explique comment exécuter les tests localement et comment exécuter les tests dans le pipeline CI/CD. La documentation devrait expliquer ce que les tests testent et comment interpréter les résultats.

    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


    Assez pour un badge !

    La documentation du projet DOIT inclure une politique selon laquelle tous les changements majeurs apportés au logiciel produit par le projet devraient ajouter ou mettre à jour des tests de la fonctionnalité dans une suite de tests automatisée. [OSPS-QA-06.03]
    Ajoutez une section à la documentation de contribution qui explique la politique d'ajout ou de mise à jour des tests. La politique devrait expliquer ce qui constitue un changement majeur et quels tests doivent être ajoutés ou mis à jour.

    .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


    Pas assez pour un badge.

    Quand un commit est effectué vers la branche principale, le système de contrôle de version du projet DOIT exiger au moins une approbation humaine non auteur des changements avant la fusion. [OSPS-QA-07.01]
    Configurez le système de contrôle de version du projet pour exiger au moins une approbation humaine non auteur des changements avant la fusion dans la branche de publication ou principale. Cela peut être réalisé en exigeant qu'une pull request soit examinée et approuvée par au moins un autre collaborateur avant qu'elle puisse être fusionnée.

    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


    Assez pour un badge !

    Quand le projet a publié une version, le projet DOIT effectuer une modélisation des menaces et une analyse de la surface d'attaque pour comprendre et se protéger contre les attaques sur les chemins de code critiques, les fonctions et les interactions au sein du système. [OSPS-SA-03.02]
    La modélisation des menaces est une activité où le projet examine la base de code, les processus et l'infrastructure associés, les interfaces, les composants clés et « pense comme un pirate » et réfléchit à la manière dont le système pourrait être cassé ou compromis. Chaque menace identifiée est répertoriée afin que le projet puisse ensuite réfléchir à la manière d'éviter ou de combler de manière proactive toute lacune ou vulnérabilité qui pourrait survenir. Assurez-vous que cela est mis à jour pour les nouvelles fonctionnalités ou les changements majeurs.

    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


    Pas assez pour un badge.

    Toute vulnérabilité présente dans les composants logiciels mais n'affectant pas le projet DOIT être prise en compte dans un document VEX, en complétant le rapport de vulnérabilité avec des détails sur la non-exploitabilité. [OSPS-VM-04.02]
    Établissez un flux VEX communiquant le statut d'exploitabilité des vulnérabilités connues, y compris les détails d'évaluation ou toute mesure d'atténuation en place empêchant l'exécution du code vulnérable.

    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


    Pas assez pour un badge.

    La documentation du projet DOIT inclure une politique qui définit un seuil pour la remédiation des résultats d'analyse de composition logicielle (SCA) liés aux vulnérabilités et aux licences. [OSPS-VM-05.01]
    Documentez une politique dans le projet qui définit un seuil pour la résolution des résultats SCA liés aux vulnérabilités et aux licences. Incluez le processus pour identifier, prioriser et résoudre ces résultats.

    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


    Pas assez pour un badge.

    La documentation du projet DOIT inclure une politique pour traiter les violations SCA avant toute publication. [OSPS-VM-05.02]
    Documentez une politique dans le projet pour traiter les résultats applicables de l'analyse de composition du logiciel avant toute publication, et ajoutez des vérifications de statut qui vérifient la conformité avec cette politique avant la publication.

    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


    Pas assez pour un badge.

    Tous les changements apportés à la base de code du projet DOIVENT être automatiquement évalués par rapport à une politique documentée concernant les dépendances malveillantes et les vulnérabilités connues dans les dépendances, puis bloqués en cas de violation, sauf lorsqu'ils sont déclarés et supprimés comme non exploitables. [OSPS-VM-05.03]
    Créez une vérification de statut dans le système de contrôle de version du projet qui exécute un outil d'analyse de composition du logiciel sur toutes les modifications apportées à la base de code. Exigez que la vérification de statut réussisse avant que les modifications puissent être fusionnées.

    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


    Pas assez pour un badge.

    La documentation du projet DOIT inclure une politique qui définit un seuil pour la remédiation des résultats d'analyse statique de sécurité (SAST). [OSPS-VM-06.01]
    Documentez une politique dans le projet qui définit un seuil pour la résolution des résultats des tests de sécurité des applications statiques (SAST). Incluez le processus pour identifier, prioriser et résoudre ces résultats.

    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


    Pas assez pour un badge.

    Tous les changements apportés à la base de code du projet DOIVENT être automatiquement évalués par rapport à une politique documentée concernant les faiblesses de sécurité et bloqués en cas de violation, sauf lorsqu'ils sont déclarés et supprimés comme non exploitables. [OSPS-VM-06.02]
    Créez une vérification de statut dans le système de contrôle de version du projet qui exécute un outil de test de sécurité des applications statiques (SAST) sur toutes les modifications apportées à la base de code. Exigez que la vérification de statut réussisse avant que les modifications puissent être fusionnées.

    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



Vous pouvez utiliser des outils et des systèmes d'IA pour proposer des modifications via une URL simple, par exemple https://www.bestpractices.dev/fr/projects/14187/choose/edit?osps_ac_01_01_status=Met&osps_ac_01_01_justification=GitHub+enforced. Consultez notre système de propositions d'automatisation pour savoir comment procéder. Ces données sont disponibles sous la licence Community Data License Agreement – Permissive, Version 2.0 (CDLA-Permissive-2.0). Cela signifie qu'un destinataire de données peut partager les données, avec ou sans modifications, à condition que le destinataire de données rende disponible le texte de cet accord avec les données partagées. Veuillez créditer Progressive Robot et les contributeurs du badge des meilleures pratiques de la OpenSSF.

Soumission du badge du projet appartenant à : Progressive Robot.
Soumission créée le 2026-08-21 05:37:27 UTC, dernière mise à jour le 2026-09-12 02:50:23 UTC. Le dernier badge obtenu l'a été le 2026-08-21 17:17:16 UTC.