应用安全介绍之Apiiro

       在2021 RSAConference2021大会上，Apiiro不仅入选了创新沙盒的十强初创公司，最后还拿到了冠军，荣膺“RSAC 2020最具创新初创企业”，显示了软件供应链安全的强劲态势。Apiiro是一家安全开发生命周期（SDLC）管理厂商，成立于2019年，总部位于以色列特拉维夫。公司的产品是Code Risk Platform，对代码风险做管理，由于两位创始人最早是做UEBA的，所以，把很多UEBA的思想融入到了代码管理中，也可以看出跨界融合对创新的推进作用。整个产品的创新点是对应用程序的多维分析，发现恶意代码提交，本质上都是UEBA技术思想在开发管理上的功能体现。Apiiro很强调对漏洞的分级，认为没有必要对漏洞统一对待，这个和Wabbi的观点类似，都关注解决重要的漏洞问题，其他的可以作为安全债务来延缓解决。第二个地方是两家都强调上下文关系，认为各个工具单纯地扫描漏洞，但彼此没有关联，各自孤立，实际是浪费了资源，降低了效率。

        绿盟科技的博客，http://blog.nsfocus.net/rsa创新沙盒盘点-apiiro-代码风险平台/，对产品做了详细说明，但看完还是有点懵，对产品具体能做什么仍然不是很清楚，同时，在网上也找不到别的资料，只好重新去官网，看看人家到底做了什么，怎么做的。

官网主页内容

        从设计到代码到云，每一次变更，完全的风险可视。

        业内第一家代码风险平台，横跨应用、基础设施、开发人员知识&业务影响，360度视角观察安全和合规风险。

一个平台

• 完全风险可视

        数据驱动的决策才是更好的决策，从设计到编码到云，通过实时的应用&架构编码行为清单，开发知识，第三方安全报警&业务影响，了解你的安全&合规风险。

1. 我有多少应用

2. 应用部署在哪里？

3. 谁占有代码，他们的安全经验如何？

• 关注最重要的风险

        安全架构师们没有时间去检查每一次变更&调查每一个报警。利用他们的专业知识，跨开发人员，代码&云，分析上下文关系，发现风险资料变更&自动化构建可操作的工作计划。

1. 通过安全、合规&业务风险优化应用

2. 做出基于风险的修复决策

3. 计量你的应用&云安全程序的效率

• 自动化治理和风险修复

        没人喜欢人工调查风险问卷，安全&合规检查—太琐碎了，不精确&和编码不同步。当设计代码时，我们必须做的更好，触发上下文的&自动化工作流。

1. 为了安全检查而优化变更

2. 缩小渗透测试范围

3. 减少SAST工具噪音

4. 修复有风险的材料变更

5. 发现云错误配置

6. 保证监管合规

风险永远不会消失

        不管你是否拥有成熟的应用&云安全程序，Apiiro会持续帮助管理你的所有风险，从设计到编码到云

Apiiro 产品功能

如何工作

• 设置

Apiiro通过只读API，连接在本地和云里，所有的资源控制&ticket系统

可选择的：第三方应用安全工具，API，Webhook。

Apiiro 提供定制的，预定义的，自适应的代码管理规则

• 学习

Apiiro 持续学习所有的产品、项目、代码库，打造一个清单，识别有风险的资料变更

开发人员知识，业务影响，应用代码，基础设施作为代码，开源代码变更，docker/k8s，第三方数据导入

• 安全

Apiiro 使用自适应代码管理规则，保证每次代码提交都保证合规、隐私和安全。

Apiiro使用你当前的工具集，在设计/开发阶段，CI/CD之前，自动地触发修复工作流。

读到这里，我还是不清楚这家公司如何实现这些功能，但网站没有别的产品介绍了，只能看网站上的blog。

 

介绍Apiiro，重新发明安全开发生命周期（SDL）

Idan Plotnik ，CEO    2020年10月13日

在信息安全行业将近20年，两次被收购，对我和Apiiro团队来说，我感觉现在是一个独一无二和令人激动的时刻。

一切都是源于变革，始于Apiiro从技术和商业上痛苦的背后想法，当我们从瀑布开发方法到微软的敏捷开发所感受到的痛苦。

在每一次应用和基础设施变更的时候，我们评估在设计上的产品风险。通过人工和周期性的安全检查，和使用“开发者最末”的方法的合规流程来实现，“开发者最末”的方法同时让开发人员和安全人员感到恼怒，从业务的角度，这个流程降低了我们扩展业务的速度。

我们决定，是改变的时候了！

我们前进，去解决CISO和CIO面临大范围的挑战。我们想打造一个新的方案，通过打通开发、安全和合规团队的鸿沟，加速交付和上市的速度。

从瀑布向敏捷转变的过程中，我们学习到的一个重要的视角是代码就是设计，这也是为什么我们重新发明了SDL，从手动的开发者最末的方法，向自动的基于风险的开发者优先方法转变。在这里，开发者在提交阶段，实时收到关于安全和风险问题的了解。没有延迟，安全是设计及开发的一部分。

我们打造了业内第一家代码风险平台，允许产品安全架构师，安全捍卫者，和开发人员，在上线之前、应用和架构的每一次变更，都能够自动化实现可视化、合规保证和风险修复。

我希望能一起重新发明SDL，开发者、产品安全架构师和安全捍卫者、云架构师、渗透测试人员、风险管理人员，大家一起。

 

SDLC和DevSecOps，向持续和同步模型转变

Russell Miller 市场总监2020年12月17日

