TechSummary 2025-09-09

2025年9月10日 · 閱讀時間約 11 分鐘

AI Assistant

🔗 如何使用 GitHub 與 JFrog 整合實現從提交到生產的安全可追溯建構

Source: https://github.blog/enterprise-software/devsecops/how-to-use-the-github-and-jfrog-integration-for-secure-traceable-builds-from-commit-to-production/

GitHub 與 JFrog 推出新的整合，旨在建立安全、可追溯的軟體供應鏈，將原始程式碼與經認證的二進位檔案連結。
此整合解決了開發者面臨的痛點，例如在建構離開 GitHub 後失去可追溯性、手動協調多個安全掃描結果，以及 CI/CD 流程缺乏無縫整合。
核心功能包括：統一安全掃描（基於 JFrog 的生產情境優先處理 Dependabot 警報）、基於策略發佈和推廣 Artifacts、自動將 GitHub 生成的所有證明（Provenance、SBOM 等）匯入 JFrog Evidence 並與建構 Artifact 關聯。
工作流程如下：推送程式碼至 GitHub -> 使用 GitHub Actions 進行建構與測試 -> 連結提交、建構與 Artifacts 以實現完整生命週期可見性 -> 自動將 Artifacts 發佈到 Artifactory -> 使用 GitHub Advanced Security 掃描程式碼，並使用 JFrog Xray 掃描 Artifacts。
設定步驟：在 JFrog Artifactory 中啟用 GitHub 整合，開啟「Enable GitHub Actions」並驗證 GitHub 組織。

GitHub Actions 範例用於生成證明並推送到 Artifactory，其中使用 jfrog/jfrog-setup-cli 和 actions/attest-build-provenance 等 actions。

name: Build, Test & Attest

on:
  push:
    branches:
      - main

env:
  OIDC_PROVIDER_NAME: [...]
  JF_URL: ${{ vars.JF_URL }}
  JF_REGISTRY: ${{ vars.JF_REGISTRY }}
  JF_DOCKER_REPO: [...]
  IMAGE_NAME: [...]
  BUILD_NAME: [...]

jobs:
  build-test-deploy:
    runs-on: ubuntu-latest
    permissions:
        contents: read
        packages: write
        attestations: write  # Required for attestation
        id-token: write      # Added for OIDC token access

    steps:
    - name: Checkout code
      uses: actions/checkout@v5

    - name: Install JFrog CLI
      id: setup-jfrog-cli
      uses: jfrog/setup-jfrog-cli@v4.5.13
      env:
        JF_URL: ${{ env.JF_URL }}
      with:
        version: 2.78.8
        oidc-provider-name: ${{ env.OIDC_PROVIDER_NAME }}

    - name: Docker login
      uses: docker/login-action@v3
      with:
        registry: ${{ env.JF_REGISTRY }}
        username: ${{ steps.setup-jfrog-cli.outputs.oidc-user }}
        password: ${{ steps.setup-jfrog-cli.outputs.oidc-token }}

    - name: Set up Docker Buildx
      uses: docker/setup-buildx-action@v3

    - name: Build and push Docker image
      id: build-and-push
      uses: docker/build-push-action@v6
      with:
        context: .
        push: true
        tags: ${{ env.JF_REGISTRY }}/${{ env.IMAGE_NAME }}:${{ github.run_number }}
        build-args: ${{ env.BUILD_ARGS }}

    - name: Attest docker image
      uses: actions/attest-build-provenance@v2
      with:
        subject-name: oci://${{ env.JF_REGISTRY }}/${{ env.IMAGE_NAME }}
        subject-digest: ${{ steps.build-and-push.outputs.digest }}

最佳實踐建議使用 OIDC 避免長時間憑證、自動化 Artifactory 中的推廣流程、早期設定安全閘門以阻止未經證明或存在漏洞的建構進入生產，並利用 JFrog Evidence 中的 Provenance 證明實現即時追溯。

✨ MPS 2025.2 發布！

Source: https://blog.jetbrains.com/mps/2025/09/mps-2025-1-is-out-2/

