'Enable fuzzy CPE matching' options lead to I/O Exception in the FuzzyVulnerableSoftwareSearchManager

Selecting ‘Enable fuzzy CPE matching’ options leads to I/O Exception in the FuzzyVulnerableSoftwareSearchManager

Steps to Reproduce:

One may reproduce the error on a clean install. I used Ubuntu 22.04 clean image with 30 GB HDD and 16 GB RAM.

I started as a sudo user and switched to root: sudo -i Than I installed Docker:

apt-get update
apt-get install     ca-certificates     curl     gnupg     lsb-release
mkdir -p /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
echo   "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \
$(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
apt-get update
apt-get install docker-ce docker-ce-cli containerd.io docker-compose-plugin

and the latest (4.6.2) version of Dependency Track:

docker pull dependencytrack/bundled
docker volume create --name dependency-track
docker run -d -m 8192m -p 8080:8080 --name dependency-track -v dependency-track:/data dependencytrack/bundled

I opened Administration -> Analyzers -> Internal and ticked all 3 ‘Enable fuzzy CPE matching’ checkboxes.

Now one can upload a SBOM file and inspect the log file (dependency-track.log):

2022-10-28 13:11:49,749 [] **ERROR [org.dependencytrack.search.FuzzyVulnerableSoftwareSearchManager] An I/O Exception occurred while searching Lucene index**
org.apache.lucene.index.IndexNotFoundException: no segments* file found in SimpleFSDirectory@/data/.dependency-track/index/vulnerablesoftware lockFactory=org.apache.lucene.store.NativeFSLockFactory@1e50f7fb: files: []
	at org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:715)

Additional Details:

As a result of this error a number of vulnerabilities are not found.

See the log file in attachment. dependency-track.log

[nscuro]

@officerNordberg Thanks for investigating. I think the change was necessary because EventSubsystemInitializer also takes care of initializing TaskScheduler. The interval of many tasks in TaskScheduler has been made configurable, and the default configuration is populated in DefaultObjectGenerator.

Perhaps it makes sense to move the initialization of default config properties into its own class, and switch the order of EventSubsystemInitializer and DefaultObjectGenerator again.

[syalioune]

@officerNordberg Thanks for investigating. I think the change was necessary because EventSubsystemInitializer also takes care of initializing TaskScheduler. The interval of many tasks in TaskScheduler has been made configurable, and the default configuration is populated in DefaultObjectGenerator.

That’s exactly the reason. However that was maybe a bit strict since the default values can be derived from the enum ConfigPropertyConstants if the value is not already in the database.

Perhaps it makes sense to move the initialization of default config properties into its own class, and switch the order of EventSubsystemInitializer and DefaultObjectGenerator again.

Maybe create a distinct IndexSubsystemInitializer to make more explicit and decouple it from the DefaultObjectGenerator. That initializer could be last.

Maybe an admin feature to trigger a reindex through the UI might be useful down the road as well.

Totally agree.