stevespringett
commented
2 years ago @matamorphosis thank you for the feedback. I'll try to reply however, for every enhancement, you'll need to create a ticket so each piece of work can be prioritized and tracked.
Inline with DependencyTrack's ability to ingest XML SBOMs, XML support for export should be added. I had someone asking for an XML format due to it being a preferred format by the FDA.
Dependency-Track already supports export to XML, but it can only be done via the API. The UI defaults to JSON. Hopefully, medical device makers are not manually exporting BOMs. Consult the swagger docs for info on how to specify xml as the serialization format.
Additionally, I have other people requesting the SBOM in a CSV format, which is easier to read as a human, than XML or JSON. SO it would be nice to have that as an option.
The CycloneDX standard does not support CSV, nor are there plans to support it. For human readable and editable use cases, please provide feedback to the CycloneDX Authoring Tool project.
There are some key missing fields, which I currently have to obtain the details for myself, that are: a. The FDA guidance refers to "manufacturer" as a required field, which with modern dependencies is referred to as Maintainer/Author Name and Email b. Latest Version c. Whether the current version is up-to-date (This shows in DependencyTrack but not in the SBOM export)
Dependency-Track already supports 'author' and 'publisher' fields. All of this data is supplied from CycloneDX, stored in DT, and is available via the API as well as SBOM export.
The latest version of every component is available via API. Determining if the component is up-to-date or not is also available via the API along with last published data. This data does not belong in an SBOM.
In addition to the above, I don't have a clear way of working this out, but if a dependency is no longer maintained. I recognise this may be an existing feature in DependencyTrack, but haven't had a situation where I've had a dependency that is no longer maintained in my project to find out. If it is an existing feature, that would also be information I would want added to the SBOM upon export.
This information is generally hard to come by and is typically provided by commercial sources of vulnerability intelligence. This data does not belong in an SBOM, but could be provided via API. We would first need to identify a source of intelligence that provided this type of data. Once identified, evaluate whether an integration between the provider and Dependency-Track could be created.
Option to import vulnerabilities from a third-party vulnerability scanner. I know DefectDojo supports a series of vulnerability scan reports in terms of ingesting findings, the parsers for which are found here. It would be awesome if you could do something similar with a DependencyTrack project, and then have the option to choose to include either the DependencyTrack OSS vulns, or the vulns from the imported vulnerability report.
Dependency-Track allows uses to create their own vulnerabilities, via UI or API along with the vulnerable software affected by those vulnerabilities. Any SBOM imported that matches the affected software will have the custom vulnerability applied to it. Currently, Dependency-Track does not import vulnerabilities from other source. If this is a feature you'd like to see, please create an enhancement ticket specific for that case.
Inline with the above proposed changes it may make sense to have a series of drop-down boxes, as follows: a. The first box should allow you to select the SBOM format: SUGGESTED OPTIONS: json, xml, or csv b. The second box should allow you to select vulnerabilities, whether to include them, and from what source. SUGGESTED > > OPTIONS: DependencyTrack OSS Vulnerabilities, {VULNERABILITY SCANNER NAME} Vulnerabilities
Excluding CSV, you can create an enhancement request to add options for JSON and XML export from the UI. And another enhancement for the vulnerabilities.
Support Python packages from Conda that aren't available on PyUp. Check out _libgcc_mutex as it doesn't exist in PyUp, but can be found on the Anaconda site
Dependency-Track currently does not support Conda repositories. If you'd like this feature added, please create an enhancement request and specify the default public conda repositories (such as Anaconda) you'd like DT to support by default.
matamorphosis
The enhancement may already be reported! Please search for the enhancement before creating one. Hi I have a list of enhancements that I think would really make DependencyTrack a really solid solution. For context I am currently doing work for a medical device company, and there are some recent newly drafted FDA guidelines, which while definitely not written by a security professional, have resulted in me capturing some gaps in the information available in the CycloneDX SBOMs my company is dynamically generating and sending to DependencyTrack. If you are interested in the guidance for any future R&D ideas it might spark beyond this ticket, you can find it here.
Current Behavior:
Proposed Behavior:
a. The FDA guidance refers to "manufacturer" as a required field, which with modern dependencies is referred to as Maintainer/Author Name and Email b. Latest Version c. Whether the current version is up-to-date (This shows in DependencyTrack but not in the SBOM export) These details can be fetched at: a. NodeJS via the NPM JS registry API (https://registry.npmjs.org/{PACKAGE}) b. Python via the PyPi registry API (https://pypi.org/pypi/{PACKAGE}/json) c. Other languages would require further R&D.
json,xml, orcsvb. The second box should allow you to select vulnerabilities, whether to include them, and from what source. SUGGESTED OPTIONS:DependencyTrack OSS Vulnerabilities,{VULNERABILITY SCANNER NAME} Vulnerabilities_libgcc_mutexas it doesn't exist in PyUp, but can be found on the Anaconda site here.Thanks in advance for your consideration of these features.