SCANOSS サポート担当の橋本です。 弊社では SCA ツールのナレッジベース製品である SCANOSS 製品を代理店として取り扱っています。 SCANOSS 製品の開発元である SCANOSS 社より、SCANOSS 社内の Dependency-Track 運用ノウハウドキュメントを提供いただきました。 Dependency-Track は SCANOSS 製品と統合することが可能な OSS であり、SBOM の管理運用を実施する上で有用なソフトウェアであるため、本ドキュメントを翻訳の上公開いたします。 Dependency-Track を検討している方のお役に立てればと思います。 注：Dependency-Track は OWASP が開発している OSS です。 SBOM 運用のデファクトスタンダード的な OSS ツールではありますが、SCANOSS 社とは直接的な関係はございません。 本ドキュメントはあくまで SCANOSS 社が考える Dependency-Track ベストプラクティスという点にご注意ください。 1. 概要 (Overview) Dependency-Trackは、組織内の全プロジェクトにおけるコンポーネントの分析、監視、および制御を可能にする一元化されたダッシュボードを提供します。 CycloneDX 形式の SBOM および VEX(Vulnerability Exploitability Exchange) のインポート・分析を通じて、組織のポートフォリオ全体に含まれるすべてのアプリケーションのコンポーネント使用状況を追跡します。 2. SBOMアップロード後の脆弱性確認  プロジェクトのSBOMがアップロードあるいは更新されると、Dependency-Track は自動的に脆弱性分析を開始します。 監査の脆弱性 (Audit Vulnerabilities) タブへの移動 「監査の脆弱性」とは、各プロジェクトのコンポーネントに関する検出事項をトリアージするプロセスです。 特定のプロジェクト内で行われた監査の決定、コメント、および履歴は、そのプロジェクトの検出事項にのみ適用され、他のプロジェクトには影響しません。 プロジェクト監査には VULNERABILITY_ANALYSIS 権限が必要です。 監査証跡の閲覧は   VIEW_VULNERABILITY 権限を持つすべてのユーザーが可能です。 EPSS と重大度 (Severity) による優先順位付け 統合された EPSS (Exploit Prediction Scoring System : 脆弱性悪用予測スコア) を CVSS の深刻度と併用することで、どの検出事項から先に対処すべきかの優先順位を付けます。 「高い CVSS」＋「高い EPSS」＝即座に修正すべき項目、という判断基準になります。 脆弱性インテリジェンスソース Dependency-Track は、以下の7つの主要なソースと統合されています。 National Vulnerability Database (NVD) GitHub Advisories Sonatype OSS Index Snyk Trivy OSV VulnDB (Risk Based Security) 3. 監査判断の実施：分析ステート 各検出事項には分析ステートを割り当てます。 まず「設定されていません」の項目から着手し、調査中は 「トリアージ中」へ移行させ、最終的に調査結果に基づいたステートを決定します。 分析ステート一覧 日本語表記 英語表記 説明 設定されていません Not Set 分析がまだ開始されていない初期状態 悪用可能 Exploitable 脆弱性が悪用可能 (またはその可能性が高い) と判断された状態 トリアージ中 In Triage 検出内容の正確性や影響度を判断するための調査が進行中の状態 偽陽性 Falese Positive 誤ったロジックやデータ (コンポーネントの誤特定や脆弱性情報の誤りなど) による誤検知 影響を受けません Not Affected 脆弱性自体は存在する (真の陽性) が、当該プロジェクトの利用方法等により影響を受けない状態   ヒント： ステートの変更を含むすべての監査証跡には、ユーザー名とタイムスタンプが自動的に付記されます。 判断の根拠を後から検証できるよう、監査時には必ず具体的な理由をコメントとして記録してください。 4. ポリシー違反の確認 組織全体、または特定のプロジェクト単位でポリシーを設定し、ポリシー違反状況を継続的に測定できます。ポリシーの評価は、SBOM がアップロードされるたびに自動的に実行されます。 ポリシー違反には以下の 3 つの種類があります： I :ライセンス違反 宣言されたライセンスが組織のコンプライアンス基準に適合しているか確認します。 ポリシー管理 > ライセンスグループ > ライセンスグループの作成より「許容ライセンス」や「禁止ライセンス」といったライセンスグループを作成し、それらに対して違反条件を設定します。 承認済みリスト以外のものを検知するには、「『ライセンスグループ』『ではない』『許容ライセンス』」という条件を使用します。 禁止されているライセンスを検知するには、「『ライセンスグループ』『は』『禁止ライセンス』」という条件を使用します。 Copyleft などの一般的なライセンスグループは標準で用意されています。 ※訳注『』内は設定値です。 II:セキュリティ違反 脆弱性の重大度を条件として指定できます。 検出事項の重大度がポリシー条件と一致した場合、違反としてトリガーされます。 抑制れた脆弱性は、ポリシー違反を引き起こしません。 III.運用違反 以下の条件に基づき、特定のコンポーネントに対する許可・禁止ルールを作成できます。 年 : バージョン公開日からの期間 座標 : group, name, version (GAV) による特定 パッケージ URL (PURL) CPE SWID Tag ID ハッシュ値: MD5, SHA, SHA3, Blake2b, Blake3 バージョン距離: 使用中のバージョンと最新バージョンの差 これにより、特定のコンポーネントの許可リストや拒否リストを作成することができます。 5.影響範囲分析と特定 新しいCVE (脆弱性) が公開された際、ポートフォリオ内の 「コンポーネント (Component)」 または 「脆弱性 (Vulnerability)」 を活用することで、その影響を受けるライブラリを利用しているプロジェクトを検索可能です。 個別のプロジェクトを一つずつ確認する必要はなく、組織全体の影響範囲を迅速に評価できるため、影響範囲を即座に特定することができます。  活用シーン: ゼロデイ脆弱性への対応、監査、およびサプライチェーン・インシデントへの対応時。 6. 抑制 抑制機能は、検出事項をグローバル (ポートフォリオ全体) または特定のプロジェクト単位で非表示にするために使用します。 自環境のアーキテクチャ上、影響対象外であることが確認された脆弱性に対して使用します。 抑制された項目は、ダッシュボード上のポリシー違反カウントから除外されます。  抑制を行う前に、必ず監査コメントにその技術的・運用的理由を記録してください。 以前は適用外だった脆弱性も、デプロイメントやアーキテクチャの変更によって再度リスクとなる可能性があるため、定期的に抑制設定を再確認することが推奨されます。 https://docs.dependencytrack.org/triage/suppression/   7. 通知の自動化 ダッシュボードを手動で確認するのではなく、通知機能を活用してプッシュ型で情報の通知が可能です。 サポートされるチャネル Slack Microsoft Teams Mattermost Webhooks Webex Email Jira 推奨される通知トリガー 新規脆弱性の特定 (特に重大度が Critical または High のもの) ポリシー違反の発生 プロジェクト SBOM の更新 CI/CD 統合 Jenkins:   OWASP Dependency-Track Plugin を使用します。ポリシー違反が発生した際にパイプラインを自動的に失敗させることも可能です。 その他の CI システム:   REST APIを使用して SBOM をアップロードし、プログラムを介して違反の有無を確認します。   8. ベストプラクティス (Best Practices) SBOM の生成 SBOM は手動で作成せず、CI プロセス内で自動生成してください。 サプライヤーやベンダーに対しても、CycloneDX SBOM の提供を契約条件として要求してください。 商用ソフトウェアについても、可能な限り SBOM を入手または生成してください。 アナライザーとデータソース Internal Analyzer および OSS Index を有効化してください。 NVD および GitHub Advisories のミラーリングを有効化し、常に最新の知見を利用できるようにしてください。 日常の衛生管理 Dependency-Track 内のプロジェクトのバージョンを常に最新の状態に保ち、検出事項のスコープ (影響範囲) が正しく設定されるようにします。 ステートを変更する際は、毎回必ず監査コメント欄を使用してください。判断に至った経緯は、チームメンバーや監査人にとって非常に重要な情報となります。  個々のプロジェクトだけでなく、ポートフォリオのダッシュボードを定期的に確認し、全体的なリスクの傾向を把握します。 「プロジェクト収集 (Collection Projects)」を活用して関連するプロジェクト (例：チームや製品ライン別など)をグループ化し、集約されたビューで確認できるようにします。 「トリアージ中 」 の状態で長期間放置されている検出事項に対処するため、定期的なレビューのサイクル (例：週次でのトリアージセッションなど)をスケジュールします。   9. チュートリアルビデオ (Tutorial Videos) タイトル とリンク 説明 OWASP Spotlight: Project 15 — Dependency-Track OWASP 財団による概念的概要 — ステークホルダー向け Tool Review: DependencyTrack   インストール、ダッシュボード、API キー、プロジェクトの作成とインポートについて説明 OWASP Flagship Projects: Dependency-Track — Steve  Springett プロジェクト作成者による解説：ビジョンと設計思想 OWASP DependencyTrack Walkthrough UI のクイックデモ (簡単な実演) — 主要な画面説明 OWASP Dependency-Track SBOM Analysis Up and Running in Minutes ステップバイステップの設定手順、および SBOM 自動アップロードのための GitHub Actions 連携 Understanding Open Source  Dependencies — Lightning Talk (Fran Hoey)  コミュニティ・カンファレンスでの講演：日々の利用に役立つ実用的な事例 Is Your Supply Chain Safe? Dependency-Track Tutorial for Devs  CycloneDX SBOM の生成とサプライチェーン・リスク評価を説明 10. 公式チャネルと主要ドキュメントリンク YouTube の公式チャネルでは、メンテナによる新機能解説やコミュニティミーティングを含む約 30 本のビデオが公開されています。 継続的なアップデート情報を得るため、サブスクライブを推奨します。  https://www.youtube.com/c/OWASPDependencyTrack 主要ドキュメントリンク 監査の基本  https://docs.dependencytrack.org/triage/auditing-basics/ 分析ステート https://docs.dependencytrack.org/triage/analysis-states/ 抑制 https://docs.dependencytrack.org/triage/suppression/ ポリシーへの準拠  https://docs.dependencytrack.org/usage/policy-compliance/ 影響分析 https://docs.dependencytrack.org/usage/impact-analysis/ CI/CD連携 https://docs.dependencytrack.org/usage/cicd/ ベストプラクティス  https://docs.dependencytrack.org/best-practices/ REST API  https://docs.dependencytrack.org/integrations/rest-api/ 通知  https://docs.dependencytrack.org/integrations/notifications   ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post Dependency-Track：日常運用ガイド first appeared on SIOS Tech Lab .

