awareness of the necessary security skill set (D33), and accessibility to
learning resources (D26). For instance, Mokhberi and Beznosov [38] pointed out
the role of personality as one of the human dimensions of developers’
challenges in engineering secure software. Lack of confidence and false
confidence are reasons developers mistakenly believe that their code is
secure. Thus, they are unable to recognize vulnerabilities in their code.
Additionally, Votipka et al. [45] acknowledged that the primary reason why
teams do not implement security is due to a lack of knowledge and, above all,
experience in different types of vulnerabilities. Furthermore, Sajwan et al.
[42] emphasized that organizations usually employ traditional training
resources and methods that developers do not feel are practical and
actionable. Most of these learning resources focus on policies and protocols,
reading, watching videos, or office conversation by either internal teams or
external parties.

Other researchers have highlighted four essential drivers that influence
developers in the adoption of security practices: providing security education
(D28), having non-technical skills (D31), creating and participating in
communities of practice (D30), and fostering hands-on learning, self-teaching,
and osmosis (D29). For instance, Weir et al. [46] pointed out that security-
related workshops facilitated by managers appear more effective than those
facilitated by developers or security specialists. Additionally, Haney et al.
[24] emphasized the relevance of having interpersonal skills, in particular,
communication skills for dealing with all stakeholders involved in a security
issue. Furthermore, researchers have reported that knowledge sharing is
crucial for learning security practices. Developers learn the best from
talking to other people in their teams as they can learn more technical skills
while applying existing knowledge [42]. Researchers have also emphasized the
crucial role of peer-based learning as an effective method to learn security
practices. Developers usually perceive mentoring as an effective way to
understand the rationale behind threats and techniques to mitigate them [46].
Interestingly, no previous studies have pointed out the essential role of
using security practices as learning tools (D27).

Comparing and contrasting drivers identified in our study with current
literature. In the above, we compared the drivers from our study with those
found in the literature we reviewed.

In particular, the Mokhberi and Beznosov’s [38] recent systematic literature
review is the closest to our work. They presented a set of 17 areas of
challenges across three dimensions: human, organizational, and technological.
Their results align with 28 of our drivers, but they mentioned two factors
that did not emerge from our findings. First, sometimes responsibilities and
roles defined in the software teams might conflict with applying security, and
therefore, developers will not follow security practices. Second, developers
may misuse APIs/libraries, which leads to decreasing security in an
application, making it easier to exploit. Another study related to our work is
the systematic literature review conducted by Rauf et al. [35]. The authors
presented a catalog of factors that influence developers’ security behavior.
Their work introduced 17 internal factors and 11 external factors analyzed
from three different perspectives: knowledge deficit, attention deficit, and
intention deficit. Their set of factors aligns with 19 of our drivers, and
they did not mention any other drivers that we did not find in our study.

As we indicated before, three of our 33 drivers have not been identified in
the literature we reviewed. They are D17: awareness of the influential role of
the industry type in developers’ disposition towards security compliance, D20:
consideration of tool constraints on developers’ autonomy, and D27: using
security practices as learning tools. We were surprised that these drivers did
not appear in any of the 15 papers we reviewed (two of which were quite
comprehensive systematic reviews). In the related literature, we did not find
any studies that highlighted how developers’ disposition towards security
compliance is highly influenced by, what the general industry mindset
considers relevant, in terms of security. For example, developers working in
the game industry or chip manufacturing tend to be more reluctant to adopt
software security practices because the entire industry focuses on security,
not at the application level but the infrastructure level. Additionally,
researchers have given less attention to developers’ perceptions regarding how
the use of tools for security could affect their autonomy. Therefore, tools
can become a deterrent to adopting security due to the restrictions imposed on
developers’ workflows. Moreover, we did not find related literature that
explores the effects of security learning when performing security practices,
even though the feedback collected while implementing a security practice can
be a tremendous learning tool for developers. Section 4 describes these
drivers in more detail.

##  6 Discussion

In this section, we review the implications of our findings. First, we discuss
the implications for organizations, and our recommendations for developers and
security specialists when adopting or advocating security practices. Then, we
discuss how researchers can use the power of behavioral theories to understand
and frame research on software security.

###  6.1 Implications for Organizations

