Highlighted
alosilva@hpe.co Absent Member.
Absent Member.
8984 views

When I try to upload .FPR to SSC i got an error

Jump to solution

When I try to upload .FPR to SSC i got an error:

Exception: An unexpected error occurred during scan processing: com.fortify.manager.exception.FMDALGeneralException: An unexpected error occurred.

Info: The following exceptions have been approved for processing by admin:

The version of the external metadata file "ExternalMetadata/externalmetadata.xml" is more recent in the scan than on the server.  The external metadata file in the scan will be ignored.

All SCA rules are imported to SSC.

Someone knows how to address this kind of error?

Labels (2)
0 Likes
1 Solution

Accepted Solutions
simon.corlett@h Absent Member.
Absent Member.

Re: When I try to upload .FPR to SSC i got an error

Jump to solution

The externalmetadata.xml file provides the mappings between the Fortify categories and the various polices we support, ie. OWASP, PCI, STIG etc. This is applied at scan time and the additional metadata added to each issue. When you open an FPR you’ll find you can group by or filter on any of these policies.

Prior to v3.60 this was hardcoded into the SCA rulepacks. However we separated it out to allow customers to edit the existing mappings or add their own internal mappings. It’s managed by our Security Research team and updated along with the rulepacks on a quarterly basis. You can find a little bit more on this on Page 14 of the .

When you upload an FPR to SSC we check the version of the externalmetadata.xml file against the one stored on SSC under Administration -> Rulepacks -> Main External List Mapping. By default if the version on SSC is older than that in the scan we require approval.

There's 2 ways to prevent this:

  • Update the version on SSC Server to be the same or newer than those used in the scan. In Administration -> Rulepacks either click the Update button to pull the latest rulepacks + externalmetadata.xml from our update server, or click Import and locate the file you're using at scan time under <SCA install dir>\Core\config\ExternalMetadata.
  • Alternatively, turn off the analysis processing rule in SSC which forces us the require approval. Open a Project Version and go to General -> Analysis Processing Rules. Uncheck any which you don't want to be held up by requiring Approval.

SSC version 4.10 introduced an exciting new properties file which allows you to globally adjusting the analysis processing rules. This can be found inside the ssc.war itself - so I’d recommend cracking open the .war and setting this before deploying to you Application Server.

The file you need is:

ssc.war\WEB-INF\config\processing-rules.properties

and the property you’ll need to set to false is:

externalListVersionProcessingRule.enabled

0 Likes
3 Replies
simon.corlett@h Absent Member.
Absent Member.

Re: When I try to upload .FPR to SSC i got an error

Jump to solution

The externalmetadata.xml file provides the mappings between the Fortify categories and the various polices we support, ie. OWASP, PCI, STIG etc. This is applied at scan time and the additional metadata added to each issue. When you open an FPR you’ll find you can group by or filter on any of these policies.

Prior to v3.60 this was hardcoded into the SCA rulepacks. However we separated it out to allow customers to edit the existing mappings or add their own internal mappings. It’s managed by our Security Research team and updated along with the rulepacks on a quarterly basis. You can find a little bit more on this on Page 14 of the .

When you upload an FPR to SSC we check the version of the externalmetadata.xml file against the one stored on SSC under Administration -> Rulepacks -> Main External List Mapping. By default if the version on SSC is older than that in the scan we require approval.

There's 2 ways to prevent this:

  • Update the version on SSC Server to be the same or newer than those used in the scan. In Administration -> Rulepacks either click the Update button to pull the latest rulepacks + externalmetadata.xml from our update server, or click Import and locate the file you're using at scan time under <SCA install dir>\Core\config\ExternalMetadata.
  • Alternatively, turn off the analysis processing rule in SSC which forces us the require approval. Open a Project Version and go to General -> Analysis Processing Rules. Uncheck any which you don't want to be held up by requiring Approval.

SSC version 4.10 introduced an exciting new properties file which allows you to globally adjusting the analysis processing rules. This can be found inside the ssc.war itself - so I’d recommend cracking open the .war and setting this before deploying to you Application Server.

The file you need is:

ssc.war\WEB-INF\config\processing-rules.properties

and the property you’ll need to set to false is:

externalListVersionProcessingRule.enabled

0 Likes
alosilva@hpe.co Absent Member.
Absent Member.

Re: When I try to upload .FPR to SSC i got an error

Jump to solution

Your explanation was very helpful!

By the way, I figured out that the problem was related to the version of SQL Server JDBC driver. I was using version 4.1 in scc configuration. After I changed the driver to version 4.0 SCC starts to work like a charm.

Thank you very much!

0 Likes
Vlad M
New Member.

Re: When I try to upload .FPR to SSC i got an error

Jump to solution
Hello. I appreciate that a lot of time has passed since you had this issue, but could you please provide a bit more detail regarding your actions to solve this issue? Where did you have to go to check and change the version of SQL Server JDBC driver?
0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.