WEBVTT 00:00.000 --> 00:06.000 Okay, I think we're good. 00:06.000 --> 00:08.000 Okay, hi everyone. 00:08.000 --> 00:13.000 Welcome to our presentation, enhancing swift supply chain security, 00:13.000 --> 00:16.000 build time S bomb generation and swift package manager. 00:16.000 --> 00:18.000 We'll start with some introductions. 00:18.000 --> 00:19.000 My name is Ed. 00:19.000 --> 00:24.000 I'm a software engineer at Apple focused on software supply chain security. 00:24.000 --> 00:27.000 And I'm based in Seattle, Washington, in the United States. 00:28.000 --> 00:30.000 Hi, I'm Sam. 00:30.000 --> 00:32.000 I'm a software developer at Apple. 00:32.000 --> 00:35.000 And I'm work on swift package manager and core builds. 00:35.000 --> 00:37.000 I'm based in Ottawa, Canada. 00:37.000 --> 00:39.000 Okay. 00:39.000 --> 00:42.000 In this presentation, we'll discuss the role of S bombs 00:42.000 --> 00:46.000 in securing swift supply chain and explain why it's hard to create swift 00:46.000 --> 00:48.000 S bombs with existing tools. 00:48.000 --> 00:51.000 We'll provide a brief demo of our upcoming future 00:51.000 --> 00:55.000 by integrates S bomb generation into swift PM to create swift S bombs. 00:55.000 --> 00:58.000 And we'll detail some channels where you can provide feedback 00:58.000 --> 01:00.000 before the features released. 01:00.000 --> 01:03.000 Sam is going to get us started by talking about swift and swift 01:03.000 --> 01:07.000 PM fundamentals, which will provide the necessary back on concepts 01:07.000 --> 01:11.000 that are crucial for understanding the independent S bomb feature. 01:11.000 --> 01:13.000 Thanks, Ed. 01:13.000 --> 01:19.000 So swift is a multi-platform programming language. 01:19.000 --> 01:24.000 It is a versatile language as it scales from embedded devices. 01:24.000 --> 01:29.000 And kernels to apps and cloud infrastructure. 01:29.000 --> 01:33.000 It's also fast, expressive, and safe. 01:33.000 --> 01:38.000 And has unmatched interoperability with C and C++. 01:38.000 --> 01:42.000 And has interoperability support with Java using either 01:42.000 --> 01:45.000 January or modern FFI. 01:45.000 --> 01:47.000 Here's a fun fact about swift. 01:47.000 --> 01:51.000 Two months ago on December 3, 2025, swift mark 01:51.000 --> 01:56.000 it's ten year anniversary of being open source. 01:56.000 --> 02:00.000 Swift package manager, also known as Swift PM, is available 02:00.000 --> 02:02.000 with the Swift 2 chain. 02:02.000 --> 02:05.000 Swift package manager is a developer tool that allows 02:05.000 --> 02:11.000 a developer to build, test, document, and run the code by managing 02:11.000 --> 02:15.000 the distribution of Swift code, including dependency management 02:15.000 --> 02:18.000 and a form of a Swift package. 02:18.000 --> 02:23.000 It also allows for easily importing other Swift packages into the application 02:23.000 --> 02:27.000 and executable or library, making it an essential part of a Swift 02:27.000 --> 02:30.000 developer's tools box. 02:30.000 --> 02:39.000 All of the Swift package can define products which can be consumed by other packages. 02:39.000 --> 02:45.000 Swift PM organizes code through several logical units. 02:46.000 --> 02:50.000 Packages, products, and targets. 02:50.000 --> 02:55.000 We will only focus on packages and products as they are important concepts 02:55.000 --> 02:59.000 for Swift S1. 02:59.000 --> 03:04.000 A Swift package is a reusable component that can be distributed 03:04.000 --> 03:07.000 to other Swift projects. 03:07.000 --> 03:12.000 It consists of a package manifest or package the Swift manifest file 03:12.000 --> 03:17.000 along with source files, resources, and other assets. 03:17.000 --> 03:20.000 Here's an example of three packages. 03:20.000 --> 03:25.000 Swift example, Swift crypto, and Swift S1. 03:25.000 --> 03:30.000 Package level dependencies relate packages to packages. 03:30.000 --> 03:35.000 In this example, Swift example depends on Swift crypto, 03:35.000 --> 03:41.000 and the Swift crypto package depends on Swift S1 package. 03:42.000 --> 03:49.000 A Swift PM product is the consumable artifacts produced and exposed by Swift package. 03:49.000 --> 03:55.000 Said differently, a Swift package can produce a zero or more products. 03:55.000 --> 04:02.000 A Swift PM product can be a library, an executable or a plugin. 04:02.000 --> 04:07.000 There are packets to product relationships where packages produce products. 04:08.000 --> 04:14.000 For this presentation, we're classifying that relationship as a dependency type. 04:14.000 --> 04:19.000 For example, each of these packages produces products. 04:19.000 --> 04:23.000 This Swift example package produces a product called Swift example product. 04:23.000 --> 04:25.000 Sorry, naming this hard. 04:25.000 --> 04:31.000 Swift crypto package produces two products, Swift crypto and crypto extras. 04:31.000 --> 04:39.000 And the Swift Sn package produces a product named Swift S1. 04:39.000 --> 04:43.000 Products can also depend on each other. 04:43.000 --> 04:47.000 These are known as product level dependencies. 04:47.000 --> 04:52.000 The Swift example product depends on the crypto product in another package. 04:52.000 --> 04:58.000 And the crypto extras product depends on Swift Sn1 product. 04:59.000 --> 05:03.000 So to recap, there are three types of dependencies. 05:03.000 --> 05:08.000 Package level dependencies, which were a package depends on another package. 05:08.000 --> 05:15.000 Package to product dependencies, where a package depends on other products it produces. 05:15.000 --> 05:23.000 And product level dependencies were products depend on another product. 05:23.000 --> 05:26.000 So we know what packages and products are. 05:26.000 --> 05:31.000 Let's do mouth and talk about how Swift PM builds a Swift project. 05:31.000 --> 05:36.000 And Swift PM goes through several stages to build a product. 05:36.000 --> 05:47.000 And the two stages that are relevant as one integration feature are the package methods loading and build execution. 05:47.000 --> 05:57.000 The green package manifest loading Swift PM performs package resolution resolution, which determines the package dependencies and the versions to use. 05:57.000 --> 06:05.000 And also creates a module's package graph representing the package and product dependency tree. 06:05.000 --> 06:09.000 The build execution stage comes next. 06:09.000 --> 06:15.000 Swift PM has several built systems, but we'll be focusing on the Swift build build system. 06:15.000 --> 06:23.000 The Swift build build system, not to be confused with the Swift build command line tool, is currently under evaluation. 06:23.000 --> 06:28.000 And there's the build engine that's used behind Xcode. 06:28.000 --> 06:33.000 Swift PM dedicates build activities to the Swift build build system. 06:33.000 --> 06:42.000 And as part of those activities, Swift build, computes and produces a build dependency graph. 06:42.000 --> 06:53.000 The build dependency graph consumes the result modures graph from the package manifest loading stage. 06:53.000 --> 06:58.000 The result modures graph is an output of the package manifest loading stage. 06:58.000 --> 07:04.000 And the Swift build dependency graph is an output of the build execution stage. 07:04.000 --> 07:14.000 The graphs contain different information. 07:14.000 --> 07:18.000 Oh, sorry to me, second here. 07:18.000 --> 07:25.000 The result modures graph includes the information that is beneficial for S-bomb, like all package and product and dependency tree, 07:25.000 --> 07:37.000 including extraneous components, package level dependencies, product to product dependencies, and product level dependencies. 07:37.000 --> 07:48.000 On the other hand, the Swift build dependency graph is derived by converting products into the result modures graph into build targets. 07:48.000 --> 08:03.000 The build dependency graph contains information about only the build targets using the build, and target level dependencies after converting from product level dependencies and the result modures graph. 08:03.000 --> 08:11.000 There are two factors that can influence the result modures graph, and the Swift build dependency graph. 08:11.000 --> 08:17.000 Traits and conditions. 08:17.000 --> 08:22.000 Traits can be thought of something similar to feature flags, they'll not quite the same. 08:22.000 --> 08:31.000 They're evaluated during the package manifest loading stage, and they can either include or exclude parts of the result modures graph. 08:31.000 --> 08:48.000 Package authors can define traits for their own package, and not dependency packages, but they can decide to enable package traits through the manual package dependency traits through the manifest. 08:48.000 --> 08:54.000 On the other hand, conditions are based on build time environmental conditions. 08:54.000 --> 09:08.000 They're evaluated during build conditions, and they affect, and their effect essentially affects the build dependency graph generated by the Swift build system. 09:08.000 --> 09:13.000 This is a summary table that compares the internal Swift PM graphs. 09:13.000 --> 09:18.000 The key takeaway here is there's red and green colors on both sides of the table. 09:18.000 --> 09:30.000 That's because the two graphs contain different information and insights about the build process, and this is important for the Swift S-bomb generation feature. 09:30.000 --> 09:44.000 Well, how long did I off now to have who will talk about some of the challenges that existing tools face when creating Swift S-bombs, and will dive deeper into our implementation of Swift S-bomb generation with Swift PM. 09:48.000 --> 09:55.000 Okay, thank you Sam. To start, I'll cover why Swift S-bombs are important to Swift supply chain security. 09:55.000 --> 09:59.000 Swift S-bombs harden the security profile of Swift projects in multiple ways. 09:59.000 --> 10:08.000 First, by understanding what software components are in the projects, Swift developers can better assess and manage the risk associated with third-party components. 10:08.000 --> 10:13.000 This includes identifying outdated or un-maintained dependencies that could pose future risk. 10:13.000 --> 10:17.000 Additionally, S-bomb's help promote transparency and compliance in Swift projects. 10:17.000 --> 10:21.000 This is important when distributing Swift software to other organizations. 10:21.000 --> 10:25.000 Swift developers can document that their software doesn't contain disclosed vulnerabilities, 10:25.000 --> 10:29.000 while organizations can show that their compliance with security standards. 10:29.000 --> 10:37.000 Finally, the event of a security incident, and S-bomb can speed up the process of determining which parts of a Swift application might be affected. 10:37.000 --> 10:41.000 So S-bomb's help Swift developers remediate vulnerabilities in their projects. 10:42.000 --> 10:46.000 We define two characteristics for good Swift S-bomb. 10:46.000 --> 10:55.000 The first characteristic is accuracy, so for the purpose of this presentation, a Swift S-bomb is accurate when it enumerates the components that are actually present and used in the artifact. 10:55.000 --> 10:59.000 The second characteristic we prioritize is granularity. 10:59.000 --> 11:07.000 For the purpose of this presentation, a Swift S-bomb is granular when it reflects direct and transmitted dependencies at the package and product levels. 11:07.000 --> 11:13.000 So this is our example diagram from the previous section. It shows package level, package to product and product level dependencies. 11:13.000 --> 11:20.000 An accurate and granular S-bomb can model all three types of dependencies without lacking critical information or adding extra noise. 11:20.000 --> 11:27.000 A good Swift S-bomb can be used to determine whether a disclosed vulnerability and a package affects our own package or product. 11:27.000 --> 11:34.000 So let's say Swift example package is a monorepo, and I'm a developer who owns Swift example product. 11:35.000 --> 11:39.000 I wake up tomorrow morning and I find out that Swift S-bomb has a new disclosed vulnerability. 11:39.000 --> 11:43.000 As a developer, I want to know whether this vulnerability affects my product. 11:43.000 --> 11:47.000 If I look at an accurate and granular Swift S-bomb, I can easily determine this. 11:47.000 --> 11:51.000 My product only uses the crypto product, which has no dependencies. 11:51.000 --> 11:56.000 That means the crypto product doesn't use Swift S-bomb and my product isn't affected. 11:57.000 --> 12:02.000 On the other hand, any other product in the monorepo, that's using crypto extras, will be affected. 12:02.000 --> 12:05.000 And that's because crypto extras uses Swift S-bomb. 12:05.000 --> 12:09.000 This example shows why the granularity of a Swift S-bomb is important. 12:09.000 --> 12:14.000 If we only look at the package level dependencies on the surface, it looks like our product is affected. 12:14.000 --> 12:21.000 It's only when we dive deeper into the product level dependencies that we can see that our product isn't affected after all. 12:21.000 --> 12:31.000 For an accurate and granular Swift S-bomb, direct and transitive dependencies should be represented for package level, package to product and product level dependencies. 12:31.000 --> 12:35.000 Extraneous or unused components should not be included in the S-bomb, 12:35.000 --> 12:40.000 and flies the enable or disabled dependencies should be safely handled. 12:40.000 --> 12:44.000 We've talked about why it's important for S-bomb to be accurate and granular. 12:44.000 --> 12:50.000 However, the capability to create accurate and granular Swift S-bomb is limited. 12:50.000 --> 12:55.000 There are two main challenges that exist in S-bomb tools based on generating Swift S-bombs. 12:55.000 --> 13:01.000 First, Swift PM encapsulates the build process and exposes limited information about components and dependencies. 13:01.000 --> 13:06.000 Second, packages and products listed in a manifest file may or may not be used. 13:06.000 --> 13:11.000 This depends on the build as well as optional flies that can enable or disabled dependencies. 13:11.000 --> 13:19.000 As a result, S-bombs from existing tools can under or over represent the final Swift components in the artifact. 13:19.000 --> 13:24.000 The first challenge is the lack of insight that existing tools have into the Swift build process. 13:24.000 --> 13:28.000 Existing tool primarily draw information from the package to a Swift manifest file, 13:28.000 --> 13:32.000 and to show dependencies package subcommand. 13:32.000 --> 13:37.000 Package to a Swift is a manifest file that defines the package, its contents, and its dependencies. 13:37.000 --> 13:41.000 So here's an example of a code snippet from the package to a Swift file. 13:41.000 --> 13:47.000 First, we define a product, my sample product, which consists of a single build target, my sample target. 13:48.000 --> 13:56.000 The build target describes the dependencies for the product. In this case, my sample product depends on the crypto product and the Swift crypto package. 13:56.000 --> 14:00.000 Package to a Swift can tell us about direct dependencies, but not transitive dependencies. 14:00.000 --> 14:06.000 So we can't tell from this code snippet how many dependencies the crypto product itself has. 14:06.000 --> 14:11.000 The show dependencies package subcommand describes direct and transitive package dependencies. 14:11.000 --> 14:19.000 In this package subcommand output, the Swift build package depends on the Swift driver and Swift system packages. 14:19.000 --> 14:25.000 The show dependencies package subcommand performs package manifest loading, but does not execute the build. 14:25.000 --> 14:30.000 So it's lacking information that's only known at the build execution stage. 14:30.000 --> 14:37.000 This is a summary table of what information is available to existing spawn tools, based on package sub Swift manifest file, 14:37.000 --> 14:46.000 and the show dependencies package subman, existing S1 tools can easily extract direct and transitive package dependencies, as well as direct product dependencies. 14:46.000 --> 14:55.000 There's partial information about package to product dependencies, and there's no easy method extract information about transitive product dependencies. 14:55.000 --> 15:03.000 The second challenge that existing tools face is that packages and products listed in a manifest file may or may not be used. 15:03.000 --> 15:17.000 The second challenge that existing components listed in package sub Swift can be entirely unused by the package, used by the package, but unused and irrelevant to the product developer owns, or conditionally included based on flags like Swift traits and conditions. 15:17.000 --> 15:24.000 This table summarizes the three cases I described in the first case unused components are included in the S1. 15:24.000 --> 15:33.000 And in the third case, traits and conditions can alter which components end up in the final artifact. 15:33.000 --> 15:38.000 Existing S1 tools don't know how to safely handle these flags to create accurate Swift S1s. 15:38.000 --> 15:45.000 For these three cases, the generated S1 by existing S1 tools is noisy and or electrically information. 15:45.000 --> 15:49.000 This is a summary table that challenges that existing S1 tools face. 15:49.000 --> 16:00.000 Due to the limited information that Swift PM exposes, existing tools aren't able to represent transitive product dependencies, ignore extraneous components and handle conditional flags. 16:00.000 --> 16:07.000 That means existing S1 tools are only able to generate partially accurate Swift S1s with package level dependencies. 16:07.000 --> 16:14.000 To overcome these challenges, we're currently working on integrating S1 generation, directing to Swift PM's bill processes. 16:14.000 --> 16:24.000 By integrating S1 generation directly into Swift PM, our S1 generation features able to take advantage of internal Swift PM graphs to create accurate and granular Swift S1s. 16:24.000 --> 16:30.000 Swift PM's existing graphs already have a necessary information to generate accurate and granular Swift S1s. 16:30.000 --> 16:39.000 By combining information from the resolve models graph and the Swift bill depends depends on your graph, we can use Swift PM to create Swift S1s. 16:40.000 --> 16:51.000 Swift S1s created by Swift PM are unique and that they'll include the three types of dependencies discussed, we'll exclude extraneous components and we'll apply the effects of conditional flags. 16:51.000 --> 17:00.000 Now all the stuff are designed to integrate S1 generation into Swift PM's bill process and we'll explore some examples of Swift S1s generated by Swift PM. 17:00.000 --> 17:08.000 This is the Swift PM bill stage diagram from the previous section's presentation, and here's the pathway for S1 generation through Swift PM. 17:09.000 --> 17:22.000 S1 generation goes through the Swift billed billed system and therefore uses both the resolve models graph and the Swift billed dependency graph to generate the S1. 17:22.000 --> 17:27.000 The generated S1 reflects bill time conditions and excludes extraneous components. 17:27.000 --> 17:32.000 To trigger S1 generation to build command, the user can use the dash dash S1 spec flag. 17:32.000 --> 17:38.000 Here's an example command that generates both cyclone dx and Sbdx S1s for the root package. 17:38.000 --> 17:44.000 This is a small demo of creating cyclone dx and Sbdx S1s on an example repo. 17:44.000 --> 17:50.000 First the bill command builds the artifact as usual, then the S1s are created. 17:50.000 --> 17:58.000 And then we take a peak at the S1 in this case the cyclone dx S1. 17:58.000 --> 18:05.000 As a result of this command, the S1 that's generated is a cyclone dx or Sbdx JSON file that includes packages and products, 18:05.000 --> 18:10.000 excludes extraneous components and factors in bill time conditions. 18:10.000 --> 18:14.000 For the following slides, SAM and I created some visualizations of Swift Sbonds. 18:14.000 --> 18:17.000 These visualizations aren't product Swift PM. 18:17.000 --> 18:24.000 So for example, here's a Swift Sbom generated by Swift PM from its own repo using the Swift bill command and visualized by us. 18:24.000 --> 18:30.000 The Sbom has around 60 components, which includes both packages and products and 350 dependencies. 18:30.000 --> 18:34.000 Packages are represented as blue nodes and products or green nodes. 18:34.000 --> 18:41.000 This is an example Sbom that will be exploring, a code snippet from the package that was used for this Sbom is on the right. 18:41.000 --> 18:46.000 The package that Swift defines is Swift Sbom example package, which is marked in blue. 18:46.000 --> 18:54.000 At the package level, the Swift Sbom example package depends on Swift crypto and arrows between blue nodes indicate package level dependencies. 18:54.000 --> 18:58.000 Package to product dependencies or arrows going from blue nodes to green nodes. 18:58.000 --> 19:02.000 In this case Swift Sbom example produces two products. 19:02.000 --> 19:06.000 Example core and example CLI, which are marked in green. 19:06.000 --> 19:09.000 Product level dependencies are arrows between green nodes. 19:09.000 --> 19:13.000 Example core product depends on the crypto product. 19:13.000 --> 19:22.000 This example Sbom contains the packages and products for single root package, but sometimes the developer has more specific needs. 19:22.000 --> 19:29.000 Additional slides that can be used with the Sbom spec flag include dash dash Sbom filter to filter by packages products or both. 19:29.000 --> 19:33.000 Sbom for specific product and a package. 19:33.000 --> 19:37.000 The Sbom filter can be applied by adding dash dash Sbom filter to the build command. 19:37.000 --> 19:39.000 By default, no filters are applied. 19:39.000 --> 19:42.000 On the left is the original Sbom without any filters. 19:42.000 --> 19:44.000 It shows both packages and products. 19:44.000 --> 19:47.000 I've highlighted the packages in the white rectangle. 19:47.000 --> 19:51.000 And on the right is the Sbom generated with a package filter. 19:51.000 --> 19:54.000 This Sbom contains only packages. 19:54.000 --> 19:56.000 This also works for products. 19:56.000 --> 19:59.000 On the left is the original Sbom without any filters. 19:59.000 --> 20:02.000 I've highlighted the products in the Sbom as well as the primary component. 20:02.000 --> 20:08.000 And on the right is the Sbom filter by products only with exception of the primary component. 20:08.000 --> 20:13.000 The Swift build command has a dash dash product flag that can be used to build a specified product. 20:13.000 --> 20:19.000 This existing flag can be used in conjunction with the Sbom spec flag to generate Sbom's for specified product. 20:19.000 --> 20:25.000 On the left is the Sbom for the Swift Sbom example package. 20:25.000 --> 20:32.000 If we want the Sbom for example core, we can use the dash dash product flag to specify example core. 20:32.000 --> 20:36.000 It should capture this portion of the graph. 20:36.000 --> 20:41.000 And this is the resulting Sbom for example core product within the Swift Sbom example package. 20:41.000 --> 20:46.000 This Sbom shows only the components that are relevant to the example core product. 20:46.000 --> 20:49.000 Lastly, we're going to see how Sbom's are affected by tracing conditions. 20:49.000 --> 20:55.000 Swift BM automatically modifies the Sbom when tracing conditions are applied during the build. 20:55.000 --> 20:58.000 Trades are applied during the package manifests loading stage of the build. 20:58.000 --> 21:03.000 In this package us with file, we added a trade for driver support for example CLI. 21:03.000 --> 21:10.000 That means when the trade driver support is enabled, example CLI will depend on the Swift driver product and the Swift driver package. 21:10.000 --> 21:16.000 To enable the trade in this case, we pass the flag dash dash traits driver support to the build. 21:16.000 --> 21:20.000 On the left is the original Sbom without the trade enabled. 21:20.000 --> 21:23.000 On the right is the Sbom with the trade enabled. 21:23.000 --> 21:30.000 Because the Swift driver trait was enabled, the Sbom on the right has extra dependencies in the form of Swift driver. 21:30.000 --> 21:38.000 Unlike traits which are applied during the package manifests loading stage, conditions can change dependencies during the build execution stage. 21:38.000 --> 21:41.000 In this package us with file, we added a condition for example core. 21:41.000 --> 21:52.000 As a result of this condition, the example core product will depend on the collections product from the Swift collections package when the build is running on the Mac OS operating system. 21:52.000 --> 21:59.000 On the left side is original Sbom when the condition is in Mac, and on the right is the Sbom when the condition is met. 21:59.000 --> 22:07.000 Because the artifact is built on Mac OS, the Sbom on the right has extra dependencies in the form of Swift collections. 22:07.000 --> 22:14.000 The integration of Sbom generation into Swift PM allows us to generate accurate and granular Swift Sbom's. 22:14.000 --> 22:22.000 We're able to represent package and product level dependencies, exclude extraneous components, and apply the results of tracing conditions. 22:22.000 --> 22:27.000 Sbom generation for Swift PM is currently in the Swift evolution proposal phase. 22:27.000 --> 22:32.000 Our release date isn't determined yet, but it will appear in a feature Swift pull chain. 22:32.000 --> 22:40.000 Although this is an in-development feature, we do want to hear from you, we have developer pull chains available that contain Sbom support for various platforms. 22:40.000 --> 22:44.000 This feature is currently untested on Windows, which has not to provide Windows link. 22:44.000 --> 22:53.000 You can access these dead pull chains by downloading our slides, which are in the resources section of our talk page on the Boston website, and the links will be available until February 28. 22:53.000 --> 22:59.000 For Mac OS and Linux, we recommend downloading the dead pull chain via command line tool like curl. 22:59.000 --> 23:07.000 Here are some examples we provided that you can reference for downloading, extracting, and calling the dead pull chain with Sbom support. 23:07.000 --> 23:14.000 We welcome feedback about this feature before it's released. Please provide feedback directly in person or on the Swift forums via the proposal. 23:14.000 --> 23:21.000 And these slides, again, will be available on the Boston website. They're actually up there already, so you can access the links. 23:21.000 --> 23:25.000 So to wrap up, we've discussed the role of Sbom's in securing the Swift supply chain. 23:25.000 --> 23:32.000 We identified the existing Sbom tools have gaps from creating Swift Sbom's due to limited insight into Swift Pants internal processes. 23:32.000 --> 23:38.000 Then we demonstrated a preview of our upcoming feature that integrates Sbom generation into Swift Pants build process. 23:38.000 --> 23:42.000 Our in-development feature integrates Sbom generation into Swift Pants build process. 23:42.000 --> 23:48.000 And it does this by leveraging Swift Pants resolve module graph and Swift builds build dependency graph. 23:48.000 --> 23:59.000 Developers will soon be able to create accurate and granular Swift Sbom's that reflect only components that are actually used in that detailed direct and transit dependencies at the package and product levels. 23:59.000 --> 24:10.000 This new capability in Swift Pants will provide Swift developers with a tool to better understand project dependencies, manage risks, and respond efficiently to security vulnerabilities. 24:10.000 --> 24:14.000 This can significantly enhance the security posture of Swift projects. 24:14.000 --> 24:17.000 Finally, at the end, we provided some channels for feedback. 24:17.000 --> 24:21.000 Again, please take a look at our slides on the Boston website to access these links. 24:21.000 --> 24:27.000 Your input is extremely valuable to us as we refine the feature and work towards our release. 24:27.000 --> 24:29.000 That brings us to the end of our presentation. 24:29.000 --> 24:31.000 Do we have time for questions? 24:31.000 --> 24:32.000 Okay. 24:40.000 --> 24:41.000 Yes. 24:41.000 --> 24:49.000 Which version of SbDX are we generating? 24:49.000 --> 24:52.000 For SbDX, we're generating 3.0. 24:52.000 --> 24:55.000 And then for Cycle and Jx, we're generating 1.7. 24:55.000 --> 24:56.000 Okay. 25:00.000 --> 25:02.000 Yeah, question, blue shirt. 25:03.000 --> 25:06.000 Okay, next, we'll also include the extraneous packages. 25:06.000 --> 25:12.000 This is because we have to get sure that Sbom will come together in the wrong ways, 25:12.000 --> 25:15.000 like maybe on the next or manual way. 25:15.000 --> 25:16.000 Yeah. 25:16.000 --> 25:18.000 So we, okay, sorry. 25:18.000 --> 25:23.000 The question is, if you're nice to get all the extraneous components in the Sbom, 25:23.000 --> 25:27.000 we actually provide a package subcommand that only runs package manifest loading. 25:27.000 --> 25:30.000 So you get the entire components. 25:30.000 --> 25:32.000 So including extraneous components. 25:32.000 --> 25:35.000 And you don't have to run the build. 25:35.000 --> 25:36.000 Yes. 25:36.000 --> 25:39.000 I don't know about anything about SbDX. 25:39.000 --> 25:44.000 But do you think any thing can be operating system in such a full-time libraries 25:44.000 --> 25:45.000 dynamic libraries? 25:45.000 --> 25:49.000 Will you see that traceability of supposed dependencies? 25:49.000 --> 25:50.000 Okay. 25:50.000 --> 25:51.000 Yeah. 25:51.000 --> 25:56.000 So the question is, are we going to see system libraries or dialogues? 25:56.000 --> 26:01.000 For this iteration of the feature, we're only working on SwiftPM packages and products. 26:01.000 --> 26:05.000 For SbK's frameworks, dialogues, system libraries. 26:05.000 --> 26:08.000 We're kind of investigating how to add those. 26:08.000 --> 26:15.000 And they may or may not appear in future iterations of the feature. 26:15.000 --> 26:16.000 Cool. 26:16.000 --> 26:19.000 I think that might have been a one.