OWASP Secure Software Contract Annex/ja - Revision history

Achim: category aded

2015-04-14T11:54:32Z

category aded

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

2011-07-06T13:18:52Z

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

Tomo: /* 10. 保証 */

2011-07-06T13:17:39Z

‎10. 保証

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

2011-07-06T13:16:35Z

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

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

2011-07-06T13:12:44Z

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

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

2011-07-06T13:10:51Z

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

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

2011-07-06T13:08:13Z

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

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

2011-07-06T13:04:20Z

‎5. 要員および組織

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

2011-07-06T12:45:00Z

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

Tomo: /* 2. 原理 */

2011-07-06T12:31:54Z

‎2. 原理

← Older revision		Revision as of 11:54, 14 April 2015
Line 193:		Line 193:

	[[Category:OWASP Legal Project]]		[[Category:OWASP Legal Project]]
		+	[[Category:OWASP Secure Software Contract Annex]]

	__NOTOC__		__NOTOC__

@@ Line 184: / Line 184: @@
 ===11. セキュリティ承認と保守 ===
-;(a) 受け入れ : 証明パッケージが完全であり、すべてのセキュリティ問題が解決されるまで、ソフトウェアは受け入れられると考慮されてはいけません。
+;(a) 受入 : 証明パッケージが完全であり、すべてのセキュリティ問題が解決されるまで、ソフトウェアは受け入れられると考慮されてはいけません。
 ;(b) セキュリティ問題の調査 : 受理の後、セキュリティ問題が発見されるか、かなり疑われるならば、開発者は顧客が問題の性質を決定するために調査を実行するのを援助しなければなりません。それがセキュリティ要求によってカバーされないで、セキュリティ・テストの理にかなった範囲の外にあるならば、問題は「新しい」と思われなければなりません。

@@ Line 176: / Line 176: @@
 ===10. 保証===
-;(a) 保証 : 開発者は、開発プロセスを通して作成されるセキュリティ文書からなる「証明パッケージ」を提供します。パッケージは、セキュリティ要求、設計、実装と試験結果がきちんと完了された、そして、すべてのセキュリティ問題が適切に解決されたと確認しなければなりません。
+;(a) 保証 : 開発者は、開発プロセスを通して作成されるセキュリティ文書からなる「証明パッケージ」を提供します。パッケージは、セキュリティ要求、設計、実装とテスト結果がきちんと完了された、そして、すべてのセキュリティ問題が適切に解決されたと確認しなければなりません。
 ;(b) 自己証明 : セキュリティ・アーキテクトは、ソフトウェアがセキュリティ要求を満たすこと、すべてのセキュリティ活動が実行されていること、そして、すべての識別されたセキュリティ問題が文書化されて、解決されたことを証明します。証明ステータスに対するあらゆる例外は、納品で完全に文書化されなければなりません。

@@ Line 172: / Line 172: @@
 ;(b) 保護 : 開発者はセキュリティ問題と関連する文書に関して情報を適切に保護します。そして、運用中の顧客ソフトウェアの脆弱性が露出するという可能性を制限するのを助けます。
-;(c) 改善 : 納品の前に確認されるセキュリティ問題は、開発者によって修正されなければなりません。納品の後に発見されるセキュリティ問題は、本契約の規定による他のバグと問題として同様に取り扱われなければなりません。
+;(c) 改善 : 納品の前に確認されるセキュリティ問題は、開発者によって修正されなければなりません。納品の後に発見されるセキュリティ問題は、本契約の規定に定められたように他のバグや問題と同様に取り扱われなければなりません。
 ===10. 保証===

@@ Line 166: / Line 166: @@
 ;(d) 見つけられた問題 : 発見されたセキュリティ問題は、顧客と開発者に報告されます。すべての問題は、この付属書のセキュリティ問題管理セクションにより追跡されて、矯正されます。
