Software Development Initiatives to Identify and Mitigate Security Threats – Two Systematic Mapping Studies

Software Security and development experts have addressed the problem of building secure software systems. There are several processes and initiatives to achieve secure software systems. However, most of these lack empirical evidence of its application and impact in building secure software systems. Two systematic mapping studies (SM) have been conducted to cover the existent initiatives for identiﬁcation and mitigation of security threats. The SMs created were executed in two steps, ﬁrst in 2015 July


Introduction
Security is a topic of interest in Information Technologies nowadays, and is considered a Quality Attribute of a System by software engineering (ISO 25010).From this point of view, several initiatives, such as techniques, methodologies, methods and tools, have been proposed in order to add architectural and design decisions throughout the Software Development Life Cycle (SDLC) [1].Some of these initiatives

Related Work
We conducted several studies aiming to explore software design decisions for developing secure software systems: An experimental approach was initially taken to compare software security tactics and security design patterns [12,13], and several questions arose when trying to operationalize the identification and mitigation of security threats.These questions guided the authors to search for some security threat identification methods with demonstrated efficiency to be added to the experimental process, as a previous step to apply security tactics or patterns.In a first search based on a survey of techniques presented by Uzunov et al. [1] and a snowballing through its main references, we did not found methods with scientific evidence of its impact were found; this motivated both systematic mapping studies.We chose a well explained methodology for a first experimental approach to threats identification: Misuse Activities [14].The results of applying this identification method can be found in [13], which show statistically significant differences when performing a guided identification process versus an ad-hoc approach.We also have on going research initiatives to explore the importance of software artifacts over security decisions [15] and the structure of the Architectural Tactics for security decisions [16].
In terms of related initiatives of identifying security methodologies and techniques, other authors have described several methodologies, as mentioned in [1].Nonetheless, the study [17] which analyzed the security expert's opinion about the State-of-Practice of initiatives in the software development process, revealed that a lot of these initiatives do not surpass the State-of-Art even if they are considered good practices.The study established requirements for a methodology for building secure systems, including those proposals must consider the compatibility of the technique with the commercial environment of developers and their current skills.
A software engineering systematic mapping study (SM) is a defined method to build a classification scheme and a structure for a software engineering field of interest.When working with SM studies, it is difficult not to relate them to Systematic Literature Reviews (SR or SLR).The main difference between them lies, according to [9,10], in the definition of goals, breadth, validity issues and implications of the studies.Also, a SLR is more ambitious and rigorous than a SM.[18] presents a series of rigorous guidelines to make a systematic mapping study are presented, this directives constitute a well defined method for reviewing systematic mapping, with potential to match the rigor of a SLR.
The study in [19] presents an example of the application of SM to answer research questions similar to the motivations of this study: a SM is done with the goal of finding information about usability evaluation methods, that have been used by researchers to evaluate web applications and their relationship with the web development process.In [19], the main results are identification of most reported methods and research gaps aiming to the validations of these methods.The study in [20] presents a work in which a systematic revision is done with the goal of finding a trend in the definition of quality in the Model Driven Engineering.Main contribution of the study is the identification of a variety of multiple quality interpretations as consequence of the diversity in MDE compliance works.

Methodology/Research Design
The aim of this research is to identify the existent initiatives and experience reports for identification and mitigation of security threats during software development in order to build secure systems.An initiative is a framework, method, technique, proposal or methodology, among others.No comparison or evaluation is done between studies, so we could classify this work as a systematic mapping study (SM).In a SM we do not consider specific outcomes or experimental designs in the study, since the aim is searching for a broad overview of the research area as a whole [21]; which is why this study is not a systematic review.In order to design and operate the study, we followed the guidelines proposed by Petersen [9,10] and documented the protocol following Biolchini et al. definitions [22].
In contrast with other systematic mapping studies, where digital libraries are queried using different design engines such as IEEEXplore, ACM, Scopus and others, we decided to obtain our sources from Journals for two main reasons: (1) we were looking for results of long term research from papers describing studies that consolidate mature initiatives and (2) the heterogeneity of the search engines and limitation in the length of the search string.
Excluding sections 3.5 and 3.6, all the following sections of this paper should be considered for both studies, the mSM and bsSM.In section 3.8, we made some improvements for the inclusion/exclusion criteria (section 3.5) and search process (section 3.6) that was used on the bsSM study.

