A software supply chain dependency network construction method for complex industrial software

Abstract

The application provides a software supply chain dependency network construction method for complex industrial software, and belongs to the technical field of software security.S1. main dependency analysis stage: through package manager multi-language configuration analysis, source code static analysis and construction log analysis, a complete direct dependency list is compiled;S2. metadata analysis and transmission extension stage: metadata is obtained by querying a software registry and a transmission closure is recursively constructed;S3. dependency graph model modeling stage: a directed graph model is constructed and stored in a Neo4j graph database.The application systematically solves the key bottleneck in the current technical solution, and further provides support for the analysis of the overall reliability, safety and other problems of industrial software.

Description

Technical Field

[0001] This invention provides a method for constructing a software supply chain dependency network for complex industrial software, belonging to the field of software security technology. Background Technology

[0002] Complex industrial software systems, including computer-aided design (CAD) and computer-aided manufacturing (CAM), are key digital infrastructures in modern manufacturing. These systems typically integrate multiple programming languages, various dependency management mechanisms, and distributed code repositories to achieve high-performance computing, flexible scripting capabilities, and rich graphical user interfaces. As a core part of the software supply chain, current software supply chain dependency network analysis primarily employs various technical solutions, each targeting different scenarios and language ecosystems. Single-language SBOM generation tools are the current mainstream solution. These tools are mostly language-specific; for example, npm-sbom is specifically for the Node.js ecosystem, while CycloneDX provides specific tools for languages ​​such as Java, Python, and Go. These tools can generate relatively accurate dependency lists within a single language ecosystem, but they generally have significant limitations, namely, they cannot effectively handle the dependency analysis needs of cross-language projects.

[0003] Specifically as follows:

[0004] The fragmented resolution of multi-language dependencies is a primary problem. Existing SBOM generators cannot simultaneously resolve multiple language dependencies managed by a single package manager. Taking industrial software like Cura as an example, these projects use Conan to manage both C++ and Python dependencies, but existing tools can only recognize one language. They cannot complete the full extraction of multi-language dependencies in a unified operation, resulting in the dependency graph being artificially fragmented.

[0005] Incomplete dependency detection without declaration is another significant drawback. Static analysis tools struggle to uncover dependencies that directly contain source code or language-specific imports. While commercial tools like Black Duck offer code snippet analysis capabilities, they lack sophisticated scanning strategies tailored to the specific import patterns of industrial software. They also lack in-depth parsing capabilities for package import statements and cannot effectively handle dependency nodes with completely missing version information, creating blind spots in the supply chain.

[0006] The lack of support for specific scenarios in industrial software is a fundamental limitation of existing general-purpose tools. Industrial software is characterized by large code volumes, multi-language mixing, deep dependency layers, and the absence of package managers for some dependencies. Existing general-purpose tools struggle to accurately construct its complete supply chain map and cannot meet the stringent requirements of supply chain security analysis for industrial-grade software. Summary of the Invention

[0007] To address the shortcomings of existing technologies, this invention provides a method for constructing a software supply chain dependency network for complex industrial software. This method aims to systematically solve key bottlenecks in current technical solutions, thereby providing support for the analysis of overall reliability and security issues in industrial software. Specifically, the main problems solved by this invention include:

[0008] (1) Achieve unified parsing of multi-language dependencies by a single package manager, breaking through the inherent limitation that existing tools can only handle single-language dependencies. Support package managers such as Conan, Pixi, and Cmake to simultaneously manage the unified extraction of multi-language dependencies such as C, C++, and Python, thereby capturing cross-language dependency relationships in a complete analysis process and eliminating the language boundary fragmentation caused by traditional tools.

[0009] (2) Achieve multi-dimensional dependency detection by combining three complementary methods: package manager configuration file parsing, static source code analysis, and build log analysis, to comprehensively capture declared and undeclared dependencies. This multi-dimensional discovery strategy can not only identify dependencies explicitly recorded by the package manager, but also discover dependencies that are not formally declared but actually exist through source code import statement analysis and build process log tracking, significantly improving the visibility of the supply chain.

