BadgeApp

Reporting 8/8 ●

Bug-reporting process
Criterion [report_process]
Met

Unmet

?

The project MUST provide a process for users to submit bug reports (e.g., using an issue tracker or a mailing list). (URL required) ^{[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]
Met

Unmet

?

The project SHOULD use an issue tracker for tracking individual issues. ^{[report_tracker]}

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

Unmet

?

The project MUST acknowledge a majority of bug reports submitted in the last 2-12 months (inclusive); the response need not include a fix. ^{[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]
Met

Unmet

?

The project SHOULD respond to a majority (>50%) of enhancement requests in the last 2-12 months (inclusive). ^{[enhancement_responses]}
The response MAY be 'no' or a discussion about its merits. The goal is simply that there be some response to some requests, which indicates that the project is still alive. For purposes of this criterion, projects need not count fake requests (e.g., from spammers or automated systems). If a project is no longer making enhancements, please select "unmet" and include the URL that makes this situation clear to users. If a project tends to be overwhelmed by the number of enhancement requests, please select "unmet" and explain.
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]
Met

Unmet

?

The project MUST have a publicly available archive for reports and responses for later searching. (URL required) ^{[report_archive]}

JIRA: https://jira.o-ran-sc.org/projects/NONRTRIC/issues
Vulnerability report process
Criterion [vulnerability_report_process]
Met

Unmet

?

The project MUST publish the process for reporting vulnerabilities on the project site. (URL required) ^{[vulnerability_report_process]}
Projects hosted on GitHub SHOULD consider enabling privately reporting a security vulnerability. Projects on GitLab SHOULD consider using its ability for privately reporting a vulnerability. Projects MAY identify a mailing address on https://PROJECTSITE/security, often in the form security@example.org. This vulnerability reporting process MAY be the same as its bug reporting process. Vulnerability reports MAY always be public, but many projects have a private vulnerability reporting mechanism.
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]
Met

Unmet

N/A

?

If private vulnerability reports are supported, the project MUST include how to send the information in a way that is kept private. (URL required) ^{[vulnerability_report_private]}
Examples include a private defect report submitted on the web using HTTPS (TLS) or an email encrypted using OpenPGP. If vulnerability reports are always public (so there are never private vulnerability reports), choose "not applicable" (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]
Met

Unmet

N/A

?

The project's initial response time for any vulnerability report received in the last 6 months MUST be less than or equal to 14 days. ^{[vulnerability_report_response]}
If there have been no vulnerabilities reported in the last 6 months, choose "not applicable" (N/A).

Quality 13/13 ●

Working build system

Criterion [build]
Met

Unmet

N/A

?

If the software produced by the project requires building for use, the project MUST provide a working build system that can automatically rebuild the software from source code. ^[build]
A build system determines what actions need to occur to rebuild the software (and in what order), and then performs those steps. For example, it can invoke a compiler to compile the source code. If an executable is created from source code, it must be possible to modify the project's source code and then generate an updated executable with those modifications. If the software produced by the project depends on external libraries, the build system does not need to build those external libraries. If there is no need to build anything to use the software after its source code is modified, select "not applicable" (N/A).

Maven

Criterion [build_common_tools]
Met

Unmet

N/A

?

It is SUGGESTED that common tools be used for building the software. ^{[build_common_tools]}
For example, Maven, Ant, cmake, the autotools, make, rake (Ruby), or devtools (R).

Maven

Criterion [build_floss_tools]
Met

Unmet

N/A

?

The project SHOULD be buildable using only FLOSS tools. ^{[build_floss_tools]}

Maven
Automated test suite

Criterion [test]
Met

Unmet

?

The project MUST use at least one automated test suite that is publicly released as FLOSS (this test suite may be maintained as a separate FLOSS project). The project MUST clearly show or document how to run the test suite(s) (e.g., via a continuous integration (CI) script or via documentation in files such as BUILD.md, README.md, or CONTRIBUTING.md). ^[test]
The project MAY use multiple automated test suites (e.g., one that runs quickly, vs. another that is more thorough but requires special equipment). There are many test frameworks and test support systems available, including Selenium (web browser automation), Junit (JVM, Java), RUnit (R), testthat (R).

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]
Met

Unmet

?

A test suite SHOULD be invocable in a standard way for that language. ^{[test_invocation]}
For example, "make check", "mvn test", or "rake test" (Ruby).

mvn test bash scripts

Criterion [test_most]
Met

Unmet

?

It is SUGGESTED that the test suite cover most (or ideally all) the code branches, input fields, and functionality. ^[test_most]

All versions are tested in autotest suite (above)

