Security Assurance Model of Software Development for Global Software Development Vendors

The number of security attacks and the impact has grown considerably in the recent several years. As a result, new emerging software development models are required that assist in developing software that is secure by default. This article reviews the most widely used security software models. It proposes a new Security Assurance Model (SAM) for Software Development that is adaptable to all contemporary scenarios, emphasizing global software development (GSD) vendor companies. The SAM of Software Development was developed after studying 11 well-known development models and analyzing results obtained from a systematic literature review (SLR) and questionnaire survey. The SAM of Software Development consists of seven security assurance levels: Governance and Security Threat Analysis, Secure Requirement Analysis, Secure Design, Secure Coding, Secure Testing and Review, Secure Deployment, and Security Improvement. The security assurance levels of SAM of software development consist of 46 critical software security risks (CSSRs) and 388 practices for addressing these risks. The proposed SAM of Software Development was assessed based on a tool created by Motorola, which is used to evaluate the present state of a company’s software processes and find areas for improvement. We conducted 3 case studies on software development companies, using data from real software projects to examine the results of a practical experiment in each company. The results of the case studies indicate that the proposed SAM of Software Development helps measure the security assurance level of an organization. In addition, it can potentially serve as a framework for researchers to develop new software security measures.


I. INTRODUCTION
Security for software has become increasingly important since hacking and other attacks on computer systems have grown in popularity in the last few years. As a result, several researchers have examined security solutions as early as the requirement engineering phase. With the growth of the software business and the Internet, people are paying increasing attention to software system security. Managers and users of software systems may suffer enormous losses if the system's sensitive data is exposed or hacked and rendered inoperable.
To incorporate security into the software engineering paradigm, it should be considered from the start of the SDLC [1,2]. Secure software engineering (SSE) is the process of designing, building, and testing software so that it becomes secure; this includes secure SDLC processes and secure software development (SSD) methods [3][4][5]. Most enterprises typically view security as a post-development procedure [6]. No consideration is given to security before development [7].
Khan [8] stated that as software development becomes more complex, distributed, and concurrent, security issues greatly influence software quality. Insecure software harms an organization's reputation with customers, partners, and investors; it increases costs, as companies are forced to repair unreliable applications; and it delays other development efforts as limited resources are assigned to address current software deficiencies [8]. Most software programs are designed and deployed without attention to protection desires [9,10].
Hidden attacking risks within or outside the organization emerge day by day, resulting in substantial financial loss and confidentiality and credibility losses by putting the availability and integrity of organizational data at risk [11,12]. Numerous methodologies for assessing software quality have been developed, including the following: "CMMI", "Microsoft Software Development Life Cycle (MS-SDL)", "Misuse case modeling", "Abuse case modeling", "Knowledge Acquisition for Automated Specification", "System Security Engineering-Capability Maturity Model (SSE-CMM)", "OWASP", and "Secure Tropos Methodology" [13].
The common phases of SDLC include requirement, design, coding, testing, deployment, and maintenance [14]. The final product will not be secure if security is not considered in all phases of the SDLC. This is only possible if a secure SDLC process is followed; secure SDLC ensures that security-related activities are an integral part of the overall development effort [15][16][17].
The literature [18][19][20][21] shows that the software industry has implemented numerous software security techniques, approaches, and solutions. There are a variety of maturity models available for evaluating software security processes, and many firms use these. However, our systematic mapping study [22,23] revealed several limitations in the existing software security models. None of these is committed explicitly to identifying security risks and their practices in each phase of the SDLC. For global software development (GSD) vendor businesses, none of the existing models encompasses all components and activities of a secure SDLC. GSD vendor companies must be aware of the security threats while producing secure applications and risk mitigation techniques to ensure the SDLC's integrity. To increase their SDLC security, GSD vendors will measure their level of maturity and assurance. It will also make GSD engineers more aware of the issue. This paper aims to develop a secure SDLC and Security Assurance Model (SAM) of Software Development for GSD vendor organizations to specify the requirements for secure software development better. As a result, GSD vendors will assess their level of security assurance and capacity to produce more secure software. To accomplish this, we investigate the following research questions (RQs): RQ1: How can a secure SDLC be developed for GSD vendor companies that are both practical and robust? RQ2: Is the proposed security assurance model capable of assisting GSD organizations in determining their security assurance to produce secure software? This paper is organized as follows: Section II includes an overview of the relevant work and its summary. Section III goes into detail on how the study was conducted. Section IV presents a secure SDLC for GSD vendor businesses. Section V outlines the proposed SAM for software development and the security assurance levels. The validation of the model using case studies is presented in Section VI. Section VII highlights the limitations of the study. Section VIII concludes with a discussion of the findings and directions for future research.

II. LITERATURE REVIEW
A review of software security research and maturity models is presented in this section:

A. SOFTWARE SECURITY
Let's a look at some of the concepts about software security that have been discussed in the literature:  "Software security is the software's ability to resist, tolerate and recover from events that intentionally threaten its dependability [24]".  "Software security is about building secure software: designing software to be secure, making sure that software is secure, and educating software developers, architects, and users about to build secure things [25]".

