Why Software Supply Chain Security is important?

Software supply chain security is the act of securing the components, activities, and practices involved in creating software.

Attacks in the software supply chain have become more and more frequent in recent years, SonaType reported more than 700% of attacks in open-source software from 2019 to 2022.

In this Google Security Blog, there are many real examples of software supply chain attacks that pose growing threats to users and Google proposed a solution called SLSA in 2021.

Also, some well-known organizations such as Linux Foundation and CNCF have created standards and tools to address the issue of how to produce trusted software and attestations.

Based on this background, many organizations want to incorporate best practices from the open-source community into our CICD pipeline.

Read More

由于近些年针对软件的供应链的攻击越来越频繁，因此 Google 在 2021 提出的解决方案是软件工件供应链级别（Supply chain Levels for Software Artifacts，”SLSA”）

本篇将介绍在非 GitHub 生态系统中，我们如何生成和验证软件工件的来源，从而提高你的项目的 SLSA Level。

Witness 是一个可插拔的软件供应链风险管理框架，它能自动、规范和验证软件工件出处。它是 in-toto 是 CNCF 下的项目之一。它的最初作者是 Testifysec，后来捐赠给了 in-toto。

什么是 Witness

Witness 是一个可插拔的供应链安全框架，可创建整个软件开发生命周期（SDLC）的证据（Provenance）跟踪，确保软件从源代码到目标的完整性。它支持大多数主要的 CI 和基础架构提供商，是确保软件供应链安全的多功能、灵活的解决方案。

安全 PKI (Public Key Infrastructure - 公钥基础设施)分发系统的使用和验证 Witness 元数据的能力进一步增强了流程的安全性，并有助于减少许多软件供应链攻击向量。

Witness 的工作原理是封装在持续集成流程中执行的命令，为软件开发生命周期（SDLC）中的每个操作提供证据跟踪，这样就可以详细、可验证地记录软件是如何构建的、由谁构建以及使用了哪些工具。

这些证据可用于评估政策合规性，检测任何潜在的篡改或恶意活动，并确保只有授权用户或机器才能完成流程中的某一步骤。

总结 - Witness 可以做什么

• 验证软件由谁构建、如何构建以及使用了哪些工具
• 检测任何潜在的篡改或恶意活动
• 确保只有经授权的用户或机器才能完成流程的每一步
• 分发证词（Attestations）和策略（Policy）

如何使用 Witness

主要分三步：

1. witness run - 运行提供的命令并记录有关执行的证词。
2. witness sign - 使用提供的密钥签署提供的文件。
3. witness verify - 验证 witness 策略。

快速开始

这是我创建的 Witness Demo 仓库用于演示 witness 的工作流程，具体可以根据如下步骤进行。

Read More

由于近些年针对软件的供应链的攻击越来越频繁，据 SonaType 的统计从 2019 年到 2022 年针对开源软件的攻击增长了 742%，因此 2021 年 Google 提出的解决方案是软件工件供应链级别（Supply chain Levels for Software Artifacts，”SLSA”）

本篇将介绍在 Python 生态系统中，我们如何使用 SLSA 框架来生成和验证 Python 工件的来源，从而让你的 SLSA Level 从 L0/L1 到 L3。

注意：本文介绍的是针对托管在 GitHub 上的 Python 项目。SLSA 框架可通过 GitHub Actions 来实现开箱即用，只需较少的配置即可完成。

对于托管在非 GitHub 上的项目（例如 Bitbucket）可以尝试 Witness，下一篇我将更新关于如何使用 Witness。

内容

1. 构建纯净的Python包
2. 生成出处证明
3. 上传到PyPI
4. 验证Python包的来源
5. 文中用到的项目

下面是从维护人员到用户的端到端工作流程：从构建 Wheel package -> 生成出处 -> 验证出处 -> 发布到 PyPI -> 以及用户验证出处 -> 安装 wheel。接下来让我们一起来完成这其中的每一步。

如果你想了解 Python 打包的流程或是术语可以参见Python 打包用户指南。

Read More

In this article, I would like to document the problems encountered when upgrading from IBM XLC 10.1 to XLC 17.1 (IBM Open XL C/C++ for AIX 17.1.0) and how to fix the following 12 errors.

If you’ve encountered any other errors, feel free to share your comments with or without a solution.

Read More

2202-23 世界质量报告（World Quality Report 简称 WQR）是一项全球研究，不论是作为软件测试、开发工程师，关注这类软件质量报告可以帮助我们快速了解软件行业的现状和趋势。

七个主题

今年的 WQR 的关键趋势和推荐包括包括以下七个关键建议：

• 敏捷质量调配 (DONE)
• 质量自动化 (DONE)
• 测试基础设施测试和配置 (DONE)
• 测试数据提供和数据验证 (WIP)
• 质量和可持续的 IT (NOT START)
• 新兴技术趋势的质量工程 (NOT START)
• 价值流管理 (NOT START)

Read More

最近遇到了通过 Jenkins agent 无法上传 artifacts 到 Artifactory 的情况，具体错误如下：

Read More

最近又遇到了在 AIX 上通过 Jenkins agent 无法下载代码的情况，报了如下错误：

Read More

DevOps 运动仍然是一个不断发展的领域，受到技术进步、行业趋势和组织需求等多种因素的影响。这使得很难对 DevOps 工程的未来做出具体预测。然而我认为有一些趋势可能会在来年继续影响 DevOps 领域的发展。

Read More

Recently my CI pipeline suddenly does not work on AIX 7.1 with error Caused by: javax.net.ssl.SSLHandshakeException: com.ibm.jsse2.util.h: PKIX path building failed: java.security.cert.CertPathBuilderException: PKIXCertPathBuilderImpl could not build a valid CertPath..

Read More

其实创建包管理平台账户没什么可说的，但最近准备在 https://www.nuget.org 上面发布产品前创建 Organization 的时候确遇到了问题。

事情是这样的

作为一名公司员工在首次打开 NuGet 网站 (www.nuget.org) 的时候，点击【Sign in】，映入眼帘的就是【Sign in with Microsoft】，点击，下一步、下一步，我就顺利的就用公司邮箱注册了我的第一个 NuGet 的账户。

此时我准备创建一个 Organization 的时候，输入自己的公司邮箱提示这个邮箱地址已经被使用了，What ？？？

OK。那我就填写同事的公司邮箱地址吧。

同事在收到邮件通知后也是一步步操作，先是打开 NuGet.org，点击【Sign in with Microsoft】，然后也是需要填写自己的账户名，结果完成这一系列的操作之后，再输入他的邮件地址去注册 Organization 的时候也同样提示这个邮箱已经被使用了？？？什么操作！！！醉了…

Read More

随着容器化技术的普及和应用场景的增多，构建和管理多平台镜像变得越来越重要。Docker Buildx 是 Docker 官方对于 Docker CLI 的一个扩展，为 Docker 用户提供了更强大和灵活的构建功能。包括：

1. 多平台构建：Docker Buildx 允许用户在一个构建命令中为多个不同的平台构建容器镜像。这样，你可以一次性构建适用于多种 CPU 架构的镜像，比如 x86、ARM 等，从而在不同的硬件设备上运行相同的镜像。
2. 构建缓存优化：Docker Buildx 改进了构建过程中的缓存机制，通过自动识别 Dockerfile 中哪些部分是可缓存的，从而减少重复构建和加快构建速度。
3. 并行构建：Buildx 允许并行构建多个镜像，提高了构建的效率。
4. 多种输出格式：Buildx 支持不同的输出格式，包括 Docker 镜像、OCI 镜像、以及 rootfs 等。
5. 构建策略：通过支持多种构建策略，用户可以更好地控制构建过程，例如，可以在多个节点上构建、使用远程构建等。

使用 docker buildx 需要 Docker Engine 版本不低于 19.03。

其中，Docker Buildx Bake 是 Buildx 的一个子命令，也是本篇文章要重点介绍包括概念、优势、使用场景以及如何使用该功能来加速构建和管理多平台镜像。

Read More

什么是 SBOM

SBOM 是软件材料清单（Software Bill of Materials）的缩写。它是一份详细记录软件构建过程中使用的所有组件、库和依赖项的清单。

SBOM 类似于产品的配方清单，它列出了构成软件应用程序的各种元素，包括开源软件组件、第三方库、框架、工具等。每个元素在 SBOM 中都会有详细的信息，如名称、版本号、许可证信息、依赖关系等。

SBOM 的目的是增加软件供应链的可见性和透明度，并提供更好的风险管理和安全性。它可以帮助软件开发者、供应商和用户了解其软件中使用的组件和依赖项，以便更好地管理潜在的漏洞、安全风险和合规性问题。通过 SBOM 用户可以识别和跟踪软件中存在的任何潜在漏洞或已知的安全问题，并及时采取相应的补救措施。

SBOM 还可以用于软件审计、合规性要求和法规遵从性等方面。一些行业标准和法规（如软件供应链安全框架（SSCF）和欧盟网络和信息安全指令（NIS指令））已经要求软件供应商提供 SBOM，以提高软件供应链的安全性和可信度。

总之，SBOM 是一份记录软件构建过程中使用的所有组件和依赖项的清单，它提供了对软件供应链的可见性，有助于管理风险、提高安全性，并满足合规性要求。

Read More

想必你也见到过很多开源项目中的 CONTRIBUTION.md 文档中通常都会让贡献者 Fork 仓库，然后做修改。

那么如果你是该开源项目中的成员是否需要 Fork 仓库进行修改呢？

以前我没有认真去想过这个问题，对于项目成员感觉 Fork 或不 Fork 好像差不多，但仔细想想 Fork 仓库与不 Fork 仓库其实是有以下几个主要的差别的：

Read More

Git 提交信息和 Git 分支命名规范是团队协作中非常重要的一部分，它们能够使代码库更加规范、易于维护和理解。

我们需要通过工具来帮助实现Git提交信息和分支创建规范，本篇将介绍如何使用 Commit Check 这个工具来验证提交信息、分支命名、提交用户名字、提交用户邮箱等是否符合规范。

更多关于Git提交信息和分支创建规范可以参看我之前发布的文章《程序员自我修养之Git提交信息和分支创建规范》，这里不再赘述。

Read More

What’s the issue

My Windows build machine is regular reboot after Windows updates, but my Jenkins agent service on this Windows can not
start automatically even I have set the startup type to Automatic.

Solution 1

After some research, select “Allow service to interact with desktop” with service properties on Log On tab can fix this problem.

In service properties -> Log On -> Select “Local System account” and select the checkbox for “Allow service to interact with desktop”.

Solution 2

Read More