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

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

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

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

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

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

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

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

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

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

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

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