アプリケーションセキュリティのテストおよび分析機能ガイド

Weixin Consultingより転載: https://mp.weixin.qq.com/s/SqKrWM5KpBZGQKHB0lxHTw

序文

近年、オープンソースコンポーネントに起因するセキュリティ問題が多発しており、2017年には米国の信用調査会社EquifaxがApache Strutsの脆弱性を修正できず、大規模な個人情報流出事件が発生、2020年には、 SolarWinds がハッキングされ、顧客が直接攻撃される原因となった脅威; 2021 年に Log4j の脆弱性が暴露されたことで、グローバル企業の間で懸念が高まり、米国サイバーセキュリティ審査委員会は、この脆弱性が 10 年間続く可能性があると考えています。

オープンソースコンポーネントの問題は、ソフトウェアサプライチェーンのセキュリティに対する懸念の波を引き起こしました。ソフトウェアサプライチェーンのセキュリティは、開発セキュリティと関連付けられることがよくあります。多くの企業がオープンソースコンポーネントを使用して、自社の環境で必要なアプリケーションを開発しているため、これはある程度理解できます。DevOpsの概念の出現により、「開発」自体はビジネスの一部にすぎず、開発と運用が徐々に統合されて閉ループを形成し、この閉ループは企業のアプリケーションそのものを中心に回ります。

オープンソースのセキュリティと開発と運用の統合は、アプリケーションのセキュリティ概念とソリューションに新たな変化をもたらしました。ソフトウェアサプライチェーンセキュリティ、DevOps、または DevOps に基づく DevSecOps のいずれであっても、アプリケーションセキュリティの分野に一定の影響をもたらし、さまざまな概念や概念に混乱をもたらしさえしました。したがって、このレポートは完全に特定のセキュリティ分野から始まるのではなく、アプリケーション開発からアプリケーション起動までの企業の主流ツールを共通点に基づいて 1 つのレポートにまとめています。

重要な発見

·現在のアプリケーションセキュリティのテストおよび分析市場のプレーヤーは、独自の競争力のある製品を持っていますが、すべての製品タイプをカバーできるソリューションはなく、複数のサプライヤーの製品を組み合わせることができるアプリケーションセキュリティ統合プラットフォームが主要なプレーヤーのニーズになります。

·アプリケーションセキュリティはソフトウェアサプライチェーンセキュリティと同じではありませんが、ソフトウェアサプライチェーンセキュリティの人気により、確かにアプリケーションセキュリティに大きな注目が集まっています。特にSCA製品の分野では、近年国内外でソフトウェアサプライチェーンを拠点とした攻撃事故が多発していることを踏まえ、オープンソースコンポーネントのセキュリティ管理が企業にとって注意を払わなければならない事象となりつつあります。。

·現在のアプリケーションセキュリティのテストおよび分析製品市場は、依然として SAST 製品の中で最大であり、SCA 製品は過去 2 年間で急速に発展し、その割合は SAST 製品に次いで 2 位となっています。今後はファズテストやアプリケーションセキュリティプラットフォーム製品にも注目だ。

SAST製品であってもSCA製品であっても、依然として多くの技術的不完全性が存在します。たとえば、SASTは低い偽陰性率を確保しながら偽陽性率を減らす必要があり、SCAはコードフラグメントに基づいてオープンソースをより迅速に識別できる必要があります。リスクなど。

アプリケーションのセキュリティのテストと分析の概要

アプリケーションセキュリティのテストと分析の範囲

このレポートにおけるアプリケーションセキュリティのテストと分析は、企業自身が開発したアプリケーションのセキュリティを確保するために、アプリケーション内のコードとアプリケーションの相互作用のテストと分析を特に指します。関連製品には以下が含まれますが、これらに限定されません。 SAST、DAST、IAST、SCA、ファズテスト、アプリケーションセキュリティ管理プラットフォームなど。ただし、アプリケーション自体のセキュリティを検出するのではなく、アプリケーションを保護する RASP などのセキュリティ製品は含まれていません。

アプリケーションのセキュリティのテストと分析、コードのセキュリティ、ソフトウェアサプライチェーンのセキュリティ

アプリケーションセキュリティのテストと分析の対象となるいくつかのツールは、多くの場合、コードセキュリティとソフトウェアサプライチェーンセキュリティに関連しており、多くの場合、3 つの間にさまざまな包含関係が形成されます。しかし、実際には、この 3 つにはまだ違いがあります。

アプリケーションはコードで構成されていますが、アプリケーションのセキュリティのテストと分析はコードのセキュリティと同じではありません。

従来のコードセキュリティは、アプリケーション内のコードを直接検出および分析してコードの抜け穴を見つけることであり、この機能の部分は現在 SAST および SCA によって実行できます。ただし、現在の環境では、コードのセキュリティ検出のみに依存するだけでは十分ではありません。コード自体に脆弱性がないからといって、そのコードによって実装された最終アプリケーションが安全であるとは限りません。アプリケーションの実行中に、脆弱性が存在する可能性があります。アプリケーションのベースとなるロジックの脆弱性攻撃を受けるリスクを引き起こす脆弱性。

したがって、アプリケーションが安全かどうかをコードだけで判断するだけでは、現在のニーズを満たすには十分ではありません。完全なアプリケーションセキュリティ検査には、ランタイムアプリケーションのテストも含める必要があります。つまり、テストはコードではなくアプリケーションに基づいて行う必要があります。

一方で、近年、オープンソースコンポーネントやサードパーティコンポーネントによる攻撃が大幅に増加し、その影響が大きいため、ソフトウェアサプライチェーンのセキュリティは開発セキュリティと関連付けられることが多いです。実際、ソフトウェアサプライチェーンのセキュリティに対するこの理解は間違いなく狭いです。

ソフトウェアサプライチェーンの下流の観点から見ると、ソフトウェアのエンドユーザーは、関連するソフトウェアまたはコンポーネントが自身のビジネス環境で正常に動作し、セキュリティリスクがないことを確認する必要があります。これには、システムベースのシステムも含まれる必要があります。オープンソースコンポーネント、および完全にサードパーティベンダーによって提供されるソフトウェア。その一方で、今年のロシア・ウクライナ戦争から、オープンソースコミュニティ、オープンソースコンポーネント、あるいはサードパーティサプライヤーのソフトウェアであっても、テクノロジーにも国境があることに気づかなければなりません。利用できない場合でも、組織に深刻な影響を与える可能性があります。露ウクライナ戦争中、多くの欧米企業や組織がロシアでの事業や支援を中断したことにより、ソフトウェアのサプライチェーンに起因するロシア関連組織の事業中断を解決することを意味する。

同時に、ソフトウェアサプライチェーンセキュリティの上流サプライヤー側は、開発セキュリティの観点から製品やコンポーネントのセキュリティを確保するだけでなく、開発から納品、さらには運用・運用に至るまでのリンク全体のセキュリティを確保する必要があります。メンテナンス。また、川下顧客の安全意識がますます高まっている場合、サプライヤーが関連製品の安全性証明書や成分リストを積極的に提供できるかどうかも考慮すべき要素となります。

SolarWinds 攻撃を例に挙げると、SolarWinds 攻撃はソフトウェアサプライチェーンに基づく APT 攻撃とみなすことができます。SolarWinds 自体は、すべてのリンクで独自のコードのセキュリティを確保し、テストを行ってきました。しかし、最終テストが完了して配布段階に入ったとき、攻撃者が忍び込んでコードを改ざんしました。この攻撃は明らかに開発セキュリティ分野の盲点に位置しており、攻撃を発見してブロックするには企業内の他のセキュリティ保護メカニズムが必要です。SolarWinds ユーザーにとって、SolarWinds に悪意のあるコードがあることを知った後、影響を受けるビジネスシステムをどのように迅速に特定するか、攻撃されているかどうかを判断する方法、および対応して防御する方法、この一連の動作には複数の分野のセキュリティが関係します。しかしそれはすべて、ソフトウェアのサプライチェーンに隠れた危険があるためです。したがって、ソフトウェアサプライチェーンのセキュリティは、少数のセキュリティ製品でカバーできる領域ではありません。

ソフトウェアサプライチェーンセキュリティでは、アプリケーションセキュリティのテストおよび分析関連製品が主に、開発段階からオンライン段階までアプリケーション自体のセキュリティをカバーします。主に開発者の観点から、開発されたアプリケーションのセキュリティを確保します。しかし、将来の開発の観点から見ると、SCA はソフトウェアサプライチェーンの上流と下流の関係を開く可能性があります。下流のユーザーはサードパーティサプライヤーのコンポーネントの使用状況をより完全に把握できるため、ソフトウェアの供給に対処できるようになります。より包括的なリスクの連鎖。

開発セキュリティからアプリケーションセキュリティまで

