Description:FIELD OF INVENTION
The present invention relates to the field of applications focusing on the management and maintenance of open-source software dependencies in applications and products. More particularly, it relates to a system and method to identify a reliable upgrade path of open-source components using context-graph; addressing the challenges associated with identifying, evaluating, and upgrading open-source components in a manner that ensures compatibility, security, and reliability.

BACKGROUND
Open-source libraries and components play a critical role in modern software development, powering over 70% of applications and products. These libraries provide reusable, specialized functionality that enables developers to accelerate the development process, ensure compatibility, and maintain efficiency. By leveraging these pre-built solutions, organizations can focus on core innovation while relying on robust, community-maintained tools for essential features such as data processing, authentication, and machine learning. However, the reliance on open-source components introduces unique challenges, including ensuring security, maintaining compatibility, and managing timely updates. Unlike proprietary software, open-source dependencies often require extensive monitoring for community-driven fixes, vulnerability patches, and compatibility tests, which can be resource-intensive and time-consuming.
PRIOR ART
CN116305143A focuses on a method for processing open-source software call requests. It includes steps such as verifying whether the requested software is in a preset white list and meets the necessary calling conditions. Additionally, it manages open-source software dependencies by acquiring downloading request information through an interface connected to a CICD system, checking if the software dependency is in the white list, and ensuring downloading authentication of these dependencies. The invention emphasizes the full life cycle management of open-source software, including introduction, use, baseline setting, and exit, ensuring precise management and control through automated processes like flow detection, software information management, and uniform governance closure.
KR101648046B1 describes a method for recommending open-source software by collecting software and meta information from at least one open-source software provider. It includes receiving user input in the form of classification information or keywords, retrieving relevant open-source software from a database based on the meta information, and displaying the recommended software to the user. The focus of this method is on making it easier for users to find suitable open-source software based on classification or keyword-based searches.
While these prior arts contribute to the fields of open-source software management and recommendation, they do not fully address several key challenges faced by modern software ecosystems. Specifically, CN116305143A deals primarily with managing software dependencies, ensuring compliance with white lists, and automating lifecycle management but does not focus on the need for automating the identification and recommendation of reliable upgrade paths for open-source components. It also does not address how to ensure that applications remain secure and up-to-date with minimal manual effort, a crucial aspect for developers and businesses relying on continuous integration and delivery systems.
KR101648046B1, on the other hand, addresses the recommendation of open-source software based on classification or keyword searches. However, it lacks the capability to ensure that recommended software components are reliable, secure, or up-to-date in the context of evolving software ecosystems. It does not incorporate the use of advanced context-graph databases or repository scoring metrics to assess the integrity and functionality of open-source software in real-time, nor does it provide a mechanism to ensure that users are always selecting the most secure, compatible, and functional components for their needs.
Therefore, a novel and optimistic solution is required to address these shortcomings. Unlike the prior arts, the system of the present invention goes beyond basic dependency management and computer-based application recommendation, providing a solution that automates the identification of reliable upgrade paths, ensures security through up-to-date component recommendations thereby providing a more comprehensive solution that ensures the long-term integrity and functionality of software ecosystems with minimal manual intervention.

DEFINITIONS
The expression “system” used hereinafter in this specification refers to an ecosystem comprising, but not limited to, a scoring system with a user, input and output devices, processing unit, plurality of mobile devices, a mobile device-based application to collect and auto-analyze data, a visualization platform, and output. It is extended to computing systems like mobile phones, laptops, computers, PCs, and other digital computing devices.
The term “repositories” refers to digital storage locations that house codebases, libraries, or software components. These repositories can be public or private, version-controlled, and may include, but is not limited to platforms like GitHub, GitLab, or Bitbucket. Repositories are the source of data used for analysis, scoring, and component selection.
The term “SBOM” refers to a comprehensive list or inventory of all software components, dependencies, libraries, and modules used in a software project. It identifies the origins, licenses, and vulnerabilities associated with each component, enabling transparency and informed decision-making in software development and maintenance.
A “scoring system” refers to a mechanism designed to evaluate and rank repositories or components based on various factors such as code quality, frequency of updates, security compliance, and community support. This score reflects the reliability, trustworthiness, and usability of the repository or component.
The term “context graph” refers to a structured representation of relationships between various components, repositories, and their attributes. This graph visually maps dependencies, interactions, and hierarchies, enabling stakeholders to analyze the ecosystem effectively and identify optimal pathways for upgrades and modifications.
The term “manifest” refers to the final output generated by the workflow. It is a document or file containing a detailed summary of the analysis, including recommendations for upgrading components, resolving vulnerabilities, and optimizing performance. The manifest serves as a guide for implementation.
“Querying” refers to the process of interacting with the context graph or database to extract specific insights or answers. Stakeholders can pose questions about the ecosystem, such as identifying reliable upgrade paths, analyzing vulnerabilities, or understanding compatibility.

