## 3 Results
### Experiments for the SOHO Configuration  
In this subsection we present our experiments concerning a small office/home office (SOHO) configuration, whose architecture follows the typical SOHO architectural style, i.e., the platform a is configured as a \"flat\" network, where network connectivity is realized by a single device acting both as (a) a layer 2 switch accommodating both wired and wireless protocols for internal nodes (which are few), and (b) as a router providing internet connectivity [47; 48]. The specific topology used in the experiment comprises:  
1. A router running PFSense ([[https://github.com/pfsense/pfsense/tree/a81a848e7565](https://github.com/pfsense/pfsense/tree/a81a848e7565) cf4b5e1679 efed08c39d13 ab7a6f]([https://github.com/pfsense/pfsense/tree/a81a848e7565](https://github.com/pfsense/pfsense/tree/a81a848e7565) cf4b5e1679 efed08c39d13 ab7a6f), accessed on 14 May 2023),
2. A NAS appliance running the Minnow Server ([[https://github.com/RealTimeLogic/MinnowServer](https://github.com/RealTimeLogic/MinnowServer)]([https://github.com/RealTimeLogic/MinnowServer](https://github.com/RealTimeLogic/MinnowServer)), accessed on 14 May 2023)
3. A smart air-conditioning appliance running the Pymodbus software ([[https://github.com/pymodbus-dev/pymodbus](https://github.com/pymodbus-dev/pymodbus)]([https://github.com/pymodbus-dev/pymodbus](https://github.com/pymodbus-dev/pymodbus)), accessed on 14 May 2023)
4. A mobile phone and a PC which include Modbus4j software ([[https://github.com/MangoAutomation/modbus4j](https://github.com/MangoAutomation/modbus4j)]([https://github.com/MangoAutomation/modbus4j](https://github.com/MangoAutomation/modbus4j)), accessed on 14 May 2023) in order to control the air-conditioning appliance. The SOHO topology corresponding to this configuration is illustrated in Figure 4.  
The source code for the software components listed above was collected and processed through the software vulnerability management framework pipeline illustrated in Figure 1 and detailed in Sections 2.1-2.6. In the security fix prioritization step, multiple values were used for the security budget to gain insight on the effect of this parameter in the recommendations formulated, regarding the list of software issues to be mitigated. The analysis of the software identified 100 security issues with the code, with a total impact equal to 722.24 and an estimated technical debt equal to 2840 min, i.e., a security budget of 2840 developer working minutes is required to mitigate all security issues. Table 3 lists indicative results from applying the security issue prioritization method described  
Figure 3: Distribution of the impact, criticality level, and technical debt of the software vulnerabilities in the “commonly used IoT technologies” configuration. in Section 2.6 to the identified security issues. As shown in Table 3, the recommendation in all cases consumes (almost) all the available budget, and manages to effectively direct the available budget to the mitigation of the issues having the highest impact, since the percentage of the total impact mitigated in the recommendation list is consistently higher than the ratio of the available budget to the total technical debt. In Table 3, we can also notice that especially when the security budget is limited, the constrained resources can be efficiently allocated to the mitigation of security issues with a very high impact, which is demonstrated by the fact that for the case of having a security budget equal to 250, the ratio of the mitigated impact percentage is 1.72 times higher than the percentage of the total available budget. When the available security budget increases, this performance margin narrows, declining to the value of 1.15 times when the security budget is equal to 1500 (or 52.46% of the total available budget). Figure 5 illustrates the effectiveness of the proposed approach against the baseline algorithms.