Scalable by design:
Products
Solutions
Industries
Learn and grow:
Resource Hub
Dive Deep
Support
Pentaho values the role that independent security researchers, customers, partners and the wider security community play in improving software security. Responsible reporting helps us identify and address vulnerabilities, reduce customer risk and improve the security of Pentaho products and services.
This policy explains how suspected vulnerabilities should be reported to Pentaho, what we ask of reporters, how we review and coordinate vulnerability reports, and how we handle public advisories and CVE coordination where applicable.
Our objective is to support responsible vulnerability disclosure while protecting customers, users, reporters and the broader ecosystem from unnecessary risk.
This policy may be used by:
This policy does not create a bug bounty programme and does not create any entitlement to payment, reward, compensation, employment, contract award or other benefit.
Pentaho welcomes reports of suspected security vulnerabilities that may affect the confidentiality, integrity or availability of Pentaho products, services, maintained components or product-managed data.
Examples of potentially reportable issues include:
Reports should be submitted where the reporter has a reasonable belief that the issue is a genuine security vulnerability and is within Pentaho’s responsibility to investigate, remediate, mitigate or coordinate.
Some reported issues may fall outside Pentaho’s vulnerability handling scope. Pentaho may close, redirect or decline reports where the issue relates primarily to:
Where appropriate, Pentaho may direct the reporter to a relevant supplier, maintainer, customer support channel, coordinator or CVE Numbering Authority.
Pentaho asks reporters to conduct research safely, lawfully and in good faith.
Reporters must not:
Reporters should limit testing to what is necessary to confirm the existence of a suspected vulnerability. If a reporter encounters data or access that does not belong to them, they should stop testing immediately and report the issue to Pentaho.
Pentaho will review vulnerability reports submitted in good faith under this policy. Pentaho does not intend to pursue legal action against reporters solely for identifying and reporting a vulnerability where the reporter complies with this policy, avoids harm, does not access or misuse data, and acts lawfully.
This safe harbour statement does not authorise unlawful activity or activity against third-party systems. It does not protect activity involving data theft, extortion, threats, privacy violations, destructive testing, unauthorised persistence, social engineering, denial-of-service attacks, physical attacks or conduct that harms Pentaho, its customers, users, suppliers or partners.
Pentaho reserves all rights where activity falls outside this policy or creates legal, security, operational, customer or privacy risk.
Reports should be submitted through Pentaho’s designated vulnerability reporting channel.
Customers with an active support relationship may also report suspected vulnerabilities through their normal support process. Where a support case appears to involve a security vulnerability, Pentaho will route it to the appropriate security and product teams.
Formal legal notices should not be sent solely through the vulnerability reporting channel. Legal notices must be submitted in accordance with the notice provisions of the applicable agreement.
A useful report helps Pentaho reproduce, validate and assess the suspected vulnerability. Reporters should include as much of the following information as possible:
Reporters should not submit customer data, personal data, credentials, private keys, secrets, confidential third-party information or data obtained through unauthorised access. If sensitive material is necessary to explain a report, the reporter should ask Pentaho for a secure transfer method before sending it.
Pentaho reviews vulnerability reports through a structured intake and triage process.
After receiving a report, Pentaho will seek to determine whether the issue is in scope, whether the affected product or service is identifiable, whether the report contains enough information, whether the issue can be reproduced, whether the issue is already known, whether a third-party supplier or upstream maintainer is involved, and whether immediate protective action is required.
Pentaho may contact the reporter to request clarification, additional technical detail, reproduction steps or coordination information. Pentaho may close or defer reports that cannot be reproduced, do not contain sufficient information, are duplicates, fall outside Pentaho’s responsibility, or do not demonstrate a meaningful security impact.
Acknowledgement of a report does not mean that Pentaho has confirmed the vulnerability, accepted the severity rating, accepted responsibility for remediation, or agreed to publish a CVE.
Pentaho assesses vulnerability reports based on risk and product context. Severity and priority are determined by considering technical impact and practical exploitability, not simply by the existence of a CVE, scanner result or theoretical weakness.
Assessment may consider:
Pentaho may use industry scoring systems and vulnerability classifications, such as CVSS and CWE, as inputs to assessment. Pentaho may also adjust severity based on product-specific context, exploitability, exposure, mitigations and customer impact.
Pentaho uses a risk-based approach to remediation and mitigation. Depending on the vulnerability, Pentaho may address the issue through code changes, product updates, dependency updates, configuration changes, mitigations, documentation updates, monitoring, supplier coordination, customer guidance or other risk reduction measures.
Pentaho uses internal remediation objectives to support prioritisation and management oversight. These objectives are not contractual service levels, warranties or guarantees unless expressly included in a signed agreement.
Actual remediation timing may vary depending on technical complexity, testing requirements, product architecture, release planning, deployment model, supplier dependency, availability of vendor fixes, customer configuration, compensating controls and the outcome of risk assessment.
Where immediate remediation is not feasible or is not the most appropriate risk treatment, Pentaho may use compensating controls, mitigations, configuration changes, monitoring, supplier remediation, scheduled release processes or approved risk acceptance.
Pentaho supports coordinated vulnerability disclosure. Reporters are expected to give Pentaho a reasonable opportunity to investigate, remediate or mitigate a reported vulnerability before public disclosure.
Pentaho will coordinate disclosure timing based on customer protection, severity, exploitability, active exploitation, whether the issue is already public, remediation availability, supplier involvement, product release planning, legal considerations, regulatory considerations and customer communication needs.
Pentaho may publish information before a full fix is available where customer protection requires earlier communication, where the issue is already public, where active exploitation is occurring, or where disclosure is necessary to provide mitigation guidance.
Pentaho asks reporters not to publish exploit code, proof-of-concept details or technical information that would materially increase risk before coordination is complete.
Pentaho may publish a security advisory, product security notice, release note, support article or similar communication when a vulnerability affects customers or requires customer action.
A Pentaho security advisory may include:
Pentaho may update advisories as additional information becomes available.
Pentaho may assign, request, reference or coordinate CVE IDs for vulnerabilities affecting products or components within Pentaho’s authorised CVE scope, where applicable.
Pentaho may assign or request a CVE ID where a reported issue is determined to be a cybersecurity vulnerability, affects an in-scope product, is not a duplicate of an existing CVE, and meets applicable CVE Programme assignment criteria.
Pentaho may decline to assign or request a CVE ID where the issue:
Where a vulnerability falls within another CNA’s scope, Pentaho may coordinate with that CNA, refer the reporter to the appropriate CNA, or work with the relevant supplier, maintainer or coordinator.
Where Pentaho publishes CVE information, Pentaho will seek to provide appropriate public references, affected product information, affected version information where known, remediation or mitigation guidance where available, and updates where material information changes.
Pentaho products may include third-party or open-source components. Where a reported vulnerability affects such a component, Pentaho will assess whether the vulnerability affects Pentaho’s implementation and whether customer action, product update, supplier coordination or upstream coordination is required.
If an existing upstream CVE already covers the vulnerability, Pentaho may reference the existing CVE rather than assign or request a new one. Where the issue appears to be newly identified in an upstream component, Pentaho may coordinate with the relevant maintainer, supplier, CNA or coordinator as appropriate.
Pentaho’s remediation approach may depend on upstream fix availability, component support status, product integration, testing requirements and customer impact.
Some Pentaho products may be deployed, configured, hosted or operated by customers. In those cases, security responsibility may be shared between Pentaho and the customer.
Pentaho may provide product updates, security patches, mitigations, documentation or guidance where appropriate. Customers may be responsible for applying updates, maintaining secure configurations, managing user access, protecting credentials, monitoring customer-managed environments, maintaining backups and securing customer infrastructure.
A weakness that arises solely from customer-specific configuration, customer infrastructure, unsupported software, unapproved customisation, customer credentials or third-party integrations outside Pentaho’s control may not be treated as a Pentaho product vulnerability.
Pentaho may recognise reporters who submit valid vulnerabilities and follow this policy.
Recognition may appear in a security advisory, CVE reference, release note, acknowledgement page or other appropriate format. Reporters who want recognition should provide their preferred name, handle or organisation.
Pentaho may decline recognition where the report does not comply with this policy, where recognition could create legal, privacy, safety or security concerns, where another party is responsible for discovery, or where the reporter requests anonymity.
Pentaho does not provide monetary rewards unless an official Pentaho bug bounty programme or authorised reward programme expressly states otherwise.
Pentaho uses reporter contact details and report content for vulnerability intake, investigation, coordination, remediation, disclosure, CVE handling and related security purposes.
Pentaho may share relevant report information internally with Security, Product Security, Engineering, Legal, Privacy, Compliance, Customer Support and other personnel who need the information to investigate or address the issue.
Pentaho may also share relevant information with suppliers, upstream maintainers, coordinators, customers, CVE Programme participants, legal advisers, regulators or other parties where appropriate for remediation, coordination, disclosure, legal compliance or customer protection.
Reporters should avoid sending sensitive personal data, customer data, credentials, secrets or confidential third-party information unless Pentaho has requested it and agreed an appropriate transfer method.
Reporters should coordinate public disclosure with Pentaho. If a reporter intends to publish information about a reported vulnerability, the reporter should notify Pentaho in advance and provide the intended disclosure date.
Pentaho asks reporters to avoid publishing details that would materially increase risk to customers before a fix, mitigation or advisory is available, unless earlier disclosure is necessary to protect users or the vulnerability is already public.
Where a reporter believes immediate public disclosure is necessary, Pentaho asks the reporter to explain the reason so that Pentaho can assess customer protection needs and determine whether expedited communication or mitigation guidance is appropriate.
This policy is provided to support responsible vulnerability reporting and coordinated disclosure. It does not create additional contractual obligations, warranties, service levels, indemnities or guarantees unless expressly incorporated into a signed agreement.
Pentaho’s handling of a specific report may vary based on product scope, technical validity, severity, exploitability, customer impact, deployment model, supplier involvement, legal obligations, active exploitation and technical feasibility.
Pentaho may update, withdraw or replace this policy as its products, services, vulnerability handling practices, CVE scope or legal obligations evolve.
Pentaho will maintain a public page for vulnerability reporting and security advisory information.
Last updated August 13, 2026