package-security-check

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Package Security Check

包安全检查

Workflow

工作流程

Treat this as a base JS supply-chain check first. Do not force the result around one CVE, vendor, package family, or incident.
Before running installs, package-manager mutation commands, or file edits, perform only read-only inspection and present a traffic-light issue analysis:
- 🔴 Blocker: compromise signal, unsafe install path, secret exposure, or policy that allows unreviewed code execution.
- 🟡 Risk: hardening gap, stale package-manager major, broad spec, lifecycle script needing review, or CI weakness.
- 🟢 OK: verified control or no finding.
After the traffic-light analysis, ask for approval before changing files or executing package-manager operations that can install, update, publish, or rewrite lockfiles.
From this skill directory, run the baseline scanner against the repo or workspace root:

bash

python3 scripts/check_js_supply_chain.py --root <repo-or-workspace-root>

Use

--strict

when the check should fail on hardening gaps. Use

--json

when another tool needs machine-readable output. Use

--include-installed

only when

node_modules

exists and installed package lifecycle metadata matters.

For a specific active incident, add one or more IOC profiles:

bash

python3 scripts/check_js_supply_chain.py \
  --root <repo-or-workspace-root> \
  --ioc data/iocs/npm-supply-chain-2026-05.json \
  --since 2026-05-11T19:20:00Z

Refresh incident facts from current advisory sources before relying on a profile. IOC profiles are detection data, not the base policy.

Inspect the report in this order:

```
package_manager_policy
```

repo_config_findings

and

effective_config_findings

```
risky_direct_specs
```

package_lifecycle_scripts

, then

installed_lifecycle_scripts

when requested

```
ci_install_findings
```
, including GitHub Actions privilege/cache warnings
```
ioc_hits
```
```
recent_package_manager_files
```

If any IOC hits appear, stop normal package work. Do not run installs or lifecycle scripts. Report exact files/packages and recommend isolation, credential rotation, and reinstall from a known-good lockfile.
If no compromise is visible but policy is weak and the user approves changes, patch toward the canonical pnpm 11 policy. Keep one package manager, one lockfile, and one repo-local policy source.

首先将其视为基础JS供应链检查，不要围绕单一CVE、供应商、包家族或事件强制判定结果。
在运行安装、包管理器变更命令或文件编辑前，仅执行只读检查并呈现红绿灯式问题分析：
- 🔴 阻塞项：存在入侵信号、不安全安装路径、密钥泄露或允许未审核代码执行的策略。
- 🟡 风险项：加固缺口、包管理器主版本过时、宽泛版本规范、需审核的生命周期脚本或CI薄弱点。
- 🟢 正常：已验证的控制措施或未发现问题。
完成红绿灯分析后，在执行可安装、更新、发布或重写锁文件的包管理器操作或修改文件前，需请求批准。
从该技能目录出发，针对仓库或工作区根目录运行基线扫描器：

bash

python3 scripts/check_js_supply_chain.py --root <repo-or-workspace-root>

当检查需在加固缺口处失败时使用

--strict

参数。当其他工具需要机器可读输出时使用

--json

参数。仅当

node_modules

存在且已安装包的生命周期元数据重要时，使用

--include-installed

参数。

针对特定活跃事件，添加一个或多个IOC配置文件：

bash

python3 scripts/check_js_supply_chain.py \
  --root <repo-or-workspace-root> \
  --ioc data/iocs/npm-supply-chain-2026-05.json \
  --since 2026-05-11T19:20:00Z

在依赖配置文件前，先从当前公告源刷新事件事实。IOC配置文件是检测数据，而非基础策略。

按以下顺序检查报告：

```
package_manager_policy
```

repo_config_findings

和

effective_config_findings

```
risky_direct_specs
```

package_lifecycle_scripts

，当请求时再查看

installed_lifecycle_scripts

```
ci_install_findings
```
，包括GitHub Actions权限/缓存警告
```
ioc_hits
```
```
recent_package_manager_files
```

若出现任何IOC命中，立即停止正常包操作。不要运行安装或生命周期脚本。上报具体文件/包，并建议隔离、凭证轮换以及从可信锁文件重新安装。
若未发现入侵迹象但策略薄弱且用户批准修改，则向标准pnpm 11策略修补。保持单一包管理器、单一锁文件和单一仓库本地策略源。

Canonical Policy

标准策略

Use pnpm 11 or newer as the single package manager because it has the best current pnpm security model: release-age gating, lifecycle-script approval, exotic-subdependency blocking, and trust policy controls.

Verify the current pnpm release before writing

packageManager

bash

npm view pnpm dist-tags --json

