Trong ngành Ngân hàng –  Tài chính – Bảo Hiểm, phần mềm không còn đơn thuần là công cụ hỗ trợ vận hành khi core banking, mobile banking, ví điện tử, hệ thống thanh toán, ứng dụng bảo hiểm và nền tảng dữ liệu đều trực tiếp liên quan đến tiền, danh tính và niềm tin của khách hàng.

Điều đó khiến một câu hỏi trở nên cấp thiết:

“Liệu doanh nghiệp có thực sự kiểm soát được phần mềm mình đang đưa vào production?”

Câu trả lời ngày càng khó khăn khi phần mềm hiện đại được xây dựng từ hàng nghìn dependency mã nguồn mở, container image, third-party package, API, cloud service và ngày càng nhiều thành phần được tạo hoặc hỗ trợ bởi AI.

Đây chính là lúc bảo mật chuỗi cung ứng phần mềm cần được nhìn nhận không còn là một vấn đề riêng của đổi ngữ DevOps, mà là một phần của chiến lược quản trị rủi ro và vận hành BFSI.

1. Áp lực kép từ pháp lý và tiêu chuẩn ngành

BFSI đang chịu tác động đồng thời từ hai phía: yêu cầu tuân thủ ngày càng cao và tốc độ thay đổi công nghệ ngày càng nhanh.

Tại Việt Nam, các yêu cầu về an toàn hệ thống thông tin và quản trị rủi ro đang thúc đẩy các tổ chức tài chính phải chứng minh rằng hệ thống của mình được bảo vệ một cách có kiểm soát, thay vì chỉ xử lý vấn đề sau khi sự cố xảy ra.

Đặc biệt, Thông tư 77/2025 tạo thêm động lực để các tổ chức trong lĩnh vực ngân hàng nâng cao năng lực quản lý an toàn thông tin, trong đó việc kiểm soát phần mềm và quy trình phát triển cần được nhìn nhận như một phần của tổng thể quản trị rủi ro.

Ở cấp độ quốc tế, các framework như NIST Secure Software Development Framework (SSDF) đưa security vào xuyên suốt vòng đời phát triển phần mềm, thay vì coi bảo mật là một bước kiểm tra cuối cùng. NIST nhấn mạnh rằng các thực hành phát triển an toàn cần được tích hợp trực tiếp vào SDLC để giảm vulnerability và xử lý nguyên nhân gốc của rủi ro.

Trong khi đó, SLSA (Supply-chain Levels for Software Artifacts) cung cấp một framework để doanh nghiệp từng bước nâng cao mức độ đảm bảo đối với software supply chain, bao gồm provenance và các bằng chứng về cách software artifact được tạo ra. 

Điều này dẫn đến một thay đổi quan trọng:

“Việc đảm bảo tuân thủ không còn chỉ là chứng minh hệ thống “đang được bảo vệ”, mà ngày càng phải chứng minh phần mềm được tạo ra, kiểm soát và triển khai như thế nào.”

2. Software Supply Chain: Điểm mù mới trong bức tranh đe dọa 2026–2027

Một ứng dụng ngân hàng có thể được phát triển nội bộ, nhưng rất ít khi được xây dựng hoàn toàn từ đầu. Một sản phẩm phần mềm hiện đại thường được cấu thành từ nhiều lớp khác nhau, không chỉ có source code do developer viết mà còn chưa open-source libraries, dependencies, packages từ public repositories, container images và third-party components. Mỗi thành phần lại có nguồn gốc, dependency và quy trình build riêng, khiến toàn bộ software supply chain trở nên phức tạp và khó kiểm soát hơn.

Trong khi đó, chỉ một mắt xích bị compromise cũng có thể tạo ra rủi ro cho toàn bộ ứng dụng. Attacker không nhất thiết phải tấn công trực tiếp vào hệ thống ngân hàng mà có thể tìm cách xâm nhập thông qua một dependency, package, build process hoặc artifact mà tổ chức đang tin tưởng. Vì vậy, khả năng kiểm soát và xác minh từng thành phần trong software supply chain đang trở thành một yêu cầu quan trọng đối với các tổ chức BFSI.

Đây cũng là lý do software supply chain security đang chuyển từ một bài toán kỹ thuật sang một vấn đề quản trị rủi ro ở cấp doanh nghiệp. Một vulnerability scan truyền thống có thể phát hiện các component đã có CVE hoặc vulnerability được biết đến, nhưng chưa chắc nhận diện được một package độc hại mới hoặc một hành vi bất thường trong quá trình build. Với những rủi ro này, việc chỉ kiểm tra sau khi component đã được đưa vào môi trường phát triển hoặc production là chưa đủ. Doanh nghiệp cần có cơ chế kiểm soát, xác minh và quản trị component ngay từ trước khi chúng được đưa vào software supply chain.

