Machine Learning-Based Cyberattack Detection in NFV: Performance, Efficiency and Explainability Analysis

Round 1

Reviewer 1 Report

Comments and Suggestions for Authors

Thank you for submitting your manuscript to Applied Sciences. The paper presents a systematic comparison of the predictive performance and computational efficiency between ensemble machine learning models and a stacking-based meta-learner within the context of Network Functions Virtualization (NFV). I appreciate the authors’ inclusion of model explainability analysis alongside standard performance metrics.

Strengths

1. The experimental pipeline is meticulously documented, spanning dataset analysis, feature selection, model training, and hyperparameter optimization. This level of detail significantly enhances the reproducibility of the work.

2. The integration of explainability analysis (e.g., feature attribution) provides valuable insights into model decision-making, which is highly relevant for operational transparency in NFV environments.

Suggestions for Improvement

1. Contextualize the contributions beyond the NFV setting. While the empirical comparison is thorough, the manuscript currently reads primarily as an application of established ML workflows to a new domain. To elevate the conceptual contribution, I recommend explicitly discussing how your findings in NFV diverge from or align with conclusions drawn in conventional networking or cloud computing scenarios. For example, do models that traditionally perform best underperform in NFV due to domain-specific characteristics (e.g., high dynamism, latency constraints, or skewed feature distributions)? Highlighting such domain-specific insights would substantially strengthen the novelty and practical impact of the paper.

2. Explicitly articulate the contributions. The manuscript’s contributions are not clearly delineated. I strongly suggest adding a concise, bulleted list of contributions at the end of the Introduction.

3. Streamline methodological detail to align with core contributions. The experimental section demonstrates strong methodological rigor, but some procedural descriptions overshadow the narrative thread linking each step to the paper’s research questions. I recommend condensing standard or well-established ML procedures (e.g., routine hyperparameter search setups) and moving highly granular implementation details to a Supplementary Material section. In the main text, focus instead on explaining how each experimental phase directly addresses your research objectives and supports the stated contributions.

Author Response

Comments 1: Contextualize the contributions beyond the NFV setting. While the empirical comparison is thorough, the manuscript currently reads primarily as an application of established ML workflows to a new domain. To elevate the conceptual contribution, I recommend explicitly discussing how your findings in NFV diverge from or align with conclusions drawn in conventional networking or cloud computing scenarios. For example, do models that traditionally perform best underperform in NFV due to domain-specific characteristics (e.g., high dynamism, latency constraints, or skewed feature distributions)? Highlighting such domain-specific insights would substantially strengthen the novelty and practical impact of the paper.
Response 1: Thank you for pointing this out. We agree with this comment, so we enhanced the conceptual contribution of the paper by expanding the Discussion section (page 29, lines 980-997 in the revised document), where we explicitly compared our findings with previous studies that used conventional networking datasets. Specifically, we explored the balance between computational efficiency and predictive performance and whether ensemble methods exhibit different predictive and inference time results in both conventional and NFV network environments. We emphasized that, mainly due to virtualization overhead and high dynamism, NFV environments require computational efficiency to be a criterion of critical importance when selecting a model, not merely its detection accuracy and false positive rate. However, the predictive performance results achieved by ensemble models, such as Random Forest, align across conventional network datasets and our VNF-specific dataset, despite the highly dynamic nature and latency constraints specific to NFV networks.

Comments 2: Explicitly articulate the contributions. The manuscript’s contributions are not clearly delineated. I strongly suggest adding a concise, bulleted list of contributions at the end of the Introduction.
Response 2: Based on the reviewer's suggestion, we have added a concise, bulleted list of contributions at the end of Introduction (page 2, lines 96-109 in the revised document).

