オープンリソースのクローズ：ファンタジーを払拭する

公開: 2022-03-31

2021年12月のLog4jの脆弱性の開示と、開発者が所有するJavascriptライブラリ「color.js」と「faker.js」を妨害するという新しい状況を追求して、オープンソースのコンピューターソフトウェアの状態が問題になっています。

ホワイトプロパティでのオープンソースに関する注目度の高い会議と、バイデン米国大統領からの政府命令により、「オープンリソースの結論」であると主張する人さえいます。供給の開放の兆候として主要な脆弱性をチェックしたくなるかもしれませんが、真実はそれからかなりのものです。

オープンソースソフトウェアは、ビジネスソフトウェアパッケージほど安全ではありません。実際には、ほとんどのプロのコンピュータソフトウェアは、オープンソースシステムを備えているか、動作している可能性があります。オープンサプライとは、ソフトウェアプログラムが、希望する個人がサプライコードにアクセスできる正確な方法で作成されていることを意味するだけです。

Apache Log4jチームからのLog4j応答で私たちが見ているのは、まさに私たちが望んでいることです。チームは、開発したソフトウェアパッケージを真剣に受け止め、現在、セットアップされた基盤の要望に応えています。彼らがボランティアであることを見ると、この種の反応は、オープンリソースコミュニティ内で頻繁に見られる所有権の喜びを示しています。

Log4jのようなインシデントは、オープンソースの閉鎖を扇動するよりも、全体としてオープンソースの強化を強化する可能性が最も高いです。これは、Heartbleedが2つのオープンソースとシャットソースの成長グループの進捗方法を強化したのと同じ方法です。それで、オープンソースが引き続きここにリストされている場合、脆弱性をはるかに巧みに検出して軽減するために、組織が転送を転送するために何をすべきでしょうか？

組織レベルからのコンピュータソフトウェア保護への対応

完全に、脆弱性を特定して軽減する戦略では、いくつかの役割を前もって概説する必要があります。ほとんどの個人は、ソフトウェアパッケージのサプライヤ（つまり、依存しているコンピュータソフトウェアを開発する人々）がそのソフトウェアをチェックすることを望んでいます。そのテストの最終結果は、サプライヤが提供するソフトウェアの弱点を浮き彫りにする結果の確立になります。偉大な全世界では、これらすべての弱点はすべて、プログラムの出荷と配信の前に解決されます。

本物の惑星では、それでも、これらすべての弱点のいくつかは事前設定され、いくつかは「修正するプログラムがない」とマークされ、いくつかは長期的な打ち上げで楽観的に修正されます。弱点のリストが何であるか、そしてどれが最終的に設定されたかは、プロバイダーが通常明らかにするものではありません。さらに、すべての弱点を発見できるツールは1つではなく、リソースコードがある場合にのみ機能するツールもありますが、他の人は実行中のソフトウェアを要求します。

これには「脆弱性」という言葉が具体的かつ基本的な意味を持っているため、言及されていないことに注意してください。アプリケーションでは、脆弱性は、悪用される可能性がある、または悪用される現実的な機会がある単なる弱点です。

すべてではありませんが、ほとんどの脆弱性は、全国的な脆弱性データベース、またはNVDのみとして認識される一元化された手順を介して開示されます。 NVDは米国にルーツがあり、米国当局によって管理されていますが、NVDのコンテンツはすべての人がアクセスでき、複数の国際的な場所に複製されます。ガバナンスの観点から、NVDのコンテンツの改善をチェックすることは、新しい脆弱性の開示を最大限に活用するための優れた方法です。

問題は、NVDの更新がメディア報道よりも遅いことです。そのため、Log4Shell、HeartBleed、Dirty Cowなどの主要な脆弱性がある場合、脆弱性を見つけた従業員は、困難の意識を広げるために、脆弱性のブランドタイトルを作成する可能性があります。これらのサイバーギャザリングのメディア保護を選別するガバナンス計画を作成することは、間違いなく素晴らしい習慣ではありません。

脆弱性管理への入り口としてのメディア報道が悪い考えであり、NVDがすべての事実を提示するために少し段階的である場合、最も効果的なガバナンスポリシーは何ですか？これは、「ソフトウェア構成分析」またはSCAとして知られるセキュリティツールの形式に由来します。 SCAソフトウェアは、アプリケーションのソースコード、またはアプリケーションを定義する実行可能ファイルまたはライブラリの両方にあるようであり、そのソフトウェアを構築するためにどのオープンソースライブラリが採用されているかを把握しようとします。

それらの人々のライブラリのリストは、SBOM、またはコンピュータソフトウェアの部品表として知られています。 SCAアプリケーションがその役割を効果的に実行すると仮定すると、NVDの詳細をSBOMにマップするガバナンスポリシーを作成できるため、パッチを適用する対象がわかります…それでも、説明すべき潜在的なNVDファクトがある場合を除きます。

