作者 | JFrog大中華區(qū)總經(jīng)理董任遠

隨著AI應(yīng)用的規(guī)模不斷擴大以及大語言模型（LLM）的商品化，開發(fā)者越來越多地承擔起將人工智能（AI）和機器學習（ML）模型與軟件更新或新軟件一起打包的任務(wù)。雖然AI/ML在創(chuàng)新方面大有可為，但同時也加劇了人們的擔憂，因為許多開發(fā)人員沒有足夠的帶寬來安全地管理其開發(fā)。

安全漏洞可能無意中將惡意代碼引入 AI/ML 模型，從而使威脅行為者有了可乘之機，引誘開發(fā)者使用開放源碼軟件模型變種，滲透企業(yè)網(wǎng)絡(luò)并對組織造成進一步損害。甚至還有開發(fā)者越來越多地使用生成式AI來創(chuàng)建代碼，卻不知道自己生成的代碼是否受到威脅的情況，這同樣會導致安全威脅長期存在。因此，必須自一開始就對代碼進行適當?shù)膶彶?，以主動降低軟件供?yīng)鏈受到損害的威脅。

由于威脅行為者會想方設(shè)法利用AI/ML 模型，威脅將持續(xù)困擾著安全團隊。隨著安全威脅的數(shù)量不斷增加，規(guī)模不斷擴大，在2024 年開發(fā)者將更加重視安全性，并部署必要的保障措施，以確保其企業(yè)的彈性。

開發(fā)者的角色演變

對于開發(fā)者來說，在軟件生命周期初始階段就考慮到安全性是一種相對較新的做法。通常情況下，二進制級別的安全性被認為只是“錦上添花”的存在。而威脅行為者會利用這種疏忽，尋找將ML模型武器化以對抗組織的途徑，找出將惡意邏輯注入最終二進制文件的方法。

同樣，許多開發(fā)者由于沒有接受過必要的培訓，無法在開發(fā)的初始階段就將安全性嵌入到代碼中。由此造成的主要影響在于，由AI生成并在開源存儲庫上訓練的代碼通常沒有經(jīng)過適當?shù)穆┒磳彶?，且缺乏整體安全控制來保護用戶及其組織免受利用。盡管這可能會節(jié)省工作職能中的時間和其他資源，但開發(fā)者卻在不知不覺中將其組織暴露在眾多風險之下。一旦這些代碼在AI/ML 模型中實現(xiàn)，這些漏洞利用就會造成更嚴重的影響，而且有可能不會被發(fā)現(xiàn)。

隨著AI的廣泛應(yīng)用，傳統(tǒng)的開發(fā)者角色已不足以應(yīng)對不斷變化的安全環(huán)境。步入 2024 年，開發(fā)者也必須成為安全專業(yè)人員，從而鞏固 DevOps 和 DevSecOps 不能再被視為獨立工作職能的理念。通過從一開始就構(gòu)建安全解決方案，開發(fā)者不僅能確保關(guān)鍵工作流的最高效率，還能增強對組織安全性的信心。

通過“左移”，自始就安裝保障措施

如果安全團隊要在新的一年里對威脅保持警惕，那么 ML 模型的安全性就必須持續(xù)發(fā)展演進。然而，隨著AI的大規(guī)模應(yīng)用，團隊不能在軟件生命周期的后期才確定必要的安全措施，因為到那時，可能就真的為時已晚了。

組織內(nèi)部負責安全方面的高層必須以“左移”的方式進行軟件開發(fā)。通過堅持此方法，即能夠自一開始就確保軟件開發(fā)生命周期中所有組成部分的安全，并從整體上改善組織的安全情況。當應(yīng)用到AI/ML時，左移不僅能確認外部AI/ML系統(tǒng)中開發(fā)的代碼是否安全，還能確保正在開發(fā)的AI/ML模型不含惡意代碼，且符合許可要求。

展望 2024 年及以后，圍繞AI和 ML 模型的威脅將持續(xù)存在。如果團隊要持續(xù)抵御來自威脅行為者的攻擊并保護組織及其客戶，確保自軟件生命周期之始就考慮到安全性將是至關(guān)重要的。