工作一直在变得更快，公交车上，人们使用手机来工作，在电影院里检查自己的社交账户。人们希望在他们想要什么的时候就能得到什么，这也许不是事情该有的样子，但确实是现实。这种高速的文化也影响了商业世界，公司也希望更快的交付，保证客户的满意度和竞争力。

十年来，软件开发一直在进化。

软件开发模型几十年来持续在进步，从瀑布，Spiral，V模型，到今天的敏捷。在进化的每一步，都有一个使用最新框架的自然趋势，感觉好像你已经达到了性能的顶点，但总是有人继续超越，发明或发现下一个潮流。DevSecOps是当前集成安全到软件开发中的主流，但这并不是最终状态，趋势仍然是线性和向上的，必须变革。

DevSecOps 进化—持续但有序

        当我们转向敏捷，我们看见从排序转移到持续的巨大价值，我们也能够调整和采用我们学习到的新的信息，DevOps和DevSecOps基本上一致，常常看到他们用一个莫比乌斯环来代表。但增加了安全，

这就是摩擦点，开发和安全团队看到了一个持续循环，相信我们已经来到了游戏末期，但这个方法仍是一系列独立的步骤，按照次序进行，尽管一直在重复。

进化到持续和同步的方法

没有什么还是线性的。代码就是设计，每一步都会影响其他步骤，通过同步处理数据，我们能学习更多，生产更多，更多正式的决定。安全要求和威胁建模能够指导什么时候和哪里去执行SCA和SAST扫描。同样，扫描结果能让我们知道在我们的设计和威胁建模中，我们在哪部分错过了关键因素。通过集成和协调这些阶段，DevOps流程能够被更新成这样：

借助于转移到持续和同步模型，我们能够改善整个DevOps流程的速度，减少所浪费的步骤、时间和费用。想像一下，当确切知道代码中，哪里会发生风险资料变更时，做一个威胁建模会是什么感觉。

关注最重要的事，当它重要时

       你能够集中你的时间和资源来保护最重要的事情的安全，同时，识别出哪些并不那么重要，只是有点儿帮助而已。如果一次新的代码提交更新了一个微服务，不包括PII（Personally IdentifiableInformation,个人可标识信息），也没有部署在通过互联网API可以访问的公有云里，为什么还要对这些代码和有风险资料变更做同样的流程呢？可以把时间和金钱花费在别的地方。你应该更仔细的检查一个有经验的安全开发布道者，还是检查一个新手开发者呢？

是时候该从盲目地跟从当前的流程走开了，每次代码提交都不同，每个开发者都是唯一的，也该独特地对待他们。

 

重新思考DevSecOps，向基于风险的SDLC迈进

Russell Miller  2021年3月2日

安全和合规如何集成到开发生命周期中，需要彻底的重新审查。组织陷入到一种“打钩文化”和漏洞驱动的心态，以实际上风险降低为代价，尽力去维持安全和合规。CISO和CIO常常有利益上冲突，而安全，常常看起来像一个拦路虎，影响了通过数字化转型来加速交付。现在所需要的是一个新方法，能够从整个开发和DevOps流程中，分析数据，来识别、排序、修复最重要的风险。我们称之为资料变更。

在许多方面，缺少基于风险的决策是可以理解的，因为现存的应用和云安全工具无法给CISO，安全架构师，开发人员提供一个准确的风险图景。

当前DevSecOps方法无法完全自动化应用和云安全流程，因为它是周期性的，资源密集型的，无法扩展的。为了对生产发布变更，你仍然需要威胁建模，安全和合规检查，渗透测试，风险评估。这些过程都是人工的和不准确，因为他们基于自我确认。借助于聚合不同工具的数据，许多平台宣传简化了DevOps引入安全的流程，但事实上，他们只是绑在了当前的流程上，保持孤立，比以往生成更多的报警（许多都是误报）。

把安全集成到DevOps，交付DevSecOps要求，改变了思维、流程和技术—Neil Macdonald Gartner

今天，人们过于关注扫描工具的漏洞检测上。组织常常有自己的策略，达到某个分数的漏洞，或者某些类型的漏洞，在代码部署到生产环境之前需要被修复，完全不管是否一个漏洞在代码的不重要位置，完全不可能被利用，或者是否他能将敏感信息暴露在互联网上。

一个更好的方法是理解一次新代码提交的整个上下文，从设计到上线，处理的方法是反映它真实风险，而不是通过同一个CD/CI管道运行所有代码。想像一个开发人员，做一个功能，增加PII到现有的API，现在这个API变得很敏感，了解这个API认证，授权和加密，API输入验证控制对于做出基于风险的决策非常重要。

修复当前的SDLC方法非常难做，人们很自然地会关注他们面前的风险，不会考虑错过一个漏洞的个人后果。我们需要有一个组织范围的框架，决定什么时候，在哪个地方接受风险，然后自动化决策过程。实现这个的方法是使用正确的信息和上下文。安全，开发，法律团队需要更好的了解他们的代码，从代码的历史，从基于Jira ticket所提供的上下文信息，到Slack新功能对话。对开发人员本身的了解也非常重要，从他们的技术经验，到安全知识。当你对自己的风险有一个更完整的了解，你能够聪明地区分变更，采用合适的方式处理。

当你完全的理解历史和上下文，你会了解Gartner的建议：

不要试图移除你代码中的所有未知漏洞，那会提高误报，而是让开发人员关注最危险，最有信心的漏洞。