Research Questions
No systematic mapping studies or reviews were found when searching for initiatives for security threats identification and mitigation.Based on the main objective, we elaborated the following research questions for both systematic mapping studies: 1. What are the existing initiatives or methods of identifying security threats and attacks?
2. What threat identification methods are related to Security Tactics? 3. What other Mitigation Methodologies exist when developing Software, to conceive Secure Systems?
The first question is the main research question, while the second and third are secondary research questions.

Identification of Population and Intervention
We used the P.I.C.O.[23] structure to define the search string; that is to define a search string according to Population, Intervention, Comparison and Output.However, since our work is a systematic mapping study we follow the considerations presented in [9,10], that suggest only the use of Population and Intervention.A systematic mapping has a different kind of depth in contrast to a systematic literature review (SLR).
We performed several test executions of the search string, looking for evident outliers that could make the filtering stages unnecessary difficult, and we found that some words could extend our search to other fields of knowledge.We excluded the following terms in order to find papers related to our area of interest: • "System": It is a word that encompasses a lot of research areas.
• Use of "Service" or "System" for population: returns results from other areas, which are of no use to this work.
• Plural words were not used in the search string.
• Complete words were not used, we use the prefixes of them.

Construction of a Search String
Table 1: Keywords used in the Search String Term keywords obtained and its synonyms P ("software" OR "design" OR "engineer" OR "develop") I ("securit" OR "privacy" OR "integrity" OR "confidential" OR "availabil" OR "accountabil") AND ("threat" OR "risk" OR "attack" OR "requirement" OR "vulnerabil") AND ("identif" OR "mitig" OR "minimiz" OR "elicit" OR "enumer" OR "review" OR "assur") AND ("model" OR "metric" OR "guideline" OR "checklist" OR "template" OR "approach" OR "strateg" OR "method" OR "methodolog" OR "tool" OR "technique" OR "heuristic") String (P AND I) The initial keywords were identified by asking our experts, and synonyms were added to the keywords already found.The keywords that represent the core of the research are: "Threat", "Attack", "Identify" and "Mitigate".As we mentioned in section 3.2, we used the prefixes of a word as a consequence of our search procedure's definition.This is further discussed in section 3.6.

Table 2: Source Selection
All source papers were be available on the web, through open access or subscription based journals (those we could get access to).The language selected for the studies was English.The list of journals was proposed and reviewed by four researchers from different domains (software engineering, software security, distributed systems and software architecture).The Source Identification list is shown in Table 2.In section 4.2, the references of the selected papers from the mSM study were used as the source for the bsSM study.
3.5 Inclusion/Exclusion Criteria, only for the main systematic mapping study For the mSM we used table 3 to select or reject papers in the search procedure (section 3.6).The Study Type selected consists of articles related to secure software development, and articles selected by the Inclusion Criteria (Table 3).Studies with at least one Exclusion criterion were not selected.
Two reviewers evaluated each study.We used the following acceptance criteria in case the reviewers did not agree which studies should be accepted.

• If the two readers accept:
The study is included.
• If one reader accepts and one is in doubt: The study will be discussed in group.
• If the two readers excluded the study: The study is not included.
• All conflicts are reviewed by a third researcher.
To help resolve the disagreements, reviewers were asked to document the rationale for including/excluding each article.

