このガイドは、Solana上でプログラムの検証済みビルドを実装したい開発者向けのリファレンスです。検証済みビルドとは何か、その使用方法、特別な考慮事項、およびオンチェーンでのプログラムの信頼性を確保するためのベストプラクティスについて説明します。

検証済みビルドとは何ですか？

検証済みビルドは、Solanaネットワークにデプロイする実行可能なプログラムが、リポジトリ内のソースコードと一致することを保証します。これにより、開発者とユーザーは、オンチェーンで実行されているプログラムが公開されているコードベースと完全に一致していることを確信でき、透明性とセキュリティを促進します。

検証プロセスでは、オンチェーンプログラムのハッシュとソースコードからローカルでビルドされたプログラムのハッシュを比較します。これにより、2つのバージョン間に相違がないことが保証されます。

検証済みビルドは未検証のビルドよりも安全であるとは限りませんが、ビルドによって開発者はソースコードがオンチェーンにデプロイされたものと一致することを自己検証できます。ソースコードを使用して、開発者はトランザクションを送信する際にコードが実行する内容を検証できます。

検証済みビルドのパイプラインはEllipsis LabsとOtterSecによって考案され、維持されています。詳細については、オリジナルの検証済みビルドリポジトリのガイドに従い、また検証ビルドプロセスをAnzaツールスイートに直接組み込んでください（サポートされた場合）。

どのように機能しますか？

検証プロセスは、オンチェーンプログラムのハッシュとソースコードからローカルでビルドされたプログラムのハッシュを比較することで行われます。Solana Verify CLIとDockerを使用して、制御された環境でプログラムをビルドします。これにより、ビルドプロセスが決定論的になり、異なるシステム間で一貫性が保たれます。実行可能ファイルができたら、Solanaネットワークにデプロイできます。ビルドプロセス中にverify programのPDAが作成されます。このPDAにはプログラムを検証するために必要なすべてのデータが含まれています。PDAにはプログラムアドレス、gitのURL、コミットハッシュ、およびプログラムをビルドするために使用された引数が含まれています。

PDAのデータを使用して、誰でもローカルで検証プログラムコマンドを実行し、プログラムが提供されたソースコードからビルドされたかどうかを確認できます。その後、完全に信頼性を確保しながら自分自身で検証したり、OtterSecが維持している独自のverify APIを実行して、ユーザーが検証を簡単に確認できるアクセスポイントを提供することができます。これらのAPIコールは、Solana ExplorerやSolanaFMなど、さまざまな場所ですでに使用されています。

検証済みビルドを使用する理由

検証済みビルドを使用すると、以下のメリットがあります：

• セキュリティ：オンチェーンで実行されているプログラムがソースコードと一致することを保証し、悪意のある改変を防止します。

• 透明性：他のユーザーや開発者が、オンチェーンプログラムを公開コードベースと比較することで、信頼性を検証できるようにします。

• 信頼：検証済みビルドはプログラムのオンチェーン動作が公開コードと一致していることを示すため、ユーザーの信頼を高めます。検証可能なプログラムを構築することで、不正または悪意のあるコードの実行に関連するリスクを最小限に抑えることができます。また、ベストプラクティスに準拠し、セキュリティ研究者が簡単に連絡できる方法を提供することも保証します。さらに、ウォレットやその他のツールは、プログラムが検証されている限り、そのプログラムからのトランザクションをより簡単に許可することができます。

• 発見可能性：プログラムの検証済みビルドを提供すると、誰でもソースコード、ドキュメント、プログラムSDKまたはIDLを見つけることができ、問題がある場合はGitHubを通じて簡単に連絡を取ることができます。

検証済みビルドを作成するにはどうすればよいですか？

検証済みビルドを作成するには、次の手順に従う必要があります：

概要：

• コードを公開リポジトリにコミットする
• Dockerで検証済みビルドを構築する
• 検証済みビルドをデプロイする
• デプロイされたプログラムを公開APIに対して検証する

Dockerコンテナ内で構築されていないプログラムを検証しようとすると、Solanaプログラムのビルドは異なるシステム間で決定論的ではないため、ほとんどの場合失敗します。

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

cargo install solana-verify

cargo install solana-verify --version $VERSION