[0010] (3) Establish a complete transitive dependency extension and metadata enhancement system. By recursively querying mainstream software repositories (including PyPI, Conan Center, and GitHub Releases), construct a complete transitive closure of the dependency network and simultaneously obtain key metadata such as timestamps and latest versions. This recursive extension mechanism ensures complete tracking of deep dependencies, while metadata enhancement provides a data foundation for subsequent security analysis and reliability risk assessment.

[0011] (4) It forms an end-to-end automated analysis pipeline, realizing integrated processing from source code parsing, dependency extraction, metadata query to graph database storage. It can complete the supply chain analysis of large-scale complex industrial software without human intervention, significantly improving analysis efficiency and repeatability, and is suitable for the actual scenario of industrial software supply chain security governance.

[0012] The specific technical solution is as follows:

[0013] A method for building a software supply chain dependency network for complex industrial software includes the following steps:

[0014] S1. Main dependency resolution phase: Through package manager multi-language configuration resolution, source code static analysis, and build log analysis, a complete list of direct dependencies is compiled;

[0015] A unified resolution mechanism for multi-language dependencies under a single package manager is implemented for multi-language configuration parsing; a cross-language unified parser is designed that can handle multiple programming language dependencies managed by a single package manager simultaneously.

[0016] First, scan all package manager configuration files in the main repository and its internal sub-projects; design specific parsing logic for mainstream package managers; and simultaneously establish a language identifier mapping table to annotate the language attributes of each parsed dependency.

[0017] Secondly, by statically analyzing undeclared dependent components, a multi-language source code scanning strategy is implemented for dependencies not declared in the package manager file. System header files and project header files are distinguished to extract external library dependencies; then, the dependencies identified by static analysis are merged with those obtained from configuration parsing to establish a unified dependency set; for dependencies whose versions cannot be determined, an "unknown" tag is assigned, and they are marked as external control leaf nodes in the graph model, terminating further propagation and expansion of that branch.

[0018] Finally, a log analysis transitive dependency component is built specifically to handle pure C++ industrial software projects that do not use package managers. Combined with build log parsing technology, the output logs of the build tool are captured after the project is compiled. A dedicated log parser is designed to identify the -I include path, -L library path, and -l link library parameters in the compilation command. The dependency relationships output by the compiler and the generated dependency files are parsed. Finally, all package names and version information, including transitive dependencies, are extracted.

[0019] S2. Metadata parsing and transit extension phase: Query the software registry to obtain metadata and recursively construct transitive closures;

[0020] The metadata parsing and transitive extension phase is responsible for expanding the direct dependencies obtained in the main dependency parsing phase into a complete transitive dependency network and enriching the key metadata information.

[0021] The metadata query module queries multiple software registries in parallel for each name-version pair of direct dependencies to obtain comprehensive information: first, it retrieves metadata for dependent packages from the package manager central repository; for example, it retrieves metadata for C++ packages from Conan Center; and it retrieves version release dates and Release Notes details from GitHub Releases. Subsequently, the recursive transitive extension module recursively executes the above queries on the dependency list of each dependency, constructing a complete transitive closure to ensure that deep dependencies are not overlooked. To handle boundary cases with unknown versions, the system implements a branch termination strategy. When a node marked as an unknown version is encountered, the recursion of that branch is terminated, and it is treated as a leaf node to avoid infinite expansion or error propagation. Simultaneously, the time series construction module builds complete timeline data for each component, including the initial release date, the date of the currently used version, and the date of the latest version, providing data support for supply chain assessment.

[0022] This stage employs a structured data model to store the enriched dependency information. Each package node contains: `package_name` (identifying the package name), `version` (recording the currently used version), `language` (indicating the programming language type), `package_manager` (specifying the source package manager), `release_date` (storeing the release timestamp of the current version), `latest_version` (recording the latest version number in the repository), `latest_release_date` (recording the release time of the latest version), and the `dependencies` array (containing all direct dependencies of the package), forming a recursively expandable tree structure. This data design ensures both information integrity and supports efficient graph database writing and subsequent graph algorithm analysis.

