BadgeApp

报告 8/8 ●

错误报告流程
Criterion [report_process]
完成

不完整

?

项目必须为用户提交错误报告（例如，使用问题跟踪器或邮件列表）提供相关流程。 (需要网址) ^{[report_process]}
Wiki: https://wiki.o-ran-sc.org/pages/viewpage.action?pageId=20877888
```
Bugs/Feedback etc accepted by: 
    Email List:
        OSC "discuss" mailing list: https://lists.o-ran-sc.org/g/discuss: discuss@lists.o-ran-sc.org 
        Please use hashtag #nonrtric
    JIRA: https://jira.o-ran-sc.org/projects/NONRTRIC/issues 
```
OSC Guidelines: https://wiki.o-ran-sc.org/display/ORAN/Reporting+Bugs
Criterion [report_tracker]
完成

不完整

?

项目必须使用问题跟踪器来跟踪每个问题。 ^{[report_tracker]}

JIRA: https://jira.o-ran-sc.org/projects/NONRTRIC/issues
Criterion [report_responses]
完成

不完整

?

该项目必须响应过去2-12个月内（含）提交的大多数错误报告；响应不需要包括修复。 ^{[report_responses]}
```
Email List:
    OSC "discuss" mailing list: https://lists.o-ran-sc.org/g/discuss: discuss@lists.o-ran-sc.org 
    Please use hashtag #nonrtric
JIRA: https://jira.o-ran-sc.org/projects/NONRTRIC/issues 
```
Criterion [enhancement_responses]
完成

不完整

?

该项目应该对过去2-12个月内（包括）的大部分（> 50％）的增强请求作出回应。 ^{[enhancement_responses]}
答复可能是“不”或有关其价值的讨论。目的只是对某些请求有一些回应，这表明项目还活着。为了该条款的目的，项目不需要计数无效请求（例如，来自垃圾邮件发送者或自动系统）。如果项目不再进行增强，请选择“未满足”，并将介绍此情况的URL包含在内。如果一个项目有超出处理能力的增强需求数量，请选择“未满足”并解释。
As can be seen on:
```
Email List:
    OSC "discuss" mailing list: https://lists.o-ran-sc.org/g/discuss: discuss@lists.o-ran-sc.org 
    Please use hashtag #nonrtric
JIRA: https://jira.o-ran-sc.org/projects/NONRTRIC/issues 
```
Criterion [report_archive]
完成

不完整

?

该项目必须有一个公开的报告和回复的档案供后续搜索。 (需要网址) ^{[report_archive]}

JIRA: https://jira.o-ran-sc.org/projects/NONRTRIC/issues
漏洞报告流程
Criterion [vulnerability_report_process]
完成

不完整

?

项目必须在项目网站上发布报告漏洞的流程。 (需要网址) ^{[vulnerability_report_process]}
例如，https://PROJECTSITE/security 上的一个明确指定的邮箱地址，通常以 security@example.org 的形式。这可能与其错误报告流程相同。漏洞报告可能一直是公开的，但是许多项目都有一个私密漏洞报告机制。
NONRTRIC: Bugs / Feedback / Vulnerabilities: https://wiki.o-ran-sc.org/pages/viewpage.action?pageId=20877888
```
Bugs/Feedback/Vulnerabilities can be notified by: 
    Email List:
        OSC "discuss" mailing list: https://lists.o-ran-sc.org/g/discuss: discuss@lists.o-ran-sc.org 
        Please use hashtag #nonrtric
    JIRA: https://jira.o-ran-sc.org/projects/NONRTRIC/issues 
OSC Guidelines: https://wiki.o-ran-sc.org/display/ORAN/Reporting+Bugs
Any private or confidential issues can be alerted to the PTL directly.
```
Criterion [vulnerability_report_private]
完成

不完整

N/A

?

如果支持私有漏洞报告，项目必须包括如何以保密的方式发送信息。 (需要网址) ^{[vulnerability_report_private]}
示例包括使用HTTPS（TLS）或使用OpenPGP加密的电子邮件在网络上提交的私密缺陷报告。如果漏洞报告总是公开的（从来没有私密漏洞报告），请选择“不适用”（N/A）。
NONRTRIC: Bugs / Feedback / Vulnerabilities: https://wiki.o-ran-sc.org/pages/viewpage.action?pageId=20877888
```
Any private or confidential issues can be alerted to the PTL directly
    Support for secure/encrypted reporting can be clarified directly with the PTL
```
Criterion [vulnerability_report_response]
完成

