

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
Hi,
Many of our developers rely on Maven SCA plugin to get their code scanned. And there has been some frustration seen by them with our not being able to tell how to suppress certain false positive vulnerabilities via a Data flow rule that they created through the Rule wizard tool.
mvn --settings test-settings-local.xml -Dfortify.sca.source.version=1.8 -Dfortify.sca.tests.exclude=true -Dfortify.sca.exclude="target:node_modules:part-ui-tests:src/test:src/main/webapp:*pom.xml:**/pom.xml" -Dfortify.sca.JavaClasspath="C:\Users\kpuvvada\GitPivot\part_analytics\partwebportal\target\part-web-portal\WEB-INF\lib" -Dfortify.sca.RulesFile="C:\Users\kpuvvada\AppData\Local\Fortify\CRE-20.2.0\rules\AccessControlDatabase-part.xml" -Dcom.fortify.sca.RulesFile="C:\Users\kpuvvada\AppData\Local\Fortify\CRE-20.2.0\rules\AccessControlDatabase-part.xml" -Dfortify.sca.debug=true -Dfortify.sca.upload=false sca:translate sca:scan
Is the above syntax not correct? Apparently so. When we look at the resultant fpr files from the scans, we still see the rule desired to be blocked being reported as vulnerability. The said rule category has been previously reviewed and concluded by our organization and we have deemed it as not-applicable or just noise. If someone can please provide me the correct syntax, I will greatly appreciate the help.
Accepted Solutions

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
I just checked the plugins directory of the installed SCA, it has the source code of the Maven plugin. In it, I can see that the plugin's scan phase will honour properties such as fortify.sca.rules (which, according to the javadoc, can be created by the nested rules and rule tags, apparently in pom.xml).
Another idea would be to set up a shell script /opt/fortify/bin/sourceanalyzer.sh and point to it with -Dfortify.sca.sourceanalyzer.executable=/opt/fortify/bin/sourceanalyzer.sh on the Maven command line.
/opt/fortify/jre/bin/java -D... -Xmx.. -jar /opt/fortify/Core/lib/exe/sca-exe.jar -rules "${FORTIFY_RULES:-/opt/fortify/Core/config/rules}" "$@"
and manipulate it with an environment variable (exported shell variable).

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
I just checked the plugins directory of the installed SCA, it has the source code of the Maven plugin. In it, I can see that the plugin's scan phase will honour properties such as fortify.sca.rules (which, according to the javadoc, can be created by the nested rules and rule tags, apparently in pom.xml).
Another idea would be to set up a shell script /opt/fortify/bin/sourceanalyzer.sh and point to it with -Dfortify.sca.sourceanalyzer.executable=/opt/fortify/bin/sourceanalyzer.sh on the Maven command line.
/opt/fortify/jre/bin/java -D... -Xmx.. -jar /opt/fortify/Core/lib/exe/sca-exe.jar -rules "${FORTIFY_RULES:-/opt/fortify/Core/config/rules}" "$@"
and manipulate it with an environment variable (exported shell variable).

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
I forgot that the rules apply only to the analysis mode of invokation, so unless there is a pressing need to analyze within the maven invokation, the maven invokation can be reserved just for the translation goal of the plugin. The analysis can reuse the translation by referring to the same "build ID" that was given as a maven command line parameter -Dfortify.sca.buildId=BUILDID.