BadgeApp

Basics

General

What is the human-readable name of the project?
Note that other projects may use the same name.

What is a brief description of the project?

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.

What is the URL for the project (as a whole)?
https://www.progressiverobot.com/hmailserver-services

What is the URL for the version control repository (it may be the same as the project URL)?
https://github.com/Progressiverobot/hmailserver

What license(s) is the project released under?
Please use SPDX license expression format; examples include "Apache-2.0", "BSD-2-Clause", "BSD-3-Clause", "GPL-2.0+", "LGPL-3.0+", "MIT", and "(BSD-2-Clause OR Ruby)". Do not include single quotes or double quotes.

What programming language(s) are used to implement the project?
If there is more than one language, list them as comma-separated values (spaces optional) and sort them from most to least used. If there is a long list, please list at least the first three most common ones. If there is no language (e.g., this is a documentation-only or test-only project), use the single character "-". Please use a conventional capitalization for each language, e.g., "JavaScript".

What is the Common Platform Enumeration (CPE) name for the project (if it has one)?
The Common Platform Enumeration (CPE) is a structured naming scheme for information technology systems, software, and packages. It is used in a number of systems and databases when reporting vulnerabilities.

Other general comments about the project:

Controls 9/21 ●

Controls

Criterion [OSPS-AC-04.02]
Met

Unmet

N/A

?

When a job is assigned permissions in a CI/CD pipeline, the source code or configuration MUST only assign the minimum privileges necessary for the corresponding activity. ^{[OSPS-AC-04.02]}
Configure the project's CI/CD pipelines to assign the lowest available permissions to users and services by default, elevating permissions only when necessary for specific tasks. In some version control systems, this may be possible at the organizational or repository level. If not, set permissions at the top level of the 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

Criterion [OSPS-BR-01.04]
Met

Unmet

N/A

?

CI/CD pipelines which accept trusted collaborator input MUST sanitize and validate that input prior to use in the pipeline. ^{[OSPS-BR-01.04]}
CI/CD pipelines should sanitize (quote, escape or exit on expected values) all collaborator inputs on explicit workflow executions. While collaborators are generally trusted, manual inputs to a workflow cannot be reviewed and could be abused by an account takeover or insider threat.

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

Criterion [OSPS-BR-02.02]
Met

Unmet

N/A

?

When an official release is created, all assets within that release MUST be clearly associated with the release identifier or another unique identifier for the asset. ^{[OSPS-BR-02.02]}
Assign a unique version identifier to each software asset produced by the project, following a consistent naming convention or numbering scheme. Examples include SemVer, CalVer, or 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

Criterion [OSPS-BR-07.02]
Met

Unmet

N/A

?

The project MUST define a policy for managing secrets and credentials used by the project. The policy should include guidelines for storing, accessing, and rotating secrets and credentials. ^{[OSPS-BR-07.02]}
Document how secrets and credentials are managed and used within the project. This should include details on how secrets are stored (e.g., using a secrets management tool), how access is controlled, and how secrets are rotated or updated. Ensure that sensitive information is not hard-coded in the source code or stored in version control systems.

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

Criterion [OSPS-DO-03.01]
Met

Unmet

N/A

?

When the project has made a release, the project documentation MUST contain instructions to verify the integrity and authenticity of the release assets. ^{[OSPS-DO-03.01]}
Instructions in the project should contain information about the technology used, the commands to run, and the expected output. When possible, avoid storing this documentation in the same location as the build and release pipeline to avoid a single breach compromising both the software and the documentation for verifying the integrity of the 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

Criterion [OSPS-DO-03.02]
Met

Unmet

N/A

?

When the project has made a release, the project documentation MUST contain instructions to verify the expected identity of the person or process authoring the software release. ^{[OSPS-DO-03.02]}
The expected identity may be in the form of key IDs used to sign, issuer and identity from a sigstore certificate, or other similar forms. When possible, avoid storing this documentation in the same location as the build and release pipeline to avoid a single breach compromising both the software and the documentation for verifying the integrity of the 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

Criterion [OSPS-DO-04.01]
Met

Unmet

N/A

?

When the project has made a release, the project documentation MUST include a descriptive statement about the scope and duration of support for each release. ^{[OSPS-DO-04.01]}
In order to communicate the scope and duration of support for the project's released software assets, the project should have a SUPPORT.md file, a "Support" section in SECURITY.md, or other documentation explaining the support lifecycle, including the expected duration of support for each release, the types of support provided (e.g., bug fixes, security updates), and any relevant policies or procedures for obtaining 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

Criterion [OSPS-DO-05.01]
Met

Unmet

N/A

?

When the project has made a release, the project documentation MUST provide a descriptive statement when releases or versions will no longer receive security updates. ^{[OSPS-DO-05.01]}
In order to communicate the scope and duration of support for security fixes, the project should have a SUPPORT.md or other documentation explaining the project's policy for security updates.

.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

Criterion [OSPS-GV-04.01]
Met

Unmet

N/A

?

The project documentation MUST have a policy that code collaborators are reviewed prior to granting escalated permissions to sensitive resources. ^{[OSPS-GV-04.01]}
Publish an enforceable policy in the project documentation that requires code collaborators to be reviewed and approved before being granted escalated permissions to sensitive resources, such as merge approval or access to secrets. It is recommended that vetting includes establishing a justifiable lineage of identity such as confirming the contributor's association with a known trusted organization.

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

Criterion [OSPS-QA-02.02]
Met

Unmet

N/A

?