Xu hướng này càng trở nên đáng chú ý khi AI đang thúc đẩy tốc độ phát triển phần mềm. Bên cạnh AI-generated code, doanh nghiệp ngày càng sử dụng AI models, agentic tools và các developer workflows được hỗ trợ bởi AI, mở rộng thêm các thành phần cần được kiểm soát trong software supply chain. Điều này đồng nghĩa với việc security strategy cũng cần mở rộng từ việc tìm kiếm vulnerability sang xác minh nguồn gốc, tính toàn vẹn và mức độ tin cậy của software artifact.

Vì vậy, trong giai đoạn 2026–2027, câu hỏi đối với BFSI không còn đơn giản là “Ứng dụng này có CVE nào không?” mà cần được đặt ở một cấp độ sâu hơn: “Chúng ta có biết artifact này đến từ đâu, được build như thế nào, sử dụng những dependency nào và có bằng chứng nào chứng minh nó đáng tin cậy hay không?” Đây chính là khoảng trống mà mô hình Secure by Design và software supply chain security cần giải quyết.

3. Vì sao BFSI dễ bị ảnh hưởng hơn các ngành khác?

Không phải mọi ngành đều chịu cùng một mức độ rủi ro khi software supply chain bị compromise. Với BFSI, tác động của một cuộc tấn công vào chuỗi cung ứng phần mềm có thể đặc biệt nghiêm trọng bởi phần mềm ngày nay gắn trực tiếp với những tài sản có giá trị cao như giao dịch, tài khoản, dữ liệu khách hàng và hệ thống thanh toán. Một security incident vì thế không chỉ tạo ra chi phí để khắc phục sự cố, mà còn có thể kéo theo gián đoạn dịch vụ, tổn thất tài chính, ảnh hưởng đến uy tín và làm suy giảm niềm tin của khách hàng.

Bên cạnh đó, các tổ chức BFSI thường vận hành một hệ sinh thái công nghệ phức tạp, kết hợp hybrid environment, cloud workloads, legacy systems, APIs, microservices và hàng loạt third-party integrations. Một ứng dụng có thể sử dụng package từ public registry, trong khi package đó lại phụ thuộc vào nhiều thành phần khác trước khi được đóng gói thành container và đưa qua CI/CD pipeline. Khi chuỗi phụ thuộc ngày càng dài, việc xác định chính xác software đang được xây dựng từ những thành phần nào và đang chạy những gì trong production trở nên khó khăn hơn. Nếu thiếu software artifact governance, security team có thể không có đầy đủ visibility để đánh giá và kiểm soát toàn bộ software supply chain.

Quan trọng hơn, trust là một tài sản cốt lõi của BFSI. Khách hàng không chỉ sử dụng một ứng dụng mà còn trao cho ngân hàng và các tổ chức tài chính quyền quản lý tiền, dữ liệu và danh tính của họ. Vì vậy, một supply chain attack có khả năng tạo ra tác động vượt xa phạm vi của một security incident thông thường, bởi nó có thể ảnh hưởng đồng thời đến hoạt động kinh doanh, yêu cầu tuân thủ và niềm tin thị trường.

Bảo mật chuỗi cung ứng phần mềm vì thế không còn đơn thuần là một bài toán kỹ thuật của DevSecOps Việt Nam. Đối với BFSI, đây là một phần của việc đảm bảo tuân thủ, duy trì hoạt động kinh doanh và niềm tin của khách hàng. 

4. Giải pháp – Secure by Design

Nếu software supply chain là một hệ thống liên kết, việc chỉ scan ở cuối pipeline sẽ không đủ, mà các tổ chức trong ngành BFSI cần chuyển đổi mô hình vận hành của mình. 

4.1. Kiểm soát software artifact từ đầu

Doanh nghiệp cần biết mình đang sử dụng artifact nào, đến từ đâu và ai có quyền đưa artifact đó vào development environment.

Một nền tảng như JFrog Artifactory có thể đóng vai trò trung tâm quản lý software artifacts, giúp doanh nghiệp kiểm soát binary, package và container trong một hệ thống thống nhất.

Khi kết hợp với các capability như software composition analysis, curation, vulnerability scanning và SBOM management, doanh nghiệp có thể chuyển từ việc “scan những gì đã được sử dụng” sang govern những gì được phép sử dụng ngay từ đầu.

JFrog hiện cũng được Gartner ghi nhận là Leader trong Magic Quadrant đầu tiên dành cho Software Supply Chain Security năm 2026, cho thấy thị trường đang chuyển mạnh sang mô hình quản trị toàn diện software supply chain.

4.2. Giảm attack surface của container

Container đang trở thành thành phần phổ biến trong cloud-native và microservices architecture. Nhưng một container image có thể chứa hàng trăm package và dependency không thực sự cần thiết.

Càng nhiều thành phần, càng nhiều khả năng xuất hiện vulnerability.

Đây là lý do container security nên bắt đầu từ base image.