ウォーターフォール開発と従来のアジャイル開発モデルでは、主な目標はソフトウェア開発を完了することです。DevOps が登場すると、開発と運用が徐々に結合されます。現時点では、アプリケーションの保護と検出は開発に限定されません。たとえば、テストプロセスでは IAST がよく使用され、このシナリオはすでに終わりと見なすことができます。従来の開発モデル、開発環境から運用シナリオに移行するプロセス、例えば本レポートでは触れていないRASP（Runtime Application Self-Protection、Runtime Application Self-Protection）なども保護を目的としています。実際の実行時にアプリケーションのセキュリティ機能を監視し、運用シナリオのセキュリティ機能で使用されます。広い意味では、開発セキュリティは開発段階でアプリケーションのセキュリティを保証しますが、アプリケーション自体の開発後もセキュリティ保護が必要な実際の使用シナリオが存在します。したがって、最終的な保護の目標は、開発シナリオのセキュリティを確保することではなく、開発されたアプリケーションの設計、プロジェクトの確立から運用に至るまでの包括的なセキュリティを実現することです。

企業が選択する開発モデルは、自社のビジネスニーズによって異なります。また、具体的な実装に関しては、企業の環境や IT 能力によっても異なりますが、アプリケーションのセキュリティ要件には多くの共通点があります。したがって、企業がどのような開発モデルを使用しているとしても、アプリケーションセキュリティツールの選択には、依然として主流のアプリケーションセキュリティツールが含まれます。

さまざまな種類のアプリケーションセキュリティテストおよび分析ツールについて、良いものと悪いものを絶対的に区別することはできず、各ツール自体は、特定のセキュリティ要件を解決するためにさまざまな開発または運用シナリオに存在します。企業が行う必要があるのは、アプリケーションのセキュリティ要件に基づいて、対応するアプリケーションセキュリティツールを適切な位置および段階で展開し、アプリケーションの継続的なセキュリティ保護を実現することです。

アプリケーションセキュリティのテストと分析現在の市場状況

·アプリケーションセキュリティのテストおよび分析製品は、基本的に 2022 年のデジタルセキュリティ成熟度ラダーのヒートゾーンにあります。SAST、IAST、SCA はすべて「統合イノベーション」および「開発市場」の分野にあり、ファズテストは「統合イノベーション」および「開発市場」の分野にあります。「統合イノベーション」と「新興市場」、一方、DAST は停滞ゾーンにあります。

Data World Consulting の中国デジタルセキュリティ能力マップ 2022 では、それらはすべて「アプリケーションシナリオセキュリティ」に位置し、「開発およびアプリケーションセキュリティ」の指揮下にあります。

· 過去 2 年間、ソフトウェアサプライチェーンのセキュリティに対する重要性の高まりにより、アプリケーションセキュリティの全体的な市場規模は急速に成長しました。来年、アプリケーションセキュリティのテストおよび分析製品の国内市場は12億元に達すると予想されている。

· 現在の市場から判断すると、SAST は依然としてアプリケーションセキュリティのテストおよび分析市場の主要製品です。企業にとって、SASTはアプリケーションセキュリティのテストおよび分析製品において必須の製品であると言えます。一方、SCAは発足してから日が浅いものの、市場の反応はSCAを上回り、今後の需要を考えるとSASTのようなアプリケーションセキュリティシステムの標準構成となる可能性が高い。また、「その他」のカテゴリーでは、アプリケーションセキュリティプラットフォーム製品の現状の収益は高くないものの、今後需要が高まる「その他」のファジング、ファズテスト、つまりファズテストが挙げられます。まだ大規模な市場の反応を引き起こすには至っていませんが、長期的には企業が注目するセキュリティツールの 1 つになるでしょう。

· 顧客市場地域の観点から見ると、華東と華南の 2 つの地域が最も高い割合を占めており、どちらも約 30% であり、これが地域市場の規模が大きい主な理由です。中国北部が3位で約25％を占めている。

一部メーカーからのコメント

Haiyunan: Haiyunan の SAST は「アジャイル」方法論を取り入れており、アジャイル開発プロセス全体の開発傾向に合わせて「アジャイルホワイトボックス」という概念を初めて提案しました。

Kude Woodpecker: Kude Woodpecker の主な製品は SAST で、これは中国で最も初期の SAST 製品の 1 つです。独自の欠陥アルゴリズム分析により、重大な欠陥につながる可能性のあるソースコードの抜け穴を効率的に検出し、特定して警告します。

Moan Technology: Moan は、中国で DevSecOps の概念を最も早く推進したセキュリティベンダーの 1 つです。Mo'an の IAST は、基本的なセキュリティ検出に加えて、個人のプライバシー情報を検出する機能も備えています。その SCA は、ソースコードとバイナリの 2 つの検出モードをサポートし、コンポーネントライブラリアクセスとセキュリティブロック機能を備えています。一方、Moan は、複数のアプリケーションのセキュリティ機能に基づいて、企業が統合プラットフォームを通じて開発ツールの統合管理を実現するのを支援します。

Qi Anxin: 中国で早くからアプリケーションセキュリティに参入した総合的な大企業として、Qi Anxin はアプリケーションセキュリティにおいてかなりの蓄積を持っています。Qi Anxin のアプリケーションセキュリティのテストおよび分析製品は主に SAST と SCA であり、どちらも国内市場で最大の市場シェアを持っています。

Sike Cloud: Sike Cloud の SAST は、プロジェクトシナリオに基づいた「スマートリダクション」二次ノイズ低減テクノロジーを通じて、製品の誤警報の数を首尾よく削減できます。同時に、中国における最先端の増分テスト機能により、製品の誤警報の数も大幅に削減できます。インクリメンタルコードによって引き起こされる脆弱性の見逃しレポートの数。Sike Cloud の SCA は、数億のオープンソースコンポーネントとオープンソースコードのデータ量に基づいて、オープンソースのセキュリティと相同性分析の 2 つの主要な機能要件を考慮して、コードを分析し、10 バイトレベルのコードフィンガープリントと照合します。

Xiaodao Technology: Xiaodao Technology は、IAST、SCA、RASP の 3 つの主要なソフトウェアサプライチェーンセキュリティアトミック機能を 1 つのプローブで接続し、「オールインワン」スリーインワンプラットフォームを統合し、実稼働環境でパイロット実践を実施します。金融機関がアプリケーションのセキュリティを実現し、ライフサイクルサポート機能を実現します。

Suspension Mirror Security: Suspension Mirror Security は、中国で DevSecOps とソフトウェアサプライチェーンセキュリティを推進する主要メーカーの 1 つです。Xuanjing の IAST 製品を企業の DevOps プラットフォームと組み合わせて、CI/CD パイプラインでの迅速なセキュリティテストのニーズを満たすことができます。その SCA 製品は、Xuanjing の IAST の機能を使用して、実行状態のオープンソースコンポーネントを検出できます。商用 SCA 製品に加えて、Xuanjing のオープンソース SCA 製品も多くの開発者のセキュリティ意識を高め、オープンソースコンポーネントをより安全に使用できるようになりました。さらに、Xuanjing Security の Fuzi プラットフォームは、プラットフォーム方式でフルプロセスの DevSecOps セキュリティ管理機能を企業に提供できます。

なお、今回はプラットフォーム製品やファズテストなどの機能のドットマトリックスは含まれていないため、引き続き注目すべき企業は以下のとおりである。

Billion Technology: すべての開発セキュリティサプライヤーの中で、Billion Technology はプラットフォームであることが特徴です。ASOC プラットフォームを通じて、SCA、SAST、IAST、DAST、Fuzzing、RASP などの開発およびアプリケーションセキュリティツールが統合され、リンクされます。「」というコンセプトワールドコンサルティングが提案する「継続的アプリケーションセキュリティ」システム。この概念は、開発およびアプリケーションセキュリティの多くのメーカーやユーザーにすぐに受け入れられ、この分野の重要な開発トレンドの 1 つとなるでしょう。

Yunqi Wuxian: Yunqi Wugian はファズテストに重点を置いており、ファズテストの重要性は業界の注目を集めています。たとえば、米国大統領の大統領令に応じて、米国国立標準規格研究所は、ソフトウェアが工場から出荷される前の最小限のテスト要件としてファズテストを組み込みました。

SAST

SAST (静的アプリケーションセキュリティテスト) とは、アプリケーションを実行せずにアプリケーションのソースコードをスキャンして、潜在的なセキュリティリスクを検出することを指します。SAST を通じて、企業はコードのセキュリティ分析を自動化し、自社の開発プロセスと統合し、セキュリティの脆弱性を事前に発見して修正を試みることができます。

一般に、SAST は開発者向けのセキュリティツールです。

SAST 機能のドットマトリックス