Since organizations play the most crucial role in fostering the adoption of
software security practices, our study pointed to several recommendations for
them. In the following, we discuss how they can use the DASP framework as a
diagnosis tool to help identify which aspects of their security practices
could be improved. Then, we discuss what organizations need to consider when
understanding the perspectives of developers and security specialists, and
additional considerations they should be aware of when applying the DASP
framework.

####  6.1.1 How to use the DASP framework

Organizations interested in promoting software security practices across
different teams and stakeholders should carefully consider developers’
behaviors and identify their perceptions and attitudes regarding their
capabilities, opportunities available to them, and their motivations for
adopting software security practices. Based on our findings, we propose DASP,
a framework that consists of a comprehensive list of 33 drivers that represent
what needs to change or happen so that the adoption of software security
practices occurs. In Table V, we present the complete list of drivers.
Following the Behavior Change Wheel (BCW) approach, these drivers are the
starting point to design interventions to foster an effective organizational
security culture and motivate developers to write secure code. As we described
in Section 2, we recommend that organizations use DASP to conduct the steps
indicated in Figure 12.

Figure 12: The Three Stages of the Behavior Change Wheel including some
intervention functions, policy categories, and behavior change techniques, as
indicated in Fig. 1.

Stage 1: The goal of this stage is to use the DASP framework to identify which
drivers apply to the organization’s particular context. To achieve this,
organizations should conduct focus groups or semi-structured interviews,
considering the perspectives of most stakeholders, from developers to
managers. In the case of big corporations, where collecting data could be
challenging due to the significant number of stakeholders involved in ensuring
a secure product, another potential mechanism is to conduct a survey. A survey
could help collect the level of agreement or disagreement concerning the
drivers influencing stakeholders to adopt software security practices. In the
end, the output of this stage is a subset of drivers that are relatable to the
organization’s context.

Stage 2: The goal of this stage is to identify the most appropriate
intervention functions and then select their respective policy categories,
which will serve as the foundation to design and deliver an intervention.

To select the most relevant intervention functions, organizations should use
the subset of drivers identified in Stage 1 to shift from diagnosis to
intervention. Organizations need to build a matrix using the COM-B model
components and the 9 intervention functions proposed by the BCW. As detailed
in Section 2, the COM-B model components to take into account are Technical
Capabilities, Non-technical Capabilities, Psychological Capabilities,
Technical Opportunities, Social Opportunities, Reflective Motivations, and
Automatic Motivations, and the intervention functions to consider are
Education, Persuasion, Incentivisation, Coercion, Training, Restriction,
Environmental restructuring, Modeling, and Enablement. By using this matrix,
organizations should be able to identify the intervention functions associated
with their context. For example, our study identified a strong relationship
between Training and Psychological capabilities. Developers perceived that
having tailored security training is crucial for building confidence in
implementing software security practices.

The next step in developing an intervention strategy is to select the policy
categories that can help deliver and implement the intervention. The BCW
indicates which policy categories are the most suitable in supporting each
intervention function. Following these indications, organizations should
select the most appropriate policy categories associated with their
intervention functions. For example, concerning Training, some essential
policy categories are Guidelines, Fiscal measures, Regulation, Legislation,
and Service provision. A complete list of the 7 policy categories and their
definitions is detailed in Table II.

Stage 3: The goal of this stage is to determine which Behavior Change
Techniques (BCTs) can support the delivery of the identified intervention
functions under the relevant policy categories. Michie et al. [12] defines a
BCT as an active component of an intervention designed to change behavior.
BCTs are also observable, replicable, and irreducible components of an
intervention. Michie et al. [27] introduces a taxonomy of 93 BCTs as a method
for specifying interventions. With this knowledge, organizations may select
the most frequently used BCTs for their particular intervention functions. For
example, in the case of the Training intervention function, some of the most
frequently used BCTs are Feedback on behavior, Feedback on outcome(s) of
behavior, Monitoring of behavior by others without evidence of feedback,
Monitoring of outcome of behavior by others without evidence of feedback, and
Self-monitoring of behavior. For example, a description of the content of an
intervention would be “Organizations should set the goal of training
developers to identify potential risks in their source code, enabling them to
understand security standards, associate those standards with threats and
compliant code examples.”