B. SECURE SOFTWARE DEVELOPMENT PROCESS
There are many different ways to include security into the software development lifecycle (SDLC), and this section explains some of the most prevalent security techniques employed in these methodologies:  McGraw [26,27] recommends seven touchpoint operations (Abuse cases, Security requirements, Architectural risk analysis, code review and repair, Penetration testing, and security operations) for creating secure software, all of which are connected to software development artefacts.  Gupta et al. [28] developed Team Software Process for Secure Software Development (TSP) specifically for software teams to help them create a high-performance team and prepare their work to produce the best results.  Flechas et al. [29] developed AEGIS (Appropriate and Effective Guidance for Information Security). It first evaluated device assets and their relationships, then moved on to risk analysis, defining weaknesses, threats, and risks.  Subedi et al. [30] present a security paradigm that extends security development practices in agile methodology to overcome this problem in web application development.
 Sodiya [31] developed the Secure Software Development Model (SSDM), which provides training to stakeholders in software development with adequate security education.  Al-Matouq et al. [15] designed a framework Secure Software Design Maturity Model (SSDMM), and the results show that SSDMM helps measure the maturity level of software development organizations.

C. SOFTWARE MATURITY MODELS
Different models for assessing the maturity of software products have been created and implemented:  The Software Engineering Institute (SEI) at Carnegie Mellon University developed the Capability Maturity Model Integration (CMMI) [32] process model, which assists companies measure and improving their development processes while also delivering highquality products.  Alshayeb et al. [33] [34], proposed a framework to evaluate the maturity of software products called Technical-CMMI (T-CMMI).  Eckert et al. [35] developed a model to measure the maturity level of Inner Source implementation, which is the process of adopting open-source software development practices for the internal development activities of an organization.  Al-Qutaish and Abran [36] proposed the Software Product Quality Maturity Model (SPQMM), which measures the quality of a software product.  The EuroScope consortium [37] developed a model to assess software product quality called the SCOPE Maturity Model (SMM).  April et al. [38] proposed the Software Maintenance Maturity Model (SMmm), based on the CMMI, to assess and improve the quality of software maintenance activities.  Da Silva and de Barros [39] presented an information security maturity model for software developers based on ISO 27001; it was evaluated by subject experts and utilized to measure the maturity level of several organizations.

D. SECURITY IN SDLC PHASES
This section presents some well-known secure software modeling processes that include security in software development phases:  S. R. Ahmed [40] identified security activities that should be performed to build secure software and has shown how the security activities are related to usual activities in different phases of software development.  Essafi et al. [41] developed the Secure Software Development Process Model (S2D-ProM), a strategyoriented process model that offers guidance and support to developers and software engineers, from beginners to experts, to build secure software.  Niazi et al. [42] conducted a systematic literature review (SLR) to pinpoint the required practices for developing secure software and identifying best requirement practices; a framework for secure requirement engineering named Requirements Engineering Security Maturity Model (RESMM) was developed.  Manico [43], designed the Comprehensive, Lightweight Application Security Process (CLASP), which consists of 24 high-level security activities that can be entirely or partially integrated into software during the SDLC.  The Building Security In Maturity Model (BSIMM) [44] quantifies numerous businesses' security activities and provides a common foundation for comparing their security endeavours. There are 119 activities in the BSIMM 10 software security framework. These activities are divided into twelve practices. Each practice's exercises are divided into three maturity levels.  The Open Web Application Security Project (OWASP) created the Software Assurance Maturity Paradigm (SAMM) [43], which is a non-commercial model and is an open platform that aids software companies in developing and implementing software security policies. It contains resources that can help a business assess its software security practices, develop a balanced software security assurance program, and show improvement programs.

E. SUMMARY
Recent software security research has concentrated on offering technical solutions for security concerns; however, a limited study examines security policies and processes in the SDLC's various phases. Little research has been conducted to increase organizational maturity and assurance in secure software development.
Despite the importance of identifying software security risks and practices for addressing these risks in all the phases of SDLC, there is no maturity, readiness, assurance, or secure model for GSD vendor organizations that has been proposed. Furthermore, multiple methodologies and strategies have been established by various researchers; however, industry developers have not adopted them. Existing industry maturity, readiness, and assurance frameworks do not consider the security procedures and techniques described in the literature. GSD vendor organizations need to be more aware of the security risks during the software development process. They need to read up on the literature and follow industry best practices. This will help that the project goes well and is secure.

III. RESEARCH METHODOLOGY
We used a seven-step methodology to meet the study's goals; we also gathered information from the academic community and the software business, as depicted in Figure  1.

A. SYSTEMATIC MAPPING STUDY (SMS)
The acquired data is more reliable because of this evidencebased methodology. The following sections go over each of these steps in-depth: SMS is a literature study that focuses on selecting and combining all high-quality research related to a specific topic and provides a complete summary of current texts applicable to specific map queries [45]. Additionally, it finds gaps in existing subject areas and forecasts future research trends [46][47][48].
The primary purpose of the first step (conducting SMS) of this study is to know what is the state-of-the-art in secure software engineering (SSE) [22,23]. The final selection was among 116 studies that met the inclusion and exclusion criteria [22,23]. The SMS findings were categorized based on the quality assessment, software security processes/models/frameworks/methods, security stages of the SDLC and the publication venue, and SWOT analysis of the software security approaches [22,23].
This study's findings suggest that this field is still in its infancy. It is necessary to conduct sufficient research, mainly focusing on empirically validated solutions, to identify software security risks and strategies for managing these risks at each stage of the software development lifecycle (SDLC).