[0023] S3. Dependency Graph Modeling Phase: Construct a directed graph model and store it in the Neo4j graph database.

[0024] The software supply chain dependency network is modeled as a directed graph G=(V,E), where the node set V contains three types of nodes: the main application node representing the entire application system, sub-project nodes representing internal module divisions, and transitive dependency component nodes covering all external dependencies, including special leaf nodes marked as unknown. Directed edges e_ij in the edge set E represent the dependency relationship declared by node v_i on v_j, and the edge type is uniformly marked as depends_on.

[0025] The node attribute design adopts a multi-dimensional information structure. The name field stores the package name as a unique identifier. The version field records the version number and allows the unknown value to indicate that the version information is missing. The language field indicates the programming language type. The source_manager field indicates the source package manager of this dependency. The release_date and latest_release_date fields record the release date of the current version and the latest version, respectively. The latest_version field records the latest version number in the repository. The is_leaf boolean field indicates whether it is a leaf node. The is_unknown_version boolean field is specifically used to mark whether the version is unknown, which facilitates subsequent risk identification and special handling.

[0026] In terms of edge attribute design, the dependency_type string field has a fixed value of depends_on to maintain semantic consistency, and the direct boolean field distinguishes whether the dependency is declared directly or transitively introduced.

[0027] At the Neo4j storage implementation level, the Neo4j graph database is used to store the graph model mentioned above; the Cypher query language is used to support complex supply chain analysis operations, including transitive dependency queries, critical path analysis, and circular dependency detection; at the same time, it supports integration with the Graph Data Science library for deep network analysis, and identifies key nodes in the supply chain through degree centrality, PageRank, and betweenness centrality algorithms, providing a quantitative basis for risk priority ranking.

[0028] This invention proposes a method for building software supply chain dependency networks for open-source complex industrial software ecosystems. It is based on package managers, software source code, and software build logs, and ultimately forms a universal supply chain dependency network building process that can be applied to a variety of common package managers and a variety of common programming languages.

[0029] This invention employs a multi-dimensional dependency discovery fusion mechanism, integrating three complementary dependency discovery methods: capturing declared dependencies through configuration file parsing, discovering undeclared dependencies through static source code analysis, and obtaining transitive dependencies through build log analysis. This achieves comprehensive capture of dependencies in complex industrial software, significantly improving the integrity and accuracy of the network.

[0030] This invention employs a unified multi-language dependency resolution technology using a single package manager, enabling the package manager to simultaneously manage and extract multi-language dependencies. This effectively solves the dependency resolution problem in complex industrial software under multi-language mixed scenarios, breaks through the single-language limitation of existing SBOM tools, and eliminates dependency blind spots caused by language fragmentation in traditional tools.

[0031] This invention relates to a dependency graph model representation for industrial software. It designs an attribute graph model that includes time and language dimensions. The time dimension covers the release date and the latest version date to support obsolescence risk assessment, and the language dimension marks the programming type to support cross-language analysis. The overall model supports the accurate representation of complex hierarchical structures and is particularly suitable for in-depth supply chain analysis and risk quantification scenarios in industrial software. Attached Figure Description

[0032] Figure 1 This is a flowchart of the present invention. Detailed Implementation

[0033] like Figure 1 As shown, this invention provides a method for constructing a software supply chain dependency network for complex industrial software, comprising three stages:

[0034] S1 Main Dependency Resolution Phase

[0035] The main dependency resolution phase is the core of this invention, comprising three collaborative technical components. Multi-language configuration resolution, as one of the core innovations of this invention, implements a unified resolution mechanism for multi-language dependencies managed by a single package manager. Traditional SBOM generators use independent parsers for each language, while this invention designs a cross-language unified parser capable of simultaneously handling multiple programming language dependencies managed by a single package manager.