这样做会改变你在整个软件开发中使用的安全方法。是一种思维方式转变，使你停止把安全思考成一个打钩工作，而是一个明了上下文的流程，更好的和你的业务战略，对风险的容忍度保证一致。

你能够提高安全，充分利用你的大多数资源，更快地交付。如花旗集团（Citigroup）前CISO，Charles Blauner所说的，最后你可以走到你的CIO面前，告诉他说，“我有一个方法，可以使你生活得更好”

 

 

应用和云安全中的可视化，创新的条件已经成熟了

Russell Miller 2021年3月11日  

       更好的信息导致更好的决策。这不是一个特别大胆的声明。但同时，我们有一个倾向，在我们狭窄的领域里寻找数据，然后……只是更多的数据，更多的领域，更多的报告，更多的仪表板。我们不是经常有机会去后退一步，重新评估你实际上需要什么去做出更明智的决策。问到“我如何能完全了解应用和基础设施的风险”，不是一个简单的问题，不仅需要一个简单的答案。

       在应用和云可视化方面，还有很多重大的创新空间，安全从业者需要更多的创新。

       CISO、安全架构师，工程副总裁，和管理人员，都想更好地了解他们的应用，包括代码组件，安全控制，数据，业务影响。说起来容易做起来难。

       DevOps已经赋能给开发人员，更主动，更加创新。但这个灵活性的缺点，从代码标准到流程，过程，和技术，很难强制多个独立团队的一致性。打造一个微服务时，一个开发团队会很自然地采用手边最适合的工具，而不是考虑长期的对多个团队的影响。但开发人员面对更快交付的压力是有后果的。

       技术扩张有一个长期的战略影响。开发、安全、法律团队需要跨框架和语言，了解最新的安全和合规问题。使用多种技术实现密钥管理、认证、授权和加密，导致临近领域不必要的碎片。所有代码组件的可视化是绝对必要的，要求了解你的风险，但这个等式还有更多。

       了解代码本身是必要的，但不幸的是，那也常常是思考停止的地方。为了对应用和云安全有一个真正业务级的影响，我们需要扩展技术和代码以外，因为风险是多维的。了解单个开发人员对一个功能的开发，可以成为做出更好决策的关键。对ticket系统中数据、拉取需求讨论、云配置等也同样适用。

       真正的应用风险可视化，要求端到端来的清晰性。从设计到代码到云。所有阶段的数据能帮助在开发过程的早期，做出更好的决策，提高安全，减少不必要的返工。

       也要考虑到开发人员经验的可视化，能帮助提高安全和开发过程的效率。当一个风险材料变更被发现，找到最佳人选去调查和修复问题非常关键。你需要了解哪一个开发人员在特定技术、语言，安全控制甚至某个功能上的经验，除此之外，你需要理解其他开发贡献者的角色，包括QA，DevOps，产品经理等等。还有他们如何对应用做出贡献。换句话说，找到合适的人做正确的事，你需要了解这个人、这个团队还有这份工作。“四处打听”，不是一个可接受的，或可扩展的方案

        除此，许多组织正在建设安全捍卫者计划，有经验的安全专家被安排到每个开发团队中，深入了解开发人员的优势和劣势，对程序的成功非常重要。你的安全捍卫者应该有适合团队的技巧，这样他们能给正确的人提供正确的辅导，他们也能更好的了解什么时候，最需要他们的专业知识。

        因此，数据驱动的决策才是更好的决策。但不要被你眼前的东西限制。有巨大的潜力去提高我们对代码和围绕着代码的上下文的了解。要求更多。

 

安全警报：开发人员没有更好的事情去做吗？

Erni Avram  2021年3月16日

       在过去的二十年，随着移动应用，web，云应用的崛起，可采取多种部署选择，如本地，混合，云的方式。我们看到了针对SDLC流程和工作流，安全工具使用量的增加。不幸的是，这些工具常常产生很多误报，导致时间的浪费和明显的挫折。

       主要目标之一就是在SDLC生命周期中，尽早的发现和修复安全漏洞（称之为“左移”）。从而减少修复漏洞所需要的时间和资源，如果这些漏洞是在生产阶段被发现的，也不会对品牌的知名度产生负面影响。因为在经过一定时间之后。开发团队很难“记住”他们做了什么和如何修复这些漏洞。

       随着软件开发向“敏捷”工作流的转变，产品/功能/修复的交付已经快速提高，在软件开发生命周期中，安全工具使用有一个同步的增长，比以往都更高频率地使用这些工具。

       包括静态分析、模糊测试、动态分析、其他的安全工具是CISO和安全架构师团队的默认手段，希望把安全集成到SDLC，目标是在产品开发过程中，希望尽可能地发现那些安全问题。

      不幸的是，更多的攻击，意味着更多的报警，这些工具结合在一起，能生成成千上万个报警，研发团队花费相当多的时间检查和分类。因为这些工具缺少代码流上下文信息，无法互相集成，也不能真正了解的源代码，会生成大量的误报。

处理安全报警对开发人员和安全架构师是一个无法完成的任务，要求他们投入大量的时间和资源。考虑到敏捷开发周期，更快的提交代码，开发人员和管理人员想最大化的使用时间。

       当把大量的信息识别为误报，一个接一个识别误报的过程中，让检查者心累，无心深入研究，导致错失一些真正的安全漏洞。

        安全、开发、法律团队需要更好地了解他们的代码，从代码库的历史到Jira ticket提供的上下文，再到Slack新功能的对话。开发人员自己也非常重要，从他们对某个技术的经验，到安全知识；从设计阶段到开发阶段，通过上下文分析代码是如何设计，最后如何被编码，整个图景的可视化，可以最小化误报。例如，了解API设计，哪个服务被涉及，如何被编码，有助于降低误报率。此外，有了这个可视化，我们能够对代码变更做优先级排序，让安全团队关注最重要的，获得更好的更精确的警报。

       这样做将会改变安全在软件开发中的整个方法。帮助你停止把安全看成一个打钩的工作，更是一个上下文感知的流程。你会有更少，但更关联的报警，更少的误报。这会帮助开发人员更好地利用他们的时间去-开发。

 