MPS 2025.2 版本著重於全面提升品質與穩定性，並帶來多項顯著升級。
新增功能包括：能夠使用 OS 原生啟動器啟動 MPS，提供更穩健便捷的方式（例如：可將應用程式釘選到任務欄和開始選單）。
「Show Node Info」對話框進行了現代化改進。
改善了在複製貼上參考時處理 resolve-info 的方式，確保其正確更新。
引入了新的 FactoryMethodIcon 概念，允許透過具體的靜態工廠方法宣告來指定圖示。
平台已更新至支援 Java 21（源代碼和目標兼容性），以利用新的語言特性和提升執行時效能。
重要提示： 更新 MPS 合併驅動程式，因為其邏輯已變更並移除了一些舊的持久化 hack。當 MPS 檢測到專案中指定了舊版本時，務必允許其更新。

❄️ 偵測 IntelliJ Platform UI 凍結問題

Source: https://blog.jetbrains.com/platform/2025/09/investigating-intellij-platform-ui-freezes/

本文探討了 JetBrains IDE 中 UI 凍結的常見原因，這些 IDE 基於單一事件分派執行緒（EDT）的 Java AWT 框架構建。
UI 凍結發生在 EDT 無法執行操作時，阻礙了用戶與 IDE 的互動；事件必須在 16 毫秒內處理才能實現 60 FPS 的渲染。
偵測 UI 凍結通常從檢查 AWT-EventQueue-0 執行緒傾印開始。

UI 凍結的常見原因及解決方案：

讀寫鎖引起的凍結： EDT 試圖獲取寫鎖時被阻塞，而後台執行緒（例如高亮顯示）持有讀鎖但沒有頻繁檢查 ProgressManager.checkCanceled。

"AWT-EventQueue-0" prio=0 tid=0x0 nid=0x0 waiting on condition
...
(!) at com.intellij.platform.locking.impl.NestedLocksThreadingSupport$ComputationState.upgradeWritePermit(NestedLocksThreadingSupport.kt:370)

後台寫操作引起的凍結： EDT 無法立即獲取寫意圖鎖，同時後台寫操作（如 VFS 刷新）因活躍的讀操作而掛起。

"AWT-EventQueue-0" #91 [119043] prio=6 os_prio=31 cpu=71985.87ms elapsed=1065.05s tid=0x00000001610c4c00 nid=119043 sleeping [0x0000000398429000]
   java.lang.Thread.State: TIMED_WAITING (sleeping)

執行緒飢餓： Dispatchers.Default 或 Dispatchers.IO 中的所有執行緒都被阻塞，導致協程停留在 Cancelling 狀態。解決方案是將阻塞操作移出 Default 分派器。

"DefaultDispatcher-worker-9@28483" daemon prio=5 tid=0xa0 nid=NA waiting
...
(!) at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.runDefaultDispatcherTask(CoroutineScheduler.kt:882)

服務初始化引起的死鎖： EDT 在服務初始化（寫操作）時被阻塞，而服務初始化又被讀鎖的獲取阻塞。解決方案是將讀操作移出服務初始化，或在讀操作中預加載服務。
```
"AWT-EventQueue-0" #59 [128003] prio=6 os_prio=31 cpu=3011.23ms elapsed=172.40s tid=0x000000012c07ae00 nid=128003 waiting on condition  [0x000000039b0ae000]
   java.lang.Thread.State: TIMED_WAITING (parking)
```
runBlocking 處理： 執行緒阻塞於 runBlocking 表示試圖同步執行協程；應使用平台專用的 runBlockingCancellable，並確保頻繁調用 ProgressManager.checkCanceled()。
```
"JobScheduler FJ pool 6/15" prio=0 tid=0x0 nid=0x0 waiting on condition
...
(!) at com.intellij.openapi.progress.CoroutinesKt.runBlockingCancellable(coroutines.kt:117)
```

結論：大多數 UI 凍結是因插件程式碼與 IntelliJ Platform 之間協作不足造成，通過使用平台的可取消操作原語可顯著提升 IDE 響應性。

