Skip to main content

3rd-party and OSS

The purpose of the process is to avoid any legal or commercial risks related to 3rd-party software that is either shipped by PAPCP R&D as a part of software acquired by the channel or by the customer as a pre-requisite for functionality. The coverage of 3rd-party software includes commercial software, OSS components, and OSS code snippets.

note

Only the R&D activities and artifacts are considered here. See the References below for more details about other organizational functions and their responsibilities.

This process ensures the selected 3rd-party software versions are supported, and the lifecycle of those applications and components aligns with the PAPCP product lifecycles and releases. 3rd-party software applications and components are analyzed from both technical and commercial perspectives to maintain our technical advantage and position as market leaders.

The qualification process considers cyber security issues at an early stage, avoiding adding components that might increase our vulnerability and attack surface.

For safety-certified products, the qualification process must ensure that third-party software components fulfill the safety requirements, based on the level of software criticality (T1 … T3). A TSR (Tool Selection Report) must be approved in collaboration with the safety engineer to allow the use of the tool for safety development. Please follow the Tool Selection Report (TSR) guideline How-to Write a Tool Selection Report

Process Overview​

Principles​

  • Ensure 3rd-party supplier agreements are active and fulfilled throughout the lifecycle.
  • Analyze legal aspects of licenses and agreements.
  • Analyze and plan for 3rd-party software updates and align them to the system and product releases.
  • Collaborate with suppliers to identify and mitigate updates, vulnerabilities, and other issues.
  • Evaluate the applicability, impact, and criticality of reported issues (safety and security).
  • Provide timely information to our customers on software updates and issues.
  • Determine if export authorization is required for the 3rd-party software (ECCN).

Activities​

3PO-1

Artifacts​

Artifact​Description​RACI​Receiver​Comments
Software Use list (Decision Focus export)List of 3rd-party Software, including information about Software Use and Supplier. Extracted from Decision Focus.(R): 3rd-party Software Manager
(A): Stream Owner
(C): Release Owner
(I): -		Release OwnersThe Release owner has to distribute the Software Use list report to Stakeholders (like P&F, P&L, Product Classification team) before gate meetings.
3rd-party DefectsDefects based on 3rd-party application issues(R): 3rd-party SW Owner
(A): Product Owner
(C): Test Lead, Test Engineer, Cyber Security Engineer
(I): Release Owner, Product Manager		R&D-
3rd-party Lifecycle RequirementsSystem Requirement for planned updates of 3rd-party applications.(R): Release Owner
(A): Product Manager
(C): 3rd-party SW Manager, 3rd-party SW Owner
(I): -		PPM-
3rd-party Risk Assessment ReportIf a 3rd-party defect is deferred, a risk assessment questionnaire / exception report is completed and evaluated.(R): 3rd-party SW Owner
(A): 3rd-party SW Owner
(C): Cyber Security Engineer & 3rd SW Manager
(I): 3rd-party SW Owner(s)		Release Owners, Cyber Security Engineers, 3rd Party SW Manager-
<Product x> Security Updates Validation Status BulletinThis document presents the validation status of 3rd-party security updates that have been evaluated.(R): Test Engineer (Security Update Testing Team)
(A): Product Manager
(C): Cyber Security Engineer
(I): Product Owner		PPM-
Safety tool selection ReportSummary of safety tool selection report(R): Development Team (SM, Eng, Tester)
(A): Stream Owner
(C): Configuration Manager, Product Owner, Release Owner, Technical Coordinator, Safety Engineer
(I): -		PPM-

Dependencies​

3PO-2

Details​

3rd party software management is necessary due to:

  • Agreements and Royalties
    • Commercial software must have valid agreements, including support.
    • All software with runtime costs must be identified and handled.
  • Obligations
    • All software has obligations to fulfill
    • OSS obligations
  • Product Classification
    • 3rd party software impacts the overall product classification
    • OSS with encryption and cryptography also has an impact on the classification
  • Cyber Security
    • 3rd party software release updates and fixed multiple bugs
    • Security vulnerabilities inside 3rd-party software will impact ABB software.
  • Lifecycle
    • 3rd-party software has a significant influence on our ABB software lifecycle.

The different types of 3rd-party software categories are:

  • Type ‘A’ - any 3rd-party software included in the build or installation package (e.g., 3rd-party libraries, embedded OS, etc.).
  • Type ‘B’ - any 3rd-party software that the product depends on, typically used in its deployment without being an integrated part of the PAPCP product (e.g., MS Windows, MS Office, Acrobat Reader, etc.).
  • Internal use – development and test tools used only internally. This includes 3rd-party software used during the development and testing of the products (e.g., compilers, linkers, static code analyzers, unit test framework, etc.).

Costs related to 3rd-party applications must be considered:

  • Runtime costs with fees for redistribution (handled by P&L and P&F)
  • Internal use costs with free runtime (handled by R&D via purchase order)

References​

3rd-Party Processes​

3rd-Party Training​

OCC Guidelines​

Templates​

Owner: 3rd-party and OSS Team