Static Scanning in Fortify on Demand

Micro Focus Expert
Micro Focus Expert
1 0 1,392

My previous application security blog post talked about The Basics of Shift Left AppSec. The focus was to share perspectives on evolving capabilities to mature an AppSec program to achieve a true automated “Shift Left” security testing process. This is a key element of being cyber resilient, where software security testing is baked in as a part of DevOps.

I wanted to add a few more thoughts for those of you early in your AppSec journey. To do so, I’ll reference two recent videos on our Fortify Unplugged YouTube channel. Make sure to subscribe to see new videos explaining the basics of application security, as well as many semi-technical videos that show our products in action.

Static Scanning in Fortify on Demand.pngThe first video is part of the AppSec 101 series hosted by Fortify Product Marketing Manager Andrew Garrett. This is a great starting point to understand What is Static Code Analysis. Andrew interviews one of our in-house SAST experts, Jimmy Rabon. This will be 15 minutes well-spent.

Then Simon Howard, a Fortify Solutions Architect, put together a really good video explaining Five Ways to Perform Static Code Scans in Fortify on Demand (FoD). If you’re a Fortify on Demand user, or considering it, this really helps sort out the various approaches. I’ll summarize the 5 ways here:

  1. Manually Initiated Scans: From the Fortify on Demand (FoD) browser interface, upload the ‘payload’ (source code and dependencies that are packaged into a zip file). Use the ‘Start Scan’ wizard, and define scan settings beforehand.
  • Pros: No integration effort is required. This can be the quickest approach if you have acces to all of the code and dependencies.
  • Cons: It is possible to miss out dependiencis from zip file, if you don’t know the structure of your code. This will generally cause the scan to be rejected. You need to know the structure of the code and what it depends on.
  1. Scans Initiated Using FoD Uploader: This is an offical Fortify tool that is available on GitHub in binary and source code formats. Scans are initiated from the command-line intervace (CLI) or any script that uses the FoD Uploader tool. Again, source code and dependiencies are packaged into a zip file (the ‘payload’), and various parameters are specified including: zip file, authorization credentials, and application release details. You can do things like use FoD Uploader to poll for results.
  • Pros: No integration effort is required, much like a manual scan, so it’s a quick approach if you have access to all of the code and dependencies. This is particularly useful for a large payload.
  • Cons: Like the manually-initiated scan, it is possible to miss out dependencies from the zip file.
  1. Scans Initiated from a Supported IDE: Fortify plugins are available for several IDEs, including Visual Studio, IntelliJ, and Eclipse. When scans are initated from within the supported IDE, the plugin packages together all source code and dependencies required to scan the application and then uploads the payload to FoD. When scan results are available they can also be reviewed in the IDE.
  • Pros: This is ideal for developer workflows. As scans are performed in the same environment as builds, dependencies will not be missed.
  • Cons: Some integration is required, meaning you need to install the plugin into the IDE. This isn’t a lot of effort, but is a manual process.
  1. Scans Initiated From a CI Pipeline: Fortify plugins are available for Jenkins and Azure DevOps, and other CI platforms, like Bamboo, can be integrated via the REST APIs. All you do is add an additional stage to a pipeline, which causes a scan to occur whenever the pipeline is run (on commit, nightly, etc.). The plugin packages together all source code and dependencies and then uploads the payloads to FoD. Scan statistics can be output to the pipeline results.
  • Pros: This is a fully-automated approach to scanning, and dependencies will not be missed. Additionally, builds can be failed if security policies are not met.
  • Cons: Integration is required, but we make that reasonably easy for you. You need to consider scan frequency with this approach.
  1. Scans Initiated From a Tool that Uses the FoD REST APIs: When the FoD off-the-shelf tools do not exactly fit your needs, you can use the FoD REST APIs to create your own tool. This lets you automate many FoD tasks. The Java source code for FoD Uploader is a good baseline to show how the APIs can be used.
  • Pros: You can fully automated scans, as well as group with other tasks such as report generation
  • Cons: Development effort required to use the REST APIs. Like manually initatied scan, it is possible to miss out dependiencies from the zip file.

 

About Micro Focus Fortify

Fortify lets you build secure software fast with an application security platform that automates testing throughout the CI/CD pipeline to enable developers to quickly resolve issues. Fortify static, dynamic, interactive, and runtime security testing technologies are available on premises or as a service, offering organizations the flexibility needed to build an end-to-end software security assurance program.

Looking to join an industry leader filled with passionate problem-solvers on a mission to help organizations protect their applications from the bad guys? Check out our open positions now.

Have technical questions about Fortify? Visit the Fortify Community. Keep up with the latest Tips & Info about Fortify. We’d love to hear your thoughts on this blog. Comment below. Or go to the Fortify Users Discussion Board to start a conversation.

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.