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..
5826 views

Centralized SCA Server

Jump to solution

I'm wondering about typical SCA infrastructure.  Currently we have an SSC server stood up and are using SCA on individual workstations and/or build machines.  Is it typical to stand up a centralized SCA server that all users point to for scanning?  If so how do you set something like this up since you need to have the bin files in your path in order to perform a scan via command line?  I realize that there is the CloudScan setup that you can perform using a Hadoop cluster but don't think we're ready for that in our environment quite yet.  For continuous integration infrastructure should the SCA instance be installed on the build server or somewhere else?

Thanks in advance for any assistance.

Mike

Labels (2)
Tags (1)
0 Likes
1 Solution

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

Re: Centralized SCA Server

Jump to solution

Hi Mike,

There's actually a few ways of approaching this, so it will often depend which will be the best fit for you organisation. The first thing to note is that an SCA scan is actually made up of 3 stages: the "clean" where any previously translated code is wiped from the Build ID; the "translation" where the source code is translated to Fortify's .nst format; and finally the "scan" where the SCA analysers and rulepacks are run over the translated code. In the vast majority of cases the scan stage will be significantly more resource intensive than the translation stage.

Smaller organisations can often get away with performing both the translation and the scan on their local machines. Often using Audit Workbench or the IDE plugins. However, this can quickly become cumbersome as the number of scans or the size and complexity of scans increases.

One solution is to use Mobile Build Sessions (page 15 of the ). This allows you to perform the translation on a local machine, where resource may be limited but the relevant project dependencies exist. This can then be exported to a .mbs bundle and moved to a dedicated scanning machine where it's extracted and the scan itself run. .mbs bundles are platform independent. As such, as an example, it's possible to perform an iOS translation on a Mac before creating a Mobile Build Session and running the scan itself on a much larger linux box.

This takes us on to the CloudScan option, which is really just an automated way of using Mobile Build Sessions (docs can be found at HP Fortify CloudScan). As you've mentioned CloudScan is currently slightly limited by the fact that it relies on using a Hadoop cluster to perform the scanning. We are actually in the process of working on an updated CloudScan offering which will allow you to use any dedicated box with SCA installed as the scanning machine - removing the necessity for a Hadoop cluster. I'm afraid I can't give specifics as to when this will be available, but it's on the roadmap for the near future.

Finally, it's also possible to automate SCA scans by integrating them into your existing build process. Probably the easiest way to get started with SCA's build integration is with the . This will help you to create a repeatable script to perform the translation and scan and even upload the results to SSC Server once done. It currently supports the following build integrations: Ant, Makefile, MSBuild, Visual Studio and Xcode. If you're building in a different way just let us know as SCA does integrate with more build tools, this is just what the Scan Wizard currently covers. Once you have your script, this can then be plugged into Jenkins, Hudson etc and run on a regular basis. With continuous build integration I believe SCA would normally sit on the build machine. However Scan Wizard scripts do allow you to integrate with CloudScan and push the scan stage to the cloud.

I hope this helps as a start. If you have any specific queries on any of these methods please feel free to drop us a message at fortifytechsupport@hp.com. Also, if you'd like expert advice and/or assistance in getting SCA setup as part of a secure SDL, we have an awesome Professional Services team who I can link you up with.

Cheers

Simon

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

Re: Centralized SCA Server

Jump to solution

Hi Mike,

There's actually a few ways of approaching this, so it will often depend which will be the best fit for you organisation. The first thing to note is that an SCA scan is actually made up of 3 stages: the "clean" where any previously translated code is wiped from the Build ID; the "translation" where the source code is translated to Fortify's .nst format; and finally the "scan" where the SCA analysers and rulepacks are run over the translated code. In the vast majority of cases the scan stage will be significantly more resource intensive than the translation stage.

Smaller organisations can often get away with performing both the translation and the scan on their local machines. Often using Audit Workbench or the IDE plugins. However, this can quickly become cumbersome as the number of scans or the size and complexity of scans increases.

