開発と脆弱性と脆弱性診断についての話

開発者と開発したシステムの脆弱性、そしてそれについてまわる脆弱性診断のそれぞれの立ち位置での話です

Transcript

1. 開発と脆弱性と脆弱性診断についての話 PentestSecJP_ver2
2. 謝辞
3. 謝辞 本スライド作成にご協力いただいた全ての皆様に感謝いたします。 会社の上司や同僚、コミュニティのメンバー、そして友人の協力がありスラ イドを完成させる事ができました。 皆様のご支援に心より感謝いたします。
4. 今回の発表で話すこと
5. 今回の発表で話すこと 開発と脆弱性診断それぞれの立場でのシステムへの向き合い方
6. 今回の発表で話さないこと セキュリティを担保していくためのアプローチ・手法や具体例 シフトレフトやDevSecOpsやSCM・SBOMの話
7. 注意 今回の発表は、発表者の経験をもとにしています。 そのため全てに置いて当てはまるものではありません。
8. 自己紹介
9. 自己紹介 名前：スリヤツキ ビャチェスラフ 情報処理安全確保支援士 所属：EGセキュアソリューションズ株式会社 業務：脆弱性診断・ペネトレーションテスト・LLM診断 経歴：開発を5年ほど、Webシステムやスマホアプリ開発の 仕様制定からテストまで一通り
10. こんなことありませんか？
11. 開発とセキュリティの埋まらない溝 また指摘か…リリース目前なのに 開発者 セキュリティ担当者 昨年から指摘事項が変わらない ...
12. そもそも「脆弱性」とは
13. そもそも「脆弱性」とは 「脆弱性とは、システムやソフトウェアに存在するセキュリティ上の弱点や欠陥を指しま す。 これらの弱点は、悪意のある攻撃者によって悪用される可能性があり、システムの機密 性、完全性、可用性に重大な影響を及ぼすことがあります。 脆弱性は、システムの設計段階や開発段階でのミス、あるいは運用中の設定ミスなど、 さまざまな要因によって発生します。」 出典 https://www.eg-secure.co.jp/blog/what-is-vulnerability
14. そもそも「脆弱性」とは 攻撃者 脆弱性が存在すると攻撃される危険性が上がる 脆弱性 攻撃 攻撃 運用中システム
15. では「脆弱性診断」とは
16. では「脆弱性診断」とは 「脆弱性診断とは、システムやアプリケーションに潜む脆弱性を洗い出すために、さまざ ま な手法を用いて診断を行い、その結果を報告書として提示するプロセスである。 診断対象の システムに対し、データベース化およびナレッジ化された脆弱性の検査リス トに照らし合わ せ、網羅的にチェックを行い、リスクを明確化することで、開発や運用の 段階で適切な修正 措置を講じられるよう支援する。」 出典 IPA 脆弱性診断内製化ガイド https://www.ipa.go.jp/jinzai/ics/core_human_resource/final_project/2025/tbl5kb 000000ag23-att/tbl5kb000000ag9u.pdf
17. そもそも「脆弱性」とは 攻撃者 脆弱性を見つけて攻撃される前に防げるようにする 脆弱性 攻撃 攻撃 運用中システム セキュリティ担当者 診断
18. 脆弱性対応とは システムや資産を守ること ブランドを守る 身を守る
19. すれ違いの原因
20. 開発側から見た事情 なぜ脆弱性対応は後回しにされがちなのか？
21. すれ違いの原因①【開発側の事情】 • 意識の問題：そもそも脆弱性を意識している人が少ない • 管理の問題：脆弱性を管理する文化や仕組みがない • タイミングの問題：診断が開発の最終盤（結合テスト後など）に行われるため、手戻 りのコストが大きい
22. すれ違いの原因②【開発側の事情】 • 背景にある「開発あるある」① ◦ 開始から遅延してるプロジェクト ▪ 初めから期間が無い ▪ 開発しながら仕様を決めている ◦ 更新されない古いフレームワーク ◦ フレームワークを使ってるけど、フレームワークの機能を利用していない
23. すれ違いの原因③【開発側の事情】 • 背景にある「開発あるある」② ◦ 新人しかいない ◦ テストコードが存在しない ◦ 人の入れ替わりで仕様の把握ができていない ◦ 開発優先やリリース優先でセキュリティを後付け
24. なぜ脆弱性対応は後回しにされがちなのか？ 開発でセキュリティを気にしている余力が無い
25. 脆弱性診断から見た事情 なぜ開発は協力的ではないのか？
26. すれ違いの原因①【診断側の事情】 • 情報不足：診断に必要な情報がなく、開発チームとのコミュニケーションラリーが発 生 • 仕様の問題：「いけてない仕様」から脆弱性が生まれている • 変わる環境：診断中に開発が進み環境が更新される
27. すれ違いの原因②【診断側の事情】 • 本来はテストで見つけるべき問題を脆弱性診断で指摘 • 本番環境での診断で気をつかい見落とす • 複雑な仕様の全体把握が難しい
28. すれ違いの原因③【診断側の事情】 • リスク評価のギャップ ◦ 診断側の判断と開発側の判断が大きく異なっている ▪ 一部の環境情報のみを診断に共有し、それをもとにリスク判断 ▪ 共有されてない仕様により判断の差が発生
29. すれ違いが招く悲劇
30. すれ違いが招く悲劇 • 納期を変えずに脆弱性がある状態でのリリース • リリース目前なので危険度を下げてほしいと打診される • 期間と予算がないため見るべき対象を診断できていない • 脆弱性対応のためコスト増大・リリース延期
31. 開発でセキュリティを気にする必要性
32. 開発でセキュリティを気にする必要性 「セキュリティ対策は「オプション」ではなく「必須の要件」と言えます。システムベンダは、 責任をもってセキュアなシステムを提供するようにしましょう。」 出典 セキュリティ・バイ・デザイン「システム開発のセキュリティ向上 0.0」 https://www.ipa.go.jp/jinzai/ics/core_human_resource/final_project/2024/f55m8 k00000034qn-att/f55m8k00000034ye.pdf
33. 目指すは溝を埋めることへ
34. 目指すは溝を埋めることへ • お互いの専門性を尊重し、同じゴールを目指すパートナーになることで、初めて安 全で質の高いシステムが生まれる • 開発者 ◦ 利用しているフレームワークのセキュリティ機能を正しく理解し活用する • セキュリティ担当 ◦ 脆弱性を指摘するだけでなく開発者に寄り添って話す
35. お互いの事情を理解する必要性 開発側の事情をわかったので それに合わせて対応を考えよう 前指摘されたから 今回は初めから対応しよう
36. 本日のまとめ
37. まとめ システムのセキュリティのためには、開発者とセキュリティ担当者の溝をうめていく必要 がある 脆弱性への対応は、単なる欠陥修正ではなく、システム、資産、そして企業のブランド価 値を守るための重要な活動 それぞれが協力して脆弱性やセキュリティへの対応していく必要がある