ドットマトリックスにより、SAST メーカーは 3 つのタイプに分類されます。

Fusion ソース: さまざまなセキュリティ製品機能を備えた総合的なセキュリティベンダー。

機能ソース: 特定の技術的特徴でより著名なメーカー、または独自のトラックからアプリケーションセキュリティのテストと分析の分野に参入したメーカー。

焦点のソース: アプリケーションのセキュリティのテストと分析機能を主な機能とするベンダー。

·最終的に合計 8 社のメーカーが SAST ビットマップに参加し、参入しました。すなわち、Ai Encryption、Haiyunan、Kaiyuan 湾岸、Kude Woodpecker、Moan Technology、Qi Anxin、Think Cloud、Xiaodao Technology です。

SAST の価値と制限

SAST の価値は非常に明白です。

· 検出可能な言語の範囲が広い。

・アプリケーションのソースコードを全体的かつ包括的に検出できる。

· 脆弱性を早期に検出し、修復コストを削減します。

しかし、SASTは誤検知が多すぎるという批判も受けている。SAST の誤検知には多くの理由があります。たとえば、SAST にはアプリケーション全体の分析が不足している可能性がありますが、一部の「脆弱性」がアプリケーションの他の部分で修正されているか、関連するリスクが限定されているため、誤検知が発生した可能性があります。一方で、一部の SAST ツールには検出ルールの作成に欠陥があり、誤検知が発生します。

現在の国内市場では、誤検知を減らす方法としては、脆弱性ルールや脆弱性の種類を調整し、判断条件が明確な脆弱性のみを通知したり、影響の大きい脆弱性のみを通知することで誤検知率を低減する方法が依然として主流です。同時に、他の潜在的な抜け穴をマークして保持し、簡単にクエリとレビューができるようにします。この方法では、誤ったアラームを減らし、過剰なアラームを生成できますが、誤った陰性の潜在的な危険性も残されており、最終的なバランスは依然としてユーザーが実行する必要があります。

誤検出を解決するもう 1 つの方法は、既存の SAST メカニズムを変更することです。これは、行ごとのスキャンによって脆弱性を検出するのではなく、機械学習、人工知能、セマンティック分析などの方法に基づいており、これらは特定の影響を及ぼします。アプリケーション自体の理解に基づいて、脆弱性の発見と特定が行われます。

SAST 自体はアプリケーションを実行せずにセキュリティ検出を実行するため、ランタイムまたはランタイム環境関連の脆弱性を検出できません。ただし、アプリケーションや開発自体のセキュリティは 1 つのツールで解決できるものではなく、SAST 以外にも、関連する隠れた危険を発見できるセキュリティツールが存在します。

SAST の主要な機能

SAST 製品のセキュリティ機能は、次の観点から測定できます。

ルールベースのカバレッジ

SAST の重要な価値は、その監視範囲の広さにあります。つまり、ソースコード分析全体の範囲の広さだけでなく、言語の範囲の広さでもあります。したがって、SAST 製品は、その検出および分析機能がエンタープライズ開発環境のニーズを完全にカバーできるように、サポートする開発フレームワーク、量、および脆弱性の種類の豊富さに注意を払う必要があります。

増分テスト

エンタープライズ開発プロジェクトのコードの量は膨大であり、毎回コード全体をテストすると膨大な時間がかかることは明らかです。したがって、SAST では、多くの場合、増分テストを通じてコードの変更された部分のみを分析する必要があります。

ただし、コードが追加または変更された場合でも、以前のコードと関連付けられて新しい脆弱性が生成される可能性があります。したがって、インクリメンタルテストでは、変更や追加によって生じた脆弱性をテストするだけでなく、変更や追加したコードと以前のコードとの相関関係を特定し、それに基づいて脆弱性が存在するかどうかを検出できる必要があります。新しい抜け穴の世代。

一方、増分テストでは「脆弱性の継承」の問題も考慮する必要があります。つまり、一部の脆弱性を部分的に修正するコードの場合、以前に検出された他の脆弱性を再検出して警告する必要があるかどうかです。これらの脆弱性が繰り返し警告されないと、誤検知のリスクが生じる可能性があります。

脆弱性の位置と分析

現在の SAST 製品は、基本的に行に対する脆弱性の場所を特定できます。しかし、実際には、脆弱性が悪用される位置は特定の行である可能性がありますが、実際には、脆弱性の根本原因はコードコンテキストの関連付けにあります。したがって、脆弱性の位置は、脆弱性が発生する特定の行に限定されるべきではなく、脆弱性全体によって生成される関連チェーンを特定して表示できるため、脆弱性をより効果的に分析して修復できます。

偽陽性率と偽陰性率のバランス

前述したように、誤検知率が高いことが SAST の大きな問題です。一部の SAST 製品は特定の脆弱性のみを警告することで誤報率を減らすことができますが、これにより誤検知率が大幅に増加することは間違いありません。

偽陽性率と偽陰性率のバランスをとる必要があります。このバランスは企業の開発チームによって決定されるだけでなく、SAST 製品自体にもサポートが必要です。特定の脆弱性のみを報告することと、考えられるすべての脆弱性を警告することの間には大きな隔たりがあります。現在の SAST 製品は、開発チームが誤検知を区別できるように、この 2 つの間のアラームしきい値の移行をスムーズにサポートできる必要もあります。許容できるバランスを見つけてください。さまざまな企業が、自社の開発能力とセキュリティ能力に応じて、ソースコードのセキュリティを最大限に高めています。

DevOpsでの検出速度

SAST の自動検出機能は人間の操作なしで実行できるため、勤務時間外に検出を実行できますが、一部の企業は依然として DevOps シナリオでよりリアルタイムにソースコードの問題を検出したいと考えています。このシナリオでは、SAST の検出速度に特定の要件が課されます。

SAST市場の状況

· SAST は、アプリケーションセキュリティのテストおよび分析製品の中で最大の市場領域です。しかし、2021年の国内市場規模は2億3000万元にとどまる（海外メーカーの売上高はカウントされていない）。今後数年間、国内の SAST サプライヤー市場には注目に値する 2 つの方向性があります: まず、この調査では、最終的に総合セキュリティベンダーである Qi Anxin のみがドットマトリックスに参入しました。他にも複数の総合セキュリティベンダーが自社のSAST関連製品を開発しているとのことで、顧客のセキュリティニーズの実現に向けた開発を誘導することで、これらの総合セキュリティベンダーは製品リリース後、国内市場の更なる拡大が期待されている。、海外の開発セキュリティサプライヤーが開発中中国には依然としてかなりの市場シェアがあり、ローカライゼーションの要件により、市場のこの部分は徐々に変化するでしょう。

·現在、SASTの提供形態は主に単一の標準化された製品であり、74%を占めています。SAST の現在の機能の 1 つは、ユーザー環境に迅速に展開して使用できることです。したがって、単一の標準化された強力な SAST を使用する方が、顧客の信頼を獲得しやすくなります。

・販売方法で見ると、SASTの強みは直接販売が70％を占めます。

·SAST の現在の主な市場は金融セクターであり、45% を占めています。金融業界自体の規模が大きく、業務の反復やアプリケーションの更新に対する要求が高い一方、デジタルセキュリティの重要性も先行しており、金融業界のあらゆる分野において主要な市場となっています。アプリケーションのセキュリティ。

SAST事例：大規模国有企業のT事例（本事例はSikeun提供）

シーン紹介

大規模な国有企業である T 社は、国務院国有資産監督管理委員会に情報サービスを提供する唯一の企業であり、世界クラスの情報およびデジタル技術プラットフォームのプロバイダーであり、安全な生産のモデルであり、世界中に約 60 の子会社があります。企業情報システムの品質、信頼性、セキュリティは極めて追求されており、継続的な事業の拡大と開発の加速の過程において、情報ビジネスシステムの安全性、安定性、信頼性をいかに確保するかは企業の最優先事項となっています。急速な発展を遂げるために。

クライアントのニーズ

大規模な国有企業には多くの T 開発プロジェクトがあります。3 つの主要な R&D センターは北京、重慶、瀋陽にあります。開発者のレベルは不均一です。多くの企業がオンライン化した後、さまざまなコードレベルのセキュリティの抜け穴が見つかります。開発者は修復に多大な時間とエネルギーを費やすだけでなく、ビジネスシステムが攻撃されるセキュリティリスクは通常の外部サービスにも影響を及ぼし、企業の評判の低下や経済的損失につながる可能性があります。

大規模な中央企業である T 社は、「セキュリティの左方へのシフト」というセキュリティの概念を積極的に採用しており、アジャイル開発モードでのコードのセキュリティの脆弱性、コードの品質とパフォーマンスの問題を防ぎ、ソースのセキュリティの脆弱性によって引き起こされるリスクを軽減したいと考えています。システムがオンラインになる前にコードを削除し、セキュリティリスクを軽減し、脆弱性の修復コストを削減します。