####  6.1.2 What organizations need to take into account when understanding
developers’ perspectives

Our work revealed several attitudes and beliefs that are useful for
organizations and researchers to understand the developer mindset behind
software security practices. First, developers often perceive the
disadvantages of adopting security more quickly than the immediate benefits,
e.g., time-consuming, delay feature delivery, add restrictions to their
workflow, etc. Developers’ mindsets typically have the time-pressure concern
as their goals focus on delivering features. If security is not baked into the
development pipeline, it will usually be overlooked if there are competing
priorities. Additionally, developers are influenced to adopt security
practices when other team members embrace the same practices. However,
management becomes a deterrent if they do not support developers’
proactiveness towards security. When a security role is present on the team,
developers usually ignore or delegate security practices as they consider
those practices outside their core responsibilities.

Furthermore, developers might self-assess their security knowledge and
capabilities with high scores. Extensive development experience can produce
false confidence in the ability to effectively conduct a security practice
without knowing the necessary security skill set required. Finally, most
developers who are passionate about security have experienced security
exploits in the past. The fear of suffering another attack is their primary
motivation to keep their security knowledge up-to-date and advocate security
concerns among peers. External events that impact developers’ emotions have a
high likelihood of sticking in a developer’s mind for a longer period of time
and will shape their attitude towards understanding and evaluating future
risks. By default, it is relevant to acknowledge that it is not part of the
developer’s mindset to think upfront about risks and what could go wrong when
customers misuse the applications they develop. Therefore, it is essential
that any corporate security training highlight these potential scenarios.

####  6.1.3 What organizations need to take into account when understanding
security specialists’ perspectives

Developers and security professionals have different mindsets. Security
specialists are usually more pessimistic because they tend to prioritize risks
over product features. Moreover, since security is the day-to-day work for a
security professional, they usually employ technical communication that
developers typically are not familiar with. As a result, their perspectives
concerning the impact of patching a security vulnerability might considerably
differ from developers or engineers. Finally, since a security professional’s
primary focus is on identifying potential risks/threats and complying with
security guidelines, their biased perspective might make it more challenging
to see the overall impact of any change on the application. This situation
becomes a threat in the organization when security teams analyze the trade-
offs of applying security without the collaboration of developers and software
architects.

####  6.1.4 Additional considerations organizations should be aware of when
applying the framework

The following considerations were emphasized by our participants during the
member-checking sessions.

A security diagnosis should be conducted periodically. Using the COM-B model
as a diagnosis tool implies identifying what drives developers to adopt
software security practices. However, practitioners’ perceptions, attitudes,
and motivations can change over time due to external factors or events. In
this scenario, the applicability of specific drivers to the current
organization’s context could be outdated. Therefore, it is essential to
acknowledge these potential changes and periodically monitor them to ensure
that the strategies or interventions are not based on inaccurate facts or
observations.

A just enough security approach for startup companies. In the case of startup
companies, the concern around adopting software security practices when
developing a product-market fit is only addressed if the targeted consumer
demands it. Otherwise, other non-functional requirements will have higher
priority. Security specialists recommend startups with limited resources focus
on delivering a just enough secure product, and if required, invest in
training developers in security practices instead of hiring specialized
resources. If available, external incentives, such as IRAP
141414https://nrc.canada.ca/en/support-technology-innovation/about-
nrcindustrial-research-assistance-program in Canada, may be beneficial to
introduce security testing practices provided by external parties to guarantee
a certain level of quality in terms of security. This opportunity will also
help developers acknowledge their typical security mistakes and which topics
to focus on in their self-directed security learning process.

Non-technical skills matter. Practitioners highlighted how it is essential to
be aware of the security skill set required to implement security in the
software development pipeline. Although most of our participants’ first
thoughts pointed out several security technical skills, they also mentioned
different challenges related to interpersonal skills that, surprisingly, are
usually not discussed in organizational security training. And when
overlooked, it could seriously impact how security is handled within the
organization, especially when multiple stakeholders are involved in security
decisions and product development. It is worth mentioning that most security
challenges are indirectly related to conflict management, negotiation skills,
communication ability, and empathy. Therefore, we encourage organizations to
include topics related to non-technical skills as part of any security
training program, which is helpful in the context of security and boosts
collaboration and productivity in the company.