不完整

N/A

?

该项目在过去6个月收到的任何漏洞报告的初始响应时间必须小于或等于14天。 ^{[vulnerability_report_response]}
如果过去6个月没有报告漏洞，请选择“不适用”（N/A）。

质量 13/13 ●

可工作的构建系统

Criterion [build]
完成

不完整

N/A

?

如果项目生成的软件需要构建使用，项目必须提供可以从源代码自动重新构建软件的可工作的构建系统。 ^[build]
构建系统确定重建软件（以及以什么顺序）需要执行哪些操作，然后执行这些步骤。例如，它可以调用编译器来编译源代码。如果从源代码创建可执行文件，则必须可以修改项目的源代码，然后通过这些修改生成更新的可执行文件。如果项目生成的软件取决于外部库，则构建系统不必构建那些外部库。如果在修改源代码之后不需要构建任何使用该软件的软件，请选择“不适用”（N/A）。

Maven

Criterion [build_common_tools]
完成

不完整

N/A

?

建议使用通用工具来构建软件。 ^{[build_common_tools]}
例如，Maven，Ant，cmake，自动工具，make，rake（Ruby）或devtools （R）。

Maven

Criterion [build_floss_tools]
完成

不完整

N/A

?

该项目应该仅使用FLOSS工具来构建。 ^{[build_floss_tools]}

Maven
自动测试套件

Criterion [test]
完成

不完整

?

该项目必须使用至少一个作为FLOSS公开发布的自动测试套件（该测试套件可以作为单独的FLOSS项目维护）。 ^[test]
该项目可以使用多个自动测试套件（例如，一个是快速运行的测试套件，而另一个更为彻底但需要特殊设备）。

Very comprehensive test environment and tests available as a sub-directory in nonrtric repo (not a separate project)

Gerrit * nonrtric : https://gerrit.o-ran-sc.org/r/admin/repos/nonrtric ./test and ./autotest

Criterion [test_invocation]
完成

不完整

?

测试套件应该以该语言的标准方式进行调用。 ^{[test_invocation]}
例如“make check”，“mvn test”或“rake test”。

mvn test bash scripts

Criterion [test_most]
完成

不完整

?

建议测试套件覆盖大部分（或理想情况下所有）代码分支，输入字段和功能。 ^[test_most]

All versions are tested in autotest suite (above)

Criterion [test_continuous_integration]
完成

不完整

?

建议项目实施持续集成，将新的或更改的代码经常集成到中央代码库中，并对结果进行自动化测试。 ^{[test_continuous_integration]}

Multiple tests triggered automatically and periodically as Jenkins jobs at numerous phases of CI/CD pipeline

https://jenkins.o-ran-sc.org/view/nonrtric/ https://jenkins.o-ran-sc.org/view/portal-nonrtric-controlpanel/ https://jenkins.o-ran-sc.org/view/sim-a1-interface/
新功能测试

Criterion [test_policy]
完成

不完整

?

该项目必须有通用的策略（正式或非正式），当主要的新功能被添加到项目生成的软件中，该功能的测试应该同时添加到自动测试套件。 ^{[test_policy]}
只要有相应的策略，即使是通过口头传播，也就是说开发人员应该为主要的新功能在自动化测试套件中添加测试，选择“Met”。

All new and updated functionality is tested in autotest suite (above) All contributions should include tests, as described at NONRTRIC: Code Style: https://wiki.o-ran-sc.org/display/RICNR/Code+Style
Criterion [tests_are_added]
完成

不完整

?

该项目必须有证据表明，在项目生成的软件的最近重大变化中，已经遵守了添加测试的条款： test_policy 。 ^{[tests_are_added]}
主要功能通常在发行说明中提及。不需要完美，只需证明，当新的主要功能添加到项目生成的软件时，测试通常会在实践中被添加到自动化测试套件中。
All new and updated functionality is tested in autotest suite (above). New test functionality can be seen in JIRA and Gerrit.

