FLOSS 最佳实践标准(所有级别)

这是自由/自由和开源软件(FLOSS)项目的最佳实践集,以在通过,银色和金色徽章级别获得核心基础设施计划(CII)最佳实践徽章。您可以仅使用标准其他信息来显示此列表。您还可以仅查看通过标准,以及标准统计信息

有关这些条件的更多信息,请参见条件讨论

通过

基本

基本项目网站内容

  • 项目网站必须简明扼要地描述软件的作用(它解决了什么问题?)。 [description_good]
    详细信息:
    必须采用潜在用户可以理解的语言(例如,它使用最少的术语/行话)。
  • 项目网站必须提供有关如何获取和提供反馈(错误报告或增强功能)以及如何贡献的信息。 [interact]
  • 关于如何贡献的信息必须解释贡献流程(例如,是否使用拉请求?) {Met URL} [contribution]
    详细信息:
    除非另有说明,否则我们假定 GitHub上的项目使用问题列表(Issues)和拉(Pull)请求。这些信息可以简短,例如,说明项目使用拉请求,问题跟踪器或邮寄到邮件列表中的哪一个。
  • 关于如何贡献的信息应包括对可接受的贡献的要求(例如,引用任何所需的编码标准)。 {Met URL} [contribution_requirements]

FLOSS许可证

文档

  • 项目必须为项目生成的软件提供基本文档。 {N/A justification} [documentation_basics]
    详细信息:
    该文档必须在某些媒体(例如文本或视频)中,包括:如何安装它,如何启动它,如何使用它(可能使用教程使用示例)以及如何安全地使用它(例如,做什么和不做什么),如果这是软件的一个适当的话题。安全文档不需要太长篇幅。项目可以使用非项目内容的超文本链接作为文档。如果项目不生产软件,请选择“不适用”(N/A)。
  • 项目必须提供描述项目生成的软件的外部接口(输入和输出)的参考文档。 {N/A justification} [documentation_interface]
    详细信息:
    外部接口的文档向最终用户或开发人员解释如何使用它。这将包括其应用程序接口(API),如果软件有。如果它是一个库,记录可以调用的主要类/类型和方法/函数。如果是Web应用程序,定义其URL接口(通常是其REST接口)。如果是命令行界面,请记录其支持的参数和选项。在许多情况下,最好是自动生成大部分文档,以便本文档随着软件的更改而保持同步,但这并不是必需的。项目可以使用非项目材料的超文本链接作为文档。文档可以自动生成(实际上这通常是最好的方法)。可以使用Swagger / OpenAPI生成REST接口的文档。代码界面文档可以使用 JSDoc (JavaScript), ESDoc (JavaScript),pydoc(Python)和Doxygen(很多)。仅在实现代码中添加注释不足以满足本条款;在没有阅读所有源代码的情况下,需要一个简单的方法来查看信息。如果项目不生产软件,请选择“不适用”(N/A)。

其他

  • 项目网站(网站,存储库和下载URL)必须使用TLS支持HTTPS。 [sites_https]
    详细信息:
    您可以从Let's Encrypt获取免费证书。项目可以使用(例如) GitHub页面实现此条款, GitLab页面,或 SourceForge项目页面。如果您使用具有自定义域的GitHub页面,则可以使用内容传送网络(CDN)作为代理来支持HTTPS,例如博客文章“使用CloudFlare安全加速GitHub页面”,以满足此条款。如果您支持HTTP,我们敦促您将HTTP流量重定向到HTTPS。
  • 该项目必须有一个或多个讨论机制(包括建议的更改和问题),可搜索,允许通过URL访问消息和主题,使新人能够参与一些讨论,并且不需要客户端安装专有软件。 [discussion]
    详细信息:
    可接受机制的示例包括归档邮件列表,GitHub问题和拉请求讨论,Bugzilla,Mantis和Trac。如果满足这些标准,异步讨论机制(如IRC)是可以接受的;确保有一个URL可访问归档机制。允许专有JavaScript,但不鼓励。
  • 项目应该提供英文文档,并能够接受英文的代码的错误报告和评论。 [english]
    详细信息:
    英语是计算机技术的通用语言;支持英语增加了全球不同潜在开发者和检视者的数量。即使核心开发人员的主要语言不是英文,项目也可以达到这个标准。

变更控制

公开的版本控制的源代码存储库

  • 该项目必须有一个版本控制的源代码存储库。它必须是公开可读的并可通过URL访问。 [repo_public]
    详细信息:
    该URL可以与项目URL相同。该项目可能在特定情况下使用私人(非公开)分支,而更改不会公开发布(例如,在向公众披露漏洞之前修复漏洞)。
  • 项目的源代码存储库必须跟踪所做的更改,谁进行了更改,何时进行了更改。 [repo_track]
  • 为了实现协作检视,项目的源代码存储库必须包括临时版本,以便检视版本之间的变化;它不得仅包括最终版本。 [repo_interim]
    详细信息:
    项目可以选择从其公共源代码库中删除特定的临时版本(例如,修复特定的未公开安全漏洞,可能永远不会公开发布的内容,或者包括不能合法发布而且不是最终版本的内容)。
  • 建议使用通用分布式版本控制软件(例如,git)作为项目的源代码存储库。 [repo_distributed]
    详细信息:
    Git不是必须,项目在合适场景可以使用集中版本控制软件(如subversion)。

唯一版本编号

  • 项目生成的用于每个用户使用的版本必须具有唯一版本标识符。 [version_unique]
    详细信息:
    本条款可以通过各种方式来满足,包括提交ID(例如git提交ID或者Mercurial 更改列表id)或版本号(包括使用语义版本或基于日期的方案,如YYYYMMDD的版本号)。
  • 建议使用语义版本控制(SemVer)格式进行发布。 [version_semver]
    详细信息:
    其他版本编号方案,如提交ID(例如git commit id或mercurial changeset id)或基于日期的方案,如YYYYMMDD,可以用作版本号,因为它们是唯一的。一些备选方案可能会导致问题,因为用户可能无法轻松确定是否是最新的。如果所有目标客户仅运行最新版本,则SemVer可能不太有助于识别软件版本(例如,它是通过持续交付不断更新的单个网站或互联网服务的代码)。
  • 建议项目识别其版本控制系统中的每个版本。例如,建议使用git的项目,使用git标签识别每个版本。 [version_tags]