cargo install solana-verify --git https://github.com/Ellipsis-Labs/solana-verifiable-build --rev 13a1db2

[workspace]
members = ["program/programs/*"]
resolver = "2"

[profile.release]
overflow-checks = true
lto = "fat"
codegen-units = 1

[profile.release.build-override]
opt-level = 3
incremental = false
codegen-units = 1

[package]
name = "waffle"
version = "0.1.0"
edition = "2021"

[lib]
name = "waffle"
crate-type = ["cdylib", "lib"]

[dependencies]
solana-program = "2.1.0"

solana-verify build

solana-verify build --library-name $PROGRAM_LIB_NAME

solana-verify get-executable-hash target/deploy/$PROGRAM_LIB_NAME.so

solana program deploy -u $NETWORK_URL target/deploy/$PROGRAM_LIB_NAME.so --program-id $PROGRAM_ID --with-compute-unit-price 50000 --max-sign-attempts 100 --use-rpc

solana-verify get-program-hash -u $NETWORK_URL $PROGRAM_ID

solana-verify verify-from-repo -u $NETWORK_URL --program-id $PROGRAM_ID https://github.com/$REPO_PATH --commit-hash $COMMIT_HASH --library-name $PROGRAM_LIB_NAME --mount-path $MOUNT_PATH

solana-verify remote submit-job --program-id <program-id> --uploader <address>

solana-verify remote get-job --job-id <job-id>

Squadsのようなマルチシグによって管理されているプログラムを検証する方法

リモート検証を機能させるには、プログラム権限者が署名したPDAに検証データを書き込む必要があります。プログラムがマルチシグによって管理されている場合は、このPDA書き込みトランザクションをエクスポートし、Squads Protocolまたは他のマルチシグソリューションを通じて送信できます。

solana-verify build

solana config set --url "PayedMainnetRPCAddress" // the public endpoint will be rate limited too much
solana program deploy target/deploy/verify_squads.so

solana-verify verify-from-repo https://github.com/solana-developers/verify-squads --program-id 6XBGfP17P3KQAKoJb2s5M5fR4aFTXzPeuC1af2GYkvhD

solana-verify export-pda-tx https://github.com/solana-developers/verify-squads --program-id 6XBGfP17P3KQAKoJb2s5M5fR4aFTXzPeuC1af2GYkvhD --uploader <your program authority> --encoding base58 --compute-unit-price 0

P6vBfcPaaXb8fZoT3NBAYEcdtEj7tubA1k2gBxmFKZ3UWF5YyrmDMFTvLKALCJoUuRsPAjMckudYruCu3eeWQtuDrFbEMLxLFutnKXac974fnkMivcwUdY66VLjbxQT6ATmcy7F4hBtz1G4P1h6iBJLhb8WtrtgY3i4qq45MUEb7RjuMEfUFXKrNgPdGxkz5xvMHq3dxKRcpmEK5k2DkeW6SUQYBVe19Ga3B9GyhTX8k3CMt9JCEah13WyRnQd8GjoK6sTEvGJym6xDNvmd8yiJYSNcaYwEJsjHEUf4Yh6kAC7ki2KRvVAr3NVe1gjqK9McrwSQjtUatvydTG8Zovcr7PPUEMf3yPMgKXjZLB2QpkH63yTTYdNAnWFuv9E6b6nYRqye5XcNi436yKw5U14fXh65yK34bgYLi9328UT1huJELsJU9BRGnGUmb6GWp6c2WL5BhnzgNTSnt9TXFfEgUMzhvKzpVBxLP44hwqqBdyUhHFysCF37531PnmiESq8x1xou23xJ6FcQbc199754MkqQd7tX9CUznGzAEqHGkzn3VBoJnojsKtgYmiTYbdRsT1CU18MbYEE7WvGAvXyxxbpNzbAcc94HrnM6cqRGmwhEBroPfFghTdmzg9D

solana-verify remote submit-job --program-id 6XBGfP17P3KQAKoJb2s5M5fR4aFTXzPeuC1af2GYkvhD
--uploader <your program authority>

solana-verify build
solana program write-buffer target/deploy/verify_squads.so --with-compute-unit-price 50000 --max-sign-attempts 50

