--no-plugins 是阻断后门的第一道闸门，因它强制跳过插件加载全流程：不读 plugins 字段、不扫描 vendor 插件、不调用 activate()；必须紧接命令后使用，如 composer install --no-plugins。
为什么 --no-plugins 是阻断后门的第一道闸门
不加 --no-plugins，Composer 就可能在 install 或 update 过程中加载并执行任意插件代码——哪怕你没主动 require 它，只要 vendor 目录里存在兼容的插件类，它就可能被触发。真实入侵案例中，攻击者通过污染私有仓库或 fork 的包注入带钩子的插件，一旦 CI 脚本用 root 执行 composer install，后门立即落地。
关键点在于：--no-plugins 不是“建议开启”，而是强制跳过整个插件加载流程：不读 composer.json 里的 plugins 字段，不扫描 vendor/ 下的插件包，也不调用任何 activate() 方法。它比环境变量更直接、更不可绕过。
- 必须紧接命令之后：
composer install --no-plugins✅；composer --no-plugins install❌（等价于composer --help） - 旧版 Composer（--no-plugins 仍有效，但需配合
COMPOSER_NO_PLUGINS=1防止脚本绕过 - CI 脚本里若封装了
bin/composer，要确认该 wrapper 没自动加--plugins或其他 flag
如何验证插件是否真被禁用，而非静默失败
终端没报错 ≠ 插件没运行。很多恶意插件会捕获异常、跳过日志、甚至只在特定条件（如 PHP 版本、环境变量）下激活。真正可靠的验证方式是查信号点：
- 执行
composer diagnose --verbose，末尾看是否有Plugin xxx is not compatible或Using version x.y for xxx—— 前者说明插件被识别但拒绝，后者说明已加载 - 检查
vendor/composer/autoload_plugins.php是否为空文件或根本不存在；若存在且含非空数组，说明插件已被注册 - 部署日志里搜索
Loading plugin、Activating plugin、Running post-install-cmd—— 出现任一即表示插件逻辑已介入 - 临时加
SF_SKIP_SIGNAL_HANDLER=1再跑一次，可排除因pcntl_signal缺失导致的假性“禁用”
禁止插件 ≠ 禁止所有扩展行为，scripts 和 platform 检查仍需单独关
--no-plugins 只停第三方插件，但 composer.json 中定义的 scripts（如 post-install-cmd）、PHP 平台约束检查、甚至某些包自带的 bin/ 脚本，依然会执行。它们同样可能成为后门载体。
- 加
--no-scripts才能跳过所有scripts钩子；生产部署必须显式带上，不能依赖--no-dev（它只删 dev 依赖，不关脚本） - PHP 版本变更后，
composer.lock中的platform字段可能失效，触发隐式重新解析 → 加--ignore-platform-reqs是自毁式操作，应改用composer config platform.php "8.1.0"显式锁定 - 某些包的
bin/脚本（如phpunit、phpcs）本身可执行，但若权限为 777 或属主为 root，攻击者可通过 Webshell 直接调用，必须后续用chmod 755 vendor/bin/*修复
权限加固必须同步做，否则禁用插件毫无意义
即使插件全禁、scripts 全关，如果 vendor/ 目录权限是 777 或属主为 root，攻击者拿到任意代码执行权限后，仍可直接篡改 vendor/autoload.php、替换 vendor/symfony/console/Command.php 等核心文件，绕过所有 Composer 层面的防护。
- 部署前设
umask 0022，确保新建文件默认为 644、目录为 755；Dockerfile 中写成RUN umask 0022 && composer install --no-dev --no-plugins --no-scripts - 安装后立刻执行：
find vendor/ -type f -exec chmod 644 {} \;和find vendor/ -type d -exec chmod 755 {} \; - 特别处理
vendor/bin/：chmod 755 vendor/bin/*（可执行但不可写），再确认vendor/composer/installed.json权限是 644 而非 666 - Web 服务器用户（如
www-data）不应直接拥有vendor/写权限；推荐做法是将它加入部署用户组，再用chmod -R g+rX vendor/，而不是放宽到 775
最常被忽略的是 PHP 版本变更和 composer.lock 文件未提交这两件事——它们会让所有参数和配置瞬间失效，退化为隐式 update。别只盯着插件，先确保 lock 文件存在、语义一致、且平台约束匹配当前运行环境。