发行说明

  • 该项目必须在每个版本中提供发布说明,这是该版本中主要变化的可读的摘要,以帮助用户确定是否应升级,升级影响将如何。发行说明不能是版本控制日志的原始输出(例如,“git log”命令结果不是发行说明)。其产出不适用于多个地点的项目(如单个网站或服务的软件),并采用持续交付,可以选择“N/A”。 {N/A justification} {Met URL} [release_notes]
    详细信息:
    发行说明可以以各种方式实施。许多项目将它们添加到名为“NEWS”,“CHANGELOG”或“ChangeLog”的文件中,可选的包含“.txt”,“.md”或“.html”等扩展名。历史上,术语“更改日志”是指每个更改的日志,但为了满足这些条款,需要的是可读取的摘要。发行说明可以由版本控制系统机制提供,例如 GitHub发布工作流程
  • 发行说明必须列出每个新版本中修复的每个公开的漏洞。如果没有发行说明或者没有公开的漏洞,选择“不适用”。 {N/A justification} [release_notes_vulns]
    详细信息:
    如果用户通常不能在自己的计算机上实际更新软件,而必须依靠中间人来执行升级(对于内核和与内核交织的底层软件通常是这种情况),项目可以选择“不适用”(N/A)。

报告

错误报告流程

  • 项目必须为用户提交错误报告(例如,使用问题跟踪器或邮件列表)提供相关流程。 {Met URL} [report_process]
  • 项目必须使用问题跟踪器来跟踪每个问题。 [report_tracker]
  • 该项目必须响应过去2-12个月内(含)提交的大多数错误报告;响应不需要包括修复。 [report_responses]
  • 该项目应该对过去2-12个月内(包括)的大部分(> 50%)的增强请求作出回应。 [enhancement_responses]
    详细信息:
    答复可能是“不”或有关其价值的讨论。目的只是对某些请求有一些回应,这表明项目还活着。为了该条款的目的,项目不需要计数无效请求(例如,来自垃圾邮件发送者或自动系统)。如果项目不再进行增强,请选择“未满足”,并将介绍此情况的URL包含在内。如果一个项目有超出处理能力的增强需求数量,请选择“未满足”并解释。
  • 该项目必须有一个公开的报告和回复的档案供后续搜索。 {Met URL} [report_archive]

漏洞报告流程

  • 项目必须在项目网站上发布报告漏洞的流程。 {Met URL} [vulnerability_report_process]
    详细信息:
    例如,https://PROJECTSITE/security 上的一个明确指定的邮箱地址,通常以 security@example.org 的形式。这可能与其错误报告流程相同。漏洞报告可能一直是公开的,但是许多项目都有一个私密漏洞报告机制。
  • 如果支持私有漏洞报告,项目必须包括如何以保密的方式发送信息。 {N/A allowed} {Met URL} [vulnerability_report_private]
    详细信息:
    示例包括使用HTTPS(TLS)或使用OpenPGP加密的电子邮件在网络上提交的私密缺陷报告。如果漏洞报告总是公开的(从来没有私密漏洞报告),请选择“不适用”(N/A)。
  • 该项目在过去6个月收到的任何漏洞报告的初始响应时间必须小于或等于14天。 {N/A allowed} [vulnerability_report_response]
    详细信息:
    如果过去6个月没有报告漏洞,请选择“不适用”(N/A)。

质量

可工作的构建系统

  • 如果项目生成的软件需要构建使用,项目必须提供可以从源代码自动重新构建软件的可工作的构建系统。 {N/A allowed} [build]
    详细信息:
    构建系统确定重建软件(以及以什么顺序)需要执行哪些操作,然后执行这些步骤。例如,它可以调用编译器来编译源代码。如果从源代码创建可执行文件,则必须可以修改项目的源代码,然后通过这些修改生成更新的可执行文件。如果项目生成的软件取决于外部库,则构建系统不必构建那些外部库。如果在修改源代码之后不需要构建任何使用该软件的软件,请选择“不适用”(N/A)。
  • 建议使用通用工具来构建软件。 {N/A allowed} [build_common_tools]
    详细信息:
    例如,Maven,Ant,cmake,自动工具,make,rake(Ruby)或devtools (R)。
  • 该项目应该仅使用FLOSS工具来构建。 {N/A allowed} [build_floss_tools]

自动测试套件

  • 该项目必须使用至少一个作为FLOSS公开发布的自动测试套件(该测试套件可以作为单独的FLOSS项目维护)。 [test]
    详细信息:
    该项目可以使用多个自动测试套件(例如,一个是快速运行的测试套件,而另一个更为彻底但需要特殊设备)。
  • 测试套件应该以该语言的标准方式进行调用。 [test_invocation]
    详细信息:
    例如“make check”,“mvn test”或“rake test”。
  • 建议测试套件覆盖大部分(或理想情况下所有)代码分支,输入字段和功能。 [test_most]
  • 建议项目实施持续集成,将新的或更改的代码经常集成到中央代码库中,并对结果进行自动化测试。 [test_continuous_integration]

新功能测试

  • 该项目必须有通用的策略(正式或非正式),当主要的新功能被添加到项目生成的软件中,该功能的测试应该同时添加到自动测试套件。 [test_policy]
    详细信息:
    只要有相应的策略,即使是通过口头传播,也就是说开发人员应该为主要的新功能在自动化测试套件中添加测试,选择“Met”。
  • 该项目必须有证据表明,在项目生成的软件的最近重大变化中,已经遵守了添加测试的条款: test_policy [tests_are_added]
    详细信息:
    主要功能通常在发行说明中提及。不需要完美,只需证明,当新的主要功能添加到项目生成的软件时,测试通常会在实践中被添加到自动化测试套件中。
  • 建议您在更改提案的说明文档中添加测试策略要求(请参阅test_policy)。 [tests_documented_added]
    详细信息:
    但是,只要在实践中添加了测试,即使是非正式规则也是可以接受的。

警告标志

  • 该项目必须启用一个或多个编译器警告标志,“安全”语言模式,或者使用单独的“linter”工具查找代码质量错误或常见的简单错误,如果至少有一个FLOSS工具可以在所选择的语言实现此条款。 {N/A allowed} [warnings]
    详细信息:
    编译器警告标志的例子包括gcc/clang “-Wall”。 “安全”语言模式的示例包括JavaScript “use strict”和perl5的“使用警告”。一个单独的“linter”工具用于检查源代码以查找代码质量错误或常见的简单错误。这些通常在源代码或构建指令中启用。
  • 该项目必须处理警告。 {N/A allowed} [warnings_fixed]
    详细信息:
    告警是通过执行warnings条款确定的。该项目应该修复告警或在源代码中将其标记为误报。理想情况下,不会有告警,但项目可能会接受一些告警(通常每100行小于1个告警,或整体少于10个告警)。
  • 建议在实际情况下,项目以最严格方式对待项目生成的软件中的告警。 {N/A allowed} [warnings_strict]
    详细信息:
    某些项目无法有效启用某些警告。需要证明的是,项目正在努力的启用警告标志,以便早期发现错误。

安全

