Devsecops安全小组：让安全成为每个人工作中的一部分！

在安全界有很多关于技能差距的讨论。拥有长期经验的高技能资源可能是困难的，甚至是不可能的。通过培训项目投资于发展一支有凝聚力的安全团队，可以帮助克服这一挑战.

组织经常会发现，将员工从相关的角色（如开发、运营支持、网络管理等）转换为构建安全团队的有效路线图。组织和技术经验这些资源是对传统安全专业知识的一个极大的赞扬。

更广泛的组织（每个人）：

安全培训不应局限于安全和devops团队，而应扩大到整个组织，以确保业务的每个方面都具有安全意识。根据风险评估的结果制定安全意识计划，确保每个员工在看到可能的威胁时都知道如何应对，并熟悉内部安全策略。

安全团队和devops团队组织的午餐和学习会议应旨在传播他们的知识，以便集体开展模拟事件的工作，测试事件响应运行手册，并使其进一步适合每个受影响团队的流程。安全意识挑战、内部安全峰会和其他创造性方法可以帮助加强正式培训工作。

增进同理心与合作

开发人员和安全从业人员之间的理解需求是几十年来一直在讨论的话题。帮助安全团队更好地意识到开发人员面临的挑战，反之亦然，这常常是一件具有挑战性的事情。然而，这种理解在实施成功的改进方面所创造的价值是不可低估的。在DevSecOps模型中，这一点尤为重要。

create unnecessary strain for developers
can be detrimental to the pipeline.安全工具的实现

开发人员引入会产生重大安全风险的技术也会导致同样具有破坏性的问题。

基于安全倡导者的思想，组织可以通过跨功能地嵌入资源来改进成功的结果。分配安全资源在开发团队中工作一段时间，并让开发人员与安全团队一起工作，有助于建立这种同理心。然后，这些资源可以为其核心团队提供关于其他团队的内部工作和面临的挑战的重要观点。这是一个有效的实践，也可以扩展到运营甚至业务团队。

研究表明，新方案的采用可以通过使用商业工具来提高。这是一个很容易被忽视的领域，因为组织推出他们的DevSecOps计划。然而，实施奖励所期望的行为的策略是至关重要的。就像培训一样，游戏化的程序可以帮助驱动强大的结果。提供礼品卡、公司赠品或其他简单的奖励，如电子徽章或特别表彰，都应该考虑。

当然，如何获得奖励的策略需要根据组织及其文化来制定。对此没有一个放之四海而皆准的方法或框架。然而，重要的是要考虑实现DevSecOps模型的目标，以及哪些好处对组织最为关键。从那里，一个奖励方法可以被创建，以确保奖励的行为有助于这些目标

流程

需要将各种实践集成到DevSecOps环境和管道沿线的战略点中。为这些实践定义的过程必须确保安全是开发中内置的，使开发人员能够使用，而不会对高节奏的部署造成障碍。

减少输送摩擦

在Netflix的成功中出现的一个概念是“铺好的路”，并被作为DevSecOps文化的一种策略。铺好的道路概念是指专注于为软件从概念走向生产创造一条低摩擦的路径。因此，做出的可能以某种方式影响或影响这些交付过程的决策应该考虑到它们是否使开发人员能够工作，或者是否给交付带来障碍。后者应尽量减少或最好是一起避免

2020年DevSecOps Insights报告发现，威胁建模对团队对其代码安全性的总体信心有显著的积极影响。不幸的是，威胁建模长期以来一直被认为是一项非常劳动密集型的活动。因此，随着组织转向DevOps/DevSecOps方法，威胁建模通常被排除在所使用的安全实践之外。然而，线程建模对开发的影响绝不能忽视。

从根本上说，威胁建模是为了检查计划中的软件，以确定如果攻击者将目标对准该软件时可能出现的错误。该分析的目标是告知开发团队他们应该考虑哪些安全控制作为实现的一部分。传统上，威胁建模是在应用程序的整个上下文范围内进行的。数据流图、详细的威胁分析框架和说明性威胁优先排序方法经常被用作此过程的一部分。

然而，在DevSecOps模型中，时间和资源密集的威胁建模方法是难以实现的。然而，可以在流水线内使用精简的方法。DevSecOps通常利用敏捷开发的实践，如产品积压管理。不是设计一个完整的系统，而是通过用户故事将新的特性和增强功能添加到backlog中。这些可管理的、独立的要素是实现高节奏发展的核心。组织可以以相同的方式进行威胁建模。

