How to resolve the scanned sql injection problem if the parameterized query is an input that is retrieved from a trusted application system?

I have 2 applications talking to each other using Kafka topic. The 1st application takes the input customer id and based on the customer type, it goes to a trusted internal query library (the 3rd app in the company) to fetch all the queries that need to be executed for this customer. All the queries are parameterized and based on the type of the customer, the fetched queries can be different. These queries are logically saved under the same query group using query planning id. Each of the query and the user input parameters is built in the message payload and then sent to the topic that the 2nd application is subscribed. The 2nd application will use the prepared statement and the user inputs to complete the query and then based on the type of the database, the query will be executed on the right database using the right JDBC adaptor (we use the common code to execute queries against different databases, oracle, PostgreSQL, etc).

After we implement the functionalities, we ran static scans on both applications. The 2nd application got SQL injections alarms for the reason of "SQL query built with input that comes from an untrusted source." Although the parameterized queries are in the request message payload for the 2nd application, the queries are fetched from the trusted query inventory library. Can I tag these SQL injections NAI - Not An Issue?

Solution

It depends.

If you've verified that the value comes from a trusted source (or is validated by a trusted source) it lowers the risk of a vulnerability - but you should also be thinking about your trust boundaries in this system.

Are these two systems within the same trust boundary or does the data cross trust boundaries? Just because you trust system A and trust system B, does not necessarily mean that B does not have to validate data coming from A. Things to think about when defining your trust boundaries:

Will the receiving system ever have the potential to be exposed externally or to other systems? Will it be obvious to future developers that this system is not validating the input. Developers love to reuse APIs, and that's generally good, but it can lead to security vulnerabilities if the assumptions are not clear?
Do you want to provide defense in depth across the systems? If system A is compromised (via a vulnerability) do you want system B to be compromised as well, or do you want more layers of defense in this system?

The fact that you've described these as "applications" would generally indicate to me that you should classify them as in different trust boundaries, especially if it's a security sensitive system. But whatever you decide, you should be explicit about it, and about documenting (in the code and architecture diagrams if you have them) the assumptions you've made. If you decide these two applications are part of the same trust boundary, you should make sure to document that the API that takes these is internal and does not validate the input.

Defining your trust boundaries is a part of defining an overall threat model. Even if you don't use formal threat modeling, the concepts provide a useful framework to think about design decisions.