SBOM and SAAS - Google Docs  ## Metadata - Author: [[google.com]] - Full Title: SBOM and SAAS - Google Docs - Category: #articles - Document Note: --- tags: - #sbom - #saas - #cloudsecurity Author: CISA SBOM Cloud Working Group (facilitated by Allan Friedman; co-chairs: Deanna Medina, Ricardo Reyes; contributors from AWS, Google, Microsoft, ServiceNow, GoDaddy, Honeywell, Dell, HPE, Deloitte, etc.) Source: Google Doc (SBOM and SaaS white paper draft) Reference: https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/edit date created: 2025-08-22 00:00 --- # Title: SBOM and SaaS — Toward Practical Transparency for Cloud Applications ## Table of Contents: - [📚 Introduction](#-introduction) - [🎯 Purpose and Objective](#-purpose-and-objective) - [🧱 Scope and Out-of-Scope](#-scope-and-out-of-scope) - [🧩 Definitions and Shared Responsibility](#-definitions-and-shared-responsibility) - [🔀 SaaS vs. Non‑SaaS: What’s Different, What’s the Same](#-saas-vs-non-saas-whats-different-whats-the-same) - [🛡️ SaaS Cloud Security Considerations](#-saas-cloud-security-considerations) - [🧰 Use Cases for Producers, Choosers, and Operators](#-use-cases-for-producers-choosers-and-operators) - [🔗 Sharing Models, Requirements, and Alternatives](#-sharing-models-requirements-and-alternatives) - [🧾 Illustrative Procurement and Operations Scenarios](#-illustrative-procurement-and-operations-scenarios) - [🗒️ Notes](#-notes) - [📖 References](#-references) - [🗣️ Paraphrase](#-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items (Advocacy & OSPO Alignment)](#-action-items-advocacy--ospo-alignment) - [🧪 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) - [🔍 SEO Evaluation](#-seo-evaluation) - [🎯 Conclusion](#-conclusion) ### References: - CISA SBOM program overview: https://www.cisa.gov/sbom - CISA SBOM Sharing Lifecycle Report: https://www.cisa.gov/resources-tools/resources/software-bill-materials-sbom-sharing-lifecycle-report - NTIA SBOM Use Cases, Roles, Benefits (2019): https://www.ntia.gov/files/ntia/publications/ntia_sbom_use_cases_roles_benefits-nov2019.pdf - NTIA Framing SBOM (2019): https://www.ntia.gov/files/ntia/publications/framingsbom_20191112.pdf - MVSP framework: https://mvsp.dev - OpenVEX: https://github.com/openvex - CISA Minimum Requirements for VEX (PDF): https://www.cisa.gov/sites/default/files/2023-04/minimum-requirements-for-vex-508c.pdf - CycloneDX VEX: https://cyclonedx.org/capabilities/vex/ - JupiterOne public SBOM example: https://www.jupiterone.com/sbom - SAFECode whitepaper: https://safecode.org/wp-content/uploads/2017/05/SAFECode_TPC_Whitepaper.pdf - EU Cyber Resilience Act overview: https://digital-strategy.ec.europa.eu/en/library/cyber-resilience-act ## 📝 Summary: This working paper explores how Software Bills of Materials (SBOMs) apply to Software as a Service (SaaS). It frames transparency as a means to improve security, procurement, and operations; narrows scope to the application layer; and contrasts SaaS with packaged software. Key points: - SaaS changes continuously and boundaries are less obvious, complicating static SBOM snapshots (see “Why is SaaS different…”). - Despite differences, core SBOM needs remain: understanding components, vulnerabilities, and risk posture (see “Why SaaS is not really different…”). - Use cases span producers, choosers (procurement), and operators, emphasizing automation, governance, and third-party risk. - Sharing models range from on‑demand SBOMs to asserting SBOM‑like capabilities; VEX is promising but scoped out for now. - The paper calls for clearer definitions, automated tooling, and practical recommendations aligned with regulatory trends. ## 📖 Main Content: The document positions SBOM as foundational for transparency in cloud applications. Transparency is instrumental—enabling vulnerability triage, license/risk analysis, and operational accountability—especially in B2B SaaS. The scope is intentionally limited to application-layer components owned by providers and third-party dependencies, excluding underlying infrastructure, customer extensions, and development toolchains. SaaS differences include continuous deployment, opaque internals, and evolving boundaries, which hinder traditional “fixed product + fixed SBOM” models. Even so, both SaaS and non‑SaaS share SDLC concerns, third-party/OSS dependencies, and regulatory obligations. The authors advocate for automation to make SBOMs actionable at SaaS scale, and they highlight trust‑but‑verify dynamics while acknowledging current tooling immaturity. Use cases: - Choosers: static SBOM snapshots in procurement to assess deprecated components, known vulns, end‑of‑support, licensing posture, and technical debt. - Operators: updated SBOMs for monitoring remediation speed, auditor inquiries, shared responsibility mapping, SLA checks, and integration hygiene. - Producers: similar needs across delivery models, but with more emphasis on DevOps/DevSecOps automation. Sharing approaches include public SBOM exemplars (e.g., JupiterOne), lifecycle guidance from CISA, and possible “SBOM‑like capabilities” when raw SBOMs aren’t practical. VEX is identified as a key adjunct for expressing exploitability and mitigations, though detailed guidance is deferred. The paper recognizes unresolved issues: definitions of SaaS scope, minimum requirements for SaaS SBOM, pros/cons of on‑demand models, and how to balance component vs. vulnerability‑first communication. ### 🗒️ Notes - Introduction and framing - Transparency is a means, not an end; benefits producers, choosers, operators; extends beyond security to efficiency. - Historical context: machine‑readable component transparency since 2011; growing consensus and policy adoption. - Purpose and objectives - Provide an overview of SBOM in SaaS; inform decisions; set market expectations; defer deep implementation to future work. - Scope and exclusions - In-scope: application-layer components (provider-owned + third-party, including OSS) affecting customer/data. - Out-of-scope: hardware, networking, virtualization, customer plugins/custom code, dev tools/artifacts. - Definitions/Shared responsibility - Emphasis on consistent terminology (SaaS vs. non‑SaaS/packaged/provider‑ vs. customer‑managed). - Shared responsibility models referenced (e.g., Azure/AWS patterns). - Why SaaS is different - Continuous change; customer lacks control/visibility; boundaries fluid; polling needed for local SBOM currency. - SaaS has more mitigation levers (e.g., rapid payload blocking) that don’t alter SBOM state. - Why SaaS is not different - Same need for component visibility, SDLC rigor, and regulatory compliance. - Similar organizational/data risks; both can be large, integrated, and OSS‑dependent. - Security perspective - SBOM is foundational; manual review doesn’t scale; tooling must evolve; trust‑but‑verify ethos persists. - Other considerations - Shared concepts: VPC, block storage, CI/CD, network architecture, and shared environment realities. - Use cases - Choosers: snapshot SBOM at decision time; analyze EoL, vulns, OSS project health, licensing, tech debt. - Operators: regular SBOM updates for response verification, audit queries, SLA adherence, integration/identity/network needs, backups/availability, performance tuning. - Producers: automation-friendly tracking across DevOps/DevSecOps. - Sharing and requirements - CISA SBOM Sharing Lifecycle guidance; JupiterOne’s public SBOM as an example. - NTIA baseline attributes; evolving regulatory posture (e.g., EU CRA mentions). - Alternatives: assert SBOM‑like capabilities; on‑demand SBOMs; component management as a service; formatted service bulletins; VEX for exploitability. - Open issues and editorial notes - Need better SaaS definition; clarify “requirements vs. recommendations”; articulate pros/cons per path. - Licensing debate: limited direct consumer impact in SaaS, but choosers’ legal - Summary: The content is not available and cannot be summarized. - URL: https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/edit | | | | --- | --- | | SBOM and SAAS | [Meeting Notes](https://www.google.com/url?q=https://docs.google.com/document/d/1WPuxHyGhZZR21mZHf8y0hT9_Nq7RCiS7wA7ompz3L-Q/edit&sa=D&source=editors&ust=1738674511478175&usg=AOvVaw1Jin-kAPi0N7DJ60GSIeUq) |  New Document: [https://docs.google.com/document/d/1\_yQgLhOEw-H5w9Dr3XbNYIIX8vLs59IJwLvJm4aHDVY/edit](https://www.google.com/url?q=https://docs.google.com/document/d/1_yQgLhOEw-H5w9Dr3XbNYIIX8vLs59IJwLvJm4aHDVY/edit&sa=D&source=editors&ust=1738674511425665&usg=AOvVaw33RSL4E3VeTpzPycbkawsV) References (for writing purposes): * [CISA Community SBOM Cloud - Running Notes](https://www.google.com/url?q=https://docs.google.com/document/d/1ZpTtsY0H2SwfNRq6qUzLMiWLQ8OwlhmJeg_M0cxrOiQ/edit&sa=D&source=editors&ust=1738674511426543&usg=AOvVaw1OMiDAlsMvHJTCiFysNhXC)[[a]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt1) * [https://www.cisa.gov/sbom](https://www.google.com/url?q=https://www.cisa.gov/sbom&sa=D&source=editors&ust=1738674511427084&usg=AOvVaw25mdnmh01_VZvpe7HCs_xC) * [NTIA SBOM Minimum Elements](https://www.google.com/url?q=https://www.ntia.doc.gov/files/ntia/publications/sbom_minimum_elements_report.pdf&sa=D&source=editors&ust=1738674511427526&usg=AOvVaw1GyMaZ-0kFjixHS_s4aW0b) * [SBOM At A Glance](https://www.google.com/url?q=https://ntia.gov/sites/default/files/publications/sbom_at_a_glance_apr2021_0.pdf&sa=D&source=editors&ust=1738674511427924&usg=AOvVaw3rq0eE31INmoHqeoUMv4Mn) * [SBOM Attestation Common Form](https://www.google.com/url?q=https://www.regulations.gov/document/CISA-2023-0001-0001&sa=D&source=editors&ust=1738674511428333&usg=AOvVaw0uNXXVcQSgoc1vIubAExAQ) * [CISA SBOM Sharing Pape](https://www.google.com/url?q=https://www.cisa.gov/resources-tools/resources/software-bill-materials-sbom-sharing-lifecycle-report&sa=D&source=editors&ust=1738674511428718&usg=AOvVaw1ZszMN930bdxuepJEs7fg-)r * SBOM Cloud White Paper: [Service Transparency](https://www.google.com/url?q=https://docs.google.com/document/d/1t_J7wPoGgnIShDVu1iWOMLotchtJJ_0iMChUREnxkvc/edit%23heading%3Dh.6p7htxk7enf7&sa=D&source=editors&ust=1738674511429099&usg=AOvVaw3rQO7otRre43GnJB4lHeNQ) * [Article: SaaSBOM](https://www.google.com/url?q=https://www.csoonline.com/article/3632149/the-case-for-a-saas-bill-of-material.html&sa=D&source=editors&ust=1738674511429493&usg=AOvVaw0VBlFktPOBfmCmOTIqD3bE) * Shared responsibility in the cloud ([Microsoft](https://www.google.com/url?q=https://learn.microsoft.com/en-us/azure/security/fundamentals/shared-responsibility&sa=D&source=editors&ust=1738674511429888&usg=AOvVaw38Y4HY7e2Q4xomDGHbOfDe) and [AWS](https://www.google.com/url?q=https://aws.amazon.com/compliance/shared-responsibility-model/&sa=D&source=editors&ust=1738674511430127&usg=AOvVaw1CspuYTtLe26Qo8CiXLGrs)) * [Slidedeck for SBOM-a-rama](https://www.google.com/url?q=https://docs.google.com/presentation/d/13Zh8BsR_WWKdH02JistuoRYL8hMTzXfO/edit%23slide%3Did.p4&sa=D&source=editors&ust=1738674511430473&usg=AOvVaw3BE2ERDQf-zH6X3fgtbmmK) * We do have good responses to the “[why SBOM doesn’t help attackers](https://www.google.com/url?q=https://ntia.gov/sites/default/files/publications/sbom_myths_vs_facts_nov2021_0.pdf&sa=D&source=editors&ust=1738674511430873&usg=AOvVaw3t8qs9Ms9DblsEZ-wGcYKn)” [Introduction](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#h.wth87sgfybto) [3](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#h.wth87sgfybto) [Purpose](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#h.yqpg3m66tsa5) [3](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#h.yqpg3m66tsa5) [The goal of transparency](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#h.s8uarmqcqkk0) [3](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#h.s8uarmqcqkk0) [Objective](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#h.m37tztyyfgq8) [3](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#h.m37tztyyfgq8) [Scope](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#h.1o9bzyom85mn) [4](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#h.1o9bzyom85mn) [Out of scope](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#h.1hzlra6th3yb) [5](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#h.1hzlra6th3yb) [Definition of SaaS](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#h.7fa6fqwezn06) [5](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#h.7fa6fqwezn06) [Shared Responsibility Models](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#h.ettd47mcwpw) [6](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#h.ettd47mcwpw) [SaaS vs. Non-SaaS](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#h.hir0phy3wp0m) [6](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#h.hir0phy3wp0m) [Why is SaaS different with respect to SBOM](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#h.uyooijaqb150) [6](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#h.uyooijaqb150) [Why is SAAS not really different with respect to SBOM](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#h.g1et7bnutrtx) [7](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#h.g1et7bnutrtx) [SaaS Cloud Security](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#h.vhrdv5kt2lv) [8](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#h.vhrdv5kt2lv) [Other considerations](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#h.xekz62lxh5l1) [8](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#h.xekz62lxh5l1) [Use Cases of SBOM for SaaS](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#h.o360o1ci9hwt) [9](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#h.o360o1ci9hwt) [SBOM for SaaS Sharing](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#h.ze0oepfhejnp) [10](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#h.ze0oepfhejnp) [Requirements](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#h.bafdcott5m27) [10](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#h.bafdcott5m27) [Recommendations](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#h.avhg7n4121ip) [11](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#h.avhg7n4121ip) [Alternative Directions](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#h.710f6npgmmm9) [11](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#h.710f6npgmmm9) [Asserting SBOM-like capabilities exist](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#h.mssvil8sgxvo) [11](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#h.mssvil8sgxvo) [Snapshot of SBOM when making procurement/contract decisions](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#h.xa5ztgns2i09) [11](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#h.xa5ztgns2i09) [On Demand SBOMs](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#h.y633zjlt0xli) [11](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#h.y633zjlt0xli) [Component Management as a Service](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#h.awibwa2hy46h) [12](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#h.awibwa2hy46h) [Formatted Service Bulletins](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#h.no8szu2yrcaf) [12](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#h.no8szu2yrcaf) [VEX for SaaS](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#h.gu27mglen4d7) [12](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#h.gu27mglen4d7) [Why are we doing this?](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#h.wct5qirsp6wo) [13](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#h.wct5qirsp6wo) [Acknowledgements](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#h.kmy1bt9cdz85) [13](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#h.kmy1bt9cdz85) [Parking lot of important issues](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#h.nj560c670ebz) [14](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#h.nj560c670ebz) [Appendix — use cases](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#h.y94r9fnkswkv) [15](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#h.y94r9fnkswkv) [Illustrative use case — ”Choosing SaaS Software”](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#h.n88kvi2oe205) [15](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#h.n88kvi2oe205) [Illustrative use case — ”Operating SaaS Software”](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#h.b606oqlf1ock) [15](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#h.b606oqlf1ock) General observations and feedback from Cloud Providers (Isaac, Henri, Adrian, Craig): [[b]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt2) 1. Better definition of SaaS 2. Clear objective or mission statement 1. Discuss what is the problem that we are trying to solve? (open) 2. Provide use case, [document](https://www.google.com/url?q=https://www.ntia.gov/files/ntia/publications/ntia_sbom_use_cases_roles_benefits-nov2019.pdf&sa=D&source=editors&ust=1738674511435999&usg=AOvVaw2mcdnitSEB01PNNHde2dhe) (open) 1. Operating - a few use cases[[c]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt3)[[d]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt4) 2. Perhaps walk through one or two end-to-end examples of SaaS SBOMs providing value to a software consumer? See also: [this comment](https://www.google.com/url?q=https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/edit?disco%3DAAAA0kEpY18&sa=D&source=editors&ust=1738674511437050&usg=AOvVaw1u-sFQWQihGM4OsPGXOHVC), and [this one](https://www.google.com/url?q=https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/edit?disco%3DAAAA0kEpY2c&sa=D&source=editors&ust=1738674511437489&usg=AOvVaw1D56E-ayom9drp9i3lV8jB) 3. Chooser - focus on Selecting a Software (SaaS) selection? Most of the content will come from here 4. Producer 3. Can we answer: SBOM for SaaS what does that mean? 1. When does the SBOM for SaaS matter? 4. Why is SaaS being called out? - hypothesis - Allan wanted to carve out an upper layer of the “everything cloud/proprietary service” space. So - what are descriptions for that upper layer; is our struggle trying to have SaaS refer to that vs other uses. 5. Henri: One top layer I often look at is “customer wanted product P and a provider to host that product”, rather than using a product owned by a provider. For example, Wordpress or MySQL hosting from a provider. 6. Proactive approach, compliance: Industry and government standards, provide metric data that help organizations make informed decision based on SBOM ### Introduction #### Purpose[[e]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt5) In an era marked by growing cybersecurity concerns and the widespread adoption of cloud-based solutions, this paper intends to provide a grounded understanding of the importance and implications of two critical concepts in modern software development and delivery: Software Bill of Materials ([SBOM](https://www.google.com/url?q=https://www.ntia.doc.gov/files/ntia/publications/sbom_minimum_elements_report.pdf&sa=D&source=editors&ust=1738674511439201&usg=AOvVaw0MAD4MwlxsTgt9OgMJ8lfL)) and how it pertains to Software as a Service (SaaS). Understanding these concepts is paramount for organizations seeking to enhance transparency, security, and efficiency in their software supply chain.[[f]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt6) ##### The goal of transparency[[g]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt7)[[h]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt8) Tracking the use of third party components in software is not a new idea.[[1]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#ftnt1) A machine readable standard has existed since 2011, focused on software licensing.[[2]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#ftnt2) A shared vision of machine-readable SBOM data has evolved, found some consensus, and is becoming a standard part of software, marketplaces, and policy. Transparency is not a goal in itself, but a means to several ends. The benefits of greater software transparency accrue to a range of actors and roles in the software ecosystem. One framing of use cases was documented in 2019, laying out benefits for producers of software, choosers or buyers of software, and operators of software, as well as increasing the overall resiliency of the software world.[[3]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#ftnt3) The benefits include identifying vulnerable components/libraries, risk factors, and fortifying the software ecosystem against potential threats, but also extend beyond security to improving efficiencies. Much of these discussions focused on on-premise software, but many of these also apply to the SaaS ecosystem. These are explored below in <<Section>> #### Objective [[i]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt9) The goal of this paper is to provide an overview of what SBOM means for SaaS. The main objective is to provide readers with the knowledge and insights necessary to make informed decisions, and strengthen their approach to software development and procurement, potentially helping to set market expectations while acknowledging the unique features of modern software. The goal is not to provide detailed implementation guidance at this stage; but we do recommend more work to be done for implementation.  Figure #: SBOM and SaaS in the Cloud Focus #### Scope Software that is considered in scope for this document operates solely at the application layer of the SaaS hosted in the cloud and on-prem[[j]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt10)[[k]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt11)[[l]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt12)[[m]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt13)[[n]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt14)[[o]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt15)[[p]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt16). The components that are in scope are similar to how a software producer would build an SBOM for non-Saas software, and are covered under existing guidance and advice for SBOMs. Thus, it would address the components developed and owned by the SaaS provider, third-party libraries and components, including open source packages and relevant dependencies that could affect the security of the consumer of the SaaS product. (A more complete attempt to define SaaS is below.) Even the broad range of devices, embedded systems, and OT (Operational Technology) often have cloud management services that would be in scope. Other, related work, is advancing our understanding of service dependencies and the full stack implementation of cloud platform, but these are out of scope for this document. Like other transparency discussions, the scope of this document will highlight the relationship between the SaaS provider and the customer. We further constrain this to B2B-type relationships, rather than individual end users. Lastly, the goal is not to provide general guidance for software development to SaaS providers–many of those exist–but to focus on software dependencies and transparency. #### Out of scope [[q]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt17)[[r]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt18) SaaS solutions can be very large and complex, spanning hardware, firmware and software. These services often rely on the integration of other best of breed services. In order to make this overview more manageable, this paper is constrained to the application stack, which is generally the application services directly affecting the customer and their data. The underlying infrastructure like the hardware, networking components, and virtualization components[[s]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt19) are outside of the scope of this exploration of SaaS applications and SBOM. If a SaaS allows for customizations or extensions through plug-ins, modules, or custom code development by customers, it is considered out of scope. This initial treatment will also not address development tools and artifacts, as well as common concerns around SBOMs for the broader software landscape.[[4]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#ftnt4) #### Definition of SaaS[[t]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt20) Some definitions of Software-as-a-Service (SaaS) center on the locus of deployment, contrasting “SaaS” or “Cloud” software with “on-premises” software. NIST’s 2011-era “The NIST Definition of Cloud Computing” ([SP-800-145](https://www.google.com/url?q=https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-145.pdf&sa=D&source=editors&ust=1738674511444433&usg=AOvVaw08WUfplL6V2AkDbvQcMZWM)) takes this approach, although notably in the cloud-native context of a narrow contrast between “SaaS” and “PaaS” and “IaaS[[u]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt21)[[v]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt22)”. In this document we orient instead around the defining aspect that SaaS is not customer-managed; it’s provider-managed. With this framing in mind it’s worth noting that SaaS can be deployed on-premises (e.g., a managed appliance mounted in an office rack) and non-SaaS can be deployed in the cloud (e.g., a customer-managed VM or cloud project).  Figure # — the defining characteristic of SaaS is that it is provider-managed For the purposes at hand we use SaaS to mean software whose deployment, support, management, maintenance, and the entire Software Development Life Cycle (SDLC) is controlled by a supplier external to the consuming organization; typically such software is hosted in the cloud by the service supplier. We contrast with “packaged” non-SaaS software which is delivered as executable bits and bytes for the customer to deploy and operate — either in the cloud or on-premises. ##### Shared[[w]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt23) Responsibility Models This model spreads responsibility for risk management between software vendors and consumers. While software vendors are responsible for the quality of code in their applications, software consumers are responsible for managing third-party risk from their software vendors, as they take on risk in the event of a software supply chain attack. As such, in terms of a relationship to managing SBOMs within a software supply chain, software consumers are responsible for enforcing transparency from their third-party software vendors. In turn, software vendors are responsible for supplying that transparency via the timely delivery of an SBOM. #### SaaS vs. [[x]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt24)[[y]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt25)Non-SaaS [[z]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt26) The focus of this white paper is to understand the application of SBOM to SaaS applications. We first explore what is different, and what is similar. While there are some unique aspects to SaaS as defined above, at the end of the day, we are still talking about software with dependencies. ##### Why is SaaS different with respect to SBOM[[aa]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt27) [[ab]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt28) SBOM files define the software componentry for a fixed software product. When the control of a software product is transferred from vendor to consumer, the consumer can store a specific SBOM file for the product in their SBOM management system. Whenever a new version of the software product is ingested, the SBOM file for the product must be updated in the SBOM management tooling. SaaS systems are frequently changing and the change is outside the control of, and often not visible to, the customer. They often deploy continuously, potentially pushing code multiple times a day with small engineering changes made each time. The consumer would need to continually poll to maintain a valuable local SBOM state. Additionally, their boundary is not as intrinsically defined as a packaged software product, no widely accepted definition exists yet SaaS systems are typically part of a larger ecosystem of associated services and tools so they have more options available when applying security mitigations. For a very simplistic example, a SaaS system may resolve a remote execution issue in a component by rapidly stopping all inbound traffic from including the exploiting payload. [[ac]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt29)This form of mitigation is likely to be much faster to deploy than component updates, and would not affect the state of any SBOM. Lastly, SaaS systems are, by their nature, opaque as to their implementation. A packaged solution may be analyzed to determine its composition. A SaaS system does not typically offer this affordance. ##### Why is SAAS not really different with respect to SBOM [[ad]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt30) Fundamentally the need for an SBOM is the same for SaaS as for non-SaaS. As a consumer of the service, you want to understand the components that are used in the service. This information provides the consumer greater visibility to answer questions such as, is a particular component in the service impacted by a specific security vulnerability. Whether on premise, remote, or in the cloud, responsibility for the solution operations can be shared between a provider and a consumer. [[ae]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt31) Both of these approaches support large and complex solutions and are likely to have a supply chain that utilizes 3rd party components (code or services), including open source software (OSS) including all the risks associated with the supply chains. Further, each of these solutions may be a component used in another solution, though this is more likely with SaaS. When considering the development process, both approaches can be supported with a similar software development life cycle * Both can be large projects[[af]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt32) * Both can be integrated into other products * Both have supply chains that often rely on third party code and OSS * In addition to the software there are similar organizational risks associated with the data storage and security. * Internal software development processes might be the same * The need for secure development practices, auditability and any regulatory requirements are the same for both. * The need for shared, role based access with granular controls is the same but the scale and the need for a federated model is going to drive additional SBOM requirements. * Concerns about sharing data on our supply chains * Human safety * Confidentiality of trade secrets * Regulatory requirements #### SaaS Cloud Security[[ag]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt33)[[ah]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt34) Security is always a shared responsibility between the provider and consumer. The nature of most SaaS offerings hides the internals of the solution from the consumer and increases the security responsibilities of the provider. This generally results in well-defined APIs that are provided to the consumer but the internals are opaque. In a perfect world the provider would rapidly fix all known security issues and the consumer would have total trust in the provider. However, businesses are pushed by the need to generate revenue, which often prioritizes new functionality over remediation. An SBOM provides consumers with greater transparency into the composition of the service. A common example for the use of an SBOM is in the case of a critical vulnerability where the consumer can analyze the SBOM to determine whether a solution is using an impacted version of a particular component. While this simple case is very important, its applications are rather limited. Provider SBOMs are likely to be large and complex and a manual process does not scale. The SBOM is a necessary foundational information component. However, to recognize its full potential automated tools are needed for this approach to mature and recognize its full potential. As in many aspects of security, a trust but verify approach is required. Today we have emphasis on trust because the tooling available is still evolving. #### Other considerations[[ai]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt35) * The cloud provider supply chain and the consumer need to have some shared concepts and understandings * VPC, block storage * Advanced software uses a similar set of tools * Have a shared view of pieces of our infrastructure * CI/CD * Network architecture guidance since by definition this is a shared environment.even when placed within an isolated network environment. ### Use Cases of SBOM for SaaS[[aj]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt36) As noted in the introduction, the benefits of SBOM can accrue across multiple roles and multiple points in the marketplace. The above discussion on the differences and similarities of SaaS helps guide the analysis of use cases. There are several clear differences. For example, the user of a SaaS would not be able to patch a vulnerability themselves, since they don’t manage the software. However, there are still important considerations for the operator of software, including understanding their own risks and their own accountability and compliance requirements of a potentially vulnerable service. The use cases below would not apply to all SaaS market contexts, but do help understand the landscape of how transparency can make the overall market for security more efficient. One framing of use cases, introduced above, is to look at the producers, choosers, and operators[[ak]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt37)[[al]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt38) of software.[[5]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#ftnt5) The use cases for software producers are largely similar, regardless of how the software is managed. <insert examples from doc> In fact, given the rapid pace of modern application development, and modern practices including DevOps and DevSecOps, tracking components with automation-friendly data is even important. The phase of choosing[[am]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt39)[[an]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt40) software applies to the decision process around deciding whether to use a SaaS provider. This decision would be made at a point in time, so the SBOM would be a static snapshot[[ao]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt41). Since the SaaS provider will be accepting a greater share of risk to protect the potential customer, understanding the potential risks in the providers’ systems is a natural part of the decision process to address concerns and due diligence about protecting company and customer data that the SaaS provider might be responsible for. SBOM data can support this decision in a number of ways beyond just checking for known vulnerabilities. Automated analysis can surface questions about risks from end-of-life or end-of-support versions, or risks from OSS projects with insufficient support. SBOM data can also be used in analysis around technical debt or licensing[[ap]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt42)[[aq]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt43)[[ar]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt44)[[as]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt45)[[at]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt46) concerns, which would help a potential customer get a more realistic picture of total cost-of-ownership or potential risk of data and functional lock-in. What about the role of operating software? As[[au]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt47) noted above, primary responsibility for issues like mitigating security vulnerabilities would lie with the SaaS provider. However, not all SaaS teams are as responsive, and priorities may differ between customers and providers. Regularly updated SBOMs can give insight into the speed and priority of security mitigations. Many organizations will have internal questions about responses to high profile vulnerabilities, or face questions from auditors or regulators about their overall exposure to known risks. The fact that vulnerability reporting for SaaS providers is still an open question[[6]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#ftnt6) hints at the potential value of greater transparency. As with all data artifacts, SBOM data makes more sense when supplied in context. Few organizations will make decisions solely based on SBOM data, but even the short history of SBOM has shown that it can be a powerful tool. As described earlier, the evolution of SBOM is still in its early stages. While this paper describes several SBOM use cases, it also states that the volume of data in many SaaS SBOMs limits the practical use. For example, it is well suited to search for the use of a component that is known to have a security vulnerability. However, the automation and intelligence of the tooling that consumes the SBOM needs to mature and evolve. Similar to how vulnerability scanners monitor large services and projects, we believe that the industry will build tooling to automatically scan SBOMs and identify risks pertaining to aspects such as the level of trust, existing security vulnerabilities and licensing for components that make up the SaaS solution. These tools will be able to analyze the SBOM and help consumers quantify the amount of risk associated with the service offering. ### SBOM [[av]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt48)[[aw]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt49)[[ax]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt50)[[ay]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt51)for SaaS[[az]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt52) Sharing Sharing SBOMs is a complicated topic that has been discussed and referenced here [https://www.cisa.gov/resources-tools/resources/software-bill-materials-sbom-sharing-lifecycle-report](https://www.google.com/url?q=https://www.cisa.gov/resources-tools/resources/software-bill-materials-sbom-sharing-lifecycle-report&sa=D&source=editors&ust=1738674511457981&usg=AOvVaw3a3Fwr7Yp6_JZTxM9uv7wE) . There are different approaches that may meet the needs of different organizations. A good example of an implementation is from JupiterOne: [https://www.jupiterone.com/sbom](https://www.google.com/url?q=https://www.jupiterone.com/sbom&sa=D&source=editors&ust=1738674511458447&usg=AOvVaw1Nh058lgELZlXMyBtEbjLu) #### Requirements[[ba]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt53) The NTIA published Framing Software Component Transparency: Establishing a Common Software Bill of Materials (SBOM) document that outlines a “core baseline set of attributes necessary to identify components with sufficient relative uniqueness.” Other regulatory agencies are adopting SBOMs as requirements, most notably the European Commission as part of the Cyber Resilience Act ([https://digital-strategy.ec.europa.eu/en/library/cyber-resilience-act](https://www.google.com/url?q=https://digital-strategy.ec.europa.eu/en/library/cyber-resilience-act&sa=D&source=editors&ust=1738674511459665&usg=AOvVaw00IbO1GtpiYGazLLUHcT8y) - will add as footnote after formatting is finalized), at the time of this publication, the EU’s CRA will require SBOMs to be provided up front with vulnerability information included. (Find specifics on SaaS requirements) ### Recommendations[[bb]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt54)[[bc]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt55)[[bd]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt56) Provide a sound approach and solution for producing SBOMs on SaaS and On-Premises software solutions[[be]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt57)[[bf]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt58). #### Alternative Directions <TODO: intro blurb> ##### Asserting SBOM-like capabilities exist SBOMs are a communication format for the purposes of consumers managing components[[bg]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt59)[[bh]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt60) via SBOM aware tooling. With SaaS, the capability to manage the components is critical, not the internal use of the SBOM format. Working with the vendor and their publications, the consumer may review the capabilities of the vendor’s component management tooling. ##### Snapshot of SBOM when making procurement/contract decisions[[bi]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt61) * Motivation * Use cases * Responding to an RFP * Pre-procurement / about to buy something * Compliance ##### On Demand SBOMs[[bj]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt62)[[bk]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt63)[[bl]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt64)[[bm]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt65) Treating SaaS software the same as traditional software deployments, consumers would obtain SBOMs on demand for the SaaS product being consumed. This on demand consumption would need to deal with the differences described above. The on demand SBOM might be considered more important in a SaaS environment, due to the implementation of CI/CD (continuous Integration/Continuous deployment) pipelines and therefore a continuous stream of changes/update in many SaaS offerings. * Use Cases * Risk Factors[[bn]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt66) ##### Component Management as a Service Rather than continuously obtaining or receiving SBOMs to store in local SBOM tooling, and then asking status questions of that tooling; consumers could ask those questions directly to the service vendor via a standard API. ##### Formatted Service Bulletins The industry practice when there is a security event is to publish information regarding the event; but that information is not consumable in a standard way. To optimize on consumers needing to call for information from a vendor, the vendor may publish information in a standard format to affected consumers, including the service, issue, vendor mitigations, and mitigations the consumer is required to perform. The consumer’s component management software can then integrate this supplied information into internal systems. ##### VEX[[bo]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt67) for SaaS VEX is out of scope[[bp]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt68)[[bq]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt69) for this document but references are provided below for those who want more information. While VEX (Vulnerability exploitability eXchange) is out of scope for this document, it is a promising tool that can determine and communicate the exploitability of components with known security vulnerabilities. One of the needed components for automated tools that will better identify and convey risk associated with the components that comprise SaaS solutions, to consumers. References: * [OpenVex GitHub](https://www.google.com/url?q=https://github.com/openvex&sa=D&source=editors&ust=1738674511465223&usg=AOvVaw0qAADOOAQ0AQBh85GlWG80) https://github.com/openvex * [CISA Minimum Requirements for VEX](https://www.google.com/url?q=https://www.cisa.gov/sites/default/files/2023-04/minimum-requirements-for-vex-508c.pdf&sa=D&source=editors&ust=1738674511465822&usg=AOvVaw1i4AJvowrTSVUNrqTn9Dqw) https://www.cisa.gov/sites/default/files/2023-04/minimum-requirements-for-vex-508c.pdf * [OWASP VDR and VEX Comparison](https://www.google.com/url?q=https://owasp.org/blog/2023/02/07/vdr-vex-comparison&sa=D&source=editors&ust=1738674511466331&usg=AOvVaw3Gh9YUtBIkXf-udJ_W1NOw) https://owasp.org/blog/2023/02/07/vdr-vex-comparison * [CycloneDX Vulnerability Exploitability Exchange](https://www.google.com/url?q=https://cyclonedx.org/capabilities/vex/&sa=D&source=editors&ust=1738674511466799&usg=AOvVaw2EZncyVx8s-1ss2CN4qNOn) https://cyclonedx.org/capabilities/vex/ * [CISA VEX Use Cases Document](https://www.google.com/url?q=https://www.cisa.gov/sites/default/files/publications/VEX_Use_Cases_Document_508c.pdf&sa=D&source=editors&ust=1738674511467177&usg=AOvVaw2I-68B7QSSthcvevIjE08B) https://www.cisa.gov/sites/default/files/publications/VEX\_Use\_Cases\_Document\_508c.pdf VEX exists and may well be useful for app provider-customer relationships at an automatable level ##### Why are we doing this? * Check box compliance * User will actually consume ### Acknowledgements This document was a product of the SBOM Cloud Working Group that is facilitated by CISA. The SBOM Cloud WG created a sub-group to address the SaaS and SBOM for the application layer hosted on a Cloud. The co-chairs Deanna Medina (Honeywell) and Ricardo Reyes (Tidelift) hosted the conversations with Industry from 2022 & 2023 and facilitated by Allan Freeman, CISA. Participants included: Aditi Sharma, Dell Adrian Diglio, Microsoft Aiden Clark, Iconist.us Allan Friedman, CISA Allen Smith, Umbraco.com Bamidele Odeniyi, BAH Ben Prime, ServiceNow Craig Rubin, HPE Courtney Robertson, GoDaddy David, Cybellum.com Deanna Medina, Honeywell Douglas Cavit, Cavit & Hohman Emily Fesnak, Deloitte Gray Williams, ServiceNow Henri Yandell, AWS Isaac Hepworth, Google Jason Beland, ServiceNow Jefferson Lacorte, ServiceNow Jeremiah T. Stoddard, INL.gov John K, Launchdarkly.com Jonathan Alboum, ServiceNow Lon Shapiro, ACM.org Maulik Shah, ServiceNow Michael Greco, ServiceNow Mike Rohde, ServiceNow Minatee Mishra, Philips Mike Thompson, AWS Nisha Kumar, Oracle Paul Giorgi, Xmcyber.com Paula Paul, Nearform.com Rene Pluis, Philips Ricardo Reyes, Tidelift, Inc Russell Haering, Edgebit.io Ryan Doughty, ServiceNow Sandeep Patil, Philips Shafia Zubair, Johnson Controls Simon Lokhvidson, Avmltd.com Steve Springett, ServiceNow Trevi Housholder, DocuSign Vincent Stammegna ServiceNow ### Parking lot of important issues * Licensing * How do customers use an SBOM? * Emily: We have a growing number of tools to consume them * Risk mgmt companies can turn SBOM data into recommendations * Manufacturers are starting to ingest supplier SBOMs, mapping to known vulns * Story for laptop vs. SaaS * We have a set of infrastructure pieces for SaaS: storage, compute, * Laptop: ### Appendix — use cases #### Illustrative use case — ”Choosing SaaS Software” As a procurement officer, I wish to know the composition of software intending to process my organization’s data so that I can choose products which meet a security baseline. A procurement officer at a mid-sized enterprise is selecting a product to process employees’ business expenses. She understands and appreciates the benefits of cloud-hosted SaaS products; her focus is on selecting the right provider amongst a crowded field. Security is a major concern and a primary selection criterion. The procurement officer asks candidate suppliers to complete a security checklist based on the open standard [mvsp.dev](https://www.google.com/url?q=http://mvsp.dev&sa=D&source=editors&ust=1738674511472488&usg=AOvVaw0xiNyGAE6aF4bj8WoS14X4) framework. She also asks each to provide detail on the composition of its hosted software, including in particular open source libraries being used in the software’s operation. The MVSP checklist helps ensure a reasonable posture across a range of security best practices. The composition analysis[[br]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt70) allows the procurement officer to additionally assess whether the product depends upon: * Deprecated or end-of-life components; * Components with known critical vulnerabilities; or * Components with a poor security track record. * Constructing the ma trix of shared responsibilities so that there is not a gap in terms of risk management. The procurement officer synthesizes these inputs into her selection process. #### Illustrative use case — ”Operating SaaS Software”[[bs]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt71) As an IT professional or as a security professional [[bt]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt72)I wish to know the composition of software used to process my organization’s data so that I can identify any vulnerable libraries, understand my role in the shared responsibility matrix, and understand the impact of changes to my environment against all my software dependencies. A IT or security professional at a mid-sized enterprise is maintaining a product to process employees’ business expenses. She understands and appreciates the benefits of cloud-hosted SaaS products; her focus is on being able to provide the application to her end users in the most efficient and secure manner possible. The IT or security professional asks her SaaS suppliers for their SBOM so that she can perform her role in the shared responsibility matrix. This may include understanding network requirements, identity frameworks, backup capabilities, and possibilities for performance tuning. In the role of making sure she is keeping the company’s information safe she would like to know if there are any vulnerable components that remain unpatched that would require her to either take some sort of interim work around action or to suspend use of the product till the issue is resolved. If the SaaS product is a subset of a bigger application or workflow she also needs the information to possibly maintain integration as well as identify opportunities for performance tuning. Finally she can use the SBOM to monitor her contractual SLA she may have with her provider for resolution of vulnerabilities. To summarize SBOM with SaaS in Operations: * Tool to understand role in shared responsibility matrix * Assess current risk posture and to provide a potential check on SLA agreement * Help identify network requirements for proper operation * Help to maintain interoperability with internal services such as identity * Make sure that the backup and availability process is known * Provide opportunities for understanding for performance tuning * Maintenance of larger workflow or application Website Use Case[[bu]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt73) The procurement officer responsible for selecting website hosting services aims to choose a provider meeting both the web hosting and website development needs. From small businesses to large enterprises, the preference lies in cloud-hosted Software-as-a-Service (SaaS) solutions. It seeks the most suitable choice from a wide range of hosting providers available in the market. Security represents the top priority and primary criterion in the selection process. [[bv]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt74) A thorough approach is followed to achieve secure website hosting, considering the hosting infrastructure and the website development agency's customized extensions alongside a mixture of publicly available customizations implemented as well. The agency tailors these custom solutions to meet the organization's specific needs, adding another layer of complexity to the hosting requirements. Detailed information is requested from all potential providers regarding their infrastructure capabilities, security measures, and support for custom solutions. Collaboration with the website development agency provides * insights into the technical specifications and resource requirements of these bespoke components, * informing the decision-making process and ensuring compatibility, * security, and * optimal performance for the website's unique functionalities. The software composition of the hosting providers' platforms is carefully analyzed to construct a matrix of shared responsibilities, ensuring a comprehensive risk management strategy. It is essential for both the hosting provider and the organization to understand their respective duties in maintaining a secure environment for hosting the website. Through this thorough analysis and assessment of the hosting providers' security, infrastructure capabilities, and support for custom solutions, informed decisions regarding website hosting services can be made. These inputs enable synthesizing information from potential hosting services and incorporation into the selection process. The ultimate goal is to procure a website hosting service that fulfills the organization's data processing needs and adheres to the highest security standards, effectively safeguarding the organization's website and sensitive information. A secure hosting environment is fundamental to ensure an organization's reliable and trustworthy online presence. By considering both the web hosting and website development needs, the selected hosting service can provide a seamless and optimized experience for website visitors while supporting the agency's custom solutions. [[1]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#ftnt_ref1) CITE: [https://safecode.org/wp-content/uploads/2017/05/SAFECode\_TPC\_Whitepaper.pdf](https://www.google.com/url?q=https://safecode.org/wp-content/uploads/2017/05/SAFECode_TPC_Whitepaper.pdf&sa=D&source=editors&ust=1738674511479175&usg=AOvVaw0LGTvjtK2XeUFm1AEEM1nO) [[2]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#ftnt_ref2) CITE SPDX creation [[3]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#ftnt_ref3) [https://www.ntia.gov/files/ntia/publications/ntia\_sbom\_use\_cases\_roles\_benefits-nov2019.pdf](https://www.google.com/url?q=https://www.ntia.gov/files/ntia/publications/ntia_sbom_use_cases_roles_benefits-nov2019.pdf&sa=D&source=editors&ust=1738674511479976&usg=AOvVaw2qof_pHJiyUw1RbE4JZz8o) [[4]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#ftnt_ref4) See: SBOM FAQ and SBOM Myths [[5]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#ftnt_ref5) [https://www.ntia.gov/files/ntia/publications/ntia\_sbom\_use\_cases\_roles\_benefits-nov2019.pdf](https://www.google.com/url?q=https://www.ntia.gov/files/ntia/publications/ntia_sbom_use_cases_roles_benefits-nov2019.pdf&sa=D&source=editors&ust=1738674511480570&usg=AOvVaw2F7guFJONoZ3kzpD0T0lLw) [[6]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#ftnt_ref6) https://www.ntia.gov/files/ntia/publications/framingsbom\_20191112.pdf [[a]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt_ref1)This is where the larger Cloud working group meets and there are links to the Cloud Stack and Service Transparency documents in those notes. [[b]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt_ref2)@[email protected] and @[email protected] @[email protected] Great feedback! We listen and introduced your great points into the document, we are updating the outline and making the necessary changes. We have incorporated the key points into the Outline and content. Please review some of the modifications, we encourage for your to update the content. We are still updating the content. \_Assigned to [email protected]\_ [[c]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt_ref3)self-reminder here [[d]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt_ref4)Doug Cavit can you write an operator use case. [[e]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt_ref5)What is the difference between "Purpose" and "Objective"? [[f]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt_ref6)Suggest: In order to navigate growing cybersecurity concerns in cloud and SaaS based solutions, this paper provides a pathway for applying Software Bill of Materials to mitigate these concerns. [[g]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt_ref7)I feel like this should go somewhere else [[h]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt_ref8)I think this should be the first sub-heading under "introduction" [[i]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt_ref9)from Isaac | related to Adrian's point, here's the equivalent section from my internal paper https://imgur.com/a/Nlw8CEB [[j]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt_ref10)revisit to make sure this aligns with our definitions. [[k]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt_ref11)Service Transparency white paper is using the term 'monolithic software' vs On-Prem: https://docs.google.com/document/d/1t\_J7wPoGgnIShDVu1iWOMLotchtJJ\_0iMChUREnxkvc/edit [[l]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt_ref12)We are using non-SaaS now [[m]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt_ref13)Steve Springett (ServiceZNow) likes thSaaS and non-Saas option as well as cloud-native and non-native [[n]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt_ref14)fwiw I'd go with one of - SaaS and non-SaaS - SaaS and packaged - provider-managed and customer-managed most importantly, though, at a high level: - define the terms in the "Definitions" section - use the defined terms consistently throughout the doc - don't be tempted to use other terms :) [[o]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt_ref15)I vote Saas/non-Saas we just need to make sure we are consistent [[p]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt_ref16)SaaS/Packaged gets my vote [[q]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt_ref17)@[email protected] \_Assigned to mike.rohde\_ [[r]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt_ref18)@[email protected] will you help document this section? \_Reassigned to \_ [[s]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt_ref19)Should we include "orchestration components" here? [[t]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt_ref20)I think this section should come before "scope" [[u]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt_ref21)Suggest: However, as cloud computing has evolved, private cloud implementations have been introduced, which may be on the customer premises thus rendering the distinction by location inadequate. [[v]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt_ref22)👍 [[w]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt_ref23)Doc note - is the rest of this section an "Alternative mechanisms" section that is considered outside of scope of "SBOMs for SaaS" because only SBOMs are within scope? [[x]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt_ref24)https://learn.microsoft.com/en-us/azure/security/fundamentals/shared-responsibility [[y]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt_ref25)@[email protected] @[email protected] [[z]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt_ref26)@[email protected] @[email protected] [[aa]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt_ref27)Do we like the order? Are there logical benefits to keeping it this way vs. starting with same and going for different? The "same" section has a few more use cases, but it may flow better to finish with "what's the same" [[ab]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt_ref28)Adrian had a comment this morning regarding the SBOM itself not changing. Find it and see if it is addressed. Delivery mechanism for SaaS is different. At at the end - summarizing the main differences. The title is not represented. More than sharing needs to be discussed? [[ac]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt_ref29)[log4j and blocking outbound is an example here too] [[ad]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt_ref30)@[email protected] \_Assigned to [email protected]\_ [[ae]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt_ref31)I think we can delete this sentence [[af]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt_ref32)@[email protected] \_Assigned to [email protected]\_ [[ag]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt_ref33)I think this section may no longer be needed. [[ah]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt_ref34)@[email protected] I have added your section under SaaS vs. Software On-Prem section -- but we can always realign it once we flush out some of the content \_Assigned to craig.rubin\_ [[ai]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt_ref35)I like the first item. That that shared understanding is crucial to getting value here. I'm not sure what the point of some of the other points are; I suspect we need a format of: \* Term-phrase: Explainer [[aj]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt_ref36)How to structure this? Bold each use case? Number? Folks weren't excited about a bulleted list. [[ak]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt_ref37)Use Case - Third Party Risk Management - SBOM will help to automate third-party risk management lifecycle allowing "Operators of Software" to accelerate third-party assessment and monitoring, increasing visibility while driving down costs. SBOM will allow "Operators" to strengthen their risk stance, identify and address issues more quickly, automate the attestation process, increase control, and free up time and resources to focus on assurance. [[al]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt_ref38)I was going to add a callout box here but the option is greyed out for me. Perhaps I don't have the necessary privileges. [[am]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt_ref39)Pull in Isaac's use case from below, but maybe make it a call-out box that tells a story. [[an]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt_ref40)@[email protected] will do this. [[ao]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt_ref41)I think some more explanation on how this would manifest is needed. Would a chooser ask for an SBOM? If yes, are they expecting the NTIA SBOM or something else? Does the NTIA SBOM answer the questions a chooser may have? How granular will this SBOM be? [[ap]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt_ref42)I think this is fairly limited if we're talking open source, nearly all open source licensing has little impact on SaaS (the way I think we're defining it). [[aq]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt_ref43)I'm not sure this is true. Using AGPL licensed software definitely has a large impact on risk assessment. Granted, most of the open source components used in SaaS are licensed permissively, but a chooser will not be able to plan for possible service disruption unless they know whether there is an AGPL component present. [[ar]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt_ref44)AGPL is one of the reasons why that was a 'nearly all'. RealNetworks license and OSL would be two others (both of them basically dead). And then there is EUPL. Non-Commercial licenses aren't open source, but can fall into this situation (though what 'non-commercial' means is never well defined and has to be handled on a case by case basis). In each case though - the licensing of the component within the SaaS service does not affect the consumer. It's not like when a product is being downloaded and the consumer has to be concerned about the risk that a component of the product has licensing conditions they didn't expect that puts the confidentiality of their IP at risk. In each of the open source cases AGPL/EUPL etc, SaaS is welcome to use them and SBOM information is going to be weak on adding any risk assessment value. What I think you're trying to use the data to identify is some kind of "what's the likelihood of a legal requirement to take a service down" - something where this cause is one tiny unicorn/rare possibility next to a horde of other business risks. Better to track the vendor's share price :) [[as]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt_ref45)I agree that the licensing of the component does not affect the consumer of the service. But we are talking about \_choosers\_ who may have a different legal posture. As such, I would think they would want to know if any of the services they are looking to acquire have components that result in a legal obligation. I also agree that the probability of this happening is small, but when it does happen, depending on how entrenched the software is, the impact can be large (think Docker's change in the licensing of Docker desktop). [[at]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt_ref46)We're talking SaaS though, not desktop. With desktop software, a consumer is an explicit part of the rights package for using that software. With SaaS they are not. I'm wary of encouraging licensing here because either a) it's tackling an enormous iceberg - just how does one entity license software from another? Is that public information? What about even whether a subsidiary in one country has sufficient intra-'company' licensing to use their parent company's software? That's a lot of weight to put on software. Alternatively, we're just suggesting something that only works for open source, in which case we're adding friction to using open source and encouraging more proprietary software. Let's say that proprietary software uses some open source, is the SBOM expected to share the open source but not the proprietary software? For the licensing examples you're thinking of AGPL, EUPL etc; the licensing already contains conditions requiring services to inform consumers AND SBOMs are not the industry/community accepted way to do that. They're not (yet) accepted as consumer readable for one. [[au]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt_ref47)identifying which providers have addressed a vuln. [[av]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt_ref48)"SBOM requirement" needs to be defined somewhere. what precisely is the requirement and what's it in service of? [[aw]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt_ref49)Added the NTIA recommended requirements for SaaS [[ax]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt_ref50)I think we need really super clarity here. "Recommended requirements" feels unhelpful... is it a recommendation, or a requirement? Is this document normative with respect to a particular government organization's minimum implementation bar? If so, whose? And so on. [[ay]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt_ref51)With respect to SaaS there are no defined minimum requirements yet that I know of. There are too many definitions/needs/wants still unclear from the community and standards organizations to make a clear definition. [[az]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt_ref52)@[email protected] \_Assigned to [email protected]\_ [[ba]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt_ref53)@[email protected] wordsmith? \_Assigned to [email protected]\_ [[bb]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt_ref54)So what we don't have in the above section are pros/cons of the paths. We explain why SaaS is different to the typical description of SBOMs, but then have things like consumers pulling SBOMs on demand as if it was typical software. Where is the right place to discuss that - as a part of the recommendations, or in the paths? [[bc]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt_ref55)The issue of consumers pulling SBOMs is multi-faceted, i.e. I may have automation against an API not unlike checking a signature or it may be part of a broader attestation and someone wants to check a specific piece or simply the case that there is a vulnerability and someone wants to see if that is part of an SBOM. [[bd]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt_ref56)The Service Transparency wp has a section on "scenarios": https://docs.google.com/document/d/1t\_J7wPoGgnIShDVu1iWOMLotchtJJ\_0iMChUREnxkvc/edit#heading=h.g1qufl5oxftz [[be]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt_ref57)This is going to be largely driven by attestation. [[bf]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt_ref58)For me, attestation tends to come up more for SSDF as a whole, or for tooling like in-toto for build attestation. I'm not sure of the scope here. [[bg]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt_ref59)yes! and... in SaaS, by definition, consumers do not manage the components. and this comes back to a big missing piece of the paper: what are we doing here, and why? [[bh]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt_ref60)We could define 4 target groups: service provider / intermediate service provider / end consumer / auditor and form the recommendations based on which group the classify under. [[bi]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt_ref61)Hard to argue this is very useful for security; is useful for licensing. Wasn't sure we wanted to say that. [[bj]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt_ref62)This is a bit tricky of a section because a lot of the SaaS vs SBOM section is explaining why simply having downloadable SBOMs is very complex. [[bk]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt_ref63)Do we continue in each of these Path sections to talk about pros/cons; and does the document continue with On Demand SBOMs to talk about some kind of SaaS-SBOM that resolves these cons? [My own bias is towards Vex type approaches here; leading with vulnerabilities and not components, and describing how the SaaS application is mitigating the vulnerability; so I'm not chock full of solutions for SaaS-SBOM] [[bl]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt_ref64)I think an on-demand SBOM would look more like this: https://www.jupiterone.com/sbom It doesn't have the vulnerabilities listed and is more of an information "list of ingredients" at the moment. [[bm]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt_ref65)This eliminates the need for 'live" vulnerability updates and if the consumer of that SBOM wants to know what the vulnerabilities are they can run it through a tool. [[bn]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt_ref66)@[email protected] please update \_Assigned to shafia.zubair\_ [[bo]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt_ref67)Is this under the right heading? Should it exist on its own? [[bp]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt_ref68)"CloudVex", if such exists or might exist, feels like it is useful for the SaaS space. I'm not sure if this should be entirely out of scope. [[bq]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt_ref69)Agree. I've found the current VEX format to be sufficient, but maybe more data may be required (for example, I use the SaaS offering as the "product" and maybe this should be expanded more) [[br]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt_ref70)How is this created in your use case? The procurement officer licenses analysis software from vendor V? (I'm assuming that the data provided is too large for manual review) [[bs]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt_ref71)@[email protected] use case focuses on the service transparency operational services and challenges. According to @[email protected] these are transparency questions. \_Assigned to [email protected]\_ [[bt]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt_ref72)Do we want to specify whether this persona is operating the application owned by them on the infrastructure owned by another business? [[bu]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt_ref73)@[email protected] @[email protected] thoughts on this term Website -- Web Application? or Modern Applications or SaaS Applications \_Assigned to [email protected]\_ [[bv]](https://docs.google.com/document/d/17d6Lpep1SpbMcUyZ6f7gi-Cmf8P37Kwebd3fmqsQclU/export?format=html#cmnt_ref74)Address audience, users, and passive voice @[email protected] But should we keep based on Service Transparency Use Cases already defined? \_Assigned to crobertson%[email protected]\_, SBOM and SAAS - Google Docs, google.com, 01h4994tv0w9pzms3ckmz8kqsf.