はじめに 近年、ソフトウェア開発において「SBOM (Software Bill of Materials)」というワードを聞くことが増えてきました。 経済産業省が公開するソフトウェア管理に向けたSBOM (Software Bill of Materials) の導入に関する手引 ver 2.0において、「ソフトウェアコンポーネントやそれらの依存関係の情報も含めた機械処理可能な一覧リスト」として説明があるように、SBOMはソフトウェア部品表として広く認識されています。 SBOMに関する記事はこちらもおすすめ SBOMは単なる概念や考え方にとどまらず、実際に運用・共有することを前

イベント概要とこの記事の目的 法人ディベロップ課のS.Sです！ 日々、アプリケーションエンジニアとして、法人ソリューション事業部向き合いで、サービスの開発・保守を行なっております。 先日、AWS のセキュリティイベント 「Security for App Builders @ Loft #1」  に参加してきました。 私は、セキュリティ専門ではないアプリケーションエンジニアですが、 このイベントで、セキュリティへの関心がよりより湧き、 未然に防ぐ具体的なアクションに取り組まねばな、と改めて思わされました。 この記事では、 「Security for App Builders @ Loft #1」 で、何を学んだのかを記すとともに、 「アプリケーションエンジニアで、セキュリティについて気にはなっている」という方の参考になれば幸いです。 改めて、この記事の内容・目的は、以下の 4 点です。 イベント内セッションの概要を記載しつつ、学びと理解を整理する アプリケーションエンジニアのセキュリティ意識や理解を深めてもらう セッション内容の共有と、背景知識やちょっぴりの深掘り情報の共有 セキュリティ専門じゃないアプリエンジニアとして、「これから試してみたい脅威の洗い出しのやり方」のたたき台をまとめる そこそこの分量になっているので、気になるタイトルをポチポチとかいつまんで見ていただけると幸いです。 なぜ、今、アプリケーションエンジニアがセキュリティを強く意識すべきなのか OWASP Top 10 とアクセス制御の不備 冒頭で触れられていたのが  OWASP Top 10  です。 OWASP Top 10 は、Web アプリケーションの代表的なリスクを 10 項目に整理したもの 直近の正式版は  OWASP Top 10: 2021  で、たとえば A01:2021 – Broken Access Control（アクセス制御の不備） A02:2021 – Cryptographic Failures… といった分類があります セッションでは、 OWASP のデータに基づき、「アクセス制御の不備」が一定割合（3.73%）で見つかっている という話がありました。 プロのエンジニアの手で開発されたサービスにおいて、アクセス制御の不備という重大な脆弱性が、およそ4%（100件に4件）も起こり得てしまうという点に驚いたとともに、エンジニアとしてお仕事を続けていれば、誰しも1度は発生させてしまうくらいの可能性があるなと背筋が伸びました。 参考： OWASP Top 10:2021 (英語) https://owasp.org/Top10/ Broken Access Control の解説 (英語) https://owasp.org/Top10/A01_2021-Broken_Access_Control/ シフトレフト：後になるほどコストが跳ね上がる 工数やスケジュールが限られた中での開発で、往々にしてセキュリティ対応は後回しにされてしまいます。 けれども、セキュリティ対応は、 開発ライフサイクルの早い段階で取り込むほど「コストは低い」「被害は小さい」 ので、むしろ開発サイクルのはやい段階で取り組むべしというお話でした。 仕様検討（要件定義）で気づく → 仕様の一部修正で対処可能 実装中に気づく → 実装の修正で対応可能 リリース後に顧客やインシデントで気づく → 影響調査、データ復旧、顧客への説明、信用回復など大きなコスト 絵にするとこんな感じです。 この「セキュリティを開発プロセスの左側に寄せる」考え方が 、 Shift-left（シフトレフト）  です。 矛盾しているように聞こえますが、工数やスケジュールが限られているからこそ、開発サイクルの中でも、なるったけ早くに、セキュリティ対応をすべしということですね。 参考： DevSecOps とは何ですか? https://aws.amazon.com/jp/what-is/devsecops/ AWS Well-Architected Framework – Security Pillar https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/welcome.html ビルダーのための脅威モデリング さて、ここからが、今回のタイトルに直結する部分です。 （サビです） 「脅威モデリング」とは何か こちらのセッションでは、まず「脅威モデリング」の定義から整理されました。 脅威モデリングとは システムに対する脅威を特定・列挙し、 それぞれにどう対応するかを検討し、優先順位をつけるプロセス 開発ライフサイクルで置く場所は、 計画 → 設計（ここで脅威モデリング） → ビルド → テスト → デプロイ → 保守 です。 絵にするとこうです。 参考： OWASP Threat Modeling Cheat Sheet (英語) https://cheatsheetseries.owasp.org/cheatsheets/Threat_Modeling_Cheat_Sheet.html AWS Prescriptive Guidance – Threat modeling on AWS (英語) https://docs.aws.amazon.com/prescriptive-guidance/latest/security-reference-architecture/threat-modeling.html 脅威モデリングの進め方 セッションで紹介されていた流れは、以下の 4 ステップでした。 「何を作っているか」を明確にする アーキテクチャ図 データフロー図 何が問題になり得るか洗い出す チームで脅威を議論する 対応方針を決め、優先順位をつける ここでのポイントは、 可視化をして、PJメンバー全員で前提・問題の認識を揃えること → 図がないと、どこに攻撃面があるか議論できない 1 回きりではあまり意味がなく、ライフサイクルに組み込む必要がある という点です。 絵にするとこうです。 STRIDE など、代表的なフレームワーク 脅威モデリングでは、次のようなフレームワークが紹介されました。 STRIDE DREAD PASTA（Process for Attack Simulation and Threat Analysis） Trike VAST（Visual, Agile, and Simple Threat） OCTAVE（Operationally Critical Threat, Asset, and Vulnerability Evaluation） 今回、取り上げられていたのは  STRIDE  でした。 網羅性が高く、チームでの議論の「型」として使いやすい のが理由です。 STRIDE の 6 要素 S: Spoofing identity（なりすまし） 攻撃者が正当なユーザーやシステムであるかのように振る舞うこと 例: 攻撃者が他人のIDとパスワードを不正に入手し、そのユーザーになりすましてシステムにログインする 例: 偽のWi-Fiアクセスポイントを設置し、正規のネットワークであるかのように見せかけて接続させる T: Tampering with data（改ざん） データや通信内容を許可なく変更すること 例: オンラインバンキングの通信を傍受し、送金金額や送金先口座番号を書き換える 例: Webサイトの設定ファイルを書き換え、訪問者を悪意のあるサイトへリダイレクトさせる R: Repudiation（否認） ユーザーが行った操作やアクションを「やっていない」と主張できる状態、またはその証拠がないこと 例: ログ機能が不十分なシステムで、従業員が不正なデータ削除を行ったが、「自分はやっていない」としらを切られ、証拠が出せない 例: 電子署名がないメールで契約の承認を行い、後になって「そのようなメールは送っていない」と主張される I: Information disclosure（情報漏えい） 機密情報が権限のない人間に閲覧・公開されること 例: データベースの設定ミスにより、顧客のクレジットカード情報がインターネット上で誰でも閲覧できる状態になる 例: エラーメッセージに詳細なシステム内部情報（パスやDB構造など）が表示され、攻撃者にヒントを与えてしまう D: Denial of service（サービス拒否） 正当なユーザーがサービスやリソースを利用できない状態にすること 例: Webサーバーに大量のアクセス（DDoS攻撃）を送りつけ、サーバーをダウンさせて一般ユーザーが閲覧できないようにする 例: アカウントロック機能を悪用し、わざとパスワードを何度も間違えて特定ユーザーのアカウントをロックさせる E: Elevation of privilege（権限昇格） 本来持っている権限以上の操作ができるようになること 例: 一般ユーザーとしてログインした攻撃者が、システムの脆弱性を突いて管理者（root/admin）権限を奪取する 例: URLのパラメータを書き換えることで、本来アクセスできない他人の注文履歴ページを閲覧・操作する これを「自分たちのシステム構成図・データフロー図」に対して当てはめていくことで、脅威モデリングができます。 参考： Microsoft – The STRIDE Threat Model (英語) https://learn.microsoft.com/en-us/azure/security/develop/threat-modeling-tool-threats OWASP Threat Modeling Cheat Sheet 内の STRIDE 解説 (英語) https://cheatsheetseries.owasp.org/cheatsheets/Threat_Modeling_Cheat_Sheet.html#stride ドメイン特有の脅威に目を向ける 一般的に、下記のような 共通の脆弱性  は見つけやすいですが、 SQL インジェクション XSS 典型的な認証バイパス ビジネス／ドメイン特有の脅威  は見逃されがちです。 例： EC サイト 在庫数や価格の改ざん ポイント／クーポンの不正利用 B2B SaaS テナント分離の不備による他社データ閲覧 管理権限の誤委譲・誤設定 サブスクリプションサービス 無料トライアルの不正延長 請求先のなりすまし 脅威モデリングでは、こういった「そのサービス特有のリスク」を意識的に洗い出せる点が大きな価値です。（ドメイン理解の深い事業会社のエンジニアの価値発揮できるポイントですね） チームでやることの意味 脅威モデリングは、セキュリティ専門家だけの作業ではない、「チームでやるべきことである」ということが強調されていました。 プロダクトオーナー アプリケーションエンジニア インフラ／SRE セキュリティ担当 など複数ロールで実施することで、 「多様なペルソナ（攻撃者像・利用者像）」を出し合える 見落としが減る という効果があります。（今の時代は、更に、AI というもう一人の存在の力も借りるのも有効ですね） セキュリティ専門じゃない自分が「脅威の洗い出し」をどう始めたいか 正直な所、私はまだ、日々の開発の中で、 本格的な脅威モデリングを回せていないです。 （新規開発や保守をしていく上での脆弱性診断や対策は行ってはいますが） このセッションを聞いて、「まずはこのくらいのスコープからなら試せそう」と感じたものがあったので、簡単に流れを書いておこうと思います。 新しい機能や API を作るときだけでもよいので対象を絞る ざっくりした構成図・データフロー図を描く（ホワイトボードや Miro 等の書き出せるものでOK） STRIDE の 6 つを観点にして 、「なりすましは？」「改ざんは？」「情報漏えいは？」… を見ていく 出てきた脅威のうち 「すぐ直せそうなもの」 「影響が大きいもの」 を対策に落とす AI を活用した脅威モデリング支援 後半戦では、 AI を活用して脅威モデリングの手間を減らす という話が出ていました。 登場したのは「AI エージェント」的なコーディング／解析支援のイメージで、AWS でいえば  Amazon Q Developer  ですね。（今は、 kiro  ですね） AI にやらせる部分 vs 人間がやる部分 スピードや網羅性に関しては、AI の方が人間よりも優れていることが多いので、うまくAIと人間で分業をして協業することが重要そうだなと感じました。 AI に任せやすい部分： ワークロードの図式化 アーキテクチャ説明文から簡易図を生成させる 想定される脅威の洗い出し 「この構成に対して STRIDE 観点で脅威を列挙して」 想定される脅威への一般的な対応策の候補出し リスク評価のたたき台 「影響度が高そうな順に並べて」 人間が担うべき部分： 脅威モデリングそのものの意義と目的の理解 事業やサービスのドメイン周りの脅威洗い出し 「何を対象に、何のために」脅威モデリングするかの設定 事業戦略・リスク許容度に基づく  優先順位付けと最終判断 「 AI は“脅威のたたき台”を出してもらうところまで 」と割り切り、 最後の判断と、プロダクト側への落とし込みは人間がやる といった線引きで使っていきたいと感じました。 セキュリティのシフトレフトと AI 活用 攻撃は 100% 防げないが、被害は限定できる このセッションは、 「リスクをゼロにはできないが、 被害を限定し、復旧を容易にすることはできる」 という前提から出発していました。 例として挙げられたランサムウェア攻撃の典型フロー： ネットワークスキャン 脆弱性の調査・悪用 ランサムウェアの設置 ランサムウェアがターゲットシステムで動作 情報の窃取や暗号化 どこか一段階でも早く検知・防御できれば、 「完全な被害」から 「一部のシステムだけ」「一部データだけ」で済む可能性が高まる という話です。 DevSecOps と AI の進化 2015年ごろから、セキュアコーディングについて、叫ばれていたが、業務に落とし込むことが物理的な制約のため難しかったけれど、2025年現在のAI の進歩により、実現可能になったので、今こそ改めて、セキュアコーディングへチャレンジをしていけるのではないかというお話でした。 2015 年ごろ DevSecOps という言葉が広がり始める ただしセキュアコーディングの学習コストが大きい 静的解析ツールなどから出る大量のアラートを人力でさばくのは現実的でない 2025 年 AI コーディングエージェントが静的解析結果を解釈し、「どこをどう直すか」まで提案 AWS の例では Amazon Q Developer による 調査（現状のコード理解、セキュリティチェック） ビルド（修正案の提案・コード生成） テスト（テストコード生成） デプロイ（PR レビュー支援、ドキュメント生成） といったフローが紹介されていました。 確かに、やりたい気持ちはあれど、なかなか手を出せていなかったですが、AI エージェントの誕生によって、良い意味で、もうそんな言い訳もできなくなったなと思いました。（← もうやってないは、怠慢かも?） 参考： DevSecOps とは何ですか? https://aws.amazon.com/jp/what-is/devsecops/ Amazon Q Developer でのコード解説や修正の例 https://docs.aws.amazon.com/amazonq/latest/qdeveloper-ug/what-is-q-developer.html セキュリティトレーニングのテーマ アプリケーションエンジニア向けに、特に挙げられていたテーマは、 ガバナンスとコンプライアンス セキュアコーディング リスクマネジメント ここでも AI を「学びの相棒」として使う例として、紹介されていました。 利用 OSS やライブラリについて 「このライブラリに既知の脆弱性はあるか？」 「この CVE（脆弱性）の影響度と対策を教えて」 自分のコードに対して 「ハードコードされたパスワードやシークレットがないか探して」 「この関数にセキュリティ上の問題はありそうか？」 これについては、既に行なっていましたが、すぐに試せて、かつ、有効な使い方だなと改めて思いました。 IAM 権限設計と IAM Access Analyzer IAM の権限設計に関しても重要なポイントがありました。 「最小権限を人間だけで完全に設計しきろうとすると、どうしても穴が出やすい」 そこで活用が推奨されていた AWS サービスが  IAM Access Analyzer  です。 AWS Identity and Access Management Access Analyzer https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html 機能の例： IAM ポリシーを解析し、「外部アカウントからアクセス可能なリソース」を検出 ポリシーの提案（Policy generation） 実際のアクセスログを分析して、「このロールに必要な最小権限」のポリシー案を生成 ここでも AI を組み合わせると、 「このポリシー JSON はどの権限をどこまで許可しているか、自然言語で説明して」 「最小権限化するために、削れそうなアクションはどれか？」 といった質問を投げることで  理解と設計の速度を上げられる 、という話でした。 自分自身、インフラ側への苦手意識が強いですが、こういった活用法を用いることで、AIエージェントの力を借りつつ、知識習得と堅牢な実装の両方を猛スピードで行なっていけるのでは？とワクワクしました。 マネージドサービスと認証・認可はビジネス差別化になり得る AI が書いたコードのセキュリティオーナーは誰か？ 登壇者の方の問いかけ： 「AI が生成したコードをそのまま本番投入してよいのか？ その結果に対するセキュリティの責任は誰が持つのか？」 結論としては、 「 全員がセキュリティのオーナー 」 あくまで、AI は「候補」を出してくれる 存在 それを採用するかどうか、どうレビューするかは人間と組織の責任 ということでした。 本当にこの通りで、最後に出す判断を下すのは我々人間なので、これまで以上に、出すものは、本当にこれで問題がないのかは、厳格に見極める必要があるなと感じました。 Culture of Security AWS では、社内外で継続的に、 セキュリティに関する発信 勉強会 事例共有 インシデントからの学びの共有 を行い、トップダウンで  「Culture of Security」  を作っているという紹介がありました。 組織やPJ のトップが、セキュリティへの関心や発信を積極的に行うことが、セキュリティへの意識・行動を想起するには重要とのことでした。 参考： AWS セキュリティ文化 https://aws.amazon.com/jp/security/culture-of-security/ AWS Security Blog 一覧 https://aws.amazon.com/blogs/security/ 認証・認可設計は「ビジネス差別化」にもなる 特に印象に残ったのが、 「優れた認証・認可の仕組みは、 セキュリティ対策であると同時に、ビジネスの差別化要因になる」 というお話でした。 各サービスごとにバラバラなユーザー管理をしている ユーザー体験：ログインが面倒、アカウントが分散 事業側：サービス横断の体験・クロスセルが難しい 統合された認証・認可基盤がある 一度ログインすれば複数サービスをシームレスに利用可能 ユーザー行動を横断的に把握できる セキュリティ設計がそのまま UX と事業戦略に効いてくるという例ですね。 認可アーキテクチャの用語整理 認可ロジックをアプリコードにべた書きせず、外部の仕組みに任せやすくするための概念として、以下の用語が紹介されていました。 PEP: Policy Enforcement Point 実際のアクセス要求をブロック／許可する「ゲート」 PDP: Policy Decision Point ポリシーに基づき「許可／拒否」の判定を行うコンポーネント PAP: Policy Administration Point ポリシー（ルール）を管理・編集するコンポーネント PIP: Policy Information Point 判定に必要な属性情報（ユーザー属性、リソース属性など）を提供するコンポーネント この分離により、アプリ側コードは「PEP と対話するだけ」で済み、 認可ルール自体は外部で一元管理しやすくなるとのことでした。 参考： AWS – Amazon Verified Permissions（ポリシーベースの認可サービス） https://aws.amazon.com/jp/verified-permissions/ セキュリティ専門じゃないアプリケーションエンジニアとして、始めてみたい「脅威の洗い出し」（＋AI 活用） 最後に、これまでのセッション内容を踏まえて、 実際に現場で「脅威の洗い出し」をどう始めてみたいか を、具体的な手順として書いてみます。 これから試してみたい「ざっくり手順」 まず、 自分用の「脅威の洗い出し」のざっくり手順（案） はこんなイメージです。 対象を決める いきなり全システムではなく、「これから作る 1 機能 / 1 API」くらいにスコープを絞る ざっくり図を描く 画面遷移 or API と外部サービスの関係、データフローを簡単に図にする 守りたいものを挙げる ユーザー情報、決済情報、社内の機密データ、ポイント残高 など STRIDE を観点に「脅威のたたき台」を AI に出してもらう AI の結果を見ながら、チームで 60〜90 分だけ議論する 「今すぐ対応するもの」を 2〜3 個だけ決めて、実装・レビューに反映する 仕様書を AI に渡して「脅威のたたき台」を作る 要件定義書・仕様書・画面遷移図などを AI に渡して、 「この仕様から想定されるセキュリティリスクを、STRIDE の観点で列挙して」  と依頼する その出力をもとに、チームで 60〜90 分の脅威モデリングミーティングを行う 「AI は“思いつきの網羅”担当、人間は評価と意思決定担当」  くらいに役割分担するイメージで進められたらと思います。 依存ライブラリの脆弱性を AI に要約させる これもすぐにできて、セキュリティリスクを抑える有効な手段なので、書いておきます。 npm audit ​ などの結果や、SCA ツールのレポートを AI に渡し、 「特に優先度が高いものはどれか？」 「どのライブラリは自分たちのアーキテクチャでは影響が小さそうか？」 を整理してもらう これにより、 「アラートの山」から「今すぐ直すべき山」を特定 して、優先度の高い脆弱性を潰せる可能性を高めます。 既存コードベースの「簡易セキュリティ健診」 重要なモジュールや API ハンドラを中心に、AI に次のような観点で探してもらう ハードコードされたパスワード／API キー 認証・認可チェックが抜けていそうなエンドポイント 危険な関数（ eval ​ など）の利用 その結果から「怪しい箇所リスト」を作り、 人間が一つずつレビューしていく AI には広く粗く見てもらって、最後の判断は人間で、という分業で進められたらと思います。 セキュリティ文化を根付かせる動き 脅威の洗い出しを 一度きりのイベントにしない ために、 次のような小さな仕掛けをチーム内で提案してみたいと思っています。 大きな機能追加のたびに 「脅威モデリングをやったか？」をチェックリストに入れる 月 1 回程度の 「インシデント／ヒヤリハット共有会」を開く 上長に、セキュリティ文化を根付かせる発信やアクションを提案する （この記事を読んで頂こう） ここにあげた手段を提案し、発信や実際に定期的イベントを行う いきなり、大きく完璧にやろうとすると、大抵続かない、うまくいかないので、まずは 「新しい機能を作るタイミングで、脅威モデリングを行う」 ところから始めてみたいと考えています。 ゆくゆくは、組織単位で、例えば上記のようなことが浸透していけることが最終ゴールにできればなと思います。 現時点では、ここに書いた「脅威の洗い出しのやり方」はあくまで これから試してみたい案 です。 実際に回してみてうまくいった点・うまくいかなかった点が見えてきたら、続編としてアップデートしていきたいと思います。 追記 開発で携わっているPJ で、早速、新規API を作成する機会ができたので、早速、脅威モデリングをお試しでやってみようとなりました。 初回なので、あまりに厳密にやりすぎず、脅威モデリングにおいて、重要な要素をシンプルに抽出して、進めていきます。 「実際に、やってみた」の記事も書けたら、書きます。

