\subsection*{CodePulse}\label{code_pulse}
Code Pulse \cite{codepulse_site} is a tool developed by Secure Decisions and OWASP that provides insight into the real-time code coverage of testing activities. Code Pulse automatically detects coverage information while the tests are being conducted and even makes it possible to understand the overlaps and boundaries of the code coverage achieved by different testing activities. The application allows you to analyze both Java and .NET projects through its passive monitoring conducted in parallel with manual or automatic tests. The main screen is divided into two different views, where the first on the left shows the structure and the related dependencies of the application, while the second on the right shows the coverage obtained from the tests through a TreeMap view of the classes.

TreeMap visualization is a widely used technique for representing hierarchical data in a compact manner. The technique involves organizing data into nested rectangles, with each rectangle representing a node in the hierarchy where the size and the color of each rectangle can be used to represent different attributes of the data, such as the size or importance of each node. The TreeMap visualization is particularly useful for visualizing large and complex datasets, as it allows users to quickly identify patterns and relationships in the data. The hierarchical structure of the visualization also makes it easy to explore the data at different levels of detail, from the overall structure of the hierarchy down to individual nodes and attributes. In Code Pulse's case, its displayed only selected content from the application inventory.

A demo application \cite{contoso_university_site} developed by Microsoft known as Contoso University was used for the test. ContosoU, as it is named in the screenshots, is a sample application that demonstrates how to use Entity Framework Core in an ASP.NET Core MVC web application. For the first part of the analysis, the project zip archive was uploaded to the application and the structure skeleton was rendered without providing further information. The next step was to connect the project application running to Code Pulse, in this case via the Code Pulse .NET Tracer. In this case the test was conducted only in manual mode, browsing through the various pages of the web application. In the first image (figure \ref{fig:CodePulse1}) can be seen the initial phase, where only a few pages were visited and only a few rectangles representing the coverage were covered. In the second (figure \ref{fig:CodePulse2}), more pages were visited, more courses were added and removed calling various APIs, and the relative test cases were updated in the TreeMap view. As shown the mouse cursor can be used for display information about the classes and in the image it's used for inspect the class that has not been triggered by tests.

One of the main strengths of Code Pulse is real-time analysis, since most penetration testing tools typically evaluate and present results at the conclusion of a testing run, rather than while the tester is immersed in the testing activity, which also results in reduced analysis times and consequently on the related costs. The rapidity of understanding the analysis is certainly also given by the approach used to show the coverage. In this case the choice, not only to use a visualization method, but to select a non-classical methodology such as the TreeMap has made it possible to obtain an impact on the communication and understanding of the data which in most of the tools are represented in a textual or indicated with simple symbols. However, despite its many advantages, the TreeMap visualization does have some limitations. For example, the technique can be difficult to interpret for users who are not familiar with hierarchical data structures, and it may be less effective for visualizing non-hierarchical data. One big downside of the application lies in its initial setup configuration. If on the one hand, once correctly activated, the tool works in a mode that we can define as semi-automatic, this comes at the expense of the connection phase between the application and the Code Pulse tracer which, depending on the type of application, can be more or less complex depending on the type of application you are working on.

\begin{figure}[ht]
    \centering
    \includegraphics[scale=.25]{Figures/chapter4/CodePulse/CodePulse_img1.png}
    \caption{Code Pulse}
    \label{fig:CodePulse1}
\end{figure}
\begin{figure}[ht]
    \centering
    \includegraphics[scale=.25]{Figures/chapter4/CodePulse/CodePulse_img2.png}
    \caption{Code Pulse and the Application running}
    \label{fig:CodePulse2}
\end{figure}


Thanks to his research paper \cite{codepulse_paper} we can make a first comparison between a developed solution and the framework proposed by Balakrishnan and mentioned in the chapter \ref{The SANS Framework}. For the first phase, i.e. defining the \emph{Visualization Goals}, the developers immediately clarify how there were two primary concerns in their objectives: how best to identify the coverage data; and how best to communicate it to the users. For the next phase of \emph{Data Preparation} no specific information is provided but an evaluation that was conducted by the developers concerns the disparity of two different points of view which are respectively the analysis of the application's source code and the analysis of the sitemap and its corresponding URL-set, which do not always translate directly to each other. In this phase, therefore, it was decided to concentrate on the analysis of the source code, postponing the other type of analysis to a future version.

Subsequently, in the paper not enough information is provided on the selection process of choosing the TreeMap as a visualization methodology, so in this case we can only assume that the \emph{Exploration} phase occurred due to the targeted and uncommon choice, but there is no evidence. As far as the \emph{Visualization} phase is concerned, the only possibility of modifications concerns only the color that the various rectangles could have, given that the other characteristics such as shapes and dimensions are dictated by the logic with which the TreeMap is developed. In this case it was decided that the different analyzes had different colors, with the possibility of personalization left to the user and consequently also allowing a more direct comparison between the methodologies during use, leaving only white as the standard colour, for the cases in which the tests are not covered by the coverage, and gray, for the case in which the tests are covered by the single coverage in the case of a single analysis or by all the coverages in the case of multiple analyses. No information is provided for the final stage of \emph{Feedback and fine-tune}. However, analyzing the final part of the conclusions and the current state of the tool, we can state that the tool has evolved allowing the analysis not only of Java projects but also of .NET projects as described above, resulting in improvement and update of the application. Thanks to this feedback, we can see how much this last phase is the most uncertain given the possible and varied developments that the various applications may undergo due to their different typology.


