Systematic Literature Review on Security Risks and its Practices in Secure Software Development

Security is one of the most critical aspects of software quality. Software security refers to the process of creating and developing software that assures the integrity, confidentiality, and availability of its code, data, and services. Software development organizations treat security as an afterthought issue, and as a result, they continue to face security threats. Incorporating security at any level of the Software Development Life Cycle (SDLC) has become an urgent requirement. Several methodologies, strategies, and models have been proposed and developed to address software security, but only a few of them give reliable evidence for creating secure software applications. Software security issues, on the other hand, have not been adequately addressed, and integrating security procedures into the SDLC remains a challenge. The major purpose of this paper is to learn about software security risks and practices so that secure software development methods can be better designed. A systematic literature review (SLR) was performed to classify important studies to achieve this goal. Based on the inclusion, exclusion, and quality assessment criteria, a total of 121 studies were chosen. This study identified 145 security risks and 424 best practices that help software development organizations to manage the security in each phase of the SDLC. To pursue secure SDLC, this study prescribed different security activities, which should be followed in each phase of the SDLC. Successful integration of these activities minimizing effort, time, and budget while delivering secure software applications. The findings of this study assist software development organizations in improving the security level of their software products and also enhancing their security efficiency. This will raise the developer’s awareness of secure development practices as well.


I. INTRODUCTION
Secure Software Engineering (SSE) has become a significant paradigm in the development of secure software for the software industry in recent years as security problems in the SDLC are difficult to address. Information and Communication Technology (ICT) has undeniably changed human lives, communications, the digital economy, socialization, and entertainment. Similarly, the market for internet-enabled applications is increasingly increasing. Therefore, there is an ever-growing demand for trusted software applications. Software security is the key to the software's success, especially in The associate editor coordinating the review of this manuscript and approving it for publication was Luca Cassano. today's fast-paced and technology-oriented world. Software and technology have become such an inseparable part of our lives that it's virtually impossible to imagine a sector that doesn't employ them in its day-to-day operations. The world in every aspect has been modernized by an immense use of software systems. Software security ensures that the CIA (Confidentiality, Integrity, and Availability) of data and services are not compromised [1], [2]. This can only be done if the security is considered during all SDLC phases [1], [2].
To incorporate security into the software engineering paradigm, it should be considered from the start of the SDLC [3], [4]. 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 [5]- [7]. Most businesses view security as a post-development process [8]. Security isn't considered at some point in the predevelopment phase [9]. A simple error sometimes can end up causing millions of dollars of losses in today's business process. But unfortunately, many software development companies do not follow best practices to incorporate in SDLC [10], [11]. This negligence includes lack of awareness, fear of time and cost overrun, teams, are always in a hurry, use of third-party components and, lack of qualified professionals, etc. Rapid developments in information and communication technologies (ICTs) have made software security a key concern, such as the Internet of Things (IOT) and the Internet of Every Things, the advancement of Internetbased software systems, cloud computing, social networking, and location-based services; also besides, new business paradigms, versatile customers' requirements, rapid advancement in ICTs, and new regulations are constantly making a software application evolve accordingly [12], [13]. As software development becomes more complex, distributed, and concurrent, security issues have an ever-greater influence on software quality [14]. Insecure software harms an organization's reputations 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 [14]. The majority of software programs are designed and deployed without attention to protection desires [15], [16]. Hidden attacking risks within or outside the organization are emerging day-by-day, results in huge financial loss, as well as confidentiality and credibility losses by putting the availability and integrity of organizational data at risk [17], [18]. Various approaches to software quality have been developed, such as 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'' [19]. However, there exists no explicit solution for incorporating security into all phases of SDLC.
One of the critical reasons for widespread vulnerabilities is not making security a key priority [2]. Even diligent businesses use the ''fix and penetrate'' technique in which security is accessed after completing the project [2]. The drawback of this is that the application users do not apply these patches. Further, attackers might plan and penetrate new vulnerabilities [20]. Traditional security mechanisms mainly focus on network systems, and they spent a huge amount of money to make their network secure. These mechanisms include IDS (Intrusion detection system), firewalls, encryption, antivirus, and antispyware [5], [21]. Building secure software means building software that functions properly even under malicious attacks [22]. This requires addressing the security challenges through the whole SDLC, especially in the early stages during the design phase [23]. This reduces the risk of overlooking critical security requirements or introducing security flaws throughout the implementation process.
SDLC is a process for producing high-quality, low-cost applications in the shortest amount of time. It offers a wellstructured step flow that assists enterprises in easily produce high-quality, well-tested, and ready-to-use production of software. The common phases of SDLC include requirement, design, coding, testing, deployment, and maintenance [24]. All these phases are dependent on each other are of equal importance. If security is not incorporated during all phases of SDLC then the resultant product will not be vulnerable to security threats. 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 [20], [22], [25].
Researchers in the literature [26]- [30] have introduced and practitioners in the software industry have adopted a wide variety of software security practices, approaches, and methods. In addition, several companies have created maturity models and frameworks to assess the degree of maturity of their software security practices. On the other hand, none of these models or structures are specifically committed to recognizing security risks/threats and their practices in the SDLC. As a result, they fall short of covering all aspects and activities of a secure SDLC. Because of the importance of a secure SDLC, it's critical to recognize the security threats that vendor organizations face while developing secure applications, as well as risk mitigation strategies. This will enable software development vendors to assess their maturity and assurance levels, as well as improve their secure SDLC performance. It will also raise the level of awareness among software engineers. Therefore, to assess and find out security threats and their practices in SDLC phases, we have studied the existing literature on finding software security threats/risks in SDLC and highlighted the security practices that need to be incorporated in SDLC phases to strengthen the security of the software development process.
The remainder of this paper is structured as follows: Section II provides context information and related work. Research methodology is presented in Section III. The results of this study are presented in Section IV. A conclusion and future studies are presented in Section V. Finally, Section VI discusses the study limitations.

