Ticket Aggregation: Grouping Vulnerabilities for Efficient Management

This section explains how to use the Ticket Aggregation settings to group vulnerabilities across scans and assets.

Ticket Aggregation allows you to streamline your workflow by grouping similar vulnerabilities into single tickets, making tracking and resolving security issues easier. This is especially useful when dealing with multiple applications, platforms, and environments (like production and testing).

The benefits of ticket aggregation:

Track the status of a vulnerability through multiple scans, application versions, platforms, etc.
No need for manual work to identify duplicates or new items or to remark an issue as an Exception or False positive.
Seamless integration with your ticketing system

There are two primary modes to group your tickets:

Platform Groups: This option allows you to define groups of platforms, such as combining "Android File" and "Android Store" into a single "Android" aggregation group. This is ideal for managing vulnerabilities that affect all applications deployed on a specific platform.
Application Groups: This option allows you to define groups based on specific application identifiers, like "android:com.myapp.prod" and "android:com.myapp.test". This is suitable for grouping vulnerabilities across different versions or environments of the same application.

Examples

You have a mobile application available on both Android and iOS. For the Android version, you scan the application from the Android store ("PlayStore") and you need to scan the "Android File" (APK file) to validate the ongoing developments. For the iOS version, you scan the application from the iOS store ("AppStore") and you need to scan the "iOS File" (IPA file) to validate the ongoing developments.

Let's say my application has the same vulnerability, "Insecure Data Storage" in my application (Both Android and iOS).

Option 1: I would like to aggregate each platform ticket separately. It means I will have four tickets: one for the Android file another one for the Android store, the iOS file and the iOS store.

To do so, can use the platform grouping option. You need to define four groups. Group 1 will contain android, Group 2 for android_store, Group 3 for ios and group 4 for ios_store.

You can refer to how to configure the aggregation ticket by platform, Once I fix the issue in the file version, I will scan it and the Ostorlab platform will automatically detect that the issue is fixed and will mark the two tickets as Fixed_verified. Then, I can upload my file to the store and run the scan, which will also updates the store tickets to mark them as fixed and verified.

Application ID	Platform	Vulnerability	Ticket ID
`android:com.myapp`	Android Store (PlayStore)	Insecure Data Storage	Ticket #001
`android:com.myapp`	Android File (APK)	Insecure Data Storage	Ticket #002
`ios:com.myapp`	iOS Store (AppStore)	Insecure Data Storage	Ticket #003
`ios:com.myapp`	iOS File (IPA)	Insecure Data Storage	Ticket #004

Option 2: I would like to aggregate Android scans together, no matter if they are for the file or the store. I also would like to aggregate the iOS tickets regardless of whether they are from the file, the store or testflight.

For that you can use the platform grouping option. You need to define two groups. Group 1 will contain android and android_store and Group 2 will contain ios, ios_store and ios_testflight.

If you scan the application from the different sources, you will have only two tickets. One ticket for Android will reference the two scans from the file and from the store. The same goes for the iOS ticket.

Application ID	Platform	Vulnerability	Ticket ID
`android:com.myapp`	Android Store (PlayStore)	Insecure Data Storage	Ticket #001
`android:com.myapp`	Android File (APK)	Insecure Data Storage	Ticket #001
`ios:com.myapp`	iOS Store (AppStore)	Insecure Data Storage	Ticket #002
`ios:com.myapp`	iOS File (IPA)	Insecure Data Storage	Ticket #002

The moment you fix the issue in the APK file and scan it, the ticket will remain open until you upload the file to the store and scan it.

However, if you scan the store directly with a higher version than the file, the platform will understand that you fixed the file and uploaded a higher version. The ticket will be marked fixed_verified even if you did not run the file scan before.

Option 3: I would like to aggregate my mobile application by platform and environments.

You have production and testing versions of your Android app with application IDs of com.company.myapp.prod and com.company.myapp.test, respectively. I would like to have one ticket for the vulnerability "Insecure Data Storage" whether I scan the prod or the test version and either from the file or the store.

For that, you need to use the Application ID grouping. You can define one group with the following items android:com.company.myapp.prod, android:com.company.myapp.test and android_store:com.company.myapp.prod. You can also use a regex to define the different environments: android:com.company.myapp.* and android_store:com.company.myapp.*.

You can refer to how to configure the aggregation ticket by application id

With this configuration, you will have one ticket for the three scans Android files com.company.myapp.prod com.company.myapp.testing or Android Store com.company.myapp.prod.

Application ID	Platform	Vulnerability	Ticket ID
`android:com.myapp.prod`	Android Store (PlayStore)	Insecure Data Storage	Ticket #001
`android:com.myapp.prod`	Android File (APK)	Insecure Data Storage	Ticket #001
`android:com.myapp.test`	Android File (APK)	Insecure Data Storage	Ticket #001

To have the ticket fixed and verified, it should be fixed in the two environments.

Key Considerations:

The selection of "Platform Groups" vs. "Application Groups" depends on your specific organizational structure and how you prefer to manage vulnerabilities.

You can change from one configuration to another; however, every time you change the configuration, the old tickets are closed, and new ones matching the new configuration get created.