大規模国有企業 T は、セキュアなコーディング標準とソースコードセキュリティテスト標準に重点を置いた完全な開発セキュリティシステムを構築する予定であり、SAST ツールが CI/CD システム、バージョン管理、メールシステムなどとシームレスに統合されることを要求しています。コードの取得、テストの実行、テスト結果の配信、電子メール通知、完全自動化を実現するプラットフォームを提供し、効率的な「無人」コードセキュリティテストを実現します。同時に、アプリケーションのセキュリティリスクを根本から軽減するための開発者向けのセキュリティ開発能力トレーニング計画を策定し、実施します。

解決

大規模中央企業 T 社の開発プロジェクト管理システムに従って、Sike Cloud は独自の SAST 検出ツールを既存のツールチェーンと統合し、顧客が開発プロセスの関連プロセスと仕様を策定および改善するのを支援し、従業員の安全性を向上させるために安全トレーニングを補足します。開発能力、完全で標準的で追跡可能で測定可能なコードセキュリティ管理システムを構築します。

(写真: Sikeunのソースコードセキュリティ実装計画)

•セキュリティテスト管理標準：Sikeunは、大規模中央企業Tが自社のビジネス情報システムの特性に応じて独自のソースコードセキュリティテスト標準を策定し、それをStarling SASTシステムに直接構成して、着陸および実行可能な安全基盤を形成するのを支援します。 (安全ゲート)。

•セキュアコーディング仕様: Sikeun は企業の内部人材トレーニングシステムを結合し、セキュリティテスト標準に対応し、セキュアコーディング仕様を提供し、開発者にセキュアコーディングガイダンスを提供します。このガイドを参照することで、開発者は一般的なセキュリティ脆弱性の回避方法と脆弱性の修復方法を迅速に把握し、セキュリティプログラミング能力を向上させ、脆弱性修復の効率を向上させることができます。

完全に自動化されたテストシステム: Sike Cloud Technology は、大規模な中央企業 T の既存の開発およびテストプロセスに従って、独自の SAST を既存の CI/CD (Jenkins) ツールチェーンに統合し、アジャイル開発プラットフォームのセキュリティ管理を改善して提供します。 , テストおよびセキュリティ管理担当者は、コードの取得、テストの実行、テスト結果の配布、電子メール通知、効率的な「無人」コードセキュリティテストに至るまでの完全な自動化を実現する完全自動化ソリューションを提供します。

·セキュアコーディング知識システム：Sikeyun はまた、大規模国有企業 T がセキュアコーディング知識プラットフォーム、セキュアコーディング標準を確立し、複数形式および複数種類のセキュリティ知識トレーニングを組織するのを支援します。開発、テスト、セキュリティ担当者に的を絞ったセキュリティ強化を提供します。トレーニング内容には、開発セキュリティ意識、セキュリティ設計、セキュリティコーディング、セキュリティテスト、セキュリティ脆弱性修復などが含まれ、セキュリティ開発能力の向上を支援します。

（図：Sikeunのソースコードセキュリティ管理システム）

プログラム値

Ø人材の解放 : ソースコードのセキュリティテストは、起動テスト、レポートの発行、セキュリティ監査、データ統計、通知メールの送信、その他のタスクを含めて完全に自動化されています。基本的には「無人」テストが実現できます。

Ø脆弱性を「最初から」発見する: ソースコードのセキュリティテストが簡単、便利、低コストになると、セキュリティテストをプロジェクト開発の初期段階に進めて「開発者」テストを実現し、テストの強度と頻度を高めることができます。初めてセキュリティホールを発見。

Øシステムの実装：ソースコードセキュリティ管理システムを確立し、システムを活用することで、企業が策定したセキュリティテスト標準を紙のテストプロセスで効果的に実装できます。

Ø共同監査: セキュリティ脆弱性の複数部門および複数役割の共同監査を実行できるため、さまざまな部門間のコミュニケーションコストが削減され、監査が迅速化され、脆弱性修復の効率が向上します。

Øセキュアコーディング：セキュアコーディングの仕様を策定し、セキュアコーディングとセキュリティテストを組み合わせ、テスト駆動開発を使用し、仕様に従って脆弱性を修正し、継続的に反復し、すべての開発者のセキュアコーディングのレベルを大幅に向上させ、セキュリティ問題をソースから解決します。

カスタマーレビュー

「Sike Cloud の SAST コードセキュリティ完全自動テストソリューションは、実際のニーズに基づいて、コードセキュリティテストのあらゆるリンクを実装します。この計画は、「安全性テスト標準」、「自動テストツール」、「セキュアコーディング」の 3 つを組み合わせた「ガイド」です。「セキュリティの左へのシフト」という基本コンセプトの完成に貢献したインワンシステムは、サイバーセキュリティ法およびセキュリティ省 2.0 以降のセキュリティ管理要件を満たしただけでなく、発見と修復も行いました。「非常に早い段階で多数のセキュリティの抜け穴を発見しました。脆弱性修復の効率が向上し、ビジネス情報システムがオンラインになった後のセキュリティインシデントの発生率が大幅に減少し、セキュリティリスクが軽減されます。」

——この大規模国有企業の安全試験部門の責任者

IAST

IAST (Interactive Application Security Test) は、アプリケーションの実行状態における環境に関する情報を監視することによって、潜在的な攻撃の脅威とアプリケーションの脆弱性を特定し、通常はテスト段階で使用されます。

一般に、IAST には 3 つの展開モードがあります。

· バイパストラフィック: バイパストラフィックのモードは、技術的には Web のブラックボックススキャナモードに偏っています。テスト対象アプリケーションにエージェントを設定する必要はありませんが、この方法では大量のダーティデータが生成され、CI/CDにおける開発効率が低下する傾向があります。

・アクティブインスツルメンテーション：テスト対象のアプリケーションにエージェントを注入し、外部から入力されたデータが最終的に脆弱性を引き起こす可能性がある箇所の情報を収集し、脆弱性の有無を監視します。アクティブインストルメンテーションテクノロジは、多くのトラフィックリプレイの問題を引き起こす可能性があるため、ダーティデータも発生する可能性があります。同時に、アクティブインストルメンテーションテクノロジも多くの時間を消費する可能性があり、既知の脆弱性を低い誤検知で検出できますが、CI/CD のリズムには適していません。

·パッシブ計装: パッシブ計装は、アクティブ計装の欠陥を補うことができます。パッシブインスツルメンテーションでは、テストのターゲットアプリケーションにエージェントをデプロイする必要もありますが、パッシブインストルメンテーションテクノロジはテスト中は沈黙を保ち、内部アプリケーションで受信する外部データストリームの変更とフロー動作のみを収集し、問題がないかどうかを分析します。セキュリティ上のリスク。パケットのリプレイや改ざんなどが行われないため、パッシブインストルメンテーションモードではアプリケーションを迅速にテストでき、ダーティデータは生成されません。

将来の観点から見ると、IAST は最終的には受動的計測に焦点を当てることになります。

IAST ビットマップ

ドットマトリックスにより、IAST メーカーは 2 つのタイプに分類されます。

焦点のソース: アプリケーションのセキュリティのテストと分析機能を主な機能とするベンダー。

・今回IASTドットマトリックスに参加・参入したメーカーは、Haiyun Security、FireWire Security、Kaiyuan Network Security、Mo'an Technology、Xiaodao Technology、Xuanjing Securityの計6社。

IAST 値と制限事項

IAST は現在、国内のアプリケーションセキュリティ市場で人気のある製品であり、その利点は非常に明白です。パッシブインストルメンテーションモードは CI/CD の速いペースに対応でき、同時に比較的低い誤検知率により企業は集中力を高めることができます。これらの実際の問題について— —特にこれらの問題が実際の使用シナリオに存在する場合。

同時に、SAST 検出では実行時の脆弱性をカバーできませんが、IAST ではアプリケーションを実行状態でテストすることで脆弱性を検出するため、この 2 つは相互に補うことができます。

一方、IAST は脆弱性の完全な追跡チェーンも提供し、関連担当者が関連機能を完全に分析して最適な修復措置を講じることができます。

ただし、IAST の限界も明らかです。最大の問題は、IAST でサポートされている言語の数が非常に少なく、現在は少数の主流言語のテストのみをサポートしていることです。さらに、IAST の実装は比較的成熟した開発環境にも依存しており、開発者はアプリケーションのランタイム関連機能を完全にカバーするさまざまなテストケースを設計できる必要があります。そうしないと、誤検知が発生する可能性があります。

IAST の主要な機能

IAST ツールの選択では、次の 3 つの側面を考慮できます。

言語範囲

