We argue that application developers, while often viewed as allies in the effort to create software with fewer security vulnerabilities, are not reliable allies. They have varying skill sets which often do not include security. Moreover, we argue that it is inefficient and unrealistic to expect to be able to successfully teach all of the world's population of software developers to be security experts. We suggest more efficient and effective alternatives, focusing on those developers who produce core functionality used by other developers (e.g. those who develop popular APIs - Application Programming Interfaces). We discuss the benefits of designing APIs which can be easily used in a secure fashion to encourage security. We also introduce two straw-man proposals which integrate security into the work- ow of an application developer. Data tagging and unsuppressible warnings provide the basis for further work where the most natural use (path of least resistance) results in secure code. We believe there are benefits to co-opting developers into programming securely. Copyright 2008 ACM.

Additional Metadata
Keywords Development tools, Education, Human factors, Persuasion, Software developers, Software security, Usability
Persistent URL dx.doi.org/10.1145/1595676.1595691
Conference New Security Paradigms Workshop 2008, NSPW '08
Wurster, G. (Glenn), & Van Oorschot, P. (2009). The developer is the enemy. Presented at the New Security Paradigms Workshop 2008, NSPW '08. doi:10.1145/1595676.1595691