[0036] At the technical implementation level, this component first scans all package manager configuration files in the main repository and its internal sub-projects, including conanfile.txt, requirements.txt, CMakeLists.txt, pixi.toml, etc. It then designs specialized parsing logic for mainstream package managers. For example, the Conan package manager is written in Python and can manage both C++ and Python dependencies. This invention extracts both C++ and Python dependency sets in a unified operation by parsing Conan's internal dependency tree. Simultaneously, it establishes a language identifier mapping table to label the language attributes of each parsed dependency. This innovation effectively solves the problem that existing tools can only recognize a single language when package managers used by industrial software such as Cura manage multiple languages ​​such as C++ and Python, achieving true unified multi-language parsing.

[0037] Secondly, by statically analyzing undeclared dependencies, a multi-language source code scanning strategy is implemented for dependencies not declared in the package manager file, such as directly included source code or language-specific imports. For example, Python dependency scanning iterates through all .py files, using regular expressions and AST parsing to identify import and from...import statements to extract package names. C / C++ dependency scanning iterates through all .c, .cpp, .h, and .hpp files, identifying #include directives and distinguishing between system header files and project header files to extract external library dependencies. The dependencies identified by static analysis are then merged with those obtained from configuration parsing to establish a unified dependency set. For dependencies whose versions cannot be determined, an "unknown" tag is assigned, and they are marked as external control leaf nodes in the graph model, terminating further propagation and expansion of that branch. This design compensates for the shortcomings of relying solely on package manager configuration, captures dependencies directly imported from source code, and elegantly handles boundary cases with missing version information through the "unknown" tag mechanism.

[0038] Finally, a log analysis component for transitive dependencies is constructed specifically to address pure C++ industrial software projects that do not use package managers. This is a common scenario in traditional industrial software, where static analysis can only reveal direct dependencies. This invention combines build log parsing technology to capture the output logs of build tools such as Make, CMake, and Ninja after project compilation; it designs a dedicated log parser to identify the -I include path, -L library path, and -l link library parameters in compilation commands; it parses the dependency relationships output by the compiler, such as the dependency files generated by the GCC -MMD option; and finally, it extracts all package names and version information, including transitive dependencies. This innovation breaks through the dependency analysis bottleneck of projects without package managers, achieving complete capture of transitive dependencies in such industrial software.

[0039] S2 Metadata Parsing and Transmission Extension Phase

[0040] The metadata parsing and transitive extension phase is responsible for expanding the direct dependencies obtained in the main dependency parsing phase into a complete transitive dependency network and enriching the key metadata information.

[0041] At the technical implementation level, the metadata query module queries multiple software registries in parallel for each directly dependent name-version pair to obtain comprehensive information: first, it retrieves metadata for dependent packages from the package manager central repository, such as the release timestamp, latest version, and dependency list for Python packages from PyPI; metadata for C++ packages from Conan Center; and detailed information such as release dates and release notes from GitHub Releases. Subsequently, the recursive transitive extension module recursively executes the above queries on the dependency list of each dependency, constructing a complete transitive closure to ensure that deep dependencies are not overlooked. To handle boundary cases with unknown versions, the system implements a branch termination strategy. When a node marked as an unknown version is encountered, the recursion of that branch is terminated, and it is treated as a leaf node to avoid infinite expansion or error propagation. Simultaneously, the time series construction module builds complete timeline data for each component, including the initial release date, the date of the currently used version, and the date of the latest version, providing data support for supply chain assessment.

[0042] This stage employs a structured data model to store the enriched dependency information. Each package node contains: `package_name` (identifying the package name), `version` (recording the currently used version), `language` (indicating the programming language type), `package_manager` (specifying the source package manager), `release_date` (storeing the release timestamp of the current version), `latest_version` (recording the latest version number in the repository), `latest_release_date` (recording the release time of the latest version), and the `dependencies` array (containing all direct dependencies of the package), forming a recursively expandable tree structure. This data design ensures both information integrity and supports efficient graph database writing and subsequent graph algorithm analysis.