IAST でサポートされる言語の数が少ないことは IAST の大きな弱点ですが、一部の大規模な開発プロジェクトでは、多くの異なる言語が使用される可能性が非常に高くなります。したがって、IAST サプライヤーは、可能な限り多くの IAST 言語サポートを提供できるようにする必要があります。現在、国内の主流の IAST メーカーは、Java、PHP、Python、Node.js、Go、および .NET (.NET Framework および .NET Core を含む) をカバーできます。企業は自社のビジネスニーズから出発し、IAST サプライヤーが自社の開発環境で使用される言語を確実にカバーできるように努め、自社のビジネスニーズを満たすために IAST サプライヤーの将来の言語サポートプランを理解する必要があります。

脆弱性検出の効率と効果

IAST のテストにはある程度の手作業が必要なため、IAST の初期導入は SAST よりも比較的複雑です。したがって、IAST サプライヤーが製品で提供するテンプレートとプロセス全体で提供されるサービスは非常に重要です。豊富で実用的なテンプレートと高品質のサービスは、企業ができるだけ早く IAST を自社の環境に導入し、役割を果たすのに役立ちます。

一方で、IASTの利用効果は、脆弱性の検出データに基づくだけでなく、脆弱性の検出と分析についても考慮する必要があります。IAST は依然として開発者指向のセキュリティツールであるため、脆弱性の影響連鎖、脆弱性の範囲、特定の脅威の状況など、開発者が理解できる脆弱性レポートを通じて、開発者が脆弱性を修正できるようにガイドできる必要があります。待って。

IAST市況

・IASTの市場は2021年に1億を超える。ただし、この分野に注力しているセキュリティベンダーは少ないため、市場規模そのものはサプライヤーの能力によってある程度制限されることになる。一方で、IASTには企業のIT構築レベルにも一定の要件があり、これもIAST推進の制約の1つとなるだろう。

·現在、IASTの提供形態は単一の標準化された製品によって占められており、82%を占めています。

・販売方法の観点から見ると、IAST の能力は 83% を占める直接販売が主であり、OEM の数は非常に少ないです。

・IASTの現在の主要市場も金融セクターであり、36%を占めています。金融業界ではIT化が進んでおり、より柔軟で効率的なテスト製品の需要が高まっています。オペレーター分野にも同様の需要があり、19% を占めています。

SCA

SCA、Software Composition Analysis、ソフトウェア構成分析は、ターゲットソフトウェアのコンポーネントを分析して、オープンソースコンポーネントの関連情報を特定し、そのセキュリティをさらに実証するツールです。

SCA はオープンソースエコシステムの製品であると言えます。エンタープライズ開発環境のコードの 90% 以上がオープンソースコンポーネントから来ている場合、これらのオープンソースコンポーネントのセキュリティを検証および追跡する必要があります。それにもかかわらず、独自のプロジェクトにおけるオープンソースコンポーネントの分析は SCA の価値の一部にすぎません。ソフトウェアサプライチェーンの観点から見ると、理想的には、SCA はサードパーティが提供する関連ソフトウェアのコンポーネントを分析する機能も備えている必要があります。サプライヤー—— サードパーティのサプライヤー自体もエンタープライズソフトウェアサプライチェーンの重要な部分だからです。

しかし、現状のSCAの実現には依然として多くの課題があり、今後の技術開発が注目される。

SCAビットマップ

ドットマトリックスにより、SCA ベンダーは 3 つのタイプに分類されます。

Fusion ソース: さまざまなセキュリティ製品機能を備えた総合的なセキュリティベンダー。

焦点のソース: アプリケーションのセキュリティのテストと分析機能を主な機能とするベンダー。

·今回のSCAドットマトリックスには、Haiyunan、Kaiyuan Ward、Moan Technology、Qi Anxin、Sike Cloud、Xiaodao Technology、Xuanjing Security、Yunyi Technologyの合計8社が参加しエントリーしました。

SCAのコアバリュー

相同性解析

SBOM (ソフトウェア部品表、ソフトウェア部品表) は、使用されるサードパーティソフトウェアおよびオープンソースコンポーネントとそのバージョン、資格情報、脆弱性、その他の情報を含む、記録されたソフトウェアコンポーネントのリストです。SCAはSBOMを通じて、分析・整理した情報を定型ドキュメントで出力することができ、企業のソフトウェアレベルでの「資産管理」を支援します。

企業の既存の環境にはすでに多数のオープンソースコンポーネントが含まれており、使用されているオープンソースコンポーネントが記録されていない可能性が高いことを考慮すると、ほとんどの企業にとっての SCA の最初のタスクは、オープンソースの使用を明確にすることです。現在の環境のコンポーネントと出力 SBOM ドキュメントのソースと照合を行います。企業はまず SCA を使用して、環境内の既存のオープンソースコンポーネント、特にバージョンが古いコンポーネント、更新とメンテナンスが停止したコンポーネント、ソースが不明なオープンソースコンポーネント、最新のビジネスシステムで使用されなくなったコンポーネントを検出する必要があります。など。直接的な脅威となるソフトウェアコンポーネント。SCA を使用して既存のソフトウェアコンポーネントの SBOM ドキュメントを出力することで、企業は現在の企業 IT 環境のセキュリティ状態をより包括的に理解できるようになり、既存の脅威への対処を開始できるようになります。

企業が現在使用しているソフトウェアコンポーネントを整理したら、次のステップはオープンソースコンポーネントの管理を正規化することです。SCAツールを開発プロセスに統合することで、オープンソースコンポーネントの参照を標準化し、使用されているオープンソースコンポーネントを追跡および確認することができ、企業が使用するソフトウェアコンポーネントを継続的に把握し、オープンソースコンポーネントの使用における盲点を回避できます。開発プロセス中のソースコンポーネント。

セキュリティの分析と管理

環境内のコンポーネントを明確に理解した後、組織の次のステップは、コンポーネント内のセキュリティの脆弱性を発見して管理することです。この機能は、既知のコンポーネントにどの脆弱性が存在するかを検出するだけでなく、これらの脆弱性を管理することもできます。これには、独自の環境やビジネスに基づいて脆弱性の重大度に優先順位を付けたり、廃棄の提案 (特定のバージョンに更新するなど) を提供したりすることが含まれます。

ソフトウェアコンポーネントのセキュリティ分析と管理も継続的なタスクであり、サードパーティサプライヤーのオープンソースコンポーネントやソフトウェアも更新されたり、新しい脆弱性が発見されたりする可能性があります。また、SCA は、最新のソフトウェアコンポーネントのセキュリティ情報と推奨事項を組織に提供できる必要もあります。

依存関係とビジネス関連の分析

セキュリティに加えて、コンポーネント間の依存関係 (依存関係) も SCA の重要な価値です。

今日のソフトウェアコンポーネントは多数のオープンソースコンポーネントで構成されているため、コンポーネント間には相互依存関係があります。コンポーネントに脆弱性が発生すると、多くの場合、それに関連する他のコンポーネントやシステムに影響が及びます。したがって、企業は自社環境内のサードパーティソフトウェアとオープンソースコンポーネントのリストを必要とするだけでなく、特定のコンポーネントやソフトウェアの脆弱性が企業環境に与える影響を迅速に理解するために、コンポーネントとソフトウェア間の依存関係も理解する必要があります。 IT環境。

これに加えて、デジタルワールドコンサルティングは、企業がビジネスアプリケーションを開発し、サードパーティソフトウェアを購入する最終的な目標は、企業ビジネスの円滑な運営を確保することであると考えています。したがって、オープンソースコンポーネントとサードパーティソフトウェアの管理は技術レベルに限定されるべきではなく、ビジネスレベルもカバーする必要があります。コンポーネント間の依存関係に基づいて、コンポーネントとビジネスをさらに結び付け、定量化する機会を得ることができます。ビジネスレベルのリスクと影響からソフトウェアサプライチェーンを分析し、対応する対応計画を構築します。

オープンソースのコンプライアンス

オープンソースコンポーネントのコンプライアンス問題にも注意が必要です。オープンソースコンポーネントが異なれば、オープンソースライセンスも異なり、オープンソースコンポーネントの使用仕様に対する要件も異なります。法的コンプライアンスを考慮するため、企業は関連するオープンソースコンポーネントを使用する際にオープンソースライセンスの規定に従う必要があります。SCAは、企業のオープンソースコンポーネントの使用方法についてコンプライアンスレベルの提案と監査を提供することで、企業がオープンソースコンポーネントの不正使用によって引き起こされる隠れた危険を回避できるように支援し、この側面は特に海外ビジネスに関連するビジネスシステムにとって重要です。

SCA の主要な機能

オープンソースのナレッジベース

