ONAP SDC (Service Design and Creation)

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.

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

Coding style is defined in https://wiki.onap.org/display/DW/Java+code+style

All packages are delivered either as an jar artifact or a docker image. In case 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. So there is no reason to selecting locations etc.

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

NexusIQ sonar scan is run on all the projects on a weekly basis

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

SDC stives to use updated technology stacks for its API usage, we are trying our best to stay up to date with package management and rely on other open source to avoid deprecated apis/functions.

Automatic test suites are run every time before merging the code. The code check in cannot pass with out jenkins posting a +1 on the review.

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

This is documented on our wiki: Code Coverage and Static Code Analysis

SDC is built using maven, maven is set commonly for ONAP projects and outputs warnings at build time for each and every code change published, this is visible in the LF jenkins instance

SDC security is analyzed by Sonar and depends on current crypto (Bouncycastle latest and SHA256), sensitive SDC data is made secure with these algorithms

SDC stores certificates and credentials in external configurations/volumes that can be overriden at install time / run time

SDC can sign artifacts produced for distribution by using digitally signed certificate (these are provided to SDC externally) since H release, ETSI packages can also be signed as per the specification SOL0007

The LF toolchain is digitally signing artifacts (Dockers) produced through GPG

SDC uses input validators (for number/string format) and does check against specific values (eg : radio button in UI is also checked on against actual values in API calls to ensure they are valid). Note that SDC does take files as input (models, csar(zip), helm packages), even though SDC does some level of validation there as well (far from being complete) it does seem this particular item is out of scope for this question.

https://sonar.onap.org

All the projects use Java which are memory safe that run on JVM. Also the end product runs on a docker container which is run on docker.