安全公司的程序员做什么？

我听说过咨询客户系统安全性的安全公司。我在该领域认识的所有人都是网络工程师，但我知道程序员也参与安全性工作。执行审核/咨询的安全程序员实际上做什么？他们是否从字面上浏览代码库，以查找人们的遗留系统中的每个漏洞？我一直以为这是他们的所作所为，但似乎这将是非常不可靠的，并且除了提供错误的安全感外，不会做太多其他事情。注意：我不是在谈论编写加密算法或类似方法的程序员，而只是在乎软件安全审核/咨询的程序员。

坦率地说，我们尝试不遍历您的代码库，而是尝试编写工具为我们完成此任务。

首先是理论。安全性是软件系统的要求，因此，与其他要求（功能，可用性，可访问性，性能等）一样，应在软件工程工作流程的每个阶段（从需求收集到部署和维护）都考虑安全性。确实，这是可能的，并且存在指导来帮助软件项目团队做到这一点。尽管我主要与iOS开发人员合作，但是我最喜欢的“安全开发生命周期”描述来自Microsoft Press。

在此模型中，当我们试图从用户那里获取需求时，应用程序安全性便开始了。我们需要发现他们的安全和隐私问题，这并不容易，因为我们是专家，而不是用户，在他们了解他们的安全要求的地方，他们可能很难表达出来。我们还需要发现软件在部署中将面临的风险以及可接受的风险级别。

我们在设计应用程序时会考虑这些要求。我们在编写代码时会着眼于满足这些要求，并避免与代码级安全性错误相关的其他风险。我们对软件进行测试以确保其安全性模型与我们实际构建的模型相一致，然后以与设计事物时对环境所做的假设相匹配的方式部署软件。最后，我们提供支持和维护，以帮助用户以符合其安全要求的方式来操作软件，并使他们（和我们）对所呈现的风险的新变化做出反应。

好的，理论上就这么多。在实践中，对于那些（在一个非技术性的方式虽然）在很好的解释原因Geekonomics，哪些是主要是由于他们的方式的软件公司的动机，最上面的东西不会发生。相反，我们得到了这个。开发人员将：

• 雇用安全人员或gal在投标合同时在场，以表明他们“获得”了安全。
• 编写软件。
• 雇用安全人员或gal在发行前验证软件，解决了步骤2中出现的许多问题。
• 部署后修补其他所有内容。

因此，正如您所说，大多数应用程序安全人员实际上所做的就是查找错误。这确实是一个光荣的代码审查，但它是由专注于此审查所寻求的各种错误的专家进行的代码审查，因此在这样做时获得外部帮助仍然很有价值。当然，这是测试的一般规则：总是让其他人测试谁没有参与制作。

如果我们接受上述观点，那么得出的结论是做出购买决定的人们可能会将“有能力的安全人员”等同于“发现很多错误”。那些拥有计算机来为他们工作的人会发现比不拥有计算机的人更多的错误，因此，他们当然严重依赖于静态分析工具，并且他们的目标是花费更多的时间来扩展工具，而不是为特定客户针对特定问题进行编码。然后我们得出结论，应用程序安全人员更可能编写工具来阅读代码，而不是阅读代码。

**警告：剩下的只是个人意见和猜测**

现实被打破了。您会注意到，软件安全性的理论全是关于识别和响应依赖软件系统的风险的，而实践则是寻找尽可能多的错误。当然，这仍然会降低风险，但仅是副作用。游戏的重点已变得不如“赢得”游戏重要，因此更改了规则以使其更容易获胜。

作为软件开发人员，您可以做什么？按照其原始规则进行游戏。在您的团队中找到一个了解安全性的重要性并从中培养勇气的人（最好是实际在您的团队中，而不是在承包商中，以便他们有动力提供长期结果而不是快速获胜）。让该人负责指导团队提供我在回答开头所述的端到端安全性。

另外，授予该人执行权限。如果设计没有表达安全要求，则必须对其进行修改。如果实施不符合安全要求，则不得发布。您的安全人员可以作出判决，但必须被允许根据该判决采取行动。我意识到这听起来像是安全人员在说“ OMFG安全是最重要的事情”，但这不是我的意思。如果您的产品也不符合功能，可用性或性能要求，那么您也不应发布该产品。

你为什么想这么做？它应该更便宜：我们都已经看过（并可能以便宜的+10代表报价）Code Complete表，其中缺陷在以后修复时变得更加昂贵，对吗？安全缺陷也是缺陷。在游戏的真实规则中，大多数都是维护中已解决的需求问题。那便宜吗？

好了，现在有什么可以我作为租用安全枪怎么办呢？事实证明，我也可以拒绝遵守修改后的规则。我可以告诉开发人员这一切都是关于降低风险的，可以在每个阶段都做到这一点，然后我可以帮助他们做到这一点。

在针对小型和超大型应用程序，环境，系统等运行安全保证程序的15年中，我想说的是一切。在我的团队中，我总是有一些是核心编码员。

在详细的级别上，其中一些可以归结为非常深入的代码审查-例如，我目前正在研究数百万行的代码库，使用工具来缩小可能出现的问题，然后逐一查看分类。

（当然，我然后交给开发人员进行补救或向我解释为什么该问题不会带来风险）

但这是一种特殊的约定，对于这种约定，风险简介对于执行此类资源密集型工作是有意义的。

试图了解组织的风险状况并着重于自上而下的风险的标准要更高得多，并且更具成本效益，例如：

• 风险偏好-对业务的影响，威胁建模
• 治理-合规性，报告等
• 政策-定义以确保治理框架有效
• 工艺流程-技术和人员
• 标准-每个安全控件的定义
• 实施-如何

实际上，编程方面仅涉及代码审查和自定义渗透测试的最后两个方面。对于某些组织而言，它的重要性很低，例如，如果您已经分层了安全控制，而这些安全控制已经被同行广泛审查（例如各种加密类型），那么尽管您可以检查实施情况，但通常不会重新检查所有安全控制措施。之前已经完成的代码。

在设计和/或针对完成的项目运行攻击/干扰/例外/测试套件期间，我从来没有遇到过比模糊讨论架构/最佳实践更有效的方法。

在几乎所有情况下，我什至可以说出他们尝试使用的攻击媒介所使用的工具以及在审核通过现有系统后进行攻击的方式。

我想实际上有一些人花时间检查代码并进行一些审查/白盒测试，但是我还没有在现实生活中遇到它们。