Comments 3: Streamline methodological detail to align with core contributions. The experimental section demonstrates strong methodological rigor, but some procedural descriptions overshadow the narrative thread linking each step to the paper’s research questions. I recommend condensing standard or well-established ML procedures (e.g., routine hyperparameter search setups) and moving highly granular implementation details to a Supplementary Material section. In the main text, focus instead on explaining how each experimental phase directly addresses your research objectives and supports the stated contributions.
Response 3: We sincerely thank the reviewer for this constructive suggestion. We agree that the original methodology contained granular implementation details that could distract from the paper's primary contributions. Based on the comment, we first introduced a sentence that provides a brief roadmap to guide the readers on how each experimental phase included in the methodology helps answer the main research questions (page 4, lines 227-232 in the revised document). To further streamline methodological detail to align with core contributions of the paper, we condensed the descriptions of ensemble learning algorithms in section 3.6 Model Training (pages 13-14). Additionally, we moved a paragraph from subsection 3.6.5 Hyperparameter Optimization that provides details on balanced class weights and hyperparameter configurations to Appendix A (lines 1141-1150).

Reviewer 2 Report

Comments and Suggestions for Authors

1. The research merely compares conventional ensemble models and a basic stacking meta-learner, without developing a novel algorithm, dedicated framework, or targeted optimization scheme for cyberattack detection in NFV environments.
2. The experimental validation is not conducted on mainstream public intrusion detection datasets.
3. The stacking-based meta-learner suffers from critical computational inefficiency, including excessive training time, large model size, and high memory consumption, which severely restricts its practical deployment in the real scenarios.
4. The SHAP-based analysis is exclusively performed on individual base ensemble models, while the interpretability of the core stacking meta-learner is completely neglected.
5. The discussion section lacks in-depth analysis of experimental findings, insufficiently addresses the practical implications for NFV security.
6. The logical linkage among the methodology, experimental results, and drawn conclusions is weak and inconsistent.

Author Response

Comments 1: The research merely compares conventional ensemble models and a basic stacking meta-learner, without developing a novel algorithm, dedicated framework, or targeted optimization scheme for cyberattack detection in NFV environments.
Response 1: We thank the reviewer for this observation. We acknowledge that the study does not introduce a novel algorithm. Instead, the novelty lies in the development of an integrated and reproducible framework for cyberattack detection in NFV environments that combines comprehensive preprocessing, automated hyperparameter optimization, model selection based on predictive performance and computational efficiency evaluation, and SHAP-based explainability insights. The Introduction has been revised to explicitly articulate the contributions of our work.

Comments 2: The experimental validation is not conducted on mainstream public intrusion detection datasets.
Response 2: The objective of this work is to evaluate cyberattack detection specifically in NFV environments. Consequently, we selected the VNFCYBERDATA dataset because it captures traffic generated by VNFs, which conventional intrusion detection datasets, such as KDD Cup 1999 or NSL-KDD, are not representative of due to NFV traffic characteristics, such as high dynamism and virtualization. To acknowledge the importance of stronger validation, we have expanded section 5.4 Limitations and Future Directions (page 30, lines 1081-1088), as well as the Conclusion section (page 31, lines 1117-1122).

Comments 3: The stacking-based meta-learner suffers from critical computational inefficiency, including excessive training time, large model size, and high memory consumption, which severely restricts its practical deployment in the real scenarios.
Response 3: We agree with the reviewer that the stacking-based meta learner suffers from critical computational inefficiencies compared to individual ensemble models. Rather than viewing this solely as a limitation, we interpret it as a key finding of this comparative study. We have expanded the Discussion to analyze the trade-offs between predictive performance and computational efficiency and to identify deployment scenarios where other models might be more appropriate. Our findings indicate that stacking is better suited for environments where computational resources are less constrained. In such cases, we explicitly highlight the importance of proper meta model selection, specifically focusing on achieving the balance between low FPR, high recall, and operational efficiency (page 28, lines 956-963).

Comments 4: The SHAP-based analysis is exclusively performed on individual base ensemble models, while the interpretability of the core stacking meta-learner is completely neglected.
Response 4: We appreciate this observation. The manuscript has been revised to more clearly justify why explainability was exclusively applied to individual base ensemble models and why the interpretation of base models' predictions provides direct insight into feature importance and attribution (page 30, lines 1064-1071). Nevertheless, we have already acknowledged the explainability limitation related to stacked meta learners, stating that it should be enhanced as part of future research work (page 31, lines 1099-1109).

