包管理器开发工具CLI【免费下载链接】pnpmFast, disk space efficient package manager项目地址https://gitcode.com/gh_mirrors/pn/pnpm点击查看免费下载pnpm/deps.compliance.audit是 pnpm 11 中负责「审计 lockfile」的专用包Audit a lockfile。它以一份解析好的 pnpm-lock.yaml 对象为输入将其扁平化为符合 npm bulk advisories 端点格式的请求再根据 registry 返回的漏洞数据在本地计算每条漏洞的依赖安装路径最终产出一份结构化的审计报告。读完本文你将掌握该包的安装与核心 API 用法、AuditReport的完整数据结构、lockfile 到审计请求的转换原理以及 pnpmaudit命令含--fix、--audit-level、--ignore等选项背后的底层实现机制。包定位审计入口与在 pnpm 生态中的角色该包位于 pnpm11/deps/compliance/audit 目录npm 包名为pnpm/deps.compliance.audit归属于 pnpm 的「依赖合规deps/compliance」子体系——该目录下还包含 license-resolver、license-scanner、sbom 以及承接 CLI 逻辑的 commands 等模块。它对外暴露的能力非常聚焦给定一个 lockfile产出一份与 npm audit 语义兼容的漏洞报告。该包自身不包含用户交互与命令行解析那是commands包audit子命令的职责而是提供一个可编程、可测试的审计内核。按照 README 的说明安装方式为pnpm add pnpm/deps.compliance.audit包本身以 ESM 形式发布type: module入口为lib/index.js需要 Node.js 22.13见 package.json并以 MIT 协议开源。核心 APIaudit()函数签名与选项主入口audit定义在 src/index.ts#L38-L95export async function audit ( lockfile: LockfileObject, getAuthHeader: GetAuthHeader, opts: { dispatcherOptions?: DispatcherOptions envLockfile?: EnvLockfile | null include?: { [dependenciesField in DependenciesField]: boolean } registry: string retry?: RetryTimeoutOptions timeout?: number } ): PromiseAuditReport参数含义如下参数类型说明lockfileLockfileObject已解析的锁文件对象packages、importers等通常由pnpm/lockfile.fs的readWantedLockfile读取得到getAuthHeaderGetAuthHeader一个按 registry URI 返回认证头如Bearer xxx的回调用于私有 registry 场景registrystring审计端点所在 registry默认官方源为https://registry.npmjs.orginclude{ dependencies, devDependencies, optionalDependencies }控制审计包含的依赖字段对应 CLI 的--prod/--dev/--no-optionalenvLockfileEnvLockfile \| null环境锁文件configDependencies、packageManagerDependencies 等可为空dispatcherOptions/retry/timeout网络相关透传给底层fetchWithDispatcher的代理、TLS、重试与超时配置一个最小可运行示例见 example.jsconst audit require(./lib).default const { readWantedLockfile } require(pnpm/lockfile.fs) readWantedLockfile(../.., {}) .then((lockfile) audit(lockfile, { registry: https://registry.npmjs.org })) .then((auditResult) console.log(JSON.stringify(auditResult, null, 2))) .catch(console.log.bind(console))审计主流程从 lockfile 到漏洞报告audit()的执行链路分为四个阶段见 src/index.ts#L50-L95依赖类型分析调用detectDepTypes(lockfile)判定每个包是否为 dev-only并调用collectOptionalOnlyDepPaths找出仅通过 optional 边可达的包请求构造lockfileToAuditRequest将 lockfile 扁平化为一个以包名为 key、版本列表为 value 的映射调用审计端点向${registry}-/npm/v1/security/advisories/bulk发起POST请求registry 末尾无/时自动补齐本地计算报告从响应中提取受影响包名集合用buildAuditPathIndex在本地重建「漏洞 → 安装路径」索引再合并出最终报告。其中请求头固定携带Content-Type: application/json若getAuthHeader返回了值则额外附加authorization头src/index.ts#L224-L234。阶段一把 lockfile 扁平化为 bulk 请求体lockfileToAuditRequestsrc/lockfileToAuditIndex.ts#L42-L140是整条链路的起点。它借助pnpm/lockfile.walker的lockfileWalkerGroupImporterSteps遍历每个 importer即工作区项目对每个(包名, 版本)组合调用内部registerOccurrence去重登记最终得到interface AuditIndexRequest { request: Recordstring, string[] // 例如 { foo: [1.0.0], bar: [1.0.0] } totalDependencies: number dependencies: number // 仅生产依赖 devDependencies: number optionalDependencies: number }测试 test/index.ts#L10-L31 验证了该行为一个根依赖foo1.0.0连同其传递依赖bar1.0.0会被展平为{ foo: [1.0.0], bar: [1.0.0] }。值得注意的工程细节计数器不重复扣减devOnly与optionalOnly并不互斥——一个包可以既是 dev 又是 optional因此dependencies计数被独立维护避免total - dev - optional造成双重扣减代码注释明确说明了这一点遍历采用显式栈而非递归深依赖链来自不可信的 lockfile递归会撑爆 JS 调用栈因此用stack帧结构实现前序遍历src/lockfileToAuditIndex.ts#L101-L123支持环境锁文件若传入envLockfile其configDependencies与packageManagerDependencies也会被纳入审计相关测试见 test/index.ts#L398-L457。阶段二请求 npm bulk advisories 端点请求地址固定为/-/npm/v1/security/advisories/bulk。实现中有三类响应处理src/index.ts#L70-L94200解析 JSON 并校验响应形状必须是「包名 → 告警数组」的对象然后进入报告组装404抛出AuditEndpointNotExistsError其错误码为ERR_PNPM_AUDIT_ENDPOINT_NOT_EXISTS并给出提示——这通常意味着你在使用私有 registry而该端点并未实现 audit 接口其他状态码或非法 JSON抛出PnpmError(AUDIT_BAD_RESPONSE, ...)错误码为ERR_PNPM_AUDIT_BAD_RESPONSE消息中会附上端点 URL 与响应片段最多 500 字符便于排查。对应的 mock 测试见 test/index.ts#L526-L612。阶段三把 bulk 响应组装为审计报告bulkResponseToAuditReportsrc/index.ts#L97-L130逐条处理每个受影响包的告警用satisfiesSafe内部为semver.satisfies开启includePrerelease与loose失败时返回false而非抛错判断 lockfile 中安装的版本是否命中vulnerable_versions区间只保留有实际受影响版本的告警——若 lockfile 中没有任何版本命中则该告警被整体跳过避免上报假阳性对 registry 返回的id必须为有限数值与severity必须在info/low/moderate/high/critical集合内做防御性校验防止脏数据污染报告每个命中告警在metadata.vulnerabilities对应级别上计数 1。报告数据结构AuditReport全解全部类型定义集中在 src/types.ts是理解整个模块的「数据字典」export interface AuditVulnerabilityCounts { info: number; low: number; moderate: number high: number; critical: number } export type AuditLevelString info | low | moderate | high | critical export type AuditLevelNumber 0 | 1 | 2 | 3 | 4 export interface AuditFinding { version: string paths: string[] // 例如 [.foobar]每个元素是一条安装路径 dev: boolean optional: boolean bundled: boolean } export interface AuditAdvisory { findings: AuditFinding[] id: number title: string module_name: string vulnerable_versions: string patched_versions?: string | null // 从 vulnerable_versions 推断null 表示推断出的区间无已发布版本满足 patched_versions_unpublished?: boolean severity: AuditLevelString cwe: string github_advisory_id: string url: string } export interface AuditReport { advisories: { [id: string]: AuditAdvisory } metadata: AuditMetadata // 含 vulnerabilities 计数与 dependencies/devDependencies/optionalDependencies/totalDependencies }patched_versions字段比较特殊它由inferPatchedVersions从vulnerable_versions语法级推断而来src/index.ts#L191-L205区间形如2.0.0或以X.Y.Z结尾时推断为2.0.0区间形如2.0.0时用semver.inc(..., patch)推得2.0.1无法识别上界时返回undefined——调用方不得将其误解为「没有修复版本」。此外github_advisory_id由告警url中的GHSA-xxxx-yyyy-zzzz提取并经normalizeGhsaId规范化前缀统一为大写、后缀统一为小写如GHSA-cph5-m8f7-6c5x这样基于 GHSA ID 的忽略列表比较就不会受大小写写法影响src/index.ts#L207-L222。路径索引为每个漏洞重建全部安装路径报告里最有价值的部分是AuditFinding.paths——它回答「这个有漏洞的包是从哪条依赖链装进来的」。这一能力由buildAuditPathIndexsrc/lockfileToAuditIndex.ts#L142-L260实现其核心思路不做全局 depPath 去重pnpm/lockfile.walker内部按 depPath 去重而路径索引要求为共享的传递依赖例如被 50 个父包同时依赖的lodash每条父链各记一条路径因此这里实现了独立的 DFS 遍历路径以abc形式输出importer 路径段工作区项目 id中的/会被替换为__如packages/foo变为packages__foo对应测试见 test/index.ts#L380-L396可达性分析用 Tarjan SCC 算法为了剪枝「可达范围内没有任何未饱和漏洞」的子树先对每个节点计算其可达漏洞集合。由于依赖图中存在环createReachableVulnerabilitiesGetter用迭代式 Tarjan 强连通分量算法让同一环共享一个集合将复杂度从二次降为线性测试验证了环规模翻倍时读取次数增长远小于 4 倍见 test/index.ts#L311-L353单条路径记录上限 100 条常量MAX_PATHS_PER_FINDING 100防止钻石型依赖产生数万条等价路径。CLI 端只展示前几条并提示用户用pnpm why深入排查因此限制是合理的取舍对应测试验证了 150 个 importer 时只记录 100 条且不再多读快照test/index.ts#L122-L147对极深依赖链免疫测试构造了 60,000 层的单链远超 JS 调用栈上限迭代实现依然能完整输出漏洞路径test/index.ts#L355-L378。路径索引还会顺带完成 dev/optional 分类一个(包名, 版本)只要存在一条非 dev 路径dev标志即被清除只要存在一条非 optional 路径optional标志即被清除。关于「仅通过 optional 边可达」的分类collectOptionalOnlyDepPathssrc/lockfileToAuditIndex.ts#L487-L513用集合差实现(带 optional 可达集) − (不带 optional 可达集)这样嵌套在必装链内部的 optional 依赖也能被正确识别。安全与健壮性设计把 lockfile 当作不可信输入这个模块的源码大量体现了「lockfile 是来自不可信环境的输入」这一防御前提null-prototype 对象所有以包名为 key 的Recordrequest、paths、versionStatesByName等均用Object.create(null)创建防止恶意包名如__proto__污染原型链显式栈代替递归lockfileToAuditRequest的遍历、walkForPaths的 DFS、Tarjan 的 SCC 全部使用显式栈帧避免深链或大环导致RangeError: Maximum call stack size exceeded避免展开超大数组appendNamedDepPaths用循环push而非push(...mapped)因为把超大依赖列表展开进函数参数会触发引擎的参数数量上限src/lockfileToAuditIndex.ts#L469-L474响应体形状校验isBulkResponseShape要求每个 value 都是合法的告警数组任何 null、标量或缺失vulnerable_versions的条目都会导致整包错误被拒绝漏洞可达性缺失即报错createReachableVulnerabilitiesGetter在查询时若发现可达集未计算会直接抛错避免静默漏报真实漏洞src/lockfileToAuditIndex.ts#L393-L404。与 pnpm CLI 的衔接pnpm audit背后的调用链在 CLI 侧commands/src/audit/audit.ts 负责参数解析与交互。它通过loadAuditContext读取 lockfile 与 env lockfile把--dev/--prod/--no-optional映射为include把代理、TLS、重试等网络配置映射为dispatcherOptions然后调用本包的audit()。该命令支持的选项与底层参数对应关系如下audit.ts#L97-L163CLI 选项作用底层对应--audit-level severity只显示达到该级别及以上的告警默认low报告后按AuditLevelNumber过滤info:0 … critical:4-D, --dev只审计 devDependenciesinclude.devDependencies等-P, --prod只审计 dependencies 与 optionalDependenciesinclude--no-optional不审计 optionalDependenciesinclude.optionalDependencies false--json以 JSON 输出报告直接序列化AuditReport--ignore GHSA-id按 GitHub 公告 ID 忽略漏洞依赖normalizeGhsaId做大小写无关比较--ignore-unfixable忽略所有无修复方案的漏洞依赖patched_versions推断结果--ignore-registry-errorsregistry 报错时以退出码 0 结束适合 CI捕获audit()抛出的PnpmError-i, --interactive交互式选择要修复的漏洞基于报告 findings 渲染表格--fix [method]修复漏洞method 为override默认或update基于patched_versions与 findings其中--fix override会把非易受攻击版本写进package.json的overrides--fix update则尝试升级 lockfile 中受影响包的版本——这两条路径都会消费本模块产出的AuditAdvisory.patched_versions与AuditFinding数据。报告中patched_versions是语法推断结果CLI 还会在展示与修复前通过 packument 发布时间校验「推断出的修复区间是否真有已发布版本满足」必要时置patched_versions_unpublished标志audit.ts#L268-L273。总结pnpm/deps.compliance.audit把「审计 lockfile」这一看似单一的动作拆解为请求构造、端点交互、路径重建、报告组装四个可独立测试的阶段并在每个阶段都针对不可信 lockfile 做了防御性设计null-prototype 防原型污染、显式栈防调用栈溢出、Tarjan SCC 保证环上的线性可达性分析、单条路径 100 条上限防止内存膨胀。如果你想深入阅读其实现建议按以下顺序先看 src/types.ts 建立数据模型再读 src/lockfileToAuditIndex.ts 理解两条核心算法请求扁平化与路径索引最后对照 test/index.ts 的 20 余个测试用例覆盖环、共享依赖、深链、可选依赖分类、错误响应等边界场景验证自己的理解。赞分享包管理器开发工具CLI【免费下载链接】pnpmFast, disk space efficient package manager项目地址https://gitcode.com/gh_mirrors/pn/pnpm点击查看免费下载相关推荐pnpm 依赖签名验证完全指南深入解析 pnpm/deps.security.signatures 的 ECDSA 签名审计机制pnpm 依赖签名验证完全指南深入解析 pnpm/deps.security.signatures 的 ECDSA 签名审计机制 导读 本文以 pnpm 仓包管理器开发工具CLI前端依赖漏洞审计实战用 pnpm audit、Dependabot 与 CI 门禁守住供应链安全前端依赖漏洞审计实战用 pnpm audit、Dependabot 与 CI 门禁守住供应链安全 本指南以 Front End Checklist 仓库中的安Monad安全审计智能合约执行引擎漏洞防护Monad安全审计智能合约执行引擎漏洞防护 智能合约安全现状与挑战 智能合约执行引擎作为区块链系统的核心组件其安全性直接关系到数亿资产的安全。近年来因执行上一篇跨平台图形渲染的基石GLFW上下文创建全解析WGL/GLX/EGL/NSGL对比下一篇earthworm/schema创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考