情報セキュリティ - アプリケーションセキュリティ - ソフトウェアコンポーネント安全性分析 (SCA) 機能の構築と進化

1 はじめに

SCA の概念は実際には長い間存在していました。簡単に言うと、既存のソフトウェアシステムに対して非常に詳細な SBOM (ソフトウェア部品表) リストを生成し、リスクデータを使用して、参照されているリスクコンポーネントがあるかどうかを照合します。現在、市場に流通している優れた商用製品には、Synopsys の Blackduck、Snyk の SCA、HP の Fortify SCA などがあり、オープンソース製品には中国の OpenSCA などがあります。

しかし、これらの製品を調査および分析した結果、リスクデータベースの完全性、既存の研究開発プロセスとの結合度、不完全なパフォーマンスおよびコミュニティサポートなどの理由により、これらの製品を企業の内部研究開発プロセスにうまく統合できないことがわかりました。、など。しかし、企業内では、この部分の能力は SDL の仕事に不可欠な能力です。したがって、企業内の情報セキュリティチームは、ビジネスチームのニーズ、セキュリティチーム自身のリスク理解、企業内部の研究開発プロセスの現状、既存のテクノロジーとデータ機能の現状と問題を組み合わせる必要があります。アプリケーションのコストと ROI。ビジネスチームがソフトウェアサプライチェーンレベルで情報セキュリティの問題をより多く、より速く、より適切に、より経済的に解決できるように、独自の SCA 機能を構築することを検討してください。セキュリティチームは、コンポーネントのリスク問題のグローバルガバナンスをより適切に実装することもできます。

上記の内容から、企業内で SCA 機能を構築するプロセスでは、部門間のコラボレーション、システムの安定性、ビジネス部門とセキュリティ部門によるリスクの定義の不一致など、多くの製品および運用上の問題が関係することがわかります。等この記事では主に、企業における SCA 機能の実際の実装プロセス、遭遇する問題、SCA テクノロジーの見解と展望を紹介し、業界の同僚に参考となるソリューションとモデルを提供することを目指しています。

2. セキュリティの観点から見た研究開発リスク

企業内の情報セキュリティチームの観点から見ると、企業内の研究開発プロセス全体で遭遇するリスクポイントは依然として多く、さまざまな攻撃対象領域を整理して分析した後、研究開発プロセス中にしばしば指摘されることがあります。これには、次の一般的な脆弱性リスク、サプライチェーン関連のリスク、および古いメンテナンスコンポーネントが含まれます。これらは以下で 1 つずつ拡大されます。

2.1 一般的な脆弱性リスク

コンポーネントのセキュリティのレベルでは、最初に遭遇する問題であり、最も見つけやすい問題は脆弱性の問題です。脆弱性の問題が引き起こす影響は非常に直観的でもあり、悪意のある使用によりシステムに予期せぬ問題が発生し、完全性とセキュリティがさらに破壊される可能性があります。システムの可用性。2021 年にシノプシスが発表したソフトウェアサプライチェーン関連のデータによると、オープンソースコードウェアハウス全体に占める、オープンソースコードウェアハウスに少なくとも 1 つの脆弱性があるウェアハウスの割合は、2016 年の 67% から 84% に増加しました。少なくとも 1 つの高リスクの脆弱性すべての倉庫に占める割合は 2016 年の 53% から 60% に増加し、最も高かったのは 2017 年で、この数字は 77% に増加しました。

Snykが2020年に発表したオープンソースコンポーネントとサプライチェーンセキュリティに関する別のレポートによると、脆弱性の数は依然として警戒が必要であり、依然としてXSS脆弱性がリストのトップを占めており、コマンド実行脆弱性がそれに続く。システム。

上記のリスクのうち、悪意のあるパッケージに焦点を当てると、このタイプのリスクが 2019 年に最も急速に増加している脅威の 1 つであることがわかります。これは次の疑問にもつながります。つまり、ソフトウェアのサプライチェーンに関連するリスクです。

2.2 サプライチェーンに関連するリスク

オープンソースコンポーネントの本番、ビルド、リリースのプロセスは、企業内の通常のシステムの研究開発および立ち上げのプロセスと基本的に同じですが、簡単に言うと、次の図のように抽象化できます。

オープンソースソフトウェアの作成者がコードの作成を完了したら、それをソースコード管理プラットフォーム (GitHub、コードクラウド、Gitlab プライベートサーバープラットフォームを含む) などにプッシュし、CI/CD 上でビルド、コンパイル、パッケージ化のプロセスを開始します。このプロセス中に、CI/CD プラットフォームはコンポーネント依存関係プラットフォーム (Sonatype Nexus プライベートサーバーまたは MVNRepository 公式ソース) から依存パッケージを取得し、CI/CD プラットフォームがパッケージ化/ミラーパッケージ化プロセスを完了した後、それをプロジェクト配布プラットフォームを介して運用環境に移行するより現代的な方法は、Docker イメージを直接取得してデプロイし、システムの起動を完了することです。このプロセスは単純に見えますが、実際にはまだ多くのリンクがあります。各リンクを見てみましょう。実際には、次の図に示すように、各リンクには多くのリスクがあります。