Comments 5: The discussion section lacks in-depth analysis of experimental findings, insufficiently addresses the practical implications for NFV security.
Response 5: The Discussion section has been expanded to provide a deeper interpretation of the experimental findings, especially related to alignment of results with conventional networking environments (page 29, lines 980-993), and practical implications of deploying the models in resource-constrained NFV environments (page 28, lines 968-972, page 29, lines 984-997).

Comments 6: The logical linkage among the methodology, experimental results, and drawn conclusions is weak and inconsistent.
Response 6: We appreciate the reviewer's comment. To address it, we have improved the logical flow of the methods, results, and conclusions by: (1) revising the Methodology section to more clearly explain how each experimental phase links to the study's research objectives and (2) expanding the Discussion and Conclusion sections to be directly supported by the presented results and re-emphasize the principal contributions of the paper in relation to the research objectives.

In addition to the specific revisions described above, the manuscript has been carefully proofread and edited by a fluent English speaker to improve language quality. Figure quality has also been improved to the maximum extent possible.

Reviewer 3 Report

Comments and Suggestions for Authors

 

The manuscript addresses a highly relevant and critical topic: improving security in Network Function Virtualization (NFV) environments using ensemble machine learning and model explainability (SHAP). The paper is well-structured and technically sound in its evaluation of Random Forest, XGBoost, CatBoost, and Stacking architectures. However, several critical technical issues, notation errors, and methodological limitations must be addressed before the paper can be considered for publication.

ey Comments (Major and Minor Points):

1. Syntax Errors in Hyperparameter Notation (Appendix A):

   • There are severe text rendering and formatting issues in Table A2 (Lines 1128–1136). For instance, the hyperparameter name is broken down as $n_{\_}$ $=478,$ (should be n_estimators). Furthermore, equality signs have merged with letters, resulting in broken parameters like min_samples_split t=16, max_leaf_nodes z=30, learning_rate e=0.2997, and min_data_in_leaf f=64. All LaTeX/Markdown formatting in the Appendix must be thoroughly checked and corrected.

2. Template Page Numbering Error:

   • In the running headers of the review draft (Lines 42, 93, 146, 199, 246, etc.), the page number is hardcoded as 2 of 35 on every single page. The authors must ensure that the dynamic page counter (\thepage or equivalent template fields) works correctly in the final layout.

