Libellus Potionis

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

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

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


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

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

        

 Основы 2/5 ●

  • Общая

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

    Libellus Potionis is a privacy-first, free, open-source, ad-free alcohol-consumption tracker that helps users monitor, pace, and manage their drinking habits entirely offline. It needs no invasive device permissions — no camera, microphone, or location access — and works completely without network connectivity.

    Key features

    • Intelligent logging: predefine custom beverages or use internationally common presets, and log drinks instantly or retroactively with precise timestamp corrections.
    • Concurrent limit tracking: set three simultaneous boundaries — a daily limit (grams of pure alcohol), a rolling 7-day weekly limit (grams), and a maximum number of drinking days per week — with visual progress bars in real time.
    • Blood-alcohol (BAC) estimation: enter your body weight for a live BAC approximation based on the established Widmark formula.
    • Addiction-counseling reports: generate a clear, well-organized two-page PDF report designed for consultations and counseling appointments.
    • Data portability: export your complete dataset as a standard CSV file for external processing (e.g. in LibreOffice Calc), or create secure JSON backups to migrate data between devices.
    • Granular adjustments: customize your "day start" time so late-night drinks count toward the correct evening, and define custom evaluation start dates for clean restarts.

    A comprehensive User's Guide is fully accessible in-app. The app is available on F-Droid.

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

    Libellus Potionis is a privacy-first, offline, ad-free Android app for tracking, pacing, and managing alcohol consumption. It requests no network permission and no camera/microphone/location access; all data stays on the device in the app's private, sandboxed storage, encrypted at rest (AES-256-GCM via the Android Keystore), with an optional biometric lock. It is Free Software under GPL-3.0-or-later, developed openly on Codeberg and distributed through F-Droid. The project is deliberately maintained as a teaching-quality codebase: every source file carries a license header and KDoc, and a release gate (tools/release-check.sh) enforces documentation, version consistency, English-only source, and translation completeness. Quality is guarded by a broad automated test suite (JVM unit tests plus instrumented Room-migration, Compose-UI, and locale tests) and by Android Lint and Kotlin compiler warnings promoted to build-breaking errors.

  • Предварительные требования


    Недостаточно для значка.

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

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


    Недостаточно для значка.

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

    Not met. The project currently has a single maintainer, so its bus factor is 1. Achieving a bus factor of 2 or more requires a second, significantly involved maintainer. This is tracked as an open item in docs/ROADMAP.md ("Working toward the OpenSSF gold badge").


    Недостаточно для значка.

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

    Not met. The project currently has a single significant contributor (the sole maintainer), so it does not have two unassociated significant contributors. This will be satisfied by bringing on a second, independent significant contributor; tracked in docs/ROADMAP.md ("Working toward the OpenSSF gold badge").


  • Другое


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

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

    Met. The same header that provides the copyright statement in each hand-authored source file also provides a licence statement — the GNU GPL v3-or-later grant text — which is a fuller form than an SPDX-License-Identifier line. It is present in every Kotlin, Gradle KTS, Python, shell, ProGuard, XML (resources and manifest), version-catalog, and configuration source file. The excluded categories are identical to copyright_per_file: generated files, vendored third-party files, third-party fonts, and pure data/binary assets.


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

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


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

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

    The project uses Git, the most widely used distributed version control system, hosted on Codeberg (Forgejo). Repository: https://codeberg.org/godisch/potillus


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

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

    Met. Small tasks for new or casual contributors are identified in the tracker with the "good first issue" label and described in CONTRIBUTING.md ("Good first issues"), which highlights native-speaker translation review of the machine-generated locales, documentation, and test cases as good entry points. URL: https://codeberg.org/godisch/potillus/issues?labels=1948199


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

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

    Met. Write (push) access to the canonical repository (hosted on Codeberg) requires two-factor authentication as a documented project policy: docs/GOVERNANCE.md ("Repository access and account security") states that any account with write access MUST have cryptographic 2FA enabled. Currently the sole maintainer is the only account with write access and has 2FA enabled; the policy binds any future account granted write access. Codeberg additionally blocks plain-password HTTP/S git operations once 2FA is enabled, so access requires a token or SSH key. The forge offers no per-project 2FA enforcement toggle, so the requirement is enforced by written policy. Reference: https://codeberg.org/godisch/potillus/src/branch/main/docs/GOVERNANCE.md


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

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

    Met. The project's 2FA policy (docs/GOVERNANCE.md, "Repository access and account security") mandates a cryptographic method — a TOTP authenticator app or a hardware security key — and explicitly excludes SMS. The maintainer's Codeberg 2FA uses such a cryptographic method. Reference: https://codeberg.org/godisch/potillus/src/branch/main/docs/GOVERNANCE.md


 Качество 4/7 ●

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


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

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

    CONTRIBUTING.md ("Code review requirements", Section 2) documents the project's code review process: how review is conducted (every change is reviewed before merge by the maintainer as reviewer and sole merger; the reviewer runs the build, the test suite, and tools/release-check.sh locally since there is no CI service yet), an explicit checklist of what must be checked (scope/privacy fit, architecture rules, coding and KDoc conventions, warnings-as-errors, mandatory tests, localization completeness, per-file licensing, DCO sign-off, and schema-freeze rules), and the acceptance criteria required for a change to be merged. URL: https://codeberg.org/godisch/potillus/src/branch/main/CONTRIBUTING.md


    Недостаточно для значка.

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

    The project currently has a single maintainer who authors and reviews all changes, so fewer than 50% of modifications are reviewed by a person other than the author. The review process and checklist are documented (CONTRIBUTING.md, "Code review requirements"); satisfying this criterion requires a second, independent reviewer. Tracked in docs/ROADMAP.md ("Working toward the OpenSSF gold badge").


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


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

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

    The Android build is reproducible. F-Droid builds the app from source and verifies that the result is bit-for-bit identical to the maintainer-signed APK before publishing it (F-Droid's Reproducible Builds process). This is documented in SECURITY.md ("Verifying releases"), and the F-Droid build recipe (fdroid/de.godisch.potillus.yml) pins the build and the allowed APK signing key, so anyone can rebuild from a release tag and compare against the published APK. URL: https://codeberg.org/godisch/potillus/src/branch/main/SECURITY.md


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


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

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

    The test suite is invoked in the standard way for a Gradle/Android project: ./gradlew test runs the JVM unit tests and ./gradlew connectedCheck runs the instrumented tests on a device or emulator. This conventional invocation is documented in CONTRIBUTING.md (Section 5, "Testing strategy", and the change-submission checklist in Section 2). URL: https://codeberg.org/godisch/potillus/src/branch/main/CONTRIBUTING.md


    Недостаточно для значка.

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

    Not currently implemented. The project is maintained by a single developer who builds and runs the full test suite and release gate (tools/release-check.sh) locally before each release, but there is no central CI service running automated tests on every change. This criterion is SUGGESTED at passing and a MUST at gold; the planned remediation is a Woodpecker pipeline (.woodpecker.yml) on Codeberg that runs the JVM unit tests (and lint/ktlint) on each push and reports success or failure — the same work as the silver automated_integration_testing item. Tracked in docs/ROADMAP.md.


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

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

    The JVM unit-test suite reaches ~97% statement (line) coverage, measured with Kover over the unit-testable code. Android-runtime-bound code (Compose UI, Room database/DAOs, DataStore preferences, Keystore, PDF/WebView rendering, and MediaStore import/export) is excluded from this figure and verified instead by the instrumented suite (src/androidTest). A build-breaking 90% line floor is enforced by the koverVerify Gradle task in the release gate (make cover-check). Methodology: CONTRIBUTING.md §5; scope/enforcement: app/build.gradle.kts.


    Недостаточно для значка.

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

    Branch coverage is ~80% (Kover, unit-testable scope), with a 75% regression floor enforced via koverVerify. The remaining branches lie in Android-/Compose-adjacent code (ViewModel StateFlow assembly, resource-bound error mapping); reaching the ≥80% gold threshold is a tracked roadmap goal.


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

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

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

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

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

    Not applicable. The application performs no network communication: it does not declare the INTERNET permission, works entirely offline, and transmits no data. There are therefore no network protocols whose security could be assessed.


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

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

    Not applicable. The application does not use TLS because it performs no network communication at all (no INTERNET permission, offline-only). There is no TLS configuration or version to assess.


  • Доставка, защищенная от атак посредника (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, поскольку в этом случае эти заголовки менее эффективны.

    Not met. The criterion requires the repository and download sites to send four key hardening headers (CSP, HSTS, X-Content-Type-Options: nosniff, X-Frame-Options). The download site (F-Droid) sends all four. The repository host (Codeberg) sends strong HSTS (max-age two years, includeSubDomains, preload) and X-Frame-Options, but not CSP or X-Content-Type-Options. These headers are set by Codeberg, not by the project, and cannot be configured from the repository. Tracked in docs/ROADMAP.md; remediation is to request the missing headers from Codeberg or mirror on a compliant platform.


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


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

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

    A security review was performed in 2026 and is recorded in docs/ASSURANCE_CASE.md ("Security review record"). It takes into account the security requirements (SECURITY.md, "Security model") and the security boundary (the threat model and trust boundaries in the assurance case), combining that analysis with an Android-focused code/QA pass over the security-relevant areas (at-rest Keystore encryption, input and backup/import validation, CSV-injection neutralization, the permission surface and exported components, and the FLAG_SECURE / allowBackup / R8 hardening). No unresolved high-severity issues are known; residual risks are stated explicitly. URL: https://codeberg.org/godisch/potillus/src/branch/main/docs/ASSURANCE_CASE.md


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

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

    Met. Release builds apply R8 code shrinking and obfuscation (isMinifyEnabled = true) with resource shrinking and the optimizing ProGuard configuration. The manifest sets android:allowBackup="false" to prevent backup-based data exfiltration, and the app applies WindowManager FLAG_SECURE by default from cold start to block screenshots, screen recording, and Recents-thumbnail exposure. The permission set is minimal (no network or telephony; only USE_BIOMETRIC) and only the launcher activity is exported. These complement the hardware-backed Keystore at-rest encryption and the warnings-as-errors/lint gate. URL: https://codeberg.org/godisch/potillus/src/branch/main/android/app/build.gradle.kts


 Анализ 1/2 ●

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


    Недостаточно для значка.

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

    No dedicated dynamic analysis tool (fuzzer, sanitizer, or scanner) is applied before releases, and branch coverage is not yet measured, so the "automated test suite with ≥80% branch coverage counts as dynamic analysis" allowance cannot yet be claimed. The instrumented tests do exercise the app on a device/emulator, but without a measured ≥80% branch-coverage figure this does not yet meet the criterion. Remediation is tied to the Kover branch-coverage work in docs/ROADMAP.md; alternatively a dedicated dynamic tool could be added.


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

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

    Not met (SHOULD). The criterion targets fault detection during dynamic analysis (testing), not production. The produced code contains a small number of always-on Kotlin preconditions (require/check/error) that are checked whenever the code runs, including under the test suite, but not "many". Remediation (tracked in docs/ROADMAP.md): add invariant assertions in the JVM-testable domain and data layers using Kotlin assert(), which Gradle's unit-test task runs with assertions enabled (-ea) by default, so they are checked during dynamic analysis while remaining disabled in ART release builds.



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

Владелец анкеты на значок проекта: Martin A. Godisch.
2026-07-04 04:21:04 UTC, последнее изменение сделано 2026-07-07 03:30:36 UTC. Последний раз условия для получения значка были выполнены 2026-07-04 08:45:54 UTC.