mattermost-plugin-circleci

项目可以选择从其公共源代码库中删除特定的临时版本（例如，修复特定的未公开安全漏洞，可能永远不会公开发布的内容，或者包括不能合法发布而且不是最终版本的内容）。

本条款可以通过各种方式来满足，包括提交ID（例如git提交ID或者Mercurial 更改列表id）或版本号（包括使用语义版本或基于日期的方案，如YYYYMMDD的版本号）。

其他版本编号方案，如提交ID（例如git commit id或mercurial changeset id）或基于日期的方案，如YYYYMMDD，可以用作版本号，因为它们是唯一的。一些备选方案可能会导致问题，因为用户可能无法轻松确定是否是最新的。如果所有目标客户仅运行最新版本，则SemVer可能不太有助于识别软件版本（例如，它是通过持续交付不断更新的单个网站或互联网服务的代码）。

发行说明可以以各种方式实施。许多项目将它们添加到名为“NEWS”，“CHANGELOG”或“ChangeLog”的文件中，可选的包含“.txt”，“.md”或“.html”等扩展名。历史上，术语“更改日志”是指每个更改的日志，但为了满足这些条款，需要的是可读取的摘要。发行说明可以由版本控制系统机制提供，例如 GitHub发布工作流程。

如果用户通常不能在自己的计算机上实际更新软件，而必须依靠中间人来执行升级（对于内核和与内核交织的底层软件通常是这种情况），项目可以选择“不适用”（N/A）。

答复可能是“不”或有关其价值的讨论。目的只是对某些请求有一些回应，这表明项目还活着。为了该条款的目的，项目不需要计数无效请求（例如，来自垃圾邮件发送者或自动系统）。如果项目不再进行增强，请选择“未满足”，并将介绍此情况的URL包含在内。如果一个项目有超出处理能力的增强需求数量，请选择“未满足”并解释。

例如，https://PROJECTSITE/security 上的一个明确指定的邮箱地址，通常以 security@example.org 的形式。这可能与其错误报告流程相同。漏洞报告可能一直是公开的，但是许多项目都有一个私密漏洞报告机制。

示例包括使用HTTPS（TLS）或使用OpenPGP加密的电子邮件在网络上提交的私密缺陷报告。如果漏洞报告总是公开的（从来没有私密漏洞报告），请选择“不适用”（N/A）。

如果过去6个月没有报告漏洞，请选择“不适用”（N/A）。

该项目可以使用多个自动测试套件（例如，一个是快速运行的测试套件，而另一个更为彻底但需要特殊设备）。

例如“make check”，“mvn test”或“rake test”。

只要有相应的策略，即使是通过口头传播，也就是说开发人员应该为主要的新功能在自动化测试套件中添加测试，选择“Met”。

主要功能通常在发行说明中提及。不需要完美，只需证明，当新的主要功能添加到项目生成的软件时，测试通常会在实践中被添加到自动化测试套件中。

但是，只要在实践中添加了测试，即使是非正式规则也是可以接受的。

编译器警告标志的例子包括gcc/clang “-Wall”。 “安全”语言模式的示例包括JavaScript “use strict”和perl5的“使用警告”。一个单独的“linter”工具用于检查源代码以查找代码质量错误或常见的简单错误。这些通常在源代码或构建指令中启用。

告警是通过执行warnings条款确定的。该项目应该修复告警或在源代码中将其标记为误报。理想情况下，不会有告警，但项目可能会接受一些告警（通常每100行小于1个告警，或整体少于10个告警）。

某些项目无法有效启用某些警告。需要证明的是，项目正在努力的启用警告标志，以便早期发现错误。

这需要了解以下设计原则，包括 Saltzer和Schroeder 中的8项原则：

• 机制经济（保持设计简单实用，例如采用彻底简化）
• 故障安全默认（默认情况下，访问决策应拒绝），项目安装应默认安全）
• 完全仲裁（必须检查每个可能被限制的访问权限，并且不可绕过）
• 开放式设计（安全机制不应该依赖于攻击者对其设计的无知，而应该更容易地保护和更改信息，例如密钥和密码）
• 特权分离（理想情况下，对重要对象的访问应该取决于多个条件，从而破坏一个保护系统将无法实现完全访问。如，多因子身份验证，要求密码和硬件令牌，比单因子认证安全性更高）
• 最小权限（进程应该以最少的权限运行）
• 最少的公共机制（设计应该最大限度地减少所有用户所依赖的，涉及到多个用户的共同机制，如，临时文件的目录）
• 心理可接受性（人机接口必须设计为易于使用 —— 设计为“最不惊讶”）
• 有限的攻击面（攻击面 —— 一组不同的入口，其​​中攻击者可以尝试输入或提取数据 —— 应该受到限制）
• 输入验证与白名单（输入通常应该在被接受之前检查以确定是否有效；此验证应使用白名单（仅接受已知的有效值），而不是黑名单（尝试列出已知的非法值））。

项目中的“主要开发人员”的定义是熟悉项目代码的任何人，很乐意对其进行更改，并被项目中大多数其他参与者确认。主要开发人员通常会在过去一年中通过代码，文档或回答问题提供一些贡献。开发人员通常被认为是主要开发人员，如果他们启动项目（并且还没有离开项目满三年），可以选择在私人漏洞报告渠道（如果有的话）上接收信息，可以代表项目接受提交，或执行项目软件的最终版本发布。如果只有一个开发者，那个人是主要开发人员。

示例（取决于软件的类型）包括SQL注入，操作系统注入，经典缓冲区溢出，跨站点脚本（XSS），缺少认证和缺少授权。请参阅 CWE/SANS 25种最常见漏洞或 OWASP十大漏洞类型项目。