3. Incomplete Metadata Placeholders:

   • Lines 33–35 contain unpopulated editorial fields: Academic Editor: Firstname Lastname, as well as placeholder text for Received: date, Revised: date, Accepted: date, and Published: date. Additionally, temporary indices are present in the journal name and DOI (Lines 3, 41: Appl. Sci. 2026, 15, x and https://doi.org/10.3390/xxxxx). While common for initial submissions, these placeholders should be cleaned up or verified during the revision tracking phase.

4. Numerical Inconsistencies and RAM Anomalies in Tables:

   • In Table 2 (Line 650) and Table 4 (Line 673), there is an inconsistency in numerical formatting. Table 2 uses a comma as a thousands separator for RAM usage (300,293), while other tables omit separators or use decimals.

   • More importantly, a value of 300,293 MB (which equals over 300 GB) seems physically anomalous for an experiment claimed to be executed on a standard laptop with only 16 GB of RAM (specified in Lines 353–356). The authors must re-verify the memory measurement units and metric tracking logic for the Stacked model.

5. Discrepancy Between Hardware Resources and Data Scale:

   • In Lines 256–259, the authors state that the full VNFCYBERDATA dataset contains over 7 million records, but they downsampled it to approximately 260,000 records because training on the full set "would not be feasible due to hardware resource constraints".

   • Relying solely on a low-power laptop CPU (Intel i5-1235U) for an Applied Sciences paper limiting data scope is a noticeable drawback. The authors should explicitly add this to a "Limitations" section and discuss how the framework scales or how it will be validated on high-performance computing (HPC) or GPU clusters in the future.

6. Over-inclusive Abbreviations List:

   • The Abbreviation list (Lines 1105–1106) includes entry-level, industry-standard networking terms such as IP, MAC, TCP, UDP, DNS, HTTP, GB, MB, GHz. To maintain a high academic standard, the list should be streamlined to feature only domain-specific or method-specific acronyms (e.g., NFV, VNF, PR-AUC, SHAP, MI-MAML, Optuna, SIEM).

7. Limitation of the Explainability (SHAP) Analysis:

   • In Lines 1047–1052, the authors acknowledge that due to the complexity of the Stacking meta-learner architecture, they only applied the SHAP framework to the three base ensemble models (Random Forest, XGBoost, CatBoost). This leaves the primary model of the study (the Stacked meta-learner) uninterpreted.

   • Given that "Explainability Analysis" is featured prominently in the title, the authors need to either justify why base-model interpretation is sufficient to understand the meta-layer's behavior or try computing SHAP values directly for the meta-classifier (Logistic Regression), which accepts a linear combination of probabilities and should be inherently interpretable.

Author Response

Comments 1: Syntax Errors in Hyperparameter Notation (Appendix A) - There are severe text rendering and formatting issues in Table A2 (Lines 1128–1136). For instance, the hyperparameter name is broken down as $n_{\_}$ $=478,$ (should be n_estimators). Furthermore, equality signs have merged with letters, resulting in broken parameters like min_samples_split t=16, max_leaf_nodes z=30, learning_rate e=0.2997, and min_data_in_leaf f=64. All LaTeX/Markdown formatting in the Appendix must be thoroughly checked and corrected.
Response 1: We sincerely thank the reviewer for carefully examining the manuscript. We thoroughly checked Appendix A and the rest of the submitted text, but were unable to identify the reported formatting issues. Other reviewers did not report this problem either, so it is possible that the reported issues resulted from document rendering or file conversion process rather than the source manuscript.

Comments 2: Template Page Numbering Error - In the running headers of the review draft (Lines 42, 93, 146, 199, 246, etc.), the page number is hardcoded as 2 of 35 on every single page. The authors must ensure that the dynamic page counter (\thepage or equivalent template fields) works correctly in the final layout.
Response 2: We thank the reviewer for pointing this out. The hardcoded page numbering in the header originates from the journal's manuscript template, but we have subsequently turned on a dynamic page counter to fix this problem. The change should be visible across the running headers of the updated document, excluding the title and abstract page.

Comments 3: Incomplete Metadata Placeholders - Lines 33–35 contain unpopulated editorial fields: Academic Editor: Firstname Lastname, as well as placeholder text for Received: date, Revised: date, Accepted: date, and Published: date. Additionally, temporary indices are present in the journal name and DOI (Lines 3, 41: Appl. Sci. 2026, 15, x and https://doi.org/10.3390/xxxxx). While common for initial submissions, these placeholders should be cleaned up or verified during the revision tracking phase.
Response 3: We have accordingly populated the metadata placeholders for the following: Academic Editor: Firstname Lastname, as well as Received: date, Revised: date (see lines 34–36 in the updated manuscript). As per your suggestion, the following editorial fields were cleaned up: temporary indices in the journal name and DOI (Lines 3, 41: Appl. Sci. 2026, 15, x and https://doi.org/10.3390/xxxxx), Accepted: date, and Published: date. 

Comments 4: Numerical Inconsistencies and RAM Anomalies in Tables - In Table 2 (Line 650) and Table 4 (Line 673), there is an inconsistency in numerical formatting. Table 2 uses a comma as a thousands separator for RAM usage (300,293), while other tables omit separators or use decimals. More importantly, a value of 300,293 MB (which equals over 300 GB) seems physically anomalous for an experiment claimed to be executed on a standard laptop with only 16 GB of RAM (specified in Lines 353–356). The authors must re-verify the memory measurement units and metric tracking logic for the Stacked model.
Response 4: We appreciate the reviewer's careful observation and we re-verified the memory measurement units. The reported value is 300.293 MB, not 300,293 MB. We consistently used the decimal point as the decimal separator rather than a thousands separator (the mentioned result is slightly over 300 MB, not 300 GB).

Comments 5: Discrepancy Between Hardware Resources and Data Scale - In Lines 256–259, the authors state that the full VNFCYBERDATA dataset contains over 7 million records, but they downsampled it to approximately 260,000 records because training on the full set "would not be feasible due to hardware resource constraints". Relying solely on a low-power laptop CPU (Intel i5-1235U) for an Applied Sciences paper limiting data scope is a noticeable drawback. The authors should explicitly add this to a "Limitations" section and discuss how the framework scales or how it will be validated on high-performance computing (HPC) or GPU clusters in the future.
Response 5: Following the recommendation, we added a discussion of computational constraints and how the proposed framework can be validated using the complete VNFCYBERDATA dataset on GPU clusters in the future in subsection 5.4 Limitations and Future Directions (page 31, lines 1081-1088 in the revised document).

Comments 6: Over-inclusive Abbreviations List - The Abbreviation list (Lines 1105–1106) includes entry-level, industry-standard networking terms such as IP, MAC, TCP, UDP, DNS, HTTP, GB, MB, GHz. To maintain a high academic standard, the list should be streamlined to feature only domain-specific or method-specific acronyms (e.g., NFV, VNF, PR-AUC, SHAP, MI-MAML, Optuna, SIEM).
Response 6: We agree, thank you for this suggestion as well. We have streamlined the abbreviation list to include only domain-specific and method-specific acronyms (see page 32, lines 1139-1140 in the revised document). Industry-standard networking and computing terms (e.g., IP, MAC, TCP, UDP, HTTP, DNS, DHCP, MB, GB, GHz, RAM, UTF, BGP, TLS) have been removed.

Comments 7: Limitation of the Explainability (SHAP) Analysis - In Lines 1047–1052, the authors acknowledge that due to the complexity of the Stacking meta-learner architecture, they only applied the SHAP framework to the three base ensemble models (Random Forest, XGBoost, CatBoost). This leaves the primary model of the study (the Stacked meta-learner) uninterpreted. Given that "Explainability Analysis" is featured prominently in the title, the authors need to either justify why base-model interpretation is sufficient to understand the meta-layer's behavior or try computing SHAP values directly for the meta-classifier (Logistic Regression), which accepts a linear combination of probabilities and should be inherently interpretable.
Response 7: Thank you for this valuable suggestion. The SHAP analysis of the stacked meta learner would primarily quantify the influence of each base learner instead of providing additional insights about the contribution of each feature to the final predictions. Based on your suggestion, we have decided to include this clarification in subsection 5.3 Model Explainability and Cyberattack Indicators (page 30, lines 1064-1071 in the revised document).

Reviewer 4 Report

Comments and Suggestions for Authors

The manuscript addresses a relevant and timely topic by evaluating machine learning-based cyberattack detection in Network Function Virtualization (NFV) environments. The use of ensemble models such as Random Forest, XGBoost, CatBoost, and a stacking-based meta learner is appropriate for the problem, and the inclusion of computational efficiency metrics and SHAP-based explainability strengthens the practical value of the study.

However, before publication, several aspects should be improved to enhance the scientific clarity, methodological rigor, and contribution of the manuscript:

1. Clarify the novelty of the study.
   The manuscript should more explicitly explain what differentiates this work from previous studies on ML-based intrusion detection, particularly in NFV environments. The authors should clearly state whether the main contribution lies in the dataset, preprocessing pipeline, model comparison, hyperparameter optimization, explainability analysis, or deployment-oriented efficiency evaluation.
2. Improve the abstract structure.
   The abstract is informative but could be more concise and better structured. It should clearly include the research problem, objective, methodology, main results, and practical implications. The current version mentions the models and metrics but does not provide specific numerical results, which would help readers understand the magnitude of the findings.
3. Provide more detail about the VNFCYBERDATA dataset.
   The authors should describe the dataset more thoroughly, including the number of instances, number of features, class distribution, types of attacks included, and whether the dataset reflects realistic NFV traffic conditions. Since the manuscript mentions imbalanced and high-dimensional data, the degree of imbalance should be explicitly reported.
4. Explain the preprocessing pipeline.
   The term “model-driven preprocessing techniques” requires clarification. The authors should specify which preprocessing steps were applied, such as normalization, encoding, feature selection, dimensionality reduction, class balancing, or data cleaning. It is also important to clarify whether preprocessing was performed within the training folds to avoid data leakage.
5. Strengthen the methodological description of Optuna optimization.
   The manuscript should provide details about the hyperparameter search space, number of trials, optimization objective, validation strategy, and stopping criteria. This would improve reproducibility and allow readers to assess the robustness of the optimization process.
6. Justify the selection of evaluation metrics.
   The chosen metrics are appropriate, especially PR-AUC and FPR for imbalanced cybersecurity datasets. However, the authors should explain why these metrics were selected and how they support decision-making in real NFV security environments.
7. Include statistical validation.
   The comparison among Random Forest, XGBoost, CatBoost, and the stacked meta learner would be stronger if supported by statistical significance testing or repeated cross-validation. This would help determine whether the observed differences in performance and efficiency are meaningful.
8. Expand the explainability analysis.
   The use of SHAP is valuable, but the manuscript should explain how SHAP results were interpreted and whether the identified features are consistent with known cyberattack behaviors in NFV environments. The authors should also discuss how explainability can support security analysts in practical deployment.
9. Discuss deployment implications.
   Since the study evaluates training speed, inference speed, memory usage, and serialized model size, the authors should expand the discussion on how these results relate to real-world NFV deployments, especially in resource-constrained or latency-sensitive environments.
10. Improve the conclusion and limitations section.
    The manuscript should include a clearer discussion of limitations, such as dataset dependency, potential generalization issues, lack of real-time deployment testing, and possible concept drift in network traffic. Future work should address online learning, adversarial robustness, and validation using additional NFV or cloud-native security datasets.

Comments on the Quality of English Language

The manuscript is generally understandable and the technical terminology is appropriate for the field of machine learning and cybersecurity. However, the quality of English requires moderate revision to improve clarity, fluency, grammar, and academic style.

Several sentences should be revised to avoid excessive length and improve readability. The authors should also check article usage, punctuation, subject–verb agreement, and consistency in the use of technical terms such as “meta learner,” “stacking-based model,” “NFV-specific traffic,” and “explainable AI.”

In addition, some expressions could be made more formal and precise for a scientific manuscript. A careful professional language review is recommended before publication to ensure that the methodology, results, and conclusions are communicated clearly and accurately.

Overall, the English is acceptable for review, but it would benefit from moderate editing by a fluent academic English speaker.

Author Response

Comments 1: Clarify the novelty of the study - The manuscript should more explicitly explain what differentiates this work from previous studies on ML-based intrusion detection, particularly in NFV environments. The authors should clearly state whether the main contribution lies in the dataset, preprocessing pipeline, model comparison, hyperparameter optimization, explainability analysis, or deployment-oriented efficiency evaluation.
Response 1: We thank the reviewer for this valuable suggestion. To address this, we have added a concise, bulleted list of contributions at the end of Introduction (page 1, lines 96-109 in the revised document). We now clarify that the novelty lies primarily in the integration of the mentioned points: VNF-specific dataset, reproducible preprocessing pipeline, deployment-oriented model comparison, automated hyperparameter optimization, and detailed explainability analysis. Additionally, we enhanced the conceptual contribution of the paper by expanding the Discussion section (page 29, lines 980-993 in the revised document), where we explicitly compared our findings with previous studies that used conventional networking datasets. Specifically, we explored the balance between computational efficiency and predictive performance and whether ensemble methods exhibit different predictive and inference time results in both conventional and NFV network environments.

Comments 2: Improve the abstract structure - The abstract is informative but could be more concise and better structured. It should clearly include the research problem, objective, methodology, main results, and practical implications. The current version mentions the models and metrics but does not provide specific numerical results, which would help readers understand the magnitude of the findings.
Response 2: We agree. Therefore, the abstract has been revised (lines 18-21, 24-30, and 31-35) per the reviewer's recommendation to more clearly present the research problem, objective, methodology, numerical results, and practical implications.

Comments 3: Provide more detail about the VNFCYBERDATA dataset - The authors should describe the dataset more thoroughly, including the number of instances, number of features, class distribution, types of attacks included, and whether the dataset reflects realistic NFV traffic conditions. Since the manuscript mentions imbalanced and high-dimensional data, the degree of imbalance should be explicitly reported.
Response 3: The dataset description was already provided in great detail in sections 3.1 Dataset Description and 3.2 Exploratory Data Analysis. To further address your concern and make the practical relevance more explicit, we have added a clarifying statement at the end of section 3.1 Dataset Description that indicates that the dataset is representative of realistic NFV traffic conditions and explains the rationale for this assessment (page 5, lines 262-266 in the revised document).

Comments 4: Explain the preprocessing pipeline - The term “model-driven preprocessing techniques” requires clarification. The authors should specify which preprocessing steps were applied, such as normalization, encoding, feature selection, dimensionality reduction, class balancing, or data cleaning. It is also important to clarify whether preprocessing was performed within the training folds to avoid data leakage.
Response 4: Full preprocessing pipeline has already been explicitly described in section 3.4 Data Cleaning and Preprocessing. We have also mentioned that MissForest imputer object was fitted exclusively on the training folds and subsequently applied to test data to prevent data leakage (e.g., see page 12, lines 429-431). Nevertheless, we included a statement (page 11, lines 413-415 in the revised document) which explicitly confirms that this strategy was performed for all preprocessing objects.

Comments 5: Strengthen the methodological description of Optuna optimization - The manuscript should provide details about the hyperparameter search space, number of trials, optimization objective, validation strategy, and stopping criteria. This would improve reproducibility and allow readers to assess the robustness of the optimization process.
Response 5: We have reviewed section 3.6.5 Hyperparameter Optimization and have to point out that the Optuna framework has already been thoroughly described, including the optimization objective (F1-score), validation strategy (10-fold StratifiedKFold cross-validation), number of trials (50 trials per model), and stopping criterion (termination after completion of the specified number of trials). To maintain the readability of the main text while ensuring strong methodological rigor, we provided a reference to Appendix A, where the complete hyperparameter search spaces and optimal configurations are given.

Comments 6: Justify the selection of evaluation metrics - The chosen metrics are appropriate, especially PR-AUC and FPR for imbalanced cybersecurity datasets. However, the authors should explain why these metrics were selected and how they support decision-making in real NFV security environments.
Response 6: To address this comment, we revised Section 3.7 Performance Evaluation Metrics by editing an introductory paragraph (page 15, lines 573-578) that justifies the selection of evaluation metrics in the context of cyberattack detection on imbalanced NFV traffic datasets. We have now specified that these metrics were selected because they provide a more informative assessment of model performance than overall accuracy in the presence of imbalanced classes, which is characteristic of the datasets used in this study. The selected metrics also support decision-making in real NFV security environments (e.g., FPR is discussed in the context of alert fatigue often present in SOCs), and are suitable for the datasets used in the study, as they are representative of real NFV traffic conditions.

Comments 7: Include statistical validation - The comparison among Random Forest, XGBoost, CatBoost, and the stacked meta learner would be stronger if supported by statistical significance testing or repeated cross-validation. This would help determine whether the observed differences in performance and efficiency are meaningful.
Response 7: Thank you for this valuable suggestion. We agree that statistical validation can further strengthen the results of our comparative analysis. Our work already employs 10-fold StratifiedKFold cross-validation, and we have clarified that all reported predictive performance and computational efficiency results represent averages across the validation folds (page 16, lines 641-644). While repeated cross-validation and statistical significance testing could provide additional evidence regarding the observed performance differences, incorporating these analyses would require a substantially expanded experimental campaign and is therefore identified as a direction for future work in section 5.4 Limitations and Future Directions (page 31, lines 1087-1090).

Comments 8: Expand the explainability analysis - The use of SHAP is valuable, but the manuscript should explain how SHAP results were interpreted and whether the identified features are consistent with known cyberattack behaviors in NFV environments. The authors should also discuss how explainability can support security analysts in practical deployment.
Response 8: Regarding explainability analysis, SHAP results were interpreted in detail in section 4.4. Model Explainability and Feature Attribution Analysis (page 20). Additionally, several paragraphs already map the identified indicators/features to known attack patterns in NFV (e.g., page 21, lines 762-766 and page 24, lines 815-818). Following the reviewer's suggestion regarding explainability in the context of security analysts' work, we added a few sentences that highlight how SHAP-based explainability can assist security analysts in SOCs by improving alert interpretability and incident triage efficiency (see page 30, lines 1035-1044 in the revised document). 

Comments 9: Discuss deployment implications - Since the study evaluates training speed, inference speed, memory usage, and serialized model size, the authors should expand the discussion on how these results relate to real-world NFV deployments, especially in resource-constrained or latency-sensitive environments.
Response 9: Thank you for this suggestion. To address this, we have expanded the Discussion section to include computational efficiency results in relation to practical deployment scenarios in NFV, including latency-sensitive services and resource-constrained environments (page 28, lines 968-972, page 29, lines 980-997).

Comments 10: Improve the conclusion and limitations section - The manuscript should include a clearer discussion of limitations, such as dataset dependency, potential generalization issues, lack of real-time deployment testing, and possible concept drift in network traffic. Future work should address online learning, adversarial robustness, and validation using additional NFV or cloud-native security datasets.
Response 10: Per reviewer's suggestion, the conclusion was expanded to include a reference to large-scale real-time deployment, adaptive online learning, robustness against adversarial threats, and validation across additional VNF-specific datasets (page 31, lines 1117-1122). Additionally, we included a statement that future studies should investigate the scalability and generalizability of the proposed framework using the complete VNFCYBERDATA dataset and additional security datasets. Finally, validation of results on GPU-accelerated clusters has also been proposed as future direction (page 30, lines 1081-1088).

In addition to the specific revisions described above, the manuscript has been carefully proofread and edited by a fluent English speaker to improve language quality.

Round 2

Reviewer 1 Report

Comments and Suggestions for Authors

The authors have addressed the reviewers' comments in this revision. The addition of a structured contribution list and the expanded discussion comparing findings across conventional and NFV-specific network environments represent meaningful improvements to the manuscript's clarity and positioning.

Author Response

We appreciate the acknowledgment that the revisions have improved the clarity and positioning of our paper. We sincerely thank the reviewer for their constructive comments and valuable feedback.

Reviewer 2 Report

Comments and Suggestions for Authors

Accept in present form.

Author Response

We sincerely thank the reviewer for their acceptance. We greatly appreciate the reviewer's time and constructive evaluation.

Reviewer 3 Report

Comments and Suggestions for Authors

Dear authors! Thank you for your work, but there are next aspects, which should be checked:

• Technical Rendering Defects in Appendix A: Hyperparameter tables still exhibit severe formatting issues, where underscores and equals signs have merged with text (e.g., min_samples_split t=16, max_leaf_nodes z=30, learning_rate e=0.2997). All LaTeX/Markdown notations must be thoroughly cleaned up.

• Anomalous RAM Consumption Metrics: The efficiency evaluation tables report RAM usage for the Stacked Learner exceeding 300,293 MB. This is physically impossible on the hardware configuration specified by the authors (a laptop with 16 GB RAM). There is a clear tracking or unit conversion error.

• Computational Environment Limitations: The authors openly admit to downsampling the VNFCYBERDATA dataset from 7 million records to roughly 260,000 records due to "resource constraints" of their local setup (Intel i5, 16 GB RAM). For a reputable journal, validating the framework on a stripped-down dataset due to weak hardware undermines the scientific validity. A proper high-performance computing (HPC) validation is required.

• Hardcoded Header Pagination Bug: The draft's running headers still duplicate a static page string (e.g., 2 of 35) across the entire document. The dynamic page counter template fields must be properly implemented.

• Deficiency in Explainability (SHAP) Coverage: Given that "Explainability Analysis" is explicitly highlighted in the title, it is a significant drawback that SHAP is applied exclusively to individual base models, leaving the core contribution of the paper—the Stacking meta-learner—completely uninterpreted.

• Over-inclusive Abbreviation List: The acronym definitions contain entry-level terms (IP, MAC, TCP, UDP, GHz, MB). These should be removed to keep the focus strictly on domain-specific terminology like NFV, VNF, PR-AUC, and SHAP.

Author Response

We appreciate the reviewer's comments. Since these comments are identical to the ones raised during the previous review round, we respectfully refer the reviewer to our previous response, where we provided a detailed explanation of the changes made in the revised manuscript. After re-examining the manuscript, we believe that the issues have been fully addressed. Thank you in advance.