建站
咨詢
售后
建站咨詢
新聞中心
2011 年，互聯(lián)網(wǎng)技術先驅(qū) Marc Andreessen 宣稱，軟件正在吞噬世界（Software is eating the world）。由軟件驅(qū)動的行業(yè)創(chuàng)新正在顛覆著傳統(tǒng)業(yè)務模式，推動著全球經(jīng)濟實現(xiàn)數(shù)字化連接。隨著互聯(lián)網(wǎng)的快速發(fā)展，數(shù)字化轉(zhuǎn)型已經(jīng)成為每一個企業(yè)的關鍵戰(zhàn)略。但是現(xiàn)代軟件開發(fā)涉及到多方協(xié)作，大量應用依賴開源代碼或者三方組件。在上游開源軟件的安全問題會傳遞到下游應用方并被放大，有可能給企業(yè)造成重大的安全風險和業(yè)務損失。
中方ssl適用于網(wǎng)站、小程序/APP、API接口等需要進行數(shù)據(jù)傳輸應用場景，ssl證書未來市場廣闊！成為成都創(chuàng)新互聯(lián)的ssl證書銷售渠道，可以享受市場價格4-6折優(yōu)惠！如果有意向歡迎電話聯(lián)系或者加微信：18982081108（備注：SSL證書合作）期待與您的合作！
軟件生產(chǎn)的過程與傳統(tǒng)制造業(yè)在很多方面是相似的。軟件制造商將自研業(yè)務代碼和第三方組件組合成完整的軟件，構建流程會將這些組件打包成為可部署的軟件制品，然后被企業(yè)客戶部署到生產(chǎn)環(huán)境中。這個過程被形象地稱為“軟件供應鏈”。而軟件供應鏈安全的目標是保軟件從開發(fā)到部署的整個生命周期的安全、可信賴。
在 Sonatypes's 2021 State of the Software Supply Chain 調(diào)查報告中，2021 年軟件供應鏈攻擊事件增長了 650%。
目前，軟件供應鏈安全已經(jīng)得到行業(yè)的高度重視。已經(jīng)有很多國家出臺了相關的政策法規(guī)來指導本國的供應鏈安全管理，以提高供應鏈安全韌性。2021 年 4 月，美國網(wǎng)絡安全與基礎設施安全局（CISA）和美國國家標準與技術院（NIST）聯(lián)合發(fā)布《防御軟件供應鏈攻擊》報告，首次對軟件供應鏈進行界定，并給出與軟件供應鏈攻擊相關的信息、關聯(lián)風險以及緩解措施。
谷歌也提出了 Supply chain Levels for Software Artifacts - 軟件制品的供應鏈等級，簡稱為 SLSA。SLSA 是 Google 內(nèi)部實施的多年的安全流程的開源版本，提供了一個安全框架和一組最佳實踐，來預防因為源代碼篡改、三方組件漏洞、制品倉庫入侵產(chǎn)生的安全威脅。
一、SBOM-提升軟件構成透明度
軟件供應鏈安全的基礎就是透明性。只有理解了應用是如何從代碼和依賴組件構建而成，我們才可以對應用的安全風險進行有效的治理。在美國 2021 年頒布的《關于改善國家網(wǎng)絡安全的行政命令》行政令中，特別要求政府軟件應包含機器可讀的軟件物料清單(Software Bill Of Materials, SBOM)。SBOM 是包含構建軟件使用的各種組件的詳細信息和供應鏈關系的正式記錄。
美國國家電信和信息管理局(NITA)在 14028 號政令的要求下，在 2021 年 7 月 12 日發(fā)布了《SBOM 的最低要素》，該文檔為各開發(fā)工具的組織和廠商提供了 SBOM 數(shù)據(jù)格式的參考。在新一代軟件開發(fā)工具中，越來越多的軟件提供了對 SBOM 的支持。
1.應用的 SBOM 信息
下面我們以一個 Golang 的 HTTP Server 示例應用為例，了解一下 SBOM 的的概念和使用方式。
$ git clone https://github.com/denverdino/secure-supply-chain-sample
$ cd secure-supply-chain-sample
$ go build .
熟悉 Go 語言的開發(fā)者一定對 go 模塊概念非常熟悉。應用所依賴的模塊，都通過 go.mod 文件聲明。go mod tidy 命令可以用來更新 go.mod 文件，并”鎖定“所依賴的模塊和版本信息，這大大提升了構建的確定性、可重現(xiàn)性和可驗證性。為了確保第三方無法篡改所依賴的模塊版本， 在 go.sum 文件記錄了每個模塊依賴的加密哈希值。當利用go命令將模塊代碼下載到本地時，就會計算其哈希值，如果計算結果與 go.sum 記錄的數(shù)據(jù)不符就意味著存在篡改的風險。更近一步，Google 運營著一個 Go 模塊校驗數(shù)據(jù)庫服務，它記錄了 go 模塊版本的加密哈希值，進一步提升了 Go 基礎設施的安全性。
更多內(nèi)容可以閱讀：https://go.dev/blog/supply-chain
對于已編譯的應用二進制文件，我們可以通過 go version -m 命令查看應用的構建信息，包括其軟件來源，依賴模塊，構建參數(shù)等等。
$ go version -m secure-supply-chain-sample
secure-supply-chain-sample: go1.18.3
path github.com/denverdino/secure-supply-chain-sample
mod github.com/denverdino/secure-supply-chain-sample (devel)
dep github.com/sirupsen/logrus v1.8.1 h1:dJKuHgqk1NNQlqoA6BTlM1Wf9DOH3NBjQyu0h9+AZZE=
dep golang.org/x/sys v0.0.0-20220702020025-31831981b65f h1:xdsejrW/0Wf2diT5CPp3XmKUNbr7Xvw8kYilQ+6qjRY=
build -compiler=gc
build CGO_ENABLED=1
build CGO_CFLAGS=
build CGO_CPPFLAGS=
build CGO_CXXFLAGS=
build CGO_LDFLAGS=
build GOARCH=amd64
build GOOS=darwin
build GOAMD64=v1
build vcs=git
build vcs.revision=c630057157df402b658ab97139895337633b5bbc
build vcs.time=2022-07-04T01:33:01Z
build vcs.modified=false
2.容器鏡像的 SBOM 支持
容器技術重塑了整個軟件供應鏈。容器鏡像將應用及其所有依賴項打包，從而使應用可以在不同的計算環(huán)境之間快速、可靠地運行。容器鏡像已經(jīng)成為了應用分發(fā)的標準，而 Kubernetes 成為了分布式資源調(diào)度和編排的事實標準。那么如何保障容器鏡像在構建、分發(fā)和運行時的完整性、安全性呢？
我們繼續(xù)以上面的 Golang 應用為例，介紹一下現(xiàn)容器化軟件供應鏈安全的最新實踐和工具鏈。
Ko 是 Google 開源的一個簡單、快速的 Go 應用程序容器鏡像構建器。今天我們只聚焦于 Ko 在軟件供應鏈的一些設計，大家可以舉一反三，應用在自己的語言和項目中。
無需編寫 Dockerfile，利用 Ko build 我們可以將一個 Golang 項目構建成為一個 Docker 鏡像。
$ cat .ko.yaml
defaultBaseImage: knative-dev-registry.cn-hangzhou.cr.aliyuncs.com/distroless/static:nonroot
$ export KO_DOCKER_REPO=knative-dev-registry.cn-hangzhou.cr.aliyuncs.com/denverdino
$ ko build -B .
2022/07/02 21:05:33 Using base knative-dev-registry.cn-hangzhou.cr.aliyuncs.com/distroless/static:nonroot@sha256:66cd130e90992bebb68b8735a72f8ad154d0cd4a6f3a8b76f1e372467818d1b4 for github.com/denverdino/secure-supply-chain-sample
2022/07/02 21:05:33 Building github.com/denverdino/secure-supply-chain-sample for linux/amd64
2022/07/02 21:05:34 Publishing knative-dev-registry.cn-hangzhou.cr.aliyuncs.com/denverdino/secure-supply-chain-sample:latest
2022/07/02 21:05:35 existing blob: sha256:64ef75a9b8ab92a78ea225f1e707dfee0434dcf7cb0e0b5a8b5020e6b737b791
2022/07/02 21:05:35 existing blob: sha256:3f99978937439fa8ef418c3f36e755f10d175ba218dda5f42846a52b8dca002d
2022/07/02 21:05:35 knative-dev-registry.cn-hangzhou.cr.aliyuncs.com/denverdino/secure-supply-chain-sample:sha256-cd1ac13d65aa8983f6c10317a09b994cd66fa46aceb1ba1eaf2cab4ee2038ec3.sbom: digest: sha256:0500ec91074135a2774c87fe86833c0267713be9e78cc4ea86b86cc42701fd0a size: 368
2022/07/02 21:05:35 Published SBOM knative-dev-registry.cn-hangzhou.cr.aliyuncs.com/denverdino/secure-supply-chain-sample:sha256-cd1ac13d65aa8983f6c10317a09b994cd66fa46aceb1ba1eaf2cab4ee2038ec3.sbom
2022/07/02 21:05:36 existing blob: sha256:7d883a3eb1c556752c73dedf88da2c0d3943b9f5c3f763cdd7a813ca766f5486
2022/07/02 21:05:36 existing blob: sha256:250c06f7c38e52dc77e5c7586c3e40280dc7ff9bb9007c396e06d96736cf8542
2022/07/02 21:05:36 existing blob: sha256:1759dab52bf113b8a23d818934e0fb48d6f4528df4d614b6edc1d7dba05a01b3
2022/07/02 21:05:36 existing blob: sha256:70e4c71b62aef82e9650deb85d30f3402b435e07665d775a3f3b700e9e7300cb
2022/07/02 21:05:36 knative-dev-registry.cn-hangzhou.cr.aliyuncs.com/denverdino/secure-supply-chain-sample:latest: digest: sha256:cd1ac13d65aa8983f6c10317a09b994cd66fa46aceb1ba1eaf2cab4ee2038ec3 size: 751
2022/07/02 21:05:36 Published knative-dev-registry.cn-hangzhou.cr.aliyuncs.com/denverdino/secure-supply-chain-sample@sha256:cd1ac13d65aa8983f6c10317a09b994cd66fa46aceb1ba1eaf2cab4ee2038ec3
knative-dev-registry.cn-hangzhou.cr.aliyuncs.com/denverdino/secure-supply-chain-sample@sha256:cd1ac13d65aa8983f6c10317a09b994cd66fa46aceb1ba1eaf2cab4ee2038ec3
為什么鏡像的創(chuàng)建時間變成了 ”1970/1/1“ ? 這是因為 Ko 的一個設計目標就是支持 Reproducible Builds - 可重現(xiàn)的構建。Reproducible Builds 是一組開發(fā)實踐，當源碼與構建環(huán)境配置一模一樣時，在不同機器上編譯出來的目標二進制文件會在比特層面上做到完全相同。這樣的好處是允許獨立的第三方可以對從源代碼到二進制文件編譯過程中進行驗證，確保沒有引入漏洞或后門。常見的 docker build 命令構建出的容器鏡像會在鏡像的 manifest 文件中包含構建時間戳，而鏡像的 HASH 計算會包含 manifest 文件。這樣導致即使是使用相同的代碼和 Dockerfile，也無法保障構建出的鏡像 HASH 是相同的。
Ko 通過固定應用代碼和鏡像構建的時間戳，確保了在任何環(huán)境構建出的鏡像 HASH 保持不變。所以我們可以通過比較鏡像的 HASH 值來快速判斷兩個鏡像中的內(nèi)容是否一致。一個開放性的問題，Reproducible Build 是否是一個最佳實踐？是否適合于您的業(yè)務場景？
此外，為了更好支持軟件供應鏈安全。Ko 自動為應用容器鏡像生成了相應的 SBOM 信息，并且作為一個應用制品推送到鏡像倉庫中?？梢酝ㄟ^ URL 路徑進行訪問：{KO_DOCKER_REPO}/{IMAGE_NAME}:sha256-{HASH}.sbom
如何獲得容器鏡像的 SBOM 信息呢？我們有兩個方法：第一，如果在鏡像倉庫中沒有保存容器鏡像的 SBOM 信息，我們可以利用 docker sbom 命令分析生成應用鏡像的 SBOM 信息。
$ docker sbom knative-dev-registry.cn-hangzhou.cr.aliyuncs.com/denverdino/secure-supply-chain-sample@sha256:cd1ac13d65aa8983f6c10317a09b994cd66fa46aceb1ba1eaf2cab4ee2038ec3
Syft v0.43.0
Loaded image
Parsed image
Cataloged packages [6 packages]
NAME VERSION TYPE
base-files 11.1+deb11u3 deb
github.com/denverdino/secure-supply-chain-sample go-module
github.com/sirupsen/logrus v1.8.1 go-module
golang.org/x/sys v0.0.0-20220702020025-31831981b65f go-module
netbase 6.3 deb
tzdata 2021a-1+deb11u4 deb
第二，如果在鏡像倉庫中已經(jīng)存儲了容器鏡像的 SBOM 信息，比如 Ko 所發(fā)布的 SBOM 信息。我們可以利用 Sigstore 項目中的 cosign 工具直接獲得鏡像的 SBOM 內(nèi)容。
$ cosign download sbom knative-dev-registry.cn-hangzhou.cr.aliyuncs.com/denverdino/secure-supply-chain-sample@sha256:cd1ac13d65aa8983f6c10317a09b994cd66fa46aceb1ba1eaf2cab4ee2038ec3
Found SBOM of media type: text/spdx
SPDXVersion: SPDX-2.2
DataLicense: CC0-1.0
SPDXID: SPDXRef-DOCUMENT
DocumentName: github.com/denverdino/secure-supply-chain-sample
DocumentNamespace: http://spdx.org/spdxpackages/github.com/denverdino/secure-supply-chain-sample
Creator: Tool: ko 0.11.2
Created: 1970-01-01T00:00:00Z
##### Package representing github.com/denverdino/secure-supply-chain-sample
PackageName: github.com/denverdino/secure-supply-chain-sample
SPDXID: SPDXRef-Package-github.com.denverdino.secure-supply-chain-sample
PackageSupplier: Organization: github.com/denverdino/secure-supply-chain-sample
PackageDownloadLocation: https://github.com/denverdino/secure-supply-chain-sample
FilesAnalyzed: false
PackageHomePage: https://github.com/denverdino/secure-supply-chain-sample
PackageLicenseConcluded: NOASSERTION
PackageLicenseDeclared: NOASSERTION
PackageCopyrightText: NOASSERTION
PackageLicenseComments: NOASSERTION
PackageComment: NOASSERTION
Relationship: SPDXRef-DOCUMENT DESCRIBES SPDXRef-Package-github.com.denverdino.secure-supply-chain-sample
Relationship: SPDXRef-Package-github.com.denverdino.secure-supply-chain-sample DEPENDS_ON SPDXRef-Package-github.com.sirupsen.logrus-v1.8.1
##### Package representing github.com/sirupsen/logrus
PackageName: github.com/sirupsen/logrus
SPDXID: SPDXRef-Package-github.com.sirupsen.logrus-v1.8.1
PackageVersion: v1.8.1
PackageSupplier: Organization: github.com/sirupsen/logrus
PackageDownloadLocation: https://proxy.golang.org/github.com/sirupsen/logrus/@v/v1.8.1.zip
FilesAnalyzed: false
PackageChecksum: SHA256: 7492ae1e0aa4d4d35096aa00e814e533559ff43387dcd063432bb487df806591
PackageLicenseConcluded: NOASSERTION
PackageLicenseDeclared: NOASSERTION
PackageCopyrightText: NOASSERTION
PackageLicenseComments: NOASSERTION
PackageComment: NOASSERTION
Relationship: SPDXRef-Package-github.com.denverdino.secure-supply-chain-sample DEPENDS_ON SPDXRef-Package-golang.org.x.sys-v0.0.0-20220702020025-31831981b65f
##### Package representing golang.org/x/sys
PackageName: golang.org/x/sys
SPDXID: SPDXRef-Package-golang.org.x.sys-v0.0.0-20220702020025-31831981b65f
PackageVersion: v0.0.0-20220702020025-31831981b65f
PackageSupplier: Organization: golang.org/x/sys
PackageDownloadLocation: https://proxy.golang.org/golang.org/x/sys/@v/v0.0.0-20220702020025-31831981b65f.zip
FilesAnalyzed: false
PackageChecksum: SHA256: c5db1e8eb5bfd167f67624f908fa775e629435bafb5efc3c9188a543eeaa8d16
PackageLicenseConcluded: NOASSERTION
PackageLicenseDeclared: NOASSERTION
PackageCopyrightText: NOASSERTION
PackageLicenseComments: NOASSERTION
PackageComment: NOASSERTION
二、新一代鏡像簽名技術-Keyless
眾所周知，我們可以用鏡像簽名的方式來保障鏡像的可追溯性。一般而言，開發(fā)者利用私鑰對鏡像加簽，在部署應用時，可以通過 OPA/Gatekeeper 攔截請求，對鏡像進行驗簽。開發(fā)者可以定義安全策略來自動化安全流程。比如我們可以定義一個策略，不允許存在高風險漏洞的鏡像部署到生產(chǎn)系統(tǒng)。在鏡像構建階段，我們可以對通過鏡像掃描且不包含高風險漏洞的鏡像進行簽名，而在 K8s 生產(chǎn)集群中，通過安全策略來來校驗鏡像簽名。
由于過去鏡像加簽/驗簽的工具易用性不好，并沒有得到企業(yè)廣泛的應用。阿里云鏡像服務 ACR，ACK 在提供了集成、簡化的鏡像安全體驗，極大降低了鏡像安全的技術門檻。
我們今天給大家介紹一個新的技術思路。Sigstore 是由紅帽、谷歌聯(lián)合幾所美國高校主導開發(fā)維護的供應鏈安全開源項目，旨在提供一個新的軟件加簽、驗簽和防護的標準。通過 Sigstore，我們可以自動對云原生下的各類開源制品進行數(shù)字簽名并校驗，幫助構建一個更安全、可追溯的供應監(jiān)控鏈。
其中 Sigstore 的無密鑰簽名 Keyless Signatures 模式是這個項目最大的亮點之一。無密鑰簽名，支持自動化的密鑰管理能力，使用者無需管理維護私鑰，極大簡化的鏡像加簽驗簽的體驗。
我們首先通過 cosign sign 命令對鏡像進行加簽：
$ COSIGN_EXPERIMENTAL=true cosign sign knative-dev-registry.cn-hangzhou.cr.aliyuncs.com/denverdino/secure-supply-chain-sample@sha256:cd1ac13d65aa8983f6c10317a09b994cd66fa46aceb1ba1eaf2cab4ee2038ec3
Generating ephemeral keys...
Retrieving signed certificate...
Note that there may be personally identifiable information associated with this signed artifact.
This may include the email address associated with the account with which you authenticate.
This information will be used for signing this artifact and will be stored in public transparency logs and cannot be removed later.
By typing 'y', you attest that you grant (or have permission to grant) and agree to have this information stored permanently in transparency logs.
Are you sure you want to continue? (y/[N]): y
Your browser will now be opened to:
https://oauth2.sigstore.dev/auth/auth?access_type=online&client_id=sigstore&code_challenge=Zj3B13VeqlwO1OEs_cc_gVly21ZWdotsB_ipAG1KUD0&code_challenge_method=S256&nonce=2BPd2p6uHg1e916zBz3MoEoH8FR&redirect_uri=http%3A%2F%2Flocalhost%3A55455%2Fauth%2Fcallback&response_type=code&scope=openid+email&state=2BPd2uo32VlgXKC9NY0rDOJlfmA
Successfully verified SCT...
tlog entry created with index: 2824482
Pushing signature to: knative-dev-registry.cn-hangzhou.cr.aliyuncs.com/denverdino/secure-supply-chain-sample
在 Keyless 模式中，終端會自動打開瀏覽器，由用戶選擇 OAuth 身份服務商進行認證，流程完成后。cosign 會對鏡像進行簽名，并將鏡像簽名保存在鏡像倉庫中，其 URL 路徑為： {IMAGE_REPO}/{IMAGE_NAME}:sha256-{HASH}.sig
在這個過程中 cosign 利用 fulcio 的根證書，創(chuàng)建了一個臨時秘鑰和證書，對鏡像進行加簽。簽名也會記錄在 Rekor 的透明化日志中，為鏡像簽名提供遠程證明。我們可以利用 cosign verify 命令對鏡像簽名進行校驗。
COSIGN_EXPERIMENTAL=true cosign verify knative-dev-registry.cn-hangzhou.cr.aliyuncs.com/denverdino/secure-supply-chain-sample@sha256:cd1ac13d65aa8983f6c10317a09b994cd66fa46aceb1ba1eaf2cab4ee2038ec3
Verification for knative-dev-registry.cn-hangzhou.cr.aliyuncs.com/denverdino/secure-supply-chain-sample@sha256:cd1ac13d65aa8983f6c10317a09b994cd66fa46aceb1ba1eaf2cab4ee2038ec3 --
The following checks were performed on each of these signatures:
- The cosign claims were validated
- Existence of the claims in the transparency log was verified offline
- Any certificates were verified against the Fulcio roots.
[{"critical":{"identity":{"docker-reference":"knative-dev-registry.cn-hangzhou.cr.aliyuncs.com/denverdino/secure-supply-chain-sample"},"image":{"docker-manifest-digest":"sha256:cd1ac13d65aa8983f6c10317a09b994cd66fa46aceb1ba1eaf2cab4ee2038ec3"},"type":"cosign container image signature"},"optional":{"Bundle":{"SignedEntryTimestamp":"MEQCIB1YeNP8suFn6xm7hn0qkAJBiID/gcOP//tsm7u2Z/FIAiBqiw0Zl1CvgVfcGhOWKUEkZKB2XdFm3FPaxq9E+Jsmyg==","Payload":{"body":"eyJhcGlWZXJzaW9uIjoiMC4wLjEiLCJraW5kIjoicmVrb3JkIiwic3BlYyI6eyJkYXRhIjp7Imhhc2giOnsiYWxnb3JpdGhtIjoic2hhMjU2IiwidmFsdWUiOiI2MDRiZWI5M2Q0OGVhYzA4ZmE3OTQzNWNhNTVlZmQyNTE4ODhlN2NmZmMzODJlZTE0MmRjMzZkZDExMzhkYzFjIn19LCJzaWduYXR1cmUiOnsiY29udGVudCI6Ik1FVUNJUUNhNXhYd25pR1J6ckRlamtHRHFCSFNTdlMvdUVCeUJkVUV0cFBiRVRxZUVBSWdGY0hWOW9RWkYxYk4xYmtxMWY3UFdWOUpCY00vZlhyZXZTa0orT0tWSDJrPSIsImZvcm1hdCI6Ing1MDkiLCJwdWJsaWNLZXkiOnsiY29udGVudCI6IkxTMHRMUzFDUlVkSlRpQkRSVkpVU1VaSlEwRlVSUzB0TFMwdENrMUpTVU52ZWtORFFXbHBaMEYzU1VKQlowbFZTSHByZFVSeVprODJWamxqVUhsSlkyZ3JOVXBFUlc4NVRtcHpkME5uV1VsTGIxcEplbW93UlVGM1RYY0tUbnBGVmsxQ1RVZEJNVlZGUTJoTlRXTXliRzVqTTFKMlkyMVZkVnBIVmpKTlVqUjNTRUZaUkZaUlVVUkZlRlo2WVZka2VtUkhPWGxhVXpGd1ltNVNiQXBqYlRGc1drZHNhR1JIVlhkSWFHTk9UV3BKZDA1NlFYbE5WRTB3VFdwSk1sZG9ZMDVOYWtsM1RucEJlVTFVVFRGTmFra3lWMnBCUVUxR2EzZEZkMWxJQ2t0dldrbDZhakJEUVZGWlNVdHZXa2w2YWpCRVFWRmpSRkZuUVVWQ016UkNhRGRPZWtRMFRqaEVWVWxyWW5WWVkxWTVUMEZEV1d4MlpGcFNiMkkzVmt3S1RIaE9SMnhOSzNrMmIycGhUR05EZHpaNVlsaHNaak5RVFU0clduaERUVmROTUVreVkyWjFPRUpZZFhNelUzaFVka3RQUTBGVlkzZG5aMFpFVFVFMFJ3cEJNVlZrUkhkRlFpOTNVVVZCZDBsSVowUkJWRUpuVGxaSVUxVkZSRVJCUzBKblozSkNaMFZHUWxGalJFRjZRV1JDWjA1V1NGRTBSVVpuVVZWUFExUm5DakZMV1dKbFZFRlpWVmxvZUZwVU1HeDJja0YzU0RaWmQwaDNXVVJXVWpCcVFrSm5kMFp2UVZVek9WQndlakZaYTBWYVlqVnhUbXB3UzBaWGFYaHBORmtLV2tRNGQwbG5XVVJXVWpCU1FWRklMMEpDWjNkR2IwVlZXa2RXZFdSdFZubGFSMngxWWpCQ2JtSlhSbkJpUXpWcVlqSXdkMHhCV1V0TGQxbENRa0ZIUkFwMmVrRkNRVkZSWldGSVVqQmpTRTAyVEhrNWJtRllVbTlrVjBsMVdUSTVkRXd5ZUhaYU1teDFUREk1YUdSWVVtOU5TVWRLUW1kdmNrSm5SVVZCWkZvMUNrRm5VVU5DU0hORlpWRkNNMEZJVlVGRFIwTlRPRU5vVXk4eWFFWXdaRVp5U2pSVFkxSlhZMWx5UWxrNWQzcHFVMkpsWVRoSloxa3lZak5KUVVGQlIwSUtkbmxZT0d0blFVRkNRVTFCVW1wQ1JVRnBRazVFYjBkNE16STNaMGRDZWxWeWRIaEZVVFZ6ZEZSRFF6Z3haRWMwY1dsU2VrMHZTMHR2Y3pGMU5IZEpad3BMVDIxTVNXdENXVzF6V21ZeFZIQTNNRXhaWkRCbGIwaFVVV3AyV1dFdldrbFdaVFEzWTBwMUwwaFpkME5uV1VsTGIxcEplbW93UlVGM1RVUmhVVUYzQ2xwblNYaEJTemREVFRkQ1NFMW1UWE5GY0hwa1lXbHlVRFIzUkZFeUwxUnZibEUxYTBack5FbEZWamRvY1dScFJWbDJVMEpEVVhoSU0xQjRjV2RGU1dJS2RVdEhiWEozU1hoQlR6VmlRamMyUVRSaE5qWXpUSGRFYVVkalYyUlpkVEZrY0Rabk1ubDRkREpyY0ZObFprcGlVMHBQT1dOWFJEVldOM1JUY1d0WmVRcGFSbkJSUmsxUlowdDNQVDBLTFMwdExTMUZUa1FnUTBWU1ZFbEdTVU5CVkVVdExTMHRMUW89In19fX0=","integratedTime":1656769347,"logIndex":2822273,"logID":"c0d23d6ad406973f9559f3ba2d1ca01f84147d8ffc5b8445c224f98b9591801d"}},"Issuer":"https://github.com/login/oauth","Subject":"[email protected]"}},{"critical":{"identity":{"docker-reference":"knative-dev-registry.cn-hangzhou.cr.aliyuncs.com/denverdino/secure-supply-chain-sample"},"image":{"docker-manifest-digest":"sha256:cd1ac13d65aa8983f6c10317a09b994cd66fa46aceb1ba1eaf2cab4ee2038ec3"},"type":"cosign container image signature"},"optional":{"Bundle":{"SignedEntryTimestamp":"MEYCIQDdn2/IzVRCAuS+8s5Zz1F2+Gp3/MXzFP2whryasTa3GQIhAJKWFtb7jGnL8krnR4CwVYr/jbtZuHtlX7TpNPtEP67R","Payload":{"body":"eyJhcGlWZXJzaW9uIjoiMC4wLjEiLCJraW5kIjoicmVrb3JkIiwic3BlYyI6eyJkYXRhIjp7Imhhc2giOnsiYWxnb3JpdGhtIjoic2hhMjU2IiwidmFsdWUiOiI2MDRiZWI5M2Q0OGVhYzA4ZmE3OTQzNWNhNTVlZmQyNTE4ODhlN2NmZmMzODJlZTE0MmRjMzZkZDExMzhkYzFjIn19LCJzaWduYXR1cmUiOnsiY29udGVudCI6Ik1FVUNJUURVVUdHOEJOZnRoeDBrZGxzWGpvZzZQaFRENmFsNUo4Y3F0WnFFOFJQY3BBSWdMYlFRd2pLT2I0VU9OS05DZ2hvNnlENDNSNHl4TVU2QldtYllBQmVTQXhnPSIsImZvcm1hdCI6Ing1MDkiLCJwdWJsaWNLZXkiOnsiY29udGVudCI6IkxTMHRMUzFDUlVkSlRpQkRSVkpVU1VaSlEwRlVSUzB0TFMwdENrMUpTVU53UkVORFFXbHRaMEYzU1VKQlowbFZTVmhtYW5nME1sTnNhQzl5TW5CTlNYUjFRMVJHVjNWVGNUTnJkME5uV1VsTGIxcEplbW93UlVGM1RYY0tUbnBGVmsxQ1RVZEJNVlZGUTJoTlRXTXliRzVqTTFKMlkyMVZkVnBIVmpKTlVqUjNTRUZaUkZaUlVVUkZlRlo2WVZka2VtUkhPWGxhVXpGd1ltNVNiQXBqYlRGc1drZHNhR1JIVlhkSWFHTk9U
網(wǎng)頁題目：談談我對創(chuàng)新互聯(lián)與軟件供應鏈安全的思考
文章路徑：http://www.fisionsoft.com.cn/article/coejcsj.html