IDE プラグインポイズニング : ソフトウェアをより効率的に開発するために、開発者は開発エクスペリエンスと効率を向上させるためにさまざまなプラグインを IDE に導入することがよくあります。これはごく普通のことのように思えますが、ソフトウェア開発者は十分なセキュリティ意識を持っていないことが多く、その結果、IDE に問題のあるコンポーネントがインストールされたり、IDE 自体がサプライチェーンで「汚染」されたりすることがあります。。さらに有名なのは、2021 年 5 月に Snyk が公開したセキュリティレポートで、攻撃者が VSCode のプラグインマーケットで「ポイズニング」行為を開始したことが示されたことです。問題のある拡張機能には、「LaTeX Workshop」、「Rainbow Fart」、「デフォルトで開く」などがあります。ブラウザ」や「Instant Markdown」など、これらの問題のある拡張機能はいずれも約 200 万回インストールされており、今回の事件の影響も非常に広範囲に及んでいます。
欠陥コードを提出する : ソフトウェア開発プロセスでは、レベルやセキュリティ意識のさまざまな理由により、開発者が開発プロセスに脆弱性を導入することがよくありますが、それ自体はごく普通のことです。しかし、オープンソースソフトウェアの場合、ほとんどの人がオープンソースプロジェクトにコードを提出し、レビューを通過した後はプロジェクトにマージできるため、問題のあるコードを意図的に導入する悪意のある人が常に存在します。 2021年4月、ミネソタ大学のKangjie Lu教授率いる研究チームはLinuxに意図的に脆弱性を導入し、その結果大学全体がLinuxカーネル開発への参加を禁止された。倫理的な問題はともかく、審査の怠慢によってこのようなリスクが実際に直接的に持ち込まれる可能性があります。
ソースコードプラットフォームが侵害される : 実際、Git プラットフォーム自体は、不適切な保護により侵害される可能性が非常に高くなります。GitHub のようなプラットフォーム自体を取り込むのは現実的ではありませんが、多くのオープンソースプロジェクトは独自に構築された Git プラットフォームであり、いくつかのよく知られた理由と相まって、Git プラットフォーム自体が保護されていない可能性が比較的高いです。2021 年 3 月、PHP 公式 Git も同様のケースに遭遇しました。これは、PHP 公式チームが git.php.net サーバー上で管理している php-src Git リポジトリに 2 つの悪意のあるコミットがプッシュされたためです。攻撃者は上流に謎の変更を提出し、「タイポグラフィを修正している」と述べ、小さなタイポグラフィの修正であるかのように装い、署名を偽造して、これらのコミットが既知の PHP 開発者兼メンテナである Rasmus Lerdorf と Nikita Popov によって行われたものであると人々に思わせました。。したがって、Git プラットフォーム自体のセキュリティ保護にもさらに注意を払う必要があります。
コードブランチが改ざんされ、パッケージ化の結果が不一致になります 。オープンソースプロジェクトの Git リポジトリは誰でも公開されているため、コンパイルされたパッケージには CI/CD が含まれているにもかかわらず、一部の攻撃者は別のブランチインプラントコードを作成してリリースしようとします。プラットフォーム署名ですが、依然として重大なセキュリティリスクを引き起こします。2019 年の DEFCON カンファレンスの時点で、セキュリティ研究者は WebMin 1.890 のデフォルト構成に重大な高リスクの脆弱性を発見しており、WebMin バージョン 1.882 ～ 1.921 はこの脆弱性の影響を受けることになります。しかし奇妙なことに、GitHub からダウンロードしたバージョンは影響を受けず、影響範囲は SourceForge からダウンロードした WebMin の特定のバージョンに限定されていました。その後の調査により、コードウェアハウスはブランチを追加していないことが判明しました。問題の原因となった保護メカニズムがセキュリティ上のリスクにつながる可能性があります。
CI/CD システムが侵害されました 。研究開発の初期段階で、コードの整合性検査が完了していれば、プロセスが改ざんされていない場合、または構築プラットフォームが正常に実行されていれば、通常の状況下では、問題が発生する可能性は非常に高くなります。低い。しかし、これまでの Git のように CI/CD プラットフォームが悪意を持って改ざんされたり、破壊されたりした場合、セキュリティ上のリスクも発生します。SolarWind 事件は、攻撃者が CI/CD プロセスに「バックドア」を埋め込んだために発生しました。署名検証が完了し、OTA 経由でパッチが配布されると、衝撃的なサプライチェーン攻撃が発生します。
安全でないコンポーネントの導入 : 依存関係の導入の過程で、問題のあるコンポーネントが導入されるとリスクを導入することと同じであり、現在最も典型的なサプライチェーン攻撃手法である当社のセキュリティ調査とさまざまなソースの分析の結果、次のことが判明した「ポイズニング」の最も大きな被害を受けている領域は、Python と NodeJS テクノロジースタックです (理由の 1 つは、フロントエンドの「マイニング」が非常に成熟していて、ハッカーによって悪用されやすいためです。もう 1 つの理由は、Python の機械学習ライブラリが非常に高度であるためです。リッチプラス（機械学習をサポートするコンピューティング環境のパフォーマンスが強力であるため、通常の IDC ホストをハッキングするよりも「マイニング」による収入が高くなります）。たくさんの例があるため、ここではリストしません。
外部CI/CDプロセス構築 ：CI/CDプラットフォームでは要件を満たせない場合や、開発者が他の要素を考慮する場合があるため、構築には非公式のCI/CDを使用しますが、パッケージ化されたJARまたはDockerイメージを自分でアップロードします。、パッケージ化ツールチェーンとソースコードは同時にパッケージ化されてコンテナインスタンスにアップロードされ、その後ローカルでパッケージ化されます (極端な場合、一部の「かわいい」依存関係ウェアハウスは、独自に構築された Sonatype Nexus ソース管理システムです)。オープンソースソフトウェアの多くのユーザーは CI/CD 署名検証 (単純なハッシュの照合など) を実行しないため、この種の攻撃が時折発生します。2008 年には、アリゾナ大学の研究チームが APT や YUM などの Linux パッケージ管理プラットフォームを分析および調査し、ほとんどのソースがパッケージを検証しておらず、これらのパッケージが配布に従うため、セキュリティ上の問題がますます増えていることを発見しました。
問題のあるパッケージの直接展開 : 一部のパッケージ製品を使用する場合、チェックサムチェックが実行されないため、問題のあるパッケージが展開される可能性があります。最も典型的な例は、Sonatype によって以前に公開された Web-Broserify パッケージの事件ですが、このパッケージはを使用して開発されました。数百もの正規のソフトウェアを監視してターゲットシステム上のホスト情報を収集するため、かなり大規模な影響を及ぼします。

2.3 保守期間外のコンポーネント

実際の運用環境では、多くの開発者が長期間更新されていないランタイムバージョン、コンポーネントバージョン、CI/CD プラットフォームバージョンを使用しています。もちろん、セキュリティの観点から、セキュリティチームはすべてのシステムで最新バージョンのコンポーネントやミドルウェアが使用されることを望んでいますが、実際には、ビジネス自体の計画や反復に基づいて互換性が発生するのは簡単です。大きなバージョン変更が多数ありますが、アップグレードや移行のコストが高額になる性的な問題やその他多くの理由により、この問題の実装はそれほど簡単ではありません。セキュリティと使いやすさのバランスを達成するために、多くの企業は内部で妥協し、他の手段を使用して攻撃対象領域を減らし、セキュリティ問題を確実にし、損失を適時に検出して阻止するためのバイパス認識システムを確立します。しかし、長期的には、古いバージョンのコンポーネントを導入すると、多くの問題が発生する可能性があります。

メンテナンスの問題 : オープンソースコミュニティの人的資源とエネルギーが限られているため、多くの場合、いくつかのメジャーバージョン (オペレーティングシステムの LTS バージョンと同様、長期サポート) しかメンテナンスできません。サポートバージョンはコミュニティの長期サポートですが、LTS 以外のバージョンはそうではありません)。そのため、かなり古くなったバージョンを使用すると、セキュリティアップデート部分に重大なギャップが生じます。高リスクの脆弱性があり、公式がそれをメンテナンスしていない場合は、それを修正するパッチを自分で作成するか、バージョンをアップグレードして「長期的な痛みは短期的な痛みよりも悪い」という効果を達成するか、単に時限爆弾のようにそこに置き、攻撃を祈るか、「青い軍」はそれほど幸運ではありません。
不完全なセキュリティベースライン : 情報セキュリティテクノロジの開発と内生セキュリティの推進により、新しいバージョンのセキュリティコンポーネントはセキュアバイデザインになることが多く、研究開発のセキュリティ要件を研究開発設計プロセス全体で実行できるようになります。ただし、初期段階ではテクノロジー、思考、攻撃対象領域の制限により、この部分の作業は行われなかった場合と同じになることがよくあります。私が深く感動した例が 2 つあります。1 つは、数年前に APT 組織によって悪用された Office 0day 脆弱性です。これは、長い間壊れていた Office のコンポーネントをターゲットにしていました。このコンポーネントは、基本的な GS (スタック) にさえ接続できない可能性があります。保護）、DEP（データ領域は実行不可能）、ASLR（メモリアドレスのランダム化）、およびその他の最新のコードセキュリティ軽減メカニズムは適用されません。仮想化の脆弱性マイニングに精通している学生は、QEMU/KVM 環境で比較的大きな攻撃対象領域が QEMU によってシミュレートされるドライバーであることを知っているかもしれません。QEMU/KVM によってシミュレートされるドライバーの多くは古いバージョンであるため、最新のドライバーも多数存在します。これらのドライバーには適用されないため、攻撃対象領域が生じます。実際、同様の状況はオープンソースソフトウェアの使用にも存在しており、これを総称して「完全なセキュリティベースラインを持たないオープンソースソフトウェアの使用」と呼んでいます。
厳格なセキュリティテストに合格しない : Sonatype など、現在のオープンソースコンポーネントプロバイダーの多くは、配布前にある程度のセキュリティテストを実施しますが、時期が早ければ早いほど、テストの範囲は小さくなります。言い換えれば、コンポーネントが古いほど、より多くの問題が発生します。結局のところ、現在ほど優れたセキュリティ製品やセキュリティのアイデアは存在しておらず、開発プロセスにもセキュリティ要件が組み込まれていませんでした。そして、これにより、新たにリリースされたバージョンでは脆弱性が修正されている間にさらに大きな脆弱性が導入され、リスクがますます増大し、ますます制御不能になることが何度も発生します。