Search Strategy/Procedure for the main systematic mapping study
Our search strategy was to explore software development and software security journals, in order to cover studies reporting long term research in initiatives and accumulated scientific evidence.1.We searched through studies from digital Journals.We selected the following information: Volume, Issue, URL (for the Journal-Volume), Title and Abstract.
2. All this information was saved in an Excel file, one file for each Journal.
3. From the Excel file we used a filter created by a Macro made in Visual Basic.

First Filter:
This was done by searching with the Search String (in the form of a Visual Basic macro) within the Abstract, and selecting papers that contained terms from the string.The Search String was created with the terms identifying the Population and Intervention.We manually evaluated the strength of the filter with one of the Journals used (IJSSE).
5. Second Filter: By reading again the title and abstract, we filtered against the Inclusion and Exclusion Criteria (Table 3).
6.If any irrelevant or duplicate study appeared, they were removed.
7. Third Filter: From the second filter, we did a quick scan of the articles and tried to categorize them in the following cases: empirical evidence/experimentation, case study, proposal or systematic review.In this high level revision of the accepted papers, we search within the Abstract, Introduction, Development of the work, Data obtained, Conclusions and other relevant sections of the paper.We considered that the abstract was not enough to judge a paper.
8. Fourth Filter: This was done by reading the complete text of the studies that were accepted by the third filtering.The fourth filtering is executed according to the Inclusion and Exclusion Criteria (Table 3).In this step, we tried to take some information that could help to speed up the Data Extraction.
3.7 Search Strategy/Procedure for obtaining studies for the backward snowballing systematic mapping The following process was used to identify relevant sources from the backwards snowballing process.
1.All the references from papers selected from the mSM study, were put together in a excel file.A researcher read the title of every reference in the file and filtered them against the following criteria: "security" AND "software engineering".
2. We checked and erased any duplicate.
3. The search procedure continued as stated in section 3.6, with the improvements of section 3.8.

Improvements for the search process in the backward snowballing systematic mapping study
To accommodate the differences in search types from the main and backward snowballing SMs search processes, the following changes were made to search and select the relevant sources.
• Three researchers were in charge of revising the studies in the search procedure, one of them was the main reviewer and checked the studies accepted by the other two researchers.If the main reviewer found rejected studies that should had been accepted, the papers were included in the next filter.The idea of this change is to regard the text used to filter the study.Since the abstract could be short, it is better to include a paper in the next filter until it can be read fully to be sure and decide whether to reject it or accept it.
• The recollection of the studies was done manually; therefore it was necessary to erase any duplicate studies in every step of the search.
• For the second filter, the studies were divided between two reviewers; they used the same inclusion and exclusion criteria to filter each study.The main reviewer, had to filter and compare all the studies against the second reviewer decision to include or reject studies.
• The third filter did not characterize the studies anymore, this was done on the forth filter while extracting the information; this way the search procedure was faster, without any loss of studies.
Figure 1 shows how we proceeded for both systematic mapping studies.The output obtained from the mSM was the input for the new search done in the bsSM.

Results from main systematic mapping (mSM)
The trial was done on 27-07-15 according to all the previous sections, the results obtained are presented in table 4. To obtain such results, we did the first phase filtering as explained in section 3.6.No duplicate articles were found.Table 5 summarizes the quantity of articles selected in each phase.In the first phase filtering, the identification of the papers was performed in each Excel of the Journal selected, a total  of 127 papers were identified by filtering its abstract with the Search String.In the second phase, 41 papers were filtered by the inclusion/exclusion criteria, and 0 were duplicated.After discussing between the reviewers, we decided to add 1 more article, so a total of 42 papers went to the third phase filtering.
The third filter was done by scanning 15 studies, which remained in the list after fully reading them and extracting the necessary information.In this new version of the work, we found that one paper obtained in this mSM study passed the filters without contributing anything to answer the research questions established.In this new version, instead of considering 15 papers we only took 14 papers; this is reflected on the data extraction section 4.3.1.