Unit test coverage can be verified using Sonar
```
https://jenkins.o-ran-sc.org/view/nonrtric/job/nonrtric-sonar/
https://jenkins.o-ran-sc.org/view/portal-nonrtric-controlpanel/job/portal-nonrtric-controlpanel-sonar/
https://jenkins.o-ran-sc.org/view/sim-a1-interface/job/sim-a1-interface-tox-sonarqube/
```
Criterion [tests_documented_added]
完成

不完整

?

建议您在更改提案的说明文档中添加测试策略要求（请参阅test_policy）。 ^{[tests_documented_added]}
但是，只要在实践中添加了测试，即使是非正式规则也是可以接受的。

Only informal rule exists, tests are continuously added in practice All contributions should include tests, as described at NONRTRIC: Code Style: https://wiki.o-ran-sc.org/display/RICNR/Code+Style
警告标志
Criterion [warnings]
完成

不完整

N/A

?

该项目必须启用一个或多个编译器警告标志，“安全”语言模式，或者使用单独的“linter”工具查找代码质量错误或常见的简单错误，如果至少有一个FLOSS工具可以在所选择的语言实现此条款。 ^[warnings]
编译器警告标志的例子包括gcc/clang “-Wall”。 “安全”语言模式的示例包括JavaScript “use strict”和perl5的“使用警告”。一个单独的“linter”工具用于检查源代码以查找代码质量错误或常见的简单错误。这些通常在源代码或构建指令中启用。
Sonar is used in development environment and automatically triggered by Jenkins during CI/CD process
```
Jenkins:
    https://jenkins.o-ran-sc.org/view/nonrtric/job/nonrtric-sonar/
    https://jenkins.o-ran-sc.org/view/portal-nonrtric-controlpanel/job/portal-nonrtric-controlpanel-sonar/
    https://jenkins.o-ran-sc.org/view/sim-a1-interface/job/sim-a1-interface-tox-sonarqube/
```
CheckStyle & Findbugs are used in development environments
Criterion [warnings_fixed]
完成

不完整

N/A

?

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

Sonar reports are acted upon continuously.

Criterion [warnings_strict]
完成

不完整

N/A

?

建议在实际情况下，项目以最严格方式对待项目生成的软件中的告警。 ^{[warnings_strict]}
某些项目无法有效启用某些警告。需要证明的是，项目正在努力的启用警告标志，以便早期发现错误。

Taken on a case by case basis.

All Checkstyle, Findbugs, test failures, notified issues/bugs and Sonar warnings are acted on promptly.

Such issues are tracked using Jira and Gerrit (See above).

分析 8/8 ●

静态代码分析
Criterion [static_analysis]
完成

不完整

N/A

?

如果至少有一个FLOSS工具以所选择的语言实现此条款，则至少需要将一个静态代码分析工具应用于软件发布之前任何提议的主要生成版本。 ^{[static_analysis]}
静态代码分析工具检查软件代码（源代码，中间代码或可执行文件），而不用特定输入执行。本条款中，编译器警告和“安全”语言模式不被视为静态代码分析工具（它们通常避免深入分析，因为速度至关重要）。此类静态代码分析工具的示例包括 cppcheck ， clang静态分析器， FindBugs （包括FindSecurityBugs）， PMD ， Brakeman ， Coverity质量分析器和 HP Fortify静态代码分析器。更多的工具列表可以在诸如维基百科静态代码分析工具列表，关于静态代码分析的OWASP信息， NIST源代码安全分析器列表和 Wheeler的静态分析工具列表。 SWAMP 是使用各种工具评估软件漏洞的免费平台。如果没有可用于所使用的实现语言的FLOSS静态分析工具，请选择“N/A”。
Sonar is used in development environment and automatically triggered by Jenkins during CI/CD process
```
Jenkins:
    https://jenkins.o-ran-sc.org/view/nonrtric/job/nonrtric-sonar/
    https://jenkins.o-ran-sc.org/view/portal-nonrtric-controlpanel/job/portal-nonrtric-controlpanel-sonar/
    https://jenkins.o-ran-sc.org/view/sim-a1-interface/job/sim-a1-interface-tox-sonarqube/
```
Findbugs and Checkstyle is used in development environment NexusIQ (from Sonatype) is also used - focuses on license scan and performs a CVE scan based on versions used. A per-release license scan based is performed for LF Legal - uses a LF-internal scanning.
Criterion [static_analysis_common_vulnerabilities]
完成

