1. SSDLCとは何か
SSDLC（Secure Software Development Lifecycle）は、ソフトウェアの企画・設計・実装・テスト・運用のすべての段階にセキュリティを組み込む開発アプローチだ。
従来の開発では、セキュリティは「最後に付け足すもの」だった。コードを書き、機能を完成させ、リリース前にセキュリティチェックを行う。問題が見つかれば修正する。
SSDLCはこの順序を逆転させる。設計の段階から「何を守るべきか」を定義し、すべての工程でセキュリティを前提とする。セキュリティは事後対策ではなく、設計思想そのものになる。
Microsoft、Google、Appleなどの大手テクノロジー企業が採用しており、ソフトウェア業界のベストプラクティスとして定着している。
2. なぜ「コスト」として語られるのか
多くの企業にとって、SSDLCは追加コストだ。セキュリティレビューに時間がかかる。脅威モデリングに人員が必要になる。ペネトレーションテストに費用がかかる。
そして何より、セキュリティに投資しても、目に見える機能が増えるわけではない。ユーザーは「この製品はSSDLCに準拠しています」と言われても、何が変わったのか分からない。
だからこそ、多くのスタートアップはSSDLCを後回しにする。まず機能を作り、ユーザーを獲得し、セキュリティは「問題が起きてから考える」。
しかし、この判断が正当化されるのは、預かるデータが「代替可能」な場合だけだ。
3. 預かるものが変わると、セキュリティの意味が変わる
ECサイトで顧客のクレジットカード情報が漏洩したとき、カードは再発行できる。SNSのアカウントが乗っ取られたとき、アカウントは再作成できる。被害は深刻だが、「代替」が存在する。
トキストレージが預かるものは、代替できない。
- 人の声——その人が生きている間にしか録音できない
- 存在の記録——購入者のストーリー、想い、選択の理由
- 国家記録への経路——国立国会図書館の永久保存につながるパイプライン
もしこのパイプラインに脆弱性があり、データが改ざんされたら。もし誰かの声が差し替えられたら。もしニュースレターの記録が書き換えられたら。
それは「データ漏洩」ではない。その人の存在証明が汚染されるということだ。
クレジットカードは再発行できる。
声は、再録音できないかもしれない。
すでに亡くなった人の声は、絶対にできない。
4. トキストレージのSSDLC
| フェーズ | 一般的なSSDLC | トキストレージの実践 |
|---|---|---|
| 設計 | 脅威モデリング、セキュリティ要件定義 | 永続すべきデータ（音声・画像）がQRコード内に自己完結する設計。運用処理（注文・問い合わせ）にはCloudflare Workers + D1を使い、注文情報と公開する記録を区別する。攻撃対象面を最小化し、必要なアクセス制御を実施 |
| 実装 | セキュアコーディング、コードレビュー | ローカルgitで変更履歴を管理し、コードレビューと検証を実施。公開サイトで配信するコードはブラウザから確認可能 |
| テスト | 脆弱性スキャン、ペネトレーションテスト | 静的配信部分の攻撃対象面を抑え、別途API・依存関係・設定を検証する |
| デプロイ | 構成管理、アクセス制御 | MacBookからCloudflare Pagesへ直接公開。公開前に差分を確認し、公開後に動作を検証する |
| 運用 | 監視、インシデント対応 | ローカルgitに変更履歴を記録し、差分を確認する。運用データや公開環境の確認は別途必要 |
注目すべきは、トキストレージのSSDLCが「セキュリティ対策を追加する」アプローチではなく、「セキュリティリスクを構造的に減らすアーキテクチャを選択する」アプローチであることだ。
注文処理はCloudflare Workers + D1を利用する。注文情報と、長期保管のために公開・複製する記録は区別し、公開範囲は本人の選択に沿って扱う。記録の保管は物理媒体・地域分散ノード・国立国会図書館への納本を組み合わせる。コードと変更履歴はローカルのgitで管理し、静的サイトはMacBookからCloudflare Pagesへ直接公開する。静的配信でも、APIや依存関係を含むレビューと検証が必要だ。
これは「守りを固める」のではなく、「守るべき城壁を最小にする」設計哲学だ。
5. 公開範囲と検証の責任
セキュリティの検証では、何を公開し、どこまで確認できるのかを明確にする必要がある。コードの一部が閲覧できることと、システム全体の安全性が確認されたことは別である。
トキストレージは、公開する説明と実際の開発・検証手順を一致させることを重視する。
ブラウザに配信されるHTML・CSS・JavaScriptは閲覧できる。ただし、全ソースコードや内部履歴の公開を意味するものではない。公開範囲を明確にし、内部のレビューと検証にも責任を持つ。
安全性の説明には、実際に行った検証とその範囲を示す必要がある。公開コードの閲覧だけで、運用設定やAPIを含む全体の安全性が保証されるわけではない。
公開サイトを閲覧できることは、第三者監査の実施を意味しない。レビュー、テスト、公開後の確認を積み重ね、確認できた事実と未検証の範囲を区別する。
6. セキュリティは1000年のスケールで考える
一般的なSSDLCは、製品のライフサイクル（数年〜10年程度）を想定している。しかしトキストレージが目指すのは1000年の保存だ。
1000年のスケールで考えると、セキュリティの問題は変質する。
- 暗号化アルゴリズムは陳腐化する——現在の暗号が1000年後に安全である保証はない。だからトキストレージは、セキュリティを暗号に依存させず、構造で担保する
- 企業は存続しないかもしれない——だから記録を特定企業のサービスから切り離し、複数の媒体と保管先に残す
- プラットフォームは変わる——だからデータをQRコード内に完結させ、特定のプラットフォームに依存させない
これは「セキュリティ対策」の範疇を超えている。1000年後にもデータが安全であり続けるための存在論的設計だ。
7. 結び——コードの一行一行に倫理がある
セキュリティは、コストではない。倫理だ。
人の存在証明を預かるコードに脆弱性があることは、
その人の声を危険にさらすことを意味する。
SSDLCは多くの企業にとってチェックリストだ。要件を満たし、監査を通し、コンプライアンスを証明する。それは正しい。しかし、トキストレージにとってのSSDLCは違う。
預かっているのは、誰かの声だ。誰かが「自分の存在を残す価値がある」と決断した、その声だ。二度と録り直せないかもしれない声だ。すでにこの世にいない人の声かもしれない。
そのコードに脆弱性を残すことは、その人の決断を裏切ることだ。
だからセキュリティは最後に付け足すものではなく、最初に設計するものであり、コストではなく倫理であり、チェックリストではなく思想だ。
そのために、変更履歴をローカルで管理し、公開前のレビューと検証を重ねる。
倫理を、日々の開発手順で実践する。