Criterion [test_continuous_integration]
Met

Unmet

?

It is SUGGESTED that the project implement continuous integration (where new or changed code is frequently integrated into a central code repository and automated tests are run on the result). ^{[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/
New functionality testing

Criterion [test_policy]
Met

Unmet

?

The project MUST have a general policy (formal or not) that as major new functionality is added to the software produced by the project, tests of that functionality should be added to an automated test suite. ^{[test_policy]}
As long as a policy is in place, even by word of mouth, that says developers should add tests to the automated test suite for major new functionality, select "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]
Met

Unmet

?

The project MUST have evidence that the test_policy for adding tests has been adhered to in the most recent major changes to the software produced by the project. ^{[tests_are_added]}
Major functionality would typically be mentioned in the release notes. Perfection is not required, merely evidence that tests are typically being added in practice to the automated test suite when new major functionality is added to the software produced by the project.
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]
Met

Unmet

?

It is SUGGESTED that this policy on adding tests (see test_policy) be documented in the instructions for change proposals. ^{[tests_documented_added]}
However, even an informal rule is acceptable as long as the tests are being added in practice.

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
Warning flags
Criterion [warnings]
Met

Unmet

N/A

?

The project MUST enable one or more compiler warning flags, a "safe" language mode, or use a separate "linter" tool to look for code quality errors or common simple mistakes, if there is at least one FLOSS tool that can implement this criterion in the selected language. ^[warnings]
Examples of compiler warning flags include gcc/clang "-Wall". Examples of a "safe" language mode include JavaScript "use strict" and perl5's "use warnings". A separate "linter" tool is simply a tool that examines the source code to look for code quality errors or common simple mistakes. These are typically enabled within the source code or build instructions.
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]
Met

Unmet

N/A

?

The project MUST address warnings. ^{[warnings_fixed]}
These are the warnings identified by the implementation of the warnings criterion. The project should fix warnings or mark them in the source code as false positives. Ideally there would be no warnings, but a project MAY accept some warnings (typically less than 1 warning per 100 lines or less than 10 warnings).

Sonar reports are acted upon continuously.

Criterion [warnings_strict]
Met

Unmet

N/A

?

It is SUGGESTED that projects be maximally strict with warnings in the software produced by the project, where practical. ^{[warnings_strict]}
Some warnings cannot be effectively enabled on some projects. What is needed is evidence that the project is striving to enable warning flags where it can, so that errors are detected early.

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).

Analysis 8/8 ●

Static code analysis
Criterion [static_analysis]
Met

Unmet

N/A

?

At least one static code analysis tool (beyond compiler warnings and "safe" language modes) MUST be applied to any proposed major production release of the software before its release, if there is at least one FLOSS tool that implements this criterion in the selected language. ^{[static_analysis]}
A static code analysis tool examines the software code (as source code, intermediate code, or executable) without executing it with specific inputs. For purposes of this criterion, compiler warnings and "safe" language modes do not count as static code analysis tools (these typically avoid deep analysis because speed is vital). Some static analysis tools focus on detecting generic defects, others focus on finding specific kinds of defects (such as vulnerabilities), and some do a combination. Examples of such static code analysis tools include cppcheck (C, C++), clang static analyzer (C, C++), SpotBugs (Java), FindBugs (Java) (including FindSecurityBugs), PMD (Java), Brakeman (Ruby on Rails), lintr (R), goodpractice (R), Coverity Quality Analyzer, SonarQube, Codacy, and HP Enterprise Fortify Static Code Analyzer. Larger lists of tools can be found in places such as the Wikipedia list of tools for static code analysis, OWASP information on static code analysis, NIST list of source code security analyzers, and Wheeler's list of static analysis tools. If there are no FLOSS static analysis tools available for the implementation language(s) used, you may select '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]
Met

Unmet

N/A

?

It is SUGGESTED that at least one of the static analysis tools used for the static_analysis criterion include rules or approaches to look for common vulnerabilities in the analyzed language or environment. ^{[static_analysis_common_vulnerabilities]}
Static analysis tools that are specifically designed to look for common vulnerabilities are more likely to find them. That said, using any static tools will typically help find some problems, so we are suggesting but not requiring this for the 'passing' level badge.
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]
Met

Unmet

N/A

?

