BadgeApp

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'.
We have created a new Jenkins job sonarqube for o-du-l2 module under ORAN sandbox. https://jenkins.o-ran-sc.org/sandbox/view/All/job/o-du-l2-cmake-sonarqube/

There are two issues: 1- While this new job compiles o-du-l2 module below error observed: 14:24:40 /w/workspace/o-du-l2-cmake-sonarqube/src/cm/cm_inet.c:128:10: fatal error: netinet/sctp.h: No such file or directory 14:24:40 #include

To resolve this libsctp-dev should be installed.
```
            2- This job could not finish in default 15 mins time, so timeout parameter under build environment should be changed. (tried with 120)
```
Temporary solution applied: Above issues resolved by putting below install command in shell script manually. sudo apt install -y libsctp-dev

For timeout changed timeout variable to 120.

With above changes the job finished successfully and below sonarcloud updated for o-du-l2 module. https://sonarcloud.io/dashboard?id=o-ran-sc_o-du-l2

NOTE: As of now there is another issue present related to workspace in sandbox https://jenkins.o-ran-sc.org/sandbox/view/All/job/o-du-l2-cmake-sonarqube/ws/

LF ticket has already been raised for this as below. https://jira.linuxfoundation.org/plugins/servlet/theme/portal/2/IT-22356
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.
We have created a new Jenkins job sonarqube for o-du-l2 module under ORAN sandbox. https://jenkins.o-ran-sc.org/sandbox/view/All/job/o-du-l2-cmake-sonarqube/

There are two issues: 1- While this new job compiles o-du-l2 module below error observed: 14:24:40 /w/workspace/o-du-l2-cmake-sonarqube/src/cm/cm_inet.c:128:10: fatal error: netinet/sctp.h: No such file or directory 14:24:40 #include

To resolve this libsctp-dev should be installed.
```
            2- This job could not finish in default 15 mins time, so timeout parameter under build environment should be changed. (tried with 120)
```
Temporary solution applied: Above issues resolved by putting below install command in shell script manually. sudo apt install -y libsctp-dev

For timeout changed timeout variable to 120.

With above changes the job finished successfully and below sonarcloud updated for o-du-l2 module. https://sonarcloud.io/dashboard?id=o-ran-sc_o-du-l2

NOTE: As of now there is another issue present related to workspace in sandbox https://jenkins.o-ran-sc.org/sandbox/view/All/job/o-du-l2-cmake-sonarqube/ws/

LF ticket has already been raised for this as below. https://jira.linuxfoundation.org/plugins/servlet/theme/portal/2/IT-22356
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.
We have created a new Jenkins job sonarqube for o-du-l2 module under ORAN sandbox. https://jenkins.o-ran-sc.org/sandbox/view/All/job/o-du-l2-cmake-sonarqube/

There are two issues: 1- While this new job compiles o-du-l2 module below error observed: 14:24:40 /w/workspace/o-du-l2-cmake-sonarqube/src/cm/cm_inet.c:128:10: fatal error: netinet/sctp.h: No such file or directory 14:24:40 #include

To resolve this libsctp-dev should be installed.
```
            2- This job could not finish in default 15 mins time, so timeout parameter under build environment should be changed. (tried with 120)
```
Temporary solution applied: Above issues resolved by putting below install command in shell script manually. sudo apt install -y libsctp-dev

For timeout changed timeout variable to 120.

With above changes the job finished successfully and below sonarcloud updated for o-du-l2 module. https://sonarcloud.io/dashboard?id=o-ran-sc_o-du-l2

NOTE: As of now there is another issue present related to workspace in sandbox https://jenkins.o-ran-sc.org/sandbox/view/All/job/o-du-l2-cmake-sonarqube/ws/

LF ticket has already been raised for this as below. https://jira.linuxfoundation.org/plugins/servlet/theme/portal/2/IT-22356
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]}
We have created a new Jenkins job sonarqube for o-du-l2 module under ORAN sandbox. https://jenkins.o-ran-sc.org/sandbox/view/All/job/o-du-l2-cmake-sonarqube/

There are two issues: 1- While this new job compiles o-du-l2 module below error observed: 14:24:40 /w/workspace/o-du-l2-cmake-sonarqube/src/cm/cm_inet.c:128:10: fatal error: netinet/sctp.h: No such file or directory 14:24:40 #include

To resolve this libsctp-dev should be installed.
```
            2- This job could not finish in default 15 mins time, so timeout parameter under build environment should be changed. (tried with 120)
```
Temporary solution applied: Above issues resolved by putting below install command in shell script manually. sudo apt install -y libsctp-dev

For timeout changed timeout variable to 120.

With above changes the job finished successfully and below sonarcloud updated for o-du-l2 module. https://sonarcloud.io/dashboard?id=o-ran-sc_o-du-l2

NOTE: As of now there is another issue present related to workspace in sandbox https://jenkins.o-ran-sc.org/sandbox/view/All/job/o-du-l2-cmake-sonarqube/ws/

LF ticket has already been raised for this as below. https://jira.linuxfoundation.org/plugins/servlet/theme/portal/2/IT-22356
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.

Valgrind being used by developers

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.

Valgrind being used by developers

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.

Valgrind being used by developers

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.

Valgrind being used by developers

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: O-DU High ( Distributed Unit High)

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