OSPOlogy Day Cloud Native 2026 Presentations, Demos & Facilitated Discussion Notes

[anajsana]

Creating a thread for the OSPOlogy Day Cloud Native presentations, demos, and roundtable notes. Please add your slides, materials, and facilitated discussion's summary notes as new comments to this thread via like (e.g, Google Slides, SpeakerDeck, etc) or PDF upload.

[ramiyengar]

OSPOlogy KubeCon Amsterdam.pdf

[anajsana]

welcome slides

Welkom_OSPOlogyDay_CloudNative.pdf

[koozz]

OSPOlogyDay_CloudNative_OSPO_book.pdf

[santidhammo]

Compliance Gate for Restricted Environments 1.pdf

[DavidPHirsch]

When Open Source Momentum Dies OSPOlogy.pdf

[nicorikken]

Facilitated Discussion: Scaling LF/CNCF trainings and certs in a large corporate enterprise

Host: @grnrs

Challenge: How to get colleagues to participate in CNCF ecosystem and take part in training and certifications as part of it.

Discussion

Noting down 'engineers' as a general term, that can include other types of professionals.

• Cloud providers for larger contracts offer training days and have direct engineering team contact to promote it.
• Engineers seem to focus on cloud provider certifications with services, rather than realizing that there are trainings on more independent technologies like Kubernetes.
• In consultancy contract training percentage can be a percentage, which can be part of procurement terms.
• Training should be appealing for the engineers.
• Certifications should be recognized by industry for credibility.
• Training and certification is and should be related to the strategy of a company, like migrating to a certain technology or product.
• An engineering ladder can be used to structure training and certification. That requires alignment with HR and strategy.
• Brown bag / lunch presentations with external speakers from the community can be a method to engage with engineers and HR.
• Certification is not a gateway for community contribution because that is based on merit. It can help gauge the knowledge level of a contributor.
• The value of certification and training is also in choosing the right projects in engineering decisions. Choosing the 'wrong' project and having to migrate can be costly to a company. Being able to assess a project is important.
• Engineers that engage in the community might consider the conference to be sufficient.
• LF Event attendance can be an opportunity to hint at the LF training and certifications.
• Engineering Managers should be the stakeholders for the strategy so they can be suggest the training to the engineers as an opportunity for training.
• Responsible for the LF training organization can help build recognition internally by contacting the manager when a course or certification is completed.
• Discoverability of LF trainings can be increased by offering them as an 'internal training' in the portal, if direct integration is a challenge.
• Keep promoting the training at public options, that there are certifications attached to it.
• The certifications can be part of the open source involvement of engineers, like on a 'open source Fridays' where engineers are allowed to contribute to open source.
• Trainings for soft skills are often easier to arrange compared to technical trainings.
• How to incentivize engineers to follow training at all and choose the more in-depth trainings.

[Starefossen]

Faciliated Discussion; Contributing to oss at scale in large orgs

Host: Thomas

Challenge: 1) github account ≠ understanding oss, 2) being an engineer ≠ being an maintainer, 3) free for all vs. legal minefield

Discussion

• maintenance: someone builds something (eg. covid), how to ensure things are maintained
  • project thinking culture: build => deliver => done
  • shift the culture (and funding) to a product mindset
    • most governments have models for building and maintaining bridges
• centralization vs. decentralization
  • different types of projects / products warrant different types of governance models
  • blueprints for different types of projects
    • ex. labling git repositories for what governance model applies
• budgeting and cross-org invoicing shared services
  • Norwegian Government has developed a cost model for shared services 1
• how to handle code of conduct / company violations on shared personal+corporate account
  • do you do policy or do you do monitoring
  • social norms for maintainers

[grnrs]

Host: @nicorikken
Making your license policy easy to communicate and enforce

Discussion notes

• there is a difference between inbound and outbound license policies

• first step: policy properly assessed and documented

  • wiki, website, slidedeck
  • better understanding of what they use

• automation can help, but also mislead:

  • huge need for further training
  • serve engineers with warnings and reporting
  • tackling the problem with better tooling
  • try to make the tooling output to be actionable and understandable
  • individual decision making doesn’t apply at that point if you have a hard policy.