B. SYSTEMATIC LITERATURE REVIEW (SLR)
"An SLR is a secondary study in which primary studies are examined impartially and iteratively to define, interpret, and discuss evidence relevant to the research questions" [49]. SLR was used in the second phase of this study to classify the selected articles for identifying security risks and practices [50]. A total of 121 papers were selected via the tollgate technique [51] based on the inclusion, exclusion, and quality rating criteria. Khan et al. [50] identified 145 security risks and 424 best practices that help software development organizations to manage security throughout the SDLC.

C. QUESTIONNAIRE SURVEY
An online questionnaire survey using Google Docs was created to validate the SLR findings and discover other security risks and their practices. The questionnaire methodology is more effective than other observational methods because it allows for a larger population to be targeted for data gathering [52][53][54][55][56][57][58][59][60].
In the 3rd stage of this study, an online survey method is employed for data collection [61]. The following steps were used in the questionnaire survey:

1) DEVELOPMENT OF QUESTIONNAIRE SURVEY
The questionnaire primarily consists of closed-ended questions designed to extract specific information from experts. There are a few open-ended questions in the questionnaire to remove any other software security-related risks and practices that were not identified by the SLR. We employed a five-point Likert scale to obtain survey participants' observations regarding the software security risks and its practices listed in the closed-ended section, i.e., "strongly agree, agree, neutral, disagree, and strongly disagree.

2) PILOT OF QUESTIONNAIRE SURVEY
To conduct the pilot assessment of the questionnaire survey, we chose experts working in the GSD environment (i.e. "Software Engineering Research Group (SERG UOM) Pakistan", "King Fahd University of Petroleum and Minerals, Saudi Arabia", and "Qatar University, Doha, Qatar."). This pilot assessment aims to address significant issues (in terms of statistical variables) and improve the survey questions' understandability. Experts suggest improving the questionnaire's design, such as adding questions to obtain more information about survey participants. The questionnaire survey was revised after taking into account the ideas and recommendations of the experts.
At the beginning of the survey, a statement on the researchers' ethical responsibility was also added to assure the participant's confidentiality. This remark reassured the participants that only the study team would access their information. It was stated that the research team would not share the data with anyone to reveal the identity of any participant or organization.

3) DATA COLLECTION SOURCES
As previously indicated, our target population was large and spread organizations across the globe. We decided to use unusual methods to collect responses from SSD professionals working in GSD. We used the snowball sampling technique to gather data from the experts [52]. Snowballing is a low-cost and straightforward strategy to reach a specific audience [52,56,62]. We used social media networks such as Facebook, LinkedIn, Research Gate, and email to contact the experts. The empirical study's data was collected online from June 01, 2021, to July 04, 2021, and the entire data gathering process took one month and four days. During the survey's implementation, 64 responses were collected.
All of the responses were manually reviewed. We excluded 14 responses because the expertise shared by these 14 persons was unrelated to GSD and SSD. For analysis, the final 50 survey results were taken into account. We ensure survey participants that the obtained data will only be used for research purposes and that their identities will never be disclosed to a third party.
For analysis, the final 50 survey results were taken into account. This study empirically validated 145 software security risks and 424 security practices that assist GSD vendor organizations in managing the security activities in the SDLC phases.

4) DATA ANALYSIS
The frequency analysis method was used to examine survey participant replies in this study. This approach works well for analyzing nominal and ordinal data over many variables or groups of variables [63]. Because the survey responses are nominal, we employed the chi-square ("liner-by-linear connection") technique to discover significant differences across the variables. Various research with similar data types has used the same analysis approach [62,64].

D. QUANTIFICATION OF SECURITY RISKS INTO CRITICAL SOFTWARE SECURITY RISKS (CSSRs) USING FREQUENCY AND RANKING ORDER
To identify the critical software security risks (CSSRs), we used the criterion of 10% occurrences in both SLR and survey findings. Other researchers have used a similar approach [64][65][66]. However, secure software development professionals and researchers might set their criteria for determining the importance of the stated software security risk. Based on this criterion, we identified 46 critical software security risks in the SDLC phases. The CSSRs and practices for addressing these risks are presented in Section IV. We also analyzed these CSSRs on GSD Experts' views concerning the impact of software security risks on secure software development (SSD) based on survey respondents' location, GSD vendor organization size, and respondents' experience level in SSD projects (Accepted for publication in Security in Communication Journal).

E. CASE STUDY
A case study is a suitable research methodology and an effective validation tool in Software Engineering [67,68]. In the last stage of this research, we have conducted three case studies in software development companies to validate our projected model, "Security Assurance Model (SAM) of Software Development," for GSD vendor organizations. We conducted focus groups with case study applicants to get feedback on our newly engineered model.

IV. SECURE SDLC FOR GSD VENDOR ORGANIZATIONS
The CSSRs and their practices collected via the SLR and questionnaire survey were categorized into different SDLC phases and used to develop the secure SDLC for GSD vendor organizations. The structure of this SDLC is shown in Figure 2. VOLUME XX, 2017 1

FIGURE 2. Secure SDLC for GSD Vendor Organizations
It consists of seven stages: Governance and Security Threat Analysis, Secure Requirement Analysis, Secure Design, Secure Coding, Secure Testing and Review, Secure Deployment, and Security Improvement. Each of these phases contains CSSRs and practices for addressing these risks. The following sections briefly describe each stage:

A. GOVERNANCE AND SECURITY THREAT ANALYSIS
To give strategic direction, ensure that objectives are met, ensure risk management is acceptable, and check resource usage is responsible, security governance is the collection of roles and procedures exercised by senior management. Effective security governance will allow your firm to efficiently coordinate its security efforts when it is carried out correctly. Table I presents the CSSRs and their practices in the "Governance and Security Threat Analysis" phase of the secure SDLC for GSD vendor organizations [14,17,23,42,[69][70][71][72][73][74]. In the following tables, R1P1: Means Practice 1 for CSSR1, R1P2: Means Practice 2 for CSSR1, and so on...

R3P1:
All stakeholders, customers, clients need to be agreed on the security requirements definition R3P2: Capture and define non-functional security requirements as attributes of the software R3P3: Define the system boundaries regarding privacy and system maintenance security requirements such as sensitive data and communication. R3P4: Define specialized security terms R3P5: A acceptable security threshold can be defined using a security index. R3P6: Specifically define each security requirement R3P7: Define policies for change management R3P8: Define standard templates for describing authentication, authorization, immunity, privacy, integrity, non-repudiation, intrusion detection, and system maintenance security requirements R3P9: Define the system's operation environment to gain survivability security requirements R3P10: Define change management policies for authentication, authorization, immunity, privacy, integrity, non-repudiation security, and system maintenance requirements R3P11: Define operational processes to gain non-repudiation, integrity, immunity, intrusion detection, and security requirements

B. SECURE REQUIREMENTS ENGINEERING
Software development begins with a phase known as requirements analysis. During the requirements phase, the goal is to define and communicate software requirements specific to the customer's needs. Additionally, security requirements must be defined in addition to software requirements. Security requirements arise from a variety of places and at various periods. Security needs are more complicated to identify than functional requirements since they are not as visible as functional requirements. Table II presents the CSSRs and their practices in the "Secure Requirement Engineering" phase of the secure SDLC for GSD vendor organizations [14,17,23,42,[69][70][71][72][73][74].

R13P1:
Plan for conflicts and conflict resolution for authentication, authorization, immunity security, nonrepudiation, and system maintenance requirements in terms of multiple accounts R13P2: Define standard templates for describing authentication, authorization, immunity, privacy, integrity, non-repudiation, intrusion detection, and system maintenance security requirements R13P3: Use concise and straightforward language to explain authentication, authorization, immunity, privacy, integrity, non-repudiation, intrusion detection, and system maintenance security requirements R13P4: Check that authentication, authorization, immunity, privacy, integrity, non-repudiation, intrusion detection, and system maintenance security requirement meets your standard R13P5: Define change management policies for authentication, authorization, immunity, privacy, integrity, non-repudiation security, and system maintenance requirements R13P6: Use interaction matrices to find conflicts and overlaps in terms of intrusion detection security requirements R13P7: Define the system boundaries in terms of privacy and system maintenance security requirements such as sensitive data and communication R13P8: Define operational processes to gain non-repudiation, integrity, immunity, intrusion detection, and security requirements

C. SECURE DESIGN
Creating a software architecture is the first step in the design process. The critical components of software and their interactions are identified by software architecture.
Software design documents are then used to explain the security architecture in further depth. Security design is constantly revised in light of this information to incorporate security.

D. SECURE CODING
The implementation phase serves a dual purpose in terms of security. The first task is to prevent software security issues by writing secure code. The second step is to look for software flaws using an automated security analysis tool. Automated tools are used to examine the source code created by the development team. These tools are run by computers and look for common security flaws. Manual reviews follow the automatic static analysis. Finally, the software is ready for testing. Table IV presents the CSSRs and their practices in the "Secure Coding" phase of the secure SDLC for GSD vendor organizations [3,8,17,74,[82][83][84][85].

F. SECURE DEPLOYMENT
Release and deployment are two distinct processes in the project's lifecycle. We still regard security activities as a single phase, even though there isn't much work to be done in this phase. A security assessment is performed before the release of the software. The evaluation's purpose is to find remaining security weaknesses. The study concludes with a review report. The development team fixes the Security flaws found in a review report. A security audit is carried out following the evaluation. Based on the audit report, the management decides on the software release. The software is now available for deployment when it has been released. Security activities are documented in Table VI [3,[89][90][91][92][93] during the release and deployment phases.

G. SECURITY IMPROVEMENT
The software becomes commercial after its release and deployment. Some known security flaws may have been left out while the software was made. The software was released with some noncritical security flaws, but they were not dangerous. In the future, the defects will be fixed at some point. As a result, a patch is created to improve the discovered security weaknesses. The patch is then tested and released. The same steps are taken for new threats.

R44P7:
A high-level view of how security trust will be maintained R44P8: Identity and access managementwho has access to specific information and how identity is authenticated and authorized R44P9: Confidentiality and sensitivity -objective analysis of the confidentiality of particular data sets, applications, and other security trust elements R44P10: Acceptable usethe standards that you expect end-users, developers, and other authorized users to abide by R46P8: Priorities the vulnerabilities R46P9: Remediate the vulnerabilities to reduce the risks R46P10: Measure the success of your vulnerability management program R46P11: Where possible, create a backup/archive and verify its integrity by deploying it on a standby system R46P12: Create a checklist/procedure for patch activities and deploy the patch on the standby system R46P13: Test the patched standby system for operational functionality and compatibility with other resident applications. R46P14: Swap the patched standby system into production and keep the previous unpatched production system as a standby for emergency patch regression R46P15: Closely monitor the patched production system for any issues not identified during testing R46P16: Patch the standby system (old production) after confidence is established with the production unit. Update related records and software configuration management plan.

V. SECURITY ASSURANCE MODEL (SAM) OF SOFTWARE DEVELOPMENT FOR GSD VENDORS
This section discusses building a suggested Software Development Security Assurance Model (SAM) for GSD Vendor Organizations. The structure of SAM of software development and its dimensions, such as security assurance levels and evaluation method, are discussed in the following sections:

A. STRUCTURE OF THE SAM OF SOFTWARE DEVELOPMENT
We have developed SAM of Software Development for GSD Vendors by studying various models frameworks [4,13,15,16,32,36,39,40,42,44,60,70,83,96,97] and the results obtained from the SLR [98] and questionnaire survey. The process flow for SAM of software development is depicted in Figure 3.

B. SECURITY ASSURANCE LEVELS OF SAM OF SOFTWARE DEVELOPMENT
A security assurance level includes relevant specific security practices for a specific process area: Governance and Security Threat Analysis, Secure Requirement Engineering, Secure Designing, Secure Coding, Secure Testing and Review, Secure Deployment and Secure Improvement, that can improve the organization's software security processes associated with that process area.
Software development Organizations that want to understand better their software security practices need to compare them with Software Security Assurance (SAM) of Software Development best practices. Implementing SAM practices often starts with an initial Governance and Security Threat Analysis level. Generally, a Software Development business decides to be appraised for one or more reasons, including to:  Evaluate how the organization's processes compare to SAM of Software Development's best security practices and determine areas of improvement  Share information with customers or suppliers about how the organization compares to SAM of Software Development's best security practices  Comply with contractual terms of customers It's worth noting that while the goal of organizations is to reach level 7 (Security Improvement), the model is still applicable and beneficial for organizations that have achieved this security assurance level. Organizations at this level are primarily focused on maintenance and improvements, and they also have the flexibility to focus on innovation and respond to industry changes.
The CSSRs and practices for addressing these risks are grouped into seven different levels, which we call security assurance levels, e. g,  Level-1: Governance and Security Threat Analysis  Table I-VII) were identified using SLR and questionnaire survey.

C. ASSESSMENT METHOD FOR SAM OF SOFTWARE DEVELOPMENT
The SAM of Software Development assessment process is based on the Motorola evaluation tool [99]. Motorola created this tool to evaluate the present state of a company's software processes and find areas for improvement [99]. Other researchers have widely used it to assess their proposed models' maturity, readiness, or assurance [15,42,60,70,100].
The following three measurement dimensions are used by the Motorola instrument [99]: 1. Approach: This aspect is concerned with the willingness and ability of the organization to implement a given practice.

Deployment:
This dimension looks at how well practices are used in different project parts.

Results: This indicator measures the success of projects across domains.
Each dimension of practice is evaluated by providing a score value (0, 2, 4, 6, 8, or 10). The given score value relates to a specific dimension's performance level and can be assessed using the criteria listed in Table 8. To assess the practice under specific security assurance level, the following steps should be followed:  Step 1: For each software security practice, compute an average of the three-dimensional scores, then round that result to the nearest whole integer.  Step 2: Add Step 1 to the number of security practices for a specific critical software security risk (CSSR). Then divide by the total number of practices. This determines the security assurance of the overall score for a particular CSSR.  Step 3: A security assurance score of less than seven is deemed weak, while a score of 7 or greater is regarded as strong.

D. VALIDATION OF THE SAM OF SOFTWARE DEVELOPMENT USING CASE STUDIES
A case study is considered an appropriate research method in software engineering and a highly effective tool for validation purposes [67,68]. In the last stage of this research, we have conducted three case studies on software development companies to validate our projected model (SAM of Software Development). The SAM of Software Development assessment process is based on the Motorola evaluation tool [99]. To get feedback on our suggested model, we convened focus groups with the participants of the case studies. The key objectives of performing case studies in this study are as follows:  Present that SAM of Software Development for GSD Vendor Organizations may be employed in a real-world setting. We chose one large, one medium-sized, and one small-sized company for our case study to reduce the impact of their size.

5) COMPANY A
Iflexion (https://www.iflexion.com/about) provides fullcycle services in content management systems, portals, eCommerce, web-based solutions for enterprise and media content distribution, and social software worldwide. We have been providing software development and related IT services since we started in 1999. To deliver high-quality solutions, they combine the expertise of 850+ trained software professionals with tried-and-true techniques, business domain knowledge, and technical competence.
Iflexion US and UK Offices: IFlexion US (Head Office). 3900, S. Wadsworth Blvd., Denver, CO 80235. Iflexion UK. 3rd floor, 5-8 Dysart Street. Their clients and partners are dispersed in 30+ countries, as presented in figure 5. They cover the entire cycle of enterprise software development, as depicted in Figure  6.

7) COMPANY C
Company C (Peshawar, Pakistan) is a CMMI Level-3 software development firm based in Peshawar, Pakistan that offers Information Technology products and services that integrate applications and data within an enterprise and across the industry. The firm provides a complete spectrum of services ranging from Financial Systems, Enterprise Resource Planning (ERP), Monitoring & Evaluation (M&E) Systems to Business Process Re-Engineering (BPR), Mobile based Information Systems, and eGovernment Information and services automation. Our team of highly experienced and qualified professionals provides practical solutions to organizations in both the Public and Private sectors. We build cohesive, flexible, and cost-effective IT solutions and guarantee their delivery on time and within budget. While ensuring timely and efficient delivery of services, they are not daunted by new technologies and always strive to stay ahead of the technological advances in other parts of the world.
Their services include an online web-based software application, Desktop, and Mobile development. They also design and develop embedded systems. They integrate different systems and implement an e-payments gateway. They think and innovate for you with new ideas to solve unsolved problems.
They combine Design Thinking, Agile Practices, Software Quality Processes, and Innovation Management to create and build digital transformation solutions. It offers five service pillars: Software Solution Design, Agile Software Development, Software Testing, Agile Team Allocation, and Professional Allocation.

