Niklas

It might be that newer Syft versions generate BOMs using the CycloneDX v1.5 schema per default. Support for CycloneDX v1.5 was introduced in Dependency-Track v4.9.

Can you share the CURL commands you're using? This is a very basic use case of DT and I am not able to reproduce the defect you're describing. I suspect...

Did you observe more detailed stack traces for this in the logs? Any more info you can share about your setup? I am reworking the BOM processing in https://github.com/DependencyTrack/dependency-track/pull/3357 and...

Hmmm, I'm thinking this might've been fixed in 4.10.0 already, at least it's a similar problem: https://github.com/DependencyTrack/dependency-track/pull/3228 Will try reproducing to verify.

It would be good to understand what the reason for needing this is. Under what circumstance would a client send such large header values? Is it due to too many...

Can you try the following: 1. Shutting down the application 2. Manually removing /data/.dependency-track/index/vulnerability/write.lock 3. Starting the application again Maybe the application failed to clean up after itself at some...

> Its odd that there was a write lock as by the nature of the ecs task they dont share any common filesystem. Normally DT takes care to remove any...

@melba-lopez @walterdeboer The conflict just resolved itself after merging #2965 :)

Thanks again @walterdeboer for the effort here. Upon further inspection, there are two major things that prevent us from merging this: * I had multiple orgs reach out indicating that...

I am working on a PoC for https://github.com/DependencyTrack/dependency-track/issues/2673 at the moment, and in doing so I'm also looking at supporting project policies. With [CEL](https://github.com/google/cel-spec/blob/master/doc/langdef.md), the policies mentioned in this issue...