製品セキュリティにおける悪い慣行
(cisa.gov)製品自体において
メモリ安全でない言語（C、C++ など）
可能な限りメモリ安全な言語を使い、そうでない既存プログラムは 2025 年末までに段階的に置き換えるべきです。
SQL 文の直接実行
パラメータ化クエリ、プリペアドステートメント、または ORM を使ってください。
OS コマンドの直接実行
ユーザーが入力する内容はコマンドそのものであってはいけません。コマンドを直接実行する代わりに組み込みライブラリ関数を使うか、入力に英字/数字/アンダースコアのみを許可するようにすべきです。
あまりにも有名なパスワード の使用
以下のような方法で、できるだけ避けられるようにするべきです。
- 最初から一意のパスワードを提供する。
- インストール中にユーザーへ強力なパスワードの作成を求める。
- MFA のようにパスワードへ時間制限を設定する。
- 確実な認証情報を得るために物理的なアクセスを要求する。
- キャンペーンを実施する、または従来より安全な認証方式へ移行する。
既知の脆弱性 の放置
そのページに載っている脆弱性は「すべて」防止されるべきです。新しい脆弱性が報告された場合は適時に対処し、修正済みバージョンへ更新していないユーザーには警告を出すべきです。
脆弱性のあるオープンソースライブラリ
使用しているライブラリについては、責任ある形でその事項を知らせ、貢献すべきです。次のような対応も含みます。
- SBOM の作成: ソフトウェアがどのライブラリを使っているかを示します。
- 依存しているオープンソースライブラリに適用すべき事項
- セキュリティ検査を実施する。
- 継続的で、十分に保護され、適切に保守されている質の高いプロジェクトを選ぶ。このようなセキュリティ原則 を守るのも有効です。
- よく知られた脆弱性がないか継続的に調査しなければならない。
- コピーをベンダーがあらかじめ保持しておくべきであり、検証されていない場所から更新してはいけない。
- 新しいメジャーバージョンへの更新やセキュリティパッチを受けるコストを考慮すべきです。
脆弱性が製品に影響しない場合は、その脆弱性がなぜ影響しないのかを公開で説明すべきです。
脆弱性がある、または未知の暗号アルゴリズム（TLS 1.0/1.1、DES、MD5 など）
最新のアルゴリズムを使うべきです。加えて、NIST の指針 に従って、標準化された耐量子暗号アルゴリズムの準備も進めるべきです。
ソースコードに含まれる秘密鍵
Secret Manager を使って、プログラムが秘密鍵を安全に取得できるようにするべきです。また、ソースコード内に秘密鍵がないか検査すべきです。
セキュリティ機能において
MFA 非対応（パスキーのみ対応も含む）
救急医療機器のように遅延が危険なものを除き、基本的に MFA を自前で実装するか、外部認証器を使えるようにするべきです。これを管理者に要求し、管理者は組織内のユーザーに対してこれを要求すべきです。
侵入の証跡を提供しない
- ごく基本的な機能として、設定の変更や参照、ログイン履歴、情報アクセスに関するログを生成すべきです。
- クラウド提供者の場合、追加費用なしで少なくとも 6 か月間これらのログを保持し、ユーザーが閲覧できるようにするべきです。
組織のプロセスとポリシーにおいて
CVE を発行しない
重大または大きな影響を与えうる脆弱性は直ちに公開されるべきです。
脆弱性公開ポリシー（VDP）を公開していない
次のようなポリシーを公開すべきです。
- 一般大衆によるテストの承認
- 善意で努力する人に対して法的措置を取らないことの約束
- 報告のための明確なチャネル
- CVD（Coordinated Vulnerability Disclosure）のベストプラクティスと国際標準
報告された脆弱性は、適時に、リスク順で修正すべきです。
（オンプレミスの場合）不明確なサポート期間
サポート期間を明確に伝え、その期間中はセキュリティアップデートを提供すべきです。
- カカオトークのワンクリックエクスプロイト
- GN⁺: NIST（米国国立標準技術研究所）、特定のパスワード文字構成要件を禁止
- ホワイトハウス、開発者に C と C++ を避けて「メモリ安全」言語の使用を促す
- 自分の車をハックする : Hyundai Ioniq: ソースコードに Google で検索可能な RSA 暗号文が見つかった
7件のコメント
セキュリティは、しまったと思ったその瞬間、、！ （というのを軍隊で見た気がするけど）
簡潔に、しかし折れずに前へ！
また ORM を使うなって話が出回ってるけど..
ORMの代わりにPrepared Statementを使えばいいです。
zzz
何事にも原則はありますよね。守るのが難しいだけで……
いいね、賛成です
ユーザーに強力なパスワードの生成を求めること != 特殊文字、英大文字・小文字、数字を必ず含めること
適度に長いだけでも、十分に強力なパスワードです。