Producing secure software is challenging. The poor usability of security Application Programming Interfaces (APIs) makes this even harder. Many recommendations have been proposed to support developers by improving the usability of cryptography libraries—rooted in wider best practice guidance in software engineering and API design. In this SLR, we systematize knowledge regarding these recommendations. We identify and analyze 65 papers, offering 883 recommendations. Through thematic analysis, we identify seven core ways to improve usability of APIs. Most of the recommendations focus on helping API developers to construct and structure their code and make it more usable and easier for programmers to understand . There is less focus, however, on documentation , writing requirements , code quality assessment , and the impact of organizational software development practices . By tracing and analyzing paper ancestry, we map how this knowledge becomes validated and translated over time. We find that very few API usability recommendations are empirically validated, and that recommendations specific to usable security APIs lag even further behind.

Existing research has shown that developers will use StackOverflow to answer programming questions: but what draws them to one particular answer over any other? The choice of answer they select can mean the difference between a secure application and insecure one, as the quality of supposedly secure answers can vary. Prior work has studied people posting on Stack Overflow—a two-way communication between the original poster and the Stack Overflow community. Instead, we study the situation of one-way communication, where people only read a Stack Overflow thread without being actively involved in it, sometimes long after a thread has closed. We report on a mixed-method study including a controlled between-groups experiment and qualitative analysis of participants’ rationale (N=1188), investigating whether explanation detail, answer scoring, accepted answer marks, as well as the security of the code snippet itself affect the answers participants accept. Our findings indicate that explanation detail affects what answers participants reading a thread select (p0.05)—theinverseof what research has shown for those asking and answering questions. The qualitative analysis of participants’ rationale further explains how several cognitive biases underpin these findings. Correspondence bias, in particular, plays an important role in instilling readers with a false sense of confidence in an answer through theway it looks, regardless of whether it works, is secure, or if the community agrees with it. As a result, we argue that StackOverflow's use as a knowledge base by people not actively involved in threads—when there is only one-way-communication—may inadvertently contribute to the spread of insecure code, as the community's voting mechanisms hold little power to deter them from answers.

Cyber security requirements are influenced by the priorities and decisions of a range of stakeholders. Board members and Chief Information Security Officers (CISOs) determine strategic priorities. Managers have responsibility for resource allocation and project management. Legal professionals concern themselves with regulatory compliance. Little is understood about how the security decision-making approaches of these different stakeholders contrast, and if particular groups of stakeholders have a better appreciation of security requirements during decision-making. Are risk analysts better decision makers than CISOs? Do security experts exhibit more effective strategies than board members? This paper explores the effect that different experience and diversity of expertise has on the quality of a team's cyber security decision-making and whether teams with members from more varied backgrounds perform better than those with more focused, homogeneous skill sets. Using data from 208 sessions and 948 players of a tabletop game runin the wildby a major national organization over 16 months, we explore how choices are affected by player background (e.g., cyber security experts versus risk analysts, board-level decision makers versus technical experts) and different team make-ups (homogeneous teams of security experts versus various mixes). We find that no group of experts makes significantly better game decisions than anyone else, and that their biases lead them to not fully comprehend what they are defending or how the defenses work.

Does the act of writing a specification (how the code should behave) for a piece of security sensitive code lead to developers producing more secure code? We asked 138 developers to write a snippet of code to store a password: Half of them were asked to write down a specification of how the code should behave before writing the program, the other half were asked to write the code but without being prompted to write a specification first. We find that explicitly prompting developers to write a specification has a small positive effect on the security of password storage approaches implemented. However, developers often fail to store passwords securely, despite claiming to be confident and knowledgeable in their approaches, and despite considering an appropriate range of threats. We find a need for developer-centered usable mechanisms for telling developers how to store passwords: lists of what they must do are not working.

Cyber security decision making is inherently complicated, with nearly every decision having knock-on consequences for an organisation’s vulnerability and exposure. This is further compounded by the fact that decision-making actors are rarely security experts and may have an incomplete understanding of the security that the organisation currently has in place. They must contend with a multitude of possible security options that they may only partially understand. This challenge is met by decision makers’ risk thinking —their strategies for identifying risks, assessing their severity, and prioritising responses. We study the risk thinking strategies employed by teams of participants in an existing dataset derived from a tabletop cyber-physical systems security game. Our analysis identifies four structural patterns of risk thinking and two reasoning strategies: risk-first and opportunity-first . Our work highlights that risk-first approaches (as prescribed by the likes of NIST-800-53 and ISO 27001) are followed neither substantially nor exclusively when it comes to decision making. Instead, our analysis finds that decision making is affected by the plasticity of teams—that is, the ability to readily switch between ideas and practising both risk-first and opportunity-first reasoning.