solana program set-buffer-authority Fu3k79g53ZozAj47uq1tXrFy4QbQYh7y745DDsxjtyLR --new-buffer-authority 3JG6ULvZVCrkKtSSskKNJGe8RNZGFe8Ruev9KUhxzK5K

solana-verify export-pda-tx https://github.com/solana-developers/verify-squads --program-id 6XBGfP17P3KQAKoJb2s5M5fR4aFTXzPeuC1af2GYkvhD --uploader 3JG6ULvZVCrkKtSSskKNJGe8RNZGFe8Ruev9KUhxzK5K

solana-verify remote submit-job --program-id 6XBGfP17P3KQAKoJb2s5M5fR4aFTXzPeuC1af2GYkvhD --uploader 3JG6ULvZVCrkKtSSskKNJGe8RNZGFe8Ruev9KUhxzK5K

Verification request sent with request id: b63339d2-163e-49ac-b55d-3454c1c2b5b3
Verification in progress... ⏳ [00:18:02] ✅ Process completed. (Done in 18
minutes) Program 6XBGfP17P3KQAKoJb2s5M5fR4aFTXzPeuC1af2GYkvhD has been verified.
✅ The provided GitHub build matches the onchain hash. On Chain Hash:
96f8c3d9400258f7759408d1f6f8435b4a24d9b52f5a0340d97907e567cb8773 Executable
Hash: 96f8c3d9400258f7759408d1f6f8435b4a24d9b52f5a0340d97907e567cb8773 Repo URL:
https://github.com/Woody4618/verify-squads/tree/0fb0a2e30c15c51732c0ad5e837975a6f7bbc7ed
Check the verification status at:
https://verify.osec.io/status/6XBGfP17P3KQAKoJb2s5M5fR4aFTXzPeuC1af2GYkvhD Job
url: https://verify.osec.io/job/b63339d2-163e-49ac-b55d-3454c1c2b5b3

Dockerイメージによる検証

以下のコマンドを実行することで、Dockerイメージに対してプログラムを検証することもできます：

solana-verify verify-from-image -e
examples/hello_world/target/deploy/hello_world.so -i
ellipsislabs/hello_world_verifiable_build:latest -p
2ZrriTQSVekoj414Ynysd48jyn4AX6ZF4TTJRqHfbJfn

このコマンドはellipsislabs/hello_world_verifiable_build:latestに保存されたイメージを読み込み、コンテナ内の実行ファイルパスのハッシュが、コマンドに指定されたオンチェーンプログラムのハッシュと一致することを検証します。ビルドはすでにイメージにアップロードされているため、長時間かかる実行ファイルの完全な再ビルドは不要です。

ellipsislabs/hello_world_verifiable_build:latestイメージを作成するDockerfileは、Ellipsis Labsリポジトリの/examples/hello_worldにあります。

以下が期待される出力です：

Verifying image: "ellipsislabs/hello_world_verifiable_build:latest", on network
"https://api.mainnet.solana.com" against program ID
2ZrriTQSVekoj414Ynysd48jyn4AX6ZF4TTJRqHfbJfn Executable path in container:
"examples/hello_world/target/deploy/hello_world.so"

Executable hash:
08d91368d349c2b56c712422f6d274a1e8f1946ff2ecd1dc3efc3ebace52a760 Program hash:
08d91368d349c2b56c712422f6d274a1e8f1946ff2ecd1dc3efc3ebace52a760 Executable
matches onchain program data ✅

検証済みビルドの例

以下は、このリポジトリのソースコードを使用して、ID FWEYpBAf9WsemQiNbAewhyESfR38GBBHLrCaU3MpEKWv を持つプログラムを検証する例です リポジトリ：

solana-verify verify-from-repo https://github.com/solana-developers/verified-program --url YOUR-RPC-URL --program-id FWEYpBAf9WsemQiNbAewhyESfR38GBBHLrCaU3MpEKWv --mount-path waffle --library-name waffle --commit-hash 5b82b86f02afbde330dff3e1847bed2d42069f4e

デフォルトでは、verify-from-repo コマンドはメインブランチの最後のコミットを使用します。リポジトリの作業を継続したい場合は、commit-hash パラメータを使用して特定のコミットを指定することもできます： --commit-hash 5b82b86f02afbde330dff3e1847bed2d42069f4e

