5 篇文章 含有標籤「Java」

🔗 大規模保障供應鏈安全：從 71 個重要開源專案做起​

Source: https://github.blog/open-source/maintainers/securing-the-supply-chain-at-scale-starting-with-71-important-open-source-projects/

• Log4j 零日漏洞事件後，凸顯了開源庫安全性對整個軟體供應鏈的巨大影響，促使 GitHub 於 2024 年 11 月啟動「GitHub 安全開源基金」（GitHub Secure Open Source Fund）。
• 該基金為維護者提供資金支援，參與為期三週的專案，內容包含安全教育、導師指導、工具、認證及安全意識社群等，旨在提升安全影響力、降低風險，並大規模保護軟體供應鏈。
• 前兩期專案已集合來自 71 個重要開源專案的 125 位維護者，取得了顯著成果：
  • 修復了 1,100 多個由 CodeQL 檢測到的漏洞。
  • 發布了 50 多個新的常見漏洞與暴露（CVE），保護下游依賴項。
  • 阻止了 92 個新機密洩漏，並檢測和解決了 176 個已洩漏的機密。
  • 80% 的專案啟用了三個或更多基於 GitHub 的安全功能，63% 的專案表示對 AI 和 MCP 安全有更好理解。
  • 維護者利用 GitHub Copilot 進行漏洞掃描、安全審計、定義和實施模糊測試策略等。
• 專案涵蓋了 AI/ML 框架（如 Ollama, AutoGPT）、前端/全端框架（如 Next.js, shadcn/ui）、Web 伺服器/網路/閘道（如 Node.js）、DevOps/建置工具（如 Turborepo）、安全框架/身份/合規工具（如 Log4j）、以及開發者工具/CLI 助手（如 Charset-Normalizer, nvm, JUnit）等多個關鍵領域。
• 該計劃的成功關鍵在於：資金支援結合時間限制的專注訓練、互動式編碼經驗以及建立一個以安全為重點的社群，促進了維護者之間的快速交流與協作。

加速 Docker 強化映像的 FedRAMP 合規性 🚀​

Source: https://www.docker.com/blog/fedramp-compliance-with-hardened-images/

• FedRAMP 合規挑戰： 聯邦風險與授權管理計畫 (FedRAMP) 合規成本高昂（45 萬至 200 萬美元以上），且需耗時 12 至 18 個月，這期間競爭對手可能已搶佔政府合約。企業需面對 NIST SP 800-53 中超過 400 項嚴格的安全控制要求。
• Docker 強化映像 (DHI) 解決方案： Docker 硬化映像提供自動化、可稽核的安全解決方案，旨在加速 FedRAMP 合規流程並降低維護成本。DHI 是一系列精簡的映像，持續更新以確保幾乎沒有已知的 CVE。
• FIPS 140 合規性： DHI 支援 FIPS 140 驗證的密碼學模組，預配置並經過測試，可確保正確功能。每個 FIPS 合規映像都附有簽名的證明，列出使用的 FIPS 驗證軟體及其 CMVP 認證和測試結果連結，支援 OpenSSL、Bouncy Castle 和 Go 等主要開源密碼學模組。
• STIG 強化映像： Docker 根據國防信息系統局 (DISA) 發布的通用作業系統 (GPOS) SRG，創建了客製化的容器 STIG。STIG 強化映像在安全建構過程中會使用 OpenSCAP 進行掃描，結果會作為簽名證明提供，其中包含易於查看的 STIG 合規分數，並支援輸出為 HTML 和 XCCDF 格式，便於稽核。
• 持續合規性：
  • 漏洞減少： DHI 起始攻擊面減少高達 95%（按包數量計算），持續更新以確保幾乎沒有已知 CVE，並掃描病毒和機密。
  • 漏洞檢測與修復： Docker 持續監控 CVE 來源，DHI 對嚴重/高風險漏洞的修復 SLA 為 7 天，中/低風險為 30 天，幫助滿足 FedRAMP 修復時限。提供 VEX (Vulnerability Exploitability eXchange) 證明來過濾不適用漏洞。
  • 供應鏈透明度： DHI 使用 SLSA Build Level 3 安全建構管道，確保建構可驗證性與防篡改。提供簽名證明和多種 SBOM 格式。
  • 稽核證據： DHI 證明符合 in-toto 證明標準，作為 provenance、資產管理、漏洞掃描及 FIPS 合規性的安全證據。

Rust 與 Java：為您的專案選擇正確的工具 💻​

Source: https://blog.jetbrains.com/rust/2025/08/01/rust-vs-java/