Results from backward snowballing systematic mapping study (bsSM)
To complement the identification and mitigate a possible threat of missing literature (see section 5), we performed a backwards snowballing process from the references of our mSM results (See 1).The initial set of sources are described in table 6.This trial started on 06-06-16 with the references obtained from the selected papers of the mSM study.Each reference was filtered by its title against the criteria "security" and "software engineering", which produced 308 results.After this filter, the search process began including the improvements to the search and selection criteria (inclusion and exclusion).The first filter accepts 38 papers whenever the search string was true for the abstract; the same Visual Basic macro for the mSM was used for this new systematic mapping.The second filter reduced the list to 31 and the third filter to 23.The last filter, the forth, needed the full reading of the paper, or at least until the extraction process of the data was sufficient.

Data Extraction for the main systematic mapping study.
The 14 papers selected by our mSM are described briefly: • CAIRIS [24]: Create security models that are automatically generated from specified, declarative data rather than via direct manipulation.
• Threat-Driven Modeling of Secure Software [7]: Use aspect-oriented extension to Predicate/Transition (PrT) nets, as a rigorous formalism for threat-driven modeling and verification.
• Aspect-Oriented Risk-Driven Development [25]: Create system functional models, using the UML 2.0 and perform a risk assessment of the system.
• SIREN (SImple REuse of software requiremeNts) [26]: In order to use the security profile properly, the Elicitation phase must start by studying the threats to the assets of the system.
• Misuse Case [3]: Identify critical assets in the system.Define security goals for each asset.Identify threats.Identify and analyze risks.Define security requirements for the threats to match risks and protection costs, preferably aided by a taxonomy of security requirements.
• SQUARE [27]: SQUARE consists of nine steps: agree on Definitions, identify security goals, develop artifacts to support security requirements definitions, perform risk assessment, select requirements elicitation technique, elicit the security requirements, categorize the security requirements, prioritize the security requirements, and inspect the security requirements.
• Secure Tropos and PriS [28]: The process consists of three iterative activities: organizational analysis, Security and Private Requirements Analysis, and selection of deployment model.
• ModelSec [29]: ModelSec proposes a generative architecture based on a chain of model transformations involving several security models at different levels of abstraction.
• Secure Tropos [30]: Supports development of IS (information systems) through four phases: early and late requirements, architectural and detailed design.Language application includes three major stages.
• SPEM, Secure Tropos and PriS [31]: Three main activities of the framework: the Security and Privacy Cataloguing, the Security and Privacy Analysis, and the Selection of Cloud Service Provider.The proposed framework consists of a language and a process that is focused on the requirements engineering stage.
• Attack Trees and Misuse Cases [32]: A pair of controlled experiments was performed.In each experiment, the participants used the two techniques individually on two different threat identification tasks.
• SEDAWA: Secure Engineering process for Data Warehouses [33]: The secure engineering process is proposed with the purpose of defining secure requirements and transforming them in order to develop secure Data Warehouses.
• Attack tres and Misuse case [34]: The participants were randomly assigned to one of four experiment groups.
• Methontology [35]: The life cycle activities of Methontology are composed of specification, conceptualization, formalization, implementation and maintenance activities.
4.3.2Data Extraction, for the backward snowballing systematic mapping study.
Using the mSM references as input, we obtained 16 papers in this new systematic mapping.We present a briefly description of each of them: • Extended Misuse Case [36]: Proposal to extend the format of a misuse case, to detect vulnerabilities and insider threats of a system when some of then can not be determined before design.
• Abuse case Based Assurance arguments [37]: Paper describes an extension to abuse-case based security requirements analysis.The approach is lightweight and is adaptable to the software development process.
• Threat-driven architectural design [38]: There is a large gap between obtaining threats and software design.To mitigate vulnerabilities they propose an approach to reduce and minimize the gap between analysis and architectural design.
• Reuse-based approach [39]: Provides a reuse-based methodology for misuse case analysis and subsequent specification of security requirements.
• Risk Management [40]: This guide provides a foundation for the development of an effective risk management program, containing both the definitions and the practical guidance necessary for assessing and mitigating risks identified within IT systems.
• Security Quality Requirements Engineering (SQUARE) Methodology [41]: SQUARE is presented as a consolidated and validated methodology for development of secure projects in the requirements engineering discipline.
• vulnerability-centric requirements engineering framework [42]: Proposes a framework for requirement engineering to model threats, security countermeasures, attacks.The initiative uses the i* framework modeling language.
• Security Requirements Hybrid Technique [43]: One hybrid technique based on misuse cases and attack trees.
• Misuse Case Maps with Misuse Cases and System Architecture Diagrams [44]: Gives empirical evidence for misuse case maps (combination of misuse case and maps for case use).The authors proposed a mixture of two important techniques in the requirement engineering that has succeeded.
• Misuse Case Maps [45]: Technique based on misuse case and misuse case maps to map requirements into an architecture.
• Anti-goal refinement and attack trees [46]: The framework integrates intentional obstacles (or antigoals) set up by attackers to break security goals.Attack trees are derived systematically through anti-goal refinement until leaf nodes are reached, and could possible be used by an attacker.
• Misuse case, attack trees and security activity models [47]: Attempt to make threat models more understandable and available to software developers, and thereby provide easy access to security knowledge that is needed to build more secure software systems.
• Secure Tropos and UMLSec [48]: Since all software systems operate within an environment with stakeholders or users, relevant laws and regulations might influence the security aspects of the system.
• Secure Tropos and Pris [49]: Integration of two software engineering methodologies, one from the security requirements domain, and other from the privacy domain.There is a need to analyze security and privacy separately but under a unified framework is of vital importance.
• Secure Tropos and UMLSec [50]: Integrates a goal-driven security requirements engineering (GDSRE) methodology (called Secure Tropos) with a model-based security engineering (MBSE) approach (called UMLSec) to create a structured methodology for secure software systems development.
• Mal activity diagrams [51]: Technique to identify security threats though activity diagrams.

