Swift: Fix some FPs from the sensitive data library #13167
Conversation
| this.asExpr() instanceof EncryptedExpr or | ||
| this.asExpr().getType().getUnderlyingType() instanceof BoolType | ||
| } | ||
| } |
There was a problem hiding this comment.
@MathiasVP do you happen to know whether a potentially large set of barriers (here: all expressions of Bool type) is likely to be a performance problem or will only be evaluated in the restricted context of nodes on a potential flow path? (if you're not sure, I will spend a bit of time investigating this)
There was a problem hiding this comment.
A large barrier predicate isn't generally an issue, no 🙂. The barrier will be evaluated prior to any real dataflow computation takes place so it won't be restricted to be nodes along path candidates, but I doubt that this will be an issue.
There was a problem hiding this comment.
We've done similar things in C++ in the past (i.e., block flow through all integral-typed expressions), and performance for this has always been fine. So I'm not concerned about this at all.
MathiasVP
left a comment
MathiasVP
left a comment
There was a problem hiding this comment.
LGTM once we have a DCA run!
|
DCA shows two less alerts for |
|
Yep, looks like we went from 2 -> 0 results. Merging! |
|
... by which I mean re-running a failed check ... |
|
Thanks! |
2 participants
Add tests for and fix some FPs caused by the sensitive data library. These patterns have been observed in real world projects at various times.
In addition to removing likely FPs, the regexp changes do introduce a few new possible results (e.g. matching
mob_num,home_no,fax_num), but based on a large MRVA run I don't expect this to have a big impact.I should probably run DCA on this PR to confirm it removes the three FP results that show up there.