Securing Software Development through People Maturity: A Fuzzy-AHP Decision Making Framework

1. Introduction

The continuing progress of technology systems has raised the importance of software in various aspects of daily life, including socioeconomic activities. As the reliance on such systems increases, the vulnerability of the software that runs these organizations also increases, making secure software development (SSD) an essential goal for organizations worldwide. These are significant risks associated with security vulnerabilities that are the root causes of financial woes, reputational losses, and unwanted penetration of sensitive data [1]. Therefore, It is evident that software systems' protection is paramount in developing and deploying software systems locally and globally [2]. Recent trends in approaching software security issues involve consideration of the human element in the improved security of the application [3]. Organizational maturity of the development team, best known as people maturity, has been cited as an essential factor that influences the effectiveness of SSD practices. Person maturity includes factors like the behavioural aspect, communication, interaction between the team members, expertise, and experience they possess that either facilitates the security of the software projects or not [4].

However, making people mature and developing such a culture, even in a software development environment, is still tricky [5]. Previous methods of identifying and enhancing team thriving tend to eschew an entirely systematic approach that considers the framework concept when analyzing human factors. Within this context, a research gap is identified that focuses on developing a systematic framework that may be used to systematically assess and facilitate improvement in people's maturity concerning the SSD context. This paper's first and foremost purpose is to bring us to the development of the framework as a guide to help organizations follow a structured approach in assessing the maturity levels of the development team and pinpointing the significant issues. By so doing, it wants to establish a culture of having people continuously learn while adopting changes to ensure that security measures are still effective, given the fast changes and growing technology.

HSFs and HSVs are two sides of the same coin in the context of SSD [6]. People success factors denote characteristics and behaviors that contribute positively to the capabilities of the personnel and subgroups for the development of secure software. These are technical capabilities, communication, problem-solving, security sensitivity, and learning orientation [7]. This paper aims to establish that when these factors are effectively addressed, they play a central role in enhancing secure and dependable software systems.

On the other hand, human security risks arise from the weaknesses and flaws that people and groups may demonstrate, thereby creating threats to software security [6, 8]. Such risks include the user's security knowledge, insufficient training, poor communication, and ignoring security policies [9]. Most insecurity issues likely originate from carelessness, a negligent act, or even deliberate provocation. Hence, it is vital to comprehend and minimize them to strengthen the protective measures of software development projects.

Despite the recognized importance of human factors, there is still a dearth of a framework that systematically examines all of these facets and offers systematic incorporation of these characteristics into the security paradigms of software development [8]. The nature of human interactions and the variability inherent in teamwork complicates defining and identifying all relevant success parameters and potential weaknesses in one complete strategic profile [10].

The human success factors and the security threats have central functions in SSD projects [8]}. The most vital of HSFs are team experience, knowledge, communication, and learning [11]. Expertise is defined as the technical know-how of the personnel in a team assigned to trace and prevent threats to security. This forms part of communication within the team and with stakeholders to ensure the security requirements are understood and implemented [12]. It helps team members to be up-to-date with security trends, thus making it easier to counter them quickly.

On the other hand, security threats result from people’s weaknesses like insufficient training, communication breakdown, and strained cooperation [9]. Lack of training exposes the programmer to a lack of information on new security threats and security measures that can lead to the ease of vulnerabilities in the software being developed [13]. Lack of communication may lead to non-coordination; thus, misinterpretation of the security necessities and inefficient implementation can appear, and inadequate collaboration may cause disintegrated work in securing the software [14]. Also, coding errors and incorrect system configurations contribute to security threats [15]. Mitigating such risks can only be possible by embracing a systems approach in the development of people through acquiring appropriate skills, coordination of efforts in implementing security measures, and effective continuous learning processes to boost the security outcome of software development projects [16].

This paper intends to fill this gap by proposing a comprehensive SSD model that integrates human success factors and security threats. In this way, using methods that consider the complexity of human factors, such as the fuzzy analytical hierarchy process (Fuzzy-AHP), we will carry out a detailed analysis of the human components of software security to identify ways for improvement. Fuzzy-AHP integrates the multilevel decision-making ability of AHP into the concept of fuzzy, which offers versatility in presenting human factors frequently in vague conditions.

The following sections present precise information on the theoretical background of the proposed framework and explain how it can be used to analyze and improve human factors within the context of software development projects. In this paper, we will demonstrate the implementation and effectiveness of our approach through the literature review supported by empirical data. In addition, we will describe the potential impact of the presented work on the research and practice of software security, and we will stress the importance of equal attention to technical and human factors for attaining holistic software protection.

By doing so, we shall provide pragmatic insights into the call for human factors in SSD and present proposals drawn from the literature for organizations seeking to strengthen their security posture.

The following research questions will help us get closer to our goal:

RQ1: What are the human factors (success factors and security vulnerabilities), as reported in the literature and real-world industry, that influence secure software development projects?

RQ2: Are there any differences between the success factors and security vulnerabilities identified in the literature and real-world industry?

RQ3: What are the best practices, as reported in the literature and real-world industry, that address the human factors (security vulnerabilities) in secure software development projects?

RQ4: How can a decision-making framework be developed to identify the weights of human success factors and security vulnerability practices and evaluate the effectiveness of secure software development projects?

The paper unfolds as follows: Section 2 delves into the motivation and background of the study. A detailed examination of the study's methodology is presented in Section 3. Section 4 conducts an in-depth analysis and evaluation of the acquired results—and section 5 offers securing software development through a people maturity decision-making framework for SSD organizations. Section 6 addresses the study's implications, Section 7 summarizes the study and its limitations, and Section 9 concludes by highlighting avenues for further research.

2. Background and Related Work

This section describes the motivations behind this study, defines software security, and discusses HSFs and HSVs in SSD-related work.

2.1. Motivations Behind the Study

The motivation behind this work is multi-layered, resting on the growing intricacy of software systems and the rising risks that modern enterprises contend with. First, hacking attacks and data leakage are critical issues in software applications and result from poor software development practices [17]. While the traditional security practices and mechanisms are still pertinent, they are insufficient if used individually [18]. It has emerged that project aspects, such as the human facets of development teams and especially their skills, collaborations, and maturity levels, have a significant bearing on the security levels of software systems [19].