E. ANALYSIS
The data collected during the case studies were analyzed in the following ways:  To assess company security assurance level for CSSRs faced by GSD vendor organizations in secure software development.
 To calculate the score for each CSSR and practice of  each company, see Tables IX, X, and XI.  The CSSR will be recognized as "Strong" (strongly addressed) if the overall score is greater or equal to 7. Otherwise, "Weak" (weakly addressed)  To examine whether SAM of Software Development needs any improvement, we conducted a focus group session with the participants to get feedback The focus session aims:  To determine whether or not SAM of Software Development can be used effectively in an organization to identify strong and weak CSSRs in the context of Secure Software Development.  Identify whether SAM of Software Development is evident, easy to use, and specifically helpful in measuring and eliminating security risks in Secure Software Development.  To assess the participant's satisfaction with the SAM of Software Development assessment outcomes.  Verify that each CSSR's practices are easy to follow.  Validate SAM of Software Development generalization and applicability for GSD vendor companies.  They identify strong and weak software security activities in Secure Software Development using SAM software development.

F. ASSESSMENT RESULTS OF COMPANY A
We have used Motorola Assessment Tool [99] for the assessment results of each company. A score of 7 or above for each CSSR indicates a specific company had successfully addressed the risk. Any CSSR with a score of less than seven is considered a weakness. The Company-A participant has measured his security assurance for these CSSRs using SAM of Software Development. Table IX presents the Company-A assessment results. The assessment will focus on the following points:  Table IX presents that Company-A stands at Level-4 "Security Coding" of the SAM of Software Development and comprehensively addresses the security risks of the previous three levels (Governance and Security Analysis, Secure Requirement Engineering, and Secure Desing) since almost it achieved a score greater than 7.  Company-A is weak in addressing the CSSR38 "Messy code, code bad smells, dead code", since the score values are less than 7.
However, Company A should focus more on monitoring the success of practice implementation rather than organizational commitment. This will aid in creating secure software by enhancing its security assurance:  Table X presents the Company-B assessment results. The assessment will focus on the following points:

G. ASSESSMENT RESULTS OF COMPANY B
 Table X presents that Company-B stands at Level-3 "Secure Design" of the SAM of Software Development. It has fully addressed the security risks of the other two levels (Governance and Security Threat Analysis and Secure Requirement Engineering) since almost it achieved a score greater than 7 in the first three levels.  Company-B is weak in achieving Level-4 "Secure Coding" since the score values of "CSSR17: Improper secure design documentation" and "CSSR21: Improper conduction of design and architecture security review" are less than 7.  Each of the practices for which Company-B has a score of less than 7 requires improvement.  It should prioritize Level-4 "Secure Coding" practices. This will help achieve a high-security assurance level in secure software development. The results show that Company-B is doing very little in security activities in secure coding, which is an area for improvement.  Table XI presents the Company-C assessment results. The assessment will focus on the following points:  Table XI presents that Company-C achieved all the security assurance levels of SAM of Software Development and comprehensively addresses the security risks of all levels since almost it achieved a score greater than 7. However, Company C should focus more on monitoring the success of practice implementation rather than organizational commitment. This will aid in creating secure software by enhancing its security assurance.

I. FEEDBACK FROM CASE STUDY PARTICIPANTS
The case study enabled us to evaluate the practicability of the SAM of Software Development for GSD vendor organizations. To get feedback, we asked 30 questions from the case study participants, which are summarized in Appendix A.

VI. THREATS TO VALIDITY
This section underlines the threats to validity. And how we overcome them to strengthen our confidence in our investigation's conclusions. According to [101], internal, external, and conclusion-validity threats are all examples of risk categories.

A. CONSTRUCT VALIDITY
One of the possible concerns is the lack of sources available in other databases or after the research was completed. We used an SLR to find all of the relevant articles in the formal literature, and we searched six different databases to make sure we found everything. We also collected the data through a questionnaire survey from software development organizations. This ensured that all relevant sources were covered completely. As a result, we have sufficient evidence that SAM of Software Development covers most software security procedures.
There is also a problem with assigning practices to CSSRs when making a SAM of Software Development. This can be subjective. We carried out the assignment based on our experiences and what we learned from the SLR and questionnaire survey.
Three university professors (2nd Co-Author (Supervisor), 3rd Co-Author, and 4th Co-Author (Co-Supervisor)) repeatedly validated the structure of SAM of Software Development and its security assurance levels and activities to reduce this threat.

B. INTERNAL VALIDITY
The techniques we discovered from our SLR and questionnaire survey are a good approximation of current secure software development methods. SLR data extraction and source selection are prone to human error because not all sources give sufficient or explicit information about our research topics. The sources were thoroughly reviewed and chosen based on quality criteria to minimise this limitation.
We have concerns regarding the accuracy of the assessment results because the participants in our case study appraised the organization's activities. The assessment may be subjective because adhering to the requirements of the Motorola assessment instrument necessitates the assessor's close attention to acquiring correct results.
In addition to existing software security experience, members' roles within the firm are also factors.

