Skip to main content

How-to Handle Vulnerabilities in 3rd-Party Software

This document describes steps to be taken when vulnerabilities are detected for any type of 3rd-party components like OSS, runtime cost, development cost- free runtime, components used in development and testing of our products.

Intended for​

3rd-party software owners and 3rd-party software managers.

Prerequisites​

The prerequisites to address vulnerable software components are as follows:

  1. Black Duck should be configured to send notifications on security risks to cyber-security engineers and product owners.
  2. Components that Black Duck cannot monitor for vulnerabilities shall be manually monitored.
  3. The expected monitoring interval shall be described and followed up in Decision Focus. Refer section 'Security checks' in How-to Create Software in Decision Focus

Note: Monitoring security updates is a continuous activity for the technical responsible for the components assigned to him/her. The list of all known components must be available in Decision Focus for the current release. The first baseline may be an import from the previous release. The frequency to check these details is preset when the software is added in Decision Focus.

Activities​

This flowchart gives an overview of the actions to be taken when a vulnerability 3rd-party component is detected. Required activities are further described in Manage vulnerabilities in 3rd-party components below.

Vulnerability-Flowchart.drawio.png

Manage vulnerabilities in 3rd-party components​

  1. Create a bug (a 3rd-party vulnerability bug).

    • If the vulnerability affects a released product:

      Assess the severity.
      If the product owner and product manager consider this sufficiently critical for customers: Trigger "security update".
      If not: Include the bug in the roadmap for future release of P. Issue a security advisory.

    • If the vulnerability only affects a product which is not yet released:

      If it is acceptably easy to update the component: Do it before the release.
      If it is not so easy: Assess the severity properly.
      If it is sufficiently low: Include the bug in the roadmap for a future release of the Product.

When assessing the severity of the product using the vulnerable 3rd-party component, the severity as given for the vulnerability in the 3rd-party component can be an indication, but cannot be taken directly. It must be clarified if the vulnerable function is used/exposed in the product and what an exploit can really do to the product.

The template "Risk Analysis Questionnaire for 3rd party components" is available in Templafy with ID 7PAA019358. This questionnaire has a list of checkpoints related to the usage of the affected software component, business risk, testing methods, mitigation plan, risk result, etc. As the technical responsible answers the queries mentioned in the questionnaire, the same is sent to the 3rd-party software manager and cyber security engineer for exception approval.

Once the questionnaire is updated, the same is attached to the bug that is raised for handling the update of the affected component in the release ADO page. The bug ID shared by the technical responsible is updated in the Decision Focus discussion log as a reference in the "Software Use" and the same is approved with an exception for the target release.

Also, refer to the template "R&D and Technology - Project Execution Deliverables and Milestone Tracker" available in Templafy with ID 2PAA121451.

Details​

Organizational preparedness and expectations​

Each project should make a plan for when new 3rd-party components can be integrated based on the severity of the issues found in them. Projects should detect issues with 3rd-party components at any point in time before G5. The default expectation is that all issues found before G2 (or correspondingly) will be addressed by updates of the affected 3rd-party components.

Closer to release only more severe issues will be addressed (just like for other bugs). There may also be reasons why issues found before G2 may be deferred. The reasons shall be documented. Product support teams shall be able to detect issues with 3rd-party components at any point in time.

The KPIs related to the last check notifications done for the security checks of software can be referred to the security check dashboards available in Decision Focus.

References​

Owner: 3rd-party and OSS Team