Secondly, the current approaches and methods to increase software security mainly use technical disciplines while not considering people’s maturity enough [15]. They concluded that there are no well-defined paradigms of human factors’ consideration in the decision-making related to SSD [18]. This gap in the current state of knowledge influenced the investigation of a holistic framework to examine and advance the maturity of development teams and, consequently, improve overall security.

Thirdly, the dynamic condition of technology and cyber threats requires decision-making criteria that can be effective in uncertain and changing situations [20]. The Fuzzy Analytical Hierarchy Process (fuzzy-AHP) provides a reliable solution by clearly categorizing AHP and the elasticity of fuzzy logic [19]. Thus, this hybrid approach enables them to consider other factors of workers’ maturity besides the objective since people and technology aspects require such flexibility in their assessment.

Besides, this research appears to be an attempt triggered by the real-world need to encourage organizations to embrace efficient security strategies. In turn, with the assistance of the created framework that enables considering and improving the maturity of development teams systematically, this work will contribute to creating more secure and reliable software systems. The long-term goal is to create a more sustainable approach to software security and encourage the spirit of aspiring to be bigger and better across development teams, decreasing threats to an application’s security and improving the software systems’ solidness.

In sum, the engineering motivations for undertaking this work are driven by the increasing awareness of the human aspects of software security, the lack of fit of existing paradigms to realize it, and the empirical reality of an organization’s struggle to achieve secure software development. Following the proposed Fuzzy-AHP decision-making framework, this research will contribute a valuable framework to improve individuals’ maturity and, in turn, increase the security of software development projects.

2.2. Software Security

Software security aims to build programs that can continue to run even when faced with hostile attacks [21]. The best way to reduce software vulnerabilities and problems is to incorporate security and non-functional requirements throughout the Software Development Life Cycle (SDLC) [3]. "Secure software" is an application that follows secure development standards and practices during its design or engineering process [19]. That way, even if the program is attacked, its operations and functions will keep running smoothly. One of the main goals of secure software is to prevent unauthorized individuals from viewing or changing data [22]. Preventing development and maintenance costs requires strict adherence to security standards throughout the design and implementation processes [23].

2.3. People's Maturity towards Secure Software Development

Analyzing the concept of people maturity in the context of secure software development (SSD), it is possible to identify the competency level and the degree of preparedness and activity of individuals and teams regarding security measures within SDLC. Thus, failure to realize high people maturity hinders the development of dependable software systems for responding to emerging threats and risks. Following are the dimensions of people's maturity towards SSD [24-31]:

2.2.1. Dimensions of People Maturity

i.

Technical Proficiency and Skill Development: The identification and confirmation that the members of the team have the required competencies is perhaps the most essential element of people's maturity. Enlisting a professional training and education program on the best practices, instruments, and techniques of contemporary securities is also crucial.

ii.

Experience: The professional members of the team need to be able to use their expertise and analyze the probable problem related to security and then implement the principles learned most appropriately.

iii.

Process Adherence and Standardization: Excellent teams operate with standard methodologies and guidelines that contain security since the beginning of the development stage, for instance, SSDLC models.

iv.

Compliance: Thus, following the best practices of the industry and the legally compliant acts guarantees that the security will be the best and most updated.

v.

Communication and Collaboration and Interdisciplinary Coordination: Communication is essential because it helps the developers, security specialists, and other related stakeholders to ensure that the security requirements are understood and reflected in the development process.

vi.

Feedback Mechanisms: The development of sound feedback mechanisms enables the development team to quickly note or report on security issues as the project progresses.

vii.

Proactive Security Culture and Security Awareness: It is compelling to make security a part of a team culture where everyone understands the organization’s threats and actively seeks to prevent them.

viii.

Responsibility and Accountability: This gives them ownership of security tasks; in the process, individuals feel responsible for the overall security tasks.

ix.

Problem-Solving and Analytical Skills: Most well-established teams employ very formal and rational strategies like threat modeling and risk analysis to analyze the weaknesses in security systems.

x.

Decision Frameworks: By applying decision-support tools like Fuzzy-AHP, the teams can calculate security measures considering various factors and the fuzziness of the decision-making environment.

2.2.2. Benefits of People Maturity towards Secure Software Development

The following benefits of people's maturity towards SSD are identified through literature [24-31]:

i.

Enhanced Security Posture: Originally, higher people's maturity meant a better ability to understand and eliminate security threats, thus improving security maturity.

ii.

Reduced Risk: Consequently, the secure maturity level of the formative team means the ability to independently assess the threats and threats handling, which leads to a decrease in the number of and the impacts due to security breaches.

iii.

Improved Compliance: Compliance with security standards and meeting regulatory standards increases, meaning the software is legal and complies with industry standards.

iv.

Increased Efficiency: That way, the practices are standardized, and communication is efficient in establishing means of providing security without overloading developers for a long time.

v.

Continuous Improvement: By practicing open acknowledgement that is not confined to learning through experience but goes further to embrace proactivity, the teams remain informed on the current security trends and hence make constant enhancements to security.

2.2.3. Achieving People Maturity towards Secure Software Development

To achieve people maturity in secure software development, organizations should [24-31]:

i.

Invest in Training: Develop and implement continuing formal training sessions and seminars about new means and protection methods.

ii.

Implement Standard Processes: First, implement and apply the set of requirements for security across the entire project, not just the separate ones.

iii.

Foster a Security Culture: Encourage the organization's personnel, teams, and departments to embrace security matters.

iv.

Facilitate Communication: Promoting the free flow of information and patronizing the establishment of rapport between all the participating stakeholders, especially in designing the software.

v.

Utilize Decision-Making Tools: Utilize well-formalized decision-making approaches like Fuzzy-AHP in security-related decision-making.

Thus, people maturity is a significant aspect of securing software processes, covering a development team's competencies, practices, information sharing, and decision-making elements. Overall, by methodologically increasing these dimensions, it is possible to create high performance for developing and maintaining secure software systems and, thus, to guard against the constant growth of potential threats in information security.

2.3. Related Work

The concept of people maturity related to secure software development (SSD) has emerged as the focus of attention in recent years. This section presents a literature review and the current frameworks for dealing with human factors in software security. Based on the literature review of previous studies, this section seeks to establish the differences and similarities of the current study regarding their contributions, shortcomings, and the existing research gaps. This research will focus on the following subsections to cover the related work:

2.3.1. Human Factors in Software Security

Human factors, at times, determine the security of software systems. Many papers have stressed the importance of awareness, training, and skills developers must possess to avoid security threats. For instance, a recent study by Acar et al. (2017) assessed the effects of security training on developers’ performances in developing secure code, and the authors noted that specific training boosts security solutions. It was also implemented by Xie et al., 2011 the study of the developer’s expertise to identify and mitigate security flaws, proving that developed developers can manage security issues.

2.3.2. Secure Software Development Lifecycle

The accommodation of security practices into the Software Development Lifecycle (SDLC) has been popularized for quite some time through several models and frameworks. Another model worth mentioning is the Secure Software Development Lifecycle (SSDLC), which was developed by Microsoft and can be described as the approach that focuses on the idea of security as the integral characteristic of the development process and should be considered and implemented at each stage, starting from the stage of requirements definition and ending with maintenance. This has been found helpful in improving the security of software projects, thus qualifying for improvement. Still, compared with SSDLC, which offers a clear approach, there is not enough emphasis on the human aspect if the security plan is effective.

2.3.3. Maturity Models

Other frameworks and management models, like CMMI and SAMM, are designed to present organizations with checklists to evaluate and advance their processes. These models include aspects that are related to security. Still, many of these models do not inherently address the level of maturity of team members in terms of security. For example, CMMI addresses improving and advancing an organization’s capabilities. At the same time, SAMM offers a framework for implementing security, especially in software development, but does not delve into specific skills and team aspects.

2.3.4. Decision-Making Frameworks

AHP and FAHP have been used to solve many decision-making problems in software project management and risk analysis. Fuzzy AHP has mainly been applied to manage the vagueness and subjectivity of human perception. A literature review done by Wang and Elhag (2006) and Lee et al. (2008) illustrated that Fuzzy AHP is effective in ranking the criteria that cannot be clearly defined with regularity, and the decision-making is made with multitudinous factors under conditions of uncertainty. However, the exact application to measure people's maturity, specifically in secure software development, is still a question mark.

2.3.5. Roles of Human Factors and Security in Integration

Recent studies focus on the interaction of the human element with typical security frameworks. For instance, Assal and Chiasson (2019) developed a framework to examine the effects of various factors attributable to developers in security practices, suggesting that adequate training and awareness should be conducted frequently. Moreover, works such as Green et al. (2016) have also pointed out the need to improve communication and cooperation among the development teams to improve the available security.

2.3.6. Gaps and Opportunities

While the literature on human factors for software development demonstrates an appreciation of people in secure software development, there is a lack of consistent approaches that systematically evaluate and improve people's maturity. Few previous models and frameworks are either technical-oriented or too general and lack a clear structure for measuring the maturity of individuals and teams. Furthermore, there is a lack of research on applying decision-making frameworks such as Fuzzy AHP specifically to health organizations in this context.

2.3.7. Conclusion

Summarizing, it is essential to move a step forward, stressing that even though considerable progress is being made in the acknowledgment of human factors regarding software security, it is crucial to develop a systematic approach to carry out the measurement and improvement of people's maturity within the frame of secure software development. This research will fill this gap using the Fuzzy AHP decision-making approach, which incorporates human factors into the security appraisal. It will offer a single solution for organizations to strengthen security by addressing people's maturity.

3. Research Methodology

To know the impact of identified human success factors (HSFs) and human security vulnerabilities for secure software development (SSD) projects, a three-phase methodology (depicted in Figure 1) was employed. First, a Systematic Literature Review (SLR) identified HSFs and HSVs and recommended practices for SSD projects. Subsequently, an empirical study involving SSD experts was carried out in the second step to assess whether the HSFs, HSVs, and practices identified in the SLR influence the security processes of SSD projects. Finally, the identified HSFs and HSVs practices were ranked using fuzzy-AHP, considering the significance of these practices in the context of the SSD domain.

The outlined phases are further detailed and discussed in the following subsections:

3.1. Phase 1: Systematic Literature Review (SLR)

A systematic literature review (SLR) was conducted initially, and it was used to investigate the realm of HSFs and HSVs and the practices that impact SSD projects. SLRs involve a meticulous and unbiased examination of primary studies, iteratively defining, interpreting, and discussing evidence relevant to research inquiries [32-35]. The guidelines outlined by Kitchenham and Charters [33] were meticulously followed to complete this SLR. SLRs are known to yield more comprehensive and reliable results, as asserted by Kitchenham [36].

SLR’s objective is to provide a systematic and comprehensive research study of the literature to evaluate people's maturity contribution to SSD and ensure that potential research gaps are uncovered and addressed effectively while developing the fuzzy-AHP decision-making framework. According to Kitchenham and Charters [33], the following steps are involved in SLR conduction:

3.1.1. Step 1: Research Questions Identification

The first step in designing an SLR involves developing specific and directed questions that the study hopes to answer. In this step, the research questions are clearly stated. It identifies human factors that play crucial roles in the security of software development projects—how people's maturity is measured in the context of SSD.

The following research questions help us get closer to our goals:

RQ1: What are the human factors (success factors and security vulnerabilities), as reported in the literature and real-world industry, that influence secure software development projects?

RQ2: Are there any differences between the success factors and security vulnerabilities identified in the literature and real-world industry?

RQ3: What are the best practices, as reported in the literature and real-world industry, that address the human factors (security vulnerabilities) in secure software development projects?

RQ4: How can a decision-making framework be developed to identify the weights of human success factors and security vulnerability practices and evaluate the effectiveness of secure software development projects?

3.1.2. Step 2: Reviewing or Drafting Review Protocol

Similarly, we create a Review Protocol. A review protocol is, therefore, a plan prepared before carrying out the SLR to determine the most appropriate approach.

• Search Strategy: Specified keywords, databases, and search engines will be used.
• Inclusion and Exclusion Criteria: Selection of literature.
• Data Extraction: The type of data that can be mined from each study.
• Quality Assessment: The quality of the studies included in the review is also considered.

3.1.3. Step 3: Search String Designing and Implementing

