SGO - Sistema de Gestao Operacional

Проекты, которые следуют приведенным ниже лучшим практикам, могут добровольно и самостоятельно оценить себя и продемонстрировать, что они получили значок Open Source Security Foundation (OpenSSF).

Не существует набора практик, гарантирующего, что у программного обеспечения никогда не будет недостатков или уязвимостей; даже формальные методы могут не помочь, если спецификации или допущения ошибочны. Также не существует какой-либо практики, которая могла бы гарантировать, что проект будет поддерживать здоровое и хорошо функционирующее сообщество разработчиков. Однако следующие хорошие правила могут помочь улучшить результаты проектов. Например, некоторые правила описывают ревью несколькими участниками перед выпуском, что может помочь найти технические уязвимости, которые было бы сложно найти другим способом, и помочь построить доверие и желание дальнейшего взаимодействия между разработчиками из разных компаний. Чтобы получить значок, нужно выполнить все критерии с ключевыми словами "НЕОБХОДИМО"/"ОБЯЗАН"/"НЕДОПУСТИМО", все критерии со словом "СЛЕДУЕТ" либо должны удовлетворяться, либо должно быть приведено обоснование их невыполнения, и все критерии со словом "ЖЕЛАТЕЛЬНО" могут быть удовлетворены ИЛИ неудовлетворены (желательно, чтобы они были хотя бы рассмотрены). Если вы хотите ввести общий комментарий вместо объяснения, почему текущая ситуация приемлема, начните текст с '//' и пробела. Приветствуется обратная связь через сайт на GitHub в виде issues или pull requests. Существует также список рассылки для общих вопросов.

Мы с удовольствием предоставляем информацию на нескольких языках, однако, если есть какой-либо конфликт или несоответствие между переводами, английская версия является авторитетной.
Если это ваш проект, пожалуйста, отобразите статус вашего базового значка на странице проекта! Статус базового значка выглядит так: Базовый уровень значка для проекта 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>


