在开发和维护自己的应用程序或为其他组织生产应用程序的组织中，应用程序安全性是应用程序开发和安全活动的重要组成部分. 攻击者继续发现和利用应用程序中的漏洞，其速度通常超过了组织的补救能力，或者在采取纠正措施时足够快地实现补偿控制以保护自己. 随着不断涌现的持续集成和持续开发/部署(CI/CD)实践迅速成为应用程序开发活动的规范, 运用合理和充分的安全概念的能力, 控制, 测试变得更加令人生畏.
这就是所谓的“左移”,或整合质量保证, 功能和安全测试, 应用程序开发活动中的实践正迅速成为增强应用程序安全性的行业领先实践，并成为成功的应用程序安全性计划的关键组成部分. 转向应用程序安全需要改变理念, 大多数组织的方法和工作实践. 它需要考虑风险和安全性, 在应用程序开发过程的每个步骤中进行集成和测试，并编排到应用程序安全程序中. 应用程序安全程序包含所有这些工具, 流程, 支持这些工作的功能和能力.
应用程序安全程序有五个关键组成部分:
- 设计安全性-增强应用程序和应用程序开发活动的安全性的最有效方法是在体系结构和设计方面考虑安全性, 在编写或编译任何源代码之前. 在任何新的应用程序开发项目开始时，应用程序安全专业人员和开发人员之间的协作可能会产生比在应用程序开发期间或完成后解决安全问题的传统方法更安全的应用程序. 这种协作应该包括基于风险的识别和安全控制目标和需求的规范，这些需要集成到应用程序中，以适应组织的风险偏好.
一旦定义了应用程序体系结构和设计, 应该执行安全风险评估，以识别和分类计划的应用程序体系结构和应用程序的预期功能的固有安全风险. 这些评估应包括各种类型的数据, 业务流程, 第三方系统和平台, 和/或应用程序将与之交互和/或存储的信息基础设施, 过程, 并传输数据. 通过深入了解固有的安全风险, 可以定义适当的安全控制目标和相关的安全控制，以适当地管理应用程序中的风险. 控制项包括, 但不限于, web应用防火墙(waf)和API安全网关的使用, 加密功能, 身份验证和秘密管理, 日志需求, 以及其他安全控制措施.
安全工具需求的识别也应该包括在应用程序开发的体系结构和设计阶段. 安全团队需要适当地监视应用程序以及应该如何解释数据的洞察力必须由开发人员识别和记录. 在将这些信息纳入应用程序编码活动之前，应该由安全人员验证其全面性.
重要的是，由应用程序生成的与安全相关的见解和数据提要必须能够被组织内使用的应用程序安全监视工具所吸收并对其有用, 例如安全事件和事件管理(SIEM)功能或其他安全工具和分析平台. 生成的警报还应该包括分类, 对预期含义和适用的关注程度的解释. 例如, 如果生成日志警报, 它们应该遵循一种可以被安全控制解释为其评估的一部分的分类分类法, 分析和报告流程, 能力(e).g.，关键，高，中，低，信息).
- 安全代码测试-安全代码测试应持续进行, 不仅仅是在质量保证或安全测试的时候. 应该执行的安全代码测试有几种主要类型:
-
- 静态应用程序安全测试(SAST)侧重于在开发时和/或在编译或运行代码之前识别安全缺陷和弱点.
- 动态应用程序安全测试(DAST)检查正在运行的已编译应用程序中的缺陷和弱点.
这两种技术都有助于识别代码中需要解决的安全问题. SAST测试的优点是能够在代码开发期间或之后不久识别问题和关注点. 当使用SAST时，应在软件开发生命周期(SDLC)中实现批准门。. 在理想的情况下, 代码扫描应该在集成开发环境(IDE)中实现，在集成开发环境中，代码可以在成为应用程序构建分支的一部分之前通过闸门, 确保在允许将代码合并到组成应用程序的更大的代码库之前解决所有已识别的安全问题. 这将最小化在纠正性重新编码活动中花费的精力，并防止缺陷成为将被编译到应用程序中的较大代码库的一部分.
渗透(渗透)测试也可以集成到测试过程中. 渗透测试可以使用自动化工具来完成，这些工具可以作为测试管道的一部分自主运行.g.打嗝套房，portswigger.Net)，或者在将代码发布到生产环境之前，通过人工驱动的测试和自动测试的组合进行测试. 如果遵循基于风险的方法, 低风险的代码可以单独通过自动化测试进行扫描, 但是高风险的应用应该至少每年进行一次人体测试. 这确保了执行因果渗透测试来弥补自动化测试中的弱点. 在这种渗透测试中, 渗透测试人员可以利用和解释来自多个测试工具的数据，并根据应用程序对它们的反应尝试多种攻击方法和技术. 因果渗透测试还全面评估跨多个攻击技术维度的安全控制的有效性.
- 软件物料清单-现代应用程序通常由内部开发的代码和开源代码及库组合而成. 软件组合分析(SCA)为应用程序的特定代码库中使用的所有开源代码库和功能创建软件材料清单(SBOM)清单. 这是考虑到当前应用程序安全状态的基本知识. 在一个值得注意的事件中，这种知识是非常有用的 Apache Log4j开源漏洞 于2021年12月出现. 由于易于利用和在许多商业和内部开发的应用程序中普遍使用Apache Log4j开源库，因此这个漏洞非常令人担忧. 对于组织来说，重要的是要有可用的soms来了解它们的暴露情况，并能够就纠正行动计划做出基于风险的决策.
SBOM应该与声誉分析配对，声誉分析提供了关于开源组件的可行性和支持历史的见解，并确定了与SBOM中确定的组件相关的任何已知的安全关注点或问题. 这种洞察力允许组织做出明智的决定，决定是否应该将开源库和功能合并到他们的应用程序中. 安全策略和标准应该包括开发人员根据声誉分析的结果允许使用哪些开源组件和功能的标准和指导.
-
安全培训及意识应用程序安全培训是任何应用程序安全计划成功的关键. 所有的开发人员都应该接受最低限度的培训 开放Web应用程序安全项目前10名列表 (OWASP top10), 由于SDLC中的错误和/或疏忽而在应用程序中发现的当前最受关注和最多产的安全问题的综合列表. 开发代码中确定的安全问题应该与OWASP Top 10交叉引用，并且应该向确定为错误来源的开发人员提供个人和重点培训.
开发人员还应该定期获得与应用程序中常见漏洞相关的威胁和漏洞情报，以及当前和新兴的用于攻击此类应用程序的应用程序攻击技术. 这些情报应包括有关如何实施攻击的信息, 攻击所需的努力程度，以及低技能的对手是否可以获得有效的攻击工具, 哪一个通常会传播攻击的频率. 常见漏洞的洞察, 它们是如何在编码过程中产生的，以及如何避免它们.
-
waf和API安全网关和规则开发waf和API安全网关应该被实现为外部连接和被认为对业务操作重要的应用程序之间的保护层. WAF和API安全网关被设计为在网络的应用层运行 开放系统互连(OSI)参考模型. 它们提供了针对常见安全漏洞的保护层，并允许开发确定命令类型的明确规则, 连接和数据可以通过web接口或API与应用程序交互.
许多组织常犯的一个错误是，将WAF和API特定于应用程序的规则的开发推迟到他们开发和/或实现的应用程序投入生产之后. 在这种情况下, 通常在WAF和API网关上启用学习模式，以允许它们动态开发规则，以便在流量通过时考虑, 尽管网关在此期间不提供任何实际的保护.
WAF和API规则应该在应用程序的体系结构和设计中考虑. 一旦定义了应用程序接口和类型, 格式, 它们将相互作用的结构和属性已经被开发出来, 可以开发和评估WAF和API安全网关规则的影响和有效性. 因此, 作为将代码推广到生产环境的一部分，这些规则可以在阻塞模式下立即实现. 这为应用程序提供了即时保护，并且比定义更有效, 在部署后实现和启用规则.
核心组件
应用程序安全性是任何成功的信息风险和安全计划的核心组成部分. 攻击者定期和一致地识别和利用新的应用程序漏洞. 有效的应用程序安全程序可以显著减少这些漏洞的存在, 哪一个, 反过来, 增强开发的应用程序的安全性. 应用程序安全性还可以减少执行纠正安全问题和漏洞所花费的时间和精力，这些问题和漏洞通常对组织具有破坏性和挑战性.
约翰P. Pironti、CISA、CRISC、CISM、CGEIT、CDPSE、CISSP、ISSAP、ISSMP
是IP建筑师有限责任公司的总裁吗.