Add sbom generation and upload workflow

[iliescuioana]

What it does

This PR aims to bootstrap the EF Security Team initiative of supporting projects in implementing automated SBOM generation and upload workflows, with the goal of enhancing software supply chain security.

We wanted this to seamlessly integrate with your existing release processes, so we implemented 1 workflow meant to generate an SBOM for all products comprised in this repository.

Currently the workflow is triggered by new releases being published. A polyglot tool (cdxgen) is used to generate the SBOM, which is then uploaded as an artifact. The store-sbom-data reusable workflow stores additional metadata about the project and upon completion, the self service system downloads the SBOM from artifacts and uploads it to our DependencyTrack instance, under the Eclipse Langium/langium-workspaces entry. After a successful workflow run, to view the uploaded results, you can log into the instance by using your EF account credentials.

For any inconsistencies or potential integration issues with existing release processes that we might have missed, please feel free to update the workflow as needed, edits by maintainers are enabled.

More details about our SBOM Early Adopters initiative at EF can be found in our Security Handbook, alongside documentation on what is an SBOM, what are they used for, tooling ecosystem and our upload integration. Previous successful early adopters workflow examples are listed in the table at SBOM Early Adopters. Additionally, more information about our DependencyTrack instance can be found at SBOM Registry.

Please let us know if you have any questions we can help with.

How to test

SBOMs will be generated when a new Github Release is created. In order to test, there's the option to do a manual run of the workflow. We have tested the SBOM generation separately and everything worked successfully. However, due to limited permissions, inability to simulate the trigger event and possibly incomplete knowledge of your release processes, if the changes get merged, we'd ask if you could manually run it once so we can confirm the upload to our instance works as expected.

For the "Version" input, the value of the latest release tag can be used, together with the default branch. Allow a couple of minutes after completion for otterdog to pick up the SBOM. Afterwards, it should appear on our DependencyTrack instance. Instructions on how to log into it can be found in our Security Handbook/SBOM Registry.

Notes

• langium-workspaces is a mono-repo that holds multiple components (packages) listed under workspaces. The workflow generates 1 "aggregate" SBOM for all these components. Therefore, if they are to be used independently, to assess risk/mitigate vulnerabilities, extra search steps will be required. As available tooling improves, generating multiple SBOMs - one per product - might be a good idea to look into in the future.
• devDependencies are captured in the SBOM; cdxgen has a required-only option that should differentiate between dev/prod dependencies, however in this case using the option seems to makes the components (packages) not show in the SBOM.
• Looking through: https://www.npmjs.com/package/langium?activeTab=versions it seems there are more versions available that the ones with a Github Release associated. It's important to note that unless one is created or the workflow is manually run (for example on a tag) - those versions will not have an SBOM generated