News Stay informed about the latest enterprise technology news and product updates.

Security scanning on both sides of the firewall

Recently, WhiteHat Security announced Sentinel PL (PreLaunch), a service for website security testing done before an application is released to production.

Senior Analyst from the 451 Group Wendy Nather says:

With Sentinel PL, WhiteHat is addressing the growing need to move security testing farther upstream in the software development lifecycle. Catching problems earlier means lower remediation costs and better-informed risk management in the release process.

It’s undisputed that the earlier in the software development cycle that defects are found, the easier and cheaper it is to fix them. However, security testing is often only done post-release, if at all. While there is still the need to test security post-release, it makes sense to test whatever can be tested pre-release as well.

The other day I spoke with WhiteHat CSO Bill Pennington and product specialist Ravi Iver about their service and the announcement. Up until now their service began once the code was complete and deployed in a production environment. They heard that their customers felt their service could be improved if some testing could be done in the pre-production environment.

I asked about some of the differences in testing in pre-production versus post-production.

Pennington answered that there were several tradeoffs that needed to be made for production testing to ensure availability, stability, performance and security.

[In production] we’re pretty low and slow. We generate less overhead than a standard Web browser. All of our tests are non-destructive, so when your looking for things like cross-site scripting (XSS), there’s two ways to do it. You can inject live JavaScript into the site. If you do that, then if they do end up having a vulnerability, you can drop in pop-up windows all over their site, which is not going to do much for confidence or their consumers, and it’s going to lead the bad guys on the path to directly where that vulnerability is. So the approach we take is to drop in pseudocode for those types of tests, chunks of things that are omnipotent and non-executable, that when we look at them we know a vulnerability is there, but no one else will.

We’ll be able to be much more agressive [earlier in the SDLC.] We’ll be able to inject live JavaScript. We’ll be able to do live SQL injection, we’ll be able to automatically test every form because we’re in a different environment than we are in production.

To read more about application security testing, check out our security expert responses, as well as the Security Lesson: Beating Web application security threats. For more information about Testing-as-a-Service (TaaS), read Testing-as-a-Service: Outsourcing your specialized software testing.

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.