The term “upgrade path” refers to the sequence or methodology for updating software components or repositories in a manner that ensures compatibility, security, and optimal performance. A reliable upgrade path minimizes disruption and addresses dependencies systematically.
The term “crawling” refers to the automated process of scanning, indexing, and extracting data from various repositories. This process gathers relevant information such as metadata, dependencies, and files for further analysis and processing.
The term “visualization platform” refers to a digital interface or tool designed to display data, relationships, and analyses in a user-friendly visual format. This can include graphs, charts, and diagrams, aiding stakeholders in understanding complex datasets.
The term “processing unit” refers to the computational hardware or software that performs the core analysis, scoring, and generation of context graphs. It includes servers, CPUs, GPUs, or cloud-based systems that handle intensive computations.
The term “mobile device-based application” refers to software designed to run on smartphones or tablets. This application is used to collect, auto-analyze data, and provide users with insights or recommendations through an intuitive interface.
The term “output devices” refers to hardware or digital tools that present processed information to users. Examples include computer monitors, mobile screens, printers, or online dashboards.
The term “visualization tools” refers to software applications that create graphical representations of data, such as bar charts, pie charts, network diagrams, or flowcharts. These tools help in analyzing and interpreting data in an intuitive manner.
The term “component” refers to an individual part of a software system, such as a module, library, or plugin. Components are often used as building blocks for applications and may have dependencies on other components.
The term “dependencies” refers to the relationships between components where one component relies on another for functionality. Managing dependencies is critical to ensure compatibility and stability in software systems.
The term “vulnerabilities” refers to weaknesses or flaws in software components that may pose security risks. Identifying and resolving vulnerabilities is essential to maintain system integrity and security.
The term “stakeholders” refers to individuals or entities involved in or affected by the workflow process, including developers, project managers, end-users, and organizations utilizing the system.

OBJECTS OF THE INVENTION:
The primary object of the present invention is to provide a system and method to identify reliable upgrade paths of open-source components using context-graph.
Another object of the present invention is to automate the identification of reliable upgrade paths for open-source components to minimize delays and risks associated with manual update management.
Yet another object of the present invention is to provide a method for crawling both public and custom repositories to collect comprehensive data on open-source components and their dependencies.
Yet another object of the present invention is to generate a Software Bill of Materials (SBOM) to map the dependencies within an application and ensure compatibility with the latest updates.
Yet another object of the present invention is to score repositories based on key factors such as security, maintenance, and popularity, ensuring that the most reliable and secure components are prioritized.
Further, the object of the present invention is to create a context-graph database to establish relationships between open-source components and their versions, allowing for efficient recommendation of compatible upgrade paths.

SUMMARY
Before the present invention is described, it is to be understood that the present invention is not limited to specific methodologies and materials described, as these may vary as per the person skilled in the art. It is also to be understood that the terminology used in the description is for the purpose of describing the particular embodiments only and is not intended to limit the scope of the present invention.
The present invention is designed to automate the upgrade process for open-source components in software applications. It begins with data collection, where the system crawls both public and private repositories to gather metadata about open-source components, such as versions, security vulnerabilities, and usage metrics. Following this, a Software Bill of Materials (SBOM) is generated to list all dependencies within an application. The next step is repository scoring, where repositories are evaluated based on three parameters—security, maintenance, and popularity. A scoring mechanism then calculates a weighted score for each repository to determine its reliability. The system also builds a context-graph, a graph database that links components based on their compatibility, usage, and repository scores. By querying this context-graph, the system identifies optimal upgrade paths that are compatible and secure. Finally, a manifest is generated, delivering upgrade recommendations in a structured format for seamless integration into applications. This system ensures compatibility and reliability, minimizing manual intervention while enhancing the efficiency and security of software applications.

