Microsoft recently released the Microsoft Application Inspector, open-source software for static code analysis.

The main difference from the existing static analysis solutions like SonarQube or Fortify is Application Inspector doesn’t assess how bad or good your code. It just provides you a retrospective overview of what your code exactly is. It tells you: “look what interesting we have here” rather than “look how good/bad this code”.

Installation

This is an overviewed article with the goal to see what is the tool and what interesting it can find. I’m just going to run this tool and review a couple of open source projects trying to find something interesting there.

If you review installation details for the ApplicationInspector you will realize you need the .Net environment as a prerequisite for installation. As per the installation guide .Net Core 3.1 has to be installed to successfully run Application Inspector.

I’m going to use Docker to perform the installation of .Net Core 3.1 and Application Inspector.

I created ~/projects/ms-app-inspector-test folder for my experements and Dockerfile there.

Dockerfile

FROM mcr.microsoft.com/dotnet/core/sdk
RUN dotnet tool install --global Microsoft.CST.ApplicationInspector.CLI
ENV PATH $PATH:/root/.dotnet/tools
CMD ["/bin/bash"]

In the Docker file above I use a basic image for .Net Core

FROM mcr.microsoft.com/dotnet/core/sdk

and install ApplicationInspector there

RUN dotnet tool install --global Microsoft.CST.ApplicationInspector.CLI

Building the Docker image:

docker build -t ms-app-inspector .

and running it in an interactive mode:

docker run -v ~/projects/ms-app-inspector-test:/root/ms-app-inspector-test -it ms-app-inspector

There is

-v ~/projects/ms-app-inspector-test:/root/ms-app-inspector-test

for mapping /root/ms-app-inspector-test folder in Docker instance to folder ~/projects/ms-app-inspector-test on the host machine.

So, now we should be able to run Application Inspector in Docker instance:

>appinspector

Analysis

Now I’m going to analyze a couple of projects:

• Spring Boot
• Google Tink
• Apple Servicetalk
• Microsoft ApplicationInspector

I have all these projects copied to ~/projects/ms-app-inspector-test folder on the host machine.

drwxr-xr-x 9 ilya ilya 4096 Mar 18 11:36 ApplicationInspector-master/
-rw-r--r-- 1 ilya ilya 164 Mar 19 12:50 Dockerfile
drwxr-xr-x 58 ilya ilya 4096 Mar 18 21:24 servicetalk-master/
drwxr-xr-x 12 ilya ilya 4096 Mar 19 10:30 spring-boot-master/
drwxr-xr-x 18 ilya ilya 4096 Mar 17 16:23 tink-master/

Now I going to analyze every project in the folder and then review reports. For analysis, we need to specify what should be analyzed:

Let’s start from the Spring Boot project:

>appinspector analyze -s ~/ms-app-inspector-test/spring-boot-master/

Ooops, something doesn’t work. Let’s run with Debug logger level:

>appinspector analyze -s ~/ms-app-inspector-test/spring-boot-master/ -v Debug

and see what is going in logs:

>more /root/.dotnet/tools/.store/microsoft.cst.applicationinspector.cli/1.1.16/microsoft.cst.applicationinspector.cli/1.1.16/tools/netcoreapp3.1/any/log.txt

For some reason, the path is excluded:

Okay, let suppress file path exclusion logic and try to run analysis one more time:

>appinspector analyze -s ~/ms-app-inspector-test/spring-boot-master/ -k none

Looks better now:

There is one issue: when HTML report format (default) is used there is no way to specify an output directory for the file. So, let’s try to copy the report manually:

>cp /root/.dotnet/tools/.store/microsoft.cst.applicationinspector.cli/1.1.16/microsoft.cst.applicationinspector.cli/1.1.16/tools/netcoreapp3.1/any/output.html ~/ms-app-inspector-test/spring-boot-master/

As an alternative, the report can be created in text and JSON formats, but I’m not going to cover this in the current article.

Now, let’s run ApplicationInspector to analyze all projects in the folder:

Google Tink

>appinspector analyze -s ~/ms-app-inspector-test/tink-master/ -k none
>cp /root/.dotnet/tools/.store/microsoft.cst.applicationinspector.cli/1.1.16/microsoft.cst.applicationinspector.cli/1.1.16/tools/netcoreapp3.1/any/output.html ~/ms-app-inspector-test/tink-master/

Apple ServiceTalk

>appinspector analyze -s ~/ms-app-inspector-test/servicetalk-master/ -k none
>cp /root/.dotnet/tools/.store/microsoft.cst.applicationinspector.cli/1.1.16/microsoft.cst.applicationinspector.cli/1.1.16/tools/netcoreapp3.1/any/output.html ~/ms-app-inspector-test/servicetalk-master/

Microsoft Application Inspector 