代码风险是多维的

Erni Avram 2021年3月25日  

       今天，每件事都是代码！从开发应用逻辑，向数据模型增加PII，更改网络策略，添加IAM 角色，到在云API网关中发布新的API，配置授权控制。

       当考虑到代码风险时，我们倾向关注并局限于漏洞和检测工具，像SAST SCA DAST IAST，甚至是把他们连接在一起的编排工具。

       只依赖这些工具非常误导，因为错过了大量的上下文关系，导致产生很多噪音和误报，减缓了开发人员的进度，阻碍了数字化转型。

        有多个安全开发生命周期进程门，每一个独立运行，看起来一个应用安全程序和其他有很大的不同。

         大多数时间，我们检查每个门，但并不看所有开发阶段上下文。资料代码变更和配置需要结合在一起，才能生成一个漏洞。这要求考考许多因素，从设计到代码到上线。

        从单一的维度看这些条目，不会给我们一个完整的视角，因此也就会生成误报。最后的结果是开发人员、架构师在浪费时间，分析误报，导致对这些工具的信任缺失。

       不从漏洞的角度来看风险，而是从实际的业务风险。这要求一个扩展的对上下文关系的理解，我们能区分不同类型的风险维度：

单维度分析

       在SDLC流程期间，在指定阶段，公司在工具适合的特定阶段，触发了工具的执行（例如，  CI/CD中SAST）。白盒在单个时间点扫描代码，构建了所有可能的代码流排列，但只关注漏洞和忽视了代码组件、数据、安全控制，部署地点、开发人员经验、业务影响等。导致发现大量的问题，相当比例是误报。

       开发人员，安全架构师和应用安全工程师，浪费了时间去调查问题，最后证明是误报而导致沮丧。此外，当人们丢掉了使用工具的信心后，也就不严肃对待结果。在大多数情况，研发人员可能会对CISO和应用安全管理者表达负面情绪，使安全处在一种没有赢家的局面，通常是根据监管要求，坚持持续使用工具，仅仅因为我们需要用一些东西。

        另外一个问题是软件成分分析工具，用来发现、治理、监控开源许可证和依赖组件中的安全漏洞。这些工具也缺少一个多维的方法，只看被包含的包，他们不知道是否代码正在使用以前提过的开源组件漏洞代码路径。而且，没有考虑这是否一个敏感的依赖，因为开发人员的经验或者它的本质（认证框架），把这段代码加入到源代码中。

多维风险分析的好处

       考虑代码风险分析的多维方法，能减少和优化这些进程，只关注SDLC工具和流程中中最重要的变更，通过收集多数据源的数据，打造一个完整的多个元数据组成的上下文概述。我们称之为“有风险的资料变更”。

       例如，基于历史代码变更，对每一个开发人员，都做一个知识和活动的概况描述，能有助于更好的决策。这包括他们已经提交了多少代码变更，这些是否是安全相关，是否有任何业务影响。我们也能考虑到数据处理，部署位置，互联网暴露等其他因素。

       结合上述这些条件和更多内容，我们使用一个上下文关联模型，能输出一个多维的风险分析，帮助安全架构师和开发人员重点关注最重要的变更。

有助于公司中不同的角色:

• CIO和CISO能得到一个高水平的，上下文关联的业务真实风险概况

• 安全架构师和应用安全领导们将收到一个可操作的工作计划，关于高业务影响风险资料代码变更，安全工具能够更集中扫描这些变更的代码，快速得出结果

• 渗透测试人员得到一个前后关联的和风险资料代码变更关联的报警，允许他们开始增量的渗透测试

• 开发人员工作于应该被解决的，对产品有实质影响的安全发现。

• 法律/合规能更容易和精准地识别合规问题，如开源软件许可证、版权、以及通知文件。

 

检测和阻止对PHP代码库的恶意提交

Gil David 2021年4月5日 

动机

       3月28日，周日，PHP团队的成员发现，使用被泄露的合法的开发人员身份，对解释器提交恶意代码，还有git.php.net 服务器。

我们的方法

       在Apiiro代码风险平台，一个功能就是使用UEBA和异常检测技术（专利申请中），检测和阻止对代码库的恶意代码提交。这个能力基于机器学习和人工智能算法，分析组织中不同实体的行为（代码组件，安全控制，数据类型，贡献者的知识能力，组织行为，代码库，项目等）。

       算法提取了许多面向域的功能（包括逻辑，上下文，时间序列特征功能），打造每个实体的多维的特征。功能采取了各种源。例如元数据和历史提交、拉取请求、ticket，都被完全分析，提取他们的数字，时间顺序，文本特征，算法所需其他数据源是我们自己平台生成的跨多个软件库的历史代码分析，一旦功能被抽离出来，根据我们自己领域专业知识丰富，Apiiro打造和训练了一个实时的自适应性行为模型。

        除了组织中每个实体的单个模型，Apiiro的算法训练更高水平的模型，用来加强检测到事件的可信度。这个方法我们能实现对恶意活动的高检出率，降低无关异常行为的错误检测。例如，对比一个开发人员的行为和类似群体行为，能看清个人活动的合法性。

       显然，我们无法发布我们平台在客户环境中检测出的恶意活动，几天之前，在php源代码库运行我们产品，我们能够检测针对php src（PHP 解释器，Github中受欢迎的开源代码库）的攻击。