プロンプトが表示されたら、検証PDAをオンチェーンにアップロードするためにはいと答えてください。その後、OtterSec APIに対してリモート検証ジョブを送信します：

solana-verify remote submit-job --program-id FWEYpBAf9WsemQiNbAewhyESfR38GBBHLrCaU3MpEKWv --uploader <your-upgrade-authority>

すでに検証済みの主要プログラム

Phoenix

solana-verify verify-from-repo -um --program-id PhoeNiXZ8ByJGLkxNfZRnkUfjvmuYqLR89jjFHGqdXY https://github.com/Ellipsis-Labs/phoenix-v1

最終出力：

Executable Program Hash from repo: 6877a5b732b3494b828a324ec846d526d962223959534dbaf4209e0da3b2d6a9
Onchain Program Hash: 6877a5b732b3494b828a324ec846d526d962223959534dbaf4209e0da3b2d6a9
Program hash matches ✅

Squads V3

solana-verify verify-from-repo https://github.com/Squads-Protocol/squads-mpl --commit-hash c95b7673d616c377a349ca424261872dfcf8b19d --program-id SMPLecH534NA9acpos4G6x7uf3LWbCAwZQE9e8ZekMu -um --library-name squads_mpl --bpf

Squads リポジトリには複数のプログラムが含まれているため、library-name を指定する必要があったことに注意してください。squads_mpl は以前 Anchor で検証されていたため、--bpf フラグを使用しています。

最終出力：

Executable Program Hash from repo: 72da599d9ee14b2a03a23ccfa6f06d53eea4a00825ad2191929cbd78fb69205c
Onchain Program Hash: 72da599d9ee14b2a03a23ccfa6f06d53eea4a00825ad2191929cbd78fb69205c
Program hash matches ✅

Drift V2

solana-verify verify-from-repo -um --program-id dRiftyHA39MWEi3m9aunc5MzRF1JYuBsbn6VPcn33UH https://github.com/drift-labs/protocol-v2 --commit-hash 110d3ff4f8ba07c178d69f9bfc7b30194fac56d6 --library-name drift

最終出力：

Executable Program Hash from repo: e31d58edeabc3c30bf6f2aa60bfaa5e492b41ec203e9006404b463e5adee5828
Onchain Program Hash: e31d58edeabc3c30bf6f2aa60bfaa5e492b41ec203e9006404b463e5adee5828
Program hash matches ✅

Marginfi V2

solana-verify verify-from-repo -um --program-id MFv2hWf31Z9kbCa1snEPYctwafyhdvnV7FZnsebVacA https://github.com/mrgnlabs/marginfi-v2 --commit-hash d33e649e415c354cc2a1e3c49131725552d69ba0 --library-name marginfi -- --features mainnet-beta

最終出力：

Executable Program Hash from repo: 890d68f48f96991016222b1fcbc2cc81b8ef2dcbf280c44fe378c523c108fad5
Onchain Program Hash: 890d68f48f96991016222b1fcbc2cc81b8ef2dcbf280c44fe378c523c108fad5
Program hash matches ✅

よくある質問

検証が失敗します。どうすればよいですか？

以下のよくある問題を確認してください：

• 署名者が正しくない: solana program show YourProgramId を実行して、署名者がプログラムのアップグレード権限であることを確認してください
• オンチェーンPDAが存在しない: solana-verify verify-from-repo -um を実行し、プロンプトが表示されたらYESを選択してください。PDAをアップロードしないと、APIが検証メタデータを取得できません。
• PDAデータの不一致: プログラムを再デプロイした場合はPDAを更新してください。PDAのデータはデプロイ済みプログラムと一致している必要があります。
• コミットハッシュが正しくない: デプロイ時に使用した正確なコミットハッシュを使用してPDAを作成してください
• ビルド環境の差異: PDAを作成する際は、solana-verifyを使用してDockerで行ってください

ローカルのビルドハッシュがオンチェーンのハッシュと一致しません。なぜですか？

これは通常、以下のことを意味します：

• 異なるバージョンのRust/Solanaツールチェーンを使用している
• ビルド間で依存関係が更新された
• Dockerコンテナ内でビルドしていなかった
• 誤ったコミットをチェックアウトした