📦 使用 ChartMuseum 作為 Helm Repository

Source: https://dzone.com/articles/using-chartmuseum-as-a-helm-repository

ChartMuseum 是一個開源、自託管的 Helm Chart 儲存庫伺服器，用於高效地儲存和管理 Helm Charts。
Helm 是 Kubernetes 的標準套件管理器，而 ChartMuseum 填補了組織內部私有和安全 Helm 儲存庫的需求。
它提供了強大的 API，支援程式化互動，是自動化 CI/CD 管道的關鍵工具。
ChartMuseum 以 Go 語言編寫，可作為獨立二進位檔案、容器或 Kubernetes 部署。

🧠 大規模 RAG：向量資料庫與 Lakehouse 架構之比較

Source: https://dzone.com/articles/tutorial-rag-at-scale-with-vector-databases-vs-lakehouse

檢索增強生成（RAG）正迅速成為企業部署大型語言模型（LLMs）的標準模式。
RAG 透過整合即時、領域特定的資訊來豐富 LLM 提示，從而提供更準確的答案、減少幻覺並提高企業對輸出結果的信任度。
實現在企業規模下構建 RAG 具挑戰性，因為這涉及到嵌入數十億行的數據，而非僅是少量 PDF。
文章探討了在企業級 RAG 應用中，向量資料庫與 Lakehouse 架構之間關鍵的架構選擇問題。

📊 深入理解 SQL Server 表統計：重要性、效能影響與實務範例

Source: https://dzone.com/articles/sql-server-table-statistics-performance

SQL Server 中的表統計（Table Statistics）是儲存關於表中一個或多個欄位資料分佈資訊的中繼資料物件。
這些統計對於查詢最佳化器（Query Optimizer）至關重要，它利用統計資訊來估計查詢條件將返回的行數（即基數估計），這是高效執行計劃的基礎。
過時的統計資訊（未能準確反映資料變化）會導致最佳化器做出錯誤的基數估計，進而產生低效率的執行計劃，消耗更多系統資源並延長執行時間。
定期更新統計資訊（手動執行 UPDATE STATISTICS 或啟用自動更新功能 AUTO_UPDATE_STATISTICS）是維護最佳查詢效能的關鍵，有助於預防效能下降並確保查詢隨著資料演變而高效運行。

🔐 基於區塊鏈的身份驗證：安全身份驗證的未來

Source: https://dzone.com/articles/blockchain-authentication-secure-identity-verification

傳統身份驗證方法（如密碼、集中式資料庫、第三方身份提供者）存在安全漏洞、身份盜竊和資料隱私問題。
基於區塊鏈的身份驗證提供了一種去中心化、防篡改且更安全的替代方案。
區塊鏈技術有望解決傳統方法的痛點，為身份驗證帶來更高的安全性與透明度。

☁️ 如何將 Jenkins 有效整合至 ECS/EKS Cluster

Source: https://dzone.com/articles/use-jenkins-effectively-with-ecseks-cluster

在現代 DevOps 工作流程中，Jenkins 作為 CI/CD 管道的基石，因其靈活性和豐富的插件而不可或缺。
AWS 的 Elastic Container Service (ECS) 和 Elastic Kubernetes Service (EKS) 則是部署與管理容器化應用的強大託管服務。
本文探討了如何將 Jenkins 有效地與 ECS 和 EKS 集群整合，以優化 CI/CD 流程。
透過此整合，可實現建構、測試和部署流程的自動化，提升容器化應用的開發效率和管理彈性。

🛡️ 或許安全：確定性與機率性系統的安全考量

Source: https://dzone.com/articles/security-concerns-deterministic-vs-probabilistic-systems

文章探討了確定性系統（基於相同輸入總是產生相同預期結果）與機率性系統（依賴於最可能正確的答案）之間在安全方面的根本差異。
隨著 AI 驅動應用程式的快速發展和廣泛應用，將 AI 融入工作流程時，需要深入思考這些系統的運作方式及其安全隱憂。
審核工作依賴於有文件證明的事實，而非機率，因此在面對機率性 AI 系統時，需要重新評估其安全確定性。
不當應用 AI 技術，可能導致新的安全風險和危險。

