Error in integrating fortify-cloudscan-jenkins-plugin

[Vin]

Hi Team,

I'm facing difficulty integrating  fortify-cloudscan-jenkins-plugin with my jenkins.

I'm getting below error and Job is failing

2016-06-18 23:50:40,256 [ERROR] com.fortify.cloud.cli.command.ExportMbsCommand - [error]: Unable to load build session with ID "{BUILD_ID}". See log file for more details.

2016-06-18 23:50:40,256 [ERROR] com.fortify.cloud.cli.command.ExportMbsCommand - Error occurred while exporting mobile build session.

java.lang.Exception: Error occurred while exporting mobile build session.

        at com.fortify.cloud.cli.command.AbstractCommand.logAndThrowException(AbstractCommand.java:176)

        at com.fortify.cloud.cli.command.ExportMbsCommand.runProcess(ExportMbsCommand.java:72)

        at com.fortify.cloud.cli.command.ExportMbsCommand.execute(ExportMbsCommand.java:55)

        at com.fortify.cloud.cli.AbstractMain.execute(AbstractMain.java:174)

        at com.fortify.cloud.cli.Main.main(Main.java:40)

 What is the value to be used for Build ID. I have used {BUILD_ID} as the value. Please help

[steve.s...@owasp.org]

Vim,

Build ID in this context is not referring to the traditional Jenkins BUILD_ID, it's referring to the buildId used by Fortify sourceanalyzer. So a Fortify build that runs through a clean and translation phase with a buildid of 'myproduct' for example, would also need to use 'myproduct' as the buildId in the CloudScan plugin.

--Steve

[Vin]

Thank you so much. Will I be able to translate the code using Fortify 3.5 version and send the build to cloud scan using this plugin?

[Vin]

with  cloud scan setup with Fortify 16.10 version*

[Steve Springett]

Vin,

It’s been several years since I’ve used Fortify SCA 3.x, but in general, if you send a job to the Cloudscan controller (16.10 in your case), you’ll need a corresponding Cloudscan worker to process the job (3.5 in your case). The Cloudscan Jenkins plugin is simply a wrapper around the cloudscan executable distributed with Fortify - makes it much simpler to configure and maintain jobs. So if you’re able to perform a Cloudscan job from the command line, you’ll be able to do it with the Jenkins plugin. If you’re unable to do it from the command line, the Jenkins plugin won’t be able to either.

Starting with Fortify 4.30 (I think), Cloudscan was included with the standard SCA distribution. Prior to that and users had to setup each SCA installation individually as a Cloudscan worker.

—Steve

--
You received this message because you are subscribed to a topic in the Google Groups "Jenkins Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jenkinsci-dev/omV6sTMNT_U/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/ca9942cf-5d62-4dc3-92a2-a8b77995e3d2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Vin]

I have Controller and workers are 16.10. SCA in Jenkins I have 3.5 version. Will I still be able to submit the job from Jenkins to Cloud scan?

Regarding build Id, from Jenkins I have to execute the maven command mentioning build Id and the same has to be used in Cloud scan configuration right?

mvn com.hpe.security.fortify.maven.plugin:maven-sca-plugin:translate

Thanks,

Vin

[Steve Springett]

Vin,

The Cloudscan controller will automatically send the Mobile Build Session file to an available worker running the same version of Fortify as what was used during translation. So if you translated with Fortify 3.5, the Cloudscan controller will only send to a worker running 3.5x.

My organization has a policy that we support the current version of Fortify and one release back. No other versions of Fortify are accepted by the security team. This is similar to what Fortify on Demand does (current version and one release back).

By doing this, you can have a centralized controller, and two groups of workers (one for each SCA version your organization supports). If teams can use any version of Fortify they want, you’ll also need to ensure you have Cloudscan workers for every version of Fortify used. This quickly becomes unmaintainable.

Yes, the Maven plugin will actually use the artifact id as the build id (i think - or something like that). But yes, whatever the build id is when running the maven plugin, that’s what you’ll use in the Cloudscan plugin configuration.

—Steve

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/af9e0200-ae4e-44fa-b0bd-06e5791e3c1a%40googlegroups.com.