在現代軟體開發環境中哪些日益增長的網路安全風險讓 CISO 忙碌？
開發人員和安全團隊面臨越來越多的威脅，從複雜的開源和供應商控制的供應鏈攻擊到 AI 生成的程式碼引入的漏洞，例如提示注入和 GitHub Copilot 的糟糕程式碼安全性。現代應用程式通常嚴重依賴開源元件（例如在 npm、PyPI 或 RubyGems 上找到的元件）和容器化部署，其複雜性增加了挑戰。
考慮到這些風險的規模和複雜性，自動化漏洞管理變得至關重要。手動網路安全流程根本無法跟上潛在漏洞和軟體開發的數量和速度。自動化不僅可以加快安全問題的識別和修復速度，還可以確保安全團隊定期遵循的這些流程在軟體開發生命週期的所有階段一致地應用。
讓我們進一步分解…備受矚目的供應鏈攻擊的另一個例子是對 Codecov 的攻擊，攻擊者透過利用流行程式碼覆蓋工具中的漏洞來存取敏感資料。開發人員的日常工作包括管理與開源依賴相關的風險。開源依賴項可能會為您的程式碼庫帶來直接和傳遞的漏洞。直接漏洞存在於您明確包含的庫中，而傳遞漏洞則存在於這些庫的依賴項中。手動管理這些風險是一項艱鉅的任務，因此自動化成為強大安全策略的關鍵組成部分。
借助 GenAI，GitHub Copilot 或 ChatGPT 等 AI 程式碼助理會引入真實的潛在漏洞。 GenAI 可能會無意中引入不安全的編碼實踐或無法識別特定於上下文的安全要求。例如，AI 模型可能會產生容易受到 SQL 注入或跨站點腳本 (XSS) 攻擊的程式碼。因此，監控和保護人工智慧產生的程式碼對於維護應用程式安全至關重要。
安全團隊也無法逃脫應對新容器漏洞的複雜性。新容器漏洞的快速出現可能令人難以承受。每個新漏洞都需要及時識別和修復，以防止潛在的漏洞。這種複雜性需要具有安全專業知識的自動化解決方案來有效管理容器安全。
容器漏洞可能會對應用程式的整體安全性產生重大影響。單一易受攻擊的容器映像可能會危及整個應用程式堆疊。 Snyk Container 等工具可以自動識別和修復容器映像中的漏洞。 Snyk Container 可以建議新的基礎鏡像標籤，以最大限度地減少漏洞數量並自動執行 Pull 請求來更新您的程式碼儲存庫。
我們如何緩解所有這些 AppSec 網路安全威脅？
為了減輕與 AI 產生程式碼相關的風險，請考慮使用 Snyk Code 等工具。這種快速的 SAST 工具由 Snyk DeepCode AI 提供支持，可以透過插件直接整合到開發人員的 IDE 中。它使用特定於安全的資料訓練來識別易受攻擊和不安全的程式碼，確保在開發早期發現並解決問題。
Snyk DeepCode AI 入門非常簡單。該插件支援流行的 IDE，例如 Visual Studio Code、IntelliJ IDEA、VS Code 和 PyCharm。
安裝後，側邊欄上的 Snyk 標誌將顯示在您的開源依賴項、您自己的程式碼（或 GenAI 產生的程式碼）以及 IaC 問題中發現的漏洞和安全性問題。
讓我們來看一個緩解 GenAI 引入的漏洞的範例。我在此專案中使用 GitHub Copilot 自動完成程式碼，該程式碼會建立 Express POST 端點路由來查詢 OpenAI API，然後使用 res.send() 將回應傳送到瀏覽器。
但是，如果此有效負載中的回應直接在瀏覽器中呈現怎麼辦？如果使用預設的 text/html 內容類型標頭發送此請求，則跨站點腳本漏洞將影響正在運行的應用程式。對此我們能做什麼？
正如您在第 31 行上方的註釋中看到的，Snyk 建議修復此安全性問題。我點擊它，幾秒鐘之內，Snyk DeepCode AI 擴充功能提出了一種緩解措施，將 res.send() 替換為 res.json，如下所示：
res.json(response.choices[0].message.content);
透過此更改，Express 應用程式強制回應中的內容類型為 application/json，它是通用文本，並且可以允許諸如alert() 之類的文本。
透過在 IDE 中利用 Snyk，開發人員可以使用底層 Snyk DeepCode AI 引擎主動識別和緩解漏洞，確保他們的程式碼從一開始就是安全的。這種主動的應用程式安全方法在當今的環境中至關重要，因為與開源供應鏈和 GenAI 生成的程式碼相關的風險始終存在。
Snyk Open Source 是一款功能強大的工具，旨在幫助開發人員和安全團隊管理與開源依賴相關的風險。隨著對開源程式庫的依賴日益增加，對強大且自動化的依賴關係管理的需求變得前所未有的迫切。 Snyk Open Source 提供全面的漏洞掃描和修復功能，確保您的專案保持安全和合規。
在我之前的 Node.js 應用程式中，我還使用了 SQLite 依賴項，Snyk 提醒我有安全問題，如下所示：
This vulnerability information is helpful to understand which transitive dependency is introducing the security risk and how to mitigate it, if at all possible. In this case, the transitive dependency inflight is detected to have a medium vulnerability.
Snyk detects that my lockfile and dependency is potentially out of date and so it can’t find a remediation path. However, let’s see the automation in practice when we import the GitHub code repository to Snyk. Doing so, shows the following information on the Snyk application:
From this point on, Snyk will automatically open new Pull Requests to suggest dependency upgrades when security vulnerabilities are detected in my package manifest.
Managing dependencies is not just about the libraries you directly include in your project. Transitive dependencies—those pulled in by your direct dependencies—can also introduce vulnerabilities. Snyk excels at identifying and remediating vulnerabilities in both direct and transitive dependencies.
Consider the following scenario:
{
"dependencies": {
"express": "^4.17.1",
"lodash": "^4.17.20"
}
}
In this example, express and lodash are direct dependencies. However, express might have its own set of dependencies, which in turn might have their own dependencies. Snyk will traverse this entire dependency tree, identifying and addressing vulnerabilities at every level.
When it comes to managing container vulnerabilities, Snyk Container helps remove the burden of keeping base image tags up-to-date with security patches.
Snyk Container is a comprehensive solution designed to help developers and security teams manage container vulnerabilities effectively. Containerized application workloads is prevalent at the Enterprise and as is the need to secure these environments. Snyk Container integrates seamlessly into your CI/CD pipeline, providing continuous monitoring and proactive remediation of vulnerabilities in your container images.
One of the standout features of Snyk Container is its ability to automate the creation of Pull Requests to address vulnerabilities in your container images. This automation is a game-changer for both developers and security teams, as it significantly reduces the manual effort required to keep container images secure.
Here's an example of how Snyk Container might automate a PR to update a vulnerable package in a Dockerfile:
FROM node:14.1.0 RUN npm install express COPY . /app CMD ["node", "/app/index.js"]
When Snyk Container detects a vulnerability, it automatically generates a PR with the necessary changes to mitigate the issue. This could include updating a vulnerable package or applying a security patch. By automating this process, Snyk Container ensures that vulnerabilities are addressed promptly, reducing the window of exposure.
By following these recommended base images, you can significantly reduce the number of vulnerabilities in your container images, enhancing the overall security of your applications.
Snyk Container identified multiple vulnerabilities in this base image and automatically generated PRs to update the image and associated dependencies. The team was able to review and merge these PRs quickly, reducing their vulnerability count by over 30% within seconds by merging the Pull Request and ensuring the CI/CD pipeline tests pass with flying colors.
This proactive approach not only improved the security posture of their applications but also freed up valuable time for developers to focus on building new features rather than managing vulnerabilities.
以上是為開發人員和安全團隊提供主動的 AppSec 持續漏洞管理的詳細內容。更多資訊請關注PHP中文網其他相關文章！
