<p>從潛在開發者到六歲的小孩都在跳上 vibe 編碼的潮流，因此不難理解，罪犯們也喜歡自動化編碼工具。</p>
<p>“每個人都在問：vibe 編碼是否用於惡意軟件？而現在的答案很可能是肯定的，” Palo Alto Networks 的 Unit 42 高級諮詢總監 Kate Middagh 在接受 <em>The Register</em> 採訪時表示。</p>
<blockquote>
<p>我們合作的組織中，只有大約一半對 AI 有任何限制。</p>
</blockquote>
<p>然而，對防禦者來説，銀 lining 是，AI 模型即使在被要求編寫贖金信時也會犯錯，這意味着 vibe 編碼攻擊可能會失敗。</p>
<p>與任何新技術一樣，AI 輔助編碼引入了許多安全漏洞，包括企業開發團隊可能加速工作到安全團隊無法匹配的速度。</p>
<p>AI 代理和系統訪問和提取不應接觸的數據也存在風險，以及提示和內存注入攻擊。</p>
<p>還有罪犯或政府支持的黑客團隊使用 LLM 編寫惡意軟件或策劃整個攻擊的風險——儘管這兩者仍然需要人類參與，但最壞的情況正逐漸接近現實安全事件。</p>
<h3>Vibe 編碼 SHIELD</h3>
<p>為了幫助公司更好地管理這些風險，Palo Alto Networks 開發了他們所稱的 &#34;SHIELD&#34; 框架，旨在在整個編碼過程中設置安全控制。Middagh 領導 Unit 42 的 AI 安全服務業務，並在週四共同撰寫了一篇關於 SHIELD 框架的博客，並提前與 <em>The Register</em> 分享。</p>
<p>“我們合作的組織中，只有大約一半對 AI 有任何限制，” 她説。</p>
<p>SHIELD 代表：</p>
<ul>
<li>S – 職責分離：這涉及通過限制代理僅限於開發和測試環境來限制訪問和權限。</li>
<li>H – 人類參與：要求人類進行代碼審查，並在代碼合併之前需要拉取請求的批准。</li>
<li>I – 輸入/輸出驗證：包括使用分離提示分區、編碼、基於角色的分離等方法來清理提示，然後要求 AI 通過靜態應用程序安全測試 (SAST) 在開發後執行邏輯檢查和代碼驗證。</li>
<li>E – 強制安全專注的輔助模型：開發輔助模型——專門設計用於為 vibe 編碼應用程序提供自動安全驗證的代理——執行 SAST 測試、秘密掃描、安全控制驗證和其他驗證功能。</li>
<li>L – 最小權限：僅授予 vibe 編碼工具和 AI 代理執行其角色所需的最低權限和能力。</li>
<li>D – 防禦性技術控制：在使用這些工具之前，在供應鏈和執行管理的組件周圍採用防禦性控制，並禁用自動執行，以允許在部署後進行人類參與。</li>
</ul>
<p>我們稍後會詳細討論。但首先，回到 vibe 編碼惡意軟件。</p>
<p>Middagh 和她的 Palo Alto 同事並不總能明確判斷開發者是否使用了 vibe 編碼平台來創建惡意軟件。有些代碼通過包含水印來簡化這一過程，驗證代碼是由 Cursor、Replit、Claude 或其他 AI 工具生成的。</p>
<p>她也不會説哪個工具在罪犯中最受歡迎，儘管她確實提到他們正在使用 &#34;多個&#34; 產品，&#34;根據這些平台的普遍受歡迎程度，你可以推測出每個產品的受歡迎程度。&#34;</p>
<p>Palo Alto 的網絡風險諮詢團隊還觀察到環境中存在 &#34;一系列不同的模式，表明&#34; 使用編碼平台開發惡意軟件，Middagh 補充道。而 Middagh 目睹的其中一個模式——惡意軟件開發者直接在代碼中寫入對大型語言模型的 API 調用——是惡意軟件開發者正在進行 vibe 編碼的有力證據。</p>
<p>“因此，在惡意軟件本身中，有對 OpenAI 或其他平台的 API 調用，詢問如何生成惡意軟件，如何生成聽起來合法的社會工程郵件，” 她解釋道，並將其描述為 &#34;直接且不可辯駁的證據，證明他們在惡意軟件開發過程中使用了這些 LLM。&#34;</p>
<h3>'安全表演'</h3>
<p>攻擊者還在使用 LLM 進行 Middagh 所稱的 &#34;安全表演&#34;。這段代碼看起來會產生有效的攻擊，但由於各種原因無效，包括沒有針對特定環境進行定製。&#34;它看起來像是一個有效的攻擊，&#34;她説，&#34;但如果你稍微深入挖掘一下，你會發現：‘嘿，等一下，這實際上沒有意義。’&#34;</p>
<p>這包括 &#34;懸而未決的攻擊策略&#34;，其中 LLM 會生成一種規避技術，例如。&#34;但這種規避技術實際上並不符合我們通常看到的現代惡意行為者，或者它將是從未在環境中實際實施的規避技術——它只是作為對 LLM 的 API 調用的副產品生成的，&#34; Middagh 説。</p>
<p>在一次這樣的事件中，Unit 42 記錄了發送給 OpenAI 的 GPT-3.5 Turbo 的提示，使用標準 API 請求模型 &#34;生成一個簡單的規避技術，用於數據提取工具，並僅返回技術名稱，最多三個單詞，以幫助避免檢測，&#34;她説。該提示包括這些示例：&#34;隨機延遲、進程欺騙、內存混淆。&#34;</p>
<blockquote>
<p>我們看到 LLM 會稱其為 'readme.txtt' 的幻覺實例。這是威脅行為者絕對不會犯的錯誤——這就像是勒索軟件 101。</p>
</blockquote>
<p>按照指示，LLM 返回了一個技術名稱，但 LLM 僅登錄到受害者的桌面——並沒有實施規避技術。&#34;它只是為了展示和純粹的記錄而出現，&#34;Middagh 説。&#34;可能有辦法讓它工作，但在環境中從未適當地實施。&#34;</p>
<p>雖然她無法確切知道攻擊者為何選擇進行安全表演而非真實攻擊，但 “如果我必須猜測，我認為這只是一個輸出，” Middagh 説。“大型語言模型將生成大量代碼，攻擊者在匆忙中，沒有驗證代碼輸出中的所有內容，因此會出現錯誤。”</p>
<p>換句話説，當被要求生成惡意代碼時，AI 工具會產生與被要求編寫合法代碼時相同的錯誤。</p>
<p>幻覺仍然是 AI 的一個常見陷阱，即使是勒索軟件開發者也感受到這種痛苦。</p>
<p>在感染受害者的機器後，勒索者會在桌面上留下一個名為 “readme.txt” 的自述文件，其中包含贖金通知和金錢要求。</p>
<p>“我們看到幻覺的實例，其中大型語言模型會稱其為 ‘readme.txtt’，” Middagh 説。“這是威脅行為者絕對不會犯的錯誤——這就像是勒索軟件的基礎知識。但我們現在看到的是，他們行動得太快，沒有進行太多驗證或檢查，這些事情就發生了。他們對所有事情都採取了全力以赴的態度。”</p>
<p>攻擊者並不是唯一在使用缺乏人類情境意識且優先考慮功能而非安全的 AI 模型時犯錯誤的人。</p>
<p>大多數允許員工使用氛圍編碼工具的組織也沒有對這些工具進行任何正式的風險評估，也沒有實施監控輸入和輸出的安全控制措施。</p>
<p>“如果你是一家企業，有幾種方法可以控制和應對氛圍編碼的風險，” Middagh 説。第一步涉及將最小權限和最小功能原則應用於 AI 工具，就像對待人類用户一樣，僅授予完成工作所需的最低角色、責任和權限。</p>
<p>“每個人都對使用 AI 感到非常興奮，希望他們的開發者能更快，因此整個最小權限和最小功能模型完全被忽視了，” Middagh 説。</p>
<p>接下來，她建議將使用限制為員工可以使用的一個對話型大型語言模型，並在防火牆上阻止所有其他 AI 編碼工具。對於那些決定在其環境中需要氛圍編碼工具的組織，“前進的方式將是 SHIELD 框架，” Middagh 説。®</p>

