You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Adding support to JSR305 @Detainted / @tainted / @Untainted in the taint analysis would allow to more easily mark specific classes / methods to ignore some of the violations raised by find-sec-bugs.
For example, in the projects that I work with, we regularly have values coming from configuration files that we implicitly trust. We tend to ignore the warnings generated as false positives (with @SuppressFBWarning), but that will lead to less trust in the tools. We could use custom signatures / configuration to mark some of our own classes as trusted. Having a simple way to mark trusted classes directly in code via annotations seems simpler and helps improve the documentation of the code itself. Since JSR305 already provides annotations that match this use case, it seems like a good idea to use them.
The text was updated successfully, but these errors were encountered:
Description
Adding support to JSR305 @Detainted / @tainted / @Untainted in the taint analysis would allow to more easily mark specific classes / methods to ignore some of the violations raised by find-sec-bugs.
For example, in the projects that I work with, we regularly have values coming from configuration files that we implicitly trust. We tend to ignore the warnings generated as false positives (with @SuppressFBWarning), but that will lead to less trust in the tools. We could use custom signatures / configuration to mark some of our own classes as trusted. Having a simple way to mark trusted classes directly in code via annotations seems simpler and helps improve the documentation of the code itself. Since JSR305 already provides annotations that match this use case, it seems like a good idea to use them.
The text was updated successfully, but these errors were encountered: