BadgeApp

Fundamentos

Geral

Qual é o nome legível do projeto?
Observe que outros projetos podem usar o mesmo nome.

Qual é uma breve descrição do projeto?

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.

Qual é a URL do projeto (como um todo)?
https://www.progressiverobot.com/hmailserver-services

Qual é a URL do repositório de controle de versão (pode ser a mesma URL do projeto)?
https://github.com/Progressiverobot/hmailserver

Sob qual(is) licença(s) o projeto é liberado?
Use o formato de expressão de licença SPDX; exemplos incluem "Apache-2.0", "BSD-2-Clause", "BSD-3-Clause", "GPL-2.0+", "LGPL-3.0+", "MIT" e "(BSD-2-Clause OR Ruby)". Não inclua aspas simples ou aspas duplas.

Qual(is) linguagem(ns) de programação são usadas para implementar o projeto?
Se houver mais de uma linguagem, liste-as como valores separados por vírgula (espaços opcionais) e ordene-as da mais usada para a menos usada. Se houver uma longa lista, liste pelo menos as três primeiras mais comuns. Se não houver linguagem (por exemplo, este é um projeto apenas de documentação ou apenas de teste), use o caractere único "-". Use uma capitalização convencional para cada linguagem, por exemplo, "JavaScript".

Qual é o nome Common Platform Enumeration (CPE) do projeto (se houver um)?
O Common Platform Enumeration (CPE) é um esquema de nomenclatura estruturado para sistemas de tecnologia da informação, software e pacotes. Ele é usado em vários sistemas e bancos de dados ao relatar vulnerabilidades.

Outros comentários gerais sobre o projeto:

Controles 9/21 ●

Controles

Criterion [OSPS-AC-04.02]
Atendido

Não atendido

N/A

?

Quando um trabalho recebe permissões em um pipeline de CI/CD, o código-fonte ou configuração DEVE atribuir apenas os privilégios mínimos necessários para a atividade correspondente. ^{[OSPS-AC-04.02]}
Configure os pipelines de CI/CD do projeto para atribuir as menores permissões disponíveis a usuários e serviços por padrão, elevando as permissões apenas quando necessário para tarefas específicas. Em alguns sistemas de controle de versão, isso pode ser possível no nível organizacional ou de repositório. Se não, defina permissões no nível superior do 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]
Atendido

Não atendido

N/A

?

Os pipelines de CI/CD que aceitam entradas de colaboradores confiáveis DEVEM sanitizar e validar essas entradas antes de usá-las no pipeline. ^{[OSPS-BR-01.04]}
Os pipelines de CI/CD devem sanitizar (citar, escapar ou sair com valores esperados) todas as entradas de colaboradores em execuções explícitas de workflow. Embora os colaboradores sejam geralmente confiáveis, as entradas manuais em um workflow não podem ser revisadas e podem ser abusadas por uma tomada de conta ou ameaça 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

Criterion [OSPS-BR-02.02]
Atendido

Não atendido

N/A

?

Quando um lançamento oficial for criado, todos os ativos dentro desse lançamento DEVEM estar claramente associados ao identificador de lançamento ou outro identificador único para o ativo. ^{[OSPS-BR-02.02]}
Atribua um identificador de versão único a cada ativo de software produzido pelo projeto, seguindo uma convenção de nomenclatura ou esquema de numeração consistente. Exemplos incluem SemVer, CalVer ou id de commit do 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

Criterion [OSPS-BR-07.02]
Atendido

Não atendido

N/A

?

O projeto DEVE definir uma política para gerenciar segredos e credenciais usadas pelo projeto. A política deve incluir diretrizes para armazenar, acessar e rotacionar segredos e credenciais. ^{[OSPS-BR-07.02]}
Documente como segredos e credenciais são gerenciados e usados dentro do projeto. Isso deve incluir detalhes sobre como os segredos são armazenados (por exemplo, usando uma ferramenta de gerenciamento de segredos), como o acesso é controlado e como os segredos são rotacionados ou atualizados. Certifique-se de que informações sensíveis não sejam codificadas diretamente no código-fonte ou armazenadas em sistemas de controle de versão.

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]
Atendido

Não atendido

N/A

?

Quando o projeto tiver feito um lançamento, a documentação do projeto DEVE conter instruções para verificar a integridade e autenticidade dos ativos de lançamento. ^{[OSPS-DO-03.01]}
As instruções no projeto devem conter informações sobre a tecnologia usada, os comandos a serem executados e a saída esperada. Quando possível, evite armazenar essa documentação no mesmo local que o pipeline de construção e lançamento para evitar que uma única violação comprometa tanto o software quanto a documentação para verificar a integridade do 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]
Atendido

Não atendido

N/A

?