Analysis
The results from both systematic mapping studies, gave us a list of 30 papers.Regarding the data obtained from both extractions, we found that proposals or examples were prevalent among other study types, followed by case studies.Only four papers, describing three techniques, had experimental data and analysis: Misuse Case Maps [44,45], Attack Trees [32] and Misuse Cases [34]. Figure 2 presents the distribution in the evidence types of the selected studies.We were interested in knowing how the papers approached the security of each proposal, whether it was thought as part of the development process or as a software component; within the 30 papers selected, security was considered part of the whole development process.In Figure 3 most of the papers supported more than one development activities in the SDLC, specially the requirement and design phases.Another fact we discovered is that some initiatives found in the selected papers, 11 of 30 papers, seemed to be used within an industrial environment (Figure 4).
Most interesting findings can be summarized in the following lines: • A Petri-based modeling approach of threats [7] showed the progressive and transversal-intrinsic nature of security threats.
• SQUARE [27] delivered a set of artifacts, threats and vulnerabilities, from which is possible to get an impact analysis, the probability of occurring and risk level.With this it was possible to categorize and prioritize security requirements, which allowed to analyze the security requirements of the software from the beginning.
• Paper [26] defined a repository of reusable generic requirements that minimized the time of developing in subsequent projects when using the practical methodology they proposed.SIREN extended the MAGERIT methodology, in accordance to the ISO 15408 or Common Criteria Framework, and based on IEEE standards.
• One approach worked to prove to the stakeholder that security was implemented in a project [24].They took into account the "usability" of the software as a part of the integration of stakeholders, to make the security more explicit to them.
• In [40] is argued that effective risk management must be totally integrated into the SDLC.Also, it clarified that a project using it would only succeed depending on who is in charge of assuring the risk management.• Misuse cases and use cases are best for capturing threats and attacks at the system boundary, but they are less suitable for capturing attacks that take place inside or outside the system [51].
• As can be seen in Figure 5, last decade concentrated most of the studies and experimental or empirical levels of evidence.Unfortunately, most of the studies were only proposals with examples of application, lacking evidence of its application or results.
• Secure Tropos focused on the elicitation and analysis of security requirements while PriS focused specifically on the incorporation of privacy requirements in the system design process [28].