II. BACKGROUND
Software security is a hot subject both in academia and industry, as it has made an important contribution to this research field over the last two decades. Secure software is software that cannot be accessed, updated, or targeted by an unauthorized user. Software that has no vulnerabilities is considered highly stable, whereas software that has at least one vulnerability is considered vulnerable [20], [31].

A. SOFTWARE SECURITY BASIC CONCEPTS
This section describes some of the security terminologies [26], [31], [32] used in this paper: • ''Software security is the idea of engineering software that continues to function correctly under malicious attack [4], [33].'' • ''Software security is the process of discussing an application to discover risks and vulnerabilities of the application and its data [34].'' • Asset: ''is anything that has value to the organization, its business operations and their continuity, including information resources that support the organization's mission.'' • Vulnerability: ''A weakness in the design, operation, implementation or any process in the system which expose the system to a threat defined it as a weakness of an asset or group of assets that can be exploited by one or more attacker.'' • Threat: ''A possible danger that may result in harm to systems and organization.'' • Attack: ''An actual event done by a person; attacker to harm as an asset of the software through exploiting a vulnerability.'' • Risk: ''A potential for loss, damage, or destruction of an asset as a result of a threat exploiting a vulnerability.'' • Software Security Requirement: ''is a non-functional requirement that elicits a control, constraint, safeguard or countermeasure to avoid or remove security vulnerabilities from requirements, design or code.'' • Confidentiality: ''means to disclose information to people or programs that are authorized to have access to that information.'' • Integrity: ''assures that a system performs its intended function in an unimpaired manner, free from deliberate or inadvertent unauthorized manipulation of the system.'' • Availability: ''assures that systems work promptly, and service is not denied to authorized users.'' • Process: ''is an instance of a computer program that is being executed.'' • Secure Software Process: ''is a set of activities used to develop and deliver a secure software solution.''

