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.

For effective vulnerability management, vulnerability and attack information must be collected quickly and efficiently. A security knowledge repository can collect such information. The Common Vulnerabilities and Exposures (CVE) provides known vulnerabilities of products, while the Common Attack Pattern Enumeration and Classification (CAPEC) stores attack patterns, which are descriptions of common attributes and approaches employed by adversaries to exploit known weaknesses. Due to the fact that the information in these two repositories are not linked, identifying related CAPEC attack information from CVE vulnerability information is challenging. Currently, the related CAPEC-ID can be traced from the CVE-ID using Common Weakness Enumeration (CWE) in some but not all cases. Here, we propose a method to automatically trace the related CAPEC-IDs from CVE-ID using three similarity measures: TF–IDF, Universal Sentence Encoder (USE), and Sentence-BERT (SBERT). We prepared and used 58 CVE-IDs as test input data. Then, we tested whether we could trace CAPEC-IDs related to each of the 58 CVE-IDs. Additionally, we experimentally confirm that TF–IDF is the best similarity measure, as it traced 48 of the 58 CVE-IDs to the related CAPEC-ID.

Static analysis tools such as bug pattern tools are useful to detect bugs early in software development. However, existing tools sometimes yield so many warnings that developers tend to ignore such warnings. To deal with this problem, we propose a gamified tool for motivating developers to remove such warnings. Our tool employs the gamification technique that calculates points by counting removed warnings with respect to each developer and each team. The points give developers feedback and urge them to compete with each other. We confirmed that developers removed about 150% warnings with our tool in comparison with the case where they did not use our tool through an experiment.