C. EXTERNAL VALIDITY
The study's findings may not apply to all software development firms. Only three companies took part in the case studies we used to determine how well SAM of Software Development worked. Consequently, it is essential to be careful when making decisions about the SAM of Software Development's applicability.

D. CONCLUSION VALIDITY
We gathered adequate information to support our conclusions about existing CSSRs and practices for addressing these risks of secure software development by conducting the SLR and questionnaire survey. The SLR and questionnaire were meticulously carried out methodically, and the sources were assessed using quality standards. This increases our confidence in SAM of Software Development and decreases the risk of jeopardizing conclusion validity.

VII. CONCLUSION AND FUTURE WORK
This section outlines our study's effort and main contributions. It also outlines the research directions that should be pursued in the future.

A. CONCLUSION AND DISCUSSION
This study's primary purpose is to develop a Security Assurance Model (SAM) of Software Development for GSD Vendors. In the SDLC phases, this model will assist software development firms in reviewing and enhancing their security processes. The primary goal of the first phase (doing SMS) is to determine what the current state-of-theart is in terms of secure software engineering (SSE) [22,23]. The final selection was made from 116 studies that met the inclusion and exclusion criteria [22,23]. After extracting data from the selected articles, they were classified according to their quality, software security processes/models/frameworks, software security methodologies, SDLC phases, publication venue, and SWOT analysis of the software security approaches [22,23].
SLR was used to classify key papers to identify security threats and practices during the second phase of this research [98]. The tollgate [51] approach was used to choose 121 papers based on inclusion, exclusion, and quality rating criteria. This study identified 145 security risks and 424 best practices that can assist software development businesses in managing security throughout the SDLC's various phases [98].
In the 3rd stage of this study, an online survey method is employed for data collection [61]. During the survey's implementation, a total of 64 responses were collected. All of the responses were manually reviewed. We excluded 14 responses because the expertise shared by these 14 persons was unrelated to GSD and/or SSD. For analysis, the final 50 survey results were taken into account. This study empirically validated 145 software security risks and 424 security practices that assist GSD vendor organizations in managing the security activities in the SDLC phases.
In the 4th stage of this research, we identify the critical software security risks (CSSRs); we used the criterion of 10% occurrences in both SLR and survey findings. Based on this criterion, we identified 46 critical software security risks in the SDLC phases.
In the 5th stage of this research, we have developed SAM of Software Development for GSD Vendors by studying various models frameworks [4,13,15,16,32,36,39,40,42,44,60,70,83,96,97] and the results obtained from the SLR [98] and questionnaire survey. The CSSRs and practices for addressing these risks are grouped into seven different levels, which we call security assurance levels: "Level-1: Governance and Security Threat Analysis, Level-2: Secure Requirement Analysis, Level-3: Secure Design, Level-4: Secure Coding, Level-5: Secure Testing and Review, Level-6: Secure Deployment, Level-7: Security Improvement". A total of 46 CSSRs and 388 practices (see Table 1-7) were identified using SLR and questionnaire survey.
The SAM of Software Development assessment process is based on the Motorola evaluation tool [99]. Motorola created this tool to evaluate the present state of a company's software processes and find areas for improvement [99].
In the last stage of this research, the model is tested as a case study in a software development company, using data from real software projects to examine the results of a practical experiment in that company. On compares the results in two development scenarios: one with reactive security and one with proactive security in all phases of software development (SDLC). The case study results indicate that SAM of Software Development helps measure the security assurance level of an organization. It will also serve as a framework for researchers to develop new software security measures.
This study recommended various security practices to follow in each phase of the SDLC to achieve a secure SDLC. The successful integration of these operations reduces effort, time, and cost while creating secure software applications. It helps software development businesses improve their software security and efficiency. This will also raise the developer's knowledge of the importance of secure development techniques.
We have briefly answered the research questions mentioned in Section-I in the following paragraphs: RQ1: How can a secure SDLC be developed for GSD vendor companies that are both practical and robust?
The CSSRs and practices for addressing these risks are grouped into seven different levels, which we call security assurance levels, e. g,  Level-1: Governance and Security Threat Analysis The security assurance levels of SAM of software development for GSD vendor organizations are illustrated in Section V-D (see Figure 4). 46 CSSRs and 388 practices (see Section IV, Table I-VII) were identified using SLR and questionnaire survey.
The SAM of Software Development assessment process is based on the Motorola evaluation tool [99]. Motorola created this tool to evaluate the present state of a company's software processes and find areas for improvement [99]. Other researchers have widely used it to assess their proposed models' maturity, readiness, or assurance [15,42,60,70,100].