Trong đó, một trong những nền tảng container phổ biến nhất chính là Docker -nền tảng container phổ biến, giúp doanh nghiệp đóng gói, triển khai và quản lý ứng dụng một cách nhất quán trên nhiều môi trường. Với hệ sinh thái container linh hoạt và khả năng tích hợp vào quy trình CI/CD, Docker hỗ trợ đội ngũ phát triển rút ngắn thời gian triển khai, tối ưu quy trình DevOps và xây dựng ứng dụng dễ dàng mở rộng.

Với BFSI, cách tiếp cận này đặc biệt phù hợp với tư duy Secure by Design: thay vì liên tục xử lý một lượng lớn vulnerability sau khi image được tạo ra, hãy bắt đầu với một image có ít thành phần và được xây dựng với security là yêu cầu nền tảng.

4.3. Tạo bằng chứng về nguồn gốc phần mềm

Một phần quan trọng khác của SLSA là provenance.

Doanh nghiệp không chỉ cần biết “artifact này có an toàn không”, mà cần có khả năng trả lời:

• Artifact được build từ source nào?
• Build bởi workflow nào?
• Build environment nào?
• Dependency nào được sử dụng?
• Ai hoặc hệ thống nào tạo artifact?
• Artifact có bị thay đổi sau quá trình build không?

Khi provenance, SBOM và artifact metadata được quản lý xuyên suốt pipeline, security team có thể điều tra và phản ứng nhanh hơn khi xảy ra incident.

Đây cũng là nền tảng để doanh nghiệp tiến gần hơn tới SLSA compliance và các mô hình software supply chain security trưởng thành.

4.4. Đưa Security trở thành trách nhiệm chung

Cuối cùng, Secure by Design không thể thành công nếu chỉ giao cho Security Team.

Developer cần được cung cấp những component an toàn để sử dụng. DevOps cần pipeline có security control. Security Team cần visibility. Compliance cần audit trail. Và lãnh đạo cần nhìn software supply chain như một phần của enterprise risk.

Đó chính là tinh thần của DevSecOps: security không đứng bên ngoài quá trình phát triển để “kiểm tra”, mà trở thành một phần của cách phần mềm được xây dựng và vận hành.

5. BFSI không thể đợi đến khi có sự cố mới bảo vệ Software Supply Chain

Software supply chain đang trở thành một trong những lớp rủi ro quan trọng nhất của phần mềm hiện đại.

Với BFSI, vấn đề còn cấp thiết hơn bởi sự kết hợp giữa yêu cầu tuân thủ, dữ liệu nhạy cảm, hệ thống phức tạp và mức độ phụ thuộc ngày càng cao vào open source, cloud, containers và AI.

Vì vậy, câu hỏi chiến lược không còn là “Doanh nghiệp có đang scan vulnerability hay không?”

Mà là:

“Doanh nghiệp có thực sự biết và kiểm soát phần mềm đang chạy trong hệ thống của mình không?”

Secure by Design chính là bước chuyển từ phản ứng sang chủ động: kiểm soát component trước khi sử dụng, bảo vệ build process, xác minh provenance, quản lý SBOM, giảm attack surface của container và duy trì security xuyên suốt software lifecycle.

Đối với các tổ chức BFSI đang chuẩn bị cho giai đoạn 2026–2027, bảo mật chuỗi cung ứng phần mềm không nên được xem là một dự án Security bổ sung. Nó cần trở thành một nguyên tắc thiết kế của chính hệ thống phát triển phần mềm.

Bởi trong một ngành mà niềm tin là tài sản, việc biết phần mềm đến từ đâu, được xây dựng như thế nào và có thể tin cậy đến đâu không còn là lợi thế cạnh tranh.

Đó là điều kiện để duy trì niềm tin.

Softribution – Đồng hành cùng doanh nghiệp xây dựng Software Supply Chain Security

Softribution cung cấp các giải pháp DevSecOps, software supply chain security và container security cho doanh nghiệp tại Việt Nam, với hệ sinh thái công nghệ từ JFrog và Chainguard.

Nguồn tham khảo: 

Từ JFrog Artifactory, software artifact governance, SBOM và vulnerability management đến secure-by-default container images, doanh nghiệp có thể từng bước xây dựng mô hình Secure by Design phù hợp với yêu cầu bảo mật và tuân thủ của BFSI.

Tài liệu tham khảo: 

Ngân hàng Nhà nước Việt Nam. (2025). Thông tư số 77/2025/TT-NHNN sửa đổi, bổ sung một số điều của Thông tư số 50/2024/TT-NHNN quy định về an toàn, bảo mật cho việc cung cấp dịch vụ trực tuyến trong ngành Ngân hàng. Cổng Thông tin điện tử Chính phủ. https://vanban.chinhphu.vn/?pageid=27160&docid=216580

National Institute of Standards and Technology. (2021). Secure Software Development Framework (SSDF). Computer Security Resource Center, U.S. Department of Commerce. https://csrc.nist.gov/projects/ssdf

SLSA. (2026). About SLSA. Supply-chain Levels for Software Artifacts, The Linux Foundation. https://slsa.dev/spec/v1.2/about