0 Fork 0

Files

T

Shuery 45bbd66815 docs(report): 新增 PROJECT_REPORT.md 与 CI/CD 流水线记录

PROJECT_REPORT.md：论文式项目报告（摘要 / 目录 / 7 章 / 参考文献 / 致谢 / 附录 A），
4 张 Mermaid 图同样经真实浏览器渲染验证。所有数字都与证据文件逐个核对过。

.scratch/ci-cd/：本次流水线的全部证据与可重跑脚本
  * 阶段报告：依赖安全扫描 / 许可证合规 / 阶段 0 静态分析 / 阶段 3 测试与性能
  * 证据：分析器原始输出（修复前 84 条、修复后 80 条）、Pester 详细输出、
    性能基线 JSON、黑盒用例结果（阶段 1 的 11 例与阶段 2 回归的 12 例）
  * 可重跑：blackbox-tests.ps1 / blackbox-regression.ps1 / perf-baseline.ps1

两条边界必须写在明处，不能含糊：

  * **VM 内验证只取到修复前的快照**（Pester 183 项全绿）。随后会话审批策略改为 never，
    gsudo 提权被自动拒绝（退出码 999），而 Hyper-V 与 PowerShell Direct 都需要管理员，
    于是修复后的三套件在 VM 内**没有跑成**。报告里明确标注了范围，没有把"宿主跑绿了"
    说成"VM 也跑绿了"。
  * **性能基线是首次建立**，无历史可比，故无退化可判；指标只在同机同宿主下对比，
    跨机比数字没有意义。

另外记一笔：静态分析的口径是"仓库自己的门禁"。剩余 80 条全是风格类（0 Error），且逐条
有依据 —— 行长 160 是配置里写明的有意偏离，PSPlaceCloseBrace 等集中在测试夹具字符串内
（改了会改变断言语义）。严格模式的"零容忍"在这里与仓库自身约定相抵，选择尊重仓库约定
并在报告里登记，而不是制造一个横跨 12 个文件的纯排版大 diff。

2026-10-02 01:17:40 +08:00

4.2 KiB

Raw Blame History

依赖安全扫描报告（dependency-security-scanner）

项目：BakNRet（Windows 备份 / 恢复工具，PowerShell）
扫描时间：2026-09-28
扫描范围：仓库根目录及全部子目录（排除 .git）
工具：npm audit / pip-audit / govulncheck 等均不适用（见下）

1. 项目概况

项目	结论
语言	PowerShell（`.ps1` / `.psm1` / `.psd1`）
依赖管理文件	不存在 —— 全仓无 `package.json`、`package-lock.json`、`requirements.txt`、`go.mod`、`pom.xml`、`Cargo.toml` 等
运行时依赖	0 个模块。运行备份 / 恢复只需要 PowerShell 5.1 或 7.x + 7-Zip
开发期依赖	Pester 5.9.1、PSScriptAnalyzer 1.25.0 —— 装在 `.tools/`，已 gitignore，不随发布产物分发
外部可执行文件	`7z.exe`（7-Zip 26.03，经 scoop 安装）

Note

依赖扫描技能面向「有包管理器的项目」。本项目没有任何包管理器依赖，因此 npm audit / safety / govulncheck 一类工具无对象可扫。下面改为对本项目真实的供应链面 逐项核对，而不是输出一份空报告。

2. 供应链面核对

组件	来源	版本	是否随分发	风险
PowerShell 引擎	操作系统 / Microsoft	5.1.26100.9502、7.7.0-preview.5	否（宿主环境）	由宿主维护；预览版仅供本机验收使用
7-Zip	scoop（`C:\Programs\Scoop\apps\7zip\26.03`）	26.03	否（用户自备）	归档/解压的执行者，必须由用户保持更新
Pester	仓库内 `.tools/modules/Pester/5.9.1`	5.9.1	否（gitignore）	仅测试期使用，不接触用户数据
PSScriptAnalyzer	仓库内 `.tools/modules/PSScriptAnalyzer/1.25.0`	1.25.0	否（gitignore）	仅静态分析使用
其余第三方	无	—	—	—

已知 CVE：无可报。本项目的依赖面里没有任何「被本项目固定版本」的第三方库（Pester 与 PSScriptAnalyzer 是测试工具且不进分发，7-Zip 与 PowerShell 由用户环境提供）。若要追查这两个工具的 CVE，应查上游公告，而不是本仓库。

3. 与安全相关的项目事实（实跑核对）

检查项	结果
仓库是否跟踪任何密钥文件	✅ 否（`git ls-files` 中无 `.key` / `.pfx`）
`baknret.key` 是否被 gitignore	✅ 是（`.gitignore:18: *.key`）
工作区是否存在口令文件 `baknret.key`	⚠️ 是 —— 见风险 R-2
口令是否可能落进日志	✅ 已处理：打印前把 `-p` 参数换成占位符（`tests/BakNRet.Tests.ps1` 有专门断言）
日志中是否出现明文口令	✅ 无
`.tools/` 是否可能进分发产物	✅ 否（已 gitignore，且构建脚本只读 `BakNRet/` 与 `tools/`）

4. 风险清单

ID	严重程度	风险	证据	建议
R-1	一般	仓库没有 `LICENSE` 文件，许可证状态未声明	根目录无 `LICENSE*`	补一份许可证（见 `license_check_report`）
R-2	一般	工作区存在口令文件 `baknret.key`（未被跟踪，但确实在仓库目录里）	`Test-Path baknret.key` = True	本项目自己的 CHANGELOG 已把「口令文件的出厂默认值指向仓库内」定为待修问题，`BackupConfig.psd1` 的注释也推荐放到仓库外。建议移到 `%USERPROFILE%\.baknret.key` 并用 `-KeyFile` 指过去。本报告不读取、不记录其内容
R-3	建议	7-Zip 版本由用户环境决定，脚本不检查版本	`Find-BakNRet7zExecutable` 只找路径	可选：在启动时打印 `7z` 版本，便于排障
R-4	建议	口令经命令行传给 7z，本机进程列表可见	上游限制，README 已用 CAUTION 声明	无技术解法，保持文档披露即可

致命 / 严重漏洞：0 个。 流水线可继续。

5. 结论

未发现已知安全漏洞。本项目零运行时依赖，是当前最重要的一条供应链优势；唯一两条「一般」级风险都属于卫生问题（缺许可证、口令文件放在仓库目录里），不影响流水线继续执行。

4.2 KiB Raw Blame History Unescape Escape