Okay, so next up we have a panel of Danone and Jeff here.
So we're going to be discussing best practices around S-Bornman supply chain.
So my idea initially, and if anybody has questions or whatever, feel free to jump in.
So just maybe questions at the end.
Would be maybe break this into three sections.
So the first one would be around what you think is best practice or
challenge about S-Born generation, sharing and gaining gestion, and
then basically handling them, storage, all of that.
So yeah, without further, I'll give the pass them back to you.
And then if you want to introduce yourself and Jeff.
Yeah, hi everyone.
I guess most of the faces are familiar from the fringe event from last week.
So yeah, hello again.
And I'm Aaron Arrogation.
I work for Siemens Health Nears.
I had the Secure Development and Compliance at the organizational level and
also a co-lead of software 360 project at Hosea-Rite Eclipse Foundation.
So the topic of S-Born has kind of,
we all know that has came up into the limelight in the last one year or so.
So it has had its effect in our workspace also.
I was only needed to concentrate on license complaints until recently, but
now the whole thing has changed and the requirements has come up in a much more
stricter way because of the regulation and the executive order.
And so predominantly from my side, being a healthcare organization,
we have a lot of challenges in adapting to or
catering to this requirement in a very sudden way.
Because this new regulation calls for a very stringent or
very disruptive way of changing things.
And it is very challenging in the healthcare sector because our processes
are very closely tied to the FDA regulations and our relationship with
our supply chain is quite sensitive.
Because we cannot suddenly demand our suppliers to give this thing,
otherwise you would be out of the process.
That cannot be done.
So we have to operate in, since it is healthcare,
I can take the example of doing a surgery.
We have to keep the patient alive and then do the work.
So that is the situation right now.
And we are taking it that seriously and taking the steps very clearly because
right now what we are doing mostly is identifying the current challenges and
gaps in the process.
And evaluating our existing methods of how we are meeting the regulations.
Declaring all the elements of open source usage was already there, but
it existed in different formats.
But now when the regulation demands a particular or a set of few formats,
there has to be a lot of work done in all areas like right from the R&D processes,
the contracts with the suppliers, all of these things.
And then we have the legal aspect also.
So the current challenges, the inability for
a large organization which is heavily regulated to transition at a fast pace,
is a major challenge.
But we are closely monitoring the developments and
trying to go along with the community in that.
And the one core strategy that we have right now is make sure that we don't
miss a train in this aspect.
But it's a challenging thing.
I'll come back to that more details after.
Hi everyone, I'm Jeff Mendoza.
I'm a maintainer on the GWAC project.
GWAC is an incubating project under the open source security foundation.
And it's a tool that ingests S-bombs and then is used for querying your S-bombs.
I can get more into it later, but as far as the S-bom management,
the idea is that we need to be able to ask questions about our S-bombs.
And so that's the kind of the part I focus on.
Some other background for me personally, I used to work at the open source programs
office at Microsoft where I worked on security and license compliance where we
would have scanners that didn't generate S-bombs.
We had an internal format, but it would scan,
put the results, all the component versions into a database and
then give you security and legal alerts based on that.
So I can kind of pull from that experience as well for
best practices and managing S-bombs even though we didn't call them S-bombs.
So one question for you, Anun.
So when you think about healthcare as a heavily regulated industry,
so when you think you as a participant that is using software from third parties,
the suppliers in this case.
So how developed is healthcare in regarding this kind of information?
How transparent is it supply chain?
Do your providers reliably get you information that you need to
form to understand your dependencies all of that?
Could you share a few words on that?
So until recently, getting the entire dependency list was more of a manual
centric process where all the architects were heavily loaded with this task.
And with the internal process of software,
the software lifecycle management, it was very much engraved in that process.
And hence it was like, yeah, we had to believe the person, okay, I'm the architect,
I decide that, okay, this is going to be our function and this things we need.
So for a longer time until automation kicked in,
we all believed that that was the truth and we had only a certain number of components.
And we did all the required clearings, whether it is from a compliance aspect or
from a security aspect to that.
So the moment when it transitioned to package managed world where we started
ingesting third party packages through the modern package managers,
the situation kind of changed.
So people were so alarmed with the number of dependencies that they see.
And then there was a surprise for these architects or those people.
Like, are we really using these many components?
It could be false positives.
Are you sure?
Is your tool working right?
So this was the discussion at some point.
So as I said earlier, because it is a regulated one,
for all the listed components, there are existing process where they validated,
they evaluated for security and license complaints.
But now that task has scaled up to an unimaginable extent.
So we are trying to figure it out.
And I guess, well, when you think about the problem of handling those dependencies,
that's where Guac comes in.
Like, it's one of those tools that will let you ingest everything and
try to understand their relationships between them.
So we just heard a number of talks about trusting.
And so at some point, well, I would like to understand also how sharing and
trust go together.
I'm not sure that Guac currently feels that, but
I'm not sure if you have overviews on how more visibility into those,
that information can lead to better trust.
I don't know about trust, but I do feel like when you're cataloging your S-bombs and
have all of the dependency information in them.
And if you're scanning through all of them and
looking for vulnerabilities or legal information, it becomes important to see
where you're using the same dependency across all of your projects.
And so if you're looking at individual S-bombs, you won't see that.
You'll just see, okay, I get the same vulnerability coming up in all these
different products that I have.
So one thing that correlating those, just part of what Guac does is,
you can see where, well, what is the path to get to the vulnerability from my products?
Does one product depend on another?
And that's why I have this showing up in multiple ones.
Is that kind of what you're getting at with kind of by looking at
how the different S-bombs all point to the same project,
you can get a lot more insights into both what you should be trusting,
what you want to look at and what you should be concerned about.
Yeah, so what I'm thinking is when you have a large body of
dependency data like some organizations like the health care industry has,
then you can start using tools like Guac and other databases to start understanding
basically who's telling you the truth, who's lying a little bit,
who's giving you missing information.
And you can start making sure that the players are doing the right job.
So that should give you a good overview on the state and ultimately making that information useful.
So I'm, well, just to switch tracks a little bit.
So I'm curious, how does the health care industry share information?
Like how do you share S-bombs?
What's the practice when you have an S-bomb?
How do you give it?
How do you receive it?
How do you supply it to others?
Okay.
So that's a very tricky question to answer at this point of time.
So how to put it?
Email is fine.
Yeah, I mean, I can say like we have not started supplying S-bombs in the current prescribed
formats yet, but the other various ways of submitting this information to FD is already
in process.
So I'm not going to talk about what format or the thing, but this information is being
submitted, but it is not as per the prescribed formats as PDX or Cyclone DX.
We are only reaching there right now.
So just to continue with what he mentioned regarding like, this brings me to the software
360 part of it, like how we catalog this applications.
So the real challenge for us is, you know, we have legacy systems, which are still 15,
20 years old and still part of machines running across different hospitals.
So we still have to maintain it.
And now we have a new set of software coming in new form, which are part of the modern
applications when compared to our old and scanners and other tools.
So right now, all the teams that were working in this area in terms of compliance or security,
we have the challenge of bridging this gap where we have to hold both sides equally well
and then think of a solution where we can cater or where we can adhere to this new regulation.
Because for us, the major challenge is when we deal with the legacy systems because it's
like some part of it is already, you know, submitted to the regulators.
We cannot really make heavy changes to that.
So that's the tricky part.
And software 360 is kind of helping in that way.
But making it adaptable to the modern world is a challenge.
So still there is going to be a certain level of manual work along with the automation to
meet the goals.
Do those applications get run under some SCA system to break them and then handle them,
catalog them properly in software 360?
Yeah, we do use multiple tools.
We do use multiple toolings right now, like a lot of tools from the Cyclone, the X-Center.
And most of it, I would say, majority is all internally developed because of various reasons.
Or, you know, we might not have felt that the available one in the open source world
is fitting our requirements.
So a mix of both, but dominated by internal SCA tools.
Any question for you?
When do you run your scanning tools, your S-Bump generators at source area time,
build time, or deployment time?
So it depends on based on the current thing is like the focus is on license complaints
and security.
So earlier the SCA was specifically for the security and then separate team taking care
of it.
And they maintain the vulnerable database and then we link to the software 360.
So right now it is changing like for the modern software is where they use the modern package
managers.
It is run and build time.
And then it is a process downstream.
Yeah, in my experience as well, scanning at build time is absolutely required.
It's completely different building an S-Bomb from a source repository where you're either
parsing a manifest or maybe doing a simulation of a manifest install or at deployment time
when you don't have all of those artifacts that may go away after the build is done.
So yeah, at Microsoft we only scanned at build time.
Kind of a proposal for the group and a question, should we be cataloging or categorizing S-Bombs
for what time they were built?
Like is that something when we have a database and we want to query them or look up something,
that would be an important metadata to attach, right?
But when you query or as a user, as a consumer, I want to know that, right?
As a consumer, especially for the medical side, what do you need to see for support windows
and what do you want to see recorded for support windows?
Yeah, I'm just repeating a question so that I can, so from a consumer side, like what
do we want to see in the S-Bomb?
Or as a producer of a device, what do you want to be able to share out, especially with
the CRA coming in, okay, in terms of your support windows?
And in either format I think you have support right now.
I think properly, fully.
And so the question is, do you have guidance on things that you're trying to get together
for?
You see that?
Yeah.
Because I wrote some of the tools they are using, why do we have our own tools?
Because most of the tools, for example, from the excitement providers, all the information
that you would need for licensing.
Right.
So we look for, where do we find the source code?
What are potential or existing information of the licenses?
Are there no displays or whatever?
And again, most of the existing tools, you will have to repeat it.
Yeah.
So just, most of the existing tools do not provide all the necessary information that
you would need for license compliance or to have a real complete S-Bomb.
And this is still an issue because this requires that you use different tools, that you then
manually adapt data, and then we come to the point, Jeff, what you mentioned, yeah, we
create the S-Bomb during CI, but later we store it in SW-16.
Most probably we have to add or modify some information because you were lacking at the
beginning.
Yeah, and regarding the submissions to the FDA part, you know, as far as I know, even
the recent submissions, like not in the current format, but FDA says, yeah, things are okay
with it.
But, you know, I think one thing I heard is when a machine readable format was shared,
FDA was not able to process it.
So they asked for a human readable version of it.
That's an insider story that was there.
FDA will do the conversion from SPDX to Excel.
Okay.
Yeah.
So, I mean, adding on to what Thomas mentioned, yes, regarding because the priority in our
organization, you know, first comes for the license compliance and then shared with security.
So, yeah.
And the missing information is not just common across all packages, but maybe very few.
But I think in the last six months, we have seen a great improvement in terms of, say,
for example, NPMR, you get this kind of sorted out, like we get almost 90% information at
the time, but others are a little bit challenging.
Yeah.
What do you get?
Yeah.
You know what Carol, you got this in there?
I mean, like we are comparing it with much more olden times.
So we feel better.
It might not be the best, but yeah.
All right.
I have another topic, but if people have questions, we have like five minutes left.
Yeah.
I'm going to know how to solve the problem of verification and verification of the SBOM.
Like I said, a bit better, right?
So, you will offer a person SBOM, you will see it and trust the developer right.
But how do you know that what the developer provides for us?
Yeah.
I'll repeat the question.
Like, so your question is how do we verify and validate the SBOM that we receive from
the developer?
The short answer is trust.
I mean, at this point of time.
Yeah.
And because it's mostly on the tools that we have implemented.
And then, you know, I think so far that is what's been done, but there is no formal validation
that we do on SBOM because we have not thoroughly started processing automated SBOMs in its
complete sense because things are here and there partially.
So it's like there is still manual intervention in between happening.
Yeah.
I'll add to that.
If you're consuming open source and you're getting an SBOM, you don't need to, you know,
you need to build your own SBOM.
Like if for anything that's open source, you should be able to fully create an SBOM based
on how you're using that library and the dependencies that you're pulling in at that time.
If it's a library and they're saying I depend on these other libraries, that's just kind
of theoretical, right?
So yeah, if you're using open source and you're getting SBOMs, just build your own.
There's some, I found about quite a few projects on Friday that people are talking about maybe
in the software heritage for public databases of these dependency information for open source.
So we should be able to get the right kind of dependency graphs for open source without
trusting somebody, an SBOM that somebody else built.
So we need better verification.
So as coming from automotive industry, how we validate it, I take your SBOM, I do the
language, I re-implement the mini project, take all of your dependencies, run it again.
If I then get dependency conflicts, I know, boom, we have already a problem.
Then I run it to, in our case, OSSRDUKIT, which Marcel spoke about, where the entire
database was to basically download all of the source code of all of the code again to
check all of the licenses.
But my standard first check is to take your dependency list.
I generate for that whatever ecosystem is, Maven, Java, and run it again.
If that already gives me a conflict, then I know, why do we have a problem?
And then I will go back to the supplier and say, like, we cannot compile this.
How the hell did you compile these versions of the code?
How did you compile these branches into a product?
But again, validation is very difficult.
So the other rule what you do is we do a risk-based approach.
You cannot do this manual check for everything.
So I run the SBOMs to some special rules that I wrote in ORT, where it's policy is code,
and then I filter out.
These are the products that in my context are high-risk products.
You know, the motive it means updating a car.
In case you don't know, over the air updates from cars doesn't work.
If you need to fix some of the cars, you need to recall the car to the garage.
That means millions of euros, dollars, and yen that need to be spent.
Those get checked in depth.
Anything else we do?
So we have a risk-based approach to validating SBOMs because consuming SBOMs is still a
sanely pain in the butt in the ass.
And you should add, because train your developers.
Train your developers.
Train your developers in Mesh.
No, because the emphasis is on the beach.
You know, right here in the modern world, I think I'm talking about different tracks,
different formats.
Even if you're good at building the locker, you can actually do a good job and feel accessible
about these three topics.
Sometimes it's just hard to do that right.
So maybe try to be the best, provide the best bonds.
And you have trust in yourself that you don't have any social rights.
And it's just a lack of your knowledge or communication that could be compromised.
Yeah, to summarize, developers don't have the proper tools.
So it should be better to just provide the...
So what I'm hearing is that maybe the SBOM community needs to get together and piece
together a verification story.
Like I should need to go and reveal the software.
I should just take that document through some mechanism and verify that it's actually
true.
Yeah.
Maybe we have time for one more question.
Any closing thoughts?
Yeah.
Yeah.
I mean, just to summarize, after observing all these developments that are going on,
all these discussions, I think from a healthcare perspective, we are going to take a very cautious
step towards it.
Because since we know this is quite a disruptive change, and also it is a mandatory change
that we need to do.
So our approach would be very cautious.
But we want to be equally close to the community and very close to the developments that happen
so that we would be able to adapt the changes in a fast-paced manner than when compared
to three, four years back.
Yeah.
I mean, I think what I already said is like, yeah, set a high standard for generating SBOMs,
do the build time, catalog your SBOMs, and then try to drive insights and relationships
between where you're seeing commonalities between all your products.
Thank you, everyone.
Thank you.
Thanks.
Thanks.
Thanks.
Thanks.