在業務系統構建中使用庫的風險與對策

在現代，「函式庫」這種系統部件已成為業務系統構建的必需品。然而，使用函式庫也存在風險。若對風險掉以輕心，可能引發問題，甚至可能導致資訊洩露等嚴重損害。本文將針對使用函式庫所潛藏的風險及其對策進行解說。

何謂「函式庫」

在建構業務系統時，系統公司幾乎不會完全自行創建所需的程式。相反地，他們通常會使用「現成的軟體部件」來建立基礎，並補充自家製作的部分。這種現成的軟體部件被稱為「函式庫」。一般來說，開發通用功能時會使用函式庫。所謂的通用功能，如「登入功能」或「從資料庫獲取資料的功能」，無論在哪個行業或哪個國家的系統中，都是需求量高的功能。這些需求量高的功能，都有相應的函式庫存在。然而，對於滿足客戶獨特需求的非通用功能，由於不存在現成的函式庫，系統公司需要自行創建。

另外，「函式庫」這個詞與「框架」有相似的意義。還有一個詞叫做OSS（開源軟體）。在業務系統的語境中，OSS是系統的部件，與本文中所說的函式庫是同一個概念，可能是您更熟悉的詞彙。但在本文中，本所將統一使用「函式庫」這個詞。

圖書館的優點：快速且安全

系統公司優先使用圖書館而非自製的原因有兩個：

• 比自製更快
• 比自製更安全

使用現成的產品自然會更快，但在安全性方面也有優勢，這是一個重要的特點。這是因為，知名的圖書館由全球優秀的工程師和企業持續進行開發、驗證和生產環境的使用，對已知的攻擊方法有所對策，即使發現新的攻擊方法，也可以期待快速更新。相反，如果不使用圖書館，而是自己製作，可能需要花費額外的時間來進行專家審查等，以研究安全性問題。在這種情況下，可能會花費成本來提高安全性。由於這些原因，如果想要更快、更安全地進行系統開發，使用圖書館變得非常重要。

圖書館的缺點是什麼

使用圖書館可以快速且安全地建立系統，對客戶和系統公司雙方都有很大的好處。然而，使用圖書館也存在一定的成本。此外，如果不更新，可能會混入「漏洞」，如果更新，系統可能無法運行，這也是一種兩難的情況。

如果不更新，就會有漏洞

犯罪者每天都在尋找圖書館（包括所有軟件）的安全缺陷，以盗取個人信息、信用卡信息和企業秘密。這些安全缺陷在IT術語中被稱為「漏洞」。有很多例子是利用了圖書館中的漏洞而受到損害。例如，日本國土交通省的問卷調查網站使用的Struts2圖書館的漏洞被攻擊，導致大約20萬條客戶信息洩露的案例，以及使用同樣的Struts2的票務銷售網站可能洩露了32187條信用卡信息的案例。在系統交付時，可能會發現之前未知的圖書館漏洞。

更新帶來的系統停機風險

在實際操作中，即使存在漏洞，也可能無法更新。這是因為更新可能會導致系統暫時無法運行。由於圖書館不是系統公司寫的程序，所以很難完全掌握其內容。因此，更新可能會導致系統出現意外的問題，使系統暫時無法運行，這種風險是無法完全排除的。作為客戶，可能會對不了解交付系統內容的系統公司感到憤怒。然而，事實上，現代系統使用的圖書館在質量和數量上都超出了一個系統公司的應對能力。例如，用於構建用戶界面的圖書館中最受歡迎的「React」。這個圖書館在質量上是由Facebook的工程師創建的高級產品，在數量上，代碼行數達到195486行（*1），是一個龐大的數量。

因脆弱性而導致訴訟的案例

當由於庫的脆弱性造成損害時，誰應該負責呢？這裡有一個可以參考的案例，那就是東京地方裁判所於平成26年（2014年）1月23日的判決。原告委託被告的系統公司建立銷售系統。然而，在系統運行後，由於系統的脆弱性，終端用戶的信用卡信息被洩露，原告因此需要道歉和調查，並因此遭受了約3200萬日元的損失，從而引發了爭議。在原告和被告簽訂的契約中，有一條免責條款規定，如果因被告的過失造成損害，賠償金額應限於契約金額。是否可以應用這個免責條款成為了爭點。判決認為，被告存在重大過失，如果存在重大過失，則不能應用免責條款，因此命令被告支付超過契約金額的賠償。

