The AppScan Appliance – Adding .NET Solution Scanning On Demand
sp1r0 270002FRMM Visits (1774)
One of the main advantages of having a full Continuous Integration environment integrated with the security scanning tools, all running together on a central server (pronounced “Mainframe”) is the ability for customization to take place, such as the initial phase of Support for ASP.NET MVC 3.0 , and immediately be made available to the entire enterprise.
In this scenario, a key aspect to take into consideration is the fact that the product integration, installation of the development / run time environments and SDKs, as well as the upgrade of various components that was necessary to perform the investigation, initial prototyping and testing of this brand new “customer specific” support was all performed behind the scenes – keeping any dirty laundry hidden while minimizing the perceived complexity.
As this is a concept in process where the twin objectives are to
generate high confidence results and to
communicate these to the developer in the most effective and efficient way, this integration is also the chance to
test out a particular 'developer workflow':
→ The creation of a specific Version Control System (VCS) repository which is to be used by the development team responsible for the MvcMusicStore application.
developer can, at any point, check in and build their code and,
trigger a Sour
→ Once the check in or commit of the code has taken place, the developer can watch the build and scanning taking place by logging into a Web Portal hosted on The AppScan.
→ The results of the scan are filtered according to the specific security policies in place, automatically incorporated into a reporting dashboard in the Web Portal and also made available for download to work with locally.
As I've become more familiar with TeamCity Artifacts, setting and using Environment Variables and Configuration Parameters, my Command Line Interface (CLI) scripts have evolved to be used in a much more generic manner:
Below are screenshots showing this workflow in action, which, of course is just the starting point for what will actually be occurring when
Automated Application Deployment, Dynamic And Static Analysis, Automated Quality and Functional Testing, IPS signature generation,
Virtual Patching, Auto-Fixing...
Here we can see the developer, obviously a Mono Champ to develop C# on a Mac, entering a commit message and syncing.
On the AppScan Appliance side we can see that a build was triggered and details about the user including the commit message.
Now the developer can log in to the AppScan Web Portal to view the overall progress of the build.
And can view the details of the build and scan in real time in the Build Log.
The ability to perform involved customization work, adding support for an entirely new 'custom' framework, behind the scenes is
certainly a step in the right direction in terms of reducing complexity for the consumer.
Being able to implement a workflow for the developer to initiate scans and view / download the results in such a relatively easy manner
seems like a nice testament to the ongoing evolution of this "Appliance" concept or "The AppScan" as some are now referring to it.