ShiftLeft公司及其产品
该资料是根据网络及我试用工具所撰写，如有侵权，请联系我。
ShiftLeft公司，成立于2016年，总部位于美国加利福尼亚州圣克拉拉市。ShiftLeft公司有三款产品Inspect、Protect、Ocular。ShiftLeft的主打产品无疑是ShiftLeft inspect，一款漏洞检测产品，inspect将SAST和IAST融合到一个产品里，跟DevOps工具链进行集成，作为上线前的漏洞检测方案。其产品使用的数据库是基于PostgreSQL的TimescaleDB，这款数据库是作为PostgreSQL的一个扩展，提供了一个叫Hypertables的超级表，估计是增强了一下PostgreSQL强大的分区表的功能，让分区根据时间段进行划分，查询的时候根据时间来筛选chunk，会省掉大部分无用的磁盘IO。开发语言使用的go语言。
主推DevSecOps应用中的CI/CD阶段运用该工具。ShiftLeft inspect根据官网放出的数据，50w行代码检测时间10分钟。SAST类大部分产品在OWASP基准测试中最高可以达到检出率为85%，但同时误报率也高达52%。
ShiftLeft能够支持Java、.NET，预计到2019年底会支持Python。
支持检测的安全漏洞为OWASP top10中的6个，包括：
A1-SQL Injection：SQL注入
A2-Broken Authentication：破坏安全验证
A4-XML External Entities Injection，XML实体注入
A5-Broken Access Control：破坏存取控制
A8-Insecure Deserialization：不安全的反序列化
A9-Known Vulnerabilities：已知漏洞
SAST类工具的技术实践大致可分为以下几种：
（1） 正则匹配：代表工具cobra，raptor；
（2） 基于语法树:代表工具p3c,fireline；
（3） java语言可基于class文件:代表工具findsecbugs；
（4） 基于控制流、数据流、函数调用关系等:市面上的商业级SAST类产品。
当然，效果是逐渐递增的，难度也是逐渐增大的，
要实现还原代码的数据流、控制流和函数调用关系，需要将编译中的前端模块完全实现一遍，基于中间代码去还原数据流和控制流等，大致流程如下：
每个阶段的具体实现大家可自行查看编译原理相关的知识，这里不展开讲，其中词法分析和语法分析一般可以借鉴相应的开源工具可以完成，但是语义分析依赖于各种语言的语法，针对每种语言一般需要单独实现，不同的语言翻译成同一套规范的中间代码，根据翻译来的中间代码，符号表等来恢复数据流、控制流和函数调用关系等，然后根据这些流来确定污点传播过程，进而确认是否存在漏洞。
白盒类产品误报率高和耗时长的原因跟这个复杂流程相关，各个安全厂商自己基于编译原理相关内容实现的代码分析模块，还原的数据流、控制流等难以做到100%准确，同时对100万行这种大量的代码分析，资源占用大，复杂度较高，数据流、控制流的构建过程自然就耗时长，导致了SAST类产品误报率高和耗时长这两个问题比较难解决，做得比较好的厂商是在两者之间取一个平衡。
ShiftLeft 发布的Inspect产品在OWASP基准测试中的结果，检出率（TPR）为100%，误报率（FPR）为25%，最终得分为75%，这说明ShiftLeft Inspect产品具有较强竞争力。
IAST相比于SAST有着明显的优势，比如误报率极低、检测速度快、漏洞详细度高、人工成本低等。ShiftLeft也将IAST融入到Inspect产品中，只不过在ShiftLeft中称为MicroAgent。 MicroAgent是IAST的关键模块，其与Security DNA（安全DNA指的是代码中容易出现攻击位置，像第三方开源库、敏感数据等）相互合作从而在一些细微处加强了漏洞检测能力。
ShiftLeft Inspect也是将SAST和IAST（interactive application security testing）相结合的一款漏洞检测产品。ShiftLeft将SAST、IAST、RASP融入其产品中，利用CPG技术让漏洞检测的检出率和误报率均得到了有效提升并且从漏洞检测、静态防护、运行时防护、自定制查询漏洞等多方面对软件开发生命周期进行安全防护从而实现了DevSecOps的落地。
Shiftleft将下一代静态代码分析与应用开发自动化工作流中涉及的安全工具（SAST、IAST、RASP）相结合，以提供应用在运行时的防护能力，相比于传统防护方式可能带来的漏洞误报率高、人工介入周期长等缺点，以上这种结合方式提供了更为准确，自动化和全面的应用安全解决方案。
关于什么是SAST、IAST、RASP，我们了解一下。
SAST：static Application Security Testing，静态应用安全测试。
处理大量代码分析时具有误报率高、耗时长、资源占用比高、复杂度高等缺点，究其主要原因，是因为在审计代码的编译阶段需要针对不同的语言实现不同的语法树从而增加了复杂度和时间成本。
IAST：Interactive Application Security Testing，交互式应用安全测试。
近实时检测、误报率极低、可定位到代码行数、展示污点调用过程等等，非常适用于DevSecOps流程。产品中也会尽力体现污点调用过程，代码行数等不同于DAST的，偏代码层的信息，。
为代码审核员和审查员提供了一个平台，用于构建和调整强大的、高度定制的查询，以交互询问其独特的代码库和环境。
具有更复杂代码探索需求的分析师可以利用全面的CPG图形映射创建高度特定和有针对性的查询，从而绕过常见的误报源。示例包括识别代码中存在的任何问题（用户输入受到适当保护）的能力，以及存在任何间接数据流（用户输入未直接用于接收器）的能力。
RASP：Runtime application Security Testing，运行时应用安全测试。
很多企业在上线前进行漏洞检测，都要求解决高中危漏洞，在业务紧急上线的情况下，低危漏洞往往可以选择性的忽略，一般会经过评审，各个负责人签字等流程，DevSecOps因为强调速度，这种情况则更多，但是作为一个安全人员或者项目经理，忽略这些低危漏洞真的放心吗？攻击者可能不会通过这些低危漏洞来直接攻击业务，但是往往成为攻击链中的一环，获取某些敏感信息等，那RASP的作用就是在Ops阶段，继续针对性的保护那些被忽略的低危漏洞。
Shiftleft提出代码属性图（Code Property Graph，CPG）概念，我们先来看一张CPG图。
CPG是一款可视化的代码分析产品，其为每个应用唯一的代码版本提供可扩展的和多层的逻辑表示，包括控制流图、调用图、程序依赖图、目录结构等。CPG创建了代码的多层三维表示，具有很强的洞察力，这使得开发人员可充分了解应用程序每个版本执行的内容及可能带来的风险。
PDG：Procedure Dependence Graph, 程序依赖图
- 系统依赖图的概念及两阶段图形可达性算法的出现，则有效解决了程序切片的过程调用问题。
- 介绍了动态切片的基本概念，并将程序依赖图算法应用于动态切片，从而达到缩小程序分析范围的目的，动态切片在程序调试和软件测试中的应用。
- 传统的算法是通过建立程序的依赖图得到动态切片，但依赖图需要占用大量的空间，因此算法效率较低。
多层语义图
CPG是一个图表。它将您命名的图形合并到一个联合数据结构中。其结果是多层次、三维的代码表示，比市场上的任何其他代码都更丰富、更全面。它提供了前所未有的代码洞察力，使CPG能够在应用程序基本上是什么和不应该做什么的上下文中显示信息流。从这个角度来看，漏洞更容易被识别为异常。CPG利用语义图创建单个多层图，从而汇总每个版本代码中的所有组件和流。CPG将所有代码元素（自定义代码、开放源代码库和商业SDK）映射到各种抽象级别，包括抽象语法树、控制流图、调用图、程序依赖关系图和目录结构。这种联合数据结构提供了对各种组件如何相互作用的更深入的理解。这种理解还可以更有效地分析识别漏洞的代码。这对于识别由一系列条件组成的复杂漏洞以及代码中使用遗留SAST工具根本无法发现的许多组件尤其有效。
从中可看出版本代码中的组件和流信息，CPG将这些代码元素（开发代码，开源库，商业SDK）映射为各种抽象级别，包括抽象语法树，控制流图，调用图，程序依赖图和目录结构，通过这种方式可以快速连接至漏洞点，使漏洞变得更容易识别，并且对于复杂漏洞（传统工具无法发现）的识别非常有效。
ShiftLeft还专门为CPG的生成做了一个工具，ShiftLeft Ocular 一个命令行生成CPG的工具，用于代码查找，漏洞排查等等。
随着应用程序与微服务体系结构、开放源代码库、商业SDK和外部API的模块化程度的提高，跨源、转换和接收器映射数据流变得更加复杂。shiftleft的cpg使用自然语言处理（nlp），以及行业特定的字典，以变量名自动识别关键数据。因此，CPG可以明确地识别泄漏，例如，关键数据以明文形式登录到splunk中，或者不经意间存储在公共Github存储库中的凭证，在它们被推送到生产环境之前进行开发。
传统的代码分析方法和工具经常忽略但CPG公开的数据泄漏的常见示例包括以下关键数据，这些关键数据无意中使用明文或凭证硬编码登录到应用程序中。
下面是我们看看这个工具的典型界面。
这都是什么意思？我们将在UI中探讨三个领域：
左上角显示了存储库主分支的当前状态摘要：最新提交详细信息和结论摘要（在白框中）。
左边的深色列表显示了shiftleft所称的结论。这些是我们潜在的可操作项目。正如我们将看到的，即使您发现一些结论是不可操作的，这些结论也将极大地提高您对明天编写的或今天需要维护的代码的潜在安全问题的认识。可以展开每个项目（黑框）以显示更多信息。
在右侧，您可以看到一棵树，其中包含按包组织的所有公共类的路径。在那个窗格的左边是一个包列表。您可以展开每个包以显示它包含的公共类。然后可以展开每个类以显示其方法。我们稍后再看。从有结论的树项目开始，您将看到其类别的浅色路径。换句话说，如果您看到一条从一个项开始的路径，不管它是一个包或类，这意味着它的一个包含项带有一个结论。
当然，首先要注意的是，我不再需要考虑整个JSON报告文件。在用户界面中，结论以一个可扩展的列表显示，而不必过滤掉图形数据（感谢上帝）。还有一个标题叫做“问题”，您将使用它来跟踪要跟踪哪些结论的更改。由于我们没有将任何结论标记为问题，因此UI会显示预期的“0”计数，并且“没有标记为问题的结论”。
要注意的第一个UI元素是“敏感数据”和“不可信数据”的两个摘要框。shiftleft在结论描述中使用这两个术语来组织其发现。
让我们从一个简单的结论开始，然后深入到细节中。当你点击“敏感数据”和“不可信数据”时，你过滤结论列表。我之所以选择“不可信数据”，是因为我正在寻找我在开放源代码中使用shiftleft编写时发现的第一个有趣的结论：方法ioutils.buffer（writer，int）不支持将不可信数据作为参数大小进行处理，因为它控制缓冲区的大小，使攻击者有机会使系统缺乏记忆。我通过网页搜索很快找到它。
单击链接进入github
虽然这个例子看起来很简单，但是shiftleft显示了对代码在这个方法中的作用的理解：我们允许调用站点以无限的方式控制内存使用。
让我们设想一个应用程序，它允许使用一个未绑定的值来处理一个2GB文件，它关心这个API和由shiftleft给出的结论。要跟踪此结论，我们将其标记为问题，以便在问题列表中跟踪：
现在，有趣的部分。让我们编辑代码以防止无边界使用。让我们设定一个任意的10 MB限制。我们将从以下位置更改代码：
在将这个更改推到Github之后，我看不到我的左移报告中有任何更改；啊，这仍然是一个测试版，我应该将其记为正在进行中的工作还是将来仍有潜在的问题？
我想知道这个方法是否不应该总是被标记。是的，我更改了代码，这样内存分配就不再是无边界的了，但是谁来决定我的最大缓冲区大小是否合理呢？对于一个简单的用例来说，这可能是很好的，就像一个单线程的应用程序只做一次。如果我有一万个并发任务想要这样做呢？这还合理吗？我不太确定。所以现在，我想我喜欢收到关于内存分配的通知。
因为shiftleft使用的是一个代码图，所以当我搜索这个URL的JSON结论时，我发现总共有14个使用这个URL的结论。这告诉我，这个代码片段在组件中创建了14个可能的漏洞；由于上下文很重要，所以要仔细强调可能存在的漏洞。
如果我在页面左侧的结论列表中搜索，我会找到几个“fileutils.copyfiletodirectory”的匹配项。然后，我可以单击展开每一个，以查看到GitHub的确切位置和超链接。我希望接下来的是过滤排序的能力，所以我创建了一个类似于JSON报告的精神图像。
shiftleft还有一种用户友好的方式来发现此信息：树视图
在这个视图中，“”节点是ApacheCommonsIO中最顶层的包。您可以看到它有一个路径，可以指向所有三个不同的类别：通用、文件和子进程。这意味着根包包含结论，并且这些结论在链接的类别中。
当我展开根节点时，我发现fileutils类（突出显示）：
你可以看到这个类有一条远离它的路径，所以我知道它包含结论。在这一点上，很难理解类别，因为它们已经从屏幕顶部滚动出来了。当你滚动的时候，如果类别向下浮动就好了。希望是第二版！您还可以看到，一些类（如filenameutils和iocase）没有通向它们的路径，因此不会得出结论。我想可以松口气，但我想过滤掉那些没有结论的东西。
现在展开fileutils类：
这里，有些方法有路径，有些没有；向下滚动，我们将复制文件到目录：
正如预期的那样，该方法有一条远离它的路径，它表明了一个结论，但我们不知道哪一种或哪一种。我们确实得到了它的参数的描述，一个很好的感受
现在，单击该方法不会做任何我希望能够执行与列表中相同操作的事情。这个视图允许您浏览整个库，但是除了类别路径之外，我觉得它没有什么特别有用的地方。我希望看到代码的超链接，以及使用颜色来区分哪些方法被标记为不受信任的数据和敏感数据，以及指示哪些类别不滚动屏幕。
不过，好的是，我在UI中有两条探索路径：结论列表和资源管理器树。
这里有两个关键技术正在工作，我希望随着测试版的进展，这两个技术都会变得更好：首先，构建一个代码图，让我们有能力看到一旦在一行代码上识别出问题，所有（我假设是公共的）调用站点都可以被标记。第二，在shiftleft的描述用语中，什么构成了一个问题或结论，将得到改进，并且是可配置的、可过滤的和可排序的。
在本例中，结论描述为：
方法“copyfiletodirectory”不支持将**敏感数据**作为参数“srcfile”传递，因为它在I/O**文件**上泄漏。
当我读到这里时，我脑子里想的是：是的，我不希望任何人能够在任何地方复制任何文件，比如覆盖密码库、将文件复制到目录（my file、“/etc/shadow”）。当然，ApacheCommonsIO是一个库，而不是一个应用程序，所以这里没有任何警报，但您可以理解。
后退一步，我认为重申这里发生的事情很重要：shiftleft在私有方法中的代码行上发现了一个问题（比问题更不引人注目），然后，使用其代码图为每个面向公共的方法创建了结论（报告项），最终可能会在其代码路径中调用此私有方法。
从基线开始工作
如果你认为有超过200个结论要筛选是令人望而生畏的，我同意你的看法。这就是为什么我期待在UI中使用一些排序和过滤的原因！
重要的是如何在代码发展时使用shiftleft。我想跟踪从提交到提交和从构建到构建的差异：我是创建还是消除了漏洞？我可以通过查看用户界面中的结论和问题列表来判断这一点。我希望shiftleft将实现类似的特性，在coveralls中，您将收到一封电子邮件，告诉您的测试代码覆盖率在构建中发生了多大的变化。
作为一个实验，让我们看看当我添加一些可能的恶意代码时会发生什么，这是一种从给定目录中删除所有文件和目录的方法：
注意，所有这些方法都是委托给另一个方法。我在浏览器中点击刷新，我看到我的提交：
这里有我的提交注释、日期和提交哈希。shiftleft工作大约两分钟（当shiftleft分析时，这两个计数重置为0），然后敏感数据和不可信数据结论计数上升。向下滚动，我看到我的新类：
看到树结构视图
注意，deleteall方法在右边有一个指向文件类别的路径，根据我以前的发现，这是有意义的。
现在我真的想点击右边的类别作为过滤器！我对“子过程”这一类别特别感兴趣。
这里值得注意的是，我的新类和方法本身并没有做任何危险的事情。但是，由于我们使用的是代码图，并且该图会导致危险的地方，所以新代码会被标记。
现在，为了有趣一点，让我们改变方法，让危险的部分无法到达：
危险类已从列表中消失，但由于它是公共API，因此存在于树中。如果是更棘手的事情呢？让我们通过一个局部变量使一些代码不可访问，我们将最终使代码图明白该值是不可变的：
危险等级仍然不在名单上。很聪明。让我们看看如何将测试委托给方法：
shiftleft现在在不受信任的数据和敏感数据列表中显示deleteall（）方法。所以这是不正确的。让我们不要使用方法，而是使用两个局部变量：
通过这种更改，Shilfleft仍然将该方法作为不受信任的数据和敏感数据列表。好吧，这有点像Eclipse针对null分析的编译器警告，它标记了可以看到的内容，而不需要进行真正的评估，这是非常公平的。
链接到根本原因
让我们回到结论列表上看一分钟。我的DeleteAll实验得出了两个结论：一个不可信数据，一个敏感数据。让我们仔细看看这些。
Untrusted Data
.ADangerousClass.deleteAll
The method deleteAll does not support handling untrusted data to be passed as parameter directory because it controls access to I/O File in a manner that would allow an attacker to abuse it.
When I click on the GitHub link for Untrusted Data, I see:
注意，我们不在这里的deleteall方法中，而是在这里，shiftleft代码图标志作为根问题。换句话说，如果我写了一个名为deleteall的公共方法，我将得到相同的结论和链接。
为什么调用directory.listfiles（）被标记为不可信？嗯，传递一个敏感的文件路径不应该被认为是一个问题，因为您正在搜索的文件路径最终不会写到磁盘上。但是，如果攻击者要控制输入路径，则被认为是危险的，因为他们可以列出系统上的任意目录。那是一种突破。
仅考虑verifiedListFiles（）方法，shiftLeft不知道在删除文件的操作中使用了该方法。接下来是：
Sensitive Data
.ADangerousClass.deleteAll
The method deleteAll does not support handling sensitive data to be passed as parameter directory because it is leaked over I/O File.
When I click on the GitHub link for Sensitive Data, I see:
显然，调用file.delete（）可能很麻烦，但使用敏感数据类别可能有点麻烦。如果在文件操作中使用了任何敏感数据（例如，作为文件的路径，如“path/to/my secrets”），则该数据将最终出现在磁盘上。对于删除操作，您可以说情况并非如此，因为您正在执行相反的操作，但实际上，您删除的是一个具有敏感名称的文件这一事实非常有趣。还可能您以前已经将敏感数据未加密写入磁盘。这是一个绕圈子的方法，但它感觉是合理的。
查找任意代码攻击
当我第一次在ApacheCommons2.5上运行shiftleft时，我在Java7Support类中发现了一些关于任意代码攻击的结论。现在，Git主机中的Apache Calm需要Java 7，Java7支持类就不存在了。目前，我还没有找到一种方法来在代码库主分支之外上运行ShiftLeft，除了一个存储库的主分支之外，所以让我们用Method.invoke（）在Java 8调用和intValueMe（）上的BigTime.InValueActhEnter（）。
package org.apache.commons.io;
import java.lang.reflect.InvocationTargetException;
import java.lang.reflect.Method;
import java.math.BigInteger;
public class BigIntHelper {
private static Method intValueExactMethod;
static {
try {
intValueExactMethod = BigInteger.class.getMethod("intValueExact");
} catch (NoSuchMethodException | SecurityException e) {
intValueExactMethod = null;
e.printStackTrace();
}
}
public static int getExactInt(BigInteger bigInt) {
try {
return (int) (intValueExactMethod != null
? intValueExactMethod.invoke(bigInt)
: bigInt.intValue());
} catch (IllegalAccessException | IllegalArgumentException | InvocationTargetException e) {
e.printStackTrace();
return bigInt.intValue();
}
}
public static void main(String[] args) {
System.out.println(getExactInt(BigInteger.TEN));
}
}
即使我们的intValueExactMethod变量是私有的但不是最终的，shiftLeft也可以使用此代码：
Let’s open things up by making the variable by changing:
private static Method intValueExactMethod;
to:
public static Method intValueExactMethod;
对于ApacheCommons2.5中的Java7Support类，shiftLeft报告了几个任意代码攻击漏洞。不幸的是，对于本例，shiftleft没有报告任何此类漏洞。我想是成长的痛苦吧。好吧，这就是我现在所拥有的。在我想很快回来的地方进行一次有趣的探索。
我想总结一下对shiftleft的探索，并简要总结一下我们发现的问题：我们可以在构建管道中添加一个工具，以发现潜在的安全漏洞。
这里有很多数据，这只是为了Apache Commons IO！另一个教训是上下文很重要。这是一个低级别库，而不是应用程序。在低级别库中查找漏洞是很好的，但这可能不是应用程序的漏洞。shiftleft结论至少可以让您了解如何安全地使用这个库。shiftleft目前提供基于代码图的结论，如同例子展示，这是非常强大的功能。我们发现了不受信任的数据（我不确定这里有什么，所以不要执行它）和敏感数据（不要以纯文本形式保存密码！）
以上资料根据网络上资料和作者自己试用工具所整理，如果侵权，请联系我。
（完）
