我已经开发软件超过 20 年了。在那段时间里，我曾在财富 100 强公司工作过，这些公司有非常具体的安全要求，由专门的安全专家和没有任何安全要求概念的小公司开发。
在我看来，很多时候，甚至在大多数情况下，事实上的安全策略最终几乎是由程序员偶然创建的，并紧密集成到成品中。大多数企业似乎只是购买一些东西并使用默认/硬编码规则而没有进一步考虑。
我的问题是，在一个完美的世界中，企业应用程序开发人员在确定其软件的安全策略时应该扮演什么角色？产品应该实施铁定的“最佳实践”还是专注于可配置并允许消费公司/组织确定自己的政策？
（我在这里谈论的是是否以及何时需要双重身份验证，密码复杂性要求以及超时时间以及在锁定之前可以输入多少错误密码。）
编辑：
好的，重申一下，我说的不是 XSS 或 SQL 注入等实际漏洞，而是策略。假设我不知道密码需要多长时间才能对我的上下文足够安全，并且我只被允许几个小时来处理最小密码长度代码。我最好研究多长时间并硬编码我的决定或编写让管理员自己定制的代码？
我也是一名开发人员，我对安全性的热情经常使这种动态在与其他不关注安全的开发人员打交道时变得有点不寻常。
在安全策略方面存在三个主要限制领域：
你的工作应该包括就技术因素提出建议，并提出可以减轻任何可用性影响的方法。但是，如果他们在技术安全问题上与您意见相左，您几乎应该始终听从称职的安全顾问的技术判断（称称“称职”）。您的工作是以最佳方式将必需品整合到产品中，同时克服困难的障碍。
就直接参与软件开发的安全策略而言，很大程度上取决于：
当您考虑到大多数软件组织没有专门的安全人员时，这个问题的有趣部分就出现了，更不用说部门了。无论您的公司是否这样做，您都有责任了解适用于您工作的安全问题的类型和机制。如果您的公司没有“安全人员”，那责任就更大了。您的工作的一部分是实施工作和可靠的软件，其中包括安全性，但另一部分涉及以他们可以理解的方式将技术信息传递给管理层。除非您了解手头的问题，否则您无法有效地做到这一点。
简而言之，没有简单的答案。作为工作的一部分，您需要做出一些安全决策并实施某些机制，因为这是开发人员所做的。至于你走多远，完全取决于你作为一个人和你所在的组织。为了在没有提供压倒一切的指令时做出合理的判断，你需要投入工作来理解这些问题。
我完全赞成推动人们达到更好的安全标准，但我喜欢控制自己的命运。我的偏好是让您开发选项，让管理员可以灵活地做出自己的选择，但将默认设置设置为高安全级别。这样，如果有人感兴趣，他们可以使事情符合他们自己的内部安全策略，如果他们开箱即用，那么它就有很高的标准。
IMO，即使在“完美的世界”中，也应该有程序员参与。程序员应该有足够的知识将业务需求和安全术语翻译成开发人员的语言，反之亦然。
简而言之，只有开发人员才能准确了解软件的工作原理，并且有可能某些内容“在翻译中丢失”。至少，开发人员（或代码审查员 - 熟悉实际代码的人）应该坐下来确保制定政策的人不会因为对幕后实现方式的误解而这样做。
它不仅有助于确保团队中的其他人理解并避免错误，制定这样的策略/策略还有助于确保程序员完全掌握其系统的安全性。他们只是没有按照应有的方式教授安全编码实践。学校或在线教程都是从向您展示如何做事开始的，而且要学习的东西太多了，他们很少会为如何不做事而烦恼。
IT 世界中的每一个安全漏洞都是某处软件的结果。在操作系统级别，在您调用的 API、您自己的代码中，某个地方存在允许不良行为发生的缺陷。它可能是代码中的错误或愚蠢的要求，但即使是糟糕的要求也是根据这些要求的规范构建的代码中的缺陷。
因此，确保开发人员参与其中是有意义的——让他们考虑安全性，并确保没有会导致问题的误解。
作为开发人员，我会说由最终用户来定义产品的安全要求应该是什么。他们应该是了解他们面临的威胁形势以及他们必须应对的风险的最佳场所。
也就是说......您不太可能找到一个完美的客户，他们会立即了解他们的安全要求，此时您正在寻找业务分析师（其中可能包括开发人员，特别是对产品有深刻理解的架构师）来帮助得出这些要求。
从开发人员的角度来看，了解实现这些需求的最佳方式将是关键。而且，同样重要的是，知道如何编写安全软件，您最不需要的是缓冲区溢出/SQL 注入，它会破坏所有这些好的要求和设计。
在安全可配置性方面，我会订阅默认安全的心态，以便尽可能安全地部署它，并可以选择在必要时放松这些安全控制。