SBOM-Enhanced Threat Correlation for Attack Detection in IoT Networks

1. Introduction

The rapid growth of Internet of Things (IoT) devices has significantly improved automation and connectivity in smart environments, critical infrastructure, industrial systems and healthcare [1]. However, serious security flaws have also been brought about by its stretch [2]. IoT devices are popular targets for cyberattacks because they often have constrained processing power, out-of-date software, and uneven security procedures. Attackers might take advantage of unreported vulnerabilities since traditional security techniques, such signature-based intrusion detection systems and periodic vulnerability screening, often fail to provide real-time insight into software dependencies and known vulnerabilities (CVEs).

1.1. Background

In order to enhance security status for IoT devices, this paper discusses the application of Software Bill of Materials (SBOM)[3][4] and its ability to detect known CVEs and components susceptible to attacks in advance or while being attacked. This work provides an automated detection mechanism that improves situational awareness and responses to attacks via SBOM creation, vulnerability assessment, and real-time network monitoring in the Internet of Things environment. The SBOM is now crucial to mitigating vulnerabilities and assuring software integrity because of growing concern over cyber security and legal liability. This is why we decided to concentrate our efforts on "Detecting and Identifying Targeted IoT Devices Under Attack Using SBOM-Enhanced [5]."

The security risks associated with Internet of Things (IoT) devices are well documented, particularly because many devices operate with constrained computing resources, limited security capabilities, and outdated or vulnerable software components [6,7]. Vulnerabilities arising from software dependencies can expose IoT devices to targeted attacks, while conventional vulnerability assessment approaches may not provide continuous visibility into the components deployed on individual devices [8,9].

Traditional network-based intrusion detection systems primarily analyse traffic patterns, signatures, or anomalies to identify potentially malicious activity. However, they generally have limited knowledge of the software components and known vulnerabilities present on the target device. As a result, network observations may lack the device-specific vulnerability context needed to determine whether a detected attack is relevant to the targeted device. An SBOM can provide this context by maintaining a structured inventory of the software components deployed on an IoT device and their associated vulnerabilities.

1.2. Existing Approaches and Research Gap

The literature review is divided into three key categories, each of which focuses on a different aspect of Internet of Things security and the role of Software Bill of Materials (SBOM) in bolstering security measures.

1.2.1. SBOM (Software Bill of Materials) in IoT Security

For the purpose of protecting IoT terminal devices, an intelligent security detection and response system based on SBOM was proposed [9]. With an emphasis on Apache Log4j and SolarWind, this clever detection method employs SBOM to fix vulnerabilities in open-source IoT applications. The system lacks real-world testing and scalability studies, although it uses Bloom filters and component dependency trees to assess vulnerabilities.

Another study examines 7,876 open-source projects using metadata-based SBOM generating tools and identifies problems such dependency capture failures. Although the paper only examines four tools, it offers best practices for SBOM development and presents a new parser confusion attack. [10]. Vulnerabilities in the IT supply chain, namely third-party service risks, with reference to the SolarWind and Kaseya cyberattacks [11,12]. The study recommends SBOMs as a risk-reduction strategy, however it offers no practical solutions for real-time SBOM updates in cloud services.

Using SBOMs connected into CI/CD pipelines, an automated vulnerability analysis has been demonstrated to be successful for C-Sharp applications. However, the study’s limited breadth and inability to be applied to real-world systems limit its generalisability [8]. The function of SBOMs in industrial IoT device security, including their integration with VEX for vulnerability assessment and the National Vulnerability Database (NVD) [13]. This study assumes perfect cooperation between manufacturers and ignores multi-vendor environments.

Taylor et al. proposed an integrated IoT security architecture combining SBOMs, runtime monitoring, anomaly detection, risk modelling, and secure updates, but its broad lifecycle focus does not specifically correlate attacks with vulnerable components on targeted devices [14]. Tolay proposed an SBOM-based IoT firmware vulnerability-triage pipeline, but focused on static vulnerability identification and prioritization rather than runtime attack correlation [15,16]. In another study authors address the reliability of SBOM-based vulnerability analysis but do not establish whether a vulnerable component is actually being targeted during runtime network activity [17].

1.2.2. Security Architectures and Protocols in IoT

IoT application-layer security protocols that are lightweight and concentrate on key management, encryption, and authentication[18]. Although these protocols are efficient, their scalability and adaptability need to be improved in order to handle new threats. To counteract deauthentication threats in IoT, the BBMDA framework was developed utilising blockchain and ECDSA[19,20]. The architecture requires more study for practical IoT applications and worries about handling sensitive data, despite encouraging outcomes.

A cryptography-based safe routing protocol for smart healthcare IoT systems is proposed by authors in another study, demonstrating enhanced attack detection and data privacy[21,22,23] . However, more research is required to fully understand scalability and practical application in big IoT networks. A 90% communication success rate was attained using a modular security strategy that combined GPS and RF fingerprinting for Internet of Things devices [24]. However, its real-time performance is limited by issues with scalability and reaction time. A framework for attribute-based encryption was presented [25] to improve the performance of IoT devices by delegating encryption tasks to proxy servers. The scheme’s viability in big IoT systems is limited by its reliance on trusted proxy servers and scalability problems.

