ISO/IEC 27001:2022 版标准 安全编码
安全编码是指一种软件开发实践，旨在在软件开发过程中构建和维护安全性。它通过遵循安全原则、使用安全技术和实践、进行安全测试和评估等方式，来减少软件中的安全漏洞和提高软件的安全性。安全编码不仅是软件开发人员的责任，也是整个团队的共同责任，因为它涉及整个开发过程和技术栈。
控制
宜将安全编码原则应用于软件开发。
目标
确保安全地编写软件，从而减少软件中潜在的信息安全漏洞的数量。
指南
总则
组织宜建立全组织范围的过程，为安全编码提供良好的治理。宜建立并应用最低安全基线。此外，这些过程和治理宜扩展到包括来自第三方的软件组件和开源软件。
组织宜监控真实世界的威胁以及有关软件漏洞的最新建议和信息，以通过持续改进和学习指导组织的安全编码原则。这有助于确保实施有效的安全编码实践，以应对快速变化的威胁环境。
计划和编码前
安全编码原则宜用于新的开发和重用场景。这些原则宜适用于组织内的开发活动以及组织向他人提供的产品和服务。策划和编码前的先决条件宜包括：
a)针对安全编码的组织特定期望和批准原则，用于内部和外包代码开发；
b)导致信息安全漏洞的常见和历史编码实践和缺陷：
c)配置开发工具，例如集成开发环境（IDE)，以帮助强制创建安全代码；
d)遵循开发工具和执行环境提供商发布的适用指南；
e)维护和使用更新的开发工具（如编译器）；
f)编写安全代码的开发人员的资格；
g)安全设计和架构，包括威胁建模：
h)安全编码标准，并在相关情况下强制使用：
i)使用受控环境进行开发。
编码期间
编码期间的注意事项宜包括：
a)针对所使用的特定编程语言和技术的安全编码实践：
b)使用安全编程技术，如配对编程、重构、同行评审、安全迭代和测试驱动开发；
c)使用结构化编程技术；
d)记录代码并消除编程缺陷，这些缺陷可能导致信息安全漏洞被利用：
e)禁止使用不安全的设计技术（例如，使用硬编码口令、未经批准的代码样本和未经认证的web服务)。
测试宜在开发期间和之后进行（见8.29）。静态应用安全测试（SAST)过程可以识别软件中的安全漏洞。
在软件投入运行之前，宜评估以下内容：
a)攻击面和最小权限原则；
b)对最常见的编程错误进行分析，并记录这些错误已得到缓解。
评审和维护
在代码投入运行之后：
a)更新宜被安全打包和部署；
b)宜处理报告的信息安全漏洞（见8.8）；
c)宜记录错误和可疑攻击，并定期评审日志，以便根据需要对代码进行调整；
d)宜防止源代码的未授权的访问和篡改（例如，通过使用配置管理工具，这些具通常提供访问控制和版本控制等功能)。
如果使用外部工具和库，组织宜考虑：
a)确保外部库得到管理（例如，通过维护所用库及其版本的清单），并随着发布周期定期更新；
b)选择、授权和重用经过充分审查的组件，特别是身份验证和加密组件：
c)外部组件的许可证、安全性和历史；
d)确保软件是可维护的、可跟踪的，并且来自己证实的、有信誉的来源；
e)开发资源和人工制品的充分长期的可用性。
当软件包需要修改时，宜考虑以下几点：
a)内置控制和完整性过程受到损害的风险；
b)是否获得卖方的同意；
c)从卖方处获得所需变更作为标准程序更新的可能性；
d)组织因变更而对软件的未来维护负责的影响；
e)与使用中的其他软件兼容。
其他信息
一个指导原则是确保与安全相关的代码在必要时被调用，并且是防篡改的。从编译的二进制代码安装的程序也具有这些属性，但仅针对应用中保存的数据。对于解释语言，只有当代码在用户和使用它的进程无法访问的服务器上执行，并且其数据保存在类似的受保护的数据库中时，这个概念才起作用。例如，解释程序代码可以在云服务上运行，其上对代码本身的访问需要管理员权限。这种管理员访问宜受到安全机制的保护，如及时管理原则和强身份验证。如果应用所有者可以通过直接远程访问服务器来访问脚本，那么原则上攻击者也可以。在这种情况下，宜配置Wb服务器以阻止目录浏览。
应用代码的最佳设计是假设它总是由于错误或恶意行为受到攻击。此外，关键应用可以设计为能够容忍内部故障。例如，可以检查复杂算法的输出，以确保在数据用于安全或财务关键应用等应用之前，该输出在安全范围内。执行边界检查的代码很简单，因此更容易证明正确性。
一些web应用容易受到糟糕的设计和编码引入的各种漏洞的影响，例如数据库注入和跨站点脚本攻击。在这些攻击中，可以操纵请求以滥用web服务器功能。
有关ICT安全评估的更多信息，请参见IS0/IEC15408系列。
