Oligoの2023年ベスト機能

これまでのOligoベストセキュリティ機能:

機能 #1: 悪用可能性（Exploitability）＆脆弱な関数のレポーティング

アプリケーションにCVEが存在するかどうかを知るだけでは不十分です――多くの場合、それらは悪用できず、深刻度スコアや既知のエクスプロイトの有無にかかわらず、優先度は高くありません。Oligoでは、関数レベルの悪用可能性検知を構築し、すべてのアプリケーションコードにおける悪用可能な脆弱性を漏れなく見つけます――あなたが作るアプリケーションも、運用するアプリケーションも対象です。

この機能は、根本原因分析とともに、その脆弱性が実際に悪用可能であることの明確な証拠を提供します。これは「ノイズ削減」ではありません――どの脆弱性がどのようにリスクを生むのかを、証明するものです。

私たちが気に入っている点: 開発者とセキュリティが、味方ではなく敵のように見えてしまうのは簡単です――誰だって時間を無駄にしたくありませんし、悪用可能性を証明せずに「脆弱性を直せ」と開発者に指示するセキュリティツールは、まさにその無駄を生みます。

Oligoセンサーはさらに深く掘り下げ、脆弱なライブラリが実行されているか、そして特定の脆弱な関数が動いているかを検知します。関数自体がアプリケーション内で一度も実行されないなら、それは悪用できません。私たちは、非悪用可能と判断された根拠（ライブラリが実行されていないのか？脆弱な関数が一度も呼ばれていないのか？）を示す証拠をチームに提供します。Oligoセンサーが、実際に実行されているライブラリ内にあり、悪用可能であることを示す脆弱性を突き止めた後は、CVSS、EPSS、CISAのKEV、エクスプロイト成熟度に基づいてさらに優先順位付けし、どの修正が最も緊急かをチームが理解できるようにします。

機能 #2: Image to Repo

現在市場にあるコンテナセキュリティ製品は、コンテナを不透明な箱として扱いがちです。たとえ内部で何か問題が起きたことを検知できても、詳細を理解するのは困難です。しかし、悪用可能な脆弱性――あるいは本番環境で実際に悪用されている脆弱性――を本当に修正するには、影響を受けたアプリケーションを特定するだけでなく、脆弱なリポジトリを突き止める必要があります。

そのため私たちはImage to Repo機能を作りました。これは、Oligoセンサーが最初に検知したコンテナイメージ上の脆弱性を、そのソースリポジトリまで遡って追跡します。 

私たちが気に入っている点: これで、いずれかのアプリケーションに悪用可能な脆弱性（あるいは実際に悪用されている状況！）が見つかった場合でも、リスクを下げるために迅速な対応が必要なリポジトリがどれなのか――そして脆弱性を修正するためにセキュリティチームが誰（どの開発者）と話す必要があるのか――を即座に特定できます。

機能 #3: 悪意あるパッケージ検知

悪意あるパッケージ（マルウェアが埋め込まれたオープンソースライブラリ）は、既知のパッケージに十分似せて作られているため、開発者や自動化されたパッケージマネージャーソフトウェアを欺くことがあります。悪用されずに何カ月、あるいは何年もコード内に存在し得る脆弱なパッケージとは異なり、悪意あるパッケージは即時のセキュリティ脅威です。

現在、Oligoは推移的依存関係を含め、あなたのあらゆるアプリケーションに悪意あるパッケージが存在する場合にそれを検知できます。

私たちが気に入っている点: Oligoは自社開発アプリだけでなくサードパーティにも利用できるため、ベンダー提供アプリケーションに悪意あるパッケージが含まれている場合でも即座に検知できます――その結果、ベンダーへ直ちに通知でき、悪意あるパッケージがあなたのシステムへ影響するのを防ぐための手段を講じられます。

機能 #4: ポリシー＆Issue

