Before every release, a scan of vulnerabilities on 3pp must be done.
Dependency Management
NexusIQ
Committers have access to NexusIQ reports, where a more straightforward list of vulnerabilities and its levels is available, showing if it’s a direct dependency or transient. The report is generated on maven-clm-master jenkins job (i.e: https://jenkins.onap.org/view/policy/job/policy-api-maven-clm-master/ ). NexusIQ can be installed as a plugin in IntelliJ. Log into ONAP nexus (https://nexus-iq.wl.linuxfoundation.org/ ) and generate an user token. Use that as User Authentication and test with Connect. If it works, then for each repository, select the correct Application.
...
How to run CSITs using docker compose: https://docs.onap.org/projects/onap-policy-parent/en/latest/development/devtools/testing/csit.html#id2
Rinse and repeat.
Sonar Issues
Currently, we have sonar jobs running alongside java verify jobs when submitting a code review
Straightforward behaviour would be fixing all the issues pointed by the sonar report, like maintainability, readability, bottlenecks, etc. Sonar reports also go over unit tests, so please ensure your unit tests are really testing an unit of code. Integration tests or usecase tests should be covered in CSIT robot tests.
Of course, any issues pointed on the sonar report that can’t be fixed with the suggested fix by Sonar itself can be reviewed case by case. Be very careful when using //NOSONAR comment and if a brief explanation why NOSONAR should be added as well.
Common cases of “doesn’t look like it can be fixed”:
When using @Mock annotations, sonar will complain about AutoCloseable. If using MockitoAnnotations.init(), this will cause a Deprecated issue. Use MockitoAnnotations.openMocks(this).
https://github.com/onap/policy-pap/blob/master/main/src/test/java/org/onap/policy/pap/main/rest/PapRestControllerV1Test.java this test class has a good example on how to fix the issue with AutoCloseable
try-resources - this goes case by case. most of the time when using a test database or test HttpClient for a rest test, sonar might suggest to use try-resources. The issue with that is that when the try block finishes, it closes the resource opened with it, which can cause side effects (like closing a db connection middle test). What can be done in most cases is making the resource that is AutoCloseable a class field and then closing it at the end of the test or in a @AfterEach annotated method.
As for security issues reported by Sonar, it is better to take some time to try to fix it if it’s in the main code. Common issues that are reported in test classes are when reading a file or creating a temporary file. Try to use sonar suggestion for fixing as much as possible.