Security and Dependency Management

Owned by Adheli Tavares
Last updated: about 8 hours ago
3 min read

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: policy-api-maven-clm-master [Jenkins] ). 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.

image-20241004-095109.png

After that, when opening pom.xml files, it will highlight any dependency with issues. Not all issues can be fixed, but it gives a good idea of how many dependencies need to be watched.

 

SonarLint / SonarCloud

Any member of ONAP can get SonarLint plugin in IntelliJ to be connected to ONAP SonarCloud.

Go to https://sonarcloud.io/organizations/onap/projects?sort=maintainability and login with GitHub (you need to ask your GitHub account to be added to ONAP organization Open Network Automation Platform (ONAP) ). Generate an user token to be used on SonarLint plugin.

To configure SonarLint, you need to have nodejs installed. On the SonarLint settings tab, use Connected Mode and login to ONAP SonarCloud. Use the token generated on previous step. It will use the ONAP rules for clean code.

image-20241004-100210.png

To run, click on each module (don’t run analysis over the whole project, it will take too long and will analyse unnecessary files from target folder) and go SonarLint → Analyse with SonarLint. Fix anything you deem fixable.

 

Updating Maven Dependencies

Most of Policy dependencies are at the parent/integration/pom.xml file. Versions can be changed at property level (i.e <version.spring>) or at dependency version tag. Other dependencies are on project level, so be careful when changing something from integration pom.xml that causes conflict with project level dependencies. Upgrade both if necessary.

Use Maven Repository (Maven Repository: Search/Browse/Explore ) as reference for the latest. Keep in mind to use actual released versions (avoid alpha or pink version). MVN Repository can also inform if a dependency is vulnerable.

Suggestion: try to upgrade versions one by one or by cascade group (i.e hibernate have a few different dependencies, so they should be upgraded together; same with spring/spring-boot/spring-security)

When changes on integration pom.xml are done, mvn clean install must be ran in ALL repos.

Here are some bash scripts that could help with that. Download them to the parent folder of all policy repos. If your folder structure is /git/policy/parent, the script should be downloaded in the /git/policy folder.

this will run mvn clean install in each repo, one by one, following dependency order. (parent - docker - common - models - etc…). If the build fails, the script generated a <repo>.log file inside the repo folder (api would generate an api.log file inside its folder - /git/policy/api/api.log) where the issue is reported.

After all repositories are building successfully, CSITs must be ran to guarantee all applications are starting correctly and executing the test cases.

this will generate all docker images used in Policy Framework.

this will remove all docker images, given a name start. It’s good to use when generating local images a few times, so it can be used ./remove-docker-images.sh onap/ to remove all local images.

Before running the tests, go to the /git/policy/docker/compose/get-versions.sh script and set the variable LOCAL_IMAGES=true so it will pick up the newly generated images instead of downloading from nexus.

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.