sbom & licenses of dependencies

[AlexanderLanin]

Please review the following use cases for anything dependency related regarding sbom & licenses.

review points e.g.:

• understandable?
• everything covered?
• too much covered?
• in-line adjustments
• prio

Domain	Use Case	Trigger	Input	Tooling Responsibility	Output	Priority
Embedded Runtime	Eclipse License Compliance	PR + Release	Bazel product targets (runtime graph only)	SBOM-tool (+ internal dependency to dash-license-scan)	License list + allow/deny decision	🔴 1
Dev Environment	Eclipse License Compliance	PR + Release	uv.lock, cargo.lock, etc.	dash-license-scan using shared license policy	License diff + allow/deny evaluation	🔴 1
Embedded Runtime	Extended License Compliance	Scheduled	Bazel product targets (runtime graph only)	SBOM-tool (+ internal dependency to dash-license-scan with custom whitelist)	License list + allow/deny decision	🟢 4
Dev Environment	Extended License Compliance	Scheduled	uv.lock, cargo.lock, etc.	dash-license-scan with custom whitelist	allow/deny evaluation	🟢 4
Embedded Runtime	SBOM Generation*	Release	Bazel product targets (runtime graph only)	SBOM-tool	SPDX + CycloneDX SBOM	🟠 2
Dev Environment	SBOM Generation*	Release	uv.lock, cargo.lock, etc.	dash-license-scan	SPDX + CycloneDX SBOM	🟡 3
Embedded Runtime	Security: Vulnerability Monitoring	Release + long-term monitoring	Embedded release SBOM	Vulnerability scanner (TBD, e.g. DependaTrack)	Vulnerability report	🟢 5
Dev Environment	Security: Vulnerability Monitoring	Release + long-term monitoring	lock files + all bazel dependencies	Vulnerability scanner (TBD, e.g. DependaTrack)	Issue creation / alert	🟢 5
Source Code Compliance	Snippet Scans	Scheduled + Release	All S-CORE Repos	distributors only? Out of scope for S-CORE?	-	🟢 4

\* use case to be detailed, e.g. upload to dependabot for main branch monitoring

[dcalavrezo-qorix]

We're mixing three different concerns in the same table ( license compliance, SBOM generation and security monitoring). Though they are related, they would run in separate workflows.

Concern	Typical Trigger
License compliance	PR + release
SBOM generation	release
Vulnerability monitoring	continuous

[dcalavrezo-qorix]

MODULE.bazel.lock should explicitly be listed since they are dependencies of the build environment.

[opajonk]

Probably a split-up by these use-cases makes sense. For SBOM generation: I think it should be automated, done on PR builds as well. Not that this is used, but only by continuously doing it we know it works.

[AlexanderLanin]

I put it all together, because we had/have quite some trouble figuring out how exactly those workflows and tools are related. e.g. sbom generation calls license check to figure out licenses. license scan works on sboms. etc.

[dcalavrezo-qorix]

I think it is unusual to use the SBOM terminology for Dev environment .

Maybe use Dev Environment Dependency Inventory ?

[AlexanderLanin]

For me personally SBOM = Dependency Inventory, but clearer. People always forget that we need sbom for all tool repos as well and not only for the "final product". As we dont deliver the embeded software, but the development environment its as least the same criticality.

[dcalavrezo-qorix]

Snippet Scans row seems out of scope - at least in this table. And is too vague/unclear, at least to me

[opajonk]

I think as well. And it is covered by the ECA of Eclipse, no?

[AlexanderLanin]

Technically it's covered (I'm not a lawyer), nevertheless I expect every distributor will have to run a snippet scanner like fossid on top of it (again, I'm not a lawyer. But thats what I heared from score committers). Technically it's probably completely unrelated to the rest. If thats true, we can remove it from this list.

[opajonk]

I also think it is technically something different. I cannot say if "snippet scanning" is a thing for OSS projects or not. I have never seen it - but then, does that mean anything? Probably not...

Do we know about other Eclipse projects that do snippet scanning?

IMHO, with the same "I am not a lawyer" disclaimer: If someone comes with a good rationale that we need it - then I would say it's the correct point in time to add it to our tool box.

[AlexanderLanin]

How do files, manifests, tools, and compliance fit together end-to-end?

I was confused for quite a while how all of this belongs together. So here is v0 of the system view.

flowchart TD
    file_in_repo["File in repository"]
    dependency_manifest["Dependency manifest\nin repository"]
    manual_declarations["Manual third-party\ndependency declarations"]

    %% File path
    file_in_repo --> header_check{"Supports copyright header?"}

    header_check -->|Yes| add_header["Add copyright+SPDX header"]
    header_check -->|No| add_license["Add .license file"]

    add_header --> copyright_owner{"Copyright holder\n= Eclipse S-CORE?"}
    add_license --> copyright_owner

    copyright_owner -->|Yes| first_party["First-party file"]
    copyright_owner -->|No| third_party_file["Third-party / external file"]

    first_party --> current_component["Component produced\nby this repo"]

    third_party_file --> reuse_checks["REUSE / license compliance"]
    reuse_checks --> external_component["Third-party component"]

    %% Dependency discovery path
    dependency_manifest --> cdxgen_scan["cdxgen"]
    cdxgen_scan --> merge_inputs["Merge cdxgen output\n+ manual declarations"]
    manual_declarations --> merge_inputs

    merge_inputs --> dash_enrichment["Enrich license data via\nEclipse Dash License Tool"]

    %% Converged SBOM candidate path
    current_component --> included_check{"Included in product?\n(SBOM scope: runtime)"}
    external_component --> included_check
    dash_enrichment --> included_check

    included_check -->|No| non_product_sbom["Development SBOM\n(build scope)"]
    included_check -->|Yes| product_sbom["Product SBOM\n(runtime scope)"]

    non_product_sbom --> license_compliance["License compliance\n(IP Lab / Dash\n+ project whitelist)"]
    product_sbom --> license_compliance

    non_product_sbom --> github_upload["Upload SBOM to GitHub"]
    non_product_sbom --> dependencytrack_upload["Upload SBOM\nto Dependency-Track"]
    product_sbom --> github_upload
    product_sbom --> dependencytrack_upload

    github_upload --> vulnerability_results["Vulnerability findings\n/ monitoring"]
    dependencytrack_upload --> vulnerability_results

    classDef artifact fill:#E3F2FD,stroke:#1E88E5,color:#0D47A1
    classDef action fill:#E8F5E9,stroke:#43A047,color:#1B5E20
    classDef decision fill:#FFF3E0,stroke:#FB8C00,color:#E65100

    class file_in_repo,dependency_manifest,manual_declarations,first_party,third_party_file,current_component,external_component,non_product_sbom,product_sbom,vulnerability_results artifact
    class add_header,add_license,cdxgen_scan,merge_inputs,dash_enrichment,reuse_checks,license_compliance,github_upload,dependencytrack_upload action
    class header_check,copyright_owner,included_check decision

Loading