Quando o projeto tiver feito um lançamento, a documentação do projeto DEVE conter instruções para verificar a identidade esperada da pessoa ou processo que criou o lançamento de software. ^{[OSPS-DO-03.02]}
A identidade esperada pode estar na forma de IDs de chave usados para assinar, emissor e identidade de um certificado sigstore ou outras formas similares. Quando possível, evite armazenar essa documentação no mesmo local que o pipeline de construção e lançamento para evitar que uma única violação comprometa tanto o software quanto a documentação para verificar a integridade do 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]
Atendido

Não atendido

N/A

?

Quando o projeto tiver feito um lançamento, a documentação do projeto DEVE incluir uma declaração descritiva sobre o escopo e a duração do suporte para cada lançamento. ^{[OSPS-DO-04.01]}
Para comunicar o escopo e a duração do suporte para os ativos de software lançados pelo projeto, o projeto deve ter um arquivo SUPPORT.md, uma seção "Support" em SECURITY.md ou outra documentação explicando o ciclo de vida do suporte, incluindo a duração esperada de suporte para cada lançamento, os tipos de suporte fornecidos (por exemplo, correções de bugs, atualizações de segurança) e quaisquer políticas ou procedimentos relevantes para obter suporte.

.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]
Atendido

Não atendido

N/A

?

Quando o projeto tiver feito um lançamento, a documentação do projeto DEVE fornecer uma declaração descritiva de quando lançamentos ou versões não receberão mais atualizações de segurança. ^{[OSPS-DO-05.01]}
Para comunicar o escopo e a duração do suporte para correções de segurança, o projeto deve ter um SUPPORT.md ou outra documentação explicando a política do projeto para atualizações de segurança.

.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]
Atendido

Não atendido

N/A

?

A documentação do projeto DEVE ter uma política de que os colaboradores de código sejam revisados antes de conceder permissões elevadas a recursos sensíveis. ^{[OSPS-GV-04.01]}
Publique uma política aplicável na documentação do projeto que exija que colaboradores de código sejam revisados e aprovados antes de receberem permissões elevadas a recursos sensíveis, como aprovação de merge ou acesso a segredos. É recomendado que a verificação inclua estabelecer uma linhagem justificável de identidade, como confirmar a associação do contribuidor com uma organização confiável conhecida.

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]
Atendido

Não atendido

N/A

?

Quando o projeto tiver feito um lançamento, todos os ativos de software compilados lançados DEVEM ser entregues com uma lista de materiais de software. ^{[OSPS-QA-02.02]}
É recomendado gerar automaticamente SBOMs no momento da compilação usando uma ferramenta que foi verificada quanto à precisão. Isso permite que os usuários ingiram esses dados de forma padronizada junto com outros projetos em seu ambiente.

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]
Atendido

Não atendido

N/A

?

Quando o projeto tiver feito um lançamento compreendendo múltiplos repositórios de código-fonte, todos os subprojetos DEVEM impor requisitos de segurança que sejam tão rigorosos ou mais rigorosos que a base de código principal. ^{[OSPS-QA-04.02]}
Quaisquer repositórios de código de subprojeto adicionais produzidos pelo projeto e compilados em um lançamento devem impor requisitos de segurança conforme aplicável ao status e intenção da respectiva base de código. Além de seguir os requisitos correspondentes da Linha de Base OSPS, isso pode incluir exigir uma revisão de segurança, garantir que esteja livre de vulnerabilidades e garantir que esteja livre de problemas de segurança conhecidos.

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]
Atendido

Não atendido

N/A

?

A documentação do projeto DEVE documentar claramente quando e como os testes são executados. ^{[OSPS-QA-06.02]}
Adicione uma seção à documentação de contribuição que explique como executar os testes localmente e como executar os testes no pipeline de CI/CD. A documentação deve explicar o que os testes estão testando e como interpretar os 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

Criterion [OSPS-QA-06.03]
Atendido

Não atendido

N/A

?

A documentação do projeto DEVE incluir uma política de que todas as mudanças importantes no software produzido pelo projeto devem adicionar ou atualizar testes da funcionalidade em um conjunto de testes automatizado. ^{[OSPS-QA-06.03]}
Adicione uma seção à documentação de contribuição que explique a política para adicionar ou atualizar testes. A política deve explicar o que constitui uma mudança importante e quais testes devem ser adicionados ou atualizados.

.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]
Atendido

Não atendido

N/A

?

Quando um commit for feito no branch principal, o sistema de controle de versão do projeto DEVE exigir pelo menos uma aprovação humana não-autora das mudanças antes do merge. ^{[OSPS-QA-07.01]}
Configure o sistema de controle de versão do projeto para exigir pelo menos uma aprovação humana não-autora das mudanças antes de fazer merge no branch de lançamento ou principal. Isso pode ser alcançado exigindo que um pull request seja revisado e aprovado por pelo menos um outro colaborador antes que possa ser feito o merge.

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]
Atendido

