Replies: 3 comments 9 replies
-
|
I think it all depends on how you define "sbom" and how you shape your dependencies. As you noticed in the referenced issue, Tycho is "just" a maven tool and you can of course use the Cyclone plugin, but if your project uses P2 dependencies not from maven central (or other maven repository) you obviously won't get "original maven dependencies" (what ever that means).
This is always possible but you should describe exactly what is the expected outcome (e.g. it is not always possible to map P2 > maven as implied in the referenced issue) in terms of output format and alike. Also be aware that there might be not enough interest to implement this right now (as it seems not very important for Tycho users right now), so the best would be to start some work and research to create a PR or if this is crucial to your business and you like to speed up the development in that area a sponsoring would allow me to assign more time-slots particular issue, or you can take a look at the
I'm not aware of any sbom for Tycho (yet). |
Beta Was this translation helpful? Give feedback.
-
|
@ghost314 It seems there is some demands from the Eclipse Security Team as well here: I'll take a look to see if we can maybe have a "p2" extension for CycloneDX, but maybe you still can explain how do you plan to use that information in the light of P2. |
Beta Was this translation helpful? Give feedback.
-
|
Not sure if I understand what you're asking, but there are a number of use cases for an SBOM file. CycloneDx is a well established format that can be parsed by a number of third party tools to provide you with information on the dependencies you're using. The file is meant to include all transitive dependencies as well and can list any known security issues/vulnerabilities in any of those libraries. Information on the licenses used by each library can also be included. For a simple real-world example, there was a major security vulnerability discovered in a log4j library a while back. None of our software at work used the library directly, but some of the libraries we rely on did. When a vulnerability like that pops up it can be tricky to figure out whether or not you have any transitive dependencies linking to it in a large commercial codebase. The SBOM I'm working on with the help of syft lists over 1,000 libraries that are in our product. With a project that size, building and maintaining an SBOM file by hand is not practical. Some kind of tool is needed to automate the process. The CycloneDX maven plugin is a great tool for projects relying on maven to manage all of their dependencies, but tycho projects will have dependencies outside of the regular maven ecosystem that are missed by that tool. That might not be an issue if another tool could do the job (SBOM files can be merged/combined) but I've yet to find one that has proper support for dependencies managed by P2 repositories. |
Beta Was this translation helpful? Give feedback.
-
The main question is, would these "number of third party tools" simply ignore or can do anything useful that is not on maven directly... Because just assume we get some kind of SBOM support in Tycho, all P2 dependencies are nicely listed you load it in your favorite third party tool and jsut get nothing as a result as these tools simply have no clue about P2 and how to find a vulnerability or similar. Also keep in mind that in OSGi there is not that dependency, if you have version ranges there can be multiple alternatives so you because you used a particular version to compile does not mean you depend on it at runtime! Especially (if done correctly) one release on the API, so in your log4j example you probably know that log4j is used somewhere but you still don't know if at runtime a vulnerable version would have been used, you even don't need to change anything (maybe raising the lower bound to be sure) to use a non vulnerable version.
In OSGi, its actually not that tricky as all dependencies are declared in the manifest, so probably one should even stay away from the maven model and make an OSGi "SBOM" ... here again, are these "number of third party tools" will be able to handle this? But on the long run this seems much more practical than relying on P2 (what is some kind of a non standard outside of eclipse), I can bring up the topic on the next OSGi specification talk today, but wondering if there is some kind of "SBOM Authority" or if effectively once can use any names as one likes?!? |
Beta Was this translation helpful? Give feedback.
-
SBOM files are not really language or package manager dependent. First off, as I understand it there are 2 common formats, SPDX and CycloneDX. I don't know much about SPDX, but CycloneDX is being led by OWASP which is a big name in the software security world so we went with that format at my workplace. That being said most third party tools are going to support both formats. A DycloneDX SBOM can have a number of formats itself as well (xml, json etc...). It allows a number of ways to identify a library, such as purl strings. It also contains a section for listing known vulnerabilities. So if the data on vulnerabilities were to be written into the SBOM file to begin with, that data would be available to third party tools without them needing to know anything about P2.
If you want compatibility then I would suggest picking one of the already-established formats (SPDX/CycloneDX) and see what data you can populate it with. It's probably worth noting here that SPDX seems to be the only SBOM file format that's been officially certified by the ISO. In either case there should be some libraries you can use to help with the actual writing of the file. In my tiny test project I was using https://github.com/CycloneDX/cyclonedx-core-java. |
Beta Was this translation helpful? Give feedback.
-
|
I think the main point is really the vulnerabilities as I'm not aware of any such place actually recording such things (Do you know how does maven central do this?) but I think thats another story. I most likely will have some time starting at end of next week to work on this and can came up with a first version of this, but probably you can in the meanwhile make a very small example DycloneDX SBOM file (e.g. for one bundle with two dependencies) to show what information you want it to include and open an issue to track the progress, I assume one might can do it very similar to how maven dependencies are listed but just with a different |
Beta Was this translation helpful? Give feedback.
-
|
Can't such sbom be generated directly from the RCP application content directly? As @laeubi mentions, there should be most metadata already available in the plugins or the OSGi runtime, so why involving Tycho? |
Beta Was this translation helpful? Give feedback.
-
|
Yes a product is actually the ultimate "source-of-truth" if you want to answer the question "what is included" (what about an updateable product?) but the idea of SBOM is (correct me if I'm wrong) that your library carry enough data to determine this even if you are using it e.g. inside a plain maven build or something like that, but I think this "promise" of SBOM is hard to hold when it comes to loosely coupled components like OSGi without looking at the final product, that are alo my main concerns regarding adding such things blindly to e.g. m2eclipse. |
Beta Was this translation helpful? Give feedback.
-
|
There are actually a number of ways to generate an SBOM file. Syft, which I used for work, scans the final binary to figure out what's actually being used. This was the only tool I could find that didn't completely miss all the OSGI/P2 stuff since it could spot the jar files. The CycloneDX maven plugin attempts to generate it during the build, but it needs dependencies to be linked through maven. Honestly I spent a fair bit of time puzzling over whether it makes more sense for tycho to try and make an SBOM or for the cyclone maven plugin or syft to learn about OSGI/P2. Then again maybe it's the third party tools and whatever databases they use to find 'known security vulnerabilities' that need to be updated with libraries from commonly used P2 repositories. I have a feeling that the final solution will require some sharing of code between multiple parties. |
Beta Was this translation helpful? Give feedback.
-
|
I'm adding to the existing thread, but this could be a separate question: How are people using the new tycho-sbom mojo? I tried it on a company project, and while it surely works fine, I cannot really use the result in the further process. No other CVE aggregation tooling knows the p2 URIs, therefore a CVE raised against the maven jar of apache.commons.io will not be flagged for the same p2 bundle listed in the tycho-sbom output. |
Beta Was this translation helpful? Give feedback.
-
|
Tycho can already map P2 > Maven: It even supports different "mappers": So one could for sure add another one that uses a well-known-list of artifacts as well. |
Beta Was this translation helpful? Give feedback.
-
My workplace is trying to sort out licenses/vulnerabilities in all the third party libraries we use. In order to do this, I'm trying to build an sbom for our application. Our application is an eclipse RCP application which we build using maven with tycho. I have yet to find a single sbom generator tool that knows how to resolve OSGI/P2 dependencies. I noticed someone put in a request for the CycloneDX maven plugin to add support for tycho projects. However they are of the opinion that it should be the tycho project that handles this since its build mechanism is very different from a regular maven project. Is there an existing solution that people are using for this? Would it be worth creating a feature request and trying to get tycho to generate sboms?
Also while we're on the subject, is there an sbom for tycho itself? Might be good practice for me to try making one 😃
Beta Was this translation helpful? Give feedback.
All reactions