An architecture for cross-layer IoT that can achieve an optimum trade-off between security and energy consumption has been proposed [26]. Many benefits with regard to security and energy have been observed in this work, but further optimisation is required [27,28]. The role of AI and power sources to improve IoT resilience through cross-layer security and energy-efficient IoT designs has been discussed in detail in a comprehensive survey [7]. The poll does, however, indicate that real-world applications and scalability in massive IoT networks continue to be difficult. AI’s involvement in enhancing IoT network security and efficiency is the subject of another study that investigates AIoT integration[29]. The study concentrates on scalability problems across diverse IoT systems and lacks specific real-world examples. For IoT security, twenty-one critical success factors (CSFs) were found and divided into four categories[30]. However, the study’s small sample size limits its adaptability, and the lack of concrete case studies limits practical application.

A review of the function of device identification and Manufacturer Usage Description (MUD) in IoT security was conducted, and MUD was suggested as a means of mitigating threats[31]. Nevertheless, the integration difficulties of MUD in extensive IoT contexts are not covered in the paper. A second study of IoT security in smart banking was carried out with an emphasis on network security and monitoring[32]. The necessity of robust security measures for sustainable agricultural systems was emphasised while discussing various risks and offering solutions for safe IoT deployments. Kumar et al. identifies IoT device types from network-flow characteristics but does not use SBOM information or CVE context to determine whether the identified device contains the component associated with an observed attack[33]. Another study strongly addresses lightweight device identification, but identification is based on network/device features rather than software-component and vulnerability information obtained from an SBOM[34].

1.2.3. Emerging Technologies and Applications in IoT Security

Suricata is an open-source intrusion detection engine that supports many protocols and alerting techniques for efficient Internet of Things security and is optimised for high-performance multi-threading [35]. For outcome analysis, this is a nice comparable work. Integrating IoT devices with blockchain to improve supply chain security and efficiency provided a proof of concept [36]. Even though it relies on steady communication, low-power IoT platforms present scalability issues.

A review of security concerns in IoT ecosystems for smart farming was conducted with an emphasis on cloud, fog, and edge computing systems[37]. The study emphasises the necessity of scalable and lightweight solutions while highlighting the significance of common protocols for improved IoT security. Another study investigates the application of deep learning and machine learning algorithms for IoT intrusion detection, with frameworks that achieve high threat detection accuracy but need to be improved for noise-prone environments and imbalanced datasets [38]. Jain et al., combines device identification and attack detection, but relies primarily on AI/network characteristics and does not incorporate SBOM-derived software vulnerability context[39]. Another research work, provides strong attack-detection and performance evaluation, but treats network traffic primarily as the detection source and does not establish whether the targeted device contains the software vulnerability associated with the detected attack[40,41].

1.2.4. Literature Review Comparison Table

This section compares closely related research work, relevant to the proposed research work. It highlights main approach, primary focus, limitations to identify the research gap and finally proposed work in the last row based on the research gap, as shown in Table-Table 1.

Recent studies have addressed SBOM-based vulnerability management, network-based IoT device identification, and machine-learning-based attack detection. SBOM-oriented approaches provide visibility into software components and their known vulnerabilities, while network-based methods identify devices or detect malicious traffic from runtime behaviour. More recent architectures have also begun to integrate SBOMs with runtime monitoring and contextual risk assessment. However, limited attention has been given to correlating device-specific SBOM vulnerability information with observed network activity to determine whether an attack is targeting a device that contains the associated vulnerable component. This study proposes a unique SBOM enhanced real-time monitoring framework that bridges the gap between software component visibility and active threat detection with particular consideration of resource-constrained IoT environments.

The comparison indicates that existing studies address different aspects of IoT security, including SBOM-based vulnerability assessment, network-based device identification, and runtime attack detection. However, these capabilities are generally considered independently or without establishing a direct relationship between the vulnerabilities identified in a specific device’s SBOM and the network activity observed against that device. The proposed framework combines these capabilities through SBOM–network correlation, using device-specific vulnerability information to provide additional context for identifying targeted attacks. The framework is further evaluated on a resource-constrained Raspberry Pi to examine its practical detection capability and computational overhead.

1.3. Research Objectives and Contributions

This study investigates whether software-component vulnerability information derived from Software Bill of Materials (SBOM) can be integrated with runtime network monitoring to improve vulnerability-aware threat detection and response for resource-constrained IoT devices. The study has three main objectives: (i) to investigate how SBOM-derived vulnerability context can complement conventional network-based detection; (ii) to develop a lightweight framework for correlating component-level vulnerabilities with observed network activity and supporting automated response; and (iii) to experimentally evaluate the proposed approach in terms of detection effectiveness, response time, and resource overhead on Raspberry Pi-based IoT testbed.

The main contributions of this research are as follows:

• SBOM-informed vulnerability-aware network monitoring: A continuous monitoring approach is developed that combines software-component vulnerability information with runtime network observations. The framework correlates observed network activity with vulnerabilities affecting components identified in the monitored IoT device’s SBOM, providing device-specific context for threat detection.
• Workflow of automated vulnerability-to-response: In the framework proposed in the current research work, the software-component inventory, vulnerability identification, network event correlation, threat alerts, and response guidance are all part of a single monitoring workflow. The alerts issued as a result of this workflow carry the context of the vulnerability along with the related CVE and attacks observed on it.
• Evaluation on resource-constrained IoT platforms: The proposed method is evaluated based on effectiveness in detection, behavior of false positives, response capabilities and resource overhead. Comparison is made in terms of resource needs for the proposed method as well as the conventional network monitoring method.

In this research work, security monitoring and vulnerability-based response for the software-based IoT devices on resource-limited Raspberry Pi platforms is studied. The proposed framework maintains software inventory of the device by creating SBOM and analyzing the software components identified against vulnerability databases publicly available. Vulnerability information gathered from this process is used to provide context to the network traffic generated by the system. Evaluation is done on the basis of effectiveness in detection, response capability and resource overhead. The analysis is limited to examining the feasibility and practical benefits of using SBOM-based monitoring in a resource-constrained IoT environment.

The rest of this paper is structured as follows. Section 2 describes the proposed framework, the experimental setup, and evaluation methodology. Section 3 discusses the experimental results. Section 4 examines the results in light of the research objectives and existing literature. Section 5 concludes the study along with limitations and suggests further lines of research.

2. Materials and Methods

In order to narrow down the noted gap between visibility and real-time threat detection capabilities of software components, this study applies design science research to develop and validate an artefact, an SBOM based security monitoring system. he approach combines 201 iterative system development with quantitative experimentation to show technological 202 viability and quantifiable security gains. The following three research questions are addressed through the proposed experiments:

1. Is it possible to reduce the rate of false positives of real-time correlation between the vulnerabilities detected using SBOM and network activity in comparison to signature-based IDS?

2. What amount of computational effort is required to conduct continuous SBOM enhanced monitoring in constrained environment of IoT devices?

3. What is the effectiveness of vulnerability aware detection in terms of detection, latency and alerts quality?

2.1. Research Design and Approach

The proposed research is based on an experimental research design to design and test the performance of an SBOM-based security monitoring system for Internet of Things (IoT) devices. The design involves the development of a prototype that incorporates SBOM generation, software vulnerability detection, network traffic monitoring, vulnerability-based correlation and alerting/remediation process. An IoT testbed is established using a Raspberry Pi to create a typical resource-constrained environment. Controlled attack scenarios against known vulnerabilities in the installed software components are then launched to evaluate the framework’s detection and response capabilities. The design is quantitatively evaluated based on detection effectiveness, reaction time, utilization of CPU and memory, and automated remediation capability. The resource requirements of the proposed design and detection behavior are evaluated and compared to traditional network monitoring techniques.

2.2. Detailed Experimental Configuration

The test bed architecture is made up of the hardware, software environment, and the vulnerable software packages that are run on the Raspberry Pi. The specifications of the hardware and software that have been used in the implementation and testing of the security monitoring framework using SBOMs are shown in Table 2 and Table 3, respectively. Table 4 shows the vulnerable software packages that were used in the experiment.

2.2.1. Hardware Specifications

The proposed security monitoring framework was tested on the Raspberry Pi 4 Model B computer with 4 GB LPDDR4 RAM and 64 GB microSD card. This computer is based on the Broadcom BCM2711 SoC with 1.5 GHz quad-core ARMv8 CPU architecture and Gigabit Ethernet using Broadcom BCM54213PE controller chip. The complete hardware configuration is presented in Table 2.

2.2.2. Software Environment

The Raspberry Pi was configured with Raspberry Pi OS (64-bit), based on Debian 11 (Bullseye), and Linux kernel version 5.15.84-v8+. Python 3.9.2 was used to implement the correlation and automation components of the framework. Syft and Grype were used for SBOM generation and vulnerability identification, respectively, while tshark was employed for runtime network traffic monitoring. Prometheus and Node Exporter were used to collect and monitor system resource utilisation during the experiments. The software configuration is summarized in Table 3.

2.2.3. Installed Vulnerable Software Packages

To provide a controlled environment for evaluating vulnerability-aware monitoring, several software packages with publicly documented vulnerabilities were installed on the Raspberry Pi. These included ntpd version 1:4.2.8p15+dfsg-1, associated with CVE-2015-7855 and CVE-2015-7871; OpenSSH Server version 1:8.4p1-5, associated with CVE-2018-15473; and Python’s http.server package version 3.9.2-3, associated with CVE-2019-6715. During SBOM generation, Syft identified a total of 847 software components across system libraries, language runtimes, and dependencies. The vulnerable packages relevant to the experimental configuration are presented in Table 4.

2.3. Data Collection Methods and Tools