派拓網絡

<p>根據 Palo Alto Networks 的 Kate Middagh 的説法，犯罪分子越來越多地使用人工智能工具進行惡意軟件開發。雖然人工智能輔助編碼可能引入安全漏洞，但它也存在缺陷，可能導致攻擊失敗。為了降低風險，Palo Alto 推出了 SHIELD 框架，強調在整個編碼過程中實施安全控制。這包括限制訪問、要求人工代碼審查以及採用專門的安全驗證模型。證據表明，惡意軟件開發者正在直接將 API 調用集成到人工智能平台中，這表明了一種向人工智能輔助網絡犯罪發展的趨勢</p>

<p>Interview With everyone from would-be developers to six-year-old kids jumping on the vibe coding bandwagon, it shouldn't be surprising that criminals like automated coding tools too.</p>
<div class="lb-trans"><p>從潛在開發者到六歲的小孩都在跳上 vibe 編碼的潮流，因此不難理解，罪犯們也喜歡自動化編碼工具。</p>
</div><p>&#34;Everybody's asking: Is vibe coding used in malware? And the answer, right now, is very likely yes,&#34; Kate Middagh, senior consulting director for Palo Alto Networks' Unit 42, told <em>The Register</em>.</p>
<div class="lb-trans"><p>“每個人都在問：vibe 編碼是否用於惡意軟件？而現在的答案很可能是肯定的，” Palo Alto Networks 的 Unit 42 高級諮詢總監 Kate Middagh 在接受 <em>The Register</em> 採訪時表示。</p>
</div><blockquote>
<p>Only about half of the organizations that we work with have any limits on AI</p>
</blockquote>
<div class="lb-trans"><blockquote>
<p>我們合作的組織中，只有大約一半對 AI 有任何限制。</p>
</blockquote>
</div><p>The silver lining for defenders, however, is that AI models – even when asked to write ransom notes – make mistakes, meaning vibe-coded attacks can fail.</p>
<div class="lb-trans"><p>然而，對防禦者來説，銀 lining 是，AI 模型即使在被要求編寫贖金信時也會犯錯，這意味着 vibe 編碼攻擊可能會失敗。</p>
</div><p>As with any shiny new technology, AI-assisted coding introduces many security vulnerabilities, including the potential for enterprise development teams to accelerate their work to a speed that security teams can't match.</p>
<div class="lb-trans"><p>與任何新技術一樣，AI 輔助編碼引入了許多安全漏洞，包括企業開發團隊可能加速工作到安全團隊無法匹配的速度。</p>
</div><p>There are also risks from AI agents and systems accessing and exfiltrating data they shouldn't be allowed to touch, plus prompt and memory injection attacks.</p>
<div class="lb-trans"><p>AI 代理和系統訪問和提取不應接觸的數據也存在風險，以及提示和內存注入攻擊。</p>
</div><p>And then there's the risk of criminals or government-backed hacking teams using LLMs to write malware or orchestrate entire attacks – and while both of these still require a human in the loop, the worst-case scenarios are getting closer to real-life security incidents.</p>
<div class="lb-trans"><p>還有罪犯或政府支持的黑客團隊使用 LLM 編寫惡意軟件或策劃整個攻擊的風險——儘管這兩者仍然需要人類參與，但最壞的情況正逐漸接近現實安全事件。</p>
</div><h3>Vibe coding SHIELD</h3>
<div class="lb-trans"><h3>Vibe 編碼 SHIELD</h3>
</div><p>To help companies better manage these risks, Palo Alto Networks developed what it calls the &#34;SHIELD&#34; framework for vibe coding, which is all about placing security controls throughout the coding process. Middagh, who leads Unit 42's AI security services engagements biz, co-authored a Thursday blog about the SHIELD framework and shared it in advance with <em>The Register</em>.</p>
<div class="lb-trans"><p>為了幫助公司更好地管理這些風險，Palo Alto Networks 開發了他們所稱的 &#34;SHIELD&#34; 框架，旨在在整個編碼過程中設置安全控制。Middagh 領導 Unit 42 的 AI 安全服務業務，並在週四共同撰寫了一篇關於 SHIELD 框架的博客，並提前與 <em>The Register</em> 分享。</p>
</div><p>&#34;Only about half of the organizations that we work with have any limits on AI at all,&#34; she said.</p>
<div class="lb-trans"><p>“我們合作的組織中，只有大約一半對 AI 有任何限制，” 她説。</p>
</div><p>SHIELD stands for:</p>
<div class="lb-trans"><p>SHIELD 代表：</p>
</div><ul>
<li>S – Separation of Duties: This involves limiting access and privileges by restricting agents to development and test environments only.</li>
<li>H – Human in the Loop: Mandate code review performed by a human and require a pull request approval prior to code merge.</li>
<li>I – Input/Output Validation: Including using methods such as separating prompt partitioning, encoding, role-based separation to sanitize prompts and then requiring the AI to perform validation of logic checks and code through Static Application Security Testing (SAST) after development.</li>
<li>E – Enforce Security-Focused Helper Models: Develop helper models – specialized agents designed to provide automated security validation for vibe-coded applications – to perform SAST testing, secrets scanning, security control verification, and other validation functions.</li>
<li>L – Least Agency: Only grant the minimum permissions and capabilities required to vibe-coding tools and AI agents needed to perform their roles.</li>
<li>D – Defensive Technical Controls: Employ defensive controls around supply chain and execution management on components before using these tools, and disable auto-execution to allow for human-in-the-loop after deployment.</li>
</ul>
<div class="lb-trans"><ul>
<li>S – 職責分離：這涉及通過限制代理僅限於開發和測試環境來限制訪問和權限。</li>
<li>H – 人類參與：要求人類進行代碼審查，並在代碼合併之前需要拉取請求的批准。</li>
<li>I – 輸入/輸出驗證：包括使用分離提示分區、編碼、基於角色的分離等方法來清理提示，然後要求 AI 通過靜態應用程序安全測試 (SAST) 在開發後執行邏輯檢查和代碼驗證。</li>
<li>E – 強制安全專注的輔助模型：開發輔助模型——專門設計用於為 vibe 編碼應用程序提供自動安全驗證的代理——執行 SAST 測試、秘密掃描、安全控制驗證和其他驗證功能。</li>
<li>L – 最小權限：僅授予 vibe 編碼工具和 AI 代理執行其角色所需的最低權限和能力。</li>
<li>D – 防禦性技術控制：在使用這些工具之前，在供應鏈和執行管理的組件周圍採用防禦性控制，並禁用自動執行，以允許在部署後進行人類參與。</li>
</ul>
</div><p>We'll talk more about that in a minute. But first, back to vibe-coded malware.</p>
<div class="lb-trans"><p>我們稍後會詳細討論。但首先，回到 vibe 編碼惡意軟件。</p>
</div><p>Middagh and her Palo Alto colleagues can't always definitively determine if developers used a vibe-coding platform to create malware. Some code makes it easy by including a watermark that verifies the code was generated by Cursor, Replit, Claude, or some other AI tool.</p>
<div class="lb-trans"><p>Middagh 和她的 Palo Alto 同事並不總能明確判斷開發者是否使用了 vibe 編碼平台來創建惡意軟件。有些代碼通過包含水印來簡化這一過程，驗證代碼是由 Cursor、Replit、Claude 或其他 AI 工具生成的。</p>
</div><p>She also won't say which tool is most popular with criminals, although she did note that they are using &#34;multiple&#34; products, &#34;and just given the general popularity of vibe-coding platforms, you can probably extrapolate based on the popularity of each of these.&#34;</p>
<div class="lb-trans"><p>她也不會説哪個工具在罪犯中最受歡迎，儘管她確實提到他們正在使用 &#34;多個&#34; 產品，&#34;根據這些平台的普遍受歡迎程度，你可以推測出每個產品的受歡迎程度。&#34;</p>
</div><p>Palo Alto's cyber-risk consulting team has also seen &#34;a bunch of different patterns in the environment that are indicative&#34; of using coding platforms to develop malware, Middagh added. And one of these that Middagh has witnessed – malware developers writing API calls to large language models directly into the code – is strong evidence that malware scum are vibe coding.</p>
<div class="lb-trans"><p>Palo Alto 的網絡風險諮詢團隊還觀察到環境中存在 &#34;一系列不同的模式，表明&#34; 使用編碼平台開發惡意軟件，Middagh 補充道。而 Middagh 目睹的其中一個模式——惡意軟件開發者直接在代碼中寫入對大型語言模型的 API 調用——是惡意軟件開發者正在進行 vibe 編碼的有力證據。</p>
</div><p>&#34;So within the malware itself, there's API calls to OpenAI or other platforms asking how to generate malware, how to generate social engineering emails to make them sound legitimate,&#34; she explained, describing this as &#34;direct and incontrovertible proof that they are using these LLMs in the course of their malware development.&#34;</p>
<div class="lb-trans"><p>“因此，在惡意軟件本身中，有對 OpenAI 或其他平台的 API 調用，詢問如何生成惡意軟件，如何生成聽起來合法的社會工程郵件，” 她解釋道，並將其描述為 &#34;直接且不可辯駁的證據，證明他們在惡意軟件開發過程中使用了這些 LLM。&#34;</p>
</div><h3>'Security theater'</h3>
<div class="lb-trans"><h3>'安全表演'</h3>
</div><p>Attackers are also using LLMs for what Middagh calls &#34;security theater.&#34; This is code that looks like it would produce a valid attack, but it's ineffective for a variety of reasons, including not being customized to a specific environment. &#34;It has the appearance of being a valid attack,&#34; she said, &#34;but if you do just a little bit more digging, you're like: 'Hey, wait a minute, this doesn't actually make sense.'&#34;</p>
<div class="lb-trans"><p>攻擊者還在使用 LLM 進行 Middagh 所稱的 &#34;安全表演&#34;。這段代碼看起來會產生有效的攻擊，但由於各種原因無效，包括沒有針對特定環境進行定製。&#34;它看起來像是一個有效的攻擊，&#34;她説，&#34;但如果你稍微深入挖掘一下，你會發現：‘嘿，等一下，這實際上沒有意義。’&#34;</p>
</div><p>This includes &#34;dangling attack strategies,&#34; in which an LLM will generate an evasion technique, for example. &#34;But that evasion technique won't really be aligned with what we typically see for modern-day bad actors, or it'll be an evasion technique that was never actually implemented in the environment – it was just generated as a byproduct of an API call to the LLM,&#34; Middagh said.</p>
<div class="lb-trans"><p>這包括 &#34;懸而未決的攻擊策略&#34;，其中 LLM 會生成一種規避技術，例如。&#34;但這種規避技術實際上並不符合我們通常看到的現代惡意行為者，或者它將是從未在環境中實際實施的規避技術——它只是作為對 LLM 的 API 調用的副產品生成的，&#34; Middagh 説。</p>
</div><p>In one such incident, Unit 42 documented a prompt sent to OpenAI's GPT-3.5 Turbo using the standard API asking the model to &#34;generate a simple evasion technique for a data extraction tool, and return only the technique name, max three words, that would help avoid detection,&#34; she said. The prompt included these examples: &#34;random delay, process spoofing, memory obfuscation.&#34;</p>
<div class="lb-trans"><p>在一次這樣的事件中，Unit 42 記錄了發送給 OpenAI 的 GPT-3.5 Turbo 的提示，使用標準 API 請求模型 &#34;生成一個簡單的規避技術，用於數據提取工具，並僅返回技術名稱，最多三個單詞，以幫助避免檢測，&#34;她説。該提示包括這些示例：&#34;隨機延遲、進程欺騙、內存混淆。&#34;</p>
</div><blockquote>
<p>We're seeing instances of hallucinations where the LLM will call it 'readme.txtt.' That's a mistake that a threat actor would never make – that's like Ransomware 101</p>
</blockquote>
<div class="lb-trans"><blockquote>
<p>我們看到 LLM 會稱其為 'readme.txtt' 的幻覺實例。這是威脅行為者絕對不會犯的錯誤——這就像是勒索軟件 101。</p>
</blockquote>
</div><p>As instructed, the LLM returned a technique name, but the LLM only logged on to the victim's desktop – it didn't implement the evasion technique. &#34;It just appeared for show and purely for logging,&#34; Middagh said. &#34;There would be a way to potentially make this work, but it was never implemented appropriately in the environment.&#34;</p>
<div class="lb-trans"><p>按照指示，LLM 返回了一個技術名稱，但 LLM 僅登錄到受害者的桌面——並沒有實施規避技術。&#34;它只是為了展示和純粹的記錄而出現，&#34;Middagh 説。&#34;可能有辦法讓它工作，但在環境中從未適當地實施。&#34;</p>
</div><p>While she can't know for sure why an attacker would stage security theater rather than a real attack, &#34;if I had to guess, I think it's just an output,&#34; Middagh said. &#34;The LLM is going to generate a voluminous amount of code, the attacker is rushing, they're not validating everything that's in the code output, and there are errors.&#34;</p>
<div class="lb-trans"><p>雖然她無法確切知道攻擊者為何選擇進行安全表演而非真實攻擊，但 “如果我必須猜測，我認為這只是一個輸出，” Middagh 説。“大型語言模型將生成大量代碼，攻擊者在匆忙中，沒有驗證代碼輸出中的所有內容，因此會出現錯誤。”</p>
</div><p>In other words, AI tools produce the same mistakes when asked to generate malicious code as they do when asked to write legitimate code.</p>
<div class="lb-trans"><p>換句話説，當被要求生成惡意代碼時，AI 工具會產生與被要求編寫合法代碼時相同的錯誤。</p>
</div><p>Hallucinations remain a common AI pitfall, and even ransomware developers feel this pain.</p>
<div class="lb-trans"><p>幻覺仍然是 AI 的一個常見陷阱，即使是勒索軟件開發者也感受到這種痛苦。</p>
</div><p>After infecting a victim's machine, the extortionists leave a readme file on the desktop, usually named &#34;readme.txt,&#34; and it contains the ransom note and monetary demand.</p>
<div class="lb-trans"><p>在感染受害者的機器後，勒索者會在桌面上留下一個名為 “readme.txt” 的自述文件，其中包含贖金通知和金錢要求。</p>
</div><p>&#34;We're seeing instances of hallucinations where the LLM will call it 'readme.txtt,'&#34; Middagh said. &#34;That's a mistake that a threat actor would never make – that's like Ransomware 101. But what we're seeing now is they're moving so fast, and they're not doing much in the way of validation or checking, that these things just happen. They're throwing the kitchen sink at everything.&#34;</p>
<div class="lb-trans"><p>“我們看到幻覺的實例，其中大型語言模型會稱其為 ‘readme.txtt’，” Middagh 説。“這是威脅行為者絕對不會犯的錯誤——這就像是勒索軟件的基礎知識。但我們現在看到的是，他們行動得太快，沒有進行太多驗證或檢查，這些事情就發生了。他們對所有事情都採取了全力以赴的態度。”</p>
</div><p>Attackers aren't the only ones making mistakes using AI models that lack a human's situational awareness and are built to prioritize functionality over security.</p>
<div class="lb-trans"><p>攻擊者並不是唯一在使用缺乏人類情境意識且優先考慮功能而非安全的 AI 模型時犯錯誤的人。</p>
</div><p>Most organizations that allow their employees to use vibe-coding tools also haven't performed any formal risk assessment on these tools, nor do they have security controls in place to monitor inputs and outputs.</p>
<div class="lb-trans"><p>大多數允許員工使用氛圍編碼工具的組織也沒有對這些工具進行任何正式的風險評估，也沒有實施監控輸入和輸出的安全控制措施。</p>
</div><p>&#34;If you are an enterprise, there's a couple of ways you can control and address the risks of vibe coding,&#34; Middagh said. Step one involves applying principles of least privilege and least functionality to AI tools much as you would to human users, granting only the minimum roles, responsibilities, and privileges needed to do their job.</p>
<div class="lb-trans"><p>“如果你是一家企業，有幾種方法可以控制和應對氛圍編碼的風險，” Middagh 説。第一步涉及將最小權限和最小功能原則應用於 AI 工具，就像對待人類用户一樣，僅授予完成工作所需的最低角色、責任和權限。</p>
</div><p>&#34;Everybody is so excited about using AI, and having their developers be speedier, that this whole least privilege and least functionality model has gone completely by the wayside,&#34; Middagh said.</p>
<div class="lb-trans"><p>“每個人都對使用 AI 感到非常興奮，希望他們的開發者能更快，因此整個最小權限和最小功能模型完全被忽視了，” Middagh 説。</p>
</div><p>Next, she suggests limiting usage to one conversational LLM that employees can use, and blocking every other AI coding tool at the firewall. And for orgs that do decide they need a vibe-coding tool in their environment, &#34;the way forward would be the SHIELD framework,&#34; according to Middagh. ®</p>
<div class="lb-trans"><p>接下來，她建議將使用限制為員工可以使用的一個對話型大型語言模型，並在防火牆上阻止所有其他 AI 編碼工具。對於那些決定在其環境中需要氛圍編碼工具的組織，“前進的方式將是 SHIELD 框架，” Middagh 説。®</p>
</div>

是的，犯罪分子正在利用 AI 來編碼惡意軟件的特徵