安全开发知识

  • 该项目必须至少有一个主要开发人员知道如何设计安全软件。 [know_secure_design]
    详细信息:
    这需要了解以下设计原则,包括 Saltzer和Schroeder 中的8项原则:
    • 机制经济(保持设计简单实用,例如采用彻底简化)
    • 故障安全默认(默认情况下,访问决策应拒绝),项目安装应默认安全)
    • 完全仲裁(必须检查每个可能被限制的访问权限,并且不可绕过)
    • 开放式设计(安全机制不应该依赖于攻击者对其设计的无知,而应该更容易地保护和更改信息,例如密钥和密码)
    • 特权分离(理想情况下,对重要对象的访问应该取决于多个条件,从而破坏一个保护系统将无法实现完全访问。如,多因子身份验证,要求密码和硬件令牌,比单因子认证安全性更高)
    • 最小权限(进程应该以最少的权限运行)
    • 最少的公共机制(设计应该最大限度地减少所有用户所依赖的,涉及到多个用户的共同机制,如,临时文件的目录)
    • 心理可接受性(人机接口必须设计为易于使用 —— 设计为“最不惊讶”)
    • 有限的攻击面(攻击面 —— 一组不同的入口,其​​中攻击者可以尝试输入或提取数据 —— 应该受到限制)
    • 输入验证与白名单(输入通常应该在被接受之前检查以确定是否有效;此验证应使用白名单(仅接受已知的有效值),而不是黑名单(尝试列出已知的非法值))。
    项目中的“主要开发人员”的定义是熟悉项目代码的任何人,很乐意对其进行更改,并被项目中大多数其他参与者确认。主要开发人员通常会在过去一年中通过代码,文档或回答问题提供一些贡献。开发人员通常被认为是主要开发人员,如果他们启动项目(并且还没有离开项目满三年),可以选择在私人漏洞报告渠道(如果有的话)上接收信息,可以代表项目接受提交,或执行项目软件的最终版本发布。如果只有一个开发者,那个人是主要开发人员。
  • 该项目的主要开发人员中,至少有一个必须知道导致这类型软件漏洞的常见错误类型,以及至少有一种方法来对付或缓解这些漏洞。 [know_common_errors]
    详细信息:
    示例(取决于软件的类型)包括SQL注入,操作系统注入,经典缓冲区溢出,跨站点脚本(XSS),缺少认证和缺少授权。请参阅 CWE/SANS 25种最常见漏洞 OWASP十大漏洞类型项目

使用基础的良好加密实践

  • 项目生成的软件默认情况下,只能使用由专家公开发布和审查的加密协议和算法(如果使用加密协议和算法)。 {N/A allowed} [crypto_published]
    详细信息:
    这些加密条款并不总是适用,因为某些软件不需要直接使用加密功能。
  • 如果项目生成的软件是应用程序或库,其主要目的不是实现加密,那么它应该只调用专门设计实现加密功能的软件,而不应该重新实现自己的。 {N/A allowed} [crypto_call]
  • 项目所产生的软件中,所有依赖于密码学的功能必须使用FLOSS实现。 {N/A allowed} [crypto_floss]
    详细信息:
    请参阅OSI (开放源代码促进会)发布的软件开放标准需求
  • 项目生成的软件中的安全机制使用的默认密钥长度必须至少达到2030年(如2012年所述)的NIST最低要求。必须提供配置,以使较小的密钥长度被完全禁用。 {N/A allowed} [crypto_keylength]
    详细信息:
    这些最小位长度是:对称密钥112,因式分解模数2048,离散对数密钥224,离散对数组2048,椭圆曲线224和散列224(密码散列不涉及该位长度),关于密码散列的更多信息可以在 crypto_password_storage 条款)。请参阅 http://www.keylength.com 以比较不同组织的密钥长度建议。在某些配置中,软件可能允许较小的密钥长度(理想情况下不会,因为这允许降级攻击,但是互操作性有时需要较短的密钥长度)。
  • 项目产生的软件中的默认安全机制不得取决于已被破解的密码算法(例如,MD4,MD5,单DES,RC4,Dual_EC_DRBG)或使用不适合上下文的密码模式(例如,ECB模式几乎不适当,因为它揭示了密文中相同的块,如 ECB企鹅所示。CTR模式通常是不合适的,因为如果重复输入状态,则它不执行认证并导致重复)。 {N/A allowed} [crypto_working]
    详细信息:
    在许多情况下,最好选择设计用于组合保密和认证的块密码算法模式,例如Galois / Counter Mode(GCM)和EAX。项目可以允许用户为必要的兼容性启用已被破解的加密机制,但是需要用户知道他们正在这么做。
  • 由项目产生的软件中的默认安全机制不应该依赖于具有已知严重弱点的加密算法或模式(例如,SHA-1密码散列算法或SSH中的CBC模式)。 {N/A allowed} [crypto_weaknesses]
    详细信息:
    CERT:SSH CBC漏洞中讨论了SSH中CBC模式的问题。
  • 项目产生的软件中的安全机制应该​​对密钥协商协议实施完美的前向保密(PFS),如果长期密钥集合中的一个长期密钥在将来泄露,也不能破坏从一组长期密钥导出的会话密钥。 {N/A allowed} [crypto_pfs]
  • 如果项目产生的软件存储用于外部用户认证的密码,则必须使用密钥拉伸(迭代)算法(例如,PBKDF2,Bcrypt或Scrypt)将密码存储为每用户盐值不同的迭代散列 。 {N/A allowed} [crypto_password_storage]
    详细信息:
    此条款仅适用于软件强制使用密码验证用户身份的情况(如服务器端Web应用程序)。在软件存储用于认证到其他系统的密码(例如,该软件实现某个其他系统的客户端)的情况下,这是不适用的,因为该软件的至少某个部分必须经常访问未散列加密的密码。
  • 由项目生成的软件中的安全机制必须使用密码学安全的随机数生成器生成所有加密密钥和随机数,并且不得使用密码学不安全的生成器。 {N/A allowed} [crypto_random]
    详细信息:
    密码安全的随机数生成器可以是硬件随机数生成器,或者它可以是使用诸如Hash_DRBG,HMAC_DRBG,CTR_DRBG,Yarrow或Fortuna之类的算法的加密安全的伪随机数生成器(CSPRNG)。对安全性随机数生成器的调用示例包括Java的java.security.SecureRandom和JavaScript的window.crypto.getRandomValues。调用不安全随机数生成器的示例包括Java的java.util.Random和JavaScript的Math.random。

安全交付防御中间人(MITM)的攻击

  • 该项目必须使用一种针对MITM攻击的传递机制。使用https或ssh + scp是可以接受的。 [delivery_mitm]
    详细信息:
    一个更强大的机制是使用数字签名的软件包发布软件,因为这样可以减轻对分发系统的攻击,但只有在用户确信签名的公钥是否正确的情况下才可以确定。用户实际上会检查签名。
  • 不得通过http协议获取加密散列(例如,sha1sum)并直接使用,而不检查密码学签名。 [delivery_unsigned]
    详细信息:
    这些散列可以在传输过程中修改。

