The only documentation that I found online was: That type of development environment is not available to me. Micro Focus provides an overview of how this process can be modeled.
FORTIFY JAVA ANNOTATIONS SOFTWARE
The preferred means of identification, mitigation, and resolution is through the Audit Workbench and Fortify Software Security Center that is integrated into supported Testing and QA processes. This is not, however, the preferred means by which Fortify issues "should be" resolved. The answer that I arrived at was the use of Fortify Annotations. Specifically for use in having a set of "SQL Injection" and "SQL Injection: Persistence" issues omitted from Fortify Scan results. I cannot find an adequate guide/manual online that will list the available in-code annotations and provide an example for their intended use. etc.) at the points at which a problem is flagged by the Fortify scan. I would like to place an annotation (or other in-code construct) (e.g. The end evaluation is that the issue remains in the scan results, it is critical, and therefore MUST be resolved.
FORTIFY JAVA ANNOTATIONS CODE
Placing an "Ignore this" comment in the code does not satisfy the goal state either. Suffice it to say, creating a set of "False Positives" to import prior to a Fortify Scan is "not an option" nor is marking "known issues" as "Not an Issue". Of course, none of these are satisfactory for the Fortify Scan.Ĭreating and storing a custom rule that is external to the code and applied to the scan results is "not going to work" because of "reasons". of these 2 approaches are sufficient for Fortify.Īdditionally, the suspect input String is also validated against known and valid values (the values are pulled from the database, so Fortify also finds that those values are also "suspect"). Using an annotated method declaration that sends the input though a regex parser has also been part of the validation e.g. The (7 character) String is fed through a Regex parser: pile(HARDCODED_REGEX_CONSTANT).matcher(suspectString) Sanitizing the input String is ridiculously easy.
This "cannot be changed" and DDL statements cannot be parameterized.
The "suspect" input String arrives from the client and then becomes part of a DDL Statement ("ALTER SESSION. Additional Information: The code exists as part of a web application.Platform: Java 8 Web App (Weblogic 12.2.1.4.0 (12c)) Redhat Unix.I am looking for a guide/manual that will list the available in-code annotations and provide an example for their intended use.
The short, short, really short version is: I have a question regarding the names and syntax for using Fortify Code Annotations.
0 kommentar(er)
