ライブラリから機能を削除すると、セキュリティリスクが増加または減少しますか？
組み込みシステムなどのリソースに制約のある環境をターゲットとするソフトウェアライブラリは、条件付きコンパイルを使用して、コンシューマーがスペースを節約できるようにし、本番環境で配布される最終的なバイナリから未使用の機能を削除してパフォーマンスを向上させます。
ライブラリ開発者がコンパイラフラグを作成し、ライブラリの設計およびテスト段階で考慮されたと想定します。
ほとんどの設計決定にはトレードオフがあり、この場合、設計およびテスト対象のブランチが増えるため、コードの複雑さと製品品質は間違いなく影響を受けます。
ただし、セキュリティに関しては、最終的な影響は明確ではなく、機能の削除によるプラスとマイナスの両方の影響があります。最初は、コードを削除することで、攻撃の対象となる領域を減らします。しかし、その一方で、カスタムバイナリをビルドするということは、その特定の組み合わせにバグが存在し、したがって悪用される可能性があることを意味します。
2つの異なるタイプの分岐が考慮されているだけでなく、コンパイラー条件構文はランタイムの対応する構文よりも安全ではない（少なくともCでは）ため、従来のランタイムパスの複雑さとは異なります。
興味深い現象は、カスタムバイナリをビルドするとユーザーが標的型攻撃にさらされる可能性がありますが、標準ビルドを使用するとユーザーが大量に悪用される可能性があることです。
問題は、セキュリティにプラスとマイナスの両方の影響があることを考えると、それらを定量化した場合、正味の影響はプラスかマイナスか？もう1つは、学問的ではない言葉ですが、セキュリティに関心がある場合、必要な機能なしでカスタムバイナリを作成する必要がありますか？
この質問を引き起こした具体的な例は、Busyboxが条件付きでコンパイルされた機能フラグを多用していることです。 https://git.busybox.net/busybox/tree/networking/httpd.c
この場合、攻撃対象が小さいため、カスタムバイナリ（存在する場合）の方が安全であると考えます。
「コードの削除」について私が心配する主な問題は 意図しない副作用 であり、特にプロジェクトに精通していないサードパーティによってコードが削除されている場合は特にそうです。
この場合、これらは上流によって公式にサポートされている条件付きフラグです。そして、多数のフラグにもかかわらず、それらは賢明に見え、それぞれ1つの機能をカプセル化します。
「コンパイラの条件構文は、ランタイムの構文よりもはるかに安全ではない」というあなたの声明はここでは関係ないと思います。
カスタムバイナリをビルドすると、ユーザーが標的型攻撃にさらされる可能性がありますが、標準ビルドを使用すると、ユーザーが大量のエクスプロイトにさらされる可能性があります
標準ビルドを使用すると、大量のエクスプロイトに加えて、標的型攻撃にさらされることになります。不利な点は、おそらく使用された特定の組み合わせが安全ではなかったために（たとえば、必要なチェックを削除できると仮定した場合）、通常のビルドではなくてもカスタムビルドが何らかの形で脆弱になる可能性があることです。これは依然としてバグのバグですこれらはアップストリームによって提供されるオプションであるため、コード。
または、おそらく脆弱性があったが、他の残骸の一部が悪用不可能になり（または悪用しにくく）、自分で脆弱にしたコードの一部を削除した（たとえば、バッファオーバーフローにより未使用が上書きされる可能性がある）標準バイナリでバッファリングしますが、ビルドでスタックを上書きします）。
ただし、ビルドが安全になり、標準のビルドが安全ではなくなる場合もあります。それらはほぼ均一になるので、一般的に小さい方の面が「勝つ」と考えます。
私がもっと重要だと思う別の問題は、保守性です。つまり、新しい（IoT？）システムを設計していて、busyboxのカスタムビルドを使用するか、ビルド済みのバイナリを使用するかを決定している（私は 提供されたバイナリを信頼する の潜在的な問題は別としておく） 。カスタムビルドを使用する必要がある場合、標準リリースをコピーする場合と比較して、後で更新することが難しくなりますか？主なリスクは、リリースでパッチが適用されていない将来の脆弱性に起因します。カスタムビルドを使用すると、プログラムが3年間更新されなくなりますが、アップストリームバイナリを使用している場合は四半期ごとに、より安全になります。 （悲しいことに、現実の答えは、バイナリは決して更新されないということです）
さまざまな順列をすべて何らかの方法で配布している場合でも、アプリケーション全体に対する攻撃の責任はまだあると思います。単一の組み合わせを使用するユーザーは攻撃対象領域が減少するため安全である可能性がありますが、すべての順列にわたって全体的に同じ数の潜在的な問題が依然として発生します。これを行うためのコストがテストの削減である場合、私はあなたが全体的に悪化していると私は言うでしょう。
もう1つの問題は、問題が見つかったときに更新を簡単に発行できることです。異なるビルドが複雑になり、パッチの配布がさらに複雑になった場合は、それもマイナスの方向に向かっていると思います。
言い換えれば、私はより小さくテストされたより悪いテストされたアプリケーションよりも、テストされたより大きなアプリケーションを採用するでしょう。
そうは言っても、悪魔は本当に具体例の詳細にあると思います。アプリケーションによってテストの自動化が容易になり、異なるビルドのテストコストが削減される場合は、複数のオプションの方向に進む可能性があります。