# Worrisome Patterns in Developers: A Survey in Cryptography

Mohammadreza Hazhirpasand Oscar Nierstrasz  University of Bern
Bern, Switzerland  Mohammad Ghafari  University of Auckland
Auckland, New Zealand
<EMAIL_ADDRESS>
###### Abstract

We surveyed 97 developers who had used cryptography in open-source projects,
in the hope of identifying developer security and cryptography practices. We
asked them about individual and company-level practices, and divided
respondents into three groups (_i.e.,_ high, medium, and low) based on their
level of knowledge. We found differences between the high-profile developers
and the other two groups. For instance, high-profile developers have more
years of experience in programming, have attended more security and
cryptography courses, have more background in security, are highly concerned
about security, and tend to use security tools more than the other two groups.
Nevertheless, we observed worrisome patterns among all participants such as
the high usage of unreliable sources like Stack Overflow, and the low rate of
security tool usage.

###### Index Terms:

Security, cryptography, survey

##  I Introduction

Many developers do not correctly use cryptographic (crypto) APIs [1].
Investigation of developer questions on the Stack Overflow website showed that
they often struggle with understanding cryptography concepts [2]. Researchers
have developed new tools and APIs to ease the adoption of cryptography [3],
yet crypto issues are prevalent [4].

We aim to shed light onto the following research question: _“What are the
practices of developers who use cryptography in the wild?”_ We conducted an
exploratory study to identify developer cryptography and security practices.
We designed an online survey containing questions regarding developer
demographics, and developer- and company-level security background. We sent
the survey to 1231 developers who had frequently used crypto APIs in open-
source projects.

We received 97 responses. Most of the respondents (_i.e.,_ 73%) had studied
Computer Science and all participants claimed to have knowledge in
cryptography. In particular, 60% stated that they are knowledgeable, and 19%
very knowledgeable. We divided the respondents into three groups, namely _low,
medium, and high-profile developers in cryptography_. We classified them based
on their responses to self-reported knowledge in cryptography (in short,
knowledge). In order to help the participants to choose the most suitable
level of knowledge, we provided them with definitions of what each level of
knowledge means and then compared the responses among the groups.

We noticed that for developer-level and company-level security factors,
_e.g.,_ security course attendance or existence of security consultant at
work, the high-profile developers have considerably better records than the
other groups. In the same vein, developers with medium and low profiles have
similar responses. With respect to company-level factors, we observed low
attention towards security-related factors, _e.g.,_ half of the companies have
no security training or only every two years, and 71% of companies have no
security consultant. We therefore arrive at the conclusion that the high-
profile group tends to report stronger security and crypto-related
characteristics than those who did not feel confident in their knowledge. Even
though there exists a high rate of security concerns among developers and
companies, there are alarming findings, _e.g.,_ low acceptance rate of
security tool adoption or relying on unreliable sources, _e.g.,_ Stack
Overflow, to solve crypto problems. Therefore, practitioners and researchers
should consider the potential effects and devise proper guidelines, training,
and methods to lead inexperienced developers in this domain. Future work
should assess developer knowledge based on their real performance in a
controlled experiment, the severity of security policies enforced in
companies, and project-level security requirements.

##  II Developer Survey

We conducted an online survey with developers identified in a recent work [4]
as having used Java Crypto APIs in real-world applications, to understand what
security and cryptography practices such developers report. In the following
subsections, we explain our methodology and present the survey results.

###  II-A Methodology

We adopted an anonymous online survey approach which involves the following
steps: (i) selecting developers, (ii) designing the survey, (iii) testing and
publishing the survey, and (iv) analyzing the survey. The questions and the
responses of the survey are available online.111http://crypto-
explorer.com/crypto/

####  II-A1 Objective

Previous studies have shown that developers have difficulty in using
cryptography securely [1][5]. In this study, we pose the following research
question: _“What are the practices of developers who use cryptography in the
wild?”_ to tackle the reasons why developer performance varies in using
cryptography. The objectives of this research are as follows: (1) except for
technical difficulties of crypto APIs explored in previous research [6] [4]
[7], the findings can shed some light on the worrisome and promising practices
among developers with respect to cryptography, (2) finding the indicative
factors can assist professionals to correctly guide and lead such developers
at workplaces.

