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:
- ISO 27001 has control A.12.5.5 (Outsourced software development), which is explained in details in ISO 27002:
Where software development is outsourced, the following points should be considered: (…) b) certification of the quality and accuracy of the work carried out; (…) f) testing before installation to detect malicious and Trojan code."
- ISO 27001 also has control A.10.3.2 (System acceptance), further explained in ISO 27002:
"Managers should ensure that the requirements and criteria for acceptance of new systems are clearly defined, agreed, documented, and tested. New information systems, upgrades, and new versions should only be migrated into production after obtaining formal acceptance. The following items should be considered prior to formal acceptance being provided: (…) d) agreed set of security controls in place;"
- There's ISO 27034 which is a kind of application security focused extension to ISO 27002. It has control A.9.5 explicitly mentioning static analysis:
"Project teams should perform static code analysis of source code. Static analysis of source code provides a scalable solution for security code review and can be used to ensure that secure coding policies set by the security team lead and security advisor are being followed. Static code analysis by itself is generally insufficient to perform a thorough security review – the security team and security advisors should be aware of the strengths and weaknesses of static analysis tools and be prepared to embellish code review tasks with other tools or human review as appropriate."
- And finally there's OWASP ASVS which also mentions SAST explicitly at level 1 automated testing:
Level 1A is for the use of automated application vulnerability scanning (dynamic analysis) tools, and Level 1B is for the use of automated source code scanning (static analysis) tools. Verification efforts may use either of these components individually, or may perform a combination of these approaches to achieve a complete Level 1 rating.
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.