II. Open-source Software Risk Monitoring

Driven by the open source community and the continuous development of open source, open source software is widely used in practical engineering projects, and the number is growing rapidly. The number of open source software in communities/warehouses including Maven, NPM, GitHub, and Gitee has reached over ten million; The iteration of open source software versions is relatively frequent, and its internal components and relationships can also undergo complex changes, such as adding or updating dependent component libraries or versions, reusing other component source code, and calling other component libraries. To improve software development efficiency, enterprises today rely on open-source components heavily to achieve business functions, but ignore the risks brought by the security of open-source components. Starting from enterprise security management, it has become an urgent security challenge to clarify the reference dependencies of open-source software for internal application products or projects, as well as the security vulnerabilities that exist in open-source software.

The regulatory side can collect, integrate, and process open-source project information hosted in the open-source component repository automatically, and build a knowledge graph of open-source software. With that, and combined with a vulnerability knowledge base and mitigation measures, the regulatory side can build a security knowledge graph for open source software, and provide data services such as semantic query of open source software components and dependencies, risk monitoring, and recommendation of secure open source projects to enterprises. In this way, the security risks brought by open-source software can be effectively identified and reduced. Both security and compliance issues when introducing open-source software assets can be solved.

The construction process is shown in the figure below. In terms of data processing technology, natural language processing technology is used to identify software entities, extract relationships, and feature engineering of open-source software (fingerprints, attributes, signatures, etc.). The upper-level visualization provides the ability to query information and analyze based on graph algorithms, providing cascading expansion of software vulnerabilities, and further mining the underlying relational knowledge.

Basic knowledge graph framework of open-source software

III. Enterprise SBOM Security Hosting Service

In software supply chain security, a highly transparent software component list (such as the SPDX specification) is beneficial for software supply chain security management, providing more effective information input and judgment basis for ecological security governance of the software supply chain. However, if it is leaked, it will greatly increase the security risk of the provider. Therefore, it is very difficult to directly connect sensitive information between upstream and downstream enterprises. Public institutions with credibility, reliable technical mechanisms, and solutions are needed in order to provide detailed software component information between enterprises with confidence and enable end users to check whether there are risks.

The combination of software supply chain data security technology and a trusted computing environment can provide a secure and trusted base for SBOM data. Throughout the entire process, third-party institutions provide the SBOM secure hosting platform for software products to enterprises. Enterprises rent their own SBOM “safe house” on the platform and store compliant SBOM data in ciphertext in the safe house. End users can query important information about the software product SBOM on the hosting platform, such as whether it contains a certain component or whether a specific component is at high risk. The platform provides the query results and proof.

Throughout the entire process, institutions providing SBOM security hosting platforms and services need to have the following capabilities:

In the SBOM safe house, SBOM data is stored in ciphertext and accessed in a trusted execution environment (TEE). The platform does not need to hold the SBOM data decryption key of the enterprise, and it is also unable to steal the SBOM data of the enterprise, meaning that the platform has the security function of “self-certification and trustworthiness”.
The SBOM data in the safe house has the characteristics of being searchable and invisible. Upstream enterprises can determine the number of times users query, but cannot obtain the user’s query content, meaning that users have the right to “hide queries”.
The platform ensures that the SBOM queried by users is consistent with the previously publicized SBOM, meaning that users have the right to “not be discriminated against by data”.
Upstream enterprises can revoke the SBOM on the hosting platform and ensure that “after revocation, the hosting platform cannot continue to use the SBOM”, meaning that upstream enterprises have the right to “SBOM forgotten”.

IV. Security Monitoring and Alert

Security monitoring, alerts, and rapid response can be achieved through the collection of intelligence information targeting key nodes in the software supply chain. It reflects a full understanding of the current severe situation of software supply chain security. Software supply chain security detection and warning can fully implement network security responsibilities and help continuously improve IT governance capabilities. Research in the fields of software supply chain industry security, supporting industries, and basic material security, providing policy guidance from a macro perspective to enrich one’s own security protection measures, conducting macro sorting and identifying vulnerabilities in existing software supply chain systems, establishing risk warning mechanisms, and ensuring supply chain security and controllability.

1. Risk environment judgment

In the entire process of the software supply chain, each stage faces different security risks. In order to better respond to various risky situations, it is necessary to have sufficient response strategies for emergency scenarios and avoid harm expansion through both management and technical means. With that, timely monitoring and warning can be carried out when emergencies occur, and they will be handled properly.

Software projects involve numerous suppliers, including consulting and design parties, software developers, information product suppliers, system integrators, operation and maintenance service providers, security service providers, etc. The lack of network security construction by suppliers can also bring risks such as operation permission theft and source code leakage. Thus, the security information and component security information provided by suppliers is also important security intelligence.

From the risks mentioned above, it can be roughly determined that the security detection and warning work of the software supply chain needs to pay attention to two aspects: one is the security risks that exist in the software supplier itself, such as network security defects, port exposure, weak passwords, weak passwords, etc; Another type is the security risks inherent in software products, such as software vulnerabilities.

2. Establish a normalization mechanism

The purchaser needs to normalize the security testing of the software supply chain, using their own security inspection tools to conduct in-depth inspections and modeling of their own system, compile a list of their own components, and combine with security intelligence services to continuously maintain intelligence updates in the later stage to achieve dynamic monitoring, and provide targeted security reinforcement and prevention for key nodes and components.

A national level unified management intelligence base can be established in conjunction with the official vulnerability management agency of the country to achieve software supply chain security warning. The supply chain involves a wide range and complex components, and it is difficult for a single enterprise or organization to ensure the universality and timeliness of security intelligence sources alone. Enterprises should establish their own security detection and warning mechanisms, and establish information control structures and intelligence adoption in advance to prepare for future integration of security monitoring and intelligence.

Feel free to explore more posts in this Software Supply Chain Security series: