You know what tables are in your database, so you can essentially whitelist your dynamic query to only allow for queries to your actual tables. You could query your valid tables from your information_schema tables, but you probably shouldn't give CF access to those tables unless absolutely needed. Granted, those permissions can also be done at the database level. I'm also guessing you also have a way to validate correct emp_ids on login, so you could validate that emp_id and set the dynamic table variable before putting it back into the query. Regardless, cfqueryparam isn't appropriate for using in a dynamic table name, even if it does appear to work.
I would imagine there's a way to explicitly ignore this flag in Veracode, for situations just like this. But I would also add that any time you are creating dynamic SQL, you should apply extra caution and validation to keep anything nefarious from entering your database. But again, only give CF the database permissions that it needs, and that will help a lot.
NOTE: I'm not sure what version of Veracode you're using, but, after some basic searching, it looks like Veracode does application-level ignores instead of just block-level. I wouldn't recommend ignoring this type of error application-wide. You'd still want to flag it so that you don't miss any instances that you aren't handling yourself.
EDIT: And also do like the the above selections suggest and clean the input itself.
Clik here to view.