The next step we followed was designing and implementing an effective literature search. Here, the following defined search strategy is applied, and a broad search is performed on several databases and search engines. Some possible keywords could be phrases like ‘people maturity software security,’ ‘secure software development,’ ‘human factor,’ ‘Fuzzy AHP’, and ‘decision-making frameworks.’

3.1.4. Step 4: Screening and Selecting Studies

Screening and selecting studies is one of the most critical steps in carrying out a systematic literature review and can take up to two-thirds of the time required to conduct a review. The first step we conducted in the screening process was identifying those studies that might be relevant according to the article's title and abstract. The shortlisted studies are then reviewed in full text to ensure they fit the inclusion/exclusion criteria. Research that examined human aspects that play a role in secure software development. Studies discussing people's maturity from the perspective of software security. Research articles discussing frameworks/ models for evaluating and enhancing people's maturity. Scholarly journals, research conferences, and technical reports which have passed through peer review. This includes all research that did not focus on software development or security. Some of the articles are not indexed for full-text access. Traditional magazines generally do not contain peer-reviewed articles, op-eds,s or editorials. Figure 2 presents the primary and final selection of papers from different digital libraries.

3.1.5. Step 5: Data Extraction

The information relevant to the review question is collected from the chosen articles using a non-structured questionnaire. The extracted data typically includes:

• Study Title
• Authors
• Publication Year
• Research Objectives
• Methodology
• Key Findings
• Limitations
• Recommendations for Future Research

3.1.6. Step 6: Quality Assessment

Quality appraisal of each selected study is done using specific quality criteria. Common quality assessment criteria include:

• Clarity of research objectives
• Rigor of the methodology
• Internal and external validity of the research
• Contribution to the field
• Honesty regarding certain constraints and perspectives

3.1.7. Step 7: Data Synthesis

In addition, patterns, themes, and relations between the studies are established from the extracted data. This refers to the number of themes identified and the style of making the synthesis where one provides narrative synthesis. Concerning the research questions, the findings are posed systematically.

3.1.8. Step 8: The Findings

The results of the SLR are compiled into a detailed report structured in Section 4 of this study.

Thus, by following these simple and structured steps, the literature review will help gain a thorough appreciation of people's maturity and significance in secure software development, help identify the missing links, and help develop a perfect and comprehensive Fuzzy-AHP decision-making system.

3.2. Phase 2: Empirical Study

We performed an empirical study using an online survey to gather insights from SSD experts and practitioners. The focus was on their experiences handling HSFs and HSVs and their practice's impact on SSD projects.

Employing an online survey in this study offered several advantages [37]:

• This method eliminated the necessity for scheduling meetings or global travel, allowing for efficient data collection from experts across continents.
• Utilizing online resources that are both cost-effective and accessible, such as Google Online Form, made the implementation process more practical.

The survey had design and sampling phases. During the design phase, several systematic and unsystematic sampling methods were considered when formulating sample questions [38]. We chose an online survey, a non-scientific data collection method often used for information gathering by other researchers [39-41] because it was more practical than directly collecting data from experts in different countries.

3.2.1. Development of Questionnaire Survey

HSFs and HSVs were evaluated in the closed-ended section using a five-point Likert scale, ranging from 'strongly agree' to 'strongly disagree.

3.2.2. The Pilot of Questionnaire Survey

To evaluate the questionnaire survey, a pilot study involved experts from software development organizations, namely, the "Cyber-Physical Systems Research Group, University of Southampton, UK", "College of Computer and Information Sciences, King Saud University, Saudi Arabia", "Software Engineering Research Group (SERG_UOM) Pakistan”. Subsequently, expert feedback was incorporated, leading to revisions in the questionnaire survey.

3.1.3. Data Collection Sources

Utilizing snowball sampling, expert data was gathered [42]. Email and numerous social media sites, such as ResearchGate, Facebook, LinkedIn, and Gmail, were used to make contact. Out of 90 responses received from SSD survey participants, 20 were excluded as their expertise didn’t align with secure software development. Subsequently, the final dataset of 70 survey responses underwent manual evaluation and was used for subsequent statistical analysis. Respondents predominantly held Master's degrees, while those with PhDs were less represented. Most participants hailed from prominent SSD enterprises, with many holding decision-making roles.

Figure 3 presents the demographic details of the 70 survey participants for identifying human success factors (HSFs) and human security vulnerabilities (HSVs) that impact secure software development (SSD) projects.

3.3. Phase-3: Fuzzy Analytical Hierarchy Process (FAHP)

The list of HSF and HSV practices was ranked based on the findings of the fuzzy analytical hierarchy process (Fuzzy-AHP).

3.3.1. Fuzzy Set

This section provides an in-depth discussion of fuzzy set theory and fundamental AHP concepts. Initially introduced by Zadeh [43], fuzzy set theory was devised to address uncertainties and vagueness inherent in real-world problems. Its main benefit is representing imprecise data [44]. Within a fuzzy set, membership functions map objects onto a scale between '0' and '1'.

