I'd like to introduce a black who is working on security attestation ideas within the scope
of the CRA and he's going to tell us about the work, thank you very much.
Thank you.
I've been a little less present at Boston, it's great to be back, so for those who don't
know me in the last couple of years, I was doing open-source security policy at Microsoft
and then kind of got pulled into more public policy, joined CISA for a while, moved over
here last year and now working on this with both of the clips and the commission trying
to figure out how to make this all work.
So quick overview of the talk and for those who are coming in and back those tons of seats
I'll give a quick background overview of the regulation, I think the previous talk, if
you were here for it, also covered a bunch of that, but also touching other regulations.
And I'll give you a little bit of info on the progress of our working group.
It's been running for a few months, some of the challenges we've identified and some of them
are pretty interesting, so we'd love your help.
Definitely, the end of this hopefully more folks will come get involved in solving these problems
together and then my talk will be only about 20 minutes, we will go maybe have time for
one or two questions, then shift into a panel, a couple more folks will join me up here
and we'll go through some questions for that and then take questions from all of you.
So a couple of years ago at a phos and adjacent event, I got teased a little bit by some
of European colleagues that you know, America innovates, but you're a regulates and that's not a bad thing.
I think they were absolutely right, but maybe America's innovation didn't go far enough with this one.
Back in 2023, I had the chance to consult with White House as they were drafting their
national cybersecurity strategy and then found out months later they actually quoted me on it.
This is like maybe some of the proudest sentences I've ever said.
The burden has to be on the users of the software, not on the freedom of software developers.
That was written into the strategy, but not really into law on the U.S., I'm so delighted it is encoded in the CRA,
which introduces the concept of the open source steward as a new type of legal actor.
Manufacturer, contributor, developer maintainer, foundation, and a steward, and it defines this a bit.
This is sort of what we're all grappling with as the CRA implementation moves along.
This is a new concept, legally, the lawyers don't know what to do with it quite yet.
We're still waiting for some guidance from the definition of it, though it's much better
interested now than two years ago, and this is a uniquely European framework at the moment.
There are a couple definitions I want to emphasize for folks, manufacturer, has a specific
definition that is distinct from an open source steward.
There is no effect from this on personal expression, hobby projects, just writing code, making contributions.
There's no obligation there, but there are some obligations for those two classes of actors.
Manufacturers have specific obligations with respect to open source.
They have to exercise due diligence into legal term if they're using open source in their products.
I suspect most manufacturers aren't doing that today.
If they find a vulnerability in the open source, they're using, they have to share the awareness
of that, report the vulnerability to the open source projects.
And if they fix it, they have to offer the fix back to the project.
The project doesn't need to take it.
There's no requirement on the project, but there is a requirement on manufacturers to do these things,
including to include open source in their S-bomb, and in their assessments for product risk and product safety.
And to handle the open source, the vulnerability is a product life cycle.
So if they chose to use open source, and five years from now or two years from now,
the project fixes the vulnerability of the manufacturer still has a responsibility
because they chose to rely on it.
On the steward side, it's a very lightweight.
You have to publish documentation about your cybersecurity policy,
your vulnerability handling policy, how to receive the report, about a vulnerability,
or how to notify people who've used your project that they should do if it's something
or pull down if it's back or something from you.
And notably, steward's under this new framework must have of the willingness and a capacity
to cooperate with market surveillance authorities and with cybersecurity coordination authorities like Anisa.
And this has been pretty common among the larger projects, Linux kernel, Apache Python, open stack, et cetera.
It's less common in the small projects, but it isn't required in every project.
Again, none of this is required for hobby projects or your non-commercial open source
that you're just writing with some friends.
This only applies to organizations that want to function as a steward.
This is relevant to the question of sustainability that I'm going to get to.
This pattern seems to emerge from careful reading of the real tech to the CRA and the context around it.
The goal of these regulations is that stewards in particular,
but also maintainers or other participants in the open source ecosystem,
can help the market benefit from open source efficiencies.
We already do that.
Open source has proven over the past 30 years to be perhaps the most economically efficient innovation engine we've ever seen as humans.
And it is global, it is across borders.
These are fantastic emergent properties of what we do in open source.
But because there's so much lack of digital safety right now,
devices failing or being vulnerable or being hacked,
the regulation is coming down that says many factors of products with digital goods have a responsibility burden to keep their products safe.
Well, if the manufacturers are going to be benefiting from the efficiencies of open source,
they need to help support that.
The regulations pretty clear on that, but doesn't specify the mechanism yet.
It does set aside the power for the commission to specify it in the future.
And throughout the CRA, there are these couple different delegated acts.
Basically, the commission says we're not sure how to solve this yet,
as a couple years ago, but we might solve it soon.
We're probably going to solve it soon.
And in this case, they've asked for all of us to sort of discuss it at input
and help them figure out what's going to work for open source.
If you've watched the keynote yesterday or some of the toxin jansson today,
or the one right before this, you will have noticed a theme this year, all over Phasem,
commission and other European government folks are here.
They're asking for input.
They've been building this engagement with open source,
because open source communities are now part of civil society and global digital infrastructure.
And this article is expressing that need to figure out
how to get the two to work together in a sustainable way.
So we started a project act in October if to explore this,
and hit a model how it might work.
We came up with a lot of questions.
Right now, we have some theories about this,
but the deeper we dig, the more questions we end up with.
The Eclipse, ORC, open regulatory compliance, working group,
the speaker before me was also talking a lot about what the ORC working group does.
They also have come across them at the same questions and posted them and posed them to the commission
and they're waiting for some responses.
Some of them in particular, relevant here is the legal text says,
manufacturer could be a natural person or a legal person,
that's like a human or a company foundation,
but the legal text says only a legal person can be a steward,
which I don't know if it doesn't,
like lots of individual people maintain open source projects
that are super important.
The legal text is a bit vague on that.
There's a whole bunch of other things with a legal text.
These are other questions.
But as a group, we have this goal.
Find a way to reduce the market burden of reassessing every open source component in every product.
If every manufacturer had to do that, it would be terribly inefficient,
and most manufacturers don't have the technical capacity or the budget
to do a full audit of all the open source they use.
If you've seen any of the black duck or other sort of analyses and audits of the supply chain,
you may have seen stats like 95% of companies use open source,
and 90% of their stats is open source or numbers like that.
Your average small company that makes a product in Europe doesn't have this or America or anywhere,
doesn't have the in-house knowledge to do an audit of the Linux kernel
and everything else they're using.
So again, there's an efficiency here.
If somehow that open source code can be deemed under the CRA as safe enough,
but because it isn't manufactured, it doesn't get a CE mark.
There's not a company there.
There's some other mechanism needed.
It can also support the shared responsibility of doing the maintenance,
and can this account for projects of all sizes from the really big ones to the single maintainers,
or just the loose collection of people who maintain a project that's 20 years old
and works fine still, and the world still runs on it like a DNS server.
We've made some progress in the past couple of months.
We've developed a tiered model to try and account for these,
you know, the very small and the very large, the microscopic and the cosmologic of open source.
We've clarified a couple of questions around financial mechanisms and transitive dependencies,
because of course projects like Debian, build out of 10,000 other components.
And the tax to make clear that a third party attestation is possible is in scope,
but what does it mean for open source if an unaffiliated entity makes one of these attestations
about a project that they aren't equipped to actually handle the vulnerability,
but it's not participating in writing it.
What does that even mean and is it valuable?
If it's the nature of a delegated act, it doesn't have to specify that yet,
but it might in the future.
So we've been exploring all that.
I'll talk from a moment about the tiers we've come up with.
The light tier and the heavy tier based on a reasonably foreseeable capability of projects
that don't have a ton of commercial support or that do have significant commercial support.
The light tier might be applicable for a component or a library.
It doesn't even have a clear product like use case yet.
Maybe it's just compression utility.
On the heavy tier side, it might be functionally equivalent to a commercial product.
It might be only modified at tiny bit when being incorporated into an actual commercial product.
This might be a browser or a word processor or cloud orchestration engine.
And if you go into the deep nerdy of the CRA and conformity assessments,
there are these things called module A or module B and C or module H assessments.
The heavy attestation seems more appropriate for things that would require a module B and C
or a module H assessment if they were products because the products will need those.
So it's sort of about aligning that.
The light attestation, I'll show you a template we've got in the moment, the draft right now.
It really doesn't require a lot of time investment.
I've been a maintainer for about half of my career of some big projects, a couple small projects.
And I think I could fill out this sort of a lightweight form in the matter of minutes.
For any product I've ever worked on, most of it's automatable.
Based on the BSI's guidance, they published a feedback in November.
And it's pretty similar to the salsa already.
It should be well understood, we just sort of drafted that based on the European standard.
On the heavy side, this gets a bit tricky and more into the unknowns right now,
because most of the CRA vertical standards aren't publicly available,
even if they are available through a national standards body for review.
They're not widely available yet.
So to say, we think the heavy attestation might need to be similar to those.
It doesn't help open source communities because those are locked up in a national standardization process,
since I'd said an ISO, even when they're finalized,
they might still need to spend money to get access.
And they might still be IPR restrictions on them that are incompatible to open source.
I don't know yet. We'll see how all that shakes out.
That's a much bigger topic I'm not going to go into.
Here's the template.
Again, it's really simple. This is just a draft.
We think would work, would love feedback on this.
It's basically, do you have a contributor guideline?
Do you have licenses? Do you check them? Do you have functional tests?
Is there a vulnerability reporting point to contact?
And are you going to be there if someone actually does report a vulnerability?
Do you have an end of life?
Are you promising that if you ever stop maintaining the project?
You're just going to make a post that says, dead now.
It's a basic hygiene of being an open source project.
Very low bar.
Unfortunately, it's a higher bar than a lot of manufacturers are incorporating today.
And that's the key.
Having this low bar harmonized sets a standard for industry.
It's a rely on it.
And there's a lot of similar things that the OpenSF has been doing,
but other goods have been doing to try and take the best practices
that have emerged from 30 years of open source in Apache and Debbie and
an open stack and so on.
And just harmonize as a cross.
As much open source as has commercial utility,
as developers are intending it for commercial use.
So that the industry that relies on all this can have a consistent thing
to rely on and thus reduce errors, reduce risk.
But, like I said, a lot of questions really remain unanswered.
The cost structure or the cost and the structures for stewards as legal entities
today would vary by country.
If they are established in Europe,
not the laws are different in each country.
A stiff tone in Germany and a stiff teen in Italy,
and an AISBL here in Belgium,
have very different nuances.
And maybe your project has developers from multiple countries
and maybe the type of entity you would use
if you were to create a new legal entity to become a steward,
has residents requirements in a country or language requirements in a country
that are incompatible with some members of your community.
That's not ideal.
So these are the kinds of questions that keep coming up as I dig into this.
The other one is that tax incentives seem kind of misaligned.
A steward's activities, maintenance, participation in vulnerability handling,
bug fixing are usually exempted from tax incentives.
Companies and the countries provide research funding over research-based tax incentives.
But those are often exclusionary to maintenance and fixing the bugs.
So this is another area where contacting your officials,
your members of parliament or your local governments,
to try and figure this out might be helpful.
As open source, as an open source maintainer myself for a long time,
I've always struggled in the companies with this,
watching the dev teams that don't do open source,
they're staff grow because they get financial incentives.
So do that while the teams that do open source maintenance
get defunded because there aren't tax incentives for them.
There isn't just a problem unique to the CRN stewards,
but it's been around for a while.
Where we are as a product right now,
we have bi-weekly meetings every Tuesday,
we have a room on matrix, mailing list,
GitHub, please, you know,
contribute to it, open review or comment on reviews.
If you are working in somebody's spaces and have ideas of how to fix this,
please do come to us.
More ideas and ideas from corners of the open source communities
that we don't yet have would be super helpful.
We just launched a small survey.
So whether you are a maintainer, a developer,
a manufacturer, a manager at a tech company,
more input on this survey would be really helpful for us to understand
how ready people are, how interested people are,
how do people think any of this might work.
I'll leave it up as decent cameras or leave it a little longer.
And lastly, I think I've heard four other talks this week say,
hey, the commission right now has an open call for feedback
for input on open source,
an European open digital ecosystem,
and considering the CRA is the first regulations
specifically to train on open source and changing some of the structures around open source
to great opportunity to go have your say as well for how you think these kinds of things
should be implemented over the next couple of years.
What sort of things should be funded,
should the commission do certain studies or investigations
or just what's your opinion on all on how great open source is?
This is a great opportunity to go have your say.
And with that, I want to say thank you and invite my panelists down.
Thank you.