要約すると、セキュリティチームの観点からすると、リスクはあらゆるところに存在します。ただし、セキュリティビジネスを行っていないセキュリティ会社では、リスクに対するビジネスの理解や要件がセキュリティチームの見解と大きく異なることがよくあります。

3. ビジネスの観点から見たセキュリティ研究開発のリスク

実際、ビジネス学生の視点から見ると、情報セキュリティ関連の業務も非常に重要視されており、企業のビジネス技術チームによっては、研究開発学生のセキュリティ関連問題への対応を支援するための専任のセキュリティチームを設置しているところもあります。企業がセキュリティ作業を排除したり、抵抗したりはしていないことがわかりますが、合理的で実行可能なセキュリティガイダンスが欠如しており、そのことがビジネス学生に製品のリスクを認識させていないことがわかります。実際のコンポーネントのリスク修復プロセス中に、多くのビジネス学生からフィードバックや苦情も受け取りました。要約すると、主に次のような状況があります。

互換性の問題 : 統合の主な手段としてバージョンアップグレードによるリスク修復を推進する場合、互換性の問題が企業から最も疑問視されることが多く、結局のところ、安定性は企業にとって非常に重要です。したがって、通常の状況では、アップグレードを推進する場合、最も安全で安定した修復バージョンをメインのアップグレードバージョンとしてプッシュすることがよくあります。しかし、この種の問題は特別なケースではなく、この種の修理が発生するたびに、企業は同様の質問をすることになります。この記事の長さを考慮して、ここでは詳しく説明しません。
セキュリティバージョンの問題 : 前の問題と同様に、ビジネス学生はコンポーネントを導入する際にセキュリティの問題も考慮しますが、セキュリティの知識が不足しているため、ビジネス学生は「安全なバージョン」についての判断に多少の差異があるため、ビジネス学生はセキュリティの問題を考慮する必要があります。セキュリティの学生にこの質問を投げてください。ただし、セキュリティの学生がこの質問に 100% 正しく答えることは困難です。オープンソースコンポーネントが多すぎて、ほとんどの企業は Google や Microsoft などの市場にあるすべてのコンポーネントのセキュリティを分析できないため、一般的にはそれしか使用できません。今すぐチェックしてください。行ったり来たりすると、この部分の品質と効率が低下します。したがって、この部分の要求も重要かつ緊急です。
「絶対的なセキュリティ」を追求する : ビジネス学生の中には、「さまざまなコンポーネントを安全に使用するにはどうすればよいですか?」と直接尋ねる人もいます。言葉は単純ですが、安全性の尺度や評価基準が十分に透明ではないという根本的な問題を反映している可能性があります。また、セキュリティ問題を数値化して基準の透明性を追求することも急務であるが、これについては運用上の問題であるため、ここでは説明しない。
コンプライアンスの問題 : 多くの企業は、オープンソース契約を理解していないため、オープンソース契約の制約に違反し、法的または知的財産の問題を引き起こしています。