被告作為一家從事信息處理系統規劃、網頁製作、業務系統開發等業務的公司，利用專業的程序知識開展業務，並提供本案的網絡應用程序作為業務的一部分，原告信賴其專業知識並簽訂了本案的系統訂購契約，被告應承擔的注意義務程度應認定為相對較高。如前所述，如果沒有採取SQL注入攻擊的對策，第三方可能通過SQL注入攻擊從本案的數據庫中洩露個人信息，這種情況是被告可以預見的，並且，經濟產業省和IPA將SQL注入攻擊列為對網絡應用程序的代表性攻擊手段，（中略）提醒注意，因此，可以輕易預見可能發生這種情況。此外，通過使用綁定機制或進行轉義處理，可以避免本案的洩露結果，（中略：為了避免的處理的技術對策的意義）並沒有證據表明需要花費大量的勞力或費用，可以說避免本案的洩露結果是容易的。
因此，應認定被告存在重大過失。

東京地方裁判所平成26年（2014年）1月23日

以下是一般財團法人軟體信息中心將此判例應用於庫脆弱性的解釋。

如果以這個判例的思考方式為前提，即使由於OSS的缺陷（脆弱性等）導致用戶遭受損害，如果可以認定供應商對脆弱性的應對存在故意或重大過失，就像本案一樣，免責條款（責任限制條款）的適用可能會受到限制，很可能無法獲得免責的效果。然而，如果在公開OSS脆弱性的對策信息後立即受到攻擊，可能會否定結果的容易避免性等，可能不會認定為重大過失。

IoT時代中的OSS使用和法律問題Q&A集[PDF][ja] （第84頁）

因此，即使是由庫引起的脆弱性，如果該脆弱性是已知的，並且可以輕易預見攻擊，那麼系統公司可能會被認為有高度的責任。

更實際的弱點對策是什麼？

如果由於系統公司的故意或重大過失導致信息洩露，從法律角度來看，可以通過訴訟獲得賠償。然而，從實務角度來看，最重要的是防止信息洩露。即使通過訴訟獲得賠償，也無法恢復因信息洩露而失去的終端用戶的信任。因此，以下兩點非常重要：

1. 簽訂包括庫更新在內的維護合約
2. 弱點診斷

簽訂包括庫更新在內的維護合約

業務系統建設合約中，有只委託開發和委託維護的情況。如果公司內沒有能夠進行維護的專家，那麼簽訂維護合約是適當的。在合約中，應該要求系統公司進行包括庫更新在內的弱點對策，並明確系統公司的應對義務和客戶的支付義務，以防止問題的發生。在強制系統公司以專家的身份應對的同時，客戶也需要承擔足夠的成本來委託專家。

弱點診斷

隨著系統處理的數據量和對UI的需求日益增大，新發現的弱點數量也在持續增加。因此，僅靠系統公司完全防止弱點的混入是困難的。因此，弱點診斷變得必要。根據IPA的說法，全體的50%以上，大企業等的80%的業者都進行了弱點診斷。

弱點診斷有從免費的工具到高價的手動診斷等各種方式。特別是處理洩露可能會導致致命後果的信息的情況下，將弱點診斷委託給專門進行弱點診斷的業者並投入足夠的成本進行對策是必須的。此外，由於弱點每天都在被發現，因此不僅在交付時，而且在交付後也需要持續進行弱點診斷[ja] (P15)。

總結

本文中，本所對於使用程式庫所帶來的風險以及應對方法進行了詳細的解釋。程式庫雖然非常便利，但如果不進行更新，就可能產生漏洞，導致資訊洩露等損害，這也是一種風險。從法律角度來看，如果系統公司有重大過失，則有可能獲得資訊洩露的賠償，但實際上，最重要的是採取措施以防止資訊洩露的發生。因此，應該在合約中就程式庫的更新工時和漏洞診斷達成一致。如果不使用程式庫，則幾乎不可能在交貨期和功能上達到所需的水平。為了在避免問題的同時享受程式庫的優點，本所認為需要在系統公司之間就更新成本和對漏洞的措施達成共識。為了避免資訊洩露對業務造成致命的打擊，本所認為不僅要關注功能、屏幕佈局、價格等因素，還應在簽訂合約時就對安全性給予充分的注意。