BRIEF DESCRIPTION OF DRAWINGS
FIG. 1 illustrates an overview of the system of the present invention.
FIG. 2 illustrates the stepwise method employed by the processing unit of the present invention.

DETAILED DESCRIPTION OF INVENTION:
Before the present invention is described, it is to be understood that this invention is not limited to methodologies described, as these may vary as per the person skilled in the art. It is also to be understood that the terminology used in the description is for the purpose of describing the particular embodiments only and is not intended to limit the scope of the present invention. Throughout this specification, the word “comprise”, or variations such as “comprises” or “comprising”, will be understood to imply the inclusion of a stated element, integer or step, or group of elements, integers or steps, but not the exclusion of any other element, integer or step, or group of elements, integers or steps. The use of the expression “at least” or “at least one” suggests the use of one or more elements or ingredients or quantities, as the use may be in the embodiment of the invention to achieve one or more of the desired objects or results. Various embodiments of the present invention are described below. It is, however, noted that the present invention is not limited to these embodiments, but rather the intention is that modifications that are apparent are also included.
The present invention is directed to a system and method to identify a reliable upgrade path of open-source components using context-graph; addressing the challenges associated with identifying, evaluating, and upgrading open-source components in a manner that ensures compatibility, security, and reliability; wherein the system comprises an input unit (2), processing unit (3) and output unit (4); wherein the said processing unit (3) employs a systematic stepwise method for managing and updating open-source components within an application involves several distinct steps, each contributing to the overall goal of ensuring the secure, efficient, and compatible use of open-source dependencies.
FIG. 1 in accordance with the embodiment of the present invention depicts the detailed process flow including multiple sequential steps.
According to a preferred embodiment of the present invention as in accordance with FIG. 2, the detailed method includes multiple sequential steps represented with corresponding reference numerals. Below is the comprehensive description of the workflow:
The process begins with Start (100), marking the initialization of the advanced workflow system. This stage sets the groundwork for the subsequent steps by triggering the necessary prerequisites and ensuring that the system is ready to execute the tasks.
1. Data Extracting:
Following the initialization of the system, the data moves to Crawl Repositories (200) through the input unit. This stage involves scanning and extracting data from a vast array of repositories, wherein the repositories may include open-source libraries, public or private code repositories, and other data sources. The crawling process ensures comprehensive data collection, capturing all relevant metadata and source files. This step forms the foundation for subsequent analysis and processing by creating a robust dataset.
2. Generating SBOM (300):
An SBOM, or Software Bill of Materials, is a detailed inventory of all the components used in a computer-based application project. At this stage, the system analyzes the crawled repositories to construct an SBOM for each application or product. This step ensures transparency and lays out the dependencies, licenses, and components associated with the application under review. The generated SBOM facilitates better understanding and management of components of the application.
3. Repository Scoring (400):
Wherein, the workflow evaluates the repositories based on predefined criteria. These criteria may include the quality of the code, the frequency of updates, the activity of contributors, and the repository's compliance with security standards. The scoring process assigns reliability and trustworthiness scores to repositories, helping stakeholders prioritize their selection.
The scoring process considers three key factors: security, maintenance, and popularity, which contribute to a weighted final score.
1. Security: The security score assesses the presence and severity of vulnerabilities in the repository. Each vulnerability is assigned a weight based on its criticality:
a. Critical: −5 points
b. High: −3 points
c. Medium: −2 points
d. Low: −1 point
If a repository contains multiple vulnerabilities, the total security score is calculated using the formula: S = ∑ Wi, where Wi is the weight of the i-th vulnerability, and n is the total number of vulnerabilities.
2. Maintenance: The maintenance score evaluates the repository's activity over time. If there are no updates within the last two years, a penalty of -4 points is applied. The formula for the maintenance score is:
M = −4 (if no updates in two years), otherwise M = 0.
3. Popularity: The popularity score reflects the community engagement with the repository. It is calculated as:
P = 0.01 ⋅ (Stars + 2 ⋅ Forks), where stars and forks are metrics indicating usage and adoption.
4. The Final Repository Score (R) is determined by combining these three factors into a single metric: R = S + M + P
Repositories with higher scores are prioritized for integration into the context-graph. This systematic scoring approach ensures that only the most reliable, well-maintained, and secure repositories are selected, aiding stakeholders in making informed decisions.
4. Creating Context Graph (500)
Wherein, the data collected and analyzed in the earlier stages is organized into a context graph, a graphical representation of relationships between various repositories, components, and their attributes. The context graph provides a visual and analytical means to understand how components interact, their dependencies, and their relative importance within the software ecosystem.
5. Querying the Context-Graph
Wherein, the system allows stakeholders to interact with the context graph by querying it for specific insights. For instance, users may ask questions about the most reliable component upgrade paths, the security vulnerabilities of particular components, or the compatibility of components within the system. This interactive querying enables tailored and actionable insights.
6. Manifesting Generation (700)
Wherein, the manifest is a detailed output document that encapsulates the results of the analysis. It includes recommendations for upgrading components, resolving vulnerabilities, and optimizing performance. The manifest provides actionable steps, ensuring that stakeholders can implement the recommendations seamlessly.
Finally, the workflow concludes with End (800). This stage signifies the successful completion of the advanced workflow. The system finalizes all processes, ensuring that all data is stored securely and that the insights generated are available for use.

