Dear LFN TAC,

The ODIM community is a bold collaborative open source initiative to bring together a critical mass of physical infrastructure management and infrastructure/service orchestration stakeholders to define and execute collaborative work focused on creating new critical open source building blocks, in areas such as composition, aggregation and telemetry, define new models and APIs, as well as influence key extensions to the DMTF Redfish® specifications that ODIM builds upon. This community will coordinate with other key SDOs and open source communities, with a focus on automation, simplification, consistency and interoperability of COTS and OSS infrastructure management solutions resulting in acceleration of infrastructure deployments across segments, while lowering operational complexity and cost.

Since June of 2020 ODIM has been an unfunded LF project and has been steadily building a robust and diverse community. Release 20.01 was released in January 2021, and the next release is on target for August 2021.

This email is formal request for LFN induction review, as a Sandbox project, during the March 10, 2021 Technical Advisory Council (TAC) meeting. The Project Induction Proposal Material is provided for your review.

We look forward to a discussion with the LFN TAC on March 10.

Best,

Alex Vul

ODIM Project TAC representative

Hello Brett, Jim and LFN TAC,

I am familiar with the XGVela project based on my active engagement with ONAP. I will be happy to either lead or participate in any workgroup discussion that may be desired from the

LFN TAC perspective  to further understand the details of this project.

Regards,

Chaker

Hello LFN communities,

Following the success of last year’s LFN technical whitepaper, we have kicked-off the process of creating the next one.

This year’s whitepaper should continue to share our vision with a broader industry audience, drive adoption of our software and bring on more players to the game.

The theme for the paper is still open for decision and we are looking for contributors.

Based on previous experience contributors can invest as little or as much as they see fit. As a contributor you will benefit from collaborating with other experts in the community and spreading your ideas. You will of course get credit as an author. You don’t have to be a member of any project or committee to contribute. Participation is open for all.

If you would like to participate or propose a theme, please add your name on this page:

https://wiki.lfnetworking.org/display/LN/Theme+proposals+and+Subject+Matter+Experts

Thanks,

Ranny Haiby

Interim Whitepaper workgroup leader.

Sorry I was unable to attend.  Sadly, this time will rarely work for me as it is my weekly staff meeting with my management!  These meetings do get canceled sometimes, but we will see how this works.  I saw the notes and I think that we are on the right direction.  I would suggest that we consider setting up a mini plenary – a couple of hours – to brainstorm how to move the work forward.

Beth Cohen

DMTS - NFV/SDN Network Product Strategy
Verizon Business Group

O 781.466.2055
M 781.434.8553
60 Sylvan Rd.
Waltham, MA 02451

  

Hi,

My colleague @Krzysztof Opasiak correctly commented that scanning Java dependencies is a good start, but there are vulnerabilities that come through Docker image dependencies. Our colleague @Alexander Mazuruk recently did some excellent image dependency scanning work for ONAP together with @morgan.richomme@.... They presented their work in the DDF:

https://wiki.lfnetworking.org/display/LN/2021-02-01+-+Plenary%3A+Dynamic+License+Scanning

Some of the tools used such as TERN and ScanCode may be used for image vulnerability scanning.

Ranny.

Brian, thank you for trying it out and getting some real metrics!

Today ONAP is running NexusIQ weekly and it generates an SBOM. There is an API that to get the SBOM in JSON or XML (I believe that NexusIQ uses the SPDX standard for SBOM encoding). I will get details from one of my co-workers when he’s back in the office (Nadeem Anwar). ONAP is using this information to provide PTLs a list of the vulnerable direct dependencies in their project that require updating. Note that the Linux Foundation makes NexusIQ available to all LF projects.

An SBOM in and of itself does not prevent an attack, but it provides information about the code, can be used in conjunction with the National Vulnerability Database (NVD) to understand the know vulns associated with each package. NexusIQ provides both SBOM and the vulns in each package. Based on this information an organization can decide how much risk is associated with using unsupported/vulnerable package versions, develop tests for exploitability, or put other compensating controls in place.

Brian, thank you for trying it out and getting some real metrics!

