...
| Jira | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|
|
Backlog (to be depricated as replace by Jira).
...
Creation of a Vulnerability Management Procedures and Team.
...
Done. Activity Closed.
...
Nexus IQ/Sonatype LCM has the ability to identify and display known vulnerabilities of used components. These used components are in the end part of the ONAP release and it is not desirable to release with known vulnerabilities.
A proposal needs to be created to bring to the TSC to address how to work-through the known vulnerabilities and relate it to the project release plan.
...
Nexus IQ/Sonatype LCM is ready for use and the results can be made available.
Status: Proposing to TSC
...
https://github.com/linuxfoundation/cii-best-practices-badge
This may identify good practices, which could include guidelines. consider, Ensure least privilege by design), consider how to look at code scaning into the integration processes.
Also look at:
- https://wiki.opnfv.org/display/security/Security+Home
- https://wiki.opnfv.org/display/security/Opnfv-security-guide
...
Done.
The security subcommittee recommends a gold level.
Included in the S3P recommendations.
...
Identify and propose a process for static vulnerability scans
Information can be found on: https://wiki.onap.org/display/DW/ONAP+security+Recomendation+Development
...
Recommendation: Coverity is used, and included as part of the CI/CD tool chain with weekly mails to the PTLs, with seccom support in analysis.
Status: proposing to TSC
...
Proposed architecture and proposal for handling credentials in ONAP
Information can be found on: https://wiki.onap.org/display/DW/ONAP+security+Recomendation+Development
...
Completed. Credential management and secret storage service will be part of the AAF project scope..
...
wondering if the Security subcommittee would find it helpful to the community to document the various attack surfaces that ONAP has and to identify what, if any tooling, counter-measures, etc exist for each, what has been covered, what is a continued gap, etc. Such attack surfaces are:
- South-bound interfaces - communication with controllers, EMSs, VIMs, VNFs, etc. What authentication, authorization, and encryption are or can be put in place for these interfaces?
- East/West interfaces - communication with other orchestrators, VNFCs, etc. ""
- North-bound interfaces - Portal access, External API access, etc.
- Component/Upgrade Security. How to ensure each ONAP component is an authentic part of the ONAP system? How to allow, but secure component upgrades?
... etc. Those are in addition to what we know we are already focused on such as:
- ONAP code vulnerabilities
- 3rd Party component published vulnerabilities (CVEs)
Given the broad scope of "ONAP Security", would we find it helpful to spell out all the different types of security that we can imagine when dealing with this system, prioritizing what are most important, identifying where we have good/medium/poor coverage of a particular attack-surface and long range plans/aspirations on improving them?
...
If you want to be involved, please contact Stephen.terrill@ericsson.com
...