WORKING EXAMPLE:
The invention hereafter will be cited by way of examples only for a better and detailed understanding:
Example
Consider a scenario where a development team seeks to upgrade a software application that relies on multiple open-source components. The system begins its operation by Crawling Repositories (200) to identify and collect data from various open-source repositories. For instance, the repositories include popular sources like GitHub and Bitbucket, and the system fetches metadata such as contributor activity, code versions, security vulnerability logs, and license information for components like Library A, Library B, and Library C.
Next, the system moves to the Generate SBOM (300) phase. During this phase, a Software Bill of Materials (SBOM) is created. For example, the SBOM reveals that Library A depends on Library X (version 1.2), while Library B depends on Library X (version 1.1). This creates a potential conflict in the application’s dependency structure.
Following this, the system evaluates the repositories in the Score Repositories (400) phase. It assigns scores based on metrics such as update frequency, vulnerability patching history, and community activity. In this case, Library A’s repository receives a higher score due to regular updates and an active community compared to Library B, which has infrequent updates and unresolved issues.
The system then proceeds to Build Context-Graph (500), where it maps all the dependencies and interconnections between libraries. For instance, the context graph visualizes that upgrading Library A to version 2.0 would resolve compatibility issues with Library X, provided Library B is also upgraded to support Library X version 1.2. The graph further identifies any risks associated with these upgrades, such as breaking changes in other components.
In Query Context-Graph (600), the team queries the graph for an optimal upgrade path. The system suggests an upgrade plan where Library A is updated to version 2.0 and Library B to version 1.5, aligning them with Library X version 1.2. It also highlights that no additional changes are needed for Library C, ensuring a seamless transition.
Finally, the Generate Manifest (700) step produces a detailed report. This manifest outlines the recommended upgrades, the justification for each, and the steps required to implement them. For instance, it specifies:
● Upgrade Library A from version 1.0 to 2.0.
● Upgrade Library B from version 1.2 to 1.5.
● Ensure Library X is standardized to version 1.2.
By following the recommendations in the manifest, the development team successfully upgrades the application, resolves dependency conflicts, and enhances security and performance without introducing new vulnerabilities.
The present invention provides certain significant advantages such that it automates the identification of reliable upgrade paths, ensures security through up-to-date component recommendations, uses advanced context-graph databases and repository scoring metrics to evaluate and recommend open-source components that best fit the needs of modern software development thereby providing, thereby making the invention not only a more comprehensive solution but also one that ensures the long-term integrity and functionality of software ecosystems with minimal manual intervention.
While considerable emphasis has been placed herein on the specific elements of the preferred embodiment, it will be appreciated that many alterations can be made and that many modifications can be made in preferred embodiment without departing from the principles of the invention. These and other changes in the preferred embodiments of the invention will be apparent to those skilled in the art from the disclosure herein, whereby it is to be distinctly understood that the foregoing descriptive matter is to be interpreted merely as illustrative of the invention and not as a limitation. , Claims:CLAIMS:
We claim,
1. A system and method to identify reliable upgrade path of open-source components using context-graph; wherein the system comprises an input unit (2), a processing unit and an output unit (4);
characterized in that:
the processing unit of the system employs a stepwise workflow comprising the steps of;
a. initializing the system using “start” (100); setting the groundwork for the subsequent steps by triggering the necessary prerequisites, and ensuring the system is ready to execute the tasks;
b. extracting data; wherein the data moves through the input unit to crawl repositories (200) that performs:
- scanning and extracting data from a vast array of repositories,
- ensuring comprehensive data collection,
- capturing all relevant metadata and source files,
- creating a robust dataset;
c. generating SBOM (300); wherein the system includes,
- analyzing the crawled repositories to construct an SBOM for each application or product,
- ensuring transparency and lays out the dependencies, licenses, and components associated with the application under review,
- generating an SBOM that facilitates better understanding and management of components of the application;
d. repository scoring (400); that includes,
- evaluating the repositories based on predefined criteria,
- scoring that assigns reliability and trustworthiness scores to repositories,
- helping stakeholders prioritize their selection;
e. creating context graph (500); that includes organizing the data collected and analyzed in the earlier stages into a context graph;
f. querying the context-graph, that includes,
- allowing the stakeholders to interact with the context graph by querying it for specific insights; wherein interactive querying enables tailored and actionable insights;
g. manifesting generation (700), wherein, the manifest is a detailed output document that includes,
- encapsulating the results of the analysis further including recommendations for upgrading components, resolving vulnerabilities, and optimizing performance,
- providing actionable steps, ensuring that stakeholders can implement the recommendations seamlessly;
h. concluding the workflow using “end” (800) signifying the successful completion of the advanced workflow, wherein the system finalizes all processes, ensuring that all data is stored securely and that the insights generated are available for use.