-===9. セキュリティ問題マネジメント ===
+===9. セキュリティ問題管理 ===
-;(a) 識別 : 要求、設計、実装、テスト、配備、または、運用中の問題にせよ、開発者は全てのライフサイクルの間に発見されるすべてのセキュリティ問題を追います。各々のセキュリティ問題に関連したリスクは、発見後できるだけ早く、評価されて、文書化されて、発見の後、顧客に報告されます。
+;(a) 識別 : 要求、設計、実装、テスト、配備、または、運用中の問題にせよ、開発者は全てのライフサイクルの間に発見されるすべてのセキュリティ問題を追跡します。個々のセキュリティ問題に関連したリスクは、発見後できるだけ早く、評価されて、文書化されて、発見の後、顧客に報告されます。
-;(b) 保護 : 開発者はセキュリティ問題と付随する文書に関して情報を適切に保護します。そして、運用中の顧客ソフトウェアの脆弱性が露出するという可能性を制限するのを助けます。
+;(b) 保護 : 開発者はセキュリティ問題と関連する文書に関して情報を適切に保護します。そして、運用中の顧客ソフトウェアの脆弱性が露出するという可能性を制限するのを助けます。
 ;(c) 改善 : 納品の前に確認されるセキュリティ問題は、開発者によって修正されなければなりません。納品の後に発見されるセキュリティ問題は、本契約の規定による他のバグと問題として同様に取り扱われなければなりません。

@@ Line 164: / Line 164: @@
 ;(c) レビューの範囲 : 最低限で、レビューはセキュリティ要求の全てをカバーしなければならなくて、他の一般的な脆弱性を捜さなければなりません。レビューは、脆弱性スキャン、侵入テスト、ソースコードの静的分析と専門家のコードレビューの組み合わせを含んでもよいです。
-;(d) 見つけられた問題 : 発見されたセキュリティ問題は、顧客と開発者に報告されます。すべての問題は、この付属書のセキュリティ問題マネジメント部分により追跡されて、矯正されます。
+;(d) 見つけられた問題 : 発見されたセキュリティ問題は、顧客と開発者に報告されます。すべての問題は、この付属書のセキュリティ問題管理セクションにより追跡されて、矯正されます。
 ===9. セキュリティ問題マネジメント ===

@@ Line 152: / Line 152: @@
 ===7. ライブラリ、フレームワーク、および生産物===
-;(a) 開示 : 開発者は、商用、フリー、オープンソース、クローズソースであるにせよ、すべてのライブラリ、フレームワーク、構成要素と他の生産物を含む、ソフトウェアで使われるすべての第三者のソフトウェアを明らかにしなければなりません。
+;(a) 開示 : 開発者は、商用、フリー、オープンソース、クローズソースであるにせよ、すべてのライブラリ、フレームワーク、構成要素および他の生産物を含む、ソフトウェアで使われるすべての第三者のソフトウェアを明らかにしなければなりません。
-;(b) 評価 : 開発者は、第三者のソフトウェアがこの契約のすべての条件を満たして、この契約の基で開発されたカスタム開発されたコードと同じくらいセキュアなことを確実とするために、理にかなった努力をしなければなりません。
+;(b) 評価 : 開発者は、第三者のソフトウェアがこの契約のすべての条項を満たして、この契約のもとで開発されたカスタム開発されたコードと同じくらいセキュアなことを確実とするために、理にかなった努力をしなければなりません。
 ===8. セキュリティ・レビュー===

@@ Line 136: / Line 136: @@
 ===5. 要員および組織===
-;(a) セキュリティ・アーキテクト : 開発者は一つの上位の技術的な資源に責任をセキュリティに指定します。そして、プロジェクトのセキュリティ・アーキテクトとして知られています。セキュリティ・アーキテクトは、各々の納品可能なもののセキュリティを保証します。
+;(a) セキュリティ・アーキテクト : 開発者は一つの上位の技術的な資源に責任をセキュリティに指定します。そして、プロジェクトのセキュリティ・アーキテクトとして知られています。セキュリティ・アーキテクトは、個々の納品可能なもののセキュリティを保証します。
 ;(b) セキュリティ・トレーニング : 開発者は、開発者チームのすべてのメンバーがセキュアなプログラミング技法の訓練をされたことを確かめる役割を果たします。
-;(c) 信用できる開発者 : 開発者は、すべての開発チーム・メンバーの適切な経歴調査を実行することに同意します。
+;(c) 信頼できる開発者 : 開発者は、すべての開発チーム・メンバーの適切な経歴調査を実行することに同意します。
 ===6.開発環境===

@@ Line 98: / Line 98: @@
 ===3.ライフサイクル活動===