• lawyers and legal are helpful

  • as an escalation path
  • create acceptable risk assessment per business use case and department
  • what a license is and what it means is difference -> with an „effective licenses decision -> leads to license intricacies

• understanding of licenses of the employees and what they are dealing with might be on a huge spectrum

  • do we need to make people aware of why and how a policy is build the way it is?
  • is it enough to have a hard requirement on compliance as a first flag of issues
  • recurring training setup

• as engineer: there are already a lot of different compliant toolings and dashboards

  • policy tooling might be blocking the teams
  • OSPO might need to cooperate more and deeper with enterprise architecture and cyber security. can use-case apply more universally?
  • technology blueprints can already provide part of the compliance

• getting priority for the policy as a strategy:

  • training and awareness for policy can follow a split approach based on target audience: c-level and managements, business and product owners, engineers
  • as OSPO try to approach high priority business use cases

[natalisucks]

Facilitated Discussion: How the CRA will affect CNCF projects

Host: Natali Vlatko (@natalisucks) and Mirko Bohem

Discussion:

How did the CRA evolve and how are we (the CNCF) implementing it?

• CNCF releases a lot of software that ends up in a lot of products, across the globe
• CRA will change how software gets released, and it will change how the stewards (like the CNCF) document this software
• If you have a device, it has a backend in terms of updates and so-on, thus CRA also affects this, in terms of overlaps with cloud software and what the CRA covers
• Best practices will develop across the community about how this evolves

Things to note when making sure you understand the CRA:

• The CRA is about cybersecurity: it isn't about software processes or procedures
• Legal entity, not a manufacturer: this is what defines an open source software steward
• There are small developer communities that help projects, but they aren’t a legal entity, thus they’re not a steward, and they’re not covered by the CRA
• Who is my steward? It depends on the legal entity – there are currently two: LF and LF EU (CNCF is not a legal entity). Each legal entity will have their way of making sure that there is a unified reporting process – this is coming but we don’t have a timeline yet
• Requirements of the community and the CRA will bleed over, and community health metrics are going to be important here for manufacturers to consider

What do stewards have to do as part of the CRA?

• They have to have a security policy
• On request of national market surveillance authorities, they must work with them on bigger issues (think of Heartbleed)

Responsible disclosure – this means means something different to everyone: If I found a vulnerability and decide to push that fix upstream without first communicating with the maintainers, isn’t that bad? Doesn’t that overtly affect other people using the project? According to CRA, no, you’re already exemplifying the behaviour they want in creating a patch and submitting it upstream.

Voluntary attestations:

• The law is currently generic and high level, and there is current standards work happening as a request from the European Commission that has been asked of from the main three standards orgs, with details currently being hashed out
• This includes: what does voluntary attestation actually mean?
• The expectation is that stewards will publish voluntary attestations, and LF/CNCF hopes to see (and implement) that releases come with these voluntary attestations

Penalties only affect manufacturers! (As in, 3% of your global revenue)

• “Provision of software without commercial intent”: this is another meaning attached to what a steward is, and how they’re treated differently, and why they wouldn’t have fines applied – fines only affect those who produce software (digital products) with commercial intent
• The CE mark is going to extend to CRA for digital products, for manufacturers, but a steward is not allowed to apply these, since they don’t have "customers" in this definition of the law
• Any sort of monetisation of any software indicates commercial intent

The responsibility for due diligence, when someone consumes from upstream, then places this in a product that goes onto the market, is on the first manufacturer that pulls the software and puts it into the product – there is no responsibility on the upstream project to maintain something secure or patch vulnerabilities!

A lot of what the CRA contains isn’t new: how you should contribute and report upstream for example, isn’t new, we’ve practiced these behaviours before, it just makes these best practices explicit now

Is there a mechanism to compel open software stewards to be doing the right thing per the CRA? Not at the moment – 95% of obligations are with the manufacturers, not the stewards

So a manufacturer can be both a manufacturer and a steward!? But the courts won’t care about this: shouldn’t we as manufacturers just treat our open source like products? Or are we okay with treating these projects under the recommendation of “pulling from upstream”, even if our company is where the “upstream” is on GitHub?

Vulnerability obligations as part of the CRA start from August 2026