Today ONAP is running NexusIQ weekly and it generates an SBOM. There is an API that to get the SBOM in JSON or XML (I believe that NexusIQ uses the SPDX standard for SBOM encoding). I will get details from one of my co-workers when he’s back in the office (Nadeem Anwar). ONAP is using this information to provide PTLs a list of the vulnerable direct dependencies in their project that require updating. Note that the Linux Foundation makes NexusIQ available to all LF projects.

An SBOM in and of itself does not prevent an attack, but it provides information about the code, can be used in conjunction with the National Vulnerability Database (NVD) to understand the know vulns associated with each package. NexusIQ provides both SBOM and the vulns in each package. Based on this information an organization can decide how much risk is associated with using unsupported/vulnerable package versions, develop tests for exploitability, or put other compensating controls in place.

Jason, Robert,

Interesting tool.

I added it to the parent pom.xml for one of the ONAP repo’s and did a test run

quite intensive (saturated 1 cpu core for 5 minutes or so – single threaded ? )

Not sure if there are other tools being used in Opensource for SBOM generation but the xml and json format of the data seems like it would be the kind of electronic format that could be provided with packaged software for those organizations that require SBOM tracking.

We also have python code in a lot of projects so not sure how an SBOM would be created for that.

I think this allows us to publish our dependencies so someone could quickly determine if we were affected by an attack on someone else.

I don’t think this would prevent an attack on our code would it ?

Brian

2021-02-10 TAC Minutes

LF Staff: Kenny Paul,  Jim Baker, Brandon Wick, Heather Kirksey, Trishan de Lanerolle

Others: Timo Perala, Beth Cohen, Tina Tsou

Minutes

• Welcome Martin Jackson from Walmart - new Platinum member
• Working internally to grow expertise in this space
• Looking to understand strategy and direction of LFN at this stage

• Developer & Testing Forum Feedback
• PLEASE take the Survey if you attended - closes on the 17th
• Feedback from the technical event
• Strong interest by communities - often had 3 parallel tracks - perhaps a different platform for non-interactive presentations - focus technical events on interaction/brain-storming
• Maybe a YouTube channel that can be used for more presentation based info
• Developer advocacy videos - demo showcase, project lead interviews, live-coding sessions, interactive meetings/discussions
• FD.io planning deep dive webinars
• Would like all presentation recordings on the YouTube as well
• Each community should have its own channel as not to flood the LFN level channel, making it difficult to navigate
• 4-5 community members from each community should have YouTube keys

• EUAG Discussion and Planned Collaboration Session 
• 2 presos at the Dev event
• How can we ger vendors and operators together to better exchange information
• Meeting on the 17th is on the TAC calendar - 1430 UTC 17 Feb 2021 
• Beth Cohen operator data is obviously sensitive info and challenge is presenting data in an anonymous fashion

• TAC Lifecycle Documentation draft Review 
• doc in draft translating the service tier spreadsheet to a narrative is in draft by LFN Staff
• Will be discussed on the list once ready

• Next version of LFN Technical Whitepaper Ranny Haiby
• 2021 Whitepaper Workgroup
• Need volunteers to contribute - 1-2 hrs. per week for ~8 weeks
• Contributors also include folks that need to review content
• Project reps please mentioned at your next TSC meetings
• Brian Freeman  - eval of SolarWinds type of attack on supply chain
• Martin Jackson - Supply chain attacks is top of mind for enterprise - this was already FUD in the enterprise space. Should discuss it head on.

• Interaction with other communities Brian Freeman
• LFN needs clarity/documentation around where LFN's interaction is with other foundations (LF-Edge, LF-AI, etc.)
• Specific wiki page a logical step
• Heather Kirksey - although we've tried many of the organic cross- pollination conversations that would normally occur at an event just don't materialize during virtual events.
• topic for a future meeting

Action items

• Casey Cain overview the YouTube channels for LFN and projects structure in TAC prior to delivering the keys to the project communities 24 Feb 2021 
• Jim Baker reach out to LF-AI to attend the meeting on the 17th 11 Feb 2021 
• LFN Staff ask communities what expectations they have of the next whitepaper 24 Feb 2021 
• Kenny Paul add cross community awareness and documentation as a future meeting topic (4 weeks out) 10 Feb 2021 
• Kenny Paul add Event survey results to next meeting agenda. 10 Feb 2021 

Thanks!

-kenny