This template is intended to be used to document the outcome of the impact analysis related to the known vulnerability reported by Nexus-IQ (CLM tab in Jenkins).  Nexus-IQ can identify the known vulnerabilities contained in the third party components embedded within ONAP deliverables.

PTLs should report in the template below only the vulnerabilities that Nexus-IQ is reporting as "Critical" (Level 7 to 10) and "Severe" (Level 4 to 6).

See the INSTRUCTIONAL VIDEO to learn how to navigate Nexus-IQ reports.

After approval of M0 for an ONAP release, the SECCOM will create a new section in the Security Vulnerabilities ONAP wiki space for the release containing copies of the Security/Vulnerability - Full Content pages for the included projects based on the most recent NexusIQ scans for the projects. There will be a table for each repo. Please do not combine findings as this makes it difficult to understand the security posture of each ONAP.

The projects must update this table for each milestone, as follows. The final table will be presented to the TSC at Code Freeze milestone (M4).

M1

  • The PTL will review the Nexus-IQ scans for their project and update their Security/Vulnerability - Full Content page
    • Repository: The repo containing the vulnerability
    • Group, Artifact, Version: Group, artifact and version of the package
    • Problem Code: The CVE or SONATYPE report for each vulnerability is listed
    • Effective/Ineffective: Each vulnerability is identified as being a Effective or Ineffective
      • Effective - there is an execution path of the ONAP code that will cause the vulnerable code to be executed
      • Ineffective - there is no execution path of the ONAP code that will cause the vulnerable code to be executed
    • Resolvable by Project: Each vulnerability is identified as something that the project can or cannot fix.
      • Yes - The project can upgrade, replace or remove the package to eliminate the vulnerable code.
      • No - Either there is no package upgrade or replacement available that eliminates the vulnerability.
    • Impact Analysis:
      • Explanation of why the vulnerability is Effective or Ineffective.
      • Description of whether the package is a Direct or Transitive Dependency:
        • Direct - developer explicitly included the package and can be directly upgraded by the developer
        • Transitive - package is included by virtue of being a dependency in another package; the developer may not be able to upgrade.
        • If the dependency is in a Transitive package, list the Direct Dependency(ies) that causes it to be include in the ONAP code, e.g., several ONAP projects include vulnerable packages because they use ODL which uses vulnerable packages.
    • Action: Each vulnerability has a corresponding Jira ticket with the following information:
      • Name of the package with the vulnerability.
      • If the package is a Transitive Dependency, name of the Direct Dependency that results in the inclusion of the vulnerable package.
      • One of the following paths to resolution:
        • Vulnerable package (Direct or Transitive) will be replaced or upgraded with available non-vulnerable package.
        • Vulnerable package replacement or upgrade is not available:
          • Direct Dependency - Project will monitor for a fix.
          • Transitive Dependency - Project will work with the owner of the Direct Dependency develop an upgrade path or will investigate a replacement .
      • If the vulnerability is effective, the Priority must be set to Highest.
      • If the vulnerability is ineffective, the Priority must be set to High.
  • The SECCOM will review each Security/Vulnerability in the Full Content page:
    • Ensure that each vulnerability found by Nexus-IQ is listed in the review table.
    • Ensure that each vulnerability has a Jira ticket.
    • Ensure that project follows-up all required actions: e.g., execution of package upgrade from previous release Jira ticket. 

M2 & M3

  • The PTL will review the Nexus IQ scans for their project weekly and update their Security/Vulnerability - Full Content page
  • The SECCOM will not review the tables, trusting that the PTLs are keeping the tables up to date; the SECCOM will answer questions from the PTLs or their delegates

M4

  • The PTL will finalize their Security/Vulnerability - Full Content page making it consistent with the Nexus-IQ scans
  • The SECCOM will review each Security/Vulnerability - Full Content page
    • Where necessary, the SECCOM representative will communicate with the PTL to clarify the information in the table
    • Ensure that project follows-up all required actions: e. g. execution of package upgrade from current release Jira ticket
    • When each table has been satisfactorily completed, the SECCOM will create a sanitized copy of each table in the public wiki to be included in the Release Notes

Note: A PTL may delegate the task of analyzing Nexus-IQ findings and updating the Security/Vulnerability - Full Content page to authorized security subject matter experts on their team. In such a case, if those experts do not have access to the protected wiki space, the PTL should create an LFN helpdesk ticket to request access. Note that only committers can be granted access to the Nexus-IQ reports.

It is recommended to first update to the latest version of the third party components available or to use the Oparent dependency approach (ask Gary Wu or Yang Xu for details). In case the latest third party components still reports some vulnerabilities, you must provide an impact analysis as illustrated in the example below.

In the case where you have nested third party components (a third party component embedding another third party component) and there is NO CVE number for the upstream third party component (meaning the third party component you are embedding), the PTL (or delegate) MUST open a vulnerability issue on the upstream third party component.

Usage

Within the M4 checklist create a link toward the copy of this template for your project.

Between, M4 and RC0, SECCOM (Amy Zwarico and Paweł Pawlak) will review and create a sanitize version for public visibility.


The information related to Repository, Group, Artifact, Version and Problem Code are extracted from the CLM report (see the below screenshot).

RepositoryGroupArtifactVersionProblem Code

Effective/Ineffective

Resolvable by ProjectImpact AnalysisAction
aai/schema-serviceorg.eclipse.jettyjetty-util9.4.15.v20190215CVE-2019-10241EffectiveYesAdd the explanation of the conditions under which the vulnerable code is executed and any precautions an ONAP deployer can take to prevent the execution of the vulnerable code

JIRA link

In the JIRA ticket, explain findings and action plan

Add the labels "Security" and the targeted release

aai/schema-serviceorg.eclipse.jettyjetty-util9.4.11.v20180605CVE-2019-10246IneffectiveNo

Add the explanation why the vulnerable code is never executed when the code in this component executes

Jira link

In the JIRA ticket, explain findings and action plan

Add the labels "Security" and the targeted release


Sample of CLM Report

Not shown because of NexusIQ license restrictions