随着资源的缺乏和速率的限制，API漏洞的行为几乎与标题所描述的完全一样。每个API都有有限的资源和计算能力，这取决于它的环境。大多数还需要处理来自用户或其他程序的请求，要求它执行所需的功能。当有太多的请求同时进来，而API没有足够的计算资源来处理这些请求时，就会出现这种漏洞。然后，API可能变得不可用或对新的请求没有反应。

如果API的速率或资源限制没有被正确设置，或者限制没有在代码中被定义，那么API就很容易出现这个问题。例如，如果一个企业经历了一个特别繁忙的时期，一个API就会超载。但这也是一个安全漏洞，因为威胁者可以故意让未受保护的API的请求超载，以便进行拒绝服务（DDoS）攻击。  

顺便问一下，到目前为止，你在API游戏化挑战中表现如何？如果你现在就想试试你处理速率限制性漏洞的技巧，请踏上竞技场。

现在，让我们再深入了解一下。

缺乏资源和速率限制了API的脆弱性，有哪些例子？

这个漏洞有两种方式可以潜入API。第一种是当编码员根本没有定义API的节流率是多少。在基础设施的某个地方可能有一个默认的节流率设置，但依赖这个设置并不是一个好的策略。相反，每个API应该单独设置其速率。这一点尤其正确，因为API的功能和可用资源可能有很大的不同。

例如，一个旨在为少数用户服务的内部API可以有一个非常低的节流率，并且工作得很好。但是，一个面向公众的API，作为一个实时电子商务网站的一部分，很可能需要定义一个特别高的速率，以补偿可能出现的同步用户激增的情况。在这两种情况下，应该根据预期的需求、潜在用户的数量和可用的计算能力来定义节流率。

这可能是很诱人的，特别是对于那些很可能非常繁忙的API来说，将速率设置为无限，以尝试最大化性能。这可以通过一段简单的代码来实现（作为一个例子，我们将使用Python Django REST框架）。

"DEFAULT_THROTTLE_RATES: {
       "anon: None,
       "user: None

在这个例子中，匿名用户和系统已知的用户都可以无限次地联系API，而不考虑一段时间内的请求数量。这是一个坏主意，因为无论一个API有多少可用的计算资源，攻击者可以部署像僵尸网络这样的东西，最终使它慢到爬行，或者可能使它完全脱机。当这种情况发生时，有效用户将被拒绝访问，而攻击也将成功。

消除资源匮乏和速率限制的问题

每一个由组织部署的API都应该在其代码中定义其节流率。这可能包括诸如执行超时、允许的最大内存、每页可返回给用户的记录数，或在定义的时间范围内允许的进程数。

从上面的例子来看，与其让节流率大开大合，不如严格定义匿名和已知用户的不同速率。

"DEFAULT_THROTTLE_RATES: {
       "anon: config("THROTTLE_ANON, default=200/hour),
       "user: config("THROTTLE_USER, default=5000/hour)

在新的例子中，API将限制匿名用户每小时发出200次请求。已经被系统审核过的已知用户会有更大的回旋余地，每小时有5000个请求。但即使是他们也受到限制，以防止在高峰期意外超载，或者在用户账户被泄露并被用于拒绝服务攻击时进行补偿。

作为最后一个要考虑的良好做法，当用户达到节流限制时，向他们显示一个通知，同时解释这些限制何时会被重置，这是一个好主意。这样一来，有效用户就会知道为什么一个应用程序拒绝他们的请求。如果执行批准任务的有效用户被拒绝访问API，这也是有帮助的，因为它可以向运营人员发出信号，表明需要增加节流。

请查看 Secure Code Warrior博客页面，了解有关这一漏洞的更多见解，以及如何保护你的组织和客户免受其他安全缺陷的蹂躏。你也可以尝试一下 Secure Code Warrior 培训平台的演示，以保持你所有网络安全技能的磨练和更新。

过度数据暴露漏洞与OWASP名单上的其他API问题不同，因为它涉及一种非常特殊的数据。该漏洞背后的实际机制与其他漏洞类似，但在这种情况下，过度数据暴露被定义为涉及受法律保护或高度敏感的数据。这可以包括任何个人可识别信息，这通常被称为PII。或者它可能涉及支付卡行业信息，或PCI。最后，过度的数据暴露可以包括任何受隐私法约束的信息，如欧洲的《通用数据保护条例》（GDPR）或美国的《健康保险可携性和责任法案》（HIPAA）。

正如你可能想象的那样，这引起了人们的深切关注，精明的开发者必须学会如何尽可能地压制这些错误。如果你已经准备好接受数据暴露龙，请前往我们的游戏化挑战。

你的分数是多少？继续阅读，了解更多。

有哪些数据过度暴露的例子？

发生过度数据暴露的主要原因之一是，开发人员和编码人员对他们的应用程序将使用的数据种类没有足够的洞察力。正因为如此，开发人员倾向于利用通用流程，在这种流程中，所有的对象属性都暴露给最终用户。

开发人员有时也会认为，前端组件在向用户显示任何信息之前会进行数据过滤。对于大多数通用数据，这很少是个问题。但是，将受法律保护的或敏感的数据作为会话ID的一部分暴露给用户，例如，从安全和法律的角度来看都会导致很大的问题。

