任何数据和信息处理都离不开软件的运作。软件开发主要集中在算法的特定任务功能上。然而，程序代码写得不好往往也会引起安全问题，如错误的访问控制、SQL注入、不正确的会话管理和认证、跨网站脚本等，这一事实现在已经众所周知。
最新的信息安全标准ISO/IEC 27002和ISO/IEC 27001:2022中强调了安全编码实践的高度重要性。作为一项新的信息安全措施（控制），软件开发中的 "安全编码 "原则正在进入ISO/IEC 27001附件A的措施目录中。请在我们的博文中阅读这项措施对您的信息安全的意义，以及这对未来的审计意味着什么。
嵌入式系统中的操作系统软件、应用软件或固件是任何数字基础设施的基本组成部分。然而，在数字化项目中日益加快的速度和最后期限的压力往往导致忽视了必须的信息安全方面。软件的开发要求通常是以功能为中心，强调建设性的方面，因此对潜在安全漏洞的破坏性看法大多与实际开发目标截然相反：许多程序员根本也缺乏结构化的、锐利的网络安全观点。
在这种情况下，开发团队很难持续审查和持续保障其软件的编码，非营利性的MITRE公司每年在其CVE（Common Vulnerabilities and Exposures）列表中公布的许多漏洞就是证明。即使是知名的软件制造商，其定期的安全补丁也说明了关闭与安全有关的漏洞是一项艰巨的任务，更不用说在它们推出市场之前就发现它们。
在对自行开发的软件进行编码时，程序员喜欢借助于开放源代码库和模块。实际的好处是显而易见的：如果你不必一次又一次地重新发明轮子，你就会从这种技术提升中受益，开发速度快，开发成本低，通过开放源代码提高透明度，并通过开放标准和接口提高互操作性。
人们还经常说，来自开放源码的代码提供了高度的安全性，因为代码已经被许多用户验证过，而且开放源码社区的群集智慧使错误得到快速有效的修复。
在实践中，这种信任现在必须以一种有区别的、关键的方式进行评估。最严重的例子是广泛用于Java应用程序的日志库Log4J中的零日安全漏洞Log4Shell，该漏洞于2021年11月被发现。你可能听说过德国联邦信息安全局（BSI）对Log4Shell发出的红色警报级别。Log4J库作为一个功能可靠的准标准通过Apache基金会发布，自2013年以来已经在许多系统中建立了自己的地位--包括亚马逊AWS等知名网络服务。
这些精心开发和维护的库的复杂性隐含地提供了强大的功能，而导入的开发者在自己的综合新开发中往往没有意识到这些功能，但这些功能可以被攻击者利用。
开源组件的另一个不安全因素是所谓的供应链攻击，即由冒充开源社区的一部分并协助代码开发的恶意行为者故意制造的内置漏洞。这样的漏洞是黑客攻击大量下游用户组织的一种极其有效的方式。因此，难怪这种攻击载体正在迅速增长：Sonatype的一项研究诊断，在比较2020年和2021年时，将增加650%。
适应当代信息风险的新版ISO/IEC 27001已于2022年10月25日发布。这对该标准的用户意味着什么？在我们的免费网络研讨会录音中，你将了解到
为了及时保障软件开发过程，国际标准化组织（ISO-委员会ISO/IEC JTC 1/SC 27）在新的ISO/IEC 27002和ISO/IEC 27001:2022，附件A标准中，将 "安全编码 "作为一个新的控制8.28。安全编码的技术措施的目的是对软件进行预防性保护。
在程序规定的基础上，早在编写阶段就建立了最低的安全水平，从而最大限度地减少了软件中潜在的安全漏洞的数量。安全代码生成的监管框架要全面适用于公司自己的程序代码和来自第三方和开放源代码的软件。值得注意的实施原则是安全设计和最小特权，在编码中也必须考虑到这一点。
措施8.28多次提到所谓的安全编码原则。许多组织和机构定期发布安全编码的指南和最佳做法，为这些原则提供指导。这些包括，例如，OWASP基金会的安全编码实践，软件工程研究所（SEI）的计算机应急响应小组（CERT）的安全编码标准，以及德国BSI的网络应用程序安全措施目录。尽管来源不同，但这些阐述显示了许多相似之处，例如在以下几点上：
在ISO/ISO 27002:2022标准中，控制8.28的建议行动分为三个部分，"计划和预编码"、"编码期间 "和 "验证和维护"，其核心内容概述如下。
新的代码开发和代码重用都需要应用安全编码原则--无论代码是为内部软件还是为外部产品和服务编写。这需要事先评估组织特定的期望和定义公认的原则。此外，规划和预编码的建议行动考虑到了已知的常见和历史的编码实践和可能导致漏洞的错误。
开发工具的配置，如集成开发环境（IDE）中基于规则的，应强制创建安全代码。相当关键的是开发人员的资格以及他们对安全架构和编程标准的熟悉程度。在开发团队中加入信息安全专家是不言而喻的。
在编码过程中，编码实践和结构化编程技术发挥着主要作用，同时考虑到具体的用例及其安全需求。不安全的设计技术--例如，硬编码的密码--应该被持续禁止。代码应该被充分记录和审查，以最好地消除与安全有关的错误。代码审查应该在开发过程中和开发后进行，通过静态应用安全测试（SAST）或类似的方法。静态测试方法支持左移方法（"早期和经常测试"），通过早期测试可见代码的规则一致性，在生命周期中左移。
这可以及早识别出被污染的代码、与文件或特定对象类的连接、或应用层面的漏洞，这些漏洞可以被滥用于与第三方程序的不被注意的互动，成为可利用的漏洞。在软件投入运行之前，Control 8.28要求对攻击面进行评估，并实施最小特权原则。应评估对最常见的编程错误进行的分析和对其纠正的文件。
即使在软件上线后，安全编码的话题仍然相关。这包括安全更新以及对自己代码中已知漏洞的检查。此外，错误和可疑的攻击必须被记录下来，以便及时进行必要的调整。在任何情况下，必须通过合适的工具可靠地防止对源代码的未授权访问。
在验证和维护方面，措施8.28还列出了使用外部工具和库的明确说明，如开放源代码软件。这些代码组件应在清单中进行管理、更新和维护。例如，这可以通过软件材料清单（SBOM）来完成。SBOM是一个正式的、结构化的软件包和库的记录，以及它们之间和供应链内的关系，特别是为了跟踪重复使用的代码和开放源代码组件。SBOM支持软件的可维护性和有针对性的安全更新。
为了使您的ISMS获得ISO 27001认证，您需要做哪些努力？免费获得信息，不承担任何义务。
我们期待着与您交谈。
安全代码是阻止潜在攻击的一个基本基础。新的控制8.28考虑到了这一长期以来的洞察力，并提升了安全编码对信息安全的重要性的关键作用。然而，由于该措施包括大量详细的行动建议，并且在技术上要求很高，其实施将涉及相对较高的努力--这一点应该在计划阶段就被考虑到了。
凭借我们经验丰富的审计师的专业意见，我们支持您合规地实施该措施。凭借我们超过35年的审计和认证经验，我们是您理想的联系伙伴，我们将很乐意在信息安全和符合ISO/IEC 27001:2022标准的认证方面为您提供帮助。
ISO/IEC 27001:2022已于2022年10月25日发布。这导致了用户过渡的最后期限和时间框架如下：
ISO/IEC 27001:2022认证准备就绪
首次/再认证审核的最后日期根据 "旧 "ISO 27001:2013进行初始/再认证审核的最后日期
所有现有证书从 "旧 "ISO/IEC 27001:2013过渡到新的ISO/IEC 27001:2022
由于过渡期的存在，企业有足够的时间按照新的要求调整他们的ISMS，并使其得到认证。然而，整个改变过程的持续时间和努力不应该被低估--特别是如果你没有足够的专业人员。如果你想安全起见，你应该尽早处理这个问题，并在必要时找有经验的专家。
作为拥有超过35年专业知识的审计和认证专家，我们很乐意支持你评估你的现状，也许是作为delta审计的一部分。从我们众多经验丰富的审核员那里了解到最重要的变化及其与贵组织的相关性。我们将一起讨论你的改进潜力，并支持你，直到你收到你的新证书。利用我们在信息安全方面的能力!我们期待着您的来电。
Jegelka作为研究生工程师在DQS担任产品管理和认证部门的信息安全专家和审核员。他回顾了三十多年的从业经验，先是作为核设施辐射防护专家，然后是ISMS的审核员和认证机构副经理。在此职位上，他向德国认证机构DAkkS和许多客户审计展示了他的信息安全专业知识（ISO/IEC 27001），根据德国能源工业法案(EnWG)第11.1a段的IT安全目录)。