###  6.2 Recommendations for Developers When Adopting Security Practices

In addition to organizational recommendations, the drivers identified in our
study point to specific recommendations for developers:

  * •

Passionate software developers care about the quality of their code. Security
is an essential quality aspect of any software product, and its adoption
gradually grows with experience. In addition, when learning a new software
technology, e.g., a programming language or a framework, developers should
take the necessary time to learn how to use it securely, not just assume that
default configurations or standard ways to use it are secure.

  * •

If security is not part of the organizational culture, this can be an
excellent opportunity to advocate the relevance of baking security into the
development workflow. Developers should look for sponsorship at the management
level. With management’s support, any effort towards security will be more
straightforward and significant.

  * •

When advocating for security, there can be some reluctance to change.
Different stakeholders have different perspectives and priorities regarding
security. To advocate for security more effectively, developers need to
acquire the ability to translate security threats into technical and business
risks. Arguments based on risks are more compelling and easier to understand.

  * •

The adoption of security practices has an undeniable social connotation. It is
recommended that developers start advocating for security among their peers.
Raising a collective need or concern for security from engineering teams will
significantly impact management levels more than any individual approach.

  * •

Including security in the software development pipeline introduces several
policies and restrictions around tools, frameworks, and open-source
components. Developers should recognize that having full autonomy in technical
decisions will cause a chaotic development environment, making it challenging
for any stakeholder to ensure a secure development workflow and product.

  * •

Developers should leverage their current working environment to customize
their learning path. The presence of a security-specific role in the
organization willing to mentor through peer-to-peer learning or osmosis is a
practical and valuable learning approach. For example, some realistic
scenarios are developers shadowing a security specialist or being indirectly
involved in fixing security vulnerabilities.

  * •

Developers should take advantage of software security practices conducted
within the organization. They are an important opportunity for developers to
follow a learning-by-doing approach, master software security skills, and
receive actionable feedback to improve their development practices, e.g.,
through security code reviews.

  * •

We recommend developers participate in communities of practice led by software
security professionals. They are an active community in the industry,
continuously organizing meet-ups, conferences, and workshops where they share
valuable security resources and their experiences dealing with security
vulnerabilities.

  * •

We recommend developers use software security practices such as code reviews
to self-assess their software security skills. Feedback from security code
reviews can help developers identify flaws in their coding practices and
suggest topics to include in an organizational security training program.

  * •

Confidence in performing software security tasks is an essential aspect that
developers achieve through proper training and experience. However, developers
should be aware that overconfidence is a deterrent to improving their security
practices, assimilating feedback, and maintaining the knowledge required to
deal with security exploits that are getting more sophisticated and harmful.

###  6.3 Recommendations for Security Specialists When Advocating for Security

The drivers we identified in our study also suggest a number of
recommendations for security specialists:

  * •

The developers in our study perceived that most security guidelines are
abstract and not developer friendly. We suggest security specialists
facilitate the comprehension of security guidelines by highlighting the
relationship between security threats, non-compliant code examples, and
compliant solutions. In other words, when designing security guidelines,
security professionals should use a technical vocabulary that developers are
more familiar with.

  * •

Most developers typically access Q&A forums, e.g., Stack
Overflow151515https://stackoverflow.com/, to gather knowledge, share
expertise, and address security and development concerns. Therefore, security
professionals should proactively approach Q&A forums to get one step closer to
developers’ communities, advocating for security while interacting with
developers by building awareness of security tools, potential security
threats, and the risks of overlooking secure coding practices.

  * •

Developers demand tailored security training that reflects their particular
information needs and software development context. Developers perceive
generic security training as too abstract, time-consuming, and ineffective.
When designing security training to meet developers’ needs, security teams or
security specialists should identify developers’ typical security mistakes
through their interactions with engineering teams. For example, the
interactions during security code reviews can be a valuable source of
information.

  * •

Developers who are passionate about security are usually self-taught software
security practitioners. However, the amount of resources and topics to learn
is typically overwhelming. Therefore, security teams should facilitate
developers’ learning process by allowing them to know the rationale behind the
compliance with security guidelines and the necessary skills to tackle their
typical security mistakes. In this way, developers will learn faster, remember
security guidelines easier, gradually build confidence in their technical
skills, and reduce the chance of repeating the same security mistakes.

