Managing an Effective Vulnerability Ticketing System with Ostorlab

Discovering vulnerabilities is just the beginning of a - often - long journey to remediate, deploy, and validate security fixes.

This journey can quickly become tedious if you do not have the right tooling to streamline the process and integrate detection, remediation, and fix validation into the lifecycle of remediation management.

Traditional ticketing systems often require significant manual effort to triage new issues, identify duplicates, and manage false positives. Large organizations will sometimes have a person or a team dedicated to the sole task of triaging findings from scanners and ensuring duplicates are removed. A glamorous task that many dread immensely.

According to a 2022 study conducted by ServiceNow, organizations spent an average of 443 hours per week on vulnerability management activities, equivalent to about 11 full-time employees.

One of the core features of the Ostorlab platform is its comprehensive ticketing system, which is tailored for vulnerability management. It has been built and thought from the ground up to address the challenges of handling the lifecycle of vulnerability fixing.

The Ostorlab ticketing system was released in October 2021. It helped more than 10.000 organizations to automate and streamline the entire process of managing and remediating security vulnerabilities.

The core features of the Ostorlab ticketing system include:

• Automatically generate tickets for newly detected vulnerabilities and embed detailed information such as type, severity, and context.
• Aggregating recurring vulnerabilities into a single ticket using a unique identifier (DNA),
• Fixed vulnerabilities are automatically verified through rescans, ensuring issues are resolved effectively.
• Enforces patching policies with Service Level Objectives (SLOs), such as resolving high-severity issues within five days.
• Seamless compatibility with tools like Jira allows organizations to manage vulnerabilities within their existing workflows.

In 2024, Ostorlab’s customer had a mean time to remediation (MTTR) of 17 days, with only 5 days for Critical issues and 10 days for High-security issues.

While the initial version of the ticketing system brought an innovative approach to aggregating tickets based on a unique DNA, the continuous user feedback helped identify new challenges that developers and security teams face while managing the vulnerabilities across different environments and platforms.

Today, we announce the release of the Ostorlab ticketing system V2, which addresses those challenges and brings more flexibility to how we can aggregate tickets across different environments and platforms.

The challenges

Tracking the status of a vulnerability across multiple versions and platforms is difficult and can lead to inconsistent remediation efforts.

For example, if you have a mobile application on Android and iOS, the application's development lifecycle typically has four steps: dev version, staging, pre-prod, and prod.

In this scenario, a single vulnerability could potentially generate up to 8 separate tickets (2 platforms x 4 lifecycle stages), creating a logistical hassle for security teams trying to manage and remediate issues effectively.

This fragmented approach often results in vulnerabilities being fixed inconsistently across different environments or platforms. For instance, a critical security flaw might be patched in the Android production version but overlooked in the iOS staging environment.

How the Ostorlab Ticket System V2 is solving these issues?

Instead of using pre-defined logic to aggregate the tickets, users can now define how they would like to group the vulnerabilities across different platforms or environments.

Use case 1:

• We have a mobile application on Android and iOS.
• We upload the APK or the IPA files to scan our dev versions
• We scan from the PlayStore and the AppStore to scan the production version.

-> We would like to have a ticket for each environment and platform.

To do so, you can define a grouping by platform and set each environment in a separate group:

Use case 2:

• We have a mobile application on Android and iOS.
• We upload the APK or the IPA files to scan our dev versions
• We scan from the PlayStore and the AppStore to scan the production version.

-> We would like to group the Android tickets from the Store or the File. The same applies to iOS. However, if an issue is fixed in the Android File, the ticket should remain open until we get the fix in the Store version.

To do so, you can define a grouping by platform and set each environment in a separate group:

Use case 3:

• We have a mobile application on Android and iOS.
• We have different environments for the APK and the IPA files:
  • Dev: com.myapp.dev
  • QA: com.myapp.qa
  • Prod: com.myapp.prod
• We scan from the PlayStore and the AppStore to scan the production version.

-> We would like to group the Android tickets from the Store or the File across all the environment versions. The same applies to iOS. However, if an issue is fixed in the Android File, the ticket should remain open until we get the fix in ALL the versions.

To do so, you can define a grouping by application IDs and set each application ID in one group:

Use case 4:

• We white-label our mobile application on Android and iOS.
• We have different customers for the APK and the IPA files:
• Android: com.android.myapp.customer
• iOS: com.ios.myapp.customer

-> We would like to group the Android tickets from white-labeled applications in one ticket.

This use case is similar to use case 3 since you just have to define one group with all the application IDs. For example, here, we add one group with the customer's regular expression.

Conclusion

Ostorlab ticketing system V2 introduces flexibility so the users can define the aggregation logic that is aligned with their internal flow.