I'm afraid this report is probably too lacking in details to provide a diagnosis. I can't diagnose this issue for you without seeing the code.
You definitely should not disregard a static analysis warning as "mitigated risk" when you haven't done anything to mitigate it and don't understand whether the warning represents an exploitable vulnerability or not.
I suggest you start by educating yourself about SQL injection, about security Hibernate, and about this particular warning. Most likely Fortify has online help that provides a detailed explanation about this warning; you should start by reading that. Read the following Fortify backgrounder on SQL injection in Hibernate.
I also recommend the following articles: How is SQL injection typically stopped in a Spring/Hibernate setup,
ORM injection, and How to avoid SQL injection in Hibernate (A Hibernate Urban Legend).
Update (4/20): I see that you updated the question to include the code. Thanks. The code you provided is indeed dubious, and I think it is reasonable for Fortify to complain about that code. Looking at this code, it is not possible to verify that the query passed to
createQuery() is a compile-time constant, which is why Fortify issues a warning message.
Basically, the code you show appears to be constructing a SQL query using string concatenation. That's dangerous. If
propName can be influenced by the attacker, then you've got yourself a possible SQL injection vulnerability. It is best to avoid constructing the SQL query in this way.
In particular, there is a myth out there that using prepared statements (or parametrized queries) is inherently immune from SQL injection. This is true, but only if the query itself is a compile-time constant that cannot be influenced by the attacker. If you insert untrusted data into the query itself, then using it in a prepared statement doesn't somehow magically make you safe.
So the best practice is that, when you use a prepared statement, make sure the query can be readily verified to be a compile-time constant (and cannot be influenced by the attacker).
To sum up the general rules of thumb: (1) Don't use string concatenation to build up a SQL query. (2) When you want some dependence upon runtime values, use prepared statements to bind runtime values. (3) Make sure the query that you use to create the prepared statement can be readily verified to be a compile-time constant. Following these practices should help ward off SQL injection attacks.