Require pnpm 11 or newer. As of 2026-05-12, npm reports

latest

as pnpm

11.1.1

. Do not hardcode that value without rechecking. If the repo's Node runtime cannot run pnpm 11, report it as a compatibility blocker instead of silently falling back to pnpm 10.

Use

devEngines.packageManager

to declare the required major:

json

{
  "devEngines": {
    "packageManager": {
      "name": "pnpm",
      "version": ">=11.0.0",
      "onFail": "download"
    }
  }
}

Also pin the verified current stable version in

packageManager

for reproducibility:

json

{
  "packageManager": "pnpm@11.1.1"
}

Treat pnpm 10 or older as

legacy-pnpm-major

unless the user explicitly approves a temporary exception.

使用pnpm 11或更新版本作为单一包管理器，因为它具备当前最佳的pnpm安全模型：发布时长准入、生命周期脚本批准、阻止非常规子依赖以及信任策略控制。

在写入

packageManager

前，验证当前pnpm版本：

bash

npm view pnpm dist-tags --json

要求使用pnpm 11或更新版本。截至2026-05-12，npm显示

latest

版本为pnpm

11.1.1

。未经重新检查不要硬编码该值。若仓库的Node运行时无法运行pnpm 11，需将其报告为兼容性阻塞项，而非静默回退到pnpm 10。

使用

devEngines.packageManager

声明所需主版本：

json

{
  "devEngines": {
    "packageManager": {
      "name": "pnpm",
      "version": ">=11.0.0",
      "onFail": "download"
    }
  }
}

同时在

packageManager

中固定已验证的当前稳定版本以保证可复现性：

json

{
  "packageManager": "pnpm@11.1.1"
}

除非用户明确批准临时例外，否则将pnpm 10或更旧版本视为

legacy-pnpm-major

。

Package Manager Posture

包管理器配置状态

```
pnpm >=11
```
: canonical baseline. Prefer this for new hardening work.
```
bun
```
: accepted only when the repo intentionally uses Bun and has equivalent local hardening.
```
npm
```
: fallback only. Recommend migration to pnpm 11 unless the repo has a clear documented reason to stay npm.
```
yarn
```
: not accepted baseline for this skill. Recommend pnpm 11 or hardened Bun.

Do not present npm as equivalent to pnpm 11. Bun can be accepted as a project-level choice, but still gets checked against Bun-specific hardening.

For npm fallback repos, require exact saves and reproducible CI while recommending pnpm migration:

ini

save-exact=true

Do not claim npm has a supported release-age gate unless verified in current npm docs and local

npm config ls -l

For Bun fallback repos, require repo-local

bunfig.toml

toml

[install]
minimumReleaseAge = 604800
exact = true
frozenLockfile = true
saveTextLockfile = true

Do not set

minimumReleaseAgeExcludes

without a reviewed, package-specific reason.

Add or update root

pnpm-workspace.yaml

yaml

minimumReleaseAge: 10080
minimumReleaseAgeStrict: true
minimumReleaseAgeIgnoreMissingTime: false
blockExoticSubdeps: true
trustPolicy: no-downgrade
trustPolicyIgnoreAfter: 43200
dangerouslyAllowAllBuilds: false
savePrefix: ""
allowBuilds: {}

Use 7 days (

) for normal repos. Use 3 days only when the repo has a real dependency freshness requirement. Do not set

minimumReleaseAgeExclude

trustPolicyExclude

without a reviewed, package-specific reason.

Allow dependency build scripts only after review:

yaml

allowBuilds:
  esbuild: true
  core-js: false

```
pnpm >=11
```
：标准基线。新加固工作优先选用。
```
bun
```
：仅当仓库有意使用Bun且具备等效本地加固措施时才接受。
```
npm
```
：仅作为备选方案。建议迁移到pnpm 11，除非仓库有明确记录的理由继续使用npm。
```
yarn
```
：本技能不接受作为基线。建议使用pnpm 11或加固后的Bun。

不要将npm等同于pnpm 11。Bun可作为项目级选择被接受，但仍需针对Bun特定的加固措施进行检查。

对于使用npm备选方案的仓库，要求精确保存和可复现CI，同时建议迁移到pnpm：

ini

save-exact=true

除非在当前npm文档和本地

npm config ls -l

中验证过，否则不要声称npm支持发布时长准入。

对于使用Bun备选方案的仓库，要求仓库本地存在

bunfig.toml

：

toml

[install]
minimumReleaseAge = 604800
exact = true
frozenLockfile = true
saveTextLockfile = true

未经针对特定包的审核理由，不要设置

minimumReleaseAgeExcludes

。

添加或更新根目录下的

pnpm-workspace.yaml

