我可以想象，对于MVP团队来说，他们想要尽快推出应用，所以他们不想花费大量时间进行威胁建模，并经历大量额外的过程，因为这将增加更多的开发时间。因此，MVP的目标和良好的安全之间似乎有一种自然的摩擦。
这绝对是一种摩擦。这很有挑战性，因为安全基本上是不可见的。这意味着好的安全性和坏的安全性看起来完全一样，直到出现问题。当有东西坏了或者有人被黑了，安全就很明显，然后你就上了新闻。然后就在你面前爆炸了。我们已经见过几次了，我不知道有多少初创公司被它扼杀了，可能是扼杀了一些，但当他们的第一个主要新闻报道是他们被黑客攻击时，这肯定让很多初创公司付出了代价。
当这种紧张存在时，组织有哪些方法可以缓解这种紧张呢?有没有办法让保安进来这样就不会太突兀了?有没有办法根据数据类型分离应用程序?也有可能允许不接触敏感数据的MVP应用程序，并对那些能够接触敏感数据的应用程序进行更深入的研究?
我认为这是一个很好的方法。正如你所指出的，一种方法是，让我们看看我们能否用不那么敏感的数据来做一个MVP，这样你就不必过分关注安全性。如今，这有点挑战性。即使你做的最小的事情，你也需要安全。不管你的数据是什么，你都会成为目标，你会被攻击，即使只是那些在互联网上运行的自动化机器人攻击一切。如果他们只能这么做的话，他们至少会使用您的基础设施来发送垃圾邮件。对我来说，方法就是必须实现一些行业最佳实践，比如OWASP top10。你必须相信安全是最小可行产品的重要组成部分，甚至是开始让这些用户故事在那里。
我想告诉人们的是考虑用户故事,甚至消极的用户故事或类似的东西,作为一个用户,我不想看到我的个人信息泄露,因为我已经在互联网上共享一些敏感的应用程序或网站,我敏感的东西存储在你的网站。我不想看到那些人用我的私人信息来攻击我。
这听起来像是一个安全团队可以编写一份指南，或者设置一个检查点来检查应用程序能否通过。例如，如果应用程序有某些条件为真，或其中一个条件为真，应用程序必须通过安全审查。如果没有，在一定的指导方针下，安全灯的方法是可以的。
那是完美的。典型地，这些精益方法至少有一些内建的测试方法，或者验收测试。或者，就像一些人所说的，“你对‘完成’的定义是什么?”第一步只是说，“我们将把安全包含在这些完成的定义中，”一旦你至少达到了这个级别，我认为不是很多人做到了，但一旦他们达到了这个级别，他们至少会做正确的事情。你要么将其构建到用户描述中，要么将其构建到验收测试中。
但你不能让它只停留在过程的最后。如果您将安全性验收测试留到最后，那么您的时间表自然会下滑。然后您将进行安全测试，并发现还有很多工作要做。然后你就会陷入这样一个不幸的决定:要么修复一些事情，让你的计划溜走，要么选择让一些不安全的事情溜走。
真正的悲剧是当一个系统本质上是不安全的，它是以一种非常不安全的方式构建的，这需要大量的返工，因为你在一开始没有考虑到安全性。很多东西都很容易在最后添加安全性，但有时您会遇到一些从基础上就破坏了的系统。就像这些东西一样，你越晚抓住它，成本就会越高。
组织可以寻找哪些迹象来表明他们正在做的是正确的?
如果你在看你的待办事项列表，不管待办事项列表是什么，不管它是一个故事列表还是一个任务和行动项目的大列表，你都应该意识到其中的一些安全问题。当你在开发某样东西时，其中一个开发者可能会说，“我们的系统很容易受到跨站请求伪造，跨站脚本攻击的攻击。任何一个不是为了防止这种情况而设计的系统，都会是这样。
如果你查看你的bug列表，你应该会在某个时候看到它弹出。有些安全问题会在开发过程中出现，因为没有什么是完美的。这将是一个早期的指标。
如果你没有任何东西,如果你看看你的错误列表,你看不到任何东西,如果您的开发人员不积极谈论安全或说,“我们要添加一些任务安全,“你会说,“嗯,我想为你添加这个功能,但会对安全产生影响。”如果你没有把它作为谈话的一部分来听，那就有问题了。
这篇报道，“问答:移动应用安全不应该是事后的想法”最初是由方案 ．