This study’s data collection includes both static and dynamic information that is essential to the functioning and assessment of the monitoring system. The datasets utilized and generated include Public CVE Feeds, SBOM Files and Simulated Attack Traffic Records. Reliable external databases, such as OSV.dev, provide information on common vulnerabilities and exposures (CVEs). These include comprehensive information about current software vulnerabilities. The target IoT devices (Raspberry Pi) in a simulated or real-time state are the basis for the creation of the Software Bill of Materials (SBOM) files. The files provide a precise inventory of all installed software, libraries, and other dependencies. Simulated attack traffic records are based on real-world CVE-based attack exploits that generate and gather network traffic logs. This enables a realistic simulation of malicious operations intended to take advantage of certain vulnerabilities. Regarding system performance metrics, CPU usage and memory metrics are indicated in real-time. The Internet of Things (IoT) and the data collected include CPU% usage, memory consumption, and equipment used for attack simulation and monitoring.

The experimental framework integrates several tools to support software inventory, vulnerability identification, network traffic monitoring, system-resource monitoring, and vulnerability-aware correlation. Syft was used to automatically generate a Software Bill of Materials (SBOM) from the software components installed on the Raspberry Pi. The generated SBOM was subsequently analysed using Grype to identify known vulnerabilities by matching the enumerated components against publicly available vulnerability databases. Runtime network traffic was captured and analysed using tshark, with particular attention to NTP traffic transmitted over UDP port 123 for the attack scenarios considered in this study. The ipify API was used to obtain the public IP address of the Raspberry Pi, enabling identification of the monitored device in network-related processing where required.

System-level performance data were collected using Prometheus together with Node Exporter. These tools provided time-series measurements of resource utilisation, including CPU and memory consumption, which were used to assess the computational overhead of the proposed monitoring framework. FuzzyFuz was employed as the fuzzy-matching component for associating observed network traffic characteristics with vulnerability and attack-pattern information. Finally, custom Python scripts were developed to integrate the outputs of the individual tools, process the collected network and vulnerability data, perform correlation between runtime observations and SBOM-derived vulnerability information, generate alerts, and support the automated response workflow. Thus, the tools collectively form the data-collection and processing pipeline used for the experimental evaluation.

2.4. Data Analysis Techniques

The collected data undergoes several stages of analysis, from SBOM generation to real-time monitoring and response, to achieve the research objectives as shown in Figure 1.

2.4.1. Vulnerability Analysis

Grype continually monitors for vulnerabilities by piping SBOMs generated by Syft. This method discovers known CVEs linked to Internet of Things device software components. To get CVE information from the Debian ecosystem, the system interacts with the OSV API. This stage ensures that the vulnerabilities found are pertinent to the specific target environment.

2.4.2. Network Traffic Analysis and Threat Correlation

With reference to Real-time Packet Inspection tshark focuses on specific protocols and ports (such as the NTP protocol and UDP port 123) while reading and analyzing real-time network data. Source IPs, timestamps, protocols, and payload segments constitute some of the most important information that are extracted.

A Python-based correlation engine uses fuzzy matching techniques (e.g., fuzzywuzzy) to compare known CVEs with observed attack patterns (from tshark captures and logs). A similarity criterion of $\ge 70\%$ is used to reduce false positives and improve the accuracy of connecting network anomalies to specific vulnerabilities.

The 70% threshold was objectively determined through testing in over 50 attack scenarios:

• Threshold $<70\%$: False positives were generated due to coincidental pattern matching, such as legitimate NTP time synchronisation marked as an amplification attack.
• Threshold $>70\%$: By ignoring minor attack variations (such as exploits using different buffer overflow offsets), false negatives were introduced.
• Threshold $=70\%$: The optimal ratio of specificity (0% false positive rate) to sensitivity (100% true positive rate).

The system detects anomalies, which can be either faulty packets or unexpected volumes of traffic, and associates them with the exploitation mechanisms of related CVEs. The validation helps confirm the type of attack and its association with known vulnerabilities.

2.4.3. Automated Remediation Analysis

The efficiency of the automated remediation process was evaluated based on the calculation of the patching success rate according to the patching logs. The efficiency of the remediation process was determined based on whether the discovered vulnerabilities were eliminated and whether there were any adverse impacts of the process on the operation of the device in the form of increased memory usage and decreased performance. After the patches were applied, the SBOM was updated, and the system checked the elimination of the vulnerabilities from the SBOM.

2.4.4. Performance and System Health Analysis

Framework performance was analyzed quantitatively using parameters associated with detection accuracy, response efficiency, and resource utilization. Detection efficiency was determined by the false positive rate recorded in the experimental tests, while the total time taken to detect and respond to attacks was calculated from the duration between the occurrence of attacks and the successful deployment of patches. Framework resource utilization was tested using Prometheus and Node Exporter through analysis of CPU and memory usage of the system during normal operations to evaluate the resource utilization needs of the framework in the resource-restricted Raspberry Pi system. Additionally, Prometheus results through Grafana dashboard were used to analyze the temporal behavior and the association of attack detection and responses with network traffic and CPU/memory usage.

2.5. Variables and Measurement Methods

To quantitatively evaluate the system, several key variables are defined and measured:

2.5.1. Independent Variables

• Attack Type: The specific CVE-based exploits that are replicated (e.g., NTP protocol attacks that target ntpd vulnerabilities).
• Attack Load/Rate: The simulated attacks’ intensity or frequency (e.g., attacks per minute).
• Configuration of IoT Devices: the software versions and packages installed on the Raspberry Pi testbed, particularly those with known vulnerabilities.

