SGO - Sistema de Gestao Operacional

遵循以下最佳实践的项目将能够自愿的自我认证，并显示他们已经实现了核心基础设施计划（OpenSSF）徽章。

没有一套可以保证软件永远不会有缺陷或漏洞的做法；如果规范或假设是错误的，即使合适的方法也可能失败。也没有哪些做法可以保证一个项目能够维持健康和运作良好的开发者社区。但是，遵循最佳做法可以帮助改善项目的成果。例如，一些做法可以在发布之前进行多人评估，这可以帮助您找到其他难以找到的技术漏洞，并帮助建立信任，并希望不同公司的开发人员之间进行重复的交互。要获得徽章，必须满足所有“必须”和“禁止”的条款，满足所有“应该”条款或有合适的理由，和所有“建议”条款必须满足或未满足（至少希望考虑）。欢迎通过 GitHub网站创建问题或提出请求进行反馈。另外还有一个一般讨论邮件列表。

如果这是您的项目，请在项目页面上显示您的基准徽章状态！基准徽章状态如下所示： 项目12038的基准徽章等级为baseline-3 以下是如何嵌入基准徽章：
您可以通过将其嵌入到Markdown文件中来显示您的基准徽章状态：
[![OpenSSF Baseline](https://www.bestpractices.dev/projects/12038/baseline)](https://www.bestpractices.dev/projects/12038)
或者将其嵌入到HTML中：
<a href="https://www.bestpractices.dev/projects/12038"><img src="https://www.bestpractices.dev/projects/12038/baseline"></a>


这些是基准等级2的标准。 这些是标准版本 v2026.02.19。

Baseline Series: 基准等级1 基准等级2 基准等级3

        

 基本

  • 常规

    请注意，其他项目可能使用相同的名称。

    SGO - Sistema de Gestao Operacional | Open-source Micro-SaaS platform with Module Federation, Docker Swarm & Traefik

    Plataforma open-source de gestão para micro empresas. Chassi pronto (autenticação, usuários, permissões, whitelabel) + módulos de negócio que você adiciona no seu ritmo. Sem lock-in: o sistema pode ficar no seu servidor, sob sua marca.

    请使用 SPDX许可证表达格式;例子包括“Apache-2.0”，“BSD-2-Clause”，“BSD-3-Clause”，“GPL-2.0+”，“LGPL-3.0 +”，“MIT”和“(BSD-2-Clause OR Ruby)”。
    如果有多种语言，请将它们列为逗号分隔值（可选空格），并将它们从最多到最少使用。如果有长列表，请至少列出前三个最常见的列表。如果没有语言（例如，这是仅文档或仅测试项目），请使用单个字符“ - ”。请使用每种语言的常规大小写，例如“JavaScript”。
    通用平台枚举（CPE）是用于信息技术系统，软件和软件包的结构化命名方案。在报告漏洞时，它可用于多个系统和数据库。

    Plataforma open-source de gestão para micro empresas. Chassi pronto (autenticação, usuários, permissões, whitelabel) + módulos de negócio que você adiciona no seu ritmo. Sem lock-in: o sistema pode ficar no seu servidor, sob sua marca.

    Para quem implanta: sistema profissional, validado, que fica com o cliente após a implantação.
    Para integradores e devs: base documentada, Module Federation, guias para criar módulos (incluindo uso com IA).

 控制 18/19 ●

  • 控制


    足够获得徽章！

    当执行CI/CD任务且未指定权限时，CI/CD系统必须将任务的权限默认为管道中授予的最低权限。 [OSPS-AC-04.01]
    配置项目的设置，默认情况下为新管道分配最低可用权限，仅在特定任务需要时才授予额外权限。

    Os workflows GitHub Actions (.github/workflows/) definem permissões explícitas ou usam o padrão restritivo do GitHub (read-only para a maioria dos escopos). O workflow docker.yml usa apenas as permissões necessárias (packages: write para ghcr.io).


    足够获得徽章！

    当创建正式发布时，该发布必须分配一个唯一的版本标识符。 [OSPS-BR-02.01]
    为项目生成的每个发布分配一个唯一的版本标识符，遵循一致的命名约定或编号方案。示例包括SemVer、CalVer或git提交id。

    Versões são identificadas de forma única: tags Git (v4.0.0), campo "version" em cada package.json, e tags de imagem Docker (latest + sha-<commit>). CHANGELOG.md documenta a versão 4.0.0. https://github.com/altrsconsult/sgo/blob/master/CHANGELOG.md


    足够获得徽章！

    当创建正式发布时，该发布必须包含功能和安全修改的描述性日志。 [OSPS-BR-04.01]
    确保所有发布都包含描述性的变更日志。建议确保变更日志是人类可读的，并且包含超出提交消息的详细信息，例如安全影响的描述或与不同用例的相关性。为确保机器可读性，请将内容放在markdown标题下，例如"## Changelog"。

    CHANGELOG.md contém registro das modificações funcionais e de segurança da versão 4.0.0 (baseado em "Keep a Changelog"), incluindo adições, alterações e documentação de segurança. https://github.com/altrsconsult/sgo/blob/master/CHANGELOG.md


    足够获得徽章！

    当构建和发布管道摄取依赖项时，它必须使用标准化工具（如果可用）。 [OSPS-BR-05.01]
    为您的生态系统使用通用工具，例如包管理器或依赖项管理工具，以在构建时摄取依赖项。这可能包括使用依赖项文件、锁文件或清单来指定所需的依赖项，然后由构建系统拉入。

    O pipeline usa pnpm (gerenciador de pacotes padronizado) com pnpm-lock.yaml para instalação determinística de dependências. Dockerfiles usam COPY controlado. GitHub Actions usa actions/checkout@v4 e docker/build-push-action@v5 (ações oficiais).


    足够获得徽章！

    当创建正式发布时，该发布必须进行签名或在包含每个资产加密哈希值的签名清单中进行说明。 [OSPS-BR-06.01]
    在构建时使用加密签名或证明（例如GPG或PGP签名、Sigstore签名、SLSA来源或SLSA VSA）对所有发布的软件资产进行签名。在签名清单或元数据文件中包含每个资产的加密哈希值。

    Imagens Docker recebem attestation de proveniência via Sigstore (GitHub Actions), que inclui o hash SHA256 do artefato e assinatura criptográfica. Verificável com: gh attestation verify. https://github.com/altrsconsult/sgo/blob/master/docs/security/BUILD-AND-PROVENANCE.md


    足够获得徽章！

    当项目发布版本后，项目文档必须包含项目如何选择、获取和跟踪其依赖项的描述。 [OSPS-DO-06.01]
    建议在可公开查看的资源（如源代码存储库、项目网站或其他渠道）上与项目的技术和设计文档一起发布此信息。

    docs/AGENTS.md e pnpm-workspace.yaml descrevem as dependências do projeto. docs/processes/SECURITY-AND-PRIVACY.md documenta o processo de monitoramento (pnpm audit, Dependabot). SBOM gerado no CI lista todas as dependências. https://github.com/altrsconsult/sgo/blob/master/docs/AGENTS.md


    未知的所需信息，不足以用于徽章。

    项目文档必须包含如何构建软件的说明，包括所需的库、框架、SDK 和依赖项。 [OSPS-DO-07.01]
    建议将此信息与项目的贡献者文档一起发布，例如在 CONTRIBUTING.md 或其他开发者任务文档中。也可以使用 Makefile 目标或其他自动化脚本来记录此信息。

    足够获得徽章！

    在活动期间，项目文档必须包含有权访问敏感资源的项目成员列表。 [OSPS-GV-01.01]
    通过项目源代码存储库中的members.md、governance.md、maintainers.md或类似文件等工件记录项目参与者及其角色。这可以简单到在维护者列表中包含姓名或账户句柄，或者根据项目的治理更复杂。

    docs/governance/README.md identifica o mantenedor principal (ALTRS Consultoria / altrsadmin) como quem tem permissão de merge e acesso a recursos sensíveis do repositório. https://github.com/altrsconsult/sgo/blob/master/docs/governance/README.md


    足够获得徽章！

    在活动期间，项目文档必须包含项目成员的角色和责任的描述。 [OSPS-GV-01.02]
    通过项目源代码存储库中的members.md、governance.md、maintainers.md或类似文件等工件记录项目参与者及其角色。

    docs/governance/README.md define papéis e responsabilidades: Mantenedor (revisa/mergeia PRs, mantém políticas e releases) e Contribuidor (envia patches/docs via PRs). https://github.com/altrsconsult/sgo/blob/master/docs/governance/README.md


    足够获得徽章！

    在活动期间，项目文档必须包含代码贡献者指南，其中包括可接受贡献的要求。 [OSPS-GV-03.02]
    扩展项目文档中的CONTRIBUTING.md或CONTRIBUTING/的内容，以概述可接受的贡献要求，包括编码标准、测试要求和代码贡献者的提交指南。建议将该指南作为贡献者和批准者的真实来源。

    CONTRIBUTING.md define requisitos: código segue convenções (AGENTS.md), CI deve estar verde, tom respeitoso, DCO (Signed-off-by). docs/AGENTS.md lista convenções técnicas detalhadas (TypeScript, Zod, sem inline styles, etc.). https://github.com/altrsconsult/sgo/blob/master/CONTRIBUTING.md


    足够获得徽章！

    处于活跃状态时，版本控制系统必须要求所有代码贡献者在每次提交时断言他们有合法授权提交相关的贡献。 [OSPS-LE-01.01]
    在项目的代码库中包含一个DCO，要求代码贡献者在每次提交时断言他们有合法授权提交相关贡献。使用状态检查以确保完成此断言。CLA也满足此要求。某些版本控制系统（例如GitHub）可能会在平台服务条款中包含此项。

    CONTRIBUTING.md define DCO implícito: "use git commit -s para adicionar Signed-off-by". Cada commit com -s atesta que o contribuidor está legalmente autorizado a submeter a contribuição. https://github.com/altrsconsult/sgo/blob/master/CONTRIBUTING.md


    足够获得徽章！

    当向主分支提交时，必须通过或手动绕过提交的任何自动化状态检查。 [OSPS-QA-03.01]
    配置项目的版本控制系统，要求所有自动化状态检查通过或在提交合并到主分支之前需要手动确认。建议不要将任何可选状态检查配置为批准者可能会绕过的通过或失败要求。

    DEVELOPMENT-AND-RELEASE.md: "Todo PR deve deixar o CI em estado verde antes do merge." DEVELOPMENT-SECURITY.md: "Merges para a branch principal exigem status verde no CI." Branch protection configurada. https://github.com/altrsconsult/sgo/blob/master/docs/processes/DEVELOPMENT-AND-RELEASE.md


    足够获得徽章！

    在接受提交之前，项目的CI/CD管道必须运行至少一个自动化测试套件，以确保更改符合预期。 [OSPS-QA-06.01]
    应在每次合并到主分支之前运行自动化测试。测试套件应在CI/CD管道中运行，结果应对所有贡献者可见。测试套件应在一致的环境中运行，并应以允许贡献者在本地运行测试的方式运行。测试套件的示例包括单元测试、集成测试和端到端测试。

    O workflow security.yml executa em todo push/PR: pnpm audit, Gitleaks, SBOM e pnpm run test (job "Testes"). CI deve estar verde para merge. https://github.com/altrsconsult/sgo/blob/master/docs/governance/TESTING-POLICY.md


    足够获得徽章！

    当项目发布版本时，项目文档必须包括设计文档，展示系统中的所有操作和参与者。 [OSPS-SA-01.01]
    在项目文档中包括说明操作和参与者的设计。参与者包括可以影响系统中另一段的任何子系统或实体。确保为新功能或重大更改更新此文档。

    docs/architecture/SYSTEM-OVERVIEW.md contém diagrama de alto nível com todos os atores (usuário, Traefik, chassi-frontend, chassi-backend, PostgreSQL, Nexus) e o ciclo de vida completo de uma requisição. https://github.com/altrsconsult/sgo/blob/master/docs/architecture/SYSTEM-OVERVIEW.md


    足够获得徽章！

    当项目发布版本时，项目文档必须包括对已发布软件资产的所有外部软件接口的描述。 [OSPS-SA-02.01]
    记录已发布软件资产的所有软件接口（API），解释用户如何与软件交互以及期望或产生什么数据。确保为新功能或重大更改更新此文档。

    docs/AGENTS.md documenta todas as interfaces externas: 19 rotas da API REST (/api/auth, /api/users, /api/modules, etc.), interface Module Federation para módulos, e a API M2M (X-SGO-MASTER-KEY). docs/standards/MODULE-MANIFEST-SCHEMA.md define o contrato de módulos. https://github.com/altrsconsult/sgo/blob/master/docs/AGENTS.md


    足够获得徽章！

    当项目发布版本时，项目必须执行安全评估，以了解软件中可能发生的最可能和最具影响力的潜在安全问题。 [OSPS-SA-03.01]
    执行安全评估可以告知项目成员和下游消费者，项目了解软件中可能出现的问题。了解可能实现的威胁有助于项目管理和应对风险。此信息对下游消费者很有用，可以证明项目的安全敏锐度和实践。确保为新功能或重大更改更新此文档。

    O processo de segurança inclui: pnpm audit (dependências), Trivy (imagens Docker), Gitleaks (secrets), revisão de código em PRs e CI. DEVELOPMENT-SECURITY.md documenta as checagens de segurança que identificam problemas mais prováveis (deps vulneráveis, secrets expostos, CVEs em imagens). https://github.com/altrsconsult/sgo/blob/master/docs/security/DEVELOPMENT-SECURITY.md


    足够获得徽章！

    处于活跃状态时，项目文档必须包括协调漏洞披露（CVD）的政策，并有明确的响应时间框架。 [OSPS-VM-01.01]
    在目录根目录创建一个SECURITY.md文件，概述项目的协调漏洞披露政策。包括报告漏洞的方法。设定项目将如何响应和处理报告问题的期望。

    SECURITY.md define política de CVD (Coordinated Vulnerability Disclosure): reporte privado (e-mail ou GitHub Security Advisories), confirmação em até 5 dias úteis, acompanhamento até correção e divulgação responsável. https://github.com/altrsconsult/sgo/blob/master/docs/security/SECURITY.md


    足够获得徽章！

    处于活跃状态时，项目文档必须提供一种方法，用于直接向项目内的安全联系人私下报告漏洞。 [OSPS-VM-03.01]
    为安全研究人员提供一种方式，以私下向项目报告漏洞。这可能是专用电子邮件地址、Web表单、VCS专用工具、安全联系人的电子邮件地址或其他方法。

    SECURITY.md fornece dois meios de relato privado: e-mail contato@altrs.com.br e GitHub Security Advisories (aba Security → Report a vulnerability). Ambos são canais privados, não públicos. https://github.com/altrsconsult/sgo/blob/master/docs/security/SECURITY.md


    足够获得徽章！

    处于活跃状态时，项目文档必须公开发布有关已发现漏洞的数据。 [OSPS-VM-04.01]
    在可预测的公共渠道（例如CVE条目、博客文章或其他媒体）中提供有关已知漏洞的信息。在可能的情况下，此信息应包括受影响的版本、消费者如何确定他们是否容易受到攻击以及缓解或修复的说明。

    SECURITY.md inclui seção "Histórico de divulgação": vulnerabilidades corrigidas e divulgadas de forma responsável são listadas com data, gravidade e resumo (ou via GitHub Security Advisory público). https://github.com/altrsconsult/sgo/blob/master/docs/security/SECURITY.md



该数据可在社区数据许可协议 – 许可性，版本 2.0 (CDLA-Permissive-2.0)下获取。这意味着数据接收方可以共享数据，无论是否经过修改，只要数据接收方在共享数据时提供本协议文本。请注明Alesso和OpenSSF最佳实践徽章贡献者。

项目徽章条目拥有者： Alesso.
最后更新于 2026-02-25 17:23:17 UTC, 最后更新于 2026-02-25 18:26:41 UTC。 最后在 2026-02-25 17:55:06 UTC 获得通过徽章。