Common Vulnerability Scoring System (CVSS) is a standard method for quantifying the severity of software vulnerabilities. Security engineers can identify the underlying causes of vulnerabilities and develop countermeasures based on CVSS base vector and their related scores. The CVSS base vector is a set of metrics used to calculate the severity score of a vulnerability based on its intrinsic characteristics, such as “Attack Vector (AV)” and “Privilege Required (PR)‘. Security experts often take a few weeks to manually determine the CVSS base vector of a new vulnerability report. Consequently, the CVSS base vector is usually unknown for a period after the report is released, and thus delaying vulnerability countermeasures. Therefore, several methods for predicting CVSS base vector have been proposed. This paper compares the performance among methods that use BERT, multinomial logistic regression, or linear regression for automatically predicting CVSS base vector. The comparison results suggested that both BERT and MLR perform better than LR, with distinct advantages. BERT excels in understanding context, making it suitable for predicting general CVSS base vector, while MLR is effective for targeting specific attributes or severity levels. Consequently, these methods hold promise in aiding security engineers to promptly address vulnerabilities.

In this paper, we propose a method to efficiently ensure security in the DevOps lifecycle through operations and development. To ensure sufficient security in DevOps, it is essential to perform sufficient threat analysis during development. However, threat analysis is generally a heavy task and difficult to apply to agile processes. In addition, existing technologies are not sufficient for security feedback from Dev to Ops and Ops to Dev, which are important elements of DevOps. In this paper, we propose a method for detecting attacks using anomaly detection from operation logs, and extracting vulnerabilities and candidate countermeasures using information such as CAPEC and CWE. Furthermore, we propose a method to determine the excess or deficiency of the countermeasure by comparing it with the Attack-Defense Trees created in the previous development. By applying our proposal to an actual development case, we confirm that the proposed method works effectively.

To examine requirements and design of a system, using graphical models such as UML is one of the effective ways because it helps developers to understand the system and activities using the system. Usually, more than two types of notations are used to represent a system. At the age of digital transformation, relationships among several different systems should be also discussed and they are of course represented in several different notations. To improve the development and the analysis of several systems using such several notations, traceability among elements in the different notations should be managed, but most techniques focus on the traceability among a single project. In this paper, we present a tool to manage traceability on several different models. The tool is developed as a plugin of an existing graphical modeling tool called Astah. Astah enables us to describe UML models as well as mind maps, data flow diagrams, flow charts and so on. To evaluate our tool, we performed a method to elicit requirements of several different systems together by using the tool. We confirmed our tool was helpful to perform the method, but some additional functions would improve the performance more than now. The additional functions are as follows: tracing links transitively, annotating each link to clarify its type and recording an end of a link while the end is removed from a model.

Due to the widespread proliferation of today's Internet of Things (IoT), a system designer needs the IoT system and software design patterns to assist in designing scalable and replicable solutions. Patterns are encapsulations of reusable common problems and solutions under specific contexts. Many IoT patterns have been published, such as IoT design patterns and IoT architecture patterns to document the successes (and failures) in IoT systems and software development. However, because these patterns are not well classified, their adoption does not live up to their potential. To understand the reasons, we conducted a systematic literature review. From the 32 identified papers, 143 IoT architecture and design patterns were extracted. We analyzed these patterns according to several characteristics and outlined directions for improvements when publishing and adopting IoT patterns. Of the extracted patterns, 57% are non-IoT patterns, suggesting that IoT systems and software are often designed via conventional architecture and design patterns that are not specific to IoT design. Although most IoT design patterns are applicable to any domain, IoT architecture patterns tend to be domain specific, implying that the unique nature of IoT adoption in specific domains appears at the architecture level. As more domains adopt IoT, the number of domain-specific IoT design patterns should increase. In terms of quality attributes, many IoT patterns address compatibility, security, and maintainability.

