OWASP - User contributions [en]

OWASP Secure Software Contract Annex/ja

2011-07-06T13:18:52Z

Tomo: /* 11. セキュリティ承認と保守 */

'''セキュア・ソフトウェア開発契約付属書'''

警告：この文書は、単にガイダンスと考えられなければなりません。
OWASPは、ソフトウェア契約を交渉するのを手助けするために、
あなたが資格のある弁護士に相談するよう強く勧めます。

==序文==

OWASPセキュア・ソフトウェア開発契約付属書は、ソフトウェアの開発者とその顧客が、開発または供給されるソフトウェアのセキュリティに関連した重要な契約条項と条件を交渉し、取り込むことを助けます。このプロジェクトの理由は、多くの契約はこれらの問題に触れておらず、しばしば関係者が実際に同意されたものに劇的に異なる見解を持つことです。私たちは、これらの条項を明確に述べることは、双方の関係者が進め方について情報に基づいた意思決定ができることを確実にするもっともよい方法であると思っています。

「市場がより良いセキュリティを要求するとき、商用ソフトのセキュリティは改善します。
最低限、あらゆるソフトウェア提案依頼書は、ベンダーに彼らがセキュリティ脆弱性に対して
生産物をテストする方法を詳述するよう依頼しなければなりません。このステップは、企業が
セキュリティを評価すると市販ソフトウェアのベンダーと外部調達された開発者を納得させ始めます。」
-- John Pescatore（Gartnerのリサーチ・ディレクター）として

私たちは、顧客と開発者が、期待について議論して、責任について交渉することに対するフレームワークとしてこの文書を使うよう勧めます。この付属書は、ソフトウェア開発契約に添付されることを目的とします。これらの条項は交渉の余地があります。そして、それらは顧客と開発者によって、協議されることができて、協議されなければならないことを意味します。

==プロジェクトについて==

この文書はOpen Web Application Security Project（OWASP）財団（セキュアなソフトウェアに関連した無料でオープンなツールとドキュメンテーションを作成することを専門とする非営利の慈善団体）によって作成されました。個人契約において容易に使用できるようにするために、この文書はCC Share Alike 3.0ライセンスにて提供されます。あなたが適すると思うように、修正してもよいですし、使用してもよいです。あなたは、http://www.owasp.com/index.php/OWASP_Legal_Project でこのプロジェクトについて更なる詳細を見つけることができます。私たちは、ソフトウェア（法律コミュニティだけでなく）の製作者と消費者のコメントを歓迎します。

OWASPは、この文書の研究と準備における彼らの役割に対して [http://www.aspectsecurity.com Aspect Security] から特別な貢献を感謝して認めます。

==異論==

以下のわずかなページは、ソフトウェア開発契約においてこの言い回しを使用することに対するいくらかのたびたび聞こえる異論をカバーします：

===しかし、すべての条項が私たちにとって適切であるというわけではありません…===

この文書は、あなたの合意の開始地点です。あなたは、すべての活動が好きではないかもしれません、または、より多くの提案をしたいかもしれません。あなたは異なる責任を割り当てたいかもしれません。この文書は、すべてのソフトウェア顧客と開発者の要望を厳密に取り込むことを意図しているわけではありません。ソフトウェアが最終的にセキュアになることを確実にするために重要である、主要な項目を議論するためのフレームワークを提供することを意図します。セキュリティを議論して合意を得た後で、あなたはこの合意を適合するように調整すべきです。

===しかし、これらの活動に対して誰が代金を払わなければならないのでしょうか===

この契約は、ソフトウェア開発者により多くの負担を与えることはほとんどありません。問題は、セキュリティ ― もちろんそこにある ― と関連したコストがあるかどうかということでありません。むしろ、適切な問題はどんな活動がそれらのコストを最小にするために双方によって実行されなければならないかということです、そして、いつ、それらは起こらなければなりませんか。

この付属書は、誰がここに記述される活動の料金を払わなければならないかという問題については、意図的に語られていません。これらの活動の多くがすでに起こらなければならなくて、多くの顧客によって期待される一方、それたはソフトウェア産業で定期的に実践されることはありません。誰が（そして、いくら）支払うかという問題が、交渉の一部でなければなりません。

セキュリティのコストを計算することは、非常に難しいです。セキュリティ活動を実行することに関連したコストがある一方、それらを無視することに関連したかなりのコストもあります。私たちは、ソフトウェアを開発する最も費用対効果がよい方法について確信しています。それは、セキュリティ瑕疵が導入されるという可能性を減らして、瑕疵を導入して、それを修正することの間で時間を最小にすることです。

コストを計算するときにする一つの重要な区別は、セキュリティ手法を構築することと、それらの手法が正しくて効果的であることを確実にする保証活動の間にあります。ライフサイクルの終わりに手法を加えようとすることは、深刻な設計問題を引き起こすことがありえて、めざましくコストを増やします。この合意は、手法についての早い段階の決定がこれらのコストを最小にするのを奨励します。同様に、配備直前に保証活動（例えばコードレビューと侵入テスト）をするまで待つことはコストをめざましく増やします。私たちは、保証を得る最も費用効果がよい方法がライフサイクルを通して努力の一定のレベルを保証に入れることであると思っています。

===しかし厳密さのレベルは間違っている….===

この合意は、開発されているソフトウェアが大企業または政府機関にとってかなり重要であると仮定します。私たちは、大部分のソフトウェア開発組織によって達成できる合意のために「厳格さのレベル」を選んで、最も一般的なリスクを確認して、取り扱います。

しかし、重要なアプリケーション（例えば医学であるか、財政的であるか、防衛に関連したソフトウェア）で使われそうであるソフトウェアについては、あなたは厳格さのレベルを上げたいかもしれません。あなたは、追加のレビュー、文書化とテストの活動を加えたくてもよいです。あなたは、脆弱性を探すこと、診断すること、修正することに対するプロセスを強化しくてもよいです。より機密を扱わないアプリケーションのために、あなたは活動を減らすか、取り除きたくてもよいです。

===しかし、私たちはそれほど多くのリスクをとることができない…===

この契約は、ソフトウェアにおけるセキュリティ脆弱性に対するリスクをとるのかという議論を容易にすることを目的とします。範囲の一端では、顧客はすべてのリスクをとることができました、そして、開発者はたくさんの脆弱性をもつコードを供給することができました。他の極端では、開発者はすべてのリスクをとることができて、完全なコードを供給することに対する責任を負うことができました。これらの両極端は、どちらとも実行不可能です。

現在、この契約において、開発者は要求においてカバーされたか、理にかなったテスト努力によってカバーされるべき問題に対するリスクをとります。しかし、「新しい」セキュリティ問題の改善は、顧客によって代金を払われるべきです。私たちは、これが開発者が彼らのリスクの境界となることができて役に立つバランスで、顧客が前もってセキュリティ要求を正しくするのを奨励すると思っています。しかし、この問題の多くの他の可能性がある解決が、あります。あなたには他の提案があるかどうか私たちに知らせます、そして、私たちは彼らをこの文書の将来の版に含めてもよいです。

ここでの議論がコードにおいてセキュリティ脆弱性を修正することに関連したリスクをカバーだけして、これらの脆弱性のあらゆるエクスプロイットに基づくあらゆるセキュリティ・インシデントから立ち直ることと関連したコストを含まないことに注意すべきです。私たちは、この領域におけるベスト・プラクティスに興味があります。

===私たちはどのように第三者のコードを保証するでしょうか===

ほとんどすべてのソフトウェアプロジェクトは、第三者のコード（例えばライブラリ、フレームワークと生産物）のかなりの量を使います。このコードは、ただセキュリティ観点から、カスタム・コードがあなたのプロジェクトのために特に発達したのと同じくらい重要です。
私たちはこのコードのセキュリティを確実にすることに対する責任が開発者によって負われて最もよいと思っています、しかし、彼らにはこのセキュリティを保証するために彼ら自身のいっぱいの能力がないかもしれません。しかし、セキュリティは「構築するか、買うか」議論の一部分でなければなりません、これはそれを促進する最もよい方法のようです。

開発者は、もちろん、終わりまで第三者のソフトウェアの提供者にこの責任をパスする選択権があります。開発者は彼ら自身第三者のコードを分析することもできるか、彼らのためにそれを分析するために、セキュリティの専門家を雇うこともできます。

===しかし、なぜ私はすべてのこのトラブルにいくべきなのでしょうか===

最後に、私たちはソフトウェアを契約しているプロセスの一部分をセキュリティをすることに代わるものがないと思っています。現在では、私たちは多くのソフトウェア開発契約のもとで供給されているコードのセキュリティに関する重大な誤解があると思っています。これは、わずかなソフトウェア経験または理解とともに個人によってなされる高価な訴訟と決定に至ることができるだけです。この問題の完全な議論に対して [[Secure software contracting hypothetical case study]] （[https://www.owasp.org/index.php/Secure_software_contracting_hypothetical_case_study/ja 日本語訳]）を読んでください。

多くの利点が、この契約を通してうまくいくことにあります。主要なものは、それが関係する関係者の間で期待を明らかにするということです。場合によっては、難しいセキュリティ問題がソフトウェアで表面化するとき、それは訴訟を妨げるのを助けます。また、これらは多くの法的で調整するコンプライアンスの理由によって必要とされる同じ活動です。

===しかし、このドキュメントですべてを作ることは難しい===

OWASPは、文書化を目的とした文書化を推奨しません。この契約は品質（量ではない）を促進することに集中します。私たちは、短いリスク評価、数ページの要求、短いセキュリティ設計文書、テストプラン、いくつかのテスト結果とともに、この契約に応じることが（若干のプロジェクトにおいて）ありえると思っています。

この文書の目標は、ライフサイクルの各段階で、単に適切な注意がセキュリティに払われたことを確実とすることです。追加の利点は、この文書が基本的に、このソフトウェアが安心してそれがそれがすると主張することをするのをまかせられなければならない理由に対する議論を配置する「証明パッケージ」をつくるために一緒に集められることができるということです。

==契約付属書==

===1. 序文===

この付属書は、顧客と開発者の間で_____________________ ("合意") するために作られます。顧客と開発者は、以下の条項によりソフトウェアのセキュリティを最大にすることに同意します。

===2. 原理===

この付属書は、ソフトウェア開発関係のすべての関係者のセキュリティ関連の権利と義務をはっきりさせることを目的とします。最高レベルで、関係者は以下に同意します

;(a) セキュリティ決定は、リスクに基づきます : セキュリティについての決定は、関係するリスクのしっかりした理解に基づく顧客と開発者によって共同でなされす。

;(b) セキュリティ活動はバランスが保たれます : セキュリティ努力は、全てのソフトウェア開発ライフサイクル全体でおおよそ均一に配布されます。

;(c) セキュリティ活動は統合されます : ここに協議されるすべての活動と文書は、開発者のソフトウェア開発ライフサイクルに統合されて、残りのプロジェクトと別にしておかれるというわけではありません。この付属書の何も、どんな特定のソフトウェア開発プロセスを意味しません。

;(d) 脆弱性は予想されます : すべてのソフトウェアにはバグがあります、そして、それらのいくらかはセキュリティ問題を生じさせます。顧客と開発者は、ライフサイクルにおいてできるだけ早く脆弱性を特定するよう努めます。

;(e) セキュリティ情報は完全に明らかにされます : すべてのセキュリティ関連した情報は、すぐに、そして、完全に、顧客と開発者で共有されます。

;(f) 役に立つセキュリティ文書だけが必要とされます : セキュリティ文書は、セキュリティ設計、リスク分析または問題を明確に記述するために詳細にわたる必要はありません。

===3.ライフサイクル活動===

;(a) リスク識別 : 開発者と顧客は、アプリケーションに直面しているリスクを理解して、文書化するために協力することに同意します。この努力は、アプリケーションにより提供される重要な資産と機能への主要なリスクを確認しなければなりません。要件部にリストされるトピックの各々は、考慮されなければなりません。

;(b) 要求 : リスクに基づいて、開発者と顧客は、開発されるソフトウェアの仕様の一部として詳細なセキュリティ要件を確立するために協力することに同意します。この付属書の要件部分で記載される個々のトピックは、開発者と顧客によって協議されなければならなくて、評価されなければなりません。これらの要件は、カスタム・ソフトウェア、第三者のソフトウェアまたはプラットホームによって満たされてもよいです。

;(c) 設計 : 開発者は、セキュリティ要件の各々を達成するために明確に設計を説明する文書を提供することに同意します。ほとんどの場合、この文書はセキュリティ手法を記載します、そこで、手法はアーキテクチャに適合しました、そして、関連したすべては彼らの適正使用を確実にするためにパターンを設計します。設計は、サポートがカスタム・ソフトか、第三者のソフトウェアかプラットホームから来るかどうか、明確に指定しなければなりません。

;(d) 実装 : 開発者は、一組のセキュアなコーディング指針に提供することに、従って、一組の共通セキュリティ制御プログラミング・インターフェース（例えば [http://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API OWASP Enterprise Security API（ESAPI）] ）を使って同意します。ガイドラインは、コードがどのようにフォーマットされなければならなくて、構築されなければならなくて、コメントされなければならないかについて示します。共通セキュリティ制御プログラミング・インターフェースは、セキュリティ制御がどのように呼ばれなければならないか、そして、セキュリティ制御がどのように機能するか定めます。すべてのセキュリティに関連したコードは、十分に解説されなければなりません。共通のセキュリティ脆弱性を回避するときの具体的なガイダンスが含まれなければなりません。また、すべてのコードはセキュリティ要件に対して少なくとも他の一人の開発者によってレビューされなければなりません、そして、それの前のコーディング・ガイドラインは単体テストの準備ができていると思われます。

;(e) セキュリティ分析とテスト : 開発者は、（ [http://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project OWASP Application Security Verification Standard (ASVS)] のような）合意された標準の検証要件により、アプリケーション・セキュリティ分析とテスト（「検証」とも言われる）を実行します。開発者は、標準の報告要件によって検証結論を文書化しなければなりません。開発者は、検証結論を顧客に提供しなければなりません。

;(f) セキュリティ配備 : 開発者は、ソフトウェアの全体的なセキュリティのために完全にすべてのセキュリティ関連した構成オプションとそれらの関連性を記述するセキュアな構成ガイドラインを提供することに同意します。ガイドラインは、オペレーティングシステム、ウェブサーバとアプリケーション・サーバーを含むサポート的なプラットホームにおける依存関係の完全な記述を含まなければいけません。また、どのようにそれらをセキュリティのために構成されるべきかを含まなければいけません。ソフトウェアのデフォルトコンフィグレーションは、セキュアでなければなりません。

===4.セキュリティ要求エリア===

以下のトピック領域は、リスク理解と要求定義活動の間、考慮されなければなりません。この努力は一組の具体的で、注文仕立てで、分析できる要求を生産しなければなりません。そして、開発者と顧客はこのプロセスに関与していなければならなくて、要求の最終セットについて同意しなければなりません。

;(a) 入力検証とエンコーディング : 要求は、ユーザー、ファイルシステム、データベース、ディレクトリまたは外部システムからであるかどうかにかかわらず、アプリケーションへの各々の入力を標準化し、検証し、コード化するためにルールを指定しなければなりません。　　　デフォルトルールは、それが何が許可されるかという詳細な仕様にマッチしない限り、すべての入力が無効であるということでなければなりません。そのうえ、無効な入力が受け取られるとき、要求はとられる措置を指定しなければなりません。具体的には、アプリケーションはインジェクション、オーバフロー、不正操作することまたは他の不正な入力攻撃に影響されやすくてはいけません。

;(b) 認証とセッション管理 : 要求は、認証証明書とセッション識別子がどのようにそれらのライフサイクルを通して保護されているかについて明記しなければなりません。すべての関連する機能（パスワード忘却、パスワード変更、パスワードリマインダ、ログアウト、そして複数ログインを含む）に対する要求は含められなければいけません。

;(c) アクセス制御 : 要求は、アプリケーションで使われるすべての役割（グループ、特権、認可）の詳細な記述を含まなければなりません。要求は、アプリケーションにより提供されるすべての資産と機能も示さなければなりません。要求は、完全に各々の資産に正確なアクセス権を指定しなければならなくて、各々の役割に対して機能しなければなりません。アクセス制御マトリックスは、これらのルールのための提案されたフォーマットです。

;(d) エラー処理 : 要求は、処理の間、発生しているエラーが取り扱われる方法を詳述しなければなりません。若干のアプリケーションはエラーの場合には最もよい努力結果を提供しなければなりません、一方、他はすぐに処理を終了しなければなりません。

;(e) ロギング : 要求は、どんなイベントがセキュリティに関連して、記録される必要があるか、たとえば、検知された攻撃、失敗したログイン試行、認可を上回ろうとする試行、を指定しなければなりません。要求は、時間と日付、イベント記述、アプリケーション詳細とフォレンジクス努力に役立つ他の情報を含む、各々のイベントでどんな情報を記録するべきかについても指定しなければなりません。

;(f) 外部システムへの接続 : 要求は、認証と暗号化がどのようにすべての外部システム（例えばデータベース、ディレクトリとウェブ・サービス）のために取り扱われるかについて指定しなければなりません。外部システムでコミュニケーションのために必要とされるすべてのクレディンシャルは、暗号化された形で構成ファイルでコードの外側に保存されなければなりません。

;(g) 暗号 : 要求は、どんなデータが暗号化されなければならないか、暗号化されることがどれほどか、そして、すべての証明書と他のクレディンシャルがどのように取り扱われなければならないか指定しなければなりません。アプリケーションは、広く使われていてテストされた暗号化ライブラリで実装される標準的なアルゴリズムを使用しなければなりません。

;(h) 可用性 : 要求は、それがどのようにサービス不能攻撃から保護するかについて指定しなければなりません。アプリケーションへのすべてのありそうな攻撃は考慮されなければなりません。そして、認証ロックアウト、接続消耗と他の資源消耗攻撃を含みます。

;(i) セキュアな設定 : 要求は、すべてのセキュリティに関連した構成オプションに対するデフォルト値がセキュアでなければならないことを示していなければなりません。監査目的のために、ソフトウェアはすべてのセキュリティに関連した構成詳細を示している簡単に読めるレポートをつくることができなければなりません。

;(j) 特定の脆弱性 : 要求は、ソフトウェアで見つかってはならない一組の具体的な脆弱性を含まなければなりません。指定されていないならば、ソフトウェアは現在の「OWASP Top Ten Most Critical Web Application Vulnerabilities」で記述される瑕疵の何も含んではいけません。

===5. 要員および組織===

;(a) セキュリティ・アーキテクト : 開発者は一つの上位の技術的な資源に責任をセキュリティに指定します。そして、プロジェクトのセキュリティ・アーキテクトとして知られています。セキュリティ・アーキテクトは、個々の納品可能なもののセキュリティを保証します。

;(b) セキュリティ・トレーニング : 開発者は、開発者チームのすべてのメンバーがセキュアなプログラミング技法の訓練をされたことを確かめる役割を果たします。

;(c) 信頼できる開発者 : 開発者は、すべての開発チーム・メンバーの適切な経歴調査を実行することに同意します。

===6.開発環境===

;(a) セキュア・コーディング : 開発者は、どんなツールがセキュアなコーディングを促すためにソフトウェア開発環境で使われるかについて明らかにしなければなりません。

;(b) 構成管理 : 開発者は、ソフトウェア・ベースラインに対するすべての変更とすべての関連した設定とビルド・ファイルを関連づけ　とすべての関連した構成にすべての変化と関連したチーム・メンバーを認証して、記録して、ファイルを構築したソース・コード管理システムを使用しなければなりません。

;(c) 配布 : 開発者は、ソースから確実に完全な配布を構築するビルド・プロセスを使用しなければなりません。このプロセスは、顧客に供給されるソフトウェアの完全性を確かめる方法を含まなければなりません。

===7. ライブラリ、フレームワーク、および生産物===

;(a) 開示 : 開発者は、商用、フリー、オープンソース、クローズソースであるにせよ、すべてのライブラリ、フレームワーク、構成要素および他の生産物を含む、ソフトウェアで使われるすべての第三者のソフトウェアを明らかにしなければなりません。

;(b) 評価 : 開発者は、第三者のソフトウェアがこの契約のすべての条項を満たして、この契約のもとで開発されたカスタム開発されたコードと同じくらいセキュアなことを確実とするために、理にかなった努力をしなければなりません。

===8. セキュリティ・レビュー===

;(a) レビューする権利 : 依頼人には、ソフトウェアを納品の60日間以内にいつでも彼らの費用でセキュリティ瑕疵のためにレビューしておく権利があります。開発者は、ソース・コードとテスト環境へのアクセスを提供することによって理にかなったサポートをレビュー・チームに提供することに同意します。

;(b) レビュー・カバレッジ : セキュリティ・レビューは供給されるソフトウェアのすべての面をカバーしなければなりません。そして、カスタム・コード、構成要素、生産物とシステム設定を含みます。

;(c) レビューの範囲 : 最低限で、レビューはセキュリティ要求の全てをカバーしなければならなくて、他の一般的な脆弱性を捜さなければなりません。レビューは、脆弱性スキャン、侵入テスト、ソースコードの静的分析と専門家のコードレビューの組み合わせを含んでもよいです。

;(d) 見つけられた問題 : 発見されたセキュリティ問題は、顧客と開発者に報告されます。すべての問題は、この付属書のセキュリティ問題管理セクションにより追跡されて、矯正されます。

===9. セキュリティ問題管理 ===

;(a) 識別 : 要求、設計、実装、テスト、配備、または、運用中の問題にせよ、開発者は全てのライフサイクルの間に発見されるすべてのセキュリティ問題を追跡します。個々のセキュリティ問題に関連したリスクは、発見後できるだけ早く、評価されて、文書化されて、発見の後、顧客に報告されます。

;(b) 保護 : 開発者はセキュリティ問題と関連する文書に関して情報を適切に保護します。そして、運用中の顧客ソフトウェアの脆弱性が露出するという可能性を制限するのを助けます。

;(c) 改善 : 納品の前に確認されるセキュリティ問題は、開発者によって修正されなければなりません。納品の後に発見されるセキュリティ問題は、本契約の規定に定められたように他のバグや問題と同様に取り扱われなければなりません。

===10. 保証===

;(a) 保証 : 開発者は、開発プロセスを通して作成されるセキュリティ文書からなる「証明パッケージ」を提供します。パッケージは、セキュリティ要求、設計、実装とテスト結果がきちんと完了された、そして、すべてのセキュリティ問題が適切に解決されたと確認しなければなりません。

;(b) 自己証明 : セキュリティ・アーキテクトは、ソフトウェアがセキュリティ要求を満たすこと、すべてのセキュリティ活動が実行されていること、そして、すべての識別されたセキュリティ問題が文書化されて、解決されたことを証明します。証明ステータスに対するあらゆる例外は、納品で完全に文書化されなければなりません。

;(c) 悪意のあるコードのなし : 開発者は、ソフトウェアがソフトウェア要求をサポートせず、コンピュータ・ウイルス、ワーム、時限爆弾、バック・ドア、トロイの木馬、イースターエッグと他のあらゆる形の悪意のあるソフトウェアを含む、アプリケーションのセキュリティを弱めるあらゆるコードを含んではならないと保証します。

===11. セキュリティ承認と保守 ===

;(a) 受入 : 証明パッケージが完全であり、すべてのセキュリティ問題が解決されるまで、ソフトウェアは受け入れられると考慮されてはいけません。

;(b) セキュリティ問題の調査 : 受理の後、セキュリティ問題が発見されるか、かなり疑われるならば、開発者は顧客が問題の性質を決定するために調査を実行するのを援助しなければなりません。それがセキュリティ要求によってカバーされないで、セキュリティ・テストの理にかなった範囲の外にあるならば、問題は「新しい」と思われなければなりません。

;(c) 新しいセキュリティ問題 : 開発者と顧客は、新しいセキュリティ問題を解決するために必要な努力を探し出すことに同意します。また、それらに取り組むために必要とされる仕事を実行するための合意を達成するために誠意を持って交渉することに同意します。

;(d) 他のセキュリティ問題 : 開発者は堅実なソフトウェア開発慣行。そして、リスクのひどさを考慮すること、そして、できるだけ速く新しいと思われないすべてのセキュリティ問題を解決することと一致したすべての商業的に理にかなった努力を使わなければなりません

[[Category:OWASP Legal Project]]

__NOTOC__

OWASP Secure Software Contract Annex/ja

2011-07-06T13:17:39Z

Tomo: /* 10. 保証 */

'''セキュア・ソフトウェア開発契約付属書'''

警告：この文書は、単にガイダンスと考えられなければなりません。
OWASPは、ソフトウェア契約を交渉するのを手助けするために、
あなたが資格のある弁護士に相談するよう強く勧めます。

==序文==

OWASPセキュア・ソフトウェア開発契約付属書は、ソフトウェアの開発者とその顧客が、開発または供給されるソフトウェアのセキュリティに関連した重要な契約条項と条件を交渉し、取り込むことを助けます。このプロジェクトの理由は、多くの契約はこれらの問題に触れておらず、しばしば関係者が実際に同意されたものに劇的に異なる見解を持つことです。私たちは、これらの条項を明確に述べることは、双方の関係者が進め方について情報に基づいた意思決定ができることを確実にするもっともよい方法であると思っています。

「市場がより良いセキュリティを要求するとき、商用ソフトのセキュリティは改善します。
最低限、あらゆるソフトウェア提案依頼書は、ベンダーに彼らがセキュリティ脆弱性に対して
生産物をテストする方法を詳述するよう依頼しなければなりません。このステップは、企業が
セキュリティを評価すると市販ソフトウェアのベンダーと外部調達された開発者を納得させ始めます。」
-- John Pescatore（Gartnerのリサーチ・ディレクター）として

私たちは、顧客と開発者が、期待について議論して、責任について交渉することに対するフレームワークとしてこの文書を使うよう勧めます。この付属書は、ソフトウェア開発契約に添付されることを目的とします。これらの条項は交渉の余地があります。そして、それらは顧客と開発者によって、協議されることができて、協議されなければならないことを意味します。

==プロジェクトについて==

この文書はOpen Web Application Security Project（OWASP）財団（セキュアなソフトウェアに関連した無料でオープンなツールとドキュメンテーションを作成することを専門とする非営利の慈善団体）によって作成されました。個人契約において容易に使用できるようにするために、この文書はCC Share Alike 3.0ライセンスにて提供されます。あなたが適すると思うように、修正してもよいですし、使用してもよいです。あなたは、http://www.owasp.com/index.php/OWASP_Legal_Project でこのプロジェクトについて更なる詳細を見つけることができます。私たちは、ソフトウェア（法律コミュニティだけでなく）の製作者と消費者のコメントを歓迎します。

OWASPは、この文書の研究と準備における彼らの役割に対して [http://www.aspectsecurity.com Aspect Security] から特別な貢献を感謝して認めます。

==異論==

以下のわずかなページは、ソフトウェア開発契約においてこの言い回しを使用することに対するいくらかのたびたび聞こえる異論をカバーします：

===しかし、すべての条項が私たちにとって適切であるというわけではありません…===

この文書は、あなたの合意の開始地点です。あなたは、すべての活動が好きではないかもしれません、または、より多くの提案をしたいかもしれません。あなたは異なる責任を割り当てたいかもしれません。この文書は、すべてのソフトウェア顧客と開発者の要望を厳密に取り込むことを意図しているわけではありません。ソフトウェアが最終的にセキュアになることを確実にするために重要である、主要な項目を議論するためのフレームワークを提供することを意図します。セキュリティを議論して合意を得た後で、あなたはこの合意を適合するように調整すべきです。

===しかし、これらの活動に対して誰が代金を払わなければならないのでしょうか===

この契約は、ソフトウェア開発者により多くの負担を与えることはほとんどありません。問題は、セキュリティ ― もちろんそこにある ― と関連したコストがあるかどうかということでありません。むしろ、適切な問題はどんな活動がそれらのコストを最小にするために双方によって実行されなければならないかということです、そして、いつ、それらは起こらなければなりませんか。

この付属書は、誰がここに記述される活動の料金を払わなければならないかという問題については、意図的に語られていません。これらの活動の多くがすでに起こらなければならなくて、多くの顧客によって期待される一方、それたはソフトウェア産業で定期的に実践されることはありません。誰が（そして、いくら）支払うかという問題が、交渉の一部でなければなりません。

セキュリティのコストを計算することは、非常に難しいです。セキュリティ活動を実行することに関連したコストがある一方、それらを無視することに関連したかなりのコストもあります。私たちは、ソフトウェアを開発する最も費用対効果がよい方法について確信しています。それは、セキュリティ瑕疵が導入されるという可能性を減らして、瑕疵を導入して、それを修正することの間で時間を最小にすることです。

コストを計算するときにする一つの重要な区別は、セキュリティ手法を構築することと、それらの手法が正しくて効果的であることを確実にする保証活動の間にあります。ライフサイクルの終わりに手法を加えようとすることは、深刻な設計問題を引き起こすことがありえて、めざましくコストを増やします。この合意は、手法についての早い段階の決定がこれらのコストを最小にするのを奨励します。同様に、配備直前に保証活動（例えばコードレビューと侵入テスト）をするまで待つことはコストをめざましく増やします。私たちは、保証を得る最も費用効果がよい方法がライフサイクルを通して努力の一定のレベルを保証に入れることであると思っています。

===しかし厳密さのレベルは間違っている….===

この合意は、開発されているソフトウェアが大企業または政府機関にとってかなり重要であると仮定します。私たちは、大部分のソフトウェア開発組織によって達成できる合意のために「厳格さのレベル」を選んで、最も一般的なリスクを確認して、取り扱います。

しかし、重要なアプリケーション（例えば医学であるか、財政的であるか、防衛に関連したソフトウェア）で使われそうであるソフトウェアについては、あなたは厳格さのレベルを上げたいかもしれません。あなたは、追加のレビュー、文書化とテストの活動を加えたくてもよいです。あなたは、脆弱性を探すこと、診断すること、修正することに対するプロセスを強化しくてもよいです。より機密を扱わないアプリケーションのために、あなたは活動を減らすか、取り除きたくてもよいです。

===しかし、私たちはそれほど多くのリスクをとることができない…===

この契約は、ソフトウェアにおけるセキュリティ脆弱性に対するリスクをとるのかという議論を容易にすることを目的とします。範囲の一端では、顧客はすべてのリスクをとることができました、そして、開発者はたくさんの脆弱性をもつコードを供給することができました。他の極端では、開発者はすべてのリスクをとることができて、完全なコードを供給することに対する責任を負うことができました。これらの両極端は、どちらとも実行不可能です。

現在、この契約において、開発者は要求においてカバーされたか、理にかなったテスト努力によってカバーされるべき問題に対するリスクをとります。しかし、「新しい」セキュリティ問題の改善は、顧客によって代金を払われるべきです。私たちは、これが開発者が彼らのリスクの境界となることができて役に立つバランスで、顧客が前もってセキュリティ要求を正しくするのを奨励すると思っています。しかし、この問題の多くの他の可能性がある解決が、あります。あなたには他の提案があるかどうか私たちに知らせます、そして、私たちは彼らをこの文書の将来の版に含めてもよいです。

ここでの議論がコードにおいてセキュリティ脆弱性を修正することに関連したリスクをカバーだけして、これらの脆弱性のあらゆるエクスプロイットに基づくあらゆるセキュリティ・インシデントから立ち直ることと関連したコストを含まないことに注意すべきです。私たちは、この領域におけるベスト・プラクティスに興味があります。

===私たちはどのように第三者のコードを保証するでしょうか===

ほとんどすべてのソフトウェアプロジェクトは、第三者のコード（例えばライブラリ、フレームワークと生産物）のかなりの量を使います。このコードは、ただセキュリティ観点から、カスタム・コードがあなたのプロジェクトのために特に発達したのと同じくらい重要です。
私たちはこのコードのセキュリティを確実にすることに対する責任が開発者によって負われて最もよいと思っています、しかし、彼らにはこのセキュリティを保証するために彼ら自身のいっぱいの能力がないかもしれません。しかし、セキュリティは「構築するか、買うか」議論の一部分でなければなりません、これはそれを促進する最もよい方法のようです。

開発者は、もちろん、終わりまで第三者のソフトウェアの提供者にこの責任をパスする選択権があります。開発者は彼ら自身第三者のコードを分析することもできるか、彼らのためにそれを分析するために、セキュリティの専門家を雇うこともできます。

===しかし、なぜ私はすべてのこのトラブルにいくべきなのでしょうか===

最後に、私たちはソフトウェアを契約しているプロセスの一部分をセキュリティをすることに代わるものがないと思っています。現在では、私たちは多くのソフトウェア開発契約のもとで供給されているコードのセキュリティに関する重大な誤解があると思っています。これは、わずかなソフトウェア経験または理解とともに個人によってなされる高価な訴訟と決定に至ることができるだけです。この問題の完全な議論に対して [[Secure software contracting hypothetical case study]] （[https://www.owasp.org/index.php/Secure_software_contracting_hypothetical_case_study/ja 日本語訳]）を読んでください。

多くの利点が、この契約を通してうまくいくことにあります。主要なものは、それが関係する関係者の間で期待を明らかにするということです。場合によっては、難しいセキュリティ問題がソフトウェアで表面化するとき、それは訴訟を妨げるのを助けます。また、これらは多くの法的で調整するコンプライアンスの理由によって必要とされる同じ活動です。

===しかし、このドキュメントですべてを作ることは難しい===

OWASPは、文書化を目的とした文書化を推奨しません。この契約は品質（量ではない）を促進することに集中します。私たちは、短いリスク評価、数ページの要求、短いセキュリティ設計文書、テストプラン、いくつかのテスト結果とともに、この契約に応じることが（若干のプロジェクトにおいて）ありえると思っています。

この文書の目標は、ライフサイクルの各段階で、単に適切な注意がセキュリティに払われたことを確実とすることです。追加の利点は、この文書が基本的に、このソフトウェアが安心してそれがそれがすると主張することをするのをまかせられなければならない理由に対する議論を配置する「証明パッケージ」をつくるために一緒に集められることができるということです。

==契約付属書==

===1. 序文===

この付属書は、顧客と開発者の間で_____________________ ("合意") するために作られます。顧客と開発者は、以下の条項によりソフトウェアのセキュリティを最大にすることに同意します。

===2. 原理===

この付属書は、ソフトウェア開発関係のすべての関係者のセキュリティ関連の権利と義務をはっきりさせることを目的とします。最高レベルで、関係者は以下に同意します

;(a) セキュリティ決定は、リスクに基づきます : セキュリティについての決定は、関係するリスクのしっかりした理解に基づく顧客と開発者によって共同でなされす。

;(b) セキュリティ活動はバランスが保たれます : セキュリティ努力は、全てのソフトウェア開発ライフサイクル全体でおおよそ均一に配布されます。

;(c) セキュリティ活動は統合されます : ここに協議されるすべての活動と文書は、開発者のソフトウェア開発ライフサイクルに統合されて、残りのプロジェクトと別にしておかれるというわけではありません。この付属書の何も、どんな特定のソフトウェア開発プロセスを意味しません。

;(d) 脆弱性は予想されます : すべてのソフトウェアにはバグがあります、そして、それらのいくらかはセキュリティ問題を生じさせます。顧客と開発者は、ライフサイクルにおいてできるだけ早く脆弱性を特定するよう努めます。

;(e) セキュリティ情報は完全に明らかにされます : すべてのセキュリティ関連した情報は、すぐに、そして、完全に、顧客と開発者で共有されます。

;(f) 役に立つセキュリティ文書だけが必要とされます : セキュリティ文書は、セキュリティ設計、リスク分析または問題を明確に記述するために詳細にわたる必要はありません。

===3.ライフサイクル活動===

;(a) リスク識別 : 開発者と顧客は、アプリケーションに直面しているリスクを理解して、文書化するために協力することに同意します。この努力は、アプリケーションにより提供される重要な資産と機能への主要なリスクを確認しなければなりません。要件部にリストされるトピックの各々は、考慮されなければなりません。

;(b) 要求 : リスクに基づいて、開発者と顧客は、開発されるソフトウェアの仕様の一部として詳細なセキュリティ要件を確立するために協力することに同意します。この付属書の要件部分で記載される個々のトピックは、開発者と顧客によって協議されなければならなくて、評価されなければなりません。これらの要件は、カスタム・ソフトウェア、第三者のソフトウェアまたはプラットホームによって満たされてもよいです。

;(c) 設計 : 開発者は、セキュリティ要件の各々を達成するために明確に設計を説明する文書を提供することに同意します。ほとんどの場合、この文書はセキュリティ手法を記載します、そこで、手法はアーキテクチャに適合しました、そして、関連したすべては彼らの適正使用を確実にするためにパターンを設計します。設計は、サポートがカスタム・ソフトか、第三者のソフトウェアかプラットホームから来るかどうか、明確に指定しなければなりません。

;(d) 実装 : 開発者は、一組のセキュアなコーディング指針に提供することに、従って、一組の共通セキュリティ制御プログラミング・インターフェース（例えば [http://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API OWASP Enterprise Security API（ESAPI）] ）を使って同意します。ガイドラインは、コードがどのようにフォーマットされなければならなくて、構築されなければならなくて、コメントされなければならないかについて示します。共通セキュリティ制御プログラミング・インターフェースは、セキュリティ制御がどのように呼ばれなければならないか、そして、セキュリティ制御がどのように機能するか定めます。すべてのセキュリティに関連したコードは、十分に解説されなければなりません。共通のセキュリティ脆弱性を回避するときの具体的なガイダンスが含まれなければなりません。また、すべてのコードはセキュリティ要件に対して少なくとも他の一人の開発者によってレビューされなければなりません、そして、それの前のコーディング・ガイドラインは単体テストの準備ができていると思われます。

;(e) セキュリティ分析とテスト : 開発者は、（ [http://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project OWASP Application Security Verification Standard (ASVS)] のような）合意された標準の検証要件により、アプリケーション・セキュリティ分析とテスト（「検証」とも言われる）を実行します。開発者は、標準の報告要件によって検証結論を文書化しなければなりません。開発者は、検証結論を顧客に提供しなければなりません。

;(f) セキュリティ配備 : 開発者は、ソフトウェアの全体的なセキュリティのために完全にすべてのセキュリティ関連した構成オプションとそれらの関連性を記述するセキュアな構成ガイドラインを提供することに同意します。ガイドラインは、オペレーティングシステム、ウェブサーバとアプリケーション・サーバーを含むサポート的なプラットホームにおける依存関係の完全な記述を含まなければいけません。また、どのようにそれらをセキュリティのために構成されるべきかを含まなければいけません。ソフトウェアのデフォルトコンフィグレーションは、セキュアでなければなりません。

===4.セキュリティ要求エリア===

以下のトピック領域は、リスク理解と要求定義活動の間、考慮されなければなりません。この努力は一組の具体的で、注文仕立てで、分析できる要求を生産しなければなりません。そして、開発者と顧客はこのプロセスに関与していなければならなくて、要求の最終セットについて同意しなければなりません。

;(a) 入力検証とエンコーディング : 要求は、ユーザー、ファイルシステム、データベース、ディレクトリまたは外部システムからであるかどうかにかかわらず、アプリケーションへの各々の入力を標準化し、検証し、コード化するためにルールを指定しなければなりません。　　　デフォルトルールは、それが何が許可されるかという詳細な仕様にマッチしない限り、すべての入力が無効であるということでなければなりません。そのうえ、無効な入力が受け取られるとき、要求はとられる措置を指定しなければなりません。具体的には、アプリケーションはインジェクション、オーバフロー、不正操作することまたは他の不正な入力攻撃に影響されやすくてはいけません。

;(b) 認証とセッション管理 : 要求は、認証証明書とセッション識別子がどのようにそれらのライフサイクルを通して保護されているかについて明記しなければなりません。すべての関連する機能（パスワード忘却、パスワード変更、パスワードリマインダ、ログアウト、そして複数ログインを含む）に対する要求は含められなければいけません。

;(c) アクセス制御 : 要求は、アプリケーションで使われるすべての役割（グループ、特権、認可）の詳細な記述を含まなければなりません。要求は、アプリケーションにより提供されるすべての資産と機能も示さなければなりません。要求は、完全に各々の資産に正確なアクセス権を指定しなければならなくて、各々の役割に対して機能しなければなりません。アクセス制御マトリックスは、これらのルールのための提案されたフォーマットです。

;(d) エラー処理 : 要求は、処理の間、発生しているエラーが取り扱われる方法を詳述しなければなりません。若干のアプリケーションはエラーの場合には最もよい努力結果を提供しなければなりません、一方、他はすぐに処理を終了しなければなりません。

;(e) ロギング : 要求は、どんなイベントがセキュリティに関連して、記録される必要があるか、たとえば、検知された攻撃、失敗したログイン試行、認可を上回ろうとする試行、を指定しなければなりません。要求は、時間と日付、イベント記述、アプリケーション詳細とフォレンジクス努力に役立つ他の情報を含む、各々のイベントでどんな情報を記録するべきかについても指定しなければなりません。

;(f) 外部システムへの接続 : 要求は、認証と暗号化がどのようにすべての外部システム（例えばデータベース、ディレクトリとウェブ・サービス）のために取り扱われるかについて指定しなければなりません。外部システムでコミュニケーションのために必要とされるすべてのクレディンシャルは、暗号化された形で構成ファイルでコードの外側に保存されなければなりません。

;(g) 暗号 : 要求は、どんなデータが暗号化されなければならないか、暗号化されることがどれほどか、そして、すべての証明書と他のクレディンシャルがどのように取り扱われなければならないか指定しなければなりません。アプリケーションは、広く使われていてテストされた暗号化ライブラリで実装される標準的なアルゴリズムを使用しなければなりません。

;(h) 可用性 : 要求は、それがどのようにサービス不能攻撃から保護するかについて指定しなければなりません。アプリケーションへのすべてのありそうな攻撃は考慮されなければなりません。そして、認証ロックアウト、接続消耗と他の資源消耗攻撃を含みます。

;(i) セキュアな設定 : 要求は、すべてのセキュリティに関連した構成オプションに対するデフォルト値がセキュアでなければならないことを示していなければなりません。監査目的のために、ソフトウェアはすべてのセキュリティに関連した構成詳細を示している簡単に読めるレポートをつくることができなければなりません。

;(j) 特定の脆弱性 : 要求は、ソフトウェアで見つかってはならない一組の具体的な脆弱性を含まなければなりません。指定されていないならば、ソフトウェアは現在の「OWASP Top Ten Most Critical Web Application Vulnerabilities」で記述される瑕疵の何も含んではいけません。

===5. 要員および組織===

;(a) セキュリティ・アーキテクト : 開発者は一つの上位の技術的な資源に責任をセキュリティに指定します。そして、プロジェクトのセキュリティ・アーキテクトとして知られています。セキュリティ・アーキテクトは、個々の納品可能なもののセキュリティを保証します。

;(b) セキュリティ・トレーニング : 開発者は、開発者チームのすべてのメンバーがセキュアなプログラミング技法の訓練をされたことを確かめる役割を果たします。

;(c) 信頼できる開発者 : 開発者は、すべての開発チーム・メンバーの適切な経歴調査を実行することに同意します。

===6.開発環境===

;(a) セキュア・コーディング : 開発者は、どんなツールがセキュアなコーディングを促すためにソフトウェア開発環境で使われるかについて明らかにしなければなりません。

;(b) 構成管理 : 開発者は、ソフトウェア・ベースラインに対するすべての変更とすべての関連した設定とビルド・ファイルを関連づけ　とすべての関連した構成にすべての変化と関連したチーム・メンバーを認証して、記録して、ファイルを構築したソース・コード管理システムを使用しなければなりません。

;(c) 配布 : 開発者は、ソースから確実に完全な配布を構築するビルド・プロセスを使用しなければなりません。このプロセスは、顧客に供給されるソフトウェアの完全性を確かめる方法を含まなければなりません。

===7. ライブラリ、フレームワーク、および生産物===

;(a) 開示 : 開発者は、商用、フリー、オープンソース、クローズソースであるにせよ、すべてのライブラリ、フレームワーク、構成要素および他の生産物を含む、ソフトウェアで使われるすべての第三者のソフトウェアを明らかにしなければなりません。

;(b) 評価 : 開発者は、第三者のソフトウェアがこの契約のすべての条項を満たして、この契約のもとで開発されたカスタム開発されたコードと同じくらいセキュアなことを確実とするために、理にかなった努力をしなければなりません。

===8. セキュリティ・レビュー===

;(a) レビューする権利 : 依頼人には、ソフトウェアを納品の60日間以内にいつでも彼らの費用でセキュリティ瑕疵のためにレビューしておく権利があります。開発者は、ソース・コードとテスト環境へのアクセスを提供することによって理にかなったサポートをレビュー・チームに提供することに同意します。

;(b) レビュー・カバレッジ : セキュリティ・レビューは供給されるソフトウェアのすべての面をカバーしなければなりません。そして、カスタム・コード、構成要素、生産物とシステム設定を含みます。

;(c) レビューの範囲 : 最低限で、レビューはセキュリティ要求の全てをカバーしなければならなくて、他の一般的な脆弱性を捜さなければなりません。レビューは、脆弱性スキャン、侵入テスト、ソースコードの静的分析と専門家のコードレビューの組み合わせを含んでもよいです。

;(d) 見つけられた問題 : 発見されたセキュリティ問題は、顧客と開発者に報告されます。すべての問題は、この付属書のセキュリティ問題管理セクションにより追跡されて、矯正されます。

===9. セキュリティ問題管理 ===

;(a) 識別 : 要求、設計、実装、テスト、配備、または、運用中の問題にせよ、開発者は全てのライフサイクルの間に発見されるすべてのセキュリティ問題を追跡します。個々のセキュリティ問題に関連したリスクは、発見後できるだけ早く、評価されて、文書化されて、発見の後、顧客に報告されます。

;(b) 保護 : 開発者はセキュリティ問題と関連する文書に関して情報を適切に保護します。そして、運用中の顧客ソフトウェアの脆弱性が露出するという可能性を制限するのを助けます。

;(c) 改善 : 納品の前に確認されるセキュリティ問題は、開発者によって修正されなければなりません。納品の後に発見されるセキュリティ問題は、本契約の規定に定められたように他のバグや問題と同様に取り扱われなければなりません。

===10. 保証===

;(a) 保証 : 開発者は、開発プロセスを通して作成されるセキュリティ文書からなる「証明パッケージ」を提供します。パッケージは、セキュリティ要求、設計、実装とテスト結果がきちんと完了された、そして、すべてのセキュリティ問題が適切に解決されたと確認しなければなりません。

;(b) 自己証明 : セキュリティ・アーキテクトは、ソフトウェアがセキュリティ要求を満たすこと、すべてのセキュリティ活動が実行されていること、そして、すべての識別されたセキュリティ問題が文書化されて、解決されたことを証明します。証明ステータスに対するあらゆる例外は、納品で完全に文書化されなければなりません。

;(c) 悪意のあるコードのなし : 開発者は、ソフトウェアがソフトウェア要求をサポートせず、コンピュータ・ウイルス、ワーム、時限爆弾、バック・ドア、トロイの木馬、イースターエッグと他のあらゆる形の悪意のあるソフトウェアを含む、アプリケーションのセキュリティを弱めるあらゆるコードを含んではならないと保証します。

===11. セキュリティ承認と保守 ===

;(a) 受け入れ : 証明パッケージが完全であり、すべてのセキュリティ問題が解決されるまで、ソフトウェアは受け入れられると考慮されてはいけません。

;(b) セキュリティ問題の調査 : 受理の後、セキュリティ問題が発見されるか、かなり疑われるならば、開発者は顧客が問題の性質を決定するために調査を実行するのを援助しなければなりません。それがセキュリティ要求によってカバーされないで、セキュリティ・テストの理にかなった範囲の外にあるならば、問題は「新しい」と思われなければなりません。

;(c) 新しいセキュリティ問題 : 開発者と顧客は、新しいセキュリティ問題を解決するために必要な努力を探し出すことに同意します。また、それらに取り組むために必要とされる仕事を実行するための合意を達成するために誠意を持って交渉することに同意します。

;(d) 他のセキュリティ問題 : 開発者は堅実なソフトウェア開発慣行。そして、リスクのひどさを考慮すること、そして、できるだけ速く新しいと思われないすべてのセキュリティ問題を解決することと一致したすべての商業的に理にかなった努力を使わなければなりません

[[Category:OWASP Legal Project]]

__NOTOC__

OWASP Secure Software Contract Annex/ja

2011-07-06T13:16:35Z

Tomo: /* 9. セキュリティ問題管理 */

'''セキュア・ソフトウェア開発契約付属書'''

警告：この文書は、単にガイダンスと考えられなければなりません。
OWASPは、ソフトウェア契約を交渉するのを手助けするために、
あなたが資格のある弁護士に相談するよう強く勧めます。

==序文==

OWASPセキュア・ソフトウェア開発契約付属書は、ソフトウェアの開発者とその顧客が、開発または供給されるソフトウェアのセキュリティに関連した重要な契約条項と条件を交渉し、取り込むことを助けます。このプロジェクトの理由は、多くの契約はこれらの問題に触れておらず、しばしば関係者が実際に同意されたものに劇的に異なる見解を持つことです。私たちは、これらの条項を明確に述べることは、双方の関係者が進め方について情報に基づいた意思決定ができることを確実にするもっともよい方法であると思っています。

「市場がより良いセキュリティを要求するとき、商用ソフトのセキュリティは改善します。
最低限、あらゆるソフトウェア提案依頼書は、ベンダーに彼らがセキュリティ脆弱性に対して
生産物をテストする方法を詳述するよう依頼しなければなりません。このステップは、企業が
セキュリティを評価すると市販ソフトウェアのベンダーと外部調達された開発者を納得させ始めます。」
-- John Pescatore（Gartnerのリサーチ・ディレクター）として

私たちは、顧客と開発者が、期待について議論して、責任について交渉することに対するフレームワークとしてこの文書を使うよう勧めます。この付属書は、ソフトウェア開発契約に添付されることを目的とします。これらの条項は交渉の余地があります。そして、それらは顧客と開発者によって、協議されることができて、協議されなければならないことを意味します。

==プロジェクトについて==

この文書はOpen Web Application Security Project（OWASP）財団（セキュアなソフトウェアに関連した無料でオープンなツールとドキュメンテーションを作成することを専門とする非営利の慈善団体）によって作成されました。個人契約において容易に使用できるようにするために、この文書はCC Share Alike 3.0ライセンスにて提供されます。あなたが適すると思うように、修正してもよいですし、使用してもよいです。あなたは、http://www.owasp.com/index.php/OWASP_Legal_Project でこのプロジェクトについて更なる詳細を見つけることができます。私たちは、ソフトウェア（法律コミュニティだけでなく）の製作者と消費者のコメントを歓迎します。

OWASPは、この文書の研究と準備における彼らの役割に対して [http://www.aspectsecurity.com Aspect Security] から特別な貢献を感謝して認めます。

==異論==

以下のわずかなページは、ソフトウェア開発契約においてこの言い回しを使用することに対するいくらかのたびたび聞こえる異論をカバーします：

===しかし、すべての条項が私たちにとって適切であるというわけではありません…===

この文書は、あなたの合意の開始地点です。あなたは、すべての活動が好きではないかもしれません、または、より多くの提案をしたいかもしれません。あなたは異なる責任を割り当てたいかもしれません。この文書は、すべてのソフトウェア顧客と開発者の要望を厳密に取り込むことを意図しているわけではありません。ソフトウェアが最終的にセキュアになることを確実にするために重要である、主要な項目を議論するためのフレームワークを提供することを意図します。セキュリティを議論して合意を得た後で、あなたはこの合意を適合するように調整すべきです。

===しかし、これらの活動に対して誰が代金を払わなければならないのでしょうか===

この契約は、ソフトウェア開発者により多くの負担を与えることはほとんどありません。問題は、セキュリティ ― もちろんそこにある ― と関連したコストがあるかどうかということでありません。むしろ、適切な問題はどんな活動がそれらのコストを最小にするために双方によって実行されなければならないかということです、そして、いつ、それらは起こらなければなりませんか。

この付属書は、誰がここに記述される活動の料金を払わなければならないかという問題については、意図的に語られていません。これらの活動の多くがすでに起こらなければならなくて、多くの顧客によって期待される一方、それたはソフトウェア産業で定期的に実践されることはありません。誰が（そして、いくら）支払うかという問題が、交渉の一部でなければなりません。

セキュリティのコストを計算することは、非常に難しいです。セキュリティ活動を実行することに関連したコストがある一方、それらを無視することに関連したかなりのコストもあります。私たちは、ソフトウェアを開発する最も費用対効果がよい方法について確信しています。それは、セキュリティ瑕疵が導入されるという可能性を減らして、瑕疵を導入して、それを修正することの間で時間を最小にすることです。

コストを計算するときにする一つの重要な区別は、セキュリティ手法を構築することと、それらの手法が正しくて効果的であることを確実にする保証活動の間にあります。ライフサイクルの終わりに手法を加えようとすることは、深刻な設計問題を引き起こすことがありえて、めざましくコストを増やします。この合意は、手法についての早い段階の決定がこれらのコストを最小にするのを奨励します。同様に、配備直前に保証活動（例えばコードレビューと侵入テスト）をするまで待つことはコストをめざましく増やします。私たちは、保証を得る最も費用効果がよい方法がライフサイクルを通して努力の一定のレベルを保証に入れることであると思っています。

===しかし厳密さのレベルは間違っている….===

この合意は、開発されているソフトウェアが大企業または政府機関にとってかなり重要であると仮定します。私たちは、大部分のソフトウェア開発組織によって達成できる合意のために「厳格さのレベル」を選んで、最も一般的なリスクを確認して、取り扱います。

しかし、重要なアプリケーション（例えば医学であるか、財政的であるか、防衛に関連したソフトウェア）で使われそうであるソフトウェアについては、あなたは厳格さのレベルを上げたいかもしれません。あなたは、追加のレビュー、文書化とテストの活動を加えたくてもよいです。あなたは、脆弱性を探すこと、診断すること、修正することに対するプロセスを強化しくてもよいです。より機密を扱わないアプリケーションのために、あなたは活動を減らすか、取り除きたくてもよいです。

===しかし、私たちはそれほど多くのリスクをとることができない…===

この契約は、ソフトウェアにおけるセキュリティ脆弱性に対するリスクをとるのかという議論を容易にすることを目的とします。範囲の一端では、顧客はすべてのリスクをとることができました、そして、開発者はたくさんの脆弱性をもつコードを供給することができました。他の極端では、開発者はすべてのリスクをとることができて、完全なコードを供給することに対する責任を負うことができました。これらの両極端は、どちらとも実行不可能です。

現在、この契約において、開発者は要求においてカバーされたか、理にかなったテスト努力によってカバーされるべき問題に対するリスクをとります。しかし、「新しい」セキュリティ問題の改善は、顧客によって代金を払われるべきです。私たちは、これが開発者が彼らのリスクの境界となることができて役に立つバランスで、顧客が前もってセキュリティ要求を正しくするのを奨励すると思っています。しかし、この問題の多くの他の可能性がある解決が、あります。あなたには他の提案があるかどうか私たちに知らせます、そして、私たちは彼らをこの文書の将来の版に含めてもよいです。

ここでの議論がコードにおいてセキュリティ脆弱性を修正することに関連したリスクをカバーだけして、これらの脆弱性のあらゆるエクスプロイットに基づくあらゆるセキュリティ・インシデントから立ち直ることと関連したコストを含まないことに注意すべきです。私たちは、この領域におけるベスト・プラクティスに興味があります。

===私たちはどのように第三者のコードを保証するでしょうか===

ほとんどすべてのソフトウェアプロジェクトは、第三者のコード（例えばライブラリ、フレームワークと生産物）のかなりの量を使います。このコードは、ただセキュリティ観点から、カスタム・コードがあなたのプロジェクトのために特に発達したのと同じくらい重要です。
私たちはこのコードのセキュリティを確実にすることに対する責任が開発者によって負われて最もよいと思っています、しかし、彼らにはこのセキュリティを保証するために彼ら自身のいっぱいの能力がないかもしれません。しかし、セキュリティは「構築するか、買うか」議論の一部分でなければなりません、これはそれを促進する最もよい方法のようです。

開発者は、もちろん、終わりまで第三者のソフトウェアの提供者にこの責任をパスする選択権があります。開発者は彼ら自身第三者のコードを分析することもできるか、彼らのためにそれを分析するために、セキュリティの専門家を雇うこともできます。

===しかし、なぜ私はすべてのこのトラブルにいくべきなのでしょうか===

最後に、私たちはソフトウェアを契約しているプロセスの一部分をセキュリティをすることに代わるものがないと思っています。現在では、私たちは多くのソフトウェア開発契約のもとで供給されているコードのセキュリティに関する重大な誤解があると思っています。これは、わずかなソフトウェア経験または理解とともに個人によってなされる高価な訴訟と決定に至ることができるだけです。この問題の完全な議論に対して [[Secure software contracting hypothetical case study]] （[https://www.owasp.org/index.php/Secure_software_contracting_hypothetical_case_study/ja 日本語訳]）を読んでください。

多くの利点が、この契約を通してうまくいくことにあります。主要なものは、それが関係する関係者の間で期待を明らかにするということです。場合によっては、難しいセキュリティ問題がソフトウェアで表面化するとき、それは訴訟を妨げるのを助けます。また、これらは多くの法的で調整するコンプライアンスの理由によって必要とされる同じ活動です。

===しかし、このドキュメントですべてを作ることは難しい===

OWASPは、文書化を目的とした文書化を推奨しません。この契約は品質（量ではない）を促進することに集中します。私たちは、短いリスク評価、数ページの要求、短いセキュリティ設計文書、テストプラン、いくつかのテスト結果とともに、この契約に応じることが（若干のプロジェクトにおいて）ありえると思っています。

この文書の目標は、ライフサイクルの各段階で、単に適切な注意がセキュリティに払われたことを確実とすることです。追加の利点は、この文書が基本的に、このソフトウェアが安心してそれがそれがすると主張することをするのをまかせられなければならない理由に対する議論を配置する「証明パッケージ」をつくるために一緒に集められることができるということです。

==契約付属書==

===1. 序文===

この付属書は、顧客と開発者の間で_____________________ ("合意") するために作られます。顧客と開発者は、以下の条項によりソフトウェアのセキュリティを最大にすることに同意します。

===2. 原理===

この付属書は、ソフトウェア開発関係のすべての関係者のセキュリティ関連の権利と義務をはっきりさせることを目的とします。最高レベルで、関係者は以下に同意します

;(a) セキュリティ決定は、リスクに基づきます : セキュリティについての決定は、関係するリスクのしっかりした理解に基づく顧客と開発者によって共同でなされす。

;(b) セキュリティ活動はバランスが保たれます : セキュリティ努力は、全てのソフトウェア開発ライフサイクル全体でおおよそ均一に配布されます。

;(c) セキュリティ活動は統合されます : ここに協議されるすべての活動と文書は、開発者のソフトウェア開発ライフサイクルに統合されて、残りのプロジェクトと別にしておかれるというわけではありません。この付属書の何も、どんな特定のソフトウェア開発プロセスを意味しません。

;(d) 脆弱性は予想されます : すべてのソフトウェアにはバグがあります、そして、それらのいくらかはセキュリティ問題を生じさせます。顧客と開発者は、ライフサイクルにおいてできるだけ早く脆弱性を特定するよう努めます。

;(e) セキュリティ情報は完全に明らかにされます : すべてのセキュリティ関連した情報は、すぐに、そして、完全に、顧客と開発者で共有されます。

;(f) 役に立つセキュリティ文書だけが必要とされます : セキュリティ文書は、セキュリティ設計、リスク分析または問題を明確に記述するために詳細にわたる必要はありません。

===3.ライフサイクル活動===

;(a) リスク識別 : 開発者と顧客は、アプリケーションに直面しているリスクを理解して、文書化するために協力することに同意します。この努力は、アプリケーションにより提供される重要な資産と機能への主要なリスクを確認しなければなりません。要件部にリストされるトピックの各々は、考慮されなければなりません。

;(b) 要求 : リスクに基づいて、開発者と顧客は、開発されるソフトウェアの仕様の一部として詳細なセキュリティ要件を確立するために協力することに同意します。この付属書の要件部分で記載される個々のトピックは、開発者と顧客によって協議されなければならなくて、評価されなければなりません。これらの要件は、カスタム・ソフトウェア、第三者のソフトウェアまたはプラットホームによって満たされてもよいです。

;(c) 設計 : 開発者は、セキュリティ要件の各々を達成するために明確に設計を説明する文書を提供することに同意します。ほとんどの場合、この文書はセキュリティ手法を記載します、そこで、手法はアーキテクチャに適合しました、そして、関連したすべては彼らの適正使用を確実にするためにパターンを設計します。設計は、サポートがカスタム・ソフトか、第三者のソフトウェアかプラットホームから来るかどうか、明確に指定しなければなりません。

;(d) 実装 : 開発者は、一組のセキュアなコーディング指針に提供することに、従って、一組の共通セキュリティ制御プログラミング・インターフェース（例えば [http://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API OWASP Enterprise Security API（ESAPI）] ）を使って同意します。ガイドラインは、コードがどのようにフォーマットされなければならなくて、構築されなければならなくて、コメントされなければならないかについて示します。共通セキュリティ制御プログラミング・インターフェースは、セキュリティ制御がどのように呼ばれなければならないか、そして、セキュリティ制御がどのように機能するか定めます。すべてのセキュリティに関連したコードは、十分に解説されなければなりません。共通のセキュリティ脆弱性を回避するときの具体的なガイダンスが含まれなければなりません。また、すべてのコードはセキュリティ要件に対して少なくとも他の一人の開発者によってレビューされなければなりません、そして、それの前のコーディング・ガイドラインは単体テストの準備ができていると思われます。

;(e) セキュリティ分析とテスト : 開発者は、（ [http://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project OWASP Application Security Verification Standard (ASVS)] のような）合意された標準の検証要件により、アプリケーション・セキュリティ分析とテスト（「検証」とも言われる）を実行します。開発者は、標準の報告要件によって検証結論を文書化しなければなりません。開発者は、検証結論を顧客に提供しなければなりません。

;(f) セキュリティ配備 : 開発者は、ソフトウェアの全体的なセキュリティのために完全にすべてのセキュリティ関連した構成オプションとそれらの関連性を記述するセキュアな構成ガイドラインを提供することに同意します。ガイドラインは、オペレーティングシステム、ウェブサーバとアプリケーション・サーバーを含むサポート的なプラットホームにおける依存関係の完全な記述を含まなければいけません。また、どのようにそれらをセキュリティのために構成されるべきかを含まなければいけません。ソフトウェアのデフォルトコンフィグレーションは、セキュアでなければなりません。

===4.セキュリティ要求エリア===

以下のトピック領域は、リスク理解と要求定義活動の間、考慮されなければなりません。この努力は一組の具体的で、注文仕立てで、分析できる要求を生産しなければなりません。そして、開発者と顧客はこのプロセスに関与していなければならなくて、要求の最終セットについて同意しなければなりません。

;(a) 入力検証とエンコーディング : 要求は、ユーザー、ファイルシステム、データベース、ディレクトリまたは外部システムからであるかどうかにかかわらず、アプリケーションへの各々の入力を標準化し、検証し、コード化するためにルールを指定しなければなりません。　　　デフォルトルールは、それが何が許可されるかという詳細な仕様にマッチしない限り、すべての入力が無効であるということでなければなりません。そのうえ、無効な入力が受け取られるとき、要求はとられる措置を指定しなければなりません。具体的には、アプリケーションはインジェクション、オーバフロー、不正操作することまたは他の不正な入力攻撃に影響されやすくてはいけません。

;(b) 認証とセッション管理 : 要求は、認証証明書とセッション識別子がどのようにそれらのライフサイクルを通して保護されているかについて明記しなければなりません。すべての関連する機能（パスワード忘却、パスワード変更、パスワードリマインダ、ログアウト、そして複数ログインを含む）に対する要求は含められなければいけません。

;(c) アクセス制御 : 要求は、アプリケーションで使われるすべての役割（グループ、特権、認可）の詳細な記述を含まなければなりません。要求は、アプリケーションにより提供されるすべての資産と機能も示さなければなりません。要求は、完全に各々の資産に正確なアクセス権を指定しなければならなくて、各々の役割に対して機能しなければなりません。アクセス制御マトリックスは、これらのルールのための提案されたフォーマットです。

;(d) エラー処理 : 要求は、処理の間、発生しているエラーが取り扱われる方法を詳述しなければなりません。若干のアプリケーションはエラーの場合には最もよい努力結果を提供しなければなりません、一方、他はすぐに処理を終了しなければなりません。

;(e) ロギング : 要求は、どんなイベントがセキュリティに関連して、記録される必要があるか、たとえば、検知された攻撃、失敗したログイン試行、認可を上回ろうとする試行、を指定しなければなりません。要求は、時間と日付、イベント記述、アプリケーション詳細とフォレンジクス努力に役立つ他の情報を含む、各々のイベントでどんな情報を記録するべきかについても指定しなければなりません。

;(f) 外部システムへの接続 : 要求は、認証と暗号化がどのようにすべての外部システム（例えばデータベース、ディレクトリとウェブ・サービス）のために取り扱われるかについて指定しなければなりません。外部システムでコミュニケーションのために必要とされるすべてのクレディンシャルは、暗号化された形で構成ファイルでコードの外側に保存されなければなりません。

;(g) 暗号 : 要求は、どんなデータが暗号化されなければならないか、暗号化されることがどれほどか、そして、すべての証明書と他のクレディンシャルがどのように取り扱われなければならないか指定しなければなりません。アプリケーションは、広く使われていてテストされた暗号化ライブラリで実装される標準的なアルゴリズムを使用しなければなりません。

;(h) 可用性 : 要求は、それがどのようにサービス不能攻撃から保護するかについて指定しなければなりません。アプリケーションへのすべてのありそうな攻撃は考慮されなければなりません。そして、認証ロックアウト、接続消耗と他の資源消耗攻撃を含みます。

;(i) セキュアな設定 : 要求は、すべてのセキュリティに関連した構成オプションに対するデフォルト値がセキュアでなければならないことを示していなければなりません。監査目的のために、ソフトウェアはすべてのセキュリティに関連した構成詳細を示している簡単に読めるレポートをつくることができなければなりません。

;(j) 特定の脆弱性 : 要求は、ソフトウェアで見つかってはならない一組の具体的な脆弱性を含まなければなりません。指定されていないならば、ソフトウェアは現在の「OWASP Top Ten Most Critical Web Application Vulnerabilities」で記述される瑕疵の何も含んではいけません。

===5. 要員および組織===

;(a) セキュリティ・アーキテクト : 開発者は一つの上位の技術的な資源に責任をセキュリティに指定します。そして、プロジェクトのセキュリティ・アーキテクトとして知られています。セキュリティ・アーキテクトは、個々の納品可能なもののセキュリティを保証します。

;(b) セキュリティ・トレーニング : 開発者は、開発者チームのすべてのメンバーがセキュアなプログラミング技法の訓練をされたことを確かめる役割を果たします。

;(c) 信頼できる開発者 : 開発者は、すべての開発チーム・メンバーの適切な経歴調査を実行することに同意します。

===6.開発環境===

;(a) セキュア・コーディング : 開発者は、どんなツールがセキュアなコーディングを促すためにソフトウェア開発環境で使われるかについて明らかにしなければなりません。

;(b) 構成管理 : 開発者は、ソフトウェア・ベースラインに対するすべての変更とすべての関連した設定とビルド・ファイルを関連づけ　とすべての関連した構成にすべての変化と関連したチーム・メンバーを認証して、記録して、ファイルを構築したソース・コード管理システムを使用しなければなりません。

;(c) 配布 : 開発者は、ソースから確実に完全な配布を構築するビルド・プロセスを使用しなければなりません。このプロセスは、顧客に供給されるソフトウェアの完全性を確かめる方法を含まなければなりません。

===7. ライブラリ、フレームワーク、および生産物===

;(a) 開示 : 開発者は、商用、フリー、オープンソース、クローズソースであるにせよ、すべてのライブラリ、フレームワーク、構成要素および他の生産物を含む、ソフトウェアで使われるすべての第三者のソフトウェアを明らかにしなければなりません。

;(b) 評価 : 開発者は、第三者のソフトウェアがこの契約のすべての条項を満たして、この契約のもとで開発されたカスタム開発されたコードと同じくらいセキュアなことを確実とするために、理にかなった努力をしなければなりません。

===8. セキュリティ・レビュー===

;(a) レビューする権利 : 依頼人には、ソフトウェアを納品の60日間以内にいつでも彼らの費用でセキュリティ瑕疵のためにレビューしておく権利があります。開発者は、ソース・コードとテスト環境へのアクセスを提供することによって理にかなったサポートをレビュー・チームに提供することに同意します。

;(b) レビュー・カバレッジ : セキュリティ・レビューは供給されるソフトウェアのすべての面をカバーしなければなりません。そして、カスタム・コード、構成要素、生産物とシステム設定を含みます。

;(c) レビューの範囲 : 最低限で、レビューはセキュリティ要求の全てをカバーしなければならなくて、他の一般的な脆弱性を捜さなければなりません。レビューは、脆弱性スキャン、侵入テスト、ソースコードの静的分析と専門家のコードレビューの組み合わせを含んでもよいです。

;(d) 見つけられた問題 : 発見されたセキュリティ問題は、顧客と開発者に報告されます。すべての問題は、この付属書のセキュリティ問題管理セクションにより追跡されて、矯正されます。

===9. セキュリティ問題管理 ===

;(a) 識別 : 要求、設計、実装、テスト、配備、または、運用中の問題にせよ、開発者は全てのライフサイクルの間に発見されるすべてのセキュリティ問題を追跡します。個々のセキュリティ問題に関連したリスクは、発見後できるだけ早く、評価されて、文書化されて、発見の後、顧客に報告されます。

;(b) 保護 : 開発者はセキュリティ問題と関連する文書に関して情報を適切に保護します。そして、運用中の顧客ソフトウェアの脆弱性が露出するという可能性を制限するのを助けます。

;(c) 改善 : 納品の前に確認されるセキュリティ問題は、開発者によって修正されなければなりません。納品の後に発見されるセキュリティ問題は、本契約の規定に定められたように他のバグや問題と同様に取り扱われなければなりません。

===10. 保証===

;(a) 保証 : 開発者は、開発プロセスを通して作成されるセキュリティ文書からなる「証明パッケージ」を提供します。パッケージは、セキュリティ要求、設計、実装と試験結果がきちんと完了された、そして、すべてのセキュリティ問題が適切に解決されたと確認しなければなりません。

;(b) 自己証明 : セキュリティ・アーキテクトは、ソフトウェアがセキュリティ要求を満たすこと、すべてのセキュリティ活動が実行されていること、そして、すべての識別されたセキュリティ問題が文書化されて、解決されたことを証明します。証明ステータスに対するあらゆる例外は、納品で完全に文書化されなければなりません。

;(c) 悪意のあるコードのなし : 開発者は、ソフトウェアがソフトウェア要求をサポートせず、コンピュータ・ウイルス、ワーム、時限爆弾、バック・ドア、トロイの木馬、イースターエッグと他のあらゆる形の悪意のあるソフトウェアを含む、アプリケーションのセキュリティを弱めるあらゆるコードを含んではならないと保証します。

===11. セキュリティ承認と保守 ===

;(a) 受け入れ : 証明パッケージが完全であり、すべてのセキュリティ問題が解決されるまで、ソフトウェアは受け入れられると考慮されてはいけません。

;(b) セキュリティ問題の調査 : 受理の後、セキュリティ問題が発見されるか、かなり疑われるならば、開発者は顧客が問題の性質を決定するために調査を実行するのを援助しなければなりません。それがセキュリティ要求によってカバーされないで、セキュリティ・テストの理にかなった範囲の外にあるならば、問題は「新しい」と思われなければなりません。

;(c) 新しいセキュリティ問題 : 開発者と顧客は、新しいセキュリティ問題を解決するために必要な努力を探し出すことに同意します。また、それらに取り組むために必要とされる仕事を実行するための合意を達成するために誠意を持って交渉することに同意します。

;(d) 他のセキュリティ問題 : 開発者は堅実なソフトウェア開発慣行。そして、リスクのひどさを考慮すること、そして、できるだけ速く新しいと思われないすべてのセキュリティ問題を解決することと一致したすべての商業的に理にかなった努力を使わなければなりません

[[Category:OWASP Legal Project]]

__NOTOC__

OWASP Secure Software Contract Annex/ja

2011-07-06T13:12:44Z

Tomo: /* 9. セキュリティ問題マネジメント */

'''セキュア・ソフトウェア開発契約付属書'''

警告：この文書は、単にガイダンスと考えられなければなりません。
OWASPは、ソフトウェア契約を交渉するのを手助けするために、
あなたが資格のある弁護士に相談するよう強く勧めます。

==序文==

OWASPセキュア・ソフトウェア開発契約付属書は、ソフトウェアの開発者とその顧客が、開発または供給されるソフトウェアのセキュリティに関連した重要な契約条項と条件を交渉し、取り込むことを助けます。このプロジェクトの理由は、多くの契約はこれらの問題に触れておらず、しばしば関係者が実際に同意されたものに劇的に異なる見解を持つことです。私たちは、これらの条項を明確に述べることは、双方の関係者が進め方について情報に基づいた意思決定ができることを確実にするもっともよい方法であると思っています。

「市場がより良いセキュリティを要求するとき、商用ソフトのセキュリティは改善します。
最低限、あらゆるソフトウェア提案依頼書は、ベンダーに彼らがセキュリティ脆弱性に対して
生産物をテストする方法を詳述するよう依頼しなければなりません。このステップは、企業が
セキュリティを評価すると市販ソフトウェアのベンダーと外部調達された開発者を納得させ始めます。」
-- John Pescatore（Gartnerのリサーチ・ディレクター）として

私たちは、顧客と開発者が、期待について議論して、責任について交渉することに対するフレームワークとしてこの文書を使うよう勧めます。この付属書は、ソフトウェア開発契約に添付されることを目的とします。これらの条項は交渉の余地があります。そして、それらは顧客と開発者によって、協議されることができて、協議されなければならないことを意味します。

==プロジェクトについて==

この文書はOpen Web Application Security Project（OWASP）財団（セキュアなソフトウェアに関連した無料でオープンなツールとドキュメンテーションを作成することを専門とする非営利の慈善団体）によって作成されました。個人契約において容易に使用できるようにするために、この文書はCC Share Alike 3.0ライセンスにて提供されます。あなたが適すると思うように、修正してもよいですし、使用してもよいです。あなたは、http://www.owasp.com/index.php/OWASP_Legal_Project でこのプロジェクトについて更なる詳細を見つけることができます。私たちは、ソフトウェア（法律コミュニティだけでなく）の製作者と消費者のコメントを歓迎します。

OWASPは、この文書の研究と準備における彼らの役割に対して [http://www.aspectsecurity.com Aspect Security] から特別な貢献を感謝して認めます。

==異論==

以下のわずかなページは、ソフトウェア開発契約においてこの言い回しを使用することに対するいくらかのたびたび聞こえる異論をカバーします：

===しかし、すべての条項が私たちにとって適切であるというわけではありません…===

この文書は、あなたの合意の開始地点です。あなたは、すべての活動が好きではないかもしれません、または、より多くの提案をしたいかもしれません。あなたは異なる責任を割り当てたいかもしれません。この文書は、すべてのソフトウェア顧客と開発者の要望を厳密に取り込むことを意図しているわけではありません。ソフトウェアが最終的にセキュアになることを確実にするために重要である、主要な項目を議論するためのフレームワークを提供することを意図します。セキュリティを議論して合意を得た後で、あなたはこの合意を適合するように調整すべきです。

===しかし、これらの活動に対して誰が代金を払わなければならないのでしょうか===

この契約は、ソフトウェア開発者により多くの負担を与えることはほとんどありません。問題は、セキュリティ ― もちろんそこにある ― と関連したコストがあるかどうかということでありません。むしろ、適切な問題はどんな活動がそれらのコストを最小にするために双方によって実行されなければならないかということです、そして、いつ、それらは起こらなければなりませんか。

この付属書は、誰がここに記述される活動の料金を払わなければならないかという問題については、意図的に語られていません。これらの活動の多くがすでに起こらなければならなくて、多くの顧客によって期待される一方、それたはソフトウェア産業で定期的に実践されることはありません。誰が（そして、いくら）支払うかという問題が、交渉の一部でなければなりません。

セキュリティのコストを計算することは、非常に難しいです。セキュリティ活動を実行することに関連したコストがある一方、それらを無視することに関連したかなりのコストもあります。私たちは、ソフトウェアを開発する最も費用対効果がよい方法について確信しています。それは、セキュリティ瑕疵が導入されるという可能性を減らして、瑕疵を導入して、それを修正することの間で時間を最小にすることです。

コストを計算するときにする一つの重要な区別は、セキュリティ手法を構築することと、それらの手法が正しくて効果的であることを確実にする保証活動の間にあります。ライフサイクルの終わりに手法を加えようとすることは、深刻な設計問題を引き起こすことがありえて、めざましくコストを増やします。この合意は、手法についての早い段階の決定がこれらのコストを最小にするのを奨励します。同様に、配備直前に保証活動（例えばコードレビューと侵入テスト）をするまで待つことはコストをめざましく増やします。私たちは、保証を得る最も費用効果がよい方法がライフサイクルを通して努力の一定のレベルを保証に入れることであると思っています。

===しかし厳密さのレベルは間違っている….===

この合意は、開発されているソフトウェアが大企業または政府機関にとってかなり重要であると仮定します。私たちは、大部分のソフトウェア開発組織によって達成できる合意のために「厳格さのレベル」を選んで、最も一般的なリスクを確認して、取り扱います。

しかし、重要なアプリケーション（例えば医学であるか、財政的であるか、防衛に関連したソフトウェア）で使われそうであるソフトウェアについては、あなたは厳格さのレベルを上げたいかもしれません。あなたは、追加のレビュー、文書化とテストの活動を加えたくてもよいです。あなたは、脆弱性を探すこと、診断すること、修正することに対するプロセスを強化しくてもよいです。より機密を扱わないアプリケーションのために、あなたは活動を減らすか、取り除きたくてもよいです。

===しかし、私たちはそれほど多くのリスクをとることができない…===

この契約は、ソフトウェアにおけるセキュリティ脆弱性に対するリスクをとるのかという議論を容易にすることを目的とします。範囲の一端では、顧客はすべてのリスクをとることができました、そして、開発者はたくさんの脆弱性をもつコードを供給することができました。他の極端では、開発者はすべてのリスクをとることができて、完全なコードを供給することに対する責任を負うことができました。これらの両極端は、どちらとも実行不可能です。

現在、この契約において、開発者は要求においてカバーされたか、理にかなったテスト努力によってカバーされるべき問題に対するリスクをとります。しかし、「新しい」セキュリティ問題の改善は、顧客によって代金を払われるべきです。私たちは、これが開発者が彼らのリスクの境界となることができて役に立つバランスで、顧客が前もってセキュリティ要求を正しくするのを奨励すると思っています。しかし、この問題の多くの他の可能性がある解決が、あります。あなたには他の提案があるかどうか私たちに知らせます、そして、私たちは彼らをこの文書の将来の版に含めてもよいです。

ここでの議論がコードにおいてセキュリティ脆弱性を修正することに関連したリスクをカバーだけして、これらの脆弱性のあらゆるエクスプロイットに基づくあらゆるセキュリティ・インシデントから立ち直ることと関連したコストを含まないことに注意すべきです。私たちは、この領域におけるベスト・プラクティスに興味があります。

===私たちはどのように第三者のコードを保証するでしょうか===

ほとんどすべてのソフトウェアプロジェクトは、第三者のコード（例えばライブラリ、フレームワークと生産物）のかなりの量を使います。このコードは、ただセキュリティ観点から、カスタム・コードがあなたのプロジェクトのために特に発達したのと同じくらい重要です。
私たちはこのコードのセキュリティを確実にすることに対する責任が開発者によって負われて最もよいと思っています、しかし、彼らにはこのセキュリティを保証するために彼ら自身のいっぱいの能力がないかもしれません。しかし、セキュリティは「構築するか、買うか」議論の一部分でなければなりません、これはそれを促進する最もよい方法のようです。

開発者は、もちろん、終わりまで第三者のソフトウェアの提供者にこの責任をパスする選択権があります。開発者は彼ら自身第三者のコードを分析することもできるか、彼らのためにそれを分析するために、セキュリティの専門家を雇うこともできます。

===しかし、なぜ私はすべてのこのトラブルにいくべきなのでしょうか===

最後に、私たちはソフトウェアを契約しているプロセスの一部分をセキュリティをすることに代わるものがないと思っています。現在では、私たちは多くのソフトウェア開発契約のもとで供給されているコードのセキュリティに関する重大な誤解があると思っています。これは、わずかなソフトウェア経験または理解とともに個人によってなされる高価な訴訟と決定に至ることができるだけです。この問題の完全な議論に対して [[Secure software contracting hypothetical case study]] （[https://www.owasp.org/index.php/Secure_software_contracting_hypothetical_case_study/ja 日本語訳]）を読んでください。

多くの利点が、この契約を通してうまくいくことにあります。主要なものは、それが関係する関係者の間で期待を明らかにするということです。場合によっては、難しいセキュリティ問題がソフトウェアで表面化するとき、それは訴訟を妨げるのを助けます。また、これらは多くの法的で調整するコンプライアンスの理由によって必要とされる同じ活動です。

===しかし、このドキュメントですべてを作ることは難しい===

OWASPは、文書化を目的とした文書化を推奨しません。この契約は品質（量ではない）を促進することに集中します。私たちは、短いリスク評価、数ページの要求、短いセキュリティ設計文書、テストプラン、いくつかのテスト結果とともに、この契約に応じることが（若干のプロジェクトにおいて）ありえると思っています。

この文書の目標は、ライフサイクルの各段階で、単に適切な注意がセキュリティに払われたことを確実とすることです。追加の利点は、この文書が基本的に、このソフトウェアが安心してそれがそれがすると主張することをするのをまかせられなければならない理由に対する議論を配置する「証明パッケージ」をつくるために一緒に集められることができるということです。

==契約付属書==

===1. 序文===

この付属書は、顧客と開発者の間で_____________________ ("合意") するために作られます。顧客と開発者は、以下の条項によりソフトウェアのセキュリティを最大にすることに同意します。

===2. 原理===

この付属書は、ソフトウェア開発関係のすべての関係者のセキュリティ関連の権利と義務をはっきりさせることを目的とします。最高レベルで、関係者は以下に同意します

;(a) セキュリティ決定は、リスクに基づきます : セキュリティについての決定は、関係するリスクのしっかりした理解に基づく顧客と開発者によって共同でなされす。

;(b) セキュリティ活動はバランスが保たれます : セキュリティ努力は、全てのソフトウェア開発ライフサイクル全体でおおよそ均一に配布されます。

;(c) セキュリティ活動は統合されます : ここに協議されるすべての活動と文書は、開発者のソフトウェア開発ライフサイクルに統合されて、残りのプロジェクトと別にしておかれるというわけではありません。この付属書の何も、どんな特定のソフトウェア開発プロセスを意味しません。

;(d) 脆弱性は予想されます : すべてのソフトウェアにはバグがあります、そして、それらのいくらかはセキュリティ問題を生じさせます。顧客と開発者は、ライフサイクルにおいてできるだけ早く脆弱性を特定するよう努めます。

;(e) セキュリティ情報は完全に明らかにされます : すべてのセキュリティ関連した情報は、すぐに、そして、完全に、顧客と開発者で共有されます。

;(f) 役に立つセキュリティ文書だけが必要とされます : セキュリティ文書は、セキュリティ設計、リスク分析または問題を明確に記述するために詳細にわたる必要はありません。

===3.ライフサイクル活動===

;(a) リスク識別 : 開発者と顧客は、アプリケーションに直面しているリスクを理解して、文書化するために協力することに同意します。この努力は、アプリケーションにより提供される重要な資産と機能への主要なリスクを確認しなければなりません。要件部にリストされるトピックの各々は、考慮されなければなりません。

;(b) 要求 : リスクに基づいて、開発者と顧客は、開発されるソフトウェアの仕様の一部として詳細なセキュリティ要件を確立するために協力することに同意します。この付属書の要件部分で記載される個々のトピックは、開発者と顧客によって協議されなければならなくて、評価されなければなりません。これらの要件は、カスタム・ソフトウェア、第三者のソフトウェアまたはプラットホームによって満たされてもよいです。

;(c) 設計 : 開発者は、セキュリティ要件の各々を達成するために明確に設計を説明する文書を提供することに同意します。ほとんどの場合、この文書はセキュリティ手法を記載します、そこで、手法はアーキテクチャに適合しました、そして、関連したすべては彼らの適正使用を確実にするためにパターンを設計します。設計は、サポートがカスタム・ソフトか、第三者のソフトウェアかプラットホームから来るかどうか、明確に指定しなければなりません。

;(d) 実装 : 開発者は、一組のセキュアなコーディング指針に提供することに、従って、一組の共通セキュリティ制御プログラミング・インターフェース（例えば [http://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API OWASP Enterprise Security API（ESAPI）] ）を使って同意します。ガイドラインは、コードがどのようにフォーマットされなければならなくて、構築されなければならなくて、コメントされなければならないかについて示します。共通セキュリティ制御プログラミング・インターフェースは、セキュリティ制御がどのように呼ばれなければならないか、そして、セキュリティ制御がどのように機能するか定めます。すべてのセキュリティに関連したコードは、十分に解説されなければなりません。共通のセキュリティ脆弱性を回避するときの具体的なガイダンスが含まれなければなりません。また、すべてのコードはセキュリティ要件に対して少なくとも他の一人の開発者によってレビューされなければなりません、そして、それの前のコーディング・ガイドラインは単体テストの準備ができていると思われます。

;(e) セキュリティ分析とテスト : 開発者は、（ [http://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project OWASP Application Security Verification Standard (ASVS)] のような）合意された標準の検証要件により、アプリケーション・セキュリティ分析とテスト（「検証」とも言われる）を実行します。開発者は、標準の報告要件によって検証結論を文書化しなければなりません。開発者は、検証結論を顧客に提供しなければなりません。

;(f) セキュリティ配備 : 開発者は、ソフトウェアの全体的なセキュリティのために完全にすべてのセキュリティ関連した構成オプションとそれらの関連性を記述するセキュアな構成ガイドラインを提供することに同意します。ガイドラインは、オペレーティングシステム、ウェブサーバとアプリケーション・サーバーを含むサポート的なプラットホームにおける依存関係の完全な記述を含まなければいけません。また、どのようにそれらをセキュリティのために構成されるべきかを含まなければいけません。ソフトウェアのデフォルトコンフィグレーションは、セキュアでなければなりません。

===4.セキュリティ要求エリア===

以下のトピック領域は、リスク理解と要求定義活動の間、考慮されなければなりません。この努力は一組の具体的で、注文仕立てで、分析できる要求を生産しなければなりません。そして、開発者と顧客はこのプロセスに関与していなければならなくて、要求の最終セットについて同意しなければなりません。

;(a) 入力検証とエンコーディング : 要求は、ユーザー、ファイルシステム、データベース、ディレクトリまたは外部システムからであるかどうかにかかわらず、アプリケーションへの各々の入力を標準化し、検証し、コード化するためにルールを指定しなければなりません。　　　デフォルトルールは、それが何が許可されるかという詳細な仕様にマッチしない限り、すべての入力が無効であるということでなければなりません。そのうえ、無効な入力が受け取られるとき、要求はとられる措置を指定しなければなりません。具体的には、アプリケーションはインジェクション、オーバフロー、不正操作することまたは他の不正な入力攻撃に影響されやすくてはいけません。

;(b) 認証とセッション管理 : 要求は、認証証明書とセッション識別子がどのようにそれらのライフサイクルを通して保護されているかについて明記しなければなりません。すべての関連する機能（パスワード忘却、パスワード変更、パスワードリマインダ、ログアウト、そして複数ログインを含む）に対する要求は含められなければいけません。

;(c) アクセス制御 : 要求は、アプリケーションで使われるすべての役割（グループ、特権、認可）の詳細な記述を含まなければなりません。要求は、アプリケーションにより提供されるすべての資産と機能も示さなければなりません。要求は、完全に各々の資産に正確なアクセス権を指定しなければならなくて、各々の役割に対して機能しなければなりません。アクセス制御マトリックスは、これらのルールのための提案されたフォーマットです。

;(d) エラー処理 : 要求は、処理の間、発生しているエラーが取り扱われる方法を詳述しなければなりません。若干のアプリケーションはエラーの場合には最もよい努力結果を提供しなければなりません、一方、他はすぐに処理を終了しなければなりません。

;(e) ロギング : 要求は、どんなイベントがセキュリティに関連して、記録される必要があるか、たとえば、検知された攻撃、失敗したログイン試行、認可を上回ろうとする試行、を指定しなければなりません。要求は、時間と日付、イベント記述、アプリケーション詳細とフォレンジクス努力に役立つ他の情報を含む、各々のイベントでどんな情報を記録するべきかについても指定しなければなりません。

;(f) 外部システムへの接続 : 要求は、認証と暗号化がどのようにすべての外部システム（例えばデータベース、ディレクトリとウェブ・サービス）のために取り扱われるかについて指定しなければなりません。外部システムでコミュニケーションのために必要とされるすべてのクレディンシャルは、暗号化された形で構成ファイルでコードの外側に保存されなければなりません。

;(g) 暗号 : 要求は、どんなデータが暗号化されなければならないか、暗号化されることがどれほどか、そして、すべての証明書と他のクレディンシャルがどのように取り扱われなければならないか指定しなければなりません。アプリケーションは、広く使われていてテストされた暗号化ライブラリで実装される標準的なアルゴリズムを使用しなければなりません。

;(h) 可用性 : 要求は、それがどのようにサービス不能攻撃から保護するかについて指定しなければなりません。アプリケーションへのすべてのありそうな攻撃は考慮されなければなりません。そして、認証ロックアウト、接続消耗と他の資源消耗攻撃を含みます。

;(i) セキュアな設定 : 要求は、すべてのセキュリティに関連した構成オプションに対するデフォルト値がセキュアでなければならないことを示していなければなりません。監査目的のために、ソフトウェアはすべてのセキュリティに関連した構成詳細を示している簡単に読めるレポートをつくることができなければなりません。

;(j) 特定の脆弱性 : 要求は、ソフトウェアで見つかってはならない一組の具体的な脆弱性を含まなければなりません。指定されていないならば、ソフトウェアは現在の「OWASP Top Ten Most Critical Web Application Vulnerabilities」で記述される瑕疵の何も含んではいけません。

===5. 要員および組織===

;(a) セキュリティ・アーキテクト : 開発者は一つの上位の技術的な資源に責任をセキュリティに指定します。そして、プロジェクトのセキュリティ・アーキテクトとして知られています。セキュリティ・アーキテクトは、個々の納品可能なもののセキュリティを保証します。

;(b) セキュリティ・トレーニング : 開発者は、開発者チームのすべてのメンバーがセキュアなプログラミング技法の訓練をされたことを確かめる役割を果たします。

;(c) 信頼できる開発者 : 開発者は、すべての開発チーム・メンバーの適切な経歴調査を実行することに同意します。

===6.開発環境===

;(a) セキュア・コーディング : 開発者は、どんなツールがセキュアなコーディングを促すためにソフトウェア開発環境で使われるかについて明らかにしなければなりません。

;(b) 構成管理 : 開発者は、ソフトウェア・ベースラインに対するすべての変更とすべての関連した設定とビルド・ファイルを関連づけ　とすべての関連した構成にすべての変化と関連したチーム・メンバーを認証して、記録して、ファイルを構築したソース・コード管理システムを使用しなければなりません。

;(c) 配布 : 開発者は、ソースから確実に完全な配布を構築するビルド・プロセスを使用しなければなりません。このプロセスは、顧客に供給されるソフトウェアの完全性を確かめる方法を含まなければなりません。

===7. ライブラリ、フレームワーク、および生産物===

;(a) 開示 : 開発者は、商用、フリー、オープンソース、クローズソースであるにせよ、すべてのライブラリ、フレームワーク、構成要素および他の生産物を含む、ソフトウェアで使われるすべての第三者のソフトウェアを明らかにしなければなりません。

;(b) 評価 : 開発者は、第三者のソフトウェアがこの契約のすべての条項を満たして、この契約のもとで開発されたカスタム開発されたコードと同じくらいセキュアなことを確実とするために、理にかなった努力をしなければなりません。

===8. セキュリティ・レビュー===

;(a) レビューする権利 : 依頼人には、ソフトウェアを納品の60日間以内にいつでも彼らの費用でセキュリティ瑕疵のためにレビューしておく権利があります。開発者は、ソース・コードとテスト環境へのアクセスを提供することによって理にかなったサポートをレビュー・チームに提供することに同意します。

;(b) レビュー・カバレッジ : セキュリティ・レビューは供給されるソフトウェアのすべての面をカバーしなければなりません。そして、カスタム・コード、構成要素、生産物とシステム設定を含みます。

;(c) レビューの範囲 : 最低限で、レビューはセキュリティ要求の全てをカバーしなければならなくて、他の一般的な脆弱性を捜さなければなりません。レビューは、脆弱性スキャン、侵入テスト、ソースコードの静的分析と専門家のコードレビューの組み合わせを含んでもよいです。

;(d) 見つけられた問題 : 発見されたセキュリティ問題は、顧客と開発者に報告されます。すべての問題は、この付属書のセキュリティ問題管理セクションにより追跡されて、矯正されます。

===9. セキュリティ問題管理 ===

;(a) 識別 : 要求、設計、実装、テスト、配備、または、運用中の問題にせよ、開発者は全てのライフサイクルの間に発見されるすべてのセキュリティ問題を追跡します。個々のセキュリティ問題に関連したリスクは、発見後できるだけ早く、評価されて、文書化されて、発見の後、顧客に報告されます。

;(b) 保護 : 開発者はセキュリティ問題と関連する文書に関して情報を適切に保護します。そして、運用中の顧客ソフトウェアの脆弱性が露出するという可能性を制限するのを助けます。

;(c) 改善 : 納品の前に確認されるセキュリティ問題は、開発者によって修正されなければなりません。納品の後に発見されるセキュリティ問題は、本契約の規定による他のバグと問題として同様に取り扱われなければなりません。

===10. 保証===

;(a) 保証 : 開発者は、開発プロセスを通して作成されるセキュリティ文書からなる「証明パッケージ」を提供します。パッケージは、セキュリティ要求、設計、実装と試験結果がきちんと完了された、そして、すべてのセキュリティ問題が適切に解決されたと確認しなければなりません。

;(b) 自己証明 : セキュリティ・アーキテクトは、ソフトウェアがセキュリティ要求を満たすこと、すべてのセキュリティ活動が実行されていること、そして、すべての識別されたセキュリティ問題が文書化されて、解決されたことを証明します。証明ステータスに対するあらゆる例外は、納品で完全に文書化されなければなりません。

;(c) 悪意のあるコードのなし : 開発者は、ソフトウェアがソフトウェア要求をサポートせず、コンピュータ・ウイルス、ワーム、時限爆弾、バック・ドア、トロイの木馬、イースターエッグと他のあらゆる形の悪意のあるソフトウェアを含む、アプリケーションのセキュリティを弱めるあらゆるコードを含んではならないと保証します。

===11. セキュリティ承認と保守 ===

;(a) 受け入れ : 証明パッケージが完全であり、すべてのセキュリティ問題が解決されるまで、ソフトウェアは受け入れられると考慮されてはいけません。

;(b) セキュリティ問題の調査 : 受理の後、セキュリティ問題が発見されるか、かなり疑われるならば、開発者は顧客が問題の性質を決定するために調査を実行するのを援助しなければなりません。それがセキュリティ要求によってカバーされないで、セキュリティ・テストの理にかなった範囲の外にあるならば、問題は「新しい」と思われなければなりません。

;(c) 新しいセキュリティ問題 : 開発者と顧客は、新しいセキュリティ問題を解決するために必要な努力を探し出すことに同意します。また、それらに取り組むために必要とされる仕事を実行するための合意を達成するために誠意を持って交渉することに同意します。

;(d) 他のセキュリティ問題 : 開発者は堅実なソフトウェア開発慣行。そして、リスクのひどさを考慮すること、そして、できるだけ速く新しいと思われないすべてのセキュリティ問題を解決することと一致したすべての商業的に理にかなった努力を使わなければなりません

[[Category:OWASP Legal Project]]

__NOTOC__

OWASP Secure Software Contract Annex/ja

2011-07-06T13:10:51Z

Tomo: /* 8. セキュリティ・レビュー */

'''セキュア・ソフトウェア開発契約付属書'''

警告：この文書は、単にガイダンスと考えられなければなりません。
OWASPは、ソフトウェア契約を交渉するのを手助けするために、
あなたが資格のある弁護士に相談するよう強く勧めます。

==序文==

OWASPセキュア・ソフトウェア開発契約付属書は、ソフトウェアの開発者とその顧客が、開発または供給されるソフトウェアのセキュリティに関連した重要な契約条項と条件を交渉し、取り込むことを助けます。このプロジェクトの理由は、多くの契約はこれらの問題に触れておらず、しばしば関係者が実際に同意されたものに劇的に異なる見解を持つことです。私たちは、これらの条項を明確に述べることは、双方の関係者が進め方について情報に基づいた意思決定ができることを確実にするもっともよい方法であると思っています。

「市場がより良いセキュリティを要求するとき、商用ソフトのセキュリティは改善します。
最低限、あらゆるソフトウェア提案依頼書は、ベンダーに彼らがセキュリティ脆弱性に対して
生産物をテストする方法を詳述するよう依頼しなければなりません。このステップは、企業が
セキュリティを評価すると市販ソフトウェアのベンダーと外部調達された開発者を納得させ始めます。」
-- John Pescatore（Gartnerのリサーチ・ディレクター）として

私たちは、顧客と開発者が、期待について議論して、責任について交渉することに対するフレームワークとしてこの文書を使うよう勧めます。この付属書は、ソフトウェア開発契約に添付されることを目的とします。これらの条項は交渉の余地があります。そして、それらは顧客と開発者によって、協議されることができて、協議されなければならないことを意味します。

==プロジェクトについて==

この文書はOpen Web Application Security Project（OWASP）財団（セキュアなソフトウェアに関連した無料でオープンなツールとドキュメンテーションを作成することを専門とする非営利の慈善団体）によって作成されました。個人契約において容易に使用できるようにするために、この文書はCC Share Alike 3.0ライセンスにて提供されます。あなたが適すると思うように、修正してもよいですし、使用してもよいです。あなたは、http://www.owasp.com/index.php/OWASP_Legal_Project でこのプロジェクトについて更なる詳細を見つけることができます。私たちは、ソフトウェア（法律コミュニティだけでなく）の製作者と消費者のコメントを歓迎します。

OWASPは、この文書の研究と準備における彼らの役割に対して [http://www.aspectsecurity.com Aspect Security] から特別な貢献を感謝して認めます。

==異論==

以下のわずかなページは、ソフトウェア開発契約においてこの言い回しを使用することに対するいくらかのたびたび聞こえる異論をカバーします：

===しかし、すべての条項が私たちにとって適切であるというわけではありません…===

この文書は、あなたの合意の開始地点です。あなたは、すべての活動が好きではないかもしれません、または、より多くの提案をしたいかもしれません。あなたは異なる責任を割り当てたいかもしれません。この文書は、すべてのソフトウェア顧客と開発者の要望を厳密に取り込むことを意図しているわけではありません。ソフトウェアが最終的にセキュアになることを確実にするために重要である、主要な項目を議論するためのフレームワークを提供することを意図します。セキュリティを議論して合意を得た後で、あなたはこの合意を適合するように調整すべきです。

===しかし、これらの活動に対して誰が代金を払わなければならないのでしょうか===

この契約は、ソフトウェア開発者により多くの負担を与えることはほとんどありません。問題は、セキュリティ ― もちろんそこにある ― と関連したコストがあるかどうかということでありません。むしろ、適切な問題はどんな活動がそれらのコストを最小にするために双方によって実行されなければならないかということです、そして、いつ、それらは起こらなければなりませんか。

この付属書は、誰がここに記述される活動の料金を払わなければならないかという問題については、意図的に語られていません。これらの活動の多くがすでに起こらなければならなくて、多くの顧客によって期待される一方、それたはソフトウェア産業で定期的に実践されることはありません。誰が（そして、いくら）支払うかという問題が、交渉の一部でなければなりません。

セキュリティのコストを計算することは、非常に難しいです。セキュリティ活動を実行することに関連したコストがある一方、それらを無視することに関連したかなりのコストもあります。私たちは、ソフトウェアを開発する最も費用対効果がよい方法について確信しています。それは、セキュリティ瑕疵が導入されるという可能性を減らして、瑕疵を導入して、それを修正することの間で時間を最小にすることです。

コストを計算するときにする一つの重要な区別は、セキュリティ手法を構築することと、それらの手法が正しくて効果的であることを確実にする保証活動の間にあります。ライフサイクルの終わりに手法を加えようとすることは、深刻な設計問題を引き起こすことがありえて、めざましくコストを増やします。この合意は、手法についての早い段階の決定がこれらのコストを最小にするのを奨励します。同様に、配備直前に保証活動（例えばコードレビューと侵入テスト）をするまで待つことはコストをめざましく増やします。私たちは、保証を得る最も費用効果がよい方法がライフサイクルを通して努力の一定のレベルを保証に入れることであると思っています。

===しかし厳密さのレベルは間違っている….===

この合意は、開発されているソフトウェアが大企業または政府機関にとってかなり重要であると仮定します。私たちは、大部分のソフトウェア開発組織によって達成できる合意のために「厳格さのレベル」を選んで、最も一般的なリスクを確認して、取り扱います。

しかし、重要なアプリケーション（例えば医学であるか、財政的であるか、防衛に関連したソフトウェア）で使われそうであるソフトウェアについては、あなたは厳格さのレベルを上げたいかもしれません。あなたは、追加のレビュー、文書化とテストの活動を加えたくてもよいです。あなたは、脆弱性を探すこと、診断すること、修正することに対するプロセスを強化しくてもよいです。より機密を扱わないアプリケーションのために、あなたは活動を減らすか、取り除きたくてもよいです。

===しかし、私たちはそれほど多くのリスクをとることができない…===

この契約は、ソフトウェアにおけるセキュリティ脆弱性に対するリスクをとるのかという議論を容易にすることを目的とします。範囲の一端では、顧客はすべてのリスクをとることができました、そして、開発者はたくさんの脆弱性をもつコードを供給することができました。他の極端では、開発者はすべてのリスクをとることができて、完全なコードを供給することに対する責任を負うことができました。これらの両極端は、どちらとも実行不可能です。

現在、この契約において、開発者は要求においてカバーされたか、理にかなったテスト努力によってカバーされるべき問題に対するリスクをとります。しかし、「新しい」セキュリティ問題の改善は、顧客によって代金を払われるべきです。私たちは、これが開発者が彼らのリスクの境界となることができて役に立つバランスで、顧客が前もってセキュリティ要求を正しくするのを奨励すると思っています。しかし、この問題の多くの他の可能性がある解決が、あります。あなたには他の提案があるかどうか私たちに知らせます、そして、私たちは彼らをこの文書の将来の版に含めてもよいです。

ここでの議論がコードにおいてセキュリティ脆弱性を修正することに関連したリスクをカバーだけして、これらの脆弱性のあらゆるエクスプロイットに基づくあらゆるセキュリティ・インシデントから立ち直ることと関連したコストを含まないことに注意すべきです。私たちは、この領域におけるベスト・プラクティスに興味があります。

===私たちはどのように第三者のコードを保証するでしょうか===

ほとんどすべてのソフトウェアプロジェクトは、第三者のコード（例えばライブラリ、フレームワークと生産物）のかなりの量を使います。このコードは、ただセキュリティ観点から、カスタム・コードがあなたのプロジェクトのために特に発達したのと同じくらい重要です。
私たちはこのコードのセキュリティを確実にすることに対する責任が開発者によって負われて最もよいと思っています、しかし、彼らにはこのセキュリティを保証するために彼ら自身のいっぱいの能力がないかもしれません。しかし、セキュリティは「構築するか、買うか」議論の一部分でなければなりません、これはそれを促進する最もよい方法のようです。

開発者は、もちろん、終わりまで第三者のソフトウェアの提供者にこの責任をパスする選択権があります。開発者は彼ら自身第三者のコードを分析することもできるか、彼らのためにそれを分析するために、セキュリティの専門家を雇うこともできます。

===しかし、なぜ私はすべてのこのトラブルにいくべきなのでしょうか===

最後に、私たちはソフトウェアを契約しているプロセスの一部分をセキュリティをすることに代わるものがないと思っています。現在では、私たちは多くのソフトウェア開発契約のもとで供給されているコードのセキュリティに関する重大な誤解があると思っています。これは、わずかなソフトウェア経験または理解とともに個人によってなされる高価な訴訟と決定に至ることができるだけです。この問題の完全な議論に対して [[Secure software contracting hypothetical case study]] （[https://www.owasp.org/index.php/Secure_software_contracting_hypothetical_case_study/ja 日本語訳]）を読んでください。

多くの利点が、この契約を通してうまくいくことにあります。主要なものは、それが関係する関係者の間で期待を明らかにするということです。場合によっては、難しいセキュリティ問題がソフトウェアで表面化するとき、それは訴訟を妨げるのを助けます。また、これらは多くの法的で調整するコンプライアンスの理由によって必要とされる同じ活動です。

===しかし、このドキュメントですべてを作ることは難しい===

OWASPは、文書化を目的とした文書化を推奨しません。この契約は品質（量ではない）を促進することに集中します。私たちは、短いリスク評価、数ページの要求、短いセキュリティ設計文書、テストプラン、いくつかのテスト結果とともに、この契約に応じることが（若干のプロジェクトにおいて）ありえると思っています。

この文書の目標は、ライフサイクルの各段階で、単に適切な注意がセキュリティに払われたことを確実とすることです。追加の利点は、この文書が基本的に、このソフトウェアが安心してそれがそれがすると主張することをするのをまかせられなければならない理由に対する議論を配置する「証明パッケージ」をつくるために一緒に集められることができるということです。

==契約付属書==

===1. 序文===

この付属書は、顧客と開発者の間で_____________________ ("合意") するために作られます。顧客と開発者は、以下の条項によりソフトウェアのセキュリティを最大にすることに同意します。

===2. 原理===

この付属書は、ソフトウェア開発関係のすべての関係者のセキュリティ関連の権利と義務をはっきりさせることを目的とします。最高レベルで、関係者は以下に同意します

;(a) セキュリティ決定は、リスクに基づきます : セキュリティについての決定は、関係するリスクのしっかりした理解に基づく顧客と開発者によって共同でなされす。

;(b) セキュリティ活動はバランスが保たれます : セキュリティ努力は、全てのソフトウェア開発ライフサイクル全体でおおよそ均一に配布されます。

;(c) セキュリティ活動は統合されます : ここに協議されるすべての活動と文書は、開発者のソフトウェア開発ライフサイクルに統合されて、残りのプロジェクトと別にしておかれるというわけではありません。この付属書の何も、どんな特定のソフトウェア開発プロセスを意味しません。

;(d) 脆弱性は予想されます : すべてのソフトウェアにはバグがあります、そして、それらのいくらかはセキュリティ問題を生じさせます。顧客と開発者は、ライフサイクルにおいてできるだけ早く脆弱性を特定するよう努めます。

;(e) セキュリティ情報は完全に明らかにされます : すべてのセキュリティ関連した情報は、すぐに、そして、完全に、顧客と開発者で共有されます。

;(f) 役に立つセキュリティ文書だけが必要とされます : セキュリティ文書は、セキュリティ設計、リスク分析または問題を明確に記述するために詳細にわたる必要はありません。

===3.ライフサイクル活動===

;(a) リスク識別 : 開発者と顧客は、アプリケーションに直面しているリスクを理解して、文書化するために協力することに同意します。この努力は、アプリケーションにより提供される重要な資産と機能への主要なリスクを確認しなければなりません。要件部にリストされるトピックの各々は、考慮されなければなりません。

;(b) 要求 : リスクに基づいて、開発者と顧客は、開発されるソフトウェアの仕様の一部として詳細なセキュリティ要件を確立するために協力することに同意します。この付属書の要件部分で記載される個々のトピックは、開発者と顧客によって協議されなければならなくて、評価されなければなりません。これらの要件は、カスタム・ソフトウェア、第三者のソフトウェアまたはプラットホームによって満たされてもよいです。

;(c) 設計 : 開発者は、セキュリティ要件の各々を達成するために明確に設計を説明する文書を提供することに同意します。ほとんどの場合、この文書はセキュリティ手法を記載します、そこで、手法はアーキテクチャに適合しました、そして、関連したすべては彼らの適正使用を確実にするためにパターンを設計します。設計は、サポートがカスタム・ソフトか、第三者のソフトウェアかプラットホームから来るかどうか、明確に指定しなければなりません。

;(d) 実装 : 開発者は、一組のセキュアなコーディング指針に提供することに、従って、一組の共通セキュリティ制御プログラミング・インターフェース（例えば [http://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API OWASP Enterprise Security API（ESAPI）] ）を使って同意します。ガイドラインは、コードがどのようにフォーマットされなければならなくて、構築されなければならなくて、コメントされなければならないかについて示します。共通セキュリティ制御プログラミング・インターフェースは、セキュリティ制御がどのように呼ばれなければならないか、そして、セキュリティ制御がどのように機能するか定めます。すべてのセキュリティに関連したコードは、十分に解説されなければなりません。共通のセキュリティ脆弱性を回避するときの具体的なガイダンスが含まれなければなりません。また、すべてのコードはセキュリティ要件に対して少なくとも他の一人の開発者によってレビューされなければなりません、そして、それの前のコーディング・ガイドラインは単体テストの準備ができていると思われます。

;(e) セキュリティ分析とテスト : 開発者は、（ [http://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project OWASP Application Security Verification Standard (ASVS)] のような）合意された標準の検証要件により、アプリケーション・セキュリティ分析とテスト（「検証」とも言われる）を実行します。開発者は、標準の報告要件によって検証結論を文書化しなければなりません。開発者は、検証結論を顧客に提供しなければなりません。

;(f) セキュリティ配備 : 開発者は、ソフトウェアの全体的なセキュリティのために完全にすべてのセキュリティ関連した構成オプションとそれらの関連性を記述するセキュアな構成ガイドラインを提供することに同意します。ガイドラインは、オペレーティングシステム、ウェブサーバとアプリケーション・サーバーを含むサポート的なプラットホームにおける依存関係の完全な記述を含まなければいけません。また、どのようにそれらをセキュリティのために構成されるべきかを含まなければいけません。ソフトウェアのデフォルトコンフィグレーションは、セキュアでなければなりません。

===4.セキュリティ要求エリア===

以下のトピック領域は、リスク理解と要求定義活動の間、考慮されなければなりません。この努力は一組の具体的で、注文仕立てで、分析できる要求を生産しなければなりません。そして、開発者と顧客はこのプロセスに関与していなければならなくて、要求の最終セットについて同意しなければなりません。

;(a) 入力検証とエンコーディング : 要求は、ユーザー、ファイルシステム、データベース、ディレクトリまたは外部システムからであるかどうかにかかわらず、アプリケーションへの各々の入力を標準化し、検証し、コード化するためにルールを指定しなければなりません。　　　デフォルトルールは、それが何が許可されるかという詳細な仕様にマッチしない限り、すべての入力が無効であるということでなければなりません。そのうえ、無効な入力が受け取られるとき、要求はとられる措置を指定しなければなりません。具体的には、アプリケーションはインジェクション、オーバフロー、不正操作することまたは他の不正な入力攻撃に影響されやすくてはいけません。

;(b) 認証とセッション管理 : 要求は、認証証明書とセッション識別子がどのようにそれらのライフサイクルを通して保護されているかについて明記しなければなりません。すべての関連する機能（パスワード忘却、パスワード変更、パスワードリマインダ、ログアウト、そして複数ログインを含む）に対する要求は含められなければいけません。

;(c) アクセス制御 : 要求は、アプリケーションで使われるすべての役割（グループ、特権、認可）の詳細な記述を含まなければなりません。要求は、アプリケーションにより提供されるすべての資産と機能も示さなければなりません。要求は、完全に各々の資産に正確なアクセス権を指定しなければならなくて、各々の役割に対して機能しなければなりません。アクセス制御マトリックスは、これらのルールのための提案されたフォーマットです。

;(d) エラー処理 : 要求は、処理の間、発生しているエラーが取り扱われる方法を詳述しなければなりません。若干のアプリケーションはエラーの場合には最もよい努力結果を提供しなければなりません、一方、他はすぐに処理を終了しなければなりません。

;(e) ロギング : 要求は、どんなイベントがセキュリティに関連して、記録される必要があるか、たとえば、検知された攻撃、失敗したログイン試行、認可を上回ろうとする試行、を指定しなければなりません。要求は、時間と日付、イベント記述、アプリケーション詳細とフォレンジクス努力に役立つ他の情報を含む、各々のイベントでどんな情報を記録するべきかについても指定しなければなりません。

;(f) 外部システムへの接続 : 要求は、認証と暗号化がどのようにすべての外部システム（例えばデータベース、ディレクトリとウェブ・サービス）のために取り扱われるかについて指定しなければなりません。外部システムでコミュニケーションのために必要とされるすべてのクレディンシャルは、暗号化された形で構成ファイルでコードの外側に保存されなければなりません。

;(g) 暗号 : 要求は、どんなデータが暗号化されなければならないか、暗号化されることがどれほどか、そして、すべての証明書と他のクレディンシャルがどのように取り扱われなければならないか指定しなければなりません。アプリケーションは、広く使われていてテストされた暗号化ライブラリで実装される標準的なアルゴリズムを使用しなければなりません。

;(h) 可用性 : 要求は、それがどのようにサービス不能攻撃から保護するかについて指定しなければなりません。アプリケーションへのすべてのありそうな攻撃は考慮されなければなりません。そして、認証ロックアウト、接続消耗と他の資源消耗攻撃を含みます。

;(i) セキュアな設定 : 要求は、すべてのセキュリティに関連した構成オプションに対するデフォルト値がセキュアでなければならないことを示していなければなりません。監査目的のために、ソフトウェアはすべてのセキュリティに関連した構成詳細を示している簡単に読めるレポートをつくることができなければなりません。

;(j) 特定の脆弱性 : 要求は、ソフトウェアで見つかってはならない一組の具体的な脆弱性を含まなければなりません。指定されていないならば、ソフトウェアは現在の「OWASP Top Ten Most Critical Web Application Vulnerabilities」で記述される瑕疵の何も含んではいけません。

===5. 要員および組織===

;(a) セキュリティ・アーキテクト : 開発者は一つの上位の技術的な資源に責任をセキュリティに指定します。そして、プロジェクトのセキュリティ・アーキテクトとして知られています。セキュリティ・アーキテクトは、個々の納品可能なもののセキュリティを保証します。

;(b) セキュリティ・トレーニング : 開発者は、開発者チームのすべてのメンバーがセキュアなプログラミング技法の訓練をされたことを確かめる役割を果たします。

;(c) 信頼できる開発者 : 開発者は、すべての開発チーム・メンバーの適切な経歴調査を実行することに同意します。

===6.開発環境===

;(a) セキュア・コーディング : 開発者は、どんなツールがセキュアなコーディングを促すためにソフトウェア開発環境で使われるかについて明らかにしなければなりません。

;(b) 構成管理 : 開発者は、ソフトウェア・ベースラインに対するすべての変更とすべての関連した設定とビルド・ファイルを関連づけ　とすべての関連した構成にすべての変化と関連したチーム・メンバーを認証して、記録して、ファイルを構築したソース・コード管理システムを使用しなければなりません。

;(c) 配布 : 開発者は、ソースから確実に完全な配布を構築するビルド・プロセスを使用しなければなりません。このプロセスは、顧客に供給されるソフトウェアの完全性を確かめる方法を含まなければなりません。

===7. ライブラリ、フレームワーク、および生産物===

;(a) 開示 : 開発者は、商用、フリー、オープンソース、クローズソースであるにせよ、すべてのライブラリ、フレームワーク、構成要素および他の生産物を含む、ソフトウェアで使われるすべての第三者のソフトウェアを明らかにしなければなりません。

;(b) 評価 : 開発者は、第三者のソフトウェアがこの契約のすべての条項を満たして、この契約のもとで開発されたカスタム開発されたコードと同じくらいセキュアなことを確実とするために、理にかなった努力をしなければなりません。

===8. セキュリティ・レビュー===

;(a) レビューする権利 : 依頼人には、ソフトウェアを納品の60日間以内にいつでも彼らの費用でセキュリティ瑕疵のためにレビューしておく権利があります。開発者は、ソース・コードとテスト環境へのアクセスを提供することによって理にかなったサポートをレビュー・チームに提供することに同意します。

;(b) レビュー・カバレッジ : セキュリティ・レビューは供給されるソフトウェアのすべての面をカバーしなければなりません。そして、カスタム・コード、構成要素、生産物とシステム設定を含みます。

;(c) レビューの範囲 : 最低限で、レビューはセキュリティ要求の全てをカバーしなければならなくて、他の一般的な脆弱性を捜さなければなりません。レビューは、脆弱性スキャン、侵入テスト、ソースコードの静的分析と専門家のコードレビューの組み合わせを含んでもよいです。

;(d) 見つけられた問題 : 発見されたセキュリティ問題は、顧客と開発者に報告されます。すべての問題は、この付属書のセキュリティ問題管理セクションにより追跡されて、矯正されます。

===9. セキュリティ問題マネジメント ===

;(a) 識別 : 要求、設計、実装、テスト、配備、または、運用中の問題にせよ、開発者は全てのライフサイクルの間に発見されるすべてのセキュリティ問題を追います。各々のセキュリティ問題に関連したリスクは、発見後できるだけ早く、評価されて、文書化されて、発見の後、顧客に報告されます。

;(b) 保護 : 開発者はセキュリティ問題と付随する文書に関して情報を適切に保護します。そして、運用中の顧客ソフトウェアの脆弱性が露出するという可能性を制限するのを助けます。

;(c) 改善 : 納品の前に確認されるセキュリティ問題は、開発者によって修正されなければなりません。納品の後に発見されるセキュリティ問題は、本契約の規定による他のバグと問題として同様に取り扱われなければなりません。

===10. 保証===

;(a) 保証 : 開発者は、開発プロセスを通して作成されるセキュリティ文書からなる「証明パッケージ」を提供します。パッケージは、セキュリティ要求、設計、実装と試験結果がきちんと完了された、そして、すべてのセキュリティ問題が適切に解決されたと確認しなければなりません。

;(b) 自己証明 : セキュリティ・アーキテクトは、ソフトウェアがセキュリティ要求を満たすこと、すべてのセキュリティ活動が実行されていること、そして、すべての識別されたセキュリティ問題が文書化されて、解決されたことを証明します。証明ステータスに対するあらゆる例外は、納品で完全に文書化されなければなりません。

;(c) 悪意のあるコードのなし : 開発者は、ソフトウェアがソフトウェア要求をサポートせず、コンピュータ・ウイルス、ワーム、時限爆弾、バック・ドア、トロイの木馬、イースターエッグと他のあらゆる形の悪意のあるソフトウェアを含む、アプリケーションのセキュリティを弱めるあらゆるコードを含んではならないと保証します。

===11. セキュリティ承認と保守 ===

;(a) 受け入れ : 証明パッケージが完全であり、すべてのセキュリティ問題が解決されるまで、ソフトウェアは受け入れられると考慮されてはいけません。

;(b) セキュリティ問題の調査 : 受理の後、セキュリティ問題が発見されるか、かなり疑われるならば、開発者は顧客が問題の性質を決定するために調査を実行するのを援助しなければなりません。それがセキュリティ要求によってカバーされないで、セキュリティ・テストの理にかなった範囲の外にあるならば、問題は「新しい」と思われなければなりません。

;(c) 新しいセキュリティ問題 : 開発者と顧客は、新しいセキュリティ問題を解決するために必要な努力を探し出すことに同意します。また、それらに取り組むために必要とされる仕事を実行するための合意を達成するために誠意を持って交渉することに同意します。

;(d) 他のセキュリティ問題 : 開発者は堅実なソフトウェア開発慣行。そして、リスクのひどさを考慮すること、そして、できるだけ速く新しいと思われないすべてのセキュリティ問題を解決することと一致したすべての商業的に理にかなった努力を使わなければなりません

[[Category:OWASP Legal Project]]

__NOTOC__

OWASP Secure Software Contract Annex/ja

2011-07-06T13:08:13Z

Tomo: /* 7. ライブラリ、フレームワーク、および生産物 */

'''セキュア・ソフトウェア開発契約付属書'''

警告：この文書は、単にガイダンスと考えられなければなりません。
OWASPは、ソフトウェア契約を交渉するのを手助けするために、
あなたが資格のある弁護士に相談するよう強く勧めます。

==序文==

OWASPセキュア・ソフトウェア開発契約付属書は、ソフトウェアの開発者とその顧客が、開発または供給されるソフトウェアのセキュリティに関連した重要な契約条項と条件を交渉し、取り込むことを助けます。このプロジェクトの理由は、多くの契約はこれらの問題に触れておらず、しばしば関係者が実際に同意されたものに劇的に異なる見解を持つことです。私たちは、これらの条項を明確に述べることは、双方の関係者が進め方について情報に基づいた意思決定ができることを確実にするもっともよい方法であると思っています。

「市場がより良いセキュリティを要求するとき、商用ソフトのセキュリティは改善します。
最低限、あらゆるソフトウェア提案依頼書は、ベンダーに彼らがセキュリティ脆弱性に対して
生産物をテストする方法を詳述するよう依頼しなければなりません。このステップは、企業が
セキュリティを評価すると市販ソフトウェアのベンダーと外部調達された開発者を納得させ始めます。」
-- John Pescatore（Gartnerのリサーチ・ディレクター）として

私たちは、顧客と開発者が、期待について議論して、責任について交渉することに対するフレームワークとしてこの文書を使うよう勧めます。この付属書は、ソフトウェア開発契約に添付されることを目的とします。これらの条項は交渉の余地があります。そして、それらは顧客と開発者によって、協議されることができて、協議されなければならないことを意味します。

==プロジェクトについて==

この文書はOpen Web Application Security Project（OWASP）財団（セキュアなソフトウェアに関連した無料でオープンなツールとドキュメンテーションを作成することを専門とする非営利の慈善団体）によって作成されました。個人契約において容易に使用できるようにするために、この文書はCC Share Alike 3.0ライセンスにて提供されます。あなたが適すると思うように、修正してもよいですし、使用してもよいです。あなたは、http://www.owasp.com/index.php/OWASP_Legal_Project でこのプロジェクトについて更なる詳細を見つけることができます。私たちは、ソフトウェア（法律コミュニティだけでなく）の製作者と消費者のコメントを歓迎します。

OWASPは、この文書の研究と準備における彼らの役割に対して [http://www.aspectsecurity.com Aspect Security] から特別な貢献を感謝して認めます。

==異論==

以下のわずかなページは、ソフトウェア開発契約においてこの言い回しを使用することに対するいくらかのたびたび聞こえる異論をカバーします：

===しかし、すべての条項が私たちにとって適切であるというわけではありません…===

この文書は、あなたの合意の開始地点です。あなたは、すべての活動が好きではないかもしれません、または、より多くの提案をしたいかもしれません。あなたは異なる責任を割り当てたいかもしれません。この文書は、すべてのソフトウェア顧客と開発者の要望を厳密に取り込むことを意図しているわけではありません。ソフトウェアが最終的にセキュアになることを確実にするために重要である、主要な項目を議論するためのフレームワークを提供することを意図します。セキュリティを議論して合意を得た後で、あなたはこの合意を適合するように調整すべきです。

===しかし、これらの活動に対して誰が代金を払わなければならないのでしょうか===

この契約は、ソフトウェア開発者により多くの負担を与えることはほとんどありません。問題は、セキュリティ ― もちろんそこにある ― と関連したコストがあるかどうかということでありません。むしろ、適切な問題はどんな活動がそれらのコストを最小にするために双方によって実行されなければならないかということです、そして、いつ、それらは起こらなければなりませんか。

この付属書は、誰がここに記述される活動の料金を払わなければならないかという問題については、意図的に語られていません。これらの活動の多くがすでに起こらなければならなくて、多くの顧客によって期待される一方、それたはソフトウェア産業で定期的に実践されることはありません。誰が（そして、いくら）支払うかという問題が、交渉の一部でなければなりません。

セキュリティのコストを計算することは、非常に難しいです。セキュリティ活動を実行することに関連したコストがある一方、それらを無視することに関連したかなりのコストもあります。私たちは、ソフトウェアを開発する最も費用対効果がよい方法について確信しています。それは、セキュリティ瑕疵が導入されるという可能性を減らして、瑕疵を導入して、それを修正することの間で時間を最小にすることです。

コストを計算するときにする一つの重要な区別は、セキュリティ手法を構築することと、それらの手法が正しくて効果的であることを確実にする保証活動の間にあります。ライフサイクルの終わりに手法を加えようとすることは、深刻な設計問題を引き起こすことがありえて、めざましくコストを増やします。この合意は、手法についての早い段階の決定がこれらのコストを最小にするのを奨励します。同様に、配備直前に保証活動（例えばコードレビューと侵入テスト）をするまで待つことはコストをめざましく増やします。私たちは、保証を得る最も費用効果がよい方法がライフサイクルを通して努力の一定のレベルを保証に入れることであると思っています。

===しかし厳密さのレベルは間違っている….===

この合意は、開発されているソフトウェアが大企業または政府機関にとってかなり重要であると仮定します。私たちは、大部分のソフトウェア開発組織によって達成できる合意のために「厳格さのレベル」を選んで、最も一般的なリスクを確認して、取り扱います。

しかし、重要なアプリケーション（例えば医学であるか、財政的であるか、防衛に関連したソフトウェア）で使われそうであるソフトウェアについては、あなたは厳格さのレベルを上げたいかもしれません。あなたは、追加のレビュー、文書化とテストの活動を加えたくてもよいです。あなたは、脆弱性を探すこと、診断すること、修正することに対するプロセスを強化しくてもよいです。より機密を扱わないアプリケーションのために、あなたは活動を減らすか、取り除きたくてもよいです。

===しかし、私たちはそれほど多くのリスクをとることができない…===

この契約は、ソフトウェアにおけるセキュリティ脆弱性に対するリスクをとるのかという議論を容易にすることを目的とします。範囲の一端では、顧客はすべてのリスクをとることができました、そして、開発者はたくさんの脆弱性をもつコードを供給することができました。他の極端では、開発者はすべてのリスクをとることができて、完全なコードを供給することに対する責任を負うことができました。これらの両極端は、どちらとも実行不可能です。

現在、この契約において、開発者は要求においてカバーされたか、理にかなったテスト努力によってカバーされるべき問題に対するリスクをとります。しかし、「新しい」セキュリティ問題の改善は、顧客によって代金を払われるべきです。私たちは、これが開発者が彼らのリスクの境界となることができて役に立つバランスで、顧客が前もってセキュリティ要求を正しくするのを奨励すると思っています。しかし、この問題の多くの他の可能性がある解決が、あります。あなたには他の提案があるかどうか私たちに知らせます、そして、私たちは彼らをこの文書の将来の版に含めてもよいです。

ここでの議論がコードにおいてセキュリティ脆弱性を修正することに関連したリスクをカバーだけして、これらの脆弱性のあらゆるエクスプロイットに基づくあらゆるセキュリティ・インシデントから立ち直ることと関連したコストを含まないことに注意すべきです。私たちは、この領域におけるベスト・プラクティスに興味があります。

===私たちはどのように第三者のコードを保証するでしょうか===

ほとんどすべてのソフトウェアプロジェクトは、第三者のコード（例えばライブラリ、フレームワークと生産物）のかなりの量を使います。このコードは、ただセキュリティ観点から、カスタム・コードがあなたのプロジェクトのために特に発達したのと同じくらい重要です。
私たちはこのコードのセキュリティを確実にすることに対する責任が開発者によって負われて最もよいと思っています、しかし、彼らにはこのセキュリティを保証するために彼ら自身のいっぱいの能力がないかもしれません。しかし、セキュリティは「構築するか、買うか」議論の一部分でなければなりません、これはそれを促進する最もよい方法のようです。

開発者は、もちろん、終わりまで第三者のソフトウェアの提供者にこの責任をパスする選択権があります。開発者は彼ら自身第三者のコードを分析することもできるか、彼らのためにそれを分析するために、セキュリティの専門家を雇うこともできます。

===しかし、なぜ私はすべてのこのトラブルにいくべきなのでしょうか===

最後に、私たちはソフトウェアを契約しているプロセスの一部分をセキュリティをすることに代わるものがないと思っています。現在では、私たちは多くのソフトウェア開発契約のもとで供給されているコードのセキュリティに関する重大な誤解があると思っています。これは、わずかなソフトウェア経験または理解とともに個人によってなされる高価な訴訟と決定に至ることができるだけです。この問題の完全な議論に対して [[Secure software contracting hypothetical case study]] （[https://www.owasp.org/index.php/Secure_software_contracting_hypothetical_case_study/ja 日本語訳]）を読んでください。

多くの利点が、この契約を通してうまくいくことにあります。主要なものは、それが関係する関係者の間で期待を明らかにするということです。場合によっては、難しいセキュリティ問題がソフトウェアで表面化するとき、それは訴訟を妨げるのを助けます。また、これらは多くの法的で調整するコンプライアンスの理由によって必要とされる同じ活動です。

===しかし、このドキュメントですべてを作ることは難しい===

OWASPは、文書化を目的とした文書化を推奨しません。この契約は品質（量ではない）を促進することに集中します。私たちは、短いリスク評価、数ページの要求、短いセキュリティ設計文書、テストプラン、いくつかのテスト結果とともに、この契約に応じることが（若干のプロジェクトにおいて）ありえると思っています。

この文書の目標は、ライフサイクルの各段階で、単に適切な注意がセキュリティに払われたことを確実とすることです。追加の利点は、この文書が基本的に、このソフトウェアが安心してそれがそれがすると主張することをするのをまかせられなければならない理由に対する議論を配置する「証明パッケージ」をつくるために一緒に集められることができるということです。

==契約付属書==

===1. 序文===

この付属書は、顧客と開発者の間で_____________________ ("合意") するために作られます。顧客と開発者は、以下の条項によりソフトウェアのセキュリティを最大にすることに同意します。

===2. 原理===

この付属書は、ソフトウェア開発関係のすべての関係者のセキュリティ関連の権利と義務をはっきりさせることを目的とします。最高レベルで、関係者は以下に同意します

;(a) セキュリティ決定は、リスクに基づきます : セキュリティについての決定は、関係するリスクのしっかりした理解に基づく顧客と開発者によって共同でなされす。

;(b) セキュリティ活動はバランスが保たれます : セキュリティ努力は、全てのソフトウェア開発ライフサイクル全体でおおよそ均一に配布されます。

;(c) セキュリティ活動は統合されます : ここに協議されるすべての活動と文書は、開発者のソフトウェア開発ライフサイクルに統合されて、残りのプロジェクトと別にしておかれるというわけではありません。この付属書の何も、どんな特定のソフトウェア開発プロセスを意味しません。

;(d) 脆弱性は予想されます : すべてのソフトウェアにはバグがあります、そして、それらのいくらかはセキュリティ問題を生じさせます。顧客と開発者は、ライフサイクルにおいてできるだけ早く脆弱性を特定するよう努めます。

;(e) セキュリティ情報は完全に明らかにされます : すべてのセキュリティ関連した情報は、すぐに、そして、完全に、顧客と開発者で共有されます。

;(f) 役に立つセキュリティ文書だけが必要とされます : セキュリティ文書は、セキュリティ設計、リスク分析または問題を明確に記述するために詳細にわたる必要はありません。

===3.ライフサイクル活動===

;(a) リスク識別 : 開発者と顧客は、アプリケーションに直面しているリスクを理解して、文書化するために協力することに同意します。この努力は、アプリケーションにより提供される重要な資産と機能への主要なリスクを確認しなければなりません。要件部にリストされるトピックの各々は、考慮されなければなりません。

;(b) 要求 : リスクに基づいて、開発者と顧客は、開発されるソフトウェアの仕様の一部として詳細なセキュリティ要件を確立するために協力することに同意します。この付属書の要件部分で記載される個々のトピックは、開発者と顧客によって協議されなければならなくて、評価されなければなりません。これらの要件は、カスタム・ソフトウェア、第三者のソフトウェアまたはプラットホームによって満たされてもよいです。

;(c) 設計 : 開発者は、セキュリティ要件の各々を達成するために明確に設計を説明する文書を提供することに同意します。ほとんどの場合、この文書はセキュリティ手法を記載します、そこで、手法はアーキテクチャに適合しました、そして、関連したすべては彼らの適正使用を確実にするためにパターンを設計します。設計は、サポートがカスタム・ソフトか、第三者のソフトウェアかプラットホームから来るかどうか、明確に指定しなければなりません。

;(d) 実装 : 開発者は、一組のセキュアなコーディング指針に提供することに、従って、一組の共通セキュリティ制御プログラミング・インターフェース（例えば [http://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API OWASP Enterprise Security API（ESAPI）] ）を使って同意します。ガイドラインは、コードがどのようにフォーマットされなければならなくて、構築されなければならなくて、コメントされなければならないかについて示します。共通セキュリティ制御プログラミング・インターフェースは、セキュリティ制御がどのように呼ばれなければならないか、そして、セキュリティ制御がどのように機能するか定めます。すべてのセキュリティに関連したコードは、十分に解説されなければなりません。共通のセキュリティ脆弱性を回避するときの具体的なガイダンスが含まれなければなりません。また、すべてのコードはセキュリティ要件に対して少なくとも他の一人の開発者によってレビューされなければなりません、そして、それの前のコーディング・ガイドラインは単体テストの準備ができていると思われます。

;(e) セキュリティ分析とテスト : 開発者は、（ [http://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project OWASP Application Security Verification Standard (ASVS)] のような）合意された標準の検証要件により、アプリケーション・セキュリティ分析とテスト（「検証」とも言われる）を実行します。開発者は、標準の報告要件によって検証結論を文書化しなければなりません。開発者は、検証結論を顧客に提供しなければなりません。

;(f) セキュリティ配備 : 開発者は、ソフトウェアの全体的なセキュリティのために完全にすべてのセキュリティ関連した構成オプションとそれらの関連性を記述するセキュアな構成ガイドラインを提供することに同意します。ガイドラインは、オペレーティングシステム、ウェブサーバとアプリケーション・サーバーを含むサポート的なプラットホームにおける依存関係の完全な記述を含まなければいけません。また、どのようにそれらをセキュリティのために構成されるべきかを含まなければいけません。ソフトウェアのデフォルトコンフィグレーションは、セキュアでなければなりません。

===4.セキュリティ要求エリア===

以下のトピック領域は、リスク理解と要求定義活動の間、考慮されなければなりません。この努力は一組の具体的で、注文仕立てで、分析できる要求を生産しなければなりません。そして、開発者と顧客はこのプロセスに関与していなければならなくて、要求の最終セットについて同意しなければなりません。

;(a) 入力検証とエンコーディング : 要求は、ユーザー、ファイルシステム、データベース、ディレクトリまたは外部システムからであるかどうかにかかわらず、アプリケーションへの各々の入力を標準化し、検証し、コード化するためにルールを指定しなければなりません。　　　デフォルトルールは、それが何が許可されるかという詳細な仕様にマッチしない限り、すべての入力が無効であるということでなければなりません。そのうえ、無効な入力が受け取られるとき、要求はとられる措置を指定しなければなりません。具体的には、アプリケーションはインジェクション、オーバフロー、不正操作することまたは他の不正な入力攻撃に影響されやすくてはいけません。

;(b) 認証とセッション管理 : 要求は、認証証明書とセッション識別子がどのようにそれらのライフサイクルを通して保護されているかについて明記しなければなりません。すべての関連する機能（パスワード忘却、パスワード変更、パスワードリマインダ、ログアウト、そして複数ログインを含む）に対する要求は含められなければいけません。

;(c) アクセス制御 : 要求は、アプリケーションで使われるすべての役割（グループ、特権、認可）の詳細な記述を含まなければなりません。要求は、アプリケーションにより提供されるすべての資産と機能も示さなければなりません。要求は、完全に各々の資産に正確なアクセス権を指定しなければならなくて、各々の役割に対して機能しなければなりません。アクセス制御マトリックスは、これらのルールのための提案されたフォーマットです。

;(d) エラー処理 : 要求は、処理の間、発生しているエラーが取り扱われる方法を詳述しなければなりません。若干のアプリケーションはエラーの場合には最もよい努力結果を提供しなければなりません、一方、他はすぐに処理を終了しなければなりません。

;(e) ロギング : 要求は、どんなイベントがセキュリティに関連して、記録される必要があるか、たとえば、検知された攻撃、失敗したログイン試行、認可を上回ろうとする試行、を指定しなければなりません。要求は、時間と日付、イベント記述、アプリケーション詳細とフォレンジクス努力に役立つ他の情報を含む、各々のイベントでどんな情報を記録するべきかについても指定しなければなりません。

;(f) 外部システムへの接続 : 要求は、認証と暗号化がどのようにすべての外部システム（例えばデータベース、ディレクトリとウェブ・サービス）のために取り扱われるかについて指定しなければなりません。外部システムでコミュニケーションのために必要とされるすべてのクレディンシャルは、暗号化された形で構成ファイルでコードの外側に保存されなければなりません。

;(g) 暗号 : 要求は、どんなデータが暗号化されなければならないか、暗号化されることがどれほどか、そして、すべての証明書と他のクレディンシャルがどのように取り扱われなければならないか指定しなければなりません。アプリケーションは、広く使われていてテストされた暗号化ライブラリで実装される標準的なアルゴリズムを使用しなければなりません。

;(h) 可用性 : 要求は、それがどのようにサービス不能攻撃から保護するかについて指定しなければなりません。アプリケーションへのすべてのありそうな攻撃は考慮されなければなりません。そして、認証ロックアウト、接続消耗と他の資源消耗攻撃を含みます。

;(i) セキュアな設定 : 要求は、すべてのセキュリティに関連した構成オプションに対するデフォルト値がセキュアでなければならないことを示していなければなりません。監査目的のために、ソフトウェアはすべてのセキュリティに関連した構成詳細を示している簡単に読めるレポートをつくることができなければなりません。

;(j) 特定の脆弱性 : 要求は、ソフトウェアで見つかってはならない一組の具体的な脆弱性を含まなければなりません。指定されていないならば、ソフトウェアは現在の「OWASP Top Ten Most Critical Web Application Vulnerabilities」で記述される瑕疵の何も含んではいけません。

===5. 要員および組織===

;(a) セキュリティ・アーキテクト : 開発者は一つの上位の技術的な資源に責任をセキュリティに指定します。そして、プロジェクトのセキュリティ・アーキテクトとして知られています。セキュリティ・アーキテクトは、個々の納品可能なもののセキュリティを保証します。

;(b) セキュリティ・トレーニング : 開発者は、開発者チームのすべてのメンバーがセキュアなプログラミング技法の訓練をされたことを確かめる役割を果たします。

;(c) 信頼できる開発者 : 開発者は、すべての開発チーム・メンバーの適切な経歴調査を実行することに同意します。

===6.開発環境===

;(a) セキュア・コーディング : 開発者は、どんなツールがセキュアなコーディングを促すためにソフトウェア開発環境で使われるかについて明らかにしなければなりません。

;(b) 構成管理 : 開発者は、ソフトウェア・ベースラインに対するすべての変更とすべての関連した設定とビルド・ファイルを関連づけ　とすべての関連した構成にすべての変化と関連したチーム・メンバーを認証して、記録して、ファイルを構築したソース・コード管理システムを使用しなければなりません。

;(c) 配布 : 開発者は、ソースから確実に完全な配布を構築するビルド・プロセスを使用しなければなりません。このプロセスは、顧客に供給されるソフトウェアの完全性を確かめる方法を含まなければなりません。

===7. ライブラリ、フレームワーク、および生産物===

;(a) 開示 : 開発者は、商用、フリー、オープンソース、クローズソースであるにせよ、すべてのライブラリ、フレームワーク、構成要素および他の生産物を含む、ソフトウェアで使われるすべての第三者のソフトウェアを明らかにしなければなりません。

;(b) 評価 : 開発者は、第三者のソフトウェアがこの契約のすべての条項を満たして、この契約のもとで開発されたカスタム開発されたコードと同じくらいセキュアなことを確実とするために、理にかなった努力をしなければなりません。

===8. セキュリティ・レビュー===

;(a) レビューする権利 : 依頼人には、ソフトウェアを納品の60日間以内にいつでも彼らの費用でセキュリティ瑕疵のためにレビューしておく権利があります。開発者は、ソース・コードとテスト環境へのアクセスを提供することによって理にかなったサポートをレビュー・チームに提供することに同意します。

;(b) レビュー・カバレッジ : セキュリティ・レビューは供給されるソフトウェアのすべての面をカバーしなければなりません。そして、カスタム・コード、構成要素、生産物とシステム設定を含みます。

;(c) レビューの範囲 : 最低限で、レビューはセキュリティ要求の全てをカバーしなければならなくて、他の一般的な脆弱性を捜さなければなりません。レビューは、脆弱性スキャン、侵入テスト、ソースコードの静的分析と専門家のコードレビューの組み合わせを含んでもよいです。

;(d) 見つけられた問題 : 発見されたセキュリティ問題は、顧客と開発者に報告されます。すべての問題は、この付属書のセキュリティ問題マネジメント部分により追跡されて、矯正されます。

===9. セキュリティ問題マネジメント ===

;(a) 識別 : 要求、設計、実装、テスト、配備、または、運用中の問題にせよ、開発者は全てのライフサイクルの間に発見されるすべてのセキュリティ問題を追います。各々のセキュリティ問題に関連したリスクは、発見後できるだけ早く、評価されて、文書化されて、発見の後、顧客に報告されます。

;(b) 保護 : 開発者はセキュリティ問題と付随する文書に関して情報を適切に保護します。そして、運用中の顧客ソフトウェアの脆弱性が露出するという可能性を制限するのを助けます。

;(c) 改善 : 納品の前に確認されるセキュリティ問題は、開発者によって修正されなければなりません。納品の後に発見されるセキュリティ問題は、本契約の規定による他のバグと問題として同様に取り扱われなければなりません。

===10. 保証===

;(a) 保証 : 開発者は、開発プロセスを通して作成されるセキュリティ文書からなる「証明パッケージ」を提供します。パッケージは、セキュリティ要求、設計、実装と試験結果がきちんと完了された、そして、すべてのセキュリティ問題が適切に解決されたと確認しなければなりません。

;(b) 自己証明 : セキュリティ・アーキテクトは、ソフトウェアがセキュリティ要求を満たすこと、すべてのセキュリティ活動が実行されていること、そして、すべての識別されたセキュリティ問題が文書化されて、解決されたことを証明します。証明ステータスに対するあらゆる例外は、納品で完全に文書化されなければなりません。

;(c) 悪意のあるコードのなし : 開発者は、ソフトウェアがソフトウェア要求をサポートせず、コンピュータ・ウイルス、ワーム、時限爆弾、バック・ドア、トロイの木馬、イースターエッグと他のあらゆる形の悪意のあるソフトウェアを含む、アプリケーションのセキュリティを弱めるあらゆるコードを含んではならないと保証します。

===11. セキュリティ承認と保守 ===

;(a) 受け入れ : 証明パッケージが完全であり、すべてのセキュリティ問題が解決されるまで、ソフトウェアは受け入れられると考慮されてはいけません。

;(b) セキュリティ問題の調査 : 受理の後、セキュリティ問題が発見されるか、かなり疑われるならば、開発者は顧客が問題の性質を決定するために調査を実行するのを援助しなければなりません。それがセキュリティ要求によってカバーされないで、セキュリティ・テストの理にかなった範囲の外にあるならば、問題は「新しい」と思われなければなりません。

;(c) 新しいセキュリティ問題 : 開発者と顧客は、新しいセキュリティ問題を解決するために必要な努力を探し出すことに同意します。また、それらに取り組むために必要とされる仕事を実行するための合意を達成するために誠意を持って交渉することに同意します。

;(d) 他のセキュリティ問題 : 開発者は堅実なソフトウェア開発慣行。そして、リスクのひどさを考慮すること、そして、できるだけ速く新しいと思われないすべてのセキュリティ問題を解決することと一致したすべての商業的に理にかなった努力を使わなければなりません

[[Category:OWASP Legal Project]]

__NOTOC__

OWASP Secure Software Contract Annex/ja

2011-07-06T13:04:20Z

Tomo: /* 5. 要員および組織 */

'''セキュア・ソフトウェア開発契約付属書'''

警告：この文書は、単にガイダンスと考えられなければなりません。
OWASPは、ソフトウェア契約を交渉するのを手助けするために、
あなたが資格のある弁護士に相談するよう強く勧めます。

==序文==

OWASPセキュア・ソフトウェア開発契約付属書は、ソフトウェアの開発者とその顧客が、開発または供給されるソフトウェアのセキュリティに関連した重要な契約条項と条件を交渉し、取り込むことを助けます。このプロジェクトの理由は、多くの契約はこれらの問題に触れておらず、しばしば関係者が実際に同意されたものに劇的に異なる見解を持つことです。私たちは、これらの条項を明確に述べることは、双方の関係者が進め方について情報に基づいた意思決定ができることを確実にするもっともよい方法であると思っています。

「市場がより良いセキュリティを要求するとき、商用ソフトのセキュリティは改善します。
最低限、あらゆるソフトウェア提案依頼書は、ベンダーに彼らがセキュリティ脆弱性に対して
生産物をテストする方法を詳述するよう依頼しなければなりません。このステップは、企業が
セキュリティを評価すると市販ソフトウェアのベンダーと外部調達された開発者を納得させ始めます。」
-- John Pescatore（Gartnerのリサーチ・ディレクター）として

私たちは、顧客と開発者が、期待について議論して、責任について交渉することに対するフレームワークとしてこの文書を使うよう勧めます。この付属書は、ソフトウェア開発契約に添付されることを目的とします。これらの条項は交渉の余地があります。そして、それらは顧客と開発者によって、協議されることができて、協議されなければならないことを意味します。

==プロジェクトについて==

この文書はOpen Web Application Security Project（OWASP）財団（セキュアなソフトウェアに関連した無料でオープンなツールとドキュメンテーションを作成することを専門とする非営利の慈善団体）によって作成されました。個人契約において容易に使用できるようにするために、この文書はCC Share Alike 3.0ライセンスにて提供されます。あなたが適すると思うように、修正してもよいですし、使用してもよいです。あなたは、http://www.owasp.com/index.php/OWASP_Legal_Project でこのプロジェクトについて更なる詳細を見つけることができます。私たちは、ソフトウェア（法律コミュニティだけでなく）の製作者と消費者のコメントを歓迎します。

OWASPは、この文書の研究と準備における彼らの役割に対して [http://www.aspectsecurity.com Aspect Security] から特別な貢献を感謝して認めます。

==異論==

以下のわずかなページは、ソフトウェア開発契約においてこの言い回しを使用することに対するいくらかのたびたび聞こえる異論をカバーします：

===しかし、すべての条項が私たちにとって適切であるというわけではありません…===

この文書は、あなたの合意の開始地点です。あなたは、すべての活動が好きではないかもしれません、または、より多くの提案をしたいかもしれません。あなたは異なる責任を割り当てたいかもしれません。この文書は、すべてのソフトウェア顧客と開発者の要望を厳密に取り込むことを意図しているわけではありません。ソフトウェアが最終的にセキュアになることを確実にするために重要である、主要な項目を議論するためのフレームワークを提供することを意図します。セキュリティを議論して合意を得た後で、あなたはこの合意を適合するように調整すべきです。

===しかし、これらの活動に対して誰が代金を払わなければならないのでしょうか===

この契約は、ソフトウェア開発者により多くの負担を与えることはほとんどありません。問題は、セキュリティ ― もちろんそこにある ― と関連したコストがあるかどうかということでありません。むしろ、適切な問題はどんな活動がそれらのコストを最小にするために双方によって実行されなければならないかということです、そして、いつ、それらは起こらなければなりませんか。

この付属書は、誰がここに記述される活動の料金を払わなければならないかという問題については、意図的に語られていません。これらの活動の多くがすでに起こらなければならなくて、多くの顧客によって期待される一方、それたはソフトウェア産業で定期的に実践されることはありません。誰が（そして、いくら）支払うかという問題が、交渉の一部でなければなりません。

セキュリティのコストを計算することは、非常に難しいです。セキュリティ活動を実行することに関連したコストがある一方、それらを無視することに関連したかなりのコストもあります。私たちは、ソフトウェアを開発する最も費用対効果がよい方法について確信しています。それは、セキュリティ瑕疵が導入されるという可能性を減らして、瑕疵を導入して、それを修正することの間で時間を最小にすることです。

コストを計算するときにする一つの重要な区別は、セキュリティ手法を構築することと、それらの手法が正しくて効果的であることを確実にする保証活動の間にあります。ライフサイクルの終わりに手法を加えようとすることは、深刻な設計問題を引き起こすことがありえて、めざましくコストを増やします。この合意は、手法についての早い段階の決定がこれらのコストを最小にするのを奨励します。同様に、配備直前に保証活動（例えばコードレビューと侵入テスト）をするまで待つことはコストをめざましく増やします。私たちは、保証を得る最も費用効果がよい方法がライフサイクルを通して努力の一定のレベルを保証に入れることであると思っています。

===しかし厳密さのレベルは間違っている….===

この合意は、開発されているソフトウェアが大企業または政府機関にとってかなり重要であると仮定します。私たちは、大部分のソフトウェア開発組織によって達成できる合意のために「厳格さのレベル」を選んで、最も一般的なリスクを確認して、取り扱います。

しかし、重要なアプリケーション（例えば医学であるか、財政的であるか、防衛に関連したソフトウェア）で使われそうであるソフトウェアについては、あなたは厳格さのレベルを上げたいかもしれません。あなたは、追加のレビュー、文書化とテストの活動を加えたくてもよいです。あなたは、脆弱性を探すこと、診断すること、修正することに対するプロセスを強化しくてもよいです。より機密を扱わないアプリケーションのために、あなたは活動を減らすか、取り除きたくてもよいです。

===しかし、私たちはそれほど多くのリスクをとることができない…===

この契約は、ソフトウェアにおけるセキュリティ脆弱性に対するリスクをとるのかという議論を容易にすることを目的とします。範囲の一端では、顧客はすべてのリスクをとることができました、そして、開発者はたくさんの脆弱性をもつコードを供給することができました。他の極端では、開発者はすべてのリスクをとることができて、完全なコードを供給することに対する責任を負うことができました。これらの両極端は、どちらとも実行不可能です。

現在、この契約において、開発者は要求においてカバーされたか、理にかなったテスト努力によってカバーされるべき問題に対するリスクをとります。しかし、「新しい」セキュリティ問題の改善は、顧客によって代金を払われるべきです。私たちは、これが開発者が彼らのリスクの境界となることができて役に立つバランスで、顧客が前もってセキュリティ要求を正しくするのを奨励すると思っています。しかし、この問題の多くの他の可能性がある解決が、あります。あなたには他の提案があるかどうか私たちに知らせます、そして、私たちは彼らをこの文書の将来の版に含めてもよいです。

ここでの議論がコードにおいてセキュリティ脆弱性を修正することに関連したリスクをカバーだけして、これらの脆弱性のあらゆるエクスプロイットに基づくあらゆるセキュリティ・インシデントから立ち直ることと関連したコストを含まないことに注意すべきです。私たちは、この領域におけるベスト・プラクティスに興味があります。

===私たちはどのように第三者のコードを保証するでしょうか===

ほとんどすべてのソフトウェアプロジェクトは、第三者のコード（例えばライブラリ、フレームワークと生産物）のかなりの量を使います。このコードは、ただセキュリティ観点から、カスタム・コードがあなたのプロジェクトのために特に発達したのと同じくらい重要です。
私たちはこのコードのセキュリティを確実にすることに対する責任が開発者によって負われて最もよいと思っています、しかし、彼らにはこのセキュリティを保証するために彼ら自身のいっぱいの能力がないかもしれません。しかし、セキュリティは「構築するか、買うか」議論の一部分でなければなりません、これはそれを促進する最もよい方法のようです。

開発者は、もちろん、終わりまで第三者のソフトウェアの提供者にこの責任をパスする選択権があります。開発者は彼ら自身第三者のコードを分析することもできるか、彼らのためにそれを分析するために、セキュリティの専門家を雇うこともできます。

===しかし、なぜ私はすべてのこのトラブルにいくべきなのでしょうか===

最後に、私たちはソフトウェアを契約しているプロセスの一部分をセキュリティをすることに代わるものがないと思っています。現在では、私たちは多くのソフトウェア開発契約のもとで供給されているコードのセキュリティに関する重大な誤解があると思っています。これは、わずかなソフトウェア経験または理解とともに個人によってなされる高価な訴訟と決定に至ることができるだけです。この問題の完全な議論に対して [[Secure software contracting hypothetical case study]] （[https://www.owasp.org/index.php/Secure_software_contracting_hypothetical_case_study/ja 日本語訳]）を読んでください。

多くの利点が、この契約を通してうまくいくことにあります。主要なものは、それが関係する関係者の間で期待を明らかにするということです。場合によっては、難しいセキュリティ問題がソフトウェアで表面化するとき、それは訴訟を妨げるのを助けます。また、これらは多くの法的で調整するコンプライアンスの理由によって必要とされる同じ活動です。

===しかし、このドキュメントですべてを作ることは難しい===

OWASPは、文書化を目的とした文書化を推奨しません。この契約は品質（量ではない）を促進することに集中します。私たちは、短いリスク評価、数ページの要求、短いセキュリティ設計文書、テストプラン、いくつかのテスト結果とともに、この契約に応じることが（若干のプロジェクトにおいて）ありえると思っています。

この文書の目標は、ライフサイクルの各段階で、単に適切な注意がセキュリティに払われたことを確実とすることです。追加の利点は、この文書が基本的に、このソフトウェアが安心してそれがそれがすると主張することをするのをまかせられなければならない理由に対する議論を配置する「証明パッケージ」をつくるために一緒に集められることができるということです。

==契約付属書==

===1. 序文===

この付属書は、顧客と開発者の間で_____________________ ("合意") するために作られます。顧客と開発者は、以下の条項によりソフトウェアのセキュリティを最大にすることに同意します。

===2. 原理===

この付属書は、ソフトウェア開発関係のすべての関係者のセキュリティ関連の権利と義務をはっきりさせることを目的とします。最高レベルで、関係者は以下に同意します

;(a) セキュリティ決定は、リスクに基づきます : セキュリティについての決定は、関係するリスクのしっかりした理解に基づく顧客と開発者によって共同でなされす。

;(b) セキュリティ活動はバランスが保たれます : セキュリティ努力は、全てのソフトウェア開発ライフサイクル全体でおおよそ均一に配布されます。

;(c) セキュリティ活動は統合されます : ここに協議されるすべての活動と文書は、開発者のソフトウェア開発ライフサイクルに統合されて、残りのプロジェクトと別にしておかれるというわけではありません。この付属書の何も、どんな特定のソフトウェア開発プロセスを意味しません。

;(d) 脆弱性は予想されます : すべてのソフトウェアにはバグがあります、そして、それらのいくらかはセキュリティ問題を生じさせます。顧客と開発者は、ライフサイクルにおいてできるだけ早く脆弱性を特定するよう努めます。

;(e) セキュリティ情報は完全に明らかにされます : すべてのセキュリティ関連した情報は、すぐに、そして、完全に、顧客と開発者で共有されます。

;(f) 役に立つセキュリティ文書だけが必要とされます : セキュリティ文書は、セキュリティ設計、リスク分析または問題を明確に記述するために詳細にわたる必要はありません。

===3.ライフサイクル活動===

;(a) リスク識別 : 開発者と顧客は、アプリケーションに直面しているリスクを理解して、文書化するために協力することに同意します。この努力は、アプリケーションにより提供される重要な資産と機能への主要なリスクを確認しなければなりません。要件部にリストされるトピックの各々は、考慮されなければなりません。

;(b) 要求 : リスクに基づいて、開発者と顧客は、開発されるソフトウェアの仕様の一部として詳細なセキュリティ要件を確立するために協力することに同意します。この付属書の要件部分で記載される個々のトピックは、開発者と顧客によって協議されなければならなくて、評価されなければなりません。これらの要件は、カスタム・ソフトウェア、第三者のソフトウェアまたはプラットホームによって満たされてもよいです。

;(c) 設計 : 開発者は、セキュリティ要件の各々を達成するために明確に設計を説明する文書を提供することに同意します。ほとんどの場合、この文書はセキュリティ手法を記載します、そこで、手法はアーキテクチャに適合しました、そして、関連したすべては彼らの適正使用を確実にするためにパターンを設計します。設計は、サポートがカスタム・ソフトか、第三者のソフトウェアかプラットホームから来るかどうか、明確に指定しなければなりません。

;(d) 実装 : 開発者は、一組のセキュアなコーディング指針に提供することに、従って、一組の共通セキュリティ制御プログラミング・インターフェース（例えば [http://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API OWASP Enterprise Security API（ESAPI）] ）を使って同意します。ガイドラインは、コードがどのようにフォーマットされなければならなくて、構築されなければならなくて、コメントされなければならないかについて示します。共通セキュリティ制御プログラミング・インターフェースは、セキュリティ制御がどのように呼ばれなければならないか、そして、セキュリティ制御がどのように機能するか定めます。すべてのセキュリティに関連したコードは、十分に解説されなければなりません。共通のセキュリティ脆弱性を回避するときの具体的なガイダンスが含まれなければなりません。また、すべてのコードはセキュリティ要件に対して少なくとも他の一人の開発者によってレビューされなければなりません、そして、それの前のコーディング・ガイドラインは単体テストの準備ができていると思われます。

;(e) セキュリティ分析とテスト : 開発者は、（ [http://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project OWASP Application Security Verification Standard (ASVS)] のような）合意された標準の検証要件により、アプリケーション・セキュリティ分析とテスト（「検証」とも言われる）を実行します。開発者は、標準の報告要件によって検証結論を文書化しなければなりません。開発者は、検証結論を顧客に提供しなければなりません。

;(f) セキュリティ配備 : 開発者は、ソフトウェアの全体的なセキュリティのために完全にすべてのセキュリティ関連した構成オプションとそれらの関連性を記述するセキュアな構成ガイドラインを提供することに同意します。ガイドラインは、オペレーティングシステム、ウェブサーバとアプリケーション・サーバーを含むサポート的なプラットホームにおける依存関係の完全な記述を含まなければいけません。また、どのようにそれらをセキュリティのために構成されるべきかを含まなければいけません。ソフトウェアのデフォルトコンフィグレーションは、セキュアでなければなりません。

===4.セキュリティ要求エリア===

以下のトピック領域は、リスク理解と要求定義活動の間、考慮されなければなりません。この努力は一組の具体的で、注文仕立てで、分析できる要求を生産しなければなりません。そして、開発者と顧客はこのプロセスに関与していなければならなくて、要求の最終セットについて同意しなければなりません。

;(a) 入力検証とエンコーディング : 要求は、ユーザー、ファイルシステム、データベース、ディレクトリまたは外部システムからであるかどうかにかかわらず、アプリケーションへの各々の入力を標準化し、検証し、コード化するためにルールを指定しなければなりません。　　　デフォルトルールは、それが何が許可されるかという詳細な仕様にマッチしない限り、すべての入力が無効であるということでなければなりません。そのうえ、無効な入力が受け取られるとき、要求はとられる措置を指定しなければなりません。具体的には、アプリケーションはインジェクション、オーバフロー、不正操作することまたは他の不正な入力攻撃に影響されやすくてはいけません。

;(b) 認証とセッション管理 : 要求は、認証証明書とセッション識別子がどのようにそれらのライフサイクルを通して保護されているかについて明記しなければなりません。すべての関連する機能（パスワード忘却、パスワード変更、パスワードリマインダ、ログアウト、そして複数ログインを含む）に対する要求は含められなければいけません。

;(c) アクセス制御 : 要求は、アプリケーションで使われるすべての役割（グループ、特権、認可）の詳細な記述を含まなければなりません。要求は、アプリケーションにより提供されるすべての資産と機能も示さなければなりません。要求は、完全に各々の資産に正確なアクセス権を指定しなければならなくて、各々の役割に対して機能しなければなりません。アクセス制御マトリックスは、これらのルールのための提案されたフォーマットです。

;(d) エラー処理 : 要求は、処理の間、発生しているエラーが取り扱われる方法を詳述しなければなりません。若干のアプリケーションはエラーの場合には最もよい努力結果を提供しなければなりません、一方、他はすぐに処理を終了しなければなりません。

;(e) ロギング : 要求は、どんなイベントがセキュリティに関連して、記録される必要があるか、たとえば、検知された攻撃、失敗したログイン試行、認可を上回ろうとする試行、を指定しなければなりません。要求は、時間と日付、イベント記述、アプリケーション詳細とフォレンジクス努力に役立つ他の情報を含む、各々のイベントでどんな情報を記録するべきかについても指定しなければなりません。

;(f) 外部システムへの接続 : 要求は、認証と暗号化がどのようにすべての外部システム（例えばデータベース、ディレクトリとウェブ・サービス）のために取り扱われるかについて指定しなければなりません。外部システムでコミュニケーションのために必要とされるすべてのクレディンシャルは、暗号化された形で構成ファイルでコードの外側に保存されなければなりません。

;(g) 暗号 : 要求は、どんなデータが暗号化されなければならないか、暗号化されることがどれほどか、そして、すべての証明書と他のクレディンシャルがどのように取り扱われなければならないか指定しなければなりません。アプリケーションは、広く使われていてテストされた暗号化ライブラリで実装される標準的なアルゴリズムを使用しなければなりません。

;(h) 可用性 : 要求は、それがどのようにサービス不能攻撃から保護するかについて指定しなければなりません。アプリケーションへのすべてのありそうな攻撃は考慮されなければなりません。そして、認証ロックアウト、接続消耗と他の資源消耗攻撃を含みます。

;(i) セキュアな設定 : 要求は、すべてのセキュリティに関連した構成オプションに対するデフォルト値がセキュアでなければならないことを示していなければなりません。監査目的のために、ソフトウェアはすべてのセキュリティに関連した構成詳細を示している簡単に読めるレポートをつくることができなければなりません。

;(j) 特定の脆弱性 : 要求は、ソフトウェアで見つかってはならない一組の具体的な脆弱性を含まなければなりません。指定されていないならば、ソフトウェアは現在の「OWASP Top Ten Most Critical Web Application Vulnerabilities」で記述される瑕疵の何も含んではいけません。

===5. 要員および組織===

;(a) セキュリティ・アーキテクト : 開発者は一つの上位の技術的な資源に責任をセキュリティに指定します。そして、プロジェクトのセキュリティ・アーキテクトとして知られています。セキュリティ・アーキテクトは、個々の納品可能なもののセキュリティを保証します。

;(b) セキュリティ・トレーニング : 開発者は、開発者チームのすべてのメンバーがセキュアなプログラミング技法の訓練をされたことを確かめる役割を果たします。

;(c) 信頼できる開発者 : 開発者は、すべての開発チーム・メンバーの適切な経歴調査を実行することに同意します。

===6.開発環境===

;(a) セキュア・コーディング : 開発者は、どんなツールがセキュアなコーディングを促すためにソフトウェア開発環境で使われるかについて明らかにしなければなりません。

;(b) 構成管理 : 開発者は、ソフトウェア・ベースラインに対するすべての変更とすべての関連した設定とビルド・ファイルを関連づけ　とすべての関連した構成にすべての変化と関連したチーム・メンバーを認証して、記録して、ファイルを構築したソース・コード管理システムを使用しなければなりません。

;(c) 配布 : 開発者は、ソースから確実に完全な配布を構築するビルド・プロセスを使用しなければなりません。このプロセスは、顧客に供給されるソフトウェアの完全性を確かめる方法を含まなければなりません。

===7. ライブラリ、フレームワーク、および生産物===

;(a) 開示 : 開発者は、商用、フリー、オープンソース、クローズソースであるにせよ、すべてのライブラリ、フレームワーク、構成要素と他の生産物を含む、ソフトウェアで使われるすべての第三者のソフトウェアを明らかにしなければなりません。

;(b) 評価 : 開発者は、第三者のソフトウェアがこの契約のすべての条件を満たして、この契約の基で開発されたカスタム開発されたコードと同じくらいセキュアなことを確実とするために、理にかなった努力をしなければなりません。

===8. セキュリティ・レビュー===

;(a) レビューする権利 : 依頼人には、ソフトウェアを納品の60日間以内にいつでも彼らの費用でセキュリティ瑕疵のためにレビューしておく権利があります。開発者は、ソース・コードとテスト環境へのアクセスを提供することによって理にかなったサポートをレビュー・チームに提供することに同意します。

;(b) レビュー・カバレッジ : セキュリティ・レビューは供給されるソフトウェアのすべての面をカバーしなければなりません。そして、カスタム・コード、構成要素、生産物とシステム設定を含みます。

;(c) レビューの範囲 : 最低限で、レビューはセキュリティ要求の全てをカバーしなければならなくて、他の一般的な脆弱性を捜さなければなりません。レビューは、脆弱性スキャン、侵入テスト、ソースコードの静的分析と専門家のコードレビューの組み合わせを含んでもよいです。

;(d) 見つけられた問題 : 発見されたセキュリティ問題は、顧客と開発者に報告されます。すべての問題は、この付属書のセキュリティ問題マネジメント部分により追跡されて、矯正されます。

===9. セキュリティ問題マネジメント ===

;(a) 識別 : 要求、設計、実装、テスト、配備、または、運用中の問題にせよ、開発者は全てのライフサイクルの間に発見されるすべてのセキュリティ問題を追います。各々のセキュリティ問題に関連したリスクは、発見後できるだけ早く、評価されて、文書化されて、発見の後、顧客に報告されます。

;(b) 保護 : 開発者はセキュリティ問題と付随する文書に関して情報を適切に保護します。そして、運用中の顧客ソフトウェアの脆弱性が露出するという可能性を制限するのを助けます。

;(c) 改善 : 納品の前に確認されるセキュリティ問題は、開発者によって修正されなければなりません。納品の後に発見されるセキュリティ問題は、本契約の規定による他のバグと問題として同様に取り扱われなければなりません。

===10. 保証===

;(a) 保証 : 開発者は、開発プロセスを通して作成されるセキュリティ文書からなる「証明パッケージ」を提供します。パッケージは、セキュリティ要求、設計、実装と試験結果がきちんと完了された、そして、すべてのセキュリティ問題が適切に解決されたと確認しなければなりません。

;(b) 自己証明 : セキュリティ・アーキテクトは、ソフトウェアがセキュリティ要求を満たすこと、すべてのセキュリティ活動が実行されていること、そして、すべての識別されたセキュリティ問題が文書化されて、解決されたことを証明します。証明ステータスに対するあらゆる例外は、納品で完全に文書化されなければなりません。

;(c) 悪意のあるコードのなし : 開発者は、ソフトウェアがソフトウェア要求をサポートせず、コンピュータ・ウイルス、ワーム、時限爆弾、バック・ドア、トロイの木馬、イースターエッグと他のあらゆる形の悪意のあるソフトウェアを含む、アプリケーションのセキュリティを弱めるあらゆるコードを含んではならないと保証します。

===11. セキュリティ承認と保守 ===

;(a) 受け入れ : 証明パッケージが完全であり、すべてのセキュリティ問題が解決されるまで、ソフトウェアは受け入れられると考慮されてはいけません。

;(b) セキュリティ問題の調査 : 受理の後、セキュリティ問題が発見されるか、かなり疑われるならば、開発者は顧客が問題の性質を決定するために調査を実行するのを援助しなければなりません。それがセキュリティ要求によってカバーされないで、セキュリティ・テストの理にかなった範囲の外にあるならば、問題は「新しい」と思われなければなりません。

;(c) 新しいセキュリティ問題 : 開発者と顧客は、新しいセキュリティ問題を解決するために必要な努力を探し出すことに同意します。また、それらに取り組むために必要とされる仕事を実行するための合意を達成するために誠意を持って交渉することに同意します。

;(d) 他のセキュリティ問題 : 開発者は堅実なソフトウェア開発慣行。そして、リスクのひどさを考慮すること、そして、できるだけ速く新しいと思われないすべてのセキュリティ問題を解決することと一致したすべての商業的に理にかなった努力を使わなければなりません

[[Category:OWASP Legal Project]]

__NOTOC__

OWASP Secure Software Contract Annex/ja

2011-07-06T12:45:00Z

Tomo: /* 3.ライフサイクル活動 */

'''セキュア・ソフトウェア開発契約付属書'''

警告：この文書は、単にガイダンスと考えられなければなりません。
OWASPは、ソフトウェア契約を交渉するのを手助けするために、
あなたが資格のある弁護士に相談するよう強く勧めます。

==序文==

OWASPセキュア・ソフトウェア開発契約付属書は、ソフトウェアの開発者とその顧客が、開発または供給されるソフトウェアのセキュリティに関連した重要な契約条項と条件を交渉し、取り込むことを助けます。このプロジェクトの理由は、多くの契約はこれらの問題に触れておらず、しばしば関係者が実際に同意されたものに劇的に異なる見解を持つことです。私たちは、これらの条項を明確に述べることは、双方の関係者が進め方について情報に基づいた意思決定ができることを確実にするもっともよい方法であると思っています。

「市場がより良いセキュリティを要求するとき、商用ソフトのセキュリティは改善します。
最低限、あらゆるソフトウェア提案依頼書は、ベンダーに彼らがセキュリティ脆弱性に対して
生産物をテストする方法を詳述するよう依頼しなければなりません。このステップは、企業が
セキュリティを評価すると市販ソフトウェアのベンダーと外部調達された開発者を納得させ始めます。」
-- John Pescatore（Gartnerのリサーチ・ディレクター）として

私たちは、顧客と開発者が、期待について議論して、責任について交渉することに対するフレームワークとしてこの文書を使うよう勧めます。この付属書は、ソフトウェア開発契約に添付されることを目的とします。これらの条項は交渉の余地があります。そして、それらは顧客と開発者によって、協議されることができて、協議されなければならないことを意味します。

==プロジェクトについて==

この文書はOpen Web Application Security Project（OWASP）財団（セキュアなソフトウェアに関連した無料でオープンなツールとドキュメンテーションを作成することを専門とする非営利の慈善団体）によって作成されました。個人契約において容易に使用できるようにするために、この文書はCC Share Alike 3.0ライセンスにて提供されます。あなたが適すると思うように、修正してもよいですし、使用してもよいです。あなたは、http://www.owasp.com/index.php/OWASP_Legal_Project でこのプロジェクトについて更なる詳細を見つけることができます。私たちは、ソフトウェア（法律コミュニティだけでなく）の製作者と消費者のコメントを歓迎します。

OWASPは、この文書の研究と準備における彼らの役割に対して [http://www.aspectsecurity.com Aspect Security] から特別な貢献を感謝して認めます。

==異論==

以下のわずかなページは、ソフトウェア開発契約においてこの言い回しを使用することに対するいくらかのたびたび聞こえる異論をカバーします：

===しかし、すべての条項が私たちにとって適切であるというわけではありません…===

この文書は、あなたの合意の開始地点です。あなたは、すべての活動が好きではないかもしれません、または、より多くの提案をしたいかもしれません。あなたは異なる責任を割り当てたいかもしれません。この文書は、すべてのソフトウェア顧客と開発者の要望を厳密に取り込むことを意図しているわけではありません。ソフトウェアが最終的にセキュアになることを確実にするために重要である、主要な項目を議論するためのフレームワークを提供することを意図します。セキュリティを議論して合意を得た後で、あなたはこの合意を適合するように調整すべきです。

===しかし、これらの活動に対して誰が代金を払わなければならないのでしょうか===

この契約は、ソフトウェア開発者により多くの負担を与えることはほとんどありません。問題は、セキュリティ ― もちろんそこにある ― と関連したコストがあるかどうかということでありません。むしろ、適切な問題はどんな活動がそれらのコストを最小にするために双方によって実行されなければならないかということです、そして、いつ、それらは起こらなければなりませんか。

この付属書は、誰がここに記述される活動の料金を払わなければならないかという問題については、意図的に語られていません。これらの活動の多くがすでに起こらなければならなくて、多くの顧客によって期待される一方、それたはソフトウェア産業で定期的に実践されることはありません。誰が（そして、いくら）支払うかという問題が、交渉の一部でなければなりません。

セキュリティのコストを計算することは、非常に難しいです。セキュリティ活動を実行することに関連したコストがある一方、それらを無視することに関連したかなりのコストもあります。私たちは、ソフトウェアを開発する最も費用対効果がよい方法について確信しています。それは、セキュリティ瑕疵が導入されるという可能性を減らして、瑕疵を導入して、それを修正することの間で時間を最小にすることです。

コストを計算するときにする一つの重要な区別は、セキュリティ手法を構築することと、それらの手法が正しくて効果的であることを確実にする保証活動の間にあります。ライフサイクルの終わりに手法を加えようとすることは、深刻な設計問題を引き起こすことがありえて、めざましくコストを増やします。この合意は、手法についての早い段階の決定がこれらのコストを最小にするのを奨励します。同様に、配備直前に保証活動（例えばコードレビューと侵入テスト）をするまで待つことはコストをめざましく増やします。私たちは、保証を得る最も費用効果がよい方法がライフサイクルを通して努力の一定のレベルを保証に入れることであると思っています。

===しかし厳密さのレベルは間違っている….===

この合意は、開発されているソフトウェアが大企業または政府機関にとってかなり重要であると仮定します。私たちは、大部分のソフトウェア開発組織によって達成できる合意のために「厳格さのレベル」を選んで、最も一般的なリスクを確認して、取り扱います。

しかし、重要なアプリケーション（例えば医学であるか、財政的であるか、防衛に関連したソフトウェア）で使われそうであるソフトウェアについては、あなたは厳格さのレベルを上げたいかもしれません。あなたは、追加のレビュー、文書化とテストの活動を加えたくてもよいです。あなたは、脆弱性を探すこと、診断すること、修正することに対するプロセスを強化しくてもよいです。より機密を扱わないアプリケーションのために、あなたは活動を減らすか、取り除きたくてもよいです。

===しかし、私たちはそれほど多くのリスクをとることができない…===

この契約は、ソフトウェアにおけるセキュリティ脆弱性に対するリスクをとるのかという議論を容易にすることを目的とします。範囲の一端では、顧客はすべてのリスクをとることができました、そして、開発者はたくさんの脆弱性をもつコードを供給することができました。他の極端では、開発者はすべてのリスクをとることができて、完全なコードを供給することに対する責任を負うことができました。これらの両極端は、どちらとも実行不可能です。

現在、この契約において、開発者は要求においてカバーされたか、理にかなったテスト努力によってカバーされるべき問題に対するリスクをとります。しかし、「新しい」セキュリティ問題の改善は、顧客によって代金を払われるべきです。私たちは、これが開発者が彼らのリスクの境界となることができて役に立つバランスで、顧客が前もってセキュリティ要求を正しくするのを奨励すると思っています。しかし、この問題の多くの他の可能性がある解決が、あります。あなたには他の提案があるかどうか私たちに知らせます、そして、私たちは彼らをこの文書の将来の版に含めてもよいです。

ここでの議論がコードにおいてセキュリティ脆弱性を修正することに関連したリスクをカバーだけして、これらの脆弱性のあらゆるエクスプロイットに基づくあらゆるセキュリティ・インシデントから立ち直ることと関連したコストを含まないことに注意すべきです。私たちは、この領域におけるベスト・プラクティスに興味があります。

===私たちはどのように第三者のコードを保証するでしょうか===

ほとんどすべてのソフトウェアプロジェクトは、第三者のコード（例えばライブラリ、フレームワークと生産物）のかなりの量を使います。このコードは、ただセキュリティ観点から、カスタム・コードがあなたのプロジェクトのために特に発達したのと同じくらい重要です。
私たちはこのコードのセキュリティを確実にすることに対する責任が開発者によって負われて最もよいと思っています、しかし、彼らにはこのセキュリティを保証するために彼ら自身のいっぱいの能力がないかもしれません。しかし、セキュリティは「構築するか、買うか」議論の一部分でなければなりません、これはそれを促進する最もよい方法のようです。

開発者は、もちろん、終わりまで第三者のソフトウェアの提供者にこの責任をパスする選択権があります。開発者は彼ら自身第三者のコードを分析することもできるか、彼らのためにそれを分析するために、セキュリティの専門家を雇うこともできます。

===しかし、なぜ私はすべてのこのトラブルにいくべきなのでしょうか===

最後に、私たちはソフトウェアを契約しているプロセスの一部分をセキュリティをすることに代わるものがないと思っています。現在では、私たちは多くのソフトウェア開発契約のもとで供給されているコードのセキュリティに関する重大な誤解があると思っています。これは、わずかなソフトウェア経験または理解とともに個人によってなされる高価な訴訟と決定に至ることができるだけです。この問題の完全な議論に対して [[Secure software contracting hypothetical case study]] （[https://www.owasp.org/index.php/Secure_software_contracting_hypothetical_case_study/ja 日本語訳]）を読んでください。

多くの利点が、この契約を通してうまくいくことにあります。主要なものは、それが関係する関係者の間で期待を明らかにするということです。場合によっては、難しいセキュリティ問題がソフトウェアで表面化するとき、それは訴訟を妨げるのを助けます。また、これらは多くの法的で調整するコンプライアンスの理由によって必要とされる同じ活動です。

===しかし、このドキュメントですべてを作ることは難しい===

OWASPは、文書化を目的とした文書化を推奨しません。この契約は品質（量ではない）を促進することに集中します。私たちは、短いリスク評価、数ページの要求、短いセキュリティ設計文書、テストプラン、いくつかのテスト結果とともに、この契約に応じることが（若干のプロジェクトにおいて）ありえると思っています。

この文書の目標は、ライフサイクルの各段階で、単に適切な注意がセキュリティに払われたことを確実とすることです。追加の利点は、この文書が基本的に、このソフトウェアが安心してそれがそれがすると主張することをするのをまかせられなければならない理由に対する議論を配置する「証明パッケージ」をつくるために一緒に集められることができるということです。

==契約付属書==

===1. 序文===

この付属書は、顧客と開発者の間で_____________________ ("合意") するために作られます。顧客と開発者は、以下の条項によりソフトウェアのセキュリティを最大にすることに同意します。

===2. 原理===

この付属書は、ソフトウェア開発関係のすべての関係者のセキュリティ関連の権利と義務をはっきりさせることを目的とします。最高レベルで、関係者は以下に同意します

;(a) セキュリティ決定は、リスクに基づきます : セキュリティについての決定は、関係するリスクのしっかりした理解に基づく顧客と開発者によって共同でなされす。

;(b) セキュリティ活動はバランスが保たれます : セキュリティ努力は、全てのソフトウェア開発ライフサイクル全体でおおよそ均一に配布されます。

;(c) セキュリティ活動は統合されます : ここに協議されるすべての活動と文書は、開発者のソフトウェア開発ライフサイクルに統合されて、残りのプロジェクトと別にしておかれるというわけではありません。この付属書の何も、どんな特定のソフトウェア開発プロセスを意味しません。

;(d) 脆弱性は予想されます : すべてのソフトウェアにはバグがあります、そして、それらのいくらかはセキュリティ問題を生じさせます。顧客と開発者は、ライフサイクルにおいてできるだけ早く脆弱性を特定するよう努めます。

;(e) セキュリティ情報は完全に明らかにされます : すべてのセキュリティ関連した情報は、すぐに、そして、完全に、顧客と開発者で共有されます。

;(f) 役に立つセキュリティ文書だけが必要とされます : セキュリティ文書は、セキュリティ設計、リスク分析または問題を明確に記述するために詳細にわたる必要はありません。

===3.ライフサイクル活動===

;(a) リスク識別 : 開発者と顧客は、アプリケーションに直面しているリスクを理解して、文書化するために協力することに同意します。この努力は、アプリケーションにより提供される重要な資産と機能への主要なリスクを確認しなければなりません。要件部にリストされるトピックの各々は、考慮されなければなりません。

;(b) 要求 : リスクに基づいて、開発者と顧客は、開発されるソフトウェアの仕様の一部として詳細なセキュリティ要件を確立するために協力することに同意します。この付属書の要件部分で記載される個々のトピックは、開発者と顧客によって協議されなければならなくて、評価されなければなりません。これらの要件は、カスタム・ソフトウェア、第三者のソフトウェアまたはプラットホームによって満たされてもよいです。

;(c) 設計 : 開発者は、セキュリティ要件の各々を達成するために明確に設計を説明する文書を提供することに同意します。ほとんどの場合、この文書はセキュリティ手法を記載します、そこで、手法はアーキテクチャに適合しました、そして、関連したすべては彼らの適正使用を確実にするためにパターンを設計します。設計は、サポートがカスタム・ソフトか、第三者のソフトウェアかプラットホームから来るかどうか、明確に指定しなければなりません。

;(d) 実装 : 開発者は、一組のセキュアなコーディング指針に提供することに、従って、一組の共通セキュリティ制御プログラミング・インターフェース（例えば [http://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API OWASP Enterprise Security API（ESAPI）] ）を使って同意します。ガイドラインは、コードがどのようにフォーマットされなければならなくて、構築されなければならなくて、コメントされなければならないかについて示します。共通セキュリティ制御プログラミング・インターフェースは、セキュリティ制御がどのように呼ばれなければならないか、そして、セキュリティ制御がどのように機能するか定めます。すべてのセキュリティに関連したコードは、十分に解説されなければなりません。共通のセキュリティ脆弱性を回避するときの具体的なガイダンスが含まれなければなりません。また、すべてのコードはセキュリティ要件に対して少なくとも他の一人の開発者によってレビューされなければなりません、そして、それの前のコーディング・ガイドラインは単体テストの準備ができていると思われます。

;(e) セキュリティ分析とテスト : 開発者は、（ [http://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project OWASP Application Security Verification Standard (ASVS)] のような）合意された標準の検証要件により、アプリケーション・セキュリティ分析とテスト（「検証」とも言われる）を実行します。開発者は、標準の報告要件によって検証結論を文書化しなければなりません。開発者は、検証結論を顧客に提供しなければなりません。

;(f) セキュリティ配備 : 開発者は、ソフトウェアの全体的なセキュリティのために完全にすべてのセキュリティ関連した構成オプションとそれらの関連性を記述するセキュアな構成ガイドラインを提供することに同意します。ガイドラインは、オペレーティングシステム、ウェブサーバとアプリケーション・サーバーを含むサポート的なプラットホームにおける依存関係の完全な記述を含まなければいけません。また、どのようにそれらをセキュリティのために構成されるべきかを含まなければいけません。ソフトウェアのデフォルトコンフィグレーションは、セキュアでなければなりません。

===4.セキュリティ要求エリア===

以下のトピック領域は、リスク理解と要求定義活動の間、考慮されなければなりません。この努力は一組の具体的で、注文仕立てで、分析できる要求を生産しなければなりません。そして、開発者と顧客はこのプロセスに関与していなければならなくて、要求の最終セットについて同意しなければなりません。

;(a) 入力検証とエンコーディング : 要求は、ユーザー、ファイルシステム、データベース、ディレクトリまたは外部システムからであるかどうかにかかわらず、アプリケーションへの各々の入力を標準化し、検証し、コード化するためにルールを指定しなければなりません。　　　デフォルトルールは、それが何が許可されるかという詳細な仕様にマッチしない限り、すべての入力が無効であるということでなければなりません。そのうえ、無効な入力が受け取られるとき、要求はとられる措置を指定しなければなりません。具体的には、アプリケーションはインジェクション、オーバフロー、不正操作することまたは他の不正な入力攻撃に影響されやすくてはいけません。

;(b) 認証とセッション管理 : 要求は、認証証明書とセッション識別子がどのようにそれらのライフサイクルを通して保護されているかについて明記しなければなりません。すべての関連する機能（パスワード忘却、パスワード変更、パスワードリマインダ、ログアウト、そして複数ログインを含む）に対する要求は含められなければいけません。

;(c) アクセス制御 : 要求は、アプリケーションで使われるすべての役割（グループ、特権、認可）の詳細な記述を含まなければなりません。要求は、アプリケーションにより提供されるすべての資産と機能も示さなければなりません。要求は、完全に各々の資産に正確なアクセス権を指定しなければならなくて、各々の役割に対して機能しなければなりません。アクセス制御マトリックスは、これらのルールのための提案されたフォーマットです。

;(d) エラー処理 : 要求は、処理の間、発生しているエラーが取り扱われる方法を詳述しなければなりません。若干のアプリケーションはエラーの場合には最もよい努力結果を提供しなければなりません、一方、他はすぐに処理を終了しなければなりません。

;(e) ロギング : 要求は、どんなイベントがセキュリティに関連して、記録される必要があるか、たとえば、検知された攻撃、失敗したログイン試行、認可を上回ろうとする試行、を指定しなければなりません。要求は、時間と日付、イベント記述、アプリケーション詳細とフォレンジクス努力に役立つ他の情報を含む、各々のイベントでどんな情報を記録するべきかについても指定しなければなりません。

;(f) 外部システムへの接続 : 要求は、認証と暗号化がどのようにすべての外部システム（例えばデータベース、ディレクトリとウェブ・サービス）のために取り扱われるかについて指定しなければなりません。外部システムでコミュニケーションのために必要とされるすべてのクレディンシャルは、暗号化された形で構成ファイルでコードの外側に保存されなければなりません。

;(g) 暗号 : 要求は、どんなデータが暗号化されなければならないか、暗号化されることがどれほどか、そして、すべての証明書と他のクレディンシャルがどのように取り扱われなければならないか指定しなければなりません。アプリケーションは、広く使われていてテストされた暗号化ライブラリで実装される標準的なアルゴリズムを使用しなければなりません。

;(h) 可用性 : 要求は、それがどのようにサービス不能攻撃から保護するかについて指定しなければなりません。アプリケーションへのすべてのありそうな攻撃は考慮されなければなりません。そして、認証ロックアウト、接続消耗と他の資源消耗攻撃を含みます。

;(i) セキュアな設定 : 要求は、すべてのセキュリティに関連した構成オプションに対するデフォルト値がセキュアでなければならないことを示していなければなりません。監査目的のために、ソフトウェアはすべてのセキュリティに関連した構成詳細を示している簡単に読めるレポートをつくることができなければなりません。

;(j) 特定の脆弱性 : 要求は、ソフトウェアで見つかってはならない一組の具体的な脆弱性を含まなければなりません。指定されていないならば、ソフトウェアは現在の「OWASP Top Ten Most Critical Web Application Vulnerabilities」で記述される瑕疵の何も含んではいけません。

===5. 要員および組織===

;(a) セキュリティ・アーキテクト : 開発者は一つの上位の技術的な資源に責任をセキュリティに指定します。そして、プロジェクトのセキュリティ・アーキテクトとして知られています。セキュリティ・アーキテクトは、各々の納品可能なもののセキュリティを保証します。

;(b) セキュリティ・トレーニング : 開発者は、開発者チームのすべてのメンバーがセキュアなプログラミング技法の訓練をされたことを確かめる役割を果たします。

;(c) 信用できる開発者 : 開発者は、すべての開発チーム・メンバーの適切な経歴調査を実行することに同意します。

===6.開発環境===

;(a) セキュア・コーディング : 開発者は、どんなツールがセキュアなコーディングを促すためにソフトウェア開発環境で使われるかについて明らかにしなければなりません。

;(b) 構成管理 : 開発者は、ソフトウェア・ベースラインに対するすべての変更とすべての関連した設定とビルド・ファイルを関連づけ　とすべての関連した構成にすべての変化と関連したチーム・メンバーを認証して、記録して、ファイルを構築したソース・コード管理システムを使用しなければなりません。

;(c) 配布 : 開発者は、ソースから確実に完全な配布を構築するビルド・プロセスを使用しなければなりません。このプロセスは、顧客に供給されるソフトウェアの完全性を確かめる方法を含まなければなりません。

===7. ライブラリ、フレームワーク、および生産物===

;(a) 開示 : 開発者は、商用、フリー、オープンソース、クローズソースであるにせよ、すべてのライブラリ、フレームワーク、構成要素と他の生産物を含む、ソフトウェアで使われるすべての第三者のソフトウェアを明らかにしなければなりません。

;(b) 評価 : 開発者は、第三者のソフトウェアがこの契約のすべての条件を満たして、この契約の基で開発されたカスタム開発されたコードと同じくらいセキュアなことを確実とするために、理にかなった努力をしなければなりません。

===8. セキュリティ・レビュー===

;(a) レビューする権利 : 依頼人には、ソフトウェアを納品の60日間以内にいつでも彼らの費用でセキュリティ瑕疵のためにレビューしておく権利があります。開発者は、ソース・コードとテスト環境へのアクセスを提供することによって理にかなったサポートをレビュー・チームに提供することに同意します。

;(b) レビュー・カバレッジ : セキュリティ・レビューは供給されるソフトウェアのすべての面をカバーしなければなりません。そして、カスタム・コード、構成要素、生産物とシステム設定を含みます。

;(c) レビューの範囲 : 最低限で、レビューはセキュリティ要求の全てをカバーしなければならなくて、他の一般的な脆弱性を捜さなければなりません。レビューは、脆弱性スキャン、侵入テスト、ソースコードの静的分析と専門家のコードレビューの組み合わせを含んでもよいです。

;(d) 見つけられた問題 : 発見されたセキュリティ問題は、顧客と開発者に報告されます。すべての問題は、この付属書のセキュリティ問題マネジメント部分により追跡されて、矯正されます。

===9. セキュリティ問題マネジメント ===

;(a) 識別 : 要求、設計、実装、テスト、配備、または、運用中の問題にせよ、開発者は全てのライフサイクルの間に発見されるすべてのセキュリティ問題を追います。各々のセキュリティ問題に関連したリスクは、発見後できるだけ早く、評価されて、文書化されて、発見の後、顧客に報告されます。

;(b) 保護 : 開発者はセキュリティ問題と付随する文書に関して情報を適切に保護します。そして、運用中の顧客ソフトウェアの脆弱性が露出するという可能性を制限するのを助けます。

;(c) 改善 : 納品の前に確認されるセキュリティ問題は、開発者によって修正されなければなりません。納品の後に発見されるセキュリティ問題は、本契約の規定による他のバグと問題として同様に取り扱われなければなりません。

===10. 保証===

;(a) 保証 : 開発者は、開発プロセスを通して作成されるセキュリティ文書からなる「証明パッケージ」を提供します。パッケージは、セキュリティ要求、設計、実装と試験結果がきちんと完了された、そして、すべてのセキュリティ問題が適切に解決されたと確認しなければなりません。

;(b) 自己証明 : セキュリティ・アーキテクトは、ソフトウェアがセキュリティ要求を満たすこと、すべてのセキュリティ活動が実行されていること、そして、すべての識別されたセキュリティ問題が文書化されて、解決されたことを証明します。証明ステータスに対するあらゆる例外は、納品で完全に文書化されなければなりません。

;(c) 悪意のあるコードのなし : 開発者は、ソフトウェアがソフトウェア要求をサポートせず、コンピュータ・ウイルス、ワーム、時限爆弾、バック・ドア、トロイの木馬、イースターエッグと他のあらゆる形の悪意のあるソフトウェアを含む、アプリケーションのセキュリティを弱めるあらゆるコードを含んではならないと保証します。

===11. セキュリティ承認と保守 ===

;(a) 受け入れ : 証明パッケージが完全であり、すべてのセキュリティ問題が解決されるまで、ソフトウェアは受け入れられると考慮されてはいけません。

;(b) セキュリティ問題の調査 : 受理の後、セキュリティ問題が発見されるか、かなり疑われるならば、開発者は顧客が問題の性質を決定するために調査を実行するのを援助しなければなりません。それがセキュリティ要求によってカバーされないで、セキュリティ・テストの理にかなった範囲の外にあるならば、問題は「新しい」と思われなければなりません。

;(c) 新しいセキュリティ問題 : 開発者と顧客は、新しいセキュリティ問題を解決するために必要な努力を探し出すことに同意します。また、それらに取り組むために必要とされる仕事を実行するための合意を達成するために誠意を持って交渉することに同意します。

;(d) 他のセキュリティ問題 : 開発者は堅実なソフトウェア開発慣行。そして、リスクのひどさを考慮すること、そして、できるだけ速く新しいと思われないすべてのセキュリティ問題を解決することと一致したすべての商業的に理にかなった努力を使わなければなりません

[[Category:OWASP Legal Project]]

__NOTOC__

OWASP Secure Software Contract Annex/ja

2011-07-06T12:31:54Z

Tomo: /* 2. 原理 */

'''セキュア・ソフトウェア開発契約付属書'''

警告：この文書は、単にガイダンスと考えられなければなりません。
OWASPは、ソフトウェア契約を交渉するのを手助けするために、
あなたが資格のある弁護士に相談するよう強く勧めます。

==序文==

OWASPセキュア・ソフトウェア開発契約付属書は、ソフトウェアの開発者とその顧客が、開発または供給されるソフトウェアのセキュリティに関連した重要な契約条項と条件を交渉し、取り込むことを助けます。このプロジェクトの理由は、多くの契約はこれらの問題に触れておらず、しばしば関係者が実際に同意されたものに劇的に異なる見解を持つことです。私たちは、これらの条項を明確に述べることは、双方の関係者が進め方について情報に基づいた意思決定ができることを確実にするもっともよい方法であると思っています。

「市場がより良いセキュリティを要求するとき、商用ソフトのセキュリティは改善します。
最低限、あらゆるソフトウェア提案依頼書は、ベンダーに彼らがセキュリティ脆弱性に対して
生産物をテストする方法を詳述するよう依頼しなければなりません。このステップは、企業が
セキュリティを評価すると市販ソフトウェアのベンダーと外部調達された開発者を納得させ始めます。」
-- John Pescatore（Gartnerのリサーチ・ディレクター）として

私たちは、顧客と開発者が、期待について議論して、責任について交渉することに対するフレームワークとしてこの文書を使うよう勧めます。この付属書は、ソフトウェア開発契約に添付されることを目的とします。これらの条項は交渉の余地があります。そして、それらは顧客と開発者によって、協議されることができて、協議されなければならないことを意味します。

==プロジェクトについて==

この文書はOpen Web Application Security Project（OWASP）財団（セキュアなソフトウェアに関連した無料でオープンなツールとドキュメンテーションを作成することを専門とする非営利の慈善団体）によって作成されました。個人契約において容易に使用できるようにするために、この文書はCC Share Alike 3.0ライセンスにて提供されます。あなたが適すると思うように、修正してもよいですし、使用してもよいです。あなたは、http://www.owasp.com/index.php/OWASP_Legal_Project でこのプロジェクトについて更なる詳細を見つけることができます。私たちは、ソフトウェア（法律コミュニティだけでなく）の製作者と消費者のコメントを歓迎します。

OWASPは、この文書の研究と準備における彼らの役割に対して [http://www.aspectsecurity.com Aspect Security] から特別な貢献を感謝して認めます。

==異論==

以下のわずかなページは、ソフトウェア開発契約においてこの言い回しを使用することに対するいくらかのたびたび聞こえる異論をカバーします：

===しかし、すべての条項が私たちにとって適切であるというわけではありません…===

この文書は、あなたの合意の開始地点です。あなたは、すべての活動が好きではないかもしれません、または、より多くの提案をしたいかもしれません。あなたは異なる責任を割り当てたいかもしれません。この文書は、すべてのソフトウェア顧客と開発者の要望を厳密に取り込むことを意図しているわけではありません。ソフトウェアが最終的にセキュアになることを確実にするために重要である、主要な項目を議論するためのフレームワークを提供することを意図します。セキュリティを議論して合意を得た後で、あなたはこの合意を適合するように調整すべきです。

===しかし、これらの活動に対して誰が代金を払わなければならないのでしょうか===

この契約は、ソフトウェア開発者により多くの負担を与えることはほとんどありません。問題は、セキュリティ ― もちろんそこにある ― と関連したコストがあるかどうかということでありません。むしろ、適切な問題はどんな活動がそれらのコストを最小にするために双方によって実行されなければならないかということです、そして、いつ、それらは起こらなければなりませんか。

この付属書は、誰がここに記述される活動の料金を払わなければならないかという問題については、意図的に語られていません。これらの活動の多くがすでに起こらなければならなくて、多くの顧客によって期待される一方、それたはソフトウェア産業で定期的に実践されることはありません。誰が（そして、いくら）支払うかという問題が、交渉の一部でなければなりません。

セキュリティのコストを計算することは、非常に難しいです。セキュリティ活動を実行することに関連したコストがある一方、それらを無視することに関連したかなりのコストもあります。私たちは、ソフトウェアを開発する最も費用対効果がよい方法について確信しています。それは、セキュリティ瑕疵が導入されるという可能性を減らして、瑕疵を導入して、それを修正することの間で時間を最小にすることです。

コストを計算するときにする一つの重要な区別は、セキュリティ手法を構築することと、それらの手法が正しくて効果的であることを確実にする保証活動の間にあります。ライフサイクルの終わりに手法を加えようとすることは、深刻な設計問題を引き起こすことがありえて、めざましくコストを増やします。この合意は、手法についての早い段階の決定がこれらのコストを最小にするのを奨励します。同様に、配備直前に保証活動（例えばコードレビューと侵入テスト）をするまで待つことはコストをめざましく増やします。私たちは、保証を得る最も費用効果がよい方法がライフサイクルを通して努力の一定のレベルを保証に入れることであると思っています。

===しかし厳密さのレベルは間違っている….===

この合意は、開発されているソフトウェアが大企業または政府機関にとってかなり重要であると仮定します。私たちは、大部分のソフトウェア開発組織によって達成できる合意のために「厳格さのレベル」を選んで、最も一般的なリスクを確認して、取り扱います。

しかし、重要なアプリケーション（例えば医学であるか、財政的であるか、防衛に関連したソフトウェア）で使われそうであるソフトウェアについては、あなたは厳格さのレベルを上げたいかもしれません。あなたは、追加のレビュー、文書化とテストの活動を加えたくてもよいです。あなたは、脆弱性を探すこと、診断すること、修正することに対するプロセスを強化しくてもよいです。より機密を扱わないアプリケーションのために、あなたは活動を減らすか、取り除きたくてもよいです。

===しかし、私たちはそれほど多くのリスクをとることができない…===

この契約は、ソフトウェアにおけるセキュリティ脆弱性に対するリスクをとるのかという議論を容易にすることを目的とします。範囲の一端では、顧客はすべてのリスクをとることができました、そして、開発者はたくさんの脆弱性をもつコードを供給することができました。他の極端では、開発者はすべてのリスクをとることができて、完全なコードを供給することに対する責任を負うことができました。これらの両極端は、どちらとも実行不可能です。

現在、この契約において、開発者は要求においてカバーされたか、理にかなったテスト努力によってカバーされるべき問題に対するリスクをとります。しかし、「新しい」セキュリティ問題の改善は、顧客によって代金を払われるべきです。私たちは、これが開発者が彼らのリスクの境界となることができて役に立つバランスで、顧客が前もってセキュリティ要求を正しくするのを奨励すると思っています。しかし、この問題の多くの他の可能性がある解決が、あります。あなたには他の提案があるかどうか私たちに知らせます、そして、私たちは彼らをこの文書の将来の版に含めてもよいです。

ここでの議論がコードにおいてセキュリティ脆弱性を修正することに関連したリスクをカバーだけして、これらの脆弱性のあらゆるエクスプロイットに基づくあらゆるセキュリティ・インシデントから立ち直ることと関連したコストを含まないことに注意すべきです。私たちは、この領域におけるベスト・プラクティスに興味があります。

===私たちはどのように第三者のコードを保証するでしょうか===

ほとんどすべてのソフトウェアプロジェクトは、第三者のコード（例えばライブラリ、フレームワークと生産物）のかなりの量を使います。このコードは、ただセキュリティ観点から、カスタム・コードがあなたのプロジェクトのために特に発達したのと同じくらい重要です。
私たちはこのコードのセキュリティを確実にすることに対する責任が開発者によって負われて最もよいと思っています、しかし、彼らにはこのセキュリティを保証するために彼ら自身のいっぱいの能力がないかもしれません。しかし、セキュリティは「構築するか、買うか」議論の一部分でなければなりません、これはそれを促進する最もよい方法のようです。

開発者は、もちろん、終わりまで第三者のソフトウェアの提供者にこの責任をパスする選択権があります。開発者は彼ら自身第三者のコードを分析することもできるか、彼らのためにそれを分析するために、セキュリティの専門家を雇うこともできます。

===しかし、なぜ私はすべてのこのトラブルにいくべきなのでしょうか===

最後に、私たちはソフトウェアを契約しているプロセスの一部分をセキュリティをすることに代わるものがないと思っています。現在では、私たちは多くのソフトウェア開発契約のもとで供給されているコードのセキュリティに関する重大な誤解があると思っています。これは、わずかなソフトウェア経験または理解とともに個人によってなされる高価な訴訟と決定に至ることができるだけです。この問題の完全な議論に対して [[Secure software contracting hypothetical case study]] （[https://www.owasp.org/index.php/Secure_software_contracting_hypothetical_case_study/ja 日本語訳]）を読んでください。

多くの利点が、この契約を通してうまくいくことにあります。主要なものは、それが関係する関係者の間で期待を明らかにするということです。場合によっては、難しいセキュリティ問題がソフトウェアで表面化するとき、それは訴訟を妨げるのを助けます。また、これらは多くの法的で調整するコンプライアンスの理由によって必要とされる同じ活動です。

===しかし、このドキュメントですべてを作ることは難しい===

OWASPは、文書化を目的とした文書化を推奨しません。この契約は品質（量ではない）を促進することに集中します。私たちは、短いリスク評価、数ページの要求、短いセキュリティ設計文書、テストプラン、いくつかのテスト結果とともに、この契約に応じることが（若干のプロジェクトにおいて）ありえると思っています。

この文書の目標は、ライフサイクルの各段階で、単に適切な注意がセキュリティに払われたことを確実とすることです。追加の利点は、この文書が基本的に、このソフトウェアが安心してそれがそれがすると主張することをするのをまかせられなければならない理由に対する議論を配置する「証明パッケージ」をつくるために一緒に集められることができるということです。

==契約付属書==

===1. 序文===

この付属書は、顧客と開発者の間で_____________________ ("合意") するために作られます。顧客と開発者は、以下の条項によりソフトウェアのセキュリティを最大にすることに同意します。

===2. 原理===

この付属書は、ソフトウェア開発関係のすべての関係者のセキュリティ関連の権利と義務をはっきりさせることを目的とします。最高レベルで、関係者は以下に同意します

;(a) セキュリティ決定は、リスクに基づきます : セキュリティについての決定は、関係するリスクのしっかりした理解に基づく顧客と開発者によって共同でなされす。

;(b) セキュリティ活動はバランスが保たれます : セキュリティ努力は、全てのソフトウェア開発ライフサイクル全体でおおよそ均一に配布されます。

;(c) セキュリティ活動は統合されます : ここに協議されるすべての活動と文書は、開発者のソフトウェア開発ライフサイクルに統合されて、残りのプロジェクトと別にしておかれるというわけではありません。この付属書の何も、どんな特定のソフトウェア開発プロセスを意味しません。

;(d) 脆弱性は予想されます : すべてのソフトウェアにはバグがあります、そして、それらのいくらかはセキュリティ問題を生じさせます。顧客と開発者は、ライフサイクルにおいてできるだけ早く脆弱性を特定するよう努めます。

;(e) セキュリティ情報は完全に明らかにされます : すべてのセキュリティ関連した情報は、すぐに、そして、完全に、顧客と開発者で共有されます。

;(f) 役に立つセキュリティ文書だけが必要とされます : セキュリティ文書は、セキュリティ設計、リスク分析または問題を明確に記述するために詳細にわたる必要はありません。

===3.ライフサイクル活動===

;(a) リスク識別 : 開発者とClientは、アプリケーションに直面しているリスクを理解して、文書化するために一緒に働くことに同意します。この努力は、アプリケーションにより提供される重要な資産と機能に主要なリスクを確認しなければなりません。要件部にリストされるトピックの各々は、考慮されなければなりません。

;(b) 要求 : リスクに基づいて、開発者と顧客は、開発されるソフトウェアの仕様の一部として詳細なセキュリティ要件を確立するために一緒に働くことに同意します。この付属書の要件部分で記載されるトピックの各々は、開発者と顧客によって協議されなければならなくて、評価されなければなりません。これらの要件は、カスタム・ソフト、第三者のソフトウェアまたはプラットホームによって満たされてもよいです。

;(c) 設計 : 開発者は、セキュリティ要件の各々を達成するために明確に設計を説明する文書を提供することに同意します。ほとんどの場合、この文書はセキュリティ手法を記載します、そこで、手法はアーキテクチャに適合しました、そして、関連したすべては彼らの適正使用を確実にするためにパターンを設計します。設計は、サポートがカスタム・ソフトか、第三者のソフトウェアかプラットホームから来るかどうか、明確に指定しなければなりません。

;(d) 実装 : 開発者は、一組のセキュアなコーディング指針に提供することに、従って、一組の共通セキュリティ制御プログラミング・インターフェース（例えば [http://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API OWASP Enterprise Security API（ESAPI）] ）を使って同意します。ガイドラインは、コードがどのようにフォーマットされなければならなくて、構築されなければならなくて、コメントされなければならないかについて示します。共通セキュリティ制御プログラミング・インターフェースは、セキュリティ制御がどのように呼ばれなければならないか、そして、セキュリティ制御がどのように機能するか定めます。すべてのセキュリティに関連したコードは、完全にコメントされます。共通のセキュリティ脆弱性を回避するときの具体的なガイダンスは、含まれなければなりません。また、すべてのコードはセキュリティ要件に対して少なくとも他の一人の開発者によってレビューされなければなりません、そして、それの前のコーディング・ガイドラインは単体テストの準備ができていると思われます。

;(e) セキュリティ分析とテスト : 開発者は、（ [http://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project OWASP Application Security Verification Standard (ASVS)] のような）合意された標準の検証要件により、アプリケーション・セキュリティ分析とテスト（「検証」とも言われる）を実行します。開発者は、標準の報告要件によって検証結論を文書化しなければなりません。開発者は、検証結論を顧客に提供しなければなりません。

;(f) セキュリティ配備 : 開発者は、ソフトウェアの全体的なセキュリティのために完全にすべてのセキュリティ関連した構成オプションとそれらの関連性を記述するセキュアな構成ガイドラインを提供することに同意します。ガイドラインは、オペレーティングシステム、ウェブサーバとアプリケーション・サーバーを含むサポート的なプラットホームにおける依存関係の完全な記述を含まなければいけません。また、どのようにそれらをセキュリティのために構成されるべきかを含まなければいけません。ソフトウェアのデフォルトコンフィグレーションは、セキュアでなければなりません。

===4.セキュリティ要求エリア===

以下のトピック領域は、リスク理解と要求定義活動の間、考慮されなければなりません。この努力は一組の具体的で、注文仕立てで、分析できる要求を生産しなければなりません。そして、開発者と顧客はこのプロセスに関与していなければならなくて、要求の最終セットについて同意しなければなりません。

;(a) 入力検証とエンコーディング : 要求は、ユーザー、ファイルシステム、データベース、ディレクトリまたは外部システムからであるかどうかにかかわらず、アプリケーションへの各々の入力を標準化し、検証し、コード化するためにルールを指定しなければなりません。　　　デフォルトルールは、それが何が許可されるかという詳細な仕様にマッチしない限り、すべての入力が無効であるということでなければなりません。そのうえ、無効な入力が受け取られるとき、要求はとられる措置を指定しなければなりません。具体的には、アプリケーションはインジェクション、オーバフロー、不正操作することまたは他の不正な入力攻撃に影響されやすくてはいけません。

;(b) 認証とセッション管理 : 要求は、認証証明書とセッション識別子がどのようにそれらのライフサイクルを通して保護されているかについて明記しなければなりません。すべての関連する機能（パスワード忘却、パスワード変更、パスワードリマインダ、ログアウト、そして複数ログインを含む）に対する要求は含められなければいけません。

;(c) アクセス制御 : 要求は、アプリケーションで使われるすべての役割（グループ、特権、認可）の詳細な記述を含まなければなりません。要求は、アプリケーションにより提供されるすべての資産と機能も示さなければなりません。要求は、完全に各々の資産に正確なアクセス権を指定しなければならなくて、各々の役割に対して機能しなければなりません。アクセス制御マトリックスは、これらのルールのための提案されたフォーマットです。

;(d) エラー処理 : 要求は、処理の間、発生しているエラーが取り扱われる方法を詳述しなければなりません。若干のアプリケーションはエラーの場合には最もよい努力結果を提供しなければなりません、一方、他はすぐに処理を終了しなければなりません。

;(e) ロギング : 要求は、どんなイベントがセキュリティに関連して、記録される必要があるか、たとえば、検知された攻撃、失敗したログイン試行、認可を上回ろうとする試行、を指定しなければなりません。要求は、時間と日付、イベント記述、アプリケーション詳細とフォレンジクス努力に役立つ他の情報を含む、各々のイベントでどんな情報を記録するべきかについても指定しなければなりません。

;(f) 外部システムへの接続 : 要求は、認証と暗号化がどのようにすべての外部システム（例えばデータベース、ディレクトリとウェブ・サービス）のために取り扱われるかについて指定しなければなりません。外部システムでコミュニケーションのために必要とされるすべてのクレディンシャルは、暗号化された形で構成ファイルでコードの外側に保存されなければなりません。

;(g) 暗号 : 要求は、どんなデータが暗号化されなければならないか、暗号化されることがどれほどか、そして、すべての証明書と他のクレディンシャルがどのように取り扱われなければならないか指定しなければなりません。アプリケーションは、広く使われていてテストされた暗号化ライブラリで実装される標準的なアルゴリズムを使用しなければなりません。

;(h) 可用性 : 要求は、それがどのようにサービス不能攻撃から保護するかについて指定しなければなりません。アプリケーションへのすべてのありそうな攻撃は考慮されなければなりません。そして、認証ロックアウト、接続消耗と他の資源消耗攻撃を含みます。

;(i) セキュアな設定 : 要求は、すべてのセキュリティに関連した構成オプションに対するデフォルト値がセキュアでなければならないことを示していなければなりません。監査目的のために、ソフトウェアはすべてのセキュリティに関連した構成詳細を示している簡単に読めるレポートをつくることができなければなりません。

;(j) 特定の脆弱性 : 要求は、ソフトウェアで見つかってはならない一組の具体的な脆弱性を含まなければなりません。指定されていないならば、ソフトウェアは現在の「OWASP Top Ten Most Critical Web Application Vulnerabilities」で記述される瑕疵の何も含んではいけません。

===5. 要員および組織===

;(a) セキュリティ・アーキテクト : 開発者は一つの上位の技術的な資源に責任をセキュリティに指定します。そして、プロジェクトのセキュリティ・アーキテクトとして知られています。セキュリティ・アーキテクトは、各々の納品可能なもののセキュリティを保証します。

;(b) セキュリティ・トレーニング : 開発者は、開発者チームのすべてのメンバーがセキュアなプログラミング技法の訓練をされたことを確かめる役割を果たします。

;(c) 信用できる開発者 : 開発者は、すべての開発チーム・メンバーの適切な経歴調査を実行することに同意します。

===6.開発環境===

;(a) セキュア・コーディング : 開発者は、どんなツールがセキュアなコーディングを促すためにソフトウェア開発環境で使われるかについて明らかにしなければなりません。

;(b) 構成管理 : 開発者は、ソフトウェア・ベースラインに対するすべての変更とすべての関連した設定とビルド・ファイルを関連づけ　とすべての関連した構成にすべての変化と関連したチーム・メンバーを認証して、記録して、ファイルを構築したソース・コード管理システムを使用しなければなりません。

;(c) 配布 : 開発者は、ソースから確実に完全な配布を構築するビルド・プロセスを使用しなければなりません。このプロセスは、顧客に供給されるソフトウェアの完全性を確かめる方法を含まなければなりません。

===7. ライブラリ、フレームワーク、および生産物===

;(a) 開示 : 開発者は、商用、フリー、オープンソース、クローズソースであるにせよ、すべてのライブラリ、フレームワーク、構成要素と他の生産物を含む、ソフトウェアで使われるすべての第三者のソフトウェアを明らかにしなければなりません。

;(b) 評価 : 開発者は、第三者のソフトウェアがこの契約のすべての条件を満たして、この契約の基で開発されたカスタム開発されたコードと同じくらいセキュアなことを確実とするために、理にかなった努力をしなければなりません。

===8. セキュリティ・レビュー===

;(a) レビューする権利 : 依頼人には、ソフトウェアを納品の60日間以内にいつでも彼らの費用でセキュリティ瑕疵のためにレビューしておく権利があります。開発者は、ソース・コードとテスト環境へのアクセスを提供することによって理にかなったサポートをレビュー・チームに提供することに同意します。

;(b) レビュー・カバレッジ : セキュリティ・レビューは供給されるソフトウェアのすべての面をカバーしなければなりません。そして、カスタム・コード、構成要素、生産物とシステム設定を含みます。

;(c) レビューの範囲 : 最低限で、レビューはセキュリティ要求の全てをカバーしなければならなくて、他の一般的な脆弱性を捜さなければなりません。レビューは、脆弱性スキャン、侵入テスト、ソースコードの静的分析と専門家のコードレビューの組み合わせを含んでもよいです。

;(d) 見つけられた問題 : 発見されたセキュリティ問題は、顧客と開発者に報告されます。すべての問題は、この付属書のセキュリティ問題マネジメント部分により追跡されて、矯正されます。

===9. セキュリティ問題マネジメント ===

;(a) 識別 : 要求、設計、実装、テスト、配備、または、運用中の問題にせよ、開発者は全てのライフサイクルの間に発見されるすべてのセキュリティ問題を追います。各々のセキュリティ問題に関連したリスクは、発見後できるだけ早く、評価されて、文書化されて、発見の後、顧客に報告されます。

;(b) 保護 : 開発者はセキュリティ問題と付随する文書に関して情報を適切に保護します。そして、運用中の顧客ソフトウェアの脆弱性が露出するという可能性を制限するのを助けます。

;(c) 改善 : 納品の前に確認されるセキュリティ問題は、開発者によって修正されなければなりません。納品の後に発見されるセキュリティ問題は、本契約の規定による他のバグと問題として同様に取り扱われなければなりません。

===10. 保証===

;(a) 保証 : 開発者は、開発プロセスを通して作成されるセキュリティ文書からなる「証明パッケージ」を提供します。パッケージは、セキュリティ要求、設計、実装と試験結果がきちんと完了された、そして、すべてのセキュリティ問題が適切に解決されたと確認しなければなりません。

;(b) 自己証明 : セキュリティ・アーキテクトは、ソフトウェアがセキュリティ要求を満たすこと、すべてのセキュリティ活動が実行されていること、そして、すべての識別されたセキュリティ問題が文書化されて、解決されたことを証明します。証明ステータスに対するあらゆる例外は、納品で完全に文書化されなければなりません。

;(c) 悪意のあるコードのなし : 開発者は、ソフトウェアがソフトウェア要求をサポートせず、コンピュータ・ウイルス、ワーム、時限爆弾、バック・ドア、トロイの木馬、イースターエッグと他のあらゆる形の悪意のあるソフトウェアを含む、アプリケーションのセキュリティを弱めるあらゆるコードを含んではならないと保証します。

===11. セキュリティ承認と保守 ===

;(a) 受け入れ : 証明パッケージが完全であり、すべてのセキュリティ問題が解決されるまで、ソフトウェアは受け入れられると考慮されてはいけません。

;(b) セキュリティ問題の調査 : 受理の後、セキュリティ問題が発見されるか、かなり疑われるならば、開発者は顧客が問題の性質を決定するために調査を実行するのを援助しなければなりません。それがセキュリティ要求によってカバーされないで、セキュリティ・テストの理にかなった範囲の外にあるならば、問題は「新しい」と思われなければなりません。

;(c) 新しいセキュリティ問題 : 開発者と顧客は、新しいセキュリティ問題を解決するために必要な努力を探し出すことに同意します。また、それらに取り組むために必要とされる仕事を実行するための合意を達成するために誠意を持って交渉することに同意します。

;(d) 他のセキュリティ問題 : 開発者は堅実なソフトウェア開発慣行。そして、リスクのひどさを考慮すること、そして、できるだけ速く新しいと思われないすべてのセキュリティ問題を解決することと一致したすべての商業的に理にかなった努力を使わなければなりません

[[Category:OWASP Legal Project]]

__NOTOC__

OWASP Secure Software Contract Annex/ja

2011-07-06T12:23:14Z

Tomo: /* 1. 序文 */

'''セキュア・ソフトウェア開発契約付属書'''

警告：この文書は、単にガイダンスと考えられなければなりません。
OWASPは、ソフトウェア契約を交渉するのを手助けするために、
あなたが資格のある弁護士に相談するよう強く勧めます。

==序文==

OWASPセキュア・ソフトウェア開発契約付属書は、ソフトウェアの開発者とその顧客が、開発または供給されるソフトウェアのセキュリティに関連した重要な契約条項と条件を交渉し、取り込むことを助けます。このプロジェクトの理由は、多くの契約はこれらの問題に触れておらず、しばしば関係者が実際に同意されたものに劇的に異なる見解を持つことです。私たちは、これらの条項を明確に述べることは、双方の関係者が進め方について情報に基づいた意思決定ができることを確実にするもっともよい方法であると思っています。

「市場がより良いセキュリティを要求するとき、商用ソフトのセキュリティは改善します。
最低限、あらゆるソフトウェア提案依頼書は、ベンダーに彼らがセキュリティ脆弱性に対して
生産物をテストする方法を詳述するよう依頼しなければなりません。このステップは、企業が
セキュリティを評価すると市販ソフトウェアのベンダーと外部調達された開発者を納得させ始めます。」
-- John Pescatore（Gartnerのリサーチ・ディレクター）として

私たちは、顧客と開発者が、期待について議論して、責任について交渉することに対するフレームワークとしてこの文書を使うよう勧めます。この付属書は、ソフトウェア開発契約に添付されることを目的とします。これらの条項は交渉の余地があります。そして、それらは顧客と開発者によって、協議されることができて、協議されなければならないことを意味します。

==プロジェクトについて==

この文書はOpen Web Application Security Project（OWASP）財団（セキュアなソフトウェアに関連した無料でオープンなツールとドキュメンテーションを作成することを専門とする非営利の慈善団体）によって作成されました。個人契約において容易に使用できるようにするために、この文書はCC Share Alike 3.0ライセンスにて提供されます。あなたが適すると思うように、修正してもよいですし、使用してもよいです。あなたは、http://www.owasp.com/index.php/OWASP_Legal_Project でこのプロジェクトについて更なる詳細を見つけることができます。私たちは、ソフトウェア（法律コミュニティだけでなく）の製作者と消費者のコメントを歓迎します。

OWASPは、この文書の研究と準備における彼らの役割に対して [http://www.aspectsecurity.com Aspect Security] から特別な貢献を感謝して認めます。

==異論==

以下のわずかなページは、ソフトウェア開発契約においてこの言い回しを使用することに対するいくらかのたびたび聞こえる異論をカバーします：

===しかし、すべての条項が私たちにとって適切であるというわけではありません…===

この文書は、あなたの合意の開始地点です。あなたは、すべての活動が好きではないかもしれません、または、より多くの提案をしたいかもしれません。あなたは異なる責任を割り当てたいかもしれません。この文書は、すべてのソフトウェア顧客と開発者の要望を厳密に取り込むことを意図しているわけではありません。ソフトウェアが最終的にセキュアになることを確実にするために重要である、主要な項目を議論するためのフレームワークを提供することを意図します。セキュリティを議論して合意を得た後で、あなたはこの合意を適合するように調整すべきです。

===しかし、これらの活動に対して誰が代金を払わなければならないのでしょうか===

この契約は、ソフトウェア開発者により多くの負担を与えることはほとんどありません。問題は、セキュリティ ― もちろんそこにある ― と関連したコストがあるかどうかということでありません。むしろ、適切な問題はどんな活動がそれらのコストを最小にするために双方によって実行されなければならないかということです、そして、いつ、それらは起こらなければなりませんか。

この付属書は、誰がここに記述される活動の料金を払わなければならないかという問題については、意図的に語られていません。これらの活動の多くがすでに起こらなければならなくて、多くの顧客によって期待される一方、それたはソフトウェア産業で定期的に実践されることはありません。誰が（そして、いくら）支払うかという問題が、交渉の一部でなければなりません。

セキュリティのコストを計算することは、非常に難しいです。セキュリティ活動を実行することに関連したコストがある一方、それらを無視することに関連したかなりのコストもあります。私たちは、ソフトウェアを開発する最も費用対効果がよい方法について確信しています。それは、セキュリティ瑕疵が導入されるという可能性を減らして、瑕疵を導入して、それを修正することの間で時間を最小にすることです。

コストを計算するときにする一つの重要な区別は、セキュリティ手法を構築することと、それらの手法が正しくて効果的であることを確実にする保証活動の間にあります。ライフサイクルの終わりに手法を加えようとすることは、深刻な設計問題を引き起こすことがありえて、めざましくコストを増やします。この合意は、手法についての早い段階の決定がこれらのコストを最小にするのを奨励します。同様に、配備直前に保証活動（例えばコードレビューと侵入テスト）をするまで待つことはコストをめざましく増やします。私たちは、保証を得る最も費用効果がよい方法がライフサイクルを通して努力の一定のレベルを保証に入れることであると思っています。

===しかし厳密さのレベルは間違っている….===

この合意は、開発されているソフトウェアが大企業または政府機関にとってかなり重要であると仮定します。私たちは、大部分のソフトウェア開発組織によって達成できる合意のために「厳格さのレベル」を選んで、最も一般的なリスクを確認して、取り扱います。

しかし、重要なアプリケーション（例えば医学であるか、財政的であるか、防衛に関連したソフトウェア）で使われそうであるソフトウェアについては、あなたは厳格さのレベルを上げたいかもしれません。あなたは、追加のレビュー、文書化とテストの活動を加えたくてもよいです。あなたは、脆弱性を探すこと、診断すること、修正することに対するプロセスを強化しくてもよいです。より機密を扱わないアプリケーションのために、あなたは活動を減らすか、取り除きたくてもよいです。

===しかし、私たちはそれほど多くのリスクをとることができない…===

この契約は、ソフトウェアにおけるセキュリティ脆弱性に対するリスクをとるのかという議論を容易にすることを目的とします。範囲の一端では、顧客はすべてのリスクをとることができました、そして、開発者はたくさんの脆弱性をもつコードを供給することができました。他の極端では、開発者はすべてのリスクをとることができて、完全なコードを供給することに対する責任を負うことができました。これらの両極端は、どちらとも実行不可能です。

現在、この契約において、開発者は要求においてカバーされたか、理にかなったテスト努力によってカバーされるべき問題に対するリスクをとります。しかし、「新しい」セキュリティ問題の改善は、顧客によって代金を払われるべきです。私たちは、これが開発者が彼らのリスクの境界となることができて役に立つバランスで、顧客が前もってセキュリティ要求を正しくするのを奨励すると思っています。しかし、この問題の多くの他の可能性がある解決が、あります。あなたには他の提案があるかどうか私たちに知らせます、そして、私たちは彼らをこの文書の将来の版に含めてもよいです。

ここでの議論がコードにおいてセキュリティ脆弱性を修正することに関連したリスクをカバーだけして、これらの脆弱性のあらゆるエクスプロイットに基づくあらゆるセキュリティ・インシデントから立ち直ることと関連したコストを含まないことに注意すべきです。私たちは、この領域におけるベスト・プラクティスに興味があります。

===私たちはどのように第三者のコードを保証するでしょうか===

ほとんどすべてのソフトウェアプロジェクトは、第三者のコード（例えばライブラリ、フレームワークと生産物）のかなりの量を使います。このコードは、ただセキュリティ観点から、カスタム・コードがあなたのプロジェクトのために特に発達したのと同じくらい重要です。
私たちはこのコードのセキュリティを確実にすることに対する責任が開発者によって負われて最もよいと思っています、しかし、彼らにはこのセキュリティを保証するために彼ら自身のいっぱいの能力がないかもしれません。しかし、セキュリティは「構築するか、買うか」議論の一部分でなければなりません、これはそれを促進する最もよい方法のようです。

開発者は、もちろん、終わりまで第三者のソフトウェアの提供者にこの責任をパスする選択権があります。開発者は彼ら自身第三者のコードを分析することもできるか、彼らのためにそれを分析するために、セキュリティの専門家を雇うこともできます。

===しかし、なぜ私はすべてのこのトラブルにいくべきなのでしょうか===

最後に、私たちはソフトウェアを契約しているプロセスの一部分をセキュリティをすることに代わるものがないと思っています。現在では、私たちは多くのソフトウェア開発契約のもとで供給されているコードのセキュリティに関する重大な誤解があると思っています。これは、わずかなソフトウェア経験または理解とともに個人によってなされる高価な訴訟と決定に至ることができるだけです。この問題の完全な議論に対して [[Secure software contracting hypothetical case study]] （[https://www.owasp.org/index.php/Secure_software_contracting_hypothetical_case_study/ja 日本語訳]）を読んでください。

多くの利点が、この契約を通してうまくいくことにあります。主要なものは、それが関係する関係者の間で期待を明らかにするということです。場合によっては、難しいセキュリティ問題がソフトウェアで表面化するとき、それは訴訟を妨げるのを助けます。また、これらは多くの法的で調整するコンプライアンスの理由によって必要とされる同じ活動です。

===しかし、このドキュメントですべてを作ることは難しい===

OWASPは、文書化を目的とした文書化を推奨しません。この契約は品質（量ではない）を促進することに集中します。私たちは、短いリスク評価、数ページの要求、短いセキュリティ設計文書、テストプラン、いくつかのテスト結果とともに、この契約に応じることが（若干のプロジェクトにおいて）ありえると思っています。

この文書の目標は、ライフサイクルの各段階で、単に適切な注意がセキュリティに払われたことを確実とすることです。追加の利点は、この文書が基本的に、このソフトウェアが安心してそれがそれがすると主張することをするのをまかせられなければならない理由に対する議論を配置する「証明パッケージ」をつくるために一緒に集められることができるということです。

==契約付属書==

===1. 序文===

この付属書は、顧客と開発者の間で_____________________ ("合意") するために作られます。顧客と開発者は、以下の条項によりソフトウェアのセキュリティを最大にすることに同意します。

===2. 原理===

この付属書は、ソフトウェア開発関係のすべての関係者のセキュリティ関連の権利と義務をはっきりさせることを目的とします。最高水準で、関係者は以下に同意します

;(a) セキュリティ決定は、リスクに基づきます : セキュリティについての決定は、関係するリスクのしっかりした理解に基づく顧客と開発者によって共同でなされす。

;(b) セキュリティ活動はバランスが保たれます : セキュリティ努力は、全てのソフトウェア開発ライフサイクル全体でおおよそ均一に配布されます。

;(c) セキュリティ活動は統合されます : ここに協議されるすべての活動と文書は、開発者のソフトウェア開発ライフサイクルに統合されて、残りのプロジェクトと別にしておかれるというわけではありません。この付属書の何も、どんな特定のソフトウェア開発プロセスを意味しません。

;(d) 脆弱性は予想されます : すべてのソフトウェアにはバグがあります、そして、それらのいくらかはセキュリティ問題を生じさせます。顧客と開発者は、ライフサイクルにおいてできるだけ早く脆弱性を特定するよう努めます。

;(e) セキュリティ情報は、完全に明らかにされます : すべてのセキュリティ関連した情報は、すぐに、そして、完全に、顧客と開発者で共有されます。

;(f) 役に立つセキュリティ文書だけが必要とされます : セキュリティ文書は、セキュリティ設計、リスク分析または問題を明確に記述するために詳細にわたる必要はありません。

===3.ライフサイクル活動===

;(a) リスク識別 : 開発者とClientは、アプリケーションに直面しているリスクを理解して、文書化するために一緒に働くことに同意します。この努力は、アプリケーションにより提供される重要な資産と機能に主要なリスクを確認しなければなりません。要件部にリストされるトピックの各々は、考慮されなければなりません。

;(b) 要求 : リスクに基づいて、開発者と顧客は、開発されるソフトウェアの仕様の一部として詳細なセキュリティ要件を確立するために一緒に働くことに同意します。この付属書の要件部分で記載されるトピックの各々は、開発者と顧客によって協議されなければならなくて、評価されなければなりません。これらの要件は、カスタム・ソフト、第三者のソフトウェアまたはプラットホームによって満たされてもよいです。

;(c) 設計 : 開発者は、セキュリティ要件の各々を達成するために明確に設計を説明する文書を提供することに同意します。ほとんどの場合、この文書はセキュリティ手法を記載します、そこで、手法はアーキテクチャに適合しました、そして、関連したすべては彼らの適正使用を確実にするためにパターンを設計します。設計は、サポートがカスタム・ソフトか、第三者のソフトウェアかプラットホームから来るかどうか、明確に指定しなければなりません。

;(d) 実装 : 開発者は、一組のセキュアなコーディング指針に提供することに、従って、一組の共通セキュリティ制御プログラミング・インターフェース（例えば [http://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API OWASP Enterprise Security API（ESAPI）] ）を使って同意します。ガイドラインは、コードがどのようにフォーマットされなければならなくて、構築されなければならなくて、コメントされなければならないかについて示します。共通セキュリティ制御プログラミング・インターフェースは、セキュリティ制御がどのように呼ばれなければならないか、そして、セキュリティ制御がどのように機能するか定めます。すべてのセキュリティに関連したコードは、完全にコメントされます。共通のセキュリティ脆弱性を回避するときの具体的なガイダンスは、含まれなければなりません。また、すべてのコードはセキュリティ要件に対して少なくとも他の一人の開発者によってレビューされなければなりません、そして、それの前のコーディング・ガイドラインは単体テストの準備ができていると思われます。

;(e) セキュリティ分析とテスト : 開発者は、（ [http://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project OWASP Application Security Verification Standard (ASVS)] のような）合意された標準の検証要件により、アプリケーション・セキュリティ分析とテスト（「検証」とも言われる）を実行します。開発者は、標準の報告要件によって検証結論を文書化しなければなりません。開発者は、検証結論を顧客に提供しなければなりません。

;(f) セキュリティ配備 : 開発者は、ソフトウェアの全体的なセキュリティのために完全にすべてのセキュリティ関連した構成オプションとそれらの関連性を記述するセキュアな構成ガイドラインを提供することに同意します。ガイドラインは、オペレーティングシステム、ウェブサーバとアプリケーション・サーバーを含むサポート的なプラットホームにおける依存関係の完全な記述を含まなければいけません。また、どのようにそれらをセキュリティのために構成されるべきかを含まなければいけません。ソフトウェアのデフォルトコンフィグレーションは、セキュアでなければなりません。

===4.セキュリティ要求エリア===

以下のトピック領域は、リスク理解と要求定義活動の間、考慮されなければなりません。この努力は一組の具体的で、注文仕立てで、分析できる要求を生産しなければなりません。そして、開発者と顧客はこのプロセスに関与していなければならなくて、要求の最終セットについて同意しなければなりません。

;(a) 入力検証とエンコーディング : 要求は、ユーザー、ファイルシステム、データベース、ディレクトリまたは外部システムからであるかどうかにかかわらず、アプリケーションへの各々の入力を標準化し、検証し、コード化するためにルールを指定しなければなりません。　　　デフォルトルールは、それが何が許可されるかという詳細な仕様にマッチしない限り、すべての入力が無効であるということでなければなりません。そのうえ、無効な入力が受け取られるとき、要求はとられる措置を指定しなければなりません。具体的には、アプリケーションはインジェクション、オーバフロー、不正操作することまたは他の不正な入力攻撃に影響されやすくてはいけません。

;(b) 認証とセッション管理 : 要求は、認証証明書とセッション識別子がどのようにそれらのライフサイクルを通して保護されているかについて明記しなければなりません。すべての関連する機能（パスワード忘却、パスワード変更、パスワードリマインダ、ログアウト、そして複数ログインを含む）に対する要求は含められなければいけません。

;(c) アクセス制御 : 要求は、アプリケーションで使われるすべての役割（グループ、特権、認可）の詳細な記述を含まなければなりません。要求は、アプリケーションにより提供されるすべての資産と機能も示さなければなりません。要求は、完全に各々の資産に正確なアクセス権を指定しなければならなくて、各々の役割に対して機能しなければなりません。アクセス制御マトリックスは、これらのルールのための提案されたフォーマットです。

;(d) エラー処理 : 要求は、処理の間、発生しているエラーが取り扱われる方法を詳述しなければなりません。若干のアプリケーションはエラーの場合には最もよい努力結果を提供しなければなりません、一方、他はすぐに処理を終了しなければなりません。

;(e) ロギング : 要求は、どんなイベントがセキュリティに関連して、記録される必要があるか、たとえば、検知された攻撃、失敗したログイン試行、認可を上回ろうとする試行、を指定しなければなりません。要求は、時間と日付、イベント記述、アプリケーション詳細とフォレンジクス努力に役立つ他の情報を含む、各々のイベントでどんな情報を記録するべきかについても指定しなければなりません。

;(f) 外部システムへの接続 : 要求は、認証と暗号化がどのようにすべての外部システム（例えばデータベース、ディレクトリとウェブ・サービス）のために取り扱われるかについて指定しなければなりません。外部システムでコミュニケーションのために必要とされるすべてのクレディンシャルは、暗号化された形で構成ファイルでコードの外側に保存されなければなりません。

;(g) 暗号 : 要求は、どんなデータが暗号化されなければならないか、暗号化されることがどれほどか、そして、すべての証明書と他のクレディンシャルがどのように取り扱われなければならないか指定しなければなりません。アプリケーションは、広く使われていてテストされた暗号化ライブラリで実装される標準的なアルゴリズムを使用しなければなりません。

;(h) 可用性 : 要求は、それがどのようにサービス不能攻撃から保護するかについて指定しなければなりません。アプリケーションへのすべてのありそうな攻撃は考慮されなければなりません。そして、認証ロックアウト、接続消耗と他の資源消耗攻撃を含みます。

;(i) セキュアな設定 : 要求は、すべてのセキュリティに関連した構成オプションに対するデフォルト値がセキュアでなければならないことを示していなければなりません。監査目的のために、ソフトウェアはすべてのセキュリティに関連した構成詳細を示している簡単に読めるレポートをつくることができなければなりません。

;(j) 特定の脆弱性 : 要求は、ソフトウェアで見つかってはならない一組の具体的な脆弱性を含まなければなりません。指定されていないならば、ソフトウェアは現在の「OWASP Top Ten Most Critical Web Application Vulnerabilities」で記述される瑕疵の何も含んではいけません。

===5. 要員および組織===

;(a) セキュリティ・アーキテクト : 開発者は一つの上位の技術的な資源に責任をセキュリティに指定します。そして、プロジェクトのセキュリティ・アーキテクトとして知られています。セキュリティ・アーキテクトは、各々の納品可能なもののセキュリティを保証します。

;(b) セキュリティ・トレーニング : 開発者は、開発者チームのすべてのメンバーがセキュアなプログラミング技法の訓練をされたことを確かめる役割を果たします。

;(c) 信用できる開発者 : 開発者は、すべての開発チーム・メンバーの適切な経歴調査を実行することに同意します。

===6.開発環境===

;(a) セキュア・コーディング : 開発者は、どんなツールがセキュアなコーディングを促すためにソフトウェア開発環境で使われるかについて明らかにしなければなりません。

;(b) 構成管理 : 開発者は、ソフトウェア・ベースラインに対するすべての変更とすべての関連した設定とビルド・ファイルを関連づけ　とすべての関連した構成にすべての変化と関連したチーム・メンバーを認証して、記録して、ファイルを構築したソース・コード管理システムを使用しなければなりません。

;(c) 配布 : 開発者は、ソースから確実に完全な配布を構築するビルド・プロセスを使用しなければなりません。このプロセスは、顧客に供給されるソフトウェアの完全性を確かめる方法を含まなければなりません。

===7. ライブラリ、フレームワーク、および生産物===

;(a) 開示 : 開発者は、商用、フリー、オープンソース、クローズソースであるにせよ、すべてのライブラリ、フレームワーク、構成要素と他の生産物を含む、ソフトウェアで使われるすべての第三者のソフトウェアを明らかにしなければなりません。

;(b) 評価 : 開発者は、第三者のソフトウェアがこの契約のすべての条件を満たして、この契約の基で開発されたカスタム開発されたコードと同じくらいセキュアなことを確実とするために、理にかなった努力をしなければなりません。

===8. セキュリティ・レビュー===

;(a) レビューする権利 : 依頼人には、ソフトウェアを納品の60日間以内にいつでも彼らの費用でセキュリティ瑕疵のためにレビューしておく権利があります。開発者は、ソース・コードとテスト環境へのアクセスを提供することによって理にかなったサポートをレビュー・チームに提供することに同意します。

;(b) レビュー・カバレッジ : セキュリティ・レビューは供給されるソフトウェアのすべての面をカバーしなければなりません。そして、カスタム・コード、構成要素、生産物とシステム設定を含みます。

;(c) レビューの範囲 : 最低限で、レビューはセキュリティ要求の全てをカバーしなければならなくて、他の一般的な脆弱性を捜さなければなりません。レビューは、脆弱性スキャン、侵入テスト、ソースコードの静的分析と専門家のコードレビューの組み合わせを含んでもよいです。

;(d) 見つけられた問題 : 発見されたセキュリティ問題は、顧客と開発者に報告されます。すべての問題は、この付属書のセキュリティ問題マネジメント部分により追跡されて、矯正されます。

===9. セキュリティ問題マネジメント ===

;(a) 識別 : 要求、設計、実装、テスト、配備、または、運用中の問題にせよ、開発者は全てのライフサイクルの間に発見されるすべてのセキュリティ問題を追います。各々のセキュリティ問題に関連したリスクは、発見後できるだけ早く、評価されて、文書化されて、発見の後、顧客に報告されます。

;(b) 保護 : 開発者はセキュリティ問題と付随する文書に関して情報を適切に保護します。そして、運用中の顧客ソフトウェアの脆弱性が露出するという可能性を制限するのを助けます。

;(c) 改善 : 納品の前に確認されるセキュリティ問題は、開発者によって修正されなければなりません。納品の後に発見されるセキュリティ問題は、本契約の規定による他のバグと問題として同様に取り扱われなければなりません。

===10. 保証===

;(a) 保証 : 開発者は、開発プロセスを通して作成されるセキュリティ文書からなる「証明パッケージ」を提供します。パッケージは、セキュリティ要求、設計、実装と試験結果がきちんと完了された、そして、すべてのセキュリティ問題が適切に解決されたと確認しなければなりません。

;(b) 自己証明 : セキュリティ・アーキテクトは、ソフトウェアがセキュリティ要求を満たすこと、すべてのセキュリティ活動が実行されていること、そして、すべての識別されたセキュリティ問題が文書化されて、解決されたことを証明します。証明ステータスに対するあらゆる例外は、納品で完全に文書化されなければなりません。

;(c) 悪意のあるコードのなし : 開発者は、ソフトウェアがソフトウェア要求をサポートせず、コンピュータ・ウイルス、ワーム、時限爆弾、バック・ドア、トロイの木馬、イースターエッグと他のあらゆる形の悪意のあるソフトウェアを含む、アプリケーションのセキュリティを弱めるあらゆるコードを含んではならないと保証します。

===11. セキュリティ承認と保守 ===

;(a) 受け入れ : 証明パッケージが完全であり、すべてのセキュリティ問題が解決されるまで、ソフトウェアは受け入れられると考慮されてはいけません。

;(b) セキュリティ問題の調査 : 受理の後、セキュリティ問題が発見されるか、かなり疑われるならば、開発者は顧客が問題の性質を決定するために調査を実行するのを援助しなければなりません。それがセキュリティ要求によってカバーされないで、セキュリティ・テストの理にかなった範囲の外にあるならば、問題は「新しい」と思われなければなりません。

;(c) 新しいセキュリティ問題 : 開発者と顧客は、新しいセキュリティ問題を解決するために必要な努力を探し出すことに同意します。また、それらに取り組むために必要とされる仕事を実行するための合意を達成するために誠意を持って交渉することに同意します。

;(d) 他のセキュリティ問題 : 開発者は堅実なソフトウェア開発慣行。そして、リスクのひどさを考慮すること、そして、できるだけ速く新しいと思われないすべてのセキュリティ問題を解決することと一致したすべての商業的に理にかなった努力を使わなければなりません

[[Category:OWASP Legal Project]]

__NOTOC__

OWASP Legal Project Roadmap/ja

2011-07-05T04:49:16Z

Tomo:

プロジェクトの全体的なゴールは以下である。

ソフトウェア・セキュリティの法律面で、開発者、
ソフトウェア購入者および販売者にサポートを提供すること

当面の間、私たちは以下の戦術的な目標に集中する。

# 契約付属書を開発することを続ける
# ソフトウェア・セキュリティの契約と取得を取り巻くプロセス活動をつくる
# 法的なプロセス活動をすべてのOWASPプロセス資材に統合する

私たちがこれらの目標を達成するのを助けるために定められた現在のタスクは次のとおりである。

* プロセス活動「ソフトウェア・セキュリティにおいて合意に達する」を下書きする
* 付属書の有用性を評価するために事例研究を実施する

[[Category:OWASP Legal Project]]

OWASP Secure Software Contract Annex/ja

2011-07-05T02:22:42Z

Tomo: /* しかし、なぜ私はすべてのこのトラブルにいくべきなのでしょうか */

'''セキュア・ソフトウェア開発契約付属書'''

警告：この文書は、単にガイダンスと考えられなければなりません。
OWASPは、ソフトウェア契約を交渉するのを手助けするために、
あなたが資格のある弁護士に相談するよう強く勧めます。

==序文==

OWASPセキュア・ソフトウェア開発契約付属書は、ソフトウェアの開発者とその顧客が、開発または供給されるソフトウェアのセキュリティに関連した重要な契約条項と条件を交渉し、取り込むことを助けます。このプロジェクトの理由は、多くの契約はこれらの問題に触れておらず、しばしば関係者が実際に同意されたものに劇的に異なる見解を持つことです。私たちは、これらの条項を明確に述べることは、双方の関係者が進め方について情報に基づいた意思決定ができることを確実にするもっともよい方法であると思っています。

「市場がより良いセキュリティを要求するとき、商用ソフトのセキュリティは改善します。
最低限、あらゆるソフトウェア提案依頼書は、ベンダーに彼らがセキュリティ脆弱性に対して
生産物をテストする方法を詳述するよう依頼しなければなりません。このステップは、企業が
セキュリティを評価すると市販ソフトウェアのベンダーと外部調達された開発者を納得させ始めます。」
-- John Pescatore（Gartnerのリサーチ・ディレクター）として

私たちは、顧客と開発者が、期待について議論して、責任について交渉することに対するフレームワークとしてこの文書を使うよう勧めます。この付属書は、ソフトウェア開発契約に添付されることを目的とします。これらの条項は交渉の余地があります。そして、それらは顧客と開発者によって、協議されることができて、協議されなければならないことを意味します。

==プロジェクトについて==

この文書はOpen Web Application Security Project（OWASP）財団（セキュアなソフトウェアに関連した無料でオープンなツールとドキュメンテーションを作成することを専門とする非営利の慈善団体）によって作成されました。個人契約において容易に使用できるようにするために、この文書はCC Share Alike 3.0ライセンスにて提供されます。あなたが適すると思うように、修正してもよいですし、使用してもよいです。あなたは、http://www.owasp.com/index.php/OWASP_Legal_Project でこのプロジェクトについて更なる詳細を見つけることができます。私たちは、ソフトウェア（法律コミュニティだけでなく）の製作者と消費者のコメントを歓迎します。

OWASPは、この文書の研究と準備における彼らの役割に対して [http://www.aspectsecurity.com Aspect Security] から特別な貢献を感謝して認めます。

==異論==

以下のわずかなページは、ソフトウェア開発契約においてこの言い回しを使用することに対するいくらかのたびたび聞こえる異論をカバーします：

===しかし、すべての条項が私たちにとって適切であるというわけではありません…===

この文書は、あなたの合意の開始地点です。あなたは、すべての活動が好きではないかもしれません、または、より多くの提案をしたいかもしれません。あなたは異なる責任を割り当てたいかもしれません。この文書は、すべてのソフトウェア顧客と開発者の要望を厳密に取り込むことを意図しているわけではありません。ソフトウェアが最終的にセキュアになることを確実にするために重要である、主要な項目を議論するためのフレームワークを提供することを意図します。セキュリティを議論して合意を得た後で、あなたはこの合意を適合するように調整すべきです。

===しかし、これらの活動に対して誰が代金を払わなければならないのでしょうか===

この契約は、ソフトウェア開発者により多くの負担を与えることはほとんどありません。問題は、セキュリティ ― もちろんそこにある ― と関連したコストがあるかどうかということでありません。むしろ、適切な問題はどんな活動がそれらのコストを最小にするために双方によって実行されなければならないかということです、そして、いつ、それらは起こらなければなりませんか。

この付属書は、誰がここに記述される活動の料金を払わなければならないかという問題については、意図的に語られていません。これらの活動の多くがすでに起こらなければならなくて、多くの顧客によって期待される一方、それたはソフトウェア産業で定期的に実践されることはありません。誰が（そして、いくら）支払うかという問題が、交渉の一部でなければなりません。

セキュリティのコストを計算することは、非常に難しいです。セキュリティ活動を実行することに関連したコストがある一方、それらを無視することに関連したかなりのコストもあります。私たちは、ソフトウェアを開発する最も費用対効果がよい方法について確信しています。それは、セキュリティ瑕疵が導入されるという可能性を減らして、瑕疵を導入して、それを修正することの間で時間を最小にすることです。

コストを計算するときにする一つの重要な区別は、セキュリティ手法を構築することと、それらの手法が正しくて効果的であることを確実にする保証活動の間にあります。ライフサイクルの終わりに手法を加えようとすることは、深刻な設計問題を引き起こすことがありえて、めざましくコストを増やします。この合意は、手法についての早い段階の決定がこれらのコストを最小にするのを奨励します。同様に、配備直前に保証活動（例えばコードレビューと侵入テスト）をするまで待つことはコストをめざましく増やします。私たちは、保証を得る最も費用効果がよい方法がライフサイクルを通して努力の一定のレベルを保証に入れることであると思っています。

===しかし厳密さのレベルは間違っている….===

この合意は、開発されているソフトウェアが大企業または政府機関にとってかなり重要であると仮定します。私たちは、大部分のソフトウェア開発組織によって達成できる合意のために「厳格さのレベル」を選んで、最も一般的なリスクを確認して、取り扱います。

しかし、重要なアプリケーション（例えば医学であるか、財政的であるか、防衛に関連したソフトウェア）で使われそうであるソフトウェアについては、あなたは厳格さのレベルを上げたいかもしれません。あなたは、追加のレビュー、文書化とテストの活動を加えたくてもよいです。あなたは、脆弱性を探すこと、診断すること、修正することに対するプロセスを強化しくてもよいです。より機密を扱わないアプリケーションのために、あなたは活動を減らすか、取り除きたくてもよいです。

===しかし、私たちはそれほど多くのリスクをとることができない…===

この契約は、ソフトウェアにおけるセキュリティ脆弱性に対するリスクをとるのかという議論を容易にすることを目的とします。範囲の一端では、顧客はすべてのリスクをとることができました、そして、開発者はたくさんの脆弱性をもつコードを供給することができました。他の極端では、開発者はすべてのリスクをとることができて、完全なコードを供給することに対する責任を負うことができました。これらの両極端は、どちらとも実行不可能です。

現在、この契約において、開発者は要求においてカバーされたか、理にかなったテスト努力によってカバーされるべき問題に対するリスクをとります。しかし、「新しい」セキュリティ問題の改善は、顧客によって代金を払われるべきです。私たちは、これが開発者が彼らのリスクの境界となることができて役に立つバランスで、顧客が前もってセキュリティ要求を正しくするのを奨励すると思っています。しかし、この問題の多くの他の可能性がある解決が、あります。あなたには他の提案があるかどうか私たちに知らせます、そして、私たちは彼らをこの文書の将来の版に含めてもよいです。

ここでの議論がコードにおいてセキュリティ脆弱性を修正することに関連したリスクをカバーだけして、これらの脆弱性のあらゆるエクスプロイットに基づくあらゆるセキュリティ・インシデントから立ち直ることと関連したコストを含まないことに注意すべきです。私たちは、この領域におけるベスト・プラクティスに興味があります。

===私たちはどのように第三者のコードを保証するでしょうか===

ほとんどすべてのソフトウェアプロジェクトは、第三者のコード（例えばライブラリ、フレームワークと生産物）のかなりの量を使います。このコードは、ただセキュリティ観点から、カスタム・コードがあなたのプロジェクトのために特に発達したのと同じくらい重要です。
私たちはこのコードのセキュリティを確実にすることに対する責任が開発者によって負われて最もよいと思っています、しかし、彼らにはこのセキュリティを保証するために彼ら自身のいっぱいの能力がないかもしれません。しかし、セキュリティは「構築するか、買うか」議論の一部分でなければなりません、これはそれを促進する最もよい方法のようです。

開発者は、もちろん、終わりまで第三者のソフトウェアの提供者にこの責任をパスする選択権があります。開発者は彼ら自身第三者のコードを分析することもできるか、彼らのためにそれを分析するために、セキュリティの専門家を雇うこともできます。

===しかし、なぜ私はすべてのこのトラブルにいくべきなのでしょうか===

最後に、私たちはソフトウェアを契約しているプロセスの一部分をセキュリティをすることに代わるものがないと思っています。現在では、私たちは多くのソフトウェア開発契約のもとで供給されているコードのセキュリティに関する重大な誤解があると思っています。これは、わずかなソフトウェア経験または理解とともに個人によってなされる高価な訴訟と決定に至ることができるだけです。この問題の完全な議論に対して [[Secure software contracting hypothetical case study]] （[https://www.owasp.org/index.php/Secure_software_contracting_hypothetical_case_study/ja 日本語訳]）を読んでください。

多くの利点が、この契約を通してうまくいくことにあります。主要なものは、それが関係する関係者の間で期待を明らかにするということです。場合によっては、難しいセキュリティ問題がソフトウェアで表面化するとき、それは訴訟を妨げるのを助けます。また、これらは多くの法的で調整するコンプライアンスの理由によって必要とされる同じ活動です。

===しかし、このドキュメントですべてを作ることは難しい===

OWASPは、文書化を目的とした文書化を推奨しません。この契約は品質（量ではない）を促進することに集中します。私たちは、短いリスク評価、数ページの要求、短いセキュリティ設計文書、テストプラン、いくつかのテスト結果とともに、この契約に応じることが（若干のプロジェクトにおいて）ありえると思っています。

この文書の目標は、ライフサイクルの各段階で、単に適切な注意がセキュリティに払われたことを確実とすることです。追加の利点は、この文書が基本的に、このソフトウェアが安心してそれがそれがすると主張することをするのをまかせられなければならない理由に対する議論を配置する「証明パッケージ」をつくるために一緒に集められることができるということです。

==契約付属書==

===1. 序文===

この付属書は、顧客と開発者の間で_____________________ ("合意") するために作られます。顧客と開発者は、以下の条件のよりソフトウェアのセキュリティを最大にすることに同意します。

===2. 原理===

この付属書は、ソフトウェア開発関係のすべての関係者のセキュリティ関連の権利と義務をはっきりさせることを目的とします。最高水準で、関係者は以下に同意します

;(a) セキュリティ決定は、リスクに基づきます : セキュリティについての決定は、関係するリスクのしっかりした理解に基づく顧客と開発者によって共同でなされす。

;(b) セキュリティ活動はバランスが保たれます : セキュリティ努力は、全てのソフトウェア開発ライフサイクル全体でおおよそ均一に配布されます。

;(c) セキュリティ活動は統合されます : ここに協議されるすべての活動と文書は、開発者のソフトウェア開発ライフサイクルに統合されて、残りのプロジェクトと別にしておかれるというわけではありません。この付属書の何も、どんな特定のソフトウェア開発プロセスを意味しません。

;(d) 脆弱性は予想されます : すべてのソフトウェアにはバグがあります、そして、それらのいくらかはセキュリティ問題を生じさせます。顧客と開発者は、ライフサイクルにおいてできるだけ早く脆弱性を特定するよう努めます。

;(e) セキュリティ情報は、完全に明らかにされます : すべてのセキュリティ関連した情報は、すぐに、そして、完全に、顧客と開発者で共有されます。

;(f) 役に立つセキュリティ文書だけが必要とされます : セキュリティ文書は、セキュリティ設計、リスク分析または問題を明確に記述するために詳細にわたる必要はありません。

===3.ライフサイクル活動===

;(a) リスク識別 : 開発者とClientは、アプリケーションに直面しているリスクを理解して、文書化するために一緒に働くことに同意します。この努力は、アプリケーションにより提供される重要な資産と機能に主要なリスクを確認しなければなりません。要件部にリストされるトピックの各々は、考慮されなければなりません。

;(b) 要求 : リスクに基づいて、開発者と顧客は、開発されるソフトウェアの仕様の一部として詳細なセキュリティ要件を確立するために一緒に働くことに同意します。この付属書の要件部分で記載されるトピックの各々は、開発者と顧客によって協議されなければならなくて、評価されなければなりません。これらの要件は、カスタム・ソフト、第三者のソフトウェアまたはプラットホームによって満たされてもよいです。

;(c) 設計 : 開発者は、セキュリティ要件の各々を達成するために明確に設計を説明する文書を提供することに同意します。ほとんどの場合、この文書はセキュリティ手法を記載します、そこで、手法はアーキテクチャに適合しました、そして、関連したすべては彼らの適正使用を確実にするためにパターンを設計します。設計は、サポートがカスタム・ソフトか、第三者のソフトウェアかプラットホームから来るかどうか、明確に指定しなければなりません。

;(d) 実装 : 開発者は、一組のセキュアなコーディング指針に提供することに、従って、一組の共通セキュリティ制御プログラミング・インターフェース（例えば [http://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API OWASP Enterprise Security API（ESAPI）] ）を使って同意します。ガイドラインは、コードがどのようにフォーマットされなければならなくて、構築されなければならなくて、コメントされなければならないかについて示します。共通セキュリティ制御プログラミング・インターフェースは、セキュリティ制御がどのように呼ばれなければならないか、そして、セキュリティ制御がどのように機能するか定めます。すべてのセキュリティに関連したコードは、完全にコメントされます。共通のセキュリティ脆弱性を回避するときの具体的なガイダンスは、含まれなければなりません。また、すべてのコードはセキュリティ要件に対して少なくとも他の一人の開発者によってレビューされなければなりません、そして、それの前のコーディング・ガイドラインは単体テストの準備ができていると思われます。

;(e) セキュリティ分析とテスト : 開発者は、（ [http://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project OWASP Application Security Verification Standard (ASVS)] のような）合意された標準の検証要件により、アプリケーション・セキュリティ分析とテスト（「検証」とも言われる）を実行します。開発者は、標準の報告要件によって検証結論を文書化しなければなりません。開発者は、検証結論を顧客に提供しなければなりません。

;(f) セキュリティ配備 : 開発者は、ソフトウェアの全体的なセキュリティのために完全にすべてのセキュリティ関連した構成オプションとそれらの関連性を記述するセキュアな構成ガイドラインを提供することに同意します。ガイドラインは、オペレーティングシステム、ウェブサーバとアプリケーション・サーバーを含むサポート的なプラットホームにおける依存関係の完全な記述を含まなければいけません。また、どのようにそれらをセキュリティのために構成されるべきかを含まなければいけません。ソフトウェアのデフォルトコンフィグレーションは、セキュアでなければなりません。

===4.セキュリティ要求エリア===

以下のトピック領域は、リスク理解と要求定義活動の間、考慮されなければなりません。この努力は一組の具体的で、注文仕立てで、分析できる要求を生産しなければなりません。そして、開発者と顧客はこのプロセスに関与していなければならなくて、要求の最終セットについて同意しなければなりません。

;(a) 入力検証とエンコーディング : 要求は、ユーザー、ファイルシステム、データベース、ディレクトリまたは外部システムからであるかどうかにかかわらず、アプリケーションへの各々の入力を標準化し、検証し、コード化するためにルールを指定しなければなりません。　　　デフォルトルールは、それが何が許可されるかという詳細な仕様にマッチしない限り、すべての入力が無効であるということでなければなりません。そのうえ、無効な入力が受け取られるとき、要求はとられる措置を指定しなければなりません。具体的には、アプリケーションはインジェクション、オーバフロー、不正操作することまたは他の不正な入力攻撃に影響されやすくてはいけません。

;(b) 認証とセッション管理 : 要求は、認証証明書とセッション識別子がどのようにそれらのライフサイクルを通して保護されているかについて明記しなければなりません。すべての関連する機能（パスワード忘却、パスワード変更、パスワードリマインダ、ログアウト、そして複数ログインを含む）に対する要求は含められなければいけません。

;(c) アクセス制御 : 要求は、アプリケーションで使われるすべての役割（グループ、特権、認可）の詳細な記述を含まなければなりません。要求は、アプリケーションにより提供されるすべての資産と機能も示さなければなりません。要求は、完全に各々の資産に正確なアクセス権を指定しなければならなくて、各々の役割に対して機能しなければなりません。アクセス制御マトリックスは、これらのルールのための提案されたフォーマットです。

;(d) エラー処理 : 要求は、処理の間、発生しているエラーが取り扱われる方法を詳述しなければなりません。若干のアプリケーションはエラーの場合には最もよい努力結果を提供しなければなりません、一方、他はすぐに処理を終了しなければなりません。

;(e) ロギング : 要求は、どんなイベントがセキュリティに関連して、記録される必要があるか、たとえば、検知された攻撃、失敗したログイン試行、認可を上回ろうとする試行、を指定しなければなりません。要求は、時間と日付、イベント記述、アプリケーション詳細とフォレンジクス努力に役立つ他の情報を含む、各々のイベントでどんな情報を記録するべきかについても指定しなければなりません。

;(f) 外部システムへの接続 : 要求は、認証と暗号化がどのようにすべての外部システム（例えばデータベース、ディレクトリとウェブ・サービス）のために取り扱われるかについて指定しなければなりません。外部システムでコミュニケーションのために必要とされるすべてのクレディンシャルは、暗号化された形で構成ファイルでコードの外側に保存されなければなりません。

;(g) 暗号 : 要求は、どんなデータが暗号化されなければならないか、暗号化されることがどれほどか、そして、すべての証明書と他のクレディンシャルがどのように取り扱われなければならないか指定しなければなりません。アプリケーションは、広く使われていてテストされた暗号化ライブラリで実装される標準的なアルゴリズムを使用しなければなりません。

;(h) 可用性 : 要求は、それがどのようにサービス不能攻撃から保護するかについて指定しなければなりません。アプリケーションへのすべてのありそうな攻撃は考慮されなければなりません。そして、認証ロックアウト、接続消耗と他の資源消耗攻撃を含みます。

;(i) セキュアな設定 : 要求は、すべてのセキュリティに関連した構成オプションに対するデフォルト値がセキュアでなければならないことを示していなければなりません。監査目的のために、ソフトウェアはすべてのセキュリティに関連した構成詳細を示している簡単に読めるレポートをつくることができなければなりません。

;(j) 特定の脆弱性 : 要求は、ソフトウェアで見つかってはならない一組の具体的な脆弱性を含まなければなりません。指定されていないならば、ソフトウェアは現在の「OWASP Top Ten Most Critical Web Application Vulnerabilities」で記述される瑕疵の何も含んではいけません。

===5. 要員および組織===

;(a) セキュリティ・アーキテクト : 開発者は一つの上位の技術的な資源に責任をセキュリティに指定します。そして、プロジェクトのセキュリティ・アーキテクトとして知られています。セキュリティ・アーキテクトは、各々の納品可能なもののセキュリティを保証します。

;(b) セキュリティ・トレーニング : 開発者は、開発者チームのすべてのメンバーがセキュアなプログラミング技法の訓練をされたことを確かめる役割を果たします。

;(c) 信用できる開発者 : 開発者は、すべての開発チーム・メンバーの適切な経歴調査を実行することに同意します。

===6.開発環境===

;(a) セキュア・コーディング : 開発者は、どんなツールがセキュアなコーディングを促すためにソフトウェア開発環境で使われるかについて明らかにしなければなりません。

;(b) 構成管理 : 開発者は、ソフトウェア・ベースラインに対するすべての変更とすべての関連した設定とビルド・ファイルを関連づけ　とすべての関連した構成にすべての変化と関連したチーム・メンバーを認証して、記録して、ファイルを構築したソース・コード管理システムを使用しなければなりません。

;(c) 配布 : 開発者は、ソースから確実に完全な配布を構築するビルド・プロセスを使用しなければなりません。このプロセスは、顧客に供給されるソフトウェアの完全性を確かめる方法を含まなければなりません。

===7. ライブラリ、フレームワーク、および生産物===

;(a) 開示 : 開発者は、商用、フリー、オープンソース、クローズソースであるにせよ、すべてのライブラリ、フレームワーク、構成要素と他の生産物を含む、ソフトウェアで使われるすべての第三者のソフトウェアを明らかにしなければなりません。

;(b) 評価 : 開発者は、第三者のソフトウェアがこの契約のすべての条件を満たして、この契約の基で開発されたカスタム開発されたコードと同じくらいセキュアなことを確実とするために、理にかなった努力をしなければなりません。

===8. セキュリティ・レビュー===

;(a) レビューする権利 : 依頼人には、ソフトウェアを納品の60日間以内にいつでも彼らの費用でセキュリティ瑕疵のためにレビューしておく権利があります。開発者は、ソース・コードとテスト環境へのアクセスを提供することによって理にかなったサポートをレビュー・チームに提供することに同意します。

;(b) レビュー・カバレッジ : セキュリティ・レビューは供給されるソフトウェアのすべての面をカバーしなければなりません。そして、カスタム・コード、構成要素、生産物とシステム設定を含みます。

;(c) レビューの範囲 : 最低限で、レビューはセキュリティ要求の全てをカバーしなければならなくて、他の一般的な脆弱性を捜さなければなりません。レビューは、脆弱性スキャン、侵入テスト、ソースコードの静的分析と専門家のコードレビューの組み合わせを含んでもよいです。

;(d) 見つけられた問題 : 発見されたセキュリティ問題は、顧客と開発者に報告されます。すべての問題は、この付属書のセキュリティ問題マネジメント部分により追跡されて、矯正されます。

===9. セキュリティ問題マネジメント ===

;(a) 識別 : 要求、設計、実装、テスト、配備、または、運用中の問題にせよ、開発者は全てのライフサイクルの間に発見されるすべてのセキュリティ問題を追います。各々のセキュリティ問題に関連したリスクは、発見後できるだけ早く、評価されて、文書化されて、発見の後、顧客に報告されます。

;(b) 保護 : 開発者はセキュリティ問題と付随する文書に関して情報を適切に保護します。そして、運用中の顧客ソフトウェアの脆弱性が露出するという可能性を制限するのを助けます。

;(c) 改善 : 納品の前に確認されるセキュリティ問題は、開発者によって修正されなければなりません。納品の後に発見されるセキュリティ問題は、本契約の規定による他のバグと問題として同様に取り扱われなければなりません。

===10. 保証===

;(a) 保証 : 開発者は、開発プロセスを通して作成されるセキュリティ文書からなる「証明パッケージ」を提供します。パッケージは、セキュリティ要求、設計、実装と試験結果がきちんと完了された、そして、すべてのセキュリティ問題が適切に解決されたと確認しなければなりません。

;(b) 自己証明 : セキュリティ・アーキテクトは、ソフトウェアがセキュリティ要求を満たすこと、すべてのセキュリティ活動が実行されていること、そして、すべての識別されたセキュリティ問題が文書化されて、解決されたことを証明します。証明ステータスに対するあらゆる例外は、納品で完全に文書化されなければなりません。

;(c) 悪意のあるコードのなし : 開発者は、ソフトウェアがソフトウェア要求をサポートせず、コンピュータ・ウイルス、ワーム、時限爆弾、バック・ドア、トロイの木馬、イースターエッグと他のあらゆる形の悪意のあるソフトウェアを含む、アプリケーションのセキュリティを弱めるあらゆるコードを含んではならないと保証します。

===11. セキュリティ承認と保守 ===

;(a) 受け入れ : 証明パッケージが完全であり、すべてのセキュリティ問題が解決されるまで、ソフトウェアは受け入れられると考慮されてはいけません。

;(b) セキュリティ問題の調査 : 受理の後、セキュリティ問題が発見されるか、かなり疑われるならば、開発者は顧客が問題の性質を決定するために調査を実行するのを援助しなければなりません。それがセキュリティ要求によってカバーされないで、セキュリティ・テストの理にかなった範囲の外にあるならば、問題は「新しい」と思われなければなりません。

;(c) 新しいセキュリティ問題 : 開発者と顧客は、新しいセキュリティ問題を解決するために必要な努力を探し出すことに同意します。また、それらに取り組むために必要とされる仕事を実行するための合意を達成するために誠意を持って交渉することに同意します。

;(d) 他のセキュリティ問題 : 開発者は堅実なソフトウェア開発慣行。そして、リスクのひどさを考慮すること、そして、できるだけ速く新しいと思われないすべてのセキュリティ問題を解決することと一致したすべての商業的に理にかなった努力を使わなければなりません

[[Category:OWASP Legal Project]]

__NOTOC__

OWASP Secure Software Contract Annex/ja

2011-07-05T02:08:12Z

Tomo: /* しかし、このドキュメントですべてを作ることは難しい */

'''セキュア・ソフトウェア開発契約付属書'''

警告：この文書は、単にガイダンスと考えられなければなりません。
OWASPは、ソフトウェア契約を交渉するのを手助けするために、
あなたが資格のある弁護士に相談するよう強く勧めます。

==序文==

OWASPセキュア・ソフトウェア開発契約付属書は、ソフトウェアの開発者とその顧客が、開発または供給されるソフトウェアのセキュリティに関連した重要な契約条項と条件を交渉し、取り込むことを助けます。このプロジェクトの理由は、多くの契約はこれらの問題に触れておらず、しばしば関係者が実際に同意されたものに劇的に異なる見解を持つことです。私たちは、これらの条項を明確に述べることは、双方の関係者が進め方について情報に基づいた意思決定ができることを確実にするもっともよい方法であると思っています。

「市場がより良いセキュリティを要求するとき、商用ソフトのセキュリティは改善します。
最低限、あらゆるソフトウェア提案依頼書は、ベンダーに彼らがセキュリティ脆弱性に対して
生産物をテストする方法を詳述するよう依頼しなければなりません。このステップは、企業が
セキュリティを評価すると市販ソフトウェアのベンダーと外部調達された開発者を納得させ始めます。」
-- John Pescatore（Gartnerのリサーチ・ディレクター）として

私たちは、顧客と開発者が、期待について議論して、責任について交渉することに対するフレームワークとしてこの文書を使うよう勧めます。この付属書は、ソフトウェア開発契約に添付されることを目的とします。これらの条項は交渉の余地があります。そして、それらは顧客と開発者によって、協議されることができて、協議されなければならないことを意味します。

==プロジェクトについて==

この文書はOpen Web Application Security Project（OWASP）財団（セキュアなソフトウェアに関連した無料でオープンなツールとドキュメンテーションを作成することを専門とする非営利の慈善団体）によって作成されました。個人契約において容易に使用できるようにするために、この文書はCC Share Alike 3.0ライセンスにて提供されます。あなたが適すると思うように、修正してもよいですし、使用してもよいです。あなたは、http://www.owasp.com/index.php/OWASP_Legal_Project でこのプロジェクトについて更なる詳細を見つけることができます。私たちは、ソフトウェア（法律コミュニティだけでなく）の製作者と消費者のコメントを歓迎します。

OWASPは、この文書の研究と準備における彼らの役割に対して [http://www.aspectsecurity.com Aspect Security] から特別な貢献を感謝して認めます。

==異論==

以下のわずかなページは、ソフトウェア開発契約においてこの言い回しを使用することに対するいくらかのたびたび聞こえる異論をカバーします：

===しかし、すべての条項が私たちにとって適切であるというわけではありません…===

この文書は、あなたの合意の開始地点です。あなたは、すべての活動が好きではないかもしれません、または、より多くの提案をしたいかもしれません。あなたは異なる責任を割り当てたいかもしれません。この文書は、すべてのソフトウェア顧客と開発者の要望を厳密に取り込むことを意図しているわけではありません。ソフトウェアが最終的にセキュアになることを確実にするために重要である、主要な項目を議論するためのフレームワークを提供することを意図します。セキュリティを議論して合意を得た後で、あなたはこの合意を適合するように調整すべきです。

===しかし、これらの活動に対して誰が代金を払わなければならないのでしょうか===

この契約は、ソフトウェア開発者により多くの負担を与えることはほとんどありません。問題は、セキュリティ ― もちろんそこにある ― と関連したコストがあるかどうかということでありません。むしろ、適切な問題はどんな活動がそれらのコストを最小にするために双方によって実行されなければならないかということです、そして、いつ、それらは起こらなければなりませんか。

この付属書は、誰がここに記述される活動の料金を払わなければならないかという問題については、意図的に語られていません。これらの活動の多くがすでに起こらなければならなくて、多くの顧客によって期待される一方、それたはソフトウェア産業で定期的に実践されることはありません。誰が（そして、いくら）支払うかという問題が、交渉の一部でなければなりません。

セキュリティのコストを計算することは、非常に難しいです。セキュリティ活動を実行することに関連したコストがある一方、それらを無視することに関連したかなりのコストもあります。私たちは、ソフトウェアを開発する最も費用対効果がよい方法について確信しています。それは、セキュリティ瑕疵が導入されるという可能性を減らして、瑕疵を導入して、それを修正することの間で時間を最小にすることです。

コストを計算するときにする一つの重要な区別は、セキュリティ手法を構築することと、それらの手法が正しくて効果的であることを確実にする保証活動の間にあります。ライフサイクルの終わりに手法を加えようとすることは、深刻な設計問題を引き起こすことがありえて、めざましくコストを増やします。この合意は、手法についての早い段階の決定がこれらのコストを最小にするのを奨励します。同様に、配備直前に保証活動（例えばコードレビューと侵入テスト）をするまで待つことはコストをめざましく増やします。私たちは、保証を得る最も費用効果がよい方法がライフサイクルを通して努力の一定のレベルを保証に入れることであると思っています。

===しかし厳密さのレベルは間違っている….===

この合意は、開発されているソフトウェアが大企業または政府機関にとってかなり重要であると仮定します。私たちは、大部分のソフトウェア開発組織によって達成できる合意のために「厳格さのレベル」を選んで、最も一般的なリスクを確認して、取り扱います。

しかし、重要なアプリケーション（例えば医学であるか、財政的であるか、防衛に関連したソフトウェア）で使われそうであるソフトウェアについては、あなたは厳格さのレベルを上げたいかもしれません。あなたは、追加のレビュー、文書化とテストの活動を加えたくてもよいです。あなたは、脆弱性を探すこと、診断すること、修正することに対するプロセスを強化しくてもよいです。より機密を扱わないアプリケーションのために、あなたは活動を減らすか、取り除きたくてもよいです。

===しかし、私たちはそれほど多くのリスクをとることができない…===

この契約は、ソフトウェアにおけるセキュリティ脆弱性に対するリスクをとるのかという議論を容易にすることを目的とします。範囲の一端では、顧客はすべてのリスクをとることができました、そして、開発者はたくさんの脆弱性をもつコードを供給することができました。他の極端では、開発者はすべてのリスクをとることができて、完全なコードを供給することに対する責任を負うことができました。これらの両極端は、どちらとも実行不可能です。

現在、この契約において、開発者は要求においてカバーされたか、理にかなったテスト努力によってカバーされるべき問題に対するリスクをとります。しかし、「新しい」セキュリティ問題の改善は、顧客によって代金を払われるべきです。私たちは、これが開発者が彼らのリスクの境界となることができて役に立つバランスで、顧客が前もってセキュリティ要求を正しくするのを奨励すると思っています。しかし、この問題の多くの他の可能性がある解決が、あります。あなたには他の提案があるかどうか私たちに知らせます、そして、私たちは彼らをこの文書の将来の版に含めてもよいです。

ここでの議論がコードにおいてセキュリティ脆弱性を修正することに関連したリスクをカバーだけして、これらの脆弱性のあらゆるエクスプロイットに基づくあらゆるセキュリティ・インシデントから立ち直ることと関連したコストを含まないことに注意すべきです。私たちは、この領域におけるベスト・プラクティスに興味があります。

===私たちはどのように第三者のコードを保証するでしょうか===

ほとんどすべてのソフトウェアプロジェクトは、第三者のコード（例えばライブラリ、フレームワークと生産物）のかなりの量を使います。このコードは、ただセキュリティ観点から、カスタム・コードがあなたのプロジェクトのために特に発達したのと同じくらい重要です。
私たちはこのコードのセキュリティを確実にすることに対する責任が開発者によって負われて最もよいと思っています、しかし、彼らにはこのセキュリティを保証するために彼ら自身のいっぱいの能力がないかもしれません。しかし、セキュリティは「構築するか、買うか」議論の一部分でなければなりません、これはそれを促進する最もよい方法のようです。

開発者は、もちろん、終わりまで第三者のソフトウェアの提供者にこの責任をパスする選択権があります。開発者は彼ら自身第三者のコードを分析することもできるか、彼らのためにそれを分析するために、セキュリティの専門家を雇うこともできます。

===しかし、なぜ私はすべてのこのトラブルにいくべきなのでしょうか===

最後に、私たちはソフトウェアを契約しているプロセスの一部分をセキュリティをすることに代わるものがないと思っています。現在では、私たちは多くのソフトウェア開発契約のもとで供給されているコードのセキュリティに関する重大な誤解があると思っています。これは、わずかなソフトウェア経験または理解とともに個人によってなされる高価な訴訟と決定に至ることができるだけです。この問題の完全な議論に対して [[Secure software contracting hypothetical case study]] を読んでください。

多くの利点が、この契約を通してうまくいくことにあります。主要なものは、それが関係する関係者の間で期待を明らかにするということです。場合によっては、難しいセキュリティ問題がソフトウェアで表面化するとき、それは訴訟を妨げるのを助けます。また、これらは多くの法的で調整するコンプライアンスの理由によって必要とされる同じ活動です。

===しかし、このドキュメントですべてを作ることは難しい===

OWASPは、文書化を目的とした文書化を推奨しません。この契約は品質（量ではない）を促進することに集中します。私たちは、短いリスク評価、数ページの要求、短いセキュリティ設計文書、テストプラン、いくつかのテスト結果とともに、この契約に応じることが（若干のプロジェクトにおいて）ありえると思っています。

この文書の目標は、ライフサイクルの各段階で、単に適切な注意がセキュリティに払われたことを確実とすることです。追加の利点は、この文書が基本的に、このソフトウェアが安心してそれがそれがすると主張することをするのをまかせられなければならない理由に対する議論を配置する「証明パッケージ」をつくるために一緒に集められることができるということです。

==契約付属書==

===1. 序文===

この付属書は、顧客と開発者の間で_____________________ ("合意") するために作られます。顧客と開発者は、以下の条件のよりソフトウェアのセキュリティを最大にすることに同意します。

===2. 原理===

この付属書は、ソフトウェア開発関係のすべての関係者のセキュリティ関連の権利と義務をはっきりさせることを目的とします。最高水準で、関係者は以下に同意します

;(a) セキュリティ決定は、リスクに基づきます : セキュリティについての決定は、関係するリスクのしっかりした理解に基づく顧客と開発者によって共同でなされす。

;(b) セキュリティ活動はバランスが保たれます : セキュリティ努力は、全てのソフトウェア開発ライフサイクル全体でおおよそ均一に配布されます。

;(c) セキュリティ活動は統合されます : ここに協議されるすべての活動と文書は、開発者のソフトウェア開発ライフサイクルに統合されて、残りのプロジェクトと別にしておかれるというわけではありません。この付属書の何も、どんな特定のソフトウェア開発プロセスを意味しません。

;(d) 脆弱性は予想されます : すべてのソフトウェアにはバグがあります、そして、それらのいくらかはセキュリティ問題を生じさせます。顧客と開発者は、ライフサイクルにおいてできるだけ早く脆弱性を特定するよう努めます。

;(e) セキュリティ情報は、完全に明らかにされます : すべてのセキュリティ関連した情報は、すぐに、そして、完全に、顧客と開発者で共有されます。

;(f) 役に立つセキュリティ文書だけが必要とされます : セキュリティ文書は、セキュリティ設計、リスク分析または問題を明確に記述するために詳細にわたる必要はありません。

===3.ライフサイクル活動===

;(a) リスク識別 : 開発者とClientは、アプリケーションに直面しているリスクを理解して、文書化するために一緒に働くことに同意します。この努力は、アプリケーションにより提供される重要な資産と機能に主要なリスクを確認しなければなりません。要件部にリストされるトピックの各々は、考慮されなければなりません。

;(b) 要求 : リスクに基づいて、開発者と顧客は、開発されるソフトウェアの仕様の一部として詳細なセキュリティ要件を確立するために一緒に働くことに同意します。この付属書の要件部分で記載されるトピックの各々は、開発者と顧客によって協議されなければならなくて、評価されなければなりません。これらの要件は、カスタム・ソフト、第三者のソフトウェアまたはプラットホームによって満たされてもよいです。

;(c) 設計 : 開発者は、セキュリティ要件の各々を達成するために明確に設計を説明する文書を提供することに同意します。ほとんどの場合、この文書はセキュリティ手法を記載します、そこで、手法はアーキテクチャに適合しました、そして、関連したすべては彼らの適正使用を確実にするためにパターンを設計します。設計は、サポートがカスタム・ソフトか、第三者のソフトウェアかプラットホームから来るかどうか、明確に指定しなければなりません。

;(d) 実装 : 開発者は、一組のセキュアなコーディング指針に提供することに、従って、一組の共通セキュリティ制御プログラミング・インターフェース（例えば [http://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API OWASP Enterprise Security API（ESAPI）] ）を使って同意します。ガイドラインは、コードがどのようにフォーマットされなければならなくて、構築されなければならなくて、コメントされなければならないかについて示します。共通セキュリティ制御プログラミング・インターフェースは、セキュリティ制御がどのように呼ばれなければならないか、そして、セキュリティ制御がどのように機能するか定めます。すべてのセキュリティに関連したコードは、完全にコメントされます。共通のセキュリティ脆弱性を回避するときの具体的なガイダンスは、含まれなければなりません。また、すべてのコードはセキュリティ要件に対して少なくとも他の一人の開発者によってレビューされなければなりません、そして、それの前のコーディング・ガイドラインは単体テストの準備ができていると思われます。

;(e) セキュリティ分析とテスト : 開発者は、（ [http://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project OWASP Application Security Verification Standard (ASVS)] のような）合意された標準の検証要件により、アプリケーション・セキュリティ分析とテスト（「検証」とも言われる）を実行します。開発者は、標準の報告要件によって検証結論を文書化しなければなりません。開発者は、検証結論を顧客に提供しなければなりません。

;(f) セキュリティ配備 : 開発者は、ソフトウェアの全体的なセキュリティのために完全にすべてのセキュリティ関連した構成オプションとそれらの関連性を記述するセキュアな構成ガイドラインを提供することに同意します。ガイドラインは、オペレーティングシステム、ウェブサーバとアプリケーション・サーバーを含むサポート的なプラットホームにおける依存関係の完全な記述を含まなければいけません。また、どのようにそれらをセキュリティのために構成されるべきかを含まなければいけません。ソフトウェアのデフォルトコンフィグレーションは、セキュアでなければなりません。

===4.セキュリティ要求エリア===

以下のトピック領域は、リスク理解と要求定義活動の間、考慮されなければなりません。この努力は一組の具体的で、注文仕立てで、分析できる要求を生産しなければなりません。そして、開発者と顧客はこのプロセスに関与していなければならなくて、要求の最終セットについて同意しなければなりません。

;(a) 入力検証とエンコーディング : 要求は、ユーザー、ファイルシステム、データベース、ディレクトリまたは外部システムからであるかどうかにかかわらず、アプリケーションへの各々の入力を標準化し、検証し、コード化するためにルールを指定しなければなりません。　　　デフォルトルールは、それが何が許可されるかという詳細な仕様にマッチしない限り、すべての入力が無効であるということでなければなりません。そのうえ、無効な入力が受け取られるとき、要求はとられる措置を指定しなければなりません。具体的には、アプリケーションはインジェクション、オーバフロー、不正操作することまたは他の不正な入力攻撃に影響されやすくてはいけません。

;(b) 認証とセッション管理 : 要求は、認証証明書とセッション識別子がどのようにそれらのライフサイクルを通して保護されているかについて明記しなければなりません。すべての関連する機能（パスワード忘却、パスワード変更、パスワードリマインダ、ログアウト、そして複数ログインを含む）に対する要求は含められなければいけません。

;(c) アクセス制御 : 要求は、アプリケーションで使われるすべての役割（グループ、特権、認可）の詳細な記述を含まなければなりません。要求は、アプリケーションにより提供されるすべての資産と機能も示さなければなりません。要求は、完全に各々の資産に正確なアクセス権を指定しなければならなくて、各々の役割に対して機能しなければなりません。アクセス制御マトリックスは、これらのルールのための提案されたフォーマットです。

;(d) エラー処理 : 要求は、処理の間、発生しているエラーが取り扱われる方法を詳述しなければなりません。若干のアプリケーションはエラーの場合には最もよい努力結果を提供しなければなりません、一方、他はすぐに処理を終了しなければなりません。

;(e) ロギング : 要求は、どんなイベントがセキュリティに関連して、記録される必要があるか、たとえば、検知された攻撃、失敗したログイン試行、認可を上回ろうとする試行、を指定しなければなりません。要求は、時間と日付、イベント記述、アプリケーション詳細とフォレンジクス努力に役立つ他の情報を含む、各々のイベントでどんな情報を記録するべきかについても指定しなければなりません。

;(f) 外部システムへの接続 : 要求は、認証と暗号化がどのようにすべての外部システム（例えばデータベース、ディレクトリとウェブ・サービス）のために取り扱われるかについて指定しなければなりません。外部システムでコミュニケーションのために必要とされるすべてのクレディンシャルは、暗号化された形で構成ファイルでコードの外側に保存されなければなりません。

;(g) 暗号 : 要求は、どんなデータが暗号化されなければならないか、暗号化されることがどれほどか、そして、すべての証明書と他のクレディンシャルがどのように取り扱われなければならないか指定しなければなりません。アプリケーションは、広く使われていてテストされた暗号化ライブラリで実装される標準的なアルゴリズムを使用しなければなりません。

;(h) 可用性 : 要求は、それがどのようにサービス不能攻撃から保護するかについて指定しなければなりません。アプリケーションへのすべてのありそうな攻撃は考慮されなければなりません。そして、認証ロックアウト、接続消耗と他の資源消耗攻撃を含みます。

;(i) セキュアな設定 : 要求は、すべてのセキュリティに関連した構成オプションに対するデフォルト値がセキュアでなければならないことを示していなければなりません。監査目的のために、ソフトウェアはすべてのセキュリティに関連した構成詳細を示している簡単に読めるレポートをつくることができなければなりません。

;(j) 特定の脆弱性 : 要求は、ソフトウェアで見つかってはならない一組の具体的な脆弱性を含まなければなりません。指定されていないならば、ソフトウェアは現在の「OWASP Top Ten Most Critical Web Application Vulnerabilities」で記述される瑕疵の何も含んではいけません。

===5. 要員および組織===

;(a) セキュリティ・アーキテクト : 開発者は一つの上位の技術的な資源に責任をセキュリティに指定します。そして、プロジェクトのセキュリティ・アーキテクトとして知られています。セキュリティ・アーキテクトは、各々の納品可能なもののセキュリティを保証します。

;(b) セキュリティ・トレーニング : 開発者は、開発者チームのすべてのメンバーがセキュアなプログラミング技法の訓練をされたことを確かめる役割を果たします。

;(c) 信用できる開発者 : 開発者は、すべての開発チーム・メンバーの適切な経歴調査を実行することに同意します。

===6.開発環境===

;(a) セキュア・コーディング : 開発者は、どんなツールがセキュアなコーディングを促すためにソフトウェア開発環境で使われるかについて明らかにしなければなりません。

;(b) 構成管理 : 開発者は、ソフトウェア・ベースラインに対するすべての変更とすべての関連した設定とビルド・ファイルを関連づけ　とすべての関連した構成にすべての変化と関連したチーム・メンバーを認証して、記録して、ファイルを構築したソース・コード管理システムを使用しなければなりません。

;(c) 配布 : 開発者は、ソースから確実に完全な配布を構築するビルド・プロセスを使用しなければなりません。このプロセスは、顧客に供給されるソフトウェアの完全性を確かめる方法を含まなければなりません。

===7. ライブラリ、フレームワーク、および生産物===

;(a) 開示 : 開発者は、商用、フリー、オープンソース、クローズソースであるにせよ、すべてのライブラリ、フレームワーク、構成要素と他の生産物を含む、ソフトウェアで使われるすべての第三者のソフトウェアを明らかにしなければなりません。

;(b) 評価 : 開発者は、第三者のソフトウェアがこの契約のすべての条件を満たして、この契約の基で開発されたカスタム開発されたコードと同じくらいセキュアなことを確実とするために、理にかなった努力をしなければなりません。

===8. セキュリティ・レビュー===

;(a) レビューする権利 : 依頼人には、ソフトウェアを納品の60日間以内にいつでも彼らの費用でセキュリティ瑕疵のためにレビューしておく権利があります。開発者は、ソース・コードとテスト環境へのアクセスを提供することによって理にかなったサポートをレビュー・チームに提供することに同意します。

;(b) レビュー・カバレッジ : セキュリティ・レビューは供給されるソフトウェアのすべての面をカバーしなければなりません。そして、カスタム・コード、構成要素、生産物とシステム設定を含みます。

;(c) レビューの範囲 : 最低限で、レビューはセキュリティ要求の全てをカバーしなければならなくて、他の一般的な脆弱性を捜さなければなりません。レビューは、脆弱性スキャン、侵入テスト、ソースコードの静的分析と専門家のコードレビューの組み合わせを含んでもよいです。

;(d) 見つけられた問題 : 発見されたセキュリティ問題は、顧客と開発者に報告されます。すべての問題は、この付属書のセキュリティ問題マネジメント部分により追跡されて、矯正されます。

===9. セキュリティ問題マネジメント ===

;(a) 識別 : 要求、設計、実装、テスト、配備、または、運用中の問題にせよ、開発者は全てのライフサイクルの間に発見されるすべてのセキュリティ問題を追います。各々のセキュリティ問題に関連したリスクは、発見後できるだけ早く、評価されて、文書化されて、発見の後、顧客に報告されます。

;(b) 保護 : 開発者はセキュリティ問題と付随する文書に関して情報を適切に保護します。そして、運用中の顧客ソフトウェアの脆弱性が露出するという可能性を制限するのを助けます。

;(c) 改善 : 納品の前に確認されるセキュリティ問題は、開発者によって修正されなければなりません。納品の後に発見されるセキュリティ問題は、本契約の規定による他のバグと問題として同様に取り扱われなければなりません。

===10. 保証===

;(a) 保証 : 開発者は、開発プロセスを通して作成されるセキュリティ文書からなる「証明パッケージ」を提供します。パッケージは、セキュリティ要求、設計、実装と試験結果がきちんと完了された、そして、すべてのセキュリティ問題が適切に解決されたと確認しなければなりません。

;(b) 自己証明 : セキュリティ・アーキテクトは、ソフトウェアがセキュリティ要求を満たすこと、すべてのセキュリティ活動が実行されていること、そして、すべての識別されたセキュリティ問題が文書化されて、解決されたことを証明します。証明ステータスに対するあらゆる例外は、納品で完全に文書化されなければなりません。

;(c) 悪意のあるコードのなし : 開発者は、ソフトウェアがソフトウェア要求をサポートせず、コンピュータ・ウイルス、ワーム、時限爆弾、バック・ドア、トロイの木馬、イースターエッグと他のあらゆる形の悪意のあるソフトウェアを含む、アプリケーションのセキュリティを弱めるあらゆるコードを含んではならないと保証します。

===11. セキュリティ承認と保守 ===

;(a) 受け入れ : 証明パッケージが完全であり、すべてのセキュリティ問題が解決されるまで、ソフトウェアは受け入れられると考慮されてはいけません。

;(b) セキュリティ問題の調査 : 受理の後、セキュリティ問題が発見されるか、かなり疑われるならば、開発者は顧客が問題の性質を決定するために調査を実行するのを援助しなければなりません。それがセキュリティ要求によってカバーされないで、セキュリティ・テストの理にかなった範囲の外にあるならば、問題は「新しい」と思われなければなりません。

;(c) 新しいセキュリティ問題 : 開発者と顧客は、新しいセキュリティ問題を解決するために必要な努力を探し出すことに同意します。また、それらに取り組むために必要とされる仕事を実行するための合意を達成するために誠意を持って交渉することに同意します。

;(d) 他のセキュリティ問題 : 開発者は堅実なソフトウェア開発慣行。そして、リスクのひどさを考慮すること、そして、できるだけ速く新しいと思われないすべてのセキュリティ問題を解決することと一致したすべての商業的に理にかなった努力を使わなければなりません

[[Category:OWASP Legal Project]]

__NOTOC__

OWASP Secure Software Contract Annex/ja

2011-07-05T00:39:40Z

Tomo: /* しかし私たちはそれほど多くのリスクをとることができない… */

'''セキュア・ソフトウェア開発契約付属書'''

警告：この文書は、単にガイダンスと考えられなければなりません。
OWASPは、ソフトウェア契約を交渉するのを手助けするために、
あなたが資格のある弁護士に相談するよう強く勧めます。

==序文==

OWASPセキュア・ソフトウェア開発契約付属書は、ソフトウェアの開発者とその顧客が、開発または供給されるソフトウェアのセキュリティに関連した重要な契約条項と条件を交渉し、取り込むことを助けます。このプロジェクトの理由は、多くの契約はこれらの問題に触れておらず、しばしば関係者が実際に同意されたものに劇的に異なる見解を持つことです。私たちは、これらの条項を明確に述べることは、双方の関係者が進め方について情報に基づいた意思決定ができることを確実にするもっともよい方法であると思っています。

「市場がより良いセキュリティを要求するとき、商用ソフトのセキュリティは改善します。
最低限、あらゆるソフトウェア提案依頼書は、ベンダーに彼らがセキュリティ脆弱性に対して
生産物をテストする方法を詳述するよう依頼しなければなりません。このステップは、企業が
セキュリティを評価すると市販ソフトウェアのベンダーと外部調達された開発者を納得させ始めます。」
-- John Pescatore（Gartnerのリサーチ・ディレクター）として

私たちは、顧客と開発者が、期待について議論して、責任について交渉することに対するフレームワークとしてこの文書を使うよう勧めます。この付属書は、ソフトウェア開発契約に添付されることを目的とします。これらの条項は交渉の余地があります。そして、それらは顧客と開発者によって、協議されることができて、協議されなければならないことを意味します。

==プロジェクトについて==

この文書はOpen Web Application Security Project（OWASP）財団（セキュアなソフトウェアに関連した無料でオープンなツールとドキュメンテーションを作成することを専門とする非営利の慈善団体）によって作成されました。個人契約において容易に使用できるようにするために、この文書はCC Share Alike 3.0ライセンスにて提供されます。あなたが適すると思うように、修正してもよいですし、使用してもよいです。あなたは、http://www.owasp.com/index.php/OWASP_Legal_Project でこのプロジェクトについて更なる詳細を見つけることができます。私たちは、ソフトウェア（法律コミュニティだけでなく）の製作者と消費者のコメントを歓迎します。

OWASPは、この文書の研究と準備における彼らの役割に対して [http://www.aspectsecurity.com Aspect Security] から特別な貢献を感謝して認めます。

==異論==

以下のわずかなページは、ソフトウェア開発契約においてこの言い回しを使用することに対するいくらかのたびたび聞こえる異論をカバーします：

===しかし、すべての条項が私たちにとって適切であるというわけではありません…===

この文書は、あなたの合意の開始地点です。あなたは、すべての活動が好きではないかもしれません、または、より多くの提案をしたいかもしれません。あなたは異なる責任を割り当てたいかもしれません。この文書は、すべてのソフトウェア顧客と開発者の要望を厳密に取り込むことを意図しているわけではありません。ソフトウェアが最終的にセキュアになることを確実にするために重要である、主要な項目を議論するためのフレームワークを提供することを意図します。セキュリティを議論して合意を得た後で、あなたはこの合意を適合するように調整すべきです。

===しかし、これらの活動に対して誰が代金を払わなければならないのでしょうか===

この契約は、ソフトウェア開発者により多くの負担を与えることはほとんどありません。問題は、セキュリティ ― もちろんそこにある ― と関連したコストがあるかどうかということでありません。むしろ、適切な問題はどんな活動がそれらのコストを最小にするために双方によって実行されなければならないかということです、そして、いつ、それらは起こらなければなりませんか。

この付属書は、誰がここに記述される活動の料金を払わなければならないかという問題については、意図的に語られていません。これらの活動の多くがすでに起こらなければならなくて、多くの顧客によって期待される一方、それたはソフトウェア産業で定期的に実践されることはありません。誰が（そして、いくら）支払うかという問題が、交渉の一部でなければなりません。

セキュリティのコストを計算することは、非常に難しいです。セキュリティ活動を実行することに関連したコストがある一方、それらを無視することに関連したかなりのコストもあります。私たちは、ソフトウェアを開発する最も費用対効果がよい方法について確信しています。それは、セキュリティ瑕疵が導入されるという可能性を減らして、瑕疵を導入して、それを修正することの間で時間を最小にすることです。

コストを計算するときにする一つの重要な区別は、セキュリティ手法を構築することと、それらの手法が正しくて効果的であることを確実にする保証活動の間にあります。ライフサイクルの終わりに手法を加えようとすることは、深刻な設計問題を引き起こすことがありえて、めざましくコストを増やします。この合意は、手法についての早い段階の決定がこれらのコストを最小にするのを奨励します。同様に、配備直前に保証活動（例えばコードレビューと侵入テスト）をするまで待つことはコストをめざましく増やします。私たちは、保証を得る最も費用効果がよい方法がライフサイクルを通して努力の一定のレベルを保証に入れることであると思っています。

===しかし厳密さのレベルは間違っている….===

この合意は、開発されているソフトウェアが大企業または政府機関にとってかなり重要であると仮定します。私たちは、大部分のソフトウェア開発組織によって達成できる合意のために「厳格さのレベル」を選んで、最も一般的なリスクを確認して、取り扱います。

しかし、重要なアプリケーション（例えば医学であるか、財政的であるか、防衛に関連したソフトウェア）で使われそうであるソフトウェアについては、あなたは厳格さのレベルを上げたいかもしれません。あなたは、追加のレビュー、文書化とテストの活動を加えたくてもよいです。あなたは、脆弱性を探すこと、診断すること、修正することに対するプロセスを強化しくてもよいです。より機密を扱わないアプリケーションのために、あなたは活動を減らすか、取り除きたくてもよいです。

===しかし、私たちはそれほど多くのリスクをとることができない…===

この契約は、ソフトウェアにおけるセキュリティ脆弱性に対するリスクをとるのかという議論を容易にすることを目的とします。範囲の一端では、顧客はすべてのリスクをとることができました、そして、開発者はたくさんの脆弱性をもつコードを供給することができました。他の極端では、開発者はすべてのリスクをとることができて、完全なコードを供給することに対する責任を負うことができました。これらの両極端は、どちらとも実行不可能です。

現在、この契約において、開発者は要求においてカバーされたか、理にかなったテスト努力によってカバーされるべき問題に対するリスクをとります。しかし、「新しい」セキュリティ問題の改善は、顧客によって代金を払われるべきです。私たちは、これが開発者が彼らのリスクの境界となることができて役に立つバランスで、顧客が前もってセキュリティ要求を正しくするのを奨励すると思っています。しかし、この問題の多くの他の可能性がある解決が、あります。あなたには他の提案があるかどうか私たちに知らせます、そして、私たちは彼らをこの文書の将来の版に含めてもよいです。

ここでの議論がコードにおいてセキュリティ脆弱性を修正することに関連したリスクをカバーだけして、これらの脆弱性のあらゆるエクスプロイットに基づくあらゆるセキュリティ・インシデントから立ち直ることと関連したコストを含まないことに注意すべきです。私たちは、この領域におけるベスト・プラクティスに興味があります。

===私たちはどのように第三者のコードを保証するでしょうか===

ほとんどすべてのソフトウェアプロジェクトは、第三者のコード（例えばライブラリ、フレームワークと生産物）のかなりの量を使います。このコードは、ただセキュリティ観点から、カスタム・コードがあなたのプロジェクトのために特に発達したのと同じくらい重要です。
私たちはこのコードのセキュリティを確実にすることに対する責任が開発者によって負われて最もよいと思っています、しかし、彼らにはこのセキュリティを保証するために彼ら自身のいっぱいの能力がないかもしれません。しかし、セキュリティは「構築するか、買うか」議論の一部分でなければなりません、これはそれを促進する最もよい方法のようです。

開発者は、もちろん、終わりまで第三者のソフトウェアの提供者にこの責任をパスする選択権があります。開発者は彼ら自身第三者のコードを分析することもできるか、彼らのためにそれを分析するために、セキュリティの専門家を雇うこともできます。

===しかし、なぜ私はすべてのこのトラブルにいくべきなのでしょうか===

最後に、私たちはソフトウェアを契約しているプロセスの一部分をセキュリティをすることに代わるものがないと思っています。現在では、私たちは多くのソフトウェア開発契約のもとで供給されているコードのセキュリティに関する重大な誤解があると思っています。これは、わずかなソフトウェア経験または理解とともに個人によってなされる高価な訴訟と決定に至ることができるだけです。この問題の完全な議論に対して [[Secure software contracting hypothetical case study]] を読んでください。

多くの利点が、この契約を通してうまくいくことにあります。主要なものは、それが関係する関係者の間で期待を明らかにするということです。場合によっては、難しいセキュリティ問題がソフトウェアで表面化するとき、それは訴訟を妨げるのを助けます。また、これらは多くの法的で調整するコンプライアンスの理由によって必要とされる同じ活動です。

===しかし、このドキュメントですべてを作ることは難しい===

OWASPは、文書の目的のために文書を励ましません。この契約は、品質（量でない）を促すことに集中します。私たちは、短時間のリスク評価、数ページの要求、短いセキュリティ設計文書、テストプラン、いくつかのテスト結果とともに、この契約に応じることが（若干のプロジェクトにおいて）ありえると思っています。

この文書の目標は、ライフサイクルの各段階で、単に適切な注意がセキュリティに払われたことを確実とすることです。追加の利点は、この文書が基本的に、このソフトウェアが安心してそれがそれがすると主張することをするのをまかせられなければならない理由に対する議論を配置する「証明パッケージ」をつくるために一緒に集められることができるということです。

==契約付属書==

===1. 序文===

この付属書は、顧客と開発者の間で_____________________ ("合意") するために作られます。顧客と開発者は、以下の条件のよりソフトウェアのセキュリティを最大にすることに同意します。

===2. 原理===

この付属書は、ソフトウェア開発関係のすべての関係者のセキュリティ関連の権利と義務をはっきりさせることを目的とします。最高水準で、関係者は以下に同意します

;(a) セキュリティ決定は、リスクに基づきます : セキュリティについての決定は、関係するリスクのしっかりした理解に基づく顧客と開発者によって共同でなされす。

;(b) セキュリティ活動はバランスが保たれます : セキュリティ努力は、全てのソフトウェア開発ライフサイクル全体でおおよそ均一に配布されます。

;(c) セキュリティ活動は統合されます : ここに協議されるすべての活動と文書は、開発者のソフトウェア開発ライフサイクルに統合されて、残りのプロジェクトと別にしておかれるというわけではありません。この付属書の何も、どんな特定のソフトウェア開発プロセスを意味しません。

;(d) 脆弱性は予想されます : すべてのソフトウェアにはバグがあります、そして、それらのいくらかはセキュリティ問題を生じさせます。顧客と開発者は、ライフサイクルにおいてできるだけ早く脆弱性を特定するよう努めます。

;(e) セキュリティ情報は、完全に明らかにされます : すべてのセキュリティ関連した情報は、すぐに、そして、完全に、顧客と開発者で共有されます。

;(f) 役に立つセキュリティ文書だけが必要とされます : セキュリティ文書は、セキュリティ設計、リスク分析または問題を明確に記述するために詳細にわたる必要はありません。

===3.ライフサイクル活動===

;(a) リスク識別 : 開発者とClientは、アプリケーションに直面しているリスクを理解して、文書化するために一緒に働くことに同意します。この努力は、アプリケーションにより提供される重要な資産と機能に主要なリスクを確認しなければなりません。要件部にリストされるトピックの各々は、考慮されなければなりません。

;(b) 要求 : リスクに基づいて、開発者と顧客は、開発されるソフトウェアの仕様の一部として詳細なセキュリティ要件を確立するために一緒に働くことに同意します。この付属書の要件部分で記載されるトピックの各々は、開発者と顧客によって協議されなければならなくて、評価されなければなりません。これらの要件は、カスタム・ソフト、第三者のソフトウェアまたはプラットホームによって満たされてもよいです。

;(c) 設計 : 開発者は、セキュリティ要件の各々を達成するために明確に設計を説明する文書を提供することに同意します。ほとんどの場合、この文書はセキュリティ手法を記載します、そこで、手法はアーキテクチャに適合しました、そして、関連したすべては彼らの適正使用を確実にするためにパターンを設計します。設計は、サポートがカスタム・ソフトか、第三者のソフトウェアかプラットホームから来るかどうか、明確に指定しなければなりません。

;(d) 実装 : 開発者は、一組のセキュアなコーディング指針に提供することに、従って、一組の共通セキュリティ制御プログラミング・インターフェース（例えば [http://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API OWASP Enterprise Security API（ESAPI）] ）を使って同意します。ガイドラインは、コードがどのようにフォーマットされなければならなくて、構築されなければならなくて、コメントされなければならないかについて示します。共通セキュリティ制御プログラミング・インターフェースは、セキュリティ制御がどのように呼ばれなければならないか、そして、セキュリティ制御がどのように機能するか定めます。すべてのセキュリティに関連したコードは、完全にコメントされます。共通のセキュリティ脆弱性を回避するときの具体的なガイダンスは、含まれなければなりません。また、すべてのコードはセキュリティ要件に対して少なくとも他の一人の開発者によってレビューされなければなりません、そして、それの前のコーディング・ガイドラインは単体テストの準備ができていると思われます。

;(e) セキュリティ分析とテスト : 開発者は、（ [http://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project OWASP Application Security Verification Standard (ASVS)] のような）合意された標準の検証要件により、アプリケーション・セキュリティ分析とテスト（「検証」とも言われる）を実行します。開発者は、標準の報告要件によって検証結論を文書化しなければなりません。開発者は、検証結論を顧客に提供しなければなりません。

;(f) セキュリティ配備 : 開発者は、ソフトウェアの全体的なセキュリティのために完全にすべてのセキュリティ関連した構成オプションとそれらの関連性を記述するセキュアな構成ガイドラインを提供することに同意します。ガイドラインは、オペレーティングシステム、ウェブサーバとアプリケーション・サーバーを含むサポート的なプラットホームにおける依存関係の完全な記述を含まなければいけません。また、どのようにそれらをセキュリティのために構成されるべきかを含まなければいけません。ソフトウェアのデフォルトコンフィグレーションは、セキュアでなければなりません。

===4.セキュリティ要求エリア===

以下のトピック領域は、リスク理解と要求定義活動の間、考慮されなければなりません。この努力は一組の具体的で、注文仕立てで、分析できる要求を生産しなければなりません。そして、開発者と顧客はこのプロセスに関与していなければならなくて、要求の最終セットについて同意しなければなりません。

;(a) 入力検証とエンコーディング : 要求は、ユーザー、ファイルシステム、データベース、ディレクトリまたは外部システムからであるかどうかにかかわらず、アプリケーションへの各々の入力を標準化し、検証し、コード化するためにルールを指定しなければなりません。　　　デフォルトルールは、それが何が許可されるかという詳細な仕様にマッチしない限り、すべての入力が無効であるということでなければなりません。そのうえ、無効な入力が受け取られるとき、要求はとられる措置を指定しなければなりません。具体的には、アプリケーションはインジェクション、オーバフロー、不正操作することまたは他の不正な入力攻撃に影響されやすくてはいけません。

;(b) 認証とセッション管理 : 要求は、認証証明書とセッション識別子がどのようにそれらのライフサイクルを通して保護されているかについて明記しなければなりません。すべての関連する機能（パスワード忘却、パスワード変更、パスワードリマインダ、ログアウト、そして複数ログインを含む）に対する要求は含められなければいけません。

;(c) アクセス制御 : 要求は、アプリケーションで使われるすべての役割（グループ、特権、認可）の詳細な記述を含まなければなりません。要求は、アプリケーションにより提供されるすべての資産と機能も示さなければなりません。要求は、完全に各々の資産に正確なアクセス権を指定しなければならなくて、各々の役割に対して機能しなければなりません。アクセス制御マトリックスは、これらのルールのための提案されたフォーマットです。

;(d) エラー処理 : 要求は、処理の間、発生しているエラーが取り扱われる方法を詳述しなければなりません。若干のアプリケーションはエラーの場合には最もよい努力結果を提供しなければなりません、一方、他はすぐに処理を終了しなければなりません。

;(e) ロギング : 要求は、どんなイベントがセキュリティに関連して、記録される必要があるか、たとえば、検知された攻撃、失敗したログイン試行、認可を上回ろうとする試行、を指定しなければなりません。要求は、時間と日付、イベント記述、アプリケーション詳細とフォレンジクス努力に役立つ他の情報を含む、各々のイベントでどんな情報を記録するべきかについても指定しなければなりません。

;(f) 外部システムへの接続 : 要求は、認証と暗号化がどのようにすべての外部システム（例えばデータベース、ディレクトリとウェブ・サービス）のために取り扱われるかについて指定しなければなりません。外部システムでコミュニケーションのために必要とされるすべてのクレディンシャルは、暗号化された形で構成ファイルでコードの外側に保存されなければなりません。

;(g) 暗号 : 要求は、どんなデータが暗号化されなければならないか、暗号化されることがどれほどか、そして、すべての証明書と他のクレディンシャルがどのように取り扱われなければならないか指定しなければなりません。アプリケーションは、広く使われていてテストされた暗号化ライブラリで実装される標準的なアルゴリズムを使用しなければなりません。

;(h) 可用性 : 要求は、それがどのようにサービス不能攻撃から保護するかについて指定しなければなりません。アプリケーションへのすべてのありそうな攻撃は考慮されなければなりません。そして、認証ロックアウト、接続消耗と他の資源消耗攻撃を含みます。

;(i) セキュアな設定 : 要求は、すべてのセキュリティに関連した構成オプションに対するデフォルト値がセキュアでなければならないことを示していなければなりません。監査目的のために、ソフトウェアはすべてのセキュリティに関連した構成詳細を示している簡単に読めるレポートをつくることができなければなりません。

;(j) 特定の脆弱性 : 要求は、ソフトウェアで見つかってはならない一組の具体的な脆弱性を含まなければなりません。指定されていないならば、ソフトウェアは現在の「OWASP Top Ten Most Critical Web Application Vulnerabilities」で記述される瑕疵の何も含んではいけません。

===5. 要員および組織===

;(a) セキュリティ・アーキテクト : 開発者は一つの上位の技術的な資源に責任をセキュリティに指定します。そして、プロジェクトのセキュリティ・アーキテクトとして知られています。セキュリティ・アーキテクトは、各々の納品可能なもののセキュリティを保証します。

;(b) セキュリティ・トレーニング : 開発者は、開発者チームのすべてのメンバーがセキュアなプログラミング技法の訓練をされたことを確かめる役割を果たします。

;(c) 信用できる開発者 : 開発者は、すべての開発チーム・メンバーの適切な経歴調査を実行することに同意します。

===6.開発環境===

;(a) セキュア・コーディング : 開発者は、どんなツールがセキュアなコーディングを促すためにソフトウェア開発環境で使われるかについて明らかにしなければなりません。

;(b) 構成管理 : 開発者は、ソフトウェア・ベースラインに対するすべての変更とすべての関連した設定とビルド・ファイルを関連づけ　とすべての関連した構成にすべての変化と関連したチーム・メンバーを認証して、記録して、ファイルを構築したソース・コード管理システムを使用しなければなりません。

;(c) 配布 : 開発者は、ソースから確実に完全な配布を構築するビルド・プロセスを使用しなければなりません。このプロセスは、顧客に供給されるソフトウェアの完全性を確かめる方法を含まなければなりません。

===7. ライブラリ、フレームワーク、および生産物===

;(a) 開示 : 開発者は、商用、フリー、オープンソース、クローズソースであるにせよ、すべてのライブラリ、フレームワーク、構成要素と他の生産物を含む、ソフトウェアで使われるすべての第三者のソフトウェアを明らかにしなければなりません。

;(b) 評価 : 開発者は、第三者のソフトウェアがこの契約のすべての条件を満たして、この契約の基で開発されたカスタム開発されたコードと同じくらいセキュアなことを確実とするために、理にかなった努力をしなければなりません。

===8. セキュリティ・レビュー===

;(a) レビューする権利 : 依頼人には、ソフトウェアを納品の60日間以内にいつでも彼らの費用でセキュリティ瑕疵のためにレビューしておく権利があります。開発者は、ソース・コードとテスト環境へのアクセスを提供することによって理にかなったサポートをレビュー・チームに提供することに同意します。

;(b) レビュー・カバレッジ : セキュリティ・レビューは供給されるソフトウェアのすべての面をカバーしなければなりません。そして、カスタム・コード、構成要素、生産物とシステム設定を含みます。

;(c) レビューの範囲 : 最低限で、レビューはセキュリティ要求の全てをカバーしなければならなくて、他の一般的な脆弱性を捜さなければなりません。レビューは、脆弱性スキャン、侵入テスト、ソースコードの静的分析と専門家のコードレビューの組み合わせを含んでもよいです。

;(d) 見つけられた問題 : 発見されたセキュリティ問題は、顧客と開発者に報告されます。すべての問題は、この付属書のセキュリティ問題マネジメント部分により追跡されて、矯正されます。

===9. セキュリティ問題マネジメント ===

;(a) 識別 : 要求、設計、実装、テスト、配備、または、運用中の問題にせよ、開発者は全てのライフサイクルの間に発見されるすべてのセキュリティ問題を追います。各々のセキュリティ問題に関連したリスクは、発見後できるだけ早く、評価されて、文書化されて、発見の後、顧客に報告されます。

;(b) 保護 : 開発者はセキュリティ問題と付随する文書に関して情報を適切に保護します。そして、運用中の顧客ソフトウェアの脆弱性が露出するという可能性を制限するのを助けます。

;(c) 改善 : 納品の前に確認されるセキュリティ問題は、開発者によって修正されなければなりません。納品の後に発見されるセキュリティ問題は、本契約の規定による他のバグと問題として同様に取り扱われなければなりません。

===10. 保証===

;(a) 保証 : 開発者は、開発プロセスを通して作成されるセキュリティ文書からなる「証明パッケージ」を提供します。パッケージは、セキュリティ要求、設計、実装と試験結果がきちんと完了された、そして、すべてのセキュリティ問題が適切に解決されたと確認しなければなりません。

;(b) 自己証明 : セキュリティ・アーキテクトは、ソフトウェアがセキュリティ要求を満たすこと、すべてのセキュリティ活動が実行されていること、そして、すべての識別されたセキュリティ問題が文書化されて、解決されたことを証明します。証明ステータスに対するあらゆる例外は、納品で完全に文書化されなければなりません。

;(c) 悪意のあるコードのなし : 開発者は、ソフトウェアがソフトウェア要求をサポートせず、コンピュータ・ウイルス、ワーム、時限爆弾、バック・ドア、トロイの木馬、イースターエッグと他のあらゆる形の悪意のあるソフトウェアを含む、アプリケーションのセキュリティを弱めるあらゆるコードを含んではならないと保証します。

===11. セキュリティ承認と保守 ===

;(a) 受け入れ : 証明パッケージが完全であり、すべてのセキュリティ問題が解決されるまで、ソフトウェアは受け入れられると考慮されてはいけません。

;(b) セキュリティ問題の調査 : 受理の後、セキュリティ問題が発見されるか、かなり疑われるならば、開発者は顧客が問題の性質を決定するために調査を実行するのを援助しなければなりません。それがセキュリティ要求によってカバーされないで、セキュリティ・テストの理にかなった範囲の外にあるならば、問題は「新しい」と思われなければなりません。

;(c) 新しいセキュリティ問題 : 開発者と顧客は、新しいセキュリティ問題を解決するために必要な努力を探し出すことに同意します。また、それらに取り組むために必要とされる仕事を実行するための合意を達成するために誠意を持って交渉することに同意します。

;(d) 他のセキュリティ問題 : 開発者は堅実なソフトウェア開発慣行。そして、リスクのひどさを考慮すること、そして、できるだけ速く新しいと思われないすべてのセキュリティ問題を解決することと一致したすべての商業的に理にかなった努力を使わなければなりません

[[Category:OWASP Legal Project]]

__NOTOC__

OWASP Secure Software Contract Annex/ja

2011-07-05T00:37:45Z

Tomo: /* しかし厳密さのレベルは間違っている…. */

'''セキュア・ソフトウェア開発契約付属書'''

警告：この文書は、単にガイダンスと考えられなければなりません。
OWASPは、ソフトウェア契約を交渉するのを手助けするために、
あなたが資格のある弁護士に相談するよう強く勧めます。

==序文==

OWASPセキュア・ソフトウェア開発契約付属書は、ソフトウェアの開発者とその顧客が、開発または供給されるソフトウェアのセキュリティに関連した重要な契約条項と条件を交渉し、取り込むことを助けます。このプロジェクトの理由は、多くの契約はこれらの問題に触れておらず、しばしば関係者が実際に同意されたものに劇的に異なる見解を持つことです。私たちは、これらの条項を明確に述べることは、双方の関係者が進め方について情報に基づいた意思決定ができることを確実にするもっともよい方法であると思っています。

「市場がより良いセキュリティを要求するとき、商用ソフトのセキュリティは改善します。
最低限、あらゆるソフトウェア提案依頼書は、ベンダーに彼らがセキュリティ脆弱性に対して
生産物をテストする方法を詳述するよう依頼しなければなりません。このステップは、企業が
セキュリティを評価すると市販ソフトウェアのベンダーと外部調達された開発者を納得させ始めます。」
-- John Pescatore（Gartnerのリサーチ・ディレクター）として

私たちは、顧客と開発者が、期待について議論して、責任について交渉することに対するフレームワークとしてこの文書を使うよう勧めます。この付属書は、ソフトウェア開発契約に添付されることを目的とします。これらの条項は交渉の余地があります。そして、それらは顧客と開発者によって、協議されることができて、協議されなければならないことを意味します。

==プロジェクトについて==

この文書はOpen Web Application Security Project（OWASP）財団（セキュアなソフトウェアに関連した無料でオープンなツールとドキュメンテーションを作成することを専門とする非営利の慈善団体）によって作成されました。個人契約において容易に使用できるようにするために、この文書はCC Share Alike 3.0ライセンスにて提供されます。あなたが適すると思うように、修正してもよいですし、使用してもよいです。あなたは、http://www.owasp.com/index.php/OWASP_Legal_Project でこのプロジェクトについて更なる詳細を見つけることができます。私たちは、ソフトウェア（法律コミュニティだけでなく）の製作者と消費者のコメントを歓迎します。

OWASPは、この文書の研究と準備における彼らの役割に対して [http://www.aspectsecurity.com Aspect Security] から特別な貢献を感謝して認めます。

==異論==

以下のわずかなページは、ソフトウェア開発契約においてこの言い回しを使用することに対するいくらかのたびたび聞こえる異論をカバーします：

===しかし、すべての条項が私たちにとって適切であるというわけではありません…===

この文書は、あなたの合意の開始地点です。あなたは、すべての活動が好きではないかもしれません、または、より多くの提案をしたいかもしれません。あなたは異なる責任を割り当てたいかもしれません。この文書は、すべてのソフトウェア顧客と開発者の要望を厳密に取り込むことを意図しているわけではありません。ソフトウェアが最終的にセキュアになることを確実にするために重要である、主要な項目を議論するためのフレームワークを提供することを意図します。セキュリティを議論して合意を得た後で、あなたはこの合意を適合するように調整すべきです。

===しかし、これらの活動に対して誰が代金を払わなければならないのでしょうか===

この契約は、ソフトウェア開発者により多くの負担を与えることはほとんどありません。問題は、セキュリティ ― もちろんそこにある ― と関連したコストがあるかどうかということでありません。むしろ、適切な問題はどんな活動がそれらのコストを最小にするために双方によって実行されなければならないかということです、そして、いつ、それらは起こらなければなりませんか。

この付属書は、誰がここに記述される活動の料金を払わなければならないかという問題については、意図的に語られていません。これらの活動の多くがすでに起こらなければならなくて、多くの顧客によって期待される一方、それたはソフトウェア産業で定期的に実践されることはありません。誰が（そして、いくら）支払うかという問題が、交渉の一部でなければなりません。

セキュリティのコストを計算することは、非常に難しいです。セキュリティ活動を実行することに関連したコストがある一方、それらを無視することに関連したかなりのコストもあります。私たちは、ソフトウェアを開発する最も費用対効果がよい方法について確信しています。それは、セキュリティ瑕疵が導入されるという可能性を減らして、瑕疵を導入して、それを修正することの間で時間を最小にすることです。

コストを計算するときにする一つの重要な区別は、セキュリティ手法を構築することと、それらの手法が正しくて効果的であることを確実にする保証活動の間にあります。ライフサイクルの終わりに手法を加えようとすることは、深刻な設計問題を引き起こすことがありえて、めざましくコストを増やします。この合意は、手法についての早い段階の決定がこれらのコストを最小にするのを奨励します。同様に、配備直前に保証活動（例えばコードレビューと侵入テスト）をするまで待つことはコストをめざましく増やします。私たちは、保証を得る最も費用効果がよい方法がライフサイクルを通して努力の一定のレベルを保証に入れることであると思っています。

===しかし厳密さのレベルは間違っている….===

この合意は、開発されているソフトウェアが大企業または政府機関にとってかなり重要であると仮定します。私たちは、大部分のソフトウェア開発組織によって達成できる合意のために「厳格さのレベル」を選んで、最も一般的なリスクを確認して、取り扱います。

しかし、重要なアプリケーション（例えば医学であるか、財政的であるか、防衛に関連したソフトウェア）で使われそうであるソフトウェアについては、あなたは厳格さのレベルを上げたいかもしれません。あなたは、追加のレビュー、文書化とテストの活動を加えたくてもよいです。あなたは、脆弱性を探すこと、診断すること、修正することに対するプロセスを強化しくてもよいです。より機密を扱わないアプリケーションのために、あなたは活動を減らすか、取り除きたくてもよいです。

===しかし私たちはそれほど多くのリスクをとることができない…===

この契約は、ソフトウェアにおけるセキュリティ脆弱性に対するリスクをとるのかという議論を容易にすることを目的とします。範囲の一端で、顧客はすべてのリスクをすることができました、そして、開発者はたくさんの脆弱性でコードを供給することができました。他の極端で、開発者はすべてのリスクをとることができて、完全なコードを供給することに対する責任を負うことができました。これらの極端の両方とも、実行不可能です。

現在、この契約において、開発者は要求においてカバーされたか、理にかなったテスト努力によってカバーされるべき問題に対するリスクをとります。しかし、「新しい」セキュリティ問題の改善は、顧客によって代金を払われるべきです。私たちは、これが開発者が彼らのリスクの境界となることができて役に立つバランスで、顧客が前もってセキュリティ要求を正しくするのを奨励すると思っています。しかし、この問題の多くの他の可能性がある解決が、あります。あなたには他の提案があるかどうか私たちに知らせます、そして、私たちは彼らをこの文書の将来の版に含めてもよいです。

ここでの議論がコードにおいてセキュリティ脆弱性を修正することに関連したリスクをカバーだけして、これらの脆弱性のあらゆるエクスプロイットに基づくあらゆるセキュリティ・インシデントから立ち直ることと関連したコストを含まないことに注意すべきです。私たちは、この領域におけるベスト・プラクティスに興味があります。

===私たちはどのように第三者のコードを保証するでしょうか===

ほとんどすべてのソフトウェアプロジェクトは、第三者のコード（例えばライブラリ、フレームワークと生産物）のかなりの量を使います。このコードは、ただセキュリティ観点から、カスタム・コードがあなたのプロジェクトのために特に発達したのと同じくらい重要です。
私たちはこのコードのセキュリティを確実にすることに対する責任が開発者によって負われて最もよいと思っています、しかし、彼らにはこのセキュリティを保証するために彼ら自身のいっぱいの能力がないかもしれません。しかし、セキュリティは「構築するか、買うか」議論の一部分でなければなりません、これはそれを促進する最もよい方法のようです。

開発者は、もちろん、終わりまで第三者のソフトウェアの提供者にこの責任をパスする選択権があります。開発者は彼ら自身第三者のコードを分析することもできるか、彼らのためにそれを分析するために、セキュリティの専門家を雇うこともできます。

===しかし、なぜ私はすべてのこのトラブルにいくべきなのでしょうか===

最後に、私たちはソフトウェアを契約しているプロセスの一部分をセキュリティをすることに代わるものがないと思っています。現在では、私たちは多くのソフトウェア開発契約のもとで供給されているコードのセキュリティに関する重大な誤解があると思っています。これは、わずかなソフトウェア経験または理解とともに個人によってなされる高価な訴訟と決定に至ることができるだけです。この問題の完全な議論に対して [[Secure software contracting hypothetical case study]] を読んでください。

多くの利点が、この契約を通してうまくいくことにあります。主要なものは、それが関係する関係者の間で期待を明らかにするということです。場合によっては、難しいセキュリティ問題がソフトウェアで表面化するとき、それは訴訟を妨げるのを助けます。また、これらは多くの法的で調整するコンプライアンスの理由によって必要とされる同じ活動です。

===しかし、このドキュメントですべてを作ることは難しい===

OWASPは、文書の目的のために文書を励ましません。この契約は、品質（量でない）を促すことに集中します。私たちは、短時間のリスク評価、数ページの要求、短いセキュリティ設計文書、テストプラン、いくつかのテスト結果とともに、この契約に応じることが（若干のプロジェクトにおいて）ありえると思っています。

この文書の目標は、ライフサイクルの各段階で、単に適切な注意がセキュリティに払われたことを確実とすることです。追加の利点は、この文書が基本的に、このソフトウェアが安心してそれがそれがすると主張することをするのをまかせられなければならない理由に対する議論を配置する「証明パッケージ」をつくるために一緒に集められることができるということです。

==契約付属書==

===1. 序文===

この付属書は、顧客と開発者の間で_____________________ ("合意") するために作られます。顧客と開発者は、以下の条件のよりソフトウェアのセキュリティを最大にすることに同意します。

===2. 原理===

この付属書は、ソフトウェア開発関係のすべての関係者のセキュリティ関連の権利と義務をはっきりさせることを目的とします。最高水準で、関係者は以下に同意します

;(a) セキュリティ決定は、リスクに基づきます : セキュリティについての決定は、関係するリスクのしっかりした理解に基づく顧客と開発者によって共同でなされす。

;(b) セキュリティ活動はバランスが保たれます : セキュリティ努力は、全てのソフトウェア開発ライフサイクル全体でおおよそ均一に配布されます。

;(c) セキュリティ活動は統合されます : ここに協議されるすべての活動と文書は、開発者のソフトウェア開発ライフサイクルに統合されて、残りのプロジェクトと別にしておかれるというわけではありません。この付属書の何も、どんな特定のソフトウェア開発プロセスを意味しません。

;(d) 脆弱性は予想されます : すべてのソフトウェアにはバグがあります、そして、それらのいくらかはセキュリティ問題を生じさせます。顧客と開発者は、ライフサイクルにおいてできるだけ早く脆弱性を特定するよう努めます。

;(e) セキュリティ情報は、完全に明らかにされます : すべてのセキュリティ関連した情報は、すぐに、そして、完全に、顧客と開発者で共有されます。

;(f) 役に立つセキュリティ文書だけが必要とされます : セキュリティ文書は、セキュリティ設計、リスク分析または問題を明確に記述するために詳細にわたる必要はありません。

===3.ライフサイクル活動===

;(a) リスク識別 : 開発者とClientは、アプリケーションに直面しているリスクを理解して、文書化するために一緒に働くことに同意します。この努力は、アプリケーションにより提供される重要な資産と機能に主要なリスクを確認しなければなりません。要件部にリストされるトピックの各々は、考慮されなければなりません。

;(b) 要求 : リスクに基づいて、開発者と顧客は、開発されるソフトウェアの仕様の一部として詳細なセキュリティ要件を確立するために一緒に働くことに同意します。この付属書の要件部分で記載されるトピックの各々は、開発者と顧客によって協議されなければならなくて、評価されなければなりません。これらの要件は、カスタム・ソフト、第三者のソフトウェアまたはプラットホームによって満たされてもよいです。

;(c) 設計 : 開発者は、セキュリティ要件の各々を達成するために明確に設計を説明する文書を提供することに同意します。ほとんどの場合、この文書はセキュリティ手法を記載します、そこで、手法はアーキテクチャに適合しました、そして、関連したすべては彼らの適正使用を確実にするためにパターンを設計します。設計は、サポートがカスタム・ソフトか、第三者のソフトウェアかプラットホームから来るかどうか、明確に指定しなければなりません。

;(d) 実装 : 開発者は、一組のセキュアなコーディング指針に提供することに、従って、一組の共通セキュリティ制御プログラミング・インターフェース（例えば [http://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API OWASP Enterprise Security API（ESAPI）] ）を使って同意します。ガイドラインは、コードがどのようにフォーマットされなければならなくて、構築されなければならなくて、コメントされなければならないかについて示します。共通セキュリティ制御プログラミング・インターフェースは、セキュリティ制御がどのように呼ばれなければならないか、そして、セキュリティ制御がどのように機能するか定めます。すべてのセキュリティに関連したコードは、完全にコメントされます。共通のセキュリティ脆弱性を回避するときの具体的なガイダンスは、含まれなければなりません。また、すべてのコードはセキュリティ要件に対して少なくとも他の一人の開発者によってレビューされなければなりません、そして、それの前のコーディング・ガイドラインは単体テストの準備ができていると思われます。

;(e) セキュリティ分析とテスト : 開発者は、（ [http://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project OWASP Application Security Verification Standard (ASVS)] のような）合意された標準の検証要件により、アプリケーション・セキュリティ分析とテスト（「検証」とも言われる）を実行します。開発者は、標準の報告要件によって検証結論を文書化しなければなりません。開発者は、検証結論を顧客に提供しなければなりません。

;(f) セキュリティ配備 : 開発者は、ソフトウェアの全体的なセキュリティのために完全にすべてのセキュリティ関連した構成オプションとそれらの関連性を記述するセキュアな構成ガイドラインを提供することに同意します。ガイドラインは、オペレーティングシステム、ウェブサーバとアプリケーション・サーバーを含むサポート的なプラットホームにおける依存関係の完全な記述を含まなければいけません。また、どのようにそれらをセキュリティのために構成されるべきかを含まなければいけません。ソフトウェアのデフォルトコンフィグレーションは、セキュアでなければなりません。

===4.セキュリティ要求エリア===

以下のトピック領域は、リスク理解と要求定義活動の間、考慮されなければなりません。この努力は一組の具体的で、注文仕立てで、分析できる要求を生産しなければなりません。そして、開発者と顧客はこのプロセスに関与していなければならなくて、要求の最終セットについて同意しなければなりません。

;(a) 入力検証とエンコーディング : 要求は、ユーザー、ファイルシステム、データベース、ディレクトリまたは外部システムからであるかどうかにかかわらず、アプリケーションへの各々の入力を標準化し、検証し、コード化するためにルールを指定しなければなりません。　　　デフォルトルールは、それが何が許可されるかという詳細な仕様にマッチしない限り、すべての入力が無効であるということでなければなりません。そのうえ、無効な入力が受け取られるとき、要求はとられる措置を指定しなければなりません。具体的には、アプリケーションはインジェクション、オーバフロー、不正操作することまたは他の不正な入力攻撃に影響されやすくてはいけません。

;(b) 認証とセッション管理 : 要求は、認証証明書とセッション識別子がどのようにそれらのライフサイクルを通して保護されているかについて明記しなければなりません。すべての関連する機能（パスワード忘却、パスワード変更、パスワードリマインダ、ログアウト、そして複数ログインを含む）に対する要求は含められなければいけません。

;(c) アクセス制御 : 要求は、アプリケーションで使われるすべての役割（グループ、特権、認可）の詳細な記述を含まなければなりません。要求は、アプリケーションにより提供されるすべての資産と機能も示さなければなりません。要求は、完全に各々の資産に正確なアクセス権を指定しなければならなくて、各々の役割に対して機能しなければなりません。アクセス制御マトリックスは、これらのルールのための提案されたフォーマットです。

;(d) エラー処理 : 要求は、処理の間、発生しているエラーが取り扱われる方法を詳述しなければなりません。若干のアプリケーションはエラーの場合には最もよい努力結果を提供しなければなりません、一方、他はすぐに処理を終了しなければなりません。

;(e) ロギング : 要求は、どんなイベントがセキュリティに関連して、記録される必要があるか、たとえば、検知された攻撃、失敗したログイン試行、認可を上回ろうとする試行、を指定しなければなりません。要求は、時間と日付、イベント記述、アプリケーション詳細とフォレンジクス努力に役立つ他の情報を含む、各々のイベントでどんな情報を記録するべきかについても指定しなければなりません。

;(f) 外部システムへの接続 : 要求は、認証と暗号化がどのようにすべての外部システム（例えばデータベース、ディレクトリとウェブ・サービス）のために取り扱われるかについて指定しなければなりません。外部システムでコミュニケーションのために必要とされるすべてのクレディンシャルは、暗号化された形で構成ファイルでコードの外側に保存されなければなりません。

;(g) 暗号 : 要求は、どんなデータが暗号化されなければならないか、暗号化されることがどれほどか、そして、すべての証明書と他のクレディンシャルがどのように取り扱われなければならないか指定しなければなりません。アプリケーションは、広く使われていてテストされた暗号化ライブラリで実装される標準的なアルゴリズムを使用しなければなりません。

;(h) 可用性 : 要求は、それがどのようにサービス不能攻撃から保護するかについて指定しなければなりません。アプリケーションへのすべてのありそうな攻撃は考慮されなければなりません。そして、認証ロックアウト、接続消耗と他の資源消耗攻撃を含みます。

;(i) セキュアな設定 : 要求は、すべてのセキュリティに関連した構成オプションに対するデフォルト値がセキュアでなければならないことを示していなければなりません。監査目的のために、ソフトウェアはすべてのセキュリティに関連した構成詳細を示している簡単に読めるレポートをつくることができなければなりません。

;(j) 特定の脆弱性 : 要求は、ソフトウェアで見つかってはならない一組の具体的な脆弱性を含まなければなりません。指定されていないならば、ソフトウェアは現在の「OWASP Top Ten Most Critical Web Application Vulnerabilities」で記述される瑕疵の何も含んではいけません。

===5. 要員および組織===

;(a) セキュリティ・アーキテクト : 開発者は一つの上位の技術的な資源に責任をセキュリティに指定します。そして、プロジェクトのセキュリティ・アーキテクトとして知られています。セキュリティ・アーキテクトは、各々の納品可能なもののセキュリティを保証します。

;(b) セキュリティ・トレーニング : 開発者は、開発者チームのすべてのメンバーがセキュアなプログラミング技法の訓練をされたことを確かめる役割を果たします。

;(c) 信用できる開発者 : 開発者は、すべての開発チーム・メンバーの適切な経歴調査を実行することに同意します。

===6.開発環境===

;(a) セキュア・コーディング : 開発者は、どんなツールがセキュアなコーディングを促すためにソフトウェア開発環境で使われるかについて明らかにしなければなりません。

;(b) 構成管理 : 開発者は、ソフトウェア・ベースラインに対するすべての変更とすべての関連した設定とビルド・ファイルを関連づけ　とすべての関連した構成にすべての変化と関連したチーム・メンバーを認証して、記録して、ファイルを構築したソース・コード管理システムを使用しなければなりません。

;(c) 配布 : 開発者は、ソースから確実に完全な配布を構築するビルド・プロセスを使用しなければなりません。このプロセスは、顧客に供給されるソフトウェアの完全性を確かめる方法を含まなければなりません。

===7. ライブラリ、フレームワーク、および生産物===

;(a) 開示 : 開発者は、商用、フリー、オープンソース、クローズソースであるにせよ、すべてのライブラリ、フレームワーク、構成要素と他の生産物を含む、ソフトウェアで使われるすべての第三者のソフトウェアを明らかにしなければなりません。

;(b) 評価 : 開発者は、第三者のソフトウェアがこの契約のすべての条件を満たして、この契約の基で開発されたカスタム開発されたコードと同じくらいセキュアなことを確実とするために、理にかなった努力をしなければなりません。

===8. セキュリティ・レビュー===

;(a) レビューする権利 : 依頼人には、ソフトウェアを納品の60日間以内にいつでも彼らの費用でセキュリティ瑕疵のためにレビューしておく権利があります。開発者は、ソース・コードとテスト環境へのアクセスを提供することによって理にかなったサポートをレビュー・チームに提供することに同意します。

;(b) レビュー・カバレッジ : セキュリティ・レビューは供給されるソフトウェアのすべての面をカバーしなければなりません。そして、カスタム・コード、構成要素、生産物とシステム設定を含みます。

;(c) レビューの範囲 : 最低限で、レビューはセキュリティ要求の全てをカバーしなければならなくて、他の一般的な脆弱性を捜さなければなりません。レビューは、脆弱性スキャン、侵入テスト、ソースコードの静的分析と専門家のコードレビューの組み合わせを含んでもよいです。

;(d) 見つけられた問題 : 発見されたセキュリティ問題は、顧客と開発者に報告されます。すべての問題は、この付属書のセキュリティ問題マネジメント部分により追跡されて、矯正されます。

===9. セキュリティ問題マネジメント ===

;(a) 識別 : 要求、設計、実装、テスト、配備、または、運用中の問題にせよ、開発者は全てのライフサイクルの間に発見されるすべてのセキュリティ問題を追います。各々のセキュリティ問題に関連したリスクは、発見後できるだけ早く、評価されて、文書化されて、発見の後、顧客に報告されます。

;(b) 保護 : 開発者はセキュリティ問題と付随する文書に関して情報を適切に保護します。そして、運用中の顧客ソフトウェアの脆弱性が露出するという可能性を制限するのを助けます。

;(c) 改善 : 納品の前に確認されるセキュリティ問題は、開発者によって修正されなければなりません。納品の後に発見されるセキュリティ問題は、本契約の規定による他のバグと問題として同様に取り扱われなければなりません。

===10. 保証===

;(a) 保証 : 開発者は、開発プロセスを通して作成されるセキュリティ文書からなる「証明パッケージ」を提供します。パッケージは、セキュリティ要求、設計、実装と試験結果がきちんと完了された、そして、すべてのセキュリティ問題が適切に解決されたと確認しなければなりません。

;(b) 自己証明 : セキュリティ・アーキテクトは、ソフトウェアがセキュリティ要求を満たすこと、すべてのセキュリティ活動が実行されていること、そして、すべての識別されたセキュリティ問題が文書化されて、解決されたことを証明します。証明ステータスに対するあらゆる例外は、納品で完全に文書化されなければなりません。

;(c) 悪意のあるコードのなし : 開発者は、ソフトウェアがソフトウェア要求をサポートせず、コンピュータ・ウイルス、ワーム、時限爆弾、バック・ドア、トロイの木馬、イースターエッグと他のあらゆる形の悪意のあるソフトウェアを含む、アプリケーションのセキュリティを弱めるあらゆるコードを含んではならないと保証します。

===11. セキュリティ承認と保守 ===

;(a) 受け入れ : 証明パッケージが完全であり、すべてのセキュリティ問題が解決されるまで、ソフトウェアは受け入れられると考慮されてはいけません。

;(b) セキュリティ問題の調査 : 受理の後、セキュリティ問題が発見されるか、かなり疑われるならば、開発者は顧客が問題の性質を決定するために調査を実行するのを援助しなければなりません。それがセキュリティ要求によってカバーされないで、セキュリティ・テストの理にかなった範囲の外にあるならば、問題は「新しい」と思われなければなりません。

;(c) 新しいセキュリティ問題 : 開発者と顧客は、新しいセキュリティ問題を解決するために必要な努力を探し出すことに同意します。また、それらに取り組むために必要とされる仕事を実行するための合意を達成するために誠意を持って交渉することに同意します。

;(d) 他のセキュリティ問題 : 開発者は堅実なソフトウェア開発慣行。そして、リスクのひどさを考慮すること、そして、できるだけ速く新しいと思われないすべてのセキュリティ問題を解決することと一致したすべての商業的に理にかなった努力を使わなければなりません

[[Category:OWASP Legal Project]]

__NOTOC__

OWASP Secure Software Contract Annex/ja

2011-07-05T00:31:54Z

Tomo: /* しかし、これらの活動に対して誰が代金を払わなければならないのでしょうか */

'''セキュア・ソフトウェア開発契約付属書'''

警告：この文書は、単にガイダンスと考えられなければなりません。
OWASPは、ソフトウェア契約を交渉するのを手助けするために、
あなたが資格のある弁護士に相談するよう強く勧めます。

==序文==

OWASPセキュア・ソフトウェア開発契約付属書は、ソフトウェアの開発者とその顧客が、開発または供給されるソフトウェアのセキュリティに関連した重要な契約条項と条件を交渉し、取り込むことを助けます。このプロジェクトの理由は、多くの契約はこれらの問題に触れておらず、しばしば関係者が実際に同意されたものに劇的に異なる見解を持つことです。私たちは、これらの条項を明確に述べることは、双方の関係者が進め方について情報に基づいた意思決定ができることを確実にするもっともよい方法であると思っています。

「市場がより良いセキュリティを要求するとき、商用ソフトのセキュリティは改善します。
最低限、あらゆるソフトウェア提案依頼書は、ベンダーに彼らがセキュリティ脆弱性に対して
生産物をテストする方法を詳述するよう依頼しなければなりません。このステップは、企業が
セキュリティを評価すると市販ソフトウェアのベンダーと外部調達された開発者を納得させ始めます。」
-- John Pescatore（Gartnerのリサーチ・ディレクター）として

私たちは、顧客と開発者が、期待について議論して、責任について交渉することに対するフレームワークとしてこの文書を使うよう勧めます。この付属書は、ソフトウェア開発契約に添付されることを目的とします。これらの条項は交渉の余地があります。そして、それらは顧客と開発者によって、協議されることができて、協議されなければならないことを意味します。

==プロジェクトについて==

この文書はOpen Web Application Security Project（OWASP）財団（セキュアなソフトウェアに関連した無料でオープンなツールとドキュメンテーションを作成することを専門とする非営利の慈善団体）によって作成されました。個人契約において容易に使用できるようにするために、この文書はCC Share Alike 3.0ライセンスにて提供されます。あなたが適すると思うように、修正してもよいですし、使用してもよいです。あなたは、http://www.owasp.com/index.php/OWASP_Legal_Project でこのプロジェクトについて更なる詳細を見つけることができます。私たちは、ソフトウェア（法律コミュニティだけでなく）の製作者と消費者のコメントを歓迎します。

OWASPは、この文書の研究と準備における彼らの役割に対して [http://www.aspectsecurity.com Aspect Security] から特別な貢献を感謝して認めます。

==異論==

以下のわずかなページは、ソフトウェア開発契約においてこの言い回しを使用することに対するいくらかのたびたび聞こえる異論をカバーします：

===しかし、すべての条項が私たちにとって適切であるというわけではありません…===

この文書は、あなたの合意の開始地点です。あなたは、すべての活動が好きではないかもしれません、または、より多くの提案をしたいかもしれません。あなたは異なる責任を割り当てたいかもしれません。この文書は、すべてのソフトウェア顧客と開発者の要望を厳密に取り込むことを意図しているわけではありません。ソフトウェアが最終的にセキュアになることを確実にするために重要である、主要な項目を議論するためのフレームワークを提供することを意図します。セキュリティを議論して合意を得た後で、あなたはこの合意を適合するように調整すべきです。

===しかし、これらの活動に対して誰が代金を払わなければならないのでしょうか===

この契約は、ソフトウェア開発者により多くの負担を与えることはほとんどありません。問題は、セキュリティ ― もちろんそこにある ― と関連したコストがあるかどうかということでありません。むしろ、適切な問題はどんな活動がそれらのコストを最小にするために双方によって実行されなければならないかということです、そして、いつ、それらは起こらなければなりませんか。

この付属書は、誰がここに記述される活動の料金を払わなければならないかという問題については、意図的に語られていません。これらの活動の多くがすでに起こらなければならなくて、多くの顧客によって期待される一方、それたはソフトウェア産業で定期的に実践されることはありません。誰が（そして、いくら）支払うかという問題が、交渉の一部でなければなりません。

セキュリティのコストを計算することは、非常に難しいです。セキュリティ活動を実行することに関連したコストがある一方、それらを無視することに関連したかなりのコストもあります。私たちは、ソフトウェアを開発する最も費用対効果がよい方法について確信しています。それは、セキュリティ瑕疵が導入されるという可能性を減らして、瑕疵を導入して、それを修正することの間で時間を最小にすることです。

コストを計算するときにする一つの重要な区別は、セキュリティ手法を構築することと、それらの手法が正しくて効果的であることを確実にする保証活動の間にあります。ライフサイクルの終わりに手法を加えようとすることは、深刻な設計問題を引き起こすことがありえて、めざましくコストを増やします。この合意は、手法についての早い段階の決定がこれらのコストを最小にするのを奨励します。同様に、配備直前に保証活動（例えばコードレビューと侵入テスト）をするまで待つことはコストをめざましく増やします。私たちは、保証を得る最も費用効果がよい方法がライフサイクルを通して努力の一定のレベルを保証に入れることであると思っています。

===しかし厳密さのレベルは間違っている….===

この合意は、開発されているソフトウェアが大企業または政府機関にとってかなり重要であると仮定します。私たちは、大部分のソフトウェア開発組織によって達成できる合意のために「厳格さのレベル」を選んで、最も一般的なリスクを確認して、取り扱います。

しかし、重要なアプリケーション（例えば医学であるか、財政的であるか、防衛に関連したソフトウェア）で使われそうであるソフトウェアについては、あなたは厳格さのレベルを上げたいかもしれません。あなたは、追加のレビュー、文書とテストしている活動を加えたくてもよいです。あなたは、脆弱性を探すこと、診断すること、修正することに対するプロセスを強化しくてもよいです。より機密を扱わないアプリケーションのために、あなたは活動を減らすか、取り除きたくてもよいです。

===しかし私たちはそれほど多くのリスクをとることができない…===

この契約は、ソフトウェアにおけるセキュリティ脆弱性に対するリスクをとるのかという議論を容易にすることを目的とします。範囲の一端で、顧客はすべてのリスクをすることができました、そして、開発者はたくさんの脆弱性でコードを供給することができました。他の極端で、開発者はすべてのリスクをとることができて、完全なコードを供給することに対する責任を負うことができました。これらの極端の両方とも、実行不可能です。

現在、この契約において、開発者は要求においてカバーされたか、理にかなったテスト努力によってカバーされるべき問題に対するリスクをとります。しかし、「新しい」セキュリティ問題の改善は、顧客によって代金を払われるべきです。私たちは、これが開発者が彼らのリスクの境界となることができて役に立つバランスで、顧客が前もってセキュリティ要求を正しくするのを奨励すると思っています。しかし、この問題の多くの他の可能性がある解決が、あります。あなたには他の提案があるかどうか私たちに知らせます、そして、私たちは彼らをこの文書の将来の版に含めてもよいです。

ここでの議論がコードにおいてセキュリティ脆弱性を修正することに関連したリスクをカバーだけして、これらの脆弱性のあらゆるエクスプロイットに基づくあらゆるセキュリティ・インシデントから立ち直ることと関連したコストを含まないことに注意すべきです。私たちは、この領域におけるベスト・プラクティスに興味があります。

===私たちはどのように第三者のコードを保証するでしょうか===

ほとんどすべてのソフトウェアプロジェクトは、第三者のコード（例えばライブラリ、フレームワークと生産物）のかなりの量を使います。このコードは、ただセキュリティ観点から、カスタム・コードがあなたのプロジェクトのために特に発達したのと同じくらい重要です。
私たちはこのコードのセキュリティを確実にすることに対する責任が開発者によって負われて最もよいと思っています、しかし、彼らにはこのセキュリティを保証するために彼ら自身のいっぱいの能力がないかもしれません。しかし、セキュリティは「構築するか、買うか」議論の一部分でなければなりません、これはそれを促進する最もよい方法のようです。

開発者は、もちろん、終わりまで第三者のソフトウェアの提供者にこの責任をパスする選択権があります。開発者は彼ら自身第三者のコードを分析することもできるか、彼らのためにそれを分析するために、セキュリティの専門家を雇うこともできます。

===しかし、なぜ私はすべてのこのトラブルにいくべきなのでしょうか===

最後に、私たちはソフトウェアを契約しているプロセスの一部分をセキュリティをすることに代わるものがないと思っています。現在では、私たちは多くのソフトウェア開発契約のもとで供給されているコードのセキュリティに関する重大な誤解があると思っています。これは、わずかなソフトウェア経験または理解とともに個人によってなされる高価な訴訟と決定に至ることができるだけです。この問題の完全な議論に対して [[Secure software contracting hypothetical case study]] を読んでください。

多くの利点が、この契約を通してうまくいくことにあります。主要なものは、それが関係する関係者の間で期待を明らかにするということです。場合によっては、難しいセキュリティ問題がソフトウェアで表面化するとき、それは訴訟を妨げるのを助けます。また、これらは多くの法的で調整するコンプライアンスの理由によって必要とされる同じ活動です。

===しかし、このドキュメントですべてを作ることは難しい===

OWASPは、文書の目的のために文書を励ましません。この契約は、品質（量でない）を促すことに集中します。私たちは、短時間のリスク評価、数ページの要求、短いセキュリティ設計文書、テストプラン、いくつかのテスト結果とともに、この契約に応じることが（若干のプロジェクトにおいて）ありえると思っています。

この文書の目標は、ライフサイクルの各段階で、単に適切な注意がセキュリティに払われたことを確実とすることです。追加の利点は、この文書が基本的に、このソフトウェアが安心してそれがそれがすると主張することをするのをまかせられなければならない理由に対する議論を配置する「証明パッケージ」をつくるために一緒に集められることができるということです。

==契約付属書==

===1. 序文===

この付属書は、顧客と開発者の間で_____________________ ("合意") するために作られます。顧客と開発者は、以下の条件のよりソフトウェアのセキュリティを最大にすることに同意します。

===2. 原理===

この付属書は、ソフトウェア開発関係のすべての関係者のセキュリティ関連の権利と義務をはっきりさせることを目的とします。最高水準で、関係者は以下に同意します

;(a) セキュリティ決定は、リスクに基づきます : セキュリティについての決定は、関係するリスクのしっかりした理解に基づく顧客と開発者によって共同でなされす。

;(b) セキュリティ活動はバランスが保たれます : セキュリティ努力は、全てのソフトウェア開発ライフサイクル全体でおおよそ均一に配布されます。

;(c) セキュリティ活動は統合されます : ここに協議されるすべての活動と文書は、開発者のソフトウェア開発ライフサイクルに統合されて、残りのプロジェクトと別にしておかれるというわけではありません。この付属書の何も、どんな特定のソフトウェア開発プロセスを意味しません。

;(d) 脆弱性は予想されます : すべてのソフトウェアにはバグがあります、そして、それらのいくらかはセキュリティ問題を生じさせます。顧客と開発者は、ライフサイクルにおいてできるだけ早く脆弱性を特定するよう努めます。

;(e) セキュリティ情報は、完全に明らかにされます : すべてのセキュリティ関連した情報は、すぐに、そして、完全に、顧客と開発者で共有されます。

;(f) 役に立つセキュリティ文書だけが必要とされます : セキュリティ文書は、セキュリティ設計、リスク分析または問題を明確に記述するために詳細にわたる必要はありません。

===3.ライフサイクル活動===

;(a) リスク識別 : 開発者とClientは、アプリケーションに直面しているリスクを理解して、文書化するために一緒に働くことに同意します。この努力は、アプリケーションにより提供される重要な資産と機能に主要なリスクを確認しなければなりません。要件部にリストされるトピックの各々は、考慮されなければなりません。

;(b) 要求 : リスクに基づいて、開発者と顧客は、開発されるソフトウェアの仕様の一部として詳細なセキュリティ要件を確立するために一緒に働くことに同意します。この付属書の要件部分で記載されるトピックの各々は、開発者と顧客によって協議されなければならなくて、評価されなければなりません。これらの要件は、カスタム・ソフト、第三者のソフトウェアまたはプラットホームによって満たされてもよいです。

;(c) 設計 : 開発者は、セキュリティ要件の各々を達成するために明確に設計を説明する文書を提供することに同意します。ほとんどの場合、この文書はセキュリティ手法を記載します、そこで、手法はアーキテクチャに適合しました、そして、関連したすべては彼らの適正使用を確実にするためにパターンを設計します。設計は、サポートがカスタム・ソフトか、第三者のソフトウェアかプラットホームから来るかどうか、明確に指定しなければなりません。

;(d) 実装 : 開発者は、一組のセキュアなコーディング指針に提供することに、従って、一組の共通セキュリティ制御プログラミング・インターフェース（例えば [http://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API OWASP Enterprise Security API（ESAPI）] ）を使って同意します。ガイドラインは、コードがどのようにフォーマットされなければならなくて、構築されなければならなくて、コメントされなければならないかについて示します。共通セキュリティ制御プログラミング・インターフェースは、セキュリティ制御がどのように呼ばれなければならないか、そして、セキュリティ制御がどのように機能するか定めます。すべてのセキュリティに関連したコードは、完全にコメントされます。共通のセキュリティ脆弱性を回避するときの具体的なガイダンスは、含まれなければなりません。また、すべてのコードはセキュリティ要件に対して少なくとも他の一人の開発者によってレビューされなければなりません、そして、それの前のコーディング・ガイドラインは単体テストの準備ができていると思われます。

;(e) セキュリティ分析とテスト : 開発者は、（ [http://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project OWASP Application Security Verification Standard (ASVS)] のような）合意された標準の検証要件により、アプリケーション・セキュリティ分析とテスト（「検証」とも言われる）を実行します。開発者は、標準の報告要件によって検証結論を文書化しなければなりません。開発者は、検証結論を顧客に提供しなければなりません。

;(f) セキュリティ配備 : 開発者は、ソフトウェアの全体的なセキュリティのために完全にすべてのセキュリティ関連した構成オプションとそれらの関連性を記述するセキュアな構成ガイドラインを提供することに同意します。ガイドラインは、オペレーティングシステム、ウェブサーバとアプリケーション・サーバーを含むサポート的なプラットホームにおける依存関係の完全な記述を含まなければいけません。また、どのようにそれらをセキュリティのために構成されるべきかを含まなければいけません。ソフトウェアのデフォルトコンフィグレーションは、セキュアでなければなりません。

===4.セキュリティ要求エリア===

以下のトピック領域は、リスク理解と要求定義活動の間、考慮されなければなりません。この努力は一組の具体的で、注文仕立てで、分析できる要求を生産しなければなりません。そして、開発者と顧客はこのプロセスに関与していなければならなくて、要求の最終セットについて同意しなければなりません。

;(a) 入力検証とエンコーディング : 要求は、ユーザー、ファイルシステム、データベース、ディレクトリまたは外部システムからであるかどうかにかかわらず、アプリケーションへの各々の入力を標準化し、検証し、コード化するためにルールを指定しなければなりません。　　　デフォルトルールは、それが何が許可されるかという詳細な仕様にマッチしない限り、すべての入力が無効であるということでなければなりません。そのうえ、無効な入力が受け取られるとき、要求はとられる措置を指定しなければなりません。具体的には、アプリケーションはインジェクション、オーバフロー、不正操作することまたは他の不正な入力攻撃に影響されやすくてはいけません。

;(b) 認証とセッション管理 : 要求は、認証証明書とセッション識別子がどのようにそれらのライフサイクルを通して保護されているかについて明記しなければなりません。すべての関連する機能（パスワード忘却、パスワード変更、パスワードリマインダ、ログアウト、そして複数ログインを含む）に対する要求は含められなければいけません。

;(c) アクセス制御 : 要求は、アプリケーションで使われるすべての役割（グループ、特権、認可）の詳細な記述を含まなければなりません。要求は、アプリケーションにより提供されるすべての資産と機能も示さなければなりません。要求は、完全に各々の資産に正確なアクセス権を指定しなければならなくて、各々の役割に対して機能しなければなりません。アクセス制御マトリックスは、これらのルールのための提案されたフォーマットです。

;(d) エラー処理 : 要求は、処理の間、発生しているエラーが取り扱われる方法を詳述しなければなりません。若干のアプリケーションはエラーの場合には最もよい努力結果を提供しなければなりません、一方、他はすぐに処理を終了しなければなりません。

;(e) ロギング : 要求は、どんなイベントがセキュリティに関連して、記録される必要があるか、たとえば、検知された攻撃、失敗したログイン試行、認可を上回ろうとする試行、を指定しなければなりません。要求は、時間と日付、イベント記述、アプリケーション詳細とフォレンジクス努力に役立つ他の情報を含む、各々のイベントでどんな情報を記録するべきかについても指定しなければなりません。

;(f) 外部システムへの接続 : 要求は、認証と暗号化がどのようにすべての外部システム（例えばデータベース、ディレクトリとウェブ・サービス）のために取り扱われるかについて指定しなければなりません。外部システムでコミュニケーションのために必要とされるすべてのクレディンシャルは、暗号化された形で構成ファイルでコードの外側に保存されなければなりません。

;(g) 暗号 : 要求は、どんなデータが暗号化されなければならないか、暗号化されることがどれほどか、そして、すべての証明書と他のクレディンシャルがどのように取り扱われなければならないか指定しなければなりません。アプリケーションは、広く使われていてテストされた暗号化ライブラリで実装される標準的なアルゴリズムを使用しなければなりません。

;(h) 可用性 : 要求は、それがどのようにサービス不能攻撃から保護するかについて指定しなければなりません。アプリケーションへのすべてのありそうな攻撃は考慮されなければなりません。そして、認証ロックアウト、接続消耗と他の資源消耗攻撃を含みます。

;(i) セキュアな設定 : 要求は、すべてのセキュリティに関連した構成オプションに対するデフォルト値がセキュアでなければならないことを示していなければなりません。監査目的のために、ソフトウェアはすべてのセキュリティに関連した構成詳細を示している簡単に読めるレポートをつくることができなければなりません。

;(j) 特定の脆弱性 : 要求は、ソフトウェアで見つかってはならない一組の具体的な脆弱性を含まなければなりません。指定されていないならば、ソフトウェアは現在の「OWASP Top Ten Most Critical Web Application Vulnerabilities」で記述される瑕疵の何も含んではいけません。

===5. 要員および組織===

;(a) セキュリティ・アーキテクト : 開発者は一つの上位の技術的な資源に責任をセキュリティに指定します。そして、プロジェクトのセキュリティ・アーキテクトとして知られています。セキュリティ・アーキテクトは、各々の納品可能なもののセキュリティを保証します。

;(b) セキュリティ・トレーニング : 開発者は、開発者チームのすべてのメンバーがセキュアなプログラミング技法の訓練をされたことを確かめる役割を果たします。

;(c) 信用できる開発者 : 開発者は、すべての開発チーム・メンバーの適切な経歴調査を実行することに同意します。

===6.開発環境===

;(a) セキュア・コーディング : 開発者は、どんなツールがセキュアなコーディングを促すためにソフトウェア開発環境で使われるかについて明らかにしなければなりません。

;(b) 構成管理 : 開発者は、ソフトウェア・ベースラインに対するすべての変更とすべての関連した設定とビルド・ファイルを関連づけ　とすべての関連した構成にすべての変化と関連したチーム・メンバーを認証して、記録して、ファイルを構築したソース・コード管理システムを使用しなければなりません。

;(c) 配布 : 開発者は、ソースから確実に完全な配布を構築するビルド・プロセスを使用しなければなりません。このプロセスは、顧客に供給されるソフトウェアの完全性を確かめる方法を含まなければなりません。

===7. ライブラリ、フレームワーク、および生産物===

;(a) 開示 : 開発者は、商用、フリー、オープンソース、クローズソースであるにせよ、すべてのライブラリ、フレームワーク、構成要素と他の生産物を含む、ソフトウェアで使われるすべての第三者のソフトウェアを明らかにしなければなりません。

;(b) 評価 : 開発者は、第三者のソフトウェアがこの契約のすべての条件を満たして、この契約の基で開発されたカスタム開発されたコードと同じくらいセキュアなことを確実とするために、理にかなった努力をしなければなりません。

===8. セキュリティ・レビュー===

;(a) レビューする権利 : 依頼人には、ソフトウェアを納品の60日間以内にいつでも彼らの費用でセキュリティ瑕疵のためにレビューしておく権利があります。開発者は、ソース・コードとテスト環境へのアクセスを提供することによって理にかなったサポートをレビュー・チームに提供することに同意します。

;(b) レビュー・カバレッジ : セキュリティ・レビューは供給されるソフトウェアのすべての面をカバーしなければなりません。そして、カスタム・コード、構成要素、生産物とシステム設定を含みます。

;(c) レビューの範囲 : 最低限で、レビューはセキュリティ要求の全てをカバーしなければならなくて、他の一般的な脆弱性を捜さなければなりません。レビューは、脆弱性スキャン、侵入テスト、ソースコードの静的分析と専門家のコードレビューの組み合わせを含んでもよいです。

;(d) 見つけられた問題 : 発見されたセキュリティ問題は、顧客と開発者に報告されます。すべての問題は、この付属書のセキュリティ問題マネジメント部分により追跡されて、矯正されます。

===9. セキュリティ問題マネジメント ===

;(a) 識別 : 要求、設計、実装、テスト、配備、または、運用中の問題にせよ、開発者は全てのライフサイクルの間に発見されるすべてのセキュリティ問題を追います。各々のセキュリティ問題に関連したリスクは、発見後できるだけ早く、評価されて、文書化されて、発見の後、顧客に報告されます。

;(b) 保護 : 開発者はセキュリティ問題と付随する文書に関して情報を適切に保護します。そして、運用中の顧客ソフトウェアの脆弱性が露出するという可能性を制限するのを助けます。

;(c) 改善 : 納品の前に確認されるセキュリティ問題は、開発者によって修正されなければなりません。納品の後に発見されるセキュリティ問題は、本契約の規定による他のバグと問題として同様に取り扱われなければなりません。

===10. 保証===

;(a) 保証 : 開発者は、開発プロセスを通して作成されるセキュリティ文書からなる「証明パッケージ」を提供します。パッケージは、セキュリティ要求、設計、実装と試験結果がきちんと完了された、そして、すべてのセキュリティ問題が適切に解決されたと確認しなければなりません。

;(b) 自己証明 : セキュリティ・アーキテクトは、ソフトウェアがセキュリティ要求を満たすこと、すべてのセキュリティ活動が実行されていること、そして、すべての識別されたセキュリティ問題が文書化されて、解決されたことを証明します。証明ステータスに対するあらゆる例外は、納品で完全に文書化されなければなりません。

;(c) 悪意のあるコードのなし : 開発者は、ソフトウェアがソフトウェア要求をサポートせず、コンピュータ・ウイルス、ワーム、時限爆弾、バック・ドア、トロイの木馬、イースターエッグと他のあらゆる形の悪意のあるソフトウェアを含む、アプリケーションのセキュリティを弱めるあらゆるコードを含んではならないと保証します。

===11. セキュリティ承認と保守 ===

;(a) 受け入れ : 証明パッケージが完全であり、すべてのセキュリティ問題が解決されるまで、ソフトウェアは受け入れられると考慮されてはいけません。

;(b) セキュリティ問題の調査 : 受理の後、セキュリティ問題が発見されるか、かなり疑われるならば、開発者は顧客が問題の性質を決定するために調査を実行するのを援助しなければなりません。それがセキュリティ要求によってカバーされないで、セキュリティ・テストの理にかなった範囲の外にあるならば、問題は「新しい」と思われなければなりません。

;(c) 新しいセキュリティ問題 : 開発者と顧客は、新しいセキュリティ問題を解決するために必要な努力を探し出すことに同意します。また、それらに取り組むために必要とされる仕事を実行するための合意を達成するために誠意を持って交渉することに同意します。

;(d) 他のセキュリティ問題 : 開発者は堅実なソフトウェア開発慣行。そして、リスクのひどさを考慮すること、そして、できるだけ速く新しいと思われないすべてのセキュリティ問題を解決することと一致したすべての商業的に理にかなった努力を使わなければなりません

[[Category:OWASP Legal Project]]

__NOTOC__

OWASP Secure Software Contract Annex/ja

2011-07-05T00:22:44Z

Tomo: /* しかし、すべての条件が私たちに対して適切であるというわけではありません… */

'''セキュア・ソフトウェア開発契約付属書'''

警告：この文書は、単にガイダンスと考えられなければなりません。
OWASPは、ソフトウェア契約を交渉するのを手助けするために、
あなたが資格のある弁護士に相談するよう強く勧めます。

==序文==

OWASPセキュア・ソフトウェア開発契約付属書は、ソフトウェアの開発者とその顧客が、開発または供給されるソフトウェアのセキュリティに関連した重要な契約条項と条件を交渉し、取り込むことを助けます。このプロジェクトの理由は、多くの契約はこれらの問題に触れておらず、しばしば関係者が実際に同意されたものに劇的に異なる見解を持つことです。私たちは、これらの条項を明確に述べることは、双方の関係者が進め方について情報に基づいた意思決定ができることを確実にするもっともよい方法であると思っています。

「市場がより良いセキュリティを要求するとき、商用ソフトのセキュリティは改善します。
最低限、あらゆるソフトウェア提案依頼書は、ベンダーに彼らがセキュリティ脆弱性に対して
生産物をテストする方法を詳述するよう依頼しなければなりません。このステップは、企業が
セキュリティを評価すると市販ソフトウェアのベンダーと外部調達された開発者を納得させ始めます。」
-- John Pescatore（Gartnerのリサーチ・ディレクター）として

私たちは、顧客と開発者が、期待について議論して、責任について交渉することに対するフレームワークとしてこの文書を使うよう勧めます。この付属書は、ソフトウェア開発契約に添付されることを目的とします。これらの条項は交渉の余地があります。そして、それらは顧客と開発者によって、協議されることができて、協議されなければならないことを意味します。

==プロジェクトについて==

この文書はOpen Web Application Security Project（OWASP）財団（セキュアなソフトウェアに関連した無料でオープンなツールとドキュメンテーションを作成することを専門とする非営利の慈善団体）によって作成されました。個人契約において容易に使用できるようにするために、この文書はCC Share Alike 3.0ライセンスにて提供されます。あなたが適すると思うように、修正してもよいですし、使用してもよいです。あなたは、http://www.owasp.com/index.php/OWASP_Legal_Project でこのプロジェクトについて更なる詳細を見つけることができます。私たちは、ソフトウェア（法律コミュニティだけでなく）の製作者と消費者のコメントを歓迎します。

OWASPは、この文書の研究と準備における彼らの役割に対して [http://www.aspectsecurity.com Aspect Security] から特別な貢献を感謝して認めます。

==異論==

以下のわずかなページは、ソフトウェア開発契約においてこの言い回しを使用することに対するいくらかのたびたび聞こえる異論をカバーします：

===しかし、すべての条項が私たちにとって適切であるというわけではありません…===

この文書は、あなたの合意の開始地点です。あなたは、すべての活動が好きではないかもしれません、または、より多くの提案をしたいかもしれません。あなたは異なる責任を割り当てたいかもしれません。この文書は、すべてのソフトウェア顧客と開発者の要望を厳密に取り込むことを意図しているわけではありません。ソフトウェアが最終的にセキュアになることを確実にするために重要である、主要な項目を議論するためのフレームワークを提供することを意図します。セキュリティを議論して合意を得た後で、あなたはこの合意を適合するように調整すべきです。

===しかし、これらの活動に対して誰が代金を払わなければならないのでしょうか===

この契約は、ソフトウェア開発者により多くの負担を与えることはほとんどありません。問題は、セキュリティ ― もちろんそこにある ― と関連したコストがあるかどうかということでありません。むしろ、適切な問題はどんな活動がそれらのコストを最小にするために双方によって実行されなければならないかということです、そして、いつ、それらは起こらなければなりませんか。

この付属書は、誰がここに記述される活動の料金を払わなければならないかという問題について、意図的に語られていません。これらの活動の多くがすでに起こらなければならなくて、多くの顧客によって期待される一方、彼らはソフトウェア産業で定期的に実践されません。誰が支払うか（そして、いくら）という問題が、交渉の一部でなければなりません。

セキュリティのコストを計算することは、非常に難しいです。セキュリティ活動を実行することに関連したコストがある一方、それらを無視することに関連したかなりのコストもあります。私たちは、ソフトウェアを開発する最も費用効果がよい方法がセキュリティ瑕疵が導入されるという可能性を減らして、瑕疵を導入して、それを修正することの間で時間を最小にすることであることを確信しています。

コストを計算するときにする一つの重要な区別は、セキュリティ手法を構築することと、それらの手法が正しくて効果的であることを確実にする保証活動の間にあります。ライフサイクルの終わりに手法を加えようとすることは、深刻な設計問題を引き起こすことがありえて、めざましくコストを増やします。この合意は、手法についての早い段階の決定がこれらのコストを最小にするのを奨励します。同様に、配備直前に保証活動（例えばコードレビューと侵入テスト）をするまで待つことはコストをめざましく増やします。私たちは、保証を得る最も費用効果がよい方法がライフサイクルを通して努力の一定のレベルを保証に入れることであると思っています。

===しかし厳密さのレベルは間違っている….===

この合意は、開発されているソフトウェアが大企業または政府機関にとってかなり重要であると仮定します。私たちは、大部分のソフトウェア開発組織によって達成できる合意のために「厳格さのレベル」を選んで、最も一般的なリスクを確認して、取り扱います。

しかし、重要なアプリケーション（例えば医学であるか、財政的であるか、防衛に関連したソフトウェア）で使われそうであるソフトウェアについては、あなたは厳格さのレベルを上げたいかもしれません。あなたは、追加のレビュー、文書とテストしている活動を加えたくてもよいです。あなたは、脆弱性を探すこと、診断すること、修正することに対するプロセスを強化しくてもよいです。より機密を扱わないアプリケーションのために、あなたは活動を減らすか、取り除きたくてもよいです。

===しかし私たちはそれほど多くのリスクをとることができない…===

この契約は、ソフトウェアにおけるセキュリティ脆弱性に対するリスクをとるのかという議論を容易にすることを目的とします。範囲の一端で、顧客はすべてのリスクをすることができました、そして、開発者はたくさんの脆弱性でコードを供給することができました。他の極端で、開発者はすべてのリスクをとることができて、完全なコードを供給することに対する責任を負うことができました。これらの極端の両方とも、実行不可能です。

現在、この契約において、開発者は要求においてカバーされたか、理にかなったテスト努力によってカバーされるべき問題に対するリスクをとります。しかし、「新しい」セキュリティ問題の改善は、顧客によって代金を払われるべきです。私たちは、これが開発者が彼らのリスクの境界となることができて役に立つバランスで、顧客が前もってセキュリティ要求を正しくするのを奨励すると思っています。しかし、この問題の多くの他の可能性がある解決が、あります。あなたには他の提案があるかどうか私たちに知らせます、そして、私たちは彼らをこの文書の将来の版に含めてもよいです。

ここでの議論がコードにおいてセキュリティ脆弱性を修正することに関連したリスクをカバーだけして、これらの脆弱性のあらゆるエクスプロイットに基づくあらゆるセキュリティ・インシデントから立ち直ることと関連したコストを含まないことに注意すべきです。私たちは、この領域におけるベスト・プラクティスに興味があります。

===私たちはどのように第三者のコードを保証するでしょうか===

ほとんどすべてのソフトウェアプロジェクトは、第三者のコード（例えばライブラリ、フレームワークと生産物）のかなりの量を使います。このコードは、ただセキュリティ観点から、カスタム・コードがあなたのプロジェクトのために特に発達したのと同じくらい重要です。
私たちはこのコードのセキュリティを確実にすることに対する責任が開発者によって負われて最もよいと思っています、しかし、彼らにはこのセキュリティを保証するために彼ら自身のいっぱいの能力がないかもしれません。しかし、セキュリティは「構築するか、買うか」議論の一部分でなければなりません、これはそれを促進する最もよい方法のようです。

開発者は、もちろん、終わりまで第三者のソフトウェアの提供者にこの責任をパスする選択権があります。開発者は彼ら自身第三者のコードを分析することもできるか、彼らのためにそれを分析するために、セキュリティの専門家を雇うこともできます。

===しかし、なぜ私はすべてのこのトラブルにいくべきなのでしょうか===

最後に、私たちはソフトウェアを契約しているプロセスの一部分をセキュリティをすることに代わるものがないと思っています。現在では、私たちは多くのソフトウェア開発契約のもとで供給されているコードのセキュリティに関する重大な誤解があると思っています。これは、わずかなソフトウェア経験または理解とともに個人によってなされる高価な訴訟と決定に至ることができるだけです。この問題の完全な議論に対して [[Secure software contracting hypothetical case study]] を読んでください。

多くの利点が、この契約を通してうまくいくことにあります。主要なものは、それが関係する関係者の間で期待を明らかにするということです。場合によっては、難しいセキュリティ問題がソフトウェアで表面化するとき、それは訴訟を妨げるのを助けます。また、これらは多くの法的で調整するコンプライアンスの理由によって必要とされる同じ活動です。

===しかし、このドキュメントですべてを作ることは難しい===

OWASPは、文書の目的のために文書を励ましません。この契約は、品質（量でない）を促すことに集中します。私たちは、短時間のリスク評価、数ページの要求、短いセキュリティ設計文書、テストプラン、いくつかのテスト結果とともに、この契約に応じることが（若干のプロジェクトにおいて）ありえると思っています。

この文書の目標は、ライフサイクルの各段階で、単に適切な注意がセキュリティに払われたことを確実とすることです。追加の利点は、この文書が基本的に、このソフトウェアが安心してそれがそれがすると主張することをするのをまかせられなければならない理由に対する議論を配置する「証明パッケージ」をつくるために一緒に集められることができるということです。

==契約付属書==

===1. 序文===

この付属書は、顧客と開発者の間で_____________________ ("合意") するために作られます。顧客と開発者は、以下の条件のよりソフトウェアのセキュリティを最大にすることに同意します。

===2. 原理===

この付属書は、ソフトウェア開発関係のすべての関係者のセキュリティ関連の権利と義務をはっきりさせることを目的とします。最高水準で、関係者は以下に同意します

;(a) セキュリティ決定は、リスクに基づきます : セキュリティについての決定は、関係するリスクのしっかりした理解に基づく顧客と開発者によって共同でなされす。

;(b) セキュリティ活動はバランスが保たれます : セキュリティ努力は、全てのソフトウェア開発ライフサイクル全体でおおよそ均一に配布されます。

;(c) セキュリティ活動は統合されます : ここに協議されるすべての活動と文書は、開発者のソフトウェア開発ライフサイクルに統合されて、残りのプロジェクトと別にしておかれるというわけではありません。この付属書の何も、どんな特定のソフトウェア開発プロセスを意味しません。

;(d) 脆弱性は予想されます : すべてのソフトウェアにはバグがあります、そして、それらのいくらかはセキュリティ問題を生じさせます。顧客と開発者は、ライフサイクルにおいてできるだけ早く脆弱性を特定するよう努めます。

;(e) セキュリティ情報は、完全に明らかにされます : すべてのセキュリティ関連した情報は、すぐに、そして、完全に、顧客と開発者で共有されます。

;(f) 役に立つセキュリティ文書だけが必要とされます : セキュリティ文書は、セキュリティ設計、リスク分析または問題を明確に記述するために詳細にわたる必要はありません。

===3.ライフサイクル活動===

;(a) リスク識別 : 開発者とClientは、アプリケーションに直面しているリスクを理解して、文書化するために一緒に働くことに同意します。この努力は、アプリケーションにより提供される重要な資産と機能に主要なリスクを確認しなければなりません。要件部にリストされるトピックの各々は、考慮されなければなりません。

;(b) 要求 : リスクに基づいて、開発者と顧客は、開発されるソフトウェアの仕様の一部として詳細なセキュリティ要件を確立するために一緒に働くことに同意します。この付属書の要件部分で記載されるトピックの各々は、開発者と顧客によって協議されなければならなくて、評価されなければなりません。これらの要件は、カスタム・ソフト、第三者のソフトウェアまたはプラットホームによって満たされてもよいです。

;(c) 設計 : 開発者は、セキュリティ要件の各々を達成するために明確に設計を説明する文書を提供することに同意します。ほとんどの場合、この文書はセキュリティ手法を記載します、そこで、手法はアーキテクチャに適合しました、そして、関連したすべては彼らの適正使用を確実にするためにパターンを設計します。設計は、サポートがカスタム・ソフトか、第三者のソフトウェアかプラットホームから来るかどうか、明確に指定しなければなりません。

;(d) 実装 : 開発者は、一組のセキュアなコーディング指針に提供することに、従って、一組の共通セキュリティ制御プログラミング・インターフェース（例えば [http://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API OWASP Enterprise Security API（ESAPI）] ）を使って同意します。ガイドラインは、コードがどのようにフォーマットされなければならなくて、構築されなければならなくて、コメントされなければならないかについて示します。共通セキュリティ制御プログラミング・インターフェースは、セキュリティ制御がどのように呼ばれなければならないか、そして、セキュリティ制御がどのように機能するか定めます。すべてのセキュリティに関連したコードは、完全にコメントされます。共通のセキュリティ脆弱性を回避するときの具体的なガイダンスは、含まれなければなりません。また、すべてのコードはセキュリティ要件に対して少なくとも他の一人の開発者によってレビューされなければなりません、そして、それの前のコーディング・ガイドラインは単体テストの準備ができていると思われます。

;(e) セキュリティ分析とテスト : 開発者は、（ [http://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project OWASP Application Security Verification Standard (ASVS)] のような）合意された標準の検証要件により、アプリケーション・セキュリティ分析とテスト（「検証」とも言われる）を実行します。開発者は、標準の報告要件によって検証結論を文書化しなければなりません。開発者は、検証結論を顧客に提供しなければなりません。

;(f) セキュリティ配備 : 開発者は、ソフトウェアの全体的なセキュリティのために完全にすべてのセキュリティ関連した構成オプションとそれらの関連性を記述するセキュアな構成ガイドラインを提供することに同意します。ガイドラインは、オペレーティングシステム、ウェブサーバとアプリケーション・サーバーを含むサポート的なプラットホームにおける依存関係の完全な記述を含まなければいけません。また、どのようにそれらをセキュリティのために構成されるべきかを含まなければいけません。ソフトウェアのデフォルトコンフィグレーションは、セキュアでなければなりません。

===4.セキュリティ要求エリア===

以下のトピック領域は、リスク理解と要求定義活動の間、考慮されなければなりません。この努力は一組の具体的で、注文仕立てで、分析できる要求を生産しなければなりません。そして、開発者と顧客はこのプロセスに関与していなければならなくて、要求の最終セットについて同意しなければなりません。

;(a) 入力検証とエンコーディング : 要求は、ユーザー、ファイルシステム、データベース、ディレクトリまたは外部システムからであるかどうかにかかわらず、アプリケーションへの各々の入力を標準化し、検証し、コード化するためにルールを指定しなければなりません。　　　デフォルトルールは、それが何が許可されるかという詳細な仕様にマッチしない限り、すべての入力が無効であるということでなければなりません。そのうえ、無効な入力が受け取られるとき、要求はとられる措置を指定しなければなりません。具体的には、アプリケーションはインジェクション、オーバフロー、不正操作することまたは他の不正な入力攻撃に影響されやすくてはいけません。

;(b) 認証とセッション管理 : 要求は、認証証明書とセッション識別子がどのようにそれらのライフサイクルを通して保護されているかについて明記しなければなりません。すべての関連する機能（パスワード忘却、パスワード変更、パスワードリマインダ、ログアウト、そして複数ログインを含む）に対する要求は含められなければいけません。

;(c) アクセス制御 : 要求は、アプリケーションで使われるすべての役割（グループ、特権、認可）の詳細な記述を含まなければなりません。要求は、アプリケーションにより提供されるすべての資産と機能も示さなければなりません。要求は、完全に各々の資産に正確なアクセス権を指定しなければならなくて、各々の役割に対して機能しなければなりません。アクセス制御マトリックスは、これらのルールのための提案されたフォーマットです。

;(d) エラー処理 : 要求は、処理の間、発生しているエラーが取り扱われる方法を詳述しなければなりません。若干のアプリケーションはエラーの場合には最もよい努力結果を提供しなければなりません、一方、他はすぐに処理を終了しなければなりません。

;(e) ロギング : 要求は、どんなイベントがセキュリティに関連して、記録される必要があるか、たとえば、検知された攻撃、失敗したログイン試行、認可を上回ろうとする試行、を指定しなければなりません。要求は、時間と日付、イベント記述、アプリケーション詳細とフォレンジクス努力に役立つ他の情報を含む、各々のイベントでどんな情報を記録するべきかについても指定しなければなりません。

;(f) 外部システムへの接続 : 要求は、認証と暗号化がどのようにすべての外部システム（例えばデータベース、ディレクトリとウェブ・サービス）のために取り扱われるかについて指定しなければなりません。外部システムでコミュニケーションのために必要とされるすべてのクレディンシャルは、暗号化された形で構成ファイルでコードの外側に保存されなければなりません。

;(g) 暗号 : 要求は、どんなデータが暗号化されなければならないか、暗号化されることがどれほどか、そして、すべての証明書と他のクレディンシャルがどのように取り扱われなければならないか指定しなければなりません。アプリケーションは、広く使われていてテストされた暗号化ライブラリで実装される標準的なアルゴリズムを使用しなければなりません。

;(h) 可用性 : 要求は、それがどのようにサービス不能攻撃から保護するかについて指定しなければなりません。アプリケーションへのすべてのありそうな攻撃は考慮されなければなりません。そして、認証ロックアウト、接続消耗と他の資源消耗攻撃を含みます。

;(i) セキュアな設定 : 要求は、すべてのセキュリティに関連した構成オプションに対するデフォルト値がセキュアでなければならないことを示していなければなりません。監査目的のために、ソフトウェアはすべてのセキュリティに関連した構成詳細を示している簡単に読めるレポートをつくることができなければなりません。

;(j) 特定の脆弱性 : 要求は、ソフトウェアで見つかってはならない一組の具体的な脆弱性を含まなければなりません。指定されていないならば、ソフトウェアは現在の「OWASP Top Ten Most Critical Web Application Vulnerabilities」で記述される瑕疵の何も含んではいけません。

===5. 要員および組織===

;(a) セキュリティ・アーキテクト : 開発者は一つの上位の技術的な資源に責任をセキュリティに指定します。そして、プロジェクトのセキュリティ・アーキテクトとして知られています。セキュリティ・アーキテクトは、各々の納品可能なもののセキュリティを保証します。

;(b) セキュリティ・トレーニング : 開発者は、開発者チームのすべてのメンバーがセキュアなプログラミング技法の訓練をされたことを確かめる役割を果たします。

;(c) 信用できる開発者 : 開発者は、すべての開発チーム・メンバーの適切な経歴調査を実行することに同意します。

===6.開発環境===

;(a) セキュア・コーディング : 開発者は、どんなツールがセキュアなコーディングを促すためにソフトウェア開発環境で使われるかについて明らかにしなければなりません。

;(b) 構成管理 : 開発者は、ソフトウェア・ベースラインに対するすべての変更とすべての関連した設定とビルド・ファイルを関連づけ　とすべての関連した構成にすべての変化と関連したチーム・メンバーを認証して、記録して、ファイルを構築したソース・コード管理システムを使用しなければなりません。

;(c) 配布 : 開発者は、ソースから確実に完全な配布を構築するビルド・プロセスを使用しなければなりません。このプロセスは、顧客に供給されるソフトウェアの完全性を確かめる方法を含まなければなりません。

===7. ライブラリ、フレームワーク、および生産物===

;(a) 開示 : 開発者は、商用、フリー、オープンソース、クローズソースであるにせよ、すべてのライブラリ、フレームワーク、構成要素と他の生産物を含む、ソフトウェアで使われるすべての第三者のソフトウェアを明らかにしなければなりません。

;(b) 評価 : 開発者は、第三者のソフトウェアがこの契約のすべての条件を満たして、この契約の基で開発されたカスタム開発されたコードと同じくらいセキュアなことを確実とするために、理にかなった努力をしなければなりません。

===8. セキュリティ・レビュー===

;(a) レビューする権利 : 依頼人には、ソフトウェアを納品の60日間以内にいつでも彼らの費用でセキュリティ瑕疵のためにレビューしておく権利があります。開発者は、ソース・コードとテスト環境へのアクセスを提供することによって理にかなったサポートをレビュー・チームに提供することに同意します。

;(b) レビュー・カバレッジ : セキュリティ・レビューは供給されるソフトウェアのすべての面をカバーしなければなりません。そして、カスタム・コード、構成要素、生産物とシステム設定を含みます。

;(c) レビューの範囲 : 最低限で、レビューはセキュリティ要求の全てをカバーしなければならなくて、他の一般的な脆弱性を捜さなければなりません。レビューは、脆弱性スキャン、侵入テスト、ソースコードの静的分析と専門家のコードレビューの組み合わせを含んでもよいです。

;(d) 見つけられた問題 : 発見されたセキュリティ問題は、顧客と開発者に報告されます。すべての問題は、この付属書のセキュリティ問題マネジメント部分により追跡されて、矯正されます。

===9. セキュリティ問題マネジメント ===

;(a) 識別 : 要求、設計、実装、テスト、配備、または、運用中の問題にせよ、開発者は全てのライフサイクルの間に発見されるすべてのセキュリティ問題を追います。各々のセキュリティ問題に関連したリスクは、発見後できるだけ早く、評価されて、文書化されて、発見の後、顧客に報告されます。

;(b) 保護 : 開発者はセキュリティ問題と付随する文書に関して情報を適切に保護します。そして、運用中の顧客ソフトウェアの脆弱性が露出するという可能性を制限するのを助けます。

;(c) 改善 : 納品の前に確認されるセキュリティ問題は、開発者によって修正されなければなりません。納品の後に発見されるセキュリティ問題は、本契約の規定による他のバグと問題として同様に取り扱われなければなりません。

===10. 保証===

;(a) 保証 : 開発者は、開発プロセスを通して作成されるセキュリティ文書からなる「証明パッケージ」を提供します。パッケージは、セキュリティ要求、設計、実装と試験結果がきちんと完了された、そして、すべてのセキュリティ問題が適切に解決されたと確認しなければなりません。

;(b) 自己証明 : セキュリティ・アーキテクトは、ソフトウェアがセキュリティ要求を満たすこと、すべてのセキュリティ活動が実行されていること、そして、すべての識別されたセキュリティ問題が文書化されて、解決されたことを証明します。証明ステータスに対するあらゆる例外は、納品で完全に文書化されなければなりません。

;(c) 悪意のあるコードのなし : 開発者は、ソフトウェアがソフトウェア要求をサポートせず、コンピュータ・ウイルス、ワーム、時限爆弾、バック・ドア、トロイの木馬、イースターエッグと他のあらゆる形の悪意のあるソフトウェアを含む、アプリケーションのセキュリティを弱めるあらゆるコードを含んではならないと保証します。

===11. セキュリティ承認と保守 ===

;(a) 受け入れ : 証明パッケージが完全であり、すべてのセキュリティ問題が解決されるまで、ソフトウェアは受け入れられると考慮されてはいけません。

;(b) セキュリティ問題の調査 : 受理の後、セキュリティ問題が発見されるか、かなり疑われるならば、開発者は顧客が問題の性質を決定するために調査を実行するのを援助しなければなりません。それがセキュリティ要求によってカバーされないで、セキュリティ・テストの理にかなった範囲の外にあるならば、問題は「新しい」と思われなければなりません。

;(c) 新しいセキュリティ問題 : 開発者と顧客は、新しいセキュリティ問題を解決するために必要な努力を探し出すことに同意します。また、それらに取り組むために必要とされる仕事を実行するための合意を達成するために誠意を持って交渉することに同意します。

;(d) 他のセキュリティ問題 : 開発者は堅実なソフトウェア開発慣行。そして、リスクのひどさを考慮すること、そして、できるだけ速く新しいと思われないすべてのセキュリティ問題を解決することと一致したすべての商業的に理にかなった努力を使わなければなりません

[[Category:OWASP Legal Project]]

__NOTOC__

OWASP Secure Software Contract Annex/ja

2011-07-05T00:18:31Z

Tomo: /* プロジェクトについて */

'''セキュア・ソフトウェア開発契約付属書'''

警告：この文書は、単にガイダンスと考えられなければなりません。
OWASPは、ソフトウェア契約を交渉するのを手助けするために、
あなたが資格のある弁護士に相談するよう強く勧めます。

==序文==

OWASPセキュア・ソフトウェア開発契約付属書は、ソフトウェアの開発者とその顧客が、開発または供給されるソフトウェアのセキュリティに関連した重要な契約条項と条件を交渉し、取り込むことを助けます。このプロジェクトの理由は、多くの契約はこれらの問題に触れておらず、しばしば関係者が実際に同意されたものに劇的に異なる見解を持つことです。私たちは、これらの条項を明確に述べることは、双方の関係者が進め方について情報に基づいた意思決定ができることを確実にするもっともよい方法であると思っています。

「市場がより良いセキュリティを要求するとき、商用ソフトのセキュリティは改善します。
最低限、あらゆるソフトウェア提案依頼書は、ベンダーに彼らがセキュリティ脆弱性に対して
生産物をテストする方法を詳述するよう依頼しなければなりません。このステップは、企業が
セキュリティを評価すると市販ソフトウェアのベンダーと外部調達された開発者を納得させ始めます。」
-- John Pescatore（Gartnerのリサーチ・ディレクター）として

私たちは、顧客と開発者が、期待について議論して、責任について交渉することに対するフレームワークとしてこの文書を使うよう勧めます。この付属書は、ソフトウェア開発契約に添付されることを目的とします。これらの条項は交渉の余地があります。そして、それらは顧客と開発者によって、協議されることができて、協議されなければならないことを意味します。

==プロジェクトについて==

この文書はOpen Web Application Security Project（OWASP）財団（セキュアなソフトウェアに関連した無料でオープンなツールとドキュメンテーションを作成することを専門とする非営利の慈善団体）によって作成されました。個人契約において容易に使用できるようにするために、この文書はCC Share Alike 3.0ライセンスにて提供されます。あなたが適すると思うように、修正してもよいですし、使用してもよいです。あなたは、http://www.owasp.com/index.php/OWASP_Legal_Project でこのプロジェクトについて更なる詳細を見つけることができます。私たちは、ソフトウェア（法律コミュニティだけでなく）の製作者と消費者のコメントを歓迎します。

OWASPは、この文書の研究と準備における彼らの役割に対して [http://www.aspectsecurity.com Aspect Security] から特別な貢献を感謝して認めます。

==異論==

以下のわずかなページは、ソフトウェア開発契約においてこの言い回しを使用することに対するいくらかのたびたび聞こえる異論をカバーします：

===しかし、すべての条件が私たちに対して適切であるというわけではありません…===

この文書は、あなたの合意の出発点と考えられなければなりません。あなたはすべての活動が好きでなくてもよいですが、より提案したくてもよいです。あなたは、違って責任を割り当てたくてもよいです。この文書は、必ずしもすべてのソフトウェア顧客と開発者のニーズを捕えることを目的としません。ソフトウェアがセキュアに終わることを確実とすることにとって重要である主要な話題を議論するためのフレームワークを提供することを目的とします。あなたがセキュリティ議論をして、合意に達したあと、あなたは合致するためにこの合意を手直ししなければなりません。

===しかし、これらの活動に対して誰が代金を払わなければならないのでしょうか===

この契約は、ソフトウェア開発者により多くの負担を与えることはほとんどありません。問題は、セキュリティ ― もちろんそこにある ― と関連したコストがあるかどうかということでありません。むしろ、適切な問題はどんな活動がそれらのコストを最小にするために双方によって実行されなければならないかということです、そして、いつ、それらは起こらなければなりませんか。

この付属書は、誰がここに記述される活動の料金を払わなければならないかという問題について、意図的に語られていません。これらの活動の多くがすでに起こらなければならなくて、多くの顧客によって期待される一方、彼らはソフトウェア産業で定期的に実践されません。誰が支払うか（そして、いくら）という問題が、交渉の一部でなければなりません。

セキュリティのコストを計算することは、非常に難しいです。セキュリティ活動を実行することに関連したコストがある一方、それらを無視することに関連したかなりのコストもあります。私たちは、ソフトウェアを開発する最も費用効果がよい方法がセキュリティ瑕疵が導入されるという可能性を減らして、瑕疵を導入して、それを修正することの間で時間を最小にすることであることを確信しています。

コストを計算するときにする一つの重要な区別は、セキュリティ手法を構築することと、それらの手法が正しくて効果的であることを確実にする保証活動の間にあります。ライフサイクルの終わりに手法を加えようとすることは、深刻な設計問題を引き起こすことがありえて、めざましくコストを増やします。この合意は、手法についての早い段階の決定がこれらのコストを最小にするのを奨励します。同様に、配備直前に保証活動（例えばコードレビューと侵入テスト）をするまで待つことはコストをめざましく増やします。私たちは、保証を得る最も費用効果がよい方法がライフサイクルを通して努力の一定のレベルを保証に入れることであると思っています。

===しかし厳密さのレベルは間違っている….===

この合意は、開発されているソフトウェアが大企業または政府機関にとってかなり重要であると仮定します。私たちは、大部分のソフトウェア開発組織によって達成できる合意のために「厳格さのレベル」を選んで、最も一般的なリスクを確認して、取り扱います。

しかし、重要なアプリケーション（例えば医学であるか、財政的であるか、防衛に関連したソフトウェア）で使われそうであるソフトウェアについては、あなたは厳格さのレベルを上げたいかもしれません。あなたは、追加のレビュー、文書とテストしている活動を加えたくてもよいです。あなたは、脆弱性を探すこと、診断すること、修正することに対するプロセスを強化しくてもよいです。より機密を扱わないアプリケーションのために、あなたは活動を減らすか、取り除きたくてもよいです。

===しかし私たちはそれほど多くのリスクをとることができない…===

この契約は、ソフトウェアにおけるセキュリティ脆弱性に対するリスクをとるのかという議論を容易にすることを目的とします。範囲の一端で、顧客はすべてのリスクをすることができました、そして、開発者はたくさんの脆弱性でコードを供給することができました。他の極端で、開発者はすべてのリスクをとることができて、完全なコードを供給することに対する責任を負うことができました。これらの極端の両方とも、実行不可能です。

現在、この契約において、開発者は要求においてカバーされたか、理にかなったテスト努力によってカバーされるべき問題に対するリスクをとります。しかし、「新しい」セキュリティ問題の改善は、顧客によって代金を払われるべきです。私たちは、これが開発者が彼らのリスクの境界となることができて役に立つバランスで、顧客が前もってセキュリティ要求を正しくするのを奨励すると思っています。しかし、この問題の多くの他の可能性がある解決が、あります。あなたには他の提案があるかどうか私たちに知らせます、そして、私たちは彼らをこの文書の将来の版に含めてもよいです。

ここでの議論がコードにおいてセキュリティ脆弱性を修正することに関連したリスクをカバーだけして、これらの脆弱性のあらゆるエクスプロイットに基づくあらゆるセキュリティ・インシデントから立ち直ることと関連したコストを含まないことに注意すべきです。私たちは、この領域におけるベスト・プラクティスに興味があります。

===私たちはどのように第三者のコードを保証するでしょうか===

ほとんどすべてのソフトウェアプロジェクトは、第三者のコード（例えばライブラリ、フレームワークと生産物）のかなりの量を使います。このコードは、ただセキュリティ観点から、カスタム・コードがあなたのプロジェクトのために特に発達したのと同じくらい重要です。
私たちはこのコードのセキュリティを確実にすることに対する責任が開発者によって負われて最もよいと思っています、しかし、彼らにはこのセキュリティを保証するために彼ら自身のいっぱいの能力がないかもしれません。しかし、セキュリティは「構築するか、買うか」議論の一部分でなければなりません、これはそれを促進する最もよい方法のようです。

開発者は、もちろん、終わりまで第三者のソフトウェアの提供者にこの責任をパスする選択権があります。開発者は彼ら自身第三者のコードを分析することもできるか、彼らのためにそれを分析するために、セキュリティの専門家を雇うこともできます。

===しかし、なぜ私はすべてのこのトラブルにいくべきなのでしょうか===

最後に、私たちはソフトウェアを契約しているプロセスの一部分をセキュリティをすることに代わるものがないと思っています。現在では、私たちは多くのソフトウェア開発契約のもとで供給されているコードのセキュリティに関する重大な誤解があると思っています。これは、わずかなソフトウェア経験または理解とともに個人によってなされる高価な訴訟と決定に至ることができるだけです。この問題の完全な議論に対して [[Secure software contracting hypothetical case study]] を読んでください。

多くの利点が、この契約を通してうまくいくことにあります。主要なものは、それが関係する関係者の間で期待を明らかにするということです。場合によっては、難しいセキュリティ問題がソフトウェアで表面化するとき、それは訴訟を妨げるのを助けます。また、これらは多くの法的で調整するコンプライアンスの理由によって必要とされる同じ活動です。

===しかし、このドキュメントですべてを作ることは難しい===

OWASPは、文書の目的のために文書を励ましません。この契約は、品質（量でない）を促すことに集中します。私たちは、短時間のリスク評価、数ページの要求、短いセキュリティ設計文書、テストプラン、いくつかのテスト結果とともに、この契約に応じることが（若干のプロジェクトにおいて）ありえると思っています。

この文書の目標は、ライフサイクルの各段階で、単に適切な注意がセキュリティに払われたことを確実とすることです。追加の利点は、この文書が基本的に、このソフトウェアが安心してそれがそれがすると主張することをするのをまかせられなければならない理由に対する議論を配置する「証明パッケージ」をつくるために一緒に集められることができるということです。

==契約付属書==

===1. 序文===

この付属書は、顧客と開発者の間で_____________________ ("合意") するために作られます。顧客と開発者は、以下の条件のよりソフトウェアのセキュリティを最大にすることに同意します。

===2. 原理===

この付属書は、ソフトウェア開発関係のすべての関係者のセキュリティ関連の権利と義務をはっきりさせることを目的とします。最高水準で、関係者は以下に同意します

;(a) セキュリティ決定は、リスクに基づきます : セキュリティについての決定は、関係するリスクのしっかりした理解に基づく顧客と開発者によって共同でなされす。

;(b) セキュリティ活動はバランスが保たれます : セキュリティ努力は、全てのソフトウェア開発ライフサイクル全体でおおよそ均一に配布されます。

;(c) セキュリティ活動は統合されます : ここに協議されるすべての活動と文書は、開発者のソフトウェア開発ライフサイクルに統合されて、残りのプロジェクトと別にしておかれるというわけではありません。この付属書の何も、どんな特定のソフトウェア開発プロセスを意味しません。

;(d) 脆弱性は予想されます : すべてのソフトウェアにはバグがあります、そして、それらのいくらかはセキュリティ問題を生じさせます。顧客と開発者は、ライフサイクルにおいてできるだけ早く脆弱性を特定するよう努めます。

;(e) セキュリティ情報は、完全に明らかにされます : すべてのセキュリティ関連した情報は、すぐに、そして、完全に、顧客と開発者で共有されます。

;(f) 役に立つセキュリティ文書だけが必要とされます : セキュリティ文書は、セキュリティ設計、リスク分析または問題を明確に記述するために詳細にわたる必要はありません。

===3.ライフサイクル活動===

;(a) リスク識別 : 開発者とClientは、アプリケーションに直面しているリスクを理解して、文書化するために一緒に働くことに同意します。この努力は、アプリケーションにより提供される重要な資産と機能に主要なリスクを確認しなければなりません。要件部にリストされるトピックの各々は、考慮されなければなりません。

;(b) 要求 : リスクに基づいて、開発者と顧客は、開発されるソフトウェアの仕様の一部として詳細なセキュリティ要件を確立するために一緒に働くことに同意します。この付属書の要件部分で記載されるトピックの各々は、開発者と顧客によって協議されなければならなくて、評価されなければなりません。これらの要件は、カスタム・ソフト、第三者のソフトウェアまたはプラットホームによって満たされてもよいです。

;(c) 設計 : 開発者は、セキュリティ要件の各々を達成するために明確に設計を説明する文書を提供することに同意します。ほとんどの場合、この文書はセキュリティ手法を記載します、そこで、手法はアーキテクチャに適合しました、そして、関連したすべては彼らの適正使用を確実にするためにパターンを設計します。設計は、サポートがカスタム・ソフトか、第三者のソフトウェアかプラットホームから来るかどうか、明確に指定しなければなりません。

;(d) 実装 : 開発者は、一組のセキュアなコーディング指針に提供することに、従って、一組の共通セキュリティ制御プログラミング・インターフェース（例えば [http://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API OWASP Enterprise Security API（ESAPI）] ）を使って同意します。ガイドラインは、コードがどのようにフォーマットされなければならなくて、構築されなければならなくて、コメントされなければならないかについて示します。共通セキュリティ制御プログラミング・インターフェースは、セキュリティ制御がどのように呼ばれなければならないか、そして、セキュリティ制御がどのように機能するか定めます。すべてのセキュリティに関連したコードは、完全にコメントされます。共通のセキュリティ脆弱性を回避するときの具体的なガイダンスは、含まれなければなりません。また、すべてのコードはセキュリティ要件に対して少なくとも他の一人の開発者によってレビューされなければなりません、そして、それの前のコーディング・ガイドラインは単体テストの準備ができていると思われます。

;(e) セキュリティ分析とテスト : 開発者は、（ [http://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project OWASP Application Security Verification Standard (ASVS)] のような）合意された標準の検証要件により、アプリケーション・セキュリティ分析とテスト（「検証」とも言われる）を実行します。開発者は、標準の報告要件によって検証結論を文書化しなければなりません。開発者は、検証結論を顧客に提供しなければなりません。

;(f) セキュリティ配備 : 開発者は、ソフトウェアの全体的なセキュリティのために完全にすべてのセキュリティ関連した構成オプションとそれらの関連性を記述するセキュアな構成ガイドラインを提供することに同意します。ガイドラインは、オペレーティングシステム、ウェブサーバとアプリケーション・サーバーを含むサポート的なプラットホームにおける依存関係の完全な記述を含まなければいけません。また、どのようにそれらをセキュリティのために構成されるべきかを含まなければいけません。ソフトウェアのデフォルトコンフィグレーションは、セキュアでなければなりません。

===4.セキュリティ要求エリア===

以下のトピック領域は、リスク理解と要求定義活動の間、考慮されなければなりません。この努力は一組の具体的で、注文仕立てで、分析できる要求を生産しなければなりません。そして、開発者と顧客はこのプロセスに関与していなければならなくて、要求の最終セットについて同意しなければなりません。

;(a) 入力検証とエンコーディング : 要求は、ユーザー、ファイルシステム、データベース、ディレクトリまたは外部システムからであるかどうかにかかわらず、アプリケーションへの各々の入力を標準化し、検証し、コード化するためにルールを指定しなければなりません。　　　デフォルトルールは、それが何が許可されるかという詳細な仕様にマッチしない限り、すべての入力が無効であるということでなければなりません。そのうえ、無効な入力が受け取られるとき、要求はとられる措置を指定しなければなりません。具体的には、アプリケーションはインジェクション、オーバフロー、不正操作することまたは他の不正な入力攻撃に影響されやすくてはいけません。

;(b) 認証とセッション管理 : 要求は、認証証明書とセッション識別子がどのようにそれらのライフサイクルを通して保護されているかについて明記しなければなりません。すべての関連する機能（パスワード忘却、パスワード変更、パスワードリマインダ、ログアウト、そして複数ログインを含む）に対する要求は含められなければいけません。

;(c) アクセス制御 : 要求は、アプリケーションで使われるすべての役割（グループ、特権、認可）の詳細な記述を含まなければなりません。要求は、アプリケーションにより提供されるすべての資産と機能も示さなければなりません。要求は、完全に各々の資産に正確なアクセス権を指定しなければならなくて、各々の役割に対して機能しなければなりません。アクセス制御マトリックスは、これらのルールのための提案されたフォーマットです。

;(d) エラー処理 : 要求は、処理の間、発生しているエラーが取り扱われる方法を詳述しなければなりません。若干のアプリケーションはエラーの場合には最もよい努力結果を提供しなければなりません、一方、他はすぐに処理を終了しなければなりません。

;(e) ロギング : 要求は、どんなイベントがセキュリティに関連して、記録される必要があるか、たとえば、検知された攻撃、失敗したログイン試行、認可を上回ろうとする試行、を指定しなければなりません。要求は、時間と日付、イベント記述、アプリケーション詳細とフォレンジクス努力に役立つ他の情報を含む、各々のイベントでどんな情報を記録するべきかについても指定しなければなりません。

;(f) 外部システムへの接続 : 要求は、認証と暗号化がどのようにすべての外部システム（例えばデータベース、ディレクトリとウェブ・サービス）のために取り扱われるかについて指定しなければなりません。外部システムでコミュニケーションのために必要とされるすべてのクレディンシャルは、暗号化された形で構成ファイルでコードの外側に保存されなければなりません。

;(g) 暗号 : 要求は、どんなデータが暗号化されなければならないか、暗号化されることがどれほどか、そして、すべての証明書と他のクレディンシャルがどのように取り扱われなければならないか指定しなければなりません。アプリケーションは、広く使われていてテストされた暗号化ライブラリで実装される標準的なアルゴリズムを使用しなければなりません。

;(h) 可用性 : 要求は、それがどのようにサービス不能攻撃から保護するかについて指定しなければなりません。アプリケーションへのすべてのありそうな攻撃は考慮されなければなりません。そして、認証ロックアウト、接続消耗と他の資源消耗攻撃を含みます。

;(i) セキュアな設定 : 要求は、すべてのセキュリティに関連した構成オプションに対するデフォルト値がセキュアでなければならないことを示していなければなりません。監査目的のために、ソフトウェアはすべてのセキュリティに関連した構成詳細を示している簡単に読めるレポートをつくることができなければなりません。

;(j) 特定の脆弱性 : 要求は、ソフトウェアで見つかってはならない一組の具体的な脆弱性を含まなければなりません。指定されていないならば、ソフトウェアは現在の「OWASP Top Ten Most Critical Web Application Vulnerabilities」で記述される瑕疵の何も含んではいけません。

===5. 要員および組織===

;(a) セキュリティ・アーキテクト : 開発者は一つの上位の技術的な資源に責任をセキュリティに指定します。そして、プロジェクトのセキュリティ・アーキテクトとして知られています。セキュリティ・アーキテクトは、各々の納品可能なもののセキュリティを保証します。

;(b) セキュリティ・トレーニング : 開発者は、開発者チームのすべてのメンバーがセキュアなプログラミング技法の訓練をされたことを確かめる役割を果たします。

;(c) 信用できる開発者 : 開発者は、すべての開発チーム・メンバーの適切な経歴調査を実行することに同意します。

===6.開発環境===

;(a) セキュア・コーディング : 開発者は、どんなツールがセキュアなコーディングを促すためにソフトウェア開発環境で使われるかについて明らかにしなければなりません。

;(b) 構成管理 : 開発者は、ソフトウェア・ベースラインに対するすべての変更とすべての関連した設定とビルド・ファイルを関連づけ　とすべての関連した構成にすべての変化と関連したチーム・メンバーを認証して、記録して、ファイルを構築したソース・コード管理システムを使用しなければなりません。

;(c) 配布 : 開発者は、ソースから確実に完全な配布を構築するビルド・プロセスを使用しなければなりません。このプロセスは、顧客に供給されるソフトウェアの完全性を確かめる方法を含まなければなりません。

===7. ライブラリ、フレームワーク、および生産物===

;(a) 開示 : 開発者は、商用、フリー、オープンソース、クローズソースであるにせよ、すべてのライブラリ、フレームワーク、構成要素と他の生産物を含む、ソフトウェアで使われるすべての第三者のソフトウェアを明らかにしなければなりません。

;(b) 評価 : 開発者は、第三者のソフトウェアがこの契約のすべての条件を満たして、この契約の基で開発されたカスタム開発されたコードと同じくらいセキュアなことを確実とするために、理にかなった努力をしなければなりません。

===8. セキュリティ・レビュー===

;(a) レビューする権利 : 依頼人には、ソフトウェアを納品の60日間以内にいつでも彼らの費用でセキュリティ瑕疵のためにレビューしておく権利があります。開発者は、ソース・コードとテスト環境へのアクセスを提供することによって理にかなったサポートをレビュー・チームに提供することに同意します。

;(b) レビュー・カバレッジ : セキュリティ・レビューは供給されるソフトウェアのすべての面をカバーしなければなりません。そして、カスタム・コード、構成要素、生産物とシステム設定を含みます。

;(c) レビューの範囲 : 最低限で、レビューはセキュリティ要求の全てをカバーしなければならなくて、他の一般的な脆弱性を捜さなければなりません。レビューは、脆弱性スキャン、侵入テスト、ソースコードの静的分析と専門家のコードレビューの組み合わせを含んでもよいです。

;(d) 見つけられた問題 : 発見されたセキュリティ問題は、顧客と開発者に報告されます。すべての問題は、この付属書のセキュリティ問題マネジメント部分により追跡されて、矯正されます。

===9. セキュリティ問題マネジメント ===

;(a) 識別 : 要求、設計、実装、テスト、配備、または、運用中の問題にせよ、開発者は全てのライフサイクルの間に発見されるすべてのセキュリティ問題を追います。各々のセキュリティ問題に関連したリスクは、発見後できるだけ早く、評価されて、文書化されて、発見の後、顧客に報告されます。

;(b) 保護 : 開発者はセキュリティ問題と付随する文書に関して情報を適切に保護します。そして、運用中の顧客ソフトウェアの脆弱性が露出するという可能性を制限するのを助けます。

;(c) 改善 : 納品の前に確認されるセキュリティ問題は、開発者によって修正されなければなりません。納品の後に発見されるセキュリティ問題は、本契約の規定による他のバグと問題として同様に取り扱われなければなりません。

===10. 保証===

;(a) 保証 : 開発者は、開発プロセスを通して作成されるセキュリティ文書からなる「証明パッケージ」を提供します。パッケージは、セキュリティ要求、設計、実装と試験結果がきちんと完了された、そして、すべてのセキュリティ問題が適切に解決されたと確認しなければなりません。

;(b) 自己証明 : セキュリティ・アーキテクトは、ソフトウェアがセキュリティ要求を満たすこと、すべてのセキュリティ活動が実行されていること、そして、すべての識別されたセキュリティ問題が文書化されて、解決されたことを証明します。証明ステータスに対するあらゆる例外は、納品で完全に文書化されなければなりません。

;(c) 悪意のあるコードのなし : 開発者は、ソフトウェアがソフトウェア要求をサポートせず、コンピュータ・ウイルス、ワーム、時限爆弾、バック・ドア、トロイの木馬、イースターエッグと他のあらゆる形の悪意のあるソフトウェアを含む、アプリケーションのセキュリティを弱めるあらゆるコードを含んではならないと保証します。

===11. セキュリティ承認と保守 ===

;(a) 受け入れ : 証明パッケージが完全であり、すべてのセキュリティ問題が解決されるまで、ソフトウェアは受け入れられると考慮されてはいけません。

;(b) セキュリティ問題の調査 : 受理の後、セキュリティ問題が発見されるか、かなり疑われるならば、開発者は顧客が問題の性質を決定するために調査を実行するのを援助しなければなりません。それがセキュリティ要求によってカバーされないで、セキュリティ・テストの理にかなった範囲の外にあるならば、問題は「新しい」と思われなければなりません。

;(c) 新しいセキュリティ問題 : 開発者と顧客は、新しいセキュリティ問題を解決するために必要な努力を探し出すことに同意します。また、それらに取り組むために必要とされる仕事を実行するための合意を達成するために誠意を持って交渉することに同意します。

;(d) 他のセキュリティ問題 : 開発者は堅実なソフトウェア開発慣行。そして、リスクのひどさを考慮すること、そして、できるだけ速く新しいと思われないすべてのセキュリティ問題を解決することと一致したすべての商業的に理にかなった努力を使わなければなりません

[[Category:OWASP Legal Project]]

__NOTOC__

OWASP Secure Software Contract Annex/ja

2011-07-04T22:39:36Z

Tomo: /* 序文 */

'''セキュア・ソフトウェア開発契約付属書'''

警告：この文書は、単にガイダンスと考えられなければなりません。
OWASPは、ソフトウェア契約を交渉するのを手助けするために、
あなたが資格のある弁護士に相談するよう強く勧めます。

==序文==

OWASPセキュア・ソフトウェア開発契約付属書は、ソフトウェアの開発者とその顧客が、開発または供給されるソフトウェアのセキュリティに関連した重要な契約条項と条件を交渉し、取り込むことを助けます。このプロジェクトの理由は、多くの契約はこれらの問題に触れておらず、しばしば関係者が実際に同意されたものに劇的に異なる見解を持つことです。私たちは、これらの条項を明確に述べることは、双方の関係者が進め方について情報に基づいた意思決定ができることを確実にするもっともよい方法であると思っています。

「市場がより良いセキュリティを要求するとき、商用ソフトのセキュリティは改善します。
最低限、あらゆるソフトウェア提案依頼書は、ベンダーに彼らがセキュリティ脆弱性に対して
生産物をテストする方法を詳述するよう依頼しなければなりません。このステップは、企業が
セキュリティを評価すると市販ソフトウェアのベンダーと外部調達された開発者を納得させ始めます。」
-- John Pescatore（Gartnerのリサーチ・ディレクター）として

私たちは、顧客と開発者が、期待について議論して、責任について交渉することに対するフレームワークとしてこの文書を使うよう勧めます。この付属書は、ソフトウェア開発契約に添付されることを目的とします。これらの条項は交渉の余地があります。そして、それらは顧客と開発者によって、協議されることができて、協議されなければならないことを意味します。

==プロジェクトについて==

この文書はOpen Web Application Security Project（OWASP）財団によって作成されました。そして、非営利の慈善団体がセキュアなソフトウェアに関連した無料でオープンなツールとドキュメンテーションを作成することを専門としました。個人契約において容易に使用できるようにするために、この文書はCC Share Alike 3.0ライセンスにて提供されます。あなたは変更してもよいです、そして、あなたに適すると思うように使用してもよいです。あなたは、http://www.owasp.com/index.php/OWASP_Legal_Project でこのプロジェクトについて更なる詳細を見つけることができます。私たちは、ソフトウェア（法律コミュニティだけでなく）の製作者と消費者のコメントを歓迎します。

OWASPは、この文書の研究と準備における彼らの役割に対して [http://www.aspectsecurity.com Aspect Security] から特別な貢献を感謝して認めます。

==異論==

以下のわずかなページは、ソフトウェア開発契約においてこの言い回しを使用することに対するいくらかのたびたび聞こえる異論をカバーします：

===しかし、すべての条件が私たちに対して適切であるというわけではありません…===

この文書は、あなたの合意の出発点と考えられなければなりません。あなたはすべての活動が好きでなくてもよいですが、より提案したくてもよいです。あなたは、違って責任を割り当てたくてもよいです。この文書は、必ずしもすべてのソフトウェア顧客と開発者のニーズを捕えることを目的としません。ソフトウェアがセキュアに終わることを確実とすることにとって重要である主要な話題を議論するためのフレームワークを提供することを目的とします。あなたがセキュリティ議論をして、合意に達したあと、あなたは合致するためにこの合意を手直ししなければなりません。

===しかし、これらの活動に対して誰が代金を払わなければならないのでしょうか===

この契約は、ソフトウェア開発者により多くの負担を与えることはほとんどありません。問題は、セキュリティ ― もちろんそこにある ― と関連したコストがあるかどうかということでありません。むしろ、適切な問題はどんな活動がそれらのコストを最小にするために双方によって実行されなければならないかということです、そして、いつ、それらは起こらなければなりませんか。

この付属書は、誰がここに記述される活動の料金を払わなければならないかという問題について、意図的に語られていません。これらの活動の多くがすでに起こらなければならなくて、多くの顧客によって期待される一方、彼らはソフトウェア産業で定期的に実践されません。誰が支払うか（そして、いくら）という問題が、交渉の一部でなければなりません。

セキュリティのコストを計算することは、非常に難しいです。セキュリティ活動を実行することに関連したコストがある一方、それらを無視することに関連したかなりのコストもあります。私たちは、ソフトウェアを開発する最も費用効果がよい方法がセキュリティ瑕疵が導入されるという可能性を減らして、瑕疵を導入して、それを修正することの間で時間を最小にすることであることを確信しています。

コストを計算するときにする一つの重要な区別は、セキュリティ手法を構築することと、それらの手法が正しくて効果的であることを確実にする保証活動の間にあります。ライフサイクルの終わりに手法を加えようとすることは、深刻な設計問題を引き起こすことがありえて、めざましくコストを増やします。この合意は、手法についての早い段階の決定がこれらのコストを最小にするのを奨励します。同様に、配備直前に保証活動（例えばコードレビューと侵入テスト）をするまで待つことはコストをめざましく増やします。私たちは、保証を得る最も費用効果がよい方法がライフサイクルを通して努力の一定のレベルを保証に入れることであると思っています。

===しかし厳密さのレベルは間違っている….===

この合意は、開発されているソフトウェアが大企業または政府機関にとってかなり重要であると仮定します。私たちは、大部分のソフトウェア開発組織によって達成できる合意のために「厳格さのレベル」を選んで、最も一般的なリスクを確認して、取り扱います。

しかし、重要なアプリケーション（例えば医学であるか、財政的であるか、防衛に関連したソフトウェア）で使われそうであるソフトウェアについては、あなたは厳格さのレベルを上げたいかもしれません。あなたは、追加のレビュー、文書とテストしている活動を加えたくてもよいです。あなたは、脆弱性を探すこと、診断すること、修正することに対するプロセスを強化しくてもよいです。より機密を扱わないアプリケーションのために、あなたは活動を減らすか、取り除きたくてもよいです。

===しかし私たちはそれほど多くのリスクをとることができない…===

この契約は、ソフトウェアにおけるセキュリティ脆弱性に対するリスクをとるのかという議論を容易にすることを目的とします。範囲の一端で、顧客はすべてのリスクをすることができました、そして、開発者はたくさんの脆弱性でコードを供給することができました。他の極端で、開発者はすべてのリスクをとることができて、完全なコードを供給することに対する責任を負うことができました。これらの極端の両方とも、実行不可能です。

現在、この契約において、開発者は要求においてカバーされたか、理にかなったテスト努力によってカバーされるべき問題に対するリスクをとります。しかし、「新しい」セキュリティ問題の改善は、顧客によって代金を払われるべきです。私たちは、これが開発者が彼らのリスクの境界となることができて役に立つバランスで、顧客が前もってセキュリティ要求を正しくするのを奨励すると思っています。しかし、この問題の多くの他の可能性がある解決が、あります。あなたには他の提案があるかどうか私たちに知らせます、そして、私たちは彼らをこの文書の将来の版に含めてもよいです。

ここでの議論がコードにおいてセキュリティ脆弱性を修正することに関連したリスクをカバーだけして、これらの脆弱性のあらゆるエクスプロイットに基づくあらゆるセキュリティ・インシデントから立ち直ることと関連したコストを含まないことに注意すべきです。私たちは、この領域におけるベスト・プラクティスに興味があります。

===私たちはどのように第三者のコードを保証するでしょうか===

ほとんどすべてのソフトウェアプロジェクトは、第三者のコード（例えばライブラリ、フレームワークと生産物）のかなりの量を使います。このコードは、ただセキュリティ観点から、カスタム・コードがあなたのプロジェクトのために特に発達したのと同じくらい重要です。
私たちはこのコードのセキュリティを確実にすることに対する責任が開発者によって負われて最もよいと思っています、しかし、彼らにはこのセキュリティを保証するために彼ら自身のいっぱいの能力がないかもしれません。しかし、セキュリティは「構築するか、買うか」議論の一部分でなければなりません、これはそれを促進する最もよい方法のようです。

開発者は、もちろん、終わりまで第三者のソフトウェアの提供者にこの責任をパスする選択権があります。開発者は彼ら自身第三者のコードを分析することもできるか、彼らのためにそれを分析するために、セキュリティの専門家を雇うこともできます。

===しかし、なぜ私はすべてのこのトラブルにいくべきなのでしょうか===

最後に、私たちはソフトウェアを契約しているプロセスの一部分をセキュリティをすることに代わるものがないと思っています。現在では、私たちは多くのソフトウェア開発契約のもとで供給されているコードのセキュリティに関する重大な誤解があると思っています。これは、わずかなソフトウェア経験または理解とともに個人によってなされる高価な訴訟と決定に至ることができるだけです。この問題の完全な議論に対して [[Secure software contracting hypothetical case study]] を読んでください。

多くの利点が、この契約を通してうまくいくことにあります。主要なものは、それが関係する関係者の間で期待を明らかにするということです。場合によっては、難しいセキュリティ問題がソフトウェアで表面化するとき、それは訴訟を妨げるのを助けます。また、これらは多くの法的で調整するコンプライアンスの理由によって必要とされる同じ活動です。

===しかし、このドキュメントですべてを作ることは難しい===

OWASPは、文書の目的のために文書を励ましません。この契約は、品質（量でない）を促すことに集中します。私たちは、短時間のリスク評価、数ページの要求、短いセキュリティ設計文書、テストプラン、いくつかのテスト結果とともに、この契約に応じることが（若干のプロジェクトにおいて）ありえると思っています。

この文書の目標は、ライフサイクルの各段階で、単に適切な注意がセキュリティに払われたことを確実とすることです。追加の利点は、この文書が基本的に、このソフトウェアが安心してそれがそれがすると主張することをするのをまかせられなければならない理由に対する議論を配置する「証明パッケージ」をつくるために一緒に集められることができるということです。

==契約付属書==

===1. 序文===

この付属書は、顧客と開発者の間で_____________________ ("合意") するために作られます。顧客と開発者は、以下の条件のよりソフトウェアのセキュリティを最大にすることに同意します。

===2. 原理===

この付属書は、ソフトウェア開発関係のすべての関係者のセキュリティ関連の権利と義務をはっきりさせることを目的とします。最高水準で、関係者は以下に同意します

;(a) セキュリティ決定は、リスクに基づきます : セキュリティについての決定は、関係するリスクのしっかりした理解に基づく顧客と開発者によって共同でなされす。

;(b) セキュリティ活動はバランスが保たれます : セキュリティ努力は、全てのソフトウェア開発ライフサイクル全体でおおよそ均一に配布されます。

;(c) セキュリティ活動は統合されます : ここに協議されるすべての活動と文書は、開発者のソフトウェア開発ライフサイクルに統合されて、残りのプロジェクトと別にしておかれるというわけではありません。この付属書の何も、どんな特定のソフトウェア開発プロセスを意味しません。

;(d) 脆弱性は予想されます : すべてのソフトウェアにはバグがあります、そして、それらのいくらかはセキュリティ問題を生じさせます。顧客と開発者は、ライフサイクルにおいてできるだけ早く脆弱性を特定するよう努めます。

;(e) セキュリティ情報は、完全に明らかにされます : すべてのセキュリティ関連した情報は、すぐに、そして、完全に、顧客と開発者で共有されます。

;(f) 役に立つセキュリティ文書だけが必要とされます : セキュリティ文書は、セキュリティ設計、リスク分析または問題を明確に記述するために詳細にわたる必要はありません。

===3.ライフサイクル活動===

;(a) リスク識別 : 開発者とClientは、アプリケーションに直面しているリスクを理解して、文書化するために一緒に働くことに同意します。この努力は、アプリケーションにより提供される重要な資産と機能に主要なリスクを確認しなければなりません。要件部にリストされるトピックの各々は、考慮されなければなりません。

;(b) 要求 : リスクに基づいて、開発者と顧客は、開発されるソフトウェアの仕様の一部として詳細なセキュリティ要件を確立するために一緒に働くことに同意します。この付属書の要件部分で記載されるトピックの各々は、開発者と顧客によって協議されなければならなくて、評価されなければなりません。これらの要件は、カスタム・ソフト、第三者のソフトウェアまたはプラットホームによって満たされてもよいです。

;(c) 設計 : 開発者は、セキュリティ要件の各々を達成するために明確に設計を説明する文書を提供することに同意します。ほとんどの場合、この文書はセキュリティ手法を記載します、そこで、手法はアーキテクチャに適合しました、そして、関連したすべては彼らの適正使用を確実にするためにパターンを設計します。設計は、サポートがカスタム・ソフトか、第三者のソフトウェアかプラットホームから来るかどうか、明確に指定しなければなりません。

;(d) 実装 : 開発者は、一組のセキュアなコーディング指針に提供することに、従って、一組の共通セキュリティ制御プログラミング・インターフェース（例えば [http://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API OWASP Enterprise Security API（ESAPI）] ）を使って同意します。ガイドラインは、コードがどのようにフォーマットされなければならなくて、構築されなければならなくて、コメントされなければならないかについて示します。共通セキュリティ制御プログラミング・インターフェースは、セキュリティ制御がどのように呼ばれなければならないか、そして、セキュリティ制御がどのように機能するか定めます。すべてのセキュリティに関連したコードは、完全にコメントされます。共通のセキュリティ脆弱性を回避するときの具体的なガイダンスは、含まれなければなりません。また、すべてのコードはセキュリティ要件に対して少なくとも他の一人の開発者によってレビューされなければなりません、そして、それの前のコーディング・ガイドラインは単体テストの準備ができていると思われます。

;(e) セキュリティ分析とテスト : 開発者は、（ [http://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project OWASP Application Security Verification Standard (ASVS)] のような）合意された標準の検証要件により、アプリケーション・セキュリティ分析とテスト（「検証」とも言われる）を実行します。開発者は、標準の報告要件によって検証結論を文書化しなければなりません。開発者は、検証結論を顧客に提供しなければなりません。

;(f) セキュリティ配備 : 開発者は、ソフトウェアの全体的なセキュリティのために完全にすべてのセキュリティ関連した構成オプションとそれらの関連性を記述するセキュアな構成ガイドラインを提供することに同意します。ガイドラインは、オペレーティングシステム、ウェブサーバとアプリケーション・サーバーを含むサポート的なプラットホームにおける依存関係の完全な記述を含まなければいけません。また、どのようにそれらをセキュリティのために構成されるべきかを含まなければいけません。ソフトウェアのデフォルトコンフィグレーションは、セキュアでなければなりません。

===4.セキュリティ要求エリア===

以下のトピック領域は、リスク理解と要求定義活動の間、考慮されなければなりません。この努力は一組の具体的で、注文仕立てで、分析できる要求を生産しなければなりません。そして、開発者と顧客はこのプロセスに関与していなければならなくて、要求の最終セットについて同意しなければなりません。

;(a) 入力検証とエンコーディング : 要求は、ユーザー、ファイルシステム、データベース、ディレクトリまたは外部システムからであるかどうかにかかわらず、アプリケーションへの各々の入力を標準化し、検証し、コード化するためにルールを指定しなければなりません。　　　デフォルトルールは、それが何が許可されるかという詳細な仕様にマッチしない限り、すべての入力が無効であるということでなければなりません。そのうえ、無効な入力が受け取られるとき、要求はとられる措置を指定しなければなりません。具体的には、アプリケーションはインジェクション、オーバフロー、不正操作することまたは他の不正な入力攻撃に影響されやすくてはいけません。

;(b) 認証とセッション管理 : 要求は、認証証明書とセッション識別子がどのようにそれらのライフサイクルを通して保護されているかについて明記しなければなりません。すべての関連する機能（パスワード忘却、パスワード変更、パスワードリマインダ、ログアウト、そして複数ログインを含む）に対する要求は含められなければいけません。

;(c) アクセス制御 : 要求は、アプリケーションで使われるすべての役割（グループ、特権、認可）の詳細な記述を含まなければなりません。要求は、アプリケーションにより提供されるすべての資産と機能も示さなければなりません。要求は、完全に各々の資産に正確なアクセス権を指定しなければならなくて、各々の役割に対して機能しなければなりません。アクセス制御マトリックスは、これらのルールのための提案されたフォーマットです。

;(d) エラー処理 : 要求は、処理の間、発生しているエラーが取り扱われる方法を詳述しなければなりません。若干のアプリケーションはエラーの場合には最もよい努力結果を提供しなければなりません、一方、他はすぐに処理を終了しなければなりません。

;(e) ロギング : 要求は、どんなイベントがセキュリティに関連して、記録される必要があるか、たとえば、検知された攻撃、失敗したログイン試行、認可を上回ろうとする試行、を指定しなければなりません。要求は、時間と日付、イベント記述、アプリケーション詳細とフォレンジクス努力に役立つ他の情報を含む、各々のイベントでどんな情報を記録するべきかについても指定しなければなりません。

;(f) 外部システムへの接続 : 要求は、認証と暗号化がどのようにすべての外部システム（例えばデータベース、ディレクトリとウェブ・サービス）のために取り扱われるかについて指定しなければなりません。外部システムでコミュニケーションのために必要とされるすべてのクレディンシャルは、暗号化された形で構成ファイルでコードの外側に保存されなければなりません。

;(g) 暗号 : 要求は、どんなデータが暗号化されなければならないか、暗号化されることがどれほどか、そして、すべての証明書と他のクレディンシャルがどのように取り扱われなければならないか指定しなければなりません。アプリケーションは、広く使われていてテストされた暗号化ライブラリで実装される標準的なアルゴリズムを使用しなければなりません。

;(h) 可用性 : 要求は、それがどのようにサービス不能攻撃から保護するかについて指定しなければなりません。アプリケーションへのすべてのありそうな攻撃は考慮されなければなりません。そして、認証ロックアウト、接続消耗と他の資源消耗攻撃を含みます。

;(i) セキュアな設定 : 要求は、すべてのセキュリティに関連した構成オプションに対するデフォルト値がセキュアでなければならないことを示していなければなりません。監査目的のために、ソフトウェアはすべてのセキュリティに関連した構成詳細を示している簡単に読めるレポートをつくることができなければなりません。

;(j) 特定の脆弱性 : 要求は、ソフトウェアで見つかってはならない一組の具体的な脆弱性を含まなければなりません。指定されていないならば、ソフトウェアは現在の「OWASP Top Ten Most Critical Web Application Vulnerabilities」で記述される瑕疵の何も含んではいけません。

===5. 要員および組織===

;(a) セキュリティ・アーキテクト : 開発者は一つの上位の技術的な資源に責任をセキュリティに指定します。そして、プロジェクトのセキュリティ・アーキテクトとして知られています。セキュリティ・アーキテクトは、各々の納品可能なもののセキュリティを保証します。

;(b) セキュリティ・トレーニング : 開発者は、開発者チームのすべてのメンバーがセキュアなプログラミング技法の訓練をされたことを確かめる役割を果たします。

;(c) 信用できる開発者 : 開発者は、すべての開発チーム・メンバーの適切な経歴調査を実行することに同意します。

===6.開発環境===

;(a) セキュア・コーディング : 開発者は、どんなツールがセキュアなコーディングを促すためにソフトウェア開発環境で使われるかについて明らかにしなければなりません。

;(b) 構成管理 : 開発者は、ソフトウェア・ベースラインに対するすべての変更とすべての関連した設定とビルド・ファイルを関連づけ　とすべての関連した構成にすべての変化と関連したチーム・メンバーを認証して、記録して、ファイルを構築したソース・コード管理システムを使用しなければなりません。

;(c) 配布 : 開発者は、ソースから確実に完全な配布を構築するビルド・プロセスを使用しなければなりません。このプロセスは、顧客に供給されるソフトウェアの完全性を確かめる方法を含まなければなりません。

===7. ライブラリ、フレームワーク、および生産物===

;(a) 開示 : 開発者は、商用、フリー、オープンソース、クローズソースであるにせよ、すべてのライブラリ、フレームワーク、構成要素と他の生産物を含む、ソフトウェアで使われるすべての第三者のソフトウェアを明らかにしなければなりません。

;(b) 評価 : 開発者は、第三者のソフトウェアがこの契約のすべての条件を満たして、この契約の基で開発されたカスタム開発されたコードと同じくらいセキュアなことを確実とするために、理にかなった努力をしなければなりません。

===8. セキュリティ・レビュー===

;(a) レビューする権利 : 依頼人には、ソフトウェアを納品の60日間以内にいつでも彼らの費用でセキュリティ瑕疵のためにレビューしておく権利があります。開発者は、ソース・コードとテスト環境へのアクセスを提供することによって理にかなったサポートをレビュー・チームに提供することに同意します。

;(b) レビュー・カバレッジ : セキュリティ・レビューは供給されるソフトウェアのすべての面をカバーしなければなりません。そして、カスタム・コード、構成要素、生産物とシステム設定を含みます。

;(c) レビューの範囲 : 最低限で、レビューはセキュリティ要求の全てをカバーしなければならなくて、他の一般的な脆弱性を捜さなければなりません。レビューは、脆弱性スキャン、侵入テスト、ソースコードの静的分析と専門家のコードレビューの組み合わせを含んでもよいです。

;(d) 見つけられた問題 : 発見されたセキュリティ問題は、顧客と開発者に報告されます。すべての問題は、この付属書のセキュリティ問題マネジメント部分により追跡されて、矯正されます。

===9. セキュリティ問題マネジメント ===

;(a) 識別 : 要求、設計、実装、テスト、配備、または、運用中の問題にせよ、開発者は全てのライフサイクルの間に発見されるすべてのセキュリティ問題を追います。各々のセキュリティ問題に関連したリスクは、発見後できるだけ早く、評価されて、文書化されて、発見の後、顧客に報告されます。

;(b) 保護 : 開発者はセキュリティ問題と付随する文書に関して情報を適切に保護します。そして、運用中の顧客ソフトウェアの脆弱性が露出するという可能性を制限するのを助けます。

;(c) 改善 : 納品の前に確認されるセキュリティ問題は、開発者によって修正されなければなりません。納品の後に発見されるセキュリティ問題は、本契約の規定による他のバグと問題として同様に取り扱われなければなりません。

===10. 保証===

;(a) 保証 : 開発者は、開発プロセスを通して作成されるセキュリティ文書からなる「証明パッケージ」を提供します。パッケージは、セキュリティ要求、設計、実装と試験結果がきちんと完了された、そして、すべてのセキュリティ問題が適切に解決されたと確認しなければなりません。

;(b) 自己証明 : セキュリティ・アーキテクトは、ソフトウェアがセキュリティ要求を満たすこと、すべてのセキュリティ活動が実行されていること、そして、すべての識別されたセキュリティ問題が文書化されて、解決されたことを証明します。証明ステータスに対するあらゆる例外は、納品で完全に文書化されなければなりません。

;(c) 悪意のあるコードのなし : 開発者は、ソフトウェアがソフトウェア要求をサポートせず、コンピュータ・ウイルス、ワーム、時限爆弾、バック・ドア、トロイの木馬、イースターエッグと他のあらゆる形の悪意のあるソフトウェアを含む、アプリケーションのセキュリティを弱めるあらゆるコードを含んではならないと保証します。

===11. セキュリティ承認と保守 ===

;(a) 受け入れ : 証明パッケージが完全であり、すべてのセキュリティ問題が解決されるまで、ソフトウェアは受け入れられると考慮されてはいけません。

;(b) セキュリティ問題の調査 : 受理の後、セキュリティ問題が発見されるか、かなり疑われるならば、開発者は顧客が問題の性質を決定するために調査を実行するのを援助しなければなりません。それがセキュリティ要求によってカバーされないで、セキュリティ・テストの理にかなった範囲の外にあるならば、問題は「新しい」と思われなければなりません。

;(c) 新しいセキュリティ問題 : 開発者と顧客は、新しいセキュリティ問題を解決するために必要な努力を探し出すことに同意します。また、それらに取り組むために必要とされる仕事を実行するための合意を達成するために誠意を持って交渉することに同意します。

;(d) 他のセキュリティ問題 : 開発者は堅実なソフトウェア開発慣行。そして、リスクのひどさを考慮すること、そして、できるだけ速く新しいと思われないすべてのセキュリティ問題を解決することと一致したすべての商業的に理にかなった努力を使わなければなりません

[[Category:OWASP Legal Project]]

__NOTOC__

OWASP Secure Software Contract Annex/ja

2011-07-04T13:34:25Z

Tomo: /* 序文 */

'''セキュア・ソフトウェア開発契約付属書'''

警告：この文書は、単にガイダンスと考えられなければなりません。
OWASPは、ソフトウェア契約を交渉するのを手助けするために、
あなたが資格のある弁護士に相談するよう強く勧めます。

==序文==

OWASPセキュア・ソフトウェア開発契約付属書は、ソフトウェアの開発者とその顧客が、開発または供給されるソフトウェアのセキュリティに関連した重要な契約条項と条件を交渉し、取り込むことを助けます。このプロジェクトの理由は、多くの契約はこれらの問題に触れておらず、しばしば関係者が実際に同意されたものに劇的に異なる見解を持つことです。私たちは、これらの条項を明確に述べることは、双方の関係者が進め方について情報に基づいた意思決定ができることを確実にするもっともよい方法であると思っています。

「市場がより良いセキュリティを要求するとき、商用ソフトのセキュリティは改善します。
最低限、あらゆるソフトウェア提案依頼書は、ベンダーに彼らがセキュリティ脆弱性に対して
生産物をテストする方法を詳述するよう依頼しなければなりません。このステップは、企業が
セキュリティを評価すると市販ソフトウェアのベンダーと外部調達された開発者を納得させ始めます。」
-- John Pescatore（Gartnerのリサーチ・ディレクター）として

私たちは、顧客を開発者に期待を協議して、責任について交渉することに対するフレームワークとしてこの文書を使うよう勧めます。この付属書は、ソフトウェア開発契約に追加されることを目的とします。これらの条件は交渉の余地があります。そして、それらは顧客よ開発者によって協議されることができて、協議されなければならないことを意味します。

==プロジェクトについて==

この文書はOpen Web Application Security Project（OWASP）財団によって作成されました。そして、非営利の慈善団体がセキュアなソフトウェアに関連した無料でオープンなツールとドキュメンテーションを作成することを専門としました。個人契約において容易に使用できるようにするために、この文書はCC Share Alike 3.0ライセンスにて提供されます。あなたは変更してもよいです、そして、あなたに適すると思うように使用してもよいです。あなたは、http://www.owasp.com/index.php/OWASP_Legal_Project でこのプロジェクトについて更なる詳細を見つけることができます。私たちは、ソフトウェア（法律コミュニティだけでなく）の製作者と消費者のコメントを歓迎します。

OWASPは、この文書の研究と準備における彼らの役割に対して [http://www.aspectsecurity.com Aspect Security] から特別な貢献を感謝して認めます。

==異論==

以下のわずかなページは、ソフトウェア開発契約においてこの言い回しを使用することに対するいくらかのたびたび聞こえる異論をカバーします：

===しかし、すべての条件が私たちに対して適切であるというわけではありません…===

この文書は、あなたの合意の出発点と考えられなければなりません。あなたはすべての活動が好きでなくてもよいですが、より提案したくてもよいです。あなたは、違って責任を割り当てたくてもよいです。この文書は、必ずしもすべてのソフトウェア顧客と開発者のニーズを捕えることを目的としません。ソフトウェアがセキュアに終わることを確実とすることにとって重要である主要な話題を議論するためのフレームワークを提供することを目的とします。あなたがセキュリティ議論をして、合意に達したあと、あなたは合致するためにこの合意を手直ししなければなりません。

===しかし、これらの活動に対して誰が代金を払わなければならないのでしょうか===

この契約は、ソフトウェア開発者により多くの負担を与えることはほとんどありません。問題は、セキュリティ ― もちろんそこにある ― と関連したコストがあるかどうかということでありません。むしろ、適切な問題はどんな活動がそれらのコストを最小にするために双方によって実行されなければならないかということです、そして、いつ、それらは起こらなければなりませんか。

この付属書は、誰がここに記述される活動の料金を払わなければならないかという問題について、意図的に語られていません。これらの活動の多くがすでに起こらなければならなくて、多くの顧客によって期待される一方、彼らはソフトウェア産業で定期的に実践されません。誰が支払うか（そして、いくら）という問題が、交渉の一部でなければなりません。

セキュリティのコストを計算することは、非常に難しいです。セキュリティ活動を実行することに関連したコストがある一方、それらを無視することに関連したかなりのコストもあります。私たちは、ソフトウェアを開発する最も費用効果がよい方法がセキュリティ瑕疵が導入されるという可能性を減らして、瑕疵を導入して、それを修正することの間で時間を最小にすることであることを確信しています。

コストを計算するときにする一つの重要な区別は、セキュリティ手法を構築することと、それらの手法が正しくて効果的であることを確実にする保証活動の間にあります。ライフサイクルの終わりに手法を加えようとすることは、深刻な設計問題を引き起こすことがありえて、めざましくコストを増やします。この合意は、手法についての早い段階の決定がこれらのコストを最小にするのを奨励します。同様に、配備直前に保証活動（例えばコードレビューと侵入テスト）をするまで待つことはコストをめざましく増やします。私たちは、保証を得る最も費用効果がよい方法がライフサイクルを通して努力の一定のレベルを保証に入れることであると思っています。

===しかし厳密さのレベルは間違っている….===

この合意は、開発されているソフトウェアが大企業または政府機関にとってかなり重要であると仮定します。私たちは、大部分のソフトウェア開発組織によって達成できる合意のために「厳格さのレベル」を選んで、最も一般的なリスクを確認して、取り扱います。

しかし、重要なアプリケーション（例えば医学であるか、財政的であるか、防衛に関連したソフトウェア）で使われそうであるソフトウェアについては、あなたは厳格さのレベルを上げたいかもしれません。あなたは、追加のレビュー、文書とテストしている活動を加えたくてもよいです。あなたは、脆弱性を探すこと、診断すること、修正することに対するプロセスを強化しくてもよいです。より機密を扱わないアプリケーションのために、あなたは活動を減らすか、取り除きたくてもよいです。

===しかし私たちはそれほど多くのリスクをとることができない…===

この契約は、ソフトウェアにおけるセキュリティ脆弱性に対するリスクをとるのかという議論を容易にすることを目的とします。範囲の一端で、顧客はすべてのリスクをすることができました、そして、開発者はたくさんの脆弱性でコードを供給することができました。他の極端で、開発者はすべてのリスクをとることができて、完全なコードを供給することに対する責任を負うことができました。これらの極端の両方とも、実行不可能です。

現在、この契約において、開発者は要求においてカバーされたか、理にかなったテスト努力によってカバーされるべき問題に対するリスクをとります。しかし、「新しい」セキュリティ問題の改善は、顧客によって代金を払われるべきです。私たちは、これが開発者が彼らのリスクの境界となることができて役に立つバランスで、顧客が前もってセキュリティ要求を正しくするのを奨励すると思っています。しかし、この問題の多くの他の可能性がある解決が、あります。あなたには他の提案があるかどうか私たちに知らせます、そして、私たちは彼らをこの文書の将来の版に含めてもよいです。

ここでの議論がコードにおいてセキュリティ脆弱性を修正することに関連したリスクをカバーだけして、これらの脆弱性のあらゆるエクスプロイットに基づくあらゆるセキュリティ・インシデントから立ち直ることと関連したコストを含まないことに注意すべきです。私たちは、この領域におけるベスト・プラクティスに興味があります。

===私たちはどのように第三者のコードを保証するでしょうか===

ほとんどすべてのソフトウェアプロジェクトは、第三者のコード（例えばライブラリ、フレームワークと生産物）のかなりの量を使います。このコードは、ただセキュリティ観点から、カスタム・コードがあなたのプロジェクトのために特に発達したのと同じくらい重要です。
私たちはこのコードのセキュリティを確実にすることに対する責任が開発者によって負われて最もよいと思っています、しかし、彼らにはこのセキュリティを保証するために彼ら自身のいっぱいの能力がないかもしれません。しかし、セキュリティは「構築するか、買うか」議論の一部分でなければなりません、これはそれを促進する最もよい方法のようです。

開発者は、もちろん、終わりまで第三者のソフトウェアの提供者にこの責任をパスする選択権があります。開発者は彼ら自身第三者のコードを分析することもできるか、彼らのためにそれを分析するために、セキュリティの専門家を雇うこともできます。

===しかし、なぜ私はすべてのこのトラブルにいくべきなのでしょうか===

最後に、私たちはソフトウェアを契約しているプロセスの一部分をセキュリティをすることに代わるものがないと思っています。現在では、私たちは多くのソフトウェア開発契約のもとで供給されているコードのセキュリティに関する重大な誤解があると思っています。これは、わずかなソフトウェア経験または理解とともに個人によってなされる高価な訴訟と決定に至ることができるだけです。この問題の完全な議論に対して [[Secure software contracting hypothetical case study]] を読んでください。

多くの利点が、この契約を通してうまくいくことにあります。主要なものは、それが関係する関係者の間で期待を明らかにするということです。場合によっては、難しいセキュリティ問題がソフトウェアで表面化するとき、それは訴訟を妨げるのを助けます。また、これらは多くの法的で調整するコンプライアンスの理由によって必要とされる同じ活動です。

===しかし、このドキュメントですべてを作ることは難しい===

OWASPは、文書の目的のために文書を励ましません。この契約は、品質（量でない）を促すことに集中します。私たちは、短時間のリスク評価、数ページの要求、短いセキュリティ設計文書、テストプラン、いくつかのテスト結果とともに、この契約に応じることが（若干のプロジェクトにおいて）ありえると思っています。

この文書の目標は、ライフサイクルの各段階で、単に適切な注意がセキュリティに払われたことを確実とすることです。追加の利点は、この文書が基本的に、このソフトウェアが安心してそれがそれがすると主張することをするのをまかせられなければならない理由に対する議論を配置する「証明パッケージ」をつくるために一緒に集められることができるということです。

==契約付属書==

===1. 序文===

この付属書は、顧客と開発者の間で_____________________ ("合意") するために作られます。顧客と開発者は、以下の条件のよりソフトウェアのセキュリティを最大にすることに同意します。

===2. 原理===

この付属書は、ソフトウェア開発関係のすべての関係者のセキュリティ関連の権利と義務をはっきりさせることを目的とします。最高水準で、関係者は以下に同意します

;(a) セキュリティ決定は、リスクに基づきます : セキュリティについての決定は、関係するリスクのしっかりした理解に基づく顧客と開発者によって共同でなされす。

;(b) セキュリティ活動はバランスが保たれます : セキュリティ努力は、全てのソフトウェア開発ライフサイクル全体でおおよそ均一に配布されます。

;(c) セキュリティ活動は統合されます : ここに協議されるすべての活動と文書は、開発者のソフトウェア開発ライフサイクルに統合されて、残りのプロジェクトと別にしておかれるというわけではありません。この付属書の何も、どんな特定のソフトウェア開発プロセスを意味しません。

;(d) 脆弱性は予想されます : すべてのソフトウェアにはバグがあります、そして、それらのいくらかはセキュリティ問題を生じさせます。顧客と開発者は、ライフサイクルにおいてできるだけ早く脆弱性を特定するよう努めます。

;(e) セキュリティ情報は、完全に明らかにされます : すべてのセキュリティ関連した情報は、すぐに、そして、完全に、顧客と開発者で共有されます。

;(f) 役に立つセキュリティ文書だけが必要とされます : セキュリティ文書は、セキュリティ設計、リスク分析または問題を明確に記述するために詳細にわたる必要はありません。

===3.ライフサイクル活動===

;(a) リスク識別 : 開発者とClientは、アプリケーションに直面しているリスクを理解して、文書化するために一緒に働くことに同意します。この努力は、アプリケーションにより提供される重要な資産と機能に主要なリスクを確認しなければなりません。要件部にリストされるトピックの各々は、考慮されなければなりません。

;(b) 要求 : リスクに基づいて、開発者と顧客は、開発されるソフトウェアの仕様の一部として詳細なセキュリティ要件を確立するために一緒に働くことに同意します。この付属書の要件部分で記載されるトピックの各々は、開発者と顧客によって協議されなければならなくて、評価されなければなりません。これらの要件は、カスタム・ソフト、第三者のソフトウェアまたはプラットホームによって満たされてもよいです。

;(c) 設計 : 開発者は、セキュリティ要件の各々を達成するために明確に設計を説明する文書を提供することに同意します。ほとんどの場合、この文書はセキュリティ手法を記載します、そこで、手法はアーキテクチャに適合しました、そして、関連したすべては彼らの適正使用を確実にするためにパターンを設計します。設計は、サポートがカスタム・ソフトか、第三者のソフトウェアかプラットホームから来るかどうか、明確に指定しなければなりません。

;(d) 実装 : 開発者は、一組のセキュアなコーディング指針に提供することに、従って、一組の共通セキュリティ制御プログラミング・インターフェース（例えば [http://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API OWASP Enterprise Security API（ESAPI）] ）を使って同意します。ガイドラインは、コードがどのようにフォーマットされなければならなくて、構築されなければならなくて、コメントされなければならないかについて示します。共通セキュリティ制御プログラミング・インターフェースは、セキュリティ制御がどのように呼ばれなければならないか、そして、セキュリティ制御がどのように機能するか定めます。すべてのセキュリティに関連したコードは、完全にコメントされます。共通のセキュリティ脆弱性を回避するときの具体的なガイダンスは、含まれなければなりません。また、すべてのコードはセキュリティ要件に対して少なくとも他の一人の開発者によってレビューされなければなりません、そして、それの前のコーディング・ガイドラインは単体テストの準備ができていると思われます。

;(e) セキュリティ分析とテスト : 開発者は、（ [http://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project OWASP Application Security Verification Standard (ASVS)] のような）合意された標準の検証要件により、アプリケーション・セキュリティ分析とテスト（「検証」とも言われる）を実行します。開発者は、標準の報告要件によって検証結論を文書化しなければなりません。開発者は、検証結論を顧客に提供しなければなりません。

;(f) セキュリティ配備 : 開発者は、ソフトウェアの全体的なセキュリティのために完全にすべてのセキュリティ関連した構成オプションとそれらの関連性を記述するセキュアな構成ガイドラインを提供することに同意します。ガイドラインは、オペレーティングシステム、ウェブサーバとアプリケーション・サーバーを含むサポート的なプラットホームにおける依存関係の完全な記述を含まなければいけません。また、どのようにそれらをセキュリティのために構成されるべきかを含まなければいけません。ソフトウェアのデフォルトコンフィグレーションは、セキュアでなければなりません。

===4.セキュリティ要求エリア===

以下のトピック領域は、リスク理解と要求定義活動の間、考慮されなければなりません。この努力は一組の具体的で、注文仕立てで、分析できる要求を生産しなければなりません。そして、開発者と顧客はこのプロセスに関与していなければならなくて、要求の最終セットについて同意しなければなりません。

;(a) 入力検証とエンコーディング : 要求は、ユーザー、ファイルシステム、データベース、ディレクトリまたは外部システムからであるかどうかにかかわらず、アプリケーションへの各々の入力を標準化し、検証し、コード化するためにルールを指定しなければなりません。　　　デフォルトルールは、それが何が許可されるかという詳細な仕様にマッチしない限り、すべての入力が無効であるということでなければなりません。そのうえ、無効な入力が受け取られるとき、要求はとられる措置を指定しなければなりません。具体的には、アプリケーションはインジェクション、オーバフロー、不正操作することまたは他の不正な入力攻撃に影響されやすくてはいけません。

;(b) 認証とセッション管理 : 要求は、認証証明書とセッション識別子がどのようにそれらのライフサイクルを通して保護されているかについて明記しなければなりません。すべての関連する機能（パスワード忘却、パスワード変更、パスワードリマインダ、ログアウト、そして複数ログインを含む）に対する要求は含められなければいけません。

;(c) アクセス制御 : 要求は、アプリケーションで使われるすべての役割（グループ、特権、認可）の詳細な記述を含まなければなりません。要求は、アプリケーションにより提供されるすべての資産と機能も示さなければなりません。要求は、完全に各々の資産に正確なアクセス権を指定しなければならなくて、各々の役割に対して機能しなければなりません。アクセス制御マトリックスは、これらのルールのための提案されたフォーマットです。

;(d) エラー処理 : 要求は、処理の間、発生しているエラーが取り扱われる方法を詳述しなければなりません。若干のアプリケーションはエラーの場合には最もよい努力結果を提供しなければなりません、一方、他はすぐに処理を終了しなければなりません。

;(e) ロギング : 要求は、どんなイベントがセキュリティに関連して、記録される必要があるか、たとえば、検知された攻撃、失敗したログイン試行、認可を上回ろうとする試行、を指定しなければなりません。要求は、時間と日付、イベント記述、アプリケーション詳細とフォレンジクス努力に役立つ他の情報を含む、各々のイベントでどんな情報を記録するべきかについても指定しなければなりません。

;(f) 外部システムへの接続 : 要求は、認証と暗号化がどのようにすべての外部システム（例えばデータベース、ディレクトリとウェブ・サービス）のために取り扱われるかについて指定しなければなりません。外部システムでコミュニケーションのために必要とされるすべてのクレディンシャルは、暗号化された形で構成ファイルでコードの外側に保存されなければなりません。

;(g) 暗号 : 要求は、どんなデータが暗号化されなければならないか、暗号化されることがどれほどか、そして、すべての証明書と他のクレディンシャルがどのように取り扱われなければならないか指定しなければなりません。アプリケーションは、広く使われていてテストされた暗号化ライブラリで実装される標準的なアルゴリズムを使用しなければなりません。

;(h) 可用性 : 要求は、それがどのようにサービス不能攻撃から保護するかについて指定しなければなりません。アプリケーションへのすべてのありそうな攻撃は考慮されなければなりません。そして、認証ロックアウト、接続消耗と他の資源消耗攻撃を含みます。

;(i) セキュアな設定 : 要求は、すべてのセキュリティに関連した構成オプションに対するデフォルト値がセキュアでなければならないことを示していなければなりません。監査目的のために、ソフトウェアはすべてのセキュリティに関連した構成詳細を示している簡単に読めるレポートをつくることができなければなりません。

;(j) 特定の脆弱性 : 要求は、ソフトウェアで見つかってはならない一組の具体的な脆弱性を含まなければなりません。指定されていないならば、ソフトウェアは現在の「OWASP Top Ten Most Critical Web Application Vulnerabilities」で記述される瑕疵の何も含んではいけません。

===5. 要員および組織===

;(a) セキュリティ・アーキテクト : 開発者は一つの上位の技術的な資源に責任をセキュリティに指定します。そして、プロジェクトのセキュリティ・アーキテクトとして知られています。セキュリティ・アーキテクトは、各々の納品可能なもののセキュリティを保証します。

;(b) セキュリティ・トレーニング : 開発者は、開発者チームのすべてのメンバーがセキュアなプログラミング技法の訓練をされたことを確かめる役割を果たします。

;(c) 信用できる開発者 : 開発者は、すべての開発チーム・メンバーの適切な経歴調査を実行することに同意します。

===6.開発環境===

;(a) セキュア・コーディング : 開発者は、どんなツールがセキュアなコーディングを促すためにソフトウェア開発環境で使われるかについて明らかにしなければなりません。

;(b) 構成管理 : 開発者は、ソフトウェア・ベースラインに対するすべての変更とすべての関連した設定とビルド・ファイルを関連づけ　とすべての関連した構成にすべての変化と関連したチーム・メンバーを認証して、記録して、ファイルを構築したソース・コード管理システムを使用しなければなりません。

;(c) 配布 : 開発者は、ソースから確実に完全な配布を構築するビルド・プロセスを使用しなければなりません。このプロセスは、顧客に供給されるソフトウェアの完全性を確かめる方法を含まなければなりません。

===7. ライブラリ、フレームワーク、および生産物===

;(a) 開示 : 開発者は、商用、フリー、オープンソース、クローズソースであるにせよ、すべてのライブラリ、フレームワーク、構成要素と他の生産物を含む、ソフトウェアで使われるすべての第三者のソフトウェアを明らかにしなければなりません。

;(b) 評価 : 開発者は、第三者のソフトウェアがこの契約のすべての条件を満たして、この契約の基で開発されたカスタム開発されたコードと同じくらいセキュアなことを確実とするために、理にかなった努力をしなければなりません。

===8. セキュリティ・レビュー===

;(a) レビューする権利 : 依頼人には、ソフトウェアを納品の60日間以内にいつでも彼らの費用でセキュリティ瑕疵のためにレビューしておく権利があります。開発者は、ソース・コードとテスト環境へのアクセスを提供することによって理にかなったサポートをレビュー・チームに提供することに同意します。

;(b) レビュー・カバレッジ : セキュリティ・レビューは供給されるソフトウェアのすべての面をカバーしなければなりません。そして、カスタム・コード、構成要素、生産物とシステム設定を含みます。

;(c) レビューの範囲 : 最低限で、レビューはセキュリティ要求の全てをカバーしなければならなくて、他の一般的な脆弱性を捜さなければなりません。レビューは、脆弱性スキャン、侵入テスト、ソースコードの静的分析と専門家のコードレビューの組み合わせを含んでもよいです。

;(d) 見つけられた問題 : 発見されたセキュリティ問題は、顧客と開発者に報告されます。すべての問題は、この付属書のセキュリティ問題マネジメント部分により追跡されて、矯正されます。

===9. セキュリティ問題マネジメント ===

;(a) 識別 : 要求、設計、実装、テスト、配備、または、運用中の問題にせよ、開発者は全てのライフサイクルの間に発見されるすべてのセキュリティ問題を追います。各々のセキュリティ問題に関連したリスクは、発見後できるだけ早く、評価されて、文書化されて、発見の後、顧客に報告されます。

;(b) 保護 : 開発者はセキュリティ問題と付随する文書に関して情報を適切に保護します。そして、運用中の顧客ソフトウェアの脆弱性が露出するという可能性を制限するのを助けます。

;(c) 改善 : 納品の前に確認されるセキュリティ問題は、開発者によって修正されなければなりません。納品の後に発見されるセキュリティ問題は、本契約の規定による他のバグと問題として同様に取り扱われなければなりません。

===10. 保証===

;(a) 保証 : 開発者は、開発プロセスを通して作成されるセキュリティ文書からなる「証明パッケージ」を提供します。パッケージは、セキュリティ要求、設計、実装と試験結果がきちんと完了された、そして、すべてのセキュリティ問題が適切に解決されたと確認しなければなりません。

;(b) 自己証明 : セキュリティ・アーキテクトは、ソフトウェアがセキュリティ要求を満たすこと、すべてのセキュリティ活動が実行されていること、そして、すべての識別されたセキュリティ問題が文書化されて、解決されたことを証明します。証明ステータスに対するあらゆる例外は、納品で完全に文書化されなければなりません。

;(c) 悪意のあるコードのなし : 開発者は、ソフトウェアがソフトウェア要求をサポートせず、コンピュータ・ウイルス、ワーム、時限爆弾、バック・ドア、トロイの木馬、イースターエッグと他のあらゆる形の悪意のあるソフトウェアを含む、アプリケーションのセキュリティを弱めるあらゆるコードを含んではならないと保証します。

===11. セキュリティ承認と保守 ===

;(a) 受け入れ : 証明パッケージが完全であり、すべてのセキュリティ問題が解決されるまで、ソフトウェアは受け入れられると考慮されてはいけません。

;(b) セキュリティ問題の調査 : 受理の後、セキュリティ問題が発見されるか、かなり疑われるならば、開発者は顧客が問題の性質を決定するために調査を実行するのを援助しなければなりません。それがセキュリティ要求によってカバーされないで、セキュリティ・テストの理にかなった範囲の外にあるならば、問題は「新しい」と思われなければなりません。

;(c) 新しいセキュリティ問題 : 開発者と顧客は、新しいセキュリティ問題を解決するために必要な努力を探し出すことに同意します。また、それらに取り組むために必要とされる仕事を実行するための合意を達成するために誠意を持って交渉することに同意します。

;(d) 他のセキュリティ問題 : 開発者は堅実なソフトウェア開発慣行。そして、リスクのひどさを考慮すること、そして、できるだけ速く新しいと思われないすべてのセキュリティ問題を解決することと一致したすべての商業的に理にかなった努力を使わなければなりません

[[Category:OWASP Legal Project]]

__NOTOC__

OWASP Secure Software Contract Annex/ja

2011-07-04T13:33:42Z

Tomo:

'''セキュア・ソフトウェア開発契約付属書'''

警告：この文書は、単にガイダンスと考えられなければなりません。
OWASPは、ソフトウェア契約を交渉するのを手助けするために、
あなたが資格のある弁護士に相談するよう強く勧めます。

==序文==

この契約付属書はソフトウェア開発者を助けることを目的とします、そして、彼らのクライアントは開発されるか、供給されるソフトウェアのセキュリティに関連した重要な契約の期間と条件を協議して、取り込みます。このプロジェクトの理由は大部分の契約がこれらの問題について語られていないということです、そして、関係者は実は同意されたことの上にまったく異なる見解をしばしば持ちます。私たちは、これらの条件を明らかに明瞭に表現することが双方が前進する方法について情報に基づいた決定をすることができることを確実とする最もよい方法であると思っています。

「市場がより良いセキュリティを要求するとき、商用ソフトのセキュリティはよくなります。
最低限で、あらゆるソフトウェア提案依頼書は、ベンダーに彼らがセキュリティ脆弱性に対して
生産物をテストする方法を詳述するよう依頼しなければなりません。このステップは、企業が
セキュリティを評価すると既製のソフトウェアのベンダーと外部調達された開発者を納得させ始めます。」
-- John Pescatore（Gartnerのリサーチ・ディレクター）として

私たちは、顧客を開発者に期待を協議して、責任について交渉することに対するフレームワークとしてこの文書を使うよう勧めます。この付属書は、ソフトウェア開発契約に追加されることを目的とします。これらの条件は交渉の余地があります。そして、それらは顧客よ開発者によって協議されることができて、協議されなければならないことを意味します。

==プロジェクトについて==

この文書はOpen Web Application Security Project（OWASP）財団によって作成されました。そして、非営利の慈善団体がセキュアなソフトウェアに関連した無料でオープンなツールとドキュメンテーションを作成することを専門としました。個人契約において容易に使用できるようにするために、この文書はCC Share Alike 3.0ライセンスにて提供されます。あなたは変更してもよいです、そして、あなたに適すると思うように使用してもよいです。あなたは、http://www.owasp.com/index.php/OWASP_Legal_Project でこのプロジェクトについて更なる詳細を見つけることができます。私たちは、ソフトウェア（法律コミュニティだけでなく）の製作者と消費者のコメントを歓迎します。

OWASPは、この文書の研究と準備における彼らの役割に対して [http://www.aspectsecurity.com Aspect Security] から特別な貢献を感謝して認めます。

==異論==

以下のわずかなページは、ソフトウェア開発契約においてこの言い回しを使用することに対するいくらかのたびたび聞こえる異論をカバーします：

===しかし、すべての条件が私たちに対して適切であるというわけではありません…===

この文書は、あなたの合意の出発点と考えられなければなりません。あなたはすべての活動が好きでなくてもよいですが、より提案したくてもよいです。あなたは、違って責任を割り当てたくてもよいです。この文書は、必ずしもすべてのソフトウェア顧客と開発者のニーズを捕えることを目的としません。ソフトウェアがセキュアに終わることを確実とすることにとって重要である主要な話題を議論するためのフレームワークを提供することを目的とします。あなたがセキュリティ議論をして、合意に達したあと、あなたは合致するためにこの合意を手直ししなければなりません。

===しかし、これらの活動に対して誰が代金を払わなければならないのでしょうか===

この契約は、ソフトウェア開発者により多くの負担を与えることはほとんどありません。問題は、セキュリティ ― もちろんそこにある ― と関連したコストがあるかどうかということでありません。むしろ、適切な問題はどんな活動がそれらのコストを最小にするために双方によって実行されなければならないかということです、そして、いつ、それらは起こらなければなりませんか。

この付属書は、誰がここに記述される活動の料金を払わなければならないかという問題について、意図的に語られていません。これらの活動の多くがすでに起こらなければならなくて、多くの顧客によって期待される一方、彼らはソフトウェア産業で定期的に実践されません。誰が支払うか（そして、いくら）という問題が、交渉の一部でなければなりません。

セキュリティのコストを計算することは、非常に難しいです。セキュリティ活動を実行することに関連したコストがある一方、それらを無視することに関連したかなりのコストもあります。私たちは、ソフトウェアを開発する最も費用効果がよい方法がセキュリティ瑕疵が導入されるという可能性を減らして、瑕疵を導入して、それを修正することの間で時間を最小にすることであることを確信しています。

コストを計算するときにする一つの重要な区別は、セキュリティ手法を構築することと、それらの手法が正しくて効果的であることを確実にする保証活動の間にあります。ライフサイクルの終わりに手法を加えようとすることは、深刻な設計問題を引き起こすことがありえて、めざましくコストを増やします。この合意は、手法についての早い段階の決定がこれらのコストを最小にするのを奨励します。同様に、配備直前に保証活動（例えばコードレビューと侵入テスト）をするまで待つことはコストをめざましく増やします。私たちは、保証を得る最も費用効果がよい方法がライフサイクルを通して努力の一定のレベルを保証に入れることであると思っています。

===しかし厳密さのレベルは間違っている….===

この合意は、開発されているソフトウェアが大企業または政府機関にとってかなり重要であると仮定します。私たちは、大部分のソフトウェア開発組織によって達成できる合意のために「厳格さのレベル」を選んで、最も一般的なリスクを確認して、取り扱います。

しかし、重要なアプリケーション（例えば医学であるか、財政的であるか、防衛に関連したソフトウェア）で使われそうであるソフトウェアについては、あなたは厳格さのレベルを上げたいかもしれません。あなたは、追加のレビュー、文書とテストしている活動を加えたくてもよいです。あなたは、脆弱性を探すこと、診断すること、修正することに対するプロセスを強化しくてもよいです。より機密を扱わないアプリケーションのために、あなたは活動を減らすか、取り除きたくてもよいです。

===しかし私たちはそれほど多くのリスクをとることができない…===

この契約は、ソフトウェアにおけるセキュリティ脆弱性に対するリスクをとるのかという議論を容易にすることを目的とします。範囲の一端で、顧客はすべてのリスクをすることができました、そして、開発者はたくさんの脆弱性でコードを供給することができました。他の極端で、開発者はすべてのリスクをとることができて、完全なコードを供給することに対する責任を負うことができました。これらの極端の両方とも、実行不可能です。

現在、この契約において、開発者は要求においてカバーされたか、理にかなったテスト努力によってカバーされるべき問題に対するリスクをとります。しかし、「新しい」セキュリティ問題の改善は、顧客によって代金を払われるべきです。私たちは、これが開発者が彼らのリスクの境界となることができて役に立つバランスで、顧客が前もってセキュリティ要求を正しくするのを奨励すると思っています。しかし、この問題の多くの他の可能性がある解決が、あります。あなたには他の提案があるかどうか私たちに知らせます、そして、私たちは彼らをこの文書の将来の版に含めてもよいです。

ここでの議論がコードにおいてセキュリティ脆弱性を修正することに関連したリスクをカバーだけして、これらの脆弱性のあらゆるエクスプロイットに基づくあらゆるセキュリティ・インシデントから立ち直ることと関連したコストを含まないことに注意すべきです。私たちは、この領域におけるベスト・プラクティスに興味があります。

===私たちはどのように第三者のコードを保証するでしょうか===

ほとんどすべてのソフトウェアプロジェクトは、第三者のコード（例えばライブラリ、フレームワークと生産物）のかなりの量を使います。このコードは、ただセキュリティ観点から、カスタム・コードがあなたのプロジェクトのために特に発達したのと同じくらい重要です。
私たちはこのコードのセキュリティを確実にすることに対する責任が開発者によって負われて最もよいと思っています、しかし、彼らにはこのセキュリティを保証するために彼ら自身のいっぱいの能力がないかもしれません。しかし、セキュリティは「構築するか、買うか」議論の一部分でなければなりません、これはそれを促進する最もよい方法のようです。

開発者は、もちろん、終わりまで第三者のソフトウェアの提供者にこの責任をパスする選択権があります。開発者は彼ら自身第三者のコードを分析することもできるか、彼らのためにそれを分析するために、セキュリティの専門家を雇うこともできます。

===しかし、なぜ私はすべてのこのトラブルにいくべきなのでしょうか===

最後に、私たちはソフトウェアを契約しているプロセスの一部分をセキュリティをすることに代わるものがないと思っています。現在では、私たちは多くのソフトウェア開発契約のもとで供給されているコードのセキュリティに関する重大な誤解があると思っています。これは、わずかなソフトウェア経験または理解とともに個人によってなされる高価な訴訟と決定に至ることができるだけです。この問題の完全な議論に対して [[Secure software contracting hypothetical case study]] を読んでください。

多くの利点が、この契約を通してうまくいくことにあります。主要なものは、それが関係する関係者の間で期待を明らかにするということです。場合によっては、難しいセキュリティ問題がソフトウェアで表面化するとき、それは訴訟を妨げるのを助けます。また、これらは多くの法的で調整するコンプライアンスの理由によって必要とされる同じ活動です。

===しかし、このドキュメントですべてを作ることは難しい===

OWASPは、文書の目的のために文書を励ましません。この契約は、品質（量でない）を促すことに集中します。私たちは、短時間のリスク評価、数ページの要求、短いセキュリティ設計文書、テストプラン、いくつかのテスト結果とともに、この契約に応じることが（若干のプロジェクトにおいて）ありえると思っています。

この文書の目標は、ライフサイクルの各段階で、単に適切な注意がセキュリティに払われたことを確実とすることです。追加の利点は、この文書が基本的に、このソフトウェアが安心してそれがそれがすると主張することをするのをまかせられなければならない理由に対する議論を配置する「証明パッケージ」をつくるために一緒に集められることができるということです。

==契約付属書==

===1. 序文===

この付属書は、顧客と開発者の間で_____________________ ("合意") するために作られます。顧客と開発者は、以下の条件のよりソフトウェアのセキュリティを最大にすることに同意します。

===2. 原理===

この付属書は、ソフトウェア開発関係のすべての関係者のセキュリティ関連の権利と義務をはっきりさせることを目的とします。最高水準で、関係者は以下に同意します

;(a) セキュリティ決定は、リスクに基づきます : セキュリティについての決定は、関係するリスクのしっかりした理解に基づく顧客と開発者によって共同でなされす。

;(b) セキュリティ活動はバランスが保たれます : セキュリティ努力は、全てのソフトウェア開発ライフサイクル全体でおおよそ均一に配布されます。

;(c) セキュリティ活動は統合されます : ここに協議されるすべての活動と文書は、開発者のソフトウェア開発ライフサイクルに統合されて、残りのプロジェクトと別にしておかれるというわけではありません。この付属書の何も、どんな特定のソフトウェア開発プロセスを意味しません。

;(d) 脆弱性は予想されます : すべてのソフトウェアにはバグがあります、そして、それらのいくらかはセキュリティ問題を生じさせます。顧客と開発者は、ライフサイクルにおいてできるだけ早く脆弱性を特定するよう努めます。

;(e) セキュリティ情報は、完全に明らかにされます : すべてのセキュリティ関連した情報は、すぐに、そして、完全に、顧客と開発者で共有されます。

;(f) 役に立つセキュリティ文書だけが必要とされます : セキュリティ文書は、セキュリティ設計、リスク分析または問題を明確に記述するために詳細にわたる必要はありません。

===3.ライフサイクル活動===

;(a) リスク識別 : 開発者とClientは、アプリケーションに直面しているリスクを理解して、文書化するために一緒に働くことに同意します。この努力は、アプリケーションにより提供される重要な資産と機能に主要なリスクを確認しなければなりません。要件部にリストされるトピックの各々は、考慮されなければなりません。

;(b) 要求 : リスクに基づいて、開発者と顧客は、開発されるソフトウェアの仕様の一部として詳細なセキュリティ要件を確立するために一緒に働くことに同意します。この付属書の要件部分で記載されるトピックの各々は、開発者と顧客によって協議されなければならなくて、評価されなければなりません。これらの要件は、カスタム・ソフト、第三者のソフトウェアまたはプラットホームによって満たされてもよいです。

;(c) 設計 : 開発者は、セキュリティ要件の各々を達成するために明確に設計を説明する文書を提供することに同意します。ほとんどの場合、この文書はセキュリティ手法を記載します、そこで、手法はアーキテクチャに適合しました、そして、関連したすべては彼らの適正使用を確実にするためにパターンを設計します。設計は、サポートがカスタム・ソフトか、第三者のソフトウェアかプラットホームから来るかどうか、明確に指定しなければなりません。

;(d) 実装 : 開発者は、一組のセキュアなコーディング指針に提供することに、従って、一組の共通セキュリティ制御プログラミング・インターフェース（例えば [http://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API OWASP Enterprise Security API（ESAPI）] ）を使って同意します。ガイドラインは、コードがどのようにフォーマットされなければならなくて、構築されなければならなくて、コメントされなければならないかについて示します。共通セキュリティ制御プログラミング・インターフェースは、セキュリティ制御がどのように呼ばれなければならないか、そして、セキュリティ制御がどのように機能するか定めます。すべてのセキュリティに関連したコードは、完全にコメントされます。共通のセキュリティ脆弱性を回避するときの具体的なガイダンスは、含まれなければなりません。また、すべてのコードはセキュリティ要件に対して少なくとも他の一人の開発者によってレビューされなければなりません、そして、それの前のコーディング・ガイドラインは単体テストの準備ができていると思われます。

;(e) セキュリティ分析とテスト : 開発者は、（ [http://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project OWASP Application Security Verification Standard (ASVS)] のような）合意された標準の検証要件により、アプリケーション・セキュリティ分析とテスト（「検証」とも言われる）を実行します。開発者は、標準の報告要件によって検証結論を文書化しなければなりません。開発者は、検証結論を顧客に提供しなければなりません。

;(f) セキュリティ配備 : 開発者は、ソフトウェアの全体的なセキュリティのために完全にすべてのセキュリティ関連した構成オプションとそれらの関連性を記述するセキュアな構成ガイドラインを提供することに同意します。ガイドラインは、オペレーティングシステム、ウェブサーバとアプリケーション・サーバーを含むサポート的なプラットホームにおける依存関係の完全な記述を含まなければいけません。また、どのようにそれらをセキュリティのために構成されるべきかを含まなければいけません。ソフトウェアのデフォルトコンフィグレーションは、セキュアでなければなりません。

===4.セキュリティ要求エリア===

以下のトピック領域は、リスク理解と要求定義活動の間、考慮されなければなりません。この努力は一組の具体的で、注文仕立てで、分析できる要求を生産しなければなりません。そして、開発者と顧客はこのプロセスに関与していなければならなくて、要求の最終セットについて同意しなければなりません。

;(a) 入力検証とエンコーディング : 要求は、ユーザー、ファイルシステム、データベース、ディレクトリまたは外部システムからであるかどうかにかかわらず、アプリケーションへの各々の入力を標準化し、検証し、コード化するためにルールを指定しなければなりません。　　　デフォルトルールは、それが何が許可されるかという詳細な仕様にマッチしない限り、すべての入力が無効であるということでなければなりません。そのうえ、無効な入力が受け取られるとき、要求はとられる措置を指定しなければなりません。具体的には、アプリケーションはインジェクション、オーバフロー、不正操作することまたは他の不正な入力攻撃に影響されやすくてはいけません。

;(b) 認証とセッション管理 : 要求は、認証証明書とセッション識別子がどのようにそれらのライフサイクルを通して保護されているかについて明記しなければなりません。すべての関連する機能（パスワード忘却、パスワード変更、パスワードリマインダ、ログアウト、そして複数ログインを含む）に対する要求は含められなければいけません。

;(c) アクセス制御 : 要求は、アプリケーションで使われるすべての役割（グループ、特権、認可）の詳細な記述を含まなければなりません。要求は、アプリケーションにより提供されるすべての資産と機能も示さなければなりません。要求は、完全に各々の資産に正確なアクセス権を指定しなければならなくて、各々の役割に対して機能しなければなりません。アクセス制御マトリックスは、これらのルールのための提案されたフォーマットです。

;(d) エラー処理 : 要求は、処理の間、発生しているエラーが取り扱われる方法を詳述しなければなりません。若干のアプリケーションはエラーの場合には最もよい努力結果を提供しなければなりません、一方、他はすぐに処理を終了しなければなりません。

;(e) ロギング : 要求は、どんなイベントがセキュリティに関連して、記録される必要があるか、たとえば、検知された攻撃、失敗したログイン試行、認可を上回ろうとする試行、を指定しなければなりません。要求は、時間と日付、イベント記述、アプリケーション詳細とフォレンジクス努力に役立つ他の情報を含む、各々のイベントでどんな情報を記録するべきかについても指定しなければなりません。

;(f) 外部システムへの接続 : 要求は、認証と暗号化がどのようにすべての外部システム（例えばデータベース、ディレクトリとウェブ・サービス）のために取り扱われるかについて指定しなければなりません。外部システムでコミュニケーションのために必要とされるすべてのクレディンシャルは、暗号化された形で構成ファイルでコードの外側に保存されなければなりません。

;(g) 暗号 : 要求は、どんなデータが暗号化されなければならないか、暗号化されることがどれほどか、そして、すべての証明書と他のクレディンシャルがどのように取り扱われなければならないか指定しなければなりません。アプリケーションは、広く使われていてテストされた暗号化ライブラリで実装される標準的なアルゴリズムを使用しなければなりません。

;(h) 可用性 : 要求は、それがどのようにサービス不能攻撃から保護するかについて指定しなければなりません。アプリケーションへのすべてのありそうな攻撃は考慮されなければなりません。そして、認証ロックアウト、接続消耗と他の資源消耗攻撃を含みます。

;(i) セキュアな設定 : 要求は、すべてのセキュリティに関連した構成オプションに対するデフォルト値がセキュアでなければならないことを示していなければなりません。監査目的のために、ソフトウェアはすべてのセキュリティに関連した構成詳細を示している簡単に読めるレポートをつくることができなければなりません。

;(j) 特定の脆弱性 : 要求は、ソフトウェアで見つかってはならない一組の具体的な脆弱性を含まなければなりません。指定されていないならば、ソフトウェアは現在の「OWASP Top Ten Most Critical Web Application Vulnerabilities」で記述される瑕疵の何も含んではいけません。

===5. 要員および組織===

;(a) セキュリティ・アーキテクト : 開発者は一つの上位の技術的な資源に責任をセキュリティに指定します。そして、プロジェクトのセキュリティ・アーキテクトとして知られています。セキュリティ・アーキテクトは、各々の納品可能なもののセキュリティを保証します。

;(b) セキュリティ・トレーニング : 開発者は、開発者チームのすべてのメンバーがセキュアなプログラミング技法の訓練をされたことを確かめる役割を果たします。

;(c) 信用できる開発者 : 開発者は、すべての開発チーム・メンバーの適切な経歴調査を実行することに同意します。

===6.開発環境===

;(a) セキュア・コーディング : 開発者は、どんなツールがセキュアなコーディングを促すためにソフトウェア開発環境で使われるかについて明らかにしなければなりません。

;(b) 構成管理 : 開発者は、ソフトウェア・ベースラインに対するすべての変更とすべての関連した設定とビルド・ファイルを関連づけ　とすべての関連した構成にすべての変化と関連したチーム・メンバーを認証して、記録して、ファイルを構築したソース・コード管理システムを使用しなければなりません。

;(c) 配布 : 開発者は、ソースから確実に完全な配布を構築するビルド・プロセスを使用しなければなりません。このプロセスは、顧客に供給されるソフトウェアの完全性を確かめる方法を含まなければなりません。

===7. ライブラリ、フレームワーク、および生産物===

;(a) 開示 : 開発者は、商用、フリー、オープンソース、クローズソースであるにせよ、すべてのライブラリ、フレームワーク、構成要素と他の生産物を含む、ソフトウェアで使われるすべての第三者のソフトウェアを明らかにしなければなりません。

;(b) 評価 : 開発者は、第三者のソフトウェアがこの契約のすべての条件を満たして、この契約の基で開発されたカスタム開発されたコードと同じくらいセキュアなことを確実とするために、理にかなった努力をしなければなりません。

===8. セキュリティ・レビュー===

;(a) レビューする権利 : 依頼人には、ソフトウェアを納品の60日間以内にいつでも彼らの費用でセキュリティ瑕疵のためにレビューしておく権利があります。開発者は、ソース・コードとテスト環境へのアクセスを提供することによって理にかなったサポートをレビュー・チームに提供することに同意します。

;(b) レビュー・カバレッジ : セキュリティ・レビューは供給されるソフトウェアのすべての面をカバーしなければなりません。そして、カスタム・コード、構成要素、生産物とシステム設定を含みます。

;(c) レビューの範囲 : 最低限で、レビューはセキュリティ要求の全てをカバーしなければならなくて、他の一般的な脆弱性を捜さなければなりません。レビューは、脆弱性スキャン、侵入テスト、ソースコードの静的分析と専門家のコードレビューの組み合わせを含んでもよいです。

;(d) 見つけられた問題 : 発見されたセキュリティ問題は、顧客と開発者に報告されます。すべての問題は、この付属書のセキュリティ問題マネジメント部分により追跡されて、矯正されます。

===9. セキュリティ問題マネジメント ===

;(a) 識別 : 要求、設計、実装、テスト、配備、または、運用中の問題にせよ、開発者は全てのライフサイクルの間に発見されるすべてのセキュリティ問題を追います。各々のセキュリティ問題に関連したリスクは、発見後できるだけ早く、評価されて、文書化されて、発見の後、顧客に報告されます。

;(b) 保護 : 開発者はセキュリティ問題と付随する文書に関して情報を適切に保護します。そして、運用中の顧客ソフトウェアの脆弱性が露出するという可能性を制限するのを助けます。

;(c) 改善 : 納品の前に確認されるセキュリティ問題は、開発者によって修正されなければなりません。納品の後に発見されるセキュリティ問題は、本契約の規定による他のバグと問題として同様に取り扱われなければなりません。

===10. 保証===

;(a) 保証 : 開発者は、開発プロセスを通して作成されるセキュリティ文書からなる「証明パッケージ」を提供します。パッケージは、セキュリティ要求、設計、実装と試験結果がきちんと完了された、そして、すべてのセキュリティ問題が適切に解決されたと確認しなければなりません。

;(b) 自己証明 : セキュリティ・アーキテクトは、ソフトウェアがセキュリティ要求を満たすこと、すべてのセキュリティ活動が実行されていること、そして、すべての識別されたセキュリティ問題が文書化されて、解決されたことを証明します。証明ステータスに対するあらゆる例外は、納品で完全に文書化されなければなりません。

;(c) 悪意のあるコードのなし : 開発者は、ソフトウェアがソフトウェア要求をサポートせず、コンピュータ・ウイルス、ワーム、時限爆弾、バック・ドア、トロイの木馬、イースターエッグと他のあらゆる形の悪意のあるソフトウェアを含む、アプリケーションのセキュリティを弱めるあらゆるコードを含んではならないと保証します。

===11. セキュリティ承認と保守 ===

;(a) 受け入れ : 証明パッケージが完全であり、すべてのセキュリティ問題が解決されるまで、ソフトウェアは受け入れられると考慮されてはいけません。

;(b) セキュリティ問題の調査 : 受理の後、セキュリティ問題が発見されるか、かなり疑われるならば、開発者は顧客が問題の性質を決定するために調査を実行するのを援助しなければなりません。それがセキュリティ要求によってカバーされないで、セキュリティ・テストの理にかなった範囲の外にあるならば、問題は「新しい」と思われなければなりません。

;(c) 新しいセキュリティ問題 : 開発者と顧客は、新しいセキュリティ問題を解決するために必要な努力を探し出すことに同意します。また、それらに取り組むために必要とされる仕事を実行するための合意を達成するために誠意を持って交渉することに同意します。

;(d) 他のセキュリティ問題 : 開発者は堅実なソフトウェア開発慣行。そして、リスクのひどさを考慮すること、そして、できるだけ速く新しいと思われないすべてのセキュリティ問題を解決することと一致したすべての商業的に理にかなった努力を使わなければなりません

[[Category:OWASP Legal Project]]

__NOTOC__

Category:OWASP Legal Project

2011-07-04T10:15:44Z

Tomo: Add * Contract Annex in Japanese.

==== Home ====

{| width="100%"
|-
! width="66%" |
! width="33%" |
|- valign="top"
|
The goal of the '''OWASP Legal Project''' is to ensure, at each stage of the life cycle, that appropriate attention has been paid to security. The cornerstone of the Legal Project is its Secure Software Development Contract Annex. The Contract Annex helps software developers and their clients negotiate and capture important contractual terms and conditions related to the security of the software to be developed or delivered. Here are two examples:

* '''Implementation.''' Developer agrees to provide and follow a set of secure coding guidelines and to use a set of common security control programming interfaces (such as the [http://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API OWASP ESAPI]). Guidelines will indicate how code should be formatted, structured, and commented. Common security control programming interfaces will define how security controls must be called and how security controls shall function. All security-relevant code shall be thoroughly commented. Specific guidance on avoiding common security vulnerabilities shall be included. Also, all code shall be reviewed by at least one other Developer against the security requirements and coding guideline before it is considered ready for unit test.
* '''Security Analysis and Testing.''' Developer will perform application security analysis and testing (also called "verification") according to the verification requirements of an agreed-upon standard (such as the [http://www.owasp.org/index.php/ASVS OWASP ASVS]). The Developer shall document verification findings according to the reporting requirements of the standard. The Developer shall provide the verification findings to Client.
|
[[Image:Esapi-sponsors.PNG]]

|}

{| width="100%"
|-
! width="33%" |
! width="33%" |
! width="33%" |
|- valign="top"
|
== Let's talk here ==

[[Image:Asvs-bulb.jpg]]'''Legal Communities'''

Further development of Legal Project documents occurs through mailing list discussions and occasional workshops, and suggestions for improvement are welcome. For more information, please [mailto:jeff.williams@owasp.org contact us].

*[https://lists.owasp.org/mailman/listinfo/owasp-legal owasp-legal mailing list (this is the main list)]

|
== Got translation cycles? ==

[[Image:Asvs-writing.JPG]]'''Legal Project Translations'''

The Legal Project project is always on the lookout for volunteers who are interested in translating Legal Project documents into another language.

*Translation Onboarding Instructions -- Coming soon!

|
== Related resources ==

[[Image:Asvs-satellite.jpg]]'''OWASP Resources'''

* [[Top Ten|OWASP Top Ten]]
* [[ASVS|OWASP Application Security Verification Standard]]
*[http://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API OWASP ESAPI]
*[http://www.owasp.org/index.php/Category:OWASP_Newsletter#tab=Press_releases OWASP Press Releases]
|}

==== Downloads ====

{| width="100%"
|-
! width="33%" |
! width="33%" |
|- valign="top"
|
[[Image:Asvs-step1.jpg]]'''1. About Legal Project Documents'''

* One Page Datasheet ([http://www.owasp.org/images/a/aa/Legal_One_Page_Handout.doc Word], [http://www.owasp.org/index.php/Image:Legal_One_Page_Handout.pdf PDF])
* One Page Datasheet in Japanese ([https://www.owasp.org/index.php/File:Legal_One_Page_Handout-ja.pdf PDF])

[[Image:Asvs-step2.jpg]]'''2. Get Legal Project Documents'''

* Contract Annex in English ([http://www.owasp.org/index.php/Image:OWASP_Secure_Software_Contract_Annex.doc Word], [http://www.owasp.org/index.php/OWASP_Secure_Software_Contract_Annex HTML])
* Contract Annex in Spanish ([http://www.owasp.org/index.php/Anexo_para_Contrato_de_Software_Seguro_de_OWASP HTML])
* Contract Annex in Japanese ([https://www.owasp.org/index.php/OWASP_Secure_Software_Contract_Annex/ja HTML])
* Verification schedule in English ([http://www.owasp.org/index.php/Image:Sample_ASVS_Fee_Schedule_Template.xls Excel])

{{OWASP Book|4037498}}

[[Image:Asvs-step3.jpg]]'''3. Learn About Legal Project Documents'''

* Coming soon!

|}

 

==== Glossary ====

[[Image:Asvs-letters.jpg]]'''Legal Project Terminology'''

* Coming soon!

==== Project Details ====
{{:GPC_Project_Details/OWASP_Legal_Project | OWASP Project Identification Tab}}

__NOTOC__ <headertabs /> ''This project licensed under the [http://creativecommons.org/licenses/by-sa/3.0/ Creative Commons Attribution ShareAlike 3.0].''

Category:OWASP Legal Project

2011-07-04T10:08:39Z

Tomo: Add * One Page Datasheet in Japanese.

==== Home ====

{| width="100%"
|-
! width="66%" |
! width="33%" |
|- valign="top"
|
The goal of the '''OWASP Legal Project''' is to ensure, at each stage of the life cycle, that appropriate attention has been paid to security. The cornerstone of the Legal Project is its Secure Software Development Contract Annex. The Contract Annex helps software developers and their clients negotiate and capture important contractual terms and conditions related to the security of the software to be developed or delivered. Here are two examples:

* '''Implementation.''' Developer agrees to provide and follow a set of secure coding guidelines and to use a set of common security control programming interfaces (such as the [http://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API OWASP ESAPI]). Guidelines will indicate how code should be formatted, structured, and commented. Common security control programming interfaces will define how security controls must be called and how security controls shall function. All security-relevant code shall be thoroughly commented. Specific guidance on avoiding common security vulnerabilities shall be included. Also, all code shall be reviewed by at least one other Developer against the security requirements and coding guideline before it is considered ready for unit test.
* '''Security Analysis and Testing.''' Developer will perform application security analysis and testing (also called "verification") according to the verification requirements of an agreed-upon standard (such as the [http://www.owasp.org/index.php/ASVS OWASP ASVS]). The Developer shall document verification findings according to the reporting requirements of the standard. The Developer shall provide the verification findings to Client.
|
[[Image:Esapi-sponsors.PNG]]

|}

{| width="100%"
|-
! width="33%" |
! width="33%" |
! width="33%" |
|- valign="top"
|
== Let's talk here ==

[[Image:Asvs-bulb.jpg]]'''Legal Communities'''

Further development of Legal Project documents occurs through mailing list discussions and occasional workshops, and suggestions for improvement are welcome. For more information, please [mailto:jeff.williams@owasp.org contact us].

*[https://lists.owasp.org/mailman/listinfo/owasp-legal owasp-legal mailing list (this is the main list)]

|
== Got translation cycles? ==

[[Image:Asvs-writing.JPG]]'''Legal Project Translations'''

The Legal Project project is always on the lookout for volunteers who are interested in translating Legal Project documents into another language.

*Translation Onboarding Instructions -- Coming soon!

|
== Related resources ==

[[Image:Asvs-satellite.jpg]]'''OWASP Resources'''

* [[Top Ten|OWASP Top Ten]]
* [[ASVS|OWASP Application Security Verification Standard]]
*[http://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API OWASP ESAPI]
*[http://www.owasp.org/index.php/Category:OWASP_Newsletter#tab=Press_releases OWASP Press Releases]
|}

==== Downloads ====

{| width="100%"
|-
! width="33%" |
! width="33%" |
|- valign="top"
|
[[Image:Asvs-step1.jpg]]'''1. About Legal Project Documents'''

* One Page Datasheet ([http://www.owasp.org/images/a/aa/Legal_One_Page_Handout.doc Word], [http://www.owasp.org/index.php/Image:Legal_One_Page_Handout.pdf PDF])
* One Page Datasheet in Japanese ([https://www.owasp.org/index.php/File:Legal_One_Page_Handout-ja.pdf PDF])

[[Image:Asvs-step2.jpg]]'''2. Get Legal Project Documents'''

* Contract Annex in English ([http://www.owasp.org/index.php/Image:OWASP_Secure_Software_Contract_Annex.doc Word], [http://www.owasp.org/index.php/OWASP_Secure_Software_Contract_Annex HTML])
* Contract Annex in Spanish ([http://www.owasp.org/index.php/Anexo_para_Contrato_de_Software_Seguro_de_OWASP HTML])
* Verification schedule in English ([http://www.owasp.org/index.php/Image:Sample_ASVS_Fee_Schedule_Template.xls Excel])

{{OWASP Book|4037498}}

[[Image:Asvs-step3.jpg]]'''3. Learn About Legal Project Documents'''

* Coming soon!

|}

 

==== Glossary ====

[[Image:Asvs-letters.jpg]]'''Legal Project Terminology'''

* Coming soon!

==== Project Details ====
{{:GPC_Project_Details/OWASP_Legal_Project | OWASP Project Identification Tab}}

__NOTOC__ <headertabs /> ''This project licensed under the [http://creativecommons.org/licenses/by-sa/3.0/ Creative Commons Attribution ShareAlike 3.0].''

File:Legal One Page Handout-ja.pdf

2011-07-04T10:01:35Z

Tomo:

Guide to Cryptography

2008-04-06T05:07:04Z

Tomo: /* Cryptography */

[[Guide Table of Contents]]__TOC__

==Objective ==

To ensure that cryptography is safely used to protect the confidentiality and integrity of sensitive user data

==Platforms Affected ==

All.

==Relevant COBIT Topics ==

DS5.18 – Cryptographic key management

==Description ==

Initially confined to the realms of academia and the military, cryptography has become ubiquitous thanks to the Internet. Common every day uses of cryptography include mobile phones, passwords, SSL, smart cards, and DVDs. Cryptography has permeated everyday life, and is heavily used by many web applications.

Cryptography (or crypto) is one of the more advanced topics of information security, and one whose understanding requires the most schooling and experience. It is difficult to get right because there are many approaches to encryption, each with advantages and disadvantages that need to be thoroughly understood by web solution architects and developers. In addition, serious cryptography research is typically based in advanced mathematics and number theory, providing a serious barrier to entry.

The proper and accurate implementation of cryptography is extremely critical to its efficacy. A small mistake in configuration or coding will result in removing a large degree of the protection it affords and rending the crypto implementation useless against serious attacks.

A good understanding of crypto is required to be able to discern between solid products and snake oil. The inherent complexity of crypto makes it easy to fall for fantastic claims from vendors about their product. Typically, these are “a breakthrough in cryptography” or “unbreakable” or provide "military grade" security. If a vendor says "trust us, we have had experts look at this,” chances are they weren't experts!

==Cryptographic Functions ==

Cryptographic systems can provide one or more of the following four services. It is important to distinguish between these, as some algorithms are more suited to particular tasks, but not to others.

When analyzing your requirements and risks, you need to decide which of these four functions should be used to protect your data.

===Authentication ===

Using a cryptographic system, we can establish the identity of a remote user (or system). A typical example is the SSL certificate of a web server providing proof to the user that he or she is connected to the correct server.

The identity is not of the user, but of the cryptographic key of the user. Having a less secure key lowers the trust we can place on the identity.

===Non-Repudiation ===

The concept of non-repudiation is particularly important for financial or e-commerce applications. Often, cryptographic tools are required to prove that a unique user has made a transaction request. It must not be possible for the user to refute his or her actions.

For example, a customer may request a transfer of money from her account to be paid to another account. Later, she claims never to have made the request and demands the money be refunded to the account. If we have non-repudiation through cryptography, we can prove – usually through digitally signing the transaction request, that the user authorized the transaction.

===Confidentiality ===

More commonly, the biggest concern will be to keep information private. Cryptographic systems were originally developed to function in this capacity. Whether it be passwords sent during a log on process, or storing confidential medical records in a database, encryption can assure that only users who have access to the appropriate key will get access to the data.

===Integrity ===

We can use cryptography to provide a means to ensure data is not viewed or altered during storage or transmission. Cryptographic hashes for example, can safeguard data by providing a secure checksum.

==Cryptographic Algorithms ==

Various types of cryptographic systems exist that have different strengths and weaknesses. Typically, they are divided into two classes; those that are strong, but slow to run and those that are quick, but less secure. Most often a combination of the two approaches is used (e.g.: SSL), whereby we establish the connection with a secure algorithm, and then if successful, encrypt the actual transmission with the weaker, but much faster algorithm.

===Symmetric Cryptography ===

Symmetric Cryptography is the most traditional form of cryptography. In a symmetric cryptosystem, the involved parties share a common secret (password, pass phrase, or key). Data is encrypted and decrypted using the same key. These algorithms tend to be comparatively fast, but they cannot be used unless the involved parties have already exchanged keys. Any party possessing a specific key can create encrypted messages using that key as well as decrypt any messages encrypted with the key. In systems involving a number of users who each need to set up independent, secure communication channels symmetric cryptosystems can have practical limitations due to the requirement to securely distribute and manage large numbers of keys.

Common examples of symmetric algorithms are DES, 3DES and AES. The 56-bit keys used in DES are short enough to be easily brute-forced by modern hardware and DES should no longer be used. Triple DES (or 3DES) uses the same algorithm, applied three times with different keys giving it an effective key length of 128 bits. Due to the problems using the DES alrgorithm, the United States National Institute of Standards and Technology (NIST) hosted a selection process for a new algorithm. The winning algorithm was Rijndael and the associated cryptosystem is now known as the Advanced Encryption Standard or AES. For most applications 3DES is acceptably secure at the current time, but for most new applications it is advisable to use AES.

===Asymmetric Cryptography (also called Public/Private Key Cryptography) ===

Asymmetric algorithms use two keys, one to encrypt the data, and either key to decrypt. These inter-dependent keys are generated together. One is labeled the Public key and is distributed freely. The other is labeled the Private Key must be kept hidden.

Often referred to as Public/Private Key Cryptography, these cryptosystems can provide a number of different functions depending on how they are used.

The most common usage of asymmetric cryptography is to send messages with a guarantee of confidentiality. If User A wanted to send a message to User B, User A would get access to User B’s publicly-available Public Key. The message is then encrypted with this key and sent to User B. Because of the cryptosystem’s property that messages encoded with the Public Key of User B can only be decrypted with User B’s Private Key, only User B can read the message.

Another usage scenario is one where User A wants to send User B a message and wants User B to have a guarantee that the message was sent by User A. In order to accomplish this, User A would encrypt the message with their Private Key. The message can then only be decrypted using User A’s Public Key. This guarantees that User A created the message Because they are then only entity who had access to the Private Key required to create a message that can be decrcrypted by User A’s Public Key. This is essentially a digital signature guaranteeing that the message was created by User A.

A Certificate Authority (CA), whose public certificates are installed with browsers or otherwise commonly available, may also digitally sign public keys or certificates. We can authenticate remote systems or users via a mutual trust of an issuing CA. We trust their ‘root’ certificates, which in turn authenticate the public certificate presented by the server.

PGP and SSL are prime examples of a systems implementing asymmetric cryptography, using RSA or other algorithms.

===Hashes ===

Hash functions take some data of an arbitrary length (and possibly a key or password) and generate a fixed-length hash based on this input. Hash functions used in cryptography have the property that it is easy to calculate the hash, but difficult or impossible to re-generate the original input if only the hash value is known. In addition, hash functions useful for cryptography have the property that it is difficult to craft an initial input such that the hash will match a specific desired value.

MD5 and SHA-1 are common hashing algorithms used today. These algorithms are considered weak (see below) and are likely to be replaced after a process similar to the AES selection. New applications should consider using SHA-256 instead of these weaker algorithms.

===Key Exchange Algorithms ===

Lastly, we have key exchange algorithms (such as Diffie-Hellman for SSL). These allow use to safely exchange encryption keys with an unknown party.

==Algorithm Selection ==

As modern cryptography relies on being computationally expensive to break, specific standards can be set for key sizes that will provide assurance that with today’s technology and understanding, it will take too long to decrypt a message by attempting all possible keys.

Therefore, we need to ensure that both the algorithm and the key size are taken into account when selecting an algorithm.

===How to determine if you are vulnerable ===

Proprietary encryption algorithms are not to be trusted as they typically rely on ‘security through obscurity’ and not sound mathematics. These algorithms should be avoided if possible.

Specific algorithms to avoid:

* MD5 has recently been found less secure than previously thought. While still safe for most applications such as hashes for binaries made available publicly, secure applications should now be migrating away from this algorithm.

* SHA-0 has been conclusively broken. It should no longer be used for any sensitive applications.

* SHA-1 has been reduced in strength and we encourage a migration to SHA-256, which implements a larger key size.

* DES was once the standard crypto algorithm for encryption; a normal desktop machine can now break it. AES is the current preferred symmetric algorithm.

Cryptography is a constantly changing field. As new discoveries in cryptanalysis are made, older algorithms will be found unsafe. In addition, as computing power increases the feasibility of brute force attacks will render other cryptosystems or the use of certain key lengths unsafe. Standard bodies such as NIST should be monitored for future recommendations.

Specific applications, such as banking transaction systems may have specific requirements for algorithms and key sizes.

===How to protect yourself ===

Assuming you have chosen an open, standard algorithm, the following recommendations should be considered when reviewing algorithms:

'''Symmetric:'''

* Key sizes of 128 bits (standard for SSL) are sufficient for most applications

* Consider 168 or 256 bits for secure systems such as large financial transactions

'''Asymmetric:'''

The difficulty of cracking a 2048 bit key compared to a 1024 bit key is far, far, far, more than the twice you might expect. Don’t use excessive key sizes unless you know you need them. Bruce Schneier in 2002 (see the references section) recommended the following key lengths for circa 2005 threats:

* Key sizes of 1280 bits are sufficient for most personal applications

* 1536 bits should be acceptable today for most secure applications

* 2048 bits should be considered for highly protected applications.

'''Hashes:'''

* Hash sizes of 128 bits (standard for SSL) are sufficient for most applications

* Consider 168 or 256 bits for secure systems, as many hash functions are currently being revised (see above).

NIST and other standards bodies will provide up to date guidance on suggested key sizes.

'''Design your application to cope with new hashes and algorithms'''

==Key Storage ==

As highlighted above, crypto relies on keys to assure a user’s identity, provide confidentiality and integrity as well as non-repudiation. It is vital that the keys are adequately protected. Should a key be compromised, it can no longer be trusted.

Any system that has been compromised in any way should have all its cryptographic keys replaced.

===How to determine if you are vulnerable ===

Unless you are using hardware cryptographic devices, your keys will most likely be stored as binary files on the system providing the encryption.

Can you export the private key or certificate from the store?

* Are any private keys or certificate import files (usually in PKCS#12 format) on the file system? Can they be imported without a password?

* Keys are often stored in code. This is a bad idea, as it means you will not be able to easily replace keys should they become compromised.

===How to protect yourself ===

* Cryptographic keys should be protected as much as is possible with file system permissions. They should be read only and only the application or user directly accessing them should have these rights.

* Private keys should be marked as not exportable when generating the certificate signing request.

* Once imported into the key store (CryptoAPI, Certificates snap-in, Java Key Store, etc), the private certificate import file obtained from the certificate provider should be safely destroyed from front-end systems. This file should be safely stored in a safe until required (such as installing or replacing a new front end server)

* Host based intrusion systems should be deployed to monitor access of keys. At the very least, changes in keys should be monitored.

* Applications should log any changes to keys.

* Pass phrases used to protect keys should be stored in physically secure places; in some environments, it may be necessary to split the pass phrase or password into two components such that two people will be required to authorize access to the key. These physical, manual processes should be tightly monitored and controlled.

* Storage of keys within source code or binaries should be avoided. This not only has consequences if developers have access to source code, but key management will be almost impossible.

* In a typical web environment, web servers themselves will need permission to access the key. This has obvious implications that other web processes or malicious code may also have access to the key. In these cases, it is vital to minimize the functionality of the system and application requiring access to the keys.

* For interactive applications, a sufficient safeguard is to use a pass phrase or password to encrypt the key when stored on disk. This requires the user to supply a password on startup, but means the key can safely be stored in cases where other users may have greater file system privileges.

Storage of keys in hardware crypto devices is beyond the scope of this document. If you require this level of security, you should really be consulting with crypto specialists.

==Insecure transmission of secrets ==

In security, we assess the level of trust we have in information. When applied to transmission of sensitive data, we need to ensure that encryption occurs before we transmit the data onto any untrusted network.

In practical terms, this means we should aim to encrypt as close to the source of the data as possible.

===How to determine if you are vulnerable ===

This can be extremely difficult without expert help. We can try to at least eliminate the most common problems:

* The encryption algorithm or protocol needs to be adequate to the task. The above discuss on weak algorithms and weak keys should be a good starting point

* We must ensure that through all paths of the transmission we apply this level of encryption

* Extreme care needs to be taken at the point of encryption and decryption. If your encryption library needs to use temporary files, are these adequately protected?

* Are keys stored securely? Is an unsecured file left behind after it has been encrypted?

===How to protect yourself ===

We have the possibility to encrypt or otherwise protect data at different levels. Choosing the right place for this to occur can involve looking at both security as well as resource requirements.

'''Application''': at this level, the actual application performs the encryption or other crypto function. This is the most desirable, but can place additional strain on resources and create unmanageable complexity. Encryption would be performed typically through an API such as the OpenSSL toolkit (www.openssl.com) or operating system provided crypto functions.

An example would be an S/MIME encrypted email, which is transmitted as encoded text within a standard email. No changes to intermediate email hosts are necessary to transmit the message because we do not require a change to the protocol itself.

'''Protocol''': at this layer, the protocol provides the encryption service. Most commonly, this is seen in HTTPS, using SSL encryption to protect sensitive web traffic. The application no longer needs to implementing secure connectivity. However, this does not mean the application has a free ride. SSL requires careful attention when used for mutual (client-side) authentication, as there are two different session keys, one for each direction. Each should be verified before transmitting sensitive data.

Attackers and penetration testers love SSL to hide malicious requests (such as injection attacks for example). Content scanners are most likely unable to decode the SSL connection, letting it pass to the vulnerable web server.

'''Network''': below the protocol layer, we can use technologies such as Virtual Private Networks (VPN) to protect data. This has many incarnations, the most popular being IPsec (Internet Protocol v6 Security), typically implemented as a protected ‘tunnel’ between two gateway routers. Neither the application nor the protocol needs to be crypto aware – all traffic is encrypted regardless.

Possible issues at this level are computational and bandwidth overheads on network devices.

==Reversible Authentication Tokens ==

Today’s web servers typically deal with large numbers of users. Differentiating between them is often done through cookies or other session identifiers. If these session identifiers use a predictable sequence, an attacker need only generate a value in the sequence in order to present a seemingly valid session token.

This can occur at a number of places; the network level for TCP sequence numbers, or right through to the application layer with cookies used as authenticating tokens.

===How to determine if you are vulnerable ===

Any deterministic sequence generator is likely to be vulnerable.

===How to protect yourself ===

The only way to generate secure authentication tokens is to ensure there is no way to predict their sequence. In other words: true random numbers.

It could be argued that computers can not generate true random numbers, but using new techniques such as reading mouse movements and key strokes to improve entropy has significantly increased the randomness of random number generators. It is critical that you do not try to implement this on your own; use of existing, proven implementations is highly desirable.

Most operating systems include functions to generate random numbers that can be called from almost any programming language.

'''Windows & .NET:''' On Microsoft platforms including .NET, it is recommended to use the inbuilt CryptGenRandom function (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/seccrypto/security/cryptgenrandom.asp.

'''Unix:''' For all Unix based platforms, OpenSSL is an excellent option (http://www.openssl.org/). It features tools and API functions to generate random numbers. On some platforms, /dev/urandom is a suitable source of pseudo-random entropy.

'''PHP:''' mt_rand() uses a Mersenne Twister, but is nowhere near as good as CryptoAPI’s secure random number generation options, OpenSSL, or /dev/urandom which is available on many Unix variants. mt_rand() has been noted to produce the same number on some platforms – test prior to deployment. '''Do not use rand() as it is very weak.'''

'''Java:''' java.security.SecureRandom within the Java Cryptography Extension (JCE) provides secure random numbers. This should be used in preference to other random number generators.

'''ColdFusion: '''ColdFusion MX 7 leverages the JCE java.security.SecureRandom class of the underlying JVM as its pseudo random number generator (PRNG)'''''.'' '''

==Safe UUID generation ==

UUIDs (such as GUIDs and so on) are only unique if you generate them. This seems relatively straightforward. However, there are many code snippets available that contain existing UUIDS.

===How to determine if you are vulnerable ===

# Determine the source of your existing UUIDS
## Did they come from MSDN?
## Or from a example found on the Internet?
# Use your favorite search engine to find out

===How to protect yourself ===

* Do not cut and paste UUIDs and GUIDs from anything other than the UUIDGEN program or from the UuidCreate() API

* Generate fresh UUIDs or GUIDs for each new program

==Summary ==

Cryptography is one of pillars of information security. Its usage and propagation has exploded due to the Internet and it is now included in most areas computing. Crypto can be used for:

* Remote access such as IPsec VPN

* Certificate based authentication

* Securing confidential or sensitive information

* Obtaining non-repudiation using digital certificates

* ?Online orders and payments

* Email and messaging security such as S/MIME

A web application can implement cryptography at multiple layers: application, application server or runtime (such as .NET), operating system and hardware. Selecting an optimal approach requires a good understanding of application requirements, the areas of risk, and the level of security strength it might require, flexibility, cost, etc.

Although cryptography is not a panacea, the majority of security breaches do not come from brute force computation but from exploiting mistakes in implementation. The strength of a cryptographic system is measured in key length. Using a large key length and then storing the unprotected keys on the same server, eliminates most of the protection benefit gained. Besides the secure storage of keys, another classic mistake is engineering custom cryptographic algorithms (to generate random session ids for example). Many web applications were successfully attacked because the developers thought they could create their crypto functions.

Our recommendation is to use proven products, tools, or packages rather than rolling your own.

==Further Reading ==

* Wu, H., ''Misuse of stream ciphers in Word and Excel''

http://eprint.iacr.org/2005/007.pdf

* Bindview, ''Vulnerability in Windows NT's SYSKEY encryption''

http://www.bindview.com/Services/razor/Advisories/1999/adv_WinNT_syskey.cfm

* Schneier, B. ''Is 1024 bits enough?, ''April 2002 Cryptogram''

''http://www.schneier.com/crypto-gram-0204.html#3

* Schneier, B., Cryptogram,

http://www.counterpane.com/cryptogram.html

* NIST, Replacing SHA-1 with stronger variants: SHA-256 ? 512

http://csrc.nist.gov/CryptoToolkit/tkhash.html

http://csrc.nist.gov/CryptoToolkit/tkencryption.html

* UUIDs are only unique if you generate them:

http://blogs.msdn.com/larryosterman/archive/2005/07/21/441417.aspx

* Cryptographically Secure Random Numbers on Win32:

http://blogs.msdn.com/michael_howard/archive/2005/01/14/353379.aspx

==Cryptography ==

The following section describes the ColdFusion’s cryptography features. ColdFusion MX leverages the Java Cryptography Extension (JCE) of the underlying J2EE platform for cryptography and random number generation. It provides functions for symmetric (or private-key) encryption. While it does not provide native functionality for public-key (asymmetric) encryption, it does use the Java Secure Socket Extension (JSSE) for SSL communication.

'''Pseudo-Random Number Generation'''

ColdFusion provides three functions for random number generation: rand(), randomize(), and randRange(). Function descriptions and syntax:

'''Rand''' – Use to generate a pseudo-random number

''' rand([algorithm])'''

'''Randomize''' – Use to seed the pseudo-random number generator (PRNG) with an integer.

''' randomize(number [, algorithm])'''

'''RandRange''' – Use to generate a pseudo-random integer within the range of the specified numbers

''' randrange(number1, number2 [, algorithm])'''

The following values are the allowed algorithm parameters''' ''':

CFMX_COMPAT: (default) – Invokes java.util.rand

SHA1PRNG: (recommended) – Invokes java.security.SecureRandom using the Sun Java SHA-1 PRNG algorithm.

IBMSecureRandom: IBM WebSphere’s JVM does not support the SHA1PRNG algorithm.

'''Symmetric Encryption'''

ColdFusion MX 7 provides six encryption functions: decrypt(), decryptBinary(), encrypt(), encryptBinary(), generateSecretKey(), and hash(). Function descriptions and syntax:

'''Decrypt''' – Use to decrypt encrypted strings with specified key, algorithm, encoding, initialization vector or salt, and iterations

''' decrypt(encrypted_string, key[, algorithm[, encoding[, IVorSalt[, iterations]]]]))'''

'''DecryptBinary''' – Use to decrypt encrypted binary data with specified key, algorithm, initialization vector or salt, and iterations

''' decryptBinary(bytes, key[, algorithm[, IVorSalt[, iterations]]])'''

'''Encrypt''' – Use to encrypt string using specific algorithm, encoding, initialization vector or salt, and iterations

''' encrypt(string, key[, algorithm[, encoding[, IVorSalt[, iterations]]]]))'''

'''EncryptBinary''' – Use to encrypt binary data with specified key, algorithm, initialization vector or salt, and iterations

''' encryptBinary(bytes, key[, algorithm[, IVorSalt[, iterations]]])'''

'''GenerateSecretKey''' – Use to generate a secure key using the specified algorithm for the encrypt and encryptBinary functions

''' generateSecretKey(algorithm)'''

'''Hash '''– Use for one-way conversion of a variable-length string to fixed-length string using the specified algorithm and encoding

''' hash(string[, algorithm[, encoding]] )'''

ColdFusion offers the following default algorithms for these functions''' ''':

CFMX_COMPAT: the algorithm used in ColdFusion MX and prior releases. This algorithm is the least secure option (default).

AES: the Advanced Encryption Standard specified by the National Institute of Standards and Technology (NIST) FIPS-197. (recommended)

BLOWFISH: the Blowfish algorithm defined by Bruce Schneier.

DES: the Data Encryption Standard algorithm defined by NIST FIPS-46-3.

DESEDE: the "Triple DES" algorithm defined by NIST FIPS-46-3.

PBEWithMD5AndDES: A password-based version of the DES algorithm which uses a MD5 hash of the specified password as the encryption key

PBEWithMD5AndTripleDES: A password-based version of the DESEDE algorithm which uses a MD5 hash of the specified password as the encryption key

The following algorithms are provided by default for the hash() function. Note, SHA algorithms used in ColdFusion are NIST FIPS-180-2 compliant''' ''':

CFMX_COMPAT: Generates a MD5 hash string identical to that generated by ColdFusion MX and ColdFusion MX 6.1 (default).

MD5: Generates a 128-bit digest.

SHA: Generates a 160-bit digest. (SHA-1)

SHA-256: Generates a 256-bit digest

SHA-384: Generates a 384-bit digest

SHA-512: Generates a 512-bit digest

'''Pluggable Encryption'''

ColdFusion MX 7 introduced pluggable encryption for CFML. The JCE allows developers to specify multiple cryptographic service providers. ColdFusion can leverage the algorithms, feedback modes, and padding methods of third-party Java security providers to strengthen its cryptography functions. For example, ColdFusion can leverage the Bouncy Castle ('''http://www.bouncycastle.org/''') crypto package and use the SHA-224 algorithm for the hash() function or the Serpent block encryption for the encrypt() function.

See Macromedia’s Strong Encryption in ColdFusion MX 7 technote for information on installing additional security providers for ColdFusion at http://www.macromedia.com/go/e546373d.

'''SSL'''

ColdFusion does not provide tags and functions for public-key encryption, but it can communicate over SSL. ColdFusion leverages the Sun JSSE to communicate over SSL with web and LDAP (lightweight directory access protocol) servers. ColdFusion uses the Java certificate database (e.g. jre_root/lib/security/cacerts) to store server certificates. It compares presented certificate of remote systems to those stored in the database. It also grabs the host system’s certificate from this database and uses it to present to remote systems to initiate the SSL handshake. Certificate information is then exposed as CGI variables.

'''''Best Practices'''''

Enable /dev/urandom for higher entropy for random number generation

Call the randomize function before calling rand() or randRange() to seed the random number generator

DO NOT use the CFMX_COMPAT algorithms. Upgrade your application to use stronger cryptographic ciphers.

Use AES or higher for symmetric encryption

Use SHA-256 or higher for the hash function

Use a salt (or random string) for password generation with the hash function

Always use generateSecretKey() to generate keys of the appropriate length for Block Encryption algorithms unless a customized key is required

Use separate key databases to store remote server certificates separately from the ColdFusion server’s certificate

[[Guide Table of Contents]]
[[Category:OWASP_Guide_Project]]
[[Category:Encryption]]

Data Validation

2008-04-06T05:04:09Z

Tomo: /* ASP.NET Viewstate */

[[Guide Table of Contents]]__TOC__

==Objective ==

To ensure that the application is robust against all forms of input data, whether obtained from the user, infrastructure, external entities or database systems

==Platforms Affected ==

All.

==Relevant COBIT Topics ==

DS11 – Manage Data. All sections should be reviewed

==Description ==

The most common web application security weakness is the failure to properly validate input from the client or environment. This weakness leads to almost all of the major vulnerabilities in applications, such as interpreter injection, locale/Unicode attacks, file system attacks and buffer overflows. Data from the client should never be trusted for the client has every possibility to tamper with the data.

In many cases, [[Encoding]] has the potential to defuse attacks that rely on lack of input validation. For example, if you use HTML entity encoding on user input before it is sent to a browser, it will prevent most [[XSS]] attacks. However, simply preventing attacks is not enough - you must perform [[Intrusion Detection]] in your applications. Otherwise, you are allowing attackers to repeatedly attack your application until they find a vulnerability that you haven't protected against. Detecting attempts to find these weaknesses is a critical protection mechanism.

==Definitions ==

These definitions are used within this document:

* '''Integrity checks'''

Ensure that the data has not been tampered with and is the same as before

* '''Validation'''

Ensure that the data is strongly typed, correct syntax, within length boundaries, contains only permitted characters, or that numbers are correctly signed and within range boundaries

* '''Business rules'''

Ensure that data is not only validated, but business rule correct. For example, interest rates fall within permitted boundaries.

Some documentation and references interchangeably use the various meanings, which is very confusing to all concerned. This confusion directly causes continuing financial loss to the organization.

==Where to include integrity checks ==

Integrity checks must be included wherever data passes from a trusted to a less trusted boundary, such as from the application to the user's browser in a hidden field, or to a third party payment gateway, such as a transaction ID used internally upon return.

The type of integrity control (checksum, HMAC, encryption, digital signature) should be directly related to the risk of the data transiting the trust boundary.

==Where to include validation ==

Validation must be performed on every tier. However, validation should be performed as per the function of the server executing the code. For example, the web / presentation tier should validate for web related issues, persistence layers should validate for persistence issues such as SQL / HQL injection, directory lookups should check for LDAP injection, and so on.

==Where to include business rule validation ==

Business rules are known during design, and they influence implementation. However, there are bad, good and "best" approaches. Often the best approach is the simplest in terms of code.

===Example - Scenario ===

* You are to populate a list with accounts provided by the back-end system
* The user will choose an account, choose a biller, and press next

===Wrong way===

The account select option is read directly and provided in a message back to the backend system without validating the account number if one of the accounts provided by the backend system.

===Why this is bad===

An attacker can change the HTML in any way they choose:

* The lack of validation requires a round-trip to the backend to provide an error message that the front end code could easily have eliminated

* The back end may not be able to cope with the data payload the front-end code could have easily eliminated. For example, buffer overflows, XML injection, or similar.

===Acceptable Method ===

The account select option parameter ("payee_id") is read by the code, and compared to an already-known list.

<code>
<pre>
if (account.hasPayee( session.getParameter("payee_id") )) {
backend.performTransfer( session.getParameter("payee_id") );
}
</pre>
</code>

This prevents parameter tampering, but requires the list of possible payee_id's to be to be calculated beforehand.

===Best Method ===

The original code emitted indexes <option value="1" ... > rather than account names.

''int payeeLstId = session.getParameter('payeelstid');''

''accountFrom = account.getAcctNumberByIndex(payeeLstId);''

Not only is this easier to render in HTML, it makes validation and business rule validation trivial. The field cannot be tampered with.



===Conclusion ===

To provide defense in depth and to prevent attack payloads from trust boundaries, such as backend hosts, which are probably incapable of handling arbitrary input data, business rule validation is to be performed (preferably in workflow or command patterns), even if it is known that the back end code performs business rule validation.

This is not to say that the entire set of business rules need be applied - it means that the fundamentals are performed to prevent unnecessary round trips to the backend and to prevent the backend from receiving most tampered data.

==Data Validation Strategies ==

There are four strategies for validating data, and they should be used in this order:

===Accept known good===

This strategy is also known as "whitelist" or "positive" validation. The idea is that you should check that the data is one of a set of tightly constrained known good values. Any data that doesn't match should be rejected. Data should be:

* Strongly typed at all times
* Length checked and fields length minimized
* Range checked if a numeric
* Unsigned unless required to be signed
* Syntax or grammar should be checked prior to first use or inspection

If you expect a postcode, validate for a postcode (type, length and syntax):

<code>
<pre>
public String isPostcode(String postcode) {
return (postcode != null && Pattern.matches("^(((2|8|9)\d{2})|((02|08|09)\d{2})|([1-9]\d{3}))$", postcode)) ? postcode : "";
}
</pre>
</code>

Coding guidelines should use some form of visible tainting on input from the client or untrusted sources, such as third party connectors to make it obvious that the input is unsafe:

<code>
<pre>
String taintPostcode = request.getParameter("postcode");
ValidationEngine validator = new ValidationEngine();
boolean isValidPostcode = validator.isPostcode(taintPostcode);
</pre>
</code>

===Reject known bad===

This strategy, also known as "negative" or "blacklist" validation is a weak alternative to positive validation. Essentially, if you don't expect to see characters such as %3f or JavaScript or similar, reject strings containing them. This is a dangerous strategy, because the set of possible bad data is potentially infinite. Adopting this strategy means that you will have to maintain the list of "known bad" characters and patterns forever, and you will by definition have incomplete protection.

''public String removeJavascript(String input) {''

'' Pattern p = Pattern.compile("javascript", CASE_INSENSITIVE);''

'' p.matcher(input);''

'' return (!p.matches()) ? input : '';''

''}''

It can take upwards of 90 regular expressions (see the CSS Cheat Sheet in the Guide 2.0) to eliminate known malicious software, and each regex needs to be run over every field. Obviously, this is slow and not secure. Just rejecting "current known bad" (which is at the time of writing hundreds of strings and literally millions of combinations) is insufficient if the input is a string. This strategy is directly akin to anti-virus pattern updates. Unless the business will allow updating "bad" regexes on a daily basis and support someone to research new attacks regularly, this approach will be obviated before long.

===Sanitize===

Eliminate or translate characters (such as to HTML entities or to remove quotes) in an effort to make the input "safe".
Like blacklists, this approach requires maintenance and is usually incomplete. As most fields have a particular grammar, it is simpler, faster, and more secure to simply validate a single correct positive test than to try to include complex and slow sanitization routines for all current and future attacks.

<code>
<pre>
public String quoteApostrophe(String input) {
if (input != null)
return input.replaceAll("[\']", "&rsquo;");
else
return null;
}
</pre>
</code>

===No validation===

This is inherently unsafe and strongly discouraged. The business must sign off each and every example of no validation as the lack of validation usually leads to direct obviation of application, host and network security controls.

''account.setAcctId(getParameter('formAcctNo'));''
''...''

''public setAcctId(String acctId) {''
'' cAcctId = acctId;''
''}''

==Prevent parameter tampering ==

There are many input sources:

* HTTP headers, such as REMOTE_ADDR, PROXY_VIA or similar

* Environment variables, such as getenv() or via server properties

* All GET, POST and Cookie data

This includes supposedly tamper resistant fields such as radio buttons, drop downs, etc - any client side HTML can be re-written to suit the attacker

Configuration data (mistakes happen :))

External systems (via any form of input mechanism, such as XML input, RMI, web services, etc)

All of these data sources supply untrusted input. Data received from untrusted data sources must be properly checked before first use.

==Hidden fields ==

Hidden fields are a simple way to avoid storing state on the server. Their use is particularly prevalent in "wizard-style" multi-page forms. However, their use exposes the inner workings of your application, and exposes data to trivial tampering, replay, and validation attacks. In general, only use hidden fields for page sequence.

If you have to use hidden fields, there are some rules:

* Secrets, such as passwords, should never be sent in the clear

* Hidden fields need to have integrity checks and preferably encrypted using non-constant initialization vectors (i.e. different users at different times have different yet cryptographically strong random IVs)

* Encrypted hidden fields must be robust against replay attacks, which means some form of temporal keying

* Data sent to the user must be validated on the server once the last page has been received, even if it has been previously validated on the server - this helps reduce the risk from replay attacks.

The preferred integrity control should be at least a HMAC using SHA-256 or preferably digitally signed or encrypted using PGP. IBMJCE supports SHA-256, but PGP JCE support require the inclusion of the Legion of the Bouncy Castle (http://www.bouncycastle.org/) JCE classes.

It is simpler to store this data temporarily in the session object. Using the session object is the safest option as data is never visible to the user, requires (far) less code, nearly no CPU, disk or I/O utilization, less memory (particularly on large multi-page forms), and less network consumption.

In the case of the session object being backed by a database, large session objects may become too large for the inbuilt handler. In this case, the recommended strategy is to store the validated data in the database, but mark the transaction as "incomplete". Each page will update the incomplete transaction until it is ready for submission. This minimizes the database load, session size, and activity between the users whilst remaining tamperproof.

Code containing hidden fields should be rejected during code reviews.

==ASP.NET Viewstate ==

ASP.NET sends form data back to the client in a hidden “Viewstate” field. Despite looking forbidding, this “encryption” is simply plain-text equivalent (base64 encoding) and has no data integrity without further action on your behalf in ASP.NET 1.0. In ASP.NET 1.1 and 2.0, tamper proofing, called "enableViewStateMAC" is on by default using a SHA-1 hash.

Any application framework with a similar mechanism might be at fault – you should investigate your application framework’s support for sending data back to the user. Preferably it should not round trip.

===How to determine if you are vulnerable ===

These configurations are set hierarchically in the .NET framework. The machine.config file contains the global configuration; each web directory may contain a web.config file further specifying or overriding configuration; each page may contain @page directives specifying same configuration or overrides; you must check all three locations:

* If the enableViewStateMac is not set to “true”, you are at risk if your viewstate contains authorization state

* If the viewStateEncryptionMode is not set to “always”, you are at risk if your viewstate contains secrets such as credentials

* If you share a host with many other customers, you all share the same machine key by default in ASP.NET 1.1. In ASP.NET 2.0, it is possible to configure unique viewstate keys per application

===How to protect yourself ===

* If your application relies on data returning from the viewstate without being tampered with, you should turn on viewstate integrity checks at the least, and strongly consider:

* Encrypt viewstate if any of the data is application sensitive

* Upgrade to ASP.NET 2.0 as soon as practical if you are on a shared hosting arrangement

* Move truly sensitive viewstate data to the session variable instead

===Selects, radio buttons, and checkboxes ===

It is commonly held belief that the value settings for these items cannot be easily tampered. This is wrong. In the following example, actual account numbers are used, which can lead to compromise:

''<html:radio value="<%=acct.getCardNumber(1).toString( )%>" property="acctNo">''

''<bean:message key="msg.card.name" arg0="<%=acct.getCardName(1).toString( )%>" />''

''<html:radio value="<%=acct.getCardNumber(1).toString( )%>" property="acctNo">''

''<bean:message key="msg.card.name" arg0="<%=acct.getCardName(2).toString( )%>" />''

This produces (for example):

''<input type="radio" name="acctNo" value="455712341234">Gold Card''

''<input type="radio" name="acctNo" value="455712341235">Platinum Card''

If the value is retrieved and then used directly in a SQL query, an interesting form of SQL injection may occur: authorization tampering leading to information disclosure. As the connection pool connects to the database using a single user, it may be possible to see other user's accounts if the SQL looks something like this:

''String acctNo = getParameter('acctNo');''

''String sql = "SELECT acctBal FROM accounts WHERE acctNo = '?'";''

''PreparedStatement st = conn.prepareStatement(sql);''

''st.setString(1, acctNo);''

''ResultSet rs = st.executeQuery();''

This should be re-written to retrieve the account number via index, and include the client's unique ID to ensure that other valid account numbers are exposed:

''String acctNo = acct.getCardNumber(getParameter('acctIndex'));''

''String sql = "SELECT acctBal FROM accounts WHERE acct_id = '?' AND acctNo = '?'";''

''PreparedStatement st = conn.prepareStatement(sql);''

''st.setString(1, acct.getID());''

''st.setString(2, acctNo);''

''ResultSet rs = st.executeQuery();''

This approach requires rendering input values from 1 to ... x, and assuming accounts are stored in a Collection which can be iterated using logic:iterate:

''<logic:iterate id="loopVar" name="MyForm" property="values">''

'' <html:radio property="acctIndex" idName="loopVar" value="value"/> ''

'' <bean:write name="loopVar" property="name"/> ''

''</logic:iterate>''

The code will emit HTML with the values "1" .. "x" as per the collection's content.

''<input type="radio" name="acctIndex" value="1" />Gold Credit Card''

''<input type="radio" name="acctIndex" value="2" />Platinum Credit Card''

This approach should be used for any input type that allows a value to be set: radio buttons, checkboxes, and particularly select / option lists.

===Per-User Data ===

In fully normalized databases, the aim is to minimize the amount of repeated data. However, some data is inferred. For example, users can see messages that are stored in a messages table. Some messages are private to the user. However, in a fully normalized database, the list of message IDs are kept within another table:

<pre>
+------------------------+
| MESSAGES |
+------------------------+
| msgid | message |
+------------------------+
</pre>

If a user marks a message for deletion, the usual way is to recover the message ID from the user, and delete that:

''DELETE FROM message WHERE msgid='frmMsgId'''

However, how do you know if the user is eligible to delete that message ID? Such tables need to be denormalized slightly to include a user ID or make it easy to perform a single query to delete the message safely. For example, by adding back an (optional) uid column, the delete is now made reasonably safe:

''DELETE FROM message WHERE uid='session.myUserID' and msgid='frmMsgId';''

Where the data is potentially both a private resource and a public resource (for example, in the secure message service, broadcast messages are just a special type of private message), additional precautions need to be taken to prevent users from deleting public resources without authorization. This can be done using role based checks, as well as using SQL statements to discriminate by message type:

''DELETE FROM message ''

''WHERE''

''uid='session.myUserID' AND''

''msgid='frmMsgId' AND''

''broadcastFlag = false;''

==URL encoding ==

Data sent via the URL, which is strongly discouraged, should be URL encoded and decoded. This reduces the likelihood of cross-site scripting attacks from working.

In general, do not send data via GET request unless for navigational purposes.

==HTML encoding ==

Data sent to the user needs to be safe for the user to view. This can be done using <bean:write ...> and friends. Do not use <%=var%> unless it is used to supply an argument for <bean:write...> or similar.

HTML encoding translates a range of characters into their HTML entities. For example, > becomes &gt; This will still display as > on the user's browser, but it is a safe alternative.

==Encoded strings ==

Some strings may be received in encoded form. It is essential to send the correct locale to the user so that the web server and application server can provide a single level of canoncalization prior to the first use.

Do not use getReader() or getInputStream() as these input methods do not decode encoded strings. If you need to use these constructs, you must decanoncalize data by hand.

==Data Validation and Interpreter Injection ==

This section focuses on preventing injection in ColdFusion. Interpreter Injection involves manipulating application parameters to execute malicious code on the system. The most prevalent of these is SQL injection but it also includes other injection techniques, including LDAP, ORM, User Agent, XML, etc. – see the Interpreter Injection chapter of this document for greater details. As a developer you should assume that all input is malicious. Before processing any input coming from a user, data source, component, or data service it should be validated for type, length, and/or range. ColdFusion includes support for Regular Expressions and CFML tags that can be used to validate input.

'''SQL Injection'''

SQL Injection involves sending extraneous SQL queries as variables. ColdFusion provides the <cfqueryparam> and <cfprocparam> tags for validating database parameters. These tags nests inside <cfquery> and <cfstoredproc>, respectively. For dynamic SQL submitted in <cfquery>, use the CFSQLTYPE attribute of the <cfqueryparam> to validate variables against the expected database datatype. Similarly, use the CFSQLTYPE attribute of <cfprocparam> to validate the datatypes of stored procedure parameters passed through <cfstoredproc>.

You can also strengthen your systems against SQL Injection by disabling the Allowed SQL operations for individual data sources. See the '''Configuration''' section below for more information.

'''LDAP Injection'''

ColdFusion uses the <cfldap> tag to communicate with LDAP servers. This tag has an ACTION attribute which dictates the query performed against the LDAP. The valid values for this attribute are: add, delete, query (default), modify, and modifyDN. <cfldap> calls are turned into JNDI (Java Naming And Directory Interface) lookups. However, because <cfldap> wraps the calls, it will throw syntax errors if native JNDI code is passed to its attributes making LDAP injection more difficult.

'''XML Injection'''

Two parsers exist for XML data – SAX and DOM. ColdFusion uses DOM which reads the entire XML document into the server’s memory. This requires the administrator to restrict the size of the JVM containing ColdFusion. ColdFusion is built on Java therefore by default, entity references are expanded during parsing. To prevent unbounded entity expansion, before a string is converted to an XML DOM, filter out DOCTYPES elements.

After the DOM has been read, to reduce the risk of XML, Injection use the ColdFusion XML decision functions: isXML(), isXmlAttribute(), isXmlElement(), isXmlNode(), and isXmlRoot(). The isXML() function determines if a string is well-formed XML. The other functions determine whether or not the passed parameter is a valid part of an XML document. Use the xmlValidate() function to validate external XML documents against a Document Type Definition (DTD) or XML Schema.

'''Event Gateway, IM, and SMS Injection'''

ColdFusion MX 7 enables Event Gateways, instant messaging (IM), and SMS (short message service) for interacting with external systems. Event Gateways are ColdFusion components that respond asynchronously to non-HTTP requests – e.g. instant messages, SMS text from wireless devices, etc. ColdFusion provides Lotus Sametime and XMPP (Extensible Messaging and Presence Protocol) gateways for instant messaging. It also provides an event gateway for interacting with SMS text messages.

Injection along these gateways can happen when end users (and/or systems) send malicious code to execute on the server. These gateways all utilize ColdFusion Components (CFCs) for processing. Use standard ColdFusion functions, tags, and validation techniques to protect against malicious code injection. Sanitize all input strings and do not allow un-validated code to access backend systems.

'''Best Practices'''

Use the XML functions to validate XML input.

Before performing XPath searches and transformations in ColdFusion, validate the source before executing.

Use ColdFusion validation techniques to sanitize strings passed to xmlSearch for performing XPath queries.

When performing XML transformations only use a trusted source for the XSL stylesheet.

Ensure that the memory size of the Java Sandbox containing ColdFusion can handle large XML documents without adversely affecting server resources.

Set the memory value to less than the amount of RAM on the server (-Xmx)

Remove DOCTYPE elements from the XML string before converting it to an XML object.

Using scriptProtect can be used to thwart most attempts of cross-site scripting. Set scriptProtect to All in the Application.cfc

Use <cfparam> or <cfargument> to instantiate variables in ColdFusion. Use this tag with the name and type attributes. If the value is not of the specified type, ColdFusion returns an error.

To handle untyped variables use IsValid() to validate its value against any legal object type that ColdFusion supports.

Use <cfqueryparam> and <cfprocparam> to valid dynamic SQL variables against database datatypes

Use CFLDAP for accessing LDAP servers. Avoid allowing native JNDI calls to connect to LDAP

'''Best Practice in Action'''

The sample code below shows a database authentication function using some of the input validation techniques discussed in this section.

{| border=1

||
* <cffunction name="dblogin" access="private" output="false" returntype="struct">

* <cfargument name="strUserName" required="true" type="string">

* <cfargument name="strPassword" required="true" type="string">

* <cfset var retargs = StructNew()>

* <cfif IsValid("regex", uUserName, "[A-Za-z0-9%]*") AND IsValid("regex", uPassword, "[A-Za-z0-9%]*")>

* <cfquery name="loginQuery" dataSource="#Application.DB#" >

* SELECT hashed_password, salt

* FROM UserTable

* WHERE UserName =

* <cfqueryparam value="#strUserName#" cfsqltype="CF_SQL_VARCHAR" maxlength="25">

* </cfquery>

* <cfif loginQuery.hashed_password EQ Hash(strPassword & loginQuery.salt, "SHA-256" )>

* <cfset retargs.authenticated="YES">

* <cfset Session.UserName = strUserName>

* 

* <cfelse>

* <cfset retargs.authenticated="NO">

* </cfif>

* <cfelse>

* <cfset retargs.authenticated="NO">

* </cfif>

* <cfreturn retargs>

* </cffunction>

|-

|}

==Delimiter and special characters ==

There are many characters that mean something special to various programs. If you followed the advice only to accept characters that are considered good, it is very likely that only a few delimiters will catch you out.

Here are the usual suspects:

* NULL (zero) %00

* LF - ANSI chr(10) "\r"

* CR - ANSI chr(13) "\n"

* CRLF - "\n\r"

* CR - EBCDIC 0x0f

* Quotes " '

* Commas, slashes spaces and tabs and other white space - used in CSV, tab delimited output, and other specialist formats

* <> - XML and HTML tag markers, redirection characters

* ; & - Unix and NT file system continuance

* @ - used for e-mail addresses

* 0xff

* ... more

Whenever you code to a particular technology, you should determine which characters are "special" and prevent them appearing in input, or properly escaping them.

==Further Reading ==

* ASP.NET 2.0 Viewstate

http://channel9.msdn.com/wiki/default.aspx/Channel9.HowToConfigureTheMachineKeyInASPNET2

[[Guide Table of Contents]]
[[Category:OWASP_Guide_Project]]
[[Category:Validation]]
[[Category:Encoding]]