This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org

Projects/OWASP Secure Coding Practices - Quick Reference Guide/Releases/SCP v1/Assessment

From OWASP
Revision as of 01:51, 9 September 2010 by Keith Turpin (talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Click here to return to project's main page

Stable Release Review of the OWASP Secure Coding Practices - Quick Reference Guide - Version 1.0 Release

Project Leader for this Release

Keith Turpin's Pre-Assessment Check-list:

Project Leader review

(This FORM is EDITED via a template)

Alpha level

1. Is this release associated with a project containing at least the Project Wiki Page Minimum Content information?


Yes

2. Is your document licensed under a free and open license? (see Project Licensing section of the Guidelines for OWASP Projects) Please point out the link(s).


Yes - Creative Commons Attribution ShareAlike 3.0 license

3. Is the document available as a PDF (Portable Document Format) and an editable (.Doc) format on the project site? Please point out the link(s).


Yes

4. Are all articles that constitute the project release properly tagged within project category and available from main project Wiki page? Please point out the link(s).


Yes Project current linked to in the Documents section of the Alpha projects page: - http://www.owasp.org/index.php/Category:OWASP_Project#tab=Alpha_Status_Projects Project pages: - http://www.owasp.org/index.php/OWASP_Secure_Coding_Practices_-_Quick_Reference_Guide#tab=Project_About - http://www.owasp.org/index.php/OWASP_Secure_Coding_Practices_-_Quick_Reference_Guide#tab=Main - http://www.owasp.org/index.php/Projects/OWASP_Secure_Coding_Practices_-_Quick_Reference_Guide/Releases/Current

5. Is there a roadmap for this project release which will take it from Alpha to Stable release? Please point out the link(s).


Yes, However this is a mature project seeking stable release now http://www.owasp.org/index.php/OWASP_Secure_Coding_Practices_-_Quick_Reference_Guide/Roadmap

Beta Level

6. Are the Alpha pre-assessment items complete?


Yes

7. Are all document contents (articles) present and listed on the OWASP project wiki page? Please point out the link(s).


Yes http://www.owasp.org/index.php/OWASP_Secure_Coding_Practices_-_Quick_Reference_Guide#tab=Project_About http://www.owasp.org/index.php/OWASP_Secure_Coding_Practices_-_Quick_Reference_Guide#tab=Main

8. Is there user documentation on the OWASP project wiki page? Please point out the link(s).


N/A

9. Is there an “About This Document” section in the document listing: (Please point out the link(s).

  • Document (Project Release) Name
  • Author(s)
  • Contributor(s)
  • Contact email address
  • Current version and/or release date
  • Project's web page address

Yes

10. Is there documentation on how to build the tool from source including obtaining the source from the code repository? Please point out the link(s).


N/A

Stable Level

11. Are the Alpha and Beta pre-assessment items complete?


Yes

12. Have any limitations been documented? Please point out the link(s).


No

13. Does the document consider OWASP Writing Style and OWASP Template for Docs? Please point out the link(s)


Yes

14. Is there a one sheet overview document about the project release? Please point out the link(s).


Yes

15. Is the document in a format which can be converted to an OWASP book? (books are currently via Lulu.com) Please point out the link(s).


I believe so, it depends on the size and format of the desired final product, but since lulu supports U.S. Letter, I would say yes. Condensing to a smaller format would not be difficult.


First Reviewer

Ludovic Petit's Review:

First Reviewer

Ideally, reviewers should be an existing OWASP project leader or chapter leader.

(This FORM is EDITED via a template)

Beta level

1. Does the document consider the OWASP Writing Style?


answer 1 Yes, but text has to be justified for a more relevant presentation.

May I also suggest the following? I fully understand – and I agree with - the aim of a Quick Reference Guide, however in my view, 2 options could be studied:

The 1st one is to let pages 1, 2 and 3 as this.

The 2nd one could be: Just have the logo, Title and Copyright on page 1 Table of Contents on page 2 And Introduction on page 3

this because at a first look, having the Table of Contents on page 2 after the Intro do not ‘seem’ to be coherent (due to the fact that generally, we have the habit to have a Table of Contents before an Intro of a subject).

It’s just a suggestion anyway.

2. Do contents from wiki articles match download-able documents? (PDF and .doc versions)


answer 2 Yes

3. Does the document have an “About This Document” section which allows the end user to get an overview of the state of the document?


answer 3 Yes

4. How completely does the release address the goal of the project? Is the overall document complete in structure and organization? Are any missing or incomplete sections critical enough to keep the document at an Alpha quality level?


answer 4 The document fulfils the aim of being a Quick Reference Guide, but my personal feeling is that something is missing however:

What about the awareness level of the developer supposed to take all these inputs into account?

Indeed, as it is said in the Introduction, this document is presented in a checklist format; and because it has to be handled as a checklist, the 1st check to take into account is to ensure about the willingness of the developer to engage in such a process of checking his own awareness level.

So, to be short, I don’t know what exactly and how to say something about that, but I just wished to raise this to your attention because that could be appreciated afterwards by people reading the Guide.

It’s up to you.

Stable Level

5. Have all the Beta Reviewer Action Items been completed? These will need to be completed if they have not already occurred during a previous assessment.


answer 5 I guess so

6. Have any limitations been documented? Please point out the link(s).


answer 6

7. Does the document substantially address the application security issues it was created to solve?


answer 7 Yes indeed, short, precise and easy to read.

8. Does the document respect OWASP Writing Style and OWASP Template for Docs?


answer 8 I guess yes about the OWASP Writing Style, but to ensure about Template

9. Have you noted any limitations of the document that are not already documented by the project release lead?


answer 9 Not yet

10. Would you consider using this document in your day to day work assuming your professional work includes a reason to use this document? Would you recommend this document to others in the profession? Why or why not?


answer 10 Yes, absolutely, given that I’ll also recommend this Guide to any outsourced services staff, dev staff, specially for platforms of Services

11. What, if anything, is missing which would make this a more useful document? Is what is missing critical enough to keep the release at a beta quality?


answer 11 I would say the same as answer 4:

The document fulfils the aim of being a Quick Reference Guide, but my personal feeling is that something is missing however:

What about the awareness level of the developer supposed to take all these inputs into account?

Indeed, as it is said in the Introduction, this document is presented in a checklist format; and because it has to be handled as a checklist, the 1st check to take into account is to ensure about the willingness of the developer to engage in such a process of checking his own awareness level.

So, to be short, I don’t know what exactly and how to say something about that, but I just wished to raise this to your attention because that could be appreciated afterwards by people reading the Guide.

Second Reviewer

Brad Causey's Review:

Second Reviewer

It is recommended that an OWASP board member or Global Projects Committee member be the second reviewer on Quality releases. The board has the initial option to review the project, followed by the Global Projects Committee.

(This FORM is EDITED via a template)

Beta level

1. Does the document consider the OWASP Writing Style?


Affirmative

2. Do contents from wiki articles match download-able documents? (PDF and .doc versions)


Affirmative

3. Does the document have an “About This Document” section which allows the end user to get an overview of the state of the document?


Affirmative

4. How completely does the release address the goal of the project? Is the overall document complete in structure and organization? Are any missing or incomplete sections critical enough to keep the document at an Alpha quality level?


Completely. The project leader has done a great job addressing the target audience with relevant information to the subject of the project.

Stable Level

5. Have all the Beta Reviewer Action Items been completed? These will need to be completed if they have not already occurred during a previous assessment.


Affirmative

6. Have any limitations been documented? Please point out the link(s).


None that I'm aware of are necessary other than what is included within the document itself.

7. Does the document substantially address the application security issues it was created to solve?


Affirmative - and very well

8. Does the document respect OWASP Writing Style and OWASP Template for Docs?


Affirmative

9. Have you noted any limitations of the document that are not already documented by the project release lead?


None

10. Would you consider using this document in your day to day work assuming your professional work includes a reason to use this document? Would you recommend this document to others in the profession? Why or why not?


Affirmative

11. What, if anything, is missing which would make this a more useful document? Is what is missing critical enough to keep the release at a beta quality?


It would be great to see an integration guide on how to combine this with an existing or new SDLC. This would be slated for a later project/release.