Difference between revisions of "Implementer"

From OWASP
Jump to: navigation, search
 
(One intermediate revision by one user not shown)
Line 1: Line 1:
 +
{{Template:SecureSoftware}}
 +
 
==Role Description==
 
==Role Description==
 
Traditionally, application development is handled in an ad-hoc manner, and it is the implementer who must carry the bulk of the security expertise. Ultimately, this is because — in ad-hoc development — developers double as designers.
 
Traditionally, application development is handled in an ad-hoc manner, and it is the implementer who must carry the bulk of the security expertise. Ultimately, this is because — in ad-hoc development — developers double as designers.
Line 6: Line 8:
 
For developers who perform any design tasks, we strongly recommend understanding designer activities by reading Appendices A and B and reviewing the Vulnerability database (Vulnerability View).
 
For developers who perform any design tasks, we strongly recommend understanding designer activities by reading Appendices A and B and reviewing the Vulnerability database (Vulnerability View).
  
==Categories==
 
 
[[Category:Role]]
 
[[Category:Role]]
 
[[Category:CLASP Role]]
 
[[Category:CLASP Role]]
 +
[[Category:OWASP CLASP Project]]

Latest revision as of 01:27, 27 May 2006


Role Description

Traditionally, application development is handled in an ad-hoc manner, and it is the implementer who must carry the bulk of the security expertise. Ultimately, this is because — in ad-hoc development — developers double as designers.

In a highly structured development environment, most implementers should be building to specification and conferring with designers when there are undocumented considerations. In such an environment, the security responsibilities of a developer are fairly minimal — primarily following coding standards and documenting the system well enough to make it easier for third parties to determine whether the software is as secure as it should be. Sometimes the documentation will be aimed at the end-users, helping to ensure that they know how to use the product securely.

For developers who perform any design tasks, we strongly recommend understanding designer activities by reading Appendices A and B and reviewing the Vulnerability database (Vulnerability View).