政府软件合规并不只是通过发布前的最终审查，而是始于代码编写方式、依赖项管理以及决策记录。JetBrains博客发表的一篇文章以Qodana平台为背景，介绍了公共部门软件开发团队可以采用的五个实践领域，以降低不合规风险，同时指出不同国家的法律要求各不相同。
这一问题之所以更加重要，是因为政府系统处理大量个人数据和敏感数据。文章援引《IBM数据泄露成本报告2026》称，全球数据泄露的平均成本达到499万美元；文章还提到Ponemon Institute与Globalscape的报告，该报告估计，不合规的成本是合规成本的2.71倍。这些数字来自消息来源所依据的报告，并非JetBrains独立作出的估算。
1. 安全与数据保护
风险始于一些常见错误，例如将凭据存储在代码中、对输入和输出验证不足，或使用过时且薄弱的加密算法。这可能导致个人信息泄露，或违反ISO/IEC 27001等安全框架的控制要求，从而威胁认证和机构声誉。
规则因司法管辖区而异。欧盟成员国的公共机构须遵守GDPR，而英国中央政府机构须遵守包括UK GDPR、2018年《数据保护法》和国家审计署标准在内的要求。在美国，则有《联邦采购条例》、 《国防联邦采购条例补充规定》和FedRAMP等框架。
在实践中，文章建议从软件开发生命周期一开始就纳入隐私保护和防御措施，而不要将其推迟到测试阶段或部署前。文中提到的措施包括安全存储凭据、明确管理用户同意、在发布前进行渗透测试，以及持续开展自动化测试。此外，还应将外部依赖项视为活跃风险，而不是中性组件。
2. 合同、采购与开源依赖项
管理政府采购或供应商协议的软件可能引发合同问题，例如未达到服务级别或交付验收标准。此外，如果开发分支中存在秘密API密钥且缺少SAST扫描，也可能导致不符合交付条件的代码被通过。
开源依赖项还会增加另一层法律和技术问题，因为其许可证可能包含copyleft条款或商业使用限制，这可能与采购规则冲突，或引发知识产权争议。因此，文章建议在依赖项层面开展自动化许可证扫描，并在CI/CD中设置质量门禁，阻止不合规代码进入交付阶段。
3. 可审计证据与问责
在审计过程中，仅仅声称控制措施存在是不够的；没有证据支持的控制措施可能会被视为未经证明。文章认为，依赖人工批准以及质量保证团队之间不一致的结果，会提高审计失败的可能性，并增加技术债务风险。
建议的实践方案是建立数字记录，将测试、可追溯性和扫描结果与开发生命周期的各个阶段关联起来。这有助于生成自动化审计报告，并在审查美国联邦系统的NIST指南，或英国的ISO/IEC 27001要求和国家审计署标准等控制措施时提供客观证据。
4. 连续性与长期支持
政府系统中断可能导致公民基本服务停止，因此优先事项不应局限于会积累未来问题的快速修复。缺乏支持的开源组件可能阻碍补丁应用；当系统在不同承包商或团队之间移交时，如果漏洞和决策背景没有记录，迁移过程也会变得更加危险。
建议的做法包括跟踪依赖项的新旧程度，使用最新稳定版本或可用的修补版本，减少外部依赖项数量，实施单元测试和集成测试，并使用静态分析及早发现代码错误。这些做法也与业务连续性要求相关，包括ISO 22301。
5. 基础设施治理与政策
开发工具和云服务必须符合政府信息技术的安全基线和政策。文章以英国的Government Cloud First政策为例，同时提到公共机构可能对使用SaaS服务或外部云依赖项施加限制，尤其是在处理敏感数据或涉及FedRAMP要求时。
从运营角度看，机构知识流失会对长期运行的系统构成风险。记录决策背景、变通方案及其原因，有助于新团队维护基础设施。当政策禁止依赖外部云时，本地托管或与外部网络隔离的工具也可以成为合适的选择。
实践中会发生什么变化？
最重要的结论不是购买某一种特定工具，而是将合规转化为开发环境中的持续控制措施：安全与许可证扫描、秘密信息发现、依赖项跟踪、自动化测试，以及可在CI/CD中执行并记录的策略。这种方法减少了对滞后人工审查的依赖，但并不会消除解释法律要求和明确人员责任的必要性。文章也没有证明这些措施能够确保每个国家实现完全合规；文章明确指出，规则取决于所在地和适用的政策。在这一背景下，Qodana被介绍为一种可以集成到开发环境和集成流水线中的工具；这一点属于宣传内容，应与可使用不同工具实施的一般原则区分开来。