One solution is to use Mobile Build Sessions (page 15 of the ). This allows you to perform the translation on a local machine, where resource may be limited but the relevant project dependencies exist. This can then be exported to a .mbs bundle and moved to a dedicated scanning machine where it's extracted and the scan itself run. .mbs bundles are platform independent. As such, as an example, it's possible to perform an iOS translation on a Mac before creating a Mobile Build Session and running the scan itself on a much larger linux box.

This takes us on to the CloudScan option, which is really just an automated way of using Mobile Build Sessions (docs can be found at HP Fortify CloudScan). As you've mentioned CloudScan is currently slightly limited by the fact that it relies on using a Hadoop cluster to perform the scanning. We are actually in the process of working on an updated CloudScan offering which will allow you to use any dedicated box with SCA installed as the scanning machine - removing the necessity for a Hadoop cluster. I'm afraid I can't give specifics as to when this will be available, but it's on the roadmap for the near future.

Finally, it's also possible to automate SCA scans by integrating them into your existing build process. Probably the easiest way to get started with SCA's build integration is with the . This will help you to create a repeatable script to perform the translation and scan and even upload the results to SSC Server once done. It currently supports the following build integrations: Ant, Makefile, MSBuild, Visual Studio and Xcode. If you're building in a different way just let us know as SCA does integrate with more build tools, this is just what the Scan Wizard currently covers. Once you have your script, this can then be plugged into Jenkins, Hudson etc and run on a regular basis. With continuous build integration I believe SCA would normally sit on the build machine. However Scan Wizard scripts do allow you to integrate with CloudScan and push the scan stage to the cloud.

I hope this helps as a start. If you have any specific queries on any of these methods please feel free to drop us a message at fortifytechsupport@hp.com. Also, if you'd like expert advice and/or assistance in getting SCA setup as part of a secure SDL, we have an awesome Professional Services team who I can link you up with.

Cheers

Simon

0 Likes
Super Contributor.. ellerm Super Contributor..
Super Contributor..

Re: Centralized SCA Server

Jump to solution

That information is extremely useful and appreciated.  It sounds as though no matter what I'll need to have SCA installed on the device where the code is regardless of using mbs, CloudScan, or a traditional sca scan.  I was hoping there would be a way to remotely call a SCA server via URL to do everything rather than the need to install software, in our current environment we have hundreds of development projects on many servers throughout our organization and trying to ensure that each of those has the correct version of SCA and is configured appropriately is quite the undertaking.  I suppose the only other solution would be to have the development teams push their code to a centralized server where we can scan from there.  I'm very interested in finding out more about CloudScan as it becomes available as well.

0 Likes
Highlighted
Valued Contributor.. sswargam Valued Contributor..
Valued Contributor..

Re: Centralized SCA Server

Jump to solution

When using CloudScan 4.21, is there a way to have a scan delegated to one slave that has more resources?

Do all slaves need to have identical resources such as RAM, cores and hard disk?

Thanks,

Satish

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

Re: Centralized SCA Server

Jump to solution

Hey Satish, in a CloudScan setup the workers are all separate boxes with SCA installed. As such each worker can have as many cores and as much RAM as you like. No need for them to be identical.

CloudScan.JPG

0 Likes
leeh@hpe.com1 Absent Member.
Absent Member.

Re: Centralized SCA Server

Jump to solution

Fortify Translation and Scanning can be coordinated and distributed over a cluster of machines using continuous integration tools.

Successful configuration have been achieved to with Jenkins to name a few, however intergration with other system should be an easy process.

Fortify 4.20 also feature a Dedicated plugin for Jenkins, which can handle uploads for your fortify reports (.fpr) to SSC (Software Security Centre).

Jennkins Plugin—The HP Fortify Jenkins Plugin (Jenkins plugin) is used in conjunction with HP Fortify Software Security Center (SSC). If you scan your source code after each build, the Jenkins plugin automatically uploads the Fortify project results (in an FPR file) to an SSC server and enables you to view the details within Jenkins. It also provides metrics for each build and an overview of the results.

!

Cheers,

Lee CISSP

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.