###  6.4 The Power of Behavioral Theories for Software Security Researchers

Our work is related to developer-centric security research. Since software
development is intensely human driven, researchers must consider developers’
behaviors, attitudes, beliefs, perceptions, and motivations to introduce any
positive change in software engineering practices. Our study highlights the
opportunity for the software engineering research community to analyze
software security challenges through the lens of behavioral science theories.
Most efforts from industry and academia in the area of software security has
focused on providing exceptional security standards, sophisticated security
tools, free online learning resources, understanding the effectiveness of
having specific security roles in the engineering teams, and encouraging
shifting security to the left or earlier stages of the software development
pipeline. However, little attention has been dedicated to allowing
organizations to design effective interventions to foster the adoption of
software security practices among developers.

Additionally, our work exposes a holistic view of all behavioral aspects that
affect how developers adopt a target behavior, such as capabilities,
opportunities, and motivations. Developers will be willing to adopt a new
practice if they feel confident and capable of doing it, have the right
opportunities and conditions in their work environment, and feel motivated to
perform the target behavior. Our study opens the door to further research to
introduce behavior change techniques to understand developer and other
stakeholder behaviors. This knowledge will serve as the foundation to design
interventions to motivate them to adopt software security practices.

##  7 Threats to Validity

In the following, we address the validity of this study in the context of
qualitative research [16, 17].

###  7.1 Transferability

Transferability is the degree to which we can transfer our results to other
contexts. Our study was based on semi-structured interviews gathering the
experiences of 28 software engineers and security specialists. Given that
their experiences, companies, technology stacks, and business domains varied
considerably, the drivers identified in our study should fit most software
development organizations. However, we did not include open-source developers
in our work, geographical and cultural determinants to analyze our data, such
as cultural differences in power distance and individualism-collectivism [50].
In addition, we did not consider group dynamics that might influence security
adoption, such as organization identity, organization climate, and culture
[51]. Therefore, we suggest future research to understand whether the open-
source community considers our findings relevant for their context and how
geographical, cultural, and group dynamics-related factors may influence
developers’ adoption of security practices.

###  7.2 Credibility

Credibility concerns whether the research findings are correctly drawn from
the original data. We applied three strategies to ensure credibility: (a) the
list of drivers was iteratively developed by two researchers and examined by
an expert reviewer in each iteration. In addition, two researchers performed
the open coding of the transcribed interview data. At the beginning of the
open coding process, two open coding iterations were conducted to align the
perspectives of both researchers. After achieving at least 75% inter-rater
agreement, both researchers started coding independently, then (b) the set of
drivers, categories, and findings were discussed several times between all the
authors of this paper to mitigate bias from any particular researcher involved
in the study, and (c) the drivers were validated through 12 member-checking
sessions.

###  7.3 Confirmability

Confirmability is the degree to which other researchers can confirm the
findings. We do not have the participants’ permission to share the
transcriptions of the interviews. However, we tried to show as much evidence
as possible for each driver by quoting participants when describing our
results. Our interview script is available in our online appendix [49].

##  8 Conclusions

Adopting software security practices is a significant concern for any
industry. The exponential increase in security vulnerabilities exploited by
malicious hackers pushes the need to understand why software security is
neglected and why developers persist in introducing security flaws into their
applications. In this study, using the lens of the COM-B model, we
systematically explore what needs to change or happen so the adoption of
software security practices occurs. As a result, we propose DASP, which
consists of a comprehensive set of 33 drivers that describes the software
security adoption phenomena. Our work is the first to introduce a behavioral
change approach to understand developers’ behaviors when adopting software
security practices. Using DASP as a starting point, we foresee that
organizations will be able to design appropriately geared interventions
following the Behavioral Change Wheel framework. We hope our study insights
will help organizations help developers write better, more secure code,
ensuring a reliable and secure software product.

## Acknowledgments

The authors would like to thank the 28 interviewees for their availability in
this study, Dr. James Gibson for his remarkable insights in behavioral
psychology at the beginning of our study, and the members of the CHISEL group
at UVic for their invaluable feedback. We also acknowledge the support of the
Natural Sciences and Engineering Research Council of Canada (NSERC).

