Skip to main content

 

 

 

Template:OutSystems/Documentation_KB/Breadcrumb_New_Layout

 

 

Template:OutSystems/OSLanguageSwitcher

 

 

 

OutSystems

Vulnerabilities

OutSystems public vulnerability disclosure policy

This policy was created to provide our customers guidance and information in the event of a vulnerability reported in an OutSystems product. It's essential to ensure that our customers have a consistent and unambiguous resource to understand how OutSystems responds to events of this nature.

The OutSystems vulnerability disclosure policy covers:

  • OutSystems components

    • Platform Server
    • LifeTime
    • Service Studio and Integration Studio
    • Mobile Apps Builder Service (MABS)
    • Architecture Dashboard
    • Workflow Builder
    • Experience Builder
  • Forge components supported by OutSystems

  • Any property under outsystems.com domain

OutSystems Product Security Incident Response Team (PSIRT) investigates all reports regardless of the OutSystems software code version or product lifecycle status until the product reaches the end of mainstream support.

Issues will be prioritized based on the risk score and severity. The resolution of a reported vulnerability may require installing new software versions of products that are under active support from OutSystems. As a best practice, OutSystems strongly recommends that customers periodically verify if their products are under mainstream support to ensure access to the latest software updates.

During any investigation, the OutSystems PSIRT manages all sensitive information on a highly confidential basis. Internal distribution is limited to those individuals who have a legitimate need-to-know and can actively assist in the resolution.

Similarly, the OutSystems PSIRT asks reporters to maintain strict confidentiality until complete resolutions are available for customers and have been published by the OutSystems PSIRT on the OutSystems website through the appropriate coordinated disclosure.

Reporting or obtaining support for a vulnerability

For OutSystems customers and partners

If you are an OutSystems customer or partner and have access to our Support Portal, please report your vulnerability reports through OutSystems Support using the available channels.

Reports will be handled within the scope and SLA's of customers' and partners' contracts.

For community members

Any person that’s not an OutSystems customer or partner is welcome to report a vulnerability to OutSystems PSIRT by using this form and filling in all the mandatory information.

OutSystems PSIRT may return to the reporter with additional questions or clarifications and provides the reporter with regular updates when relevant information comes to light.

OutSystems management of a reported vulnerability

High level, the phases of tackling a vulnerability found at OutSystems products are as follows:

It consists of 2 phases, the embargo phase and public disclosure.

Embargo phase

During this phase, and to protect customers, OutSystems doesn't disclose further details about the vulnerability. It’s important to note that the more details are divulged, the more probable it's that such information is used to exploit the vulnerability. Therefore, OutSystems allows reasonable time to protect your infrastructures before disclosing further.

During the embargo phase the following steps occur:

  1. Identification: OutSystems learns about the vulnerability.

  2. Classification: OutSystems classifies reported vulnerabilities and attributes a risk score and severity. This is done using the version 3.1 of the Common Vulnerability Scoring System (CVSS). This framework assigns a vulnerability score to a vulnerability which is then translated into five possible severities, ranging from Info up to Critical, according to the risk score.

  3. Risk Assessment: For all vulnerabilities, study the vulnerability and come up with a recommended mitigation strategy. The mitigation can range from shutting a service down to releasing a patch.

  4. Plan and fix: For all vulnerabilities planned to be fixed, OutSystems defines a schedule and a deadline for the fix, according to internal criteria defined to mitigate vulnerabilities. The fix and / or workaround for the vulnerability is prepared.

  5. Publish security bulletin and fix release: A fix is publicly released along with installation details. A security bulletin for each vulnerability is published and listed here. At this point, the bulletins don't disclose any technical details.

  6. Patch OutSystems Cloud: For OutSystems Cloud customers, a patch schedule may also be communicated for all affected environments. If the patch has no impact on normal operations and availability, it won’t require scheduling. OutSystems reserves the right to start scheduling patches to OutSystems Cloud environments as soon as a fix or workaround is found. Self-managed infrastructures can be patched at the customer’s discretion.

Public disclosure

Approximately 90 days after the fix release, OutSystems discloses further details about the vulnerability by updating the respective security bulletin.

  • Was this article helpful?