• 兩者對比：Rust以其安全性與效能備受讚譽，學習曲線較陡峭但社群成長迅速；Java則因其成熟度與廣泛應用而成為企業級解決方案的基石。Rust的用戶群在2024年達到約227萬開發者，而Java因其成熟且穩健的生態系仍吸引數千萬開發者。
• Rust的演進與核心理念：起源於2006年Mozilla的專案，於2015年發布1.0穩定版。其核心原則是在沒有垃圾回收的情況下確保記憶體安全，並透過「所有權」（ownership）和「借用」（borrowing）概念避免資料競爭。它杜絕了空指針解引用、懸空指針或緩衝區溢位等常見錯誤。
• Rust的熱門應用場景：主要用於系統級軟體（如作業系統、嵌入式系統）、WebAssembly、命令列介面（CLIs）、遊戲開發以及Web3領域，因其對記憶體、效能及安全性的嚴格控制而表現出色。
• Java的歷史與核心理念：可追溯到1991年，於1995年發布。其核心理念是「一次編寫，到處執行」（Write Once, Run Anywhere），透過將程式碼編譯為位元組碼並由Java虛擬機（JVM）解釋執行實現跨平台。Java也嚴格遵循物件導向程式設計（OOP）和DRY（Don’t Repeat Yourself）原則。
• Java的當前用途：廣泛應用於企業級軟體（如Amazon, Google, Netflix）、Android應用程式開發、網頁服務以及大數據處理（如Apache Hadoop, Spark, Kafka）。
• 技術差異：
  • 執行時：Java依賴JVM，提供自動垃圾回收和JIT編譯，易於跨平台開發但有記憶體和啟動時間開銷。Rust則提供最小化執行時（zero-cost abstractions），無垃圾回收器，提供精細的記憶體和速度控制。
  • 效能：Rust因無垃圾回收和對資源的精細控制，提供可預測的高速執行。Java依賴JIT編譯器在執行時優化效能，但可能因垃圾回收導致啟動時間較長和不可預測的暫停。
  • 記憶體管理：Java透過垃圾回收自動管理記憶體。Rust則在編譯時透過所有權和借用系統強制執行記憶體安全，無需執行時垃圾回收，提供高效能和可靠性。
  • 學習曲線：Java對初學者較為友好，尤其是熟悉物件導向程式設計的開發者。Rust的學習曲線較陡峭，其所有權概念和借用檢查器可能讓新手感到挫折，但提供了穩定高效的程式碼。
• 工具與生態系差異：
  • IDEs：Java有IntelliJ IDEA、Eclipse、NetBeans等成熟IDE。Rust在IDE支援上進步顯著，有RustRover，IntelliJ IDEA也透過插件支援Rust。
  • 建構系統與套件管理器：Rust擁有統一的工具鏈Cargo，集建構系統、套件管理器和依賴管理器於一身，使用簡單。Java則有多種建構工具，如Maven和Gradle，功能強大但配置較為複雜。
  • 除錯與分析工具：Java擁有數十年發展的成熟除錯和分析工具。Rust除錯依賴GDB或LLDB，但生態系仍在演進。
  • 開發者體驗：Java提供成熟的企業級開發體驗。Rust的體驗更現代、簡化且社群化，尤其適合注重安全性、效率和簡潔工具流程的開發者。
• 社群與採用差異：
  • 社群規模與活躍度：Java擁有龐大且成熟的社群。Rust的社群雖較新，但活躍且快速成長。
  • 函式庫與框架：Java擁有龐大的函式庫與框架生態系，如Spring、Jakarta EE。Rust的函式庫生態系仍在擴展，在系統程式設計、嵌入式開發、遊戲引擎等領域表現出色。
  • 行業採用與職缺趨勢：Java在企業軟體、Android和後端開發領域仍有高需求。Rust的職缺市場雖小但快速成長，被Mozilla、Dropbox、Amazon等公司用於效能或安全關鍵應用。
• 共同點：兩者都旨在防止常見的記憶體相關錯誤；提供強大的並行支援（Java使用傳統線程和java.util.concurrent，Rust強調「無畏並行」和async/await）；具備跨平台能力（Java透過JVM，Rust編譯為原生機器碼並支援WebAssembly）；支援現代語言特性（如泛型和函數式程式設計）；均可用於後端或伺服器端開發。
• 選擇建議：Rust適用於需要低層次控制、極致效能和記憶體安全的場景（如作業系統、設備驅動、高效能運算、WebAssembly）。Java則適用於大型企業應用，重視穩定性、可維護性和成熟生態系（如Android、網路服務、大數據處理）。
• 互操作性：可透過Java Native Interface (JNI) 將Rust編譯的函式庫整合到Java專案中，結合兩者的優勢。

⚙️ Upcoming Changes to JetBrains .NET Tools​

Source: https://blog.jetbrains.com/dotnet/2025/07/25/upcoming-changes-to-dotnet-tools/

• JetBrains 將依據用戶回饋和使用數據，對其 .NET 工具進行一系列精簡與調整，旨在提升工具效能並聚焦核心功能。
• 2025.2 版本更新重點：
  • dotCover 精簡化： 獨立的 dotCover 工具將被精簡以提升性能並降低複雜度。命令列運行器已現代化，指令整合至統一的 dotcover cover 介面，配置檔從 XML 轉換為簡潔的純文字參數檔。
  • 移除部分不常用過濾選項（方法/類別過濾器、檔案路徑過濾器、原始碼註解過濾器），並終止對舊版應用程式類型（如 IIS Express, WCF, WinRT, 外部 .NET 程序）的支援。
  • Rider 中 Mono 和 Unity 專案的程式碼覆蓋率分析終止： Rider 2025.2 起將不再提供 Mono 和 Unity 專案的覆蓋率分析，因使用率低且增加了技術債。待 Unity 遷移至 CoreCLR（預計 Unity 7 LTS 後）將恢復 Unity 專案的覆蓋率分析。
  • Visual Studio 的 TeamCity 擴充功能終止： 為了簡化工具鏈並專注於更具影響力的開發體驗，此擴充功能將被停用。
• 2025.3 版本更新重點：
  • Rider 中的動態程式分析 (DPA) 功能整合： DPA 將不再作為獨立工具，其分析能力將進一步整合到 Monitoring 工具中，並作為 dotUltimate 許可證的一部分提供（與 dotTrace 和 dotMemory 分析器相同）。
• 這些變更旨在釋放開發資源，以持續改進工具的性能、穩定性和核心功能。

用 Java 和 Spring AI 輕鬆建立 Generative AI 應用 🛠️🤖​

來源： Docker官方博客

這篇文章介紹如何使用 Java 和 Spring AI，不需學習 Python，便能快速構建本地的 GenAI 應用。重點在於整合 Docker Model Runner、Testcontainers 進行本地模型管理與測試，並利用 Grafana 進行觀測，提升開發與運維的效率。