Overview

Tags are a way to systematically identify common and specific features for well-known programming API's, functions and more into recognizable features and meta-data. They are named using a structured and hierarchical dot based method and represent a friendly and easier way to refer to a rule over an ID number or name.

The 'tags' field is part of the Rules schema and is used to define these values.

Tags definitions start with an outer common parent name or root designation like "OS" or "Cryptography" followed by an ever increasing level of specificity or subnaming e.g. OS.Networking.Connection like these shown below.

The complete default supported set of defined tags can be obtained by running the exporttags command mentioned in the help or readme.md or here at the time of this posting AppInspectorTags.

When searching for common features like 'Networking' in the report results, all identified types of networking can be easily found by searching on the root name because of this structured naming, while allowing for specific types of connections like 'Http' to return just Networking.Connection.Http.

You can even add your own tags as you define new Rules. However, there are minimal but key scoping aspects to be aware of for achieving the maintaining a high level of accuracy in the report results as explained further in the sections below.

Metadata vs Features

Features represent executable programming logic, functions or API's. Metadata is information about the source code or project that is valuable in identifying build or config aspects about the software, but is not an executable feature of the code at run-time. Metadata tags have a root name that starts with "Metadata" to ensure better separation of build metadata from executable features. Tags that do not have a Metadata root are considered features.

Features

Authentication.SAML
Authorization.Claims
Authorization.General

Metadata

Metadata.Application.Author
Metadata.Application.BuildOutput.Category
Metadata.Application.Description
Metadata.Application.Name
Metadata.Application.Publisher
Metadata.Build.Microsoft.AzurePipelines
Metadata.Development.Build.Bamboo
Metadata.Development.Build.Gradle
Metadata.Development.Build.Grape
Metadata.Development.Build.VisualStudio
Metadata.Development.PackageManager.Microsoft.NuGet
Metadata.Development.PackageManager.NPM
Metadata.Development.PackageManager.PyPI etc..

Counters

Certain types of meta-data identified by the tool are best categorized and reported as simple metrics such as the number of classes, functions or similar statements that were found to get an idea about complexity or simply whether they were detected. Custom rules can be added defining additional things to count by including "Metric" as a component in the tag. For example: Metric.Foo, Foo.Metric.Bar and Foo.Bar.Metric are all valid metric tags.

Note that groups or tag patterns that contain the value "metric" such as "Metric.Code.Class.Defined" are not supported in the HTML "Features" report page** which is based on detailed matches not counters. Counters do appear in the Summary Tag Counters area or in other report formats simply as "counters". This is to distinguish features that represent an action or behavior from simple characteristics about the code.

Tag Naming and Scope

Application Inspector 1.0.20 and above uses the 'Metadata' naming shown here to sets limits when scanning files to prevent features (tags without 'Metadata' in their name structure) from being detected in build files e.g. pom.xml, .yaml, package.json or similar. This is to reduce the possibility of false positive matches of features in build files i.e. those which should only be identified in executable code.

A build.xml or pipeline file (yaml) may include cryptographic references related to code signing or hosting information such the name of a source code repository where the code lives that otherwise could be detected as a feature. Making sure the rules and related tags in them accurate reflect what type of pattern is represented either a feature or metadata is important to the quality of the scans.

Summarizing

Rules with tag values that represent features (those without Metadata in the name) may only be detected in code files e.g. language files like C, C++ (cpp) not build files.
Rules with tag values that represent metadata as designated by the word 'Metadata' in the name, may be detected in either build or code files.

See the applies_to section for more important information on how tags are related to language file types.