refactor content location, w/o text changes

cncf · ultrasaurus · May 2, 2019 · Jan 18, 2019 · Jan 18, 2019 · Apr 11, 2019
commit 050c64bc988c0bea03880bfb89c1ed6b15cf68c7
diff --git a/assessments/guide/README.md b/assessments/guide/README.md
@@ -0,0 +1,17 @@
+The SAFE WG has been ask to provide the CNCF’s TOC with effective
+information about the security of different projects.  The purpose of this
+document is to outline the procedure by which a project should be audited
+(by a set of members of the SAFE WG henceforth called SAFE examiners),
+including the expected effort from different participants.  This procedure
+can help the CNCF ensure that projects that are being considered for
+inclusion in the CNCF have reasonable security fundamentals that are
+expected to stop an attacker.  
+
+
+Due to the nature and timeframe for the analysis, *this review is not meant
+to subsume the need for a professional security audit of the code*.  Audits
+of implementation vulnerabilities and similar issues at that level are not
+intended to be covered by this audit.  The purpose of this effort is to 
+uncover design flaws and to obtain a clear articulation of what the project's 
+design goals and security properties are intended to be.
+
diff --git a/assessments/guide/outline.md b/assessments/guide/outline.md
@@ -1,21 +1,4 @@
-The SAFE WG has been ask to provide the CNCF’s TOC with effective
-information about the security of different projects.  The purpose of this
-document is to outline the procedure by which a project should be audited
-(by a set of members of the SAFE WG henceforth called SAFE examiners),
-including the expected effort from different participants.  This procedure
-can help the CNCF ensure that projects that are being considered for
-inclusion in the CNCF have reasonable security fundamentals that are
-expected to stop an attacker.  
-
-Due to the nature and timeframe for the analysis, *this review is not meant
-to subsume the need for a professional security audit of the code*.  Audits
-of implementation vulnerabilities and similar issues at that level are not
-intended to be covered by this audit.  The purpose of this effort is to 
-uncover design flaws and to obtain a clear articulation of what the project's 
-design goals and security properties are intended to be.
-
-
-## Needed information for assessment
+# Outline
 
 First of all, the burden is primarily on the proposing project to
 demonstrate it is secure in a manner that is understandable to the broader
@@ -81,31 +64,3 @@ community members to understand the answers to some questions, especially
 involving deployment scenarios and the impact of attacks.
 
 
-## Expected time / effort
-
-
-The level of effort for the team providing the information is expected to
-be around 80 hours of work.  Note, that projects that have already
-performed a security analysis internally are expected to have much lower
-requirements.
-
-The level of effort for the SAFE examiners is expected to be 10 hours.
-Despite the fact that there may be some back and forth to get clarification
-on a few points, it is expected analysis can usually be concluded in a few
-weeks of effort.  This will primarily involve carefully reading the written
-document and analyzing the security assertions and assumptions. The SAFE WG
-may decide on minimum security best practices for the software development
-process that the project must also demonstrate it is following. 
-
-## SAFE examiner qualifications
-
-Unless approved by the SAFE WG chairs, at least one of the examiners will
-have previously performed a SAFE WG audit.  (Exemptions are expected to be
-granted bootstrap the process but only in extreme cases later on.)  In
-general, a SAFE examiner should have performed security audits for diverse
-organizations.  The ideal SAFE examiner should also have been the recipient
-of security audits for a software project they manage.  Note that it is
-encouraged to have participation (shadowing) from participants that are not
-yet qualified to help them gain the necessary skills to be a SAFE examiner
-in the future.  
-
diff --git a/assessments/guide/project-lead.md b/assessments/guide/project-lead.md
@@ -0,0 +1,6 @@
+## Expected time / effort
+
+The level of effort for the team providing the information is expected to
+be around 80 hours of work.  Note, that projects that have already
+performed a security analysis internally are expected to have much lower
+requirements.
diff --git a/assessments/guide/security-reviewer.md b/assessments/guide/security-reviewer.md
@@ -0,0 +1,12 @@
+## SAFE examiner qualifications
+
+Unless approved by the SAFE WG chairs, at least one of the examiners will
+have previously performed a SAFE WG audit.  (Exemptions are expected to be
+granted bootstrap the process but only in extreme cases later on.)  In
+general, a SAFE examiner should have performed security audits for diverse
+organizations.  The ideal SAFE examiner should also have been the recipient
+of security audits for a software project they manage.  Note that it is
+encouraged to have participation (shadowing) from participants that are not
+yet qualified to help them gain the necessary skills to be a SAFE examiner
+in the future.  
+