ONAP ESR (External System Register)

All major releases are tagged in gerrit and the artifacts are stored with the release information on onap.nexus. So we can access all old versions of the artifact. If and when a upgrade requires certain steps to be followed they are being added to the release documents as needed

Jira is used to track issues. https://wiki.onap.org/display/DW/Tracking+Issues+with+JIRA

Vulnerabilities can be reported using the link https://wiki.onap.org/pages/viewpage.action?pageId=6591711 Currently we dont have any vulnerabilities reported, but the wiki page explains on how to report a vulnerability and how to report anonymously if you do not want the credit for it.

Vulnerability handling is documented in https://wiki.onap.org/pages/viewpage.action?pageId=6591711

Google coding style is used in ONAP https://github.com/google/styleguide

maven-checkstyle-plugin

The application does not create native binaries.

The application does not create native binaries.

The application does not create native binaries.

All releases are tagged in gerrit(git), and the builds are controlled using jenkins. By providing the git tag information the same image can be build over and over again with same bit-for-bit result.

All packages are delivered either as an jar artifact or a docker image. Incase of maven artifacts, they can be removed using the pom file. In case of docker container. We can delete the container we dont want. Also control the orchestration in Kubernetes if you want to exclude certain docker images.

The compiled docker images and jar files can be installed/used as the user sees fit. Both run on JVM or docker.

All the components require only java and maven to begin with for a developer to quickly install and test it. Even for deployment using OOM and the right amount of resources, we can deploy the full AAI/ONAP suite in less than a day. The steps are documented in https://onap.readthedocs.io/en/latest/submodules/oom.git/docs/oom_quickstart_guide.html

We use sonatype CLM https://nexus-iq.wl.linuxfoundation.org/ and https://sonar.onap.org

External components are maintained through Maven. The user can get a list of all included components using the maven dependency tree and can update or reuse as they see fit

We choose free open source solutions in every case and choose up-to-date versions of the components.

https://jenkins.onap.org - on every commit, a verification job runs which runs an automated test suite. The code check in cannot pass with out jenkins posting a +1 on the review.

We add tests in these cases.

Contributing guide lines for development is recorded in https://wiki.onap.org/display/DW/Development+Procedures+and+Policies

The code coverage requirement is listed as a developer best practice here: https://wiki.onap.org/display/DW/Code+Coverage+and+Static+Code+Analysis

This project is using sonar(https://sonar.onap.org) to look for code quality errors or common simple mistakes, which has comprehensive rules(more than 200) to check the codes, all the findings are listed in the quality report.

AAI strives to implement secure design principles. We encrypt data where possible, and run security scans on the code and its dependencies.

We disallow SHA-1 or other insecure cryptographic algorithms.

We support mutiple cryptographic algorithms.

Credentials are separate and can be replaced without code compilation.

We use ssh2 internal to the cluster and TLS1.2+ for the external interfaces.

We only allow TLS1.2+

We perform certificate verfication.

We support TLS certification verification before exchange of private information.

The project strives to validate all input

This project is using nexus iq(https://nexus-iq.wl.linuxfoundation.org) to look for common vulnerabilities