2.5.2. Dependent Variables

• Detection Accuracy(False Positives): Number of legitimate activities incorrectly flagged as attacks. This is directly measured and reported in Table 5.
• Attack Rate per Minute: The frequency of attacks identified over a specific time period is expressed in attacks per minute. To calculate the number of attacks per minute, multiply the attack rate by 60, as shown in Table 5.
• Resource Utilization(CPU and Memory Usage): Prometheus measured "CPU (%)" and memory usage in Megabytes (MB) as shown in Table 5.
• Alerting Effectiveness: Assessed by the successful delivery of SMTP email alerts with complete and accurate attack details (CVEs, similarity scores, IPs, timestamps).

2.5.3. Measurement Methods

• Prometheus Metrics Collection: Prometheus agents running on Raspberry Pi devices periodically continuously scrape system resource data (CPU, RAM, attacks detected). These indicators are used to assess resource utilisation and system stability.
• Ground Truth Establishment: For simulated attacks, the exact time and kind of attack initiation are known. This established fundamental truth allows for: Startitemise
• Precise measurement of detection latency (the time gap between the start of an attack and the creation of an alarm).
• It is possible to directly count False Positives (FP) by comparing system alarms to known non-attack times. After remediation attempts, the vulnerable package’s condition is monitored to verify the success of the patching process.
• System Command Output Analysis: Parsing of apt command outputs and system logs (such dpkg logs) is done in order to verify successful package updates, identify any issues during the patching process, and validate the new version of the patched software.

2.6. Algorithm for Vulnerability-Aware Attack Correlation

By comparing observed attack patterns with known vulnerabilities and device-specific software inventories, the suggested Vulnerability-Aware Attack Correlation method examines incoming network packets to find security risks as shown in Algorithm 1. In order to create an attack signature based on payload characteristics and communication context, protocol-level information are first retrieved from each packet. Fuzzy string matching is then used to compare this signature with known exploit patterns from a vulnerability database, enabling the method to handle differences in attack representations. Software Bill of Materials (SBOM) filtering is used to further validate candidate vulnerabilities that surpass a predetermined similarity level. In this way, only the vulnerabilities impacting components actually implemented in the target device are considered. Finally, the algorithm generates a comprehensive security alert containing all the required CVE identifiers, affected components, similarity score, attack metadata, and recommendations for mitigating the threat if there is any confirmed threat detected; otherwise, no alert gets generated at all.

Algorithm 1: Vulnerability-Aware Attack Correlation

Input:  Network packet P; SBOM vulnerability database V; similarity threshold $T=0.70$ Output:  Security alert A or ⌀ 1: Extract protocol features from P: 2:      $F\leftarrow \{\mathrm{source}\_\mathrm{IP},\mathrm{destination}\_\mathrm{port},\mathrm{payload},\mathrm{timestamp}\}$ 3: Identify protocol type $p\in \{\mathrm{NTP},\mathrm{HTTP},\mathrm{SSH},\mathrm{MQTT},\mathrm{CoAP}\}$ 4: Generate attack signature S from payload patterns 5: Initialize candidate set $C\leftarrow \varnothing$ 6: for all CVE entries $c\in V$ do 7:     Retrieve documented exploit pattern $E_c$ 8:     Compute similarity score: 9:          $score\leftarrow FuzzyTokenSetRatio(S,E_c)$ 10:     if $score\ge T$ then 11:         $C\leftarrow C\cup \left\{\right(c,score\left)\right\}$ 12:     end if 13: end for 14: Initialize confirmed threat list $CT\leftarrow \varnothing$ 15: for all$(c,score)\in C$do 16:     Query the SBOM for an affected component associated with c 17:     if an affected component exists on the target device then 18:         $CT\leftarrow CT\cup \left\{\right(c,score,\mathrm{component}\left)\right\}$ 19:     end if 20: end for 21: if $CT\ne \varnothing$then 22:     Generate security alert A containing CVE identifiers, 23:     affected components, similarity scores, attack metadata, 24:     and remediation guidance 25:     return A 26: else 27:     return ⌀ 28: end if

2.7. Experimental Workflow

The experiment begins by generating an SBOM of the software components installed on the Raspberry Pi and identifying the associated known vulnerabilities. The resulting vulnerability information is then used as the context for runtime network monitoring. During the experiment, network traffic is captured and analysed to identify activity associated with the monitored services, particularly NTP traffic over UDP port 123. The observed traffic is processed by the correlation engine and compared with the vulnerability information derived from the SBOM. When the observed activity matches the characteristics of an attack targeting a vulnerable component, a security alert is generated and the relevant vulnerability and attack information is recorded.

In parallel, system-level performance metrics are collected during the experiment to measure the computational overhead of the proposed framework. CPU and memory utilisation are monitored throughout the detection process, while the timing of attack initiation, detection, and alert generation is recorded for response-performance analysis. The full experimental cycle and lab setup from SBOM generation and vulnerability detection to runtime traffic analysis, correlation, alerting and performance assessment are shown in Figure 2.

3. Results