B. SECURE SDLC PROCESSES
Software security is threatened at different points during SDLC phases, both through inadvertent and malicious acts by insiders and outsiders with no association with the company. The most efficient technique to eliminate software bugs/vulnerabilities is to incorporate security and other nonfunctional standards into all phases of the SDLC. Over the years, there has been a lot of research into ''high integrity,'' and researchers and practitioners have worked hard to construct secure software systems. Despite all of the efforts, software that offers high standards of security integrity is uncommon. Even when security is a specified, requirement and security design is given to the implementation team as input, there is no assurance that the result will be safe [35]. This section discusses the different methodologies for incorporating security into the SDLC phases, as well as the security practices that are commonly used in these methodologies: McGraw [36], [37] 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 artifacts. Microsoft developed the Microsoft Trustworthy Computing Security Development Lifecycle [38] adds a set of security practices to each step of its software development process, as follows: during requirement phase, the security feature requirements are defined based on the customer demands, in the design phase the MS SDL suggests a set of activities to be performed such as threat modeling for security risk identification, identifying components that are critical to security or needs special attention during testing, in the implementation phase, use of static analysis code-scanning tools and code reviews, after completing implementation, the complete software is tested focusing on the security-critical components of the software during the testing phase, a final code review of new as well as legacy code is used during the verification phase, and finally, during the release phase, a Final Security Review is conducted by the Central Microsoft Security team.
TSP Secure (Team Software Process for Secure Software Development) [39] is developed specifically for software teams to help them create a high-performance team and prepare their work to produce the best results. The TSP Secure focuses directly on the security of software in three ways: planning, development and management, and training for developers about security-related aspects and other team members. In the initial phase; planning, the team identifies security risks, security requirements, secure design, code review, use of static analysis tools, unit tests, and Fuzz testing, and produces a detailed plan to be used in the development phase during a series of meetings. Next, the plan is executed, and the team ensures that all the security activities are taken place. Secure Software Development Process Model (S2D-ProM) [40] is a strategy-oriented process model that offers guidance and support to developers and software engineers at all level, from beginners to experts, to build secure software. Niazi et al. [2], conducted a systematic literature review (SLR) to pinpoint the required practices for developing secure software. This paper also amended Somerville's requirement engineering practices. After identifying best requirement practices, a framework for secure requirement engineering named Requirements Engineering Security Maturity Model (RESMM) was developed. Questionnaires and case studies were used to test the suggested framework. The findings demonstrate that the proposed framework is practical and adaptable.
Comprehensive, Lightweight Application Security Process (CLASP) [41] is a straightforward process that consists of 24 high-level security activities that can be completely or partially integrated into software during the SDLC. In CLASP threat modeling and risk analysis is performed during requirement and design phase. In the design and implementation phase, it suggests secure design guidelines and secure coding standards [42]. Inspections, static code analysis, and security testing are performed in the assurance phase [43]. Correctness by Construction is a technique for developing high integrity software [44]. The following are the seven main principles of Correctness by Construction [44]: expect requirements to change, know why you are testing, eliminate errors before testing, write software that is easy to verify, develop incrementally, some aspects of software development are just plain hard, the software is not useful by itself. AEGIS (Appropriate and Effective Guidance for Information Security) first evaluating device assets and their relationships, then moves on to risk analysis, which defines weaknesses, threats, and risks [45]. According to Subedi et al. [46], security protection is not considered in the overall system development lifecycle due to which a lot of security breaches occur. This paper presents a secure paradigm that is an extension of security development practices in agile methodology to overcome this problem in web application development.
The Secure Software Development Model (SSDM) security training provides stakeholders in software development with adequate security education [47]. During the requirements process of SSDM, a threat model is used to identify and their capabilities. The security specification must be specialized by specifying the guidelines for achieving security. Penetration monitoring is the only SSD operation in the security assurance process that checks the software's ability to avoid the attack. Security Quality Requirements Engineering (SQUARE) methodology allows for elicitation, classification, and prioritization of security specifications for information technology systems and applications [48]. Al-Matouq et al. [20], conducted a Multi-vocal literature review to identify the best practices for designing secure software. Based on identified best practices, a framework Secure Software Design Maturity Model (SSDMM) was developed. The framework was evaluated using case studies, and the results show that SSDMM helps measure the maturity level of software development organizations.
• It is obvious from the above discussion that incorporating security in different phases of SDLC is inevitable for quality software. There exist various studies that discuss the importance of incorporating security in SDLC, however, still there exists space for further research in this area. To address the security risks at all stages of SDLC, there is a dire need to identify security risks and introduce secure specialized practices in SDLC. Therefore, to assess and measure security threats and vulnerabilities in SDLC phases, we have conducted a systematic literature review in this paper to identify security risks in SDLC and highlighted the security best practices that need to be incorporated in SDLC phases to make the development process more secure.

III. RESEARCH METHODOLOGY
A systematic literature review (SLR) was selected as the research method for this study. ''An SLR is a type of secondary study in which primary studies are examined impartially and iteratively to define, interpret, and discuss evidence relevant to the research questions'' [49]. According to Kitchenham [49], [50], an SLR has three main phases: planning, conducting and reviewing the review, as shown in Table 1. Researchers have used the SLR process in several domains [2], [51]- [55]. The authors of this work completed all three phases of the SLR. Inter-rate reliability analyses were undertaken during the initial and final selection phases of the SLR to reduce inter-person bias. The findings of the inter-rater reliability review are discussed in Section 3.2. We followed all of the processes in the three phases of the SLR, as stated in Table 1. The current study conducted an SLR to identify security threats/risks in SDLC and highlighted the security best practices that need to be incorporated in SDLC phases to make the development process more secure. The following research questions were answered in this study: RQ1: What are the security risks that vendor firms should avoid while designing secure software applications, according to the literature? RQ2: What are the best practices for vendor firms to follow when designing secure software applications, as identified in the literature?

2) DATA SOURCES
In this study, the data is gathered by an automated search. The automated search technique uses an optimized search string to find the most relevant literature [56]. As a result of our research experience and the recommendations of Chen et al. [57], a total of six digital repositories were chosen.
The following are the digital sources that were chosen:

3) SEARCH STRING
We generate an efficient search string based on the submitted study questions for retrieving relevant literature from the selected digital sources. Zhang et al. [56] following the criteria of the search strings were developed using the main search words used in the research questions and their alternatives.
To concatenate the keywords into search strings, we used the Boolean ''OR'' and ''AND'' operators. The following string was used to scan the digital repositories:
• Papers were published between 2000 and 2020.
• Papers must provide at least one risk or practice relevant to software development process security specifications, design, code, testing, and maintenance security.
• Papers were peer-reviewed in conferences and journals.

5) EXCLUSION CRITERIA
For data exclusion, we followed the guidelines based on parameters used by other researchers [11], [32], [55], [58]- [61]: • Papers that don't deal with secure software development and aren't related to the research questions.
• Papers that do not describe software security risks and practices in detail.
• Publications are not peer-reviewed and do not conform to a complete book's abstract, an editorial, or a letter.
• Paper that is not in English.
• Duplicate papers were not considered.

6) STUDY QUALITY ASSESSMENT
The final selected publications' data extraction and quality assessment (QA) were done at the same time. We established a checklist to objectively and subjectively assess the primary studies that were chosen. The checklist was generated using the guidelines given in [61] (Table 2). We have designed seven questions on the QA checklist (QA1-QA7). For each question, the following assessment was made: • We gave an article a score of 1 if it answered the checklist question fully.
• For a partial answer, we gave it a score of 0.5.
• If it did not cover the question on the defined checklist, we gave it a score of 0. The quality evaluation aims to see how well selected primary studies can be used to answer study research questions. As a result, Appendix contains the score assigned to each primary study. The credibility, integrity, and relevance to answering the study questions were used to evaluate the quality of the studies.

B. PHASE 2: CONDUCTION THE REVIEW 1) PRIMARY STUDY SELECTION
The tollgate method suggested by Afzal et al. [62] was used to refine the research articles found during primary study collection. There are five steps to this method (see Table 3): Phase 1: Using search terms to find related articles. Initially, the developed search string and on the base of inclusion and exclusion criteria was used to retrieve 12114 papers from the selected online databases. The tollgate method [62] yielded a shortlist of 121 papers for consideration in the primary study. Finally, the quality assessment requirements were applied to the shortlisted papers. Appendix contains a list of the primary studies that were chosen.

2) DATA EXTRACTION AND SYNTHESIS
The primary (first) author extracted all of the data in this publication by using the inclusion and exclusion criteria as well as the study quality assessment research questions. The other authors, on the other hand, evaluated the categories and subcategories of security risks, as well as their methods, by dispersing them throughout the SDLC phases. Interrater reliability analyses were used to eliminate inter-person bias. Three external reviewers from the Software Engineering Research Group (SERG UOM) randomly selected fifteen papers from the first phase of the tollgate process and applied the tollgate process selection phases (phases 2-5) as well as the quality assessment criteria. We calculated the nonparametric Kendall's coefficient of concordance to examine inter-rater agreement among the reviewers (W) [63] values. The reviewer's rate W on a scale of 0 to 1, with 0 indicating complete disagreement and 1 indicating perfect agreement. W = 0.78 for fifteen publications chosen at random, showing a high level of agreement between the authors and the external reviewers. To acquire the results against the research questions, all of the collected data was arranged by rephrasing the security threats and practices according to the study questions.

C. PHASE 3: REPORTING THE REVIEW 1) QUALITY ASSURANCE OF PRIMARY SELECTED STUDIES
The overall score for each QA question was determined and is presented in Appendix. The QA score for each primary sample was determined using the seven QA questions in Appendix. According to the data, about 88 percent of the primary studies received a score of >57 percent on the QA questions, implying that the primary studies chosen are relevant to the study research questions.

IV. RESULTS
In this section, the results of the SLR study are discussed: This section aims to present security risks/threats to assist software development organizations to avoid these risks when designing secure software development. We have obtained a list of 156 software security risks using the SLR methodology. The identified security risks, along with the frequencies are discussed in the following subsections:

1) LACK OF PROPER ATTENTION TO SECURITY ISSUES DURING THE REQUIREMENT ENGINEERING (RE) PHASE
The findings of this study show that security risks in the RE phase of the SDLC are a highly rated factor, in the development of secure software. It stands on the top (97.5%) amongst all the identified security risks. Existing literature on requirement security has highlighted different security risks that might occur if security is not incorporated from the beginning. Some common security risks that might occur during the requirement phase of SDLC are listed [2], [24], [64]- [67] in Table 4.