OWASP报告举例说明敏感数据很容易被意外分享，该报告设想了这样一个场景：一名保安被授权访问一个设施中基于物联网的特定摄像头。也许这些摄像头正在监视密封和安全的区域，而其他能看到人的摄像头应该只限于拥有更高权限的警卫或主管人员。

为了使警卫能够访问被授权的摄像机，开发者可以使用像下面这样的API调用。

/api/sites/111/cameras

作为回应，该应用程序将以下列格式发送关于警卫能够看到的摄像机的详细信息。

{ "id":"xxx","live_access_token":"xxxxbbbbb","building_id":"yyy"}

从表面上看，这似乎工作得很好。使用应用程序上的图形用户界面的警卫，将只看到他们被授权查看的摄像机画面。问题是，由于使用的是通用代码，实际的API响应将包含整个设施中所有摄像机的完整列表。任何嗅探网络的人，如果捕捉到这些数据，或破坏了警卫的账户，就能发现网络上每台摄像机的位置和名称。然后，他们可以不受限制地访问这些数据。

消除过度的数据暴露

防止数据过度暴露的最大关键是对数据和围绕它的保护措施的理解。创建通用的API并让客户端在向用户显示数据之前对其进行分类是一个危险的选择，会导致许多可预防的安全漏洞。

除了了解相关的数据保护外，停止用通用API向用户发送一切的过程也很重要。例如，必须避免to_json()和to_string()这样的代码。相反，代码应该专门挑选需要返回给授权用户的属性，并专门发送这些信息。

作为一种确保没有受保护的数据被意外地过度共享的方法，组织应考虑实施基于模式的响应验证机制，作为额外的安全层。它应该定义并执行由所有API方法返回的数据，包括错误报告的规则。

最后，所有被归类为包含PII或PCI的数据，或受GDPR或HIPAA等法规保护的信息都应使用强大的加密技术进行保护。这样，即使该数据的位置作为过度数据暴露漏洞的一部分被泄露出去，也有一个良好的第二道防线，即使数据落入恶意用户或威胁行为者手中，也能保护数据。

。 Secure Code Warrior博客页面，了解有关这一漏洞的更多见解，以及如何保护你的组织和客户免受其他安全缺陷的蹂躏。你也可以尝试一下 Secure Code Warrior 培训平台的演示，以保持你所有的网络安全技能得到磨练和更新。

难怪破损的认证被列入OWASP的API问题名单--认证机制是出了名的难以正确实施。另外，攻击者也有一点优势，因为就其本质而言，大多数认证挑战必须暴露给用户，让攻击者有机会研究它们，寻找他们可以利用的模式或漏洞。

最后，由于认证经常作为应用程序和潜在的网络其他部分的网关，它们是攻击者的诱人目标。如果一个认证过程被破坏或有漏洞，攻击者很有可能会发现这个弱点并加以利用。

因此，在本章中，我们将学习如何在涉及到认证问题时将坏人拒之门外。如果你想先测试一下你的技能，可以去玩我们的游戏化挑战。

想提高你的分数吗？请跟着我，我们来分析一下。

破损或配置错误的认证有哪些例子？

一个问题可能不那么明显的例子是，当一个认证方法容易受到凭证填充的影响，或者使用已知的用户名和密码列表来破坏安全。即使是通常非常安全的授权方法，如多因素认证，如果不对请求进行限制、节制或其他监控，也可能会受到攻击。

例如，攻击者可以通过向/发送POST请求来触发密码恢复请求。api/system/verification-codes并在请求正文中提供一个用户名，从而触发密码恢复请求。如果一个应用程序使用短信挑战，将六位数的代码发送到用户的手机上，但输入字段没有限制，那么该应用程序可以在短短几分钟内被攻破。攻击者只需向应用程序发送每一个可能的六位数组合，直到他们找到正确的组合。

在这种情况下，从表面上看，拥有双因素认证似乎可以保证应用程序的安全。但由于用户的输入没有速率限制，认证就被破坏了，很容易受到攻击。

在另一个例子中，一个应用程序可能使用编码的用户对象作为认证cookie。但是，如果一个有低级用户权限的攻击者使用Base64解码该cookie，他们可以发现该cookie如何定义会话和用户到应用程序。例如，他们可能会看到下面的JSON，一旦被解码。