Answers to Research Questions
In this section we present the answers to the Research Questions in Section 3.1.Table 7 shows the initiatives found in the 30 studies reviewed after the selection process; we collected papers using the same or similar initiative.Research questions are also answered in columns RQ1 (regarding the first research question about security threat identification initiatives), RQ2 (regarding the identification methods suitable to work with Architectural Tactics as mitigation method) and RQ3 (related to the third research question regarding other security threat mitigation methods).The Adoption column indicates if there is any evidence of adoption or empirical application of the initiative in an industrial setting, and the Evidence column indicates if there is quantitative evidence of the results of the technique.
In addition to the data shown in table 7, we characterized each initiative according to its abstraction level, from high level proposals, such as frameworks and methodologies, to more specific initiatives (methods and techniques).Also, we identified relationships between the proposals: we looked for initiatives that served as foundation or reference in other proposals, or high level initiatives that contained or use more specific ones.In figure 6 we depicted this dependency by a red arrow, and grouped initiatives in 12 sectors defined by level of scientific evidence of the initiatives and their context of application adoption (industrial, academic or theoretical).In addition, Figure 7 shows the initiatives grouped by abstraction level and goal (security threat identification, mitigation or both).These last maps showed that most initiatives have the highest level of abstraction and complexity (methodologies and frameworks), and aim for both identification and mitigation of security threats.Some comments for each research question are detailed bellow: 1. What are the existing initiatives for identifying security threats and attacks?ModelSec [53] x I10 Methontology [35] x I11 Abuse Case [37] x x I12 Threat-driven Architecture Design [38] x x x I13 Reuse-based approach [39] x x I14 Risk Management [40] x x I15 Vulnerability-centric Req.Eng.Framework [42] x Security Activity Models [47] x • According to the results obtained on this work, we can affirm that there are 17 security threat identification initiatives, as detailed in column RQ1 in Table 7.
• In spite of the results, there is no clear distinction for defining threats and attacks, every article read had at least one different conception of the Threat and Attack concepts.
• From the initiatives found, we understood that all of them take into account security threats analysis within the requirement discipline.
• There are only six initiatives that showed application in industrial environment, and only two of them showed experimentation evidence, as seen in Table 7.
• Finally, we can relate to the work of Whyte and Harrison [17], which states the lack of implemented initiatives within the industry, clearly reflected in the results above.
2. What threat identification initiatives are related to Security Tactics?With the search and extraction done, we could not find anything that explicitly supported Security Tactics.Initiatives marked as related to Tactics in Table 7, were identification techniques that operate at architectural level, which is the same abstraction level as Tactics.
3. What other Mitigation initiatives exist when developing Software, to conceive Secure Systems?
• As showed in table 7, 14 mitigation initiatives were found.Most of them were also identified as security threat identification initiatives, except for [35] and [47].
• In [25] they use AOM (Aspect-Oriented Modeling) methodology and techniques to specify generic security mitigation mechanism models.With a set of these security mechanisms, they performed a trade-off analysis between them to improve the security in the design.
• The view in the Risk analysis model in [24], compressed goal trees arising from risk responses, thereby making it easier to trace risks to mitigating responses, the requirements they treat, and the countermeasures they refine.
• Mitigation on web based attacks [35] was based in the complete understanding of the domain and context of information contents to be processed, and the ability to filter them on the basis of their effects on the target web application, with the help of policies; which is done through the process of reasoning and intelligent decision making.
• [7] used threat mitigation, security features or assurance techniques, for mitigating specific security threats.
• [34], [32], [3] mentioned that a use case can be a countermeasure for a misuse case, in which the first reduces the Misuse Cases chance of succeeding; they are called security use cases.• [30] used Risk treatment-related concepts or decisions, requirements and controls defined and implemented to mitigate the risks.A risk treatment is the treatment decision for a risk.

