flowlogix

遵循以下最佳实践的项目将能够自愿的自我认证，并显示他们已经实现了核心基础设施计划（OpenSSF）徽章。

如果这是您的项目，请在您的项目页面上显示您的徽章状态！徽章状态如下所示：

项目8431的徽章级别为passing

这里是如何嵌入它：

您可以通过将其嵌入在您的Markdown文件中：

[![OpenSSF Best Practices](https://www.bestpractices.dev/projects/8431/badge)](https://www.bestpractices.dev/projects/8431)

或将其嵌入到HTML中来显示您的徽章状态：
<a href="https://www.bestpractices.dev/projects/8431"><img src="https://www.bestpractices.dev/projects/8431/badge"></a>

这些是

级别条款。您还可以查看

或

级别条款。

变更控制 1/1 ●

之前的版本

Criterion [maintenance_or_update]
完成

不完整

N/A

?

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

https://github.com/flowlogix/flowlogix

分析 2/2 ●

静态代码分析

Criterion [static_analysis_common_vulnerabilities]
完成

不完整

N/A

?

如果至少有一个FLOSS工具能够以所选择的语言实现此条款，则该项目必须至少使用一个具有规则或方式的静态分析工具来查找分析语言或环境中的常见漏洞。 ^{[static_analysis_common_vulnerabilities]}
专门设计用于寻找常见漏洞的静态分析工具更有可能找到它们。也就是说，使用任何静态工具通常会帮助找到一些问题，所以我们“通过”级别的徽章建议，但不要求这个条款。

https://github.com/flowlogix/flowlogix
动态代码分析

Criterion [dynamic_analysis_unsafe]
完成

不完整

N/A

?

如果由项目生成的软件包含使用内存不安全语言编写的软件（例如，C或C ++），则项目必须至少使用一个动态工具（例如，fuzzer或web应用扫描程序）与一种检测缓冲区覆写等内存安全问题的机制组合例行使用。如果项目不生成以内存不安全语言编写的软件，请选择“不适用”（N/A）。 ^{[dynamic_analysis_unsafe]}
检测内存安全问题的机制的示例包括AddressSanitizer（ASAN）（可在GCC和LLVM中使用），“Memory Sanitizer”和 valgrind 。其他可能使用的工具包括ThreadSanitizer和UndefinedBehaviorSanitizer。广泛的断言也将起作用。

https://github.com/flowlogix/flowlogix

此数据在知识共享署名3.0或更高版本许可证（CC-BY-3.0 +）下可用。所有内容都可以自由分享和演绎，但必须给予适当的署名。请署名为Lenny Primak和OpenSSF最佳实践徽章贡献者。

项目徽章条目拥有者： Lenny Primak.
最后更新于 2024-02-21 21:52:18 UTC, 最后更新于 2024-04-05 02:08:39 UTC。最后在 2024-02-21 22:01:51 UTC 获得通过徽章。