Why Visibility of Third-party Components in your Software is Critical

Jul 25, 2023 | Portfolio Governance Why Visibility of Third-party Components in your Software is Critical

Keeping track of external packages used in a software application and obtaining visibility on their versions, vulnerabilities, and adherence with rest of the software is crucial for several reasons.

Firstly, understanding the external packages and their versions helps ensure compatibility and proper functioning of the software. Different versions may introduce new features, bug fixes, or even breaking changes. By having visibility into the versions used, developers can assess whether their application is leveraging the latest capabilities and if any updates are necessary.

Secondly, monitoring for known vulnerabilities in external packages is essential for maintaining the security of the software. Many vulnerabilities are discovered and patched over time, and using outdated or vulnerable versions can expose the application to potential security risks. Keeping track of vulnerabilities allows developers to proactively update or replace affected packages, reducing the chances of exploitation.

Overall, having visibility into external packages, their versions, vulnerabilities, and adherence to the internal elements of the software helps to maintain software integrity and security. It enables developers to make informed decisions regarding updates and patches thereby reducing potential risks in the software.

This article is a feature focused on CAST Imaging to explain how to quickly identify the use of third-party components in your application and make the upgrade or removal a much more easy and safe task in your day-to-day work.

How to access it in CAST Imaging?

Let’s first focus on the inventory regarding third-party components in your application which needs to be upgraded. From the Welcome page, you can find a specific tile dedicated to it named “Third Party Components” in the modernization section.

1-2 Just click on the tile to get access to the list of third-party components.

How it works?

Note that all this list of information comes from the CAST Highlight’s SCA database.

CAST Highlight’s SCA database is made up of 118+ million Open-Source components gathered from various forges that we crawl such as Github, GitLab, Maven Central, NPM, NuGet, RubyGem, Packagist, etc. Depending on the component name and version detected in an application scan, CAST Highlight finds possible vulnerabilities (CVEs) by cross-referencing the National Vulnerablity Database (NVD) from NIST, across 150+ thousand known vulnerabilities. Users typically run a first analysis of their application to establish a CVE baseline and prioritize risk mitigation actions. 

What detailed information can I find on third-party components?

You can find a list of third-party components with the following information:

2-2Component Name

Lists the name of the obsolete third-party component found in your application.

Version

Displays the version number of the obsolete third-party component found in your application.

Release Date

Displays the release date of the version of the obsolete third-party component found in your application.

Gap

Displays the age of the obsolete third-party component–i.e. the difference between today’s date and the release date of the version found in your application. The larger the gap the higher the prioritization should be for modernization.

CVE

Displays statistics about any CVEs (Common Vulnerabilities and Exposures etc.) that are present in the obsolete third-party component. The total count of CVEs is displayed together with the specific number of Critical, High, Medium, Low and Advisory CVEs.

Components containing a higher CVE count should be prioritized for modernization.

Release per year

Displays the average number of releases per year of the third-party component.

Object Count

Displays the total number of objects present in the third-party component – for example, for a Java framework, you may find Java Class objects within the framework. Additionally, you can filter by the object count value using the icon in the header (you can enter the count value and select on the option from the list).

Where are these components used in my application?

The next step is to now focus on adherence regarding the third-party component to know how and where it is used in your application.

Select one component 'Jackson Databind' as an example which is a general data-binding functionality for Jackson. In this application the release used isfive5 years old with 65 CVEs and 22 are critical. Look at the graph at the high-level overview to see adherence:

3-2

 We can see two types of elements, Java classes and MVC classes having some connections to the third-party component.

Click on the investigate button to drill-down to the details and understand what can be the impact of doing an upgrade of this component, or if you want to remove it. Immediately you will be informed about the internal elements (classes) and if it is concentrated or scattered in your application.

In the red square this about the external class from the Jackson component and all other classes corresponds to internal classes part of the application that call the Jackson class. 

4-1You can save this information in order to prepare the upgrade, that’s why you can add comment and save this view in order to share the information with the relevant team.

If you need to get more details zooming on each link is possible to get access to the source code:

5-1

 

You will also add specific tags to all classes interacting with this component to get very quick access to these elements later and regarding the tests to be done after the upgrade to be sure there is no regression in your application. 

6

You have seen in very few steps how to take good decisions based on the CAST Imaging knowledge base about third-party components and adherence with your software.