不是把威胁建模看作是一个必须针对整体应用程序进行的过程，而是可以在backlog中实现简单的威胁建模实践。在编写新的用户故事时，该故事还应包括对用户故事引入或影响的威胁的简要描述。应该识别作为故事一部分的敏感功能或数据。在backlog中开发人员可以获得这些信息后，威胁建模的作用将以一种能够实际加快每个故事的开发的方式实现。

在一个自动化的世界中，唯一不变的就是变化，而变化需要既一致又可追踪。要跟踪所有更改，DevSecOps必须确保适当且不可变的版本控制到位。每个操作都需要一个版本，就像管理代码一样，以允许快速恢复。一旦转换为元数据，运营团队就可以高效地跟踪变更并度量它。

编排软件不仅提供了一种可重复的方法来部署基础设施，它还提供了关于任何任务的大量元数据。反过来，元数据不仅可以由编排软件本身使用，而且可以作为集成工具的权威来源使用。一旦与版本控制相结合，编排软件就成为所有运营团队的强大信息源。

安全体系结构由一组特定于每个公司的原则支持。这些原则取决于正在处理的数据的类型，尽管可以使用一组高级原则来指导软件交付走向更安全的实践。采用DevSecOps模型的组织需要确保建立和持续更新这些体系结构的过程到位。这使得开发更快、更安全。

将这些原则编码为DevSecOps文化的一部分，并将其提供并包含在backlog中，允许产品经理无缝地集成安全性，将其作为计划和支持架构的一部分。如果由于业务流程和/或缺乏资源而出现任何偏差，则捕获偏差并考虑到与之相关的风险。这些偏差最终可以以与任何其他bug相同的方式处理，并跟踪到解决方案。

威胁情报

随着环境中越来越多的组件被定义和记录在代码中，威胁情报的可见性也在增长。许多组织很难以一种方式来识别他们的IT资产，使他们能够将收到的威胁情报有效地链接到他们环境中的资产。通过确保构建流程，将DevSecOps管道中的元数据提供给威胁情报能力，组织可以确保收集正确的情报，并以适当的风险优先级方式应用和响应这些情报。

应对安全事件不应是即兴或计划外的活动。提前创建工作流程、行动计划、剧本和运行手册是关键。这是为了确保对事件的响应是一致的、可重复的和可测量的。事件管理应该利用元数据来帮助简化这个过程，从而更改度量标准来突出显示重新部署受损资产所花费的时间。随着剧本的制定，所采用的程序应包括所有形式的事件。由于DevSecOps联合了各种功能，因此实现它的流程也应该联合起来。因此，事件管理流程应该具有一定的抽象级别，在该级别中，操作和安全事件按照相同的框架处理。这是加强对DevSecOps至关重要的分担责任文化的另一个有效步骤。

反过来，一旦Playbook被编码，它们就可以集成到CI/CD管道中，以实现它们的自动化。在一个DevSecOps世界中，积极主动和先发制人的威胁狩猎，以及对威胁和漏洞的持续检测和响应意味着更少的重大事件和更多的缓解。渗透测试、红色团队和bug赏金的使用提供了一个额外的减轻漏洞风险的层。虽然持续检测是一件很好的事情，但组织必须警惕警惕疲劳。这意味着建立反馈循环，以推动监测的持续改进，并在评估和响应警报方面实现更大的自动化。

积极主动的安全评估

无论组织的DevSecOps方法变得多么先进，都需要主动的漏洞识别。渗透测试是一个经常用来指围绕在给定范围内全面识别漏洞所做的努力的术语。红队的不同之处在于，它通常更专注于模仿攻击者的实际动机和战术。例如，渗透测试可能会试图识别应用程序中易受SQL注入攻击的所有页面，而red team评估可能只会识别一个或两个易受攻击的页面，并利用这些漏洞进一步利用应用程序。

渗透测试

当涉及应用程序内的漏洞管理时，渗透测试通常是成熟的第一个阶段。这些测试的目标是识别应用程序中可能易受某种形式攻击的区域。这些评估的理想目标是提供对总体安全态势的全面可见性，并尝试补救有风险的漏洞。但是，要全面查看应用程序中的漏洞可能会很耗时。因此，在DevSecOps中，虽然该测试是安全卫生的基本要求，但它通常是作为后期生产活动实现的。

