# KubeHound: Detecting Microservices' Security Smells in Kubernetes Deployments
## 7 Conclusions  
We showed that the task of automatically detecting the security smells listed by [PERSON] et al. [1] is actually possible, and we presented a first set of analysis techniques enabling the detection of instances of such smells in microservice applications deployed with Kubernetes. We also provided a first tool supporting automated security smell detection, called KubeHound, which already features a subset of the presented smell-detection techniques and whose design is modular and extensible to enable extending it to provide a more comprehensive coverage of microservice security smell detection. We finally assessed our approach and tool in practice by applying KubeHound to controlled experiments and case studies based on two third-party applications.  
Our work can help researchers and practitioners better understand how security smells [1] can be identified in microservice applications. They can also exploit KubeHound to automatically detect instances of such security smells in their microservice applications, if deployed with Kubernetes. The coverage of detected smell instances is, however, currently limited to the built-in plugins presented in Section 5.3. For this reason, we are already working on extending KubeHound to feature all the analysis techniques in Section 4 as built-in plugins. We also plan to investigate new analysis techniques to provide a more comprehensive coverage of the the possible instances of already-known security smells [1], as well as to enable the incorporation of newly discovered security smells, if any.  
It is worth noting that KubeHound is \"best effort\", meaning that it runs a smell-detection technique only if all the resources it needs are available. This obviously limits the set of detected smell instances to only those that can be detected with the inputs provided to KubeHound. At the same time, it enables end-users to provide only what they wish to be analysed, e.g., enabling KubeHound to work if the source code of some microservices is not available or if users do not wish KubeHound to interact with a running instance of the target microservice application. The choice of a \"best effort\" approach was motivated to enhance the usability and applicability of KubeHound. We plan to further improve such usability and applicability, e.g., by devising a graphical user interface and by enabling it to work with other container-orchestration frameworks or API-specification languages. We also plan to improve the performance of KubeHound, e.g., by enabling the parallel execution of the smell-detection techniques. Finally, we plan to further support end-users by devising a confidence level to be attached to the detected security smells. This would help assess how likely is that any security smell detected by KubeHound represents a security problem in the application.  
Conceptualization, G.D., J.S. and A.B.; Methodology, G.D., J.S. and A.B.; Software, G.D. and J.S.; Validation, G.D.; Investigation, G.D., J.S. and A.B.; Writing--original draft preparation, J.S.; Writing--review and editing, G.D., J.S. and A.B.; Supervision, J.S. and A.B.; Project administration, A.B. All authors have read and agreed to the published version of the manuscript.  
This research received no external funding.  
Data Availability Statement: No new data were created or analyzed in this study. Data sharing is not applicable to this article.  
The authors declare no conflict of interest.