攻击

       3月28日，一个名为“rledorf”的合法贡献者恶意提交被推送到代码库，代码的恶意片段被添加到zlib.c中，检查传入的HTTP包中的HTTP_USER_AGENT头（x2T被攻击者精巧利用），如果这个数据包头由字符串“zerodium”开始，字符串的其他部分将会在服务器上作为PHP代码来执行。通过这种方法，攻击者能够在运行更新php src版本的服务器上，注入和运行强制性的PHP代码。

       感谢代码库贡献者的负责任的审查，对这次提交的代码进行调查，赶在更新代码上线前几小时，删除了恶意代码。

        Apiiro代码风险平台使用UEBA和异常检测技术，检测了最初的对PHP 代码库的恶意提交（学习了4400次提交）， 

检测和阻止

       Apiiro能够基于被攻破的用户的异常行为，检测恶意提交。我们的异常检测算法把这次提交标记为怀疑，根据他过去的行为，和代码库中其他贡献者的行为，偏离了这个用户的常见行为。触发了我们算法的一些异常检测的指标为：

1.  提交强度不符合贡献者最近的活动

2.  提交时间和有用户正常的提交时间有偏离

3.  贡献者和代码库中他所属的组的常见特征有偏离

4. 提交信息和被分析的代码之间有很大的差异

5. 增加的代码和这个代码库模型预测的有明显不同

        Apiiro自动实时的检测，对语言和主机都不可知。一旦我们检测到了攻击，我们的平台能够对有怀疑的提交PR上自动做出评论，甚至在安全操作中心Slack中触发一个报警。

错误报警

       异常检测系统的一个关键挑战是维持一个低的误报率。在过去两年对php src库的分析中，我们的平台触发了4次有怀疑的事件，只有一例涉及到一个主要的代码增加，以及一组标记的高风险。就是我们在本文中提到的恶意提交。我们平台低的误报率让运维人员集中精力在大量怀疑事件中，不会被无尽的无关 异常行为所淹没。

总结

       Apiiro的异常检测算法通过分析不同实体各种各样的活动行为，能够成功的检测恶意提交，保持一个极低的误报率，本文证明了Apiiro的异常检测能力，被我们客户使用，保护他们代码库的安全。

停止同样地对待所有应用

Russell Miller 2021年4月9日 

       我们有一个集体优先级的问题，当分析单个应用时，这是正确的，跨多个应用的时候也是如此。组织不是很擅长细微差别，他们倾向根据固化的流程来思考，忽视风险和潜在的业务影响。不幸的是，这个方法对应用风险有实际的影响。

        考虑一个组织内部开发应用程序的名单，会包括从客户移动应用，到合作伙伴门户，内部的交易算法，人力资源网站，设备要求app等。

       现在考虑你的应用安全程序如何处理这些应用，处理所有这些应用，多少流程和步骤是相同的？如果你要增加或更改一个现有的功能，你可能必须填写一个风险调查表，但你需要回答的问题数量，根据应用对业务的影响都不一样，如果你执行白盒扫描，根据应用的业务影响，你有不同修复要求吗？答案是不，你曾问过你自己为什么？

        在某种程度上，这是可理解的，因为量化一个应用的业务影响不是一件小事，主要基于人工输入，在许多情况，你根据自然的本能来区分应用可能是不对的，因此你需要看看代码！

        下面是一些例子，你也许会在你的代码和配置中发现，对于理解应用的业务影响非常重要：

• 开发人员的知识和专长

• 数据（PII 支付，PHI）

• 部署位置（云/本地）

• 用户身份（消费者，厂商，雇员）

• 代码中的敏感信息（密码，PIN  API key）

• 可能暴露敏感数据、面向互联网的API

       如果你调整自己的流程适用于基于风险的，业务影响感知的，你的应用安全工程师、安全架构师、开发人员将更有效率，在不重要的应用上花费更少的时间，在重要的应用上面花费更多的时间，最后有助于更快发布更安全的应用。

       无论何时你执行一个安全任务，问问你自己，所做的工作是为了应付流程，还是事实上减少组织的风险。如果你曾经发现你自己在做前者，认识到那不应该是这个样子，并大声讲出来。

        Apiiro正在改变行业，关注应用风险，而不是关注应用安全，加入我们，一起革命。

关掉你的应用安全程序