はじめに こんにちは、NTTドコモグループの 現場受け入れ型インターンシップ2025 に参加した 博士1年の樋口 です。 私が参加したポストは、 【D3】脅威インテリジェンスを生成・活用するセキュリティエンジニア/アナリスト です。前半は Network Analytics for Security PJ（以下、NA4Sec）、後半は Metemcyber PJ（以下、Metemcyber）に参加し、幅広い内容を学ぶことができました。 本体験記が、来年以降に参加を検討されている方の一助となりましたら幸いです。 はじめに インターンシップの説明 参加した経緯 概要 SBOM SBOMとは何か フォーマットごとの差分 SPDX CycloneDX 小括 Threatconnectome Threatconnectomeの紹介 抱える課題 実施した調査 方針 OSS Review Toolkit (ORT) 概要 環境構築 実行方法 考察 ScanCode 概要 環境構築 実行方法 考察 本調査から得られたこと まとめ 参考文献 インターンシップの説明 参加した経緯 きっかけは、論文の査読コメントに書かれていた一言でした。 main issue: Why this research is important? Threat model should be added to this manuscript. 前半については、単に私の書き方が悪かっただけなので、すぐに修正できました。 一方で、後半に書かれていた「Threat model」とは何なのかが気になり、調べ始めたことが、脅威インテリジェンスに興味を持つ最初のきっかけになりました。 調べていくうちに、実際の調査方法や扱う範囲の広さから、「これを一人で独学するのはかなり大変そうだ」と感じるようになりました。 どうせ学ぶなら、最先端で業務として脅威インテリジェンスに取り組んでいる現場で学びたい。そう考えて情報を探していたところ、このインターンシップに出会いました。 また、私自身が博士課程に在籍していることもあり、インターンシップに申し込んでよいのか正直迷っていました。 そんな中、NA4Sec の神田さんから「気にせず申し込んで大丈夫」と背中を押していただけたことも、参加を決める大きなきっかけになりました。 概要 インターンシップは2週間にわたって実施され、1 週目は本ポストにも参加している脇本くんと同じ内容に取り組み、2 週目は互いに異なる活動に取り組みました。 本ポストのインターン生だった 脇本くんのインターンシップ体験記 はすでに公開されていますので、よろしければそちらもあわせてご覧ください。 私は、2週間のインターンシップで以下の活動を行いました。 1週目 (Na4Secチーム): Cobalt Strike の調査/分析・ハンズオン 1 フィッシングサイトに関する調査/分析・ハンズオン 2 2週目 (Metemcyberチーム): SBOM 生成ツール「Threatconnectome」の研究開発 2週目の Metemcyber では朝会があり、私も参加させていただきました。 毎朝、その日に何を進めるのか、どの程度進捗しているのかを共有するのですが、とても新鮮でした。「今週の目標が何で、いまどの位置にいるのか」をチーム全体でそろえることで、進捗や課題の共有がとてもスムーズになるのだと実感しました。 以降では、このような 2週目での経験を踏まえつつ、SBOM 生成ツール「Threatconnectome」の研究開発について、主にお話ししていきます。 SBOM SBOMとは何か SBOMとは「Software Bill of Materials」の略称で、ソフトウェアがどのような要素から構成されているのかを一覧表としてまとめたものを指します。 経済産業省の 「ソフトウェア管理に向けたSBOM（Software Bill of Materials）の導入に関する手引 Ver 2.0」 では、SBOM について次のように説明されています。 SBOM とは、ソフトウェアコンポーネントやそれらの依存関係の情報も含めた機械処理可能な一覧リストである。SBOM には、ソフトウェアに含まれるコンポーネントの名称やバージョン情報、コンポーネントの開発者等の情報が含まれ、OSS だけではなくプロプライエタリソフトウェアに関する情報も含めることができる。また、SBOM をソフトウェアサプライチェーンの上流から下流に向かって組織を越えて相互共有することで、ソフトウェアサプライチェーンの透明性を高めることが期待されており、特に、コンポーネントの脆弱性管理の課題に対する一つの解決策として期待されている。 フォーマットごとの差分 SBOM は、一般的に次の 2 つのフォーマットで生成されることが多いです。 ただし、極端な話、下記 2 つに準拠していなくても「SBOM」と名乗ること自体は可能である点には注意が必要です。 SPDX CycloneDX 以降では、実際にこの 2 つのフォーマットを生成し、生成された JSON ファイルを確認しながら、どのような違いがあるかを比較してみましょう。 ここでは、 コンテナ／ファイルシステム向けのセキュリティスキャナ兼 SBOM 生成ツールである Trivy を使い、コンテナイメージ nginx:latest から SBOM を作成します。 SPDX SPDXは、Linux Foundationが策定している SBOM フォーマットです。 SPDXの公式サイト では、SPDX を次のように説明しています。 SPDX is an open standard for communicating software bill of material information, including provenance, license, security, and other related information. また、SPDX は国際標準規格 ISO/IEC 5962:2021 としても認定されており、 ソフトウェアのライセンスやコンプライアンス、セキュリティなどの情報をやり取りするための標準として位置づけられています。 これらを踏まえると、SPDX は「ソフトウェアに含まれるコンポーネントやライセンス情報、著作権情報などを詳細かつ厳密に記述できる SBOM フォーマット」と言えます。 特に、法務・コンプライアンスの観点での活用を想定しており、ライセンス遵守状況の確認や監査対応に向いています。 それでは、SPDX の SBOM を生成してみましょう。以下に、 trivy を用いた生成例を示します。 trivy image --format spdx-json --output sbom.spdx.json nginx:latest このコマンドを実行すると、sbom.spdx.json という SPDX 形式の SBOM ファイルが出力されます。 生成されたJSONファイルは以下のようになります(一部抜粋)。 { " name ": " apt ", " SPDXID ": " SPDXRef-Package-4289b9e5f32d574b ", " versionInfo ": " 3.0.3 ", " supplier ": " Organization: APT Development Team \u003c deity@lists.debian.org \u003e ", " downloadLocation ": " NONE ", " filesAnalyzed ": false , " sourceInfo ": " built package from: apt 3.0.3 ", " licenseConcluded ": " GPL-2.0-or-later AND LicenseRef-aba21f0b27260cd4 AND BSD-3-Clause AND MIT AND GPL-2.0-only ", " licenseDeclared ": " GPL-2.0-or-later AND LicenseRef-aba21f0b27260cd4 AND BSD-3-Clause AND MIT AND GPL-2.0-only ", " externalRefs ": [ { " referenceCategory ": " PACKAGE-MANAGER ", " referenceType ": " purl ", " referenceLocator ": " pkg:deb/debian/apt@3.0.3?arch=amd64 \u0026 distro=debian-13.2 " } ] , 上の例では、 apt パッケージについての情報が含まれています。 このようなエントリが多数並ぶことで、コンテナイメージ内部のパッケージ構成とそれぞれのライセンス情報を、SPDX 形式の SBOM として機械可読に表現できます。 また、ライセンス管理やコンプライアンス管理をしやすくするために、このフォーマットが設計されていることがわかります。 CycloneDX CycloneDX は OWASP が主導している SBOM フォーマットで、 CycloneDXの公式サイト では次のように紹介されています。 OWASP CycloneDX is a full-stack Bill of Materials (BOM) standard that provides advanced supply chain capabilities for cyber risk reduction. さらに、CycloneDX 自身も Ecma International の標準（ECMA-424）として策定されており、 ソフトウェアサプライチェーンにおけるサイバーリスク低減を強く意識した仕様になっています。 このことから、CycloneDX は「セキュリティや脆弱性管理への利用を強く意識して設計された SBOM フォーマット」と言えます。 依存関係の構造や、脆弱性スキャナ・セキュリティツールとの連携を前提としたフィールドが充実しており、セキュリティ運用のワークフローに組み込みやすい点が特徴です。 それでは、CycloneDX の SBOM を生成してみましょう。以下に、 trivy を用いた生成例を示します。 trivy image --format cyclonedx --output sbom.cyclonedx.json nginx:latest こちらのコマンドでは、CycloneDX形式のSBOMがsbom.cyclonedx.jsonとして出力されます。 生成されたJSONファイルは以下のようになります(一部抜粋)。 { " components ": [ { " bom-ref ": " pkg:deb/debian/apt@3.0.3?arch=amd64&distro=debian-13.2 ", " type ": " library ", " supplier ": { " name ": " APT Development Team <deity@lists.debian.org> " } , " name ": " apt ", " version ": " 3.0.3 ", " licenses ": [ { " license ": { " id ": " GPL-2.0-or-later " } } , { " license ": { " name ": " curl " } } , { " license ": { " id ": " BSD-3-Clause " } } , { " license ": { " id ": " MIT " } } , { " license ": { " id ": " GPL-2.0-only " } } ] , " purl ": " pkg:deb/debian/apt@3.0.3?arch=amd64&distro=debian-13.2 " } ] , " dependencies ": [ { " ref ": " nginx:latest ", " dependsOn ": [ " pkg:deb/debian/apt@3.0.3?arch=amd64&distro=debian-13.2 " ] } ] } ref と dependsOn の組み合わせで、「どのコンポーネントがどのコンポーネントに依存しているか」という依存関係のグラフを定義しています。 これによって、あるライブラリに脆弱性が見つかったときに、以下をツール側で自動的に追跡できるようになります。 どのイメージがそのライブラリに依存しているか 依存関係を辿ったとき、どこまで影響が波及するか 上記項目が入ることで、「どのコンポーネントがどのコンポーネントに依存しているか」を表現できていることが分かります。 このように、CycloneDX の JSON をそのままセキュリティツールが読み取ることで、「どのコンポーネントにどんな脆弱性やライセンスリスクがあるか」や「そのコンポーネントに依存しているのはどの部分か」といった情報を機械的に解析できるようになり、結果として脆弱性や依存関係の管理がしやすくなります。 小括 一般的には、次のように整理できます。 SPDX ：ライセンス管理やコンプライアンス対応に向いている CycloneDX ：コンポーネントの脆弱性管理や依存関係の把握に向いている 以上を踏まえて、要点を表にまとめると以下の通りです。 観点 SPDX CycloneDX 主な用途 ライセンス・著作権・コンプライアンスを主目的として発展 サプライチェーンにおける脆弱性・依存関係・セキュリティ運用を意識して設計 提唱元 Linux Foundation OWASP 脆弱性・影響範囲の追跡 可能だが、フォーマットとしては汎用寄り CVE 突き合わせや影響範囲の追跡をツール側で行いやすい設計 今回の Trivy での出力例 --format spdx-json --format cyclonedx ざっくりイメージ 「法務・ライセンスに強い部品表」 「セキュリティ運用に強い部品表」 Threatconnectome 以降では、SBOM をインポートして脆弱性管理を行う Metemcyber のOSSプロジェクト Threatconnectome を前提に議論するため、まずその概要を紹介します。 Threatconnectomeの紹介 Threatconnectomeは現在、 GitHubで公開 されており、以下のように説明されています。 Threatconnectome supports vulnerability management in industries where products are hard to update, such as automotive, manufacturing and communications infrastructure. ここからわかるように、自動車・製造業・通信インフラなど、製品のアップデートが難しい領域向けの脆弱性管理プラットフォームとして提供されています。つまり、先ほどのようにSBOMを生成し、それをわかりやすく管理できるプラットフォームとなっています。 なお、2025年11月現在、SPDX2.3、CycloneDX1.6がサポート対象となっています。 先ほど紹介した GitHub リポジトリでは、Threatconnectome のデモ環境が公開されているため、実際にアクセスしてみましょう。 デモ環境へのアクセス方法は、 リポジトリ内の README に記載されています。 アクセスすると、まず次のような画面が表示されます。 もし脆弱性が検知された場合は、下記のようにアラート画面が表示され、 誰が対応を担当するか、といったアサイン操作などを行うことができます。 画面中央の Uploadから、ユーザが生成した SBOM をアップロードすることも可能です。 実際に、先ほど生成した CycloneDX 形式の SBOM をアップロードしてみると、次のように表示されます。 このように、Threatconnectome は「生成した SBOM を取り込み、脆弱性の有無をチェックし、 必要に応じてアラートや担当者アサインまで行える脆弱性管理プラットフォーム」として動作していることが分かります。 抱える課題 Threatconnectome では、SBOMをインポートし、Trivy が利用している脆弱性データベースである Trivy DB の情報を用いて脆弱性管理を行っています。 現在は Trivy および Syft が生成した SBOM のみを入力対象としていますが、将来的には対応する SBOM 生成ツールの種類を広げていきたいという課題を抱えています。 ここで問題になるのが、Linux ディストリビューションのパッケージマネージャ（dpkg / apt / rpm / apk など）で管理される OS パッケージの脆弱性検知です。 Trivy DB は Ubuntu / Debian 系の脆弱性情報を、ソースパッケージ（Source Package）の名前をキーとして管理しています。 Ubuntu / Debian 系では、ビルドの単位となる「ソースパッケージ」と、実際にインストールされる「バイナリパッケージ」が区別されています。 SrcName は、このソースパッケージ名を SBOM 上で表現するために、Trivy が独自プロパティとして付与しているものです。 Trivy が生成する CycloneDX 形式の SBOM には、次のような項目が存在します。 { " name ": " aquasecurity:trivy:SrcName ", " value ": " openssl " } , Trivy で生成した CycloneDX 形式の SBOM では、 properties フィールドに生成ツール固有のメタデータが出力されます。 そのうち、Trivy 固有の項目である aquasecurity:trivy:SrcName の value がソースパッケージ名を表します。 しかし、同じコンポーネントには name として次のような情報が記載されています。 " name ": " libssl3t64 ", Trivy が生成する CycloneDX 形式の SBOM では、この name がバイナリパッケージ名を表すことが多く、上記からわかるように両者は必ずしも一致しません。 その結果、SBOM から得た情報だけでは、ソースパッケージ名と正しく突き合わせて脆弱性を検知することが難しくなる可能性があります。 また、ソースパッケージ名を扱うためには SBOM 中に SrcName が含まれている必要がありますが、その有無や表現方法は SBOM 生成ツールに依存します。 このため、対応ツールを拡張するにあたっては、各ツールの出力における SrcName 相当情報の扱いを確認する必要があります。 実施した調査 方針 本調査では、SBOM 生成ツールを用いて実際に SBOM ファイルを生成し、主に次の点を確認しました。 生成される SBOM のフォーマット 独自プロパティSrcName (または同等の情報）の有無と表現方法 その結果を踏まえ、各 SBOM 生成ツールが出力する SBOM を Threatconnectome が処理できるかどうかを判断しました。 なお、OS パッケージの分類やソースパッケージ名／バイナリパッケージ名の違い、そこから生じる問題点については、 最近公開されたエンジニアブログエントリー でも整理されています。 本調査でも同様の整理に基づいて問題を位置づけています。 本調査で対象としたツールは以下の 2 つです。 OSS Review Toolkit (ORT) ScanCode OSS Review Toolkit (ORT) 概要 OSS Review Toolkit（以下 ORT） は、ソフトウェアプロジェクトの管理と分析を支援するツールキットとして提供されています。 複数の機能に分かれており、それぞれ Analyzer、Scanner、Advisor、Evaluator、Reporter の 5 つのコンポーネントが独立して動作しつつ、結果を連携させて処理を進めることができます。 今回、CycloneDX 形式の JSON ファイルを生成するためには、Analyzer → Reporter の順に実行する必要があります。 なお、本調査では「OS パッケージが検知できるか」を確認するため、test ディレクトリに OS パッケージのみを配置した環境を用意しました。 環境構築 今回は、Gradle 経由で ORT をインストールしました。 Gradle 経由でインストールした場合、ORT を起動するための実行スクリプトが cli/build/install/ort/bin/ort というパスに作成されます。 以降は、この方法でインストールした ORT を前提に説明します。 実行方法 # 通常の実行例 ./ort analyze --input-dir test --output-dir . # 短縮オプションを用いる場合 ./ort analyze -i test -o . # ORT のルートディレクトリから直接実行する場合 cli/build/install/ort/bin/ort analyze -i test -o . 上記コマンドを実行すると、Analyzerの結果としてYAMLファイルが生成されます。 --- repository: vcs: type: "Git" url: "https://github.com/oss-review-toolkit/ort" revision: "d47c9ac5d6f922020aa8ddc14605686e2bf955fa" path: "cli/build/install/ort/bin/test" vcs_processed: type: "Git" url: "https://github.com/oss-review-toolkit/ort.git" revision: "d47c9ac5d6f922020aa8ddc14605686e2bf955fa" path: "cli/build/install/ort/bin/test" config: {} analyzer: start_time: "2025-09-02T06:36:17.500581Z" end_time: "2025-09-02T06:36:17.785581Z" environment: ort_version: "66.1.0" build_jdk: "21.0.7+6-LTS" java_version: "21.0.8" os: "Mac OS X" processors: 8 max_memory: 8589934592 variables: HOME: "/Users/sectu" SHELL: "/bin/zsh" TERM: "xterm-256color" tool_versions: {} config: allow_dynamic_versions: false enabled_package_managers: - "Bazel" - "Bower" - "Bundler" - "Cargo" - "Carthage" - "CocoaPods" - "Composer" - "Conan" - "GoMod" - "GradleInspector" - "Maven" - "NPM" - "NuGet" - "PIP" - "Pipenv" - "PNPM" - "Poetry" - "Pub" - "SBT" - "SpdxDocumentFile" - "Stack" - "SwiftPM" - "Tycho" - "Unmanaged" - "Yarn" - "Yarn2" skip_excluded: false result: projects: - id: "Unmanaged::ort:d47c9ac5d6f922020aa8ddc14605686e2bf955fa" definition_file_path: "" declared_licenses: [] declared_licenses_processed: {} vcs: type: "" url: "" revision: "" path: "" vcs_processed: type: "Git" url: "https://github.com/oss-review-toolkit/ort" revision: "d47c9ac5d6f922020aa8ddc14605686e2bf955fa" path: "cli/build/install/ort/bin/test" homepage_url: "" scopes: [] packages: [] scanner: null advisor: null evaluator: null resolved_configuration: package_curations: - provider: id: "DefaultDir" curations: [] - provider: id: "DefaultFile" curations: [] 次に、この YAMLファイルをReporterに渡してCycloneDX形式のSBOMを生成します。 ./ort report -f CycloneDX --ort-file analyzer-result.yml --output-dir . これにより、 bom.cyclonedx.json が生成されます。 { " bomFormat " : " CycloneDX ", " specVersion " : " 1.6 ", " serialNumber " : " urn:uuid:2b46dd12-caa0-40c2-a5f9-8ca2958fc134 ", " version " : 1 , " metadata " : { " timestamp " : " 2025-09-02T06:23:22Z ", " tools " : { " components " : [ { " type " : " application ", " name " : " OSS Review Toolkit ", " version " : " 66.1.0 " } ] , " services " : [ ] } , " component " : { " type " : " file ", " bom-ref " : " https://github.com/oss-review-toolkit/ort.git@d47c9ac5d6f922020aa8ddc14605686e2bf955fa ", " name " : " https://github.com/oss-review-toolkit/ort.git ", " version " : " d47c9ac5d6f922020aa8ddc14605686e2bf955fa " } , " licenses " : [ { " expression " : " CC0-1.0 " } ] } , " externalReferences " : [ { " type " : " vcs ", " url " : " https://github.com/oss-review-toolkit/ort.git ", " comment " : " URL to the Git repository of the projects " } ] } 考察 生成された yaml、json を確認すると、 packages が空であることから、今回はパッケージ情報が取得できていないことが分かります。 今回用意した test フォルダの内容に対して、ORT では OS パッケージを取得できていない可能性が高いと考えられます。 また、ORT の公式ドキュメントによると、 The analyzer is a Software Composition Analysis (SCA) tool that determines the dependencies of software projects inside the specified version-controlled input directory ( -i ). It is the only mandatory tool to run from ORT as its output is the input for all other tools. Analysis works by querying the detected package managers; no modifications to your existing project source code, like applying build system plugins, are necessary for that to work if the following preconditions are met と記されています。 上記の通り、Analyzer は ORT の他ツールすべての入力となるコンポーネントであり、同時に「ソフトウェアプロジェクトの依存関係を解析する SCA ツール」として提供されています。 この設計上の前提から、OS パッケージのような「プロジェクト外のベースイメージ由来のパッケージ」については、そもそも取得対象になっていないのではないかと考えられます。 なお、関連ツールとして tern というツール では OS パッケージが検知できるとされていますが、私のインターン期間中には環境構築が間に合わず、実際に確認することはできませんでした。 ただし、少なくとも現時点で得られた結果からは、「ORT の Analyzer / Reporter の組み合わせだけでは、今回の test ディレクトリに含めた OS パッケージを CycloneDX SBOM として取得することはできなかった。」と結論付けました。 ScanCode 概要 ScanCode は、OSS のライセンスやパッケージ情報を解析し、SBOM などを生成できるツールです。比較的簡単にインストール・実行でき、CI/CD パイプラインにも組み込みやすい設計になっています。 また、複数のパイプラインが用意されており、コンテナイメージを対象とした SBOM 生成も可能です。 環境構築 まず、リポジトリをクローンして Docker イメージをビルドします。 git clone https://github.com/aboutcode-org/scancode.io.git cd scancode.io make envfile docker compose build Apple Silicon を採用した Mac を使う場合、docker-compose.yml を編集します。 Docker 側は Linux 向けの arm64 イメージを使おうとしますが、Apple Silicon 自体も arm64 であるため、macOS 向けの arm64 用リポジトリに向かってしまい、うまく動作しないケースがあります。 これを解決するためには、 platform: linux/amd64 を追加する必要があります。 そのため、本調査では web, worker, clamav サービスに以下の設定を追加し、Linux の amd64 としてコンテナを動かすようにしました。 web: build: . command: > sh -c " ./manage.py migrate && ./manage.py collectstatic --no-input --verbosity 0 --clear && gunicorn scancodeio.wsgi:application --bind :8000 --timeout 600 --workers 8 ${GUNICORN_RELOAD_FLAG:-}" platform: linux/amd64 env_file: - docker.env expose: - 8000 volumes: - .env:/opt/scancodeio/.env - /etc/scancodeio/:/etc/scancodeio/ - workspace:/var/scancodeio/workspace/ - static:/var/scancodeio/static/ depends_on: db: condition: service_healthy redis: condition: service_started chown: condition: service_completed_successfully worker: build: . # potential db migrations が完了するまで "web" を待つ command: > wait-for-it --strict --timeout=600 web:8000 -- sh -c " ./manage.py rqworker --worker-class scancodeio.worker.ScanCodeIOWorker --queue-class scancodeio.worker.ScanCodeIOQueue --verbosity 1" platform: linux/amd64 env_file: - docker.env volumes: - .env:/opt/scancodeio/.env - /etc/scancodeio/:/etc/scancodeio/ - workspace:/var/scancodeio/workspace/ depends_on: - redis - db - web - chown clamav: image: docker.io/clamav/clamav:latest platform: linux/amd64 volumes: - clamav_data:/var/lib/clamav - workspace:/var/scancodeio/workspace/ restart: always 設定変更後、以下を実行してコンテナ群を起動します。 docker compose up 実行方法 まず、ブラウザから ScanCode.ioのUIにアクセスし、New Projectから Dockerイメージを指定します。その後、下側の pipeline には analyze_docker_image を選択します。 Download URLs には次のような形式で Docker イメージを指定します。今回はalpine:latestを指定しています。 docker://<image name>:<tag> e.g.)docker://alpine:latest 処理が完了すると、プロジェクト一覧でステータスが Success と表示されます。 自分が作成したプロジェクトをクリックし、画面上部の緑色のボタンから CycloneDX を選択して、CycloneDX 形式の SBOM をダウンロードします。 以下に、生成したjsonを示します(一部抜粋)。 " name ": " libcrypto3 ", " properties ": [ { " name ": " aboutcode:homepage_url ", " value ": " https://www.openssl.org/ " } , { " name ": " aboutcode:package_uid ", " value ": " pkg:alpine/libcrypto3@3.5.1-r0?arch=x86_64&uuid=bd3ad788-4a83-4509-965b-1068090db4cf " } ] , " purl ": " pkg:alpine/libcrypto3@3.5.1-r0?arch=x86_64 ", " type ": " library ", " version ": " 3.5.1-r0 " }, { " bom-ref ": " pkg:alpine/libssl3@3.5.1-r0?arch=x86_64&uuid=d6a913c7-309a-4741-89dc-3207e125348e ", " copyright ": "", " description ": " SSL shared libraries ", " externalReferences ": [ { " type ": " vcs ", " url ": " git+https://git.alpinelinux.org/aports/commit/?id=370a62f0ac139d30d09aba7ed93fcbf455a032ae " } ] , " licenses ": [ { " expression ": " Apache-2.0 " } ] , 考察 今回の調査では、ScanCode のパイプライン analyze_docker_image を用いることで、OS パッケージも SBOM に含まれていることを確認できました。 一方で、Trivy の例で登場した SrcName のような「ソースパッケージ名」に相当する情報は取得できず、 SrcName そのものを CycloneDX の properties 等として明示的に出力することはできませんでした。 以上より、ScanCode については、「OS パッケージを対象にした CycloneDX SBOM を生成することはできる一方で、SrcName をキーとした検知漏れ対策という観点では、そのままでは要件を満たさない可能性がある。」と結論付けました。 本調査から得られたこと 本調査などを通じて、大きく 2 つのことを学びました。 第一に、ツールの開発元の考え方や背景を事前に調べておく必要がある、という点です。 今回扱った ORT、ScanCodeはいずれも「SBOM を生成できるツール」として紹介されていますが、実際には想定しているユースケースや設計思想がそれぞれ異なっていました。 例えば ORT は、SCA（Software Composition Analysis）ツールとして「プロジェクトの依存関係」を主な対象としており、OS パッケージの取得はそもそも守備範囲外である可能性が高いことが分かりました。 このように「どの企業／コミュニティが、どんな目的で作ったツールなのか」を押さえておかないと、自分たちの要件（SrcName ベースでのマッチングなど）と微妙にズレたツールを選んでしまい、期待した情報（ source_name / SrcName など）が出てこない、というミスマッチが起こり得ます。 そのため、ツール選定時には機能一覧だけでなく、開発元やプロジェクトの背景も含めて確認することが重要だと分かりました。 また、開発元の「国」にも注意を払う必要があることを学びました。 特に、脅威インテリジェンスと組み合わせて利用する場合には、 特定の国や地域の法規制・政治状況 インフラやデータへのアクセス権限がどこに帰属するか といった点によって、特定の国で開発された OSS を利用することがリスク要因となる可能性があります。 このため、ツールの技術的な機能だけでなく、地政学的・コンプライアンス上の観点からも慎重に評価する必要があると感じました。 第二に、生成された SBOM やツールの「使いやすさ」にも注意する必要がある、という点です。 今回の調査では、どのツールも CycloneDX 形式の SBOM を出力できる一方で、 OS パッケージがどこまで取得できるか SrcName のような独自プロパティが出力されるか CLI や Web UI でどこまで簡単に取得・確認できるか といった「使いやすさ」の面で差があることが分かりました。 例えば ScanCode は、OS パッケージを含めた CycloneDX SBOM を生成できたものの、 SrcName に相当する情報は出力されず、そのままでは TrivyDB を使ったマッチング要件を満たせませんでした。 そのため、追加の変換や補完を行わない限り、SrcName ベースの検知漏れ対策には使いにくいという結果になりました。 このことから、「CycloneDX に対応しているか」だけで満足するのではなく、 生成された SBOM が自分たちの分析フロー（例：TrivyDB との連携、SrcName をキーにしたマッチング）に、どの程度そのまま載せられるかという「使いやすさ」も評価軸に含める必要があると分かりました。 まとめ 本記事では、インターンシップ2週目の内容にフォーカスしてご紹介しました。 単なる体験記にとどまらず、初めて読む方でも「SBOM とは何か」「インターンに参加することでどんな観点が身につくのか」が伝わるよう意識して執筆しました。 まず、1週目を担当してくださった NA4Sec の神田さん、益本さん、鮫嶋さん、本当にありがとうございました。「脅威インテリジェンスとは何か」という根本的な部分から、脅威調査・分析やフィッシングサイトの調査・分析に至るまで、幅広いテーマを深く学ばせていただきました。 2週目を担当してくださった Metemcyber の高橋さん、西野さん、志村さんにも感謝いたします。 インターン開始時点では、SBOM について正直ふんわりとした理解しかありませんでした。 しかし、3日間の調査や議論を通じて、SBOM の考え方だけでなく OSS 開発や脅威インテリジェンスを組み合わせたときの難しさや面白さも身をもって学べました。 言葉では言い尽くせないほど、多くの貴重な経験をさせていただき、本当にありがとうございました。 本文中でお名前を挙げきれませんでしたが、NA4Sec の皆さま、Metemcyber の皆さま、そして PJ は異なりますがOffensive Security PJ、OsecT Tech PJで関わってくださった皆さま、すべての方々に心より感謝申し上げます。 そして最後に、一緒にインターン生として、そして友人として関わってくれたみんなへ。 ここに書き切れないくらいの感謝の気持ちを込めて、本記事を締めくくりたいと思います。 参考文献 インターンシップ体験記 〜Cobalt StrikeのC2サーバ追跡〜, https://engineers.ntt.com/entry/2023/03/24/081829 （閲覧日: 2025年11月28日） ↩ フィッシングキットの詳細分析に挑戦！（インターンシップ体験記）, https://engineers.ntt.com/entry/202410-summer-internship-phishing/entry （閲覧日: 2025年11月28日） ↩