####  II-A2 Selecting developers

We selected developers from a recent study conducted by Hazhirpasand _et al._
[4], where the authors investigated Java Cryptography Architecture (JCA) uses
and misuses in 489 open-source projects. They identified developers who
committed code containing crypto uses to these repositories, _i.e.,_ they
extracted their names and email addresses using the git blame command.

TABLE I: Factors to explore in the survey Demographics | Developer-level | Company-level
---|---|---
Developer age |  | Security course
---
attendance and experience
as code auditor
| Security training
---
by company
| Years of experience
---
in programming
| Crypto knowledge level
---
and experience in using
Crypto API
| Existence of security
---
consultant
| Years of experience
---
in Java
| Background in IT security
---
and security concern level
| Company security
---
concern level
Educational level |  | Ways of solving crypto
---
problems and evaluating
crypto code
| The percentage of
---
security developer
in company

####  II-A3 Survey Design

In the survey, we collected information about the participants in three
sections, and then evaluated the factors to determine which of them influence
developer knowledge. To determine the explored factors, we studied the
literature and identified studies wherein individual or work-related facets
were studied with regard to cryptography (See Table I). Thereafter, we
constructed a list of explored factors that could influence developer
knowledge, namely security tool adoption [8] [9], security concern [10] [11],
means of resolving crypto challenges [12] [13], security training and its
frequency [14] [15] [16], and work and technical experience [17] [18] [19]
[12]. Nevertheless, the aim of the previous studies was to evaluate developer
performance or developer practice but not developer knowledge.

The initial section is dedicated to the demographic information of developers.
Within this section, we asked for their degree, field, age, years of
programming and Java programming experience. Participant demographics help us
to determine which factors may affect a respondent’s answers.

In the second section, we mostly focus on developer practices, _e.g.,_
security or cryptography course attendance. They are asked to specify their
level of knowledge about cryptography as well as their experience with crypto
APIs. We used a 5-point Likert scale to ask developer security concerns in
development. Further, We inquired developers what information sources they use
to solve a crypto scenario or how they evaluate a crypto code snippet.

In the last section of the survey, we primarily concentrate on company-level
factors. We provided them with questions regarding the existence of security
consultant, company-level security concern (5-point Likert scale), and the
percentage of developers responsible for secure development.

####  II-A4 Testing, and Publishing the Survey Tool

We used Google Forms to create our online questionnaire. As overlong
questionnaires are commonly not completed on the internet [20], we limited the
completion time of the survey to less than 5 minutes. To evaluate the survey
before asking the real participants, we asked five colleagues to review the
survey to reveal potential misunderstandings. Then, based on the received
recommendations, we refined the questions and rearranged them. Next, we
emailed the 1231 developers. We noticed that 128 email addresses were not
valid, which left us with 1 103 potential survey participants.

####  II-A5 Survey Analysis

We received 97 responses (8.7%) within a month. To perform the analysis, we do
not consider missing values in the analysis. We use percentage graphs in order
to analyze responses of Likert scale questions. Notably, the explanations of
respondents to the open-ended question consisted of fewer than 20 words.
However, to minimize human errors, two authors of the paper coded the
responses and cross-checked the consistency of the results.

####  II-A6 Knowledge factor

Nadi _et al._ conducted two surveys with 48 developers and devised a four-
level classification for developer crypto knowledge [5]. We used the same
levels in the survey. However, we attempted to minimize the impact of wrong
assumptions with regard to how developers report their level of knowledge in
cryptography. As a result, we provided the participants with an explanation of
what each level means in this study. The four-level items can be viewed in the
survey file.222http://crypto-explorer.com/crypto/

####  II-A7 Ethics

The developers’ email addresses were identified by the use of the git blame
command in a recent study [4]. We also asked developers to read the statement
of the survey and state their agreement before participating. Moreover, we did
not collect any personal information except for the information explicitly
gathered by the survey instrument.

##  III Developer practice

