品質管理とセキュリティの新基準: ブラックボックス化から脱却するソフトウェア透明性

品質管理とセキュリティの新基準:ブラックボックス化から脱却するソフトウェア透明性～インテリジェントなSCAで実現する構成管理と脆弱性対応～

### ブラックボックス化からの脱却、いま求められるソフトウェア透明性

ソフトウェア開発の現場では、OSSやサードパーティコンポーネントの活用が拡大し、開発効率は飛躍的に高まりました。その一方で、「自社システムの構成やライセンス、脆弱性を把握しきれない」という“ブラックボックス化”が深刻なリスクとなりつつあります。脆弱性対応の遅れによるセキュリティインシデント、ライセンス違反による法的リスクなど、経営や社会的信用を揺るがしかねないケースも増えてきました。
また、「EU Cyber Resilience Act（CRA：欧州サイバーレジリエンス法）」や「米国大統領令14028」など、世界各国でソフトウェアの透明性や安全性を厳しく求める規制が進行しており、我が国のサプライヤーにも大きな影響があります。金融や医療、交通といった基幹インフラにもソフトウェアが組み込まれる今、セキュリティ品質の確保のために「ソフトウェアの透明性」をどうするか。この問題は、企業の競争力や社会的信用を損なうリスクに関わる優先課題となっています。
・OSSライセンス違反による法的リスク
・ソフトウェアの脆弱性への対応にメスを入れる
・EU Cyber Resilience Act（CRA）など規制対応が必要な局面

### SCAとSBOMで実現する“見える化”

こうした時代背景の中でここ数年欧米を中心に導入が進んでいる実践手段は「SCA（Software Composition Analysis:ソフトウェア構成分析） 」とその結果得られる「SBOM（Software Bill of Materials: ソフトウェア部品表）」による手法です。OSSやサードパーティコンポーネントの情報を可視化し、脆弱性やライセンスリスクに的確に対応できることから、次世代のセキュリティ基盤として期待されています。
講演内では、SPDXとOWASP CycloneDXの2つのSBOMフォーマットの特性の違い についても触れます。システムに含まれるOSSやコンポーネントのバージョン、ライセンス、脆弱性情報を素早く可視化し、リスク対応の加速につなげるには重要なトピックです。

### 実践手段の紹介：システムのサプライチェインリスクを可視化する「Checkmarx CxOne」

本セミナーでは 「Checkmarx CxOne」 を活用した統合セキュリティプラットフォームの実践的な導入方法をわかりやすく解説します。
このツールは、皆様の開発コードを解析する「SAST（静的ソースコード解析）」、SCA、SBOM生成も統合されています。また、SCAで分析するリスクは、単にCVEの羅列を超え、喫緊に対応すべきコンポーネントを見つけ出すインテリジェンスが反映されています。
どのようにシステムの透明性を高め、セキュリティ強化と開発効率の両立を実現するのか ――具体的な事例や最新の規制動向を交えながらご紹介します。

Transcript