SCA の最初のタスクは、ソフトウェア内の各コンポーネントのソースを整理することです。したがって、エンタープライズ環境のソフトウェアコンポーネントに対応するには、SCA自体が膨大なナレッジベースを持っている必要があります。これには、オープンソースコンポーネントのソースを特定するための基礎となるオープンソースコンポーネントライブラリや、脆弱性を分析するための脆弱性ライブラリが含まれます。証明書ライブラリは、オープンソースコンプライアンスの要件を満たすことができます。

コンポーネントの特定と分析

SCA は、オープンソースのナレッジベースに基づいて、アプリケーションで使用されている特定のコンポーネントを識別して、アプリケーションにオープンソースコンポーネントによって引き起こされるリスクがあるかどうかを確認できる必要があります。

現在のコンポーネントの識別方法は、ソースコードとバイナリです。ソースコードの識別はコードから直接開始され、コンポーネントのソースを検出します。一方、バイナリの識別は、開発されたアプリケーションのコンパイル後に形成されたバイナリファイルを分析します。

バイナリ識別は、ソースコード識別よりも後の段階で使用できます。最終的なバイナリファイルを基に解析を行うため、開発中に改ざんされたファイルや悪意を持って導入されたファイルをチェックすることができます。一方で、将来の開発の観点から、企業がソフトウェアサプライヤーのコンポーネントの使用状況を自己チェックすることはますます重要になります。また、ソフトウェアサプライヤーが提供するソフトウェアは最終的なバイナリファイルであることが多く、バイナリが作成されます。認識テクノロジーの重要性がさらに高まっています。しかし、現時点ではソースコード認識と比較すると、バイナリ認識の技術的な成熟度にはまだ大きな差があり、それを突破するには時間がかかると思われます。

見える化能力

SCA が組織の IT 環境で使用されるコンポーネントを明確にした後の次のステップは、さまざまなコンポーネント間の依存関係を分析することです。ただし、システムレベルで依存関係を明確にするだけでは当然不十分であり、セキュリティツールの最終的な目的は、セキュリティ担当者が必要なセキュリティ目標を達成できるようにすることであるため、セキュリティ担当者が依存関係を明確に把握できる必要がある。関係は、依存関係を明確にする際の SCA の価値、つまり、SCA を通じて環境内の関連コンポーネントを視覚化する機能です。

SCA の視覚化機能を通じて、組織は、さまざまなコンポーネントとそのコンポーネントが配置されているソフトウェアがビジネスに与える影響を理解できるため、直面するリスクをより正確に評価できます。 , Supported by コンポーネントの可視化機能があれば、組織は自社の環境における関連する脆弱性の影響範囲やビジネスへの影響を即座に特定し、自社の状況に基づいて関連する脆弱性に対応することができます。

SCA導入の難しさ

オープンソースのナレッジベースの使用

導入時には、オープンソースのナレッジベースの使用が満足のいくものではない可能性があります。たとえ SCA ベンダー自体が大量のオープンソースコンポーネント情報を持っていたとしても、ユーザーがそれを完全に利用できるわけではない可能性があります。

その主な理由は、多くの企業が依然としてサプライヤーに対し、権限付与のためにサプライヤー独自のクラウドではなく、ローカル展開またはプライベートクラウド展開を通じて製品を提供することを要求していることです。したがって、SCA プロバイダーは、大量のデータをユーザー側にローカルに展開する必要があります。更新のたびに、多数の物理ハードディスクを交換する必要もあり、SCA の導入と更新に大きな困難が生じます。

現在、この問題には 2 つの解決策がありますが、どちらもユーザー自身を変える必要があります。

1 つ目の方法は、ユーザーが SCA プロバイダーを徐々に受け入れてクラウドでサービスを提供することで、ローカル展開によって生じる多くの不便を回避することです。

もう 1 つの方法は、ユーザーが開発段階でオープンソースコンポーネントの適切な使用仕様を確立する必要があることです。たとえば、固定された信頼できるソースからのオープンソースコンポーネントのみを使用するなどです。オープンソースコンポーネントの標準開発が欠如していると、未知のソースからプロジェクトに多数のオープンソースコンポーネントが導入されることになり、SCA オープンソースナレッジベースが大きく、幅広く、完全であることが盲目的に追求され、潜在的に追加の機能が追加される可能性があります。不要なオープンソースコンポーネント情報が大量にあります。開発環境でのオープンソースコンポーネントの使用を標準化できれば、オープンソースコンポーネントライブラリの数の要件を大幅に削減でき、圧縮テクノロジを使用すると、オープンソースナレッジベースのサイズを 20 Tb 未満に縮小できます。各増分更新は 1Tb 以内で実行できます。

コード断片認識能力

SCA が現在技術的に直面している課題の 1 つは、コードフラグメント検出機能です。開発者がプロジェクトに対してオープンソースコンポーネント全体を直接参照する場合、参照されたコンポーネントはパッケージマネージャーを通じて識別できます。ただし、開発者はオープンソースコンポーネント内のコードの一部のみを参照することもあり、その際、関連するリスクを回避するためにコードフラグメントからオープンソースコンポーネントのソースを特定する必要があります。

コードフラグメントを正確に識別し、コードソースを効果的に識別する機能に加えて、識別可能なコードフラグメントの粒度と認識速度も同様に重要です。ただし、全体としては、コード断片によるオープンソースコンポーネント識別テクノロジはまだ開発段階にあります。

バイナリ検出機能

バイナリ検出機能は、SCA の技術開発のもう 1 つの課題です。バイナリファイルからの検出では、コンパイルされたアプリケーションに対して二次検出を実行し、ライブラリに保存されたオープンソースコンポーネントの改ざんされた動作を検出できます。一方、成熟したバイナリ検出機能は、エンタープライズソフトウェアサプライヤーのソフトウェアを検出して、使用されている関連コンポーネントのセキュリティを明確にすることもできます。

バイナリ検出技術の使用シナリオは非常に貴重ですが、バイナリ検出技術自体は現在開発段階にあり、検出速度も精度もあまり理想的ではありません。

SCA市場の状況

・近年、ソフトウェアサプライチェーンのセキュリティへの注目が高まる中、オープンソースコンポーネントガバナンスの重要なツールとしてSCAも急速に市場規模を拡大しています。SCA の初期の顧客は主に海外メーカーの製品でしたが、ローカライゼーションの要件により、国内メーカーがこの市場を変革すると予想されています。

・SCAシングルサインの提供形態は主に単一の標準化製品に基づいており、71%を占めています。カスタマイズされた製品と動作モード、およびプロジェクト内の特定の機能モードとの間の差異はほとんどありません。

・販売方法で見ると、SCAの実力は直接販売が79％を占めています。

·SCAの現在の主要顧客も金融分野であり、42%を占めています。続いて通信事業者とインターネット業界。インターネット業界では SCA の需要が大きいですが、インターネット業界自体が優秀な IT 人材やセキュリティ人材を多く抱えており、自給自足していることが多く、また、インターネット業界では海外の SCA 製品を使用する傾向もあります。

大手国営総合証券会社におけるオープンソースガバナンスの実践（本件は玄京警備保障より提供）

顧客の背景

全国規模の大手総合証券会社は、「テクノロジーでビジネスをリードし、顧客志向である」という価値観を堅持し、金融テクノロジーを精力的に開発し、情報テクノロジーにおける核となる競争力を構築し、人工知能、ビッグデータ、テクノロジーなどの新興テクノロジーを総合的に適用しています。自主管理と革新を企業のIT文化とし、今後も情報システムの構築を最適化し、お客様に高品質なサービスを提供し、ビジネスの迅速な発展に貢献してまいります。

クライアントのニーズ

近年、オープンソース技術は急速に発展しており、オープンソース技術の幅広い応用は企業に利便性をもたらす一方で、オープンソースの脆弱性、オープンソースライセンス・知的財産コンプライアンス等のリスクももたらします。エンタープライズソフトウェアアプリケーションには、従来の CS、BS、マイクロサービス、その他のアーキテクチャタイプを含む、アウトソーシング、自己研究、共同開発などのさまざまなソースが含まれ、C、C++、Java、JS、およびその他の開発言語のソースコード管理が含まれます。複雑なアプリケーション環境では、オープンソースガバナンスツールには強力な互換性と適応性が必要です。アプリケーションシステムへの攻撃や損傷を防ぐために、アプリケーションのサードパーティコンポーネントの既存の脆弱性、ソフトウェアライセンスの問題、悪意のあるコードの問題を迅速に特定する方法。古いサードパーティコンポーネントの使用に関する未公開の問題、および修正された 0day 問題は企業にとっての悩みの種となっています。

プログラムの実現

