Does anyone know if there is a way to integrate WebInspect into the code build process? We would need to pare back the rules that are used to save time and focus and focus more on things like cross-site scripting, etc.
Can WebInspect be used earlier in the life-cycle than the Pre- and Post-production phases?
Can WebInspect be integrated in the developer's build process?
What are the best configurations for using WebInspect in a QA or Dev environment?
Also, I would be remiss if I did not mention that HP Fortify has other products available for SAST testing of your code directly. Our SCA product and scan engine can be used in a variety of ways and places, including IDE plug-in, standalone UI, CLI, from the build server, or delegated to the Cloud. This product can interface an entire team of users via the HP SSC Server, offering Governance and Collaboration features plus integrations to a variety of secondary systems. And all of the DAST and SAST testing you can do on-site with our software solutions can also be run or augmented via our Fortify On Demand ("FoD") SaaS service. For a light-weight taste of this FoD system please visit FortifyMyApp.com.
1) Can WebInspect be used earlier in the life-cycle than the Pre- and Post-production phases?
Yes. The only technical requirement is that the code is hosted on a web server. The hard part will be identifying your organization's work flow and how to incorporate the dynamic tests into that.
Some customers just verbally request the test by their WebInspect user(s). Others use an internal form or ticketing system to help tack these requests. The WebInspect results are often generated as a report to be distributed or hosted internally, or they can be published into HP Quality Center (ALM( or IBM ClearQuest as defects.
If the customer uses our HP WebInspect Enterprise or older HP AMP product, the developers might have direct access to log into that server's web UI to configure and run their own scans, limited by their user role.
2) Can WebInspect be integrated in the developer's build process?
As an example, using our WebInspect Enterprise product, the developers work within the HP SSC Server web UI. When their code is scan-ready, they can request a Dynamic test for their current Project in SSC. This Scan Request requires they complete a form to provide necessary application and authentication details for the target application. Once completed, this Scan Request appears within the web UI of the WebInspect Enterprise server where it will be picked up and manually run by one of the Secops team trained in using WebInspect. Once completed, the security staff will review and edit the scan results, then Publish the verified items back into the SSC Server. These results will then be available to the developer within the SSC web UI, in their Project alongside any static analysis results they have from HP SCA.
Alternatively, your team may opt to create your own system and process. The WebInspect desktop product does not have an API, but it does offer a full-featured CLI. Using batch files and other established tools, it is possible to remotely trigger WebInspect scans via this CLI. It would be best to configure a general saved scan settings file for this purpose, and to then specify that setting file when issuing the scan command. Since this is a single workstation installation, it is possible that this sort of crude use will run into resource bottlenecks as your development team becomes more comfortable with submitting these requests. You might be able to control this growth by only issuing the WebInspect scan command at the times that the build system has completed its most recent build, or perhaps once weekly. The CLI scan offers output options such as automatic Report or Export generation upon completion of the scan. The resulting files could be picked up from a shared folder and transferred via other processes that you design and build.
3) What are the best configurations for using WebInspect in a QA or Dev environment?
The primary need here is to understand the scan policy choices as well as the available attack engines. Open the Policy Manager tool in WebInspect and familiarize yourself with the three views: Threat Classes, Severity, and Attack Groups. Attack Groups provides the best detailed view. Also review the Search function and its options.
The Standard scan policy is a good balance between speed and thoroughness, but it is primarily used against web applications that are ready for deployment. This means that it will spend a good amount of time on Discovery of the site structure as well as flag verbose error messages as vulnerabilities. In such an early life cycle phase, you will probably have verbose messaging enabled, so this could result in many findings that will be "cleaned" once the application has been properly deployed.
The Standard policy is effectively the combination of the Application ("Application-Only") policy and the Platform ("Platform-Only") policy. The Application will disregard any implementation issues for your test server. Similarly, the Platform-Only policy can be used to review your planned implementation server. If you need to speed up the Standard policy, you could opt to use the Criticals & Highs policy, which is just the "upper half" of the Standard policy's selected attacks. The QA policy omits simple items for a QA environment, such as those verbose error message findings, and focuses on simpler items that would pertain to an early version of the application. There are other application-focused policies to select such as the Cross-Site Scripting, SQL Injection, or Aggressive SQL Injection policies.
You may create your own policy within the Policy Manager tool. From the File menu, select "New" and then choose the HP policy you would like to use as your base. If you want to start from scratch, select the "Blank" policy. As I said before, the Attack Groups view offers you the best option for modifying the attacks. The Audit Engines listed can be thought of as the "head of the snake". The many, many individual attacks available are linked with one or more of these engines. By disabling just the engine, you need not worry about disabling all the linked attacks shown lower in this tree view. And you would not want to, as you may still want those attacks to be used with their other linked audit engines. For example, you might disable Header Injection and Cookie Injection, but leave the Query and POST Injections engines enabled.
If is also possible to shape the scan to target only selected areas of the application. Features such as Restrict To folder, Session Exclusions, Audit-Only, Workflow or List-Driven scans can all be combined to do this. Since you have direct access to the application, you may want to use the Basic Scan Wizard to access the List-Driven scan option, and provide an XML input file listing the site structure. Read up on the FilestoURLs tool hidden in the WebInspect installation folders for information on this.
Additionally, you could augment WebInspect into "WebInspect Real-Time" by deploying our HP SecurityScope agent on the target web app server (Java or .NET). This "WIRT" combination of WebInspect plus SecurityScope provides advanced information such as attack verification, Duplicates bundling based on source-to-sink information, stack traces with LOC details, and automatic discovery of hidden folders, structures, and inputs. To see these differences yourself, open WebInspect and import the two sample scans named "Riches" buried within the WebInspect installation folder.
-- Habeas Data Micro Focus Fortify Customers-Only Forums – https://community.saas.hpe.com/t5/Fortify/ct-p/fortify