Regulatory requirements, standards and market of software security scanning (SAST)

2013-10-23 00:00:00 +0100


Source code security reviews and scanning (SAST</a>, or less frequently SCA</a>) is one of the most effective techniques to reduce number of security related bugs in software. As of 2013 it’s still not very widespread due to a number of limiting factors. The root cause is probably that there’s no “middle class” among source code scanning techniques. Manual code review is very time consuming and, as such, very expensive. Surprisingly, same applies for commercial scanners. While you can find sufficient amount of reasonably priced (BurpSuite) or even free dynamic (DAST) testing tools (sBurpSuite free edition, w3af or OWASP ZAP), the situation in SAST market is diferent.

Free tools are few and rather poor qulity, mostly based on simple pattern search logic, which does not provide much added value of “find” and “grep” tools used for manual code reviews for years. But middle-class SAST tools are virtually non-existent. There’s no BurpSuite equivalent in the SAST market. Either you have nothing or need to reach to the enterprise level with prices starting from $20k per year. It’s not just failure of the market — while a DAST tool can test web applications written in virtually any programming language, the SAST scanners are implemented for very specific languages and environments. It’s just difficult and expensive to write SAST tools (it doesn’t mean impossible — see Brakeman for Ruby).

Because of that the first question of the budget holders at any software project is — “do we have to use SAST?”. And in most cases the answer is — do, we don’t have to in terms of regulatory or contractual requirements (unless of course it actually is in the contract).

There is one exception from that rule — PCI-DSS v2, which is mandatory for most projects related to payment processing and other financial transactions. Here’s what PCI-DSS says on source code testing:

6.3.2 Review of custom code prior to release to production or customers in order to identify any potential coding vulnerability. Note: This requirement for code reviews applies to all custom code (both internal and public-facing), as part of the system development life cycle. Code reviews can be conducted by knowledgeable internal personnel or third parties. Web applications are also subject to additional controls, if they are public facing, to address ongoing threats and vulnerabilities after implementation, as defined at PCI DSS Requirement 6.6

This requirement has been seemingly causing a lot of confusion in the past, so PCI has refined it in a 2008 document Information Supplement: Requirement 6.6 Code Reviews and Application Firewalls Clarified:

Properly implemented, one or more of these four alternatives could meet the intent of Option 1 and provide the minimum level of protection against common web application threats: 1. Manual review of application source code 2. Proper use of automated application source code analyzer (scanning) tools 3. Manual web application security vulnerability assessment 4. Proper use of automated web application security vulnerability assessment (scanning) tools

This interpretation explicitly mentions source code scanners and, at the same time, explains the outburst of commercial SAST market over the last few years as well as the prices — if you’re subject to DSS, you don’t usually suffer from a limited budget.

Those of us aren’t subject to PCI-DSS and still look for a standards based rationale for SAST in their software projects do not really have any ultimate arguments, but it doesn’t mean the rationale is completely non-existent. It can be still implied from existing standards:

None of them is really mandatory in the jurisdictions I’m aware of. However, most of them use ISO 27001 as the main guideline for information systems security at least in public sector and it’s also standard baseline in enterprise environment.