証券会社では、オープンソースコンポーネントを導入した商品の安全性を確保するため、オープンソースソフトウェアの特性を踏まえ、経営実態と合わせて社内にオープンソースガバナンス体制を構築し、ソフトウェアサプライチェーンからソフトウェアサプライチェーンのセキュリティを確保しています。ソース。情報技術部門は、オープンソースソフトウェアの導入、オープンソースソフトウェアの検出、オープンソースライセンスの管理、リスク評価、セキュリティトレーニング、およびオープンソースソフトウェアの使用と運用におけるその他のセキュリティリスク管理を担当します。

オープンソースガバナンスの効果的な実装を達成するために、証券会社は、ソフトウェアサプライヤーの管理、オープンソースソフトウェアの導入、セキュリティリスクの検出、セキュリティ脅威インテリジェンスの監視、およびオープンソースソフトウェアの引き出し管理のリンクにおいて、対応する制御メカニズムを設計しました。

uサプライヤーアクセスメカニズム：購入した商用ソフトウェアについては、サプライヤーの資格とレベルを評価し、レベルに応じてアクセスしきい値を設定する必要があります。

uオープンソースソフトウェア導入管理メカニズム:ソフトウェアバージョンのベースラインとブラックリストとホワイトリストを策定および維持します。オープンソースソフトウェアの導入は、ベースラインとブラックリストとホワイトリストの要件を満たす必要があります。

uオープンソースソフトウェアのセキュリティリスク検出メカニズム:アプリケーションシステムは、オンラインになる前および動作中にオープンソースソフトウェアのリスクをスキャンする必要があります。オンライン化する前に、要件開発管理プロセスとアプリケーション変更管理プロセスの行き詰まった点でスキャンを実行し、オープンソースソフトウェアの脆弱性を持つアプリケーションのオンライン化を禁止します。運用中は、オープンソースソフトウェアのセキュリティリスクスキャンを定期的に実施し、関連する脆弱性作業を推進します。セキュリティの脆弱性を命令し、対処します。

uオープンソースソフトウェアのセキュリティリスク監視メカニズム：オープンソースソフトウェアの情報記録を統合してオープンソースソフトウェアの部品表を作成すると同時に、正規化された脅威インテリジェンスの追跡を実行し、ソフトウェアに新たなコンプライアンス問題や脆弱性リスクが発生した場合、タイムリーにリスク管理と制御を実行するために警告を行うことができます。

uオープンソースソフトウェアの終了管理メカニズム:古いソフトウェア、メンテナンスが終了したソフトウェア、またはセキュリティリスクのあるソフトウェアについては、技術チームとセキュリティチームによる評価後に終了され、ソフトウェアバージョンのベースラインとブラックリストとホワイトリストが同期して更新されます。

（証券機関のオープンソースリスクガバナンスプロセス）

具体的な実践的な手順:

証券会社のオープンソースガバナンス業務は、自社の DevOps 関連プロセス、プラットフォーム、ツールと高度に統合されており、オープンソースソフトウェア導入の検出、ライセンスの検出、脆弱性の検出などのアクションはすべてアプリケーション要件の開発管理プロセスに組み込まれており、継続的に実行されます。配信パイプライン。

その中で、製品ツールを使用して製品構築の基本情報を記録することで、ソフトウェア構築のトレーサビリティが向上し、依存関係情報に基づいて逆依存関係分析を実行したり、コンポーネント変更の影響範囲を迅速に特定したり、リスク評価機能を提供したりできます。

Xuanjing Security の Yuanjian OSS オープンソース脅威管理および制御プラットフォーム (「Yuanjian OSS」と呼びます) を使用して、開発およびテスト段階でオープンソースコンポーネントのセキュリティリスク管理を実施します。Yuan Jian OSS は、オープンソースアプリケーションの欠陥検出、マルチレベルのオープンソース依存関係マイニング、詳細なコード相同性検出などのコア機能に基づいて、アプリケーション開発プロセスで参照されるサードパーティのオープンソースコンポーネントを正確に識別し、さまざまなコンポーネントを深く調査します。コンポーネントに隠されたセキュリティの脆弱性とオープンソースプロトコルのリスク。Source Jian OSS は、アプリケーションシステムの実際の動作中に動的に読み込まれるサードパーティのコンポーネントと依存関係に焦点を当て、これに基づいて詳細でより効果的な脅威分析を実行します。要件管理および開発テストのプロセスにソース識別 OSS を組み込み、コーディング完了後に OSS コンポーネントのスキャンを自動的にトリガーし、スキャン結果に応じて欠陥作業指示をプッシュし、導入された脆弱なコンポーネントのソースを完全にブロックします。

(出典 Jian OSS DevSecOps 導入図)

HIDS オンライン運用環境を使用して、運用フェーズ中にオープンソースコンポーネントのセキュリティリスクを管理し、オンライン環境内のすべてのホストをリアルタイムでスキャンし、導入されたリスクコンポーネントを検出します。脆弱性管理プラットフォームは、検出データを同期した後、コンポーネントの脆弱性修復の完了を監視するための作業指示を送信します。

プログラム効果

この証券会社はオープンソースガバナンス活動を開始して以来、比較的完全なオープンソースガバナンスシステムを構築してきました。証券会社は、日々の研究開発プロセスにおいて、10,000 近くのオープンソースコンポーネントに大きく依存しており、オープンソース技術に基づいた分散型コア証券ビジネスシステムも構築しており、提供と同時にオープンソースの優れたリスクガバナンス効果を実現しています。収穫した。

u 研究開発パイプラインと統合して、オープンソースソフトウェアのクローズドループリスク管理を形成します。

オープンソースセキュリティリスク管理システム全体は、GitLab ソースコードライブラリ、JIRA 開発要件管理プロセス、継続的インテグレーションパイプライン、継続的デリバリー製品ライブラリに基づいており、Xuanjing OSS や製品検出などのオープンソースソフトウェアリスク検出ツールを通じて、リスクガバナンス、修復、記録追跡などのガバナンス機能がアプリケーションのライフサイクル管理プロセスに組み込まれており、内生的なセキュリティを実現します。現在、オープンソースソフトウェアのリスククローズドループ管理プロセスは証券会社のすべてのアプリケーションシステムをカバーしており、 10,000 近くのオープンソースソフトウェアを追跡しており、脆弱性の検出効果は顕著です。

u 研究開発過程でセキュリティカードポイント管理を実施し、脆弱性修復効率と修復率が高い

この証券会社は長年にわたって脅威インテリジェンスの追跡とオープンソースソフトウェアの脆弱性管理を行ってきました。オープンソースソフトウェアのセキュリティ脆弱性の警告が発生すると、情報セキュリティチームは適時に脆弱性スキャンを開始し、脆弱性管理プラットフォームを通じてフォローアップ修復のための作業指示を送信できます。脆弱性の警告から作業指示のプッシュまで、プロセス全体は24 時間以内に完了します。毎日の脆弱性追跡および修復率は 95% と高く、効率的で高品質なオープンソースソフトウェアセキュリティの脆弱性リスク管理を実現します。

u ソフトウェアサプライチェーンのセキュリティガバナンスと運用レベルを向上させる

証券会社がオープンソースガバナンス検出ツールを導入した後、一方では、セキュリティガバナンスと運用を改善するために、SBOM ソフトウェア部品表などの多数のサードパーティ製オープンソースコンポーネントのセキュリティリスクを発見しました。独自のソフトウェアサプライチェーンのレベル。

(証券ユーザー向け元建OSS適用シナリオ)

カスタマーレビュー

当社のオープンソースガバナンスシステムの構築は段階的に発展し続け、ソフトウェアのテストと選択、テクノロジーの使用管理、テクノロジーの運用と保守管理、定期的な健全性評価とソフトウェア終了管理。ソフトウェアサプライチェーンセキュリティ分野の大手メーカーとして、Xuanjing Security は革新的で高度な技術製品と、オープンソースガバナンスにおける安定した完全なソリューションを提供しています。オープンソースガバナンスシステムの実践において、Xuanjing Security は社内のさまざまな部門と積極的にコミュニケーションを図り、Yuanjian の OSS 導入プロセスを継続的に磨き上げ、最終的に SCA オープンソースガバナンスツールの社内へのソフト実装を実現しました。将来的には、ソフトウェアサプライチェーンのセキュリティガバナンスと運用に関して、綿密な議論を実施し、玄京警備保障との協力強化に向けて取り組んでいきたいと考えています。

他の

アプリケーションセキュリティのテストおよび分析製品は、上記の SAST、IAST、SCA の 3 種類に限定されません。ただし、その他の製品は市場規模が比較的小さいため、調査は行われませんでした。ただし、次の 3 つのアプリケーションセキュリティテストおよび分析製品については、依然として言及する価値があります。

ダスト

DAST (Dynamic Application Security Test、ダイナミックアプリケーションセキュリティテスト) は、アプリケーションの実行状態でセキュリティテストを実施し、潜在的なセキュリティリスクを発見します。一般に、DAST は、基本的に完成したアプリケーションを、アプリケーションの起動前および動作状態にテストするために使用されます。

