=== is duplicated by: S3371

=== relates to: S3649

=== replaces: S1877

=== on 12 Oct 2014, 16:47:56 Freddy Mallet wrote:
@Ann, I would associate this rule to Findbugs rules : SQL_NONCONSTANT_STRING_PASSED_TO_EXECUTE,SQL_PREPARED_STATEMENT_GENERATED_FROM_NONCONSTANT_STRING

=== on 12 Nov 2014, 15:41:27 Sébastien Gioria wrote:
May I suggest to setup default severity as "Blocker" ? We should not find anymore Dynamic query in the source code without sanitizing. 




=== on 21 Nov 2014, 15:22:02 Freddy Mallet wrote:
Fine for me [~ann.campbell.2] and [~sebastien.gioria] to increase the severity to "Blocker"

=== on 21 Nov 2014, 17:33:03 Ann Campbell wrote:
\[~freddy.mallet] I considered this, but our guidelines specifically say SQL Injection rules should be Critical. Guess I should have annotated the ticket accordingly. :-/


cc [~sebastien.gioria]

=== on 24 May 2016, 13:13:14 Ann Campbell wrote:
ABAP reference: \https://www.kiuwan.com/blog/security-business-oriented-languages-abap/

=== on 26 May 2016, 11:44:21 Nicolas Bontoux wrote:
PL/SQL reference https://oracle-base.com/articles/misc/literals-substitution-variables-and-bind-variables[here] . Note that for PL/SQL this best practice is not just about security, there's also a performance impact (soft/hard parsing logic).

=== on 16 Jun 2016, 15:54:30 Freddy Mallet wrote:
\[~ann.campbell.2] there is a huge difference between the two rules :

* In PL/SQL, when using Literals or Substitution Variables there is absolutely no risk to change the structure of the SQL request to do something which is not expected -> so we absolutely don't care about the content of literal or substitution variables and a so about the fact that those values should be sanitized. The only overlap between the two rules is the remediation action but the purpose is absolutely not the same

=== on 17 Jun 2016, 13:48:52 Ann Campbell wrote:
To close the thread, we'll leave PL/SQL here

=== on 19 Sep 2018, 15:12:19 Nicolas Harraudeau wrote:
This rule becomes a Hotspot. The corresponding vulnerability is  RSPEC-3649.

