wasmCloud

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

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

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


これらはゴールドレベルの基準です。合格またはシルバーレベル基準を表示することもできます。

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

        

 基本的情報 3/5 ●

  • 一般

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

    wasmCloud is a cloud native platform for running WebAssembly workloads across any cloud, Kubernetes, datacenter, or edge.

    Using wasmCloud, you can run microservices, functions, and agents as ultra-dense, deny-by-default bytecode sandboxes that are far more secure and efficient than traditional containers.

    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）システム、ソフトウェア、およびパッケージのための構造化された命名体系です。脆弱性を報告する際に、多くのシステムやデータベースで使用されています。

  • 前提要件


    バッジには十分です！

    プロジェクトは、シルバー レベル バッジを達成しなければなりません。 [achieve_silver]

  • プロジェクトの管理・運営


    バッジには十分です！

    プロジェクトは2以上の "バス ファクタ"を持つ必要があります。 (URLが必要です) [bus_factor]
    「バス ファクタ」（別名「トラック ファクタ」）は、知見があり有能な人材が離脱して、プロジェクトが停止に至る時に、プロジェクトから突然消失する（「バスに当たった」）プロジェクトメンバーの最小人数です。 トラック ファクタツールは、GitHub上のプロジェクトに対してこれを見積もることができます。詳細については、Cosentino et al。の Gitリポジトリのバス ファクタの評価を参照してください。

    At least eight people each made 20 or more commits in the past year, MAINTAINERS.md (https://github.com/wasmCloud/wasmCloud/blob/main/MAINTAINERS.md) lists the maintainer teams, and CODEOWNERS assigns every path to the org-maintainers team. Releases are automated (RELEASE_RUNBOOK.md), so no single person is required to keep the project going.


    バッジには十分です！

    プロジェクトには少なくとも2人の関係を持たない重要な貢献者がいなければなりません。 (URLが必要です) [contributors_unassociated]
    同じ組織によって作業に対しに支払われ（従業員または請負業者）、組織がプロジェクトの成果の恩恵を受ける場合、貢献者は関連します。財務補助金が他の組織を通過する場合、同じ組織のものであると見なされません（例えば、共通の政府やNGOのソースから異なる組織に支払われた科学補助金は、貢献者を関連させません）。過去1年間にプロジェクトに些細でない貢献をしていれば、その人は大きな貢献をしています。重要な貢献者の良い指標の例としては、少なくとも1,000行のコード、50個のコミット、または少なくとも20ページの文書化が挙げられます。

    In the past year the repository received significant contributions from several contributors not associated with the organization that employs most maintainers, including if0ne, Aditya Salunkhe, Junji Takakura and Pavel Agafonov. See https://github.com/wasmCloud/wasmCloud/graphs/contributors.


  • その他


    バッジには不十分です。

    プロジェクトは、各ソースファイルにライセンスステートメントを含まなければなりません。これは、各ファイルの先頭近くに次のコメントを含めることによって行うことができます： SPDXライセンス識別子：[プロジェクトに対するSPDXライセンス表現] [license_per_file]
    これは、ライセンスを特定する自然言語での記述を含めることによっても行うことができます。プロジェクトには、ライセンス テキストまたは完全なライセンステキストを指し示す安定したURLを含めることもできます。 license_location基準は、プロジェクトライセンスが標準の場所にあることを要求します。 SPDXライセンスの詳細については、このSPDXチュートリアルを参照してください。 copyright_per_file との関係に注意してください。その内容は通常、ライセンス情報に先行します。

 変更管理 4/4 ●

  • 公開されたバージョン管理ソースリポジトリ


    バッジには十分です！

    プロジェクトのソースリポジトリは、共通の分散バージョン管理ソフトウェア（gitやmercurialなど）を使用しなければなりません。 [repo_distributed]
    Gitが特別に必要とされているわけでなく、プロジェクトでは、集中型バージョン管理ソフトウェア（例：subversion）を正当とする証拠を持って使用できます。

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


    バッジには十分です！

    プロジェクトは、新規または偶に参加する貢献者によって実行できる小さなタスクを明確に識別しなければなりません。 (URLが必要です) [small_tasks]
    この特定は、通常、課題トラッカーの選択された課題に対して、プロジェクトがそのために使用する1つまたは複数のタグ、たとえば、 up-for-grabs（誰でも使用可能）、first-timers-only（初心者専用）、Small fix（小修正）、microtask（小タスク）、またはIdealFirstBug（理想的な最初のバグ）のいずれかをマークすることによって行われます。 これらの新しいタスクには機能を追加する必要はありません。ドキュメントを改善したり、テストケースを追加したり、プロジェクトを支援したり、プロジェクトの詳細を貢献者が理解できるようにすることができます。

    Small tasks for new contributors are labeled "good first issue": https://github.com/wasmCloud/wasmCloud/labels/good%20first%20issue


    バッジには十分です！

    プロジェクトは、中央リポジトリを変更したり、機密データ（プライベート脆弱性レポートなど）にアクセスするために、開発者に対して二要素認証（2FA）を要求する必要があります。推奨されませんが、2FAメカニズムは、SMSのような暗号化メカニズムを持たないメカニズムを使用することができます。 [require_2FA]

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


    かろうじてバッジには十分です。

    プロジェクトの2要素認証（2FA）は、偽装を防ぐために暗号化メカニズムを使用すべきです。ショート メッセージ サービス（SMS）ベースの2FA自体は、暗号化されていないため、この基準を満たしていません。 [secure_2FA]
    この基準を満たす2FAメカニズムは、一定時間後に変更される認証コードを自動的に生成するタイムベースのワン タイム パスワード（TOTP）アプリケーションです。 GitHubはTOTPをサポートしています。

    The organization requires 2FA but does not yet restrict members to cryptographic methods; we plan to enable GitHub's secure-methods-only setting.


 品質 4/7 ●

  • コーディング標準


    バッジには十分です！

    プロジェクトは、コードレビューの実施方法、チェックする必要があるもの、受け入れられる必要があるものなど、コードレビュー要件を文書化しなければなりません。 (URLが必要です) [code_review_standards]
    two_person_review とcontribution_requirementsも参照してください。

    The main branch ruleset requires a pull request with at least one approving code-owner review, dismisses stale approvals on push, and requires approval of the most recent push, so every change is reviewed by someone other than its author before merge and release. Required status checks must also pass.

    Documentation for code review practices are covered in https://github.com/wasmCloud/wasmCloud/blob/main/CONTRIBUTING.md#code-review.


    バッジには十分です！

    プロジェクトは、公開する前に、提案されたすべての変更の少なくとも50％を著作者以外の人がレビューして、それが価値のある変更であり、取り込みに反対する既知の問題がないかどうかを判断しなければなりません。 [two_person_review]

    The main branch ruleset requires a pull request with at least one approving code-owner review, dismisses stale approvals on push, and requires approval of the most recent push, so every change is reviewed by someone other than its author before merge and release. Required status checks must also pass.


  • 作業ビルドシステム


    バッジには不十分です。

    プロジェクトが再現可能なビルドを持たなければなりません。ビルドが発生しない場合（たとえば、コンパイルされないでソースコードが直接使用されるスクリプト言語）、「該当なし」（N/A）を選択します。 (URLが必要です) [build_reproducible]
    再現可能なビルドは、複数の当事者がソース ファイルから情報を生成するプロセスを独立にやり直し、ビット単位でまったく同じ結果を得られることを意味します。ある場合には、これ（再現可能なビルド）は、あるソート順を強いることで解決されます。Javaスクリプトの開発者は、npm shrinkwrapとwebpack OccurenceOrderPluginの使用を検討するかもしれません。GCCとclangのユーザーは、-frandom-seedオプションが有用であることを見つけるかもしれません。ビルド環境（ツールセットを含む）は、リビルドに使用できる特定のコンテナや仮想マシンの暗号化ハッシュを指定することによって、外部パーティのために、しばしば定義可能です。再現可能なビルド プロジェクトは、これを行う方法を記載したドキュメントを有します。

    Release builds pin all inputs (Cargo.lock, go.sum, SHA-pinned actions, digest-pinned base images) and set SOURCE_DATE_EPOCH from the commit timestamp, but bit-for-bit reproducibility is not yet verified.


  • 自動テスト スイート


    バッジには十分です！

    テストスイートは、その言語の標準的な方法で呼び出すことができなければなりません。 (URLが必要です) [test_invocation]
    たとえば、「make check」、「mvn test」、「rake test」（Ruby）などです。

    cargo test (after cargo xtask build-fixtures) for the Rust workspace and go test ./... for the operator and gateway: https://github.com/wasmCloud/wasmCloud/blob/main/CONTRIBUTING.md#running-tests


    バッジには十分です！

    プロジェクトは、新しいコードまたは変更されたコードが頻繁に中央コードリポジトリに統合され、その結果に対して自動化されたテストが実行される、継続的な統合を実装しなければなりません。 (URLが必要です) [test_continuous_integration]
    ほとんどの場合、これは、プロジェクトでフルタイムで働く各開発者が少なくとも1日に1回統合作業をすることを意味します。

    Every pull request and every push to main runs the Rust, Go, component, coverage and Kubernetes end-to-end suites in GitHub Actions, and merges require the gate check to pass: https://github.com/wasmCloud/wasmCloud/actions


    バッジには不十分です。

    プロジェクトは、選択された言語でこの基準を測定できる少なくとも1つのFLOSSツールがある場合、少なくとも80％のステートメント カバレッジを提供するFLOSS自動テストスイートを備えていなければなりません。 [test_statement_coverage90]

    Coverage is measured on every push to main with cargo-llvm-cov and enforced at 80% (https://github.com/wasmCloud/wasmCloud/actions/workflows/coverage.yml); the latest run reports 83% line coverage, below 90%.


    バッジには不十分です。

    選択された言語でこの基準を測定できる少なくとも1つのFLOSSツールがあれば、少なくとも80％のブランチカバレッジを提供するFLOSS自動テストスイートがプロジェクトに存在しなければなりません。 [test_branch_coverage80]

    Coverage is measured on every push to main with cargo-llvm-cov, a FLOSS tool (https://github.com/wasmCloud/wasmCloud/actions/workflows/coverage.yml), and the job fails below 80% line and 80% region coverage (xtask/src/coverage.rs). Branch coverage is not measured yet. LLVM region coverage counts each side of a condition as its own region, so it is close to branch coverage, but it is not the same metric. We plan to enable llvm-cov branch coverage and hold it at 80%.


 セキュリティ 3/5 ●

  • 優良な暗号手法を使用する

    一部のソフトウェアは暗号化メカニズムを使用する必要がないことに注意してください。あなたのプロジェクトが作成するソフトウェアが、(1) 暗号化機能を含む、アクティブ化する、または有効化し、(2) 米国（US）から米国外または米国市民以外にリリースされる可能性がある場合は、法的に義務付けられた追加手順の実行を要求される可能性があります。通常、これにはメールの送信が含まれます。詳細については、 Understanding Open Source Technology & US Export Controls（「オープンソース技術と米国の輸出管理について」）の暗号化のセクションを参照してください。

    バッジには十分です！

    プロジェクトで作成されたソフトウェアは、ネットワーク通信すべてに対して、SSHv2以降、TLS1.2以降 (HTTPS)、IPsec、SFTP、SNMPv3などのセキュア プロトコルをサポートしなければなりません。FTP、HTTP、telnet、SSLv3以前、SSHv1などのセキュアでないプロトコルは、デフォルトで無効にしておき、ユーザーが特別に設定した亜場合のみ有効にしなければなりません。プロジェクトによって作成されたソフトウェアがネットワーク通信をサポートしない場合は、「該当なし」（N/A）を選択します。 [crypto_used_network]

    Outbound connections default to encrypted protocols: OCI registry pulls use HTTPS unless an operator explicitly sets --allow-insecure-registries (default false), outbound wasi:http requests to https:// hosts use TLS, and NATS connections support TLS (and TLS-first) with CA and client certificates. Inbound HTTP ingress supports TLS (--tls-cert-path/--tls-key-path). Plain HTTP ingress remains available for deployments where a gateway or ingress controller terminates TLS in front of the host.


    バッジには十分です！

    プロジェクトによって作成されたソフトウェアは、TLSをサポートあるいは使用する場合、少なくともTLSバージョン1.2をサポートしなければなりません。TLSの前身は、SSLと呼ばれていたことに注意して下さい。ソフトウェアがTLSを使用ない場合、「該当なし」（N/A）を選択します。 [crypto_tls12]

    All TLS in wasmCloud uses rustls 0.23 (with the aws-lc-rs provider), via rustls, tokio-rustls, hyper-rustls, reqwest's rustls-tls and oci-client's rustls-tls features (workspace Cargo.toml). rustls implements only TLS 1.2 and TLS 1.3 and has no support for SSL or TLS 1.0/1.1.


  • MITM（man-in-the-middle：中間者）攻撃に対応できる安全な配信


    バッジには不十分です。

    プロジェクトウェブサイト、リポジトリ（ウェブからアクセス可能な場合）、およびダウンロードサイト（別々の場合）には、許容できない値を持つキー強化ヘッダーが含まれていなければなりません。 (URLが必要です) [hardened_site]
    GitHubやGitLabはこれを満たしていることが知られているので注意してください。https://securityheaders.com/ のようなサイトは、これをすぐに確認することができます。重要なセキュリティ強化ヘッダーは以下の通りです。Content Security Policy (CSP)、HTTP Strict Transport Security (HSTS)、X-Content-Type-Options (「nosniff」として)、および X-Frame-Options 。Web ページからログインする機能のない完全に静的な Web サイトでは、いくつかの強化ヘッダーを省略してもリスクは少なくて済みますが、そのようなサイトを検出する信頼できる方法がないため、完全に静的なサイトであってもこれらのヘッダーが必要です。

    Required security hardening headers missing: https://wasmcloud.com: content-security-policy


  • その他のセキュリティ上の課題


    バッジには十分です！

    プロジェクトは過去5年間にセキュリティレビューを実施していなければなりません。このレビューは、セキュリティ要件とセキュリティ境界を考慮しなければならりません。 [security_review]
    これは、プロジェクトメンバーおよび/または独立した評価によって行うことができます。この評価は、静的および動的解析ツールによってサポートされることができますが、ツールが検出できない問題（特に設計上）を特定するためには、人間によるレビューが必要です。

    Per security-insights.yml: repository.security.assessments.third-party=[{"name" => "OSTIF and Trail of Bits security audit", "evidence" => "https://ostif.org/wp-content/uploads/2023/10/wasmcloud-audit-ostif-trail-of-bits-final.pdf", "date" => "2023-10-17", "comment" => "Covered wasmCloud 1.x. The 2.x host in this repository replaced the audited code."}]


    必須情報が不明、バッジに十分ではありません。

    プロジェクトによって作成されたソフトウェアで強化メカニズムを使用しなければならないので、ソフトウェア欠陥がセキュリティ上の脆弱性を引き起こす可能性が低くなります。 (URLが必要です) [hardening]
    強化メカニズムは、Content Security Policy（CSP）などのHTTPヘッダー、攻撃を緩和するコンパイラ フラグ（-fstack-protectorなど）、または未定義の動作を排除するためのコンパイラ フラグを含みます。私たちの目的のために、最低限の特権は強化メカニズムとはみなされません（最低の特権は重要ですが、別の話です）。

    wasmCloud uses several hardening mechanisms so that defects are less likely to become vulnerabilities:

    • Memory-safe languages and denied undefined behavior: the host, CLI and plugins are Rust and the operator and gateway are Go. The Rust workspace denies unsafe_code for every crate ([workspace.lints.rust] in Cargo.toml, with warnings also denied); the few exceptions are individually annotated #[allow(unsafe_code)] sites for OS FFI and environment mutation, each with a SAFETY comment.
    • Lints that eliminate crash and misuse classes: the workspace denies clippy's unwrap_used, expect_used, panic, indexing_slicing, panicking_unwrap, transmute_ptr_to_ref, transmute_undefined_repr and serde_api_misuse ([workspace.lints.clippy] in Cargo.toml), so an unexpected input yields an error instead of a panic, an out-of-bounds index, or an unsound transmute.
    • Compiler and linker hardening: Rust release binaries are built with the toolchain's default mitigations for Linux targets (position-independent executables, full RELRO, non-executable stack and data, and stack probes against stack clashing), and Go binaries get the Go runtime's bounds checking and stack guards.
    • Sandboxing of untrusted code: guest WebAssembly runs in wasmtime with bounds-checked linear memory and guard pages, structured control flow (Wasm-level control-flow integrity), Spectre mitigations on memory and table accesses, and epoch-based interruption, so a defect in guest code cannot read or write host memory.
    • Resource limits: per-workload and host-wide limits on guest memory, connections and file descriptors (crates/wash-runtime/src/engine/guest_memory.rs, crates/wash-runtime/src/host/quota.rs) keep a defect from exhausting the host.
    • Continuous checks: CodeQL, zizmor, cargo audit and cargo deny run in CI.

    警告：URLが必要ですが、URLは見つかりません。


 分析 1/2 ●

  • 動的コード分析


    バッジには不十分です。

    プロジェクトは、リリース前にプロジェクトによって作成されたソフトウェアの主要な製品リリースに対して、少なくとも1つの動的解析ツールを適用しなければなりません。 [dynamic_analysis]
    動的解析ツールは、ソフトウェアを特定の入力で実行して検査します。たとえば、プロジェクトは、ファジングツール（アメリカンファジーロップなど）やウェブ アプリケーション スキャナ（例： ZAP または w3af ）です。場合によっては、 OSS-Fuzz プロジェクトがプロジェクトにファズテストを適用する可能性があります。この基準のために、動的分析ツールは、様々な種類の問題を探すために何らかの方法で入力を変更するかまたは少なくとも80％のブランチ カバレッジを持つ自動テスト スイートである必要があります。 動的解析に関するWikipediaのページと ファジングに関するOWASPページで、いくつかの動的解析ツールを特定しています。解析ツールは、セキュリティの脆弱性を探すことに重点を置くことができますが、これは必須ではありません。

    Every release candidate passes the full automated test suites in CI (Rust unit and integration tests, component fixtures, Kubernetes end-to-end tests), with coverage measured by cargo-llvm-cov at 83% of lines and enforced at 80% of lines and regions (https://github.com/wasmCloud/wasmCloud/actions/workflows/coverage.yml). Branch coverage is not yet measured, and fuzzing is not yet part of the release process: the operator has Go native fuzz targets (e.g. runtime-operator/api/runtime/v1alpha1/workload_fuzz_test.go) whose seed corpora run with the regular tests, but they are not fuzzed before release. We plan to add a pre-release fuzzing job.


    バッジには十分です！

    プロジェクトは、生成するソフトウェアに多くの実行時アサーションを含めるべきであり、動的分析中にそれらのアサーションをチェックするべきです。 [dynamic_analysis_enable_assertions]
    この基準は、本番環境でアサーションを有効にすることを示唆するものではありません。それは完全にプロジェクトとそのユーザーが決定することです。この基準の焦点は、展開前の動的分析中の障害検出を改善することです。プロダクション環境でのアサーションの有効化は、動的分析（テストなど）中にアサーションを有効にすることとはまったく異なります。場合によっては、プロダクション環境でアサーションを有効にすることは非常に賢明ではありません（特に高整合性コンポーネントの場合）。プロダクション環境でアサーションを有効にすることには多くの議論があります。たとえば、ライブラリは呼び出し元をクラッシュさせてはなりません。ライブラリが存在するとアプリストアによる拒否が発生する可能性があります。また、プロダクション環境でアサーションをアクティブにすると、秘密鍵などの秘密データが公開される可能性があります。多くのLinuxディストリビューションではNDEBUGが定義されていないため、これらのディストリビューションのプロダクション環境ではデフォルトで C/C++ assert() が有効になります。これらの環境でのプロダクション環境では、別のアサーションメカニズムを使用するか、 NDEBUGを定義することが重要です。

    The software includes run-time assertions that are checked during testing and coverage runs, and are not relied on in production:

    • Explicit invariant assertions: debug_assert! checks guard internal invariants on the hottest and most state-heavy paths, for example call-state encoding and store-drop tracking in the invocation dispatcher (crates/wash-runtime/src/engine/dispatch.rs), and socket state in crates/wash-runtime/src/sockets/. These are compiled into test, coverage and debug builds and removed from release builds.
    • Compiler-inserted checks: the test suites and the cargo-llvm-cov coverage job (https://github.com/wasmCloud/wasmCloud/actions/workflows/coverage.yml) build with the dev profile, which enables integer-overflow checks and debug assertions in wasmCloud and its dependencies, including wasmtime's internal assertions. Array and slice bounds checks and RefCell borrow checks are always on.
    • Assertions surface as errors in production: the workspace denies clippy's unwrap_used, expect_used, panic and indexing_slicing (Cargo.toml), so invariants that can fail on real input are checked explicitly and returned as errors rather than crashing the host.
    • The test suites themselves (crates/wash-runtime/tests/, crates/wash/tests/, and the operator's Go tests) assert on behavior extensively.


ツールやAIシステムを使って、https://www.bestpractices.dev/ja/projects/6363/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)のもとで利用可能です。これは、データ受領者が、データ受領者がこの契約のテキストを共有データとともに利用可能にする限り、変更の有無にかかわらずデータを共有できることを意味します。Brooks TownsendおよびOpenSSFベストプラクティスバッジのコントリビューターにクレジットを表示してください。

プロジェクト バッジ登録の所有者： Brooks Townsend.
エントリの作成日時 2022-08-15 21:56:48 UTC、 最終更新日 2026-11-03 20:55:31 UTC 最後に2023-11-02 18:23:16 UTCにバッジ合格できませんでした。 最後に2023-11-02 18:38:53 UTCにバッジ合格を達成しました。