Это критерии Базового Уровня 3. Эти критерии относятся к базовой версии v2025.10.10 с обновлённым текстом критериев из версии v2026.02.19. Критерии, новые в версии v2026.02.19, помечены как «будущие» и начнут применяться с 2026-06-01. Пожалуйста, предоставьте ответы на «будущие» критерии до этой даты.

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».
    Common Platform Enumeration (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).

 Элементы управления 20/21 ●

  • Элементы управления


    Достаточно для значка!

    Когда задаче назначаются разрешения в конвейере CI/CD, исходный код или конфигурация ДОЛЖНЫ назначать только минимальные привилегии, необходимые для соответствующей деятельности. [OSPS-AC-04.02]
    Настройте конвейеры CI/CD проекта так, чтобы по умолчанию назначать пользователям и службам наименьшие доступные разрешения, повышая разрешения только когда это необходимо для конкретных задач. В некоторых системах контроля версий это может быть возможно на уровне организации или репозитория. Если нет, установите разрешения на верхнем уровне конвейера.

    Arquitetura de mínimo privilégio: superadmin existe apenas no Nexus (não no chassi). Middleware requireAdmin verifica role=admin explicitamente. Rate limiting por IP. GitHub Actions usa permissões mínimas por workflow. https://github.com/altrsconsult/sgo/blob/master/docs/AGENTS.md


    Не хватает обязательной информации, недостаточно для значка.

    (Будущий критерий) Конвейеры CI/CD, принимающие входные данные от доверенных коллабораторов, ДОЛЖНЫ санировать и проверять эти входные данные перед их использованием в конвейере. [OSPS-BR-01.04]
    Конвейеры CI/CD должны санировать (заключать в кавычки, экранировать или завершаться при ожидаемых значениях) все входные данные коллабораторов при явном выполнении рабочих процессов. Хотя коллабораторы в целом являются доверенными, ручные входные данные для рабочего процесса не могут быть проверены и могут быть использованы в злоумышленных целях при захвате учётной записи или угрозе изнутри.

    Достаточно для значка!

    Когда создается официальный релиз, все активы в этом релизе ДОЛЖНЫ быть четко связаны с идентификатором релиза или другим уникальным идентификатором для актива. [OSPS-BR-02.02]
    Назначьте уникальный идентификатор версии каждому программному активу, произведенному проектом, следуя единообразному соглашению об именовании или схеме нумерации. Примеры включают SemVer, CalVer или идентификатор git-коммита.

    Imagens Docker são publicadas com tags sha-<commit> (ex.: sha-d08f186), associando cada ativo ao commit/release exato. Attestation de proveniência inclui o commit SHA. CHANGELOG.md e tags Git associam as mudanças à versão. https://github.com/altrsconsult/sgo/blob/master/docs/security/BUILD-AND-PROVENANCE.md


    Достаточно для значка!

    НЕОБХОДИМО, чтобы проект определил политику управления секретами и учетными данными, используемыми проектом. Политика должна включать руководства по хранению, доступу и ротации секретов и учетных данных. [OSPS-BR-07.02]
    Задокументируйте, как секреты и учетные данные управляются и используются в рамках проекта. Это должно включать подробную информацию о том, как хранятся секреты (например, с использованием инструмента управления секретами), как контролируется доступ, и как секреты ротируются или обновляются. Убедитесь, что конфиденциальная информация не встроена в исходный код и не хранится в системах контроля версий.

    Política de segredos documentada em DEVELOPMENT-SECURITY.md: Gitleaks no CI detecta e bloqueia commits com credenciais. Segredos configurados via variáveis de ambiente (não no código). .env.example documenta quais vars usar. JWT_SECRET e POSTGRES_PASSWORD são rotacionáveis via env vars.


    Достаточно для значка!

    Когда проект выпустил релиз, документация проекта ДОЛЖНА содержать инструкции по проверке целостности и подлинности активов релиза. [OSPS-DO-03.01]
    Инструкции в проекте должны содержать информацию об используемой технологии, командах для выполнения и ожидаемом выводе. По возможности избегайте хранения этой документации в том же месте, что и конвейер сборки и выпуска, чтобы избежать компрометации как программного обеспечения, так и документации для проверки целостности программного обеспечения в случае единичного нарушения безопасности.

    docs/security/BUILD-AND-PROVENANCE.md inclui instruções para verificar attestation: "gh attestation verify ghcr.io/altrsconsult/chassi-backend@sha256:<digest>". O comando confirma a integridade e proveniência do artefato. https://github.com/altrsconsult/sgo/blob/master/docs/security/BUILD-AND-PROVENANCE.md


    Достаточно для значка!

    Когда проект выпустил релиз, документация проекта ДОЛЖНА содержать инструкции по проверке ожидаемой личности человека или процесса, создающего программный релиз. [OSPS-DO-03.02]
    Ожидаемая личность может быть в форме идентификаторов ключей, используемых для подписи, эмитента и личности из сертификата sigstore или других подобных форм. По возможности избегайте хранения этой документации в том же месте, что и конвейер сборки и выпуска, чтобы избежать компрометации как программного обеспечения, так и документации для проверки целостности программного обеспечения в случае единичного нарушения безопасности.

    docs/security/BUILD-AND-PROVENANCE.md: a attestation Sigstore inclui repositório (altrsconsult/sgo), organização, commit SHA e workflow que gerou o artefato — verificando a identidade do processo de release. Verificável publicamente com gh attestation verify.


    Достаточно для значка!

    Когда проект выпустил релиз, документация проекта ДОЛЖНА включать описательное заявление о масштабе и сроках поддержки для каждого релиза. [OSPS-DO-04.01]
    Для информирования о масштабе и сроках поддержки выпущенных программных активов проекта, проект должен иметь файл SUPPORT.md, раздел "Поддержка" в SECURITY.md или другую документацию, объясняющую жизненный цикл поддержки, включая ожидаемую продолжительность поддержки для каждого релиза, типы предоставляемой поддержки (например, исправления ошибок, обновления безопасности) и любые соответствующие политики или процедуры получения поддержки.

    CHANGELOG.md documenta a versão atual (4.0.0). O projeto suporta ativamente a versão mais recente (branch master). Versões anteriores não recebem backports; usuários são encorajados a usar a versão mais recente. Licença MIT permite que qualquer instância forke e mantenha sua própria versão.


    Достаточно для значка!

    Когда проект выпустил релиз, документация проекта ДОЛЖНА предоставлять описательное заявление о том, когда релизы или версии больше не будут получать обновления безопасности. [OSPS-DO-05.01]
    Для информирования о масштабе и сроках поддержки исправлений безопасности, проект должен иметь SUPPORT.md или другую документацию, объясняющую политику проекта в отношении обновлений безопасности.

    A política de suporte é documentada no CHANGELOG.md e processo de desenvolvimento: apenas a versão mais recente (latest) recebe atualizações de segurança. Versões anteriores não são suportadas com patches de segurança — usuários devem atualizar para o latest.


    Достаточно для значка!

    Пока проект активен, документация проекта ДОЛЖНА содержать политику, согласно которой участники кода проверяются перед предоставлением повышенных разрешений на доступ к критическим ресурсам. [OSPS-GV-04.01]
    Опубликуйте исполняемую политику в документации проекта, которая требует, чтобы участники кода были проверены и одобрены до предоставления повышенных разрешений на доступ к критическим ресурсам, таким как одобрение слияния или доступ к секретам. Рекомендуется, чтобы проверка включала установление обоснованной линии идентичности, такой как подтверждение связи участника с известной доверенной организацией.

    docs/governance/README.md define que permissões elevadas (merge/commit ao main) são concedidas apenas a mantenedores revisados pela ALTRS Consultoria. Todo PR requer revisão de código antes do merge. DEVELOPMENT-AND-RELEASE.md: "código review: pull requests são revisados antes do merge".


    Достаточно для значка!

    Когда проект выпустил релиз, все скомпилированные выпущенные программные активы ДОЛЖНЫ поставляться со списком компонентов программного обеспечения (Software Bill of Materials). [OSPS-QA-02.02]
    Рекомендуется автоматически генерировать SBOM во время сборки с использованием инструмента, который был проверен на точность. Это позволяет пользователям получать эти данные стандартизированным способом наряду с другими проектами в их среде.

    SBOM (CycloneDX/SPDX) gerado automaticamente no CI (workflow security.yml usando Syft) e publicado como artefato de cada run. BUILD-AND-PROVENANCE.md documenta a disponibilidade. https://github.com/altrsconsult/sgo/blob/master/docs/security/BUILD-AND-PROVENANCE.md


    Достаточно для значка!

    Когда проект выпустил релиз, состоящий из нескольких репозиториев исходного кода, все подпроекты ДОЛЖНЫ применять требования безопасности, которые являются столь же строгими или более строгими, чем первичная кодовая база. [OSPS-QA-04.02]
    Любые дополнительные репозитории кода подпроектов, созданные проектом и скомпилированные в релиз, должны применять требования безопасности в соответствии со статусом и целями соответствующей кодовой базы. В дополнение к следованию соответствующим требованиям OSPS Baseline, это может включать требование проверки безопасности, обеспечение отсутствия уязвимостей и обеспечение отсутствия известных проблем безопасности.

    Todos os pacotes do monorepo (chassi, nexus, packages/ui, packages/sdk, modules) passam pelo mesmo pipeline de CI com as mesmas verificações de segurança (pnpm audit, Gitleaks, Trivy). Não há subprojetos com requisitos menos rigorosos.


    Достаточно для значка!

    Пока проект активен, документация проекта ДОЛЖНА четко документировать, когда и как выполняются тесты. [OSPS-QA-06.02]
    Добавьте раздел в документацию по участию в проекте, объясняющий, как запускать тесты локально и как запускать тесты в конвейере CI/CD. Документация должна объяснять, что тестируют тесты и как интерпретировать результаты.

    docs/governance/TESTING-POLICY.md documenta quando e como os testes são executados: job "Testes" no .github/workflows/security.yml, executado em todo push/PR, via pnpm run -r test --if-present. https://github.com/altrsconsult/sgo/blob/master/docs/governance/TESTING-POLICY.md


    Достаточно для значка!

    Пока проект активен, документация проекта ДОЛЖНА включать политику, согласно которой все значительные изменения программного обеспечения, производимого проектом, должны добавлять или обновлять тесты функциональности в автоматизированном наборе тестов. [OSPS-QA-06.03]
    Добавьте раздел в документацию по участию в проекте, объясняющий политику добавления или обновления тестов. Политика должна объяснять, что представляет собой значительное изменение и какие тесты должны быть добавлены или обновлены.

    docs/governance/TESTING-POLICY.md: "Novo código que altere comportamento crítico deve incluir ou atualizar testes quando fizer sentido". Política documentada formalmente. https://github.com/altrsconsult/sgo/blob/master/docs/governance/TESTING-POLICY.md


    Достаточно для значка!

    Когда совершается коммит в основную ветку, система контроля версий проекта ДОЛЖНА требовать как минимум одного одобрения изменений человеком, не являющимся автором, перед слиянием. [OSPS-QA-07.01]
    Настройте систему контроля версий проекта так, чтобы она требовала как минимум одного одобрения изменений человеком, не являющимся автором, перед слиянием в релизную или основную ветку. Это можно достичь, требуя, чтобы запрос на включение изменений был рассмотрен и одобрен как минимум одним другим участником, прежде чем его можно будет объединить.

    O repositório usa branch protection com revisão de PR obrigatória antes do merge. DEVELOPMENT-AND-RELEASE.md: "code review: pull requests são revisados antes do merge." O autor do PR não pode fazer o merge sem aprovação de outro mantenedor.


    Достаточно для значка!

    Когда проект выпустил релиз, проект ДОЛЖЕН выполнить моделирование угроз и анализ поверхности атаки для понимания и защиты от атак на критические пути кода, функции и взаимодействия внутри системы. [OSPS-SA-03.02]
    Моделирование угроз - это деятельность, при которой проект рассматривает кодовую базу, связанные процессы и инфраструктуру, интерфейсы, ключевые компоненты и "думает как хакер", проводя мозговой штурм о том, как система может быть взломана или скомпрометирована. Каждая выявленная угроза перечисляется, чтобы проект мог затем подумать о том, как проактивно избежать или закрыть любые бреши/уязвимости, которые могут возникнуть. Убедитесь, что это обновляется для новых функций или критических изменений.

    Avaliação de segurança automatizada após cada lançamento: CI executa pnpm audit, Trivy (CVEs nas imagens Docker), Gitleaks e gera SBOM. DEVELOPMENT-SECURITY.md documenta o processo contínuo de avaliação. https://github.com/altrsconsult/sgo/blob/master/docs/security/DEVELOPMENT-SECURITY.md


    Достаточно для значка!

    Пока активен, любые уязвимости в программных компонентах, не затрагивающие проект, ДОЛЖНЫ быть учтены в документе VEX, дополняющем отчет об уязвимостях деталями о неэксплуатируемости. [OSPS-VM-04.02]
    Создайте поток VEX, сообщающий о статусе эксплуатируемости известных уязвимостей, включая детали оценки или любые меры по смягчению, препятствующие выполнению уязвимого кода.

    Documento VEX (OpenVEX 0.2) em docs/security/openvex.json contabiliza CVEs que não afetam o projeto (ex.: CVE-2024-21626 runc, status not_affected, justificativa vulnerable_code_not_in_execute_path). Referenciado em BUILD-AND-PROVENANCE.md e validado pelo job "vex" no security.yml. https://github.com/altrsconsult/sgo/blob/master/docs/security/openvex.json


    Достаточно для значка!

    Пока активна, документация проекта ДОЛЖНА включать политику, определяющую порог для устранения результатов SCA, связанных с уязвимостями и лицензиями. [OSPS-VM-05.01]
    Задокументируйте в проекте политику, определяющую порог для устранения результатов SCA, связанных с уязвимостями и лицензиями. Включите процесс выявления, приоритизации и устранения этих результатов.

    DEVELOPMENT-SECURITY.md documenta política SCA: pnpm audit --audit-level=critical (vulnerabilidades críticas bloqueiam CI) e Trivy com threshold em críticos. Licenças verificadas via SBOM. https://github.com/altrsconsult/sgo/blob/master/docs/security/DEVELOPMENT-SECURITY.md


    Достаточно для значка!

    Пока активна, документация проекта ДОЛЖНА включать политику для устранения нарушений SCA до любого релиза. [OSPS-VM-05.02]
    Задокументируйте в проекте политику для устранения применимых результатов анализа состава программного обеспечения перед любым релизом и добавьте проверки статуса, которые подтверждают соответствие этой политике перед релизом.

    O CI (security.yml + docker.yml) bloqueia o pipeline em caso de vulnerabilidades críticas (pnpm audit + Trivy). Nenhum artefato é publicado no ghcr.io se houver violações críticas — o job falha e o push da imagem não ocorre.


    Достаточно для значка!

    Пока активны, все изменения в кодовой базе проекта ДОЛЖНЫ автоматически оцениваться на соответствие задокументированной политике по вредоносным зависимостям и известным уязвимостям в зависимостях, а затем блокироваться в случае нарушений, за исключением случаев, когда они объявлены и подавлены как неэксплуатируемые. [OSPS-VM-05.03]
    Создайте проверку статуса в системе контроля версий проекта, которая запускает инструмент анализа состава программного обеспечения для всех изменений в кодовой базе. Требуйте, чтобы проверка статуса проходила успешно, прежде чем изменения могут быть объединены.

    Todo push/PR é automaticamente avaliado: pnpm audit bloqueia em vulnerabilidades críticas de dependências; Trivy bloqueia em CVEs críticos nas imagens Docker. CI falha e merge/release não ocorre. Documentado em DEVELOPMENT-SECURITY.md.


    Достаточно для значка!

    Пока активна, документация проекта ДОЛЖНА включать политику, определяющую порог для устранения результатов SAST. [OSPS-VM-06.01]
    Задокументируйте в проекте политику, определяющую порог для устранения результатов статического тестирования безопасности приложений (SAST). Включите процесс выявления, приоритизации и устранения этих результатов.

    DEVELOPMENT-SECURITY.md documenta SAST via TypeScript (verificação de tipos) e ESLint. Erros de lint e tipos bloqueiam o CI. Política: código deve passar lint antes do merge. Quando SAST mais avançado (ex.: CodeQL) for implementado, será atualizado neste documento.


    Достаточно для значка!

    Пока активны, все изменения в кодовой базе проекта ДОЛЖНЫ автоматически оцениваться на соответствие задокументированной политике по слабым местам безопасности и блокироваться в случае нарушений, за исключением случаев, когда они объявлены и подавлены как неэксплуатируемые. [OSPS-VM-06.02]
    Создайте проверку статуса в системе контроля версий проекта, которая запускает инструмент статического тестирования безопасности приложений (SAST) для всех изменений в кодовой базе. Требуйте, чтобы проверка статуса проходила успешно, прежде чем изменения могут быть объединены.

    Todo PR/push é automaticamente avaliado: TypeScript (fraquezas de tipo), ESLint (padrões inseguros), pnpm audit (deps vulneráveis), Gitleaks (credenciais expostas), Trivy (CVEs em imagens). Violações bloqueiam o pipeline. DEVELOPMENT-SECURITY.md documenta o processo completo.



Эти данные доступны по лицензии Community Data License Agreement – Permissive, Version 2.0 (CDLA-Permissive-2.0). Это означает, что получатель данных может распространять данные с изменениями или без них, при условии, что получатель данных предоставляет текст данного соглашения вместе с распространяемыми данными. Пожалуйста, укажите в качестве источника Alesso и участников OpenSSF Best Practices badge.

Владелец анкеты на значок проекта: Alesso.
2026-02-25 17:23:17 UTC, последнее изменение сделано 2026-02-25 18:26:41 UTC. Последний раз условия для получения значка были выполнены 2026-02-25 17:55:06 UTC.