$${\mu }_F\left(x\right)=\left\{\begin{array}{c}\frac{x-f^l}{f^m-f^l},f^l\le x\le f^m\\ \frac{f^u-x}{f^u-f^m},f^m\le x\le f^u\\ 0,otherwise\end{array}\right.$$

(1)

when the exact values for the lowest, most significant, and highest ranges are denoted by (fl, fm, fu). Triangular fuzzy numbers (TFNs) for T1 and T2 are mathematically represented in Table 1.

3.3.2. FAHP

The Analytical Hierarchy Process (AHP) is used to solve "multi-criteria decision-making" (MCDM) problems. The limitations of conventional AHP methods, such as a "crisp environment," an absence of uncertainty consideration, unbalanced judgmental scales, and subjective judgment selection, have been greatly helped by AHP and fuzzy set theory. Thus, in MCDM scenarios involving uncertainties and fuzziness, the Fuzzy Analytical Hierarchy Process (FAHP) has become increasingly popular [45]. Using the Triangular Fuzzy Numbers (TFNs) scale, FAHP allows linguistic terms to be incorporated to collect input from several decision-makers. This provides the opportunity to quantify the linguistic variables. Similar techniques have been utilized to gauge vagueness in fuzzy environments across various engineering disciplines [46]. This study adopts Chang's FAHP [47], recognized for its consistency and appropriateness in such analyses.

Imagine a situation where you must prioritize HSF and HSV practices toward SSD projects. There are two sets, X = {x1', x2', … xn} and U = {u1', u2', … un}, where X is the set of objects and U is the set of goals. Chang [47] asserts that each object undergoes measurement while every goal (gi) is pursued. By employing equations (11) and (12), the extent of analysis values (m) for each object can be determined.

$${\widetilde{F^1}}_{gi}+{\widetilde{F^2}}_{gi},\dots {\widetilde{F^m}}_{gi}$$

(2)

$$i=1,2,...,\mathrm{n}$$

(3)

where the TRNs indicate ${\widetilde{F^j}}_{gi}$ (where j=1, 2, …, m). The following procedures are carried out to apply Chang's extent analysis methodology:

Step 1: The first step is to create a comparison matrix that considers fuzzy values.

Step 2: Figure out the fuzzy synthetic extent as it relates to the options

$$Si={\sum }_{j=1}^m{\widetilde{F^j}}_{gi}\otimes {\left[{\sum }_{i=1}^n{\sum }_{j=1}^m{\widetilde{F^j}}_{gi}\right]}^{-1}$$

(4)

To achieve the expression${\sum }_{j=1}^m{\widetilde{F^j}}_{gi}$, “execute the fuzzy addition operation of m extent analysis such as:”

$${\sum }_{j=1}^m{\widetilde{F^j}}_{gi}=\left({\sum }_{j=1}^m{\widetilde{f^l}}_{gi},{\sum }_{j=1}^m{\widetilde{f^m}}_{gi},{\sum }_{j=1}^m{\widetilde{f^u}}_{gi}\right)$$

(5)

and to achieve the expression ${\left[{\sum }_{i=1}^n{\sum }_{j=1}^m{\widetilde{F^j}}_{gi}\right]}^{-1}$, “the fuzzy addition operation is executed on” ${\widetilde{F^j}}_{gi}$(j = 1, 2, .....m) value, as follow:

$${\sum }_{i=1}^n{\sum }_{j=1}^m{\widetilde{F^j}}_{gi}=\left({\sum }_{i=1}^n{\widetilde{f^l}}_i,{\sum }_{i=1}^n{\widetilde{f^m}}_i,{\sum }_{i=1}^n{\widetilde{f^u}}_i\right)$$

(6)

Finally, calculate the vector's inverse using Eq. (7):

$${\left[{\sum }_{i=1}^n{\sum }_{j=1}^m{\widetilde{F^j}}_{gi}\right]}^{-1}=\left(\frac{1}{{\sum }_{i=1}^n{\widetilde{f^u}}_i},\frac{1}{{\sum }_{i=1}^n{\widetilde{f^m}}_i},\frac{1}{{\sum }_{i=1}^n{\widetilde{f^l}}_i}\right)$$

(7)

Step 2: “As $F_a$ and $F_b$ are two triangular fuzzy numbers, then the degree of possibility of” $F_a$= ($f_a^l$, $f_a^m$, $f_a^u$) ≥ $F_b$= ($f_b^l$, $f_b^m$, $f_b^u$) is defined as follows. The Equation (8) is also given below:

$$\mathrm{V}(F_a\ge F_b)=\sup \left[\min ({\mu }_{Fa}\left(x\right),{\mu }_{Fb}\left(x\right))\right]$$

(8)

$$\mathrm{V}(F_a\ge F_b)=\mathrm{hgt}\left(F_a\cap F_b\right)={\mu }_{Fa}\left(d\right)=\left\{\begin{array}{c}1,if{f}_a^m\ge f_b^m\\ \frac{f_a^u-f_b^l}{\left(f_a^u-f_b^m\right)+(f_b^m-f_b^l)},f_b^l\le f_a^u\\ 0,otherwise\end{array}\right.$$

(9)

Here, the ordinate of the highest point where d, μ_Fa, and μ_Fb intersect is represented by the value of d (Figure 5).To find out what P1 and P2 are worth, you need to know the values of V1(F_a≥ F_b) and V2(F_a≥ F_b).

Step 3: The following is one way to express the process of finding the full "degree of possibility of a convex fuzzy number and other convex fuzzy numbers Fi (i=1, 2,…, k)":

V(F≥F1​,F2​,F3​,…Fk​)=minV(F≥Fi​)

(10)

Assuming:

d/Fi​=minV(Fi​≥Fk​)

(11)

for k=1,2,…,n; k≠i.

It is through the utilization of Equation 21 that the weight vector is established.

W^/ = (d^/(F₁), d^/(F₂), d^/(F₃) … , d^/(F_n))

(12)

in which Fi are definite variables where i=1,2,...,n.

Step 4: The weight vector obtained from Equation (14) and Equation (13) standardizes it. This normalized non-fuzzy value indicates priority weight for HSF and HSV practices.

W = (d(F₁) , d(F₂) , d(F₃) … , d(F_n))

(13)

with W standing for the weight of a security risk's priority.

Step 5: Fifthly, ensure that the matrices used to compare options in fuzzy AHP are consistent [48]. The Consistency Ratio (CR) calculation for each matrix is an essential component. Fuzzy matrices can be created using the graded-mean method. The triangular fuzzy matrix P = (l, m, u) is transformed using Equation 14:

$${\mathrm{P}}_{\mathrm{crisp}}=\frac{(4m+l+u)}{6}$$

(14)

The final consistency ratio is calculated using equations (15) and (16):

$$\mathrm{CI}=\frac{({\lambda }_{max}-n)}{n-1}$$

(15)

$$\mathrm{CR}=\frac{CI}{RI}$$

(16)

Where ${\lambda }_{max}$represents "the largest eigenvalue of the comparison matrix", n is "the number of items being compared in the matrix," and RI is "the random index. Its value can be referenced from Table 2." CI is "the consistency index" computed using equation (16). The matrix maintains consistency if CR is below 0.1; otherwise, decision-makers should resort to pair-wise judgments.

4. Results and Data Analysis

In this section, we describe the detailed analysis of the data acquired through the empirical survey, and FAHP used to answer the research questions (RQs) posed in Section 1:

4.1. RQ1: What are the Human Factors (Success Factors and Security Vulnerabilities), as Reported in the Literature and Real-World Industry, that Influence Secure Software Development Projects?

Several human factors significantly influence success in secure software development (SSD) projects. These factors encompass various aspects of team dynamics, knowledge, communication, and organizational culture. Similarly, in SSD projects, various human factors can introduce security vulnerabilities that compromise the software's integrity, confidentiality, and availability. Understanding these factors is crucial to mitigating risks and ensures the SSD process.

Table 3 presents the key human factors (success factors and security vulnerabilities) that impact SSD projects:

By focusing on these human success factors (HSFs) and human security vulnerabilities (HSVs), organizations can significantly enhance the success of their SSD projects, resulting in more resilient and trustworthy software solutions.

4.2. RQ2: What are the Similarities and Differences between HSFs and HSVFs, as Identified through Literature and Real-World Industries, that Influence SSD Projects?

To analyze the similarities and differences between human success factors (HSFs) and human security vulnerabilities factors (HSVFs) as identified through literature and real-world industries that influence secure software development (SSD), we considered how these factors and vulnerabilities are perceived and addressed in both contexts (as presented in Table 4 and 5).

Table 5 summarizes the similarities and differences between human security vulnerabilities (HSVs) identified through literature and those observed in real-world industries, clearly comparing common themes and unique challenges faced in both contexts.

Table 6 provides a comparative analysis of the impact percentage of human success factors (HSFs) and human security vulnerabilities (HSVs) identified through literature review and empirical study.

Key Observation aboutTable 6:

• Top Success Factors: HSF1 (Skill and Expertise) and HSF2 (Awareness and Mindset) are rated highest in the literature review and empirical survey, indicating their critical importance in SSD projects.
• Consistency: Most factors show high consistency between literature and survey impacts, reflecting a general effect on their importance.
• Lower Impact Factors: HSF11 (Scalability and Flexibility) and HSF12 (Ethical and Cultural Sensitivity) are rated lower, suggesting these are less emphasized in practical settings than technical and managerial skills.
• Top Security Vulnerabilities: HSV1 (Lack of Security Awareness and Training) and HSV2 (Poor Communication and Collaboration) are consistently rated highest, highlighting their significant impact on security.
• Variability: There is more variability in the impact percentages of vulnerabilities than success factors, suggesting differences in perceptions of vulnerability impacts.
• Lower Impact Vulnerabilities: HSV10 (Cultural Issues), HSV11 (Insufficient Incident Response Preparedness), and HSV12 (Over-Reliance on Tools) are rated lower, indicating these are perceived as less critical compared to others.

Figure 6 depicts that both the literature review and empirical survey data agree that skills and expertise (HSF1), awareness and mindset (HSF2), and communication and collaboration (HSF3) are critical success factors with very high impact percentages. This indicates a strong consensus on the importance of continuous education and awareness programs to secure the software development processes. Similarly, effective communication and collaboration are crucial for identifying and addressing security issues. Ethical and cultural sensitivity (HSF11), scalability, and flexibility (HSF12) are rated less impactful than other factors.

Figure 7 shows a high level of agreement between literature reviews and empirical surveys on the impact of various human security vulnerabilities. The percentages are consistently close across most categories. The most critical vulnerabilities identified are lack of awareness and training (HSV1); poor communication and collaboration (HSV2), and inadequate testing and reviews (HSV3). Cultural issues (HSV10) and over-reliance on tools (HSV12) are related as less impactful compared to other factors

4.3. RQ3: What are the Practices For Addressing HSFs and HSVFs, as Identified through Literature Review and Real-World Industries, that Influence SSD Projects?

Addressing human success factors (HSFs) in secure software development (SSD) projects requires a comprehensive approach that balances technical excellence with well-being, collaboration, and continuous improvement of the development team. Table 7 presents some best practices identified through literature review and empirical study.

By implementing Table 7 practices, SSD projects can effectively address HSFs, leading to improved security outcomes, enhanced team performance, and higher stakeholder satisfaction.

Addressing human security vulnerabilities (HSVs) in SSD projects involves training, process improvements, technology, and a strong security culture. Table 8 presents some practices identified through literature review and real-world industries.

By implementing Table 8 practices, SSD projects can effectively address HSVs, leading to more resilient and improved security outcomes.

4.4. RQ4: How Can a Decision-Making Framework Be Developed to Identify the Weights of Maintenance and Deployment Security Risks in Healthcare System Software Development?

In this paper, we employed the coding system of Strauss' [49] ground theory (GT) technique to identify, classify, and organize the identified practices for HSFs and HSVs that impact SSD projects. Although we have already collected the data through a literature review, we used the four main phases of the GT coding scheme to map the practices into four major categories (i.e., "code," "categories", "sub-categories," and theory/theoretical model"). All the authors of this study are on the mapping team. First, we allocated a unique code/label to each practice we studied. The second phase involved categorizing the examined practices into nine broad phases/groups, “C1: Security Training and Awareness”, “C2: Collaborative Security Culture and Leadership”, “C3: Effective Communication and Collaboration”, “C4: Skill Development and Stakeholder Engagement”, “C5: Agile and DevSecOps Practices”, “C6: User-Centric Security, Clear Roles and Responsibilities”, “C7: Supply Chain Security and Risk Management”, “C8: Continuous Improvement, Monitoring and Testing”, and “C9: Data Protection and Privacy, Access Control and Least Privilege”. In the third step, the sub-practices were mapped into these categories. In the fourth step, we engineered a theoretical model depicted in Figure 8.

The primary goal of this categorization is to construct a hierarchical framework for executing the FAHP. Furthermore, this categorization will help academic researchers and practitioners to identify the most essential practice for HSFs and HSVs in the context of SSD. We identified 38 practices mapped in each category, as stated in Table 9.

This section presents an analysis of the results obtained from the fuzzy AHP. The FAHP steps were meticulously executed to ascertain HSF and HSV practice weights for SSD projects within and across categories. Subsequent subsections detail the complete sequence of FAHP steps undertaken, along with their corresponding implications:

4.4.1. Step-1: Sorting out a problem's components (HSFs and HSVs practices) using a hierarchical framework

Motivated by existing literature [45, 50-52], we constructed a hierarchical structure to address progressively complex decision-making problems. This hierarchy consisted of three levels, as depicted in Figure 8.

At Level 1, the primary issue (prioritization of HSFs and HSVs for SSD projects) was outlined. Level 2 encompassed the categories of practices, while Level 3 detailed their respective practices, as illustrated in Figure 8.

4.4.2. Step-2: Comparing Matrix Pairs

In Step 2, within the FAHP analysis, our objective was to rank the identified HSF and HSV practices based on their significance within SSD projects. This required a pair-wise matrix comparison and expert input to prioritize practices and categories. We expanded upon our first survey with a Fuzzy-AHP version, but only 25 of 70 people who were invited to take part were willing to do so. Rigorous checks were applied to ensure consistency and completeness of the 20 complete responses obtained from healthcare security experts for the pair-wise matrix comparison. While the sample size 20 might seem limited, it aligns with comparable studies [45, 50-53] and allows for reasonable generalization. The geometric mean formula below-converted expert survey responses to Triangular Fuzzy Numbers (TFN):

$$\mathrm{Geometric}\mathrm{mean}=\sqrt[n]{a1\times a2\times a3\dots \dots an}$$

a = weight of each response

n = number of responses

Table 10 shows the fuzzy triangle values used to apply the linguistic variable. As described in [54], the triangular matrix method was used to formulate pair-wise comparison matrices. Table 11 displays the paired matrix comparison of HSF and HSV practice categories for SSD projects.

4.4.3. Step 3: Consistency Evaluation

The practices Categories matrix (refer to Table 12) was employed to assess consistency. This table illustrates the Fuzzy Crisp Matrix (FCM) derived from de-fuzzifying practices. It divides categories into crisp numbers through pair-wise matrix comparisons using equation (14).

4.4.4. Step 4: Identification of Local Priority Weight of HSFs and HSVs Practices Categories

a. A Numerical Example

To find the weight vector's normalized values, we used Equation (15). Table 13 and Table 14 show the priority weights assigned to each HSF and HSV practice category in the development of the SSD project, and these values are normalized and non-fuzzy.

λ_max= (11 × 0.09227) + (9.72 × 0.11300) + (7.61 × 0.11726) + (8.5 × 0.12435) + (11.11 × 0.09387) + (9.2 × 0.10896) + (9.72 × 0.10325) + (9.33 × 0.11922) + (9.32 × 0.11216)

= 1.01431 + 1.09836 + 0.89234 + 1.05697 + 1.04289 + 1.00243 + 1.00359 + 1.11232 + 1.04533

= 9.26854

In Table 2, the random index (RI) is determined as 1.45, considering the presence of 9 elements. Equations (15) and (16) were used to calculate the consistency index (CI) and, by extension, the consistency ratio (CR):

$$\mathrm{CI}=\frac{(9.26854-9)}{9-1}$$

$$\mathrm{CI}=\frac{0.26854}{8}$$

CI = 0.03356

$$\mathrm{CR}=\frac{CI}{RI}$$

$$\mathrm{CR}=\frac{0.03356}{1.45}$$

CR = 0.02314

CR value of 0.02314, which is <0.10

This CR value of 0.02314, being <0.10, indicates the consistency of the pair-wise matrix representing HSF and HSV practice categories.

Table 15, Table 16, Table 17, Table 18, Table 19, Table 20, Table 21, Table 22, Table 23 and Table 24 show the results of applying these same procedures to assign weights to each HSF and HSV practice category, its practices, and the fuzzified pair-wise matrix comparison.

4.4.5. Step 5: How to calculate the local and global weights and ranks of HSF and HSV practices

The significance of various categories and HSF and HSV practices in SSD projects was assessed through a weighted analysis. Table 24 displays the rankings of these categories and their practices, calculated using local and global weights. Local weights were assigned to rank each category alongside its associated risk, indicating the relative importance of practice within its category based on its position in the local ranking. Global weights were then computed for each practice to establish their global ranking. These global weights were derived by multiplying the local weight of a practice by the respective category weights. For instance, the category “C4: Skill Development and Stakeholder Engagement” is ranked highest at rank-1 and possesses the greatest weight of 0.12435, as detailed in Table 24, among the identified HSFs and HSVs practices for SSD projects. Similarly, Table 24 shows the highest global weight, which is 0.051506, and the global ranked (rank-1) HSF and HSV practice is “P15: Hands-On Practice and Stakeholder Communication”.

5. Securing Software Development through People Maturity: A Fuzzy-AHP Decision-Making Framework

To illustrate the impact of each human success factor (HSF) and human security vulnerability (HSV) practice for secure software development (SSD), we have constructed a prioritization-oriented taxonomy depicted in Figure 8. This taxonomy outlines the relative priority of each practice within its category. It compares them across all categories in securing software development through people maturity. Visualizing both local and global impacts of each practice aids practitioners in discerning the most significant practice relevant to their roles and responsibilities. The insights in Figure 8 are intended to guide the software development team maturing in refining and formulating new strategies to execute SSD projects. This prioritization-oriented taxonomy serves as a focal point, enabling the team to concentrate on critical areas essential for the success of the SSD projects within the software engineering landscape.

In Figure 8, the category “C4: Skill Development and Stakeholder Engagement” is ranked highest at rank-1 and possesses the most significant weight of 0.12435, as detailed in Table 19, among the identified HSFs and HSVs practices for SSD projects. ‘Skill Development and Stakeholder Engagement’ remain core prerequisites for SSD because they are the primary determinants of overall security and project success [55]. A Skilled team ensures that the personnel involved have the skills and the necessary and updated knowledge of how to integrate good security standards right from the development process. This learning never stops the organization from checking and eliminating possible risks, using recommended standards, and maintaining relevance with threats. On the other hand, stakeholder engagement specifically refers to embracing every stakeholder during the project implementation, coordinating with the clients, users, or any other interested party. Since people are encouraged to communicate and create synergy, it guarantees that security concerns are clearly defined, valued, and implemented in the process. Stakeholders are involved in offering feedback, contributing to the initiatives regarding the implementation of security policies, and assisting in the direction in which specific objectives of the project should be aligned with those of the organization. Captured jointly, skill enhancement and stakeholder participation ensure that everyone within the software supply chain comprehends security and works towards hardening the output to create adequately secure, dependable, and efficient software solutions.

Similarly, in Figure 8, the highest global weight is 0.051506, and the global ranked (rank-1) HSF and HSV practice is “P15: Hands-On Practice and Stakeholder Communication” [56]. Action and engagement with the projects’ stakeholders can be identified as key components in guaranteeing success and security in software development projects. Gaining experience implies interactivity with the tools, technologies, and methodologies used to develop secure software. A direct interaction of this nature improves their working knowledge and skills, thus making them aware and better placed to avoid security risks. It also helps to develop a culture of minimized stoppages and constant learning, which is especially important in cybersecurity due to its high dynamics.

On the other hand, the stakeholders’ communication entails all the involved parties, such as the developers, project managers, clients, and the project's end-users, to be in Compliance with the project's goals, requirements, and limitations. Thus, communication facilitates a clear description of expectations for security, an assessment of the consequences of failed security, and the evaluation of the need for security and the degree to which essential measures are taken. It also encourages timely feedback, decision-making, and teamwork, allowing for the quick identification of new risks and developing ways of handling them. Thus, effectively strengthening practical orientations in developing software solutions and improving communication with key stakeholders can create more secure, intrinsically reliable, and friendly end-user applications.

The taxonomy also presents the variation in the impact of identified HSF and HSV practices concerning their position in their respective categories and overall people's maturity towards SSD projects. For example, the “C1: Security Training and Awareness” category comprises four practices. According to the local ranking in Figure 8, “P4: User-Friendly Security Features” is ranked as the highest priority practice in C-1, but considering the global ranking, it stands at 21^st. Similarly, P3 and P1 stand at 2^nd and 3^rd in C-1, but both stand at 22^nd and 24^th concerning global ranking. Hence, the SSD team needs to consider both ranking orders (local and global) while developing secure software projects.

6. Implications of the Study

This research holds several implications for both academic professionals and practitioners within the software security domain:

• For Academics: This study consolidates a comprehensive overview of HSFs and HSVs and their practices in SSD projects. Meticulously reviewing academic and published materials contributes to a valuable knowledge base. Researchers can leverage these findings to establish practical SSD projects, enhancing secure software development strategies. This study encourages SSD academia to incorporate the most prevalent HSFs and HSVs and their practices for SSD in their ongoing and future projects.
• For Practitioners: Industry experts gain insights into HSFs and HSVs and their practices in secure software development through an extensive literature review and empirical studies. Identifying 12 HSFs and 12 HSVs and 38 prioritized practices for SSD processes, this study aids professionals in implementing robust security measures. By addressing and mitigating these HSFs and HSVs, practitioners can refine existing techniques and devise novel approaches for the seamless adoption of HSFs and HSVs in SSD practices. The comprehensive overview offered by this study assists practitioners in recognizing critical security HSF and HSV practices pivotal for SSD projects.

The outcomes and recommendations derived from this framework significantly contribute to enhancing security in software development projects. Thus, the mentioned proposed framework is an effective instrument for development of new approaches and enhancing the SSD project quality by the assistance of both industry specialists and academic researchers.

The identified priorities give the HSF and HSV practitioners direction to encourage them to select the most appropriate practice depending on their practice categories and their general influence on the SSD context. This prioritization mechanism is thought to help SSD teams and researchers to deal with some of the most typical HSFs and HSVs experienced by programs and organizations to which SSD belongs.

Altogether, this is a comprehensive investigation of the HSFs and HSVs along with related practices in the context of the SSD system and contributes to the lack of literature in this area. The findings are useful for SDPs planning to implement HSFs and HSVs practices in the organizations that work on secure software development.

7. Summary and limitation of the study

This study aims to discern HSFs and HSVs and its practices for SSD projects and formulate a people maturity decision-making framework for secure software development, enhancing software development initiatives. Initially, 24 HSFs and HSVs were identified along with 38 practices to mitigate them through empirical studies involving 70 SSD experts. Additionally, 20 SSD expert panels were convened to analyze the interrelationship between HSF and HSV practices using the FAHP method. Based on collected data, FAHP prioritized these practices, highlighting the most critical category, “C4: Skill Development and Stakeholder Engagement,” which ranked highest at rank-1 and possessed the most significant weight of 0.12435, as detailed in Table 24. Similarly, the highest global weight, 0.051506, and global ranked (rank-1) HSF and HSV practice are “P15: Hands-On Practice and Stakeholder Communication,” as detailed in Table 24.

This study utilized an empirical questionnaire survey to explore people's maturity towards SSD by identifying HSFs and HSVs and their practices, ensuring content validity by aligning the survey with prior SLR findings. Construct validity was confirmed by survey respondents using various scales to assess attribute relevance. Internal validity leveraged SLR results to structure the questionnaire, while external validity incorporated a diverse group of international security experts who participated voluntarily, ensuring varied industry and project backgrounds. The small sample size in the fuzzy-AHP analysis could potentially limit findings due to the interpretive nature of this method.

8. Conclusion and Future Direction

The study advocates integrating security measures for SSD projects, emphasizing the importance of addressing HSFs and HSVs and their practices. This empirical study fills a void by delving into HSFs and HSVs, their specific practices, and their interrelationships, creating a framework via the FAHP approach. The taxonomy developed offers valuable insights for academic researchers and practitioners, guiding prioritization and fostering innovation in SSD processes. The proposed framework aids SSD organizations in assessing and enhancing people's maturity for secure software development activities.

The future goal is to carry out more extensive empirical tests and real-life applications of the proposed framework. The rationale is to extend the usefulness of the presented approach for various software development settings and project sizes. Furthermore, the plan is to enhance people's decision-making processes by applying the Fuzzy-AHP method and integrating it with state-of-the-art machine learning algorithms. Thus, these accomplishments aim to offer a better and more responsive solution in terms of promoting maturity rationale for software development teams and boosting the overall level of security and quality within projects. Future research will further investigate the effects of the proposed framework on the aspects of teamwork, efficiency, and success of the projects to set its applicability as the norm in the field of secure software development.

This study also envisions designing a software product resilient to HSFs and HSVs and their practices and establishing testing protocols for such factors. A comparative analysis will be conducted, pitting our framework against other security models/frameworks in a hybrid approach.