脆弱性に対処するための一般原則がいくつかあり、セキュリティの考え方や意思決定の指針として使用できます。
まず、何を保護しているのかを理解することが常に重要です。これは、実行する必要があるアクションに影響を与えるためです。たとえば、アーティファクトが Web サーバーの場合、信頼できないユーザーからそれを保護する必要があります。私たちのアーティファクトが暗号化ソフトウェアである場合、システムに物理的にアクセスできるユーザーからもそれを保護する必要があるのは明らかです。それぞれのケースにおいて、私たちはリスクの境界が何か、どこに重点を置く必要があるのかを明確に区別します。
次に、構成はコード ベースの一部です。悪意のある攻撃者が構成にアクセスできる場合、それは基本的に、悪意のある攻撃者がコード ベースにアクセスできる場合と同じです。
最近の Log4j 2.x 脆弱性 (Log4Shell) によって引き起こされた脆弱なシステムの津波を考慮すると、セキュリティ組織として、他の潜在的な脆弱性をより詳しく調査する必要があるかもしれません。ただし、コード内で見つかった潜在的なセキュリティ問題をすべて急いで判断する前に、この機会を一時停止して熟考する必要があるかもしれません。冷静な考えは、安全上の問題を引き起こすすべてが必ずしも同等に分類されるわけではないことを示唆している可能性もあります。
例として、このレンズを通して Log4j 1.x に対する最近の CVE-2021-4104 の割り当てを確認できます。これを悪用するには、設定を操作するために構成ファイルに直接アクセスする必要があります。同様のトピックが現在、Node コミュニティの例とともに Logback プロジェクトを中心に浮上しています。
明確にしておきますが、潜在的な脆弱性を暴露することは依然として良いことです。しかし、メディアの恐怖の真っただ中には、私たち自身の批判的思考を探求し、私たちが注意を払うべきコミュニティの基準を再確立することも適切です。潜在的な脆弱性の津波が再び発生すると、良いことよりも害の方が大きくなり、すでに過度のストレスを抱えているセキュリティチームをさらに圧倒し、オープンソースソフトウェアを保護するための業界の継続的な取り組みを混乱させる可能性があります。
CVE について批判的に考える
上記のスレッドで特定された議論は、いくつかの非常に興味深い疑問を引き起こします。
たとえば、脆弱性を悪用するにはシステム内のファイルへの特権アクセスが必要な場合、それは本当に脆弱性でしょうか?ほとんどすべての重要な最新のソフトウェアは、安全でない操作を許可するように構成できます。同様に、sshd が空のパスワードでのログインを許可するように設定されている可能性は十分にあります。これは sshd の新しい脆弱性と考えるべきでしょうか?
私たちのセキュリティ チームが使用するメカニズムの 1 つは、予想される動作と予期しない動作を考慮するというアイデアです。ソフトウェアがリモート コードを実行するように構成でき、この機能が十分に文書化されている場合、それは悪用可能な脆弱性を提供する行為でしょうか?これは、それ自体が実際のセキュリティ上の脆弱性であるというよりも、予期された動作であると考えられます。
安全でない構成可能なパターンを持たないようにソフトウェアを設計する必要があるでしょうか?これは賞賛に値する目標と見なされますが、過去 30 年以上にわたって私たちがオープンソース ソフトウェアを設計してきた方法とは多少矛盾します。オープンソース ソフトウェアの一般的な設計目標は、あらゆるユースケースを可能にする最高レベルの構成可能性を達成することです。近年、賢明なセキュリティのデフォルト設定は二次的な目標になっていますが、原則は常に、ユーザーが適切、安全、または安全でないと判断する方法でソフトウェアを構成する選択肢を提供することでした。
また、私たちは現在、CVE が個人や企業によって簡単に調達でき、その信頼性とキャッシュ可能性により価値がある世界に住んでいます。このユニークな組み合わせにより、問題のある割り当てが発生する可能性があります。一方で、潜在的なセキュリティ問題をスムーズに報告できることは良いことばかりなので、ある種の矛盾に直面しています。
業界として、より多くのソフトウェアを作成しながら脆弱性の特定がますますうまくなっているため、過負荷の可能性が容易にわかります。
ソフトウェアの脆弱性を適切に特定し、それらを評価し、軽減策を提供することは、特に複雑なケースの場合、非常にリソースを大量に消費し、大部分が手作業のプロセスです。機械学習手法はますます有用になり、人工知能の価値がさらに高まる可能性がありますが、多くの場合、（皮肉なことに）コンピュータは診断においてそれほど役に立ちません。
未来を見据えて
ここで概説した論点は、特定の CVE を変更することを目的としたものではなく、脆弱性評価の将来と、現在および将来的に安全ではないと考えられるものについての会話を開始することを目的としています。一般的なユースケースに適した堅牢で汎用的なオープンソース ソフトウェアを構築すると、必然的に多かれ少なかれセキュリティを提供する構成可能なモードが生成されます。これを続けたい場合は、使用の落とし穴を理解するのもユーザーの責任です。おそらくその答えは、ドキュメントと教育を強化し、通常の使用例における潜在的な脆弱性をトリアージすることです。
参考：https://snyk.io/blog/when-is-a-cve-not-a-cve/
CNCSOによるオリジナル記事。転載される場合は、出典を明記してください： https://cncso.com/jp/コンテキストのセキュリティ-html