[0043] S3 Dependency Graph Modeling Phase

[0044] This invention models the software supply chain dependency network as a directed graph G=(V,E), where the node set V contains three types of nodes: the main application node representing the entire application system, sub-project nodes representing internal module divisions, and transitive dependency component nodes covering all external dependencies, including special leaf nodes marked as unknown. The directed edge e_ij in the edge set E represents the dependency relationship declared by node v_i on v_j, and the edge type is uniformly marked as depends_on. This directed design accurately reflects the unidirectional transitive nature of software dependencies.

[0045] The node attribute design adopts a multi-dimensional information structure. The name field stores the package name as a unique identifier. The version field records the version number and allows the unknown value to indicate that the version information is missing. The language field indicates the programming language type, such as python, cpp, java, etc. The source_manager field indicates the source package manager of this dependency. The release_date and latest_release_date date and time fields record the release date of the current version and the latest version, respectively. The latest_version field records the latest version number in the repository. The is_leaf boolean field indicates whether it is a leaf node. The is_unknown_version boolean field is specifically used to mark whether the version is unknown, which facilitates subsequent risk identification and special handling.

[0046] In terms of edge attribute design, the dependency_type string field has a fixed value of depends_on to maintain semantic consistency, and the direct boolean field distinguishes whether the dependency is declared directly or transitively introduced. This distinction is of great value for risk assessment and dependency optimization.

[0047] At the Neo4j storage implementation level, this invention uses the Neo4j graph database to store the aforementioned graph model, fully leveraging its native graph structure advantages; it utilizes the Cypher query language to support complex supply chain analysis operations, including transitive dependency queries, critical path analysis, and circular dependency detection; it also supports integration with the Graph Data Science library for deep network analysis, identifying key nodes in the supply chain through algorithms such as degree centrality, PageRank, and betweenness centrality, providing a quantitative basis for risk prioritization.

[0048] Regarding package manager extensions in the embodiments, although the embodiments focus on describing mainstream package managers such as Conan and PyPI, the architecture design of this invention supports extension to other package manager ecosystems through the adapter pattern. This includes Maven and Gradle adapters for parsing pom.xml and build.gradle for Java industrial software, npm adapters for parsing package.json to support Node.js industrial software, vcpkg adapters for vcpkg dependency management for C++ projects, and Poetry and Pipenv adapters for modern Python package management tools. This modular design ensures the broad applicability of the framework.

[0049] Metadata sources can be expanded according to the actual environment. In addition to public repositories such as PyPI, Conan Center, and GitHub Releases, relevant data can also be obtained from enterprise-owned private package repositories such as Nexus and Artifactory, operating system package managers such as apt and yum, and hardware description language repositories such as FPGA and ASIC industrial software.

[0050] The graph database storage layer can be replaced by other graph databases, such as Amazon Neptune, JanusGraph, and ArangoDB.

Claims

1. A method for constructing a software supply chain dependency network for complex industrial software, characterized in that, Includes the following steps: S1. Main dependency resolution phase: Through package manager multi-language configuration resolution, source code static analysis, and build log analysis, a complete list of direct dependencies is compiled; S2. Metadata parsing and transit extension phase: Query the software registry to obtain metadata and recursively construct transitive closures; S3. Dependency Graph Modeling Phase: Construct a directed graph model and store it in the Neo4j graph database.