1. 品質管理とセキュリティの新基準: ブラックボックス化から脱却するソフトウェア透明性 岡田良太郎 Release: 2024/2
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 委員 2024/3
3. https://www.youtube.com/watch?v=Rp9uPVahpUw マジセミ：いまさら聞けない脆弱性入門 ユーチューバーになってしもた(？) youtube.com/@asteriskresearch
4. アスタリスク・リサーチ 2006年創立のリスク対策実現企業 2024/3
5. Q. 皆さんは、ものづくりは好きですか • 使ってくれる人を大切にできる • いいものにしていける • 壊されにくくできる • 挑戦できる • ともに成長できる • いいユーザやコンテンツ入ったら最高 • 事業が継続できる 2024/3
6. 2025/2/13
7. 2025/2/13
8. アプリケーション プレゼンテーション セッション トランスポート ネットワーク データリンク 物理層 2025/2/13
9. 2025/2/13 アプリケーション バックエンド Web service 仮想/クラウド Platform
10. ソフトウェア ソフトウェア ソフトウェア ソフトウェア ソフトウェア ソフトウェア ソフトウェア 2025/2/13
11. システム開発コードの品質保証 IT システム 自社開発 自社開発コード 展開(デプロイ)の コード(IoC) 外部委託 開発委託のコード オフショアによる コード 第三者開発 コード OSSコンポーネン トの利用 商用APIやライブ ラリ 外部サービスとの 連携・つなぎこみ
12. システム開発コードの品質保証における課題 • 立ち遅れるセキュリティレビュー • 能力、スキルの不足による不安な設計・実装 • 脆弱性検証はブラックボックステスト依存 • デプロイコードの問題 • 過信されている外部委託 • 内容の妥当性を検証する能力の不足 • コンプライアンス要件、脅威の想定のあいまいさ • 開発プロセス、スキルの費用負担の不足 IT システム 自社開発 自社開発コード 展開(デプロイ)の コード(IoC) 外部委託 開発委託のコード オフショアによる コード 第三者開発 コード OSSコンポーネン トの利用 商用APIやライブ ラリ 外部サービスとの 連携・つなぎこみ
13. システム開発コードの品質保証における課題 • 自社開発部分のセキュリティ • 能力、スキルの不足による不安な設計・実装 • 平均 526 のOSSコンポーネント(Synopsys 調査) • 一般的なアプリケーションには、数百かそれ以上の OSSコンポーネントが使われている • アップデート運用は困難 • 脆弱性情報は多すぎる (CVE List 毎日何百何千ものアップデート） • 自社のものでさえブラックボックス化 • 利用部品は自社開発者も把握できていない • 外部事業者の開発成果物はなおのこと IT システム 自社開発 自社開発コード 展開(デプロイ)の コード(IoC) 外部委託 開発委託のコード オフショアによる コード 第三者開発 コード OSSコンポーネン トの利用 商用APIやライブ ラリ 外部サービスとの 連携・つなぎこみ
14. 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を利用した情報操作の可能性が浮上。
15. さらに意図的な侵害コード混入というOSSリスク • PyPI に登録されたプロジェクトに マルウェアが混入 • OSごとに適格なinfostealerがダウ ンロードされるsetup.py • 見かけ、ちゃんとしたパッケージ • 2023/10/27-30にnpmにアップ ロード • 48 もの個別パッケージに難読化さ れたリバースシェルが展開された • 現在も絶賛活動中との観測 • 戦争反対！の意図からコミッターがコー ドに仕掛けた • ロシアとベラルーシからのユーザのみを ターゲットにワイパーが入っていた！ (攻撃的)
16. Q.セキュリティ脆弱性対策、 シフトレフト課題は？ 1. 脆弱性検査は外部に発注できていない 2. OSSのアップデート不十分かもしれない 3. 外部委託のコードは検証が困難 4. 自社開発のコードの検証は難しい 5. 開発セキュリティに関するトレーニングが調達できていない 6. どこから手をつけるべきか判断が難しい 7. 予算も人もなさすぎる 2024/3
17. ロボット 2025/2/13
18. BOMの概念 https://www.techs-s.com/media/show/7
19. そこで、BOM: Bill Of Materials = 部品表 • 製品を製造する上で必要な部品情報・構成情報 • 自社のメリット：設計部門から購買部門、製造部門へと引 き渡され、調達スケジュールや工程管理、さらに原価管理 においても不可欠 • サプライチェイン全体：共有されれば、製品に必要な部品 管理・改善を効率的に行える • ソフトウェアは？
20. SBOM Software Bill Of Materials ソフトウェア部品表 特定の製品に含まれるすべて （プロプライエタリおよびオー プンソースなど）のソフトウェ アコンポーネント、ライセンス、 依存関係を一覧化したもの <component> <type> library <name> antlr:antlr <version> 2.7.7 <license> Maven-antlr:antlr-2.7.7-BSD 3 <component> <type> library <name> org.apache.directory.shared <version> 0.9.19 <license> pkg:Maven/org.apache.directory. shared:shared-ldap@0.9.19 <component> <type> library <name> com.caucho:hessian <version> 4.0.7 <license> Apache 1.1
21. US 大統領令 EO14028 • 2021年7月12日、米国連邦政府は、バイデ ン政権の大統領令に準拠するためのSBOM における最低限必要な要素を発表。 • このガイドラインは、連邦政府と取引のあ る組織にのみ適用。
22. 経産省「SBOMの導入に関する手引」改訂版v2.0 SBOMの詳説と脆弱性管理プロセスの具体化を推進 • Ver2.0はソフトウェアを供給する企業と調 達する企業の双方を想定読者とし、「脆弱 性管理プロセスの具体化」、「SBOM対応 モデル」「SBOM取引モデル」の追加をし ている 2024/9 https://www3.nhk.or.jp/news/html/20240722/k10014518591000.html
23. EU サイバーレジリエンス法 • 施行・監督において中心的な役割を担う、欧州 連合サイバーセキュリティ機関（ENISA） • 2024年12月10日に施行 • 適用開始時期は、法律の成立後36ヶ月後、すな わち2027年12月11日 • 制裁金: 最高1,500万ユーロまたは全世界の年間 売上高の2.5％（いずれか高い方） • 販売制限: 規制当局は、非適合製品の市場流通を制 限する権限を持ちます。 • リコール: 規制当局は、非適合製品のリコールを命 じられる ソフトウェア部品に関わるレギュレーション • セキュリティ・バイ・デザイン • 必須のサイバーセキュリティ要件の遵守 • 脆弱性への対応 • 最低５年間のセキュリティ更新の提供 • SBOM含む情報提供 • 適合性評価 • 脆弱性報告窓口の設置
24. ソフトウェア透明性と追跡可能性の重要性 - グローバルスタンダードの流れ • 米国大統領令(EO 14028/2021年公布) • 国家のサイバーセキュリティ強化 • SBOMの提出: 連邦政府機関にソフトウェアを提供 するベンダーは、SBOMを提出する義務があります。 • セキュリティガイドラインの遵守: NIST（米国国立 標準技術研究所）が策定したソフトウェアサプライ チェーンセキュリティに関するガイドラインを遵守 する必要があります。 • 脆弱性情報の共有: ソフトウェア製品に発見された 脆弱性に関する情報を、政府機関と共有する必要が あります。 • EUのサイバーレジリエンス法 (CRA) • デジタル要素を含む製品のセキュリティ要件を定め た包括的な法規制 • 脆弱性開示: ソフトウェア製品に発見された脆弱性 について、速やかに情報公開し、ユーザーに提供す る義務があります。 • セキュリティテスト: 開発プロセスにおいて、適切 なセキュリティテストを実施し、製品のセキュリ ティレベルを確保する必要があります。 • SBOMの提供: 製品に含まれるソフトウェアコン ポーネントに関する情報をSBOMとして作成し、 ユーザーに提供することが求められます。
25. ソフトウェア部品の信頼性 ソフトウェア透明性（トランスペアレンシ） • ソフトウェアの構成要素、依存関係、出自などが明確に把握・開 示できている状態を指します。 • SBOMを通じて、使用されているコンポーネントやその詳細情報が透明 化されること ソフトウェア追跡可能性（トレーサビリティ） • ソフトウェアのコンポーネントについて、その由来や変更履歴、 供給経路などを遡って追跡できる能力。 • SBOMによって、各コンポーネントのライフサイクルや流通経路を追跡 すること
27. SBOMは手になじんできましたか？ SCA SBOM
28. SPDX • The Linux Foundation • コンプライアンス • OSSライセンス • ISO標準 CycloneDX • OWASP • セキュリティ脆弱性情報 • 変更追跡 • ライセンスはOSS/商用に対応 • ECMA標準
29. OWASP と SBOMといえば CycloneDX • CycloneDX v1.6は ECMA標準 • セキュリティ脆弱性管理に重心 • 多方面のBOMへの対応 • SBOM, SaaSBOM, 暗号化、AI • OSS、商用ライセンスも対応 • 220以上のツールが対応 https://cyclonedx.org/capabilities/
30. CycloneDX サプライチェインリスクに直球 CycloneDXv1.6 は xBOM国際標準 ECMA技術委員会 54 (TC54) • ソフトウェアの脆弱性とコンプライアンスの両方に対 応するコンポーネント透明性 • サービス(SaaSBOM) 運用整合性に影響を与える潜在 的リスクと依存 • ハードウェアとファームウェアなどIoTの物理コン ポーネントと組み合わせる仕組みのセキュリティ保護 • AI/ML駆動型システムにおける信頼性 • 暗号化資産の安全な取り扱い • OSSとプロプライエタリライセンスの両方をサポート
31. OWASP SBOM CycloneDX 1. 外部参照情報の充実 2. 依存関係の透明性 3. セキュリティスキャンとの連携がしやすい 4. ライセンス情報の明確さ • CycloneDX形式は、外部参照、バージョン情報、 ライセンス情報が豊富で、依存関係の透明性が 高い https://cyclonedx.org/capabilities/
32. v1.6 •Released by OWASP in April 2024 •Added support for CBOM and Attestations (CDXA) to capabilities •Will become Ecma standard in 2024 •Pursuing ISO standardization v1.7 •Work underway. Three FWGs established •Will add support for Blueprints (ABOM + BOB), TM-BOM, and OSS Sustainability •Will become an Ecma standard (likely in 2025) •Will pursue ISO standardization CycloneDX Updates SBOM SaaSBOM HBOM OBOM BOV VDR VEX AI/MLBOM MBOM CDXA CBOM CURRENT CAPABILITIES
33. OWASP Dependency Track BOMを扱うツール 何をもとに • CycloneDX SBOMおよびVEXなどの標準フォーマット • 脆弱性データベース（NVDやGitHub Advisories、Sonatype OSS Index 等）や、ライセンス情報（SPDX標準ID）などの外部情報 誰のために • 企業のセキュリティ管理者やコンプライアンス担当者 • ソフトウェア開発者やエンジニアリングチーム • リスク管理・サプライチェーンの担当者 何をするのか • 全スタックのコンポーネントの利用状況の管理（ライブラリ、OS、ハード ウェア、API、サービスプロバイダーまで） • リスクの特定と優先的な緩和策の提示（既知の脆弱性、ライセンスリスク、 改変コンポーネント等） • 統合的な脆弱性情報の収集・ポリシー管理 • セキュリティリスクやライセンス・運用リスクの可視化と管理
34. </ > 34 CxOne DEMO w/SBOM
35. ASTERISKセレクション Asterisk MSSP by Checkmarx CxOne 2024/3
36. Figure 1: Magic Quadrant for Application Security Testing • Checkmarxはこのマジック・クアドラントのリーダーです。Checkmarx は、SAST、DAST、SCA、コンテナ・チェック、APIテスト、IaCセキュ リティなどの機能を、スタンドアロンでもCheckmarx Oneプラット フォームでも提供しています。そのほとんどが、SaaSまたはマネージ ド・サービスとして提供されています。Checkmarx IASTは独立した製 品で、IaCはオープンソースツール（KICS by Checkmarx）としても提 供されています。Checkmarx社は米国に本社を置き、グローバルに事業 を展開しています。 • 同社は、開発者のエクスペリエンスを向上させ、優先順位付けされたリス クベースの調査結果を顧客に提供することに主眼を置いています。中核と なるAST機能とは別に、チェックマーク スは開発者トレーニングやセ キュリティ・リサーチも提供し、そのポー トフォリオにオートレメディ エーション機能を追加しています。Checkmarxは、開発者の間で高い評 価を得ており、DevSecOpsに取り組み始めた組織に適しています。 2024/3
37. Asteriskセレクション： MSSP by Checkmarx CxOne 2024/3 • SAST(自社・委託によるコードの解析） – 対応言語が豊富 – NIST800, OWASP, PCIDSSその他のコ ンプライアンスに対応 – レポジトリ単位：複数言語同時スキャン に対応 – プライオリティづけされた問題の詳細な 指摘
38. Asteriskセレクション： MSSP by Checkmarx CxOne 2024/3 • SCA (サードパーティコンポーネン トの解析） – 脅威インテリジェンスによる評 価 – ライセンスにももちろん対応 – SBOM出力(SPDX, CycloneDX)に対応 – 受領したSBOMの解析も可能 – 履歴も出せる SBOM
39. Asteriskセレクション： MSSP by Checkmarx CxOne 2024/3 Actions* Webhooks* SCM CI/CD Pipelines IDEs Feedback Channels/ Adv. Reporting
40. 生産技術チームにも、開発者にもわかりやすい指摘と改善ガイド 2024/3 随時スキャン可能。状況がわかりやすい総合レポート わかりやすい指摘箇所と解説
41. ユーザーと専門家の声 早い段階でセキュリティ脆弱性を見 つけ出し、コードが本番環境に展開 される前に修正するには、最適な方 法です CI/CD（継続的インテグレーション / 継続的デリバリー） パイプライ ンへ簡単に統合できた点です。 開発者に優しい作りの製品のため、 開発者たちにもすぐに受け入れられ ました。 Github Issuesに自動的に流し込 むことで、いつでも手戻りなく問題 発見できるのが便利です • モバイルサービス・生産技術 Yamory, BlackDuck, FutureVuls と使ってきましたが、 SCA ツールとしても、最高でした • 日本の著名SIer 生産技術部門、アプリケー ション・スペシャリスト テクニカルサポートは、行き届いた 支援をしてくれました。 2024/3
42. Q.Asterisk MSSP by CxOneのSCA、どこが良いと思われましたか 1. SCA（コンポーネント分析）が詳細を捉えている 2. SPDXにもCycloneDXに対応している 3. 外部由来のSBOMも検査できる 4. プロジェクトのリスクを上司やチームに共有しやすいダッシュボード 5. Githubとの自動化連携やIDEなど開発環境との親和性 6. モダンな開発言語への対応 7. 日本国内の利用サポートが得られる 2024/3
44. まとめ セキュリテイが開発とうまくつきあう 2024/3
45. 2024/3
46. ソフトウェア部品の信頼性 ソフトウェア透明性（トランスペアレンシ） • ソフトウェアの構成要素、依存関係、出自などが明確に把握・開 示できている状態を指します。 • SBOMを通じて、使用されているコンポーネントやその詳細情報が透明 化されること ソフトウェア追跡可能性（トレーサビリティ） • ソフトウェアのコンポーネントについて、その由来や変更履歴、 供給経路などを遡って追跡できる能力。 • SBOMによって、各コンポーネントのライフサイクルや流通経路を追跡 すること
47. まとめ • 自社開発および購入したアプリケーションに何が含まれているかを知る価値 • アプリケーションチームおよびベンダーはSBOM管理が必要 • 作成するアプリケーションのSBOMの作成と維持は容易ではない • 仕組み化：自動化と標準化が重要 • SBOMを作ることは、最終目的ではない。ソフトウェアサプライチェーン信頼 性の手段 • 透明性と責任追跡性は自社のため。ソースコード管理（SCM) に含まれる、SAST、 SCA、脅威インテリジェンスは、アプリケーションセキュリティの必須要素 ✓
48. セキュリティが本当にシステム開発に貢献するためには たくさんのすべきことがある ゲートウェイではなく ガードレール 最も効果的な修正ポイ ントとタイミング 使っている言語や環境 に馴染む 頻繁な更新と柔軟性 リスクをほったらかさな い。合理的な対策を得る 開発者が自分で問題を 確認する方法を得る 共通の目標を持ち、 その成功をたたえる 異なった役割の人と 協力する経験を増やす Join OWASP 2024/3
49. 2024/3
50. 「どこから始めようか？」 support@rsrch.jp 2006年創業の、日本のリスク対策支援企業です。ご相談ください。 2024/3 改善計画に役立つサービス、あります。 • ブリーフィング・トレーニング • 製品・サービスの選定やPOC支援 • リスクトレンドのアップデートと対応訓練計画 • グローバルコンプライアンスに対応したセキュリティテスト • SAMMスコアカードで実践支援：PSIRTアドバイザリ 業界特化にも、対応を拡げています。 金融、医療、ライフライン、製造、流通、サービスまたソフト ウェア業界において、品質管理、生産技術、リスクやコンプライ アンスに関わる部門はもちろん、高速に成長させるミッションの ある事業経営部門のお客様をご支援しています。 「アスタリスクリサーチ」で検索
51. Thank you Github/speakerdeck/X: okdt LinkedIn: riotaro Youtube: asteriskresearch