The results of the research are presented in this section, demonstrating the successful implementation and evaluation of the proposed SBOM enhanced monitoring for IoT devices.

3.1. Fulfillment of Objective 1: SBOM-Enhanced Threat Detection

Using SBOM analysis and vulnerability scanning, Objective 1 sought to show the high accuracy of IoT threat detection. The following significant outcomes helped to achieve this:

3.1.1. SBOM Generation and Analysis

The manual SBOM creation based on Syft for Raspberry Pi Internet of Things devices was done as part of the implementation. It included the analysis of the most important packages, such as ntpd and the dependencies they have, providing the necessary granularity of software composition of the device. The first step in the vulnerability-aware identification of the software installed on the IoT device is SBOM generation. Packages of interest are highlighted in a manually generated SBOM for Raspberry Pi IoT devices.

3.1.2. Real-Time CVE Correlation

With the help of a vulnerability scanning tool with Grype integration, it was demonstrated how to correlate the manually assembled SBOM modules with the most recent CVE databases. This correlation allowed obtaining exact and instant context about threats related to detected anomalies. As opposed to regular monitoring tools that could only inform about suspicious behavior of networks, our system that combines SBOM and CVE data allows comprehending which exact vulnerable component is being attacked. An example of this feature is the detection of attacks against a specific CVE in a particular version of software, which described in detail in later sections.

3.1.3. Precision NTP Attack Detection and High Precision

The capability of the tshark-based monitoring system to detect attacks based on NTP protocol (UDP port 123) was proven. It requires good attack pattern recognition and exact source IP identification. Zero False Positive Rate (FP=0), which can be seen in Table 5 and in Figure 7, is an important result that meets objective 1.

Achieving Superiority Through Awareness of Vulnerability and Contextual Accuracy: The SBOM-enabled solution yields such a great degree of accuracy precisely due to the use of SBOM data, particularly its absence of false positives.

• Contextual Accuracy (Specificity): Whereas a regular Intrusion Detection System (IDS) may detect "suspicious NTP traffic" or "malformed packets" thus issuing an alarm about "something wrong going on," the SBOM-enabled solution achieves unprecedented specificity. For instance, it detects a "NTP protocol attack on CVE-XXXX-YYYY in ntpd package version Z.Y.X on device A." Such a specific information is delivered due to the use of SBOM context data, which is crucial for a fast and specific response and mitigation. It ensures that the exact vulnerable component is patched, saving inquiry time. This is a significant improvement over the generic warning messages. The detection of an NTP protocol attack targeting CVE-2015-7855 (ntpd vulnerability) and subsequent patching is shown in Figure 3.

  

  Figure 3. Example notification email alert

  Figure 3. Example notification email alert

  
• Vulnerability-Aware Detection: Conventional IDSs detection mechanisms tend to use either anomaly detection or signatures of known attacks; however, such mechanisms cannot identify whether the target system is really vulnerable to the current attack being observed. Warnings of attacks against the already patched systems will lead to this effect, producing "noise". Conversely, our detection mechanism triggers alerts only for attacks that are based on known vulnerabilities of certain software components of the device. For example, our system will not raise an alert about an exploit attempt related to some CVE as long as the ntpd package on the Raspberry Pi is not vulnerable to that CVE. In this way, by reducing "actionable noise" to zero, the system ensures that attention is paid to real vulnerabilities.

Such characteristics clearly demonstrate how the integration of vulnerability scanning and SBOM analysis allows one to improve detection accuracy, moving far beyond anomaly detection to obtain actionable threat intelligence. An example of a vulnerability-aware alert can be seen in Figure 4.

Figure 4. Example of a vulnerability-aware alert

Figure 4. Example of a vulnerability-aware alert

3.2. Fulfillment of Objective 2: Development and Implementation of an Automated, Integrated Monitoring Framework

Objective 2 concerned the development and implementation of an automated, integrated monitoring framework for the Internet of Things devices. Success in achieving this objective can be seen through the successful development and working of the prototype system. Figure 5 below shows the code structure of the automated IoT monitoring and response system developed using Python programming language.

3.2.1. Automated Alerting System

A functioning SMTP email alert mechanism is now in place. In case of any threat detection, this mechanism will provide the managers with alert emails that include important information like CVEs, similarity scores showing the confidence level of the match, and attack metadata such as source IPs, time stamps, and relevant packet excerpts. Such an extensive automated alert mechanism ensures timely and informed responses to events. One such alert email is illustrated in Figure 3.

3.2.2. Proven Monitoring Framework

The research successfully developed a working prototype that integrates all core components into a cohesive IoT security system. This framework seamlessly combines:

• SBOM analysis (using Syft)
• vulnerability scanning (using Grype)
• Real-time network monitoring (tshark)
• A Python-based correlation engine linking network anomalies to SBOM-identified vulnerabilities
• An automated alerting system (SMTP)

This integrated approach shows the viability of an all-encompassing, automated defense mechanism for resource-constrained IoT environments and is a major step towards a workable and scalable SBOM-powered IoT security solution.

3.3. Fulfillment of Objective 3: Quantitative Evaluation of the Framework’s Performance