When the project has made a release, all compiled released software assets MUST be delivered with a software bill of materials. ^{[OSPS-QA-02.02]}
It is recommended to auto-generate SBOMs at build time using a tool that has been vetted for accuracy. This enables users to ingest this data in a standardized approach alongside other projects in their environment.

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.

Criterion [OSPS-QA-04.02]
Met

Unmet

N/A

?

When the project has made a release comprising multiple source code repositories, all subprojects MUST enforce security requirements that are as strict or stricter than the primary codebase. ^{[OSPS-QA-04.02]}
Any additional subproject code repositories produced by the project and compiled into a release must enforce security requirements as applicable to the status and intent of the respective codebase. In addition to following the corresponding OSPS Baseline requirements, this may include requiring a security review, ensuring that it is free of vulnerabilities, and ensuring that it is free of known security issues.

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

Criterion [OSPS-QA-06.02]
Met

Unmet

N/A

?

The project documentation MUST clearly document when and how tests are run. ^{[OSPS-QA-06.02]}
Add a section to the contributing documentation that explains how to run the tests locally and how to run the tests in the CI/CD pipeline. The documentation should explain what the tests are testing and how to interpret the results.

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

Criterion [OSPS-QA-06.03]
Met

Unmet

N/A

?

The project documentation MUST include a policy that all major changes to the software produced by the project should add or update tests of the functionality in an automated test suite. ^{[OSPS-QA-06.03]}
Add a section to the contributing documentation that explains the policy for adding or updating tests. The policy should explain what constitutes a major change and what tests should be added or updated.

.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

Criterion [OSPS-QA-07.01]
Met

Unmet

N/A

?

When a commit is made to the primary branch, the project's version control system MUST require at least one non-author human approval of the changes before merging. ^{[OSPS-QA-07.01]}
Configure the project's version control system to require at least one non-author human approval of changes before merging into the release or primary branch. This can be achieved by requiring a pull request to be reviewed and approved by at least one other collaborator before it can be merged.

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

Criterion [OSPS-SA-03.02]
Met

Unmet

N/A

?

When the project has made a release, the project MUST perform a threat modeling and attack surface analysis to understand and protect against attacks on critical code paths, functions, and interactions within the system. ^{[OSPS-SA-03.02]}
Threat modeling is an activity where the project looks at the codebase, associated processes and infrastructure, interfaces, key components and "thinks like a hacker" and brainstorms how the system be be broken or compromised. Each identified threat is listed out so the project can then think about how to proactively avoid or close off any gaps/vulnerabilities that could arise. Ensure this is updated for new features or breaking changes.

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

Criterion [OSPS-VM-04.02]
Met

Unmet

N/A

?

Any vulnerabilities in the software components not affecting the project MUST be accounted for in a VEX document, augmenting the vulnerability report with non-exploitability details. ^{[OSPS-VM-04.02]}
Establish a VEX feed communicating the exploitability status of known vulnerabilities, including assessment details or any mitigations in place preventing vulnerable code from being executed.

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

Criterion [OSPS-VM-05.01]
Met

Unmet

N/A

?

The project documentation MUST include a policy that defines a threshold for remediation of SCA findings related to vulnerabilities and licenses. ^{[OSPS-VM-05.01]}
Document a policy in the project that defines a threshold for remediation of SCA findings related to vulnerabilities and licenses. Include the process for identifying, prioritizing, and remediating these findings.

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

Criterion [OSPS-VM-05.02]
Met

Unmet

N/A

?

The project documentation MUST include a policy to address SCA violations prior to any release. ^{[OSPS-VM-05.02]}
Document a policy in the project to address applicable Software Composition Analysis results before any release, and add status checks that verify compliance with that policy prior to release.

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

Criterion [OSPS-VM-05.03]
Met

Unmet

N/A

?

All changes to the project's codebase MUST be automatically evaluated against a documented policy for malicious dependencies and known vulnerabilities in dependencies, then blocked in the event of violations, except when declared and suppressed as non-exploitable. ^{[OSPS-VM-05.03]}
Create a status check in the project's version control system that runs a Software Composition Analysis tool on all changes to the codebase. Require that the status check passes before changes can be merged.

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

Criterion [OSPS-VM-06.01]
Met

Unmet

N/A

?

The project documentation MUST include a policy that defines a threshold for remediation of SAST findings. ^{[OSPS-VM-06.01]}
Document a policy in the project that defines a threshold for remediation of Static Application Security Testing (SAST) findings. Include the process for identifying, prioritizing, and remediating these findings.

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

Criterion [OSPS-VM-06.02]
Met

Unmet

N/A

?

All changes to the project's codebase MUST be automatically evaluated against a documented policy for security weaknesses and blocked in the event of violations except when declared and suppressed as non-exploitable. ^{[OSPS-VM-06.02]}
Create a status check in the project's version control system that runs a Static Application Security Testing (SAST) tool on all changes to the codebase. Require that the status check passes before changes can be merged.

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

You can use tools and AI systems to propose changes via a simple URL, such as https://www.bestpractices.dev/en/projects/14187/choose/edit?osps_ac_01_01_status=Met&osps_ac_01_01_justification=GitHub+enforced. See our automation proposals system for how to do that. This data is available under the Community Data License Agreement – Permissive, Version 2.0 (CDLA-Permissive-2.0). This means that a Data Recipient may share the Data, with or without modifications, so long as the Data Recipient makes available the text of this agreement with the shared Data. Please credit Progressive Robot and the OpenSSF Best Practices badge contributors.

hMailServer

Basics

General

Controls 9/21 ●

Controls