実務的な観点から見ると、ビジネス学生はセキュリティに関する作業を行うことを拒否しません。多くの場合、それは効果的なメカニズムが欠如していることが原因です。インポートされたソフトウェアの依存関係が安全かどうか、またそれらの操作と構成には必要があるかどうかを学生に伝える必要があります。オープンソースコンポーネントをより安全に使用できるようにするために完成する必要があります。セキュリティエンジニアとして、私たちはビジネスの視点に立って、これらの問題が本当に解決できないのかを考える必要があります。ビジネスとセキュリティの両方にコンポーネントのセキュリティに関連する要件があるため、SCA テクノロジがビジネスとそれ自体のニーズを十分に満たす可能性があるため、SCA 構築プロセス全体でこれらの要件を常に調査する必要があります。

4. SCA構築のプロセス

実はSCAはそれほど高度な技術ではなく、現代の研究開発プロセスにおいて、プロセスの標準化、コンポーネントの充実、オープンソースコミュニティの活発化、開発コストの削減などにより、純粋に単独で書かれたプロジェクトプロジェクト全体に占めるコードの割合はますます低くなります。これは、サプライチェーン問題の影響がますます大きくなることを意味しており、DevSecOps の普及により、従来の SCA 技術が復活しています。

多くの企業の内部慣行と SCA テクノロジーに対する業界の理解によれば、SCA の中核機能には主に次の点が含まれると考えられます。

ソフトウェア資産の観点 : 企業は、すべてのアプリケーションシステムによってどのコンポーネントが参照されているかを明確に理解し、ほとんどのシナリオ (ビジネスアプリケーションシステム、Hadoop ジョブなど) をカバーするよう努める必要があります。データサービス、Puppet、その他の運用および保守サービス、など)、その開発プロセスを調査し、リスク発見のための SCA 機能をどの段階で導入できるかを分析します。
リスクデータの発見 : 現在はデータ爆発の時代です。セキュリティチームは、セキュリティリスク情報のさまざまなソースに毎日注意を払う必要がありますが、できるだけ多くのリスク関連データを収集し、状況に応じて統合する必要があります。自動および半自動で動作します。しかし、よく考えてみると、リスクの数を追求するだけでなく、より強力な実効性を追求し、先制攻撃の効果を達成することはできるでしょうか？企業内で長年にわたるセキュリティ脅威インテリジェンス機能の構築を通じて、有効性と使いやすさの二重の SLA を追求することは可能です。また、注意が必要なリスクは脆弱性と「汚染」の2つのシナリオに限定されるものではなく、オープンソースソフトウェアのベースライン情報も収集する必要があります。
リスクおよび資産関連のインフラストラクチャの構築: 最初の 2 つの方向はデータ次元の要件です SCA の実装を検討するのは情報セキュリティ部門だけの問題ではありません保守チームが無害な相互作用メカニズムを確立して初めてセキュリティを実現できます機能はビジネスに浸透するため、コア API 機能の構築を実現し、ビジネスを強化するために関連するインフラストラクチャを構築する必要があります。簡単そうに聞こえますが、実際に開発されるのは、UDF の機能であったり、一部の分析サービスのプラグインであったり、CEP (Complex Event Process、リアルタイムコンピューティングに応用された分析技術) のルールであったりします。
可視化に関する要件 ：リスクが存在する今、セキュリティチームやビジネス関連チームの学生は、システム開発を担当する学生にもリスクを知るだけでなくその存在を理解させ、タイムリーに解決策を提示して導く必要があるビジネスの完了と同時に、セキュリティチームはリスク修復の進捗状況を把握するために運用データを取得する必要もあります。