DAST ツールは、テストするアプリケーションのソースコードを知る必要はなく、アプリケーションの種類にも依存しません。一方、DAST のテスト方法は実際の攻撃者が使用するツールに近いため、現実世界の攻撃シナリオをより現実的にシミュレートできます。

ただし、DAST の実際の使用は理想的ではありません。DAST のテスト方法は攻撃シナリオに近いものになりますが、そのテストの範囲は一般的な攻撃タイプに大きく限定されており、脆弱性検出の範囲は非常に不十分であり、多数の偽陰性が発生する傾向があります。同時に、DAST はユーザーに対する要件が高く、DAST を使用し、DAST によって生成されるレポートを理解するには、ある程度のセキュリティ知識が必要です。最後に、DAST を通じて脆弱性が発見されたとしても、脆弱性を特定することは依然として困難です。

ファズテスト/ファジング

ファズテスト (ファジング) は、意味のないランダムな情報をアプリケーションに入力し、アプリケーションの応答を観察してセキュリティリスクを発見するファズテストです。ファジングは、アプリケーションが意図した方法で使用されなかった場合に攻撃される可能性があるかどうかをテストします。

ファジングには、DAST と同様に、ユーザーにとってより高い要件があります。ファジングはランダムな情報を入力してテストされますが、純粋なランダム情報とアプリケーション自体によって生成されたランダム情報のバランスをとる必要があります。一方で、ファジングはテストや結果の詳細な分析に多くの時間を費やしやすいため、現在DevOpsを推進している一部の企業にとっては懸念があるかもしれません。

しかし、Fuzzing 独自のテクノロジーとエンタープライズ IT 機能がますます成熟するにつれて、Fuzzing には他のアプリケーションセキュリティテストおよび分析製品が見逃しているセキュリティリスクを発見する機会があることを考慮すると、関連製品は注目に値します。

アプリケーションセキュリティプラットフォーム

アプリケーションのセキュリティのテストと分析の製品が徐々に成熟するにつれて、企業が使用できる関連ツールが増えています。前述したように、アプリケーションの開発および運用のさまざまな状態にはさまざまな製品が適しており、企業はアプリケーションのセキュリティテストおよび分析製品を統合および管理するためのプラットフォームも必要とし始めています。

アプリケーションセキュリティプラットフォームは依然として企業のアプリケーション開発と運用にサービスを提供するため、企業のアプリケーション開発と運用プロセスに統合できる必要があり、企業の関連開発プラットフォームに接続できる必要があります。技術的にはエンタープライズ。一方、DevOpsを利用する企業にとって、アプリケーションセキュリティプラットフォームは、開発段階のセキュリティ要件だけでなく、アプリケーションの利用状態におけるセキュリティの検出と保護もカバーします。したがって、アプリケーションセキュリティプラットフォームは、アプリケーションセキュリティのテストおよび分析製品だけでなく、RASP やその他の運用シナリオを含むセキュリティ機能も管理します。

今後の動向

アプリケーションは企業デジタルビジネスの重要なキャリアであるため、アプリケーションのセキュリティは企業デジタルビジネスの運営と発展に直接関係します。企業はアプリケーションのセキュリティにますます注意を払う必要があります。企業内で開発して使用するアプリケーションであっても、サプライヤーから購入したアプリケーションであっても、最終的にはセキュリティ検査に合格する必要があります。この観点から、アプリケーションソフトウェアサプライヤーは、将来的に顧客からのセキュリティ上の課題に直面することになるため、自社のアプリケーション開発のセキュリティレベルへの投資を増やすことになります。

アプリケーションセキュリティのテストと分析は、アプリケーションセキュリティ全体の一部にすぎません。将来の観点から見ると、これらの製品の技術的な深さであっても、アプリケーション全体のセキュリティであっても、さらにはソフトウェアサプライチェーンのセキュリティであっても、さまざまな傾向が見られるでしょう。

SAST インテリジェンス

アプリケーションのソースコード全体をテストする必要は常にあり、アプリケーション開発プロセスにおける SAST の重要性は自明です。コードの量が増加するにつれて、SAST 検出の精度要件はますます高くなります。現在、警報基準の変更による誤警報率の低減は、SAST の使用効率を向上させる手段となっていますが、開発チームにとって、これは依然として恒久的な治療法ではなく指標であり、これにより SAST の誤検知率が増加するためです。

SAST の高い誤検知率の問題を解決するには、本質的に SAST エンジンから始める必要がありますが、人工知能などのテクノロジーを通じて、SAST ツールはソースコードをよりグローバルに理解できるため、誤検知の発生を減らすことができます。

IASTの多言語化

IAST が現在直面している制限の 1 つは、サポートされる言語が少ないことです。SAST および SCA がサポートする言語タイプと比較して、IAST は複数の言語しかサポートできないため、使用シナリオに一定の制限があります。IASTの普及と関連ビジネスの発展に伴い、IASTがサポートできる言語の種類は徐々に増加していきます。

SCAの一般化

SCA は近年特に人気のある分野であり、ソフトウェアサプライチェーンのセキュリティにおいて重要な役割を果たしています。現在の SCA の使用シナリオは、企業が自社の開発環境で使用されるオープンソースコンポーネントを管理し、そのセキュリティを確保することに依然として重点を置いていますが、開発の観点から見ると、SCA はさらに多くのことができます。

ソフトウェアサプライチェーンのセキュリティがますます注目を集めているため、企業は自社の開発で使用されているオープンソースコンポーネントを気にするだけでなく、他のソフトウェアサプライヤーパートナーでどのコンポーネントが使用されているかを把握する必要もあります。もちろん、バイナリ検出機能が成熟すると、企業はバイナリ SCA 検出機能を使用してサプライヤーが使用するコンポーネントを特定できるようになりますが、明らかにそれには多くの時間がかかります。「チェーンをチェーンで管理する」ことによってのみ、関連するオープンソースコンポーネントをより効率的に管理できます。つまり、企業がサプライヤーパートナーのソフトウェアを購入して使用する場合、関連するサプライヤーパートナーが正確な SBOM 情報を発行することも要求されます。企業がソフトウェア資産を管理すること。

したがって、ソフトウェアサプライチェーンのセキュリティがますます注目を集めているため、SCA の価値は独自の開発とアプリケーションのセキュリティに存在するだけでなく、独自の製品のセキュリティを証明する強力な手段にもなるでしょう。ソフトウェアを下流の顧客に提供します。

開発チームの確保

DevSecOps はすべてのプロジェクトにとって最適な開発モデルではありませんが、セキュリティを開発および運用プロセスに統合するというその考え方は学ぶ価値があります。実際、アプリケーションのセキュリティは「セキュリティを左にシフト」するだけでなく、アプリケーションのライフサイクル全体を通して実行する必要があります。そうすることで、いつでもアプリケーション上でセキュリティの検出、脆弱性の修復、攻撃からの保護、その他の対策を実行できるようになります。ステージ。

開発チームのセキュリティを確保するということは、セキュリティチームを開発チームに統合することを要求することではなく、元の開発チームのセキュリティ開発に対する意識と能力を強化することを意味します。アプリケーションを最もよく知っているのは開発チームであるため、開発チームのセキュリティ機能を向上させることは、セキュリティチームとビジネスチームの間の対立を効果的に減らすだけでなく、アプリケーションのセキュリティリスクを修復する効率を向上させ、セキュリティリスクを高めることもできます。アプリケーションのセキュリティ機能の価値を使用します。

アプリケーションセキュリティプラットフォーム

アプリケーションのセキュリティの構築は、アプリケーションの開発および運用システムの成熟度と切り離すことができません。アプリケーション開発および運用システムが成熟すると、企業はアプリケーション開発および運用に関する完全なプロセスセットを持ち、多くの場合、このプロセスには全体的な管理のためのアプリケーションプラットフォームが存在します。このシナリオでは、アプリケーションの開発および運用期間が異なると、さまざまなリスクが発生するため、対応するセキュリティ機能をさまざまな段階で適切に組み込むことができます。また、プラットフォームはアプリケーション段階全体のセキュリティ状況を監視および分析し、アプリケーションのセキュリティ機能を継続的に出力する必要があります。

この考え方に基づいて提案されているのが、SCA、SAST、IAST、DAST、FUZZING、RASP、モバイルアプリケーションのセキュリティテストなどのセキュリティ機能を、アプリケーションの開発・運用期間ごとのセキュリティ問題に対応するプラットフォームで統合する「Continuous Application Security（CAS）」です。そしてセキュリティデータを分析し、最終的にユーザーのリソース投資の削減、セキュリティ機能の統合、セキュリティ効率の向上を支援するという目的を達成します。