We discuss our findings from the developer self-reported knowledge
perspective. We then compare variables related to each participant
characteristic with the reported knowledge level. The participants rated their
knowledge in cryptography as 21% (_i.e.,_ 21) somewhat knowledgeable, 60%
(_i.e.,_ 58) knowledgeable, and 19% (_i.e.,_ 18) very knowledgeable. We
respectively assign these participants to low (21), medium (58), and high-
profile (18) groups in this domain.

###  III-A Developer demographics

We analyzed whether age, experience in programming, or education are
correlated to knowledge in cryptography. Unsurprisingly, the older
participants are, the more experienced they are in programming. Although
experienced participants exist in every knowledge group, there is a clear
distinction between high to medium-profile developers and low-profile
developers (See Figure 1). All participants from the high-profile group have
more than 10 years of experience in programming, and there are no participants
from high or medium-profile groups with fewer than 5 years of experience in
programming. The same pattern was seen among the groups for years of
programming experience in Java. The education level is almost evenly
distributed among the three groups. Of the seven Ph.D. participants, five
belong to the medium-profile group.

_Developers with a high or medium level of knowledge in cryptography have more
years of experience in programming and Java._

Figure 1: Years of experience in programming and Java

###  III-B Developer characteristic

To have a glance at developer characteristic, we examined the relationship
between developer knowledge and any of the following: security course
attendance, experience in using crypto libraries, background in IT-security,
developer security concern, ways of solving crypto problems and evaluating a
crypto code, and working as a source code auditor.

With regards to security or cryptography course attendance, the more knowledge
developers had, the more courses they attended. The high group has the highest
number of participants (22%) attending both courses, while there are 9% and
14% such participants of the medium and low groups, respectively. The number
of participants who attended such courses is below 40% in all groups.

Although several participants (_i.e.,_ 15) responded that they worked as a
secure code auditor, they belong to different knowledge groups, _i.e.,_ high
(3), medium (10), and low (2). Just over a half (_i.e.,_ 53%) of such
participants never attended a security or cryptography course, whereas the
rest (_i.e.,_ 7) attended security and cryptography courses.

In total, 38% of participants (_i.e.,_ 37) reported that they had background
in IT security. We observed that a very large proportion (86% and 61%) of the
low and medium-profile participants had no background in IT security. In
contrast, 61% of the high-profile developers expressed their security-relevant
background, achieved through various methods _e.g.,_ bachelor and master
thesis on software security, or personal enthusiasm and self-study in software
security.

Notably, all respondents from the high-profile group stated that they have at
least two years of experience in using crypto libraries, whereas 52% and 21%
of the low and medium-profile developers are not highly experienced (_i.e.,_
<= 2 years) with such crypto libraries.

We received 47 responses regarding the hindrances developers encounter when
dealing with cryptographic tasks. The majority of them mentioned two key
obstacles: the first was the high complexity of using crypto APIs. For
instance, a developer mentioned that “Wide variety of configuration options”
is troublesome. The second obstacle concerned unreliable sources and lack of
security experts in teams. For example, one participant blamed “Poor Java
docs”. More than half of the 47 respondents (63%) were from medium-profile
developers, and 17% of them were from the high-profile group. This means that
developers who still feel confident about their knowledge in cryptography
struggle to use them in the wild.

_A large proportion of low-profile developers have no IT security background,
while more than half of the high-profile developers do have such backgrounds.
High-profile developers have slightly better records in the
security/cryptography course attendance and considerably more years of
experience in using crypto libraries than other developers, whereas medium and
low-profile developers are almost similar. developers from all groups mainly
complained about the complexity of crypto APIs and insufficient
documentation._

With regards to developer security concerns, 81% of developers rated their
concern as _important_ or _very important_. Remarkably, 61% high-profile
developers are _very_ concerned with security while 33% and 43% from low and
medium groups reported the same level of concern (See Figure 2). Only one
high-profile developer is _somewhat_ concerned with security while 19% of low-
and 17% of medium-profile developers reported the same level.

Figure 2: Security concern by participants