2. The system and method as claimed in claim 1, wherein the repositories may include open-source libraries, public or private code repositories, and other data sources.

3. The system and method as claimed in claim 1, wherein the predefined criteria include the quality of the code, the frequency of updates, the activity of contributors, and the repository's compliance with security standards.

4. The system and method as claimed in claim 1, wherein the scoring process considers three key factors including security, maintenance, and popularity, which contribute to a weighted final score; such that the security score assesses the presence and severity of vulnerabilities in the repository, wherein each vulnerability is assigned a weight based on its criticality as -Critical: −5 points, High: −3 points, Medium: −2 points,Low: −1 point; and
where a repository contains multiple vulnerabilities, the total security score is calculated using the formula:S = ∑ Wi,where Wi is the weight of the i-th vulnerability, and n is the total number of vulnerabilities; and
maintenance score evaluates the repository's activity over time, such that if no updates within the last two years, a penalty of -4 points is applied, using the formula for the maintenance score:
M = −4 (if no updates in two years), otherwise M = 0; and
the popularity score reflects the community engagement with the repository, calculated as: P = 0.01 ⋅ (Stars + 2 ⋅ Forks), where stars and forks are metrics indicating usage and adoption;
such that the Final Repository Score (R) is determined by combining said three factors into a single metric: R = S + M + P; whereby the repositories with higher scores are prioritized for integration into the context-graph.

1. The system as claimed in claim 1, wherein the context graph is a graphical representation of relationships between various repositories, components, and their attributes; such that it provides a visual and analytical means to understand how components interact, their dependencies, and their relative importance within the software ecosystem.

2. The system and method as claimed in claim1, wherein the interactive for specific insights may include questions about the most reliable component upgrade paths, the security vulnerabilities of particular components, or the compatibility of components within the system, that enables tailored and actionable insights.

7. The system and method as claimed in claim 1, wherein the context-graph is queried to recommend reliable upgrade paths for components, providing an automated way to identify and resolve dependency updates.

8. The system as claimed in claim 1, wherein the system is capable of automatically generating a Software Bill of Materials (SBOM) to map application dependencies and ensure compatibility with the latest component versions.

9. The system as claimed in claim 1, wherein the recommendations for upgrades are delivered in a format that can be directly integrated into the application’s deployment pipeline, minimizing manual effort in updating components.

Dated this 31st day of December, 2024.