How a Bank Secures Open‑Source Software: Practices, Policies, and Platforms

Background

Open‑source technologies are the foundation of digital infrastructure and applications, increasingly driving innovation and digital transformation in financial institutions. Their widespread use inevitably brings security vulnerabilities and supply‑chain attacks. The People’s Bank of China, the Cyberspace Administration and four other ministries issued the “Opinions on Regulating the Application and Development of Open‑Source Technology in the Financial Industry”, which provides clear guidance.

The Opinions state that financial institutions should follow the principles of “security‑controlled, compliant use, problem‑oriented, open innovation”, integrate open‑source technology into their information‑technology development plans, encourage its use to enhance core‑technology autonomy, and promote the healthy, sustainable development of open‑source technology.

Implementing the Opinions

The Software Development Center has been committed to the practice and innovation of open‑source security, strictly implementing the Opinions, treating information‑system security as the baseline for using open‑source technology, actively applying open‑source solutions, improving open‑source usage and autonomy, and supporting the financial industry’s next‑generation technology.

Open‑Source Security Management Practices and Innovations

1. Governance Framework

To operationalize the Opinions, the Center leverages an open‑source security management platform together with a DevOps system to establish a relatively complete management framework covering policies, technical support, routine management, and capability building. This includes defining security management standards for the full lifecycle of open‑source software, establishing security assessment criteria, and integrating security management into the development process.

(1) Policies and Standards

Establish security management specifications : Define lifecycle security standards, classify open‑source software, and assign clear responsibilities (“who uses, who is responsible”).

Establish security assessment criteria :

Secure introduction mechanism : Conduct network anomaly detection, malware scanning, component analysis, source‑code review, and baseline checks before introducing software.

Secure usage and update mechanism : Perform continuous open‑source security scanning, real‑time incident checks, risk assessment, maintenance, and long‑term governance.

Secure de‑commission mechanism : Use vulnerability notifications, production monitoring, and incident checks to define emergency de‑commission procedures.

Establish secure usage guidelines :

Set security configuration baselines to harden default settings and avoid exploitable conditions.

Unify public component versions to reduce maintenance cost and risk.

Encourage component packaging and customization to strengthen security and ensure sustainable support.

(2) Technical Support

Build an open‑source security management platform : Provide standardized security technical support, manage software artifacts, versions, inventories, and vulnerabilities throughout their lifecycle.

Optimize software repository security : Implement vulnerability scanning, sandbox behavior analysis, identity authentication, fine‑grained access control, and logging to ensure only approved open‑source packages are downloaded.

(3) Routine Management

Maintain an open‑source inventory : Continuously monitor risks, catalog existing open‑source components, and record versions, licenses, and vulnerabilities.

Optimize security management processes : Embed the security platform into the DevOps pipeline for automated component analysis, vulnerability detection, and remediation.

Enhance emergency response : Form a vulnerability analysis team, provide actionable remediation, and establish timely notification and remediation mechanisms for enterprise‑level open‑source software.

(4) Capability Building

Leverage open‑source security to boost development : Consolidate component versions, ensure timely updates, retire outdated versions, and enable secondary development to improve R&D efficiency.

Maintain an open‑source vulnerability database : Track and analyze vulnerabilities, offering technical support for rapid fixes.

Adopt SBOM for full‑cycle fine‑grained management : Use Software Bill of Materials to record components, licenses, and dependencies, enabling transparent supply‑chain risk management and compliance checks.

Conclusion

The Software Development Center will continue to implement the spirit of the Party’s 20th Congress, align with the bank’s strategic deployment, and follow the “48‑character” work approach. Guided by the Opinions, it will advance security architecture, strengthen open‑source software security management, reduce risks, and provide a robust technological safeguard for digital transformation.