最大手を含む6社が締結、米CISAが幼稚園〜高校向け教育ソフト開発会社と交わしたセキュア・バイ・デザインの誓約の中身

原則1：顧客のセキュリティの結果に責任を持つ

1. 追加料金なしのシングルサインオン（Single Sign On：SSO）。SSOはパスワードベースの攻撃を減らすことでセキュリティを強化できるため、開発会社は全ての顧客が標準ベースのSSOを構成できるようにすべきである。

目標：誓約書にサイン後6カ月以内に、顧客は追加料金なしで標準ベースのSSOを構成できるようにする。

2. 追加料金なしのセキュリティ監査ログ。サイバーセキュリティインシデントの監視と対応に必要なセキュリティ監査ログは追加料金なしで学校に提供されるべきである。

目標：誓約書にサイン後6カ月以内に、セキュリティ監査ログは追加料金なしで顧客に提供する。

原則2：抜本的な透明性と説明責任を取り入れる

1. セキュア・バイ・デザインのロードマップを公表する。顧客のセキュリティを向上させるためにソフトウェア開発ライフサイクル（Software Development Life Cycle：SDLC）にどのような変更を加えているかを文書化する。これには脆弱性のクラス全体を排除するために講じた措置（例えば、メモリセーフな言語、パラメータ化されたクエリ、ウェブテンプレートフレームワークの使用など）が含まれる。またそのために、採用、トレーニング、コードレビュー、その他の内部開発プロセスをどのように更新しているかについての詳細も含める。そのロードマップでは、従来MFAに使われているモバイルデバイスを生徒が所有していない可能性があることを考慮した上で、生徒を含む全てのユーザをMFAに誘導するために開発会社がどのような計画を立てるのかについても概説すべきである（パスキーのような他の認証オプションを考慮すべきである）。

目標：誓約書にサイン後6カ月以内に、セキュア・バイ・デザインのロードマップは開発会社のウェブサイトで公表する。

2. 脆弱性開示ポリシーを公表する。公表する脆弱性開示ポリシーは次のとおり。（1） 開発会社が提供する全ての製品に対するテストを許可し、（2） ポリシーに基づくテストを許可する法的なセーフハーバー（安全地帯）を提供し、（3） 設定されたタイムラインの後に脆弱性を一般公開することを許可する。開発会社は発見された脆弱性の根本原因の分析を行ない、実現可能な最大限で、セキュア・バイ・デザインのロードマップに沿って根本原因の脆弱性クラスを排除するための措置を講じるべきである。

目標： 誓約書にサイン後3カ月以内に、開発会社は上記の基準に準拠した脆弱性開示ポリシーを自社のウェブサイトで公表する。

3. 脆弱性の透明性を取り入れる。脆弱性の根本原因を特定するCWEフィールドを含め、製品のCVEエントリが正確且つ完全であることを保証する。

目標：誓約書にサイン後3カ月以内に、開発会社が公表する全ての新しいCVEに、脆弱性についての完全な詳細情報が含まれ、脆弱性の根本原因に対して適切に割り当てられたCWEタグが付与されるようにする。

4. セキュリティ関連の統計データと傾向を公表する。これには、顧客および管理者のMFA導入状況や、安全でないレガシープロトコルの使用状況について集計された統計データが含まれる場合がある。

目標：誓約書にサイン後6カ月以内に、セキュリティ統計と傾向は開発会社のウェブサイトで公表される。

原則3：トップから主導する

1. セキュリティに対してセキュリティを負うビジネスリーダーのトップ（CTOやCISOではない）を指名する。この人物は、セキュア・バイ・デザインのロードマップの策定と実施を含め、ビジネスの中核機能としてセキュリティと品質を統合するプロセスを管理する責任を負うべきである。

目標：誓約書にサイン後3カ月以内に、開発会社はセキュリティに対して責任を負うビジネスリーダーのトップを指名する。