5-1. 準拠する法令・規約

個人情報保護法、GDPR、PCI DSS等のうち、どれに準拠するかを明示する。日本国内ユーザー向けサービスであれば個人情報保護法が、EU圏ユーザーが含まれる場合はGDPRが対象になる。プロジェクト開始時に確認・明記しておかないと、リリース直前に「この機能、法的にアウトでは？」と気づき、大規模な改修を余儀なくされる。

法令・規約対象主な義務違反リスク
個人情報保護法日本国内のユーザーデータ利用目的の明示・安全管理措置・第三者提供の制限行政指導・課徴金・社会的信用の失墜
GDPREUユーザーのデータ同意取得・削除権・データポータビリティ・DPO指名年間売上の4%または2,000万ユーロの高い方
PCI DSSクレジットカード情報を扱う場合カード番号の非保持化・暗号化・ログ管理カードブランドとの契約解除・損害賠償
電子帳簿保存法電子取引・電子帳票を扱う場合電子データの改ざん防止・検索要件青色申告の取消・加算税

⚠️ 定義しないと…

リリース直前に「この機能、法的にアウトでは？」と気づき、大規模な改修や最悪リリース中止に追い込まれる。準拠義務を把握していないと、罰則・損害賠償リスクにもなる。

法令への準拠はエンジニアだけが考えることではない。どの法令が適用されるかをプロジェクト開始時にビジネス側・法務と合意しておき、「どのデータを・どこに・どのように保存してよいか」の方針を技術実装前に固めることが重要だ。特にGDPRは「EUに住んでいるユーザーがいれば適用される」ため、グローバル展開を視野に入れたサービスは早期に対応方針を固める必要がある。

✅ 最低限やっておくこと

① どの法令が適用されるかを書き出す。② プライバシーポリシーにデータの利用目的・保持期間・第三者提供の有無を明記する。③ ユーザーが自身のデータを削除・エクスポートできる機能の要否を確認する。

5-2. 脆弱性発見時の対応フロー

脆弱性を発見したら誰に報告し、どのタイムラインで修正・公開するかを定義する。フローを事前に決めておかないと、脆弱性が発見されたときに「誰が対応すべきか」「何を優先するか」で混乱し、対応が遅延する。その間にユーザーデータが危険にさらされ続けるリスクがある。

ℹ️ 標準的な対応フロー

① 発見 → ② セキュリティ担当者へ即時報告（24時間以内） → ③ 影響範囲の特定 → ④ 修正・テスト → ⑤ 本番適用 → ⑥ ユーザーへの通知（必要な場合） → ⑦ 事後分析

脆弱性の深刻度に応じて対応速度の目安を定めておくと、現場での判断がしやすくなる。

深刻度CVSS スコア目安対応期限の例代表的なケース
Critical9.0 〜 10.024時間以内に修正・適用認証バイパス・RCE・SQLインジェクション
High7.0 〜 8.972時間以内権限昇格・機密データの漏洩リスク
Medium4.0 〜 6.92週間以内XSS（非永続型）・情報漏洩の軽度リスク
Low0.1 〜 3.9次回リリース情報開示の軽微なリスク

⚠️ 定義しないと…

脆弱性が発見されても「誰が対応すべきか」で混乱し、対応が遅れる。その間にユーザーデータが危険にさらされ続ける。

外部からの脆弱性報告（セキュリティリサーチャーや善意のユーザーからの連絡）に備えて、責任ある開示（Responsible Disclosure） のポリシーも定めておくとよい。サービスのセキュリティページや security.txt ファイル（/.well-known/security.txt）に連絡先を記載することで、報告を受け取りやすくなる。

5-3. 依存ライブラリの管理方針

セキュリティアップデートの適用ルールと、定期チェックの頻度を定義する。現代のWebアプリケーションは数百〜数千の外部ライブラリに依存しており、それらのライブラリに脆弱性が発見されることは珍しくない。自分が書いたコードは安全でも、依存ライブラリが脆弱性の入り口になるケースは多い。

⚠️ 定義しないと…

既知の脆弱性を持つライブラリが放置され、攻撃の踏み台になる。「誰かがやるだろう」で誰もやらない状態が続く。

✅ 実践的なアプローチ

npm audit / pip-audit / Dependabot 等のツールを CI に組み込み、自動的に脆弱性を検出する仕組みを作る。月1回の手動チェックも組み合わせると効果的。

代表的な脆弱性管理ツールと特徴を整理する。

ツール対応言語・エコシステム特徴
Dependabot（GitHub）npm / pip / bundler / Go / Maven 等プルリクエストを自動作成。GitHub に統合されているため導入コスト低
npm auditNode.js / npmnpm に標準搭載。npm audit fix で自動修正も可能
OWASP Dependency-CheckJava / .NET / Python 等多数NVD（National Vulnerability Database）と照合。CI への組み込みが可能
Snyk多言語対応脆弱性の修正提案が詳細。無料プランあり

ライブラリのバージョン固定（lockfile）と定期的なアップデートはトレードオフの関係にある。lockfile を使えば「いつも同じバージョンが使われる」ことで予期せぬ挙動変化を防げるが、アップデートをサボると脆弱性のある古いバージョンが長期間使われることになる。定期的にアップデートを行い、CIでテストが通ることを確認してからマージする運用を確立しておくとよい。

セキュリティ方針でよくある失敗パターン

セキュリティ対応は「後からやる」と言い続けると、リリース直前に大量の対応が降ってくる。

失敗パターン何が起きるか防止策
セキュリティ要件を要件定義フェーズに含めないGDPR・個人情報保護法の対応がリリース直前に判明し、大規模な機能追加が必要になる要件定義フェーズ開始時にセキュリティ担当を参加させ、準拠法令・要件を最初に定義する
DependabotなどのCIチェックを後回しにするリリース直前に多数の脆弱性が検出され、対応優先度判断で時間を消費するプロジェクト開始時にDependabot・npm auditをCI/CDに組み込み、警告を毎回確認する
脆弱性対応の優先度基準がないCriticalとLowの脆弱性が混在し、何を先に対応すべきか判断できずに放置されるCVSS スコアを基にCritical/High/Medium/Lowの対応期限を文書化しておく