Russell Miller 2021年4月22日 

       不，我没有开玩笑，关掉你的应用安全程序。在和数百家组织和多个分析师公司聊过之后，一件事情变得很清楚了，他们不是很有效。那不是说安全不重要，而是比以往更重要。SolarWind和PHP攻击已经提醒了我们，但管理层和董事会讨论并不关注安全，他们关注风险。

        为保持相关性，安全专家们需要提高思考和信息水平，和管理层做出决策的过程保证一致，做到这一点的方法就是关闭应用安全程序，打造应用风险程序。这样做，安全从业者能更好地参与到董事会的业务讨论中，这将驱动真正的数字化转型。

        也许这看起来有些学术化，但一个可怜的表达能导致错误的决定。向应用风险程序转移，并不只是字面的意思，也是一个技术、流程、观念和文化的转变。谈论“安全”，大多数人很自然地会关注漏洞，意味着一种僵化的观点，导致一些问题，如“你已经关闭了CVSS 分值大于7的漏洞了吗？”任何人花了足够长度时间对漏洞分类，调查和修复的人都知道，扫描分数不会和应用程序事实上的业务风险有任何关系，太多的时间被浪费在寻找缺乏现实风险意义的漏洞上了。

        应该询问的正确问题是，“我们的应用安全和我们的业务目标及对风险的容忍度是否一致？”

       从遍布整个组织的大量安全工具中得到的风险评分，让我们关注点集中在错误的事情上。扫描发现的结果，被指定到个人去修复，根本没有考虑到对真实世界的影响。例如 ，一个SQL注入发现也许有一个重要的扫描评分，但这个标记没有说明整个故事，这个应用面向互联网吗，应用包含PII吗，如果是，这个PII被面向互联网的API暴露，有正确的安全控制吗？在许多情况，一个得分为5的漏洞，比其他得分为10的漏洞更重要，取决于上下文环境。

        除此之外，一个真正的基于风险，左移的方法将关注风险资料的变更，在PII需求变成漏洞之前。例如，当一个新的开发人员改变了负责转账的敏感模块的逻辑，安全和开发团队自动地发起一个安全检查。这不是一个漏洞，这只是可能引入业务风险的上下文变化。当一个UI元素被变更，只会加快上线的速度。

       在高效的组织中，安全并不是消除风险，如果安全需求过于沉重，影响开发的速度和用户体验，就会出现更多的安全性。安全的角色是对业务的安全和合规有深入的了解，提供保证业务的合适的安全水平。这要和业务领导人一起工作，了解业务目标，从增长需求到风险容忍度。

        随着2021年的进展，前瞻性思维的安全团队正在向理解和评估业务对风险的偏好转变，采用一个过于严格的要求会阻碍进程，影响创新，甚至边缘化安全。如果你的组织交付软件的速度提高20%，但风险也随之增加20%，组织会更好吗，这是一个业务决策，不是一个安全决策。

       当你打造一个应用风险程序，记住，不仅需要关注软件，还有关注整个开发流程。代码是非常重要，但只是全景的一部分，要准确了解风险，需要深入了解开发人员和他们的知识，需要了解从用户故事到提交信息，到拉取需求讨论到API网关的设置，简而言之，要求深入了解你的SDLC流程，从设计到代码到云。

 

对整个SDLC，做基于风险的变更管理

  Russell Miller  2021年5月4日

       组织有很多原因，更改他们的应用、架构、和业务优先级，如客户要求新的功能和使用者发现缺陷。策略也随之更新去适应变化的市场条件和竞争动向。技术过时了，被最新和最好的技术替代，法规要求也更新，应用环境变得复杂。任何个人都不可能理解变更的影响，以及它会如何影响整个系统。我们需要有一个全新的，基于风险的方法，来实现对SDLC的变更管理。需要从设计，到代码，到云。

        希腊哲学家赫拉克利在公元前500年说过，“唯一不变的是变化”。因此人们似乎永远都在努力同变化做斗争。但新的变化是变更本身的速度以及应用和IT环境的复杂度。应用的改变不再孤立进行。单个的微服务或许和其他的多个微服务有关联。敏感信息也许暴露在一个应用的多个部分，被不同的API暴露。API网关的配置能够决定是否特定的代码和数据被合适的认证和授权控制所保护。

        变更管理的目的是了解、控制和适应变更。在安全领域，这要求了解每次变更是如何影响系统的可用性、完整性和保密性的。为了有效，变更管理需要包括所有影响和被影响的信息。对今天的应用程序来说，基于自我确认的变更管理系统是没有意义的。仅关注于代码或云环境的变更管理系统也没意义，这个“系统”包括整个的SDLC，从设计，到代码，到云。

        考虑到在现存的高业务影响应用数据模型中，增加PII带来的改变，为有效地理解变更的风险，你需要了解数据如何被访问和保护，是否被API所暴露？API是面向互联网的吗？这个API的安全控制是什么？是否被API网关或者作为代码被执行？

        变更管理程序的最佳实践不仅仅分析正确的输入，而且还保证合适的人被引入到决策过程中，个人的角色和专业知识是流程的关键部分，保证在合适的时间做出正确的决策。

        例如，当一个用户故事被指定，需求符合开发者的安全和合规知识能力吗？是否开发者是一个新人，或被指派在一个不熟悉的语言中编程？如果正在对一个安全控制做变更，是否有其他适合的开发者或安全冠军，帮助编码或检查变更。

        无效的变更管理导致对业务中变更的风险和影响的误解，在一些情况，具有明显业务影响的高风险变更可能被忽视。这会导致经济损失，品牌和声誉的影响，法律曝光或更多。

       在其他情况，时间或许被浪费在似乎看起来重要但实际并不重要的变更上，这影响了功能交付的速度和收入，这两种情况都可以通过适当地更改变更管理流程来避免。扩展从设计到代码到云的流程，对有效的应用开发和业务增长非常重要。

 

应用安全是战术性的，应用风险是战略性的