はるかに優れたSCA機器のいくつかは、保留中のNVDエントリがあるが、そのNVDエントリの詳細がSCAベンダーによって拡張されている場合に顧客に事前に警告するアドバイザリを生成することにより、その課題を解決します。最新の機器のいくつかは、脆弱性の開示によって影響を受けるコンピューターソフトウェアのバリエーションのスクリーニングまたは検証にも専念しています。

それでも、SCAソフトウェアプログラムは開示と識別の間の穴を埋めることができますが、根本的な制限があることに注意する必要があります。 SCAプログラムがすべてのプログラムをスキャンしていない場合、せいぜい、プログラムのサブセットに対する新しい脆弱性の開示にのみフラグを立てることができます。

ガバナンスカバレッジの観点から、IT部門は、すべてのソフトウェアプログラムと調達機能を確立して、更新や無料ダウンロードなどのすべてのアプリケーションがSBOMの下に表示され、SBOMが適用されて検証されていることを確認します。 SCAソフトウェアプログラム。プログラムはソース形式とバイナリ形式の両方で利用できるため、この道を進むガバナンスチームは、すべての種類と形式のコンピュータソフトウェアを効果的に実行できるSCAソフトウェアプログラムを選択することが重要です。これらのタイプのガバナンス計画は、新しい脆弱性の開示と企業への影響の特定に役立ちますが、緩和にはソフトウェアテストが必要となるため、生産的な緩和と独自のポリシーの違いが生じます。

自分のエンジニアリングのセキュリティを確保することは1つのポイントにすぎませんが、オープンリソースの優雅さは、コラボレーションできるように設計されていることです。

エイブラハムリンカーンを言い換えると、オープンリソースは、個人による、個人のための人々のノウハウです。ファッショナブルなオープンソース運動は、コードの動作が気に入らなければ、コードを自由に変更して、機能のギャップが存在すると認識されても取り組むことができるという基本原則に基づいて開始されました。

最近私たちが直面している困難の要素は、オープンソースプロジェクトの消費者またはエンドユーザーが、オープンサプライの課題がビジネスアプリケーションの売り手であるかのように振る舞うという感情です。

GitHubで行われている、かなりよく知られているオープンリソースのチャレンジリストに表示されると、機能のリクエストと、選択したトラブルがいつ解決されるかについてのレビューが表示されます。このような問題のストーリーと保守性に関する不満は、製品マネージャーがそれらの人々の要求に終止符を打ち、ロードマップに追加され、ある時点で立ち上げられることを暗黙のうちに期待しています。すべて無料です。

実際、機能のギャップ、さらには認識されたバグのギャップは、無料のプログラミングエキスパートサービスを要求するのではなく、不平を言う人にとって実質的に重要なコードの長期的な成果に貢献するための代替手段としてのチャンスを意味します。

もちろん、プロジェクトで使用されているプログラミング言語を知らない人もいますが、他の人が、エネルギッシュな貢献者の複雑さを解消するバリエーションよりも、未知のサードパーティからの苦情を優先することを期待するのは現実的ではありません。何よりも重要なのは、寄稿者の利他主義によるオープンリソース機能です。

現代を超えて、私たちは長い間、有名なオープンリソースの仕事の主な貢献者に耳を傾けてきました。彼らのソフトウェアパッケージの使用から大企業が稼いだ収入についての特定の迷惑です。誰かが自分の力をタスクに投入して、その試みから3分の1の収益を得るだけであることに関係するのは簡単ですが、現実には、その3番目のbashがオープンなリソース向上労働力の試みから利益を得ている場合、彼らはその長期的な成功に貢献している。

そうしないと、問題のコードが信頼できないメソッドに変換される可能性があるだけでなく、保護の懸念が特定されて解決されたときに、人の修正の適用が遅れる可能性があるという危険があります。結局のところ、中小企業が企業を動かすコンピュータソフトウェアを作成するチームとのやり取りに時間をかけていなければ、企業を動かすすべてのプログラムがどこから発信されているのかわからず、確実にパッチを適用できない可能性があります。それ。

オープンサプライの脆弱性を発見することは問題ではありませんが、悪用される可能性のある弱点を表すプログラムの欠陥を検出することは重要な主題です。オープンソースとクローズドサプライのソフトウェアパッケージには、安定性の問題について同等の可能性がありますが、オープンリソースを使用すると、誰でもこれらすべての問題を特定できます。それを頭に入れて、組織は最新の脆弱性を監視するために、メディア保護に依存しない予防的な対策を講じる必要があります。

同様に重要なこととして、彼らは報酬を与えるオープンサプライの割り当てに貢献する目的を実行する必要があります。そうしないと、予期しないコードのバリエーションや重要なパッチの認識の遅れに苦しむ可能性があります。

Tim Mackeyは、 Synopsysのプリンシパルプロテクションストラテジストです。