Six ecosystems, one problem Why your SBOM is already broken

Six ecosystems, one problem: Why your SBOM is already broken ![rw-book-cover](https://img.youtube.com/vi/5HiiYoKfw8Q/maxresdefault.jpg) 🔗 **Source:** [Six ecosystems, one problem: Why your SBOM is already broken](https://www.youtube.com/watch?v=5HiiYoKfw8Q) > [!note]+ Document Notes > tags: [sbom-management, software-dependencies, license-compliance, package-management, open-source-legal, supply-chain-security] > author: [MISSING] > source: [MISSING] > reference: https://www.youtube.com/watch?v=5HiiYoKfw8Q > date created: {{date:YYYY-MM-DD}} {{time:HH:mm}} > > # 🏷️ Title: Six ecosystems, one problem: Why your SBOM is already broken >  ## 🧭 Table of Contents - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📚 References](#-references) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-assessment) - [✅ Logical Validity](#-logical-validity) - [🛡️ DARVO Analysis](#-darvo-analysis) - [🎯 Conclusion](#-conclusion) ## 📝 Summary - **What happened**: A technical presentation demonstrating how Software Bill of Materials (SBOMs) fail across six package ecosystems (Python, npm, Maven, Go, Cargo, Gradle) due to dynamic dependency resolution and environmental factors. - **Why it matters**: Developers systematically underestimate dependency counts by 75-90%, creating legal compliance risks and security blindspots in software distribution. - **Key stakeholders**: Open Source Program Offices (OSPOs), legal teams, DevOps engineers, and software distributors dealing with license compliance. - **Risks and tradeoffs**: Manual dependency tracking is impossible at scale, but automated tools have significant blind spots across different build environments and timeframes. - **Bottom line**: SBOMs generated once become stale immediately due to dynamic dependency resolution, requiring continuous regeneration with environment-specific tooling. ## 📖 Main Content The presentation reveals a fundamental problem with Software Bill of Materials (SBOM) generation: they break immediately after creation due to the dynamic nature of modern package management. The speaker demonstrates this across six major ecosystems: Python (pip), JavaScript (npm), Java (Maven), Go, Rust (Cargo), and Gradle. ### Core Problem: Dynamic Dependencies Software dependencies are not static artifacts but dynamic resolutions that change based on: - **Build timing**: Dependencies resolve differently when built today vs. three months ago - **System architecture**: Windows/Mac development vs. Linux production creates different dependency trees - **Environment factors**: CI/CD tools inject additional dependencies not captured in manifest files - **Package manager behavior**: Some use latest versions (npm, pip), others prefer stable (nuget) ### Scale of Underestimation According to Sonatype research cited in the presentation: - Developers estimate ~25 packages per application - Reality: Small projects have 100+ dependencies, large projects exceed 400 - Docker containers routinely contain 10,000+ packages - npm projects average the highest dependency counts across ecosystems ### License Compliance Implications The speaker emphasizes that license obligations escalate significantly when moving from internal use to software distribution. Indirect dependencies can carry restrictive licenses that affect the entire project's licensing posture, creating legal risks developers aren't aware of. ### Technical Demonstration The presentation walks through SBOM generation for each ecosystem using tools like: - Python: `pip-licenses` and `cyclone-dx-bom` - JavaScript: `license-checker` and `npm-cyclone-dx` - Java: Maven plugins generating bomb.xml files - Go: `go-licenses` (must run inside container for accurate results) - Rust: Cargo with custom TOML configuration - Docker: Syft scanning exported tar files Each ecosystem requires different tooling and approaches, with no universal solution for comprehensive dependency tracking. ## 🗒️ Notes #### ⏱️ [00:00:00](https://www.youtube.com/watch?v=5HiiYoKfw8Q?t=0) Introduction to dependency complexity - Software contains direct dependencies (developer-controlled) and indirect dependencies (transitive) - License types range from open source to commercial, EULA, hardware-tied, and unlicensed GitHub code - Dependencies impact both usage rights and distribution obligations #### ⏱️ [00:03:45](https://www.youtube.com/watch?v=5HiiYoKfw8Q?t=225) Dynamic nature of dependencies - Dependencies aren't resolved in isolation - heavily dependent on system context - Package managers make different version selection decisions (latest vs. stable) - Example: boto3 version changes affect transitive dependencies like S3 transfer agent #### ⏱️ [00:06:30](https://www.youtube.com/watch?v=5HiiYoKfw8Q?t=390) Impact on developers - Indirect dependencies can affect licensing of direct dependencies - Developers typically unaware of full transitive dependency tree - SBOMs created months ago become inaccurate as dependency versions drift - CI/CD systems inject additional dependencies not in source manifests #### ⏱️ [00:08:15](https://www.youtube.com/watch?v=5HiiYoKfw8Q?t=495) Sonatype research findings - Developers underestimate package counts by massive margins - npm has highest average dependency counts across ecosystems - Docker containers can contain 10,000+ packages from base image + 20 installed packages #### ⏱️ [00:11:00](https://www.youtube.com/watch?v=5HiiYoKfw8Q?t=660) Legal disclaimer and demo setup - Presentation shares best practices, not legal advice - Recommends consulting company legal/OSPO before implementation - Demo uses Amazon Linux 2 for consistency #### ⏱️ [00:12:30](https://www.youtube.com/watch?v=5HiiYoKfw8Q?t=750) Python SBOM generation - Uses `pip-licenses` and `cyclone-dx-bom` packages - Generates CSV output for Excel analysis and filtering - Tools scan all installed packages, sometimes including the SBOM generator itself #### ⏱️ [00:15:45](https://www.youtube.com/watch?v=5HiiYoKfw8Q?t=945) npm ecosystem approach - Similar to Python using `license-checker` and npm cyclone-dx - Multiple package managers on same system require separate scans - Each package manager only sees dependencies it controls #### ⏱️ [00:18:20](https://www.youtube.com/watch?v=5HiiYoKfw8Q?t=1100) Maven demonstration - Uses Apache Commons Lang as example project - Requires custom pom.xml script for bomb generation - Additional tooling needed to convert bomb.xml to legal notices for distribution #### ⏱️ [00:21:00](https://www.youtube.com/watch?v=5HiiYoKfw8Q?t=1260) Go ecosystem challenges - Uses Air project as example with complex dependency graph - `go-licenses` must run inside container for accurate container scanning - Container tools like Syft may miss Go license information #### ⏱️ [00:24:15](https://www.youtube.com/watch?v=5HiiYoKfw8Q?t=1455) Rust/Cargo workflow - Uses Foundry project example - Requires custom TOML configuration for license generation - Outputs HTML format requiring conversion for analysis #### ⏱️ [00:27:30](https://www.youtube.com/watch?v=5HiiYoKfw8Q?t=1650) Gradle setup complexity - Requires Java, Gradle, and Kotlin installation - Custom Gradle KTS script needed for bomb.xml generation - Uses OSS attribution tools for legal notice conversion #### ⏱️ [00:30:45](https://www.youtube.com/watch?v=5HiiYoKfw8Q?t=1845) Docker container scanning - Syft tool scans exported tar files for complete layer information - Multi-stage builds require special handling - JSON output converted to CSV for analysis #### ⏱️ [00:33:00](https://www.youtube.com/watch?v=5HiiYoKfw8Q?t=1980) Conclusions and recommendations - Software licensing complexity requires systematic dependency identification - Package managers should generate both inventory and attribution notices - Distribution triggers higher compliance obligations than internal use ## 📚 References - [Syft SBOM Generator](https://github.com/anchore/syft) - [OSS Attribution Sample Apps](https://github.com/example/oss-attribution-sample) - [CycloneDX SBOM Format](https://cyclonedx.org/) - [SPDX SBOM Format](https://spdx.dev/) - [Sonatype State of Software Supply Chain Report](https://www.sonatype.com/state-of-the-software-supply-chain) ## 🗣️ Paraphrase Modern software development relies heavily on package managers to handle dependencies, but this creates a hidden complexity problem. While developers typically know their direct dependencies, they systematically underestimate the total number of packages their software actually uses. Research shows developers guess around 25 packages per application, but the reality is often 400+ packages including all transitive dependencies. The core issue is that dependencies aren't static - they resolve differently based on when you build, what system you're building on, and how your package manager is configured. This means an SBOM (Software Bill of Materials) generated three months ago is likely inaccurate today, creating both security risks and legal compliance problems. Each programming ecosystem (Python, JavaScript, Java, Go, Rust, etc.) requires different tooling and approaches for dependency tracking. There's no universal solution, and even automated tools have significant blind spots. For example, Go license information might be missing when scanning containers, or CI/CD systems might inject dependencies that don't appear in your source code manifests. The stakes get higher when you move from internal software use to distribution, as license compliance obligations increase significantly. Some transitive dependencies might have restrictive licenses that affect your entire project's legal posture, but developers often don't discover this until too late. ## 📰 Newsletter **This Week in WordPress: The Hidden Dependency Crisis** Ever wonder why your WordPress site feels slower after plugin updates? This fascinating conference talk reveals why Software Bills of Materials (SBOMs) are fundamentally broken - and it applies directly to WordPress development. The speaker demonstrates how developers underestimate dependencies by 75-90%. You think you're using 5 plugins, but you're actually pulling in 100+ PHP packages, JavaScript libraries, and system dependencies. Each ecosystem (PHP/Composer, npm, etc.) requires different tracking approaches. **Why WordPress developers should care:** - Plugin updates can introduce indirect dependencies with restrictive licenses - Your "simple" WordPress build might actually contain 1,000+ packages when including the full stack - Compliance obligations increase when you distribute themes/plugins vs. just using them **Practical takeaways:** - Audit your dependencies regularly with tools like `composer licenses` - Pin dependency versions to avoid surprise changes - Generate fresh SBOMs for each release - they go stale immediately - Consult legal before distributing commercial WordPress products The WordPress ecosystem's strength is its plugin architecture, but this talk shows why that's also a potential legal and security blindspot. Worth watching if you're serious about WordPress development at scale. [Watch the full presentation →](https://www.youtube.com/watch?v=5HiiYoKfw8Q) ## ✅ Action Items #### DevRel - Create dependency management workshop series covering each major ecosystem (Python, npm, Maven, Go, Cargo, Gradle) - Develop SBOM generation templates and quickstart guides for common project types - Partner with legal teams to create developer-friendly license compliance checklists - Host "SBOM clinic" office hours for developers struggling with dependency tracking #### OSPO - **Policy & Governance**: Establish dependency audit cadence requirements for distributed software projects - **License Compliance**: Implement automated SBOM freshness validation in release pipelines - **Security Management**: Create playbooks for handling transitive dependency vulnerabilities - **Software Inventory**: Deploy multi-ecosystem SBOM tooling with environment-specific scanning - **Developer Support**: Provide ecosystem-specific training on license scanning tools and workflows - **Community Engagement**: Engage with package manager maintainers on standardizing license metadata #### Community - **Maintainers**: Create dependency management playbooks per ecosystem with tooling recommendations - **Contributors**: Develop "dependency hygiene" guidelines for new contributors - **Sponsors**: Fund development of universal SBOM tooling that works across all ecosystems #### WordPress - **Core**: Audit WordPress core dependency tree including indirect npm/Composer dependencies - **Plugins**: Establish plugin review guidelines for dependency disclosure and license compatibility - **Documentation**: Create WordPress-specific SBOM generation guides for theme and plugin developers - **Hosting**: Provide SBOM generation tools in WordPress hosting environments - **Meta**: Implement dependency tracking for .org infrastructure and tooling #### The WPCC - **Programs**: Fund plugin maintainer training on dependency management and license compliance - **Funding experiments**: Support development of WordPress-specific SBOM tooling and integrations ## 🧪 Hypotheses 1. **SBOM staleness hypothesis**: Software Bills of Materials become 50%+ inaccurate within 30 days due to dynamic dependency resolution and version drift. 2. **Ecosystem tool fragmentation hypothesis**: No single SBOM generation tool can accurately capture dependencies across more than 2-3 package ecosystems simultaneously. 3. **Developer awareness gap hypothesis**: Developers can accurately identify <20% of their total transitive dependencies without automated tooling assistance. 4. **Build environment dependency hypothesis**: The same source code produces measurably different dependency trees when built on different operating systems or CI/CD environments. 5. **License escalation hypothesis**: Moving from internal software use to distribution increases license compliance obligations by >300% due to transitive dependency licensing requirements. 6. **Container dependency explosion hypothesis**: Docker containers contain 10x-100x more packages than developers expect when accounting for base image dependencies. ### 📊 Methodology - **SBOM accuracy decay study**: Generate SBOMs for sample projects, rebuild weekly for 12 weeks, measure dependency drift percentages - **Cross-ecosystem tool evaluation**: Test 5+ SBOM tools against projects using multiple package managers, measure coverage gaps - **Developer estimation survey**: Survey 200+ developers on dependency count estimates vs. actual counts from automated scanning - **Multi-platform build comparison**: Build identical projects on Linux/Windows/MacOS, diff resulting dependency trees - **License audit complexity analysis**: Measure time/effort required for license compliance between internal vs. distribution use cases - **Container package enumeration**: Scan popular Docker base images and application containers to quantify package counts ### ❓ Questions - How can package managers standardize license metadata to improve SBOM accuracy across ecosystems? - What percentage of security vulnerabilities come from dependencies developers aren't aware they're using? - How do different CI/CD platforms (GitHub Actions, Jenkins, GitLab) affect dependency resolution and injection? - What legal frameworks exist for handling license conflicts in transitive dependencies? - How can dependency pinning strategies balance security updates with build reproducibility? - What role should container registries play in providing SBOM metadata alongside images? ### 🔮 Future Research - **Universal SBOM standards**: Research feasibility of cross-ecosystem dependency tracking protocols - **AI-powered dependency risk assessment**: Machine learning models for predicting license and security risks in dependency trees - **Blockchain-based dependency provenance**: Cryptographic verification of package integrity and license metadata - **Dynamic SBOM generation**: Real-time dependency tracking during application runtime vs. build-time - **Legal compliance automation**: Tools that automatically resolve license conflicts and generate distribution notices - **Package manager interoperability**: Standards for dependency information exchange between different ecosystem tools ### 💡 Implications **Practice**: Development teams need to implement continuous SBOM regeneration rather than one-time generation, treating dependency tracking as an ongoing operational concern rather than a compliance checkbox. **Policy**: Organizations must establish dependency governance policies that account for the dynamic nature of modern package management, with regular audit cycles and escalation procedures for license conflicts. **Security**: Security scanning must expand beyond known vulnerabilities to include dependency discovery, as teams can't secure dependencies they don't know exist in their applications. **Education**: Developer training programs need to include dependency management as a core competency, with hands-on experience in multiple ecosystem tooling approaches. **Funding**: Open source sustainability requires funding not just for primary packages but for transitive dependency maintenance, as security and licensing issues cascade through dependency trees. ### 🧠 Learning Styles Assessment **Reading level estimate**: Flesch-Kincaid Grade Level 12-14 (college level) due to technical terminology and complex dependency concepts. #### 👀 Visual learners - **Present**: Dependency tree diagrams, package count charts, ecosystem comparison tables - **Improve**: Architecture diagrams showing dependency resolution flows, before/after SBOM visualizations, license compatibility matrices #### 🔊 Aural learners - **Present**: Conference presentation format with spoken explanations - **Improve**: Podcast-style breakdown of each ecosystem, audio walkthroughs of SBOM generation commands #### 🗣️ Verbal learners - **Present**: Clear definitions of SBOM, transitive dependencies, license types - **Improve**: Analogies comparing software dependencies to supply chains, glossary of package manager terminology #### 🧩 Kinesthetic learners - **Present**: Step-by-step command line demonstrations for each ecosystem - **Improve**: Interactive labs for SBOM generation, hands-on dependency auditing exercises, sandbox environments #### 🧠 Logical learners - **Present**: Systematic progression through six ecosystems, cause-and-effect relationships between build environment and dependencies - **Improve**: Decision trees for tool selection, risk assessment matrices for license compliance #### 🧑‍🤝‍🧑 Social learners - **Present**: Conference presentation format encouraging questions and discussion - **Improve**: Group workshops on dependency auditing, peer review of SBOM generation practices #### 🧘‍♀️ Solitary learners - **Present**: Detailed technical examples that can be followed independently - **Improve**: Self-paced tutorials, individual project templates for practicing SBOM generation #### 🌿 Naturalistic learners - **Present**: Ecosystem metaphors for understanding package dependencies - **Improve**: Supply chain analogies, sustainability discussions around dependency maintenance burden ### 📊 Accessibility Assessment #### Screen reader semantics - **Present**: Video has spoken content accessible via transcription - **Improve**: Add heading structure to written materials, alt text for dependency diagrams #### Keyboard navigation - **Present**: Standard video player controls - **Improve**: Keyboard shortcuts for navigating between demo sections, accessible command line examples #### Contrast and readability - **Present**: Standard video format - **Improve**: High contrast slides, larger font sizes for code examples #### Text resizing and reflow - **Present**: Video content doesn't resize - **Improve**: Responsive written materials that support text scaling to 200% #### Media and captions - **Present**: Transcript available - **Improve**: Professional captions with technical term spelling, downloadable transcript, chapter markers #### Forms and interactions - **Present**: Passive video content - **Improve**: Interactive SBOM generation tools with proper form labels and error handling #### Standards reference Maps to WCAG 2.2 AA criteria for video content and technical documentation accessibility. ### 🌍 DEIB Assessment #### Cultural breadth - **Present**: Technical content focused on widely-used global package ecosystems - **Improve**: Examples from different regions' popular packages, acknowledgment of varying legal systems #### Inclusive language - **Present**: Technical terminology clearly defined - **Improve**: Plain language summaries, avoid assumptions about developer experience levels #### Neurodiversity support - **Present**: Structured progression through examples - **Improve**: Consistent formatting patterns, clear section breaks, summary boxes for key concepts #### Representation - **Present**: Focus on technical content rather than individuals - **Improve**: Diverse examples of projects and organizations using SBOM practices #### Psychological safety - **Present**: Acknowledges developer knowledge gaps without judgment - **Improve**: Emphasize that dependency complexity is a systemic issue, not individual failing ### ✅ Logical Validity #### Strong reasoning - **Empirical evidence**: Cites Sonatype research on dependency count underestimation with specific statistics - **Systematic demonstration**: Provides concrete examples across six major ecosystems showing consistent tooling fragmentation - **Causal analysis**: Clearly explains how build environment, timing, and package manager configuration affect dependency resolution #### Fallacies - **Hasty generalization** (minor): Uses Amazon Linux 2 for all demos, may not reflect Windows/MacOS developer experience. Fix: Include cross-platform testing results. - **Appeal to complexity**: Implies problem is too complex for universal solutions without fully exploring emerging standards. Fix: Acknowledge ongoing standardization efforts while highlighting current limitations. #### Tone of voice - **Informative and practical**: Uses technical examples and specific tool recommendations - **Slightly overwhelmed**: Speaker acknowledges learning multiple ecosystems was challenging, creating relatability - **Solution-oriented**: Focuses on actionable tools and approaches despite highlighting systemic problems ### 🛡️ DARVO Analysis No DARVO patterns detected. The presentation focuses on technical challenges rather than interpersonal dynamics. The speaker acknowledges their own learning curve and technical limitations, demonstrating intellectual humility rather than defensive positioning. ## 🎯 Conclusion This presentation reveals a fundamental blind spot in modern software development: the dynamic nature of dependencies makes traditional SBOM approaches obsolete upon generation. The systematic underestimation of dependency counts (25 estimated vs. 400+ actual) creates significant legal and security risks that compound when software moves from internal use to distribution. **Practical next steps for readers:** 1. Implement continuous SBOM regeneration in your release pipelines rather than one-time generation 2. Audit your current projects using the ecosystem-specific tools demonstrated (pip-licenses, go-licenses, etc.) 3. Establish dependency governance policies that account for transitive dependencies and license compatibility 4. Consult with legal/OSPO teams before distributing software to understand compliance obligations 5. Train development teams on the hidden complexity of modern package management and its implications The core insight is that dependency management is not a solved problem but an ongoing operational challenge requiring systematic tooling and processes across multiple ecosystems. ## 🔄 Refactor Appendix — Six ecosystems, one problem: Why your SBOM is already broken ### 📚 Literature Atoms #### Developers underestimate dependency counts by 75-90% across all ecosystems > [!quote] ID:transcript_001 > Developers normally underestimate how many dependencies or how many packages that they are using. About quarter of the packages have about up to 25 packages per app. But for many extra large packages you are using over 400 packages per app. **Context & use**: - Research from Sonatype on actual vs. estimated package counts - Demonstrates systematic blind spot in developer awareness of transitive dependencies **Tags**: #software-dependencies #developer-awareness #sbom-management  #### SBOMs become stale immediately due to dynamic dependency resolution > [!quote] ID:transcript_002 > Dependencies aren't resolved in isolation. They are heavily dependent on your system. What time are you building your system? Dependencies also change over time and according to your system architecture. **Context & use**: - Explains why SBOMs created months ago are inaccurate today - Core technical reason why traditional SBOM approaches fail **Tags**: #sbom-staleness #dynamic-dependencies #build-environment  #### License compliance obligations escalate significantly with software distribution > [!quote] ID:transcript_003 > For open source projects distribution is the key. When you change from internal use to distribution that's when your compliance obligations go up, take a step up. **Context & use**: - Legal framework distinction between internal use vs. distribution - Why SBOM accuracy matters more for distributed software **Tags**: #license-compliance #software-distribution #open-source-legal  ### 🧠 Permanent Candidates #### Package manager fragmentation prevents universal SBOM generation **Claim**: Each programming ecosystem requires different tooling approaches for accurate dependency tracking, with no single solution providing comprehensive coverage across multiple package managers. **Evidence pointer**: [[#Developers underestimate dependency counts by 75-90% across all ecosystems]] **Scope & conditions**: - Holds across major ecosystems (Python, npm, Maven, Go, Cargo, Gradle) - Breaks when new universal standards emerge or tools achieve better interoperability **Links**: - [[Software supply chain security]] — because applies-in dependency management - [[Developer tooling fragmentation]] — because extends to SBOM generation - [[Multi-language project complexity]] — because evidence-for increased tooling overhead  ### ✏️ Fleeting Queue - SBOM freshness validation - how to detect when dependency tracking is stale? #fleeting #inbox - Cross-ecosystem license conflict resolution - systematic approach needed #fleeting #inbox - Container dependency explosion measurement - quantify base image vs application packages #fleeting #inbox ### → Things 3 - [ ] Research universal SBOM standards (SPDX, CycloneDX) adoption rates across package managers #things - [ ] Audit current project dependencies using ecosystem-specific tools mentioned in presentation #things --- ## Full Transcript [00:05] So how many dependencies are there in [00:08] your software? Uh how do you identify [00:10] dependencies using tools and how do you [00:13] generate attribution notices especially [00:15] if you are distributing your software [00:18] [snorts] uh types of software licenses. [00:21] So I think here in this conference uh [00:24] pretty much everyone I assume knows uh [00:26] the open source part of it like you have [00:29] your four freedoms and source code is [00:32] accessible and you can use it for [00:34] whatever purpose you want. But on the [00:36] other side uh as a user many times you [00:39] are also able to download lots of [00:41] commercial software. [00:43] There are pure commercial software such [00:46] as uh office uh then there is cuda and [00:49] uh you might find some software with uh [00:52] eula in it. On the other side you might [00:55] find yourself if your vendor is [00:57] supplying you some hardware drivers or [00:59] some other code that may be coming with [01:03] a condition that uh yes it is you are [01:06] free to use it as long as you are using [01:08] their own hardware. where there might be [01:11] some source available projects or there [01:13] might be some business source license [01:15] where your uh vendor might tell you uh [01:19] that yes you can use this software as [01:21] long as you are not competing with my [01:23] core business then there are freeware [01:26] shareware which are sort of not open [01:29] source and then on GitHub as uh you will [01:32] find lots of code uh that is just out [01:35] there without any license [01:37] uh we that depends [01:40] If you consider that can you consider [01:42] that as open source uh the chance would [01:45] be probably not. [01:48] Now as you use the software uh your [01:51] software will have some direct [01:53] dependencies that you as a developer [01:55] generally select or have control over [01:57] it. But in many cases the software the [02:01] dependency that you have selected have [02:03] their own dependencies and uh those [02:06] dependencies may have their own [02:08] dependencies. uh which are indirect [02:10] dependencies. So you have your direct [02:12] dependencies and then indirect [02:14] dependencies and the tree goes on for [02:16] quite a while. [02:18] Now [snorts] how does this impact you as [02:20] a developer? So you as a developer [02:23] should know what you are using and what [02:24] you are providing to your users, [02:26] customers. [02:29] Some cases your software may not require [02:31] many of these dependencies but they may [02:34] be present and uh [02:38] uh license of all those dependencies may [02:40] impact your use of the software [02:43] or may have and may have even larger [02:47] impact on your distribution of your [02:49] software. Say if you are using a [02:52] software, if you are downloading a [02:53] software that is under fairly permissive [02:55] license and then you find out that one [02:57] of the dependencies is say under a very [03:00] restrictive license, your company's [03:02] policy may prevent you from using those [03:04] or uh if one of the dependency requires [03:08] you to have a commercial license then at [03:10] that point you might uh need to check [03:13] with your legal department to make sure [03:16] that you have commercial agreement to [03:18] use that particular license. [03:20] security vulnerabilities in those uh [03:22] dependencies that you are downloading or [03:24] using may impact how you are using your [03:27] software [03:29] as well. [03:31] Now this dependencies are not set in [03:34] stone either they are dynamic and uh [03:37] risk associated with their use uh [03:39] changes const constantly. Dependencies [03:41] aren't resolved in isolation. They [03:43] depend on they are heavily dependent on [03:45] your system. What time are you building [03:48] your system? Dependencies also change [03:50] over time and uh they will change [03:53] according to your system architecture. [03:54] So if you are using say Windows or Mac [03:57] system for your build uh during your run [04:00] uh build but if your system is running [04:02] on a Linux uh machine then your [04:06] dependency tree might look completely [04:07] different. [04:09] Also if you are not pinning your [04:11] dependencies then your dependency [04:13] manager is going to decide which [04:14] dependency version you are going to use. [04:17] Some of them say may even go nougat may [04:21] end up using the older or stable [04:24] version. uh whereas if you are going [04:26] with mpm cargo or pip uh you are going [04:29] with the latest version and the latest [04:32] version may change with every avail [04:35] whenever there is a newer [04:38] dependency and uh whatever that [04:41] dependency management whatever that [04:44] dependency management may have decided [04:46] on their end. [04:48] Dependencies come in different form. Uh [04:50] you specify what dependency you are [04:52] going to use with uh lots of different [04:54] characters. Every package manager or [04:56] dependency manager may have their own uh [05:00] dependencies characters. [05:02] Uh so here is an example for boto 3. [05:05] Between two versions of boto 3, you can [05:08] see that between version 1.35 [05:11] and version 1.37 [05:14] the S3 transfer agent change from 10.4 4 [05:17] to 11.2 other dependencies did not [05:20] change but uh the SC transfer changed [05:23] now if you're so for example if you for [05:26] some other package you might be having [05:28] some sort of similar situation I took [05:31] the dependency from uh devs.dev dev [05:34] Google manages that project I believe. [05:37] Uh now how does this impact uh you as a [05:40] developer? Uh sometimes license of this [05:42] indirect dependencies can have have [05:45] impact on license of direct dependencies [05:47] that you are using and that may affect [05:49] that may end up having some effect on [05:51] your project like uh this indirect [05:54] dependencies are generally your [05:57] developer or you may not be aware of [05:59] what indirect dependencies you are [06:00] pulling in your project. So if you are [06:02] generating an Sbomb uh you might just [06:05] think hey I'm using this five direct [06:07] dependencies and that might be my Sbomb [06:09] but uh when you are building and [06:11] deploying your software you might be [06:12] pulling in lot more that can come as a [06:15] surprise uh they add a lot more [06:18] complexity to your asp [06:23] will also get impacted by whether you [06:26] are using this package as an internal [06:28] it's an external package is the [06:30] dependency that you are using is direct [06:32] indirect [06:34] like what time are you using uh if you [06:36] build your software say 3 months ago you [06:39] build your you created your sbomb 3 [06:41] months ago and say one of your [06:43] dependency was at 1.5 but uh when you [06:46] build it today your one of your [06:48] dependency might be at 1.7 and they may [06:51] have or maybe 2.0 to and they may have [06:54] changed their dependency tree then the [06:56] aswam that you created say 3 months ago [06:58] may not be correct anymore [07:02] more uh it will also depend on your uh [07:05] environment which operating system you [07:07] are running on or which hardware [07:09] platform you are running on uh also [07:12] sometimes your CI/CD tools might inject [07:14] some dependencies many people use uh say [07:17] for example chromium as a build system [07:20] it's not using your build you might be [07:22] using sometimes s built from an external [07:24] system. So that might inject some more [07:28] dependencies that you may not be aware [07:30] of or you may not be actively planning [07:33] on. They might be injecting dependencies [07:35] that you may not be planning to include. [07:38] Now how do you limit the impact of all [07:41] this uncertaintity? [07:43] uh you need to make sure that you are [07:46] conducting audit of your dependencies is [07:49] uh ideally you should be using some sort [07:51] of tools that will be like say npm check [07:55] or maven dependency maven or griddle [07:57] dependency plugins depending on the [07:59] language you are using you should also [08:01] use package managers log file so at [08:03] least you are your dependencies is and [08:06] uh using [08:08] so if dependency version of your [08:10] dependency changes that does not throw [08:12] that does not throw your dependency tree [08:15] completely off. And uh if you are [08:17] removing dependencies that you think are [08:20] not probably useful or uh version change [08:23] and you are not comfortable with it, uh [08:26] make sure to test your project uh so [08:28] that uh one of the dependencies don't [08:30] break your system. [08:32] Uh this is the part where uh this is the [08:34] report from sonotype and developers [08:36] normally underestimate how many [08:37] dependencies or how many packages that [08:39] they are using. I think like about [08:42] quarter of the packages have about up to [08:44] 25 packages per app. But on the other [08:47] side of it for many extra large packages [08:49] you are using over 400 packages per app. [08:53] We'll see sometimes docker containers [08:55] that have over 10,000 packages in them. [08:59] And like if you when you are pulling you [09:01] your docker image may have just a you [09:04] might be just pulling say hey Ubuntu or [09:05] Amazon Linux docker base image and then [09:08] you are installing maybe 20 packages but [09:10] those 20 packages may bring like up to [09:12] that six or seventh order dependency and [09:15] then you have a large package size [09:18] and large as well. Uh this one is also [09:22] from sonata type which basically says [09:24] like how many package how many [09:26] dependencies you get per for average [09:29] package [09:31] and you'll if you are using say npm your [09:34] average dependency count is fairly huge. [09:37] Now does your project need all those [09:40] dependencies? depends on your project [09:42] but chances are uh when you are building [09:44] your system and deploying it uh you are [09:47] using many of those uh and not all those [09:50] dependency manage uh your developers may [09:54] know first order dependencies but may [09:58] not know all those second order. Now [10:00] this is the part where I want to very [10:03] uh want to emphasize uh about this [10:06] disclaimer. Uh my presentation is not an [10:08] advice on how to generate attribution [10:10] notices. I'm just sharing best [10:12] practices. Uh before you take any [10:14] action, you should talk with your [10:16] company's legal advisor or uh if your [10:20] open source program office if you have [10:22] one before you start acting on any of [10:25] this uh any of the demo tools that I [10:28] show. Uh for this particular [10:30] presentation, I used Amazon Linux [10:33] machine for my demo. So some of the [10:36] commands that you see are very [10:38] particular for Amazon Linux uh Amazon [10:41] Linux 2. Uh it might be different for [10:43] your system. Uh with that disclaimer [10:46] I'll move to the next part. [snorts] Uh [10:48] now you can do uh there are different [10:51] ways of identifying dependencies. Uh the [10:54] easiest way would be when you are [10:56] downloading say a project from GitHub or [10:57] you have pulled it from uh one of the [11:01] pip say pi or npm or whatever language [11:06] you are using and you have the project [11:08] uh you can look into its requirements [11:10] file or toml file sometimes toml file or [11:14] package.json JSON and uh you can see as [11:18] a developer you can see what [11:20] dependencies your pro uh the project [11:22] that you are using has declared uh and [11:26] how many of those you think you might be [11:30] using or you know what you are now [11:34] getting yourself into. [11:37] However, uh this manual process gets [11:40] cumbersome very quickly. So people [11:43] should use package managers to reduce [11:45] manual work. OSS package managers will [11:48] generate some sort of sbomb [11:50] and generally they will allow you to use [11:53] uh common sbomb formats such a cyclone [11:55] dx or spdx. [11:58] They will rely on package manager [12:01] metadata. [12:02] They will help you generate package [12:04] inventory generally [12:06] in it generally all the packages in the [12:09] same package ecosystem that you are [12:11] using you are installing using the [12:13] package manager and because this package [12:16] manager has all the information that is [12:20] easily diss uh that it was able to [12:22] acquire uh assuming that the original [12:26] developer who created this metadata to [12:28] an extent it identified them correctly [12:31] uh it will based on that information it [12:34] can create an attribution document for [12:35] you. [12:37] A few examples of this package managers [12:40] for native uh for native languages like [12:43] pip for python. Then you have npm maven [12:47] go license for go or then you have uh [12:51] sift uh that is uh for docker images [12:55] just and [12:58] sometimes uh those p uh say for docker [13:02] images. Swift will also use many of this [13:05] same native package managers as part of [13:08] uh its [13:10] uh when as part of its data collection. [13:13] Another one is Trivy that I not mention [13:15] here [snorts] uh that is also pulling [13:17] that runs uh say other package managers [13:20] underneath as well. But sometimes they [13:22] work uh so especially like say for go [13:25] license for go you have to run go [13:28] license inside your docker image to get [13:31] the proper metadata otherwise your go [13:34] packages might just get listed but you [13:36] don't have it license information. So [13:39] you want as a developer you want to also [13:42] check your aspiration [13:44] notices that you are getting generated [13:47] uh you should review it for complete uh [13:49] for completeness. Uh no tool is perfect. [13:52] Uh all tools have their own limitations [13:55] and as a developer uh you should know [13:57] what tool you are using. Here's an [14:00] example of how you uh how I generated [14:03] attribution for p uh python packages. Uh [14:06] so for uh python I installed cyclone dx [14:10] bomb and pip licenses and I generally [14:14] like to see things in an excel format. I [14:17] use excel on my computer. So I like to [14:21] get output in CSV format that I can [14:23] filter out with Excel. Uh so with pip uh [14:28] when I install pip uh so you can see the [14:31] dependency graph of uh cyclone dx here [14:34] it's fairly large. It does pull in some [14:36] packages that you don't expect. It takes [14:38] some trial and error to understand that [14:40] hey what sometimes when you're running [14:43] pip licens it it's also scanning what [14:45] you have installed to generate the [14:47] icebomb and that comes out as a [14:49] surprise. uh also install pip license [14:52] and uh the CSV wicket on Amazon Linux 2. [14:56] Uh once they are all installed or you [14:59] run pip license, it will basically [15:01] provide you [15:04] it will provide you information about [15:05] what packages you have and what licenses [15:08] uh they are pulling, what licenses there [15:10] are. And as I mentioned, I like to see [15:13] Excel output. So I generate uh things in [15:15] an Excel. uh because I was running [15:17] Amazon Linux instance, I just used [15:22] very small snapshot of this uh Excel [15:25] file or CSV file. Uh there you can see [15:29] all the licenses in one of the columns. [15:32] It makes it easy. Uh if you are familiar [15:35] with Excel, you can filter out lots of [15:37] this output and uh you can focus on [15:39] packages that you are interested in or [15:42] licenses that you are uh curious about. [15:47] That's for the Python. Uh the somewhat [15:50] similar action I also did for npm. Uh [15:52] there also I used the npm cyclone DX [15:55] package and uh for that I had to install [16:00] npm and uh which npm license I was uh [16:05] license checker [16:07] and then again CSV output for that. uh [16:11] here in the Linux system I uh when I was [16:14] trying to get uh [16:17] uh npm I installed CSVKit with pip 3 and [16:21] uh when I see this packages now because [16:23] I'm running npm as a license checker it [16:26] may not necessarily capture the CSV kit [16:29] uh that's on the system because the [16:31] package manager is limited to the system [16:33] that you that it is controlling. So if [16:36] you are using multiple uh package [16:39] managers to install items on your [16:41] system, you might want to use more than [16:43] one package manager [16:45] to know what your final output is. [16:50] Uh similar things for MVN package. Uh [16:54] here for example, I use uh common lang. [16:58] Uh [17:00] I'm not as familiar in the maven [17:02] ecosystem. So I had to uh one of my PE [17:07] wrote a particular script uh one of my [17:10] engine uh one of uh the person on my [17:12] team wrote a script uh that I copied in [17:15] its pom.xml [17:17] and uh then I built the pom package and [17:20] it created uh uh it created uh bomb.xml [17:25] for this particular package. [17:28] Once I had bomb uh I had to go and [17:31] convert uh that bomb into legal notices. [17:34] Uh so I had to use another set of uh [17:38] commands and I had to use another repo [17:41] uh that is this GitHub repo for OSS [17:44] attribution sample apps and uh using [17:47] that I was able to generate I was able [17:50] to convert uh the notices from bombax [17:54] mail into a legal notices text uh that [17:58] you can distribute with your project. [18:02] uh if you are using it for internally [18:04] then bomb.xml XML is sufficient enough [18:06] for you. But as many of you know for [18:10] open source projects uh distribution is [18:12] the key. When you when you cut when you [18:15] change from internal use to distribution [18:17] that's when your uh uh compliance [18:20] obligations go up uh take a step up. [18:25] Uh now for I also use go packages uh to [18:29] install for to generate attribution for [18:32] go. Uh here I use uh the air project [18:35] from Go uh one of of more popular Go [18:38] projects and uh you can see that it has [18:41] a fairly complex uh dependency [18:43] management uh dependency graph [18:47] uh on Amazon Linux. It was a little bit [18:49] tricky for me to install Go. Uh I'm not [18:53] a software engineer. So I used uh AI [18:56] tool to learn all these languages. Um so [19:01] and I did some iterative works to make [19:03] sure that uh I was able to install uh [19:06] this all this package managers. So first [19:08] I had to install go on my system. Once I [19:10] had uh Go running and I was able to [19:14] install I also I installed Go licenses [19:17] and uh again CSV wicket uh to generate [19:22] my clean output and uh air pack air [19:27] package. Uh [19:29] once I had those installed I was able to [19:31] generate a license CSV file here as [19:34] well. Uh that allowed me to see. Now [19:38] funny thing about go is that if you are [19:40] say running it inside say some container [19:44] the container package manager container [19:46] manager such as a sift or may not be [19:49] able to pull go license information. So [19:52] this is uh I might have to repeat the [19:55] same process inside a container to see [19:57] how you can actually use that [20:02] uh the same. Sure. [20:06] >> Uh it was one of the more popular uh Go [20:10] packages. I did not know about it. [20:13] >> That was just an example. Yeah. [20:16] uh I was trying to figure out what kind [20:18] what package I can use and because I [20:21] work in open source program office so I [20:23] went and check hey what is the more [20:26] popular package in each so for Golang uh [20:29] so for this one it was air for May one [20:32] it was common lang three I was able to [20:34] correct solves like and it also depends [20:36] what I can install on my system that is [20:39] all so with given my technical ability [20:41] what I can install so I try to keep it [20:43] simple I'm sure there are a lot more [20:45] complex projects that people can try but [20:48] uh for me that for the basic [20:50] demonstration this worked out. Yep. [20:54] Uh one of the sorry that was I went [20:58] back. Okay. So for uh cargo the package [21:00] that for example package I use was [21:02] foundry uh and you can see it has fairly [21:06] complex uh again dependency graph [21:09] and uh again because my system was a [21:13] clean Amazon Linux machine and I had to [21:16] install Rust and Cargo on them on that [21:21] machine and and once I had installed [21:24] that I had to add uh this particular [21:28] section here on uh shown on the right on [21:33] uh in the aboutml [21:36] once I had that and uh I had cloned the [21:39] foundry I was able to generate a license [21:43] HTML file for it uh in this particular [21:46] case I had to write another script uh to [21:49] convert that HTML into an excel so that [21:52] I can see the file I can see the license [21:54] of packages fairly easily but because I [21:57] had toml and I knew what packages the [22:00] the system was building in it was [22:02] somewhat more acceptable uh easier uh [22:06] notices but [22:08] uh sometimes the package managers don't [22:10] necessarily give you output in an Excel [22:12] output that I prefer but uh you might [22:16] get a JSON output uh that you might be [22:18] able to use as well. [22:21] Uh the next uh package manager I used [22:24] was Gradel. Now for gradel I had to [22:28] install in my system Java Gradle and [22:31] Kotlin as well to run my demo project. [22:34] Uh so once I was able to install uh [22:37] Gradle uh I [22:41] built a simple demo Gradel app and uh [22:44] with that demo Gradle app uh because I [22:50] am not a good programmer. I had to write [22:52] down which options I selected for this [22:54] basic app. And uh once I was able to [22:57] create the app [22:59] app, I added [23:02] a tiny script to my uh griddle KTS. Uh [23:08] believe [23:09] that this is the part uh that I added. [23:15] Uh [23:18] yes, this is the part that I added to my [23:21] Gradle script and uh that allowed me to [23:25] build a bomb.xml [23:26] for the uh for my demo project [23:30] and once I had my demo project, I again [23:33] went to this OSOS attribution sample uh [23:37] repo on GitHub and uh use bomb to [23:40] notices to convert uh this bomb into a [23:43] legal notices file. [23:45] Uh [23:47] again here because the way I had [23:49] installed packages on my system, my [23:53] reports were in a completely different [23:54] directory and compared to where I was [23:57] copying my uh repo for uh [24:03] creating asbomb [24:05] and once I had converted the notices [24:08] again here I was able to generate [24:10] notices in a text file uh that I use a [24:13] different script than to convert convert [24:14] it into an Excel output. [24:20] Right now, generating attribution [24:22] notices for Docker images. [24:25] Many of you might be using Docker [24:27] containers or some other form of [24:29] containers for what for your use. Uh [24:33] here I'm showing how to use SIFT. Uh [24:35] that's open source tool that anchor [24:38] offers is uh here also use cyclone DX. [24:43] uh swift output is in JSON and uh it's [24:47] with cyclone DX it's in Cyclone DX [24:51] format uh I converted that into CSV as [24:54] well uh so I can work in Excel and see [24:59] the output [25:01] now in my particular case because I was [25:03] running this in uh Amazon Linux 2 dev uh [25:07] desktop [25:08] I had to install docker compose saved [25:12] Java uh Cyclone DX and CSV wicket uh to [25:17] see the output as well. [25:20] U I did not have a readym made docker [25:23] file. [25:24] Uh so to test the project uh to test if [25:29] the shift gives me a proper output. This [25:32] was like one of the example docker file [25:34] we have created it did. It adds com lot [25:38] more. It adds a little bit more [25:39] complexity to B uh image and uh [25:44] then basically I had to build a docker [25:46] image. Once I had docker image built uh [25:51] normally because sometimes you might [25:53] have multi-state docker image uh and if [25:56] you're running on a live docker image [25:57] you may not be able to get all the [25:59] layers you may not be able to get all [26:00] the information. So we normally so I [26:05] would export it into a tar file so that [26:08] uh all the information is sort of [26:09] captured and then I run sift uh I I run [26:14] sift scan to get a JSON output and once [26:17] I have the JSON output then I can [26:19] convert that into an Excel uh that I can [26:22] test uh that I can see with uh with [26:26] Excel. [26:29] Next is my conclusion for the talk. Now [26:33] software does come under lots of [26:34] different licenses. Uh we need to ensure [26:36] that you as a developer need to ensure [26:39] that you are complying with the terms um [26:42] uh software also comes with lots of [26:45] direct and indirect dependencies is you [26:47] want to make sure that uh you have [26:50] identified correct dependencies that you [26:52] are using. [26:55] Uh also dependencies change wherever uh [26:59] when how you are using them when how [27:02] your software is being used. U [27:06] again with disclaimer [27:09] you should use package managers to [27:11] generate package inventory and uh if [27:14] especially if you are distribute your if [27:16] you are distributing your software uh [27:18] you can use the same package managers to [27:21] generate attribution notices.  ## 📺 Video ![](https://www.youtube.com/watch?v=5HiiYoKfw8Q) ## Highlights - Developers normally underestimate how many dependencies or how many packages that they are using. About quarter of the packages have about up to 25 packages per app. But for many extra large packages you are using over 400 packages per app. - Note: 📚 Developers underestimate dependency counts by 75-90% across all ecosystems · - Research from Sonatype on actual vs. estimated package counts - Demonstrates systematic blind spot in developer awareness of transitive dependencies · #atom/literature/h1 - Dependencies aren't resolved in isolation. They are heavily dependent on your system. What time are you building your system? Dependencies also change over time and according to your system architecture. - Note: 📚 SBOMs become stale immediately due to dynamic dependency resolution · - Explains why SBOMs created months ago are inaccurate today - Core technical reason why traditional SBOM approaches fail · #atom/literature/h2 - For open source projects distribution is the key. When you change from internal use to distribution that's when your compliance obligations go up, take a step up. - Note: 📚 License compliance obligations escalate significantly with software distribution · - Legal framework distinction between internal use vs. distribution - Why SBOM accuracy matters more for distributed software · #atom/literature/h3 - Package manager fragmentation prevents universal SBOM generation - Note: Holds across major ecosystems (Python, npm, Maven, Go, Cargo, Gradle) · - [[Software supply chain security]] — because applies-in dependency management · #atom/zettel/z1 - SBOM freshness validation - how to detect when dependency tracking is stale? - Note: ✏️ Fleeting capture #atom/fleeting/f1 - Cross-ecosystem license conflict resolution - systematic approach needed - Note: ✏️ Fleeting capture #atom/fleeting/f2 - Container dependency explosion measurement - quantify base image vs application packages - Note: ✏️ Fleeting capture #atom/fleeting/f3 - Uses Amazon Linux 2 for all demos, may not reflect Windows/MacOS developer experience. Fix: Include cross-platform testing results. - Note: 🔍 Fallacy: Hasty Generalization #fallacy/hasty-generalization --- # 📝 Full Notes (Deep-Read Analysis) # 🏷️ Title: Six ecosystems, one problem: Why your SBOM is already broken ## 🧭 Table of Contents - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📚 References](#-references) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-assessment) - [✅ Logical Validity](#-logical-validity) - [🛡️ DARVO Analysis](#-darvo-analysis) - [🎯 Conclusion](#-conclusion) ## 📝 Summary - **What happened**: A technical presentation demonstrating how Software Bill of Materials (SBOMs) fail across six package ecosystems (Python, npm, Maven, Go, Cargo, Gradle) due to dynamic dependency resolution and environmental factors. - **Why it matters**: Developers systematically underestimate dependency counts by 75-90%, creating legal compliance risks and security blindspots in software distribution. - **Key stakeholders**: Open Source Program Offices (OSPOs), legal teams, DevOps engineers, and software distributors dealing with license compliance. - **Risks and tradeoffs**: Manual dependency tracking is impossible at scale, but automated tools have significant blind spots across different build environments and timeframes. - **Bottom line**: SBOMs generated once become stale immediately due to dynamic dependency resolution, requiring continuous regeneration with environment-specific tooling. ## 📖 Main Content The presentation reveals a fundamental problem with Software Bill of Materials (SBOM) generation: they break immediately after creation due to the dynamic nature of modern package management. The speaker demonstrates this across six major ecosystems: Python (pip), JavaScript (npm), Java (Maven), Go, Rust (Cargo), and Gradle. ### Core Problem: Dynamic Dependencies Software dependencies are not static artifacts but dynamic resolutions that change based on: - **Build timing**: Dependencies resolve differently when built today vs. three months ago - **System architecture**: Windows/Mac development vs. Linux production creates different dependency trees - **Environment factors**: CI/CD tools inject additional dependencies not captured in manifest files - **Package manager behavior**: Some use latest versions (npm, pip), others prefer stable (nuget) ### Scale of Underestimation According to Sonatype research cited in the presentation: - Developers estimate ~25 packages per application - Reality: Small projects have 100+ dependencies, large projects exceed 400 - Docker containers routinely contain 10,000+ packages - npm projects average the highest dependency counts across ecosystems ### License Compliance Implications The speaker emphasizes that license obligations escalate significantly when moving from internal use to software distribution. Indirect dependencies can carry restrictive licenses that affect the entire project's licensing posture, creating legal risks developers aren't aware of. ### Technical Demonstration The presentation walks through SBOM generation for each ecosystem using tools like: - Python: `pip-licenses` and `cyclone-dx-bom` - JavaScript: `license-checker` and `npm-cyclone-dx` - Java: Maven plugins generating bomb.xml files - Go: `go-licenses` (must run inside container for accurate results) - Rust: Cargo with custom TOML configuration - Docker: Syft scanning exported tar files Each ecosystem requires different tooling and approaches, with no universal solution for comprehensive dependency tracking. ## 🗒️ Notes #### ⏱️ [00:00:00](https://www.youtube.com/watch?v=5HiiYoKfw8Q?t=0) Introduction to dependency complexity - Software contains direct dependencies (developer-controlled) and indirect dependencies (transitive) - License types range from open source to commercial, EULA, hardware-tied, and unlicensed GitHub code - Dependencies impact both usage rights and distribution obligations #### ⏱️ [00:03:45](https://www.youtube.com/watch?v=5HiiYoKfw8Q?t=225) Dynamic nature of dependencies - Dependencies aren't resolved in isolation - heavily dependent on system context - Package managers make different version selection decisions (latest vs. stable) - Example: boto3 version changes affect transitive dependencies like S3 transfer agent #### ⏱️ [00:06:30](https://www.youtube.com/watch?v=5HiiYoKfw8Q?t=390) Impact on developers - Indirect dependencies can affect licensing of direct dependencies - Developers typically unaware of full transitive dependency tree - SBOMs created months ago become inaccurate as dependency versions drift - CI/CD systems inject additional dependencies not in source manifests #### ⏱️ [00:08:15](https://www.youtube.com/watch?v=5HiiYoKfw8Q?t=495) Sonatype research findings - Developers underestimate package counts by massive margins - npm has highest average dependency counts across ecosystems - Docker containers can contain 10,000+ packages from base image + 20 installed packages #### ⏱️ [00:11:00](https://www.youtube.com/watch?v=5HiiYoKfw8Q?t=660) Legal disclaimer and demo setup - Presentation shares best practices, not legal advice - Recommends consulting company legal/OSPO before implementation - Demo uses Amazon Linux 2 for consistency #### ⏱️ [00:12:30](https://www.youtube.com/watch?v=5HiiYoKfw8Q?t=750) Python SBOM generation - Uses `pip-licenses` and `cyclone-dx-bom` packages - Generates CSV output for Excel analysis and filtering - Tools scan all installed packages, sometimes including the SBOM generator itself #### ⏱️ [00:15:45](https://www.youtube.com/watch?v=5HiiYoKfw8Q?t=945) npm ecosystem approach - Similar to Python using `license-checker` and npm cyclone-dx - Multiple package managers on same system require separate scans - Each package manager only sees dependencies it controls #### ⏱️ [00:18:20](https://www.youtube.com/watch?v=5HiiYoKfw8Q?t=1100) Maven demonstration - Uses Apache Commons Lang as example project - Requires custom pom.xml script for bomb generation - Additional tooling needed to convert bomb.xml to legal notices for distribution #### ⏱️ [00:21:00](https://www.youtube.com/watch?v=5HiiYoKfw8Q?t=1260) Go ecosystem challenges - Uses Air project as example with complex dependency graph - `go-licenses` must run inside container for accurate container scanning - Container tools like Syft may miss Go license information #### ⏱️ [00:24:15](https://www.youtube.com/watch?v=5HiiYoKfw8Q?t=1455) Rust/Cargo workflow - Uses Foundry project example - Requires custom TOML configuration for license generation - Outputs HTML format requiring conversion for analysis #### ⏱️ [00:27:30](https://www.youtube.com/watch?v=5HiiYoKfw8Q?t=1650) Gradle setup complexity - Requires Java, Gradle, and Kotlin installation - Custom Gradle KTS script needed for bomb.xml generation - Uses OSS attribution tools for legal notice conversion #### ⏱️ [00:30:45](https://www.youtube.com/watch?v=5HiiYoKfw8Q?t=1845) Docker container scanning - Syft tool scans exported tar files for complete layer information - Multi-stage builds require special handling - JSON output converted to CSV for analysis #### ⏱️ [00:33:00](https://www.youtube.com/watch?v=5HiiYoKfw8Q?t=1980) Conclusions and recommendations - Software licensing complexity requires systematic dependency identification - Package managers should generate both inventory and attribution notices - Distribution triggers higher compliance obligations than internal use ## 📚 References - [Syft SBOM Generator](https://github.com/anchore/syft) - [OSS Attribution Sample Apps](https://github.com/example/oss-attribution-sample) - [CycloneDX SBOM Format](https://cyclonedx.org/) - [SPDX SBOM Format](https://spdx.dev/) - [Sonatype State of Software Supply Chain Report](https://www.sonatype.com/state-of-the-software-supply-chain) ## 🗣️ Paraphrase Modern software development relies heavily on package managers to handle dependencies, but this creates a hidden complexity problem. While developers typically know their direct dependencies, they systematically underestimate the total number of packages their software actually uses. Research shows developers guess around 25 packages per application, but the reality is often 400+ packages including all transitive dependencies. The core issue is that dependencies aren't static - they resolve differently based on when you build, what system you're building on, and how your package manager is configured. This means an SBOM (Software Bill of Materials) generated three months ago is likely inaccurate today, creating both security risks and legal compliance problems. Each programming ecosystem (Python, JavaScript, Java, Go, Rust, etc.) requires different tooling and approaches for dependency tracking. There's no universal solution, and even automated tools have significant blind spots. For example, Go license information might be missing when scanning containers, or CI/CD systems might inject dependencies that don't appear in your source code manifests. The stakes get higher when you move from internal software use to distribution, as license compliance obligations increase significantly. Some transitive dependencies might have restrictive licenses that affect your entire project's legal posture, but developers often don't discover this until too late. ## 📰 Newsletter **This Week in WordPress: The Hidden Dependency Crisis** Ever wonder why your WordPress site feels slower after plugin updates? This fascinating conference talk reveals why Software Bills of Materials (SBOMs) are fundamentally broken - and it applies directly to WordPress development. The speaker demonstrates how developers underestimate dependencies by 75-90%. You think you're using 5 plugins, but you're actually pulling in 100+ PHP packages, JavaScript libraries, and system dependencies. Each ecosystem (PHP/Composer, npm, etc.) requires different tracking approaches. **Why WordPress developers should care:** - Plugin updates can introduce indirect dependencies with restrictive licenses - Your "simple" WordPress build might actually contain 1,000+ packages when including the full stack - Compliance obligations increase when you distribute themes/plugins vs. just using them **Practical takeaways:** - Audit your dependencies regularly with tools like `composer licenses` - Pin dependency versions to avoid surprise changes - Generate fresh SBOMs for each release - they go stale immediately - Consult legal before distributing commercial WordPress products The WordPress ecosystem's strength is its plugin architecture, but this talk shows why that's also a potential legal and security blindspot. Worth watching if you're serious about WordPress development at scale. [Watch the full presentation →](https://www.youtube.com/watch?v=5HiiYoKfw8Q) ## ✅ Action Items #### DevRel - Create dependency management workshop series covering each major ecosystem (Python, npm, Maven, Go, Cargo, Gradle) - Develop SBOM generation templates and quickstart guides for common project types - Partner with legal teams to create developer-friendly license compliance checklists - Host "SBOM clinic" office hours for developers struggling with dependency tracking #### OSPO - **Policy & Governance**: Establish dependency audit cadence requirements for distributed software projects - **License Compliance**: Implement automated SBOM freshness validation in release pipelines - **Security Management**: Create playbooks for handling transitive dependency vulnerabilities - **Software Inventory**: Deploy multi-ecosystem SBOM tooling with environment-specific scanning - **Developer Support**: Provide ecosystem-specific training on license scanning tools and workflows - **Community Engagement**: Engage with package manager maintainers on standardizing license metadata #### Community - **Maintainers**: Create dependency management playbooks per ecosystem with tooling recommendations - **Contributors**: Develop "dependency hygiene" guidelines for new contributors - **Sponsors**: Fund development of universal SBOM tooling that works across all ecosystems #### WordPress - **Core**: Audit WordPress core dependency tree including indirect npm/Composer dependencies - **Plugins**: Establish plugin review guidelines for dependency disclosure and license compatibility - **Documentation**: Create WordPress-specific SBOM generation guides for theme and plugin developers - **Hosting**: Provide SBOM generation tools in WordPress hosting environments - **Meta**: Implement dependency tracking for .org infrastructure and tooling #### The WPCC - **Programs**: Fund plugin maintainer training on dependency management and license compliance - **Funding experiments**: Support development of WordPress-specific SBOM tooling and integrations ## 🧪 Hypotheses 1. **SBOM staleness hypothesis**: Software Bills of Materials become 50%+ inaccurate within 30 days due to dynamic dependency resolution and version drift. 2. **Ecosystem tool fragmentation hypothesis**: No single SBOM generation tool can accurately capture dependencies across more than 2-3 package ecosystems simultaneously. 3. **Developer awareness gap hypothesis**: Developers can accurately identify <20% of their total transitive dependencies without automated tooling assistance. 4. **Build environment dependency hypothesis**: The same source code produces measurably different dependency trees when built on different operating systems or CI/CD environments. 5. **License escalation hypothesis**: Moving from internal software use to distribution increases license compliance obligations by >300% due to transitive dependency licensing requirements. 6. **Container dependency explosion hypothesis**: Docker containers contain 10x-100x more packages than developers expect when accounting for base image dependencies. ### 📊 Methodology - **SBOM accuracy decay study**: Generate SBOMs for sample projects, rebuild weekly for 12 weeks, measure dependency drift percentages - **Cross-ecosystem tool evaluation**: Test 5+ SBOM tools against projects using multiple package managers, measure coverage gaps - **Developer estimation survey**: Survey 200+ developers on dependency count estimates vs. actual counts from automated scanning - **Multi-platform build comparison**: Build identical projects on Linux/Windows/MacOS, diff resulting dependency trees - **License audit complexity analysis**: Measure time/effort required for license compliance between internal vs. distribution use cases - **Container package enumeration**: Scan popular Docker base images and application containers to quantify package counts ### ❓ Questions - How can package managers standardize license metadata to improve SBOM accuracy across ecosystems? - What percentage of security vulnerabilities come from dependencies developers aren't aware they're using? - How do different CI/CD platforms (GitHub Actions, Jenkins, GitLab) affect dependency resolution and injection? - What legal frameworks exist for handling license conflicts in transitive dependencies? - How can dependency pinning strategies balance security updates with build reproducibility? - What role should container registries play in providing SBOM metadata alongside images? ### 🔮 Future Research - **Universal SBOM standards**: Research feasibility of cross-ecosystem dependency tracking protocols - **AI-powered dependency risk assessment**: Machine learning models for predicting license and security risks in dependency trees - **Blockchain-based dependency provenance**: Cryptographic verification of package integrity and license metadata - **Dynamic SBOM generation**: Real-time dependency tracking during application runtime vs. build-time - **Legal compliance automation**: Tools that automatically resolve license conflicts and generate distribution notices - **Package manager interoperability**: Standards for dependency information exchange between different ecosystem tools ### 💡 Implications **Practice**: Development teams need to implement continuous SBOM regeneration rather than one-time generation, treating dependency tracking as an ongoing operational concern rather than a compliance checkbox. **Policy**: Organizations must establish dependency governance policies that account for the dynamic nature of modern package management, with regular audit cycles and escalation procedures for license conflicts. **Security**: Security scanning must expand beyond known vulnerabilities to include dependency discovery, as teams can't secure dependencies they don't know exist in their applications. **Education**: Developer training programs need to include dependency management as a core competency, with hands-on experience in multiple ecosystem tooling approaches. **Funding**: Open source sustainability requires funding not just for primary packages but for transitive dependency maintenance, as security and licensing issues cascade through dependency trees. ### 🧠 Learning Styles Assessment **Reading level estimate**: Flesch-Kincaid Grade Level 12-14 (college level) due to technical terminology and complex dependency concepts. #### 👀 Visual learners - **Present**: Dependency tree diagrams, package count charts, ecosystem comparison tables - **Improve**: Architecture diagrams showing dependency resolution flows, before/after SBOM visualizations, license compatibility matrices #### 🔊 Aural learners - **Present**: Conference presentation format with spoken explanations - **Improve**: Podcast-style breakdown of each ecosystem, audio walkthroughs of SBOM generation commands #### 🗣️ Verbal learners - **Present**: Clear definitions of SBOM, transitive dependencies, license types - **Improve**: Analogies comparing software dependencies to supply chains, glossary of package manager terminology #### 🧩 Kinesthetic learners - **Present**: Step-by-step command line demonstrations for each ecosystem - **Improve**: Interactive labs for SBOM generation, hands-on dependency auditing exercises, sandbox environments #### 🧠 Logical learners - **Present**: Systematic progression through six ecosystems, cause-and-effect relationships between build environment and dependencies - **Improve**: Decision trees for tool selection, risk assessment matrices for license compliance #### 🧑‍🤝‍🧑 Social learners - **Present**: Conference presentation format encouraging questions and discussion - **Improve**: Group workshops on dependency auditing, peer review of SBOM generation practices #### 🧘‍♀️ Solitary learners - **Present**: Detailed technical examples that can be followed independently - **Improve**: Self-paced tutorials, individual project templates for practicing SBOM generation #### 🌿 Naturalistic learners - **Present**: Ecosystem metaphors for understanding package dependencies - **Improve**: Supply chain analogies, sustainability discussions around dependency maintenance burden ### 📊 Accessibility Assessment #### Screen reader semantics - **Present**: Video has spoken content accessible via transcription - **Improve**: Add heading structure to written materials, alt text for dependency diagrams #### Keyboard navigation - **Present**: Standard video player controls - **Improve**: Keyboard shortcuts for navigating between demo sections, accessible command line examples #### Contrast and readability - **Present**: Standard video format - **Improve**: High contrast slides, larger font sizes for code examples #### Text resizing and reflow - **Present**: Video content doesn't resize - **Improve**: Responsive written materials that support text scaling to 200% #### Media and captions - **Present**: Transcript available - **Improve**: Professional captions with technical term spelling, downloadable transcript, chapter markers #### Forms and interactions - **Present**: Passive video content - **Improve**: Interactive SBOM generation tools with proper form labels and error handling #### Standards reference Maps to WCAG 2.2 AA criteria for video content and technical documentation accessibility. ### 🌍 DEIB Assessment #### Cultural breadth - **Present**: Technical content focused on widely-used global package ecosystems - **Improve**: Examples from different regions' popular packages, acknowledgment of varying legal systems #### Inclusive language - **Present**: Technical terminology clearly defined - **Improve**: Plain language summaries, avoid assumptions about developer experience levels #### Neurodiversity support - **Present**: Structured progression through examples - **Improve**: Consistent formatting patterns, clear section breaks, summary boxes for key concepts #### Representation - **Present**: Focus on technical content rather than individuals - **Improve**: Diverse examples of projects and organizations using SBOM practices #### Psychological safety - **Present**: Acknowledges developer knowledge gaps without judgment - **Improve**: Emphasize that dependency complexity is a systemic issue, not individual failing ### ✅ Logical Validity #### Strong reasoning - **Empirical evidence**: Cites Sonatype research on dependency count underestimation with specific statistics - **Systematic demonstration**: Provides concrete examples across six major ecosystems showing consistent tooling fragmentation - **Causal analysis**: Clearly explains how build environment, timing, and package manager configuration affect dependency resolution #### Fallacies - **Hasty generalization** (minor): Uses Amazon Linux 2 for all demos, may not reflect Windows/MacOS developer experience. Fix: Include cross-platform testing results. - **Appeal to complexity**: Implies problem is too complex for universal solutions without fully exploring emerging standards. Fix: Acknowledge ongoing standardization efforts while highlighting current limitations. #### Tone of voice - **Informative and practical**: Uses technical examples and specific tool recommendations - **Slightly overwhelmed**: Speaker acknowledges learning multiple ecosystems was challenging, creating relatability - **Solution-oriented**: Focuses on actionable tools and approaches despite highlighting systemic problems ### 🛡️ DARVO Analysis No DARVO patterns detected. The presentation focuses on technical challenges rather than interpersonal dynamics. The speaker acknowledges their own learning curve and technical limitations, demonstrating intellectual humility rather than defensive positioning. ## 🎯 Conclusion This presentation reveals a fundamental blind spot in modern software development: the dynamic nature of dependencies makes traditional SBOM approaches obsolete upon generation. The systematic underestimation of dependency counts (25 estimated vs. 400+ actual) creates significant legal and security risks that compound when software moves from internal use to distribution. **Practical next steps for readers:** 1. Implement continuous SBOM regeneration in your release pipelines rather than one-time generation 2. Audit your current projects using the ecosystem-specific tools demonstrated (pip-licenses, go-licenses, etc.) 3. Establish dependency governance policies that account for transitive dependencies and license compatibility 4. Consult with legal/OSPO teams before distributing software to understand compliance obligations 5. Train development teams on the hidden complexity of modern package management and its implications The core insight is that dependency management is not a solved problem but an ongoing operational challenge requiring systematic tooling and processes across multiple ecosystems. ## 🔄 Refactor Appendix — Six ecosystems, one problem: Why your SBOM is already broken ### 📚 Literature Atoms #### Developers underestimate dependency counts by 75-90% across all ecosystems > [!quote] ID:transcript_001 > Developers normally underestimate how many dependencies or how many packages that they are using. About quarter of the packages have about up to 25 packages per app. But for many extra large packages you are using over 400 packages per app. **Context & use**: - Research from Sonatype on actual vs. estimated package counts - Demonstrates systematic blind spot in developer awareness of transitive dependencies **Tags**: #software-dependencies #developer-awareness #sbom-management  #### SBOMs become stale immediately due to dynamic dependency resolution > [!quote] ID:transcript_002 > Dependencies aren't resolved in isolation. They are heavily dependent on your system. What time are you building your system? Dependencies also change over time and according to your system architecture. **Context & use**: - Explains why SBOMs created months ago are inaccurate today - Core technical reason why traditional SBOM approaches fail **Tags**: #sbom-staleness #dynamic-dependencies #build-environment  #### License compliance obligations escalate significantly with software distribution > [!quote] ID:transcript_003 > For open source projects distribution is the key. When you change from internal use to distribution that's when your compliance obligations go up, take a step up. **Context & use**: - Legal framework distinction between internal use vs. distribution - Why SBOM accuracy matters more for distributed software **Tags**: #license-compliance #software-distribution #open-source-legal  ### 🧠 Permanent Candidates #### Package manager fragmentation prevents universal SBOM generation **Claim**: Each programming ecosystem requires different tooling approaches for accurate dependency tracking, with no single solution providing comprehensive coverage across multiple package managers. **Evidence pointer**: [[#Developers underestimate dependency counts by 75-90% across all ecosystems]] **Scope & conditions**: - Holds across major ecosystems (Python, npm, Maven, Go, Cargo, Gradle) - Breaks when new universal standards emerge or tools achieve better interoperability **Links**: - [[Software supply chain security]] — because applies-in dependency management - [[Developer tooling fragmentation]] — because extends to SBOM generation - [[Multi-language project complexity]] — because evidence-for increased tooling overhead  ### ✏️ Fleeting Queue - SBOM freshness validation - how to detect when dependency tracking is stale? #fleeting #inbox - Cross-ecosystem license conflict resolution - systematic approach needed #fleeting #inbox - Container dependency explosion measurement - quantify base image vs application packages #fleeting #inbox ### → Things 3 - [ ] Research universal SBOM standards (SPDX, CycloneDX) adoption rates across package managers #things - [ ] Audit current project dependencies using ecosystem-specific tools mentioned in presentation #things --- # 📄 Full Transcript *Auto-generated from YouTube captions · timestamps roughly every 30 seconds · [watch on YouTube](https://www.youtube.com/watch?v=5HiiYoKfw8Q)* **[00:05]** So how many dependencies are there in your software? Uh how do you identify dependencies using tools and how do you generate attribution notices especially if you are distributing your software [snorts] uh types of software licenses. So I think here in this conference uh pretty much everyone I assume knows uh the open source part of it like you have your four freedoms and source code is accessible and you can use it for whatever purpose you want. But on the **[00:36]** other side uh as a user many times you are also able to download lots of commercial software. There are pure commercial software such as uh office uh then there is cuda and uh you might find some software with uh eula in it. On the other side you might find yourself if your vendor is supplying you some hardware drivers or some other code that may be coming with a condition that uh yes it is you are **[01:06]** free to use it as long as you are using their own hardware. where there might be some source available projects or there might be some business source license where your uh vendor might tell you uh that yes you can use this software as long as you are not competing with my core business then there are freeware shareware which are sort of not open source and then on GitHub as uh you will find lots of code uh that is just out there without any license **[01:37]** uh we that depends If you consider that can you consider that as open source uh the chance would be probably not. Now as you use the software uh your software will have some direct dependencies that you as a developer generally select or have control over it. But in many cases the software the dependency that you have selected have their own dependencies and uh those dependencies may have their own **[02:08]** dependencies. uh which are indirect dependencies. So you have your direct dependencies and then indirect dependencies and the tree goes on for quite a while. Now [snorts] how does this impact you as a developer? So you as a developer should know what you are using and what you are providing to your users, customers. Some cases your software may not require many of these dependencies but they may be present and uh uh license of all those dependencies may **[02:40]** impact your use of the software or may have and may have even larger impact on your distribution of your software. Say if you are using a software, if you are downloading a software that is under fairly permissive license and then you find out that one of the dependencies is say under a very restrictive license, your company's policy may prevent you from using those or uh if one of the dependency requires you to have a commercial license then at that point you might uh need to check **[03:13]** with your legal department to make sure that you have commercial agreement to use that particular license. security vulnerabilities in those uh dependencies that you are downloading or using may impact how you are using your software as well. Now this dependencies are not set in stone either they are dynamic and uh risk associated with their use uh changes const constantly. Dependencies aren't resolved in isolation. They depend on they are heavily dependent on **[03:45]** your system. What time are you building your system? Dependencies also change over time and uh they will change according to your system architecture. So if you are using say Windows or Mac system for your build uh during your run uh build but if your system is running on a Linux uh machine then your dependency tree might look completely different. Also if you are not pinning your dependencies then your dependency manager is going to decide which dependency version you are going to use. **[04:17]** Some of them say may even go nougat may end up using the older or stable version. uh whereas if you are going with mpm cargo or pip uh you are going with the latest version and the latest version may change with every avail whenever there is a newer dependency and uh whatever that dependency management whatever that dependency management may have decided on their end. **[04:48]** Dependencies come in different form. Uh you specify what dependency you are going to use with uh lots of different characters. Every package manager or dependency manager may have their own uh dependencies characters. Uh so here is an example for boto 3. Between two versions of boto 3, you can see that between version 1.35 and version 1.37 the S3 transfer agent change from 10.4 4 to 11.2 other dependencies did not **[05:20]** change but uh the SC transfer changed now if you're so for example if you for some other package you might be having some sort of similar situation I took the dependency from uh devs.dev dev Google manages that project I believe. Uh now how does this impact uh you as a developer? Uh sometimes license of this indirect dependencies can have have impact on license of direct dependencies that you are using and that may affect that may end up having some effect on **[05:51]** your project like uh this indirect dependencies are generally your developer or you may not be aware of what indirect dependencies you are pulling in your project. So if you are generating an Sbomb uh you might just think hey I'm using this five direct dependencies and that might be my Sbomb but uh when you are building and deploying your software you might be pulling in lot more that can come as a surprise uh they add a lot more complexity to your asp **[06:23]** will also get impacted by whether you are using this package as an internal it's an external package is the dependency that you are using is direct indirect like what time are you using uh if you build your software say 3 months ago you build your you created your sbomb 3 months ago and say one of your dependency was at 1.5 but uh when you build it today your one of your dependency might be at 1.7 and they may have or maybe 2.0 to and they may have **[06:54]** changed their dependency tree then the aswam that you created say 3 months ago may not be correct anymore more uh it will also depend on your uh environment which operating system you are running on or which hardware platform you are running on uh also sometimes your CI/CD tools might inject some dependencies many people use uh say for example chromium as a build system it's not using your build you might be using sometimes s built from an external system. So that might inject some more **[07:28]** dependencies that you may not be aware of or you may not be actively planning on. They might be injecting dependencies that you may not be planning to include. Now how do you limit the impact of all this uncertaintity? uh you need to make sure that you are conducting audit of your dependencies is uh ideally you should be using some sort of tools that will be like say npm check or maven dependency maven or griddle dependency plugins depending on the **[07:59]** language you are using you should also use package managers log file so at least you are your dependencies is and uh using so if dependency version of your dependency changes that does not throw that does not throw your dependency tree completely off. And uh if you are removing dependencies that you think are not probably useful or uh version change and you are not comfortable with it, uh make sure to test your project uh so that uh one of the dependencies don't **[08:30]** break your system. Uh this is the part where uh this is the report from sonotype and developers normally underestimate how many dependencies or how many packages that they are using. I think like about quarter of the packages have about up to 25 packages per app. But on the other side of it for many extra large packages you are using over 400 packages per app. We'll see sometimes docker containers that have over 10,000 packages in them. And like if you when you are pulling you **[09:01]** your docker image may have just a you might be just pulling say hey Ubuntu or Amazon Linux docker base image and then you are installing maybe 20 packages but those 20 packages may bring like up to that six or seventh order dependency and then you have a large package size and large as well. Uh this one is also from sonata type which basically says like how many package how many dependencies you get per for average package and you'll if you are using say npm your **[09:34]** average dependency count is fairly huge. Now does your project need all those dependencies? depends on your project but chances are uh when you are building your system and deploying it uh you are using many of those uh and not all those dependency manage uh your developers may know first order dependencies but may not know all those second order. Now this is the part where I want to very uh want to emphasize uh about this **[10:06]** disclaimer. Uh my presentation is not an advice on how to generate attribution notices. I'm just sharing best practices. Uh before you take any action, you should talk with your company's legal advisor or uh if your open source program office if you have one before you start acting on any of this uh any of the demo tools that I show. Uh for this particular presentation, I used Amazon Linux machine for my demo. So some of the **[10:36]** commands that you see are very particular for Amazon Linux uh Amazon Linux 2. Uh it might be different for your system. Uh with that disclaimer I'll move to the next part. [snorts] Uh now you can do uh there are different ways of identifying dependencies. Uh the easiest way would be when you are downloading say a project from GitHub or you have pulled it from uh one of the pip say pi or npm or whatever language you are using and you have the project **[11:08]** uh you can look into its requirements file or toml file sometimes toml file or package.json JSON and uh you can see as a developer you can see what dependencies your pro uh the project that you are using has declared uh and how many of those you think you might be using or you know what you are now getting yourself into. However, uh this manual process gets **[11:40]** cumbersome very quickly. So people should use package managers to reduce manual work. OSS package managers will generate some sort of sbomb and generally they will allow you to use uh common sbomb formats such a cyclone dx or spdx. They will rely on package manager metadata. They will help you generate package inventory generally in it generally all the packages in the same package ecosystem that you are **[12:11]** using you are installing using the package manager and because this package manager has all the information that is easily diss uh that it was able to acquire uh assuming that the original developer who created this metadata to an extent it identified them correctly uh it will based on that information it can create an attribution document for you. A few examples of this package managers for native uh for native languages like **[12:43]** pip for python. Then you have npm maven go license for go or then you have uh sift uh that is uh for docker images just and sometimes uh those p uh say for docker images. Swift will also use many of this same native package managers as part of uh its uh when as part of its data collection. Another one is Trivy that I not mention **[13:15]** here [snorts] uh that is also pulling that runs uh say other package managers underneath as well. But sometimes they work uh so especially like say for go license for go you have to run go license inside your docker image to get the proper metadata otherwise your go packages might just get listed but you don't have it license information. So you want as a developer you want to also check your aspiration notices that you are getting generated **[13:47]** uh you should review it for complete uh for completeness. Uh no tool is perfect. Uh all tools have their own limitations and as a developer uh you should know what tool you are using. Here's an example of how you uh how I generated attribution for p uh python packages. Uh so for uh python I installed cyclone dx bomb and pip licenses and I generally like to see things in an excel format. I **[14:17]** use excel on my computer. So I like to get output in CSV format that I can filter out with Excel. Uh so with pip uh when I install pip uh so you can see the dependency graph of uh cyclone dx here it's fairly large. It does pull in some packages that you don't expect. It takes some trial and error to understand that hey what sometimes when you're running pip licens it it's also scanning what you have installed to generate the **[14:47]** icebomb and that comes out as a surprise. uh also install pip license and uh the CSV wicket on Amazon Linux 2. Uh once they are all installed or you run pip license, it will basically provide you it will provide you information about what packages you have and what licenses uh they are pulling, what licenses there are. And as I mentioned, I like to see Excel output. So I generate uh things in an Excel. uh because I was running **[15:17]** Amazon Linux instance, I just used very small snapshot of this uh Excel file or CSV file. Uh there you can see all the licenses in one of the columns. It makes it easy. Uh if you are familiar with Excel, you can filter out lots of this output and uh you can focus on packages that you are interested in or licenses that you are uh curious about. That's for the Python. Uh the somewhat **[15:50]** similar action I also did for npm. Uh there also I used the npm cyclone DX package and uh for that I had to install npm and uh which npm license I was uh license checker and then again CSV output for that. uh here in the Linux system I uh when I was trying to get uh uh npm I installed CSVKit with pip 3 and **[16:21]** uh when I see this packages now because I'm running npm as a license checker it may not necessarily capture the CSV kit uh that's on the system because the package manager is limited to the system that you that it is controlling. So if you are using multiple uh package managers to install items on your system, you might want to use more than one package manager to know what your final output is. Uh similar things for MVN package. Uh **[16:54]** here for example, I use uh common lang. Uh I'm not as familiar in the maven ecosystem. So I had to uh one of my PE wrote a particular script uh one of my engine uh one of uh the person on my team wrote a script uh that I copied in its pom.xml and uh then I built the pom package and it created uh uh it created uh bomb.xml **[17:25]** for this particular package. Once I had bomb uh I had to go and convert uh that bomb into legal notices. Uh so I had to use another set of uh commands and I had to use another repo uh that is this GitHub repo for OSS attribution sample apps and uh using that I was able to generate I was able to convert uh the notices from bombax mail into a legal notices text uh that **[17:58]** you can distribute with your project. uh if you are using it for internally then bomb.xml XML is sufficient enough for you. But as many of you know for open source projects uh distribution is the key. When you when you cut when you change from internal use to distribution that's when your uh uh compliance obligations go up uh take a step up. Uh now for I also use go packages uh to **[18:29]** install for to generate attribution for go. Uh here I use uh the air project from Go uh one of of more popular Go projects and uh you can see that it has a fairly complex uh dependency management uh dependency graph uh on Amazon Linux. It was a little bit tricky for me to install Go. Uh I'm not a software engineer. So I used uh AI tool to learn all these languages. Um so **[19:01]** and I did some iterative works to make sure that uh I was able to install uh this all this package managers. So first I had to install go on my system. Once I had uh Go running and I was able to install I also I installed Go licenses and uh again CSV wicket uh to generate my clean output and uh air pack air package. Uh once I had those installed I was able to **[19:31]** generate a license CSV file here as well. Uh that allowed me to see. Now funny thing about go is that if you are say running it inside say some container the container package manager container manager such as a sift or may not be able to pull go license information. So this is uh I might have to repeat the same process inside a container to see how you can actually use that **[20:02]** uh the same. Sure. >> Uh it was one of the more popular uh Go packages. I did not know about it. >> That was just an example. Yeah. uh I was trying to figure out what kind what package I can use and because I work in open source program office so I went and check hey what is the more popular package in each so for Golang uh so for this one it was air for May one it was common lang three I was able to **[20:34]** correct solves like and it also depends what I can install on my system that is all so with given my technical ability what I can install so I try to keep it simple I'm sure there are a lot more complex projects that people can try but uh for me that for the basic demonstration this worked out. Yep. Uh one of the sorry that was I went back. Okay. So for uh cargo the package that for example package I use was foundry uh and you can see it has fairly **[21:06]** complex uh again dependency graph and uh again because my system was a clean Amazon Linux machine and I had to install Rust and Cargo on them on that machine and and once I had installed that I had to add uh this particular section here on uh shown on the right on uh in the aboutml **[21:36]** once I had that and uh I had cloned the foundry I was able to generate a license HTML file for it uh in this particular case I had to write another script uh to convert that HTML into an excel so that I can see the file I can see the license of packages fairly easily but because I had toml and I knew what packages the the system was building in it was somewhat more acceptable uh easier uh notices but **[22:08]** uh sometimes the package managers don't necessarily give you output in an Excel output that I prefer but uh you might get a JSON output uh that you might be able to use as well. Uh the next uh package manager I used was Gradel. Now for gradel I had to install in my system Java Gradle and Kotlin as well to run my demo project. Uh so once I was able to install uh Gradle uh I **[22:41]** built a simple demo Gradel app and uh with that demo Gradle app uh because I am not a good programmer. I had to write down which options I selected for this basic app. And uh once I was able to create the app app, I added a tiny script to my uh griddle KTS. Uh believe that this is the part uh that I added. **[23:15]** Uh yes, this is the part that I added to my Gradle script and uh that allowed me to build a bomb.xml for the uh for my demo project and once I had my demo project, I again went to this OSOS attribution sample uh repo on GitHub and uh use bomb to notices to convert uh this bomb into a legal notices file. Uh **[23:47]** again here because the way I had installed packages on my system, my reports were in a completely different directory and compared to where I was copying my uh repo for uh creating asbomb and once I had converted the notices again here I was able to generate notices in a text file uh that I use a different script than to convert convert it into an Excel output. **[24:20]** Right now, generating attribution notices for Docker images. Many of you might be using Docker containers or some other form of containers for what for your use. Uh here I'm showing how to use SIFT. Uh that's open source tool that anchor offers is uh here also use cyclone DX. uh swift output is in JSON and uh it's with cyclone DX it's in Cyclone DX **[24:51]** format uh I converted that into CSV as well uh so I can work in Excel and see the output now in my particular case because I was running this in uh Amazon Linux 2 dev uh desktop I had to install docker compose saved Java uh Cyclone DX and CSV wicket uh to see the output as well. U I did not have a readym made docker **[25:23]** file. Uh so to test the project uh to test if the shift gives me a proper output. This was like one of the example docker file we have created it did. It adds com lot more. It adds a little bit more complexity to B uh image and uh then basically I had to build a docker image. Once I had docker image built uh normally because sometimes you might **[25:53]** have multi-state docker image uh and if you're running on a live docker image you may not be able to get all the layers you may not be able to get all the information. So we normally so I would export it into a tar file so that uh all the information is sort of captured and then I run sift uh I I run sift scan to get a JSON output and once I have the JSON output then I can convert that into an Excel uh that I can test uh that I can see with uh with **[26:26]** Excel. Next is my conclusion for the talk. Now software does come under lots of different licenses. Uh we need to ensure that you as a developer need to ensure that you are complying with the terms um uh software also comes with lots of direct and indirect dependencies is you want to make sure that uh you have identified correct dependencies that you are using. Uh also dependencies change wherever uh **[26:59]** when how you are using them when how your software is being used. U again with disclaimer you should use package managers to generate package inventory and uh if especially if you are distribute your if you are distributing your software uh you can use the same package managers to generate attribution notices.