The third stage of our release strategy will feature various improvements in reporting, including additional standards for reporting with CWE and OWASP.

It’s available for download through our members area – you can login or sign up from the buttons in the top right corner of this page.

Once you’re up and running, jump into our quick start guide.

As usual, we are looking to continue improving in the next releases of CodeScan Developer. We’re always keen to get some more feedback, so please feel free to contact us by Twitter (@CodeScanDev), our forums, email or comment on the blog.

We’ve also introduced a language bundle, which includes all three languages for only US$997 (a saving of US$394)!

If you have any questions, or would like to discuss your needs with one of our security experts, please email us at support@codescan.com

Cheers,
The CodeScan Labs Team

Once you’re up and runing, jump into our quick start guide.

We have been listening, and have significantly improved CodeScan’s user interface. Refreshing the display, simplifying the process so that you can now get up and running with your source code scanning projects much faster. This is a significant change, with new navigation, new display of the overall scan set up and reporting.

This new design makes CodeScan much more user friendly- and we’re looking to continue improving in the next releases. We’re always keen to get some more feedback, so please feel free to contact us, or comment on the blog.

Cheers,
The CodeScan Team

Already we are planning releasing a new class of vulns in our 1.8.4 release, Stored Cross Site Scripting. We are taking a slightly different approach to some of the others in the space at the moment, and really expect to have both accurate detection, and a great reduction in false positives.

Also keep an eye out for a revised File Management screen, which will provide better usability for adding and managing files in Projects. This is a good win for us, and will make the management of projects (applications) within CodeScan a lot easier.

So we have had coverage last week in Computerworld, and good feedback / validation of approach through the Serendipity IT Ltd blog.

Keep the feedback and comments coming guys, the good, the bad, and the ugly. We’re here to build products for you guys, so the more the better. One free license each month for the best feedback!

It’s all good.

One of the issues that I face on a daily basis is the attitude that web applications are “presumed” secure once they are developed, as a lot of people assume that their code is secure, even if large parts of their code are copied in from other sources. So the first real time that the application is exposed to security testing is when it goes into either a pre-production environment, or worst case, once it has gone live. Sometimes not even then.

Anecdotally, we have spent a lot of time working on open source software, including code that has been worked on by a lot of very knowledgeable people, and we are still finding interesting vulnerabilities. I know that a lot of implementations of these systems are not being tested when they go live, so it is likely that there are way too many untested and unproven web sites out there.

Seriously, the only way, and the most cost effective way, is to test your code while you are building systems, not waiting until the end (or never!). This way the code will be better, more secure, and costs a heck of a lot less than if someone finds your vulnerabilities once the system is out there and exposed.

Once your application has been deployed into either pre-production, or production, by all means use Application testing tools, and penetration testing, to prove the security of the deployed implementation. But this testing should be a back stop, and NOT the first time that security is actually addressed.

Oh yeah, if you then make changes to your web applications, either maintenance releases or new functionality, test your source code again. I get really concerned sometimes at the number of times a web site gets changed without being tested again. Security and exploits are also evolving, and what was secure last month is not necessarily secure this month. Either in operations or as a part of your regular release development, test your systems!

Operationally, layer your security with active management systems such as Firewalls and IDS, implement a vulnerability and configuration management system, and verify your security over time with application testing and manual penetration testing.

Want to be secure? The above is a lot more likely to both get you there, and to keep you there.

This is the second in a series of posts, which will help to identify where each type of product fits best. In this post, I will explore the notions of black box vs white box testing.

Firstly the definitions:

Black box testing takes an external perspective of the test object to derive test cases. These tests can be functional or non-functional, though usually functional. The test designer selects valid and invalid inputs and determines the correct output. There is no knowledge of the test object’s internal structure.

This method of test design is applicable to all levels of software testing: unit, integration, functional testing, system and acceptance. The higher the level, and hence the bigger and more complex the box, often the more one is forced to use black box testing to simplify. While this method can uncover unimplemented parts of the specification, it is really difficult to be sure that all existent paths are tested.

White box testing on the other hand, uses an internal perspective of the system to design test cases based on internal structure, and is based on a level of knowledge. While white box testing is applicable at the unit, integration and system levels of the software testing process, it is typically applied to the unit. While it normally tests paths within a unit, it can also test paths between units during integration, and between subsystems during a system level test.

Though this method of test design can uncover an overwhelming number of test cases, it might not detect unimplemented parts of the specification or missing requirements, but one can be sure that all paths through the test object are tested.

Application Scanning vs Source Code Scanning

Application Scanning is generally considered to be “black box” oriented, as the scanning is done against an object or system without a high level of knowledge, and there is a requirement by the tools to be able to interpolate a level of knowledge as to what it is testing against to determine the level of testing involved. As the testing involves both valid and invalid inputs and qualifying the output this is can sometimes be risky in production environments. Generally systems will be sufficiently robust to not fail under this level of testing, however it is a risk that needs to be considered when testing anything in a production environment.

Application Scanners can also often work in a partial “black box” environment, where often credentials are required to be provided to the scanner in order to test or access functions that are not immediately visible to the scanners.

The best way to look at application scanners, is that they are largely black box oriented, and can only test what they find / see / discover. Their advantages are that (in a production environment) testing can be performed from anywhere, and the testing is based on what is essentially a “user experience” based analysis.

 Source code scanners on the other hand, are very white box oriented. While earlier source code scanners required a high level of programming knowledge to set up the various tests, the new generations of source code scanners will operate with a minimum level of programming knowledge; more often than not, requiring that the operator understand the structure of the overall application being tested. From there, the source code scanner should be able to identify and “read” the code, and apply testing as appropriate against the code base.

The big advantage here is that the overall (total) application code can be tested, as all the code is supplied. Combinations and object interactions can be tracked and measured, and there is no requirement to access one level before testing the next level. The testing of the code is very comprehensive. The main disadvantages of the Source Code “white box” approach are that often the configuration of the operating system / server that the application is run on may not be tested in conjunction with the code base, and secondly (not a big disadvantage if done properly), it is a “pure” test, and not necessarily reflective of what an external attacker would see.

Summary:

Both levels of testing have their place in a full defence in depth strategy, where black (or semi-black) box testing using application scanners are used in both the pre-production and production environments to simulate attacks as they would be undertaken by an attacker. Can be run from almost anywhere, and can be run relatively easily. Generally only tests what it can see or discover through initial analysis, however has a strong position in operational testing.

Source Code Scanners on the other hand have the advantage that ALL source code associated with an application can be tested, and can be tested from the first line of code that is cut by developers, through to the point that the application is deployed. Also, any time that the code is updated, refreshed, maintained, or new exploit methods are discovered, the source code can be rescanned before committing the application to the world.

Generally it can be considered that Application or Code scanners perform reasonably similar functions, and there is a place for both. A reasonable defence in depth strategy has a number of tiers of protection, and both types of scanners play a part in the overall control of security within a company.

While I will discuss a number of other differences over time, the primary difference that interests me is:

“We should be developing secure applications from the outset”. Source code scanners, that are used during the development lifecycle, are a primary means whereby more secure applications are developed. Most application level scanners are really designed to be used in either pre-production, or production environments, and do not necessarily address the needs to test the development of your applications, as the code is being written.

Most security applications and controls are based on a Reactive approach to security , and are really compensating controls, i.e. compensating for issues that should not be occurring in the first place. Source Code Scanning is one of the primary tools that can be used to develop secure systems in the first instance.  Once systems have been developed, additional control mechanisms then come into their own, such as Firewalls, Intrusion Prevention Systems, Application Scanners, etc. Most of these either provide protection or assurance, which is definitely required, but I personally prefer proactive security mechanisms such as Source Code Scanning, so that a lot of the issues that we try to protect against, are dealt with before they become issues.

Its always better to build a secure house that stops mice from coming in, rather than trying to build a better mouse trap