{
"username" : "ShadyGuy",
"role" : "user"
{

在这一点上，恶意用户可以改变他们的用户名、角色或两者。他们可以通过改变几个值而成为另一个具有更高权限级别的用户。

{
"username" : "GoodGuy",
"role" : "admin"
{

在这一点上，如果攻击者重新编码信息并将其设置为cookie值，他们基本上就会成为具有更高权限级别的新用户。除非有办法防止这样的改变，否则应用程序很有可能会接受这种转变。

消除破损或错误配置的认证方式

如果认证失败，很有可能整个系统的安全就会受到影响。但是，在对应用程序进行编码时，遵循一些重要的准则可以帮助保持一切安全。

首先，一定要在允许用户访问程序功能的所有地方包括认证检查。如果认证检查根本不存在，那么这场战斗从一开始就已经输了。

在最佳实践方面，要记住的一件好事是避免在用户可访问的URL中暴露会话ID。在上面第二个关于破解认证的例子中，如果会话cookie从未暴露给攻击者，那么防止攻击者试图解码会话cookie就容易得多。

实施多因素认证也是一个好主意。这可以通过使用硬件令牌来安全地完成，这些令牌可以在严格的时间表上通过算法生成密码。如果你不能为你的用户提供这样的设备，短信也可以发挥作用。但你需要确保用户的请求被限制在合理的范围内，比如在30秒内尝试三次或四次，而且代码在几分钟后就会全部失效。使用字母数字代码也可以通过在潜在的密码中加入字母和数字来提高安全性。

最后，如果可能的话，避免依赖用户名或可预测的顺序值作为会话ID。相反，使用一个安全的服务器端会话管理器，每次生成一个随机会话ID。

实施安全的认证方法比打击一般的漏洞要棘手一些。但是，由于授权对每个应用程序、程序和API都非常重要，所以值得花额外的时间来确保你得到它。

请查看 Secure Code Warrior博客页面，了解有关这一漏洞的更多见解，以及如何保护你的组织和客户免受其他安全缺陷的蹂躏。你也可以尝试一下 Secure Code Warrior 培训平台的演示，以保持你所有网络安全技能的磨练和更新。

在科技创业公司工作的最好的事情之一是你在工作中遇到的所有有趣的、聪明的人，并与之合作。将一个公司从一个很酷的想法发展成一个严肃的市场竞争者，需要组建你自己的复仇者团队（或者，正义联盟，取决于你的忠诚）。

考虑到这一点，我们想把目光投向我们的一位专家，Oscar Quintas。他是我们产品内容团队的一员，作为高级安全研究员工作。他也是我们所有基础设施即代码（IaC）方面的常驻巫师。他是我们178个（而且还在不断增加！）IaC平台挑战背后的力量，也是我们解决所有关于这个新鲜、热门话题的迫切问题的首选。

我们认为他很特别，所以我们希望你能更好地了解他。在这里，他将分享他对基础设施即代码安全这一热门话题的见解，他的角色，以及组织可以做什么来更好地准备他们的云基础设施和工程师。

问：请告诉我们你在Secure Code Warrior 的角色。对你来说，典型的一天是什么样子的？

答：我是产品内容团队的一员，担任高级安全研究员。典型的一天包括审查不同语言的挑战代码（Python、Java、Golang和许多其他语言！），以确保代码质量标准得到满足，安全最佳实践得到实施。我还开发新的IaC内容。

问：你是我们所有基础设施即代码平台挑战背后的天才。你的过程是什么？

我想说的是，这是一个研究和努力工作的组合，为多种技能水平提供高度相关和参与的内容。我通常从研究用户在部署基础设施时面临的最常见的问题开始，利用这些信息，我开发了有用的挑战，以展示每个案例的安全最佳实践。

我总是试图为我们的战士提供一个良好的学习经验，并确保这是一个与工作相关的、有用的练习，并持续受益。

问：IaC安全是目前一个非常流行的话题。在云安全实践方面，公司面临的主要问题是什么？
答：基础设施即代码是指用代码来管理你的基础设施资源。只需几行该代码，你就可以部署数以百计的云资源（网络、防火墙规则、虚拟机、容器等），如果配置不当，就可能包含安全漏洞。因此，适用于安全应用部署的原则也可以适用于IaC，这些风险--以及它们的修复--必须被参与SDLC的每个团队理解。

这种意识和行动从适当的IaC安全培训开始，并优先考虑你的云工程师的安全编码技能。他们可以成为一个强大的防御层，当他们正在构建承载应用程序的基础设施时，这一点尤为重要。

问：业界对Kubernetes有很多兴趣，它似乎也被广泛使用。然而，我们的平台数据反映出Terraform是一种压倒性的流行语言，具有很高的参与度。你有什么见解可以分享吗？
答：Terraform是IaC事实上的语言，因为它允许我们使用简单的语法在多云环境（如AWS、GCP、Azure）中部署基础设施资源。它允许你使用代码来定义你的基础设施，并与云的API透明地互动，以管理资源的部署。

这种语言的用途非常广泛，由于它可以被添加到源控制库中，DevOps/DevSecOps原则也可以被应用到基础设施部署中。然而，这也会带来新的威胁，必须加以解决，所以用Terraform进行安全编码的全面培训是必须的。

问：你是一名IaC安全专家。你的工作中最好的部分是什么？
答：IaC仍然处于早期阶段，所以有很多新的东西被频繁发布。要跟上这些新技术的发展，有点挑战性，但同时也很有收获。我非常喜欢学习新的东西，测试新服务的安全最佳实践。

把你的IaC安全提高到新的水平。

如果你想让你的云计算开发人员围绕基础设施即代码来磨练他们的安全技能，那就用我们的IaC Top 8来挑战自己吧阅读每一章，了解八种常见的IaC安全漏洞的全部内容，包括测试他们新知识的互动挑战。

让我们知道你的分数，并让奥斯卡感到骄傲

如今，网络安全的威胁无处不在，而且无情。它已经变得如此糟糕，以至于在程序部署后试图跟上它们几乎成为不可能。然而，在这个DevSecOps、持续交付和比以往任何时候都更多的数据的时代，精明的组织正在帮助他们的开发人员提高技能，成为安全意识的超级明星，在他们进入生产之前协助消除常见的漏洞。我们已经解决了网络漏洞，加上我们自己的8大基础设施即代码的错误，现在是时候熟悉下一个大的软件安全挑战了。你准备好了吗？

接下来的一系列博客将集中讨论一些最糟糕的安全漏洞，因为它们与应用编程接口（API）有关。这些漏洞是如此糟糕，以至于它们被列入了开放网络应用安全项目（OWASP）的顶级API漏洞名单。鉴于API对现代计算基础设施的重要性，这些都是关键问题，你需要不惜一切代价防止你的应用程序和程序出现。

在对被破坏的对象级授权漏洞的检查中，可以发现一个完美的例子，说明为什么使用代码来执行安全是至关重要的。当程序员未能明确定义哪些用户能够查看对象和数据，或提供任何形式的验证来查看、改变或提出其他请求来操纵或访问对象，允许他们通过API端点修改和访问对象和数据，就会发生这种情况。一个API端点是一个接触点，通常是一个URL，用于API本身和另一个系统之间的通信。应用程序之间的连接能力提升了世界上一些最受欢迎的软件，但如果它们不是密不透风的，就会有暴露多个端点的风险。

当编码人员忘记或继承父类的属性时，也会发生这种情况，而没有意识到这样做也会遗漏他们代码中的关键验证过程。一般来说，对于使用用户输入的数据源的每个函数，都应该包括对象级的授权检查。

你认为你已经熟悉了这些，并且现在就能找到、修复和消除一个访问控制的错误？参加游戏化的挑战。

你的表现如何？如果你想努力提高你的分数，请继续阅读!

破解对象级授权漏洞的例子有哪些？

对象级访问控制漏洞允许攻击者采取他们不应该被允许的行动。这可能是一个应该保留给管理员的行动，如访问或查看敏感数据，或销毁记录。在一个高度安全的环境中，它甚至可能意味着阻止任何人查看记录，除非他们被特别授权这样做。
在定义对象级别的授权时，你应该记住所有可能的行动。例如，在Java Spring API中，一个有潜在问题的端点可能看起来像这样。

public boolean deleteOrder(Long id) {
       Order order = orderRepository.getOne(id);
       if (order == null) {
           log.info("No found order");
           return false;
       }
       User user = order.getUser();
       orderRepository.delete(order);
       log.info("Delete order for user {}", user.getId());
       return true;

API端点按ID删除订单，但不验证该订单是否由当前登录的用户做出。这就给攻击者提供了一个机会，可以利用这个漏洞，删除其他用户的订单。

为了正确地实现安全访问限制，代码看起来更像这样。

public boolean deleteOrder(Long id) {
       User user = userService.getUserByContext();
       boolean orderExist = getUserOrders().stream()
               .anyMatch(order -> (order.getId() == id));
       if (orderExist) {
           orderRepository.deleteById(id);
           log.info("Delete order for user {}", user.getId());
           return true;
       } else {
           log.info("No found order");
           return false;

消除破碎的对象级授权漏洞

访问控制代码不需要过于复杂。在我们的Java Spring API环境的例子中，它可以通过严格定义谁可以访问对象来解决。

首先，必须实施一个核查程序，以确定谁在提出请求。

用户user = userService.getUserByContext()。

接下来，我们必须确保该对象的ID存在，并且属于提出请求的用户。

boolean orderExist = getUserOrders().stream()
.anyMatch(order -> (order.getId() == id))。

最后，我们继续删除该对象。

orderRepository.deleteById(id)。

请记住，你需要确保你的代码中的授权方法与你组织的用户政策和数据访问控制相一致。作为确保你的代码完全安全的一种方式，你应该进行检查，以验证具有不同权限级别的用户是否可以访问他们执行工作所需的数据，但被阻止查看或改变任何应该限制他们的东西。这样做可能会发现不小心被忽略的对象控制漏洞。

从这些例子中得到的主要启示是，首先要定义用户对一个对象可能采取的每一个动作，然后直接在代码中添加强大的访问控制。最后，永远不要相信继承的父属性可以完成这项工作，也不要把这个权力委托给其他地方。相反，在代码中为你需要保护的每个对象类型明确定义用户权限和操作。

请查看 Secure Code Warrior博客页面，了解有关这一漏洞的更多见解，以及如何保护你的组织和客户免受其他安全缺陷的蹂躏。你也可以尝试一下 Secure Code Warrior 培训平台的演示，以保持你所有网络安全技能的磨练和更新。

在日本的拟声词中，"doki-doki"（""""）这个短语代表了心脏剧烈跳动的声音......这正是安全团队成员在他们的Docker服务器感染Doki时可能遇到的情况，Doki是一个新的漏洞，为恶意代码注入提供一个后门，还有更多。至少可以说，这是一个合适的名字。

随着我们对云计算基础设施的依赖程度越来越高，对安全最佳实践的精确性和可扩展性的需求是至关重要的，它需要远远超出安全应用部署的最低限度，在整个SDLC中对容器安全的定制措施进行宣传和部署。

网络攻击只会越来越频繁，影响基于Linux的基础设施的威胁也越来越普遍，其最终目的是有机会破解存储在云中的敏感数据的战利品。Doki旨在做到这一点，它使用多种技术来保持不被发现、强大和有效，这与以前在基于Docker的安全问题领域所看到的情况不同。

什么是Doki，它是如何工作的？

正如许多被破坏的应用程序的共同主题一样，安全错误配置在软件被破坏的过程中发挥了不可接受的巨大作用。具体到Docker，错误配置的Docker引擎API已被证明对攻击者来说是有成效的。自2018年以来，Ngrok Botnet加密机器人一直在嗅探不安全的Docker服务器，旋转自己的容器并在受害者的基础设施上执行恶意软件。

Doki是这种恶意软件的一个更狡猾的恶意版本，通过相同的僵尸网络暴露相同的攻击载体而获得成功。API错误配置，这应该在任何代码部署或服务器的公开可见性之前得到解决。Doki利用大家最喜欢的讽刺性加密货币Dogecoin的区块链，作为一个几乎无法检测的后门。就目前的情况来看，自1月以来，它已经悄悄地溜走了，没有什么痕迹。

该恶意软件基本上滥用区块链钱包，以生成命令和控制（C2）域名，这本身并不新鲜，但Doki为受感染的服务器提供了持续的远程代码执行能力，为一系列基于恶意软件的破坏性攻击，如勒索软件和DDoS，让路。它是无情的，如果你愿意，就像一个 "有骨头的狗"。Intezer的好心人对整个威胁和其庞大的有效载荷进行了全面的报道。

在代码中发现一个Doki的途径。

事实上，Doki是一个在去中心化区块链网络上运行的后门，采用难以捉摸和快速的容器逃逸技术来掩盖踪迹，进入主机的更多区域并继续传播感染，这使得它在某种程度上成为开发者和安全团队的噩梦。

然而，Doki不能感染拥有安全API端口的Docker服务器。在生产过程中错误地配置这些端口是一个具有深远影响的错误，但面对这样一个复杂而难缠的恶意软件，对云开发人员进行有效的安全意识和实用的安全编码技能培训是一个有点 "简单 "的解决方案。

让我们看看这个不安全的Docker API的例子，在这个例子中，Doki可以找到一个入口并开始传播。

dockerd -H tcp://0.0.0.0:2375

你能发现这些错误的配置吗？安全版本看起来像这样。

dockerd -H tcp://0.0.0.0:2376 --tlsverify --tlscacert=/etc/ssl/certs/ca.pem --tlscert=/etc/ssl/certs/server-certif.pem --tlskey=/etc/ssl/private/server-key.pem

在不安全的例子中，Docker引擎API在TCP 2375端口上监听，它将接受任何连接请求，因此任何人到达Docker服务器都能使用它。

在安全的例子中，Docker引擎API已经被配置为使用TLS证书验证，它将只接受来自提供由你的CA信任的证书的客户端的连接。

我们有一套全新的游戏化挑战，以帮助开发者识别和修复Doki感染的根源，你可以玩一个 这里:

安全的云基础设施是一项团队运动。

在2018年和2019年，云的错误配置给企业带来了令人震惊的5万亿美元的损失，这意味着数十亿的暴露记录和不可逆转的声誉损失。对于一个在很大程度上可以避免的攻击载体，这是一个相当惊人的统计数字。想想看，监测和修复暴露的端口（最好是在部署之前），检查任何未知的容器，并保持对任何过度的服务器负载的关注，可以阻止像Doki这样的滚雪球式的破坏，嗯，这是一个小的代价，以获得心灵的平静。

公司范围内的安全意识是至关重要的，对于参与SDLC的每一个人来说，以安全最佳实践进行操作是没有商量余地的。最好的组织致力于一个坚实的DevSecOps过程，在这个过程中，安全的责任是共同的，开发人员和AppSec专业人员都有知识和工具来阻止常见的漏洞进入软件和重要的基础设施。
想成为一个有安全意识的、超强的云工程师？现在就开始测试你的技能。

我们在2020年刚刚过半，但我们已经在创造一个严峻的数据泄露记录，与2019年上半年相比，被盗数据增加了273%。这些天，问有多少数据还没有被盗更准确。随着COVID-19大流行等世界性事件的发生，这些攻击的频率和效力只会增加，目标越来越脆弱。

这是我们都知道的事情：安全不再是可有可无的，我们的重点必须是先发制人的打击。要做到这一点，SDLC中的每个人都必须具有安全意识，尤其是开发人员。这是DevSecOps的 "DevSec"部分，是一种理想的软件开发方法论的气候，但许多组织并没有做好充分准备来有效地执行这一点。

考虑到你的组织，在你的角色背景下思考这些问题。在接受DevSec测试时，它的表现会如何？

DevSec Self-Assessment: 你的SDLC花园准备好绽放安全意识的工程师了吗？

1. 
   一系列的网络安全风险因素可能会让普通的CISO夜不能寐，但令人担忧的现实是，虽然许多公司将安全作为优先事项，但他们的内部方法可能不够强大，无法减轻潜在的灾难（或者，至少是AppSec团队的巨大麻烦和软件的延迟发货）。
   DevSecOps可能是当前安全涅槃的状态，但很少有公司采用这种方法。如果你还处于敏捷期--甚至是瀑布期--那么安全往往还被认为是专家的领域，他们与流程相距甚远，在SDLC的后期才被激活，突然出现的热修复破坏了开发者的一天。在这样的环境中，要推动开发安全文化是很有挑战性的：开发人员喜欢并优先考虑功能建设，他们根本没有足够的安全实践经验，无法将其视为一个理想的提高技能的途径。事实上，他们与安全的接触点可能是沮丧和消极的。这种情况必须迅速得到纠正，以便为参与软件开发过程的每个人灌输一种思想前卫的方法。
   
2. 当涉及到威胁建模时，你的组织还在追赶吗？
   这是一个令人清醒的统计数字，60%的中小企业在成功的网络攻击后六个月内就会倒闭，就像其他灾难一样，如果没有足够的规划，影响会更大。
   威胁建模是安全最佳实践的一个重要元素，允许AppSec专业人士评估攻击面的全部范围并构建适当的防御、反措施和规划。在完全接受DevSecOps的公司中，安全在CI/CD管道的早期就已启用，其方式不会像过去那样拖累生产。安全、安全编码和持续交付都是流程的一部分，开发团队被赋予了所需的资源和机会，成为引擎的主要组成部分，吐出无懈可击的代码。
   
3. 开发经理是否优先考虑安全最佳实践？
   无论他们是否愿意，开发经理都是他们团队的榜样。而且，这不仅仅是文化和氛围的问题，比如穿人字拖去办公室或者他们如何 "向上管理"。他们的工作重点将不可避免地被他们的团队成员所吸收，如果安全不是关键目标的一部分，或者在培训和支持方面没有计划，那么他们下面的工程师就会错过，而企业的风险将比它应该的更大。
   
4. 
   根据我的经验，让一个人越位的最快方法是告诉他们必须做一些与他们目前的方法不一样的事情，而不告诉他们为什么。
   
   被告知 "改变 "意味着以前的方法是错误的，而在许多情况下，这只是一个改进，希望以后能让事情变得更容易和更有效。要真正接受DevSec运动，首先需要给开发人员一个关心安全的理由--毕竟，在大多数组织中，它在很大程度上仍然是 "别人的问题"（即AppSec向导被锁在另一个房间里，很远很远）。
   
   如果安全不是一个共同的责任，DevSecOps就不会发挥作用。开发人员需要正确的工具、支持和培训来完成他们的工作......而这需要时间来推出和完善整体安全计划的一部分。最糟糕的方法是使人不知所措和疏远的方法，当开发人员有太多竞争性的优先事项，而没有人帮助他们管理这些优先事项而不使自己发疯时，就会出现这种情况。这是一个文化转变，而且不是一蹴而就的。
   
5. 你是否依靠少数神奇的安全独角兽来承担许多任务？
   安全专业人员是非常短缺的，我们需要的人数远远超过目前的水平。这是一个既定事实，但有越来越多的开发人员转向更注重安全的角色。通常情况下，他们的头衔可能是 "安全工程师 "或 "DevOps工程师"（慢慢地，我们会看到这个头衔演变成DevSecOps工程师，如果幸运的话！）。一个有枪的DevOps工程师能够为几乎任何应用程序开发功能，同时使用真正的CI/CD管道进行部署。他们做的都是端到端的工作，而且通常具有健康的安全意识。从这个意义上说，他们是一种神奇的人，因此也是罕见的。
   
   然而，一些公司犯了一个错误，那就是雇用这些专业工程师，把他们塞进一个团队，并期望他们在开发过程的每个阶段都能解决所有的安全问题，而这就是万能的了。让你的DevSecOps魔术师负担过重，你就会在你开始的地方结束--运送不安全的代码，而没有检查、平衡和安全精度，他们首先被雇用来执行。最重要的是，开发团队要提高技能，并在一个积极的安全环境中得到培养，这样他们就有能力以一种有意义的方式分担负担。

找到你想在你的组织中看到的变化。

如果你将强大的培训作为安全计划的一部分，你会在你的开发团队中发现一些隐藏的宝石。这些人，尽管他们在日常工作中可能有任何负面的经历，但他们对安全编码和安全最佳实践有一定的热情。这些人是团队中安全卫士的主要候选人；他们是安全和工程之间的联系点，为其他人树立了一个很好的榜样，保持了较高的意识，并有助于参与计划。他们的人际交往能力也是非常重要的，可以将安全的喜悦传播到更远的地方，并向管理层和安全团队倡导开发者的需求。

"这对我有什么好处？"对话是一个积极的进步。

即使是最崇高的人类，也需要一些 "胡萝卜 "来让他们涉足不熟悉的领域，或者一个可能没有最令人愉快的学习曲线的活动。
从 "开发 "到 "DevSec "的飞跃，对开发者的职业生涯是一个巨大的推动。有安全意识的开发人员已经努力理解安全，在他们可以控制的领域承担起安全责任，并在操作中理解到只有安全的代码才是高质量的代码。一般来说，开发人员希望改进，解决新问题，并创造令人羡慕的功能，帮助他们在同行中脱颖而出。给他们提供一条达到更高水平的软件开发的途径，这是一个双赢的局面。

建立你的开发安全梦之队永远不会太晚。

如果你管理开发人员，领导一个AppSec意识团队，或者你是众多努力设计安全计划策略的人之一，现在是比 "左移 "更好的时候了。有了正确的培训、工具和环境，你可以为开发者创造一个安全孵化器，为所有各方带来巨大的红利。如果这份清单强调了一些需要改进的地方，那么你就有了一个很好的机会，为你的组织准备一个由DevSec领导的工程部门，可以从SDLC的一开始就减少风险。

外面有一个不方便的事实，一个往往被政府、大公司，甚至一些行业领导者所掩盖的事实：作为一个社会，我们正处于一场与网络威胁的持续战斗中，而我们目前处于失败的一方。我们如何知道这一点？这些统计数据讲述了一个令人警醒的故事。

• 据估计，到2021年，网络犯罪的全球成本将达到6万亿美元。
• 每39秒就有一次网络攻击发生
• 24%的数据泄露是由人为错误造成的
• 令人震惊的是，77%的组织没有一个跨企业的网络安全事件响应计划，而且在各部门之间的应用也不一致。

谈到网络安全专家，我们的人手严重不足；技能差距不可能被填补，也没有秘密的AppSec军队来拯救我们。我们知道这一点已经很多年了，我们必须要改变我们的方法。在我们的情况下，最好的攻击是一个伟大的防御，我们可以用一个好的计划先下手为强。

这一切听起来有点令人沮丧，但它并不像一些人可能认为的那样糟糕。我们有一张王牌，网络安全环境为我们提供了一个黄金机会。你不需要在你的内部开发团队中寻找来拯救组织的人员，但你的安全计划必须支持他们成为有安全意识的工程师，准备好分担安全编码的责任的轨迹。

任何老式的培训都无法完成工作--我们当然已经说得够多了--但即使是正确的培训，如果能吸引人、建立上下文知识并帮助开发人员爱上安全，也会有效得多，只要它能针对企业的需求、他们面临的威胁以及帮助企业保持我们所有数据安全的合规要求进行策划。

而这正是我们最新的功能所在。 Courses的作用。顺便说一下，如果你明白了标题中的参考，你就正式老了（或只是欣赏经典）。

针对组织的学习：建立防御，加强开发者技能

对于为什么有些类型的开发者培训比其他的好，我们有各种各样的意见（即不要用几个小时的干巴巴的通用视频说教把他们烦死，然后期望安全编码的激情能绽放）。但是，即使是旨在吸引开发人员思维的竞争性学习，其内容仍然可能比组织内的特定需求更广泛。

一个精心策划的课程包含了你的开发人员需要显示熟练程度的确切模块，将产生有力的影响，并使他们在日常工作中的安全最佳实践中打好基础。为前端团队、云计算工程师等量身定制课程，能够以与他们相关的语言和框架，深入研究最重要的漏洞。开发人员将通过持续的背景、接触点和经验提高他们的技能，而企业将从对构成最大风险的问题的精确认识中受益。

定制符合要求的课程

世界各地都在实施更严格的网络安全相关法规，而软件安全合规性是建立积极有效的安全文化的一个重要基础。它不应该是枯燥的，一个好的安全计划会点燃开发人员的自豪感和责任感，而不是呻吟和打脸。

作为一个起点，让每个人都掌握OWASP Top 10是一个非常好的主意，但要真正达到行业相关合规的新高度，你可以围绕特定法规的要求设计一个定制课程。例如，一个金融组织可以根据管理支付和卡处理应用的PCI-DSS准则，为他们的软件量身定制一个课程，以适应其合规性要求。当你负责处理和存储像信用卡号码这样的敏感信息时，风险是很高的，而对开发人员的学习进行超具体化，则可以穿过噪音，在正确的时间提供正确的教育，并使团队的能力更容易被监控。  

这就是通用电气（GE）如何在其团队中使用Courses 。

"Courses 是我们的工程师的一个伟大的解决方案。有了新功能--将学习途径、视频和检查点捆绑到一个可定制的模块中--我们有能力根据我们在任何特定时刻的需要来塑造内容。合规能力和灵活性提供了一个更好的机会，以确保一个更加精简和灵活的过程。 这种能力帮助通用电气为每个工程师量身定做相关的培训，比以往任何时候都更快、更容易"。

请记住，这可能是精心策划的合规培训，但它仍然是以一点一滴的、有背景的、引人入胜的学习体验的方式提供的，这对开发者来说更有吸引力。

建立在尊重和相关性基础上的积极安全文化

教育是一个终身的过程，但在疯狂的DevSecOps世界中，有很多盘子要转。为培训留出的时间应该被明智地利用，有一个可行的学习路径，继续吸引和增加价值。

通过策划一个高度相关的定制课程，你尊重开发者的时间和工作流程，同时努力为企业实现漏洞和网络安全风险的可衡量的减少。

AppSec专家和工程师之间的关系传统上充满了误解和紧张，但通过Courses ，结构化的学习可以使双方在安全最佳实践方面达成一致。开发人员肯定会感谢AppSec团队提供的一些以解决方案为重点的支持，这可以最大限度地减少他们的负担，并协助他们制作出更高标准的代码。

消除弱点，扩大企业级安全卫生的规模

我们都是人，而且不幸的是，我们会犯错误。这些错误在数字世界中可能会造成极大的损失，但它们却令人震惊地普遍存在。赛门铁克的2019年互联网安全威胁报告证实，由于S3桶配置错误，超过7000万条记录被盗。安全错误配置是数据泄露的主要原因，其中人为错误占了大约四分之一。

这些问题发生的原因有很多，但缺乏安全意识和培训是一个巨大的驱动力，使小的机会窗口被攻击者所利用。要想获得具有影响力的可扩展的安全卫生，你必须通过为你的企业定制的课程使其发挥作用。对你的敌人不留情面，并关闭他们造成你可能遇到的最大头痛的每一个机会。

我们已经看到我们的客户产生了惊人的影响，包括这个领先的基于云的会计SaaS供应商。

"Courses'定制的学习途径已经改变了游戏规则。围绕编程语言和漏洞的特殊性提供了更多的控制和灵活性，以根据个人和公司的需求为每个开发人员创造正确的学习经验。将Courses 与Secure Code Warrior'更广泛的安全编码平台结合起来使用，已经改变了我们的开发人员的参与度，因为他们现在对提高他们的安全编码技能以编写更好、更安全的代码更感兴趣。"

为开发安全做好准备。了解更多关于安全代码勇士全新的Courses 功能。 这里.

软件开发生命周期（SDLC）似乎很无害；它是一个过程，我们这些软件人员一起创造了奇迹，并将所有这些社会不能缺少的数字产品运送出去。

除了......如果你曾经参与过一个软件开发项目，你就会知道这通常是一场战役，有许多任务要征服，有许多龙要杀死。这在一段时间内很有趣，但倦怠是真实的，对软件的需求使我们在最好的时候都以光速工作，尤其是开发团队。

现在想象一下，他们被抛出另一项必须完成的任务......负责他们所接触的项目元素的安全。这在最坏的情况下，可能会导致一些人的房子倒塌，但更现实的情况是，它根本没有被列为优先事项，而被认为更紧迫的问题会优先过关。当大多数开发人员没有接受过安全编码的培训时（特别是如果他们的经理也没有优先考虑安全问题的话），我们看到频繁的数据泄露，有缺陷的应用程序发布，以及一些严重的安全专业人员在错误的代码雪崩下达到崩溃的地步就不足为奇了。

开发人员需要一个AppSec的推行者。

当考虑到上述情况时，你可以理解为什么安全问题在编码过程中被放在 "太难 "的篮子里，而留给安全团队去解决。太多竞争性的最后期限，没有足够的培训，而且没有真正的理由在其他事情上关心安全问题。然而，对代码的需求实在太多，这种现状无法继续。而这正是超级精英开发人员可以从他们的同行中脱颖而出，学习新技能，最重要的是，建立更安全的代码。

然而，重要的是要记住，管理软件安全并不全在开发人员的肩上--这仍然是AppSec团队的领域（当他们与有安全意识的开发人员合作时，将有更多的喘息空间，而不是重复修复常见的错误）。一个有效的DevSecOps流程需要团队中的每个成员都能得到他们所需的支持和工具来分担安全责任，而正确的培训是最重要的。平衡正确的工具和培训套件需要AppSec专业人员的洞察力，他们愿意与开发人员密切合作，激励他们并推动积极的变化。

破坏性的培训比它的效果更令人讨厌，任何令开发者厌恶的东西都不会起作用。集成开发环境或问题跟踪器集成的解决方案是一种替代方案，它可以在需要的时候将正确的信息送到他们面前。

以下是它的实际工作情况。

及时，而不是 "以备不时之需"。

到目前为止，上下文的实践学习是最有效的培训方式，在最有意义的时候提供一口大小的块状内容。这有时被称为 "及时"（JiT）培训，对于学习安全编码的开发人员来说是非常有效的。

源于丰田的精益生产原则，JiT培训的目的是在需要了解的基础上，在最重要的时候激活。一个开发人员刚刚写的东西看起来有不适当的权限？如果一个小的后门被打开，允许攻击者远程执行代码呢？如果开发人员能够在需要的时候获取知识，而不是在Confluence中翻阅文档，或者在Google上搜索培训中提到的东西，那将会更令人难忘。

及时学习是 "以防万一 "的对立面；虽然后者是更常见的传授知识的方式，但它根本没有效率。我们必须让开发人员更容易参与到安全编码的最佳实践中来，并在保持对他们现在正在进行的关键目标的关注的同时，看到提高技能对他们的职业生涯的好处。

不要再让开发者追逐培训了。

我们已经知道在一个工作日里有太多的事情要做，因此，开发人员有什么动机要去教室上课，或者通过上下文切换来获得静态的理论培训？

普遍的共识是，无论大多数组织正在做什么，如果造成数据泄露的漏洞数量是什么的话，都不是非常有效的。Verizon公司的2020年数据泄露调查报告指出，43%的数据泄露可归因于网络漏洞。开发人员没有接受有效的培训；没有在高等教育中接受培训，也没有作为工作场所提高技能措施的一部分。如果他们接受了培训，像SQL注入和老式路径穿越这样的常见漏洞就不会被利用来获取大量数据，网络安全技能的短缺也不会失控。

所以，知道这是目前开发人员接受培训和熟悉安全的环境，为什么我们对糟糕的结果感到惊讶？这可能只是一个影响--一个积极的影响--对于开发者和组织来说，确保一个更顺畅、更综合、更不刺耳的培训体验，在他们实际工作的空间中，如Jira、GitHub和IDE中都可以获得。这个行业只需要向前发展，让安全意识变得更加容易，在这个环境中，安全意识不再是一种奢侈品。

准备好保障开发工作流程了吗？

具有安全意识的开发人员因其技能而备受推崇，他们在代码构建阶段就能为企业提供保护。安全不再是可有可无的东西，尤其是 GDPR 罚单、PCI-DSS 合规法规、NIST 治理......以及被起诉的可能性，就像 Equifax 那样，被提起数百万美元的集体诉讼。

一个综合的方法可能是催化剂，开始用较少的破坏性学习来赢得开发者，并为更深入的courses ，培训安全卫士，以及普遍激发我们需要的共同责任来保持世界的数据安全和健全。

现在就下载Jira和GitHub的整合工具，并让我们知道你的想法。