：

yaml

minimumReleaseAge: 10080
minimumReleaseAgeStrict: true
minimumReleaseAgeIgnoreMissingTime: false
blockExoticSubdeps: true
trustPolicy: no-downgrade
trustPolicyIgnoreAfter: 43200
dangerouslyAllowAllBuilds: false
savePrefix: ""
allowBuilds: {}

普通仓库使用7天（

）。仅当仓库有真实的依赖新鲜度需求时才使用3天。未经针对特定包的审核理由，不要设置

minimumReleaseAgeExclude

或

trustPolicyExclude

。

仅在审核后允许依赖构建脚本：

yaml

allowBuilds:
  esbuild: true
  core-js: false

CI Rules

CI规则

Require frozen pnpm installs:

bash

pnpm install --frozen-lockfile

Treat these as findings unless the repo has a written reason:

non-pnpm lockfiles in a pnpm repo

CI using

npm install

yarn install

, unfrozen

bun install

, or unfrozen

pnpm install

npm repos that do not use
```
npm ci
```
with a committed lockfile while migration is pending
Bun repos missing
```
bunfig.toml
```
release-age, exact, frozen-lockfile, or text-lockfile policy
```
pull_request_target
```
workflows; these are allowed only with a reviewed reason and must not checkout or run untrusted PR code
shared caches in publish/release pipelines, including GitHub Actions cache, Turborepo, and Nx cache
any path where PR-controlled cache content can feed a privileged publish/release workflow
lockfile rewrite during CI/deploy
```
latest
```
,
```
*
```
, broad ranges, Git/GitHub shorthands, HTTP tarballs, or external
```
file:
```
specs
dependency lifecycle scripts that are not explicitly approved
```
dangerouslyAllowAllBuilds: true
```
workflow use of
```
toJSON(secrets)
```
or publish credentials in broad build jobs

要求使用冻结的pnpm安装：

bash

pnpm install --frozen-lockfile

除非仓库有书面理由，否则以下情况视为问题：

pnpm仓库中存在非pnpm锁文件

CI使用

npm install

、

yarn install

、未冻结的

bun install

或未冻结的

pnpm install

迁移期间，npm仓库未配合提交的锁文件使用
```
npm ci
```
Bun仓库缺少
```
bunfig.toml
```
中的发布时长、精确版本、冻结锁文件或文本锁文件策略
```
pull_request_target
```
工作流；仅当有审核通过的理由时才允许，且不得检出或运行不可信PR代码
发布/发布流水线中的共享缓存，包括GitHub Actions缓存、Turborepo和Nx缓存
PR控制的缓存内容可进入特权发布/发布工作流的任何路径
CI/部署期间重写锁文件
使用
```
latest
```
、
```
*
```
、宽泛版本范围、Git/GitHub简写、HTTP tar包或外部
```
file:
```
规范
未明确批准的依赖生命周期脚本
```
dangerouslyAllowAllBuilds: true
```
工作流使用
```
toJSON(secrets)
```
或在宽泛构建任务中使用发布凭证

Script

脚本

scripts/check_js_supply_chain.py

performs deterministic local checks:

detects package-manager and lockfile policy
checks repo-local and effective pnpm hardening settings
reports npm fallback and Bun fallback hardening gaps
reports risky direct dependency specs
reports lifecycle scripts in workspace manifests and optionally installed packages
reports risky GitHub Actions install/publish/secret patterns
warns on
```
pull_request_target
```
and shared cache patterns that can become supply-chain escalation paths
reports package-manager file mtimes after
```
--since
```
applies optional IOC JSON profiles for incident-specific fingerprints, payload files, persistence paths, workflow markers, and known bad package versions

Keep incident profiles under

data/iocs/

. Do not add incident-specific constants to the scanner unless they are generic across npm supply-chain attacks.

scripts/check_js_supply_chain.py

执行确定性本地检查：

检测包管理器和锁文件策略
检查仓库本地和生效的pnpm加固设置
上报npm备选方案和Bun备选方案的加固缺口
上报高风险直接依赖规范
上报工作区清单中的生命周期脚本，以及可选的已安装包中的生命周期脚本
上报高风险GitHub Actions安装/发布/密钥模式
对可成为供应链升级路径的
```
pull_request_target
```
和共享缓存模式发出警告
上报
```
--since
```
参数指定时间后的包管理器文件修改时间
应用可选的IOC JSON配置文件，针对特定事件的指纹、 payload文件、持久化路径、工作流标记以及已知恶意包版本

将事件配置文件保存在

data/iocs/

下。除非是npm供应链攻击通用的内容，否则不要将事件特定常量添加到扫描器中。