ことわざにあるように、「ローマは一日にして成らず」。SCA の建設要件と建設の方向性は決定されましたが、実装はまだ段階的に完了する必要があります。他のセキュリティサブシステムの構築と同様に、セキュリティチームは基本データ/SOP から構築を開始し、次にプラットフォームとシステムを構築して、SCA 機能全体の実装を完了する必要があります。したがって、実際の運用プロセスでは、全体の構築を次の 3 つの段階に分割する必要があります。

第 1 段階 : データのインベントリと収集プロジェクト構築の初期段階で、情報セキュリティチームは、企業の内部インフラストラクチャに関連するチームと協力して、企業の内部基本コンポーネントのデータ資産インベントリを完了する必要があります。基盤技術と情報セキュリティの観点から研究開発技術スタックと研究開発プロセスのリンクを整理し、適切な位置にデータを貼り付けることで関連データを取得し、資産データの収集を完了します。一方、情報セキュリティ部門は、既存の脅威インテリジェンスの経験とデータに基づいて、コンポーネントデータをカプセル化および統合し、インターネット全体からリスクを収集することを目的とした別個のオープンソースコンポーネントリスクデータベースを構築し、インターネットとの連携を容易にします。その後の資産データ。
第 2 段階 ：SOP（標準運用手順、標準的な運用手順）と概念実証の構築情報セキュリティチームは自らの脆弱性修復経験を通じて SOP を強固にし、継続的なチューニングを通じて一般的な脆弱性修復 SOP を完成させます。コンセプト (PoC、概念実証) は、SOP が既存の技術条件下でリスク修復の部分を十分に完了できることを証明します。同時に、SOP と組み合わせて、以前に収集された資産データとリスクデータがチェックおよび入力され、データとデータリンクの検証が完了して、システムの高可用性が確保されます。この段階で、SCA サービスプロバイダーは、いくつかのコア API を一部の企業の品質チームと効率チームに公開し、テストの実施とフィードバックの収集を支援し、それらを自社のリスクガバナンスリンクに統合する必要があります。
第 3 段階 : プラットフォームの構築と安定した作業のサポート SOP が最初に作成され、概念実証が完了したら、この部分の作業を分離できるように、対応するプラットフォームとサブシステムを構築する必要があります。手動統計により、ほぼ 100% オンラインになります。内部 SOC のモジュール設計のおかげで、SCA 関連のサブシステムを既存のプラットフォーム上に簡単に構築して、機能データを完成させることができます。エンドユーザーのリスクを視覚化するという問題を目指して、SCA サブシステムは、研究開発学生がリスク情報の同期を完了できるようにコア API を SOC プラットフォームに提供します。サービスの高可用性を確保するために、サポートするデータリンク検査メカニズムが将来構築され、データの可用性が継続的に向上します。

より重要なジョブのいくつかを上に示します。3 つのフェーズが完了すると、おそらく SCA の機能が構築されますが、構築プロセス中にセキュリティチームは多くのことを考慮する必要があります。セキュリティベンダーのセキュリティ製品やサービスが問題解決の「分子」だとすれば、甲のセキュリティチームの仕事は、それをより大きく、より包括的にする「分母」に当たるものです。見逃されることはありません。

まず、資産構築に関しては、企業内のセキュリティチーム、品質効率チーム、データプラットフォームチームなどの研究開発プロセスを持つ技術チームが協力して、CI/CDシステムデータとデータサービス構築データの収集を完了する必要があります。また、IDE プラグインチームがコード開発からアプリケーション起動までのデータ収集を完了するための SCA API も提供します。

しかし、データのこの部分を適用した後、データ自体の品質と精度とは別に、多くの問題が見つかりました（それについて話さないということは、それが重要であるという意味ではありません、逆に、この部分は非常に重要であり、この部分は将来後述）、前述のシナリオに応じて、多くの追加シーンがあります。たとえば、ビジネスの一部がグレースケール化された後、まだグレースケール化されていないことは忘れられ、その結果、サービス対象の一部のマシンのみが修理されることになります。別の例としては、多くの「かわいい」が自社のマシンをバイパスしてしまうことです。デプロイメント操作のための CI/CD プロセス (独自のものもあります)。これらの例外を考慮するには、ホストの粒度、つまり、ホストインスタンス (Docker コンテナー、仮想マシン、物理マシン)、シェルログおよびその他の情報を分析した結果、ホストインスタンスが修復されたと判断されます。このようにして、リンクとホストの次元を構築するデータのポジティブおよびネガティブ検証メカニズムを確立しました。理論的には、ホスト側の HIDS Agent のカバー率と生存率が基準を満たしていれば、詳細なソフトウェア資産データをほぼ取得できます (もちろん、データの不正確さや遅延などの問題は残ります)。ランディングコアプロジェクトと構造的関係の詳細については、次の図を参照してください。

データカバレッジがほぼ同じ場合、データのクロスオーバーと分析を完了するためにデータバスを通じてデータウェアハウスとコンピューティングエンジンにデータを渡す必要があり、その結果がリスクとリスクの進行状況になります。ここで、リアルタイムエンジンは、一方では増分資産データの分析を行う必要があり、他方では、分析のために多くの集約された CEP ルールも保存します。オフラインエンジンは、株式リスクの定期的な検出とガバナンスを完了します。