红队

红色团队评估通常出现在成熟度较高的组织中。红色团队评估是渗透测试的附加步骤。在Red team方法中，目标不是识别尽可能多的漏洞。相反，该方法更多地基于目标，更类似于攻击者会采取的方法。范围通常不限于单个应用程序，而是跨越环境中系统的全部范围。这使组织能够了解多个系统中的漏洞如何组合在一起以实现攻击。它为成功攻击的预期影响提供了更大的背景。因此，与传统的渗透测试相比，这些评估需要更高程度的技能和更多样的技能组合。随着公司的DevSecOps方法的成熟，他们可能希望探索红色团队参与，将其作为常规安全卫生的一部分.

Bug赏金

Bug赏金在最近几年也受到了很多关注，部分原因是众源Bug赏金计划已经变得可用。Bug bounties设置范围、报告要求和报告方法，以便外部黑客尝试识别组织环境中的漏洞。作为遵循这些规则的交换条件，黑客会因为他们向组织报告的漏洞而获得“赏金”。

虽然bug bounds是鼓励外部各方以负责任的方式披露漏洞的一种很好的方式，并且虽然它们提供了一个额外的漏洞识别层，但不应依赖它们来取代渗透测试实践。参与bug赏金计划的安全研究人员通常不会把组织的最大利益放在心上。他们并不寻求全面地识别漏洞，大多数人只搜索最严重的发现，以获得最大的赏金。

源代码库

技术使您的人员能够正确执行DevSecOps流程。当大多数人想到DevSecOps和ci/cd时，工具通常是最重要的。集成和自动化各种开发、安全和操作流程的能力是成功实现DevSecOps的核心。以下是组织在寻求在企业内实现成功的DevSecOps方法时必须考虑的技术集合。

源代码存储库位于地球上几乎每一个开发环境的核心。在实现DevSecOps方法时，存储库是管道中大多数其他技术与之集成的关键技术。当组织评估其是否准备好采用DevSecOps范例时，必须考虑存储库与其他关键技术集成的能力。

随着应用程序环境的越来越多方面在代码中定义，存储库的安全性变得至关重要。必须实现用户访问、存储库配置等方面的最佳实践。将存储库暴露于未经授权或不必要的各方可能导致重大暴露

DevSecOps组织中最流行的存储库之一是bitbucket。它方便的基于Web的界面以及与广泛的其他技术的集成使它非常适合DevSecOps的自动化和编排需求。然而，随着这种流行，安全漏洞的出现也越来越多，这通常是由于存储库的不安全配置或使用造成的。为帮助防范这些问题，应采用以下最佳实践：

1.切勿将凭据作为代码/配置存储在Bitbucket中

对于存储在BitBucket中的任何存储库，应始终遵循机密管理实践。其中一些实践包括利用git-secrets、定期的秘密审计和使用信誉良好的秘密管理器。

2.删除敏感数据

如果敏感数据最终出现在存储库中，则使所有公开的令牌和密码无效，删除信息并清除Git历史记录，并评估泄漏的私有信息的影响。

3.严格控制出入

存储库安全方面的失败通常归结为人为错误。为了帮助减轻这种风险，利用强大的用户管理和使用访问控制技术。

4.新增security.md文件

您应该包含一个security.md文件，该文件突出显示项目的安全相关信息。该文件应包括一个公开策略、一个安全更新策略、一个与安全相关的配置、已知的安全漏洞以及未来的增强。

5验证Bitbucket应用程序

这些应用程序由第三方开发人员编写，应该检查访问权限、作者/组织可信度和总体安全态势。

6.将安全提示作为工作流程的一部分，并提供代码洞察

使用Bitbucket代码洞察对所有打开的请求执行扫描。这将有助于识别公关可能引入的新漏洞。

7.PRs增加安全测试

使用Bitbucket钩子检查PRs是否没有引入新的漏洞。

8.在Bitbucket管道中增加安全测试

将安全扫描管道添加到CI/CD流中，以确保自动管道不包含安全回归。

9考虑Bitbucket服务器

为了显著减少存储库的攻击面，Bitbucket服务器允许存储库在prem上托管