2. The method for constructing a software supply chain dependency network for complex industrial software according to claim 1, characterized in that, The specific process of S1 includes: A unified resolution mechanism for multi-language dependencies under a single package manager is implemented to resolve multi-language configurations; a cross-language unified resolver is designed to handle multiple programming language dependencies managed by a single package manager. First, scan all package manager configuration files in the main repository and its internal sub-projects; design specific parsing logic for mainstream package managers; and simultaneously establish a language identifier mapping table to annotate the language attributes of each parsed dependency. Secondly, by statically analyzing undeclared dependent components, a multi-language source code scanning strategy is implemented for dependencies not declared in the package manager file; system header files and project header files are distinguished to extract external library dependencies; then the dependencies identified by static analysis are merged with the dependencies obtained by configuration parsing to establish a unified dependency set; for dependencies whose versions cannot be determined, an "unknown" tag is assigned and they are marked as external control leaf nodes in the graph model to terminate further propagation and expansion of that branch; Finally, a log analysis transitive dependency component is built specifically to address industrial software projects that do not use package managers. Combined with build log parsing technology, the output logs of the build tool are captured after the project is compiled. A dedicated log parser is designed to identify the -I include path, -L library path, and -l link library parameters in the compilation command. The dependency relationships output by the compiler and the generated dependency files are parsed. Finally, all package names and version information, including transitive dependencies, are extracted.

3. The method for constructing a software supply chain dependency network for complex industrial software according to claim 1, characterized in that, The specific process of S2 includes: The metadata parsing and transitive extension phase is responsible for expanding the direct dependencies obtained in the main dependency parsing phase into a complete transitive dependency network and enriching the key metadata information. The metadata query module queries multiple software registries in parallel for each name-version pair of direct dependencies to obtain comprehensive information: first, it retrieves the metadata of dependent packages from the package manager's central repository; then, the recursive transitive extension module recursively executes the above query on the dependency list of each dependency, constructing a complete transitive closure to ensure that deep dependencies are not missed; to handle boundary cases with unknown versions, the system implements a branch termination strategy, terminating the recursion of the branch when a node marked as an unknown version is encountered, treating it as a leaf node to avoid infinite expansion or error propagation; simultaneously, the time series construction module builds complete timeline data for each component, including the first release date, the date of the currently used version, and the date of the latest version, providing data support for supply chain assessment.

4. The method for constructing a software supply chain dependency network for complex industrial software according to claim 3, characterized in that, S2 uses a structured data model to store the enriched dependency information. Each package node contains package_name (identifying the package name), version (recording the current version), language (marking the programming language type), package_manager (specifying the source package manager), release_date (storing the release timestamp of the current version), latest_version (recording the latest version number in the repository), latest_release_date (recording the release time of the latest version), and the dependencies array (containing all direct dependencies of the package), forming a recursively expandable tree structure.

5. A method for constructing a software supply chain dependency network for complex industrial software according to claim 1, characterized in that, The S3 process includes: The software supply chain is modeled as a directed graph G=(V,E), where the node set V contains three types of nodes: the main application node representing the entire application system, the sub-project nodes representing the internal module division, and the transitive dependency component nodes covering all external dependencies, including those special leaf nodes marked as unknown; the directed edge e_ij in the edge set E represents the dependency relationship declared by node v_i on v_j, and the edge type is uniformly marked as depends_on; The node attribute design adopts a multi-dimensional information structure. The name field stores the package name as a unique identifier, the version field records the version number and allows the unknown value to indicate that the version information is missing, the language field indicates the programming language type, the source_manager field indicates the source package manager of the dependency, the release_date and latest_release_date fields record the release date of the current version and the latest version, respectively, the latest_version field records the latest version number in the repository, the is_leaf boolean field indicates whether it is a leaf node, and the is_unknown_version boolean field is specifically used to mark whether the version is unknown, which facilitates subsequent risk identification and special handling. In terms of edge attribute design, the dependency_type string field has a fixed value of depends_on to maintain semantic consistency, and the direct boolean field distinguishes whether the dependency is declared directly or transitively introduced; At the Neo4j storage implementation level, the Neo4j graph database is used to store the graph model mentioned above; the Cypher query language is used to support complex supply chain analysis operations, including transitive dependency queries, critical path analysis, and circular dependency detection; at the same time, it supports integration with the Graph Data Science library for deep network analysis, and identifies key nodes in the supply chain through degree centrality, PageRank, and betweenness centrality algorithms, providing a quantitative basis for risk priority ranking.

Images