Não atendido

N/A

?

Quando o projeto tiver feito um lançamento, o projeto DEVE realizar uma modelagem de ameaças e análise de superfície de ataque para entender e proteger contra ataques em caminhos de código críticos, funções e interações dentro do sistema. ^{[OSPS-SA-03.02]}
Modelagem de ameaças é uma atividade onde o projeto analisa a base de código, processos e infraestrutura associados, interfaces, componentes-chave e "pensa como um hacker" e faz um brainstorming de como o sistema pode ser quebrado ou comprometido. Cada ameaça identificada é listada para que o projeto possa então pensar em como evitar proativamente ou fechar quaisquer lacunas/vulnerabilidades que possam surgir. Certifique-se de que isso seja atualizado para novos recursos ou mudanças críticas.

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]
Atendido

Não atendido

N/A

?

Quaisquer vulnerabilidades nos componentes de software que não afetem o projeto DEVEM ser registradas em um documento VEX, complementando o relatório de vulnerabilidade com detalhes de não explorabilidade. ^{[OSPS-VM-04.02]}
Estabeleça um feed VEX comunicando o status de explorabilidade de vulnerabilidades conhecidas, incluindo detalhes de avaliação ou quaisquer mitigações em vigor impedindo que código vulnerável seja executado.

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]
Atendido

Não atendido

N/A

?

A documentação do projeto DEVE incluir uma política que defina um limite para a correção de descobertas de SCA relacionadas a vulnerabilidades e licenças. ^{[OSPS-VM-05.01]}
Documente uma política no projeto que defina um limite para remediação de descobertas de SCA relacionadas a vulnerabilidades e licenças. Inclua o processo para identificar, priorizar e remediar essas descobertas.

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]
Atendido

Não atendido

N/A

?

A documentação do projeto DEVE incluir uma política para tratar violações de SCA antes de qualquer lançamento. ^{[OSPS-VM-05.02]}
Documente uma política no projeto para abordar os resultados aplicáveis de Análise de Composição de Software antes de qualquer lançamento, e adicione verificações de status que confirmem a conformidade com essa política antes do lançamento.

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]
Atendido

Não atendido

N/A

?

Todas as mudanças na base de código do projeto DEVEM ser avaliadas automaticamente em relação a uma política documentada para dependências maliciosas e vulnerabilidades conhecidas em dependências, e então bloqueadas em caso de violações, exceto quando declaradas e suprimidas como não exploráveis. ^{[OSPS-VM-05.03]}
Crie uma verificação de status no sistema de controle de versão do projeto que execute uma ferramenta de Análise de Composição de Software em todas as alterações na base de código. Exija que a verificação de status seja aprovada antes que as alterações possam ser mescladas.

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]
Atendido

Não atendido

N/A

?

A documentação do projeto DEVE incluir uma política que defina um limite para a correção de descobertas de SAST. ^{[OSPS-VM-06.01]}
Documente uma política no projeto que defina um limite para remediação de resultados de Teste de Segurança de Aplicação Estática (SAST). Inclua o processo para identificar, priorizar e remediar esses resultados.

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]
Atendido

Não atendido

N/A

?

Todas as mudanças na base de código do projeto DEVEM ser avaliadas automaticamente em relação a uma política documentada para vulnerabilidades de segurança e bloqueadas em caso de violações, exceto quando declaradas e suprimidas como não exploráveis. ^{[OSPS-VM-06.02]}
Crie uma verificação de status no sistema de controle de versão do projeto que execute uma ferramenta de Teste de Segurança de Aplicação Estática (SAST) em todas as alterações na base de código. Exija que a verificação de status seja aprovada antes que as alterações possam ser mescladas.

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

Você pode usar ferramentas e sistemas de IA para propor alterações por meio de uma URL simples, como https://www.bestpractices.dev/pt-BR/projects/14187/choose/edit?osps_ac_01_01_status=Met&osps_ac_01_01_justification=GitHub+enforced. Veja nosso sistema de propostas de automação para saber como fazer isso. Estes dados estão disponíveis sob o Community Data License Agreement – Permissive, Version 2.0 (CDLA-Permissive-2.0). Isso significa que um Destinatário de Dados pode compartilhar os Dados, com ou sem modificações, desde que o Destinatário de Dados disponibilize o texto deste acordo com os Dados compartilhados. Por favor, dê crédito a Progressive Robot e aos contribuidores do selo de melhores práticas OpenSSF.

hMailServer

Fundamentos

Geral

Controles 9/21 ●

Controles