Figure 6 - uploaded by Anas M.R. Alsobeh
Content may be subject to copyright.
![Secure software development process model of Microsoft [10]](profile/Anas-Alsobeh/publication/327338379/figure/fig5/AS:665610530873354@1535705325722/Secure-software-development-process-model-of-Microsoft-10.png)
Source publication
![Figure 5: Classical software development life cycle of Microsoft [6]](profile/Anas-Alsobeh/publication/327338379/figure/fig4/AS:665610530852865@1535705325694/Classical-software-development-life-cycle-of-Microsoft-6_Q320.jpg)
![Figure 6: Secure software development process model of Microsoft [10]](profile/Anas-Alsobeh/publication/327338379/figure/fig5/AS:665610530873354@1535705325722/Secure-software-development-process-model-of-Microsoft-10_Q320.jpg)
Recently, the need to improve the security of software has become a key issue for developers. The security function needs to be incorporated into the software development process at the requirement, analysis, design, and implementation stages as doing so may help to smooth integration and to protect systems from attack. Security affects all aspects...
Context in source publication
Context 1
... of the first initiatives in relation to the SSDLC was the MSSDLC proposed by Microsoft, which works in line with the phases of a classic SDLC. Microsoft proposed some of the best security practices to fit with each stage of its classical SDLC, which is shown in Figure 5 [6]. For the training stage, which is the initial stage of the classic SDLC at the company, Microsoft proposed some core security training to secure the other upcoming stages and focused particularly on the issue of privacy. At the stage of Requirements, Microsoft proposed quality gates and privacy risk assessment to determine on the privacy impact rating. The same thing goes to the other stages, for the design phase, Microsoft proposed quite a few security practices such as threat modelling and attach surface analysis. As for implementation, they suggested using approved tools, deprecating unsafe functions and performing static analysis. For all stages, best practices were applied to ensure the highest possible levels of security. Figure 6provides a summary of the main security activities Microsoft deployed for each SDLC stage [10]. ...
Citations
... The paper reviews prior art that presents the proposed integration and validates the effectiveness of AOP-based blockchain model checking through a case study. The goal is to advance research at the intersection of formal methods, distributed systems, and AO software engineering [18] [52][53][54][55][56][57][58]. As blockchain technology continues to permeate various sectors, this research hopes to shed light on this area. ...
... This aspect deals with model checking, hypothesis testing, and context data measurement. A model checker takes a model and a property as inputs, and outputs either a claim that the property is true or a counterexample falsifying the property [53], [54]. ...
Blockchain systems are lauded for their security and reliability. Security is a cornerstone, as they employ cryptographic techniques to ensure the immutability of data, making it extremely resistant to tampering. With decentralized networks, they also reduce the risk of a single point of failure, enhancing reliability. Model checking plays a vital role in ensuring the security and reliability of blockchain systems. However, traditional model-checking approaches face challenges in handling the inherent dynamism exhibited in blockchain systems. To overcome this challenge, Aspect-Oriented programming (AOP) offers capabilities to enhance blockchain model checking through the modularization of cross-cutting concerns, enabling traceability and monitoring, facilitating dynamic instrumentation, and supporting fine-grained property specifications. The aim of this research is to enable more effective and efficient verification of dynamic behaviors in blockchain systems compared to conventional model-checking techniques using AOP. As a result, this research introduces
BlockASP
, a novel blockchain model verification method that leverages AOP to analyze and monitor dynamic behavior of the blockchain system.
BlockASP
integrates the benefits of aspect-orientation and model checking into the blockchain architecture to strengthen security and reliability. This research has examined prior arts that are related to blockchain modeling using Object-oriented (OO) and those that are using AOP. Our research has proposed and discussed the
BlockASP
technique, the research provided a case study to demonstrate the validity and superiority in facilitating the monitoring of dynamic blockchain behavior using AOP compared to traditional approaches such as Model-Driven Architecture (MDA).
... However, the majority of the tools models used have their challenges and flaws, ranging from the inability to update the risk factors, to the failure to recognize the risk factors connected to software product issues [28,29]. Hence, an intelligent system is required that will combine risk management processes into all stages of the SDLC in the production of software products [30]. Each phase of the SDLC has a unique set of risks attached to it [31-33], but there no or little tools or models that can help developers to carry out risk management tasks across the SDLC process' phases [34,35]. ...
In the field of software development, the efficient prioritizing of software risks was essential and play significant roles. However, finding a viable solution to this issue is a difficult challenge. The software developers have to adhere strictly to risk management practice because each phase of SDLC is faced with its individual type of risk rather than considering it as a general risk. Therefore, this study proposes an adaptive neuro-fuzzy inference system (ANFIS) for selection of appropriate risk factors in each stages of software development process. Existing studies viewed the SDLC’s Security risk assessment (SRA) as a single integrated process that did not offer a thorough SRA at each stage of the SDLC process, which resulted in unsecure software development. Hence, this study identify and validate the risk factors needed for assessing security risk at each phase of SDLC. For each phase, an SRA model based on an ANFIS was suggested, using the identified risk factors as inputs. For the logical representation of the fuzzification as an input and output variables of the SRA risk factors for the ANFIS-based model employing the triangular membership functions. The proposed model utilized two triangular membership functions to represent each risk factor’s label, while four membership functions were used to represent the labels of the target SRA value. Software developers chose the SRA risk factors that were pertinent in their situation from the proposed taxonomy for each level of the SDLC process as revealed by the results. As revealed from the study’s findings, knowledge of the identified risk factors may be valuable for evaluating the security risk throughout the SDLC process.