Participants reported various information sources to solve the challenges in a
cryptography-related task (presented in Table II). In particular, the primary
information sources seem to be online. In each of the three groups, websites
found on search engines and Stack Overflow are among the top three preferred
approaches. It is noteworthy that the role of information security experts is
not as commonly cited as other approaches. Participants only from high- and
medium-profile groups consult with a security expert, and none of them are
from the low-profile group. High-profile participants prefer discussion with
colleagues, security consultants, and crypto stack exchange more than other
participants.

Just over half of the developers in all groups only evaluate their code
manually (See Figure 3). Remarkably, the total number of participants who use
a static analysis tool is fewer than one-fifth (_i.e.,_ 18) of the total
number of participants. In more detail, high-profile developers had the
highest usage of static analysis tools (28%), while low-profile developers had
the lowest usage of such tools (5%). Of ten developers who do not evaluate,
only one belongs to high-profile group.

_Unlike others, nearly all (_i.e.,_ 17) high-profile developers are
_extremely_ or _moderately_ concerned about security. Developers mainly solve
their crypto problems on Stack Overflow or websites returned by search
engines. The high-profile group benefits more from security consultants,
discussions with colleagues, and crypto Stack Exchange to resolve crypto
problems. Developers mainly evaluate crypto-related issues manually rather
than using analysis tools. All high-profile developers evaluate their crypto
code and they use static analysis more than others. In contrast, low-profile
developers tend to use static analysis tools less than others, and 16% do not
evaluate their code. _

TABLE II: The information sources that developers use - bold items are the highest | High | Medium | Low
---|---|---|---
Websites on search engines | 83% | 88% | 86%
Stack Overflow | 72% | %74 | %80
Crypto Stack Exchange | 34% | 33% | 19%
Security consultant | 28% | 10% | 0%
Books | 33% | 41% | 14%
Discussion with colleagues | 77% | 38% | 57%
Figure 3: How developers evaluate a crypto copy-pasted code

###  III-C Company characteristic

Developers were asked to respond to how concerned their companies are with
security (See Figure 4). More than half of the companies (_i.e.,_ 72) were
concerned (important and very important) with security. Furthermore, 71%
(_i.e.,_ 69) of the companies do not have any security consultant in their
team and 70% of the companies have no or fewer than 30% of developers
responsible for secure development. Disappointingly, we learned that 57%
(_i.e.,_ 53) of respondents do not receive security training at workplace. A
yearly training interval is the most common approach (27%), and a two-year
training interval is the least common approach (6%) among companies.

Figure 4: Security concerns by companies

We observed the mapping of “in-site consultant”, “regular training”, and
“responsible developers” with developer knowledge (See Figure 5). As expected,
in all three factors, high-profile developers reported positive responses
slightly more than the medium-profile group, and noticeably more than the low-
profile group. However, the medium and low-profile developers are very similar
concerning the in-site security consultant.

_The majority of companies are concerned with security but the lack of
security consultants, regular security training, and security developers are
inevitable. In particular, high-profile developers benefit more from the three
factors factors._

Figure 5: Security support provided by participant companies

##  IV Discussion and Related work

_Developer background:_ Acar _et al._ assigned 307 active GitHub users to
complete several security-relevant programming tasks and surprisingly, found
no statistically significant differences concerning functional correctness and
security perception among the participants who registered their status as a
student, professional developer, or those who had security background [18].
Interestingly, years of experience was not an effective factor for security
perception. Oliveira _et al._ designed a study for 109 developers to use some
APIs that had some blind spots, _i.e.,_ containing underlying causes to misuse
an API, and some easy to use ones [19]. The results show that developer
expertise and experience did not predict their ability to identify blind
spots. In another study, the outcome of an experiment with 54 professional and
inexperienced developers for writing security-related code explains that
development experience is not a decisive factor for code security [12]. Nadi
_et al._ conducted two surveys and asked developers about the issues they face
when working with crypto tasks [5]. The participants mentioned several types
of issues including lack of documentation, difficulty in API use, and
indirection between the APIs and the underlying implementation. The authors
also realized that developers from various knowledge level groups still face
the same types of issues in cryptography. Robillard _et al._ conducted surveys
and interviews with Microsoft developers, and realized that poor documentation
is a major learning obstacle for learning APIs [21]. To alleviate unsafe
coding practices, security training courses, _e.g.,_ secure programming, are
more effective compared to general security training [15].