修正公开的漏洞

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

其他安全问题

  • 公共存储库不得泄漏旨在限制公众访问的有效私人凭证(例如,工作密码或私钥)。 [no_leaked_credentials]
    详细信息:
    项目可以泄漏测试和不重要数据库的“样本”凭据,只要它们不旨在限制公共访问。

分析

静态代码分析

动态代码分析

  • 建议在发布之前,至少将一个动态分析工具应用于软件任何发布的主要生产版本。 [dynamic_analysis]
    详细信息:
    动态分析工具通过执行特定输入来检查软件。例如,项目可以使用模糊工具(例如, American Fuzzy Lop )或Web应用扫描程序(例如, OWASP ZAP w3af )。在某些情况下, OSS-Fuzz 项目可以对您的项目应用模糊测试。为满足此条款,动态分析工具需要以某种方式改变输入,以寻找各种问题,或者将其作为一个具有至少80%分支覆盖率的自动测试套件。 动态分析维基百科页面 OWASP的fuzzing页面 识别一些动态分析工具。分析工具可能专注于寻找安全漏洞,但这不是必需的。
  • 建议如果项目生成的软件包含使用内存不安全语言编写的软件(例如C或C++),则至少有一个动态工具(例如,fuzzer或web应用扫描程序)与检测缓冲区覆盖等内存安全问题的机制例行应用。如果该项目生成的软件没有以内存不安全语言编写,请选择“不适用”(N / A)。 {N/A allowed} [dynamic_analysis_unsafe]
    详细信息:
    检测内存安全问题的机制的示例包括AddressSanitizer(ASAN)(可在GCC和LLVM中使用),“Memory Sanitizer” valgrind 。其他可能使用的工具包括ThreadSanitizerUndefinedBehaviorSanitizer。广泛的断言也将起作用。
  • 建议由项目生成的软件包括许多运行时断言,在动态分析期间检查。 [dynamic_analysis_enable_assertions]
    详细信息:
    这个标准并不建议使生产过程中的断言;这完全取决于项目及其用户的决定。该标准的重点是部署之前的动态分析过程中改善故障检测。在生产使用中启用断言与在动态分析(例如测试)期间启用断言完全不同。在某些情况下,在生产中使用断言是极其不明智的(尤其是在高完整性组件中)。存在许多反对在生产环境中启用断言的论点,例如,库不应使调用程序崩溃,它们的存在可能会导致应用商店拒绝,和/或在生产环境中激活断言可能会暴露诸如私钥之类的私有数据。请注意,在许多Linux发行版中都未定义NDEBUG ,因此C / C ++缺省情况下,assert()将在这些环境中启用生产。对于那些环境中的生产,使用不同的断言机制或定义NDEBUG可能很重要。
  • 通过动态代码分析发现的所有严重性为中,高的可利用漏洞必须在确认后及时修复。 {N/A allowed} [dynamic_analysis_fixed]
    详细信息:
    如果 CVSS 2.0 基本分数为4,那么一个漏洞是中等到高的严重性。如果您没有运行动态代码分析,没有发现任何这样的漏洞,选择“不适用”(N/A)。

白银

基本

先决条件

基本项目网站内容

  • 关于如何贡献的信息必须包括对可接受的贡献的要求(例如,引用任何所需的编码标准)。 {Met URL} [contribution_requirements]

项目监督

  • 该项目应该有一个合法机制,所有对项目软件做出显著贡献的开发人员都声明他们有合法授权作出这些贡献。最常用且易于实施的方法是使用开发者原产地证书(DCO),用户可以在其提交中添加“signed-off-by”,另外,项目链接到DCO网站。本条款也可以使用贡献者许可协议(CLA)或其他法律机制实现。 {Met URL} [dco]
    详细信息:
    DCO是推荐的机制,因为它易于实现,在源代码中进行跟踪,并且git使用“commit -s”直接支持“签名”功能。更有效的是,项目文件解释了该项目的“签名”手段。 CLA是一项法律协议,用于定义知识产权许可给组织或项目的条款。捐助者转让协议(CAA)是将知识产权权利转让给另一方的法律协议;项目不必具备CAA,因为CAA增加了潜在贡献者不愿贡献的风险,特别是如果接收者是一个营利性组织。 Apache Software Foundation CLA(个人贡献者许可证和公司CLA)是CLA的示例,用于确定项目的这些CLA的风险对项目的影响小于其获益。
  • 该项目必须明确定义和记录其项目治理模式(决策方式,包括关键角色)。 {Met URL} [governance]
    详细信息:
    需要有一些成熟的书面方式来作出决定和解决争端。在小项目中,这可能就像“项目拥有者和负责人做所有最终决定”一样简单。有各种治理模式,包括仁慈的独裁者和正式的精英统治;有关详细信息,请参阅治理模式。集中式(例如,单一维护者)和分散式(例如,组维护者)方法都已经在项目中成功使用。治理信息不需要记录创建项目分支的可能性,因为对于FLOSS项目来说总是可能的。
  • 该项目必须采取行为守则,并将其发布在标准的位置。 {Met URL} [code_of_conduct]
    详细信息:
    项目可能能够提高社区的文明程度,并通过采取行为守则来规定对可接受的行为的期望。这可以帮助在发生问题之前避免问题,并使项目成为更加欢迎的地方来鼓励贡献。这应该只关注项目社区/工作场所的行为。行为规范的示例是贡献者约定行为准则和Linux内核代码冲突
  • 该项目必须明确定义和公开记录项目中的关键角色及其职责,包括这些角色必须执行的任务。必须清楚指出谁是什么角色,尽管这可能没有以相同的方式记录下来。 {Met URL} [roles_responsibilities]
    详细信息:
    治理和角色和职责的文档可以在一个地方。
  • 如果任何一个开发者丧失工作能力或丧生,该项目必须能够继续保持最小的中断。特别是,在确认个人无行为能力或死亡的一周内,项目必须能够创建和关闭问题,接受提议的更改和发布软件版本。这可以通过确保其他人有任何必要的密钥,密码和合法权利来继续该项目。运行FLOSS项目的个人可以通过在锁箱中提供密钥,并提供任何所需的合法权利(例如DNS名称)来实现。 {Met URL} [access_continuity]
  • 项目必须具有2个或更多的“公交车因子”。 {Met URL} [bus_factor]
    详细信息:
    “公交车系数”(又名“卡车因子”)是指最少数量的项目成员,如果突然离开项目(“被公交车撞了”),项目会由于缺乏具备知识的或有能力的人员而暂停。 卡车因子 工具可以对GitHub上的项目进行估计。有关详细信息,请参阅Cosentino等人的评估Git存储库的卡车因子

