Libellus Potionis

本サイトが提示する下記のベストプラクティスを実行するプロジェクトは、Open Source Security Foundation (OpenSSF) バッジを達成したことを自主的に自己認証し、そのことを外部に示すことができます。

ソフトウェアに欠陥や脆弱性がないことを保証する手立てはありません。形式論的な証明ができたとしても、仕様や前提が間違っていると誤動作の可能性があります。また、プロジェクトが健全で、かつ機能的な開発コミュニティであり続けることを保証する手立てもありません。しかし、ベストプラクティスの採用は、プロジェクトの成果の向上に寄与する可能性があります。たとえば、いくつものベストプラクティスがリリース前の複数人によるレビューを定めていますが、それによりレビュー以外では発見困難な技術的脆弱性を見つけるのを助け、同時に異なる企業の開発者間の信頼を築き、さらに交流を続けることに対する意欲を生んでいます。バッジを獲得するには、すべてのMUSTおよびMUST NOT基準を満たさなければなりません。すべてのSHOULD基準も満たさなければなりませんが、正当な理由がある場合は満たさなくても構いません。そしてすべてのSUGGESTED基準も満たさなければなりませんが、満たさないとしても、少なくとも考慮することが望まれます。フィードバックは、 GitHubサイトのissueまたはpull requestとして提示されれば歓迎します。また、議論のためのメールリストも用意されています。