## References

  * [1] NIST, _National vulnerability database_ , 2021, accessed: 2021-10-04. [Online]. Available: https://nvd.nist.gov
  * [2] State of Software Security - Volume 11, 2021, https://www.veracode.com/blog/research/announcing-state-software-security-v11-open-source-edition, Accessed: 2021-10-05.
  * [3] The Daily Swig, https://portswigger.net/daily-swig/malicious-hackers-are-exploiting-known-vulnerabilities-because-organizations-arent-quick-enough-to-patch-report, Accessed: 2021-10-05.
  * [4] J. van der Pligt and M. Vliek, _The psychology of influence: Theory, research and practice_ , Routledge/Taylor & Francis Group, 2017.
  * [5] C. I. Hovland, , I. L. Janis, and H. H. Kelley, (1953). _Communication and persuasion: psychological studies of opinion change_ , New Haven: Yale University Press.
  * [6] M. Fishbein and J. Ajzen, (1975), _Belief, attitude, intention and behavior: an introduction to theory and research_ , MA: Addison-Wesley.
  * [7] N. K. Janz, and M. H. Becker, (1984), _The health belief model: A decade later_ , Health education quarterly, 11(1), 1-47.
  * [8] D. Kahneman and A. Tversky, (1979), _Prospect theory: an analysis of decisions under risk_ , Econometrica,47, 263–291.
  * [9] F. Strack and R. Deutsch, (2004), _Reflective and impulsive determinants of social behavior_ , Personality and social psychology review, 8(3), 220-247.
  * [10] A. Bandura, (1982), _Self-efficacy mechanism in human agency_ , American psychologist, 37(2), 122-127.
  * [11] S. Michie, M. M. van Stralen, R. West, _The behaviour change wheel: a new method for characterising and designing behaviour change interventions_ , Implement Sci., 2011, doi: 10.1186/1748-5908-6-42. PMID: 21513547; PMCID: PMC3096582.
  * [12] S. Michie, L. Atkins, and R. West, _The behaviour change wheel: A guide to designing interventions_ , 1st ed., London: Silverback, 2014
  * [13] F. Barker, L. Atkins, S. de Lusignan, _Applying the COM-B behaviour model and behaviour change wheel to develop an intervention to improve hearing-aid use in adult auditory rehabilitation_ , Int J Audiol, 2016, doi: 10.3109/14992027.2015.1120894. Epub 2016 Jan 12. PMID: 27420547.
  * [14] J. W. Creswell, _Research design: Qualitative, quantitative, and mixed methods approaches_ , Sage, 2013.
  * [15] H. H. Hiller and L. DiLuzio, _The Interviewee and the Research Interview: Analysing a Neglected Dimension in Research. Canadian Review of Sociology and Anthropology_ , 41(1), 1–26, 2004, https://doi.org/10.1111/j.1755-618X.2004.tb02167.x
  * [16] E.G. Guba, _Criteria for assessing the trustworthiness of naturalistic inquiries_ , 75, 1981, https://doi.org/10.1007/BF02766777
  * [17] I. Korstjens, A. Moser, _Series: Practical guidance to qualitative research. Part 4: Trustworthiness and publishing_ , 2018 Dec;24(1):120-124. doi: 10.1080/13814788.2017.1375092.
  * [18] I. Etikan, S. A. Musa, R. S. Alkassim, _Comparison of Convenience Sampling and Purposive Sampling_ , American Journal of Theoretical and Applied Statistics. Vol. 5, No. 1, 2016, pp. 1-4. doi: 10.11648/j.ajtas.20160501.11
  * [19] S. E. Hove and B. Anda, _Experiences from conducting semi-structured interviews in empirical software engineering research_ , 11th IEEE International Software Metrics Symposium (METRICS’05), 2005, pp. 10 pp.-23, doi: 10.1109/METRICS.2005.24.
  * [20] D. S. Cruzes and T. Dyba, _Recommended Steps for Thematic Synthesis in Software Engineering_ , 2011 International Symposium on Empirical Software Engineering and Measurement, 2011, pp. 275-284, doi: 10.1109/ESEM.2011.36.
  * [21] J.M. Corbin, A. Strauss, _Grounded theory research: Procedures, canons, and evaluative criteria_ , Qual Sociol 13, 3–21 (1990). https://doi.org/10.1007/BF00988593
  * [22] M. B. Miles, A. M. Huberman, and J. Saldana, _Qualitative data analysis: A methods sourcebook_ , 2014.
  * [23] A. L. Strauss and J. M. Corbin, _Grounded theory in practice_ , Sage Publications, Inc, 1997.
  * [24] J. Haney, W. Lutters and J. Jacobs, _Cybersecurity Advocates: Force Multipliers in Security Behavior Change_ , in IEEE Security & Privacy, vol. 19, no. 4, pp. 54-59, July-Aug. 2021, doi: 10.1109/MSEC.2021.3077405.
  * [25] J. Haney and W. Lutters, _Security Awareness Training for the Workforce: Moving Beyond “Check-the-Box” Compliance_ , in Computer, vol. 53, no. 10, pp. 91-95, Oct. 2020, doi: 10.1109/MC.2020.3001959.
  * [26] S. Michie, L. Atkins, and H.L. Gainforth, _Changing Behaviour to Improve Clinical Practice and Policy_ , 2016.
  * [27] S. Michie, M. Richardson, M. Johnston, C. Abraham, J. Francis, W. Hardeman, MP Eccles, J. Cane, CE. Wood CE, _The behavior change technique taxonomy (v1) of 93 hierarchically clustered techniques: building an international consensus for the reporting of behavior change interventions._ Ann Behav Med, 2013, Aug;46(1):81-95. doi: 10.1007/s12160-013-9486-6. PMID: 23512568.
  * [28] A. Bandura, _Self-efficacy_ , In V. S. Ramachaudran (Ed.), Encyclopedia of human behavior (Vol. 4, pp. 71-81). New York: Academic Press. (Reprinted in H. Friedman[Ed.], Encyclopedia of mental health. San Diego: Academic Press, 1998).
  * [29] A. Bandura, _Self-efficacy: Toward a unifying theory of behavioral change_ , Advances in Behaviour Research and Therapy, Volume 1, Issue 4, 1978, Pages 139-161, ISSN 0146-6402, https://doi.org/10.1016/0146-6402(78)90002-4.
  * [30] A. D. Stajkovic, F. Luthans, _Social cognitive theory and self-efficacy: Going beyond traditional motivational and behavioral approaches_ , Organizational Dynamics, Volume 26, Issue 4, 1998, Pages 62-74, ISSN 0090-2616, https://doi.org/10.1016/S0090-2616(98)90006-7.
  * [31] R. W. Rogers, 1975. _A Protection Motivation Theory of Fear Appeals and Attitude Change_ , Journal of Psychology (91), pp.93-114, https://doi.org/10.1080/00223980.1975.9915803
  * [32] K. Witte, and M. Allen, (2000), _A meta-analysis of fear appeals: implications for effective public health campaigns_ , Health education & behavior : the official publication of the Society for Public Health Education, 27(5), 591–615. https://doi.org/10.1177/109019810002700506
  * [33] I. Ajzen, (1991), _The theory of planned behavior_ , Organizational Behavior and Human Decision Processes, 50(2), 179-211.
  * [34] C. Carver and M. Scheier, (1982), _Control theory: A useful conceptual framework for personality-social, clinical, and health psychology_ , Psychological bulletin. 92. 111-35. 10.1037/0033-2909.92.1.111.
  * [35] I. Rauf, M. Petre, T. Tun, T. Lopez, P. Lunn, D. Van Der Linden, J. Towse, H. Sharp, M. Levine, A. Rashid, and B. Nuseibeh, _The Case for Adaptive Security Interventions_ , ACM Trans. Softw. Eng. Methodol. 31, 1, Article 9 (January 2022), 52 pages. DOI:https://doi.org/10.1145/3471930
  * [36] R. Jones, A. Rastogi, _Secure Coding: Building Security into the Software Development Life Cycle_ , Information Systems Security. 13. 29-39, 2004, doi: 10.1201/1086/44797.13.5.20041101/84907.5.
  * [37] R. Werlinger, K. Hawkey, D. Botta, K. Beznosov, _Security practitioners in context: Their activities and interactions with other stakeholders within organizations_ , International Journal of Human-Computer Studies, 67. 584-606, 2009, doi: 10.1016/j.ijhcs.2009.03.002.
  * [38] A. Mokhberi, K. Beznosov, SoK: Human, _Organizational, and Technological Dimensions of Developers’ Challenges in Engineering Secure Software_ , In European Symposium on Usable Security - EuroUSEC 2021, Association for Computing Machinery, New York, NY, USA, 59–75, 2021, doi: 10.1145/3481357.3481522
  * [39] T. Lopez, H. Sharp, T. Tun, A. Bandara, M. Levine, B. Nuseibeh, _Talking About Security with Professional Developers_ , IEEE/ACM Joint 7th International Workshop on Conducting Empirical Studies in Industry (CESI) and 6th International Workshop on Software Engineering Research and Industrial Practice (SER&IP), 2019, pp. 34-40, doi: 10.1109/CESSER-IP.2019.00014.
  * [40] J. Xie, H.R. Lipford, B. Chu, _Why do programmers make security errors?_ , IEEE Symposium on Visual Languages and Human-Centric Computing (VL/HCC), 161-164, 2011.
  * [41] A. Poller, L. Kocksch, S. Turpe, F. Anand Epp, 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 - CSCW 2017, Association for Computing Machinery, New York, NY, USA, 2489–2503, 2017, doi: 10.1145/2998181.2998191
  * [42] L. Sajwan, J. Noble, C. Anslow, R. Biddle, _Why do Programmers do What they do? A Theory of Influences on Security Practices_ , In Proceedings of the HATS Workshop on Usable Security and Privacy (USEC), 2021.
  * [43] H. Assal, S. Chiasson, _Think secure from the beginning: A Survey with Software Developers_ , Proceedings of the 2019 CHI Conference on Human Factors in Computing Systems, Association for Computing Machinery, New York, NY, USA, Paper 289, 1–13, 2019. doi: 10.1145/3290605.3300519
  * [44] H. Assal, S. Chiasson, _Motivations and Amotivations for Software Security_ , 2018.
  * [45] D. Votipka, K.R Fulton, J. Parker, M. Hou, M.L. Mazurek, M.W. Hicks, _Understanding security mistakes developers make: Qualitative analysis from Build It, Break It, Fix It_ , USENIX Security Symposium, 2020.
  * [46] C. Weir, I. Becker, L. Blair, _A Passion for Security: Intervening to Help Software Developers_ , IEEE/ACM 43rd International Conference on Software Engineering: Software Engineering in Practice (ICSE-SEIP), 2021, pp. 21-30, doi: 10.1109/ICSE-SEIP52600.2021.00011.
  * [47] L. Braz, C. Aeberhard, G. Çalikli, A. Bacchelli, _Less is More: Supporting Developers in Vulnerability Detection during Code Review_ , IEEE/ACM 44th International Conference on Software Engineering (ICSE), 2022, doi: 10.1145/3510003.3511560.
  * [48] F. Fischer, J. Grossklags, _Nudging Software Developers Toward Secure Code_ , in IEEE Security & Privacy, vol. 20, no. 02, pp. 76-79, 2022, doi: 10.1109/MSEC.2022.3142337.
  * [49] E. Larios-Vargas, O. Elazhary, S. Yousefi, D. Lowlind, M. L. W. Vliek, and Margaret-Anne D. Storey. (2022). _DASP: A Framework for Driving the Adoption of Software Security Practices (v1.0)_ , [Appendix]. Zenodo. https://doi.org/10.5281/zenodo.6502947
  * [50] V. Taras, B. L. Kirkman, and P. Steel, (2010), _Examining the impact of Culture’s consequences: a three-decade, multilevel, meta-analytic review of Hofstede’s cultural value dimensions_ , The Journal of applied psychology, 95(3), 405–439. https://doi.org/10.1037/a0018938
  * [51] B. Schneider, M. Ehrhart, and W. Macey, (2012), _Organizational Climate and Culture_ , Annual review of psychology. 64. 10.1146/annurev-psych-113011-143809.