文档

  • 该项目必须有一个文档化的路线图,描述项目打算做什么,至少在下一年做什么。 {Met URL} [documentation_roadmap]
    详细信息:
    项目可能没有实现路线图,没关系。路线图的目的是帮助潜在的用户和贡献者了解项目的预期方向。它不需要特别详细。
  • 该项目必须包括项目生成的软件的架构(也称为高级别设计)的文档。如果项目不产生软件,请选择“不适用”(N/A)。 {N/A justification} {Met URL} [documentation_architecture]
    详细信息:
    软件架构解释了程序的基本结构,即程序的主要组件,它们之间的关系以及这些组件和关系的关键属性。
  • 该项目必须书面记录用户从项目生成的软件的安全性上可以获得和不能指望的内容(其“安全需求”)。 {Met URL} [documentation_security]
    详细信息:
    这些是软件意图满足的安全需求。
  • 该项目必须为新用户提供“快速启动”指南,以帮助他们快速使用该软件。 {N/A justification} {Met URL} [documentation_quick_start]
    详细信息:
    这个想法是向用户展示如何入门,使软件完全可以做事情。这对于潜在用户是至关重要的。
  • 项目必须努力使文档与当前版本的项目结果(包括项目生成的软件)保持一致。任何已知的文档缺陷使其不一致必须修正。如果文档基本是最新的,但是错误地包括一些不再是真实的旧信息,那么将其视为缺陷,然后像往常一样进行跟踪和修复。 {N/A justification} {Met justification} [documentation_current]
    详细信息:
    该文档可以包括有关软件版本之间的差异或更改的信息,与/或链接到旧版本的文档。这个条款的意图在于努力保持文档的一致性,而不是文档必须完美。
  • 项目存储代码库首页和/或网站必须在获得成就的48小时内标识并超链接任何成就,包括此最佳实践徽章。 {Met URL} [documentation_achievements]
    详细信息:
    一个成就是项目致力于满足的任何外部条款,包括徽章。该信息不需要在项目网站首页上。使用GitHub的项目可以通过将其添加到README文件中,将成果放在存储代码库首页。

无障碍和国际化

  • 该项目(项目网站和项目成果)都应遵循无障碍最佳做法,使残疾人仍然可以参与项目,并在合理的情况下使用项目成果。 {N/A justification} {Met justification} [accessibility_best_practices]
    详细信息:
    对于Web应用程序,请参阅 Web 内容无障碍指导 (WCAG 2.0,英文) 以及其支持文档 理解 WCAG 2.0(英文);或者 W3C 无障碍信息(英文). 图形界面(GUI)应用考虑使用环境特定的无障碍指导(例如 Gnome, KDE, XFCE, Android, iOS, Mac, 以及 Windows). 一些TUI应用 (例如,`ncurses` 程序) 可以做一些特定的工作,增强可访问性(例如,`alpine` 的 `force-arrow-cursor` 设置)。多数命令行应用没有特别的无障碍设置。本条款经常是不涉及(N/A),例如,对于组件库。以下是一些要采取的行动或需要考虑的问题的例子:
    • 提供非文字内容的文字替代,以便于转换为其他需要的格式,如大字体、盲文、语音、符号或者简单文字( WCAG 2.0 指导 1.1 (英文))
    • 颜色不被用作传达信息,指示动作,提示响应或区分视觉元素的唯一视觉方式。 ( WCAG 2.0 指导 1.4.1(英文))
    • 文本和文字图像的视觉呈现对比度至少为4.5:1,除了大文本,次要文本和标识符之外。 ( WCAG 2.0 指导 1.4.3(英文))
    • 使用键盘可访问所有功能 (WCAG 指导 2.1)
    • 图形界面应用(GUI)或者Web应用在目标平台上,应该至少使用一种屏幕阅读器测试(例如,NVDA;Jaws;Windows上的WindowEyes;Mac & iOS上的VoiceOver;Linux/BSD上的Orca;Android上的TalkBack)。TUI程序可以减少过度渲染以防止屏幕阅读器的冗余读取。
  • 该项目产生的软件应该被国际化,以便为目标受众的文化,地区或语言进行简单的本地化。如果国际化(i18n)不适用(例如,该软件不会生成针对最终用户的文本,并且不排序可读文本),请选择“不适用”(N/A)。 {N/A justification} {Met justification} [internationalization]
    详细信息:
    本地化“是指适应产品,应用或文档内容以满足特定目标市场(语言环境)的语言,文化和其他要求。国际化是“设计和开发产品,应用或文档内容,使不同文化,地区或语言的目标受众更容易本地化”。 (请参阅 W3C的“本地化与国际化”)。软件只需通过国际化即可达到此标准。不需要另一种特定语言的本地化,因为一旦软件已被国际化,其他人就可以从事本地化。

其他

  • 如果项目站点(网站,存储库和下载URL)存储用于外部用户认证的密码,则必须使用密钥拉伸(迭代)算法将密码存储为具有每用户盐值的迭代散列(例如,PBKDF2,Bcrypt或Scrypt)。如果项目站点不存储密码,请选择“不适用”(N/A)。 {N/A justification} {Met justification} [sites_password_security]
    详细信息:
    请注意,使用 GitHub 符合此条款。此条款仅适用于用于外部用户认证到项目站点的密码。如果项目站点必须登录到其他站点,则可能需要为此目的存储密码(因为使用像Bcrypt这样的算法会使这些密码无效)。本条款将 crypto_password_storage 条款应用于项目站点,类似于sites_https条款。

变更控制

之前的版本

  • 该项目必须维护最常用的旧版本的产品提供较新版本的升级路径。如果升级路径很困难,项目必须记录如何执行升级(例如,给出更改的接口描述和详细的建议步骤以帮助升级)。 {N/A justification} {Met justification} [maintenance_or_update]

报告

错误报告流程

  • 项目必须使用问题跟踪器来跟踪每个问题。 {N/A justification} {Met justification} [report_tracker]

漏洞报告流程

  • 除了要求匿名的报告者外,该项目必须对过去12个月内解决的所有漏洞报告的报告者表示感谢。如果过去12个月没有修复漏洞,请选择“不适用”(N/A)。 {N/A justification} {Met URL} [vulnerability_report_credit]
  • 该项目必须有一个书面的流程来响应漏洞报告。 {Met URL} [vulnerability_response_process]
    详细信息:
    这与security_report_process有很强的相关性,它需要有一个书面的流程来报告漏洞。它还涉及到spam_report_response,它需要在一定时间内响应漏洞报告。

质量

