security - 有关于不同 CMS 安全性的研究吗？

Question

我喜欢发布指向 Secunia 搜索结果的链接，以（以数字形式）展示某个 CMS（或博客软件）的不安全性。

请参阅Drupal 的一些缺点是什么？

但是这个答案有一个有趣的评论：

伊顿：

还需要注意的是，Secunia 仅发布明确宣​​布的漏洞报告。我与其他 CMS 软件包合作过，这些软件包在次要版本中添加了重要的安全修复，根本没有任何公告。Drupal 有一个 15 人的团队，负责审查核心和所有 3500 个插件，并根据政策正式宣布安全补丁，无论多么小。

在比较内容管理系统时，是否有任何研究或文章考虑到这一点？

Answer 1

我有少量文章加了书签（比如我同事的这篇），但它们几乎都是由人们为他们选择的 CMS 辩护，以免受到安全性差的指控。（包括我自己在您的帖子中的评论！）其中一个困难是，我认为没有人已经解决了构成“合理比较”的问题——每个人都对不好的比较感到恼火，但在任何人确定什么之前就走开了一个公平的竞争环境。

大多数“快速概述”都错过了几件事：

• 产品开发团队的安全策略
• 负责安全的特定人员或团队（取决于项目的规模）的存在。显然，项目中的每个人都应该关心
• 是否有针对第三方开发人员的书面安全最佳实践
• 按类型和严重性比较漏洞

也许这个线程将是一个集思广益的好地方，什么将构成一个好的比较研究？

更新- 一位同事对 Secunia 有相反的挫败感：第三方针对 OSS 项目提交的不准确和错误的报告。Secunia 显然拒绝更新或修改它们。这是一项有用的服务或公告，但我听到的一切都让我在使用它们进行比较时感到畏缩。

Answer 2

使用这些 Secunia 搜索的另一个主要问题是，它们包括所有贡献的模块以及 Drupal Core，即使特定公告可能是针对大约 30 人使用的模块。

除了按类型和严重性划分的漏洞之外，您还需要考虑“核心”与“附加”模块以及偶尔将多个漏洞放入单个公告中的做法（经常发生）。

我的感觉是，伊顿的一些政策措施比具体的漏洞数量或严重程度更重要。

我要添加到该列表中的最后一个好措施是在过去 X 年的几个月中，在没有任何项目修复的情况下公开披露了漏洞。这种情况很少见，但却是安全过程真正失败的标志。