这些加密条款并不总是适用，因为某些软件不需要直接使用加密功能。

请参阅OSI （开放源代码促进会）发布的软件开放标准需求。

这些最小位长度是：对称密钥112，因式分解模数2048，离散对数密钥224，离散对数组2048，椭圆曲线224和散列224（密码散列不涉及该位长度），关于密码散列的更多信息可以在 crypto_password_storage 条款）。请参阅 http://www.keylength.com 以比较不同组织的密钥长度建议。在某些配置中，软件可能允许较小的密钥长度（理想情况下不会，因为这允许降级攻击，但是互操作性有时需要较短的密钥长度）。

在许多情况下，最好选择设计用于组合保密和认证的块密码算法模式，例如Galois / Counter Mode（GCM）和EAX。项目可以允许用户为必要的兼容性启用已被破解的加密机制，但是需要用户知道他们正在这么做。

在 CERT：SSH CBC漏洞中讨论了SSH中CBC模式的问题。

此条款仅适用于软件强制使用密码验证用户身份的情况（如服务器端Web应用程序）。在软件存储用于认证到其他系统的密码（例如，该软件实现某个其他系统的客户端）的情况下，这是不适用的，因为该软件的至少某个部分必须经常访问未散列加密的密码。

密码安全的随机数生成器可以是硬件随机数生成器，或者它可以是使用诸如Hash_DRBG，HMAC_DRBG，CTR_DRBG，Yarrow或Fortuna之类的算法的加密安全的伪随机数生成器（CSPRNG）。对安全性随机数生成器的调用示例包括Java的java.security.SecureRandom和JavaScript的window.crypto.getRandomValues。调用不安全随机数生成器的示例包括Java的java.util.Random和JavaScript的Math.random。

一个更强大的机制是使用数字签名的软件包发布软件，因为这样可以减轻对分发系统的攻击，但只有在用户确信签名的公钥是否正确的情况下才可以确定。用户实际上会检查签名。

这些散列可以在传输过程中修改。

该漏洞必须由项目本身修补和发布（修补程序可能在其他地方开发）。一旦漏洞具有公开发布的非付费信息的CVE（例如，在国家漏洞数据库）或项目已被通知，且信息已经发布给公众（可能是项目自己发布），则视为漏洞已经公众所知。如果其 CVSS 2.0 基本分数为4或更高，则漏洞是中等到高的严重性。 注意：这意味着全世界的所有攻击者可能会对用户造成长达60天的伤害。这个标准通常比Google在重新启动负责任的披露中所推荐的容易得多。因为Google建议，如果报告不是公开的，那么当项目得到通知，甚至报告尚未公开时，60天的时间段就会开始。

项目可以泄漏测试和不重要数据库的“样本”凭据，只要它们不旨在限制公共访问。

静态代码分析工具检查软件代码（源代码，中间代码或可执行文件），而不用特定输入执行。本条款中，编译器警告和“安全”语言模式不被视为静态代码分析工具（它们通常避免深入分析，因为速度至关重要）。此类静态代码分析工具的示例包括 cppcheck ， clang静态分析器， FindBugs （包括FindSecurityBugs）， PMD ， Brakeman ， Coverity质量分析器和 HP Fortify静态代码分析器。更多的工具列表可以在诸如维基百科静态代码分析工具列表，关于静态代码分析的OWASP信息， NIST源代码安全分析器列表和 Wheeler的静态分析工具列表。 SWAMP 是使用各种工具评估软件漏洞的免费平台。如果没有可用于所使用的实现语言的FLOSS静态分析工具，请选择“N/A”。

专门设计用于寻找常见漏洞的静态分析工具更有可能找到它们。也就是说，使用任何静态工具通常会帮助找到一些问题，所以我们“通过”级别的徽章建议，但不要求这个条款。

如果其 CVSS 2.0 评分为4或更高，则此漏洞是中等到高的严重性。

动态分析工具通过执行特定输入来检查软件。例如，项目可以使用模糊工具（例如， American Fuzzy Lop ）或Web应用扫描程序（例如， OWASP ZAP 或 w3af ）。在某些情况下， OSS-Fuzz 项目可以对您的项目应用模糊测试。为满足此条款，动态分析工具需要以某种方式改变输入，以寻找各种问题，或者将其作为一个具有至少80％分支覆盖率的自动测试套件。 动态分析维基百科页面和 OWASP的fuzzing页面 识别一些动态分析工具。分析工具可能专注于寻找安全漏洞，但这不是必需的。

检测内存安全问题的机制的示例包括AddressSanitizer（ASAN）（可在GCC和LLVM中使用），“Memory Sanitizer”和 valgrind 。其他可能使用的工具包括ThreadSanitizer和UndefinedBehaviorSanitizer。广泛的断言也将起作用。

This criterion does not suggest enabling assertions during production; that is entirely up to the project and its users to decide. This criterion's focus is instead to improve fault detection during dynamic analysis before deployment. Enabling assertions in production use is completely different from enabling assertions during dynamic analysis (such as testing). In some cases enabling assertions in production use is extremely unwise (especially in high-integrity components). There are many arguments against enabling assertions in production, e.g., libraries should not crash callers, their presence may cause rejection by app stores, and/or activating an assertion in production may expose private data such as private keys. Beware that in many Linux distributions NDEBUG is not defined, so C/C++ assert() will by default be enabled for production in those environments. It may be important to use a different assertion mechanism or defining NDEBUG for production in those environments.

如果 CVSS 2.0 基本分数为4，那么一个漏洞是中等到高的严重性。如果您没有运行动态代码分析，没有发现任何这样的漏洞，选择“不适用”（N/A）。