[00:00.000 --> 00:08.600]  Well, everybody, welcome, please, welcome, Kuki, our next speaker.
[00:08.600 --> 00:21.000]  Yes, I'm very happy last year, I also do the presentation, but it was online, so I'm
[00:21.000 --> 00:28.800]  very happy to see a real audience, hi, real ones, okay, so today I would like to talk
[00:28.800 --> 00:37.800]  about the SW360 features, so the title is Understanding and Managing the Dependency as One with the
[00:37.800 --> 00:44.800]  New Feature of SW360s, so I'm from Japan, so I'm a little dizzy because due to the jet
[00:44.800 --> 00:55.800]  lags, but so, okay, so I am a Koki Hammer, I'm a Toshiba Corporation, so my main task is
[00:55.800 --> 01:01.800]  to research the open source compliance and these tools and the management process, and
[01:01.800 --> 01:06.800]  so now I am a one with the leader of SW360 projects.
[01:06.800 --> 01:16.800]  Yeah, that's our today's contents, at first I would like to explain what is SW360, and so
[01:16.800 --> 01:24.800]  next I would like to explain the software dependencies, so unfortunately at this moment
[01:24.800 --> 01:34.800]  SW360 cannot manage the software dependency registration, so I solved these issues with
[01:34.800 --> 01:44.800]  my colleagues, and so now, but still have the problems, so this is one format not corresponding
[01:44.800 --> 01:54.800]  to the SW360s, so of course future works, SW360s need to be up improved for a popular
[01:54.800 --> 01:58.800]  SMM standards, okay, so let's start.
[01:58.800 --> 02:07.800]  At first, part is SW360s, as far as I remember, seven years or more ago one of the
[02:07.800 --> 02:20.800]  man, Michael Yeager, developed this, so a lot of people continue to commit a lot of
[02:20.800 --> 02:27.800]  source codes, now they can handle a lot of information related to the software inside
[02:27.800 --> 02:34.800]  your company, so for example, you can assemble in the security vulnerability or maintain the
[02:34.800 --> 02:41.800]  license and its obligations and some assist to generate the legal documents.
[02:41.800 --> 02:51.800]  Yeah, this is just an example, so now SW360 supports a lot of software component management
[02:51.800 --> 03:00.800]  activities, so this is an overview, of course your company has used a lot of software
[03:00.800 --> 03:08.800]  components, but so different product or project has different software components, so for
[03:08.800 --> 03:16.800]  example, if you use a component A, this component is used by product A, it's okay, but so for
[03:16.800 --> 03:24.800]  example, if you use a component C, product A or product B, both are used, so if you
[03:24.800 --> 03:30.800]  centralize this kind of data, you can reuse the information about the license or
[03:30.800 --> 03:40.800]  vulnerability, so centralizing the data is very important, so now maybe some company
[03:40.800 --> 03:48.800]  has a lot of system inside your company, for example, license scanner or artifact
[03:48.800 --> 03:55.800]  repository, so yeah, so they are all important, but so sometimes a lot of
[03:55.800 --> 04:03.800]  problems, for example, if your company don't have the unique naming rules, so they
[04:03.800 --> 04:12.800]  cannot exchange data easily, for solving this one, so centralizing mappings, so if you do
[04:12.800 --> 04:24.800]  so, you can input every data into SW360, so you can manage a lot of components in
[04:24.800 --> 04:38.800]  your company by SW360, yeah, so now this is a screenshot of the SW360, so at this moment
[04:38.800 --> 04:46.800]  software component or language or a lot of information you can register, and now so we
[04:46.800 --> 04:55.800]  update it and maybe within few months we can support the SPDX format and also we also
[04:55.800 --> 05:02.800]  plan to do the Cyclone DX related information on the roadmap, and some more information,
[05:02.800 --> 05:11.800]  so this screenshot is written in English, but now other languages is also used, and now
[05:11.800 --> 05:20.800]  English and Vietnamese and Japanese and maybe Chinese prerequisites exist, so you can use
[05:20.800 --> 05:26.800]  four languages, and if you want to add new languages, so we already prepare for the
[05:26.800 --> 05:34.800]  template and everyone can prerequest about the new language format, so in this case
[05:34.800 --> 05:46.800]  the SW360 handles more variety of languages, okay that's the next brain, so what is the
[05:46.800 --> 05:58.800]  SW360, so today's topic is software dependencies, so I summarized this chapter at first, so
[05:58.800 --> 06:04.800]  yeah, as you know software dependency information is a very huge and complex, but so sometimes
[06:04.800 --> 06:16.800]  it needs to be managed for license obligation or manage variabilities, yeah this is the example
[06:16.800 --> 06:22.800]  of the software dependencies map, so the software dependency of the project refer to the third
[06:22.800 --> 06:27.800]  party open source software that this project depend on, software dependencies can be direct
[06:27.800 --> 06:39.800]  or transitive, yeah so even if you register or manage the software dependency graph, some
[06:39.800 --> 06:47.800]  component version update it, so whenever some component update it, you also need to register
[06:47.800 --> 06:56.800]  this kind of data, this is also one of the reason why you cannot manage the software
[06:56.800 --> 07:07.800]  graph easily, yeah so this is a real example for if you project is a grant of this one,
[07:07.800 --> 07:17.800]  so this is the other software component, so that's this is an example, yeah in the real
[07:17.800 --> 07:32.800]  maybe you use a lot of software and you need to manage like this graph, so why you need
[07:32.800 --> 07:38.800]  to register or manage the software component dependencies, one reason is the license
[07:38.800 --> 07:46.800]  manages, so different component have different licenses and of course you need to follow these
[07:46.800 --> 07:54.800]  obligations, so yeah this of course right away or following the license obligation is the most
[07:54.800 --> 08:03.800]  important things for open source users, yeah so we need to track them, on the other hand
[08:03.800 --> 08:14.800]  vulnerability is also important, so if you use the one software, but so this is a deep
[08:14.800 --> 08:23.800]  insider as component graphs, you may not find this vulnerability easily, but so this is a
[08:23.800 --> 08:36.800]  very sometimes important risks for your management component, yeah so that's either or why manage
[08:36.800 --> 08:44.800]  software component dependencies are important, yeah so taking the proper dependency or updating
[08:44.800 --> 08:50.800]  outdated dependencies or solving risk of dependencies, all you need to do for the
[08:50.800 --> 09:01.800]  your products of component, yeah that's a background, so but unfortunately so traditional
[09:02.800 --> 09:12.800]  software component catalog application is W360 cannot handle this situation, so I would like to
[09:12.800 --> 09:21.800]  explain this one, so this at this moment is that the word W360 can register only one
[09:21.800 --> 09:27.800]  software dependency information, this means different dependencies cannot be registered
[09:27.800 --> 09:39.800]  for the different projects, so this is the architecture of the W360, so for example if
[09:39.800 --> 09:47.800]  you are project X use the component SW360 then you link the release, release means the
[09:47.800 --> 10:02.800]  version, so and so this release also use the other releases in the components, so yeah now you
[10:02.800 --> 10:11.800]  can register it, the dependency of a project, if you want to register this project for example one,
[10:12.800 --> 10:22.800]  so you can link the like this project, example one have the mini match and this is linked to the
[10:22.800 --> 10:33.800]  brass expansions on the like to this, so this is looks like it's okay, but it's not a good way
[10:34.800 --> 10:44.800]  in real SW360, yeah so this is a screenshot of the real interface of the SW360, yeah so you can
[10:44.800 --> 10:57.800]  register this project and you can also register dependencies, yeah it's so but so unfortunately
[10:57.800 --> 11:08.800]  this is not perfect because if other project want to register other information with different
[11:08.800 --> 11:22.800]  dependencies it is impossible to manage this information by current SW360s, yeah so like
[11:22.800 --> 11:33.800]  these graphs of course different component have link to be a different component and the company
[11:33.800 --> 11:45.800]  manage all the information for each project, but so now it is impossible, ideally we need to
[11:45.800 --> 11:53.800]  project information what these dependencies like this, so if you register mini match with these
[11:53.800 --> 12:00.800]  dependencies it's okay, so another project also need to do the same things but different versions,
[12:01.800 --> 12:16.800]  so at this moments of course if you someone already registered their dependencies as a project member
[12:16.800 --> 12:25.800]  cannot register new dependencies and so yeah if you force to change in the links information are with
[12:25.800 --> 12:33.800]  the admin writer, as the redirect also change their dependency information, this means first project
[12:33.800 --> 12:46.800]  information are not correct, so for solving these problems and my colleagues and a lot of SW360
[12:46.800 --> 12:58.800]  community people solve these problems, yeah for solving one we change the data architecture
[12:58.800 --> 13:08.800]  and GUI, yeah of course important function I plan to be full request soon and but if you want to
[13:08.800 --> 13:16.800]  challenge or try to this function or this update it you can go to this branch and if you
[13:16.800 --> 13:30.800]  built this source course you can do it, so our idea how to solve the problem is a project,
[13:31.800 --> 13:39.800]  different project has a different dependency graphs, so all the specification has only one
[13:39.800 --> 13:47.800]  dependency graph, so but new specification different project has a different dependency graphs,
[13:47.800 --> 13:58.800]  yeah of course for this for realizing this specification we need to change the GUI,
[13:58.800 --> 14:10.800]  so all the one if you set the links you can find only one thing but so as new specifications
[14:10.800 --> 14:25.800]  GUI you can set the links for releases, yeah source this is the real GUI and so the current
[14:25.800 --> 14:35.800]  new one, new branch you can do the you can find this kind of GUI for register the dependency
[14:36.800 --> 14:45.800]  graph on the SW360, yeah for example you can select the versions or delete this kind of
[14:45.800 --> 14:59.800]  information, yeah like this kind a lot of assistance for managing this one, yeah so basically
[14:59.800 --> 15:07.800]  the release page on the SW360 it's not changed from the old one so the dependency information
[15:07.800 --> 15:12.800]  here will be seen as the price starting the default information it will keep the same
[15:12.800 --> 15:22.800]  with the latest information in the ecosystem, yeah this is the view page of the dependencies
[15:22.800 --> 15:30.800]  so each dependency graph can be committed so it's a difficult to change but if you see
[15:30.800 --> 15:40.800]  this screen in detail you can find the differences so especially a race expansion has different
[15:40.800 --> 15:53.800]  versions, yeah so of course editing page is also changed as this page is for using the
[15:53.800 --> 16:07.800]  when register the new information for your project on your company's SW360, okay so this
[16:07.800 --> 16:18.800]  is a solution for the buy and how to deal with dependency graphs on the SW360 and so I need
[16:18.800 --> 16:27.800]  to mention the SM standards from our dependency, defined dependencies because SW360 is of course
[16:27.800 --> 16:34.800]  using for your company's source code management or component management but so it's needed
[16:34.800 --> 16:48.800]  to be corresponding with common SM standards, yeah so SM standards like a common SM format
[16:48.800 --> 16:59.800]  also defines some dependencies and they support or describes how to register the dependency
[16:59.800 --> 17:11.800]  in your project, for example I can find the SPDX paper types so they handle the element
[17:11.800 --> 17:20.800]  and so by this kind of relationships we can handle the dependencies linked which software
[17:20.800 --> 17:32.800]  depends on which other source whereas and so I can find the dependency in the cycle of
[17:32.800 --> 17:39.800]  DX based on the package you were right so they manage some dependency graphs in their
[17:40.800 --> 17:52.800]  formats, yeah so from now I would like to explain the future work for the SW standards, I have already
[17:52.800 --> 18:06.800]  explained how to update it SW360 for the dependency graphs but still have the problems SW360 definition
[18:06.800 --> 18:16.800]  of the dependencies are very unique and they are not same with both SPDX or Cyclone DX, yeah it's a
[18:16.800 --> 18:31.800]  problems for corresponding with common SM formats SW360 should be updated again so I think this is one
[18:31.800 --> 18:41.800]  of the most important future tasks about this function, okay I would like to summarize today's
[18:41.800 --> 18:49.800]  presentation SW360 can manage the internal software information and the registration of
[18:49.800 --> 18:56.800]  dependencies important for licensed security management, registration of dependency information
[18:56.800 --> 19:04.800]  software in SW360 was not flexible however we developed a new function to register different
[19:04.800 --> 19:10.800]  dependency information for each project to be registered so definition of relevance between
[19:10.800 --> 19:18.800]  software is unique to SW360 so we need to follow the SPDX or Cyclone DX so in the future it will be
[19:18.800 --> 19:26.800]  adapted to the common SM definitions, okay that's all thank you
[19:49.800 --> 20:03.800]  Yes, so you asked about whether SW360 can or dependency or not, no
[20:04.800 --> 20:08.800]  Can SW360 also read the dependency information?
[20:08.800 --> 20:17.800]  Ah no so for reading or analyzing the dependencies need to use other series like our old maybe, yeah
[20:20.800 --> 20:21.800]  Hi
[20:21.800 --> 20:24.800]  So your tool is consuming what type of S-bombs?
[20:28.800 --> 20:30.800]  Sourcing build
[20:30.800 --> 20:32.800]  Sourcing build?
[20:35.800 --> 20:44.800]  SW360 defines these kinds of types, every kind of build information can register, yeah so
[20:46.800 --> 20:55.800]  if user want to register based on the source build they can do register it so but if other SW360
[20:55.800 --> 21:03.800]  user want to do register as their related system they can do it, yeah
[21:03.800 --> 21:05.800]  So build of bonsai, yeah
[21:05.800 --> 21:11.800]  The relationships that you said that are not in both of them, which one is closest?
[21:11.800 --> 21:19.800]  Like when you had that slide with the relationships not matching, some of those relationships I think are pretty clear in
[21:19.800 --> 21:23.800]  SPDX but I'm trying to figure out which ones you think are the gaps
[21:23.800 --> 21:33.800]  Ah yeah so I think SW360 developer defines this one
[21:33.800 --> 21:43.800]  I think SPDX, no one tried to correspond to the SPDX one so very similar to the SPDX relationships
[21:43.800 --> 21:46.800]  So I'm just trying to tell you about an X there
[21:46.800 --> 21:53.800]  Yeah that's right, yeah, SW360 side needed to update it to SPDX
[21:53.800 --> 22:01.800]  Okay, I'm just trying to say along those ones are relationships already but if there's something that you're missing please open an issue in SPDX
[22:01.800 --> 22:03.800]  Ah, okay, thank you
[22:03.800 --> 22:12.800]  Is there also some information available about where the package is used like a test development of a test library or a dev dependency
[22:12.800 --> 22:22.800]  Because for certain things, for a large number of years you might have to exclude dev dependencies from a product
[22:22.800 --> 22:27.800]  Is there also somewhere a catch up where a dependency is used in the build process?
[22:27.800 --> 22:32.800]  From now I would like to do so, I need to catch up so
[22:33.800 --> 22:35.800]  So what's the
[22:35.800 --> 22:45.800]  So ORT has an integration called SW360, so ORT will detect from the package managers what are a test scope
[22:45.800 --> 22:51.800]  Now we call the API of SW360 and the internal build tools get marked by internal use
[22:51.800 --> 22:55.800]  So basically that's how ORT works together with SW360
[22:55.800 --> 23:04.800]  The integration from ORT to SW360 we translate everything from the internal use relationship that is in SW360
[23:04.800 --> 23:12.800]  But you need to have an other tool to get that information and from the website we do this translation
[23:12.800 --> 23:19.800]  And I can continue with the answer that yes we are in the middle of doing a refactoring to make the dev fully compliant
[23:19.800 --> 23:24.800]  And this will be integrated on future versions, I don't know which one but
[23:29.800 --> 23:35.800]  The question is what kind of information you really would like to have in SW360
[23:35.800 --> 23:40.800]  SW360 should be able to support all the different points of view
[23:40.800 --> 23:44.800]  We would say we don't want to have the dev dependencies
[23:44.800 --> 23:51.800]  So as Thomas already explained we would sort them out in the scanner that creates the original Aspom
[23:51.800 --> 23:58.800]  And their work is to import an existing Aspom and to map it to a specific system
[23:58.800 --> 24:07.800]  Yeah but in some cases you do want to have the dev dependencies where you want to use an Aspom for operational disks or whatever
[24:07.800 --> 24:17.800]  But we are very confused with which use Aspom and I don't want to store Aspom so we want to put it in 8th and 2nd
[24:17.800 --> 24:26.800]  I totally agree and as Thomas explained you have different kind of tags or meta information that you can apply to
[24:26.800 --> 24:29.800]  to releases or to components unless they are with its view
[24:29.800 --> 24:32.800]  So this would allow you that kind of map
[24:33.800 --> 24:37.800]  I wonder whether that's identifying a new type of Aspom then
[24:37.800 --> 24:44.800]  Because it sits between the build and the analyse
[24:44.800 --> 24:53.800]  It can actually, there must be, you might have new tools that you want to use purely internally to demonstrate the quality
[24:53.800 --> 24:56.800]  But actually not deliver to your end user
[24:56.800 --> 24:59.800]  So is there a gap there?
[24:59.800 --> 25:02.800]  It's not really so
[25:02.800 --> 25:07.800]  We do it in port, we store it in one Aspom for the source code
[25:07.800 --> 25:09.800]  It's the complete corresponding source code
[25:09.800 --> 25:15.800]  And then I have another Aspom for the build Aspom that I build from the source code
[25:15.800 --> 25:17.800]  And that's
[25:28.800 --> 25:31.800]  Subset has been extracted to actually make the image
[25:31.800 --> 25:36.800]  But yeah, I can think of when you test you may have different compile options to include debug or not debug
[25:36.800 --> 25:42.800]  This is a very simple example and actually you need to know whether you've got that in your deployed
[25:42.800 --> 25:43.800]  Exactly
[25:43.800 --> 25:49.800]  And so that's where the build Aspom will potentially refer to the source Aspoms
[25:49.800 --> 25:53.800]  Or to other pieces so you can get the details
[25:53.800 --> 25:56.800]  We're going to have a slight schedule change
[25:56.800 --> 26:01.800]  The Octo1 is going to be switched with Yon Simone's as the next one
[26:01.800 --> 26:04.800]  But in the Octo they're doing that today
[26:04.800 --> 26:11.800]  And so I think the Octo1 example will probably clarify how we're linking these Aspoms together in some places
[26:12.800 --> 26:13.800]  Thank you
[26:13.800 --> 26:15.800]  Any more questions? We have time still?
[26:15.800 --> 26:16.800]  Yeah, three minutes
[26:16.800 --> 26:17.800]  Three minutes, okay
[26:17.800 --> 26:18.800]  Well, we have to switch
[26:18.800 --> 26:19.800]  Okay
[26:29.800 --> 26:31.800]  Can it import as PDX already?
[26:31.800 --> 26:33.800]  I thought you could do for X now
[26:33.800 --> 26:36.800]  Ah, so now make it
[26:36.800 --> 26:38.800]  When?
[26:38.800 --> 26:42.800]  When do you actually merge the batch that was waiting for it?
[26:42.800 --> 26:44.800]  Ah, yes, as he mentioned
[26:44.800 --> 26:46.800]  I already prepared the prerequisites
[26:46.800 --> 26:49.800]  But as a community member, reviewing it
[26:49.800 --> 26:51.800]  Let's do a review of that
[26:51.800 --> 26:58.800]  So after the reviews, we can manage the PDX import, export and editings on the Sable360
[26:58.800 --> 27:00.800]  So unfortunately at this moment we cannot
[27:00.800 --> 27:03.800]  But yeah, of course we already prepared the prerequisites
[27:03.800 --> 27:08.800]  If you go to my company's branch, you can try it
[27:08.800 --> 27:09.800]  Okay
[27:09.800 --> 27:14.800]  We missed the 17 release, but I hope we can do it
[27:14.800 --> 27:21.800]  Yes, yeah, within, I hope within a few weeks everybody can do it
[27:24.800 --> 27:26.800]  Thank you very much
[27:26.800 --> 27:28.800]  Thank you
[27:33.800 --> 27:36.800]  You