🔑 使用 Keycloak 和 OIDC 保護您的 Spring Boot 應用程式

Source: https://dzone.com/articles/secure-spring-boot-apps-keycloak-oidc

本文深入探討 Spring Security，特別是結合 Keycloak 和 OpenID Connect (OIDC) 來保護 Spring Boot 應用程式。
Spring Security 是 Spring 框架中用於為應用程式添加安全功能的解決方案，涵蓋身份驗證和授權。
文章將透過範例和單元測試，引導讀者學習 Spring Security 的註解和類別，最終目標是建置一個使用 OIDC 和 Keycloak 的應用程式。
建議讀者若不熟悉 OIDC 和 Keycloak 的概念，可先閱讀相關介紹文章。

🤖 您的 AI 是精神病患嗎？

Source: https://dzone.com/articles/is-your-ai-a-psychopath

文章指出在修復 AI 錯誤時面臨「打地鼠」問題，即解決一個問題後可能出現新的、意想不到的行為。
舉例說明，一個旨在友好的客服聊天機器人，在經過巧妙的元提示（meta-prompt）調整後，可能開始「熱心」地編造不存在的產品功能。
這凸顯了由於 AI 系統的內在結構，導致 AI 錯誤的修正過程往往是無休止的，並且一個修補可能引發新的不良副作用。

☁️ 卓越的雲端自動化：用於企業架構的 Terraform、Ansible 和 Nomad

Source: https://dzone.com/articles/cloud-automation-excellence-terraform-ansible-amp

企業雲端架構要求對跨不同計算平台的基礎設施、配置和工作負載管理進行複雜的協調。
手動配置和孤立工具的傳統方法已成為阻礙組織實現雲原生敏捷性的瓶頸。
本文探討了三種互補自動化技術的策略性整合：
- Terraform： 用於基礎設施配置。
- Ansible： 用於配置管理。
- HashiCorp Nomad： 作為輕量級工作負載協調器，管理跨多樣基礎設施環境的應用程式部署、擴展和排程。
這種生態系統方法利用了在各自領域表現卓越的專業工具，同時在 AWS、Azure、Google Cloud、IBM Cloud 和混合環境中保持平台無關的能力。

💡 邁向可解釋 AI（第八部分）：彌合理論與實踐 — SHAP：強大，但我們能信任它嗎？

Source: https://dzone.com/articles/series-toward-explainable-ai-bridging-theory-and-p-7

本系列文章旨在探討 AI 的可解釋性如何建立信任、確保問責制並符合實際需求，從基礎原則到實際應用案例。
這是「邁向可解釋 AI」系列的第八部分，延續了第七部分對 SHAP 在金融決策制定中應用的探討。
本部分將深入探討 SHAP 模型的強大功能，同時也提出關鍵問題：SHAP 儘管功能強大，但其可信度如何？

🔗 如何使用 GitHub 與 JFrog 整合實現從提交到生產的安全可追溯建構​

✨ MPS 2025.2 發布！​

❄️ 偵測 IntelliJ Platform UI 凍結問題​

📦 使用 ChartMuseum 作為 Helm Repository​

🧠 大規模 RAG：向量資料庫與 Lakehouse 架構之比較​

📊 深入理解 SQL Server 表統計：重要性、效能影響與實務範例​

🔐 基於區塊鏈的身份驗證：安全身份驗證的未來​

☁️ 如何將 Jenkins 有效整合至 ECS/EKS Cluster​

🛡️ 或許安全：確定性與機率性系統的安全考量​

🔑 使用 Keycloak 和 OIDC 保護您的 Spring Boot 應用程式​

🤖 您的 AI 是精神病患嗎？​

☁️ 卓越的雲端自動化：用於企業架構的 Terraform、Ansible 和 Nomad​

💡 邁向可解釋 AI（第八部分）：彌合理論與實踐 — SHAP：強大，但我們能信任它嗎？​