# Bridging the Gap: A Survey and Classification of Research-Informed Ethical Hacking Tools
## 6 Evaluation
### Recommendations  
To improve the dissemination and enhance the impact of research on the wider community of practitioners, we suggest that researchers should:  
* Distribute the software as open source without exception and keep the software repository alive. Otherwise, it would be impossible for any dissemination within the practitioner community [152]. * Clearly specify the licence type and adopt standard FOSS licences [153], like GNU GPLv3, so that users may know precisely what they can do with the tools. * Produce comprehensive documentation and tutorials on how to use the tools. Currently, this is partially conducted, but the existing documentation is primarily intended to support the peer-review process, as noted by [PERSON] (2020) [154]. * Try to maintain the software by implementing bug fixes and improvements after publishing the paper. This is particularly challenging for academic projects as they \begin{table}
\begin{tabular}{l c c} \hline \hline
**\%** _of Project Activity_ & _No_ & \% \\ \hline
0–0 & 5 & 8.47\% \\ \hline
1–25 & 12 & 20.34\% \\ \hline
26–50 & 15 & 25.42\% \\ \hline
51–75 & 5 & 8.47\% \\ \hline
76–99 & 2 & 3.39\% \\ \hline
100–100 & 20 & 33.90\% \\ \hline _Total_ & 59 & _100.00\%_ \\ \hline \hline \end{tabular}
\end{table} 
Table 6: Distribution of project activity within 3 years after release. \begin{table}
\begin{tabular}{l c c} \hline \hline \multicolumn{3}{l}{**(a)** Distribution of Period of Project Activity (last—first _commit_)} \\ \hline _Period (Months)_ & _No._ & \% \\ \hline
0–3 & 19 & 32.20\% \\ \hline
4–6 & 3 & 5.08\% \\ \hline
6–12 & 6 & 10.17\% \\ \hline
13–24 & 6 & 10.17\% \\ \hline
25–36 & 10 & 16.95\% \\ \hline
37–60 & 8 & 13.56\% \\ \hline
61-inf & 7 & 11.86\% \\ \hline _Total_ & 59 & _100.00\%_ \\ \hline \hline \multicolumn{3}{l}{**(b)** Distribution of Number of Project’s _Commits_} \\ \hline _Commits Range_ & _No._ & \% \\ \hline
1–10 & 17 & 28.81\% \\ \hline
11–50 & 19 & 32.20\% \\ \hline
51–100 & 4 & 6.78\% \\ \hline
101–250 & 6 & 10.17\% \\ \hline
251-500 & 5 & 8.47\% \\ \hline
501-inf & 8 & 13.56\% \\ \hline _Total_ & 59 & _100.00\%_ \\ \hline \hline \end{tabular}
\end{table} 
Table 5: Distribution of project activity and _commits_. operate with limited availability of human resources and funding. Once the project ends or the paper is published, the interest of the researcher tends to move to new projects [152]. * Some tools may become obsolete for several reasons: incompatibility with more recent versions of other software (OSs, libraries, applications, etc.) or the vulnerability covered by the tool being patched. In those cases, the authors should update the documentation and clearly specify the requirements, scope, context and limitations of the tool. * Try to implement their solutions in modular tools utilised by practitioners like Metasploit and Nmap. While this can be possible for certain solutions, in general, some tools are so different and innovative that they cannot fit into the API of existing tools. * Consider that public dissemination mitigates the risk of weaponising tools by promoting a level-playing field approach. Another question is: what can practitioners and industry do? We cannot expect many individual practitioners to engage directly with the research outputs except when driven by intellectual curiosity. However, the IT and cybersecurity industry should try to incentivise collaboration with academia. Industry and venture capitalists likely monitor academic research to understand the state-of-the-art and gain inspiration for new ideas. However, more effective engagement from the industry may help academic research to enhance its impact. For example, the industry currently invests in bug bounty programs, providing monetary incentives to security researchers to identify and report vulnerabilities. This informs bug fixes and improves the quality of the product overall. However, this process is typically ex-post and not something an academic researcher would be directly involved in, except if finding a bug is a by-product of the research work.