Skip to main content






  • Edit
    Collaborate with us
    Edit this page on GitHub
  • OutSystems public vulnerability 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 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 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.

    Before submitting a vulnerability report

    Often, vulnerability scans, static code analysis or dynamic code analysis are performed by third party tools that output a report.Those reports shouldn’t be sent untreated to OutSystems. Instead, they should first be analysed.

    This means that customers and partners must first analyze the findings in such reports and determine if:

    1. It’s related to application logic and was introduced during the development (related to application logic). In this case, it’s the customer's responsibility to address it.
    2. The finding is a false positive or not. It’s the customer's responsibility to consult the available documentation.
    3. Understand if the vulnerability falls under the customer or OutSystems responsibility.

    Read the following articles before performing any type of testing on your OutSystems applications:

    Assistance in analyzing reports

    For customers who require help in analyzing reports from third party tools, OutSystems has made available a service. To obtain more information about this service, customers should reach out to their Customer Success Managers (CSM), Account Representative, or Solution Design Manager (SDM).

    After analysis, if the findings are related with the OutSystems platform, please submit a vulnerability report. The instructions to submit such a report to OutSystems support can be found next.

    How to submit a vulnerability report

    To submit a vulnerability report, use Support Portal.

    Vulnerability reports must contain the following information:

    1. Provide a detailed vulnerability summary This section must contain a summary of the vulnerability and its impact.

      Example (not real):

      LifeTime contains an insecure object reference vulnerability where any user can view the details of any other user. This may lead to data leak since details of the users can be accessed by any user.

    2. Proof of concept or detailed steps to reproduce or exploit the vulnerability

      Example (not real):

      1. Login into LifeTime
      2. Go to https://[URL]/users?uid=2
      3. Confirm you’re seeing the details of another user.

    If this information is not consistently provided, the support case may ultimately be closed.

    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?