hMailServer

Los proyectos que siguen las mejores prácticas a continuación pueden autocertificarse voluntariamente y demostrar que han obtenido una insignia de mejores prácticas de Open Source Security Foundation (OpenSSF).

No existe un conjunto de prácticas que pueda garantizar que el software nunca tendrá defectos o vulnerabilidades; incluso los métodos formales pueden fallar si las especificaciones o suposiciones son incorrectas. Tampoco existe ningún conjunto de prácticas que pueda garantizar que un proyecto mantenga una comunidad de desarrollo saludable y que funcione bien. Sin embargo, seguir las mejores prácticas puede ayudar a mejorar los resultados de los proyectos. Por ejemplo, algunas prácticas permiten la revisión por parte de múltiples personas antes del lanzamiento, lo que puede ayudar a encontrar vulnerabilidades técnicas que de otro modo serían difíciles de encontrar y ayudar a generar confianza y un deseo repetido de interacción entre desarrolladores de diferentes compañías. Para obtener una insignia, se deben cumplir todos los criterios DEBE y NO DEBE, se deben cumplir, así como todos los criterios DEBERÍAN deben cumplirse o ser justificados, y todos los criterios SUGERIDOS se pueden cumplir o incumplir (queremos que se consideren al menos). Si desea añadir texto como justificación mediante un comentario genérico, en lugar de ser un razonamiento de que la situación es aceptable, comience el bloque de texto con '//' seguido de un espacio. Los comentarios son bienvenidos a través del sitio de GitHub mediante "issues" o "pull requests". También hay una lista de correo electrónico para el tema principal.