不完整

N/A

?

建议至少有一个用于static_analysis标准的静态分析工具包括在分析语言或环境中查找常见漏洞的规则或方法。 ^{[static_analysis_common_vulnerabilities]}
专门设计用于寻找常见漏洞的静态分析工具更有可能找到它们。也就是说，使用任何静态工具通常会帮助找到一些问题，所以我们“通过”级别的徽章建议，但不要求这个条款。
Sonar is used in development environment and automatically triggered by Jenkins during CI/CD process
```
Jenkins:
    https://jenkins.o-ran-sc.org/view/nonrtric/job/nonrtric-sonar/
    https://jenkins.o-ran-sc.org/view/portal-nonrtric-controlpanel/job/portal-nonrtric-controlpanel-sonar/
    https://jenkins.o-ran-sc.org/view/sim-a1-interface/job/sim-a1-interface-tox-sonarqube/
```
Findbugs and Checkstyle is used in development environments NexusIQ (from Sonatype) is also used - focuses on license scan and performs a CVE scan based on versions used. A per-release license scan based is performed for LF Legal - uses a LF-internal scanning.
Criterion [static_analysis_fixed]
完成

不完整

N/A

?

使用静态代码分析发现的所有中，高严重性可利用漏洞必须在确认后及时修复。 ^{[static_analysis_fixed]}
如果其 CVSS 2.0 评分为4或更高，则此漏洞是中等到高的严重性。

All reports are acted upon continuously.

Criterion [static_analysis_often]
完成

不完整

N/A

?

建议每次提交或至少每天执行静态源代码分析。 ^{[static_analysis_often]}

Sonar is used in development environment and automatically triggered by Jenkins during CI/CD process
动态代码分析

Criterion [dynamic_analysis]
完成

不完整

?

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

Criterion [dynamic_analysis_unsafe]
完成

不完整

N/A

?

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

Java, Python is used.

Criterion [dynamic_analysis_enable_assertions]
完成

不完整

?

建议由项目生成的软件包括许多运行时断言，在动态分析期间检查。 ^{[dynamic_analysis_enable_assertions]}
这个标准并不建议使生产过程中的断言;这完全取决于项目及其用户的决定。该标准的重点是在部署之前的动态分析过程中改善故障检测。在生产使用中启用断言与在动态分析（例如测试）期间启用断言完全不同。在某些情况下，在生产中使用断言是极其不明智的（尤其是在高完整性组件中）。存在许多反对在生产环境中启用断言的论点，例如，库不应使调用程序崩溃，它们的存在可能会导致应用商店拒绝，和/或在生产环境中激活断言可能会暴露诸如私钥之类的私有数据。请注意，在许多Linux发行版中都未定义NDEBUG ，因此C / C ++缺省情况下，assert（）将在这些环境中启用生产。对于那些环境中的生产，使用不同的断言机制或定义NDEBUG可能很重要。
Test-level assertions are checked in tests. All runtime failing assertions/exceptions are caught and logged. Any error/exception appearing in test logs or reported by users are assessed in timely manner.
Criterion [dynamic_analysis_fixed] 完成不完整 N/A ? 通过动态代码分析发现的所有严重性为中，高的可利用漏洞必须在确认后及时修复。 ^{[dynamic_analysis_fixed]} 如果 CVSS 2.0 基本分数为4，那么一个漏洞是中等到高的严重性。如果您没有运行动态代码分析，没有发现任何这样的漏洞，选择“不适用”（N/A）。 No exploitable vulnerabilities to our knowledge. Not running dynamic code analysis and thus have not found any vulnerabilities in this way

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

ORAN SC: OSC Non-RealTime RIC (NONRTRIC)

基本 13/13 ●

识别

基本项目网站内容

FLOSS许可证

文档

其他

变更控制 9/9 ●

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

唯一版本编号

发行说明

报告 8/8 ●

错误报告流程

漏洞报告流程

质量 13/13 ●

可工作的构建系统

自动测试套件

新功能测试

警告标志

安全 16/16 ●

安全开发知识

使用基础的良好加密实践

安全交付防御中间人（MITM）的攻击

修正公开的漏洞

其他安全问题

分析 8/8 ●

静态代码分析

动态代码分析