_Security tool adoption:_ Johnson _et al._ conducted interviews with 20
developers to understand the determinant factors why static analysis tools
were not adopted by many developers [8]. Participants mentioned reasons such
as the high rate of false positives, the way that warnings are displayed,
faulty integration of the tool into the development process, lack of detailed
explanation of bugs with automatic fixes, and not including understandable
configuration options in the tool for all levels of developers. Other
researchers investigated the reasons for a low rate of security tool adoption
[9] [22]. They found that organization and team policies affect the usage of
security-related tools and larger organizations use security tools more than
small ones. The greater adoption of security tools can be influenced by
factors such as the culture of the company, security concerns, training, and
dedicated security and testing teams.

_Ways of solving crypto problems:_ Even though using Stack Overflow might help
the functional correctness, it leads to more insecure copy-pasted code
snippets [12]. Ye _et al._ worked on a system called insecure code snippet
detection (ICSD) to detect the imminent insecure code snippets on Stack
Overflow [23]. In a survey with 87 Stack Overflow visitors, they reported
outdated answers, wrong solutions, and buggy code. Their results cast light on
the choice for finding programming solutions, and how often they reused a
prepared solution. Stack Overflow had the first rank in finding solutions.
Acar _et al._ conducted a comprehensive study by surveying 295 app developers,
and a lab study with 54 Android developers (professionals and students) in
which they were allowed to resolve coding issues with one of the following
four means: any resources, Stack Overflow only, official Android documentation
only, or books only [12]. Their findings suggest that developers use Stack
Overflow as a major source. Interestingly, developers who could use any
resources had similar performance (functional and security correctness) to
those who were assigned to use Stack Overflow only. The lack of an official
role in organizations as security champions/consultants is evident, and
oftentimes this role is given to someone on the development team with limited
security knowledge. By hiring security consultants, managers can gain positive
impacts from the resulting security level of products, and security testers
would largely benefit from the presence of such consultants [11] [13].

_Security concern:_ Witschey _et al._ conducted a study to understand what
factors affect the usage of security tools [24]. Strangely enough, being more
concerned about security did not lead to greater security tool usage while
having training or academic background in the security field did. Research
indicates that some organizations use external resources,_e.g.,_ penetration
testers, to encourage developers to pay extra attention to security in
development, however, without strong support, the motives tend to lose
priority compared to the important functional requirements [10]. Likewise,
managers sometimes are obliged to make vital decisions, such as releasing the
code with some known problems, due to business forces [11].

_Security training:_ The need for regular information security training is
undeniable in companies [14]. From the training frequency viewpoint, quarterly
security awareness training is recommended to renew employee knowledge
concerning the latest threats and trends, and in case some difficulties exist,
biannual training could be the minimum required time frame [16]. Puhakainen
_et al._ stressed that information security trainings and communication
efforts should be continuous and integrated into the organization’s usual
communication efforts otherwise security policies lose their efficacy [25].
According to the SANS Institute, a security awareness program should consider
who is going to be in the training course, which topics are suitable for the
audience, and ultimately how participants engage in order to identify how
frequent security training should take place.333https://www.sans.org/security-
awareness-training/blog/wrong-question-how-long-should-security-awareness-
training-be

By studying the literature we found clear evidence to corroborate the findings
of this study. Each of the discussed studies either solely explored one factor
and obtained similar results or they emphasized the importance of the studied
factor to improve the state of developers in security or cryptography. We
believe that even though 81% of the participants, as well as 75% of their
companies, are utterly concerned, _i.e.,_ _important_ or _very important_ ,
about security, the practices of the participants and companies do not accord
with their grave security concern. However, conducting a survey has some
inherent limitations. To profoundly investigate this matter, we plan to
conduct interviews with some of the participants who provided their email
addresses to inspect organizational policies, project-level limitations, and
objectives..

##  V Threats to validity

