Skip to main content

How-to Handle End-of-Life Software

This guide describes the steps to handle 3rd-party software that has reached end-of-life (EOL) and "Operational risks" identified by Black Duck for OSS.

Note: The default approach to handle any 3rd party software that has reached EOL is to upgrade it to the latest and best version.

Intended for​

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

Prerequisites​

The prerequisites to address the EOL software components are as follows:

  1. Black Duck should be configured to notify the product owners of operational risks.
  2. Components that Black Duck cannot monitor for lifecycle issues shall be manually monitored.
  3. The expected monitoring interval shall be described and followed up in Decision Focus under the security check section. The manual monitoring of lifecycle status and vulnerabilities is expected to be done as a combined activity, see section 'Lifecycle' in How-to Create Software in Decision Focus.

Note: Monitoring lifecycle is a continuous activity for the technical responsible for the components assigned to him/her. The list of all the 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 of checking these details is pre-set when the software is added to Decision Focus.

Activities​

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

How-to-Handle-3rd-Party-EoL.drawio.png

Manage EOL 3rd-party components​

  1. Create a bug (for out-of-date 3rd-party software) for each impacted ABB product.

  2. For a released product, the bug shall be included in the roadmap for future releases of the product.

  3. For a product which is not yet released:

    a. If it is acceptably easy to update the component, do it before the release.

    b. If updating the component is not so easy, assess the risk of keeping the current version and document the details about the decision not to upgrade.

    c. If the risk is sufficiently low, include the bug in the roadmap for future releases of 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 a bug which 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 R&D and Technology - Project Execution Deliverables and Milestone Tracker available in Templafy ID 2PAA121451.

Details​

Organizational preparedness and expectations​

Each project shall make a plan for when new 3rd-party components can be integrated based on the severity found. Projects shall be able to detect the lifecycle status of 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 EOL of components can be referred to in the lifecycle dashboards available in Decision Focus.

References​

Owner: 3rd-party and OSS Team.