Compliance Tsunami

Is There a Way to Survive the Tsunami of Compliance?
- Software Quality Management Department: The Red Zone Era

ソフトウェア品質管理部門レッドゾーン時代
コンプライアンス津波を生き延びる方法はあるのか

Transcript

1. ソフトウェア品質管理部門レッドゾーン時代 コンプライアンス津波を 生き延びる方法はあるのか 岡田 良太郎 アスタリスク・リサーチ/OWASP Japan lead riotaro@rsrch.jp
2. アスタリスク・リサーチ 岡田良太郎 岡田 良太郎 代表・エグゼクティブリサーチャ CISA, MBA riotaro@rsrch.jp 活動 - activities - Hardening Project オーガナイザ 衛る技術を顕彰する、8時間耐久ビジネス堅牢化技術競技プロジェクト - OWASP (Open Web Application Security Project) 世界最大のアプリケーションセキュリティ推進団体 ・OWASP Japan チャプターリーダ ・OWASP Top 10、Top 10 for LLM、ASVS コントリビュータ ・OWASP Foundation “Best Chapter Leader”, “Best Community Supporter” 受賞（2014） - Hackademy（ハッキングと防御） 「ハッキングと防御」コース - ビジネスブレークスルー大学（学長 大前研一） 「サイバーセキュリティ実践」コース担当講師 - 独立行政法人 IPA 情報セキュリティ10大脅威選考委員 - 総務省 サイバーセキュリティ演習 CYDER 委員 2025/10/27 author: riotaro@rsrch.jp
3. TM
4. SBOM Guide now available Future guides include: https://cyclonedx.org/guides Authoritative Guides
5. OWASP.org / OWASP Japan chapter Open Worldwide Application Security Project • https://github.com/owasp-ja • OWASPトップ10 for LLM日本語 • OWASPトップ10 2021日本語 • OWASP Proactive Controls 2018日本語 • OWASP ASVS 4.0 日本語 • Mobile ASVS日本語 • 開発者のためのOWASPチートシート一覧表 日本語資料：Github: owasp-ja 2025/10/27 author: riotaro@rsrch.jp
6. Hardening Project 2025/10/27 author: riotaro@rsrch.jp
7. https://www.youtube.com/watch?v=Rp9uPVahpUw マジセミ：いまさら聞けない脆弱性入門 ユーチューバーになってしもた(？) https://www.youtube.com/@asteriskresearch 2025/10/27 author: riotaro@rsrch.jp
8. Q.システムの脆弱性対策、どこまでシフトレフトしてる？ 1. ユーザやシステム利用者のご指摘を中心に対応している（十分追いついていない） 2. 全体の脆弱性検査は専門企業に発注している（セキュリティ検証） 3. OSSなどアップデートはまめにやっている（運用セキュリティ） 4. 外部委託のコード、自社開発のコード検証はツールとマニュアルでやっている（リスク対策） 5. セキュアな開発に関するトレーニングは毎年受けさせている（コンプライアンス） 6. セキュリティと品質を監督するチームががんばって機能している（組織づくり） 7. 技術面、制度面で、新しい取り組みに積極的にチャレンジしている(先行的投資に熱心) 2025/10/27 author: riotaro@rsrch.jp
9. EU サイバーレジリエンス法 • 施行・監督において中心的な役割 を担う、欧州連合サイバーセキュ リティ機関（ENISA） • 2024年12月10日に施行 • 適用開始時期は、法律の成立後 36ヶ月後、すなわち2027年12月11 日 • 制裁金: 最高1,500万ユーロまたは 全世界の年間売上高の2.5％（いず れか高い方） • セキュア・バイ・デザイン（Secure-by-Design）： 製品の企画・設計段階からサイバーセキュリティリスクを評価し、対策を組み込むことが 法的に義務付けられる • 脆弱性管理：製造者は、製品の想定耐用期間中（最長5年間）、発見された脆弱性 に効果的に対処し、セキュリティアップデートを無償で提供するプロセスを確立しなけれ ばならない 。 • 強制的な報告義務：実際に悪用されている脆弱性を検知した場合、製造者は24 時間以内にEUサイバーセキュリティ機関（ENISA）へ報告する義務を負う 。この極めて短 い報告期限は、高度なインシデント検知・対応能力がなければ遵守不可能。 • 透明性の確保：製造者は、利用者に対して製品のセキュリティに関する明確で理 解しやすい情報を提供するとともに、製品を構成するすべてのソフトウェアコンポーネン トをリスト化した「ソフトウェア部品表（SBOM）」を作成・提供することが求められる 。 2025/10/27 author: riotaro@rsrch.jp
10. ENISA Threat Landscape 2024 • 可用性への脅威（DDoS）とランサムウェアが引き 続き最も大きな脅威。 • クラウド環境を利用したステルス攻撃（LOTS手 法）で、正規サイトを用いたC2通信が活a発化。 • 地政学的要因が引き続きサイバー攻撃の大きな動機。 • 防御回避技術の進化：サイバー犯罪者がLOT （Living Off The Land）手法を駆使し、環境に溶け 込む。 • ビジネスメール詐欺（BEC）の急増。 • 報告期限を利用した恐喝が新たな手口に。 • ランサムウェア攻撃は高い水準で安定。 • AIを活用した詐欺・サイバー犯罪：FraudGPTや LLMで詐欺メールや悪意のあるスクリプト生成。 • 脆弱性の19,754件が報告され、そのうち9.3％が 「クリティカル」、21.8％が「高」。 • 情報窃盗ツールが攻撃チェーンの重要要素に。 • ハクティビストと国家関与の類似。 • データリークサイトの信頼性が低下、重複や誤報が 増加。 • モバイルバンキングトロイの木馬の急増と攻撃手法 の複雑化。 • MaaS（Malware-as-a-Service）が急速に進化。 • サプライチェーン攻撃の社会工学的手法： OSSのXZ Utilsにバックドアが埋め込まれた事例。 • データ流出が増加傾向。 • DDoS-for-Hireサービスにより、未熟な攻撃者でも大 規模攻撃が可能。 • ロシアの情報操作がウクライナ侵攻において依然と して重要。 • AIを利用した情報操作の可能性が浮上。 2025/10/27 author: riotaro@rsrch.jp
11. ソフトウェアにおける深刻な サプライチェインリスク 敵対者が悪意のあるコードや悪意のあるコンポーネン ト全体を、信頼されているソフトウェアやハードウェ アの内部に紛れ込ませる手法により発生するリスク 2025/10/27 author: riotaro@rsrch.jp
12. OSSサプライチェイン問題に警鐘(Checkmarx) • 攻撃者はPyPIやnpmの人気パッケージ名を もじって悪意のコードを仕込んだり （Typo-squatting） • GitHubリポジトリ乗っ取り （RepoJacking） • これらの攻撃は開発者が意図せずインポー トしたときに発覚しにくい 2025/10/27 author: riotaro@rsrch.jp
13. PyPI依存コードによる侵害 • 「termncolor」パッケージは、 「colorinal」という 依存パッケージを介して多段階のマルウェア操作に よって不正な機能を実現 • 「この攻撃はDLLサイドローディングを利用して、 復号化を容易にし、永続性を確立し、コマンドアン ドコントロール（C2）通信を実行し、最終的にリ モートコード実行に至る可能性がある」 2025/10/27 author: riotaro@rsrch.jp
14. 意図的な侵害コード混入 • Fortinetは、Q2 2025に140万以上のnpm パッケージと40万のPyPIパッケージを解析 • データ窃取やウォレット盗難を目的とした 多くの悪意パッケージを検出したことを紹 介 2025/10/27 author: riotaro@rsrch.jp
15. システム開発コードの品質保証はカオス • 立ち遅れるセキュリティレビュー • 能力、スキルの不足による不安な設計・実装 • 脆弱性検証はブラックボックステスト依存 • デプロイコードの問題 • 過信されている外部委託 • 内容の妥当性を検証する能力の不足 • コンプライアンス要件、脅威の想定のあいまいさ • 開発プロセス、スキルの費用負担の不足 IT システム 自社開発 自社開発コード 展開(デプロイ)の コード(IoC) 外部委託 開発委託のコード オフショアによる コード 第三者開発 コード OSSコンポーネン トの利用 商用APIやライブ ラリ 外部サービスとの 連携・つなぎこみ 2025/10/27 author: riotaro@rsrch.jp
16. システム開発コードの品質保証はカオス • 自社開発部分のセキュリティ • 能力、スキルの不足による不安な設計・実装 • 平均 526 のOSSコンポーネント (Synopsys調査) • 一般的なアプリケーションには、数百かそれ以上の OSSコンポーネントが使われている • アップデート運用は困難 • 脆弱性情報は多すぎる (CVE List 毎日何百何千ものアップデート） • 自社のものでさえブラックボックス化 • 利用部品は自社開発者も把握できていない • 外部事業者の開発成果物はなおのこと IT システム 自社開発 自社開発コード 展開(デプロイ)の コード(IoC) 外部委託 開発委託のコード オフショアによる コード 第三者開発 コード OSSコンポーネン トの利用 商用APIやライブ ラリ 外部サービスとの 連携・つなぎこみ 2025/10/27 author: riotaro@rsrch.jp
17. 続々とくるコンプライアンス津波(一例) • CSDDD：2026-07-26 国内法化期限／2027〜 大企業から段階適用 • CBAM：2023-10〜2025-12 移行期（報告）／2026-01 本格適用 • FLR（強制労働製品禁止規則）：2027以降 本格適用見込み＊ • CRA：2024-12-10 施行／2027-12-11 主な義務適用 EU： • CTSCA：継続（公開義務）／PFAS州規制拡大 2025〜 • EAR強化：2024-12 先端半導体・装置の規制強化 US： • FIT関連：継続（再エネ拡大に伴う脱炭素対応） • 製品安全4法 改正検討：2025-01以降 動向注視＊ JP： 2025/10/27 author: riotaro@rsrch.jp
18. author: riotaro@rsrch.jp
19. 経済産業省「SBOMの導入に関する手引」改訂版v2.0 （1）ソフトウェアの脆弱性を管理する一連プロセ スにおいてSBOMを効果的に活用するための具体 的な手順と考え方、 （2）SBOM導入の効果及びコストを勘案して実際 にSBOMを導入することが妥当な範囲を検討する ためのフレームワーク、 （3）委託先との契約等においてSBOMに関して規 定すべき事項（要求事項、責任、コスト負担、権 利等）を追加 • 添付のチェックリストは必見です！ 2025/10/27 author: riotaro@rsrch.jp
20. </ > 23 SBOM、でた。なんで必要なの？
21. 今日一番大事なこと コンプライアンス(整備手段) は - ソフトウェア透明性・責任追跡性(目的)のためである 2025/10/27 author: riotaro@rsrch.jp
22. ロボット 2025/10/27 author: riotaro@rsrch.jp
23. 部品表 = “材料”をクリアに示す手段 https://www.techs-s.com/media/show/7 2025/10/27 author: riotaro@rsrch.jp
25. 「脆弱性」の解像度 脆弱性発生箇所 どんな状態か 対応手段の提供者 すぐ対応 シフトレフト デスクトップやスマートフォン デバイスのOSに問題があり、保護が手 薄、あるいは脆弱な状態になっている プラットフォーマ (Apple, Googleなど) アップデート適用、 設定調整 自動アップデート活用、 更新情報プロセス強化 アプリケーションソフトウェア バグや、踏み台などの脆弱性 開発会社、販売会社 アップデート適用、設定 調整、 アップデートあるいは アンインストール ネットワーク機器、デバイス 装置のファームウェアが古いあるいは 悪用されやすい設定になっているため 脆弱な状態 メーカー アップデート適用 ネットワーク機器や 構成の見直し システム：オープンソースや サードパーティAPIなど システムで利用しているOSで使われて いるOSSのソースコードに問題が発見 され脆弱性があるということが広く知 られる OSSプロジェクト、 LinuxやMicrosoftなど OSベンダー 動作検証と アップデート適用 ソフトウェア構成分析SCA の導入、SBOM システム：プログラムコード 自社あるいはSIerが開発したコードに問 題があり、脆弱になっている コードを書いた人ない し、開発プロジェクト チーム プログラムの修正 SAST、ハンズオン 教育訓練、検査ツールの強 化など生産技術的強化 システム：クラウドサービス、 アプリケーションの設定 コンフィギュレーションの問題で、 データが侵害されやすい状態などで脆 弱になっている クラウドベンダーある いはその先進的なユー ザ 設定の修正 適切な脆弱性検査や モニタリングの強化 ユーザ、オペレータ 利用が許可されている機能あるいは データの取り扱いを誤用してしまう ユーザ自身、ならびに その組織 応急対応と原因究明 非常事態の対応訓練 業務データ取り扱い訓練 ユーザビリティ向上 モニタリングの強化 2025/10/27 author: riotaro@rsrch.jp
26. CVSSチェックしてアップデートしていれば大丈夫？ 受け入れ基準を複数観点で評価する必要性 • コードのコミット履歴やメンテナの信用 • PoC公開の有無 • KEVリスト掲載状況 • コード量や暗号化の有無 2025/10/27 脆弱性優先付けにおいては、脆弱性対応要否の簡易なフィルタリ ング、脆弱性のインシデント有無、Exploitコードの公開有無、VEX 情報の活用、CVSSスコアなどに基づき費用対効果を考慮して優先 付けを行う。優先付けにおいては、SSVCの考え方を参考に必要に 応じて優先度のカテゴリー分類を行う。（7.4.2を参考とする。） ソフトウェア管理に向けたSBOMの導入に関する手引 ver2.0 付録：SBOM導入に向けた実施事項チェックリスト author: riotaro@rsrch.jp
27. どちらも使えるようにしておくべき 2025/10/27 author: riotaro@rsrch.jp SPDX • The Linux Foundation • コンプライアンス • OSSライセンス • ISO標準 CycloneDX • OWASP • セキュリティ脆弱性情報 • 変更追跡 • ライセンスはOSS/商用に対応 • ECMA標準
28. OWASP と SBOMといえば CycloneDX • CycloneDX v1.6は 国際標準(ECMA) • セキュリティ脆弱性管理に重心 • OSSライセンスだけでなく商用コンポーネ ントも対応 • 多方面のBOMへの対応 • SBOM, SaaSBOM, 暗号化、AI • OSS、商用ライセンスも対応 • 220以上のツールが対応 2025/10/27 author: riotaro@rsrch.jp
29. Blueprints Sustainability Threat Models
30. OWASP FOUNDATION owasp.org SBOM Software Bill of Materials MLBOM Machine Learning Bill of Materials OBOM Operations Bill of Materials SaaSBOM Software-as-a-Service Bill of Materials VEX Vulnerability Exploitability Exchange VDR Vulnerability Disclosure Report BOV Bill of Vulnerabilities HBOM Hardware Bill of Materials
31. </ > 39 SBOM集めても脆弱性だらけだ
32. author: riotaro@rsrch.jp
33. author: riotaro@rsrch.jp
34. OWASP Dependency Track BOMを扱うツール 何をもとに • CycloneDX SBOMおよびVEXなどの標準フォーマット • 脆弱性データベース（NVDやGitHub Advisories、Sonatype OSS Index等） や、ライセンス情報（SPDX標準ID）などの外部情報 誰のために • 企業のセキュリティ管理者やコンプライアンス担当者 • ソフトウェア開発者やエンジニアリングチーム • リスク管理・サプライチェーンの担当者 何をするのか • 全スタックのコンポーネントの利用状況の管理（ライブラリ、OS、ハード ウェア、API、サービスプロバイダーまで） • リスクの特定と優先的な緩和策の提示（既知の脆弱性、ライセンスリスク、 改変コンポーネント等） • 統合的な脆弱性情報の収集・ポリシー管理 • セキュリティリスクやライセンス・運用リスクの可視化と管理 2025/10/27 author: riotaro@rsrch.jp
35. フォーカスを誤ると推進が困難になる author: riotaro@rsrch.jp
36. author: riotaro@rsrch.jp
37. author: riotaro@rsrch.jp
38. </ > 48 OSS製品で十分では？ 商用SCA製品はなにがうれしいの？
39. 商用製品の特徴：商用製品の導入には意味がある 1. 利用場所と連携(調査タイミング、レイヤーの違い) 2. 調査対象、部品依存関係のレベル感の調整（スニペットからパッケージ まで） 3. ライセンスや脆弱性など違反の重大度判別の知見 4. 脆弱性にかかわるインテリジェンス 5. 製品にかかわる記録、履歴の追跡性 6. レポート機能（単体、横断） 7. 他のダッシュボードサービスとの連携機能 (ASPM) 2025/10/27 author: riotaro@rsrch.jp
40. まとめ 津波を乗り越えるプロセス、 そして乗り越えたあとにあるものを見よう
41. Q. あなたの企業・チームが来期に、 セキュリティをぐっと強化するのに有効な手立ては？ 1. 戦略：現状の成熟度をはかり、課題を明確にすること 2. 戦略：チームの協力関係の強化・サイロ化の解消 3. 仕組：生産技術、インシデント対応などの組織づくり 4. 仕組：脆弱性検査ベンダーやアドバイザの調達 5. 道具：脆弱性を早期に発見するのに助けになるツール 6. 教育：不安のない構築手法の基礎スキルの獲得 7. 訓練：役割にフィットするトレーニング 2025/10/27 author: riotaro@rsrch.jp
42. LinkedIn
43. Sansan/Eight
44. Prairie Card
45. Thank you Github/speakerdeck/X: okdt LinkedIn: riotaro Youtube: asteriskresearch 2025/10/27 author: riotaro@rsrch.jp