编码标准

  • 该项目必须确定其使用的主要语言的具体编码风格指南,并要求贡献一般情况下符合此要求。 {N/A justification} {Met URL} [coding_standards]
    详细信息:
    在大多数情况下,这是通过参考一些现有的风格指南来完成的,可能列出差异。这些风格指南可以包括提高可读性的方法和减少缺陷可能性(包括漏洞)的方法。许多编程语言有一个或多个广泛使用的风格指南。样式指南的示例包括 Google风格指南(英文) SEI CERT编码标准(英文)
  • 如果至少有一个FLOSS工具可以应用于所选择的语言,项目必须自动执行其选定的编码风格。 {N/A justification} {Met justification} [coding_standards_enforced]
    详细信息:
    这可以使用静态分析工具和/或通过代码重新格式化强制代码实现。在许多情况下,工具配置包含在项目的存储库中(因为不同的项目可能会选择不同的配置)。项目可以允许风格例外(通常会);在发生例外的情况下(应该很少),它们必须在其位置的代码中记录在案,以便可以对这些例外进行检视,并使工具能够在将来自动处理它们。这些工具的例子包括ESLint(JavaScript)和Rubocop(Ruby)。

可工作的构建系统

  • 本地二进制文件的构建系统必须遵守传递给它们的相关编译器和链接器(环境)变量(例如CC,CFLAGS,CXX,CXXFLAGS和LDFLAGS),并将它们传递给编译器和链接器。构建系统可以使用附加标志来扩展它们,但不能简单地用自己的替换提供的值。如果没有生成本地二进制文件,请选择“不适用”(N/A)。 {N/A justification} {Met justification} [build_standard_variables]
    详细信息:
    应该很容易启用特殊的构建功能,如地址消毒剂(Address Sanitizer,ASAN),或符合发布加固最佳实践(例如,通过轻松打开编译器标志来实现)。
  • 构建和安装系统在在相关标志中要求时,应该保留调试信息(例如,“install -s”未被使用)。如果没有构建或安装系统(例如典型的JavaScript库),请选择“不适用”(N/A)。 {N/A justification} {Met justification} [build_preserve_debug]
    详细信息:
    例如,如果使用这些语言,则应该设置CFLAGS(C)或CXXFLAGS(C ++)创建相关的调试信息,并且在安装过程中不应该剥离它们。支持和分析时,需要调试信息,也可用于测量编译二进制文件中加固特性的存在。
  • 如果子目录中存在交叉依赖关系,则由项目生成的软件的构建系统必须不能递归地构建子目录。如果没有构建或安装系统(例如典型的JavaScript库),请选择“不适用”(N/A)。 {N/A justification} {Met justification} [build_non_recursive]
    详细信息:
    项目构建系统的内部依赖关系信息需要准确,否则,对项目的更改可能无法正确构建。不正确的构建可能会导致缺陷(包括漏洞)。大型构建系统中的常见错误是使用“递归构建”或“递归生成”,即包含源文件的子目录的层次结构,其中每个子目录都是独立构建的。除非每个子目录完全独立,否则这是一个错误,因为依赖关系信息不正确。
  • 该项目必须能够重复从源代码文件生成的过程,并获得完全相同的比特位结果。如果没有发生构建(例如,直接使用源代码而不是编译使用的脚本语言),请选择“不适用”(N/A)。 {N/A justification} {Met justification} [build_repeatable]
    详细信息:
    GCC和clang用户可能会发现-frandom-seed选项有用;在某些情况下,这可以通过强制某种排序来解决。更多建议可以在可重复构建(英文)站点找到。

安装系统

  • 该项目必须提供一种使用常用惯例轻松安装和卸载由项目生成的软件的方法。 {N/A justification} {Met justification} [installation_common]
    详细信息:
    示例包括使用软件包管理器(在系统或语言级别),“make install/uninstall”(支持DESTDIR),标准格式的容器或标准格式的虚拟机映像。安装和卸载过程(例如,打包)可以由第三方FLOSS软件实现。
  • 最终用户的安装系统必须遵守用于在安装时选择构建工件写入位置的标准约定。例如,如果在POSIX系统上安装文件,它必须遵守DESTDIR环境变量。如果没有安装系统或没有标准惯例,请选择“不适用”(N/A)。 {N/A justification} {Met justification} [installation_standard_variables]
  • 该项目必须为潜在开发人员提供一种快速安装所有项目成果和支持环境所必需的环境,包括测试套件和测试环境。必须通过常规惯例执行。 {N/A justification} {Met justification} [installation_development_quick]
    详细信息:
    可以使用生成的容器和/或安装脚本来实现。外部依赖关系一般通过调用系统和/或语言包管理器(根据 external_dependencies 条款)进行安装。

外部维护的组件

  • 项目必须以计算机可处理的方式列出外部依赖关系。 {N/A justification} {Met URL} [external_dependencies]
    详细信息:
    通常这是使用包管理器和/或构建系统的约定完成的。请注意,这有助于实施 installation_development_quick
  • 项目必须监视或定期检查其外部依赖(包括便利副本)以检测已知的漏洞,并修复可利用的漏洞或将其验证为不可利用的漏洞。 {N/A justification} {Met justification} [dependency_monitoring]
    详细信息:
    这可以使用源分析器/依赖项检查工具/软件组成分析工具(例如OWASP的Dependency-CheckSonatype的Nexus AuditorSynopsys的Black Duck软件组成分析Bundler-audit(针对Ruby))来完成。一些程序包管理器包括执行此操作的机制。如果无法利用组件的漏洞,这是可以接受的,但是这种分析是困难的,有时简单地更新或修复零件就更容易。
  • 该项目必须满足下述情况之一:
    1. 可以轻松识别和更新重用的外部维护组件;
    2. 使用系统或编程语言提供的标准组件。
    这样,如果在重用的组件中发现了一个漏洞,将容易更新该组件。 {N/A justification} {Met justification} [updateable_reused_components]
    详细信息:
    符合这一条款的典型方法是使用系统和编程语言的包管理系统。许多FLOSS程序与“便利库”一起分发,这些库是标准库的本地副本(可能是分支)。一般没问题。但是,如果程序*必须*使用这些本地(分支)副本,则“标准”库的安全更新将使这些附加副本仍然易受攻击。这对于基于云的系统尤其是一个问题;如果云提供商更新他们的“标准”库,但程序不会使用它们,那么这些更新实际上不会有帮助。参见,例如,“Chromium:为什么它不在Fedora中作为适当的包”(Tom Callaway)
  • 该项目应避免使用已弃用或过时的功能和API,如果FLOSS替代品在其使用的技术集合(“技术堆栈”)中以及项目支持的大多数用户中可用(以便用户可以随时访问该替代品)。 {N/A justification} {Met justification} [interfaces_current]