Dockerで solana-verify build を使用し、デプロイ時の正確なコミットでビルドすることで解決できます。

検証にはどのくらい時間がかかりますか？

プログラムのサイズに応じた目安の所要時間は以下のとおりです：

• シンプルなプログラム：1〜5分
• 複雑なプログラム：5〜15分
• 非常に大きなプログラム：最大30分

ジョブステータスエンドポイントを使用して進捗を確認してください。

プログラムがイミュータブル（アップグレード権限なし）です。どうやって検証できますか？

プログラムにアップグレード権限がない、またはPDAを作成する前にイミュータブルにされた場合は、このような状況のためにホワイトリストに登録されたアドレスをご用意しています。contact@osec.io までご連絡いただければ、プログラムの検証をサポートします。

PDAとは何ですか？なぜ重要なのですか？

あなたのPDA（Program Derived Account）により、トラストレスな検証が可能になります：

• オンチェーンストレージ: 検証メタデータ（リポジトリURL、コミットハッシュ、ビルドパラメータ）を、Otter VerifyプログラムのPDA（verifycLy8mB96wd9wqq3WDXQwM4oU6r42Th37Db9fC）が所有するオンチェーンに保存します
• 暗号学的リンク: あなたのPDAはプログラムアドレスから派生しており、検証データへの不変のリンクを作成します
• 分散型トラスト: 誰でもあなたのPDAを読み取り、プログラムを独立して検証できます

APIを使用する前にPDAを作成しなければならないのはなぜですか？

APIがオンチェーンPDAのみで機能する理由：

• トラストレス: APIは任意のデータを拒否し、アップグレード権限者がオンチェーンに保存したデータのみを使用します
• シンプル: 署名者とprogram_idを指定するだけで、APIがPDAから残りの情報をすべて取得します
• 改ざん防止: あなたのPDAは誰でも独立して検証できる不変のレコードを作成します
• 所有権の証明: 署名者はアップグレード権限者である必要があり、プログラムを管理していることを暗号学的に証明します

プログラムの検証はどのくらいの頻度で行うべきですか？

以下のタイミングでプログラムを検証してください：

• デプロイまたはアップグレードのたびに
• ソースリポジトリを更新したとき
• それ以外の再検証は不要です — APIが24時間ごとにすべてのプログラムを自動的に再検証します

プログラムをアップグレードするとどうなりますか？

アップグレード後に以下の手順を実行してください：

1. APIがアップグレードを検出し、プログラムの検証を解除します。
2. 新しい検証メタデータでPDAを更新します：

solana-verify verify-from-repo -um \
  --program-id YourProgramId... \
  https://github.com/your-org/your-program

3. アップグレード権限を使用して新しい検証リクエストを送信します
4. APIが更新されたPDAに対して新しいバージョンを検証します

重要: アップグレードされたプログラムの新しいコミットハッシュを使用して、必ずアップグレード権限でPDAを更新してください。

検証結果は信頼できますか？

はい。このシステムはトラストレスで、独立した検証が可能な設計になっています：

信頼できる理由：

• オンチェーンPDA：検証メタデータはオンチェーンに保存され、中央機関による管理は一切ありません
• アップグレード権限の証明：PDAの作成・更新は、プログラムのアップグレード権限を持つ者のみが行えます
• 独立した検証：PDAを読み取り、solana-verifyをローカルで実行することで、誰でも検証できます
• 継続的な再検証：APIはすべてのプログラムを24時間ごとに自動的に再検証します

以下の制限事項をご理解ください：

• 検証はソースコードとデプロイ内容が一致することを確認するものであり、コードが安全であることを保証するものではありません
• プログラムを操作する前に、必ずコードをレビューしてください
• 検証済み ≠ 監査済み、または安全
• PDA内のリポジトリとコミットを確認し、信頼できるソースからのものであることを確かめてください

プログラムを独自に検証するにはどうすればよいですか？

オンチェーンPDAを読み取り、ローカルで検証を実行することで、任意のプログラムを自分で検証できます：

ステップ1：オンチェーンPDAを読み取る

# Install solana-verify if you haven't
cargo install solana-verify

# Get the PDA data
solana-verify list-program-pdas --program-id YourProgramId...