資産データの収集について説明した後、リスクデータの収集について説明します。脅威インテリジェンスシステムの構築段階の早い段階から、コンポーネント脆弱性インテリジェンスは、基本的なセキュリティインテリジェンスアプリケーションシナリオにおける脆弱性インテリジェンスのサブセットとして常に存在していました。しかし、これまでの「脆弱性＝リスク」という概念により、実際の実装プロセスではコンポーネントの脆弱性に関するリスク情報のみが保存されており、既存の要件と実態を総合的に評価した結果、現在のコンポーネントの脆弱性データは、研究開発のセキュリティリスクのガバナンス作業の一部しか引き受けることができません。サプライチェーンポイズニングやオープンソースコンポーネントのベースライン状況など、その他のリスクデータについては、当時ビジネス利用に耐えうる成熟した機能を提供できるデータが存在しなかったため、十分な議論と研究を経て、コンポーネント関連のデータを含めることが決定されました。脆弱性データを分離し、その他のサプライチェーンセキュリティのリスクデータを新たに収集し、コンポーネントセキュリティに関するデータベースを再構築し、リスクデータの保管と活用を完了します。

コンポーネントのリスク収集に関する当社独自の脅威インテリジェンスの実践と業界のベストプラクティスを組み合わせることで、次の 5 つの側面からコンポーネント関連のリスクを収集して保存する予定です。

NVD/CNVD/GitHub-GHSAなどの一般的な脆弱性データベース：脆弱性リスクを収集し、脆弱性の実態に基づいて人手による調査・判断を行うための基本的な業務です。
Jira、Commit、Release、BugziliaなどのPull-Request関連データ ：関連データを取得し、自社開発のNLP（Natural Language Process、自然言語解析）解析エンジンと組み合わせてコンテンツの傾向を判断し、フィルタリングし、セキュリティ関連情報を出力し、手動または自動で調査・判断を整理することで、リスクを事前に発見できることが実践を通じてわかりました（筆者はリスク発見の必要性と導入経験についてISC2019で説明したことがあります）。
コンポーネント別リスクライブラリ：当社が脆弱性データを調査した後、GithubやSnykなどの機関が専用のコンポーネントリスクライブラリを保有し、その情報を取得・分析することで処理後のユーザビリティの高いコンポーネントを取得できます。要求に応じて研究され、判断される。
ソフトウェアのリスクに関するニュース情報と RSS フィード : このタイプのソースは主に、APT 組織が実際に悪用したゼロデイ脆弱性や脆弱性を解決しますプルリクエストデータと同様に、このタイプのリスクデータのほとんどは NLP を通過する必要があります分析エンジンは、インテリジェンスデータ分析を行い、使用可能な基準に達する前にさらに感情的な推論を実行します。
手動入力 ：これも定型的な作業です。多くの種類のリスクが収集されますが、サプライチェーン攻撃の種類と展開によって実際には制限があり、すべてを考慮することは不可能です。リスクを補完するには、依然として手動インターフェースが必要です。操作する必要があります。ただし、セキュリティチームは、すべてのリスクに対する手動で入力されたリスクの割合を合理的な範囲内で制御して、運用担当者の問題 (経験不足、退職など) によって機能のこの部分がフラッシュされないようにしたいと考えています。、等）崩壊の欠陥。

上記の内容から、データの大部分が非構造化されていることが分かりました。つまり、直接使用することができず、使用する前に加工（異種データ、自然言語データ）する必要があるため、 NLP 分析エンジンは処理中に導入され、脆弱性リスクデータがマークされた後 (主な作業は RepoID を追加して資産データとリンクすることです)、それをデータエンジンと API に渡すことができます。

脅威インテリジェンスのデータ構築の観点から見ると、2019年頃、基本的なセキュリティ関連の脅威インテリジェンスは構造化インテリジェンスと非構造化インテリジェンスの比率が約1:1に達し、現在では非構造化インテリジェンスのデータが構造化インテリジェンスのデータをはるかに上回っており、その比率は近づきつつある設計目標に近づくと、具体的なランディングコア作業の内容と関係構造が次の図に示されます。

リスク情報処理のプロセスでは、リアルタイムコンピューティングエンジンとオフラインエンジンの機能が資産データ処理と一致し、主に増分と在庫の問題を解決します。同時に、ビジネス自体がリスクを自己チェックする必要があることを考慮して、SCA プラットフォームはいくつかのコア API もビジネス側に提供します。

こうしたデータ関連インフラの構築を始める際には、プラットフォーム自体の問題により一部の主要機能が大規模に利用できなくなることを防ぐために、いくつかの構築指標を提案する必要がある。資産に関しては、現在の資産データベースインフラストラクチャは TB レベルの資産データの取得をサポートでき、戻り時間は 100 ミリ秒を超えません。また、リスクデータ構築に関しては、現在合計 10 のテクノロジースタック (以下を含む) をカバーしています。主流の Maven/Gradle、PyPi、NPM、SPM、APT/Yum、CocoaPods) 合計約 590,000 個のリスクデータ、更新サイクルは 2 時間以内、計算エンジンは資産データと迅速に照合できるため、95 近くのコストを節約できます。トラブルシューティング時間の % が短縮され、業務効率が大幅に向上します。

マッチングルールの構築では、データソースが多く乱雑であるため、自社開発のNLP解析エンジンにより大規模な学習とデータ処理を行った後、比較的固定されたデータ構造に統合することで実現可能です。マーキング処理後もアセットデータと効率的に連携。

NLP モデルの学習プロセスや学習方法は SCA 構築プロセスにおいて重要な技術ではないため、本稿では詳細な学習プロセスや感情推論学習プロセスについては説明しません。リスクデータベースは、資産情報の関連付けに加えて、CVSS（Common Vulnerability Scoring System、つまり共通の脆弱性スコアリングシステム）と照合することもでき、CVSSの影響範囲に応じた情報をタイムリーにプッシュすることができます（ここではCVSSスコアとは言いませんが、 CVSS スコア）、説明表現）の脆弱性情報を提供し、セキュリティ運用の学生に関連するリスクに注意を払い、適時に調査と判断を行うよう思い出させます。

