Thank you for allowing me to come here, the organizers.
I am almost new to the S1 community out here.
My name is Sal Nielsen.
I am part of something called the SEPA security working group.
We work on supply chain stuff and security on the oldest open source software repository
system out there.
It started in 1995 with lots and lots of...
Let's see if we can switch the slides here.
There we are.
And I am here with software and all that implies with developers publishing there and downstream
in Debian and Redats and all the systems out there being used all over the world.
And like 14,000 developers still, more than 14,000 packages.
So it's a real system.
It's out there, it's working and people are earning a lot of money on this stuff so they
want to keep it going.
And now we are having a new reality coming with legislation.
So I am trying to today bring the open source supply chain perspective.
This is recently finished slides so please excuse me if I am either finished early or
late I will try to do my best to make you happy.
So I talked to a bunch of the people who are involved in the middle parts of this chain
of events.
They often say why should I care about this stuff?
We already do a key track of dependencies on that one.
We have the new formats and this is not my problem.
If you pay me maybe we can talk.
This is actually, this is paraphrasing but the essence of the discussions are like some
of the blog posts are like I am not your supplier.
It's actually like that out there.
As I can confirm that notion.
Then reality arrives and end users or use all the software are obliged by the threat
of fines to keep track of all the dependencies and what is happening with them so that we
can't get all those horrible security situations going on.
That means they need authority and up to date information from the utmost upstream sources.
And to do that you actually have to have the supply chain bits and pieces and steps play
along in this game so that we can get all the good stuff.
Like figure out where stuff comes from, check it up against very built-in databases and
all that good stuff.
We like that.
So I am researching, looking around what the documentation tried to learn, this whole
S-bound thing, reading documents from the US government and all kinds of interesting
organizations like many of you probably have done.
Very interesting stuff.
Then I find this thing.
This is from my nice tea.
They tried to describe where I spawned the show in, show up and there's something wrong
there.
There's no supply chain mentioned at all in there.
It says third party software enters here and there's no open source or processes or communities
or anything.
It seems almost like there's a lot of, this is a pattern, it seems a lot of documentation
and even in some of the standards it's just assumed there's something going on here.
And well, it isn't.
There's stuff going on.
And I would like you to just get a little picture of what's going on there to draw a
simplified supply chain.
We have an author at the top who does stuff, publishes something.
There's a language ecosystem they publish on.
They also collaborate with others on a collaboration platform.
So the language ecosystem would be the PIPIs or the NPMs or the C-Pants collaboration
ecosystem would be the GitOps and GitLabs and all that stuff.
And they are sources for downstream package.
Oops, sorry.
There we have it.
So that one, the red one, that's where I come from.
That's the C-Pan and then PIMS.
And we care about the infrastructure and how that happens and making sure that only the
right people get to upload software and that it's published and available and all that
good stuff.
But the downstream of us, we have a packaging ecosystems.
These folks here, that's the Debian and the Red Hats and all kinds of places that compile
stuff for their own environment and make sure it's available in a consistent and available
manner.
But they also feed into themselves.
Like downstream of Debian you find Ubuntu.
And sometimes the packages here are patched because of upstream availability or you have
to back port security fixes.
And there's a package there that sometimes I have to talk with a curator about which of
the software pipelines you should publish one package.
Because some of them are LTS pipelines.
You don't want to do stuff there that you can do in another one.
And then of course you have to make it all available so that the developers, some business
can do their work and all that magic so that it can put to something production environment
and make people happy.
All these boxes here, I try to make it so that there are boxes that represent a role
that cares about something that is supposed to be in an S-bomb file.
I'll try to be quick.
So these bits here, that's actually this one except for that the third-party software
arrow here, the tiny little grey one there is doing some seriously heavy lifting.
That needs to stop, seriously.
And there's another one, second-party software.
We are not third-party software doing this.
We're second-party.
We're partners.
When people say we can get third-party software from open source, no, we get second-party.
When you accept a license, you're actually getting a partner, someone you are supposed
to cooperate with.
Most people don't but they're still there and expected and you need to know about that
and people who make decision management, they have to know about this.
That means anyone who writes documentation and teaches this kind of stuff needs to stop
calling open source as a third-party source of software.
That's just insane.
Second-party software means people like these actual people working on infrastructure out
there get ignored, basically.
And that's not a good way to get the inclusion and the support from that software supply
chain people and the ecosystem that you actually depend on.
So, okay, who are these people?
They're, in fact, your open source colleagues.
In fact, they are your unpaid open source colleagues.
Just so you know that.
So stop treating them as a stranger, start treating them as a colleague, talk with them,
interact with them, teach them and learn from them as usual colleagues do in a healthy
environment.
Of course, if you don't have any healthy environment at work, maybe your work should
go do something else or quit or something.
So to make S-Bomb become first-class citizens in open source ecosystem, make open source
ecosystem first-class citizens in the S-Bomb community.
Please do that.
Don't just put them behind a miniscule with one pixel wide arrow that says third-party
software enters here.
That's just so bad and wrong.
It's horrible.
So there we have that.
And don't, yeah, they are your partners.
Please, it's a good thing to have them on your team, even if they're living somewhere
and you don't pay them.
They're competent people and they actually do want to help you.
Like if you've treated them badly, they'll just say, this is your problem and see if
you can fix it.
No, you can't.
And in a way, if you want something happened with somebody you don't have a monetary relationship
with, you have to treat them as friends and with respect and help them if they have a
problem and communicate and stuff.
And this is the good way to operate if you want to have a supply chain in on the S-Bomb
game.
So I hope this is a message that you can find useful and adopt in your work in years to
come.
Thank you.
If you have any questions, maybe we'll have a room for one or two.
One question?
I've been involved in some of the groups that produce the thing that we should show them.
I think there may be a miscommunication between them because that third-party perspective,
it wasn't planned to offend anyone.
Anybody can be a third-party when you're developing, right?
So I think it's just not you.
But in fact, some of the work that some of the work that they're doing has been, you
know, approaching those language communities and helping them build their, for example,
involved with the BIPA Foundation and their efforts to create their own S-Bomb.
So I think if it's a miscommunication, then we just need to sit down and talk a little
bit more.
There might be a miscommunication, of course.
You'll have to repeat that.
Yes, there's a long comment here.
There might be miscommunications out there.
And of course, my perspective comes from one community.
All the communities who might be more resourceful, like the Python community, are easier and
don't feel that it's, of course, not meant as an insult.
And of course it is.
But I think my point still stands that by treating open-source communities as partners,
you get all the benefits, even if it's a small community like mine or a big one.
So I think, thank you for your comment.
I'll still mean what I mean.
You haven't changed my mind.
Thank you very much.
Okay, that was it.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.