1. はじめに 本記事は、ネットワーク自動化イベント AutoCon 5の参加レポート前編です。 2026 年 6 月にドイツ・ミュンヘンで開催された AutoCon 5 では、ワークショップが 2026年6月8日~2026年6月9日、カンファレンスが2026年6月10日~2026年6月12日にかけて行われ、ネットワーク自動化の実践例や設計思想が数多く共有されました。 前編である本記事では、AutoCon 5 を俯瞰して見えてきたネットワーク自動化の方向性と、その全体像を整理する軸になっていた NAF Framework の考え方を取り上げます。 いまネットワーク自動化のトップランナ

本記事は 2026 年 4 月 26 日に AWS DevOps & Developer Productivity Blog で公開された AWS Transform custom: Enterprise Code Modernization with the Learn-Scale-Improve Flywheel を翻訳したものです。翻訳は Solutions Architect の山崎 宏紀が担当しました。 エンタープライズにおけるモダナイゼーションは、大きな転換点を迎えています。1 つのリポジトリを変換するだけなら容易です。 AWS Transform custom でも、他の既存のツールでも、個別のリポジトリに対して十分に機能し、プロセスも確立されています。しかし、50 のリポジトリではどうでしょうか。100、200 ではどうでしょうか。エンタープライズ規模でモダナイゼーションを進めようとすると、コードを変換することは課題全体の一部にすぎません。人員の調整、ナレッジの蓄積、そしてポートフォリオ全体における品質の維持も重要になります。 本記事では、AWS Transform custom の 大規模な自動化の仕組み が、インテリジェントな学習とスケール実行によって、エンタープライズにおける組織内連携の課題をどう解決するかをご紹介します。あるお客様は、モダナイゼーション全体の期間を 7-12 週間から 2.5 週間へと短縮し、デリバリー期間を 3-5 分の 1 に、総工数を 10-20 分の 1 に削減しました。そして何より、ご自身のモダナイゼーションの取り組みを今すぐ始めるための方法をお伝えします。 エンタープライズ規模における組織内連携の課題 エンタープライズのアーキテクトに直近の大規模モダナイゼーションについて尋ねると、きまって同じような話を耳にします。例えば、あるエンタープライズソフトウェア企業では、大規模なレガシーコードベースをモダンなプラットフォームへ移行する必要がありました。当初の見積りは、複数チームにまたがる調整作業を含めて 12 週間の集中的な作業でした。 コード変換そのものは数日で完了しました。しかし残りの数週間は、コード変換を取り巻く一連の作業に費やされました。具体的には、タイムゾーンをまたぐチームの調整、異なる経緯を持つコードベース間でのパターンの一貫性の確保、そして上流の変更が下流のシステムを壊さないよう依存関係を管理することです。各チームはミーティングやスプレッドシートでステータスを追跡し、シニア開発者の頭の中にしか存在しない暗黙知に頼っていました。 これがエンタープライズにおける組織内連携の課題です。1 つのリポジトリから数百のリポジトリへとスケールするとき、連携のオーバーヘッドは爆発的に増大します。リポジトリが 1 つ増えるごとに、そのリポジトリ自身の複雑さだけでなく、新たな連携箇所、エッジケース、そして想定外の調整要件が加わるのです。 見落とされがちな 70% のギャップ エンタープライズの案件において、私たちはコード変換がモダナイゼーション作業全体の約 30% にすぎないことを確認してきました。残りの 70% には、テスト生成、検証、包括的なドキュメント作成、ビジネス分析、そして数百の作業項目にまたがる組織的な調整などが含まれます。 このギャップこそが、変換ツールによる生産性向上がなかなか実を結ばない理由です。ツールがコードの変更は処理できても、組織は連携、検証、ナレッジの蓄積に依然として苦労しています。変換作業は迅速に終わるのに、プロジェクト全体は数か月を要するという状況です。 実際に私たちが目にしてきたのは、従来のアプローチがエンタープライズ規模で機能しないという事実です。各リポジトリを独立した課題として扱ってしまうからです。チームはコードベース間で同じ作業を繰り返し、一貫性のない判断を下し、開発者が別のプロジェクトへ異動するたびに学びを失っていきます。組織のナレッジは再利用可能な資産とならず、個人の頭の中に閉じ込められたままです。 エンタープライズモダナイゼーションへの新しいアプローチ AWS Transform custom は、エンタープライズモダナイゼーションに対して異なるアプローチをとります。同じ操作を何百回も繰り返すのではなく、すべての実行から学習し、そこで得た知見を次の変換の改善に活用します。 Learn-Scale-Improve フライホイール この Learn-Scale-Improve（学習・スケール・改善）フライホイール のワークフローは、リスクを最小化しつつ学習効果を最大化するよう綿密に設計されたステップで進みます。まず小規模な Learn (学習) パイロットから始め、一括自動化を通じて Scale (スケール) し、計画的なレビューによって Improve (改善) する。このサイクルを繰り返すフライホイールによって、イテレーションのたびに前回よりも良い結果を生み出します (図 1)。 図 1: AWS Transform custom の変換ワークフローにおける Learn-Scale-Improve フライホイール Learn (学習) : 代表的な 2-3 個のリポジトリを対象に、インタラクティブモードで変換を実行するところから始めます。AI エージェントと直接やり取りしながら、各ステップでの判断にフィードバックを提供し、品質を検証します。エージェントが曖昧な箇所に遭遇すると質問を投げかけ、お客様がガイダンスを与えると、システムがそのコンテキストを記録します。パイロットの最後には、蓄積されたフィードバックを確認して変換定義を修正します。その結果として得られるのは、お客様の組織のナレッジが組み込まれた、スケール実行の準備が整った変換定義です。 Scale (スケール) : 次に、自律モードへ切り替えて一括実行を行います。システムは数十、数百のリポジトリを一晩で、手動介入なしに処理し、パイロットで学習したパターンを適用します。ビルドコマンドやテストコマンドを使用して変換結果を検証し、ポートフォリオ全体の進捗状況をリアルタイムで追跡します。これまで数週間のチーム調整を要していた作業が、一晩で完了します。実行中、システムは新しいエッジケース、想定外のパターン、パイロットでは見えてこなかった最適化の機会などを発見事項として記録します。 Improve (改善) : 一括実行のラウンドが終わるごとに、処理中にシステムが記録したナレッジアイテムをレビューします。これらの発見事項は、パイロットではカバーできなかったリポジトリ特有のパターンやエッジケースを浮き彫りにします。その中から価値のある学びを承認することで、次のイテレーションに向けて変換定義が改善されます。このレビューステップが品質管理の役割を担います。システムは自己改変せず、どの学びを取り込むかを決めるのは、変換定義のオーナーです。 Scale と Improve のサイクルは繰り返されます。一括実行のラウンドごとに得られたインサイトが、次のラウンドをさらに効果的にします。変換の成功率は向上し、手動介入は減少し、エッジケースのハンドリングもイテレーションを重ねるたびに改善されます。 このフライホイールは、エンタープライズが組織としてナレッジをどう蓄積し共有するかを大きく変えます。変換定義は単なる自動化スクリプトではありません。特定のモダナイゼーションシナリオに対して、自社がどう取り組むかを体系化した組織資産です。アーキテクトが変換戦略を定義すると、その戦略は再利用可能な定義としてレジストリに保存されます。チームがベストプラクティスを特定すると、それらは変換定義の中に埋め込まれ、すべてのリポジトリに自動的に適用されるようになります。従来であれば、シニア開発者がチームを離れれば、そのナレッジも一緒に消えてしまっていました。AWS Transform custom を利用すれば、その専門知識を変換定義やナレッジアイテムとして蓄積し、組織全体で使える形にできます。個人の専門性が、組織のケイパビリティへと昇華するのです。 エンタープライズのお客様によるモダナイゼーション事例 これらの生産性向上は理論上の予測ではなく、実際の本番環境での成果です。あるエンタープライズソフトウェア企業では、本番環境で稼働する大量の Control-M（訳註: BMC Software 社のワークロード自動化プラットフォーム）のワークフローを Apache Airflow へ移行する必要がありました。このモダナイゼーションには、技術的な精密さと、複雑かつ相互依存するコードベース全体における一貫性の両方が求められました。当初の見積りでは、複数チームでの集中的な調整に 12 週間を要するとされ、一貫性の欠如や統合失敗のリスクも抱えていました。 この企業は、 AWS Transform custom を活用して Learn-Scale-Improve のイテレーション型ワークフローを実行しました。パイロットフェーズでは、代表的なリポジトリに対してインタラクティブモードでの変換を実行し、結果をレビューしたうえで変換定義を洗練させました。イテレーションを重ねるごとに、変換定義はエッジケースへの対応精度を高めていきました。その後、自律モードの一括実行へと移行し、ポートフォリオ全体の移行を 2.5 週間で完了しました。 検証の結果、対象となったすべてのワークフローで 100% の成功率を達成しました。エッジケースのハンドリングは従来のアプローチと比べて 60% 改善し、変換後のコードは業界の専門家が求めるコード品質基準を満たしながら、実行時のパフォーマンスも 19% 向上しました。この事例は、移行のスピードと本番品質の両立が可能であることを示しました。従来のアプローチと比較して、デリバリー期間を 3-5 分の 1 に、総工数は 10-20 分の 1 に削減しました。 ポートフォリオ全体の変換を始めましょう AWS Transform custom の大規模な自動化の仕組みは、 GitHub リポジトリ でソリューションとして提供されています。Learn-Scale-Improve ワークフローに沿って、モダナイゼーションの取り組みを始めてみてください。 前提条件 開始前に、以下をご確認ください。 AWS Transform custom へのアクセスが有効化された AWS アカウント 適切な認証情報で構成された AWS CLI ローカルマシンまたは CI/CD 環境にインストールされた Git AWS Transform custom の操作に必要な IAM 権限 実装の進め方 AWS Transform custom は、 Java のアップグレード (例: 8 から 17、17 から 21)、Python の移行 (例: 3.7 から 3.11)、Node.js のアップデート (例: 14 から 20)、AWS SDK の移行 (例: boto2 から boto3、SDK v1 から v2) など、多様な変換 をサポートしています。これらの AWS マネージドな変換に加えて、組織固有の標準、独自のフレームワーク移行、各環境特有のアーキテクチャパターンに対応するカスタム変換定義を作成することもできます。 AWS Transform custom は、既存の開発プロセスに自然に統合できます。CLI は Jenkins、GitLab CI、GitHub Actions といった CI/CD パイプラインと連携します。変換結果はローカルの Git ブランチとして生成され、お客様の標準的なコードレビュー・マージプロセスに沿って流れていきます。Web インターフェイスでは、チーム横断での進捗状況を一元的に可視化できます。検証コマンドは変換処理中に自動的に実行され、変更が完了したと見なされる前にコードが正常にビルドされ、テストが通過していることを保証します。変換処理の終了時に検証条件を満たさない場合、その変換は失敗として扱われます。 スケール実行までの道のりを加速するため、AWS は本番環境で利用できるスタート地点となるオープンソースのサンプルリポジトリを提供しています。複数のリポジトリと変換定義に対して同時に変換を実行するためのものです。 aws-transform-custom-samples の scaled-execution リポジトリには、一括実行をオーケストレーションするスクリプト、リポジトリのキューイングを管理する仕組み、ポートフォリオ全体のステータス追跡を扱うスクリプトが含まれています。オーケストレーションをゼロから構築するのではなく、サンプルをクローンし、ご自身のリポジトリリストと変換定義で設定すれば、すぐにスケール変換の実行を始められます。 まとめ エンタープライズ規模でのモダナイゼーションには、コード変換ツール以上のものが必要です。本当の課題は、チーム間の連携、実行からの学習、そしてナレッジを組織資産として蓄積することにあります。AWS Transform custom の Learn-Scale-Improve ワークフローは、これらの課題に対して、実行のたびに品質を高める継続的学習、暗黙知を再利用可能な資産へと変える組織ナレッジの捕捉、そして数百のリポジトリに一貫して適用できる一括自動化で応えます。次に重大なセキュリティ脆弱性が発見され、リポジトリ全体のフレームワーク更新が必要になったときも、新しいランタイムのバージョンでパフォーマンスを改善できるようになったときも、すでに効果を検証済みの変換定義を使って、数か月ではなく数日単位で対応できるようになります。 実際のお客様は、デリバリー期間を 3-5 分の 1、総工数を 10-20 分の 1 に削減し、モダナイゼーションを数か月から数週間に圧縮しています。これは願望ではなく、AWS Transform custom を活用している組織が本番環境で実現している成果です。 今すぐ変換を始めましょう まずは 2-3 個の代表的なリポジトリを対象に Learn-Scale-Improve ワークフローを実施し、変換定義を洗練させたうえで、ポートフォリオ全体へと展開してください。 AWS Transform custom の大規模な自動化の仕組みをさらに深く知るには、以下のリソースをご覧ください。 AWS Transform custom ドキュメント : 全機能、API リファレンス、統合ガイドを網羅した技術ドキュメント: AWS Transform custom Scaled Execution サンプルリポジトリ : 複数のリポジトリと変換定義に対して変換を実行するためのオープンソーススクリプト: aws-transform-custom-samples Transformation Registry : AWS マネージドな変換の発見と、カスタム定義の作成: aws-transform-custom-samples 取り組みを開始するには、AWS アカウントチームにお問い合わせいただくか、AWS Transform custom のドキュメントをご参照ください。 著者について Meghan Kothari Meghan Kothari は、Customer Experience and Business Trends チームのシニアテクニカルプロダクトマネージャーです。AWS のリーダーシップと連携し、Agentic AI を活用したアプリケーション開発とモダナイゼーションにおける進化するトレンドを発見するための戦略的な Deep Dive に取り組んでいます。ソリューションアーキテクトおよびフルスタック開発者としての経歴により、開発者体験の形成に貢献する独自の実践的な視点を持っています。 Venugopalan Vasudevan Venugopalan Vasudevan (Venu) は、AWS のプリンシパルスペシャリストソリューションアーキテクトであり、AWS Transform に焦点を当てた Agentic AI の取り組みを主導しています。お客様が AI を活用した開発者向けソリューションおよびモダナイゼーションソリューションを採用しスケールさせ、イノベーションとビジネス成果を加速できるよう支援しています。 Rodney Grilli Rodney Grilli は、AWS のプリンシパルテクノロジストであり、Agentic AI サービスを活用した製品およびコードのモダナイゼーションを専門としています。お客様が製品ポートフォリオをモダナイズし、AI-Native Enterprise への変革を加速できるソリューションを構築しています。

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 .