Threats to Validity/Limitations of this Study
Throughout the execution of the protocol, we took care to reduce the threats that could invalidate the results obtained.We presented the threats identified, and tried to explain what we did to mitigate them (or chose to accept).

Threat of missing Literature
In the beginning, for the mSM study, we were using web search engines to get the conference and journal papers, like IEEEXplore, ACM, Springer, and others.But we decided not to used them because every one of them used different forms to build a search string; which could lead to different kinds of search.Also, we found that some web search platform changed the maximum quantity of keywords, so this gave us a big limitation.We changed our focus to ensure a more stable population, allowing the replication of the study.Likewise, we focused in journals in order to cover studies reporting long term research in initiatives and accumulated scientific evidence.We decided to do a "manual" search within the Journals we knew and had the access to the material needed.To obtain all the articles within a Journal, we built a script1 based on Python to download all the information needed to identify an article within a Journal (URL, Volume, Title, Abstract, etc.).To obtain the selected articles, we used Excel macros to filter according to the abstract, with the keyword obtained by the Population and Intervention.To mitigate the possible threat within the procedure to extract papers from the Journals and the filtering within the excel list made, we • Executed the script at least everyday, for 2 weeks, to compare and see if the results obtained had not changed.
• Executed the macro, with our keywords every time we got a new list from the execution of the script.
• Observed that there were no changes.
We may have filtered out some studies when selecting papers in a time interval.We mitigated this by looking the earliest date in which software development processes (an in consequence all sort of initiatives too) started to become popular.UML and RUP were created on the nineties, but started to become popular in the early 2000.For this special issue version, the bsSM study was done to mitigate the above threat by inclusion of the backward snowballing process.These new systematic mapping study had as input the references of each study found in the mSM, with 794 new sources that where analyzed and filtered according to section 3.7 and 3.8.

Threat of Selection Bias
The selection of papers during both systematic mapping studies procedure was done by three researchers; two of them performed the selection process by following our guideline in section 3.6.Both researchers applied the inclusion and exclusion criteria, compared results and resolved conflicts following the definitions stated in the research protocol.A third person was in charge of managing the selection and intervening whenever a resolution was difficult to make by the other two.This general guideline was maintained during the revision of this work for the special issue.The same inclusion/exclusion criteria were followed by the same three researchers, therefore there was no new confounding factor in the selection of relevant sources from either the included journals, nor from the snowballing process.This is important, to warranty that the sources can be analyzed together as a set, as we have done so in this version for the special issue.
We need to add that in this special issue, we revised our selected papers from both systematic mapping studies and found one mistake: one study from the mSM was found to be of no use.This particular study, passed all the filters but it did not had any information to answer the research questions; therefore it was of no use to the bsSM since no reference was selected from it.In this new version of the article, we have deleted that study and fortunately our results were not influenced by this extraction.

Threat of Inaccuracy of data extraction
This threat was mitigated by the iterative nature of the execution of the protocol, the peer review applied with the 2 extractors and a third reviewer in case of conflicts.

