Security Policy

Cubewise Software is committed to delivering secure, reliable products and to maintaining the trust of our customers and partners. This document outlines our approach to application security, with a particular focus on the use and management of third‑party libraries.

Overview

Like most modern software, our products rely on a number of third‑party libraries and components. For example, we use Handsontable for the grid component of the cube viewer (also used by Apliqo) and Log4j for log management (also used by IBM Planning Analytics/TM1).

From time to time, customers request upgrades of specific libraries, often following automated vulnerability scans or penetration tests that flag non‑latest library versions. This policy explains how we manage such libraries and how we assess and address security risks.

Security Responsibility

Security is a top priority for Cubewise Software. We take full responsibility for the security of our products, including all third‑party libraries we incorporate.

• We conduct regular, independent penetration tests against our products.

• Many of our customers also perform their own penetration tests as part of their security and upgrade processes.

• Our development practices are informed by web application security best practices, and we employ developers with relevant security expertise and certifications.

Customers can confidently include our products in their security assessment processes, including penetration testing.

How We Handle Third‑Party Libraries

Automated tools used in penetration testing and vulnerability scanning typically:

1. Identify the libraries included in an application.

2. Check their versions against public vulnerability databases.

3. Flag libraries that are not at the latest version or are associated with known CVEs (Common Vulnerabilities and Exposures).

While such reports can appear alarming, they often:

• Do not distinguish between theoretical and practical exploitability in a given product.

• Do not consider whether the specific vulnerable feature of a library is actually used by the application.

• Recommend upgrades solely on the basis of version numbers rather than a contextual risk assessment.

Our approach is to treat these findings as inputs into a structured security review, rather than as automatic triggers for upgrades.

Risk‑Based Upgrade Policy

We do not upgrade every library to the latest version by default. Instead, we follow a risk‑based approach:

1. Security Focus

   • Our development teams are trained in secure coding practices.

   • We design and review features with security in mind, not only at the library level but across the entire application stack.

2. Active Monitoring

   • We monitor the OWASP Top 10 and other recognized security information sources and newsletters.

   • When a security issue is reported that affects a library version used by our products, we assess:

     • Whether the vulnerability is relevant to our specific usage of the library.

     • The potential impact and exploitability in our environment.

   • If a relevant security risk is identified, we prioritize upgrading to a secure version and release an update as appropriate.

3. Stability and Risk Management

   • Newer library versions can sometimes introduce regressions or new vulnerabilities.

   • Older, well‑tested versions may be more stable and, in practice, safer if they are not affected by known relevant vulnerabilities.

   • We balance the security benefits of an upgrade against the risk of introducing new issues or breaking existing functionality.

Given this, enhancement requests or support tickets solely to “upgrade to the latest library version” are not always necessary. We prioritize upgrades when there is a clear, identified and relevant security or stability benefit.

Customer Penetration Tests and Security Assessments

Customers are welcome and encouraged to include our products in their standard security processes, including penetration tests and vulnerability scans.

• If a customer’s testing identifies a potential vulnerability, we review the finding, assess its applicability to our implementation, and respond accordingly.

• Where a third‑party library is implicated and the finding is relevant and actionable, we will plan and execute an appropriate remediation, which may include upgrading or reconfiguring the library.

In practice, this approach is consistent with how organizations manage other enterprise software: for example, most customers do not upgrade every release of Planning Analytics Workspace or TM1 immediately, but instead follow a controlled, risk‑based upgrade strategy.