Having problems with your account or logging in?
A lot of changes are happening in the community right now. Some may affect you. READ MORE HERE
Super Contributor.. ellerm Super Contributor..
Super Contributor..
4585 views

Jenkins Cloudscan

I'm curious if anyone uses Cloudscan with Jenkins.  I'd like to hear more about your setup.

Labels (1)
7 Replies
Highlighted
sspringett Super Contributor.
Super Contributor.

Re: Jenkins Cloudscan

My org uses a global Jenkins and CloudScan infrastructure.

We use the Jenkins Custom Tools plugin and define a custom tool for each SCA version. On a job config, we 'install' the custom tool which basically puts that specific version for SCA in the path so it can be used. This allows a team to easily change between SCA versions with a simple change to a drop down. We only run SCA on Jenkins slaves.

Our SCA installations on Jenkins slaves do not have any rulepacks installed, nor is the update URL valid. So they cannot be used to perform an analysis, thus forcing the use of CloudScan.

We utilize the open source Fortify CloudScan Jenkins plugin (which I wrote) making CloudScan configuration really easy for the teams. In our environment, ease of configuration is vitally important as the security team is not configuring the jobs, we only provide consulting advice, best practices, or answer questions when they come up.

Our dedicated CloudScan hardware consists of machines with 32 cores and 256GB RAM. We have multiple of these machines and we support two versions of SCA at any given time. This is usually the current release, and one release back. There are always exceptions to this as we perform testing of each SCA version prior to rollout to ensure a release doesn't cause adverse effects on our results.

Rulepacks are always updated on SSC and we have a regular update process to ensure the CloudScan workers always have the latest rulepacks.

We also have an Intranet where we have every rulepack produced since 2012 available to the teams. We also have the optional insider-threat rulepacks there as well as custom rulepacks. So if a team wants to use specific rulepacks, they can specify the URL to the rulepack in the CloudScan Jenkins config.

My org simple doesn't accept results if they were not produced by CloudScan. We find that all that hardware can produce better results than a typical desktop-class machine, even if you don't experience the out of memory issues. So per policy, we require CloudScan. We maintain a Jive page that details when the next Fortify version will be made available and when versions will be decommissioned. We also have information on rulepack updates available.

For us, CloudScan produces better results, faster, and operates asynchronously. Once translation and cloudscan packaging has occurred, the Jenkins job completes but the scan is just getting started. So the security team isn't seen as a blocker. Our DevOps teams like their jobs to complete within 5-10 minutes (max) and with CloudScan, this is easily accomplished.

Tags (1)
Super Contributor.. ellerm Super Contributor..
Super Contributor..

Re: Jenkins Cloudscan

Thank you so much for the reply!  This is the type of information I was looking for.  Right now I have one big monolithic Jenkins server with SCA installed that runs all the scan jobs.  This isn't ideal so I'm considering a switch to Cloudscan environment and ordered a new server to be used as the scanning machine (256GB RAM and 32 Cores).  What kind of resources does the controller require?  I'm considering putting the controller on the same machine as SSC since I already have that server.  That server has 48GB of RAM and 16 Cores.  We do not use SCA on desktops in our environment for scans.  We only trust centralized scans so using Cloudscan will certainly help us scale more effectively.

sspringett Super Contributor.
Super Contributor.

Re: Jenkins Cloudscan

In our environment, the CloudScan controller and SSC are on separate virtualized machines. We find it easier to simply use the bundled Tomcat/CloudScan distribution and move in our config rather than trying to deploy the war separately. So packaging-wise, you may be better off with them separate. Not sure if there would be any conflicts or not running them on the same machine. Never tried.

All our Jenkins machines, SSC, and CloudScan controller all run on virtualized hardware with snapshots of each instance available allowing us to recover a machine from scratch in about a minute. The virtualized hardware we use for the CloudScan controller is 1 core and 16GB RAM. We find that this is more than adequate to handle a global infrastructure with 50+ products being scanned on a regular basis.

We've been using CloudScan since 4.30 and it was the best move I ever made - wish I would have done it sooner.

My only complaints about CloudScan is it doesn't clean up after itself really well, and the REST API isn't documented. We've solved the first problem with carefully crafted cron jobs. The second issue can easily be reverse engineered, but just never have the time to sit down and do it.

salgak2017 Absent Member.
Absent Member.

Re: Jenkins Cloudscan

Excellent information.  My current enterprise is moving both to Cloud and to DevOps as a model.  A question: has your Jenkins plugin been tested with v17.0/17.1 ???

Also, which Cloud environment are you using ?  We're using AWS. . .

sspringett Super Contributor.
Super Contributor.

Re: Jenkins Cloudscan

Keith, we have not deployed 17.1 yet, but expect to begin testing the release next week. It's currently working with 16.2. I don't anticipate any issues with 17.1, but if there are, I will be fixing them. Also, since this is an open source project, feedback and pull requests are welcome.

GitHub - jenkinsci/fortify-cloudscan-plugin: Jenkins plugin for HP Fortify CloudScan

As far was cloud environments. my org uses several, primarily AWS, but we use multiple vendors. Not to confuse the issue, but CloudScan doesn't actually require the cloud. It's designed using tech/architecture that would be typical of cloud environments, but is packaged in a way that (by default) is optimized for on-premise environments.

salgak2017 Absent Member.
Absent Member.

Re: Jenkins Cloudscan

We're still trying to decide what to do. . . .a lot of it is who pays for what, and that's always a fun battle. . . for values of "fun" approaching zero. . . .    but at least from your description of your virtual boxes, they sound like fairly pricey r4x8large AWS instances. . . .and you run quite a number of them.


Part of our larger initiative is a parallel move two a private cloud and moving programs to a DevOps paradigm. . . .  so I'm trying to come up with the most cost-effective solution that meets the need. . .

Tech question: Do you have an autoscale group configured, to launch additional sensors in the pool as needed ??

sspringett Super Contributor.
Super Contributor.

Re: Jenkins Cloudscan

My org does not run CloudScan in the cloud. We run it on-prem along side an army of high-end CloudScan workers.

Running on-prem allows us to adapt to whatever development methodology a team is using. For more traditional agile teams with on-prem git or svn repos, we're able to scan on every commit allowing them to get near immediate feedback. For the more DevOps teams that are pushing to production 20 times a day whos code is hosted in Git Enterprise for example, we're able to do the same.

So we run CloudScan on-prem. You might find it difficult to use CloudScan in the cloud. There are settings to replace the embedded H2 database with Hadoop for example. And as you pointed out, the workers running SCA need to be extremely high-end and costly machines. The CloudScan controller distributes jobs to CloudScan workers in a round-robin fashion until it finds one that's free. If all workers are busy processing other jobs, it's places it in the queue until a worker is free. No load balancer required.

One solution that does use CloudScan in the cloud is Fortify on Demand. They basically have a global CloudScan infrastructure and support two versions of SCA at any given time (the current release and one major release back). The only difference being that their CloudScan controllers are not using Software Security Center. Instead, they have a cloud-first, multi-tenant web interface along with REST APIs that allow you to securely interact with the service. If I had a requirement to have a scanning infrastructure in the cloud, I don't think I would try to create one, I would likely choose FoD as they've already done all the hard work.

BTW, My org is largely an on-prem Fortify customer, but we're also a FoD customer, as we find value in both depending on the use case.

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.