Our sample of software developers using crypto APIs on GitHub is limited in
size. To increase the number of such developers, more crypto open-source
projects need to be identified, and associated developers must be extracted.
In the survey, there was no participant who reported _no knowledge of
cryptography_ , and we did not exclude any participant from our analysis. All
the participants had used crypto APIs in Java open-source projects, and it was
unexpected to receive responses indicating no knowledge of cryptography.
Developers, in general, may have different viewpoints on how to evaluate their
knowledge in a specific area, such as cryptography. To lower the risk of bias
assumption, we provided the participants in the survey with an extra
definition of what each level of knowledge is intended to mean, and the four-
level knowledge used in a previous study [5]. To grasp the real knowledge of
developers, we need to judge developer knowledge based on their real
performance, _i.e.,_ in a controlled experiment. We only asked the
participants about their companies’ practices since we did not intend to ask
about the names or web addresses. Even though we received 97 responses from
1103 potential participants, it may be possible that more than one participant
refers to the same company.

##  VI Conclusions

We surveyed 97 developers, who used cryptography in open-source projects, and
studied their security and cryptography practices. Our analyses demonstrate
that high-profile developers reported better to the developer- and company-
level questions, _e.g.,_ security tool usage, and background in IT security.
It should be recalled that over 70% of the participants and their companies
are utterly concerned about security. Nevertheless, a number of worrisome
patterns, _e.g.,_ lack of regular security training and security consultants
and low rate of security tool usage, were observed in other participants’
responses. The results provide corroborative evidence supporting the outcome
suggested by prior research. To further understand the root causes of
developer practice in this area, future studies should consider organizational
policies, project-level limitations and objectives, and developer expertise in
practice.

##  VII Acknowledgments

We gratefully acknowledge the financial support of the Swiss National Science
Foundation for the project “Agile Software Assistance” (SNSF project No.
200020-181973, Feb. 1, 2019 - April 30, 2022).