Con mucho gusto proporcionaríamos la información en varios idiomas, sin embargo, si hay algún conflicto o inconsistencia entre las traducciones, la versión en inglés es la versión autorizada.
Si este es su proyecto, por favor muestre el estado de su insignia base en la página de su proyecto. El estado de la insignia base se ve así: El nivel de insignia base para el proyecto 14187 es in_progress Aquí se explica cómo insertar la insignia base:
Puede mostrar el estado de su insignia base insertando esto en su archivo markdown:
[![OpenSSF Baseline](https://www.bestpractices.dev/projects/14187/baseline)](https://www.bestpractices.dev/projects/14187)
o insertando esto en su HTML:
<a href="https://www.bestpractices.dev/projects/14187"><img src="https://www.bestpractices.dev/projects/14187/baseline"></a>


Estos son los criterios de Nivel Base 3. Estos son los criterios de la versión v2026.08.28.

Baseline Series: Nivel Base 1 Nivel Base 2 Nivel Base 3

        

 Fundamentos

  • General

    Tenga en cuenta que otros proyectos pueden usar el mismo nombre.

    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.

    Por favor use formato de expresión de licencia SPDX; los ejemplos incluyen "Apache-2.0", "BSD-2-Clause", "BSD-3-Clause", "GPL-2.0+", "LGPL-3.0+", "MIT" y "(BSD-2-Clause OR Ruby)". No incluya comillas simples o comillas dobles.
    Si hay más de un lenguaje, enumérelos como valores separados por comas (los espacios son opcionales) y ordénelos de más a menos usado. Si hay una lista larga, por favor enumere al menos los tres primeros más comunes. Si no hay lenguaje (por ejemplo, este es un proyecto solo de documentación o solo de pruebas), use el carácter único "-". Por favor use una capitalización convencional para cada lenguaje, por ejemplo, "JavaScript".
    La Common Platform Enumeration (CPE) es un esquema de nomenclatura estructurado para sistemas de tecnología de la información, software y paquetes. Se utiliza en varios sistemas y bases de datos al reportar vulnerabilidades.

 Controles 9/21 ●

  • Controles


    ¡Suficiente para una insignia!

    Cuando se asigna permisos a un trabajo en un pipeline de CI/CD, el código fuente o configuración DEBE asignar solo los privilegios mínimos necesarios para la actividad correspondiente. [OSPS-AC-04.02]
    Configure los pipelines de CI/CD del proyecto para asignar los permisos más bajos disponibles a usuarios y servicios por defecto, elevando los permisos solo cuando sea necesario para tareas específicas. En algunos sistemas de control de versiones, esto puede ser posible a nivel organizacional o de repositorio. Si no es posible, establezca los permisos en el nivel superior del 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


    No es suficiente para una insignia.

    Los flujos de CI/CD que aceptan entradas de colaboradores de confianza DEBEN sanear y validar dichas entradas antes de utilizarlas en el flujo. [OSPS-BR-01.04]
    Los flujos de CI/CD deben sanear (entre comillas, escapar o salir en valores esperados) todas las entradas de colaboradores en ejecuciones explícitas de flujos de trabajo. Aunque los colaboradores son generalmente de confianza, las entradas manuales a un flujo de trabajo no pueden revisarse y podrían ser abusadas por una toma de control de cuenta o una amenaza interna.

    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


    ¡Suficiente para una insignia!

    Cuando se crea un lanzamiento oficial, todos los activos dentro de ese lanzamiento DEBEN estar claramente asociados con el identificador del lanzamiento u otro identificador único para el activo. [OSPS-BR-02.02]
    Asigne un identificador de versión único a cada activo de software producido por el proyecto, siguiendo una convención de nomenclatura o esquema de numeración consistente. Ejemplos incluyen SemVer, CalVer, o git commit id.

    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


    No es suficiente para una insignia.

    El proyecto DEBE definir una política para gestionar secretos y credenciales utilizados por el proyecto. La política debe incluir directrices para almacenar, acceder y rotar secretos y credenciales. [OSPS-BR-07.02]
    Documente cómo se gestionan y utilizan los secretos y credenciales dentro del proyecto. Esto debe incluir detalles sobre cómo se almacenan los secretos (por ejemplo, utilizando una herramienta de gestión de secretos), cómo se controla el acceso y cómo se rotan o actualizan los secretos. Asegúrese de que la información sensible no esté codificada directamente en el código fuente ni almacenada en sistemas de control de versiones.

    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


    No es suficiente para una insignia.

    Cuando el proyecto haya realizado un lanzamiento, la documentación del proyecto DEBE contener instrucciones para verificar la integridad y autenticidad de los activos del lanzamiento. [OSPS-DO-03.01]
    Las instrucciones en el proyecto deben contener información sobre la tecnología utilizada, los comandos a ejecutar y la salida esperada. Cuando sea posible, evite almacenar esta documentación en la misma ubicación que el pipeline de compilación y lanzamiento para evitar que una sola violación comprometa tanto el software como la documentación para verificar la integridad del software.

    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


    No es suficiente para una insignia.

    Cuando el proyecto haya realizado un lanzamiento, la documentación del proyecto DEBE contener instrucciones para verificar la identidad esperada de la persona o proceso que crea el lanzamiento del software. [OSPS-DO-03.02]
    La identidad esperada puede estar en forma de IDs de clave utilizados para firmar, emisor e identidad de un certificado sigstore, u otras formas similares. Cuando sea posible, evite almacenar esta documentación en la misma ubicación que el pipeline de compilación y lanzamiento para evitar que una sola violación comprometa tanto el software como la documentación para verificar la integridad del software.

    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


    ¡Suficiente para una insignia!

    Cuando el proyecto haya realizado un lanzamiento, la documentación del proyecto DEBE incluir una declaración descriptiva sobre el alcance y la duración del soporte para cada lanzamiento. [OSPS-DO-04.01]
    Para comunicar el alcance y la duración del soporte para los activos de software lanzados del proyecto, el proyecto debe tener un archivo SUPPORT.md, una sección "Soporte" en SECURITY.md, u otra documentación que explique el ciclo de vida del soporte, incluyendo la duración esperada del soporte para cada lanzamiento, los tipos de soporte proporcionados (por ejemplo, corrección de errores, actualizaciones de seguridad), y cualquier política o procedimiento relevante para obtener soporte.

    .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


    ¡Suficiente para una insignia!

    Cuando el proyecto haya realizado un lanzamiento, la documentación del proyecto DEBE proporcionar una declaración descriptiva sobre cuándo los lanzamientos o versiones ya no recibirán actualizaciones de seguridad. [OSPS-DO-05.01]
    Para comunicar el alcance y la duración del soporte para correcciones de seguridad, el proyecto debe tener un SUPPORT.md u otra documentación que explique la política del proyecto para actualizaciones de seguridad.

    .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


    ¡Suficiente para una insignia!

    La documentación del proyecto DEBE tener una política que exija que los colaboradores de código sean revisados antes de otorgarles permisos elevados a recursos sensibles. [OSPS-GV-04.01]
    Publique una política exigible en la documentación del proyecto que requiera que los colaboradores de código sean revisados y aprobados antes de otorgarles permisos elevados a recursos sensibles, como aprobación de fusiones o acceso a secretos. Se recomienda que la verificación incluya establecer un linaje justificable de identidad, como confirmar la asociación del colaborador con una organización confiable conocida.

    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


    No es suficiente para una insignia.

    Cuando el proyecto haya realizado un lanzamiento, todos los activos de software compilados lanzados DEBEN ser entregados con una lista de materiales de software. [OSPS-QA-02.02]
    Se recomienda generar automáticamente SBOMs en el momento de la compilación utilizando una herramienta que haya sido verificada para precisión. Esto permite a los usuarios ingerir estos datos en un enfoque estandarizado junto con otros proyectos en su entorno.

    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.


    ¡Suficiente para una insignia!

    Cuando el proyecto haya realizado un lanzamiento que comprenda múltiples repositorios de código fuente, todos los subproyectos DEBEN aplicar requisitos de seguridad que sean tan estrictos o más estrictos que la base de código principal. [OSPS-QA-04.02]
    Cualquier repositorio de código de subproyecto adicional producido por el proyecto y compilado en un lanzamiento debe aplicar requisitos de seguridad según sea aplicable al estado e intención de la base de código respectiva. Además de seguir los requisitos correspondientes de la Línea Base OSPS, esto puede incluir requerir una revisión de seguridad, asegurar que esté libre de vulnerabilidades y asegurar que esté libre de problemas de seguridad conocidos.

    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


    ¡Suficiente para una insignia!

    La documentación del proyecto DEBE documentar claramente cuándo y cómo se ejecutan las pruebas. [OSPS-QA-06.02]
    Agregue una sección a la documentación de contribución que explique cómo ejecutar las pruebas localmente y cómo ejecutar las pruebas en el pipeline de CI/CD. La documentación debe explicar qué están probando las pruebas y cómo interpretar los resultados.

    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


    ¡Suficiente para una insignia!

    La documentación del proyecto DEBE incluir una política de que todos los cambios importantes al software producido por el proyecto deben agregar o actualizar pruebas de la funcionalidad en un conjunto de pruebas automatizado. [OSPS-QA-06.03]
    Agregue una sección a la documentación de contribución que explique la política para agregar o actualizar pruebas. La política debe explicar qué constituye un cambio importante y qué pruebas deben agregarse o actualizarse.

    .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


    No es suficiente para una insignia.

    Cuando se realiza un commit a la rama principal, el sistema de control de versiones del proyecto DEBE requerir al menos una aprobación humana no autora de los cambios antes de fusionarlos. [OSPS-QA-07.01]
    Configure el sistema de control de versiones del proyecto para requerir al menos una aprobación humana no autora de los cambios antes de fusionarlos en la rama de lanzamiento o principal. Esto se puede lograr requiriendo que un pull request sea revisado y aprobado por al menos otro colaborador antes de que pueda fusionarse.

    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


    ¡Suficiente para una insignia!

    Cuando el proyecto haya realizado un lanzamiento, el proyecto DEBE realizar un modelado de amenazas y análisis de superficie de ataque para comprender y protegerse contra ataques en rutas de código críticas, funciones e interacciones dentro del sistema. [OSPS-SA-03.02]
    El modelado de amenazas es una actividad donde el proyecto examina la base de código, procesos asociados e infraestructura, interfaces, componentes clave y "piensa como un hacker" y hace una lluvia de ideas sobre cómo el sistema puede ser vulnerado o comprometido. Cada amenaza identificada se enumera para que el proyecto pueda pensar en cómo evitar proactivamente o cerrar cualquier brecha/vulnerabilidad que pueda surgir. Asegúrese de que esto se actualice para nuevas características o cambios importantes.

    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


    No es suficiente para una insignia.

    Cualquier vulnerabilidad en los componentes de software que no afecte al proyecto DEBE ser contabilizada en un documento VEX, complementando el informe de vulnerabilidad con detalles de no explotabilidad. [OSPS-VM-04.02]
    Establezca un feed VEX comunicando el estado de explotabilidad de vulnerabilidades conocidas, incluyendo detalles de evaluación o cualquier mitigación implementada que impida que el código vulnerable sea ejecutado.

    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


    No es suficiente para una insignia.

    La documentación del proyecto DEBE incluir una política que defina un umbral para la corrección de los hallazgos de SCA relacionados con vulnerabilidades y licencias. [OSPS-VM-05.01]
    Documente una política en el proyecto que defina un umbral para la remediación de hallazgos de Análisis de Composición de Software (SCA) relacionados con vulnerabilidades y licencias. Incluya el proceso para identificar, priorizar y remediar estos hallazgos.

    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


    No es suficiente para una insignia.

    La documentación del proyecto DEBE incluir una política para abordar las infracciones de SCA antes de cualquier lanzamiento. [OSPS-VM-05.02]
    Documente una política en el proyecto para abordar los resultados aplicables del Análisis de Composición de Software antes de cualquier lanzamiento, y agregue verificaciones de estado que comprueben el cumplimiento de esa política antes del lanzamiento.

    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


    No es suficiente para una insignia.

    Todos los cambios a la base de código del proyecto DEBEN ser evaluados automáticamente contra una política documentada de dependencias maliciosas y vulnerabilidades conocidas en las dependencias, y bloqueados en caso de infracciones, excepto cuando se declaren y se supriman por no ser explotables. [OSPS-VM-05.03]
    Cree una verificación de estado en el sistema de control de versiones del proyecto que ejecute una herramienta de Análisis de Composición de Software en todos los cambios en la base de código. Requiera que la verificación de estado pase antes de que los cambios puedan fusionarse.

    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


    No es suficiente para una insignia.

    La documentación del proyecto DEBE incluir una política que defina un umbral para la corrección de los hallazgos de SAST. [OSPS-VM-06.01]
    Documente una política en el proyecto que defina un umbral para la remediación de hallazgos de Pruebas de Seguridad de Aplicaciones Estáticas (SAST). Incluya el proceso para identificar, priorizar y remediar estos hallazgos.

    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


    No es suficiente para una insignia.

    Todos los cambios a la base de código del proyecto DEBEN ser evaluados automáticamente contra una política documentada de debilidades de seguridad y bloqueados en caso de infracciones, excepto cuando se declaren y se supriman por no ser explotables. [OSPS-VM-06.02]
    Cree una verificación de estado en el sistema de control de versiones del proyecto que ejecute una herramienta de Pruebas de Seguridad de Aplicaciones Estáticas (SAST) en todos los cambios en la base de código. Requiera que la verificación de estado pase antes de que los cambios puedan fusionarse.

    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



Puede utilizar herramientas y sistemas de IA para proponer cambios a través de una URL simple, como https://www.bestpractices.dev/es/projects/14187/choose/edit?osps_ac_01_01_status=Met&osps_ac_01_01_justification=GitHub+enforced. Consulte nuestro sistema de propuestas de automatización para saber cómo hacerlo. Estos datos están disponibles bajo el Acuerdo de Licencia de Datos de la Comunidad – Permisivo, Versión 2.0 (CDLA-Permissive-2.0). Esto significa que un Destinatario de Datos puede compartir los Datos, con o sin modificaciones, siempre que el Destinatario de Datos ponga a disposición el texto de este acuerdo con los Datos compartidos. Por favor, acredite a Progressive Robot y a los colaboradores de la insignia de Mejores Prácticas de OpenSSF.

Entrada de insignia del proyecto propiedad de: Progressive Robot.
Entrada creada el 2026-08-21 05:37:27 UTC, última actualización el 2026-09-12 02:50:23 UTC. Última obtención de la insignia de nivel básico el 2026-08-21 17:17:16 UTC.