\subsection*{Vulnex}\label{Vulnex}
The last tool presented in this section is called Vulnex \cite{vulnex_paper}, which stands for Vulnerability Explorer, a tool to audit software development organizations. Vulnex is designed for explore and assess the mitigation of OSS vulnerabilities, through a visualization of vulnerabilities related to the code, allowing the estimation of the overall risk exposure of development organizations. Nowadays, developers and security analysts in development companies require a well-defined analysis due to the widespread use of open-source components in various development areas.

\begin{figure}[h]
    \centering
    \includegraphics[scale=.26]{Figures/chapter4/Vulnex/Vulnex.png}
    \caption{Vulnex default view}
    \label{fig:vulnex}
\end{figure}

For its operation, the tool requires a previously conducted code analysis, specifically through Eclipse Steady \cite{eclipse_steady}, which supports static and dynamic analysis. Afterwards, by downloading the tool from the dedicated repository \cite{vulnex_github}, it is possible to connect it to the Steady backend using the appropriate settings and launch the Docker build, which will deploy the backend and frontend services of the application. Once the setup and launch are complete, the interactive visualization can be accessed through a web browser. By default, when downloading the application code, a demo mode is set, allowing the visualization of an analysis conducted by the developers on the public repository of the Eclipse Foundation \cite{eclipse_github}. The subsequent images will specifically pertain to this demo mode, given the inability to test personal codes, limitation that will be described later.

\begin{figure}[h]
    \centering
    \includegraphics[scale=.33]{Figures/chapter4/Vulnex/Vulnex_repository.png}
    \caption{Repository view}
    \label{fig:vulnex_repository}
\end{figure}
\begin{figure}[h]
    \centering
    \includegraphics[scale=.33]{Figures/chapter4/Vulnex/Vulnex_library.png}
    \caption{Library view}
    \label{fig:vulnex_library}
\end{figure}
\begin{figure}[h]
    \centering
    \includegraphics[scale=.33]{Figures/chapter4/Vulnex/Vulnex_bug.png}
    \caption{Bug view}
    \label{fig:vulnex_bug}
\end{figure}

After launching the application via the Docker container, we can see the main screen of the tool as shown in the figure (figure \ref{fig:vulnex}). In this case as well, we find a single-page view where in the center, we have the main view, while on the side and at the top, we have the available filter section and various visualization modes, respectively. The three different types of visualizations (Repository, Library, Bug) primarily differ in the order in which the dependency tree is calculated, allowing for differentiation between the different perspectives required for the analyses. An example of the different dependencies is shown in the figure (figure \ref{fig:vulnex_repository}, \ref{fig:vulnex_library}, \ref{fig:vulnex_bug}). Beside the visualization of the dependencies we find the number of occurrences of the vulnerabilities classified into 4 ranges (Low, Medium High and Critical), which refers to the National Security Database \cite{nist_site} for coloring. In addition to this representation, it is possible to obtain a distribution of the CVSS scores using the appropriate button which changes the display mode to a heatmap (figure \ref{fig:vulnex_heatmap}). Finally, for each repository, it is possible to inspect its structure through a tree representation, which shows the repository in question as a single vertex, the various modules related to it and finally the vulnerabilities present (figure \ref{fig:vulnex_tree}).

The tool, which aims to allow analysts to detect severe and relevant vulnerabilities and determine impacted libraries, modules, and repositories, has received positive evaluations from security experts who conducted the initial user feedback sessions. From their comments, it has also emerged that the visualizations that provide an overview of the general status were more utilized and preferred compared to specific detailed visualizations. In general, the positive evaluations align with the fact that the tool, through its various types of visualizations, can address different questions that analysts need to consider during their analysis, such as ``Which repositories contain the most severe vulnerabilities?", ``Which severe vulnerabilities are present?", or by simultaneously representing multiple projects, it can also answer questions like ``Which dependencies contain severe vulnerabilities and are often used across different applications?", thereby providing a more diverse and comprehensive analysis. Regarding the current limitations, when using the demo version, it can be observed that the data calculation timings are not optimized, requiring several minutes for the rendering process as shown in the figure. Additionally, compared to the presentation described in the paper, there are missing representations, such as the ``Meta information" matrix. Furthermore, a significant issue encountered during the usage test was the connection of the application with the Eclipse Steady backend, which prevented the loading of personal projects, despite similar problems being addressed through the GitHub page's issue section by other community users. The dependency on Steady also presents another limitation of the application, as it requires a prior code analysis, and the exclusivity of the connection with Steady only provides utility for applications written in Java and Python, thus not covering a wide range of solutions adopted by development companies.

In terms of the tool's development process, we can identify the main phases described in previous chapters. For the \emph{Visualization Goals} definition phase, there were collaborations between the tool developers and industry experts such as security analysts and software developers. Among the objectives defined in this phase, we can find references to goals such as ``provide views to detect vulnerable repositories and projects to apply countermeasures" and ``the tool needs to show the impact of specific bugs on the organization's codebase", which by the same experts have been defined as achieved by the described version of the tool. In the subsequent \emph{Data Preparation} phase, as mentioned above, the developers chose the public repository of the Eclipse Foundation as the reference dataset and during the data cleaning sub-phase, they replaced the original repository and module names with pseudonyms to avoid attributing problems to individual projects. For the subsequent two phases, \emph{Exploration} and \emph{Visualization}, specific details are not provided as the choice of a simple visualization type does not require extensive studies, as an example, the color scheme used, dictated by the National Security Database, leverages an already defined standard.In this last phase, \emph{Feedback and fine-tuning}, similar to the entire development process, collaboration with domain experts is emphasized which, in addition to providing positive evaluations on the usefulness of the tool, also offer critical feedback aimed at improving or adding functionalities, such as ``adding additional information about the open-source libraries to the tool", or provide guidance on how to resolve critical vulnerabilities, given the need to resolve these vulnerabilities within several hours. Despite this feedback, it is noticeable that there have been no changes regarding these functionalities in the repository, although there have been recent updates in the past few months, they primarily focus on improving the codebase and do not include any modifications to its functionality.

\begin{figure}[h]
    \centering
    \includegraphics[scale=.26]{Figures/chapter4/Vulnex/Vulnex_heatmap.png}
    \caption{Heatmap View}
    \label{fig:vulnex_heatmap}
\end{figure}

\begin{figure}[h]
    \centering
    \includegraphics[scale=.26]{Figures/chapter4/Vulnex/Vulnex_tree.png}
    \caption{Vulnex Repository Tree view}
    \label{fig:vulnex_tree}
\end{figure}
\FloatBarrier

