sentinel

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

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

Мы с удовольствием предоставляем информацию на нескольких языках, однако, если есть какой-либо конфликт или несоответствие между переводами, английская версия является авторитетной.
Если это ваш проект, пожалуйста, покажите свой значок на странице проекта! Статус значка выглядит следующим образом: Уровень значка для проекта 14063 - passing Вот как вставить его:
Вы можете показать свой статус значка, вставив его в файл с разметкой Markdown:
[![OpenSSF Best Practices](https://www.bestpractices.dev/projects/14063/badge)](https://www.bestpractices.dev/projects/14063)
- или HTML:
<a href="https://www.bestpractices.dev/projects/14063"><img src="https://www.bestpractices.dev/projects/14063/badge"></a>


Это критерии уровня Gold. Вы также можете просмотреть критерии уровня Passing или Silver.

Baseline Series: Базовый уровень 1 Базовый Уровень 2 Базовый Уровень 3

        

 Основы 0/5

  • Общая

    Обратите внимание, что другие проекты могут использовать то же имя.

    The security update management platform for SUSE and openSUSE Linux distributions

    Используйте формат выражения лицензии 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) - это структурированная схема именования для информационных систем, программного обеспечения и пакетов. Она используется в ряде систем и баз данных для отчетов об уязвимостях.
  • Предварительные требования


    Проект ОБЯЗАН получить серебряный значок. [achieve_silver]

  • Надзор за проектом


    Проект ОБЯЗАН иметь «коэффициент автобуса» 2 или более. (Требуется URL) [bus_factor]
    «Коэффициент автобуса» (или «коэффициент грузовика») - это минимальное количество участников проекта, которые должны внезапно исчезнуть из проекта («попасть под автобус»), чтобы проект заглох из-за отсутствия квалифицированного или компетентного персонала. Инструмент truck-factor может оценить это для проектов на GitHub. Для получения дополнительной информации см. статью Cosentino et al. Assessing the Bus Factor of Git Repositories.

    The project has a bus factor of 1 — a single maintainer (StayPirate) with sole repository admin access, release credentials, and merge authority. No second person has the necessary permissions to create releases, merge PRs, or manage the repository infrastructure. This is the same underlying gap as the previous criterion.



    Проект ОБЯЗАН иметь как минимум двух несвязанных значительных соавторов. (Требуется URL) [contributors_unassociated]
    Соавторы связаны, если они оплачиваются работой одной и той же организации (как работник или подрядчик), и организация может выиграть от результатов проекта. Финансовые гранты не считаются находящимися в одной организации, если они проходят через другие организации (например, гранты на науку, выплачиваемые различным организациям из общего правительства или источника НПО, не приводят к тому, что вкладчики могут быть связаны). Соавтор считается значительным, если за последний год он(а) внес(ла) заметный вклад в проект. Примерами хороших показателей значительного соавтора являются: написано не менее 1000 строк кода, внесено 50 коммитов или предоставлено не менее 20 страниц документации.

    Sentinel currently has a single primary contributor/maintainer. There are no two unassociated significant contributors to the project. This is consistent with the "Unmet" bus factor criterion noted earlier — both reflect the single-maintainer reality of the project's current stage.


  • Другое


    Проект ОБЯЗАН указывать лицензию в каждом исходном файле. Это МОЖЕТ быть сделано путем включения в комментарий рядом с началом каждого файла следующей строки: SPDX-License-Identifier: [SPDX-выражение лицензии для проекта]. [license_per_file]
    Это МОЖЕТ также быть сделано путем указания лицензии на естественном языке. Проект МОЖЕТ также включать стабильный URL-адрес, указывающий на текст лицензии, или полный текст лицензии. Обратите внимание, что критерий license_location требует помещать лицензию проекта в стандартном расположении. См. этот учебник SPDX для получения дополнительных сведений об SPDX-выражениях лицензии. Обратите внимание на связь с критерием copyright_per_file, содержимое для которого обычно предшествует информации о лицензии.

    Sentinel source files do not currently include SPDX license identifiers. The project has a top-level LICENSE file (MIT) but individual source files lack per-file license statements.


 Управление изменениями 3/4

  • Публичное хранилище исходного кода с поддержкой версий


    Хранилище проектного исходного кода ОБЯЗАНО использовать типовое ПО для распределенного управления версиями (например, git или mercurial). [repo_distributed]
    Не требуется именно git, и проекты могут использовать централизованное программное обеспечение для управления версиями (например, Subversion) с обоснованием.

    Repository on GitHub, which uses git. git is distributed.



    Проект ОБЯЗАН четко обозначать небольшие задачи, которые могут быть выполнены новыми или случайными участниками. (Требуется URL) [small_tasks]
    Это обозначение обычно делается путем маркировки выбранных проблем в трекере одним или несколькими тегами, которые использует проект для этой цели, например up-for-grabs, «только для новичков», «Небольшое исправление», «микрозадача» или IdealFirstBug. Эти новые задачи не обязательно требуют добавления функциональности; это может быть улучшение документации, добавление тестовых кейсов или что-то еще, что помогает проекту и помогает участнику лучше понять проект.

    Sentinel does not currently use GitHub's "good first issue" label or any equivalent mechanism to identify tasks suitable for new or casual contributors. There are no labeled issues marking small, approachable tasks.



    Проект ОБЯЗАН требовать двухфакторной аутентификации (ДФА) от разработчиков для изменения центрального хранилища или доступа к конфиденциальным данным (например, приватным отчетам об уязвимостях). Этот механизм ДФА МОЖЕТ использовать механизмы без криптографической защиты, такие как SMS, хотя это не рекомендуется. [require_2FA]

    GitHub requires 2FA as of March 2023. [osps_ac_01_01]



    При двухфакторной аутентификации (ДФА) проекту СЛЕДУЕТ использовать криптографические механизмы для предотвращения имперсонации. ДФА на основе службы коротких сообщений (SMS) сама по себе НЕ соответствует этому критерию, поскольку короткие сообщения не шифруются. [secure_2FA]
    Механизм ДФА, который соответствует этому критерию, может быть приложением для генерации временных одноразовых паролей (Time-based One-Time Password, TOTP), которое автоматически генерирует код аутентификации, меняющийся через определенный промежуток времени. Обратите внимание, что GitHub поддерживает TOTP.

    The project's GitHub organization/account uses GitHub's two-factor authentication, which supports cryptographic mechanisms — TOTP (time-based one-time passwords via authenticator apps), hardware security keys (WebAuthn/FIDO2), and GitHub Mobile push notifications. SMS-based 2FA is not relied upon as the sole mechanism. GitHub's 2FA enforcement has been mandatory for all contributors since 2023.


 Качество 6/7

  • Стандарты кодирования


    Проект ОБЯЗАН документировать свои требования по ревью кода, в том числе, как проводится ревью кода, что необходимо проверять и что необходимо для приемлемости кода. (Требуется URL) [code_review_standards]
    См. также критерии two_person_review и contrib_requirements.

    Sentinel's code review requirements are comprehensively documented in CONTRIBUTING.md (https://github.com/StayPirate/sentinel/blob/master/CONTRIBUTING.md), which references the detailed conventions. The full review process includes:

    • Automated reviewer agents: 15+ specialized reviewer agents (security, design, data-model, test, API convention, spec coherence, docs, etc.) are invoked per guardrail rules defined in AGENTS.md (https://github.com/StayPirate/sentinel/blob/master/AGENTS.md) — each guardrail specifies when to invoke which reviewer and what must be checked
    • What must be checked: mandatory testing for all changes (Guardrail 6), security review for security-sensitive code (Guardrail 10), data model review for schema changes (Guardrail 8), documentation completeness (Guardrail 9), spec coherence (Guardrail 15), API convention conformity (Guardrail 20), and more
    • Acceptance criteria: all CI checks must pass (ruff, mypy --strict, bandit, pip-audit, pytest), applicable reviewer agents must be invoked and findings addressed, PR description must include test evidence and manual verification notes
    • PR requirements: documented in docs/conventions.md (https://github.com/StayPirate/sentinel/blob/master/docs/conventions.md) (Pull Request Requirements) — title format, issue linkage, scope summary, reviewer results, verification evidence
    • Finding evaluation: Guardrail 26 documents how reviewer findings are evaluated — independent verification, discard criteria, proportionality, escalation procedure
    • CI enforcement: required status checks on master branch protection (7 checks), conversation resolution required before merge

    URL: https://github.com/StayPirate/sentinel/blob/master/CONTRIBUTING.md



    Проект ОБЯЗАН проводить проверку не менее 50% всех предлагаемых модификаций до их попадания в выпуск человеком, отличным от автора, для определения того, являются ли эти модификации целесообразными и не содержат ли известных проблем, препятствующих включению. [two_person_review]

    Branch protection on master requires a pull request before merge, but the required approvals count is set to 0. This means a PR author can merge their own changes without any non-author human review. The project is currently single-maintainer, which makes enforcing non-author approval impractical (there is no second person to approve), but the criterion as stated is not satisfied by the current configuration. [osps_qa_07_01]


  • Рабочая система сборки


    Проект ОБЯЗАН обеспечивать воспроизводимую сборку. Если сборка не требуется (например, в случае языков сценариев, где исходный код используется непосредственно вместо компиляции), выберите «N/A». (Требуется URL) [build_reproducible]
    Воспроизводимая сборка означает, что несколько сторон могут независимо повторить процесс генерации информации из исходных файлов и получить аналогичный результат с точностью до бита. В некоторых случаях воспроизводимости можно достичь путем принудительного выставления окружения. Разработчики JavaScript могут рассмотреть возможность использования npm shrinkwrap и webpack OccurenceOrderPlugin. Пользователи GCC и clang могут найти полезной опцию -frandom-seed. Среда сборки (включая набор инструментов) часто может быть определена для внешних сторон путём указания криптографической суммы (hash) для конкретного контейнера или виртуальной машины, которые они могут использовать для пересборки. В проекте Reproducible Builds есть документация о том, как это сделать.

    Sentinel is a pure Python application — the source code is interpreted directly, not compiled into binary artifacts. There is no compilation step that would produce build output requiring bit-for-bit reproducibility. The Docker image build installs Python packages from a lockfile (uv.lock) but the application itself has no build/compilation phase.


  • Набор автотестов


    Набор тестов ОБЯЗАН запускаться стандартным способом для этого языка. (Требуется URL) [test_invocation]
    Например, «make check», «mvn test» или «rake test» (Ruby).

    Sentinel's test suite is invocable using pytest, the standard Python testing framework:

    • Standard invocation: cd backend && uv run pytest — the conventional command documented in the project
    • Configuration: test settings are defined in backend/pyproject.toml (https://github.com/StayPirate/sentinel/blob/master/backend/pyproject.toml) under [tool.pytest.ini_options], following the standard pytest configuration convention
    • CI invocation: the CI pipeline (.github/workflows/ci.yml) invokes the same uv run pytest command with coverage flags
    • Markers: tests use standard pytest markers (@pytest.mark.unit, @pytest.mark.integration, @pytest.mark.e2e) for selective execution

    URL: https://github.com/StayPirate/sentinel/blob/master/backend/pyproject.tomlard invocation is required.



    Проект ОБЯЗАН реализовать непрерывную интеграцию, при которой новый или измененный код интегрируется в центральное хранилище кода, и на получившейся базе кода запускаются автоматические тесты. (Требуется URL) [test_continuous_integration]
    В большинстве случаев это означает, что каждый разработчик, занимающийся проектом полный рабочий день, интегрируется, по крайней мере, ежедневно.

    Sentinel implements continuous integration via GitHub Actions. Every push and pull request to master triggers the CI pipeline, which runs the full automated test and analysis suite:

    • Linting: ruff check . + ruff format --check .
    • Static type checking: mypy --strict
    • Security analysis: bandit (SAST) + pip-audit (SCA)
    • Shell analysis: shellcheck + shfmt -d + actionlint
    • Automated tests: uv run pytest (850+ tests with coverage)
    • Container scanning: Trivy image scan
    • PR title validation: Conventional Commits format enforcement
    • PR metadata validation: issue linkage requirement

    Branch protection on master requires 7 status checks to pass before merge. All changes arrive via pull request with squash merge — no direct pushes to master.

    URL: https://github.com/StayPirate/sentinel/blob/master/.github/workflows/ci.yml



    Проект ОБЯЗАН иметь автоматические тестовые пакеты на СПО, которые обеспечивают покрытие не менее 90% инструкций кода, если есть хотя бы один инструмент на СПО, который может измерять этот критерий на выбранном языке. [test_statement_coverage90]

    Sentinel achieves 99% statement coverage (98.99% measured precisely), well above the 90% threshold. Coverage is measured by pytest-cov (a FLOSS tool) and enforced in CI with a minimum threshold of 85%. Results are uploaded to Codecov on every CI run. The latest successful CI run shows TOTAL: 3113 statements, 27 missed, 568 branches, 10 missed — 99% coverage.

    URL: https://app.codecov.io/github/staypirate/sentinel



    Проект ОБЯЗАН иметь автоматические тестовые пакеты на СПО, которые обеспечивают покрытие не менее 80% веток кода, если есть хотя бы один инструмент на СПО, который может измерять этот критерий на выбранном языке. [test_branch_coverage80]

    From the same CI run, Sentinel's test suite achieves high branch coverage as well. The coverage report shows 568 branches, 10 missed — which is 98% branch coverage, well above the 80% threshold. Branch coverage is measured by pytest-cov (a FLOSS tool) using the --cov-branch flag, and results are uploaded to Codecov on every CI run.


 Безопасность 5/5

  • Основы правильного использования криптографии

    Обратите внимание, что некоторое ПО не нуждается в использовании криптографических механизмов.

    В ПО, создаваемом проектом, НЕОБХОДИМО поддерживать безопасные протоколы для всех сетевых коммуникаций, такие как SSHv2 или новее, TLS1.2 или новее (HTTPS), IPsec, SFTP и SNMPv3. По умолчанию НЕОБХОДИМО отключать небезопасные протоколы, такие как FTP, HTTP, telnet, SSLv3 или более ранние версии, и SSHv1, и разрешать их только в том случае, если пользователь явным образом это задаёт. Если программное обеспечение, созданное проектом, не поддерживает сетевые коммуникации, выберите «неприменимо» (N/A). [crypto_used_network]

    Sentinel supports secure protocols for all network communications and does not enable insecure protocols by default:

    • API server: serves over HTTPS; TLS configuration is handled at the deployment layer (reverse proxy / load balancer)
    • External service integrations: all HTTP clients (IBS, SMELT, AIMAAS, NVD, MITRE, Bugzilla, etc.) use HTTPS exclusively. The networking infrastructure (docs/features/platform/networking.md) configures TLS with certificate verification enabled by default
    • Database: connects to PostgreSQL via asyncpg, which supports TLS connections (sslmode parameter in DATABASE_URL)
    • Redis: connects via REDIS_URL, which supports rediss:// (TLS) scheme
    • RabbitMQ: connects via IBS_RABBITMQ_URL, which supports amqps:// (TLS) scheme
    • Git transport: git-based fetchers clone via HTTPS
    • No insecure defaults: no HTTP, FTP, telnet, or unencrypted protocols are used in application code. Plain HTTP is only accepted for local development (CORS_ORIGINS may include http://localhost:*)

    See docs/features/platform/networking.md (https://github.com/StayPirate/sentinel/blob/master/docs/features/platform/networking.md) and docs/data-sources.md (https://github.com/StayPirate/sentinel/blob/master/docs/data-sources.md) for the full external service catalog and protocol details.



    Если ПО, создаваемое проектом, поддерживает или использует TLS, НЕОБХОДИМО поддерживать как минимум версию TLS 1.2. Примечание: предшественник TLS называется SSL. Если программное обеспечение не использует TLS, выберите «неприменимо» (N/A). [crypto_tls12]

    Sentinel's TLS configuration supports TLS 1.2 and later:

    • Python runtime: Python 3.13's ssl module uses OpenSSL's default minimum protocol version, which is TLS 1.2 on all modern distributions (TLS 1.0 and 1.1 were deprecated in OpenSSL 1.1.1 and disabled by default in OpenSSL 3.x)
    • HTTP clients: the httpx library (used for all external service integrations) uses Python's ssl module, which enforces TLS 1.2+ by default
    • Database: asyncpg TLS connections negotiate TLS 1.2+ via the system OpenSSL
    • Redis/RabbitMQ: TLS connections via rediss:// and amqps:// schemes use Python's ssl module, defaulting to TLS 1.2+
    • Custom TLS context: the networking infrastructure (docs/features/platform/networking.md) supports configurable TLS contexts with certificate verification enabled by default, using the system trust store

    TLS versions prior to 1.2 (SSL 2.0, SSL 3.0, TLS 1.0, TLS 1.1) are disabled by the underlying OpenSSL library in the Python 3.13 base image (python:3.13-slim).


  • Доставка, защищенная от атак посредника (MITM)


    Веб-сайт проекта, репозиторий (если он доступен через Интернет) и сайт загрузки (если он существует отдельно) ОБЯЗАНЫ использовать упрочняющие безопасность (hardening) заголовки с неразрешающими значениями. (Требуется URL) [hardened_site]
    Обратите внимание, что GitHub отвечает этому критерию. Такие сайты как https://securityheaders.io/ могут быстро проверить использование. Ключевыми заголовками для упрочнения являются: Content Security Policy (CSP), HTTP Strict Transport Security (HSTS), X-Content-Type-Options (выставленный в «nosniff»), X-Frame-Options и X-XSS-Protection. Статические веб-сайты без возможности входа в систему через веб-страницы могут опускать упрочняющие HTTP-заголовки CSP и X-XSS-Protection, поскольку в этом случае эти заголовки менее эффективны.

    Sentinel's repository and website are hosted on GitHub, which serves all pages with hardening headers including:

    • Content-Security-Policy: restrictive policy limiting script and resource sources
    • X-Content-Type-Options: nosniff
    • X-Frame-Options: DENY
    • Strict-Transport-Security: HSTS with long max-age, includeSubDomains, and preload
    • X-XSS-Protection: 0 (modern approach — CSP replaces this deprecated header)
    • Referrer-Policy: restrictive policy

    These are enforced by GitHub's infrastructure for all repositories and GitHub Pages sites. The project does not operate a separate website or download site outside of GitHub.

    URL: https://github.com/StayPirate/sentinel


  • Другие вопросы безопасности


    Проект ОБЯЗАН иметь проверку безопасности за последние 5 лет. При проверке НЕОБХОДИМО учитывать требования и границы безопасности. [security_review]
    Эта оценка МОЖЕТ быть выполнена членами проекта и/или независимо. Эта оценка МОЖЕТ подкрепляться инструментами статического и динамического анализа, но кроме этого должна быть проверка человеком для выявления проблем (особенно в дизайне), которые инструменты не могут обнаружить.

    The project maintains an extensive docs/reviews/ directory with security review findings for every major component — over 50 review documents covering authentication, RBAC, networking, API specification, fetcher infrastructure, and all integration points. Each review includes findings from a dedicated @security-reviewer agent (among others), threat model assessments (e.g., brute-force resistance in local-authentication, trusted-upstream assumptions in networking, pre-disclosure data exposure in RBAC), and explicit risk acceptance decisions with rationale. The CI pipeline also runs bandit (static security analysis) and pip-audit (dependency vulnerability scanning) on every merge. Security-sensitive areas are subject to mandatory review per Guardrail 10. [osps_sa_03_01]



    В ПО, создаваемом проектом, НЕОБХОДИМО использовать механизмы упрочнения безопасности (hardening), чтобы дефекты программного обеспечения с меньшей вероятностью приводили к уязвимостям в безопасности. (Требуется URL) [hardening]
    Механизмы упрочнения могут включать HTTP-заголовки, такие как Content Security Policy (CSP), флаги компилятора для противостояния атакам (например, -fstack-protector) или флаги компилятора, устраняющие неопределенное поведение. Для наших целей политика наименьших привилегий не считается механизмом упрочнения (использовать наименьшие достаточные привилегии важно, но этому посвящён отдельный критерий).

    Sentinel employs multiple hardening mechanisms to reduce the likelihood that software defects result in security vulnerabilities:

    • Memory-safe language: Python is memory-safe by design — no buffer overflows, use-after-free, or memory corruption
    • Strict static type checking: mypy --strict is a mandatory CI gate, catching type errors, unhandled None values, and forgotten await calls before production
    • SQL injection prevention: all database queries use SQLAlchemy's parameterized query API — no raw SQL string concatenation
    • Input validation at boundaries: Pydantic schemas reject malformed input before business logic; database CHECK constraints provide defense-in-depth
    • Secret masking: SecretStr type prevents accidental credential exposure in tracebacks, logs, and repr output
    • SAST: bandit detects common Python security anti-patterns (hardcoded passwords, eval, insecure deserialization) in CI
    • SCA: pip-audit blocks dependencies with known vulnerabilities pre-merge
    • Container scanning: Trivy scans the Docker image for OS and library vulnerabilities
    • Least-privilege CI: workflows default to permissions: read-all; jobs escalate only specific permissions needed
    • Secret scanning: GitHub Secret Scanning with Push Protection prevents accidental credential commits
    • Pessimistic locking: centralized mutation modules use SELECT ... FOR UPDATE to prevent race conditions
    • No custom cryptography: all crypto delegates to vetted FLOSS libraries (bcrypt, PyJWT, OpenSSL)

    These mechanisms are documented across docs/conventions.md (https://github.com/StayPirate/sentinel/blob/master/docs/conventions.md), docs/architecture.md (https://github.com/StayPirate/sentinel/blob/master/docs/architecture.md), and docs/deployment.md (https://github.com/StayPirate/sentinel/blob/master/docs/deployment.md) (CI Pipeline).


 Анализ 1/2

  • Динамический анализ кода


    Проект ОБЯЗАН применять хотя бы один инструмент динамического анализа к любой предлагаемой основной версии ПО, создаваемого проектом до её выпуска. [dynamic_analysis]
    Инструмент динамического анализа проверяет программное обеспечение, выполняя его с конкретными входными данными. Например, проект МОЖЕТ использовать инструмент фаззинг-тестирования (например, American Fuzzy Lop) или сканер веб-приложений (например, OWASP ZAP или w3af). В некоторых случаях проект OSS-Fuzz может быть готов применить фаззинг-тестирование к вашему проекту. Для целей этого критерия инструмент динамического анализа должен каким-то образом варьировать исходные данные, чтобы искать проблемы разного рода или быть автоматическим набором тестов с покрытием веток исполнения не менее 80%. Страница Википедии о динамическом анализе и cтраница OWASP о фаззинг-тестировании указывают некоторые инструменты динамического анализа. Использование инструмента/ов анализа МОЖЕТ, но не обязано быть сосредоточено на поиске уязвимостей в безопасности.

    Sentinel does not currently apply dynamic analysis tools (e.g., fuzzing, property-based testing with Hypothesis, runtime sanitizers, or similar) to production releases. The project relies on static analysis (mypy --strict, bandit, ruff), dependency auditing (pip-audit), container scanning (Trivy), and an extensive automated test suite (850+ tests), but no dynamic analysis tool is part of the CI pipeline or release process. This is consistent with the "Unmet" status on the runtime assertions criterion above.



    Проекту СЛЕДУЕТ включать достаточно много утверждений (assertions) времени выполнения в создаваемом им ПО и проверять эти утверждения во время динамического анализа. [dynamic_analysis_enable_assertions]
    Этот критерий не предполагает включения утверждений на этапе эксплуатации; решение об этом полностью лежит на проекте и его пользователях. Вместо этого критерий направлен на улучшение обнаружения ошибок во время динамического анализа перед развертыванием. Использование утверждений при эксплуатации полностью отличается от такового во время динамического анализа (например, при тестировании). В некоторых случаях включать утверждения при эксплуатации крайне неразумно (особенно в компонентах с высокой степенью целостности). Существует множество аргументов против включения утверждений в выпускаемых сборках: например, библиотеки не должны вызывать сбой при вызове, присутствие утверждений может привести к отклонению магазинами приложений и/или активация их при рабочем использовании может привести к раскрытию частных данных, таких как закрытые ключи. Помните, что во многих дистрибутивах Linux NDEBUG не определен, поэтому C/C++assert() в таких рабочих средах по умолчанию будет включен. Может быть важно использовать другой механизм утверждений или определить NDEBUG для эксплуатации в этих средах.

    Sentinel does not currently make significant use of run-time assertions (assert statements) in its production code. Python's assert statements are stripped when running with optimization flags (-O), and the project relies instead on explicit validation (Pydantic schemas, service-layer guard clauses raising typed exceptions, database CHECK constraints) rather than assert-based runtime assertions. No dynamic analysis tool (e.g., fuzzing, property-based testing with Hypothesis) is currently integrated into the test suite or CI pipeline.



Вы можете использовать инструменты и системы ИИ для предложения изменений через простой URL, например https://www.bestpractices.dev/ru/projects/14063/choose/edit?osps_ac_01_01_status=Met&osps_ac_01_01_justification=GitHub+enforced. Смотрите нашу систему автоматизированных предложений о том, как это сделать. Эти данные доступны по лицензии Community Data License Agreement – Permissive, Version 2.0 (CDLA-Permissive-2.0). Это означает, что получатель данных может распространять данные с изменениями или без них, при условии, что получатель данных предоставляет текст данного соглашения вместе с распространяемыми данными. Пожалуйста, укажите в качестве источника Gianluca Gabrielli и участников OpenSSF Best Practices badge.

Владелец анкеты на значок проекта: Gianluca Gabrielli.
2026-08-13 13:55:49 UTC, последнее изменение сделано 2026-08-14 06:09:03 UTC. Последний раз условия для получения значка были выполнены 2026-08-13 16:48:08 UTC.