Configuration Persistence Service (CPS)

Projects that follow the best practices below can voluntarily self-certify and show that they've achieved an Open Source Security Foundation (OpenSSF) best practices badge.

If this is your project, please show your badge status on your project page! The badge status looks like this:

Here is how to embed it:

You can show your badge status by embedding this in your markdown file:

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

or by embedding this in your HTML:
<a href="https://www.bestpractices.dev/projects/4398"><img src="https://www.bestpractices.dev/projects/4398/badge"></a>

These are the

level criteria. You can also view the

level criteria.

Analysis 2/2 ●

Dynamic code analysis

Criterion [dynamic_analysis]
Met

Unmet

N/A

?

The project MUST apply at least one dynamic analysis tool to any proposed major production release of the software produced by the project 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.

CPS has a project set up with ONAP Sonarcloud for analysis, see https://sonarcloud.io/component_measures?metric=coverage&view=treemap&id=onap_cps wherein a minimum of 97% code coverage is always maintained by the team. CPS also uses the SonarQube Scanner for Maven which uses the JaCoCo plugin to generate code coverage reports during the build process and track code coverage during run-time.

Criterion [dynamic_analysis_enable_assertions]
Met

Unmet

N/A

?

The project SHOULD include many run-time assertions in the software it produces and check those assertions during dynamic analysis. ^{[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.

Instead of run-time assertions, pre-run assertions are included where all the tests including the Integration tests are executed. Only after the successful pre-run tests, the projects are released and deployed on production. CPS uses Groovy for all unit and integration testing which is compiled and executed at runtime. CPS uses its capability to perform runtime assertions, see the following example https://gerrit.onap.org/r/gitweb?p=cps.git;a=blob;f=cps-ncmp-service/src/test/groovy/org/onap/cps/ncmp/api/impl/operations/DmiDataOperationsSpec.groovy;h=03825c2bbf34398df77a0028ee0825e96f5a5fbb;hb=3d97a963ce51c4f0ecdb656a3b25bcabf2f6f8b7

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 mrsjackson76 and the OpenSSF Best Practices badge contributors.

Configuration Persistence Service (CPS)

Basics 5/5 ●

Identification

Prerrequisitos

Supervisión del proyecto

Other

Change Control 4/4 ●

Repositorio público para el control de versiones de código fuente

Calidad 7/7 ●

Coding standards

Working build system

Automated test suite

Seguridad 5/5 ●

Use buenas prácticas criptográficas

Entrega garantizada contra ataques de hombre en el medio (MITM)

Otros problemas de seguridad

Analysis 2/2 ●

Dynamic code analysis