詳細マニュアル

マニュアル · 目次

1. 点検を依頼

点検する Web アプリのドメインと結果を受け取るメールを入力し、「点検を依頼」を押します。その依頼だけに紐づく固有トークンが発行されます。この時点ではまだ何もスキャンしません。

2. 管理権の証明（肝心な手順）

発行トークンをドメインに置いて所有を証明します。どちらか一方でかまいません。そこに置けること自体が証明です。

3. 検証後に点検を実行

「同意を確認する」を押すと、サーバーがトークンの場所を読んで検証します。verified になるとそのドメインだけが許可リストに入り、点検キューに入ります。外部点検は読み取り専用 GET のみ — インジェクション・総当たり・過負荷なし。 例外が 1 つだけあります。点検対象のバンドルに Supabase プロジェクトの URL（*.supabase.co）と anon キーがある場合、そのプロジェクトのホスト 1 か所に読み取り専用の GET を送り、RLS が有効かを確認します。バンドルがすでに呼んでいるテーブル名のみ、テーブルごとに 1 件で、行の値は読み取りも保存もしません。

4. 点検証明書を読む

点検が終わると点検証明書をメールで受け取ります。各項目の判定は三値のいずれかで（失敗は深刻度を併記）、改ざん検知可能なハッシュチェーンで残ります:

何を点検するか

安全とプライバシー

同意を証明したドメインのみ点検します。結果はあなただけに渡し、どこにも公開しません。資金・決済手段は受け取らず、寄付はウォレットへ直接です。

点検バッジ（任意）

点検が終わると、サイトに「star365 点検済み」バッジを付けられます。バッジはあなたがオンにしたときだけ表示されます — 同意ファイル（または TXT レコード）にトークンと一緒に badge=on の 1 行を書いてください。オンにしない限りバッジの URL は 404 で、点検を受けた事実すら表に出ません。実際の点検証明書があるドメインだけにバッジが出て（偽造不可）、失敗件数は公開しません。下のコードのドメインだけをご自身のものに置き換えてください:

CI でデプロイごとに点検

最初の一度だけ人が行います: 下のコマンドが同意ファイルの内容と点検証明書キーを出力します。ファイル内容（末尾の standing=on 行を含む）をサイトに置き、出力された NONCE・RECEIPT_KEY を CI のシークレットに保存してください。

あとはデプロイのパイプラインに 1 ステップ加えるだけです（GitHub Actions の例 — action.yml と star365-audit.sh をリポジトリに一緒に置きます。他の CI では bash star365-audit.sh rescan）:

- uses: ./.github/actions/star365-audit   # action.yml + star365-audit.sh
  with:
    nonce: ${{ secrets.STAR365_NONCE }}
    receipt-key: ${{ secrets.STAR365_RECEIPT_KEY }}
    fail-on: crit

終了コード: 0 合格 · 1 失敗（既定は「危険」のみ失敗、fail-on: warn なら「注意」も）· 2 判定不可（待機タイムアウト・同意なし）。同じドメインは 1 時間に 1 回までです。繰り返し点検をやめるには同意ファイルから standing=on 行を消してください — 次のリクエストから拒否されます。

トラブルシューティング

「トークンが見つかりません」と出る

ファイル URL が正確か（誤字・大文字小文字）、中身がトークンだけか確認してください。DNS の場合は反映を待ってから再度「同意を確認」を押します。

「確認不可」は失敗ですか？

いいえ。その項目を読めなかったという意味で、合格に見せかけず正直に伝えます。必要ならソース位置や SSH 内部点検で確認できます。

点検はいつ実行されますか？

同意が verified になると自動キューに入り、まもなく実行され、完了後に点検証明書をメールします。

費用

外部点検は無料です。SSH 内部点検・定期監視は範囲に応じて相談のうえ進めます。役立ったら任意の（非カストディ）寄付を歓迎します。