2) LACK OF PROPER ATTENTION TO SECURITY ISSUES DURING THE DESIGN PHASE
The stages of the SDLC where the security aspect is considered, according to our findings, can differ from study to study. Design flaws are one of the most common sources of security threats in software systems [20], [68]. It has been observed, that in most cases, software bugs are found during the design process of the SDLC [69]. The design process of the SDLC serves as the foundation for designing a secure software system [70]. Reducing risks in this step can reduce the effort needed in subsequent phases [19], [32]. As it can be observed from the findings of this study, security risks are reported more frequently in the design phase of VOLUME 10, 2022 SDLC. Table 5, presents some of the most common security problems that occur during software design [6], [20], [68], [71]- [73]:

3) LACK OF SECURE DEVELOPMENT OR CODING
The selection of appropriate coding language and classification of modules is a challenging task. Each phase of the SDLC must include a variety of appropriate security protections, analyses, and countermeasures that result in more secure code being released [74], [75]. Table 6 presents, software security issues during the coding phase of SDLC [11], [74], [76]- [78]: Improper authentication and authorization mechanisms refer to the erroneous implementation of authentication functions and access-control policies [79]. Authentication and authorization are critical components of basic security processes, and they are particularly important in the production of secure software [80]. Microsoft uses STRIDE to model threats to their systems; threats are defined by looking into   the possibilities of spoofing identity, tampering with data, repudiation, information leakage, denial of services, and elevation in the given situation [71]. The present study identified 63 articles to discuss authentication and authorization are essential parts of security in the development of secure software. Spoofing, tampering, repudiation, information disclosure, denial of services, elevation of privilege and failure to restrict URL access are some of the most common security issues that hamper the process of secure authorization and authentication [31], [64], [71], [72], [81].
Incorrect input validation refers to the lack of or incorrect validation of input provided by a user via the application's user interface. Injection attacks take advantage of the lack of input validation controls to allow malicious inputs to be passed in, which can be used to obtain elevated rights, alter data, or crash a system [82]. Code injection attacks can breach data security, cause a loss of services, and harm thousands of users' systems [83]. This study identified; Cross-site scripting, Cross-site request forgery, format string problems, code and command injection, autocomplete attribute not enabled,  POST change requests for GET, POST directives with invalidated parameters, and accessible database are injection vulnerabilities from the literature [5], [11], [79], [83], [84].
The vulnerabilities in software systems include outdated software/firmware, default usernames and password, password conjuncture, and the inability to run software updates or change usernames and passwords, are leveraged to gain initial access to systems of corporate targets which then can be further exploited [6], [85], [86].   The majority of security attacks are possible due to implementation flaws such as improper input validation, improper authentication, and authorization mechanisms, improper session management, and other vulnerabilities (Session-Id vulnerable or theft, logout incorrectly implemented, lock failed attempts per browser session, peer-user session restriction, and log replay feature) that compromise the application's intended functionality [5], [79], [87].
In MITRE's Common Vulnerabilities Exposures database, the latest classification of common defects by type is provided in Common Vulnerability Enumeration [88], a list of registered vulnerabilities. As a consequence, the most common forms of security vulnerabilities are weak encryption, explicit password storage, insecure communication, and synchronization errors [88]. Invalidated redirects and forwards, improper use of secure APIs, weak encryption, insecure communication, man in the middle, and bandwidth usage are some of the most common security issues that hamper the communication and encryption processes [85], [88], [89].
Software security is concerned with protecting data, facilities, and applications from harm caused by various types of malware attacks (e.g., password sniffing, viruses, hijacking) that may be mounted by various types of attackers (e.g., hackers, crackers, domestic cyber-terrorists, industrial spies, international military, and so on) [87], [89]. This study identified some of the most common malware attacks (various kinds of viruses, malware, trojan virus, brute force attack, DNS hijacking, replay attack flaws, attacker denies services to the application by opening thousands of connections but does nothing with them, BPEL state deviation and flooding attacks, send fake seismic parameters, the bulleting is modified before and during sending, the bulletin is not delivered or delivered to the fake place, blocking of E-mail notification by a malicious user, the attacker shuts down the user's process, slicing attacks, and cookie poisoning) which affect the processes of secure software development [87], [89]- [91].

4) LACK OF PROPER ATTENTION TO SECURITY TESTING ANALYSIS
The testing phase of the SDLC aims to make sure that all the system components provide their required functionality alone and as part of the whole system. Software testing is the most time-consuming, complicated, and costly process of the SDLC [92]. This phase is an important component of improving the efficiency of software development projects [32]. While it is an essential part of software development, rigorous testing is not always a focus of software engineering education [93]. As a result of this shortcoming, software developers often regard software testing as a liability, lowering overall software quality. Threat modeling is a systematic method for identifying threats that may compromise security, and it is considered a well-known accepted practice by the software testing industry [94]. This phase aims to find possible bugs and errors in the system and remove them. The present study identified 64 papers to discuss software security risks during software testing phase of SDLC. Some common security risks involved in this phase are as follows [5], [22], [95]- [98]:

5) SOFTWARE SECURITY RISKS IN DEPLOYMENT PHASE
Developing secure software systems involves many challenging problems, e.g., designing authentication protocols, improper configuration management, building strong cryptosystems, devising effective trust models and security policies [99]. Configuration management is an important component in the secure maintenance and operation phase [100]. This study identified (see Table 8), some of the common software security risks which affect deployment phase of the SDLC in the development of secure software [5], [78], [99]- [102].

6) SOFTWARE SECURITY RISKS IN THE MAINTENANCE PHASE
Vulnerability-oriented architectural research provides a systematic and thorough approach to evaluating a wide variety of possible vulnerabilities, but it is time-consuming and costly [91]. For estimating the severity and cost of security threats, Table 9 presents, some maintenance and stakeholder considerations may be considered [78], [91], [103].
Software development iterations are of limited time, often few weeks, which makes fitting security activities (e.g., security requirement elicitation) challenging because they are often time-consuming'' [65]. Furthermore, defining security policies takes time and raises the cost of software development [65]. Some of the common issues due to  time pressure in the secure software development process are [65], [83], [101]: i. Organizations compromise security activities to accommodate the accelerated releasing schedule ii. Timing attacks iii. Insufficient time for the teams to get used to the security activities iv. The pressure to deliver to tight deadlines.

B. PRACTICES FOR DEVELOPING SECURE SOFTWARE (ANSWER RQ2)
In all phases of the Software Development Life Cycle (SDLC), the focus on secure software development has gradually grown over the last two decades. To produce secure software, security awareness, guidelines, principles, and practices are very important during all the stages of SDLC. The purpose of this section is to describe software security practices to help software development firms better specify the criteria for secure software development. To answer RQ2, we must go through the following subsections:

1) BEST PRACTICES FOR SECURE REQUIREMENT ENGINEERING (SRE)
The requirement stage in the SDLC is the primary stage where the initial plan for software is made. It necessitates a set of initial specifications, which are collected from a variety of sources. Various methods such as brainstorming, group sessions, and interviews are used to gather requirements. Secure requirement engineering (SRE) is different; the aim is to provide complete security by implementing basic security functions, such as confidentiality, integrity, and availability [25]. SRE is usually done during the first stage of the SDLC, and the success of this phase leads towards a better software product. Further, handling security in this phase assists software development organizations to save rework and additional costs. SRE has proved to be a difficult task over time. The main activities involved in this stage are security requirements identification and inception, documentation, elicitation, analysis and negotiation, mapping, verification and validation, prioritization and management, authentication, and authorization [2], [64], [104]. Various researchers and industry practitioners have emphasized the importance of considering SRE from the start of the secure software development process. We list down (See Table 10) the commonly used best practices for handling security issues during the requirement stage of SDLC [2], [22], [24], [59], [64], [67], [90], [104]- [106].

2) BEST PRACTICES FOR DESIGNING SECURE SOFTWARE
The design phase is one of the most creative stages of the SDLC, which is one of the reasons it is important from the viewpoint of security [32], [69]. 50%, software defects are identified and detected during the design stage of the SDLC [32], [69]. The security design architecture specifies design methods such a strongly typed programming, least privilege, develop threat modeling, analyze and minimize attack surface [14]. The software developer must consider security best practices during design to complete this phase in a manner that is appropriate and secure. Table 11 presents some of the most widely used design security practices, these should be followed when designing secure software [14], [22], [31], [32], [68], [69], [71]- [73], [105], [107].
3) BEST PRACTICES FOR IMPLEMENTING SECURE CODE 80 percent of system penetration is due to coding errors in commercial software. This is surely a matter of national security. Increased bugs, security issues, and costs are all associated with bad code. Good code pays off in the long run [14]. Due to time-to-market pressures, software developers are passed to meet the deadline, lack security expertise, and fail to follow secure code guidelines. Furthermore, they make the mistake of assuming that perimeter security is sufficient to protect applications. Security code reviews, which can be conducted while the code is being checked for functionality, whether manual or automated, are required to verify the fundamental tenets of software security [22], [108]. The programmer must be aware of implementation-level vulnerabilities when writing secure code [14]. Programmers can use the documentation and guidelines created in earlier stages to help them write secure code. Table 12 shows prescriptive actions to increase security during the coding phase of SDLC [5], [14], [22], [98], [105], [109]- [111].

4) BEST PRACTICES FOR SECURE SOFTWARE TESTING
Software testing is the most time-consuming, complex, and costly phase of the SDLC [92]. This phase aims to identify and fix any bugs or errors in the system. ''To detect potential attacks and the consequences of successful attacks, security testers typically use misuse cases, threat models, and design documents'' [14]. Following the completion of security testing, test documents containing security test cases and a prioritized list of vulnerabilities resulting from automated and manual dynamic analysis are created [14]. Table 13 shows   prescriptive actions to increase security during the testing phase of SDLC [5], [22], [25], [95]- [98], [105], [112], [113].