## References

  * [1] M. Hazhirpasand, M. Ghafari, S. Krüger, E. Bodden, and O. Nierstrasz, “The impact of developer experience in using Java cryptography,” in _2019 ACM/IEEE International Symposium on Empirical Software Engineering and Measurement (ESEM)_. IEEE, 2019, pp. 1–6.
  * [2] M. Hazhirpasand, O. Nierstrasz, M. Shabani, and M. Ghafari, “Hurdles for developers in cryptography,” in _37th International Conference on Software Maintenance and Evolution (ICSME)_ , 2021.
  * [3] S. Kafader and M. Ghafari, “Fluentcrypto: Cryptography in easy mode,” in _37th International Conference on Software Maintenance and Evolution (ICSME)_ , 2021.
  * [4] M. Hazhirpasand, M. Ghafari, and O. Nierstrasz, “Java cryptography uses in the wild,” in _Proceedings of the 14th ACM/IEEE International Symposium on Empirical Software Engineering and Measurement (ESEM)_ , 2020, pp. 1–6.
  * [5] S. Nadi, S. Krüger, M. Mezini, and E. Bodden, “Jumping through hoops: Why do java developers struggle with cryptography apis?” in _Proceedings of the 38th International Conference on Software Engineering_ , 2016, pp. 935–946.
  * [6] M. Egele, D. Brumley, Y. Fratantonio, and C. Kruegel, “An empirical study of cryptographic misuse in Android applications,” in _Proceedings of the 2013 ACM SIGSAC Conference on Computer & Communications Security_, ser. CCS ’13. New York, NY, USA: ACM, 2013, pp. 73–84. [Online]. Available: http://doi.acm.org/10.1145/2508859.2516693
  * [7] I. Muslukhov, Y. Boshmaf, and K. Beznosov, “Source attribution of cryptographic api misuse in android applications,” in _Proceedings of the 2018 on Asia Conference on Computer and Communications Security_ , 2018, pp. 133–146.
  * [8] B. Johnson, Y. Song, E. Murphy-Hill, and R. Bowdidge, “Why don’t software developers use static analysis tools to find bugs?” in _Proceedings of the 2013 International Conference on Software Engineering_. IEEE Press, 2013, pp. 672–681.
  * [9] N. Ayewah and W. Pugh, “A report on a survey and study of static analysis users,” in _Proceedings of the 2008 workshop on Defects in large software systems_. ACM, 2008, pp. 1–5.
  * [10] S. Xiao, J. Witschey, and E. Murphy-Hill, “Social influences on secure development tool adoption: why security tools spread,” in _Proceedings of the 17th ACM conference on Computer supported cooperative work & social computing_. ACM, 2014, pp. 1095–1106.
  * [11] T. W. Thomas, M. Tabassum, B. Chu, and H. Lipford, “Security during application development: An application security expert perspective,” in _Proceedings of the 2018 CHI Conference on Human Factors in Computing Systems_ , 2018, pp. 1–12.
  * [12] Y. Acar, M. Backes, S. Fahl, D. Kim, M. L. Mazurek, and C. Stransky, “You get where you’re looking for: The impact of information sources on code security,” in _2016 IEEE Symposium on Security and Privacy (SP)_. IEEE, 2016, pp. 289–305.
  * [13] A. Poller, L. Kocksch, S. Türpe, F. A. Epp, and K. Kinder-Kurlanda, “Can security become a routine? A study of organizational change in an agile software development group,” in _Proceedings of the 2017 ACM conference on computer supported cooperative work and social computing_ , 2017, pp. 2489–2503.
  * [14] J. A. Valentine, “Enhancing the employee security awareness model,” _Computer Fraud & Security_, vol. 2006, no. 6, pp. 17–19, 2006.
  * [15] M. Nadeem, E. B. Allen, and B. J. Williams, “Computer security training recommender for developers.” in _RecSys Posters_ , 2014.
  * [16] B. Gardner and V. Thomas, _Building an information security awareness program: Defending against social engineering and technical threats_. Elsevier, 2014.
  * [17] M. P. Robillard, “What makes apis hard to learn? answers from developers,” _IEEE software_ , vol. 26, no. 6, pp. 27–34, 2009.
  * [18] Y. Acar, C. Stransky, D. Wermke, M. L. Mazurek, and S. Fahl, “Security developer studies with GitHub users: Exploring a convenience sample,” in _Thirteenth Symposium on Usable Privacy and Security ( $\\{$SOUPS$\\}$ 2017)_, 2017, pp. 81–95.
  * [19] D. S. Oliveira, T. Lin, M. S. Rahman, R. Akefirad, D. Ellis, E. Perez, R. Bobhate, L. A. DeLong, J. Cappos, and Y. Brun, “API blindspots: Why experienced developers write vulnerable code,” in _Fourteenth Symposium on Usable Privacy and Security SOUPS 2018)_ , 2018, pp. 315–328.
  * [20] B. Batinic and M. Bosnjak, “11 fragebogenuntersuchungen im internet,” _Internet für Psychologen_ , p. 287, 2000.
  * [21] M. P. Robillard and R. DeLine, “A field study of api learning obstacles,” _Empirical Software Engineering_ , vol. 16, no. 6, pp. 703–732, 2011.
  * [22] N. Ayewah, W. Pugh, D. Hovemeyer, J. D. Morgenthaler, and J. Penix, “Using static analysis to find bugs,” _IEEE software_ , vol. 25, no. 5, pp. 22–29, 2008.
  * [23] Y. Ye, S. Hou, L. Chen, X. Li, L. Zhao, S. Xu, J. Wang, and Q. Xiong, “Icsd: An automatic system for insecure code snippet detection in stack overflow over heterogeneous information network,” in _Proceedings of the 34th Annual Computer Security Applications Conference_ , 2018, pp. 542–552.
  * [24] J. Witschey, O. Zielinska, A. Welk, E. Murphy-Hill, C. Mayhorn, and T. Zimmermann, “Quantifying developers’ adoption of security tools,” in _Proceedings of the 2015 10th Joint Meeting on Foundations of Software Engineering_. ACM, 2015, pp. 260–271.
  * [25] P. Puhakainen and M. Siponen, “Improving employees’ compliance through information systems security training: an action research study,” _MIS quarterly_ , pp. 757–778, 2010.