證指南：使用 cosign 校驗(yàn) SLSA 構(gòu)建證明與 SBOM 物料清單)
文檔教程云原生【免費(fèi)下載鏈接】docsUser documentation for Knative components.項(xiàng)目地址https://gitcode.com/gh_mirrors/docs1/docs點(diǎn)擊查看免費(fèi)下載本文面向 Knative 集群管理員與安全運(yùn)維人員講解如何利用 cosign 校驗(yàn) Knative 官方發(fā)布的容器鏡像既能驗(yàn)證構(gòu)建過程的 SLSASupply-chain Levels for Software Artifacts軟件工件供應(yīng)鏈級別證明也能提取每個(gè)鏡像的 SBOM軟件物料清單從而在安裝 Knative Serving、Eventing 等組件前確認(rèn)鏡像的真實(shí)性與來源可信度。讀完本文你將掌握兩條核心命令鏈——cosign verify-attestation驗(yàn)證構(gòu)建聲明、cosign download sbom拉取架構(gòu)級物料清單并能將同樣的校驗(yàn)邏輯接入 sigstore policy controller 等準(zhǔn)入控制器形成自動(dòng)化供應(yīng)鏈安全防線。背景Knative 發(fā)布物中的安全元數(shù)據(jù)Knative 為每個(gè)隨版本發(fā)布的容器鏡像同時(shí)公開兩類供應(yīng)鏈安全元數(shù)據(jù)SLSA 構(gòu)建證明SLSA provenance采用 in-toto 規(guī)范描述的 attestation 文檔記錄鏡像的構(gòu)建過程、構(gòu)建環(huán)境與來源信息用于回答這個(gè)鏡像是不是 Knative 官方構(gòu)建的、以及它是如何構(gòu)建的。SBOM軟件物料清單列出鏡像內(nèi)部包含的每一個(gè)軟件組件及其版本用于回答這個(gè)鏡像里到底裝了哪些軟件。這兩類數(shù)據(jù)在 Knative 構(gòu)建流程中自動(dòng)生成并作為 attestation 存儲(chǔ)在容器鏡像倉庫中任何擁有 cosign 工具的人都可以獨(dú)立讀取和驗(yàn)證不依賴對發(fā)布頁面的信任。其背后的供應(yīng)鏈安全定位在 威脅模型文檔 中有明確說明對容器鏡像與命令行二進(jìn)制進(jìn)行簽名并附帶 SBOM 與 SLSA 證明是為了降低供應(yīng)鏈攻擊風(fēng)險(xiǎn)讓管理員與用戶能夠確認(rèn)自己拿到的工件與 Knative 官方構(gòu)建的一致并驗(yàn)證 SLSA 關(guān)于臨時(shí)構(gòu)建與可復(fù)現(xiàn)構(gòu)建的安全保證。Knative 的knCLI 客戶端二進(jìn)制同樣采用 cosign 簽名驗(yàn)證方式記錄在 驗(yàn)證客戶端二進(jìn)制文檔其使用的簽名身份與鏡像驗(yàn)證完全一致可作為交叉印證。前置條件驗(yàn)證鏡像前需要準(zhǔn)備兩樣?xùn)|西cosign 工具cosign 是 sigstore 項(xiàng)目提供的容器簽名/驗(yàn)證 CLI負(fù)責(zé)從容器倉庫拉取并解析 attestation。安裝方式請參考 sigstore 官方文檔cosign install或各發(fā)行版包管理器。目標(biāo)鏡像引用$IMAGEKnative 發(fā)布清單 YAML 中列出的鏡像地址例如gcr.io/knative-releases/knative.dev/serving/cmd/controller這類帶 tag 的引用。Knative 的簽名模式與驗(yàn)證身份KEYLESS無密鑰簽名模式Knative 的鏡像與二進(jìn)制均采用KEYLESS 簽名模式keyless signing不預(yù)先管理長期私鑰而是在構(gòu)建/簽名時(shí)由 CI 流水線向 sigstore 的 Fulcio 證書機(jī)構(gòu)申請短期證書完成簽名證書與簽名一并寫入倉庫。驗(yàn)證方無需持有公鑰只需校驗(yàn)Subject簽名身份signerknative-releases.iam.gserviceaccount.comIssuer證書簽發(fā)者h(yuǎn)ttps://accounts.google.com從發(fā)布腳本印證簽名身份簽名身份在倉庫的發(fā)布腳本 vendor/knative.dev/hack/release.sh 中被硬編碼為兩個(gè)常量RELEASE_SIGNING_IDENTITYsignerknative-releases.iam.gserviceaccount.com——正式版本簽名身份即本文所有命令中使用的 SubjectNIGHTLY_SIGNING_IDENTITYsignerknative-nightly.iam.gserviceaccount.com——每晚構(gòu)建nightly的簽名身份驗(yàn)證 nightly 鏡像時(shí)應(yīng)改用該郵箱。在sign_release()函數(shù)中release.shCI 通過gcloud auth print-identity-token --audiencessigstore模擬上述服務(wù)賬號取得短期身份令牌然后執(zhí)行cosign sign簽名鏡像與cosign attest附加 SLSA 證明。這意味著凡是你驗(yàn)證通過的鏡像其簽名鏈最終都指向 Knative 官方維護(hù)的 Google 服務(wù)賬號而不是某個(gè)個(gè)人密鑰。驗(yàn)證 SLSA 構(gòu)建證明signed provenance單條驗(yàn)證命令針對發(fā)布清單中給定的任一鏡像用以下命令驗(yàn)證其構(gòu)建 attestationcosign verify-attestation \ --certificate-oidc-issuer https://accounts.google.com \ --certificate-identity signerknative-releases.iam.gserviceaccount.com \ --type slsaprovenance02 \ $IMAGE參數(shù)說明參數(shù)含義--certificate-oidc-issuer校驗(yàn)簽名證書的 OIDC 簽發(fā)者Knative 固定為https://accounts.google.com--certificate-identity校驗(yàn)簽名主體SubjectKnative 正式版固定為signerknative-releases.iam.gserviceaccount.com--typeattestation 的 predicate 類型Knative 生成的為 SLSA v0.2 規(guī)范即slsaprovenance02$IMAGE要驗(yàn)證的鏡像引用當(dāng)證書鏈有效、身份與 issuer 匹配、且 attestation 與鏡像摘要digest一致時(shí)命令返回成功否則會(huì)報(bào)出證書不匹配或無法提取證明等錯(cuò)誤。注意命令會(huì)輸出全部 attestation你需要逐一確認(rèn)每一條都滿足預(yù)期身份條件因?yàn)橥荤R像可能附帶多個(gè)簽名。用 jq 解碼 in-toto 文檔attestation 中的 in-toto 文檔以 Base64 編碼存放在.payload字段中配合jq可以解碼出可讀的 JSON 構(gòu)建聲明cosign verify-attestation \ --certificate-oidc-issuer https://accounts.google.com \ --certificate-identity signerknative-releases.iam.gserviceaccount.com \ --type slsaprovenance02 \ $IMAGE | jq -r .payload | base64 --decode | jq這一連串管道完成了驗(yàn)證簽名 → 提取 payload → Base64 解碼 → 格式化輸出四步。解碼后你將看到 in-toto 聲明中的builder、buildType、recipe、materials等字段它們描述了鏡像由哪個(gè)構(gòu)建系統(tǒng)、在什么環(huán)境下、引用了哪些上游源碼與依賴構(gòu)建而成——這正是 SLSA 證明的核心信息可用于審計(jì)構(gòu)建可復(fù)現(xiàn)性。驗(yàn)證的工程化落地接入準(zhǔn)入控制器驗(yàn)證命令本身可用于手工審計(jì)但更常見的生產(chǎn)場景是自動(dòng)強(qiáng)制校驗(yàn)將 Knative 公開的這些 attestation 信息配置進(jìn)sigstore policy controller或其他準(zhǔn)入控制器admission controller使得集群在拉取/創(chuàng)建 Pod 時(shí)自動(dòng)檢查鏡像簽名與證明不滿足策略的鏡像直接拒絕部署。這與文檔 security-prereqs-images 片段 描述的用法一致——當(dāng)集群被配置為在 Pod 執(zhí)行期間校驗(yàn)鏡像簽名時(shí)你就需要本頁的鏡像驗(yàn)證信息來配置策略。若需在安裝前先人工核對鏡像來源也可參考 security-prereqs-images 片段 的提示在安裝 Knative 前可選地對鏡像執(zhí)行驗(yàn)證再從發(fā)布清單進(jìn)行部署。下載與解析 Knative SBOMSBOM 的生成方式Knative 的每個(gè)容器鏡像都會(huì)發(fā)布與之對應(yīng)的 SBOM且這些 SBOM 是在編譯期由ko工具 生成并寫入倉庫的。因此 SBOM 精確反映了該次構(gòu)建實(shí)際鏈接進(jìn)來的軟件組件而不是一份靜態(tài)的預(yù)期清單。下載命令使用 cosign 的download sbom子命令即可拉取cosign download sbom $IMAGE多架構(gòu)鏡像的架構(gòu)級提取Knative 發(fā)布清單 YAML 中的鏡像引用是多架構(gòu)multi-arch鏡像manifest list。由于不同架構(gòu)在構(gòu)建時(shí)可能鏈接不同的底層庫SBOM 內(nèi)容會(huì)因架構(gòu)而異要精確獲取某個(gè)架構(gòu)例如linux/amd64的軟件組件必須針對架構(gòu)專屬鏡像執(zhí)行下載cosign download sbom $IMAGE-linux-amd64 # 示例帶架構(gòu)后綴的鏡像引用實(shí)際操作中架構(gòu)專屬鏡像的引用形式取決于倉庫的命名約定常見為鏡像 digest 或帶-linux-amd64后綴的 tag你可以先用docker buildx imagetools inspect $IMAGE或crane manifest查看 manifest list 中各個(gè)平臺(tái)對應(yīng)的 digest再對目標(biāo) digest 執(zhí)行cosign download sbom。拿到 SBOM 后可結(jié)合企業(yè)漏洞掃描如 Trivy、Grype與 CVE 庫比對確認(rèn)鏡像組件版本是否在受影響的范圍內(nèi)。驗(yàn)證完整流程示例端到端將以上環(huán)節(jié)串起來一次完整的鏡像供應(yīng)鏈校驗(yàn)流程為# 1. 驗(yàn)證鏡像的 SLSA 構(gòu)建證明 cosign verify-attestation \ --certificate-oidc-issuer https://accounts.google.com \ --certificate-identity signerknative-releases.iam.gserviceaccount.com \ --type slsaprovenance02 \ $IMAGE # 2. 解碼并審閱構(gòu)建聲明的 payload cosign verify-attestation \ --certificate-oidc-issuer https://accounts.google.com \ --certificate-identity signerknative-releases.iam.gserviceaccount.com \ --type slsaprovenance02 \ $IMAGE | jq -r .payload | base64 --decode | jq # 3. 按需下載對應(yīng)架構(gòu)的 SBOM 進(jìn)行成分審計(jì) cosign download sbom $IMAGE三步分別回答三個(gè)問題鏡像是否由 Knative 官方身份簽名構(gòu)建過程聲明了什么鏡像由哪些軟件組件構(gòu)成三者疊加即構(gòu)成來源可信 構(gòu)建可審計(jì) 成分可盤點(diǎn)的完整鏡像信任鏈。補(bǔ)充資料Knative 安全與漏洞披露總覽安全團(tuán)隊(duì)、漏洞報(bào)告渠道與威脅模型入口Knative 威脅模型SLSA 構(gòu)建與 provenance 緩解的供應(yīng)鏈攻擊場景system code execution驗(yàn)證客戶端二進(jìn)制與鏡像驗(yàn)證同源的 cosign KEYLESS 簽名身份可用于校驗(yàn)kn等 CLI 二進(jìn)制2023 年安全審計(jì)博客記錄 Knative 自建 provenance-generator 生成 SLSA 兼容證明并納入發(fā)布流程的背景。贊分享文檔教程云原生【免費(fèi)下載鏈接】docsUser documentation for Knative components.項(xiàng)目地址https://gitcode.com/gh_mirrors/docs1/docs點(diǎn)擊查看免費(fèi)下載相關(guān)推薦驗(yàn)證 Knative kn CLI 二進(jìn)制使用 cosign 與 SHA256 校驗(yàn)官方發(fā)行物驗(yàn)證 Knative kn CLI 二進(jìn)制使用 cosign 與 SHA256 校驗(yàn)官方發(fā)行物 從 Knative 1.9 版本開始官方使用 cosign文檔教程云原生LinuxKit SBoM 軟件物料清單構(gòu)建期生成、合并與 050_sbom 測試驗(yàn)證全解析LinuxKit SBoM 軟件物料清單構(gòu)建期生成、合并與 050_sbom 測試驗(yàn)證全解析 LinuxKit 將若干 OCI 鏡像組合為最小化、面向容器場景操作系統(tǒng)云原生容器運(yùn)行時(shí)Beekeeper Studio 配置文件位置速查3 平臺(tái)路徑、3 層優(yōu)先級一次講清Beekeeper Studio 配置文件位置速查3 平臺(tái)路徑、3 層優(yōu)先級一次講清 改了配置、反復(fù)重啟Beekeeper Studio 就是沒有反應(yīng)——十桌面應(yīng)用數(shù)據(jù)庫客戶端開發(fā)工具上一篇Hermes Agent 配置全解從 3 條命令到多場景定制下一篇智慧教育平臺(tái)電子課本下載終極指南3步快速獲取PDF教材創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考 Knative 鏡像驗(yàn)證指南：使用 cosign 校驗(yàn) SLSA 構(gòu)建證明與 SBOM 物料清單
文檔教程云原生【免費(fèi)下載鏈接】docsUser documentation for Knative components.項(xiàng)目地址https://gitcode.com/gh_mirrors/docs1/docs點(diǎn)擊查看免費(fèi)下載本文面向 Knative 集群管理員與安全運(yùn)維人員講解如何利用 cosign 校驗(yàn) Knative 官方發(fā)布的容器鏡像既能驗(yàn)證構(gòu)建過程的 SLSASupply-chain Levels for Software Artifacts軟件工件供應(yīng)鏈級別證明也能提取每個(gè)鏡像的 SBOM軟件物料清單從而在安裝 Knative Serving、Eventing 等組件前確認(rèn)鏡像的真實(shí)性與來源可信度。讀完本文你將掌握兩條核心命令鏈——cosign verify-attestation驗(yàn)證構(gòu)建聲明、cosign download sbom拉取架構(gòu)級物料清單并能將同樣的校驗(yàn)邏輯接入 sigstore policy controller 等準(zhǔn)入控制器形成自動(dòng)化供應(yīng)鏈安全防線。背景Knative 發(fā)布物中的安全元數(shù)據(jù)Knative 為每個(gè)隨版本發(fā)布的容器鏡像同時(shí)公開兩類供應(yīng)鏈安全元數(shù)據(jù)SLSA 構(gòu)建證明SLSA provenance采用 in-toto 規(guī)范描述的 attestation 文檔記錄鏡像的構(gòu)建過程、構(gòu)建環(huán)境與來源信息用于回答這個(gè)鏡像是不是 Knative 官方構(gòu)建的、以及它是如何構(gòu)建的。SBOM軟件物料清單列出鏡像內(nèi)部包含的每一個(gè)軟件組件及其版本用于回答這個(gè)鏡像里到底裝了哪些軟件。這兩類數(shù)據(jù)在 Knative 構(gòu)建流程中自動(dòng)生成并作為 attestation 存儲(chǔ)在容器鏡像倉庫中任何擁有 cosign 工具的人都可以獨(dú)立讀取和驗(yàn)證不依賴對發(fā)布頁面的信任。其背后的供應(yīng)鏈安全定位在 威脅模型文檔 中有明確說明對容器鏡像與命令行二進(jìn)制進(jìn)行簽名并附帶 SBOM 與 SLSA 證明是為了降低供應(yīng)鏈攻擊風(fēng)險(xiǎn)讓管理員與用戶能夠確認(rèn)自己拿到的工件與 Knative 官方構(gòu)建的一致并驗(yàn)證 SLSA 關(guān)于臨時(shí)構(gòu)建與可復(fù)現(xiàn)構(gòu)建的安全保證。Knative 的knCLI 客戶端二進(jìn)制同樣采用 cosign 簽名驗(yàn)證方式記錄在 驗(yàn)證客戶端二進(jìn)制文檔其使用的簽名身份與鏡像驗(yàn)證完全一致可作為交叉印證。前置條件驗(yàn)證鏡像前需要準(zhǔn)備兩樣?xùn)|西cosign 工具cosign 是 sigstore 項(xiàng)目提供的容器簽名/驗(yàn)證 CLI負(fù)責(zé)從容器倉庫拉取并解析 attestation。安裝方式請參考 sigstore 官方文檔cosign install或各發(fā)行版包管理器。目標(biāo)鏡像引用$IMAGEKnative 發(fā)布清單 YAML 中列出的鏡像地址例如gcr.io/knative-releases/knative.dev/serving/cmd/controller這類帶 tag 的引用。Knative 的簽名模式與驗(yàn)證身份KEYLESS無密鑰簽名模式Knative 的鏡像與二進(jìn)制均采用KEYLESS 簽名模式keyless signing不預(yù)先管理長期私鑰而是在構(gòu)建/簽名時(shí)由 CI 流水線向 sigstore 的 Fulcio 證書機(jī)構(gòu)申請短期證書完成簽名證書與簽名一并寫入倉庫。驗(yàn)證方無需持有公鑰只需校驗(yàn)Subject簽名身份signerknative-releases.iam.gserviceaccount.comIssuer證書簽發(fā)者h(yuǎn)ttps://accounts.google.com從發(fā)布腳本印證簽名身份簽名身份在倉庫的發(fā)布腳本 vendor/knative.dev/hack/release.sh 中被硬編碼為兩個(gè)常量RELEASE_SIGNING_IDENTITYsignerknative-releases.iam.gserviceaccount.com——正式版本簽名身份即本文所有命令中使用的 SubjectNIGHTLY_SIGNING_IDENTITYsignerknative-nightly.iam.gserviceaccount.com——每晚構(gòu)建nightly的簽名身份驗(yàn)證 nightly 鏡像時(shí)應(yīng)改用該郵箱。在sign_release()函數(shù)中release.shCI 通過gcloud auth print-identity-token --audiencessigstore模擬上述服務(wù)賬號取得短期身份令牌然后執(zhí)行cosign sign簽名鏡像與cosign attest附加 SLSA 證明。這意味著凡是你驗(yàn)證通過的鏡像其簽名鏈最終都指向 Knative 官方維護(hù)的 Google 服務(wù)賬號而不是某個(gè)個(gè)人密鑰。驗(yàn)證 SLSA 構(gòu)建證明signed provenance單條驗(yàn)證命令針對發(fā)布清單中給定的任一鏡像用以下命令驗(yàn)證其構(gòu)建 attestationcosign verify-attestation \ --certificate-oidc-issuer https://accounts.google.com \ --certificate-identity signerknative-releases.iam.gserviceaccount.com \ --type slsaprovenance02 \ $IMAGE參數(shù)說明參數(shù)含義--certificate-oidc-issuer校驗(yàn)簽名證書的 OIDC 簽發(fā)者Knative 固定為https://accounts.google.com--certificate-identity校驗(yàn)簽名主體SubjectKnative 正式版固定為signerknative-releases.iam.gserviceaccount.com--typeattestation 的 predicate 類型Knative 生成的為 SLSA v0.2 規(guī)范即slsaprovenance02$IMAGE要驗(yàn)證的鏡像引用當(dāng)證書鏈有效、身份與 issuer 匹配、且 attestation 與鏡像摘要digest一致時(shí)命令返回成功否則會(huì)報(bào)出證書不匹配或無法提取證明等錯(cuò)誤。注意命令會(huì)輸出全部 attestation你需要逐一確認(rèn)每一條都滿足預(yù)期身份條件因?yàn)橥荤R像可能附帶多個(gè)簽名。用 jq 解碼 in-toto 文檔attestation 中的 in-toto 文檔以 Base64 編碼存放在.payload字段中配合jq可以解碼出可讀的 JSON 構(gòu)建聲明cosign verify-attestation \ --certificate-oidc-issuer https://accounts.google.com \ --certificate-identity signerknative-releases.iam.gserviceaccount.com \ --type slsaprovenance02 \ $IMAGE | jq -r .payload | base64 --decode | jq這一連串管道完成了驗(yàn)證簽名 → 提取 payload → Base64 解碼 → 格式化輸出四步。解碼后你將看到 in-toto 聲明中的builder、buildType、recipe、materials等字段它們描述了鏡像由哪個(gè)構(gòu)建系統(tǒng)、在什么環(huán)境下、引用了哪些上游源碼與依賴構(gòu)建而成——這正是 SLSA 證明的核心信息可用于審計(jì)構(gòu)建可復(fù)現(xiàn)性。驗(yàn)證的工程化落地接入準(zhǔn)入控制器驗(yàn)證命令本身可用于手工審計(jì)但更常見的生產(chǎn)場景是自動(dòng)強(qiáng)制校驗(yàn)將 Knative 公開的這些 attestation 信息配置進(jìn)sigstore policy controller或其他準(zhǔn)入控制器admission controller使得集群在拉取/創(chuàng)建 Pod 時(shí)自動(dòng)檢查鏡像簽名與證明不滿足策略的鏡像直接拒絕部署。這與文檔 security-prereqs-images 片段 描述的用法一致——當(dāng)集群被配置為在 Pod 執(zhí)行期間校驗(yàn)鏡像簽名時(shí)你就需要本頁的鏡像驗(yàn)證信息來配置策略。若需在安裝前先人工核對鏡像來源也可參考 security-prereqs-images 片段 的提示在安裝 Knative 前可選地對鏡像執(zhí)行驗(yàn)證再從發(fā)布清單進(jìn)行部署。下載與解析 Knative SBOMSBOM 的生成方式Knative 的每個(gè)容器鏡像都會(huì)發(fā)布與之對應(yīng)的 SBOM且這些 SBOM 是在編譯期由ko工具 生成并寫入倉庫的。因此 SBOM 精確反映了該次構(gòu)建實(shí)際鏈接進(jìn)來的軟件組件而不是一份靜態(tài)的預(yù)期清單。下載命令使用 cosign 的download sbom子命令即可拉取cosign download sbom $IMAGE多架構(gòu)鏡像的架構(gòu)級提取Knative 發(fā)布清單 YAML 中的鏡像引用是多架構(gòu)multi-arch鏡像manifest list。由于不同架構(gòu)在構(gòu)建時(shí)可能鏈接不同的底層庫SBOM 內(nèi)容會(huì)因架構(gòu)而異要精確獲取某個(gè)架構(gòu)例如linux/amd64的軟件組件必須針對架構(gòu)專屬鏡像執(zhí)行下載cosign download sbom $IMAGE-linux-amd64 # 示例帶架構(gòu)后綴的鏡像引用實(shí)際操作中架構(gòu)專屬鏡像的引用形式取決于倉庫的命名約定常見為鏡像 digest 或帶-linux-amd64后綴的 tag你可以先用docker buildx imagetools inspect $IMAGE或crane manifest查看 manifest list 中各個(gè)平臺(tái)對應(yīng)的 digest再對目標(biāo) digest 執(zhí)行cosign download sbom。拿到 SBOM 后可結(jié)合企業(yè)漏洞掃描如 Trivy、Grype與 CVE 庫比對確認(rèn)鏡像組件版本是否在受影響的范圍內(nèi)。驗(yàn)證完整流程示例端到端將以上環(huán)節(jié)串起來一次完整的鏡像供應(yīng)鏈校驗(yàn)流程為# 1. 驗(yàn)證鏡像的 SLSA 構(gòu)建證明 cosign verify-attestation \ --certificate-oidc-issuer https://accounts.google.com \ --certificate-identity signerknative-releases.iam.gserviceaccount.com \ --type slsaprovenance02 \ $IMAGE # 2. 解碼并審閱構(gòu)建聲明的 payload cosign verify-attestation \ --certificate-oidc-issuer https://accounts.google.com \ --certificate-identity signerknative-releases.iam.gserviceaccount.com \ --type slsaprovenance02 \ $IMAGE | jq -r .payload | base64 --decode | jq # 3. 按需下載對應(yīng)架構(gòu)的 SBOM 進(jìn)行成分審計(jì) cosign download sbom $IMAGE三步分別回答三個(gè)問題鏡像是否由 Knative 官方身份簽名構(gòu)建過程聲明了什么鏡像由哪些軟件組件構(gòu)成三者疊加即構(gòu)成來源可信 構(gòu)建可審計(jì) 成分可盤點(diǎn)的完整鏡像信任鏈。補(bǔ)充資料Knative 安全與漏洞披露總覽安全團(tuán)隊(duì)、漏洞報(bào)告渠道與威脅模型入口Knative 威脅模型SLSA 構(gòu)建與 provenance 緩解的供應(yīng)鏈攻擊場景system code execution驗(yàn)證客戶端二進(jìn)制與鏡像驗(yàn)證同源的 cosign KEYLESS 簽名身份可用于校驗(yàn)kn等 CLI 二進(jìn)制2023 年安全審計(jì)博客記錄 Knative 自建 provenance-generator 生成 SLSA 兼容證明并納入發(fā)布流程的背景。贊分享文檔教程云原生【免費(fèi)下載鏈接】docsUser documentation for Knative components.項(xiàng)目地址https://gitcode.com/gh_mirrors/docs1/docs點(diǎn)擊查看免費(fèi)下載相關(guān)推薦驗(yàn)證 Knative kn CLI 二進(jìn)制使用 cosign 與 SHA256 校驗(yàn)官方發(fā)行物驗(yàn)證 Knative kn CLI 二進(jìn)制使用 cosign 與 SHA256 校驗(yàn)官方發(fā)行物 從 Knative 1.9 版本開始官方使用 cosign文檔教程云原生LinuxKit SBoM 軟件物料清單構(gòu)建期生成、合并與 050_sbom 測試驗(yàn)證全解析LinuxKit SBoM 軟件物料清單構(gòu)建期生成、合并與 050_sbom 測試驗(yàn)證全解析 LinuxKit 將若干 OCI 鏡像組合為最小化、面向容器場景操作系統(tǒng)云原生容器運(yùn)行時(shí)Beekeeper Studio 配置文件位置速查3 平臺(tái)路徑、3 層優(yōu)先級一次講清Beekeeper Studio 配置文件位置速查3 平臺(tái)路徑、3 層優(yōu)先級一次講清 改了配置、反復(fù)重啟Beekeeper Studio 就是沒有反應(yīng)——十桌面應(yīng)用數(shù)據(jù)庫客戶端開發(fā)工具上一篇Hermes Agent 配置全解從 3 條命令到多場景定制下一篇智慧教育平臺(tái)電子課本下載終極指南3步快速獲取PDF教材創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考