>appinspector analyze -s ~/ms-app-inspector-test/ApplicationInspector-master/ -k none
>cp /root/.dotnet/tools/.store/microsoft.cst.applicationinspector.cli/1.1.16/microsoft.cst.applicationinspector.cli/1.1.16/tools/netcoreapp3.1/any/output.html ~/ms-app-inspector-test/ApplicationInspector-master/

It’s time to go and see reports created. Let’s do in the order of how they were created. Spring Boot goes first:

Oh, again something wrong. The report has broken links to the resources.

So, let’s do the quick and dirty trick to fix our reports. All that is needed is just copy missed resources from the ApplicationInspector folder to the place where our reports are located:

>cp -r /root/.dotnet/tools/.store/microsoft.cst.applicationinspector.cli/1.1.16/microsoft.cst.applicationinspector.cli/1.1.16/tools/netcoreapp3.1/any/html/ ~/ms-app-inspector-test/spring-boot-master/
>cp -r /root/.dotnet/tools/.store/microsoft.cst.applicationinspector.cli/1.1.16/microsoft.cst.applicationinspector.cli/1.1.16/tools/netcoreapp3.1/any/html/ ~/ms-app-inspector-test/tink-master/
>cp -r /root/.dotnet/tools/.store/microsoft.cst.applicationinspector.cli/1.1.16/microsoft.cst.applicationinspector.cli/1.1.16/tools/netcoreapp3.1/any/html/ ~/ms-app-inspector-test/servicetalk-master/
>cp -r /root/.dotnet/tools/.store/microsoft.cst.applicationinspector.cli/1.1.16/microsoft.cst.applicationinspector.cli/1.1.16/tools/netcoreapp3.1/any/html/ ~/ms-app-inspector-test/ApplicationInspector-master/

Now, everything looks good:

Let’s see the project info for all our projects.

Spring Boot

Based on project info we could say that is Java application, used Gradle and/or Maven for build and possibly some components are written on different languages like Groovy, Ruby, Javascript and etc.

Google Tink

This is an application written on different languages, based on the ratio of the languages it could be the same functionality implemented using different languages. So, it could be some kind of utility library.

Apple Servicetalk

This is a Java application for sure, Gradle is used as a build tool and Groovy possibly for testing.

Microsoft ApplicationInspector

This is a .Net application, which possibly has two modules: front-end and back-end parts. A front-end part is written with the usage of Typescript and Javascript when the backend part is C#.

Let’s review feature groups now.

Spring Boot

 

Interesting facts identified you can find below.

Rule: Cloud Service: Hosting (Amazon Web Services)
File: spring-boot-project/spring-boot/src/test/java/org/springframework/boot/cloud/cloudfoundry/CloudFoundryVcapEnvironmentPostProcessorTests.java:93

+ "\"hostname\":\"mysql-service-public.clqg2e2w3ecf.us-east-1.rds.amazonaws.com\","

Successfully identified AWS endpoint used in testing.

Rule: Hygiene: Suspicious Comment
File: ci/images/docker-lib.sh:72

server_args="${server_args} --insecure-registry ${registry}"

Sorry, but there is no comment. This is a false positive.

Rule: Data: Financial (Credit Card)
File: spring-boot-tests/spring-boot-smoke-tests/spring-boot-smoke-test-data-jpa/src/main/resources/import.sql:186

insert into review(id, hotel_id, idx, check_in_date, rating, trip_type, title, details) values (63, 27, 1, '2006-02-20', 0, 0, 'Avoid', 'This place is the pits, they charged us twice for a single night stay. I only got refunded after contacting my credit card company.')

Even if the ‘credit card’ word group is used there, there is no information related to the credit card. This is a false positive.

Google Tink

If we check Cryptography rules we could see:

Wow, this tool must be something to do with cryptography. Based on previous analysis this could be a library with cryptographic functionality implemented for different languages.

Apple Servicetalk

Rule: CloudServices: Financial (eCommerce)
File: servicetalk-http-api/src/main/java/io/servicetalk/http/api/HttpResponseStatus.java:202

/**
* 402 Payment Required
*
* @see <a href="https://tools.ietf.org/html/rfc7231#section-6.5.2">RFC7231, section 6.5.2</a>
*/
public static final HttpResponseStatus PAYMENT_REQUIRED = new HttpResponseStatus(402, "Payment Required");

Difficult to say something about this application, possibly it could be payment client for some service.

Microsoft ApplicationInspector

So, you definitely know for what Microsoft ApplicationInspector is used and highly possible that you are familiar with the Spring Boot project, but try to guess what is Google Tink and Apple Servicetalk based on reports above.

If you want to play with ApplicationInspector here the link:

https://github.com/microsoft/ApplicationInspector

PS: if you look carefully at Feature Groups part of the report and thumbnails, especially the ‘OS Integration’ section you can see Tux there. This is a little bit unexpected for me to see Linux mascot there. I wouldn’t be surprised to see Windows sign there, but not Tux. Anyway, I think this is a good sign.