Page Comparison

New ticket was opened as old one was closed by Jess. Reference link provided by Jess points out to the deprecated API

documentation. Tony provided his comment under the ticket. It seems that the new reference is for API documentation that will stop working in a few months. So it is a workaround and not ultimate solution.

The replacement we should be using accroding SonarCloud requires explicit permissions to search varoius different repos to be granted to the person doing search which is not a good solution. 

IT-23621

Log4j status update – we recommendreleasing Istanbul Maintenancerelease*

• Target version 2.17.1: https://logging.apache.org/log4j/2.x/changes-report.html#a2.17.1

Following All related jira tickets openedclosed:

• AAI-3431 - AAI status (4 components with log4j) COMPLETE
  • aai-graph-admin, aai-resources, aai-traversal, aai-common : log4j <2.17.1 Direct dependencies updated
  • Waiting for OOM code merge - COMPLETE
• DMAAP-1704 - DMAAP status (1 component with log4j) COMPLETE
  • dmaap-messagerouter-messageservice: log4j <2.17.1 Direct dependencies updated
• SDNC-1655 - SDNC status (1 component with log4j) – COMPLETE - Latest CLM scans for SDNC-OAM do not contain any version of log4j, so it is removed
  • sdnc-oam: log4j 1.2.17 Direct dependency -> Dan created a ticket for an upgrade in Istanbul with low priority (https://jira.onap.org/browse/SDNC-1591) – “data-migrator needs to be migrated from log4j to log4j2 - which mostly entails just updating properties file and command line arguments in run script. Note: data-migrator is not currently used”. I have increased priority to high and added fixed version: Istanbul Maintenance release + comment under the ticket on the need to migrate to log4j-core 2.17.1.
• VNFSDK-827 - VNFSDK status (1 component with log4j) COMPLETE - Kanagaraj removedvnfsdk-ves-agent from Istanbul & Jakarta
  • vnfsdk-ves-agent: no scans for Istanbul branch -> as per Kanagaraj’s email sent on 24th of August, he mention that vnfsdk-ves-agent is not an active VNFSDK repo, so I have sent him an e-mail today to configure his jjb file accordingly.
• Restricted Wiki for Istanbul Maintenance release created
• CVE creation: no need to do it, simply we will document in the Release Notes repos that were impacted and fixed. CVE is raised for vulnerability discovered in the code.

New Ticket opened to LFN IT on NexusIQ reporting false positive log4j direct dependencies.To provide SECCOM recommendation at the TSC for releasing Istanbul Maintenance releaseCLM jobs failing.

• Tony (slides 8 and 9):
• Maggie:

(1) OWASP Top 10

• • https://owasp.org/Top10/

(2) BSIMM

• • https://www.bsimm.com/framework.html

(3) Secure Software Development Framework 

• • https://csrc.nist.gov/Projects/ssdf

  This publication is a little different and is actually geared more for when selecting products and making good choices on deployment across the   enterprise.  However, it does bring up points that we may want to consider addressing across the architecture.

(4) CIS Critical Security Controls

• • https://www.cisecurity.org/controls

• Muddasar:

-Security Belts structures activities of the secure software development

-https://github.com/AppSecure-nrw/security-belts

-OWASP Devsecops Maturity Model       

-https://dsomm.timo-pagel.de

-DevSecOps Platform-Independent Model: Requirements and Capabilities-SEI (FFRDC) Technical report (figure 7)

-https://apps.dtic.mil/sti/pdfs/AD1152747.pdf

-ISACA Cybersecurity Maturity Assessment (self-assessment)

-https://www.isaca.org/enterprise/cmmi-cybermaturity-platform#cmmicp-tabs

ONAP 5Y assessment should be a group capability assessment where we stand for the security measures that we have and how we measure it.

From assessment on per each project level we will get an image of ONAP as a whole.

Pawel to create criteria's proposal (kind of high level document propsoal) for futher review based on Figure 7.

Distinction between SCA scans: source code (better) vs. executables.

Industry best practice is to find 3rd party packages in your code or to generate an SBOM. Having SCA scans against source code provides full information about composition of your application. 

Discussion on alternative ways of packaging CNFs to ETSI SOL (option 2 supported with package signature) and ASD (some extra metadata), need to ensure signing capabilities.

Istanbul Maintenance -> 17th of February

Unmaintained projects

JSON file review, what repo to be stored and where. 

Log4j SECCOM recommendation for Istanbul Maintenance release presented

https://wiki.onap.org/display/DW/Jakarta+Best+Practice+Proposal+for+Standardized+Logging+Fields

Some more clarifications planned, naming causing some confusion.Good progress.

One more session (on 25th of February) to complete fields review.

Next to be reviewed with PTLs.

Jess had trouble with polling dependencies from some project. All CLM jenins jobs are failing now.

We want to make SBOM available to end user.

We are compliant to MVP for fields for SBOM.

SPDX 3.0 standard will have an extended field capability (long list of optional atributes) and there will be a new ISO standard associated.

Amy made some contributions already. Contribution needed for SBOM part – Sean to be addressed.

https://wiki.lfnetworking.org/display/LN/2022+LFN+Security+whitepaper

NTIA paper could be a good reference.

SECCOM MEETING CALL WILL BE HELD ON 1st OF MARCH'22. 

Quality gates for code quality improvements - continuation of the discussion.

5Y review criteria.