Conclusions and Discussion
A systematic mapping study was planned and executed, in two iterations, in order to identify initiatives for security threats identification and mitigation.
We covered 11 main software development and security journals, and selected sources published between years 2000 and 2015 (July).From a total of 10.838 articles, 127 were analyzed following the research protocol.We complemented our review by performing a backwards snowballing mapping, applying our selection plan to 794 additional studies.Finally, 30 relevant studies were selected for analysis (14 from the mSM, and 16 from the bsSM).Of these selected studies, 19 different initiatives were found.Among them, 17 supported security threats identification, and 14 supported the mitigation of threats, with the remarkable observation that only 3 of them presented experimental evidence: Misuse Case Maps [44,45], Attack Trees [32] and Misuse Cases [34].From this experimental approaches, two studies reported a comparison of Misuse Case and Attack Trees, as replications of the same experiment, in academic and industrial settings [34,32].The studies concluded that Attacks Trees have a better usability and identify more security threats than Misuses Cases, although the threats identified by both were different and complementary.This finding guides us to think that there is a research gap on the comparison of threat identification techniques, in order to assess their impact and explore their complementary nature.
No security threat identification methods explicitly supporting Architectural Tactics were found, but two initiatives [38,44] operated at an architectural level.From the 19 initiatives, 6 showed evidence of application in industrial settings.
All the identified initiatives defined security in at least one phase and at least 8 initiatives, in two phases of software development lifecycle.Although there are many forms in which security could be introduced in the software development, the most repeated form was in the search of requirements or security requirements, and at least eight of them seemed to support other development activities.However, proposals were not clear in how they integrate the rest of the SDLC.Proposal [33], elicited security requirements based on business and organizational goals, in contrast with the majority who elicited from scenario based requirement development initiatives.This guides us to think that the scenario based requirements analysis is more suitable for security analysis, but further research is required to validate this idea.Elicitation of threats does not always involve a whole methodology, for example Misuse Case and Attack Trees are techniques or methods contextualized in the requirement analysis activities, but not involved in a whole development methodology.
Studies have shown that there is no common agreement with some word definition or language in the Security Community [25], [28], [34], [31], [30], [35], [3].Some studies presented security domain models to define the domain in which a threat could be related to others entities, others just used a definition already used by others, either way, we realized that the definition of the term "threat" depends on the initiative and it is not a global concept, as some with poor experience in security could have thought.For example, some would define the term "threat" as a way to use something in a way it is not supposed to; others may think that a threat is a temporal sequence of attack steps; there are those who could not consider this construct at all and just use the term "attack".This suggest the necessity of a common conceptual model focused on identification and mitigation of security threats to conform a unified vocabulary for future research in technologies for building secure software systems.
As can be inferred from references of the techniques in table 7, five techniques were studied in more than one article: Secure Tropos with Agents, SQUARE, Attack Trees, Misuse Cases and Misuse Case Maps.Studies for Secure Tropos with Agents, and Misuse Case Maps seemed to be a continuous endeavor of the same research groups, while SQUARE, Attack Trees and Misuse Cases are initiatives continued by different researchers.Remarkably, the research team of Karpati et al. studied several secure software development initiatives in a systematic and evidence based contribution.
The backwards snowballing mapping allowed us to trace the evolution of the initiatives from merely theoretical proposals to initiatives experimentally tested in industrial settings.As figure 6 depicts, Misuse Cases and Attack Trees are the most well founded initiatives: they were based in several theoretical proposals, showed the higher level of scientific evidence (experimental tests) and were operated in industrial contexts.A remarkably aspect is that the initiatives with experimental evidence of their results were classified as techniques, thus, prescribe specific tasks, so they are highly operationalizable, and provide short term results.Further studies could allow us to confirm that broader and long term initiatives such as methodologies could not be validated through an experimental approach.
Finally, in light of the results of this SM, and consistently with our original concerns -the lack of scientific evidence in initiatives presented in [1] and the fulfillment of the recommendations described in [17] -we have identified a research gap in the formalization of the application and validation of secure software development initiatives.

Figure 1 :
Figure 1: Process for both systematic mapping studies.

Figure 5 :
Figure 5: Evidence types and time distribution of the selected studies.

Figure 6 :Figure 7 :
Figure 6: Relationship between initiatives and how they are classified (Adoption versus Type of Proposal)

Table 5 :
Amount of papers selected in each phase of the mSM study

Table 6 :
Amount of number of papers selected in each phase of the bsSM

Table 7 :
Answers to research questions summary