5) BEST PRACTICES FOR DEPLOYING SECURE SOFTWARE
After the software is deployed into its operational environment, it is important to monitor responses to flaws and vulnerabilities of the system to check for new evolved security patterns [66], [91]. After identifying new security patterns, the same should bed included in the requirement stage for further security improvements in subsequent releases [66], [91]. Static analysis and peer review are two useful procedures for mitigating or minimizing newly discovered vulnerabilities [14]. Final security reviews and audits are performed during the secure deployment phase [14]. At this phase, customer satisfaction is also very important. Table 14 presents prescriptive actions to increase security during the deployment phase of SDLC [5], [14], [98], [105], [114], [115].

6) BEST PRACTICES FOR MAINTAINING SECURE SOFTWARE
Before deploying software, administrators must first understand the software's security stance. Some of the identified faults that were not addressed previously will be revisited, prioritized, and corrected after deployment. New threats are tracked during this phase. The software can never be 100 percent secure, and new threats emerge regularly phase [14]. As a result, efforts must be made to secure the software. The maintenance team should keep track of new threats that the system encounters to address them promptly and prevent security breaches [83], [116]. Table 15 presents prescriptive actions to increase security during the maintenance phase of SDLC [14], [65], [105], [114], [117], [118].

V. CONCLUSION AND FUTURE WORK
The above discussion has highlighted the brief details of SDLC phases along with the security issues and their mitigation practices. Software security is now a primary need for secure software development (SSD) at every phase of the SDLC. We conclude from the preceding discussion that securing software systems in the post-development phases is insufficient, and better ways and means of securing software systems are urgently required. To summarize, software security is an important feature that should be given top priority. Many software projects have failed in the past due to a lack of attention on the security factor. Testing software for security after it has been developed is not only time-consuming and difficult, but it also adds to the project's complexity and more cost. Secure software engineering (SSE) believes that software security is a critical factor that should be assessed early in the SDLC process [119]. To build and deploy a secure software system, we need to integrate security features into our application development life cycle and adapt the latest SSE practices [3], [4].
Backward compatibility will be harmed if security is added after deployment since it will change functionality and/or application interfaces. Because adding security takes more time and money than doing it from the beginning, it is less likely to be done effectively or with care. In view of the necessity of incorporating security into the development lifecycle, the authors of this study endeavored to establish a methodology that addresses security across the SDLC.
The purpose of this article is to identify security issues and to give a set of development techniques, guidelines, activities, principles, and rules to help developers create more secure software. In the light of the importance of software security, we conducted a thorough systematic literature review and identified 145 security risks and 424 security practices for managing security in the SDLC to integrate security into the overall development cycle. This study is prescriptive and can provide software developers with simple security guidelines at each stage of the SDLC. It covers a six-phase SDLC and the prescriptive activities that must be completed at each stage. VOLUME 10, 2022  The software development stages are Requirement, Design, Coding, Testing, Deployment, and Maintenance.
The findings of this study show that security risks in the RE phase of the SDLC are a highly rated factor, in the development of secure software. It stands on the top (97.5%) amongst all the identified security risks. We conclude that many software security issues stem from insufficient or incorrect identification, documentation, analysis, mapping, prioritization, specification, and availability of security requirements. The importance of identifying non-functional security requirements should be stressed more because it aids in the reduction or elimination of software vulnerabilities [2], [61], [100]. Misuse cases are similar to use cases in that they specify what a system should not do, and they are a great way to get security requirements [97], [100]- [102].
Section IV-A shows that software security risks were highlighted in the design phase of the SDLC in 64 percent of the studies in our SLR. This is because design-level flaws are the most common sources of security risks in software systems [32]. We conclude that ''lack of developing threat modeling,'' ''improper secure design documentation,'' and ''lack of attention to follow security design principles'' are the three topmost security issues in the design phase. To mitigate the risks in the design phase, Table 5 presents that ''enumerate threats and prioritize the threat based on the potential impact,'' ''follow least privilege design principle,'' ''implement a defense-in-depth policy which includes multilevel security,'' ''revise or review design implementation,'' and ''implement security design decisions: (security cryptographic protocols, standards, services, and mechanisms)'' are the most highlighted security practices in the design phase.
The antivirus, intrusion detection mechanisms, and firewalls are not enough to reduce the risk in the coding phase of the SDLC. It needs further various suitable security defenses, practices, analysis, and countermeasures that result in further secure the released code [74], [75]. The findings of this study show that ''software security often fail because their development is generally based on ad-hoc foundations or follow traditional development processes,'' ''lack of using secure coding practices,'' ''lack of security awareness, training,'' ''messy code, code bad smells, dead code,'' and ''buffer and array overflow'' are the topmost security risks in the coding phase. To mitigate these risks, software development organizations need to ''perform code review,'' ''provide security knowledge and training to software developers,'' ''implement static code analysis'' and ''secure code writing'' during the secure design phase.
Section IV-A portrays that software security was considered in the testing phase of the SDLC in 53 percent of the studies. The security testing approach is one of the most important, efficient, and widely used methods for improving software security, as it is used to detect vulnerabilities and ensure security functionality. Threat modeling is a systematic method for identifying threats that may compromise security, and it is considered a well-known accepted practice by the software testing industry [94]. We conclude that ''lack of static, dynamic, penetration, and vulnerability analysis security testing,'' ''lack of secure test cases'' and ''lack of security test documentations'' are the topmost security risks in the testing phase of the SDLC. Table 13 presents that ''perform penetration, static and dynamic analysis, fuzz testing, and vulnerability scanning testing,'' ''develop threat models: it helps to develop test cases or test plans'' and ''use manually reviewing the code'' are the most highlighted security practices for secure testing.
The deployment stage deals with release and change management. The software is installed in its real environment at this stage. It may appear easy, but integrating software into an existing environment can be difficult. Patches are developed to address the flaws, but the software remains vulnerable to a variety of security threats. In this stage, it is important to monitor responses to flaws and vulnerabilities of the system to check for newly evolved security threats. ''After identifying new security risks, the same should be included in the requirement stage for further security improvements in subsequent releases'' [66], [91]. Static analysis and peer review are two useful procedures for mitigating or minimizing newly discovered vulnerabilities [14]. Final security reviews and audits are performed during the secure deployment phase [14].
Similarly, we aimed to discover any security-related risks and their practices in the software maintenance phase of the SDLC. The maintenance team should keep track of new threats that the system encounters. We conclude that ''perform static analysis,'' ''perform final security review to find any remaining security flaws,'' ''perform security assessment and secure configuration,'' ''establish a plan to review to reduce the time and resources'' and ''analyze the overall state of the software'' are the most cited practices for the secure maintenance of software.
Based on the foregoing discussion, we conclude that securing software systems in the post-development phases is insufficient and that better ways and means of securing software systems in the early stages are urgently required. To incorporate security in the overall SDLC, we have done a detailed literature review and identified 145 security risks and 424 best practices that help software development organizations to manage the security in each phase of the SDLC.  The important activities to follow during the development lifecycle to build secure software were specified in this study. The specified actions are successfully incorporated into each phase of the SDLC, reducing effort, time, and budget while delivering secure software. This effort should aid software development companies in increasing the security level of their goods and improving their security performance. This will raise the developer's understanding of secure development methods as well.
In the future, we intend to develop a software security assurance model [19] for global software development (GSD) vendor organizations. This model will assist GSD vendors to determine their readiness for secure software development. We will develop the model using the results of this study, industrial survey, case study, supervisor inputs, and lessons learned from the existing studies ( [2], [5], [20], [51], [64], [100]). The model will generate several assessment reports, including a list of security risks/threats and their practices that GSD vendor organizations will use in each phase of the SDLC. In the future, we aim to answer the following research questions (RQs) to achieve the above-mentioned objectives: RQ1: According to the industrial survey, what are the security threats to the development of secure software products that GSD vendor organizations should avoid? RQ2: What are the mitigation practices that GSD vendor organizations can use to create secure software products, as identified during the industrial survey? RQ3: Is the proposed software security assurance model capable of assisting GSD vendor organizations in determining their readiness to develop secure software?

VI. THREATS TO VALIDITY
The study's validity is concerned with the reliability of its findings. The following are the limitations for this systematic literature review: • Construct Validity To broaden the scope of the study, we conducted a systematic search using a wide range of words in the sample. The study's keywords were included after thorough discussions and suggestions by the two authors to ensure the validity of the study and to include as much relevant literature as possible. Another threat to build validity was the use of digital libraries for the    studies. This threat was mitigated by identifying six digital libraries as key sources in such a domain.
• Internal Validity Internal validity threats have been reduced to the point where all interested readers are encouraged to view the data extracted from the papers of the studies displayed without restrictions.

• Conclusion Validity
To minimize the threats, each step of the data collection, extraction, and analysis was checked through a systematic process and periodic reviews by the participating authors. The rationale for this move was that the same method has been used in the literature for similar studies.
• External Validity External validity includes how much it is possible to generalize the outcomes of this study. To reduce this issue, the ratio of security risks and their practices have been included in this work. Table 16.