セキュリティ保証ケース¶

この文書は httptap のセキュリティ保証ケースです。それらのセキュリティ特性が**何であるか**だけでなく、プロジェクトがそれらのセキュリティ特性が成立すると考える**理由**を説明します。OpenSSF Best Practices の silver レベルの assurance_case 基準に従って構成されています。

最終レビュー: 2026-04-13、httptap 0.5.0 について。

保証ケースは生きた文書です。すべてのメジャーリリース時、および脅威の状況や機能セットに重大な変化があるたびにレビューされます。修正の提案はこのファイルに対するプルリクエストとして受け付けます。

httptap とは¶

httptap はコマンドラインの診断ツールです。開発者は単一の URL（およびオプションでヘッダー、ボディ、プロキシ、CA バンドルなど）を指定し、httptap は 1 回の HTTP リクエスト（または短いリダイレクトチェーン）を実行して、フェーズごとのタイミングと TLS 情報を表示します。以下は**行いません**:

• 信頼できないピアからネットワーク入力を受け付ける（サーバーではありません）;
• ユーザーアカウント、セッション、または長期間有効な認証情報を管理する;
• リモートコードを実行したり、サーバーから提供されたスクリプトを評価したりする;
• オプションの --json エクスポートを超えてシークレットやユーザーデータを永続化する。

セキュリティ要件¶

プロジェクトは以下の観測可能なセキュリティ特性にコミットします。それぞれは以下のセクションの裏付けとなる論拠にマッピングされています。

信頼境界¶

   ┌─────────────────────┐
   │ CLI user            │   trusted
   │ (argv, stdin, env)  │
   └──────────┬──────────┘
              │
              ▼
   ┌─────────────────────┐
   │ httptap process     │   trusted
   │ (Python 3.10+)      │
   └──────────┬──────────┘
              │  TLS/HTTP  ◄─── untrusted: network, proxy, remote host
              ▼
   ┌─────────────────────┐
   │ Remote HTTP server  │   untrusted
   └─────────────────────┘

• ユーザー → httptap は信頼できる: ユーザーは任意のリクエストを発行する正当な理由を持っていると想定される。入力検証は、オペレーターのミスを防ぐために、不正な形式の URL、メソッド、タイムアウトなどを依然として拒否する。
• httptap → ネットワーク → リモートサーバー は信頼できない。この境界を越えるすべてのデータは攻撃者に制御されているものとして扱われる: レスポンスヘッダー、ステータスコード、Location の値、TLS 証明書、コンテンツボディ。
• ビルドパイプライン → PyPI / GitHub Releases は、GitHub OIDC（長期間有効な鍵なし）、Sigstore 署名、および SHA でピン留めされたアクションによって保護された別の信頼境界。

脅威モデル¶

脅威は、診断用 HTTP クライアントに適用される STRIDE カテゴリを用いて列挙します。クライアントの範囲外の脅威（例: サーバー側の DoS）は、非目標として明示的に除外します。

範囲外の脅威¶

• 開発者のマシン上でローカルコード実行を行う敵対者。 範囲外 — その敵対者はすでにプロセスを掌握している。
• ユーザーのターミナル / TTY を制御する敵対者。 範囲外。
• TLS 自体に対する暗号解析攻撃。 OpenSSL に委譲されている; 緩和策はシステムの Python ビルドから継承される。
• ポスト量子の脅威。 上流（OpenSSL / Python）で追跡されている; httptap 自体としては範囲外。

適用されたセキュア設計原則¶

Saltzer & Schroeder (1975) に現代的な追加を加えたものにマッピングしています。

対策された一般的な実装上の脆弱性¶

CWE Top 25 (2023) および OWASP ASVS 4.0 から導出されています。列挙されていない項目は、HTTP クライアントに該当しないか、上流で処理されるかのいずれかです。

サプライチェーンの保証¶

リリースの完全性特性（SR-5）を裏付けるもの:

• 公開: GitHub OIDC Trusted Publishing を介した PyPI（および事前本番のスモークテストとしての TestPyPI）— 長期間有効な PyPI トークンはどこにも存在しない。PEP 740 の証明書は PyPI 上で「Verified publisher」として表示される。
• コンテナイメージ: マルチアーキテクチャ（linux/amd64、linux/arm64）のイメージが Buildx でビルドされ、GHCR にプッシュされ、cosign で鍵なしで署名され、レジストリに添付された SLSA ビルドプロベナンスを伴う。
• Git 署名: リリースコミットと注釈付きタグは、リリースワークフローの OIDC アイデンティティを使用して gitsign（Fulcio による x.509 + Rekor 透明性ログ）で鍵なしで署名される。
• 署名: actions/attest-build-provenance と cosign を通じた Sigstore の鍵なし署名。署名鍵は短命であり、実行ごとに Fulcio によって発行され、Rekor 透明性ログを介して検証可能である。
• プロベナンス: SLSA v1.0 の証明書がすべての wheel、sdist、およびコンテナイメージのダイジェストに付随する。
• Dockerfile のリンティング: hadolint がすべての PR で警告レベルの失敗しきい値とともに実行される。
• ピン留め: すべてのワークフローのすべての GitHub Action は SHA でピン留めされる; Scorecard Pinned-Dependencies と zizmor pedantic によってすべての PR で強制される。
• 依存関係の追跡: CycloneDX および SPDX 形式の SBOM がリリース中に生成され、GitHub Release のアセットとして添付される。
• 悪用可能性の開示: OpenVEX 文書（httptap-X.Y.Z.openvex.json）が SBOM とともに配布され、各依存関係の CVE について httptap が実際に影響を受けるかどうかを宣言する。信頼できる情報源は .vex/httptap.openvex.json にバージョン管理されている; VEX を利用するスキャナー（Grype、Trivy、Snyk）はこれを使用して、到達不可能な脆弱なコードパスに対する誤検知アラートを抑制する。

ユーザーはダウンロードした成果物を独立して検証できます:

gh attestation verify dist/httptap-X.Y.Z-py3-none-any.whl \
  --repo ozeranskii/httptap

既知の残存リスク¶

これらは緩和されるのではなく文書化されています。それらは、見落としではなく明示的なトレードオフを表しています。

• 単独のメンテナー。 バス係数は 1 である（GOVERNANCE.md で追跡）。継続性計画は運用における単一障害点を緩和するが、コードレビューについては緩和しない: 単一のレビュアーが第二の目なしに変更をマージできる。pre-commit、CI ゲート、および公開監査証跡が部分的に補償する。
• ランタイムのサンドボックス化なし。 httptap はユーザーの完全な権限で実行される。これは開発者の診断ツールとしては適切であるが、httptap 自体のバグがユーザーの権限で実行されることを意味する。
• OS から継承された TLS トラストアンカー。 OS のトラストストアが侵害された場合（例: 企業の MITM プロキシが private CA をインストールする）、httptap はこれを検出できない。JSON エクスポートの network.tls_custom_ca および proxy_source フィールドは、カスタム CA バンドルまたはプロキシが使用されていたかどうかを記録する。

変更履歴¶

参考文献¶

• SECURITY.md — 脆弱性報告のプロセスとサポートされるバージョン。
• GOVERNANCE.md — プロジェクトの役割、決定、および継続性計画。
• ROADMAP.md — 範囲、非目標、および廃止ポリシー。
• トラブルシューティング & FAQ — 運用上のガイダンス。
• CWE Top 25 および OWASP ASVS 4.0 — 実装上の脆弱性のリファレンスカタログ。