火遍全球的小程式技術,軟體供應鏈安全也能幫得上忙?
我們的工作和生活已經離不開各式各樣的軟體。
趨勢所向。今年初白宮都不得不展開會議討論Log4J,拜登都得知道Java,是不是莫名魔幻?但對於碼農來說是不是略感自豪 - 相當於所在銀行行長、公司CEO深入IT基層,親自了解一個用Java寫的、通常埋在十八層程式碼之下的日誌工具,“並作出重要指示”的既視感...
那麼,軟體盛行的年代,企業中高管最怕的是什麼?
“某天,某銀行被盜取大量資料、遭受巨大經濟損失,並遭到消費者集體訴訟和監管天量罰單。原因是技術系統用了某個開原始碼包,該開原始碼包原來是一個遭駭客汙染過植入了後門的有毒元件。不小心誤用這個程式碼包的,是IT部門某基層小弟所為。新聞爆出,CIO一臉蒙圈,卒。”
上述例子的罪魁禍首,叫軟體供應鏈攻擊。這個問題的潛在風險,大到什麼程度呢?根據Gartner,至2025年全球有接近一半的企業會會遭遇到,感興趣的同學可以自行腦補...
“Hello,World”後面可能有幾萬行程式碼
開源軟體運動如火如荼的進行了二十四五年(如果從1998年2月3日在矽谷的一次會議中首次提出“open source”一說開始算 - 當時網際網路先驅Netscape剛剛宣佈開放他們的瀏覽器原始碼),極大程度的改變了軟體業的面貌。當前全球企業超過90%直接或者間接甚至在無意識中使用了開源技術。
時間快進到2022年,很多企業的業務軟體裡可能只有低至10%的程式碼是自己的工程師寫的,其他的都來源於不知名的開源世界,開發者自己都不知道,供應鏈被汙染了,影響到自己,也殃及其他“租戶”。“物業”呢,則不排除內部人員有道德風險,做倒賣“租戶”資產(例如資料)的事情。
你想用JavaScript+Node.js開發一個只能對網路請求返回“Hello,World”回覆的微服務,你決定採用一個最輕量簡約的微服務框架ExpressJS - 一動手的瞬間,你的開發工具npm就給你從上游拉取100+軟體包 - 54,000行程式碼拿去,不謝。如果你想再玩點高階功能,例如新增一個MVC框架(例如Locomotive),你的這個“微”服務實際程式碼量馬上升至220,000行 - 不好意思,起步價,哪怕你只寫一行程式碼。
軟體供應鏈的四大風險
對於企業來說,當前軟體供應鏈起碼面臨四類風險。
-
軟體質量風險。企業軟體表面上由IT或者外包商開發,可是實質上背後是成千上萬的第三方開原始碼,企業的QA工程質量管理方法和流程,對於第三方完全失控無效。
-
長期支援風險。企業軟體所間接依賴的一些第三方開源零部件,並沒有商業體在背後提供質量承諾和長期支援。開源專案因創始人退出或者社群活躍度低而不再維護、半途而廢的,不在小數。產生維護支援需求時,企業自己不得不安排人手去處理該部分程式碼,先不說有沒有這個意願,企業自己的IT工程師是否有這個能力也難說。
-
智慧財產權風險。開源軟體的智慧財產權機制,反映在著佐權(Copyleft)和許可證(Permissive)。後者約束了你的軟體的分發傳播需要滿足的條件,前者則往往更進一步要求你用開源元件開發的軟體本身的原始碼必須沿用同樣的開源條款,導致你的軟體智慧財產權不得不公開。國內軟體企業在使用開源、貢獻開源的過程中規則意識普遍薄弱,存在錯誤混用不相容的許可證,違反許可證規定二次釋出等問題,帶來更為複雜的智慧財產權問題和法律合規風險。
-
資訊保安風險。在開發人員寫第一行程式碼前,一個系統可能就註定繼承了一堆“安全債務” - 部分取決於這個系統的設計者、開發者選擇採用什麼第三方元件,部分取決於這些第三方元件的開發者又選擇依賴於什麼別的元件。反正安全風險是傳遞的,只要有一個零部件有安全漏洞、甚至是在漫長複雜的網際網路分發鏈路上被篡改過注入了惡意程式碼,你的系統就繼承了所有這些風險。
在資訊化程度比較高的金融業,軟體作為金融資訊基礎設施的重要組成部分,安全問題將直接影響金融資訊系統的安全穩定執行。
小程式安全沙箱類技術的盛行
首先說說小程式生態。在BAT等巨頭的帶動下,市場上已經有11大小程式平臺,700W+的小程式應用,覆蓋200+個細分垂直領域,可見,小程式生態在國內已經具備相當影響力的規模。正因為如此迅猛的發展,網際網路系列全球標準的制定者W3C,也正在透過其Mini-Apps工作組制定小程式技術的國際標準。
然後說說App外掛生態。作為Web 2.0的標誌性技術產物,歷經網際網路蓬勃發展的市場需求的迭代,衍生出許多標準化的、能夠降低App(甚至擴充套件至移動裝置)開發的外掛式SDK:極光推送、聲網音影片、第三方登入、第三方支付.....
再說說小程式安全沙箱技術。如果將小程式和移動裝置外掛比喻成“點”,那麼小程式安全沙箱技術(例如:FinClip)就是能夠讓一個個點組裝成App的“線”。FinClip小程式容器技術的價值點之一在於「連線」:只要把FinClip SDK嵌入到自己的App中,馬上獲得小程式執行能力,而只有獲得小程式執行能力,才能在App中充分引入成熟的小程式應用。
此外, 在軟體供應鏈安全防護上,小程式容器技術天然的安全隔離能力,透過構建一個封閉的軟體環境,隔離了它所在的“宿主”的資源包括記憶體、檔案系統、網路等等的訪問許可權。執行在這個封閉環境中的程式,其程式碼不受信任,程式不能因為其自身的穩定性導致沙箱的崩潰從而影響宿主系統,程式也無法突破沙箱的安全管控以讀寫宿主系統的資源。
俗話說,天時-地利-人和,現代社會快節奏市場強壓下,如果還是老式的思想,企業重複造車輪,那麼鐵定是跟不上使用者快速變化的需求。只有充分利用各領域構建起來的成熟生態,以互聯互通、合作共贏的方式方能發揮企業1+1>2的效應。
小程式容器技術便是一個非常好的「技術催化劑」,將小程式應用生態、移動裝置外掛生態、移動裝置有機的“粘合”在一起,且Plus一個安全沙箱的機制,對軟體供應鏈安全的端側進行安全隔離和防護。感興趣的可以登陸FinClip官網瞭解一下。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/70023421/viewspace-2920625/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 軟體供應鏈安全
- 火熱報名中|OSCS 軟體供應鏈安全技術論壇議程搶先看
- 開源軟體能幫上SOA多大的忙
- Kubernetes 時代的安全軟體供應鏈
- 再談“開源軟體供應鏈安全”
- 解決軟體供應鏈安全問題
- 軟體供應鏈安全如何受到駭客的威脅
- 影響軟體供應鏈安全的10大風險因素
- 中國信通院首屆3SCON軟體供應鏈安全會議成功召開 聚焦軟體供應鏈全鏈路安全
- 全球供應鏈和物流技術投資資料盤點
- 倒數計時 | 2021 OWASP中國軟體開發與供應鏈安全技術論壇
- 無技術基礎也能學會搭建小程式的方法!
- NSA 和 CISA分享保護軟體供應鏈安全指南
- 軟體供應鏈中斷時代
- 網路安全行政命令:保護軟體供應鏈
- 數字生態系統安全演進:軟體供應鏈中的API安全API
- 基於 Docker 的現代軟體供應鏈Docker
- 解決軟體供應鏈安全問題需要關注哪些問題
- 軟體供應鏈風險評估:實現安全 SDLC有哪些步驟
- 簡析《美國白宮<利用安全的軟體開發實踐增強軟體供應鏈的安全性>備忘錄》
- 區塊鏈技術結合供應鏈金融解決方案區塊鏈
- 【供應鏈】供應鏈高手必須掌握的79個專業術語
- 基於區塊鏈技術的反向保理模式供應鏈金融研究區塊鏈模式
- 區塊鏈技術構造出的全新供應鏈資訊平臺架構區塊鏈架構
- PokémonGo火遍全球,開啟全民捕捉小精靈的時代Go
- 區塊鏈應技術應用開發方案,區塊鏈技術為企業賦能區塊鏈
- 評估軟體供應鏈安全可關注這5個關鍵問題
- RSA創新沙盒盤點 | Cycode——軟體供應鏈安全完整解決方案
- 京東為openKylin新增SBOM利器,保障軟體供應鏈安全和可追溯性!
- 聚合供應鏈電商系統開發軟體流程
- 構建安全程式碼 防止供應鏈攻擊
- 讓企業數字化砸鍋和IT主管背鍋的軟體供應鏈安全風險
- 謝謝斑竹能否幫個忙!! (改個小程式)
- 「技術層面」詳解供應鏈管理平臺主流技術架構方案架構
- 安勢資訊加入Linux基金會OpenChain專案,助力軟體供應鏈安全LinuxAI
- 醫療裝置製造商如何在軟體供應鏈中提高網路安全
- 華為雲CodeArts 12大安全防護機制,端到端全面保障軟體供應鏈安全!
- 2023年軟體供應鏈風險管理指南