セキュリティの検出結果を完全に手作業で扱いたい人はいません。特定の種類のセキュリティリスクが見つかったときには、特定の担当者へ通知する必要があります――そして、誰も「通知ツール」をこれ以上増やしたくありません。

そのため私たちは、幅広いカスタマイズ可能なポリシーを設定でき、Jiraに自動でIssueを作成し、必要な関係者へアラートを送れる「ポリシー＆Issue」機能を開発することが重要だと考えました。

私たちが気に入っている点: 組織によってリスク許容度は異なり、アプリケーションごとにリスクは大きく変わり得ます。アラートのトリガーを完全に制御できるため、Oligoを組織のニーズに合わせて細かく調整できます。

機能 #5: 動的SBOM＆VEX

企業がSBOMを作り始めたとき、すぐに期待していたほど有用ではないことに気づきました――製品の変化を示す手段がなく、コードベースに脆弱なライブラリが含まれていても、特定の脆弱性がアプリケーションで悪用不可能であることを示す方法がなかったのです。

そこで登場するのがVEXです。「Vulnerability Exploitability eXchange（脆弱性悪用可能性交換）」の略で、SBOMの補完アーティファクトとして、悪用可能性の分析を示し、顧客やコンプライアンスの専門家がアプリケーションの実際のリスクを理解するのに役立ちます。しかしVEXは素晴らしいアイデアに見える一方で（特に、アプリケーションライブラリに存在する脆弱性の80%以上が悪用不可能である世界では）、組織はこれまで手作業で作成せざるを得ず、膨大な労力が必要でした。

だからこそ私たちは、VEXアーティファクト作成の手作業をなくし、アプリケーションコードで実際にどのライブラリと関数が動作・実行されているかを正確に把握できる「自動VEX」と「動的SBOM」機能を誇りに思っています。 

毎日何十件もの新しい脆弱性が公開される中、手作業で作成したVEXアーティファクトは、作成された瞬間に古くなってしまいます。自動化こそが、VEXを最新の状態に保ち、顧客や他の関係者からの要求に対して即座に提供可能にする唯一の方法です。

私たちが気に入っている点:  サードパーティアプリケーションを使っていて、その中身が分からない？ベンダーにSBOMやVEXを依頼する必要はありません――Oligoを使えば自動で取得できます。

先行公開（ネタバレ注意: 2024年は本当に、本当に大きな年になります）

アプリケーション層の攻撃で最悪なのは何でしょう？私にとっては、サイバー犯罪者がそれで逃げ切ってしまうこと、そして侵入者がすでに建物を去り、金の入った袋を抱えている後になって、私たちがいつも後始末をする羽目になることです。 

コンテナやアプリケーションを可視化するためのあらゆるツールがあっても、リアルタイムで何が起きているかについては私たちは盲目のままです――すべてが事後対応で、後からなら誰もが完璧に見通せて「なるほど、今ならどうしてこうなったかは明らかだ。でも、どうやって事前に分かったというのか？」と言えてしまいます。

さて……アプリケーション層攻撃を検知できるタイミングについて、あなたが知っている常識をすべて変える準備をしてください。

侵害が始まった瞬間――横展開が起きる前、被害が出る前に――アプリケーションへの攻撃を検知できるとしたらどうでしょう？

そして、CVEが割り当てられていない脆弱性への攻撃であっても、その瞬間検知ができるとしたら……？（まだ割り当てられていないだけの場合もあれば、誤った設定やその他の非CVE要因に起因する場合もあります。）

さらに、あなたが開発したものだけでなく、利用しているすべてのアプリケーションに対して、そのような保護を提供できるとしたら？

それはセキュリティのSFではありません。私たちのラボではすでに動作しているものであり、この第1四半期の後半に皆さまへお届けする予定です。

それまでは……この場から目を離さないでください。そして、私たちが取り組んでいる内容をもう少し踏み込んで先行して見てみたい方には、実際の動作をお見せします――詳しく知るには、ライブデモを予約してください。

‍