Huge amount of techniques for creating, maintaining and/or recovering traceability among software development artifacts have been proposed. It is thus not easy for a potential user of such techniques to choose a technique suitable for his/her project because too many techniques exist and projects are different from each other. In this paper, we proposed a model for characterizing a traceability technique with respect to its users. The model can become a meta-model of the knowledge base for such users. The model is designed on the basis of the contents of existing technical papers so that we can easily describe model instances on the basis of technical papers. The model is represented in a feature model, and it has four mandatory features: source, destination, consequence and process. The user can at least understand a technique is unsuitable for him/her by referring such features. If a technique estimates the traceability relationships, the instance of its feature model may contain the quality metrics of its estimation such as precision and recall. It has also several optional features: assumptions, preprocess and tool. Although we sometimes cannot obtain such optional features from technical papers, they are so helpful for a user to decide a technique suitable for him/her. On the basis of the feature model, we described model instances of several techniques in technical papers. We also examined and discussed who the suitable user for each technique is.

With the growing number of services on the Internet, the need for secure software development has increased. It is required for secure software development to consider security in the whole development life cycle. It is indispensable for secure software development to use various types of security knowledge. This study deals with security requirement analysis. Existing security requirements modeling systems do not provide a function to create an artifact while referring to security knowledge in an integrated manner. In this paper, the authors develop a modeling support system for a misuse case diagram that enables the association of knowledge with elements that constitute the diagram. The results of an experiment using the system show the system's usefulness in both the integration of the knowledge base with the artifact creation environment and the association of the knowledge with the elements of the diagram.

Traceability is important knowledge for improving the artifacts of software and systems and processes related to them. Even in a single system, various kinds of artifacts exist. Various kinds of processes also exist, and each of them relates to different kinds of artifacts. Traceability over them has thus large diversity. In addition, developers in each process have different types of purposes to improve their artifacts and process. Research results in traceability have to be categorized and analyzed so that such a developer can choose one of them to achieve his/her purposes. In this paper, we report on the results of Systematic Literature Review (SLR) related to software and systems traceability. Our SLR is preliminary one because we only analyzed articles in ACM digital library and IEEE computer society digital library. We found several interesting trends in traceability research. For example, researches related to creating or maintaining traceability are larger than those related to using it or thinking its strategy. Various kinds of traceability purposes are addressed or assumed in many researches, but some researches do not specify purposes. Purposes related to changes and updates are dominant.

We propose a metamodel for handling security and privacy in cloud service development and operation. The metamodel is expected to be utilized for building a knowledge base to accumulate, classify and reuse existing cloud security and privacy patterns and practices in a consistent and uniform way. Moreover the metamodel and knowledge base are expected to be utilized for designing and maintaining architectures for cloud service systems incorporating security and privacy.

An information system can store personal information of its primary users such as shopping histories, and some third party wants or happens to know such information. Because the system usually provides its privacy policy and its users have to give their consent to it, they sometimes have to partially give up the protection of their privacy. On the other hand, a chance of a third party to know such information is too limited if the policy is too defensive. We proposed a method to explore trade-offs between protection of such information and access permissions for a third party, and exemplified it. In this method, operation logs of a system are focused. The structure of each log is then modelled for analysing what kinds of information can be accessed by a third party. Access limitations of each third party are explored so as to balance the protection of privacy information against access right of third parties.

Because software developers are not necessarily security experts, identifying potential threats and vulnerabilities in the early stage of the development process (e.g., the requirement- or design-phase) is insufficient. Even if these issues are addressed at an early stage, it does not guarantee that the final software product actually satisfies security requirements. To realize secure designs, we propose extended security patterns, which include requirement-and design-level patterns as well as a new model testing process. Our approach is implemented in a tool called TESEM (Test Driven Secure Modeling Tool), which supports pattern applications by creating a script to execute model testing automatically. During an early development stage, the developer specifies threats and vulnerabilities in the target system, and then TESEM verifies whether the security patterns are properly applied and assesses whether these vulnerabilities are resolved.