自动测试套件

  • 必须将自动测试套件应用于至少一个分支的共享代码库的每次签入。该测试套件必须生成关于测试成功或失败的报告。 {Met justification} [automated_integration_testing]
    详细信息:
    这个要求可以被视为test_continuous_integration的一个子集,但是仅仅是测试,而不需要持续集成。
  • 该项目必须为过去六个月内修复的至少50%的错误,在自动化测试套件中添加回归测试。 {N/A justification} {Met justification} [regression_tests_added50]
  • 如果有至少一个FLOSS工具可以以所选语言度量此条款,该项目的FLOSS自动测试套件必须具有至少80%语句覆盖率。 {N/A justification} {Met justification} [test_statement_coverage80]
    详细信息:
    许多FLOSS工具可用于度量测试覆盖范围,包括gcov / lcov,Blanket.js,Istanbul和JCov。请注意,满足这个条款并不能保证测试套件是完备的,而不满足该条款则意味着测试套件很差。

新功能测试

  • 该项目必须具有正式的书面策略,一旦添加了主要的新功能,新功能的测试必须被添加到自动测试套件中。 {N/A justification} {Met justification} [test_policy_mandated]
  • 该项目必须在其关于变更建议的书面指导中包括要为主要新功能添加测试的策略。 {N/A justification} {Met justification} [tests_documented_added]

警告标志

  • 在实际允许时,项目必须最大限度地严格修复项目生成的软件中的警告。 {N/A justification} {Met justification} [warnings_strict]

安全

安全开发知识

  • 该项目必须实施安全设计原则(来自“know_secure_design”)(如适用)。如果项目不生产软件,请选择“不适用”(N/A)。 {N/A justification} {Met justification} [implement_secure_design]
    详细信息:
    例如,项目结果应该具有故障安全默认值(默认情况下,访问决策应该拒绝,默认情况下项目的安装应该是安全的),也应该有完全的仲裁(每一个可能被限制的访问权限必须被检查,不可绕过)。请注意,在某些情况下,原则会发生冲突,在这种情况下必须做出选择(例如,许多机制使事情更复杂,违反“机制经济”/“保持最简化”的原则)。

使用基础的良好加密实践

  • 由项目产生的软件中的默认安全机制不得取决于具有已知严重弱点(例如,SHA-1密码散列算法或SSH中的CBC模式)的加密算法或模式。 {N/A allowed} {Met justification} [crypto_weaknesses]
  • 该项目应该支持多种加密算法,如果一个被破解,用户可以快速切换。普通的对称密钥算法包括AES,Twofish和Serpent。通用密码散列算法的选择包括SHA-2(包括SHA-224,SHA-256,SHA-384和SHA-512)和SHA-3。 {N/A allowed} {Met justification} [crypto_algorithm_agility]
  • 该项目必须支持在与其他信息(如配置文件,数据库和日志)分离的文件中存储身份验证凭据(如密码和动态令牌)以及私有加密密钥,并允许用户更新和替换它们,而无需重新编译代码。如果项目从不处理身份验证凭据和私有加密密钥,请选择“不适用”(N/A)。 {N/A allowed} {Met justification} [crypto_credential_agility]
  • 该项目产生的软件应该支持所有网络通信的安全协议,如SSHv2或更高版本,TLS1.2或更高版本(HTTPS),IPsec,SFTP和SNMPv3。默认情况下,FTP,HTTP,Telnet,SSLv3或更早版本和SSHv1等不安全协议将被禁用,只有在用户专门配置时才启用。如果项目生成的软件不支持网络通信,请选择“不适用”(N/A)。 {N/A allowed} {Met justification} [crypto_used_network]
  • 项目生成的软件(如果支持或使用TLS)应该至少支持TLS版本1.2。请注意,TLS的前身称为SSL。如果软件不使用TLS,请选择“不适用”(N/A)。 {N/A allowed} {Met justification} [crypto_tls12]
  • 由项目生成的软件必须,如果它支持TLS,则在使用TLS(包括子资源)时默认执行TLS证书验证。如果软件不使用TLS,请选择“不适用”(N / A)。 {N/A allowed} {Met justification} [crypto_certificate_verification]
    详细信息:
    请注意,不正确的TLS证书验证是一个常见的错误。有关详细信息,请参阅“世界上最危险的代码:在非浏览器软件中验证SSL证书“,Martin Georgiev等人 “你信任这个应用程序吗?”作者Michael Catanzaro
  • 项目生成的软件(如果支持TLS)必须在发送具有私有信息(如安全Cookie)的HTTP头之前执行证书验证。如果软件不使用TLS,请选择“不适用”(N/A)。 {N/A allowed} {Met justification} [crypto_verification_private]

安全发布

  • 该项目必须加密签名旨在广泛使用的项目结果的发布,并且必须有一个书面流程,向用户解释如何获取公共签名密钥并验证签名。这些签名的私钥不得在项目网站上直接向公众发布。如果发行版本不适用于广泛使用,请选择“不适用”(N/A)。 {N/A justification} {Met justification} [signed_releases]
    详细信息:
    项目结果包括源代码和适用的任何生成的可交付成果(例如,可执行文件,包和容器)。生成的交付项可以单独签名源代码。可以用签名的git标签实现(使用加密数字签名)。项目可以从git类似的工具分别提供生成的结果,但在这些情况下,单独的结果必须单独签署。
  • 建议在版本控制系统中,每个重要版本标签(作为主要版本的一部分的标签,次要版本或修复公开提到的漏洞)都按照signed_releases中的要求进行加密签名,并可验证。 {Met justification} [version_tags_signed]

其他安全问题

分析

静态代码分析

  • 如果至少有一个FLOSS工具能够以所选择的语言实现此条款,则该项目必须至少使用一个具有规则或方式的静态分析工具来查找分析语言或环境中的常见漏洞。 {N/A justification} {Met justification} [static_analysis_common_vulnerabilities]

动态代码分析

  • 如果由项目生成的软件包含使用内存不安全语言编写的软件(例如,C或C ++),项目必须至少使用一个动态工具(例如,fuzzer或web应用扫描程序)与一种检测缓冲区覆写等内存安全问题的机制组合例行使用。如果项目不生成以内存不安全语言编写的软件,请选择“不适用”(N/A)。 {N/A justification} {Met justification} [dynamic_analysis_unsafe]

黄金

基本

先决条件

项目监督

  • 项目必须具有2个或更多的“公交车因子”。 {Met URL} [bus_factor]
  • 该项目必须至少有两个不相关的重要贡献者。 {Met URL} [contributors_unassociated]
    详细信息:
    如果同一组织(作为雇员或承包商)支付工作费用,并且组织将从项目的结果中受益,则贡献者是相关联的。如果通过其他组织得到财务补助(例如,源自政府或非政府组织,支付给不同组织的科学补助金不会导致捐助者关联),不视为来自同一组织。重要贡献者定义为过去一年对项目做出了不平凡的贡献。一个重要贡献者的良好指标的例子是:编写至少1,000行代码,贡献50个提交或至少提交20页的文档。