危険なベースラインデータについては、現時点ではベースライン建設データの比較的完全な参照標準はありませんが、OpenSSF Foundation (Open Source Security Foundation、Google やその他のインターネット企業と米国政府の推進のもとに設立されたオープンソースコンポーネントセキュリティ基金) は、 ) 2021 年後半にリリースされた ScoreCard 関数は優れた参照標準であり、同じく OpenSSF によって開始された AllStar ベースライン検出ツールと組み合わせることで、コンポーネントのベースラインに関連するデータを完全に補完できます。

5. SCA構築で遭遇する問題点

もちろん、SCA 建設のプロセスはすべてが順風満帆だったわけではありませんが、主に以下の点を含む困難な部分をまとめてみましょう。

脆弱性と資産の関連付けルールには成熟した有効な業界標準が欠如している: SCA 分野では、現在、NVD 関連の生態環境に匹敵する成熟した生態環境はありません。NVD システムでは、脆弱性情報と資産を記述するために CVE が使用されます。影響範囲：CPE (共通製品列挙)、攻撃経路を記述する CAPEC (共通攻撃パターン列挙および分類)、およびリスクの種類を記述する CWE (共通弱点列挙)。しかし、コンポーネントセキュリティの分野では、各社のインフラストラクチャ構築の成熟度や技術選択に大きな違いがあるため、「すぐに使える」完全なエコシステムが存在しません。既存の技術アーキテクチャとインフラストラクチャに基づいて独自のルールを設計し、同時にこの一連の標準をセキュリティ運用に実装することを促進します。
データ品質とデータリンクの信頼性: データの品質と可用性の問題は、プロジェクトの開始から後の運用段階までに発生する問題であり、上流の収集ロジックの不完全や収集エラー、データリンクの不安定などが原因で発生する可能性があります。コンピューティングエンジンへの書き込み時に大量のバッチ損失が発生するという問題があり、データリンクの検査メカニズムがないため、具体的な問題がどこにあるのかは不明であり、使用されているデータ分析テクノロジスタックによっても、送信されたデータがデータは CEP ルールの正確性と有効性に影響を与える可能性があります。これらの問題の中には偶然ではなく、実際のアプリケーションシナリオで頻繁に発生する問題もあるため、長期的なデータダイヤルテストメカニズムとデータ汚染追跡機能を確立することが必要かつ必要です。
リスクデータのデータ構造と精度: リスクデータにはあまりにも多くのソースが導入されており、モデルトレーニングの精度を考慮して、非構造化データを構造化データに変換するために多数の機械学習およびNLPテクノロジーが導入されているため、トレーニングサンプルデータ、トレーニングネットワーク、その他の問題により、プラットフォームによって抽出された脆弱性情報には特定の矛盾が存在することが多く、リスクインテリジェンスのデータはコンテキストと有効性により依存するため、さまざまな側面でトレードオフを行う必要があります。この問題は実際に関連しています。データの問題も同様で、一朝一夕に解決できるものではなく、解決を進めるためには多くの実践的な運用と、ケースバイケースでのダイヤルテストメカニズムが必要です。
非標準資産の CI/CD 制御とガバナンス: この側面は実際には SCA の実装とはほとんど関係ありませんが、言及された理由は、SCA 自体が R&D プロセスと強く関連する必要がある機能であるためです。プラットフォームは、ユーザーが迅速に操作できるように標準化された API と GUI を提供できるだけでなく、非標準の公開プロセスやオンライン標準と互換性がある必要があります。そのため、主要なテクノロジースタックに加えて、一部のニッチなテクノロジースタックも引き続きカバーされています。 Powershell の C#/NuGet、ErLang の Hex パッケージ管理など。
アセットパースペクティブの深さ: この部分は、実際には SCA のコア機能の現れです。理論上、SCA は FatJar などのオープンソースコンポーネントにネストされた JAR パッケージを分析できますが、実際にはデータ品質と技術的能力により分析できないことがよくあります。非常に細かい粒度になるため、この部分では、関連する設計をガイドする MTI (ここでの最大許容指数は、許容可能な最も粗い分析粒度を表します) 指標を設計する必要があります。

6. SCA技術の将来性の展望

構築プロセス中に、コンポーネントのリスク分析とガバナンスに関して多くの企業と商用製品のベストプラクティスを参照し、ソフトウェアコンポーネント分析テクノロジーとソフトウェアサプライチェーンのセキュリティガバナンスに関連する多数の論文、公開特許、企業文書をレビューしました。 .さんのブログです。OpenSSF Foundation の研究結果には、印象的なものがあります。

OpenSSF が 2021 年 6 月に SLSA (ソフトウェアアーティファクトのサプライチェーンレベル、つまりソフトウェアサプライチェーンのセキュリティレベル) をリリースした後、分析に役立つ多くのデータサービスと製品が、準SCA 製品 Open Source Insight、OSV (オープンソース脆弱性、オープンソースコンポーネントリスクデータ)、ソフトウェアセキュリティベースラインチェックツール AllStar および ScoreCard、オープンソースコンポーネントリスク報酬プログラム SOS Rewards (オープンソースコンポーネントの脆弱性報酬プログラムとして理解できます) ）。