In recent years, importance on software security technologies has been recognized and various types of technologies have been developed. On the other hand, in spite of recognition of necessity of providing cases that deal with full life cycle for secure software development, only few are reported. This paper describes a case-based management system (CBMS) that consists of an artifact management system and a knowledge-based management system (KBMS) to manage cases for secure software development. The former manages the artifacts created in secure software life cycle. The latter manages software security knowledge. The case-based management system also manages association between artifacts and software security knowledge and supports both visualization among software security knowledge and between artifacts and software security knowledge. We conducted an experiment to evaluate the system. We describe the effectiveness and future work of the system.

Although security patterns contain security expert knowledge to support software developers, these patterns may be inappropriately applied because most developers are not security specialists, leading to threats and vulnerabilities. Here we propose a validation method for security design patterns in the implementation phase of software development. Our method creates a test template from a security design pattern, which consists of the "aspect test template" to observe the internal processing and the "test case template". Providing design information creates a test from the test template. Because a test template is recyclable, it can create easily a test, which can validate the security design patterns. As a case study, we applied our method to a web system. The result shows that our method can test repetition in the early stage of implementation, verify pattern applications, and assess whether vulnerabilities are resolved.

Software developers are not necessarily security specialists, security patterns provide developers with the knowledge of security specialists. Although security patterns are reusable and include security knowledge, it is possible to inappropriately apply a security pattern or that a properly applied pattern does not mitigate threats and vulnerabilities. Herein we propose a method to validate security pattern applications. Our method provides extended security patterns, which include requirement- and design-level patterns as well as a new model testing process using these patterns. Developers specify the threats and vulnerabilities in the target system during an early stage of development, and then our method validates whether the security patterns are properly applied and assesses whether these vulnerabilities are resolved.

Unlike functional implementations, it is difficult to analyze the impact software enhancements on security. One of the difficulties is identifying the range of effects by new security threats, and the other is developing proper countermeasures. This paper proposes an analysis process that uses two kinds of security pattern: security requirements patterns (SRP) for identifying threats and security design patterns (SDP) for identifying countermeasures at an action class level. With these two patterns and the conventional traceability methodology, developers can estimate and compare the amounts of modifications needed by multiple security countermeasures.

Although aspect-oriented software development is regarded as a suitable way to build non-functional requirements such as security concerns, there are few researches for identifying security aspects in early development stages. This paper presents an approach for identifying security aspects and pointcuts in a requirement analysis stage with extending misuse cases.

It is difficult to apply existing software development methods to security concerns. Using software for security testing purposes, in particular, is hard to do. The fact that there is a restriction on the implementation of software affects the ease with which security can be tested. In this paper we propose a decision process of coding conventions for security, mindful of testing security. Then, we apply our method to preventing injection attacks on Web application programs, and establish some coding conventions that can be used against injection attacks and cross site scripting. We also discuss security frameworks, which are also useful as conventions

Proposes a new method for updating information in distributed collaborative work. The effective performance of collaborative work distributed among several locations requires that information be replicated and freely updated in each distributed server. This is difficult to achieve with existing information-sharing methods such as the WWW and workflow. Our optimistic lock control method enables the direct updating of replicated information in any server while maintaining consistency among all the servers. A server failure is not critical to other servers because there is no master server. This method differs from the traditional master-slave method in which updates are performed in a specific master server. This paper also addresses the dynamic deployment of a new server. Our method is being used on a trial basis for an international software development project between Japan and India.

We describe a new reverse engineering technology to generate a narrative specification used by real-world maintainers which facilitates the understanding of business procedures in existing COBOL programs. It defines business process logic and how to recognize it in a program. It also defines how to generate narrative specifications based on this process logic. We also discuss a specification-based maintenance support system; proof-correction marking and parallel scrolling. Evaluations were made in collaboration with more than six software maintainers by inspecting 500 generated specifications from real programs of financial firms. The evaluation suggests that generated specifications are helpful in clarifying the program in terms of business procedures and in locating statements to be changed during software maintenance.