其他

  • 该项目必须在每个源文件中包含一个版权声明,确定至少一个相关年份和版权所有者。 {Met justification} [copyright_per_file]
    详细信息:
    这可以通过在每个文件开头附近的注释中加入以下内容:“Copyright [year this project or content started] - [most recent year modified], [project founder] and the [project name] contributors.
  • 项目必须在每个源文件中包含许可证声明。这可以通过在每个文件开头附近的注释中加入以下内容来实现: SPDX-License-Identifier: [SPDX license expression for project]。 {Met justification} [license_per_file]
    详细信息:
    这可以通过在自然语言中包含许可证标识来完成。该项目还可以包括完整许可证文本,或者指向许可证文本的稳定URL。请注意,license_location条款要求项目许可证在标准位置。有关SPDX许可证表达式的更多信息,请参阅SPDX教程。请注意与 copyright_per_file 的关系,其内容通常在许可证信息之前。

变更控制

公开的版本控制的源代码存储库

  • 必须使用通用的分布式版本控制软件(例如,git,mercurial)作为项目的源代码存储库。 {Met justification} [repo_distributed]
  • 该项目必须清楚地识别新的或临时贡献者可以执行的小型任务。 {Met URL} [small_tasks]
    详细信息:
    此标识通常通过在项目使用的一个或多个标签的问题跟踪器中标记所选问题来完成,例如 up- for-grabs 仅限第一时间,“小修复”,微任务或IdealFirstBug。这些新任务不需要添加功能;他们可以改进文档,添加测试用例或其他有助于项目的内容,并帮助贡献者更了解项目。
  • 项目必须要求开发人员使用双因素身份验证(2FA)来更改中央存储库或访问敏感数据(如私密漏洞报告)。这种2FA机制可以使用没有密码学机制的方案,如SMS(短消息),尽管不推荐。 {Met justification} [require_2FA]
  • 项目的双因素身份认证(2FA)应该使用加密机制来防止仿冒。基于短消息服务(SMS)的2FA本身不符合此标准,因为它不被加密。 {Met justification} [secure_2FA]
    详细信息:
    满足此条款的2FA机制将是一种基于时间的一次性密码(TOTP)应用程序,可自动生成在一段时间后更改的验证码。请注意, GitHub支持TOTP

质量

编码标准

  • 该项目必须记录其代码检视需求,包括代码检视是如何进行的,必须检查的内容以及哪些是可接纳的内容。 {N/A justification} {Met URL} [code_review_standards]
    详细信息:
    另请参阅 two_person_review 和contribution_requirements 条款。
  • 该项目必须至少有50%的修改(作者之外的人提出的)在发布之前审查,以确定是否是一个有价值的修改,并且没有已知的问题,会反对其包含 {Met justification} [two_person_review]

可工作的构建系统

  • 该项目必须具有可重复构建。如果没有发生构建(例如,直接使用源代码而不是编译的脚本语言),请选择“不适用”(N/A)。 {N/A justification} {Met URL} [build_reproducible]
    详细信息:
    可重复的构建意味着多方可以独立地重做从源文件生成信息的过程,并获得每比特完全相同的结果。在某些情况下,这可以通过强制某种排序来解决。 JavaScript开发人员可能会考虑使用npm shrinkwrap和webpack的OccurenceOrderPlugin。 GCC和clang用户可能会发现-frandom-seed选项有用。通常可以通过指定可用于重新构建的特定容器或虚拟机的加密散列来为外部方定义构建环境(包括工具集)。 可重复构建项目具有文档指导如何执行此操作。

自动测试套件

  • 测试套件必须以该语言的标准方式进行调用。 {Met URL} [test_invocation]
  • 该项目必须实施持续集成,将新的或更改的代码经常集成到中央代码库中,并对结果进行自动化测试。 {Met URL} [test_continuous_integration]
    详细信息:
    在大多数情况下,这意味着每个在项目上全职工作的开发人员至少每天都会整合。
  • 如果有至少一个FLOSS工具可以以所选语言度量此条款,该项目的FLOSS自动测试套件必须具有至少90%语句覆盖率。 {N/A justification} {Met justification} [test_statement_coverage90]
  • 如果有至少一个FLOSS工具可以以所选语言度量此条款,该项目的FLOSS自动测试套件必须具有至少80%分支覆盖率。 {N/A justification} {Met justification} [test_branch_coverage80]

安全

使用基础的良好加密实践

  • 项目生成的软件必须支持所有网络通信的安全协议,如SSHv2或更高版本,TLS1.2或更高版本(HTTPS),IPsec,SFTP和SNMPv3。默认情况下,FTP,HTTP,Telnet,SSLv3或更早版本以及SSHv1等不安全协议必须被禁用,只有在用户专门配置时才启用。如果项目生成的软件不支持网络通信,请选择“不适用”(N/A)。 {N/A allowed} {Met justification} [crypto_used_network]
  • 由项目生成的软件必须,如果支持或使用TLS,至少支持TLS版本1.2。请注意,TLS的前身称为SSL。如果软件不使用TLS,请选择“不适用”(N/A)。 {N/A allowed} {Met justification} [crypto_tls12]

安全交付防御中间人(MITM)的攻击

  • 项目网站,存储库(如果可通过网络访问)和下载站点(如果单独)必须包括具有非允许值的密钥加固头。 {Met URL} [hardened_site]
    详细信息:
    请注意,GitHub是已知满足的。 https://securityheaders.io/ 等网站可以快速查看。主要头加固包含:内容安全策略(CSP),HTTP严格传输安全性(HSTS),X-Content-Type-Options(“nosniff”),X-Frame-Options和X-XSS-Protection。

其他安全问题

  • 该项目必须在过去5年内进行安全审查。此审查必须考虑安全需求和安全边界。 {Met justification} [security_review]
    详细信息:
    这可以由项目成员完成和/或独立评估。此评估可能由静态和动态分析工具支持,但还必须进行人工审查,以确定工具无法检测到的问题(特别是设计问题)。
  • 加固机制必须用于项目生产的软件,以便软件缺陷不太可能导致安全漏洞。 {N/A justification} {Met URL} [hardening]

分析

动态代码分析

  • 必须在发布之前,至少将一个动态分析工具应用于软件任何候选发布的主要生产版本。 {N/A justification} {Met justification} [dynamic_analysis]
  • 项目应该在其生成的软件中包含许多运行时断言,并在动态分析期间检查这些断言。 {N/A justification} {Met justification} [dynamic_analysis_enable_assertions]