All medium and higher severity exploitable vulnerabilities discovered with static code analysis MUST be fixed in a timely way after they are confirmed. ^{[static_analysis_fixed]}
A vulnerability is considered medium or higher severity if its Common Vulnerability Scoring System (CVSS) base qualitative score is medium or higher. In CVSS versions 2.0 through 3.1, this is equivalent to a CVSS score of 4.0 or higher. Projects may use the CVSS score as published in a widely-used vulnerability database (such as the National Vulnerability Database) using the most-recent version of CVSS reported in that database. Projects may instead calculate the severity themselves using the latest version of CVSS at the time of the vulnerability disclosure, if the calculation inputs are publicly revealed once the vulnerability is publicly known. Note that criterion vulnerabilities_fixed_60_days requires that all such vulnerabilities be fixed within 60 days of being made public.

All reports are acted upon continuously.

Criterion [static_analysis_often]
Met

Unmet

N/A

?

It is SUGGESTED that static source code analysis occur on every commit or at least daily. ^{[static_analysis_often]}

Sonar is used in development environment and automatically triggered by Jenkins during CI/CD process
Dynamic code analysis

Criterion [dynamic_analysis]
Met

Unmet

?

It is SUGGESTED that at least one dynamic analysis tool be applied to any proposed major production release of the software before its release. ^{[dynamic_analysis]}
A dynamic analysis tool examines the software by executing it with specific inputs. For example, the project MAY use a fuzzing tool (e.g., American Fuzzy Lop) or a web application scanner (e.g., OWASP ZAP or w3af). In some cases the OSS-Fuzz project may be willing to apply fuzz testing to your project. For purposes of this criterion the dynamic analysis tool needs to vary the inputs in some way to look for various kinds of problems or be an automated test suite with at least 80% branch coverage. The Wikipedia page on dynamic analysis and the OWASP page on fuzzing identify some dynamic analysis tools. The analysis tool(s) MAY be focused on looking for security vulnerabilities, but this is not required.

Criterion [dynamic_analysis_unsafe]
Met

Unmet

N/A

?

It is SUGGESTED that if the software produced by the project includes software written using a memory-unsafe language (e.g., C or C++), then at least one dynamic tool (e.g., a fuzzer or web application scanner) be routinely used in combination with a mechanism to detect memory safety problems such as buffer overwrites. If the project does not produce software written in a memory-unsafe language, choose "not applicable" (N/A). ^{[dynamic_analysis_unsafe]}
Examples of mechanisms to detect memory safety problems include Address Sanitizer (ASAN) (available in GCC and LLVM), Memory Sanitizer, and valgrind. Other potentially-used tools include thread sanitizer and undefined behavior sanitizer. Widespread assertions would also work.

Java, Python is used.

Criterion [dynamic_analysis_enable_assertions]
Met

Unmet

?

It is SUGGESTED that the project use a configuration for at least some dynamic analysis (such as testing or fuzzing) which enables many assertions. In many cases these assertions should not be enabled in production builds. ^{[dynamic_analysis_enable_assertions]}
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.

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]
Met

Unmet

N/A

?

All medium and higher severity exploitable vulnerabilities discovered with dynamic code analysis MUST be fixed in a timely way after they are confirmed. ^{[dynamic_analysis_fixed]}
If you are not running dynamic code analysis and thus have not found any vulnerabilities in this way, choose "not applicable" (N/A). A vulnerability is considered medium or higher severity if its Common Vulnerability Scoring System (CVSS) base qualitative score is medium or higher. In CVSS versions 2.0 through 3.1, this is equivalent to a CVSS score of 4.0 or higher. Projects may use the CVSS score as published in a widely-used vulnerability database (such as the National Vulnerability Database) using the most-recent version of CVSS reported in that database. Projects may instead calculate the severity themselves using the latest version of CVSS at the time of the vulnerability disclosure, if the calculation inputs are publicly revealed once the vulnerability is publicly known.

No exploitable vulnerabilities to our knowledge. Not running dynamic code analysis and thus have not found any vulnerabilities in this way

This data is available under the Creative Commons Attribution version 3.0 or later license (CC-BY-3.0+). All are free to share and adapt the data, but must give appropriate credit. Please credit Trishan de Lanerolle and the OpenSSF Best Practices badge contributors.

ORAN SC: OSC Non-RealTime RIC (NONRTRIC)

Basics 13/13 ●

Identification

Basic project website content

FLOSS license

Documentation

Other

Change Control 9/9 ●

Public version-controlled source repository

Unique version numbering

Release notes

Reporting 8/8 ●

Bug-reporting process

Vulnerability report process

Quality 13/13 ●

Working build system

Automated test suite

New functionality testing

Warning flags

Security 16/16 ●

Secure development knowledge

Use basic good cryptographic practices

Secured delivery against man-in-the-middle (MITM) attacks

Publicly known vulnerabilities fixed

Other security issues

Analysis 8/8 ●

Static code analysis

Dynamic code analysis