So I thought it was going to be very hard to actually give a talk after the talk that was
just given which was amazing.
But I didn't know what was going to do that without any slides for you to see.
So that adds like an extra dimension to it.
So we're going to talk about, you're going to be able to see the slides later on.
We're going to talk about the attestations.
To talk about the attestations we have to talk about is the requirements as a manufacturer,
you have to integrate a component into your product.
And there are essentially two key things that you have to do.
The first thing is you have to do do diligence when you do this and then get into what
that means.
And the second thing is you have to handle your vulnerability obligations throughout the whole
life cycle of your own product for all of your dependencies.
And for open source, that includes not only your own good direct dependencies, but all
of your transit of dependencies.
So do diligence is essentially, this is really hard to do without.
You have being able to watch the slides.
So do diligence is what you have to do to avoid compromising the cybersecurity of your own
product.
And what's important is when you put in a component, you do not have that component.
There's not itself have to meet all of the requirements of the CRA.
And what's also very important is that the level of do diligence has to be proportionate
to the risk of the component itself, but also how you're integrating that component
into your own product and so your own product itself.
And your vulnerability handling obligations, so that's the second point, they apply to your
product and its entirety, including, of course, all of its components.
So you're going to have to handle vulnerability issues throughout the whole life cycle.
So there are essentially four ways that manufacturers can meet the obligations that they
have when they include components.
The first way is to do everything in-house.
And that, obviously, as a lot of work, when you have to consider all options that have
dependencies.
The second is essentially to rely on a supplier that packages the open source components
for you and handles all of those obligations themselves.
That's not going to be available on every industry, but this is clearly a business model
and some places, especially in IoT.
The third option is to rely on stewards.
The concern with this is stewards are only offering at highly bit of what's required
in the integration process.
They're not there to help with due diligence and the vulnerability handling obligations
are much smaller than yours as a manufacturer.
And so the manufacturer remains responsible also for the transitive dependencies, even for
a stewarded project.
And so it's also important to note that most projects are not stewarded.
If you look at the data, the difference between open source projects that are used in a
large-scale product and the ones that are stewarded are orders of magnitude.
I would have the numbers up here for you, but you'll have to look at them on that
like that.
And so in this year, there's this notion of security attestations that's defined in Article
25, whose purpose is precisely to help manufacturers deal with the due diligence requirements.
And they emerged as the need to essentially move the security left, the shift security
left, back to the components, back to the open source projects, if you will, where it
makes some more sense to do in where it scales better, and to an exchange provide mechanisms
to support financially the projects that would step up to issue attestations.
It can be thought of as an open source equivalent to the C mark.
Of course, those remain voluntary.
And what's also important to note is that it can be issued not only by maintainers of stewards,
but essentially by the integrators and manufacturers themselves, or by third parties.
So there's ongoing work in discussions in the ORC working group on this topic that's
led by Eva Black.
And so if you're interested, they're really encouraged you to have to have a look at what's
happening there.
So now what I really want to talk about is how do we make those attestations viable?
When do they make sense?
And what decisions do they make sense?
They have to provide meaningful value to manufacturers.
Essentially, they have to be a cheaper alternative to doing everything yourself as a
manufacturer to rely on a vendor to provide you with essentially a packaged open source
component.
And they have to help manufacturers tame the transitive dependency help.
So if you think of the relationship between a manufacturer, it's due to the obligations,
you will see that there's essentially three layers which an attestation can help.
The first layer is the first layer is essentially all of the public automatable signals.
Everything that you can identify, if I'm looking at a GitHub project, or it's repository,
and kind of understanding how the project is behaving, how long it's taking to fix issues,
how active it is, and how essentially healthy it's community is.
So this is probably, this is very low cost to create, and it's easy to automate.
And so there's probably not a lot of value there that maintainers can capture, essentially
to help sustain the projects.
I'm expecting that you're going to see code hosting platforms, package managers, etc.
Be focusing on that layer.
The second layer is all of the private security information that a product manager is.
So this is internal processes, CV, history, a time to fix, and all of that data that
usually isn't public for security reasons.
And this is actually no relevant to due diligence, and it really helps sort of better
on the security poster of an open source project.
It's probably not very easy for maintainers to monetize this, but it might be actually easier
for stewards to offer this information, maybe to their membership.
And the last layer is, you know, if you sort of think about what it takes on what is required
of a manufacturer or the integrated component, it's looking at the long term picture.
If a manufacturer has to fix vulnerabilities and its dependencies, then essentially having
maintainers or some third party offering commitment or help to do this in the long term,
that can be very helpful and it can be very valuable.
And so of course, that is an area when the maintainers are the best position to offer this.
And so I really believe that when it comes to manifestations, it is this layer that is probably the most valuable layer.
Because it can really help with conservative dependencies, essentially maintainers can make sure that the dependencies
of their own project are secure and well maintained.
It addresses the total cost of a position of component and not just the due diligence.
So essentially the total cost of the whole period of using it.
And again, I think maintainers are uniquely positioned to help with this.
So there are a few concerns.
The first is whether this makes maintainer take on liability and contractual obligations.
So that's a thing that's important to discuss.
And, you know, the real question is, can manifestations sustain maintainers without implicating them?
And so I think here that one of the possible models towards which we could move is a model where there are professionalized maintainers for certain projects.
That operate maybe in something like maintainer pods that would focus on probably multiple projects, probably possibly tied to verticals or specific risk profiles.
And this is a model that is closer to some of the commercial offerings in that space.
So I think tied left or here it does.
And that is less tightly coupled with a specific project than the steroid bottle is.
And you can imagine lots of different sort of structures for this.
If we're profits, it could be nonprofits, something a bit like OSTF.
But more focused on maintenance, kind of maintainer cops, et cetera.
And I think that's mostly it.
Yes, lastly, I think this might not be a good fit for every kind of ecosystem.
But I think it's a model that would work quite well for ecosystems that are full of like very small projects like, for example, the JavaScript ecosystem.
And so in summary, yes.
So the CRA requires new diligence and vulnerability handling for all components including transit of dependencies.
Security attestations can help facilitate this.
There are three layers to security attestations if you think about it.
Public signals, private security information and sort of long term commitment to maintenance.
In my opinion, the greatest value ad for maintainers is in providing the long term maintenance.
So shielding maintainers away from personal liability requires professionalizing maintenance.
And then lastly, if you really want to create sustainability, you have to create value.
And to create value, you have to focus on manufacturing need.
And so the key really is starting from what manufacturers need and essentially providing maintenance for that.
Thank you very much, and you can see the slides.
Thanks, Debbie.