ステップ2：ローカルで検証する

# Verify using the repository and commit & other arguments from the PDA
solana-verify verify-from-repo \
  --program-id YourProgramId... \
  https://github.com/your-org/your-program
  --commit-hash <commit-hash>
  ... (other arguments from the PDA)
# Confirm the hash output matches the onchain program hash

これにより以下が証明されます：

1. PDAメタデータが正真正銘のものであること（オンチェーンに保存）
2. PDAのリポジトリ内のソースコードがデプロイ済みプログラムと一致すること
3. APIを信頼する必要はなく、すべてオンチェーンで自分自身が検証できること

他の人が許可なく自分のプログラムを検証できますか？

はい、これが署名者をアップグレード権限者とする必要がある理由です。署名者がアップグレード権限者である場合にのみ、検証が有効であるとみなされます。

検証可能なビルドを作成するには何が必要ですか？

以下のツールをインストールしてください：

• Docker（決定論的ビルド用）
• Cargo（Rustパッケージマネージャー）
• Solana Verify CLI：cargo install solana-verify
• ソースコードを含む公開Gitリポジトリ

プライベートリポジトリを検証できますか？

いいえ。検証にはソースコードの公開が必要です：

• PDAには誰でもアクセスできる公開リポジトリのURLが保存されています
• トラストレスな検証は、コードが公開されていることを前提としています
• ユーザーがプログラムの動作を理解するには、ソースコードを読む必要があります
• この仕組みの目的は、ソースコードとデプロイ内容が一致することをユーザーが独自に検証できるようにすることです

プライベートリポジトリは、検証システムの根幹となる信頼モデルを損ないます。

Squads Multisigで管理されているプログラムを検証するには？

マルチシグ管理プログラムの検証手順：

# 1. Build and deploy normally
solana-verify build
solana program deploy <your-program.so> --program-id YourProgramId...

# 2. Verify locally first - confirm the hash matches
solana-verify verify-from-repo -um \
  --program-id YourProgramId... \
  https://github.com/your-org/your-program

# 3. Export the PDA creation transaction
solana-verify export-pda-tx \
  --program-id YourProgramId... \
  https://github.com/your-org/your-program

# 4. Execute the PDA transaction through your Squads Multisig interface

# 5. After multisig execution, trigger remote verification
solana-verify remote submit-job \
  --program-id YourProgramId... \
  --uploader YourMultisigAddress...

重要：PDAトランザクションをエクスポートする前に、必ずローカルで検証（手順2）を行い、ビルドハッシュが一致することを確認してください。

まとめ

Solanaの検証済みビルドを活用することで、ネットワーク上のプログラムの整合性と信頼性を確保し、開発者がSolana Explorerから直接SDKを見つけられるようになります。Solana Verify CLIやDockerなどのツールを活用することで、ソースコードと一致した検証可能かつ安全なビルドを維持できます。一貫した環境の使用に十分注意を払い、安全なアップグレードとデプロイのためにガバナンスソリューションの導入を検討してください。

セキュリティと免責事項

検証済みビルドはSolanaプログラムの整合性を保証する強力なツールですが、デフォルトの設定では完全にトラストレスではありません。Dockerイメージは、Solana Foundationによってビルドおよびホストされています。

ダウンロードしたDockerイメージ内でプロジェクトをビルドすることになるため、機密情報を含む可能性のあるセットアップ全体がビルド用のDockerイメージにコピーされる点にご注意ください。

完全にトラストレスな環境を構築したい場合は、Dockerイメージを自分でビルドし、独自のインフラ上でホストすることができます。これにより、Dockerイメージが改ざんされていないことを確実に確認できます。独自のDockerイメージを作成するためのスクリプトは、Verified buildsリポジトリで公開されており、フォークしてGitHub Actionsを自分で実行したり、その内容が正しいことを検証したりすることができます。

さらに、リモート検証においては、OtterSec APIおよび Solana Explorer をある程度信頼することになります。

APIまたはSolana Explorerが侵害された場合、誤った情報が表示される可能性があります。

完全にトラストレスな環境を構築したい場合は、 Verify APIを自身で実行するか、またはオンチェーンの検証データを使用してverify-from-repoコマンドによりプログラム検証をローカルで実行することができます。オンチェーンの検証データは、プログラムのデプロイ権限と verify programから導出された PDA に保存されています。

