2012年，一种名为Flame的恶意软件在中东地区的计算机系统中悄然蔓延。它不仅使用了有效的数字证书签名，而且这个证书竟然来自一家知名的硬件制造商——宏碁的一家台湾子公司。安全研究人员最初以为自己看错了：一个经过微软Windows系统完整验证的、带有可信证书链签名的文件，怎么可能是恶意软件？
这个发现揭示了一个令人不安的事实：代码签名体系在保护软件供应链安全的同时，也正在被攻击者系统性地武器化。根据NDSS 2022发表的研究论文《Understanding the Status and Strategies of the Code Signing Abuse》，研究团队收集了超过133万个经过签名的恶意软件样本和188万个签名的潜在不需要程序（PUP）样本。在这些样本中，83.68%被明确标注了特定的滥用类型——证书盗窃、借用合法身份、或者利用过期证书绕过验证。
代码签名技术诞生的初衷，是为了解决软件分发中最核心的信任问题：用户如何确信下载的程序确实来自声称的开发者，且在传输过程中未被篡改？这个问题在互联网早期并不存在——那时候软件主要通过物理介质分发，用户可以直接验证软盘或光盘的来源。但随着网络分发的普及，信任链条断裂了。
timeline
title 代码签名技术发展关键节点
section 1990年代
1995 : 第一个代码签名专利申请
: (Eolas Technologies)
1996 : Microsoft发布Authenticode
: 用于ActiveX控件签名
1998 : Java Applet签名机制
: Sun Microsystems推出
section 2000年代
2002 : Windows驱动签名强制
: (WHQL认证)
2005 : EV代码签名证书推出
: Extended Validation
2008 : 苹果App Store上线
: 强制代码签名
section 2010年代
2012 : Flame恶意软件
: 使用被盗证书签名
2016 : macOS Gatekeeper强制
: 公证机制推出
2019 : CA/Browser Forum
: 强制HSM要求
section 2020年代
2021 : Sigstore项目启动
: 无证书签名方案
2023 : CA/Browser Forum新规
: 所有代码签名需HSM
2024 : SLSA框架推广
: 供应链安全标准
一、信任的数学基石：代码签名如何工作
理解代码签名为何会被武器化，首先需要理解它的技术本质。代码签名本质上是公钥基础设施（PKI）在软件分发领域的应用，它依赖于几个核心的密码学原语。
1.1 签名的数学构造
一个数字签名方案由三个算法组成：密钥生成（KeyGen）、签名（Sign）和验证（Verify）。在RSA签名方案中，签名的生成过程可以表示为：
$$\sigma = m^d \mod n$$其中 $m$ 是待签名消息的哈希值，$d$ 是私钥指数，$n$ 是模数。验证过程则计算：
$$m' = \sigma^e \mod n$$其中 $e$ 是公钥指数。如果 $m' = H(\text{message})$，则签名有效。这里的哈希函数 $H$ 通常使用SHA-256或SHA-384，将任意长度的文件映射为固定长度的摘要值。
但这里有一个关键问题：验证者如何确信公钥 $(e, n)$ 确实属于声称的开发者？这就是证书颁发机构（CA）介入的地方。CA用自己的私钥对开发者的公钥进行签名，形成一张证书。验证者只需信任少数几个根CA，就能建立对大量开发者证书的信任链条。
1.2 Windows Authenticode的结构
在Windows平台上，代码签名的标准格式是Authenticode，它基于PKCS#7的SignedData结构。一个Authenticode签名包含以下核心组件：
graph TD
A[PE文件] --> B[WIN_CERTIFICATE结构]
B --> C[证书链]
B --> D[签名数据]
B --> E[时间戳令牌]
D --> F[文件哈希]
D --> G[签名算法]
D --> H[签名值]
C --> I[终端实体证书]
I --> J[中间CA证书]
J --> K[根CA证书]
E --> L[TSA服务器URL]
E --> M[时间戳签名]
E --> N[时间戳证书链]
subgraph 验证流程
O[提取证书链] --> P[验证证书有效性]
P --> Q[验证签名]
Q --> R[验证时间戳]
R --> S[检查吊销状态]
end
WIN_CERTIFICATE结构存储在PE文件的可选头部数据目录中，其定义如下：
typedef struct _WIN_CERTIFICATE {
DWORD dwLength; // 结构总长度
WORD wRevision; // 版本号，目前为0x0200
WORD wCertificateType; // 证书类型，Authenticode为0x0002
BYTE bCertificate[ANYSIZE_ARRAY]; // PKCS#7 SignedData
} WIN_CERTIFICATE, *LPWIN_CERTIFICATE;
Authenticode签名的一个关键特性是它并不签名整个文件，而是签名文件的"摘要"。这是因为PE文件在签名后可能还需要被修改——例如添加额外的签名（双重签名场景）。计算摘要时，Authenticode会跳过PE文件中的特定区域，包括校验和字段、安全目录条目本身，以及资源部分的某些区域。
1.3 时间戳服务器的关键角色
代码签名面临一个独特挑战：证书会过期，吊销检查也会因为CA服务器不可用而失败。如果一个十年前签名的软件在今天无法通过验证，用户体验将极其糟糕。RFC 3161定义的时间戳协议（TSP）就是为了解决这个问题。
当开发者签名一个文件时，签名工具不仅会生成签名，还会向时间戳权威机构（TSA）发送请求。TSA返回一个时间戳令牌，证明签名是在特定时间点之前创建的。即使签名证书后来被吊销或过期，只要时间戳证明签名是在证书有效期内创建的，Windows仍然会信任该签名。
时间戳请求的ASN.1结构如下：
TimeStampReq ::= SEQUENCE {
version INTEGER { v1(1) },
messageImprint MessageImprint,
reqPolicy TSAPolicyId OPTIONAL,
nonce INTEGER OPTIONAL,
certReq BOOLEAN DEFAULT FALSE,
extensions [0] IMPLICIT Extensions OPTIONAL
}
时间戳令牌则是一个带有TSA签名的结构，包含了原始请求的消息摘要和时间值。这个设计使得签名的长期有效性不再依赖于开发者证书的有效期，而是依赖于TSA证书的有效期——而TSA通常是高度可靠的机构。
二、信任的断裂：签名恶意软件的规模化现实
如果说代码签名的技术机制是完美的，那么现实世界的数据则揭示了另一面。NDSS 2022的研究《Understanding the Status and Strategies of the Code Signing Abuse》提供了迄今为止最全面的签名恶意软件统计。
2.1 数据集的规模与来源
研究团队从VirusTotal收集了签名文件样本，经过筛选和分类，最终获得了：
- 1,330,838个签名的恶意软件样本
- 1,885,275个签名的潜在不需要程序（PUP）样本
- 时间跨度：2018年至2021年
这些样本中，83.68%被明确标注了特定的滥用类型。研究将证书滥用分为五类：
| 滥用类型 | 描述 | 占比 |
|---|---|---|
| 证书盗窃 | 攻击者窃取合法公司的证书私钥 | 27.4% |
| 身份伪造 | 使用虚假身份注册获取证书 | 22.1% |
| 过期证书 | 使用已过期但未被吊销的证书 | 18.3% |
| 测试证书 | 滥用开发测试阶段的证书 | 15.7% |
| 合法滥用 | 开发者自愿签名恶意软件 | 16.5% |
2.2 证书盗窃的技术路径
证书盗窃是最常见的滥用方式。攻击者通过多种途径获取证书私钥：
供应链入侵是最具破坏性的方式。2022年3月，显卡制造商NVIDIA披露其系统遭到入侵，攻击者窃取了1TB数据，其中包括用于签名驱动程序的代码签名证书。这些被盗证书随后被用于签名恶意软件，使得这些恶意软件能够在Windows系统上加载内核驱动。
针对性钓鱼攻击则是更常见的手段。攻击者伪装成证书颁发机构或IT部门，向开发者发送钓鱼邮件，诱导其导出并提交证书文件。由于许多开发者对证书安全缺乏意识，这类攻击的成功率相当高。
恶意软件感染也是一个重要途径。某些信息窃取类恶意软件专门扫描受感染系统上的证书存储，寻找.pfx、.p12等证书文件并上传到攻击者的服务器。
graph LR
A[攻击者目标: 获取签名证书] --> B[供应链入侵]
A --> C[钓鱼攻击]
A --> D[恶意软件感染]
A --> E[购买被盗证书]
B --> F[入侵开发者网络]
F --> G[窃取证书文件]
C --> H[伪造CA邮件]
H --> I[诱导开发者导出证书]
D --> J[扫描证书存储]
J --> K[上传证书文件]
E --> L[暗市市场]
L --> M[购买已泄露证书]
G --> N[签名恶意软件]
I --> N
K --> N
M --> N
N --> O[绕过安全检测]
O --> P[部署恶意载荷]
2.3 知名案例分析
Flame恶意软件（2012年）：这是第一个被公开披露的使用被盗证书签名的高级持续性威胁（APT）。Flame使用了来自宏碁台湾子公司VeriSign的证书进行签名，使得其能够伪装成合法的Microsoft安全组件。这个案例揭示了代码签名体系的一个根本性弱点：即使证书被盗，在证书被正式吊销之前，签名仍然有效。
D-Link证书泄露（2018年）：网络设备制造商D-Link的一个代码签名证书在2018年被发现泄露在网上。这个证书被用于签名多个恶意软件家族。值得注意的是，这个证书的有效期到2023年，意味着在被发现泄露后，攻击者仍有数年时间可以滥用。
NVIDIA证书被盗（2022年）：勒索软件组织Lapsus$入侵NVIDIA后，泄露了两个代码签名证书。这些证书随后被多个恶意软件家族使用，包括用于签名内核模式驱动程序。Windows内核驱动签名要求WHQL认证或EV证书，这使得被盗证书的价值极高。
三、平台差异：各操作系统的验证策略
不同操作系统对代码签名的验证策略存在显著差异，这些差异直接影响攻击者利用签名证书的难度。
3.1 Windows的多层验证机制
Windows的代码签名验证是一个多层过程，涉及WinVerifyTrust API和多个信任提供者。验证流程大致如下：
sequenceDiagram
participant User as 用户/系统
participant API as WinVerifyTrust
participant TP as 信任提供者
participant CA as 证书颁发机构
participant TSA as 时间戳服务器
participant CRL as CRL/OCSP服务器
User->>API: 验证文件签名
API->>TP: 调用信任提供者
TP->>TP: 提取证书链
TP->>CA: 验证证书链有效性
TP->>TP: 计算文件摘要
TP->>TP: 验证签名值
TP->>TSA: 验证时间戳令牌
TP->>CRL: 检查证书吊销状态
alt 所有检查通过
TP->>API: 返回TRUST_E_SUCCES
API->>User: 文件可信
else 任一检查失败
TP->>API: 返回错误代码
API->>User: 文件不可信
end
Windows验证的一个关键特性是对SmartScreen信誉系统的依赖。即使一个文件有有效的签名，如果该证书缺乏足够的"信誉"（即历史上没有被大量用户下载过），SmartScreen仍然会警告用户。这个机制在一定程度上缓解了证书滥用问题——攻击者获取的新证书没有历史信誉，签名的恶意软件仍然会触发警告。
3.2 macOS的公证机制
Apple在macOS 10.15 Catalina中引入了公证（Notarization）机制，这是对传统代码签名的重大增强。开发者不仅需要签名其应用，还需要将应用提交给Apple进行安全扫描。只有通过扫描的应用才能获得"公证票据"（notarization ticket），这个票据需要嵌入到应用包中。
公证机制的关键创新在于它引入了一个中心化的安全审查层。即使攻击者获得了有效的代码签名证书，仍然需要通过Apple的安全扫描才能获得公证。而Apple的扫描系统会检测已知的恶意行为模式，大大提高了攻击者滥用证书的难度。
3.3 Android的多版本签名方案
Android平台对APK的签名方案经历了多次演进：
| 签名方案 | 版本 | 特点 | 安全性 |
|---|---|---|---|
| JAR签名 (v1) | Android 1.0 | 基于JAR的签名，签名META-INF目录 | 易被修改 |
| APK签名 v2 | Android 7.0 | 签名嵌入APK文件，覆盖整个文件 | 防止修改 |
| APK签名 v3 | Android 9.0 | 支持密钥轮转，包含密钥历史 | 支持证书更新 |
| APK签名 v4 | Android 11 | 增量更新支持，用于APEX | 支持流式验证 |
Android签名方案的一个独特之处在于它不依赖外部CA。开发者自己生成密钥对并签名APK，证书只需要保证一致性（同一应用的更新必须使用相同的签名密钥）。这种设计简化了流程，但也意味着无法通过CA验证开发者身份。
3.4 Linux的包签名实践
Linux发行版对软件包签名采取了不同的策略。主流发行版维护自己的密钥，所有官方仓库中的软件包都由发行版密钥签名。开发者不需要从商业CA获取证书，而是将软件提交给发行版维护者进行签名。
这种模式的优点是攻击者无法通过获取证书来签名恶意软件——他们需要入侵发行版的基础设施。缺点是它限制了软件分发的灵活性，开发者无法独立分发经过系统验证的软件。
四、信任的重建：现代解决方案的探索
面对证书滥用问题，安全社区正在探索多种解决方案，从技术层面到制度层面都有创新。
4.1 CA/Browser Forum的强制HSM要求
2023年6月，CA/Browser Forum通过了新的基线要求，强制所有代码签名证书必须使用硬件安全模块（HSM）存储私钥。这个要求的技术逻辑是：如果私钥永远不离开HSM，那么攻击者即使入侵开发者系统也无法窃取证书。
HSM的核心安全特性包括：
- 防篡改设计：物理攻击会触发密钥销毁
- 访问控制：私钥操作需要物理令牌或生物特征认证
- 审计日志：所有签名操作都被记录
- FIPS 140-2认证：满足政府级安全标准
HSM要求显著提高了证书盗窃的难度，但它也有局限性：它无法防止合法证书被恶意使用（开发者自愿签名恶意软件），也无法解决身份伪造问题。
4.2 证书透明度日志
Certificate Transparency（CT）最初是为TLS证书设计的，但其原则同样适用于代码签名。CT要求所有证书必须被记录在公开的、不可篡改的日志中，任何人都可以监控这些日志来发现可疑的证书颁发。
对于代码签名，CT的价值在于：
- 快速发现被盗证书：监控日志可以及时发现证书被用于签名可疑文件
- 审计证书颁发：可以检查CA是否遵循了验证要求
- 建立责任追溯：每个证书都有完整的颁发记录
目前，主要的浏览器厂商已经要求EV代码签名证书必须记录在CT日志中，普通代码签名证书的CT要求也在逐步推进。
4.3 Sigstore：无证书签名方案
Sigstore是一个革命性的开源项目，旨在简化代码签名并消除对传统PKI的依赖。它的核心创新是使用短暂证书和透明度日志替代长期有效的证书。
Sigstore的工作流程如下：
sequenceDiagram
participant Dev as 开发者
participant Fulcio as Fulcio CA
participant OIDC as OIDC提供者
participant Rekor as Rekor日志
participant Verifier as 验证者
Dev->>OIDC: 登录(GitHub/Google等)
OIDC->>Dev: 返回身份令牌
Dev->>Fulcio: 请求签名证书
Note over Dev,Fulcio: 附带身份令牌和公钥
Fulcio->>Fulcio: 验证身份令牌
Fulcio->>Dev: 返回短暂证书
Dev->>Dev: 用私钥签名工件
Dev->>Rekor: 提交签名和证书
Rekor->>Rekor: 记录到透明度日志
Rekor->>Dev: 返回包含证明
Note over Verifier: 验证阶段
Verifier->>Rekor: 查询日志条目
Verifier->>Fulcio: 验证证书链
Verifier->>Verifier: 验证签名
alt 验证通过
Verifier->>Verifier: 确认工件可信
else 验证失败
Verifier->>Verifier: 拒绝工件
end
Sigstore的关键优势在于：
- 短暂证书：证书有效期通常只有几分钟到几小时，即使被窃取也几乎没有利用价值
- 身份绑定：证书与开发者的OIDC身份（如GitHub账户）绑定，而非与公司实体绑定
- 透明度日志：所有签名操作都被记录在Rekor日志中，支持审计和监控
- 免费使用：开发者无需购买商业证书
4.4 SLSA框架与供应链安全
Supply-chain Levels for Software Artifacts（SLSA）是一个安全框架，旨在为软件供应链提供可验证的安全保证。SLSA定义了从Level 1到Level 4的四个安全级别：
| 级别 | 描述 | 要求 |
|---|---|---|
| L1 | 文档化构建 | 构建过程有记录 |
| L2 | 托管构建 | 在隔离环境中构建 |
| L3 | 硬化构建 | 构建环境有强隔离 |
| L4 | 可重现构建 | 两人独立验证可重现 |
SLSA与代码签名的关系在于，它通过确保构建过程的完整性来增强签名的可信度。如果一个工件满足SLSA L3要求并通过Sigstore签名，那么验证者可以确信：该工件确实由声称的开发者在隔离环境中构建，且构建过程没有被篡改。
五、工程实践：如何正确使用代码签名
对于软件开发者而言，正确使用代码签名需要理解其安全边界并采取相应的保护措施。
5.1 证书保护的最佳实践
首先，私钥保护是重中之重。如果使用传统证书，应该：
- 将证书存储在HSM或智能卡中，永远不要导出私钥
- 对签名操作实施多因素认证
- 限制能够访问签名环境的人员
- 建立签名操作的审计日志
其次，应该考虑迁移到Sigstore等现代签名方案。Sigstore的短暂证书模型消除了证书盗窃的风险，同时其透明度日志提供了额外的安全保障。
5.2 验证签名时的注意事项
对于验证代码签名的系统，需要注意以下几点：
不要只验证签名有效性。一个有效的签名只证明文件未被篡改，不证明文件是安全的。应该结合其他信号进行判断：
- 证书的颁发时间和历史信誉
- 签名者身份的验证
- 文件来源的可信度
- 静态和动态安全扫描结果
正确处理时间戳。时间戳令牌可以证明签名是在证书有效期内创建的，但它不能证明文件本身是安全的。即使时间戳有效，如果证书后来因安全原因被吊销，仍然应该进一步调查。
实施证书白名单机制。对于关键系统，可以维护一个允许的证书白名单，只有白名单中的证书签名的文件才能执行。这虽然增加了管理负担，但可以显著降低风险。
5.3 双重签名与迁移策略
Windows支持对同一文件进行多次签名（双重签名），这对于证书迁移非常有用。例如，当从SHA-1迁移到SHA-256签名算法时，可以同时添加两种签名，确保新旧系统都能验证：
SignTool sign /fd SHA256 /sha1 <SHA1证书指纹> /as <文件>
SignTool sign /fd SHA256 /sha1 <SHA256证书指纹> <文件>
/as参数表示添加附加签名而非替换现有签名。双重签名的另一个用途是同时使用EV证书和普通证书签名，以获得更强的安全保证同时保持向后兼容。
六、未来展望：代码签名的演进方向
代码签名技术正在经历深刻的变革，几个趋势值得关注。
6.1 零信任架构中的代码签名
传统的代码签名假设存在一个可信的"根"——根CA。但在零信任架构中，信任需要被持续验证，而不是一次性授予。这意味着代码签名需要与其他身份和访问控制机制更紧密地集成：
- 将签名身份与开发者的企业身份绑定
- 实施持续监控，在证书被滥用时快速响应
- 支持动态吊销，而不仅仅依赖CRL和OCSP
6.2 机器学习增强的异常检测
现代安全系统正在使用机器学习来检测证书滥用：
- 分析签名行为模式，发现异常的签名活动
- 将签名文件与已知恶意软件家族进行关联
- 监控证书的使用地理位置和频率
这些技术可以补充传统的签名验证，帮助发现那些使用有效但被盗证书签名的恶意软件。
6.3 去中心化身份的潜力
去中心化身份（DID）技术为代码签名提供了另一种可能性。开发者可以拥有一个自己控制的去中心化身份，而非依赖CA颁发的证书。签名验证将检查身份的控制权证明，而非证书链。这种模式可以消除对中心化CA的依赖，但也带来了新的技术挑战。
graph TB
subgraph 传统PKI模式
A1[根CA] --> A2[中间CA]
A2 --> A3[开发者证书]
A3 --> A4[签名文件]
end
subgraph Sigstore模式
B1[OIDC身份<br/>GitHub/Google] --> B2[Fulcio CA]
B2 --> B3[短暂证书<br/>有效期: 分钟]
B3 --> B4[签名文件]
B4 --> B5[Rekor日志<br/>透明度记录]
end
subgraph 去中心化身份模式
C1[DID标识符<br/>区块链注册] --> C2[开发者控制<br/>私钥]
C2 --> C3[签名文件]
C3 --> C4[智能合约验证<br/>无需中心CA]
end
A4 --> D[验证者]
B5 --> D
C4 --> D
结语
代码签名技术诞生于1995年，三十年来它一直是软件供应链安全的基石。然而，随着超过133万个签名恶意软件样本的出现，这个基石正在被侵蚀。
技术社区正在通过多种方式应对这一挑战：强制HSM提高了证书盗窃的难度，CT日志提供了证书滥用的可见性，Sigstore用短暂证书模型消除了长期证书的风险，SLSA框架从更宏观的层面保障软件供应链的完整性。
代码签名的本质是建立信任，而信任是安全领域永恒的主题。在可预见的未来，这场围绕代码签名的攻防博弈仍将继续——攻击者在寻找新的滥用方式，防御者在构建新的信任机制。对于开发者而言，理解这些技术原理并正确使用代码签名，是保护用户和软件供应链安全的基本责任。
参考文献
-
Microsoft Learn. “WinVerifyTrust function (wintrust.h) - Win32 apps.” https://learn.microsoft.com/en-us/windows/win32/api/wintrust/nf-wintrust-winverifytrust
-
NDSS 2022. “Understanding the Status and Strategies of the Code Signing Abuse.” https://www.ndss-symposium.org/wp-content/uploads/2026-f2857-paper.pdf
-
CA/Browser Forum. “Baseline Requirements for the Issuance and Management of Publicly-Trusted Code Signing Certificates.” https://cabforum.org/working-groups/code-signing/
-
RFC 3161. “Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP).” https://datatracker.ietf.org/doc/html/rfc3161
-
SpecterOps. “Subverting Trust in Windows.” https://specterops.io/wp-content/uploads/sites/3/2022/06/SpecterOps_Subverting_Trust_in_Windows.pdf
-
Trail of Bits. “Verifying Windows binaries, without Windows.” https://blog.trailofbits.com/2020/05/27/verifying-windows-binaries-without-windows/
-
Sigstore. “Software Supply Chain Security.” https://www.sigstore.dev/
-
SLSA. “Supply-chain Levels for Software Artifacts.” https://slsa.dev/
-
NVD. “CVE-2013-3900 Detail.” https://nvd.nist.gov/vuln/detail/CVE-2013-3900
-
Google Security Blog. “Software Supply Chain Security.” https://security.googleblog.com/
-
Krebs on Security. “NVIDIA Code-Signing Certificates Stolen.” https://krebsonsecurity.com/2022/03/nvidia-code-signing-certificates-stolen/
-
F-Secure. “Flame Malware Analysis.” https://www.f-secure.com/
-
Apple Developer Documentation. “Notarizing macOS software before distribution.” https://developer.apple.com/documentation/security/notarizing_macos_software_before_distribution
-
Android Developers. “APK Signature Scheme v4.” https://source.android.com/docs/security/features/apksigning/v4
-
Certificate Transparency. “What is Certificate Transparency?” https://certificate.transparency.dev/
-
NIST. “FIPS 140-2 Security Requirements for Cryptographic Modules.” https://csrc.nist.gov/publications/detail/fips/140/2/final
-
Krebs on Security. “D-Link Code Signing Certificate Leaked.” https://krebsonsecurity.com/2018/04/d-link-code-signing-certificate-leaked-online/
-
Microsoft Security Blog. “SmartScreen reputation-based protection.” https://www.microsoft.com/en-us/wdsi/defender
-
Google Open Source Blog. “Introducing Sigstore.” https://opensource.googleblog.com/2021/08/introducing-sigstore.html
-
The Update Framework (TUF). “Securing Software Updates.” https://theupdateframework.io/
-
in-toto. “A framework for cryptologically ensuring the integrity of software supply chains.” https://in-toto.io/
-
CycloneDX. “OWASP CycloneDX Software Bill of Materials Standard.” https://cyclonedx.org/
-
SPDX. “Software Package Data Exchange (SPDX) specification.” https://spdx.dev/
-
OpenSSF. “Open Source Security Foundation.” https://openssf.org/
-
GCP Blog. “Binary Authorization for GKE.” https://cloud.google.com/binary-authorization
-
AWS. “Code Signing for AWS Lambda.” https://docs.aws.amazon.com/lambda/latest/dg/configuration-codesigning.html
-
GitHub Blog. “Securing software supply chains.” https://github.blog/category/security/
-
Linux Foundation. “The Linux Foundation Security Initiatives.” https://www.linuxfoundation.org/security/
-
Mozilla. “Mozilla Root Store Policy.” https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/
-
Chromium. “Chromium Certificate Transparency Policy.” https://www.chromium.org/Home/chromium-security/certificate-transparency/
-
Cloudflare. “Certificate Transparency and the Battle for Trusted HTTPS.” https://blog.cloudflare.com/certificate-transparency-and-the-battle-for-trusted-https/
-
DigiCert. “Code Signing Best Practices.” https://www.digicert.com/signing/code-signing-best-practices
-
Sectigo. “EV Code Signing Requirements.” https://www.sectigo.com/ev-code-signing-certificates
-
GlobalSign. “Code Signing Certificate Guide.” https://www.globalsign.com/en/code-signing-certificate
-
Venafi. “Machine Identity Management.” https://www.venafi.com/learning-center/what-is-machine-identity-management
-
Keyfactor. “Code Signing Security.” https://www.keyfactor.com/resources/code-signing-security/
-
Thales. “Hardware Security Modules for Code Signing.” https://cpl.thalesgroup.com/encryption/hardware-security-modules
-
Entrust. “Code Signing Security Considerations.” https://www.entrust.com/digital-security/certificate-solutions/products/digital-certificates/code-signing
-
RSA Conference. “Software Supply Chain Security Talks.” https://www.rsaconference.com/
-
USENIX Security. “Software Supply Chain Security Research Papers.” https://www.usenix.org/conference/byname/108