RQ2:
Is the proposed security assurance model capable of assisting GSD organizations in determining their security assurance to produce secure software?
A case study is considered an appropriate research method in software engineering and a highly effective tool for validation purposes. In the last stage of this research, we have conducted three case studies on software development companies to validate our projected model (SAM of Software Development). To get feedback on our suggested model, we convened focus groups with the participants of the case studies. We chose one large, one medium-sized, and one small-sized company for our case study to reduce the impact of their size.
We have used Motorola Assessment Tool for the assessment results of each company. A score of 7 or above for each CSSR indicates a specific company had successfully addressed the risk. Any CSSR with a score of less than seven is considered a weakness. The Company-A participant has measured his security assurance for these CSSRs using SAM of Software Development. Table IX presents the Company-A assessment results. The assessment will focus on the following points:  Table IX presents that Company-A stands at Level-4 "Security Coding" of the SAM of Software Development and comprehensively addresses the security risks of the previous three levels (Governance and Security Analysis, Secure Requirement Engineering, and Secure Desing) since almost it achieved a score greater than 7.  Company-A is weak in addressing the CSSR38 "Messy code, code bad smells, dead code", since the score values are less than 7. Table X presents the Company-B assessment results. The assessment will focus on the following points:  Table X presents that Company-B stands at Level-3 "Secure Design" of the SAM of Software Development. It has fully addressed the security risks of the other two levels (Governance and Security Threat Analysis and Secure Requirement Engineering) since almost it achieved a score greater than 7 in the first three levels.  Company-B is weak in achieving Level-4 "Secure Coding" since the score values of "CSSR17: Improper secure design documentation" and "CSSR21: Improper conduction of design and architecture security review" are less than 7.  Each of the practices for which Company-B has a score of less than 7 requires improvement. Table XI presents the Company-C assessment results. The assessment will focus on the following points:  Table XI presents that Company-C achieved all the security assurance levels of SAM of Software Development and comprehensively addresses the security risks of all levels since almost it achieved a score greater than 7.
However, Company C should focus more on monitoring the success of practice implementation rather than organizational commitment. This will aid in creating secure software by enhancing its security assurance.
The case study enabled us to evaluate the practicability of the SAM of Software Development for GSD vendor organizations. To get feedback, we asked 30 questions from the case study participants, which are summarized in Section V-I (see Appendix A) for details.
We compare the goals of our research work with other relevant studies, as depicted in Table XII.  In this paper, they report SLR findings to identify the challenges faced by the globally distributed teams during different software development phases. They also suggested best practices and tools alleviate these challenges. 8 An This article reviews the most widely used security software models. It proposes a new Security Assurance Model (SAM) for Software Development that is adaptable to all contemporary scenarios, emphasizing global software development (GSD) vendor companies. The SAM of Software Development was developed after studying 11 well-known development models and analyzing results obtained from a systematic literature review (SLR) and questionnaire survey. The SAM of Software Development consists of seven security assurance levels: Governance and Security Threat Analysis, Secure Requirement Analysis, Secure Design, Secure Coding, Secure Testing and Review, Secure Deployment, and Security Improvement. The security assurance levels of SAM of software development consist of 46 critical software security risks (CSSRs) and 388 practices for addressing these risks. The proposed SAM of Software Development was assessed based on a tool created by Motorola, which is used to evaluate the present state of a company's software processes and find areas for improvement. We conducted 3 case studies on software development companies, using data from real software projects to examine the results of a practical experiment in each company. The results of the case studies indicate that the proposed SAM of Software Development helps measure the security assurance level of an organization. In addition, it can potentially serve as a framework for researchers to develop new software security measures.

B. FUTURE RESEARCH DIRECTIONS
With the increasing number of software security threats, regularly upgrade software security processes and practices. This study project can be improved in a variety of ways. The following are some of the open study directions that researchers can look into:  To improve the outcomes of SAM of Software Development, collaboration with software development organizations is required. Depending on the facilities and methods used, it might be adapted to meet the needs of various organizations.  The SAM of Software Development might include characteristics relating to specific technologies like the Internet of Things (IoT), blockchain, and cloud computing.  The SAM)of Software Development might be made available as an online repository (tool) updated regularly with new academic and industry practices. The SAM of Software Development will become a reliable resource for scholars and practitioners. 6. It is easy to understand distribution of critical software security risks and practices for addressing these risks among different software security assurance levels, e.g. Governance and threat analysis, Secure Requirement Engineering, Secure Design, Secure Coding, Security Testing and Review, Secure Deployment, and Security Improvement. Ans: Many times software developers face problem during System and Application integration leading to failure of software projects also. Further Maintenance and Up gradation becomes a problem for software developers for some software projects. The company need to make changes are acceptable till design but once development starts any further change should be rejected.

27.
Are there any components that you may suggest to add to the SAM of Software Development in the future, please also give the reasons? Ans: Integrated Development Environment (IDE)-Modern IDEs like Visual Studio or Eclipse offer so much support to the coding process -built-in wizards to help you accomplish numerous tasks, code completion and dependency management, are just a few examples of standard features -that it's almost inconceivable to attempt a serious application without one. 28. Please provide any comments relating to the assessment method. Ans: Software testing Technology CMMI. The Capability Maturity Model Integration (CMMI) is a process model that provides a lucid definition of the process improvement approach which examines whether an organization's current processes are in place and helps them identify their strengths and weaknesses. 29. Please provide any comments relating to the distribution of practices across various critical software security risks. Ans: Web applications that do not properly protect sensitive data could allow threat actors to steal or modify weakly protected data. They could also conduct malicious activities such as credit card fraud and identity theft, among others. Improperly configured or badly coded APIs could also lead to a data breach. 30. Please provide any comments relating to the usability of SAM of Software Development with respect to time it take users to addressing the CSSRs. Ans: A key part of the software development process, usability testing provides invaluable feedback on the user experience of a product. Usability testing means conducting real-world testing with a segment of your customer base.