私たちは、将来の SCA 構築ルートは 3 つの方向にあるべきであると予備的に見ています: 十分にきめの細かい資産およびリスクの視点機能の追求、リスクのプロアクティブな特定、およびオープンソースソフトウェアのベースライン検査機能です。言い換えれば、SCA が十分な効果を発揮したい場合は、コードの整合性、プロセスの整合性、ベースライン検査機能など、ソフトウェア開発から発売までのすべてのリンクをカバーする必要があり、これらのすべてに SCA の中核機能が必要です。

SCA が提供するリスク視点機能に加えて、DevSecOps プロセス全体において、セキュリティチーム、品質効率チーム、運用保守チーム、ビジネスチームが暗黙のうちに連携する必要があり、全員がそれぞれの職務を遂行し、共同で研究開発リスクを解決します。その中で、セキュリティチームが提供できるものには、リスクデータや修復提案に加えて、ビジネスチームがより効率的にリスクに対処できるよう、対応するインフラストラクチャサービスも提供する必要があります。オープンソースソフトウェアのリスクガバナンス全体に拡張して、参考用のチートシートも提供します。

もちろん、上記のプロジェクトをすべて実行したい場合は、実際には企業のインフラストラクチャとインフラストラクチャに特定の要件が必要ですが、幸いなことに、オープンソースコミュニティは、OpenSSF やChainGuard.dev、SigStore、Anchore など、営利企業によって設計および開発された一連のツールチェーンです。もちろん、中国には優れたオープンソースソリューションが数多くあります。特定の変更を加えた後、既存のインフラストラクチャに統合できます。

反セキュリティ属性が含まれていることを考慮すると、SCA ツールが企業の研究開発プロセスに組み込まれる場合、必然的に SCA 検出に対抗する多くの方法が必要になります。したがって、SCA 機能の構築を継続する過程で、「網をすり抜けた魚」を防ぐために、対立検出と強化を徐々に追加します。

7. 結論

上記は、SCA の能力構築のプロセスを通じて私たちが蓄積してきたいくつかのアイデアと実践です。SCA 機能を構築する過程で、さまざまなチームとの共同作業とコミュニケーションを通じて、多くのビジネスアイデアとコンポーネントセキュリティの実際のニーズを学び、要件を通じて構築する必要がある機能を導き出しました。技術ソリューションの実装において、HIDS エージェントや RASP など、企業内に導入されている多くのセキュリティ製品は、ホストの観点から構築プロセスが正しいかどうかを逆検証できます。

さらに、SCA 機能の実装は、セキュリティチームとビジネスチームの協力と切り離すことができません。実際、SCA 構築のプロセスでは、より深いレベルで見ると、クローズドソースソフトウェア、オープンソースソフトウェアのクロスアーキテクチャ、クロスコンパイラの識別、他のキャリアのセキュリティ分析 (たとえば、これらの技術的課題は、企業での SCA 機能の実際の実装には依然として非常に高いものですが、現在のソリューションがまだ PoC 段階にあることを考慮して、ここでは詳しく説明しません。

もちろん、着陸プロセス全体に関わらず、各社のインフラやコア技術スタック、ホスト情報の監視能力の違いを考慮すると、実装できない箇所はあるはずだ。セキュリティサービスプロバイダーの観点から見ると、SCA 関連製品の将来の構築は、より軽量で、オープンで、協調的なものになる必要があるかもしれません。

いわゆる軽量とは、製品のコア機能がさまざまなインフラストラクチャから分離されることなく、安定的かつ効率的にコア機能を提供でき、顧客の研究開発プロセスと完全に接続できることを意味します。調査結果によると、現在市販されているすべての SCA 製品は基本的に比較的重いアーキテクチャ設計上の問題を抱えており、既存の CI/CD プロセスにうまく統合することができません。いわゆるオープンコラボレーションとは、他のセキュリティ製品やセキュリティ機能とさまざまな方法で提供できるデータ共有メカニズムを指し、他のセキュリティデバイスとのデータ連携を実現し、対応するリスク発見機能を相互に補完して、シンプルかつ効率的なセキュリティを実現します。。

これらは、SCA の能力構築プロセスにおけるいくつかの考えです。長期的な観点から、導入、開発、コンパイル、展開、使用に至るプロセス全体をカバーする、ソースからの完全なゼロトラストサプライチェーンリスク管理および制御システムを確立し、真の Secure-by-デフォルト。

垂直的な観点から、システム全体の SBOM レベルのデータ依存関係を、研究開発プロセスの枠組みの中で可能な限り完全に明確にする必要があります。同時に、水平的な観点から、これまでに収集されたコンポーネント関連のリスクデータと制限データによってカバーされる技術スタックが十分に包括的で正確であることを確認する必要もあります。たまたま、これら 2 つの機能が SCA 機能の 2 つのコア機能であるということは、SCA 機能がシステムの重要な部分であり、システム全体に完全な知識ベースを提供し、基礎を提供できることを意味します。その後のサプライチェーンのリスク管理に向けて、リスク検出ロジックにより完全なデータセットが提供されます。

最後に、SCA の能力構築プロセス全体を通じて支援と提案をいただいた、Diandian Business Group の技術部門の Meituan 品質効率チーム、基礎技術チーム、およびケータリングテストチームに特別に感謝します。同時に、皆さんも記事の最後にコメントを残してください。

8. この記事の著者

Li Zhongwen (e1knot)、Meituan のシニアセキュリティエンジニア。

9. 参考文献

From:オープンソースコンポーネントのリスクにどう対処するか? ソフトウェアコンポーネントセキュリティ分析 (SCA) 機能の構築と進化 - Meituan 技術チーム