Page Comparison

SECCOM weekly scheduling/timing

Security is part of the ONAP DNA. The community continued to improve the security of the platform by continuing the migration from Java 8 and Python 2 to Java 11 and Python 3. Approximately 550 security and code quality issues in the ONAP developed code were fixed.  Additionally, open source dependency upgrades removed nearly 700 known vulnerabilities. In the effort to shift security further left, a proof of concept was performed that integrates security and code quality tests into the merge process. Unused and unmaintained repos were removed from the release. Finally, a uniform set of security events to be logged and data about the events were defined and will be staged into ONAP beginning with the Jakarta release.

Requirements Subcommittee session held yesterday:

• Jakarta SECCOM requirements presented (Bob, Amy, Pawel), no specific comments received

Software BOMs presentation by Muddasar.

Feedback from Krzysztof Opasiak

• SECCOM presentation on Istanbul achievements by Amy
• Nov 15 PTL meeting as a new date for Istanbul release sign-off
• Nov 18th – presentation of non-functional requirements to TSC

Update from Toine – ok from the team, questions to be clarified.

Weekly and daily testing by Integration team

Are the filebeat containers included in the release?

To be confirmed if LFN would run SBOMs, as LFN signs the ONAP code. Kenny was contacted at least twice but no feedback. 

https://docs.sonarqube.org/latest/user-guide/security-hotspots/

This is for security testing - results to be compared. Exception file support under consideration as might not be supported at the very first step.

• sdc
  • Security hotspot : 1
  • Bug Major : 100
• aai
  • Security hotspot : 97
  • Bug : 74
  • vulnerability : 29
• dmaap-messagerouter-dmaapclient
  • Security hotspot : 10
  • Bug blocking : 17
  • Bug critical : 63
  • Bug Major : 119

Meeting on November 1st was cancelled.

• A Security Hotspot highlights a security-sensitive piece of code that the developer needs to review. Upon review, you'll either find there is no threat or you need to apply a fix to secure the code. Another way of looking at hotspots may be the concept of defense in depth in which several redundant protection layers are placed in an application so that it becomes more resilient in the event of an attack.
• Vulnerability or Hotspot? The main difference between a hotspot and a vulnerability is the need of a review before deciding whether to apply a fix:
  • With a Hotspot, a security-sensitive piece of code is highlighted, but the overall application security may not be impacted. It's up to the developer to review the code to determine whether or not a fix is needed to secure the code.
  • With a vulnerability, a problem that impacts the application's security has been discovered that needs to be fixed immediately.An example is the RSPEC-2092 where the use of cookie secure flag i.
• Why are Security Hotspots Important? While the need to fix individual hotspots depends on the context, you should view Security Hotspots as an essential part of improving an application's robustness. The more fixed hotspots there are, the more secure your code is in the event of an attack. Reviewing Security Hotspots allows you to:
  • Understand the risk – Understanding when and why you need to apply a fix in order to reduce an information security risk (threats and impacts).
  • Identify protections – While reviewing Hotspots, you'll see how to avoid writing code that's at risk, determine which fixes are in place, and determine which fixes still need to be implemented to fix the highlighted code.
  • Identify impacts – With hotspots you'll learn how to apply fixes to secure your code based on the impact on overall application security. Recommended secure coding practices are included on the Hotspots page to assist you during your review.
• Source: https://docs.sonarqube.org/latest/user-guide/security-hotspots/

Kubernetes hardening

Muddasar and Bob provided some feedback to NSA team related to logging requirements