The third objective was to evaluate the performance of the proposed model quantitatively through Raspberry Pi test bed. It was achieved through measurements of some performance metrics as well as extensive testing. The performance of the system under simulated attack situations is highlighted in Table 5. A 15-second window was chosen for attack detection because of its efficiency in burst and real-time attack detection, using the following formula:

$$\mathrm{Attack}\mathrm{Rate}(\mathrm{per}15\sec )={\displaystyle \frac{\mathrm{No}.\mathrm{of}\mathrm{Attacks}\mathrm{in}15\sec }{15}}$$

(1)

3.4. Performance Metrics

In this section we discussed the false positive rate, resource efficiency and system health monitoring.

3.4.1. Resource Efficiency:

Figure 6, demonstrates the system’s resource utilization. CPU usage remained stable, typically around 20-33.4%.

On the other hand, memory usage is always between 750 and 760 MB. These metrics demonstrate the framework’s effectiveness on Raspberry Pi devices, which makes it suitable for IoT deployments with limited resources.

3.4.2. System Health Monitoring

Continuous monitoring of the CPU, memory, and network usage has been conducted by use of Prometheus based resource monitoring. The features outlined above imply that the system works under respected limits, hence, capable of processing any load without undermining the security features in place, which is extremely important for detecting anomalies.

3.4.3. False Positives (FP)

An important quantitative result is the fact that there have been consistently zero (0%) false positives during the testing process. See Figure 7.

Figure 7. False Positives Over Time

Figure 7. False Positives Over Time

3.4.4. Attack Detection

Another significant quantitative result is the identification of every attack observed during the test period, as shown in Figure 8. This verifies even more how reliable and accurate the system is in identifying real threats.

4. Discussion

This study was successful in implementing a comprehensive security monitoring solution for Raspberry Pi IoT devices. The software components in the package containing the ntpd package were identified using the automated SBOM process with Syft, which also effectively identified vulnerable dependencies. Grype’s sub-real-time CVE correlation implementation made it possible to precisely identify vulnerabilities and improve the system’s ability to respond to threats.

NTP protocol-based attacks with accurate source IP address attribution and the capacity to recognise attack patterns were detected by monitoring using a tshark-based system. Administrators received rich communications from this automated alerting system, including details about CVEs and attack metadata, enabling them to promptly address security incidents.

In the event of the simulated attack scenario, there was also no variation in system performance and efficient use of CPU, memory, and network resources. The system’s accuracy in identifying an assault was further compromised by a lack of false positives. These components came together to create a cohesive structure that demonstrated the system’s potential for real-time IoT security monitoring.

Because it used strictly published data, adhered to privacy, permission, and data integrity rules, and was open and honest about every facet of the study, the research was morally sound.

4.1. Comparison with previous studies

As shown in Table 6, the measurements of the suggested Python script and previous research known as Suricata produced variations in the use of CPU and memory resources. In contrast to Suricata, the Python script utilised fewer resources.

The foundation of Suricata is traffic analysis and signature-based detection [35]. Nevertheless, the majority of studies, including Suricata, do not specify complete CVE correlation using Software Bill of Materials (SBOM), a novel approach that is the subject of our proposed work.

The results of our suggested lightweight Python script verify that our SBOM-powered tool can detect CVEs and that security monitoring can be implemented with similar capabilities but significantly less resources (see Table 6). Suricata’s average CPU utilisation is 44.83%, while the suggested method’s average is 25.53% and, in the worst scenario, 33.4%. This demonstrates that as compared to Suricata’s average CPU utilisation, the suggested solution improves it to 43%. Similarly, the average memory utilisation with Suricata is 2467.7 MB, but with the suggested technique it is 754.8 MB, indicating a 69% improvement over Suricata.

This feature of using few resources without sacrificing performance is tremendously advantageous, particularly in an Internet of Things setting. Because SBOM analysis makes it possible to map vulnerabilities with a high degree of accuracy that is not possible with traditional techniques alone.

4.2. Performance Graphs

The suggested lightweight Python script and the Suricata intrusion detection system are compared in the following graphs based on two crucial metrics: CPU and memory use.

Figure 9, which shows the CPU usage over time, shows that the Python script’s consumption is roughly consistent around 20–34%, while Suricata’s usage is highly variable, reaching a maximum of 72%. This indicates that the Python script uses CPU resources more efficiently.

The Figure 10, demonstrates the usage of memory where Suricata uses about 2,471 MB as opposed to the constant 755 MB of the Python script. This is an indication of the benefits of deploying a lightly enforceable solution in poverty-stricken settings.

In general, these measurements show that the Python script is effective in monitoring and does not use so many system resources as Suricata.

5. Conclusions

5.1. Limitations

A number of restrictions should be acknowledged, despite the fact that the monitors based on the suggested SBOM-enriched framework can show significant advancements in the field of IoT security:

• Dependency on External CVE Databases: It makes use of It matches CVEs found in external databases like OSV.dev and NVD. System dependability and real-time detection accuracy may be impacted by any delays, errors, or unavailability in these services.
• Resource Limitations for Internet of Things Devices: Even though the surveillance system is designed to operate on Raspberry Pi, it may not function well on IoT devices with low CPU and memory capacities, which could cause issues with scalability in more limited settings.
• Simulated Attack Environment: Attack Simulation Environment NTP attacks were simulated and verified in a controlled laboratory environment. The ecosystems may reveal uncontrolled IoT attack vectors or network conditions that could have an impact on detection performance.
• Coverage of Restricted Protocols: The system is primarily safeguarding NTP udp-port 123 (traffic). Providing support for additional IoT protocols would need extra tshark filters and script (e.g. MQTT, CoAP) modifications that were not dealt with in this research

5.2. Contribution

This research advances IoT security through four distinct contributions:

• Dynamic SBOM Network Correlation: We describe a continuous monitoring framework that dynamically correlates software component vulnerabilities with observable network attack patterns, in contrast to static SBOM approaches that conduct one-time vulnerability assessments. This makes it possible for vulnerability-aware threat detection to distinguish between actual exploitation efforts aimed at known vulnerabilities on particular devices and generic network oddities.
• Vulnerability Aware Precision Detection: Without determining if the target systems are genuinely susceptible, traditional IDS raises alarms based on questionable traffic patterns. By using fuzzy matching approaches ($\ge 70\%$ similarity threshold) that only detect attacks associated with vulnerabilities verified to exist in the device’s SBOM, our solution achieves zero false positives by correlating attacks to components.
• Automated Threat Response Integration: From vulnerability identification through attack detection to automated alerting with actionable intelligence, such as particular CVE numbers, similarity ratings, attack details, and remedial suggestions, we offer a complete end-to-end security workflow.
• Implementing IoT with Resource Efficiency: We show through rigorous experimentation that full SBOM enhanced monitoring works well on devices with low resources while maintaining higher detection accuracy, with a 69% reduction in memory consumption and a 43% reduction in CPU overhead when compared to Suricata.

5.3. Future Work

On the basis of the current framework, several future directions can be proposed that are intended to expand its functions and get around its limitations:

• Total Automated Remediation: Further work is required to finish the automated patching cycle so that the system can automatically apply updates or mitigations against the identified CVEs, which would further speed up response times.
• Support for Extra IoT Protocols: By adding more IoT protocols like MQTT, CoAP, and HTTP support, the monitoring system could be expanded to support a greater variety of IoT devices. In addition to new tshark filters, correlation logic would be needed for this.
• IoT Testing in the Real World: The framework will be evaluated in real-world IoT environments, such as smart homes or industrial settings, to see how well it works with various network configurations and attack scenarios.
• Optimisation of Low-Power Devices: In order to make the system more compatible with ultra-low-power IoT devices, this should be further optimised to consume less CPU and memory. The creation of lightweight monitoring agents may fall under this category.
• Machine Learning Integration: The system would be able to enhance the CVE-based approach of detection by using machine learning techniques, particularly machine learning models of anomaly detection, to better discover unknown or zero-day attacks.
• Sources of Decentralised CVE Data: In order to avoid relying too much on third-party CVE databases, future releases can make use of decentralised or cached CVE data repositories, which promises dependability and minimal latency when doing vulnerability lookups.

5.4. Summary

... This study presented an SBOM-informed security monitoring approach for vulnerability-aware identification of targeted IoT devices. The proposed framework combines SBOM generation using Syft, vulnerability identification using Grype, runtime network monitoring using tshark, and a Python-based correlation engine to associate observed network activity with vulnerabilities identified in the software inventory of the monitored device. This SBOM–network correlation provides vulnerability context that is not directly available in conventional network-based monitoring and supports more targeted security alerting. SMTP-based notifications further enable timely communication of detected security events.

The proposed approach was experimentally evaluated on a Raspberry Pi 4 Model B using a controlled IoT testbed and simulated NTP attack activity. The system identified attack activity associated with an SBOM-confirmed vulnerable component while producing zero false positives across the evaluated attack scenarios. Compared with the Suricata-based baseline, the proposed approach reduced mean CPU utilisation by approximately 43% and mean memory consumption by approximately 69%, indicating that the approach can provide vulnerability-aware monitoring with lower resource requirements on the evaluated platform.

Several limitations should be considered when interpreting these results. The experimental validation of the framework was performed on a single Raspberry Pi platform and thus does not validate performance for other IoT hardware architectures. The attack simulations took place in a laboratory setting with the attacks concentrating mainly on NTP communication. Thus, the generalization of results is limited to the range of protocols used and the particularities of the laboratory simulation scenario. Moreover, vulnerability detection relies on external databases of vulnerabilities and the differences or lack of such databases may result in vulnerability correlation problems.

Future research will involve testing the framework on other IoT protocols such as MQTT and CoAP as well as other IoT platforms. Moreover, there is a need to optimize the algorithm for other resource-restricted and ultra-low power IoT devices. Automatic vulnerability fix and patching can be considered as a future extension of the system. Machine-learning-based anomaly detection may additionally be incorporated to complement the existing vulnerability-aware correlation mechanism. Finally, locally cached or decentralised vulnerability information sources could be explored to improve lookup efficiency and reduce dependence on external vulnerability databases.