導入
リリース直前に脆弱性診断の指摘が入り、開発チームが慌てる
一方でセキュリティ担当は「去年も同じ指摘をした」と感じている
このような 開発とセキュリティのすれ違い は多くの現場で起きている
この記事では勉強会 PenTestSecJP2 の内容をもとに、
開発と脆弱性診断の関係を整理する
この記事では次のことをまとめる
- 脆弱性と脆弱性診断の基本
- 開発とセキュリティが衝突する理由
- 開発現場でセキュリティを機能させる考え方
勉強会概要
イベント
PenTestSecJP2
テーマ
開発と脆弱性と脆弱性診断についての話
内容
- 開発者視点の課題
- 脆弱性診断側の課題
- 両者のギャップと改善の方向性
脆弱性とは
脆弱性とは
- システムやソフトウェアのセキュリティ上の弱点
- 攻撃者に悪用される可能性のある欠陥
影響する領域
- 機密性（Confidentiality）
- 完全性（Integrity）
- 可用性（Availability）
つまり
システムの安全性に穴がある状態
ただし興味深い話として
- 実在する脆弱性のうち
- 実際に悪用されるのは 約2%
つまり
脆弱性の存在と攻撃される確率は別問題
脆弱性診断とは
脆弱性診断は次のプロセス
- システムを調査
- 脆弱性を発見
- リスクを評価
- 開発者へ報告
目的
- 攻撃者より先に問題を見つける
- リスクを可視化する
- 修正につなげる
つまり
攻撃される前に弱点を見つける活動
脆弱性対応の目的
脆弱性対応は単なる修正ではない
守るもの
- システム
- 情報資産
- 企業ブランド
つまり
セキュリティはビジネスリスク管理
開発とセキュリティがすれ違う理由
開発と脆弱性診断の間には構造的なギャップがある
主な原因は次の2つ
- 開発側の事情
- 診断側の事情
開発側の事情
脆弱性対応が後回しになる理由
意識の問題
- セキュリティを意識する開発者が少ない
- 機能開発が優先される
管理の問題
- 脆弱性管理の仕組みがない
- セキュリティ課題を追跡する文化がない
タイミングの問題
多くの企業では診断が
- 開発終盤
- リリース直前
このタイミングだと
- 修正コストが大きい
- スケジュール変更が難しい
開発現場あるある
セキュリティ対応を難しくする典型例
プロジェクトの遅延
- 最初からスケジュールが厳しい
- 開発しながら仕様を決める
技術的負債
- 古いフレームワーク
- 更新されないライブラリ
フレームワークを使いこなしていない
例
- ORMがあるのに生SQL
- セキュリティ機能を使っていない
チーム構成
- 新人中心のチーム
- AIコード生成の利用
- テストコードが存在しない
優先順位
結果
- リリース優先
- セキュリティ後回し
脆弱性診断側の事情
診断側にも難しさがある
情報不足
診断に必要な情報
- システム構成
- ネットワーク構成
- 認証方式
不足すると
- 診断精度が下がる
- コミュニケーションコストが増える
仕様の問題
脆弱性は次の両方から生まれる
- 実装ミス
- 設計ミス
特に
仕様そのものが問題の場合
診断側では解決できない
本来テストで見つかる問題
診断では次のような問題も多い
- 入力バリデーション不足
- エラーハンドリング不足
- 不適切な権限チェック
本来は
- 単体テスト
- 結合テスト
で見つかるべき問題
リスク評価のギャップ
よくある衝突
開発側
- 社内ネットワーク
- 閉じた環境
診断側
- ネットワーク全体は把握できない
結果
リスク評価が一致しない
すれ違いが招く問題
開発と診断のギャップがあると
次の問題が起きる
- 脆弱性があるままリリース
- リリース直前の危険度調整
- 診断範囲不足
- 修正コスト増大
つまり
セキュリティ対応コストが膨らむ
セキュリティ・バイ・デザイン
重要な考え方
セキュリティはオプションではない
セキュリティは
- 追加機能
ではなく - システム要件
つまり
設計段階から考える必要がある
溝を埋めるために
重要なのは
お互いの事情を理解すること
開発側
- フレームワークのセキュリティ機能を理解
- 早い段階でセキュリティを考慮
セキュリティ側
- 指摘だけで終わらない
- 開発者と対話する
目指す姿
同じゴールを持つパートナー
技術者視点の考察
この問題の本質は
技術ではなくプロセス
よくある構造
- 診断はリリース前
- 修正余力なし
- リスク調整
これは
プロジェクト設計の問題
改善するには
- 設計段階のセキュリティレビュー
- CIでのセキュリティチェック
- ライブラリ管理
- フレームワーク機能の活用
つまり
セキュリティを開発プロセスに組み込む必要がある
学び
今回のポイント
- 脆弱性対応は単なる修正ではない
- 開発とセキュリティには構造的ギャップがある
- セキュリティは設計段階から考える必要がある
まとめ
脆弱性対応は
- システム
- 情報資産
- ブランド
を守るための活動
そのためには
開発とセキュリティが協力する体制が必要
セキュリティは後付けではなく
開発プロセスの一部として扱うべき