[SC-L] Perspectives on Code Scanning

Carl Alphonce alphonce at buffalo.edu
Sun Jun 10 11:31:13 EDT 2007


[Apologies for this reply being a bit behind the discussion - I originally submitted it from a different
e-mail account than the one I subscribed with, and so it sailed off to /dev/null.]

On Wed Jun  6 18:59 , "Michael Silk" michaelslists at gmail.com> sent:
>On 6/7/07, McGovern, James F (HTSC, IT) James.McGovern at thehartford.com> wrote:
>> I really hope that this email doesn't generate a ton of offline emails and hope that folks will
>> talk publicly. It has been my latest thinking that the value of tools in this space are not really
>> targeted at developers but should be targeted at executives who care about overall quality
>> and security folks who care about risk. While developers are the ones to remediate, the
>> accountability for secure coding resides elsewhere.
>
>and that's the problem. the accountability for insecure coding should
>reside with the developers. it's their fault [mostly].

I started to look through the ACM Code Of Ethics (COE) to see what it says about this.  ACM has
a general COE:

    http://www.acm.org/constitution/code.html

and one for Software Engineering and Professional Practice:

    http://www.acm.org/serving/se/code.htm

I glanced through them fairly quickly, but neither appears to specifically address secure coding. 
Reading through both it seems to me that the spirit of both of these COE documents is that everyone
involved in the production of software (including developers and managers) has an obligation to
ensure the quality/reliability/safety of the software.  (It would be interesting to look at other professional
organizations' COEs too.)

This makes sense to me.  If only developers are held responsible, then it is too easy for management to make
the work environment difficult for developers who sweat code security, and then wash their hands of it.
Similarly, if only the managers are responsible, the developers can take shortcuts to meet deadlines and
avoid responsibility if the software breaks.  If everybody has a stake in the security of the software, maybe
it will happen.




More information about the SC-L mailing list