「Drupalのセキュリティ勧告ポリシーの対象外」のモジュールを使用する
Drupal 7モジュール）、具体的には 条件フィールド モジュールを使用したいと思います。
それは私が私が必要とするものを正確に行うことを可能にします。このモジュールはかなり積極的に使用および保守されているようですが、セキュリティの問題が発生した場合に更新を取得しないモジュールを使用することについて、どれほど心配する必要があるかわかりません。
何かアドバイス？このようなコーディング（hook_form_alterとstatesを使用）は自分自身でより安全なアプローチですか？
セキュリティアドバイザリプロセスと権限ポリシー によると、アルファ、ベータ、またはrc（リリース候補）ステータスのモジュールはこのポリシーの対象外であり、これらのプロジェクトのセキュリティアドバイザリは報告されません。これを書いている時点で、 条件フィールド はDrupal 7および8の両方が「アルファ」段階にあるリリースを推奨しています。セキュリティ勧告がなくても、モジュールが更新されたときに通知されます。
モジュールのリリースとそのステータスはプロジェクトのメンテナーによって任意に割り当てられるため、Drupalのセキュリティアドバイザリポリシーの対象外としてマークされたモジュールを使用するかどうかを判断できるのはあなただけです。あるメンテナの「アルファ」モジュールは、別のメンテナにとって「1.0」バージョンになります。
メンテナの信頼性、Drupal.orgの歴史、プロジェクトの人気、問題が解決または対応されるスピードを調べる必要があります。多くの人気のある公開サイトdoは、「ベータ版」またはその他のモジュールを利用しています。
独自のモジュールをコーディングして、既存のモジュールの機能を複製すると、潜在的に診断または修正できるのが1人のユーザー（つまり、あなた）だけであるセキュリティの脆弱性が発生する可能性が高くなります。有能なメンテナとアクティブなユーザーコミュニティで「アルファ」モジュールを使用することは、はるかに賢明なようです。
セキュリティアドバイザリを使用する「のみ」に注意してください。代わりに、より多くの基準を検討して、意思決定を行うことができます。 （私が呼ぶもの） メンテナンススコアカード で説明したように。その場合、それらはチャート作成モジュールに関連しますが、もちろんモジュールの任意のセットに適用できます。
これらはIMOであり、次のことも考慮する必要があります
- 未解決のバグの数
- RTBCされたアイテムはありません
- 最後のコミット
- コミュニティ文書
- 2つのコアリリースをサポート
- D8のDEVリリース
- コミッターの数
- SimpleTestsまたは単体テスト
- 自動テストが有効
- ダウンロード/インストール率
- コミットでのユーザーの貢献