Russell Miller   2021年6月1日

       “安全”和“风险”常常被互换着来使用，这是一个错误，从董事会层面的关于数字化转型的讨论，到关键业务应用的变化，再到底线，都有切实的影响。所有类型组织里的管理层和董事会成员，自然地就了解这件事。管理层的业务对话，会涉及到收入预测，和实现这些目标伴随的风险。简单地说：董事会不关心应用安全，他关心应用风险，包括安全和合规。

       真正了解一家公司的最好方法是读它的年度报告（美国证券交易管理委员会10-K表格）（注：10-K 表格适用于美国上市公司。 在每个财政年度末后的90天之内（拥有75million美元资产的公司必须在60天之内），公司要向美国证券交易管理委员会US Securities and Exchange Commission （SEC）递交10-K表格，内容包括公司历史、结构、股票状况及盈利等情况。年度报表(10-K表) 季度报表(10-Q表) 当期报表(8-K表)）10-K表格都会有如下开始格式，而且也没有更好的方法来描述风险对商业世界的重要性。（以下是苹果公司的例子）：

       条目1：业务

       条目1A：风险因素

       在条目1A中的风险因素包括任何能真正影响业务的因素。范围非常广，包括从安全和合规风险，到通货膨胀和全球宏观经济状况，下面举一个苹果公司报告里面的例子：

       “本公司的全球业务受制于复杂且不断变化的法律法规，这些法律法规涉及的主题包括但不限于：反垄断；隐私、数据安全和数据本地化；消费者保护；广告、销售、计费和电子商务；产品责任；知识产权所有权和侵权；数字平台；互联网、电信和移动通信；媒体、电视、电影和数字内容；第三方软件应用程序和服务的可用性；劳动就业；反腐败；进出口贸易；外汇管制和现金回流限制；反洗钱；外国所有权和投资；税收；以及环境、健康和安全。”

       苹果公司进一步说明“这些法律和法规的合规，也许是繁重和昂贵的，增加了公司全球运营的成本”。

        这就是董事会层面对安全的看法，作为一个更大框架里面的组成部分，去了解和减轻风险。

       很久以来，“安全”一直把自己看成一个和其他业务风险完全不同的元素，需要被单独评估，优先考虑，给予资金支持，但这在现实中是没有根据的。安全本身不是目的，只是计算业务风险的一个组成部分，就像一个来自新竞争者的挑战、不断变化的买家情绪、市场波动，或者甚至一个传染病。需要承认的是，安全有一个道德因素，对客户数据负责，有义务去保护他们。但没有一个安全系统是完美的，需要根据风险来决定优先级和预算。

        这是一个问题，因为考虑到安全和考虑到风险，常常导致不同的结论和不同的行为。安全是战术的，关注于攻击防御，近乎于痴迷去发现、分类和修复漏洞，常常基于扫描或编排工具的结果。忽略了上下文、细微差别、以及和人为因素及业务目标的一致性以及许多其他相关风险因素。

        基于风险的思考是战略的。它权衡实现增加收入的业务目标、减少潜在和当前的风险的自然愿望，而在今天这常常通过加速数字化转型来完成。业务需要更快的发展，而那样，也带来带来额外的风险。

       对许多人来说，这也许听起来有些争议，但是安全组织的角色，不是和其他优先级事务分开，在真空中最小化、甚至减少风险。它是评估风险并给业务领导人提供选择。在一些情况下，管理层需要选择在整个组织内，去实施严格的安全控制，甚至以牺牲速度作为代价。在其他情况，安全团队需要尽最大努力去减少风险带来的限制。关键是：关于风险的决策是业务决策。

       许多安全专家常常相信，他们的关注点只得到了短期注意，而对开发工作的目标和速度给与了更大的优先级。这也许是100%正确，但同时也是对形势的误读。小公司的CEO和大公司的管理者都同样了解风险，开发团队的领导和IT系统的负责人也同样了解。但他们的观点完全不同，安全的焦点从漏洞向风险转移得越快，也就能越早的在业务决策中有自己的一席之地。

 

代码中敏感信息的秘密

   Igal Kreichman 2021年6月9日

       发现代码中的敏感信息，听起来很简单，不是吗？只要寻找像“password”，“token”，或“API_Key”。或者挖掘得更深入一点，搜索常用的密码，寻找随机生成的特定长度的字符串。

        不幸的是，有更多的工作要做。在了解代码中敏感信息的影响、在第一时间找到他们，不被无休止的误报所淹没，都有很多细微的差别和复杂性。下面是我们遇到的最常见的问题，我们希望他们会帮助你更好的了解为什么代码中的敏感信息如此重要，以及您能做些什么。

为什么这变成了一个如此重要的问题？

       软件开发已经变了！工程师们不再只在自己的台式机或者笔记本电脑里，自己写自己的代码。当一个攻击者攻破一个设备，仅仅访问本地存储的文件。基于云的开发已经改变了安全模型，开发人员常常扩展自己的访问到整个应用。随着DevOps的崛起，同一个开发人员有能力对生产环境做出更改，现在单点身份被攻破对整个应用和基础设施的安全能够造成灾难性的影响。

管理代码中敏感信息的步骤是什么？

为什么开发人员把敏感信息放到代码中？

        说起来容易，开发人员应该更小心，更好的遵循最佳实践，但事实是，开发人员处在日益增加的交付压力之下。把token和口令硬编码只是暂时的方案，等有更好的方案就会……，但随着下一个任务的到来，这件事就被忘记了。

       此外，开发人员不是总能看到自己的代码被部署到哪里，因此他们没有一个端到端的安全视角。或老的代码能按照从来没有被开发人员最初预料到新的方法来部署。同样常见的情况，希望在开发环境中存储敏感信息，不要进入到生产环境中。

我们在哪里能发现敏感信息？

       你可以在许多地方发现敏感信息，包括：

1. 源代码

2.  配置文件

3. 架构即代码

4. 测试代码

5. 文档

