Hello @gmodena - Would we be able to confirm more specific dates for desired launch dates, etc? Also, we can perform vendor reviews for both QLever and Virtuoso, but if there's one that appears to be the stronger contender / likely choice, we'd probably want to focus on that one. We can probably accommodate this review sometime this quarter (2026-01-01 to 2026-03-31) but would like to address the previous questions prior to making any formal commitment.

Hey @sbassett. Our target launch date is July 2026. However, ahead of that date (throughout Q3 and Q4 of the current FY) both systems will be deployed on test hosts in eqiad and are expected to serve limited traffic for selected use cases.

At the moment, both vendors are strong contenders, and it would be great if both could be reviewed. That information could help inform our final decision.

@gmodena - Sounds good. I still think we can push this review on our end to next quarter. I'm not concerned about the two options being run on test hosts, assuming those will be fairly locked down in Wikimedia production.

In T413229#11497256, @sbassett wrote:

@gmodena - Sounds good. I still think we can push this review on our end to next quarter. I'm not concerned about the two options being run on test hosts, assuming those will be fairly locked down in Wikimedia production.

Terrific! Do you have specific requirements for what lock down measures are needed, or can we move forward and implement auth/blocklisting with SRE?

In T413229#11507530, @gmodena wrote:

In T413229#11497256, @sbassett wrote:

@gmodena - Sounds good. I still think we can push this review on our end to next quarter. I'm not concerned about the two options being run on test hosts, assuming those will be fairly locked down in Wikimedia production.

Terrific! Do you have specific requirements for what lock down measures are needed, or can we move forward and implement auth/blocklisting with SRE?

Sorry you didn't get a response for this. Auth/blocklisting with SRE should be adequate. We're assigning this work now, so let me know if there have been any changes to the plan or the timeline. And if you can provide access to the test hosts for the review, that would be great

In T413229#11779405, @Mstyles wrote:

In T413229#11507530, @gmodena wrote:

In T413229#11497256, @sbassett wrote:

@gmodena - Sounds good. I still think we can push this review on our end to next quarter. I'm not concerned about the two options being run on test hosts, assuming those will be fairly locked down in Wikimedia production.

Terrific! Do you have specific requirements for what lock down measures are needed, or can we move forward and implement auth/blocklisting with SRE?

Sorry you didn't get a response for this. Auth/blocklisting with SRE should be adequate. We're assigning this work now, so let me know if there have been any changes to the plan or the timeline. And if you can provide access to the test hosts for the review, that would be great

No worries! I've been in touch with your team and SRE over slack.

Timeliene still stands. We have documentation on test infra at https://wikitech.wikimedia.org/wiki/Wikidata_Query_Service/Migration/Development_Infrastructure#eqiad_test_nodes. wdqs1028 could be a good guinea pig. Let me know if there anything we can do to help with this process.

Hi everyone. Quick timeline update - we're working on this review and should have this completed by the end of next week. Thank you for your patience!

Hi everyone,

As part of the security review for adopting QLever, we ran a set of static analysis tools across the repository which included Snyk, Semgrep, and Bearer. At this time there are no blocking security concerns for adopting QLever and the overall risk can be considered low. However, we have a few recommendations that we would like you to implement so that the risk can remain low.

1. Avoid exposing auxiliary scripts in production workflows: Static analysis findings were limited to Python scripts (e.g., under misc/) used for benchmarking and data transformation. These scripts should not be integrated into production pipelines or exposed through APIs, as they are not designed to safely handle untrusted input.
2. Ensure all inputs to QLever are trusted or properly validated: If QLever is used to process externally sourced data (e.g., user-generated queries or datasets), implement appropriate input validation and sanitization at the application layer to prevent unintended behavior.
3. Do not rely on auxiliary scripts for security-sensitive workflows: If any of the included scripts are needed, they should be reviewed before use, particularly those involving file handling or sub process execution.

Please feel free to reach out if you'd like details about our security assessment. Thank you!

Hi @aranyap,

Thanks for this!

In T413229#11866419, @aranyap wrote:

Hi everyone,

As part of the security review for adopting QLever, we ran a set of static analysis tools across the repository which included Snyk, Semgrep, and Bearer. At this time there are no blocking security concerns for adopting QLever and the overall risk can be considered low. However, we have a few recommendations that we would like you to implement so that the risk can remain low.

This is great to hear. For my own education, is the output of your static analysis tests available?

We will incorporate your recommendations in our upcoming deployments. How would you like us to keep you in the loop for further reviews?

Hi @gmodena , I will send you the link to the static analysis test results over Slack.

For future reviews, please feel free to reach out to our team if the use-case has significantly changed or this project will be processing personally identifiable information (PII). Thank you again for your patience!

Edit: I was given permission to share the static code analysis results here in this Phabricator task. Here are the security assessment results.