こんにちは！システムセキュリティ推進グループの小笠原 (@gassara5) です。 最近では連日の ...

本ブログは 2026 年 4 月 7 日に公開された AWS Blog “ Building AI defenses at scale: Before the threats emerge ” を翻訳したものです。 AWS は数十年にわたり、世界中で事業を展開する何百万のお客様を同時に保護するためのプロセスとツールを開発してきました。AWS のセキュリティチームと脅威インテリジェンスチームは、日々、表に出ることのない AI と自動化を駆使した取り組みを続けています。AI を活用したログ分析システムにより、SecOps エンジニアのセキュリティログ分析に要する時間は平均 6 時間からわずか 7 分にまで短縮されました。この 50 倍もの生産性向上により、脅威の検出と対応をかつてないスピードで行えるようになっています。AWS 全体では、1 日あたり 400 兆を超えるネットワークフローを分析し、新たな脅威の兆候となるパターンを検出しています。2025 年だけでも、Amazon S3 上のお客様のファイルを不正に暗号化しようとする 3 億件を超える試みをブロックしました。 あるお客様を保護する過程で得た知見は、すべてのお客様の保護に役立ちます。この規模で運用しているからこそ、新たに検出した脅威がすべてのお客様の防御強化に直結します。AI はすでにその中核を担っています。 サイバーセキュリティのための新たなクラスの AI 本日 (2026 年 4 月 7 日)、 Anthropic が Project Glasswing を発表しました 。これは、世界で最も重要なソフトウェアの保護と、AI の進化に伴い業界に求められるサイバーセキュリティの実践を前進させることを目的としたイニシアチブです。重要なデジタルインフラストラクチャを構築・運用する組織は、世界が依存するシステムの脆弱性を発見し修正するための新しいクラスの AI モデルである Claude Mythos Preview に早期アクセスできるようになります。世界で最も重要なインフラストラクチャの一端を保護する役割を担う AWS は、この取り組みを推進するうえで重要な役割を果たしています。 このプロジェクトを支えるのは、Anthropic のこれまでで最も高度な AI モデルであり、サイバーセキュリティにおける推論能力と AI 能力の飛躍的な進歩を実現する Claude Mythos Preview です。Claude Mythos Preview は根本的に新しいモデルクラスであり、Anthropic のこれまでのフロンティアモデルを上回る知性と能力を備え、サイバーセキュリティ、ソフトウェアコーディング、複雑な推論タスクでより高いパフォーマンスを発揮します。 Project Glasswing の一環として、AWS では継続的な AI セキュリティレビューが行われている重要なコードベースに Claude Mythos Preview をすでに適用しています。十分にテストされた環境であっても、コードをさらに強化できる箇所の特定に役立っています。内部テストでは、Claude Mythos Preview がセキュリティの検出結果を洗い出す際に従来のモデルよりも高い生産性を発揮し、エンジニアによる手動のガイダンスが少なくても実用的な結果を提供できることが実証されました。一部のお客様にも早期アクセスを提供しており、自社のセキュリティワークフローへの Claude Mythos Preview の導入を通じて、モデルの進化の方向性を形作ることに貢献しています。AWS にとって Claude Mythos Preview は、すでに活用している AI ツールの自然な進化形です。テクノロジーがより強力になるにつれて、防御もそれに合わせて強化していかなければなりません。 こうしたイノベーションこそが AWS の取り組みを推進するものであり、Claude Mythos Preview がエンタープライズでの利用に対応できるよう Anthropic と緊密に連携してきました。AWS は、Anthropic のミッションクリティカルなワークロードや安全性の研究、基盤モデル開発を支える主要なクラウドプロバイダーです。より広い視点で見ると、世界をリードする AI 企業が最先端モデルの構築、トレーニング、デプロイに利用する基盤インフラストラクチャを AWS が提供しています。数十年にわたるセキュリティの経験をこのパートナーシップに活かし、さらに多くの組織が Claude Mythos Preview を基盤として安全かつ大規模に運用できるよう支援しています。 Claude Mythos Preview は、これまでにないスケールと速度で脆弱性を発見し、実際に機能するエクスプロイトを構築できる新世代モデルの先駆けです。Anthropic と AWS は意図的に慎重なリリースアプローチをとっています。まず少数の組織からアクセスを開始し、数億人のユーザーに影響を与えるソフトウェアやデジタルサービスを提供するインターネットの重要インフラ企業やオープンソースのメンテナーが優先されます。目標は、世界で最も重要なソフトウェアの脆弱性を発見し修正することです。Claude Mythos Preview は Amazon Bedrock を通じて限定 (リサーチ) プレビューとして利用可能で、カスタマーマネージド暗号化、VPC 分離、詳細なログ記録などのエンタープライズグレードのセキュリティコントロールを備えています。これにより、本番環境のアセットを不要なリスクにさらすことなく、Claude Mythos Preview の機能を検証できます。 セキュリティを中核に据えた AWS のサービス設計 Project Glasswing における AWS の取り組みは、ミッションクリティカルなワークロードを 20 年以上にわたって保護してきた経験の中で培った理念に基づいています。脅威が現実化してから防御を構築するのでは遅いのです。先を見越して新しいテクノロジーを採用し、まず保護策を構築して自社の運用に大規模にデプロイし、そこから得た知見に基づいて改善を重ねていく必要があります。 これこそが AWS が AI とセキュリティにおいて実践してきたことです。AWS のアプローチは多岐にわたります。脅威ハンティングと脆弱性リサーチによるプロアクティブな防御、進行中の攻撃キャンペーンへの動的な対応、そしてセキュリティの取り組みが業界最高水準を満たすことを検証する第三者認証です。こうした運用経験から、AI がセキュリティ業務をどこで加速させ、人間の判断がどこで不可欠なのかを学びました。また、セキュリティのイノベーションは実用的でなければならない、つまりお客様にご活用いただく前に本番環境で実証されている必要があるということを改めて実感しました。 だからこそ AWS は、安全な AI とはどうあるべきかを定義する取り組みにも貢献しています。AWS は AI サービスにおける ISO 42001 認証を取得した最初の主要クラウドプロバイダーとなりました。OWASP、Coalition for Secure AI、Frontier Model Safety Framework にも積極的に参加しています。また、エコシステム全体でのより優れた脅威インテリジェンスの共有を実現するため、Open Cybersecurity Schema Framework (OCSF) を共同設立しました。 AWS Nitro System はワークロード間の数学的に証明された分離を実現します。ゼロオペレータアクセスアーキテクチャにより、AWS のオペレーターがお客様のデータにアクセスすることはできません。これらは将来の理想像ではなく、AWS が現在、大規模に日々実践していることです。 Amazon Bedrock は、これらの原則を AI の領域で実現するサービスです。ポリシー適用型のアクセス制御、モデルによる脆弱性の特定・検証の有効性を測定する組み込みの評価ツール、お客様専用の仮想プライベートクラウド内でワークロードを実行する機能を提供します。さらに AWS は、一般提供されている Claude 基盤モデルについて FedRAMP High および Department of Defense Security Requirements Guide Impact Level 4/5 の認定を取得した最初のクラウドプロバイダーでもあります。最も厳しいセキュリティ要件を持つ組織が、Anthropic のテクノロジーを安心して利用できる場として Amazon Bedrock を選んでいることの証です。 今すぐ始めるには AWS の大規模運用を支える原則は、使用する AI ツールに関係なく適用できます。包括的なオブザーバビリティ、多層防御、価値を生む領域での自動化、そして不可欠な場面での人間の判断です。以下にその実践方法をご紹介します。 次世代の AI セキュリティに備える。 Claude Mythos Preview は、サイバーセキュリティを変革する新世代の AI モデルの先駆けとなるものです。これらの機能がより広く利用可能になったときに備えて、今からセキュリティポスチャの強化を始めてください。Claude Mythos Preview は Amazon Bedrock を通じた限定プレビューとして利用可能であり、アクセスは許可リストに登録された初期の組織に限定されています。許可リストに登録されている場合は、AWS アカウントチームから直接ご連絡します。 AWS Security Agent でオンデマンドのペネトレーションテストを実行する。 一般提供が開始された AWS Security Agent は、手動のペネトレーションテストと比べてわずかなコストで 24 時間 365 日稼働する自律型ペネトレーションテストを提供します。ペネトレーションテストを、定期的に発生するボトルネックから、AWS、Azure、GCP、その他のクラウドプロバイダー、オンプレミスにわたり開発速度に合わせてスケールするオンデマンド機能へと変革します。AWS Security Agent は新しいクラスのフロンティアエージェントです。目標達成のために自律的に動作し、同時並行のタスクに対応するためにスケールし、人間の常時監視なしに継続的に稼働します。高度な多段階の攻撃シナリオを通じてセキュリティの脆弱性を発見、検証、報告する専門的な AI エージェントをデプロイします。検証なしに検出結果を生成する従来のスキャナとは異なり、AWS Security Agent は潜在的な脆弱性を特定した後、標的を絞ったペイロードと攻撃チェーンを使用してエクスプロイトを試み、正当なセキュリティリスクであることを確認します。各検出結果には、CVSS リスクスコア、アプリケーション固有の重大度評価、詳細な再現手順、修正の提案が含まれます。その結果、かつて数週間かかっていたペネトレーションテストが数時間で完了し、最も重要なシステムだけでなくアプリケーションポートフォリオ全体にわたってセキュリティカバレッジをスケールできるようになります。新規のお客様は 2 か月間の無料トライアルで AWS Security Agent をお試しいただけます。 Amazon Bedrock で信頼できる AI アプリケーションを構築する。 生成 AI を活用して構築するチームにとっての課題は、AI を機能させることだけではなく、AI を安全に機能させることです。Amazon Bedrock は、責任ある AI のデプロイに必要なセキュリティと安全性のコントロールを提供します。 自動推論 は、形式的論理を使用してハルシネーションによる事実の誤りを防ぐ、先駆的かつ唯一の AI セーフガードであり、99% の精度で検証可能な説明を提供します。これは、AWS のストレージ、アイデンティティ、ネットワーキング全体で 10 年以上にわたり形式的手法を適用してきた経験を基に磨き上げてきたものです。Amazon Bedrock はさらに、有害なコンテンツをブロックしコンテンツポリシーを適用するカスタマイズ可能なガードレールに加え、ワークロード全体にわたって AI の動作を追跡し異常を検出する包括的なオブザーバビリティも提供します。 脅威の状況は待ってくれない 脅威の状況は、こちらの対応を待ってはくれません。国家レベルの攻撃者、ランサムウェアオペレーター、サプライチェーン攻撃者は、すでに AI を活用して攻撃のスケールを拡大しています。AWS の使命は、まず防御を構築し、大規模にデプロイし、そこで得た知見をコミュニティ全体に共有・還元することで、常に一歩先を行くことです。 これこそ AWS が日々実践していることです。お客様にお使いいただく前に、まず自社の運用でテクノロジーが機能することを実証しています。標準に従うのではなく、自ら標準を打ち立てています。そして、先を見越して明日の課題に今日から取り組んでいます。 AI の機能がどれだけ進化しても、このアプローチは変わりません。AWS は引き続き防御を先に構築し、大規模な運用の中で改良を重ねていきます。そして Anthropic のようなパートナーと協力し、次世代の AI セキュリティツールがこの規模で防御を行うエンタープライズの実際のニーズに応えられるよう取り組んでいきます。 関連情報 AWS Security Agent の利用を開始する AI コンテンツの安全性を実現する Amazon Bedrock Guardrails を確認する Securing AI at AWS で取り組みを確認する AWS Responsible AI について確認する AWS AI Compliance について確認する 新たな脅威について AWS Security Bulletins を確認する Amy Herzog Amy Herzog は Amazon Web Services (AWS) のバイスプレジデント兼最高情報セキュリティ責任者 (CISO) です。セキュリティを最優先に掲げる AWS において、クラウドセキュリティプロフェッショナルのグローバル組織を率いています。AWS 入社前は、Amazon の Devices and Services、Media and Entertainment、Advertising の各事業で CISO を務め、Alexa+ や Ring などのコンシューマーテクノロジー製品のセキュリティを統括しました。また、低軌道衛星を通じて世界中のお客様やコミュニティに高速かつ高信頼のブロードバンドを提供する Amazon のイニシアチブである Project Kuiper のセキュアな開発にも重要な役割を果たしました。 <!-- '"` --> 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。