verify programはOtterSecチームによってデプロイされており、まだフリーズされていないため、いつでもアップグレードが可能です。

Solana Foundation、OtterSec、およびEllipsis Labsチームは、検証済みビルドパイプラインの使用によって生じる損失や損害について一切の責任を負いません。

SolanaプログラムのSecurity.txt

検証済みビルドに加えて、プログラムにsecurity.txtファイルを追加することもできます。将来的に実装された際には、security.txtには検証PDAに保存された検証データへの簡単なアクセスのために、検証者のpubkeyが保持される予定です。プログラムのビルドと検証に必要なすべての情報を含むPDAは、プログラムのアドレスと検証者のpubkeyから導出されます。デフォルトでは、これはプログラムをビルドしてデプロイしたのと同じpubkeyですが、security.txtで別のpubkeyを指定することもできます。

security.txt機能により、開発者はSolanaスマートコントラクト内に連絡先およびセキュリティ情報を直接埋め込むことができます。securitytxt.orgにインスパイアされたこのアプローチは、コントラクトのアドレスしか知らない場合でも、セキュリティ研究者がプロジェクトのメンテナーに連絡できる標準化された方法を提供します。

security.txtを使用する理由

多くのプロジェクト、特に小規模なプロジェクトやプライベートなプロジェクトでは、コントラクトアドレスだけから開発者を特定することは難しく、時間がかかります。security.txtファイルをプログラムに埋め込むことで、セキュリティ研究者が適切な担当者に簡単に連絡できるようになり、エクスプロイトの防止やバグレポートの迅速な対応が期待できます。

security.txtの実装方法

Solanaプログラムにsecurity.txtを追加するには、以下の手順に従ってください。

Cargo.tomlにsolana-security-txt依存関係を追加します。

[dependencies]
solana-security-txt = "1.1.1"

コントラクト内でsecurity_txt!マクロを使用して、セキュリティ情報を定義します。連絡先、プロジェクトのURL、セキュリティポリシーなどを含めることができます。以下に例を示します。

#[cfg(not(feature = "no-entrypoint"))]
use {default_env::default_env, solana_security_txt::security_txt};

#[cfg(not(feature = "no-entrypoint"))]
security_txt! {
    name: "MyProject",
    project_url: "https://myproject.com",
    contacts: "email:security@myproject.com,discord:security#1234",
    policy: "https://myproject.com/security-policy",

    // Optional Fields
    preferred_languages: "en,de",
    source_code: "https://github.com/solana-developers/solana-game-preset",
    source_revision: "5vJwnLeyjV8uNJSp1zn7VLW8GwiQbcsQbGaVSwRmkE4r",
    source_release: "",
    encryption: "",
    auditors: "Verifier pubkey: 5vJwnLeyjV8uNJSp1zn7VLW8GwiQbcsQbGaVSwRmkE4r",
    acknowledgements: "Thank you to our bug bounty hunters!"
}

security.txt情報をプログラムに埋め込むと、Solana Explorerなどのツールを通じて簡単に照会できるようになり、潜在的な問題を報告しようとする人々が連絡先やセキュリティの詳細にアクセスできます。

ベストプラクティス

• リンクの活用：変更される可能性のある情報（例：連絡先）は、コントラクトにハードコードするのではなく、Webページへのリンクを使用することを推奨します。これにより、頻繁なプログラムのアップグレードを避けることができます。

• 検証：デプロイ前に、query-security-txtツールを使用してフォーマットと内容を検証してください。このツールはオンチェーンプログラムとローカルバイナリの両方を検証できます。

query-security-txt target/bpfel-unknown-unknown/release/my_contract.so

セキュリティの連絡先情報をコントラクトに直接埋め込むことで、研究者があなたに連絡しやすくなり、Solanaエコシステム内のセキュリティとコミュニケーションの向上に貢献します。

これはSolana ExplorerでのSecurity.txtの表示例です。

security.txtプロジェクトはNeodyme Labsによってメンテナンスされています。

検証ステータスを確認し、検証済みプログラムを参照するにはverify.osec.ioをご覧ください。