6. 包管理文件

7. 脚本

8. 项目文件

       每种类型的敏感信息能被存在多个环境中，包括开发过程和上线后。面临的挑战是自动识别这些地方的敏感信息并量化风险，包括开发环境，测试环境，生产环境或其他环境。

代码中有什么类型的敏感信息？

       有很多种敏感信息，开发人员可能放到代码中：

• 用户密码

• API密钥

• 认证token

• 私钥

• 数字证书

攻击者如何访问到这些敏感信息？

       不要假设攻击者为了访问敏感信息，必须要访问源代码。熟练的攻击者可以攻破存储你源代码的托管服务器（甚至在云中）。更有技巧的攻击者将逆向二进制文件来获得源代码，当你的B2B软件部署在客户本地或者是面向消费者时，如windows.exe，甚至IOS或Android 应用，都可以做到。

攻击者用发现的敏感信息能做什么？

       最复杂的攻击者使用多个步骤，一个单点的敏感信息，可以作为实现更多命令和控制的起点。如果攻击者能够发现硬编码的令牌，他们能使用它去获得这个令牌能访问到的信息。使用正确的令牌，一个攻击者能够模仿授权用户或服务，然后使用其他方式提权或水平跳转到其他系统。

       在你代码中的包含敏感信息的主要问题，是会使你的防御系统短路。例如，即使你有一个SaaS产品，你的云架构是安全的，一个攻击者能使用社交工程后其他方法获取对访问开发人员账户，访问代码发现和利用敏感信息。如果你有1000个开发人员，他们所做的只是需要访问一个账户！

为什么检测敏感信息这么难？

        主要的原因是有很多类型的敏感信息，一些数据是“结构化的”（不是数据库意义上的结构化）。认证和访问令牌常常是标准格式，很容易被发现，几乎没有误报和漏报。

        其他类型的数据不那么结构化，由随机字符的长字符串组成，也许被加密或哈希。问题是如果你不了解代码，你不能判断你看到的内容！如果你发现100个看起来“随机”的字符串，有些是测试文件，有些是二进制文件，有些被加密或哈希。在代码中这样是还好的，一个工具应该能区别他们。

        加密密钥常常足够长，你能使用统计学去判定是否这个字符串是否足够随机，可以当作密钥。但对许多类型的文件，并不是很清晰，问题也变成，你能接受多少误报，Github最近更改了他们的整个API认证令牌，因此很容易被扫描器检测出来。

       另一个挑战是开发速度，任何组织能执行一个代码检查，从一个细致的人工搜索中发现相当数量的敏感信息，但这不是一个可扩展的方案。

是的，确实很难，我们能做什么？

       可以做很多事情去发现敏感信息，修复问题，减少风险

• 遵从密钥管理的最佳实践。当前的安全需求要求密码和令牌仅能被使用一次。但很不幸，那不是现实。开发人员将在测试环境使用API 密钥，然后在开发和生产环境使用同样的密钥。密码也因为要满足交付期限，本来是暂时使用的，后来也被留到了生产环境中。我们已经发现存储在客户测试环境中的密钥，得到让耳朵生茧子的过度敏感报警。结果发现了那些同样的密钥被用到生产环境中，此外，即使在测试环境中，也需要遵从安全实践。

• 使用第三方敏感信息检测方案。这些工具常常使用正则表达式的组合来检测代码中的敏感信息的特征，以及熵检查，检测也许被认为是密码或密钥随机性。

代码中敏感信息的检测和修复是一个独立的功能吗？

       了解和修复代码中敏感信息的风险不能独立地进行。对于发现部署在本地的、有低的业务影响、应用中的敏感信息，和发现存储PII的高业务影响应用中、类似的敏感信息。在风险中有一个明显的区别。

       风险是多维的，代码中的敏感信息只是围绕着多维应用风险的代码图景中的一部分。

现存方案的缺点，Apiiro如何能提供帮助？

       围绕着代码中敏感信息检测，涉及整个的行业，但现存的方案中的一些方法有其不足：

• 代码上下文。对代码有一个深入的了解非常关键，不仅检测难懂的敏感信息，而且也能最小化误报率。随着了解代码功能如何实现，可能测试潜在的密码、API密钥，更多的实际代码如何使用他们的类似方式。这提高了检测（误报率）的数量级

• 开发者行为。如果某个特定的开发人员在过去，向代码中增加了多个敏感信息，在敏感信息方面的打分会比没有类似操作的开发人员高。

• 历史。许多方案仅仅评估当然的源代码，但完全忽视了也许存储在测试环境中、早期版本中的敏感信息。虽然在源代码管理期中的存储历史敏感信息不能被通过逆向来获取，他们万一黑客获取了源代码库的访问，那里有所有历史上的修订信息，这些敏感信息仍会带来风险。

• 编排。Apiiro自动编排敏感信息的发现、修复和阻止。评论拉取需求、生成自动化工作流、发送合适的报警，让流程尽可能的简单。我们使用您现有的工具，从jira到Slack

       Apiiro使用多种技术发现代码中的敏感信息，我使用最新的算法，实现加密密钥的熵检测，使用我们对代码的深度了解，查看上下文，在代码的整个历史中这样做。此外，Apiiro提供持续的敏感信息检测，使用自动化工作流，因此你可以在新的敏感信息被引入时，管理你的代码和你的风险。Apiiro也了解哪一个密钥管理系统在使用，能指导开发人员如何修复而不是只提供报警。

 

 

原文始发于微信公众号（安全行者老霍）：应用安全介绍之Apiiro