Alexandra Svatikova是Odnoklassniki的信息安全专家。 8年前，她从用Java开发转向测试应用程序安全性。
我们在讨论她的地方采访了她：
- 开发人员难于转向应用程序分析吗？
- pentester，rescher和分析员的表现差异；
- 安全开发生命周期或SDLC；
- 人在寻找脆弱性中的作用；
- 其他公司的安全分析情况如何。
本文将不会有任何硬核-您可以跟随他到Heisenbug 2019 Moscow ，Alexandra将在那儿谈论静态安全测试。 我们将在帖子末尾查看她的报告，但现在，欢迎关注。
登录应用程序安全性并不像听起来那么困难
“你为谁学习的？” 您为什么要参与应用程序安全性？
-我可能不是一个榜样（笑） 。 我以程序员的身份学习，文凭中写着“软件工程”之类的东西。 首先以移动开发人员的身份工作，然后转而使用Java进行Web开发。 在找到另一位Java程序员的工作后，我进入了负责应用程序安全性的团队-维护开发过程中与安全性相关的部分。 这是一个组织良好，公式化的过程，他们需要人员进行代码审查和静态分析器。 因此，他们正在寻找Java程序员，并准备教给他安全性。 对我来说似乎很有趣，所以我留下了。
-您的想法是，您会在该地区停留很长时间，还是会在这个阶段进一步发展？
-我想我会永远留下，因为自2011年以来我一直是应用程序安全分析师。 事实证明，我已经没有多少开发经验了。 程序员不应该害怕例行任务，修复错误，但是安全专家具有不同的特性，这吸引了我更多。
-与传统开发相比，您还需要掌握哪些其他领域？
-在我职业生涯的初期，我正在测试。 它使您的大脑很好：您看到的系统不是代码堆，而是生物体，可以用不同的方式来影响。 因此，测试人员和开发人员的想法有所不同。
例如，在10到15年前，人们认为测试人员应该以任何方式破坏系统并查找错误。 安全专业人员有时需要有相似的观点。 因此，您需要了解系统如何整体运作。
一些开发人员专注于细节：他们知道系统的一部分是如何工作的，但他们不了解系统如何相互作用。 例如，他知道如何在浏览器中执行JS，但是开发人员不知道该浏览器如何进一步工作并与服务器通信，为什么这样安排。 测试人员必须从鸟瞰角度进行评估，以评估组件的互连，弱变化或任何漏洞。
-还有一些工程，例如网络堆栈，您必须从头开始学习吗？ 例如，JS，前台，后台如何工作？
-原则上，我已经是一名全栈开发人员，所以我了解后端和前端的工作方式。 您需要具有一定的前景，但是细节的深化已经取决于您在做什么。 根据项目的不同，相同的开发人员和测试人员会了解某种系统知识（例如，网络协议）或对前端有所了解。 这要视情况而定。
-在您看来，从事编程，自动化和测试的抽象的全栈开发人员或全栈测试人员将转而对应用程序进行分析是多么现实，也就是说，您在做什么？
-对于测试人员来说很容易。 确保具有一定的编程技能，并了解如何从内部构建系统。 但是，没有这个的优秀测试人员将不复存在。 如果是这种情况，那么就会出现专业化的问题：他需要阅读有关安全性和某些技术（例如，Android或支持技术）的信息，即他正在尝试查找漏洞的内容。
开发人员认为他们对流程的参与有些不同。 因此，对于开发人员而言，这是一场革命，对行业的看法有所不同。 对于开发人员来说，一定有用的东西很重要，但是对他来说很难打破。
Pentester，Rescher和应用程序安全分析师：有什么区别
-据我了解，您的专长与渗透者有关。 渗透测试者和零时差漏洞研究人员如何比较，或者将它们混为一谈，真的很难弄清楚谁是谁？
-没有明确划分职位。 但是，我将告诉您聚会使用的术语。
有侦察员研究产品，技术，协议，服务器以寻找有趣的问题。 有趣的是指以前没有发现的问题，或在意外地方发现的问题，或者它是先前已知问题的复杂组合。 我可以说，通常来说，侦察员会发现各种0day漏洞。
Pentest是一项服务。 您拥有一个系统，并且想要查找漏洞。 渗透测试者的任务是渗透系统。 他们将无法发现所有潜在问题。 例如，可以通过不同级别的其他安全机制来缓解漏洞。 Pentester将查找实际被利用的内容，然后将发布报告并离开，因为它没有提高系统安全性或调整开发流程的任务。
也有应用程序安全性或产品安全性分析。 相反，他们从内部看系统。 他们的任务是使系统安全。 这意味着他们拥有有关系统的信息，对于他们来说这不是一个“黑匣子”。 另一方面，他们对问题的排名不同。 分析师甚至考虑了目前无法利用的漏洞。 例如，管理面板上有一个严重的漏洞，很明显它只能从内部网络访问，因此并不十分可怕。 但是内部人士知道，在某些情况下可能会发生可怕的事情。
分析人员更加专注于支持流程。 如果测试人员发现20个错误并离开，而开发人员在修复错误的过程中也做同样的事情，那么测试人员将无济于事。 因此，仅在那一刻才需要了解系统中的漏洞数量。
-然后，应用程序安全分析师每天都在此过程中执行此操作吗？
-是的，并且活动同时指向两个方向。 一方面，您需要寻找现有的漏洞并加以解决。 另一方面，还有一项任务是使系统更安全。
这可以通过不同的方式来解决。 例如，建立开发流程，以便减少错误或迅速发现错误。 或实施可减少该漏洞投入生产的风险的机制。 有几种方法可以确保系统安全。
-那么，应用程序安全分析的工作与团队紧密相连，而开发流程恰恰在内部吗？
-是的，应用程序安全分析师应提出有关开发过程的问题。 SDLC（安全开发生命周期）是在阅读有关应用程序安全性时遇到的第一个流行语。 简而言之，这些操作的目标是确保在开发的每个阶段都考虑系统安全性考虑。 在这种情况下，并非总是由安全专家来执行特定任务，有时您可以委派给其他团队成员。 毕竟，您越早发现问题，修复它的成本就越低。
寻找脆弱性仍然是人的心灵
-在没有一行代码的情况下，可以在规范，讨论，原型，草图的级别上找到产品的问题。 但是，在什么阶段可以发现安全问题？ 甚至在编写代码之前就可以找到它们吗？
-当然，因为存在与要求制定方式直接相关的问题。 让我给你一个疯狂的例子。 您制作了一个登录表单，设计师告诉您：“并且让我们的用户说他们不仅输入了错误的密码，而且在密码的最后一个字母中输入了错误。” 也就是说，要求的措辞可能本质上是不安全的。
另外，在传统知识阶段，可以假设系统将受到某些漏洞的影响，并且必须实施某些保护机制。 如果您在网站上采用相同的形式，则肯定需要输入验证码以防止密码猜测。 因此，在架构开发中应提到这些要点。
-在CI / CD流程中嵌入安全测试的频率有多高，难吗？ 也就是说，为了能够“拆除” Jenkins或TeamCity中的任何管道，并且有一个单独的阶段运行安全测试。 它有多真实？
-在同一SDLC上有准则，在监管者方面也有要求。 因此，拥有成熟开发流程的公司会实施它们。 有一些工具可以使流程的一部分自动化，但是工作量和结果的比例取决于项目的性质以及这些技术在开发的哪个阶段开始实施。
如果应用程序是从头开始编写的，那么您可以提出使用静态分析器来避免代码中的可疑指令。 而且，如果在编写代码的10年之前，您随身带上了疯狂赚钱的工具，那么，您当然会发现一些。
所有自动工具都有一个问题，就是他们不了解系统的工作原理。 如果可以隔离系统的单个组件，则可以使用现成的工具对其进行测试。 但是在具有许多依赖性的系统中，自动扫描程序可能会丢失有价值的信息。
其他公司的安全分析
-根据公司的演讲和会议演讲，您认为哪个公司或哪个项目是应用程序安全分析的旗舰？
-微软提出了SDLC的实施，这成为了经典。 但是，这是它们在最低级别工作的方式，使用的工具是什么，我不知道。
Facebook撰写了很多有关技术上如何安排一切的文章：他们如何扫描代码，查找工作系统中的漏洞等。 一些Facebook工具甚至是开源项目，因此您可以更深入地了解他们的勇气。
如果我们选择俄罗斯公司，那么Sberbank会有趣地谈论他们如何正式制定SDLC，记录该过程。 尽管他们的应用程序安全团队非常庞大，但对于许多开发人员来说还远远不够。 因此，他们对团队中的安全冠军进行教育，将一些有关安全的知识带入他们的头脑，在这种情况下，冠军可以举起红旗。
Yandex在会议上谈论诸如“如何破解浏览器”之类的很酷的事情。
-会议结束后，测试人员在听到有关威胁和工具的报告后，在实施之后会产生重大影响是否现实？ 例如，一家公司将以10,000美元的价格购买一台寻找Jenkins管道漏洞的扫描仪。 还是更重要的是了解利用漏洞的机制来实施某些事情？
-你买不到一万美元的扫描仪（笑） 。 如果我们谈论对漏洞的搜索，则归结为测试特定方案。 场景取自常识集合。
例如，OWASP（开放Web应用程序安全性项目）发布了有关如何进行安全性测试，代码审查等的指南。 例如，在OWASP应用程序安全验证标准中，它写了所有需要测试的内容。 要阅读该文档，不需要特别的知识，足以了解Web应用程序，因此任何测试人员都可以处理。
标准表和备忘单足以进行手动测试。 它说明了存在哪些类型的漏洞以及如何查找它们。 根据定义，某些测试不能由标准扫描程序执行：例如，与检查业务逻辑有关的测试。
另一方面，如果需要查找XSS，则需要在每个已更改的参数中添加引号，括号等，如果系统中有1亿个参数，则该任务不再可行。 但是自动化工具将对她很好。
但是，当您启动扫描仪时，可能会出现以下三种情况：
- 该工具发布了一份报告，报告中存在许多良好的可重现错误以及一些误报（理想，但不太可能）。
- 该报告包含2万个发现，其中约1％是真实的。 因此，您必须坐下来确定是否存在真正的问题。
- 该工具无法理解系统中的某些内容，因此发布了一份报告，说明一切正常，但事实并非如此。 例如，由于找不到该库，我无法编译代码。 还是漏洞扫描程序发出了10个请求，遇到了洪灾，并且没有收到来自服务器的其余百万个请求的响应。
因此，我认为，重要的是要了解扫描仪处于“幕后”状态，以便选择与要解决的任务相对应的工具并充分评估结果。
Alexander将在Heisenbug的报告中提出正确选择和调整工具的主题。 在那里，她将讨论SAST解决方案SonarQube的应用程序和自定义，以及查找安全错误以搜索其项目中的漏洞。 这些工具提供“开箱即用”的功能吗？ 以及如何自行扩展功能？ 例如，演讲者将考虑XSS和IDOR的漏洞。
会议将于 12月5日至6日在莫斯科举行 。