The pressure on software developers to produce secure software has never been greater. But what does security look like in environments that do not produce security-critical software? In answer to this question, this multi-sited ethnographic study characterizes security episodes and identifies five typical behaviors in software development. Using theory drawn from information security and motivation research in software engineering, this article characterizes key ways in which individual developers form security responses to meet the demands of particular circumstances, providing a framework managers and teams can use to recognize, understand, and alter security activity in their environments.

Despite the availability of various methods and tools to facilitate secure coding, developers continue to write code that contains common vulnerabilities. It is important to understand why technological advances do not sufficiently facilitate developers in writing secure code. To widen our understanding of developers' behaviour, we considered the complexity of the security decision space of developers using theory from cognitive and social psychology. Our interdisciplinary study reported in this article (1) draws on the psychology literature to provide conceptual underpinnings for three categories of impediments to achieving security goals, (2) reports on an in-depth meta-analysis of existing software security literature that identified a catalogue of factors that influence developers' security decisions, and (3) characterises the landscape of existing security interventions that are available to the developer during coding and identifies gaps. Collectively, these show that different forms of impediments to achieving security goals arise from different contributing factors. Interventions will be more effective where they reflect psychological factors more sensitively and marry technical sophistication, psychological frameworks, and usability. Our analysis suggests “adaptive security interventions” as a solution that responds to the changing security needs of individual developers and a present a proof-of-concept tool to substantiate our suggestion.