Open Harmony 安全隐私从 code-linter.json5 看安全规则扫描实践 前言 安全隐私不是等应用上线前才补的功能也不是只靠权限弹窗就能解决。真正稳定的项目应该在编码阶段就引入安全检查让不安全的写法尽早暴露。当前项目中存在code-linter.json5这个文件配置了代码检查范围、忽略目录、推荐规则集以及一组安全相关规则。它非常适合写成安全隐私方向的工程实践文章。本文对应四大主题中的安全隐私。当前项目的 linter 配置范围 当前配置首先声明了检查文件{files: [**/*.ets] }这表示 linter 主要检查 ArkTS / ETS 文件。项目同时配置了忽略目录ignore: [ **/src/ohosTest/**/*, **/src/test/**/*, **/src/mock/**/*, **/node_modules/**/*, **/oh_modules/**/*, **/build/**/*, **/.preview/**/* ]这很合理。测试目录、mock 目录、依赖目录、构建产物目录不应该和业务源码完全采用同样检查范围。尤其是node_modules、oh_modules、build这类目录本身不是项目手写源码加入检查会带来大量噪音。推荐规则集 ⚙️当前项目启用了两个推荐规则集ruleSet: [plugin:performance/recommended,plugin:typescript-eslint/recommended]这说明项目不仅关注语法风格也关注性能和 TypeScript/ArkTS 相关基础规范。虽然当前项目页面代码还很简单但提前保留 lint 配置是有价值的。随着页面、组件和 service 层增多静态检查会成为质量保障的一部分。为什么要忽略测试和 mock 目录当前项目忽略了**/src/ohosTest/**/*, **/src/test/**/*, **/src/mock/**/*这不是说测试代码不重要而是不同目录的代码目标不同。业务源码需要更严格地控制性能、安全和可维护性测试代码更关注断言覆盖和验证逻辑mock 代码可能会保留一些模拟数据或临时结构。如果把所有目录都用同一套规则强行检查可能会产生很多无意义告警反而掩盖真正需要关注的问题。当前配置说明项目已经区分了源码、测试、mock、依赖和构建产物这种边界意识很重要。安全规则禁止不安全算法 ️当前配置中最值得关注的是安全规则security/no-unsafe-aes:error,security/no-unsafe-hash:error,security/no-unsafe-mac:warn,security/no-unsafe-dh:error,security/no-unsafe-dsa:error,security/no-unsafe-ecdsa:error,security/no-unsafe-rsa-encrypt:error,security/no-unsafe-rsa-sign:error,security/no-unsafe-rsa-key:error这些规则围绕密码算法和安全实现展开。它们的目标不是“让项目拥有加密能力”而是避免开发者使用不安全或不推荐的加密方式。这点非常关键当前项目并没有实现加密业务也没有用户隐私数据加密模块。所以文章不能写成“项目已经完成加密保护”。更准确的说法是当前项目通过 linter 配置为后续安全编码建立了静态检查基础。安全规则不是加密实现本身 这里要特别强调配置了security/no-unsafe-aes、security/no-unsafe-hash不等于项目已经实现了安全加密。它们更像是“红线规则”。当后续有人写到加密、摘要、签名相关代码时如果使用了不安全方式linter 可以提前提醒。所以这篇文章的重点不是展示加密算法而是展示项目如何在工程层面对潜在风险进行约束。对安全隐私来说这种前置约束非常实用。error 和 warn 的区别 配置中既有error也有warnsecurity/no-unsafe-mac:warn一般来说error表示严重问题通常应阻止继续通过检查。warn表示警告问题需要关注但不一定立即中断流程。当前项目对多数不安全算法规则使用error说明安全底线比较明确。对部分规则使用warn则保留了一定开发阶段弹性。适合在团队中怎样落地如果这是一个多人协作项目code-linter.json5可以作为统一编码底线。例如新增 ArkTS 代码前先确认是否在检查范围内。提交前执行代码检查。对error级别问题不允许带入主分支。对warn级别问题记录原因避免长期堆积。安全规则变更时在团队中同步说明。当前项目不是 git 仓库也没有 CI 流程所以这些只是后续工程化建议。但文章这样写可以让读者理解 linter 不只是本地配置文件而是可以演进成团队质量门禁。为什么这属于安全隐私安全隐私不只是运行时行为也包括开发过程中的约束。如果没有静态检查开发者可能在业务扩展时无意中使用不安全哈希、不安全 RSA 配置或过时算法。等到上线前再排查成本就会变高。通过code-linter.json5项目可以在编码阶段就发现风险。这属于“前置安全治理”。和当前 ArkTS 代码的关系 当前项目的业务代码主要集中在EntryAbility.ets、EntryBackupAbility.ets和Index.ets。这些文件都属于**/*.ets的检查范围。也就是说虽然当前页面代码很简单但 linter 配置并不是摆设。后续只要继续在entry/src/main/ets下新增 ArkTS 代码就会自然进入检查范围。例如后续新增工具函数、数据 service、页面组件如果写法存在性能或安全问题就有机会被规则提前发现。这也是为什么基础项目阶段就保留 linter 配置是有意义的。当前项目的真实边界 ✅需要明确当前项目已经有linter 配置文件。ETS 文件检查范围。性能推荐规则。TypeScript ESLint 推荐规则。多项安全规则。当前项目还没有复杂加密业务。用户隐私数据存储。权限申请流程。安全扫描报告自动化流程。因此文章要写“安全规则扫描实践入门”不要写成“完整安全隐私体系”。后续可以如何增强基于当前项目后续可以继续做在提交前执行 linter。在构建流程中加入代码检查。为新增 service 层设置更严格规则。对日志输出、权限使用、敏感字段处理增加规范。将安全检查结果纳入发版前检查清单。这些是后续工程化方向不是当前项目已经完成的能力。总结 这篇文章对应安全隐私方向。当前项目的code-linter.json5体现了一个重要思想安全要尽早进入开发流程。它通过文件范围、忽略目录、推荐规则集和安全规则给项目建立了基础质量门槛。即使当前项目还只是基础 ArkTS 应用也已经具备继续扩展安全编码规范的基础。对 OpenHarmony 项目来说安全隐私不是最后补一层而是从第一行代码、第一份配置就开始慢慢建立的。