私たちは多言語で情報を提供していますが、翻訳版に矛盾や意味の不一致がある場合は、英語版を正式な記述とします。
これがあなたのプロジェクトである場合は、プロジェクトページにベースラインバッジステータスを表示してください!ベースラインバッジステータスは次のようになります: プロジェクト13480のベースラインバッジレベルはbaseline-2です ベースラインバッジを埋め込む方法は次のとおりです:
ベースラインバッジステータスを表示するには、マークダウンファイルに以下を埋め込みます:
[![OpenSSF Baseline](https://www.bestpractices.dev/projects/13480/baseline)](https://www.bestpractices.dev/projects/13480)
または、HTMLに以下を埋め込みます:
<a href="https://www.bestpractices.dev/projects/13480"><img src="https://www.bestpractices.dev/projects/13480/baseline"></a>


これらはベースラインレベル1の基準です。 これらは基準バージョン v2026.08.28 の評価項目です。

Baseline Series: ベースラインレベル1 ベースラインレベル2 ベースラインレベル3

        

 基本的情報

  • 一般

    他のプロジェクトが同じ名前を使用していないか注意してください。

    Libellus Potionis is a privacy-first, free, open-source, and ad-free alcohol consumption tracker designed to help users monitor, pace, and manage their drinking habits entirely offline. It requires no invasive device permissions—no camera, microphone, or location access—and completely operates without network connectivity. It runs on both Android and iOS, and 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)」。一重引用符または二重引用符を含めないでください。
    複数の言語がある場合は、コンマを区切り(スペースを入れてもよい)としてリストし、使用頻度の高いものから順に並べます。使用言語が多くある場合は、少なくとも最初の3つの最も多く使われるものをリストアップしてください。言語がない場合(例:ドキュメントだけ、またはテスト専用のプロジェクトの場合)、1文字 " - "を使用します。言語ごとにある大文字・小文字の慣用を踏襲してください(例:「JavaScript」)。
    Common Platform Enumeration(CPE)は、情報技術(IT)システム、ソフトウェア、およびパッケージのための構造化された命名体系です。脆弱性を報告する際に、多くのシステムやデータベースで使用されています。

    The two are separate native apps in this one repository — Kotlin/Jetpack Compose for Android, Swift/SwiftUI for iOS — that share the same design, the same feature set, and a common JSON backup format, so a backup exported on one platform imports on the other. Their behaviour is kept in lock-step by a shared set of golden test vectors.

    Key Features

    • Logging: predefine custom beverages or use internationally common presets. Log drinks instantly or retroactively with precise timestamp corrections.
    • Concurrent limits: set three boundaries at once — a daily limit in grams of pure alcohol, a rolling 7-day limit in grams, and a maximum number of drinking days per week. Each has its own progress bar.
    • Blood alcohol concentration (BAC): enter your body weight to get a live estimate from the Widmark formula.
    • Counseling reports: generate a two-page PDF report of your consumption for a counseling appointment.
    • Data portability: export the dataset as a CSV file for external processing (e.g. in LibreOffice Calc), or create JSON backups to move data between devices.
    • Adjustments: set your own "day start" time, so that late-night drinks count toward the preceding evening, and an evaluation start date for a clean restart.

    A User's Guide is available inside the app.

 管理策 24/24

  • 管理策


    ユーザーがプロジェクトの権威リポジトリにある機密リソースを読み取ったり変更したりしようとする場合、システムは多要素認証プロセスの完了をユーザーに要求しなければなりません。 [OSPS-AC-01.01]
    プロジェクトのバージョン管理システムに多要素認証を強制し、協力者が機密データにアクセスしたりリポジトリ設定を変更したりする際に第2の認証形式を提供するよう要求します。パスキーはこの管理として許容されます。

    Write (push) access to the canonical repository (hosted on GitLab) 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. GitLab additionally accepts no account password for git over HTTP/S at all — an access token or an SSH key is required — so a stolen password alone cannot push. Per-project 2FA enforcement is a group-level setting the project's plan does not offer, so the requirement is enforced by written policy.



    新しい協力者が追加される場合、バージョン管理システムは手動による権限割り当てを要求するか、デフォルトで協力者の権限を最低利用可能な特権に制限しなければなりません。 [OSPS-AC-02.01]
    ほとんどの公開バージョン管理システムは、この方法で設定されています。プロジェクトのバージョン管理システムが、協力者を追加する際にデフォルトで常に利用可能な最低限の権限を割り当て、必要な場合にのみ追加の権限を付与するように設定してください。

    On GitLab, project members are never added automatically: a user with the Owner role must explicitly invite each member and assign a role (Guest/Reporter/Developer/Maintainer/Owner), and no role grants itself an escalation. The project also currently has a single maintainer, so no additional members with elevated access exist. The set of accounts with write access is documented in docs/GOVERNANCE.md. Any future collaborator therefore requires a deliberate, manual permission grant by the owner.



    プロジェクトのプライマリブランチに直接コミットが試行された場合、強制メカニズムが変更の適用を防止しなければなりません。 [OSPS-AC-03.01]
    バージョン管理システムが集中型の場合は、プロジェクトのバージョン管理システムのプライマリブランチにブランチ保護を設定してください。あるいは、Linuxカーネルのような分散型アプローチを使用します。この場合、変更はまず別のリポジトリで提案され、プライマリリポジトリへの変更のマージには特定の個別の操作が必要です。

    The primary branch (main) on the project's GitLab repository is a protected branch whose "Allowed to push and merge" setting is "No one", so direct pushes are rejected server-side for every role including the project Owner, and changes reach main only through a merge request. All changes to main therefore go through a merge request, satisfying the enforcement requirement even though the project currently has a single maintainer.



    プロジェクトのプライマリブランチの削除が試行された場合、バージョン管理システムはこれを機密性の高い活動として扱い、意図の明示的な確認を要求しなければなりません。 [OSPS-AC-03.02]
    プロジェクトのバージョン管理システムのプライマリブランチにブランチ保護を設定して削除を防止してください。

    The primary branch (main) is the repository's default branch and is additionally a protected branch. On GitLab a protected branch cannot be deleted while the protection rule is active, and the default branch cannot be deleted at all; removing the protection is itself a deliberate, separately audited settings change. Deleting the primary branch is therefore treated as a blocked, non-accidental action, exceeding the "require explicit confirmation of intent" requirement.



    CI/CDパイプラインが信頼できないメタデータを処理する場合、それらのパラメータはパイプラインで使用する前にサニタイズおよび検証されなければならない。 [OSPS-BR-01.01]
    CI/CDパイプラインは、信頼できないソースに対応するすべてのメタデータ入力をサニタイズ(期待値の引用、エスケープ、または終了)する必要があります。これには、ブランチ名、コミットメッセージ、タグ、プルリクエストのタイトル、作者情報などのデータが含まれます。

    The project's CI/CD pipeline consumes no untrusted input, by construction rather than by sanitizing after the fact. .gitlab-ci.yml interpolates no forge-supplied string anywhere: no merge request title, branch name, commit message, fork payload or user-supplied variable appears in any job's script. The jobs run three fixed commands — tools/release-check.sh --Werror, make check-static and an osv-scanner source scan — each of which reads only the checked-out tree. The single CI variable the file references, CI_MERGE_REQUEST_TARGET_BRANCH_NAME, appears in a workflow: rule comparison, never in a shell command, so it cannot be interpreted as code. There is therefore no injection path from a proposed change into pipeline execution.



    CI/CDパイプラインが信頼されていないコードスナップショットで動作する場合、特権のあるCI/CDクレデンシャルおよびアセットへのアクセスを防止しなければなりません。 [OSPS-BR-01.03]
    CI/CDパイプラインは、信頼されていないコードスナップショットを特権のあるクレデンシャルおよびアセットから分離する必要があります。特に、プロジェクトは、協力者によるレビュー前にコードをビルドまたは実行するワークフローがCI/CDクレデンシャルにアクセスできないよう注意する必要があります。

    Untrusted code snapshots cannot reach privileged credentials, because the pipeline holds none. .gitlab-ci.yml defines no secret, no protected or masked variable and no deployment credential; its three jobs are read-only checks on a plain python:3-slim image. The project's privileged credentials — the release-signing keystore, the Google Play and App Store upload keys, and the GitLab release token in fastlane/gitlab-credentials.txt — exist only in the maintainer's local, git-ignored files and are never present in a CI environment; releases are built and published manually on a trusted local checkout. A merge request from a fork therefore executes only the fixed check commands, with nothing privileged in reach. The automatic CI job token is scoped to this project alone under Settings > CI/CD > Token Access.



    プロジェクトがURIを公式プロジェクトチャンネルとしてリストする場合、そのURIは暗号化されたチャンネルを使用して排他的に配信されなければなりません。 [OSPS-BR-03.01]
    プロジェクトのウェブサイトおよびバージョン管理システムを、データ送信にSSHまたはHTTPSなどの暗号化されたチャンネルを使用するように設定してください。プロジェクトドキュメントで参照されるすべてのツールとドメインが、暗号化されたチャンネルを介してのみアクセスできるようにしてください。

    All official project channels are served exclusively over encrypted transport. The canonical repository and issue tracker (gitlab.com/godisch/potillus) are reached over HTTPS (and Git over HTTPS/SSH), and the distribution page (f-droid.org/packages/de.godisch.potillus) is HTTPS-only; both GitLab and F-Droid enforce HTTPS with HSTS. No project URL uses plain HTTP.



    プロジェクトが公式配布チャネルとしてURIを掲載する場合、そのチャネルは暗号学的に認証されたチャネルを使用して、中間者(adversary-in-the-middle)攻撃から保護されなければならない。 [OSPS-BR-03.02]
    プロジェクトによって配布される成果物は、完全性と真正性を保証するチャネルを通じて配布されるべきです。ダウンロードにHTTPSを使用すること、署名付きリリースを使用すること、信頼できるパッケージマネージャーを通じて配布することは、いずれも中間者攻撃から保護するための許容できる方法です。

    The distribution channel is protected against adversary-in-the-middle attacks by cryptographically authenticated delivery, not transport security alone. The app is published on F-Droid (f-droid.org/packages/de.godisch.potillus) over HTTPS, where F-Droid cryptographically signs its repository index and signs the APK. The build is reproducible: F-Droid rebuilds the app from the published GPL-licensed source and verifies the result bit-for-bit against the developer-signed APK before publishing, so the distributed binary is provably the one built from public source. Clients therefore verify a signed index and a signed package whose provenance is independently reproducible. GitLab source access is likewise HTTPS-only. The planned Apple App Store channel likewise delivers Apple-signed packages over HTTPS; the App Store re-signs the binary with an Apple identity, so — like Google Play — the delivered artifact is not third-party-reproducible, though the underlying iOS build is verified reproducible by the two-build check in make release-ios.



    プロジェクトは、シークレットや認証情報などの暗号化されていない機密データが、バージョン管理システムに意図せず保存されることを防止しなければなりません。 [OSPS-BR-07.01]
    機密情報を含む可能性のあるファイルを除外するために、.gitignoreまたは同等のものを設定してください。プリコミットフックおよび自動スキャンツールを使用して、コミットに機密データが含まれることを検出および防止してください。

    The public repository leaks no valid private credentials. It contains no keystore or private-key files (no .jks/.keystore/.pem/.p12, no real keystore.properties) and no hard-coded passwords or API keys. Release signing material and the Google Play service-account key are explicitly git-ignored (/android/keystore.properties, /fastlane/play-store-credentials.json) and marked "SECRET, never commit"; only a documented placeholder template (android/keystore.properties.example) is committed, and the Play key is referenced only by path/SUPPLY_JSON_KEY, never embedded.



    プロジェクトがリリースを行った場合、プロジェクトドキュメントには、すべての基本機能に対するユーザーガイドを含まなければなりません。 [OSPS-DO-01.01]
    プロジェクトのすべての基本機能について、インストール、設定、およびプロジェクトの機能の使用方法を説明するユーザーガイドまたはドキュメントを作成してください。既知の危険な行為または破壊的な行為が利用可能な場合は、非常に目立つ警告を含めてください。

    The project provides basic user documentation. A comprehensive, screen-by-screen User's Guide (localized into 21 languages) explains every screen and feature — Today, Calendar, Statistics, Drinks, and Settings (limits, backup/restore, security, appearance) — and is rendered and displayed inside the app itself (via tools/render-guide.py, shown in DocumentViewerScreen). The README additionally documents the app's purpose, feature set, platform requirements (Android 11+), and how to obtain it. The iOS port ships the same screen-by-screen guide (docs/guide/usersguide.ios.md), rendered inside the app, and targets iOS 17+.



    プロジェクトがリリースを行った場合、プロジェクトドキュメントには、欠陥報告のためのガイドを含まなければなりません。 [OSPS-DO-02.01]
    プロジェクトでは、バージョン管理システムのデフォルトの課題追跡ツールを使用することをお勧めします。外部ソースが使用される場合は、プロジェクトドキュメントと貢献ガイドで報告システムの使用方法を明確かつ目立つように説明してください。プロジェクトドキュメントでは、欠陥がどのようにトリアージおよび解決されるかについての期待値を設定することもお勧めします。

    Users submit bug reports through the project's GitLab issue tracker, with android@godisch.de offered as an alternative. This process is documented in the README's "Feedback & Contributing" section.



    プロジェクトは、提案された変更や利用上の障害についての公開討論のための1つ以上のメカニズムを持たなければならない。 [OSPS-GV-02.01]
    メーリングリスト、インスタントメッセージング、または課題追跡ツールなど、プロジェクト内の公開討論のための1つ以上のメカニズムを確立し、オープンなコミュニケーションとフィードバックを促進してください。

    Discussion of proposed changes and issues takes place in the project's GitLab issue tracker and merge requests (gitlab.com/godisch/potillus/-/issues). This mechanism is full-text searchable; every issue, merge request, and comment is addressable by a stable URL; any person with a free GitLab account can open issues and join the discussion; and it is used entirely through a web browser, requiring no proprietary client-side software (GitLab's core is released as free software under the MIT licence).



    プロジェクトのドキュメントには、貢献プロセスの説明を含めなければならない、または一般からの貢献を受け付けていないことを明確に記載しなければならない。 [OSPS-GV-03.01]
    変更の提出手順やプロジェクトメンテナーとのやり取りを含む、貢献プロセスの概要を示すCONTRIBUTING.mdまたはCONTRIBUTING/ディレクトリを作成します。

    The contribution process is documented in CONTRIBUTING.md, Section 2 "Submitting changes": contributors open an issue to discuss the change, then submit it as a merge request against main on GitLab (a patch by e-mail is accepted as an alternative); the change must meet the documented architecture, coding, testing, and translation conventions, and is reviewed and merged by the maintainer.



    ソースコードのライセンスは、OSIのオープンソース定義またはFSFのフリーソフトウェア定義を満たさなければならない。 [OSPS-LE-02.01]
    OSI(Open Source Initiative)によって承認されたライセンス、またはFSF(Free Software Foundation)によって承認されたフリーライセンスを含むLICENSEファイルをプロジェクトのリポジトリに追加します。そのようなライセンスの例としては、MIT、BSD 2-clause、BSD 3-clause revised、Apache 2.0、Lesser GNU General Public License(LGPL)、およびGNU General Public License(GPL)が含まれます。特許などの他の障害がない場合、パブリックドメインへのリリースはこの管理を満たします。

    The GPL-3.0-or-later license for the repository contents is approved by the Open Source Initiative (OSI).



    リリースされたソフトウェア資産のライセンスは、OSIのオープンソース定義またはFSFのフリーソフトウェア定義を満たさなければならない。 [OSPS-LE-02.02]
    リリースされたソフトウェア資産に異なるライセンスが含まれている場合は、OSI(Open Source Initiative)によって承認されたライセンス、またはFSF(Free Software Foundation)によって承認されたフリーライセンスであることを確認してください。そのようなライセンスの例としては、MIT、BSD 2-clause、BSD 3-clause revised、Apache 2.0、Lesser GNU General Public License(LGPL)、およびGNU General Public License(GPL)が含まれます。リリースされたソフトウェア資産のライセンスはソースコードとは異なる場合があることに注意してください。

    The software is released as Free/Libre and Open Source Software under the GNU General Public License v3.0 or later (GPL-3.0-or-later). The full license text is provided in LICENSE.md, the copyright notice in COPYING.md ("either version 3 of the License, or (at your option) any later version"), and the F-Droid metadata declares License: GPL-3.0-or-later.



    ソースコードのライセンスは、対応するリポジトリのLICENSEファイル、COPYINGファイル、LICENSES/ディレクトリ、またはLICENSE/ディレクトリで管理されなければならない。 [OSPS-LE-03.01]
    ライセンス条項の可視性と明確性を確保するため、プロジェクトのソースコードライセンスをプロジェクトのLICENSEファイル、COPYINGファイル、LICENSES/ディレクトリ、またはLICENSE/ディレクトリに含めてください。ファイル名には拡張子を付けてもかまいません。プロジェクトが複数のリポジトリを持つ場合は、各リポジトリにライセンスファイルが含まれていることを確認してください。

    The project's license is posted in a standard location at the repository root as LICENSE.md (full GPL-3.0-or-later text), which GitLab auto-detects and displays as the project license; COPYING.md sits alongside it with the copyright notice.



    リリースされたソフトウェア資産のライセンスは、リリースされたソースコードに含めるか、対応するリリース資産と共にLICENSEファイル、COPYINGファイル、またはLICENSE/ディレクトリに含めなければならない。 [OSPS-LE-03.02]
    ライセンス条件に関する可視性と明確性を提供するために、プロジェクトのリリースされたソフトウェア資産のライセンスを、リリースされたソースコードに、または対応するリリース資産と一緒にあるLICENSEファイル、COPYINGファイル、またはLICENSE/ディレクトリに含めます。ファイル名には拡張子を付けることができます。プロジェクトに複数のリポジトリがある場合は、各リポジトリにライセンスファイルが含まれていることを確認してください。

    The released software assets carry the same GPL-3.0-or-later license as the source. In the repository the license is posted in a standard location at the root — LICENSE.md (full GPL-3.0-or-later text) with COPYING.md alongside — which GitLab auto-detects. The license also travels with the released application: each package bundles the verbatim text of every license it is obliged to reproduce, copied verbatim from the project-root license files at build time (Android: res/raw/license_gpl3.md, license_apache2.md, license_gpl2.md and license_bsd3.md; iOS: license_gpl3.md), and the in-app About screen states the app's own GPL notice with the App Store Distribution Exception in full and links to each verbatim text. F-Droid builds the published APK from this GPL-licensed source and distributes that source alongside the binary.



    プロジェクトのソースコードリポジトリは、静的なURLで公開され、読み取り可能でなければならない。 [OSPS-QA-01.01]
    GitHub、GitLab、Bitbucketなどの一般的なVCSを使用します。リポジトリが公開読み取り可能であることを確認してください。主要なソースを明確にする可視性の高いドキュメントがない限り、リポジトリの複製またはミラーリングを避けてください。リポジトリURLに影響を与える可能性のある頻繁なリポジトリの変更を避けてください。リポジトリが公開されていることを確認してください。

    The project uses a publicly readable, version-controlled Git repository at a stable URL, gitlab.com/godisch/potillus — readable without an account and cloneable over HTTPS.



    バージョン管理システムには、行われたすべての変更、誰が変更を行ったか、いつ変更が行われたかの公開読み取り可能な記録が含まれている必要があります。 [OSPS-QA-01.02]
    GitHub、GitLab、Bitbucketなどの一般的なVCSを使用して、公開読み取り可能なコミット履歴を維持します。コミットの作成者が不明瞭になるような方法でコミットをスカッシュまたは書き換えることは避けてください。

    The project's source repository uses Git, which inherently records, for every commit, what changed (the diff/tree), who made the change (author and committer identity), and when (author and commit timestamps). The full history is publicly browsable on GitLab (commit list, diffs, and blame view) at gitlab.com/godisch/potillus/-/commits/main



    パッケージ管理システムがサポートしている場合、ソースコードリポジトリには、直接の言語依存関係を説明する依存関係リストが含まれている必要があります。 [OSPS-QA-02.01]
    これは、package.json、Gemfile、go.modなど、すべての直接依存関係を列挙するパッケージマネージャーまたは言語依存関係ファイルの形式を取ることができます。

    External dependencies are declared in a computer-processable, versioned form and are obtained automatically by a standard build. The Gradle version catalog (android/gradle/libs.versions.toml) pins every library and plugin version in its [versions], [libraries], and [plugins] tables, referenced via alias(libs.…) in the build scripts; settings.gradle.kts configures the repositories (google, mavenCentral, gradlePluginPortal), so ./gradlew resolves and downloads all declared dependencies with no manual steps. The iOS port declares its dependencies the same way: ios/PotillusKit/Package.swift names them and ios/PotillusKit/Package.resolved pins each to an exact version and revision, which SwiftPM resolves automatically. Both builds additionally generate a CycloneDX 1.6 JSON SBOM of the release dependencies as a standardized machine-readable inventory (make sbom, make ios-sbom).



    複数のリポジトリを持つプロジェクトは、プロジェクトの一部であるコードベースの一覧を文書化しなければならない。 [OSPS-QA-04.01]
    プロジェクトによって生成され、リリースにコンパイルされる追加のサブプロジェクトコードリポジトリを文書化します。このドキュメントには、それぞれのコードベースのステータスと意図を含める必要があります。

    The project consists of a single source repository (gitlab.com/godisch/potillus) with no Git submodules and no separate subproject repositories. As the project does not span multiple repositories, this requirement's precondition does not apply. Should the project ever split into multiple repositories, the constituent codebases would be documented (e.g. in README.md/docs/).



    バージョン管理システムには、生成された実行可能な成果物を含めてはなりません(MUST NOT)。 [OSPS-QA-05.01]
    プロジェクトのバージョン管理システムで生成された実行可能アーティファクトを削除します。生成された実行可能アーティファクトがテストなどのプロセスで重要と思われるシナリオでは、代わりにビルド時に生成するか、別に保存して、明確に文書化されたパイプライン ステップ中に取得する必要があることが推奨されます。

    The version control system contains no artifacts generated by the project's own build. All build outputs (APK/AAB, AAR, .dex, .class, compiled libraries) are produced under git-ignored directories (android/build, android/app/build, android/.gradle) and are never committed. The only committed binary is gradle/wrapper/gradle-wrapper.jar, the upstream Gradle bootstrap wrapper whose in-repository presence is the Gradle-recommended practice; it is not a project-generated artifact. Its integrity is addressed under OSPS-QA-05.02. The iOS port is the same: Xcode build products (DerivedData, .build) and the XcodeGen-generated ios/Potillus.xcodeproj are git-ignored and never committed, and no iOS binary is checked in.



    バージョン管理システムには、レビュー不可能なバイナリ成果物を含めてはなりません(MUST NOT)。 [OSPS-QA-05.02]
    プロジェクトのバージョン管理システムにレビュー不可能なバイナリアーティファクトを追加しないでください。これには、実行可能なアプリケーションバイナリ、ライブラリファイル、および同様のアーティファクトが含まれます。これには、グラフィック画像、音声や音楽ファイル、および通常バイナリ形式で保存されるコンテンツなどのアセットは含まれません。

    The only executable/library binary committed to version control is gradle/wrapper/gradle-wrapper.jar, the standard Gradle Wrapper bootstrap (committing it is Gradle's recommended practice and is required to build without a pre-installed Gradle). It is not an opaque, unreviewable blob: it is a stock Gradle Wrapper jar whose authenticity is independently verifiable via the OpenSSF/Gradle wrapper-validation tooling. The build additionally pins the Gradle distribution by cryptographic checksum in gradle/wrapper/gradle-wrapper.properties (distributionSha256Sum, with validateDistributionUrl=true), so the wrapper can only bootstrap an authenticated official Gradle release; the pinned checksum was verified against the value Gradle publishes for that release. On every Gradle update the wrapper is regenerated from the verified distribution (documented in CONTRIBUTING.md §7), so the committed jar remains a stock, verifiable wrapper regardless of version. All other binary files are content assets explicitly excluded by this control — graphical images (PNG, SVG), TTF fonts, and sample report PDFs. No executable application binaries or opaque library files are committed. On the iOS side no binary is committed at all: SwiftPM resolves dependencies from source, pinned by exact version and revision in ios/PotillusKit/Package.resolved, so there is no wrapper jar or prebuilt library to review.



    プロジェクトの文書には、セキュリティ連絡先を含めなければなりません(MUST)。 [OSPS-VM-02.01]
    プロジェクトのセキュリティ連絡先を含むsecurity.md(または同様の名前の)ファイルを作成してください。

    The process for reporting vulnerabilities is published in SECURITY.md at the repository root (which GitLab surfaces as the project's security policy) and is linked from the README's "Security" section. Reporters are asked to disclose privately via PGP-encrypted e-mail to android@godisch.de rather than opening a public issue.



ツールやAIシステムを使って、https://www.bestpractices.dev/ja/projects/13480/choose/edit?osps_ac_01_01_status=Met&osps_ac_01_01_justification=GitHub+enforcedのような簡単なURLで変更を提案できます。その方法については、自動化提案システムをご覧ください。 このデータは、Community Data License Agreement – Permissive, Version 2.0 (CDLA-Permissive-2.0)のもとで利用可能です。これは、データ受領者が、データ受領者がこの契約のテキストを共有データとともに利用可能にする限り、変更の有無にかかわらずデータを共有できることを意味します。Martin A. GodischおよびOpenSSFベストプラクティスバッジのコントリビューターにクレジットを表示してください。

プロジェクト バッジ登録の所有者: Martin A. Godisch.
エントリの作成日時 2026-07-04 04:21:04 UTC、 最終更新日 2026-08-29 11:29:00 UTC 最後に2026-07-19 18:17:51 UTCにバッジ合格できませんでした。 最後に2026-07-19 18:18:14 UTCにバッジ合格を達成しました。