Progress OpenEdge Security Guidelines

Last Updated: 11 November 2021

DISCLAIMER: Note these guidelines are meant to outline Progress’ general protocols for handling security vulnerabilities and are not intended to be exhaustive or all-inclusive. At times, there may be circumstances that necessitate different action than detailed below and Progress may utilize its experience and expertise to exercise judgment to take alternative actions. All customers and end users should refer to their respective applicable End User License Agreement for any contractual obligations.

1. Overview

These Progress OpenEdge Security Guidelines outline the general principles under which Progress manages the reporting, management, discussion, and disclosure of Security Vulnerabilities (Vulnerabilities) discovered in OpenEdge software and related components.

These Security Guidelines use the ISO 27005 definition of Vulnerability: "A weakness of an asset or group of assets that can be exploited by one or more threats.", where an asset is anything that has value to the organization, its business operations and their continuity, including information resources that support the organization's mission.

2. OpenEdge Security Team

The Progress OpenEdge Security Team is the first line of defense, using its security expertise to identify and triage reported vulnerabilities. The Security Team will assess and monitor vulnerabilities in a transparent way with OpenEdge Product Management. It will seek to control risk and exposure to customers who use OpenEdge products. The remediation of vulnerabilities resides with the OpenEdge engineering teams who resolve vulnerabilities under the direction of the OpenEdge Security Team and using industry best practices.

3. Reporting

Please refer to the Reporting Security Vulnerabilities guidelines.

4. Assessment

All reported or internally discovered vulnerabilities will be assessed and scored by the OpenEdge Security Team according to the latest published standard of the Common Vulnerability Scoring System (CVSS) provided by the National Infrastructure Advisory Council (NIAC).

At the discretion of the Security Team or Product Management, any vulnerability may be escalated to an outside body such as the Computer Emergency Response Team (CERT) of the Software Engineering Institute (SEI).

5. Resolution

A reported or internally discovered vulnerability is considered resolved when either:

  • A security update is provided
  • A workaround is made available or is identified and communicated to OpenEdge customers
  • It is determined that a fix is not possible or desirable
  • It is determined that a reported vulnerability is not a vulnerability

A vulnerability that is unfixable through any manner of timeliness in accordance with these OpenEdge Security Guidelines will be disclosed based on the protocol described in the “Timing” section of this document.

6. Distribution

Once a vulnerability is resolved, a Security Update will be made available to all OpenEdge customers via the Download Center. Customers with an active maintenance agreement will also be notified by Progress Technical Support.

7. Disclosure

For OpenEdge Customers:

Disclosure, including a summary of the security assessment, is initially limited to the reporter but may be expanded, at the discretion of Progress, to include other customers and/or security experts for the purposes of soliciting subject-matter help or advice. The intent of disclosing any information about security vulnerabilities is always to minimize the risk and exposure of our customers’ computing assets.

All reported vulnerabilities that are assessed above a CVSS score of zero will be disseminated using a Responsible Disclosure approach. This approach avoids the risk of sharing all vulnerability information prematurely or to any excess that could be used by malicious parties to exploit OpenEdge applications before a corrective action can be taken by the product users.

Progress may determine at times that users and/or administrators of OpenEdge software should be made aware of a vulnerability in advance of the availability of a patch or remediation so that they can assess their own risk, and take appropriate action to protect potentially vulnerable software, users, servers and systems. Customers with an active maintenance contract may receive notice of or mitigation instructions for a known vulnerability in advance of a patch in one of two ways:

  • Product Alert: Through the Product Alert Customer Portal when the CVSS assessment is rated below 9.
  • Critical Alert: Through a Progress outreach campaign of email communication to customers and partners when the CVSS assessment is rated at 9 or above.

For Researchers and Non-customers:

OpenEdge follows the Disclosure Policy described in Reporting Security Vulnerabilities guidelines for non-customers who believe they have discovered a vulnerability in OpenEdge products.

8. Timing

The timing of disclosure is left to the discretion of the OpenEdge Security Team and Product Management and is in line with the Responsible Disclosure approach and the following guidelines:

  • Vulnerabilities for which there is a Security Update, workaround or fix, should be disclosed to all customers with active maintenance and support services immediately.
  • All vulnerabilities, regardless of state, should be disclosed to all customers with active maintenance and support services no later than three months after being assessed and scored.

Vulnerabilities need not necessarily be resolved at the time of disclosure.

9. Credits

Progress values the independent security research community members who find vulnerabilities and work with us so that security fixes can be issued to all OpenEdge customers. Our policy is to credit all researchers in the Security Update announcement when a fix for the reported security vulnerability is issued. To receive credit, security researchers must follow Responsible Disclosure practices, including:

  • They do not publish the vulnerability before Progress releases a fix for it
  • They do not divulge exact details of the issue, for example, through exploits or proof-of-concept code

Progress does not credit employees or contractors of Progress and its subsidiaries for vulnerabilities they have found.