-;(a) リスク識別 : 開発者とClientは、アプリケーションに直面しているリスクを理解して、文書化するために一緒に働くことに同意します。この努力は、アプリケーションにより提供される重要な資産と機能に主要なリスクを確認しなければなりません。要件部にリストされるトピックの各々は、考慮されなければなりません。
+;(a) リスク識別 : 開発者と顧客は、アプリケーションに直面しているリスクを理解して、文書化するために協力することに同意します。この努力は、アプリケーションにより提供される重要な資産と機能への主要なリスクを確認しなければなりません。要件部にリストされるトピックの各々は、考慮されなければなりません。
-;(b) 要求 : リスクに基づいて、開発者と顧客は、開発されるソフトウェアの仕様の一部として詳細なセキュリティ要件を確立するために一緒に働くことに同意します。この付属書の要件部分で記載されるトピックの各々は、開発者と顧客によって協議されなければならなくて、評価されなければなりません。これらの要件は、カスタム・ソフト、第三者のソフトウェアまたはプラットホームによって満たされてもよいです。
+;(b) 要求 : リスクに基づいて、開発者と顧客は、開発されるソフトウェアの仕様の一部として詳細なセキュリティ要件を確立するために協力することに同意します。この付属書の要件部分で記載される個々のトピックは、開発者と顧客によって協議されなければならなくて、評価されなければなりません。これらの要件は、カスタム・ソフトウェア、第三者のソフトウェアまたはプラットホームによって満たされてもよいです。
 ;(c) 設計 : 開発者は、セキュリティ要件の各々を達成するために明確に設計を説明する文書を提供することに同意します。ほとんどの場合、この文書はセキュリティ手法を記載します、そこで、手法はアーキテクチャに適合しました、そして、関連したすべては彼らの適正使用を確実にするためにパターンを設計します。設計は、サポートがカスタム・ソフトか、第三者のソフトウェアかプラットホームから来るかどうか、明確に指定しなければなりません。
-;(d) 実装 : 開発者は、一組のセキュアなコーディング指針に提供することに、従って、一組の共通セキュリティ制御プログラミング・インターフェース（例えば [http://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API OWASP Enterprise Security API（ESAPI）] ）を使って同意します。ガイドラインは、コードがどのようにフォーマットされなければならなくて、構築されなければならなくて、コメントされなければならないかについて示します。共通セキュリティ制御プログラミング・インターフェースは、セキュリティ制御がどのように呼ばれなければならないか、そして、セキュリティ制御がどのように機能するか定めます。すべてのセキュリティに関連したコードは、完全にコメントされます。共通のセキュリティ脆弱性を回避するときの具体的なガイダンスは、含まれなければなりません。また、すべてのコードはセキュリティ要件に対して少なくとも他の一人の開発者によってレビューされなければなりません、そして、それの前のコーディング・ガイドラインは単体テストの準備ができていると思われます。
+;(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)] のような）合意された標準の検証要件により、アプリケーション・セキュリティ分析とテスト（「検証」とも言われる）を実行します。開発者は、標準の報告要件によって検証結論を文書化しなければなりません。開発者は、検証結論を顧客に提供しなければなりません。

@@ Line 82: / Line 82: @@
 ===2. 原理===
-この付属書は、ソフトウェア開発関係のすべての関係者のセキュリティ関連の権利と義務をはっきりさせることを目的とします。最高水準で、関係者は以下に同意します
+この付属書は、ソフトウェア開発関係のすべての関係者のセキュリティ関連の権利と義務をはっきりさせることを目的とします。最高レベルで、関係者は以下に同意します
 ;(a) セキュリティ決定は、リスクに基づきます : セキュリティについての決定は、関係するリスクのしっかりした理解に基づく顧客と開発者によって共同でなされす。
@@ Line 92: / Line 92: @@
 ;(d) 脆弱性は予想されます : すべてのソフトウェアにはバグがあります、そして、それらのいくらかはセキュリティ問題を生じさせます。顧客と開発者は、ライフサイクルにおいてできるだけ早く脆弱性を特定するよう努めます。
-;(e) セキュリティ情報は、完全に明らかにされます : すべてのセキュリティ関連した情報は、すぐに、そして、完全に、顧客と開発者で共有されます。
+;(e) セキュリティ情報は完全に明らかにされます : すべてのセキュリティ関連した情報は、すぐに、そして、完全に、顧客と開発者で共有されます。
 ;(f) 役に立つセキュリティ文書だけが必要とされます : セキュリティ文書は、セキュリティ設計、リスク分析または問題を明確に記述するために詳細にわたる必要はありません。