The GS Days 2015 provided Advens the opportunity to demonstrate a simple and practical approach for detecting and fixing vulnerabilities in an application source code. This approach, associated with SonarSource, allows to simultaneously maintain the security level on the long term.
Today, source code security is limited to intrusion tests and/or code reviews implementation1.
For RSSI, these two methods allow to assess, via external firms, the security level of the applications to be released.
This approach, coming quite late in the development chain, is often wrongly perceived by developers. The external firm doesn’t engage the developers enough and the reports it provides are often too complex, and don’t take the software context into account. The security-driven approach is therefore identified as a death sentence to be avoided at all cost, or postponed indefinitely.
In the end, nobody’s happy with the result. To the extent of questioning the very point of those methods.
That’s why a key to successfully securing an application is to strongly involve developers, as early as possible in the development cycle. But in order to do that, you need to talk the “developers language” !
Managing an application production line has drastically evolved since the dawn of IT. The era of makefiles, sources stored on a shared network drive, and simple text editors, has ended. Today, a development team talks continuous integration, or even continuous deployment. This means the integration of application security in this approach is imperative. It needs to give the team the necessary toolset to fully understand the development process.
The legacy source code audit approach focuses in most cases on the whole application source code, which can lead to never-ending negotiating, pushback from the development teams and, ironically, to injecting potential functional setbacks. To stay consistent with the paradigm shift associated to using continuous integration, the only source code that should be analyzed should be the one that’s evolved between two versions. The induced positive edge effects are numerous: upgrade efforts are smoothed out over time, no risk for functional setbacks since only the very recent code is touched, no pushback from the development teams since the code touched is fresh from them, hence they’re liable for it… It’s the well-known metaphor about water leakage.
It’s therefore possible, introducing a mechanism for continuous control, to force the security needs onto the developers (that would previously have been properly trained to using the secure libraries and the secure code, please refer to the slides hereafter) and to ensure the level is maintained.
The code analysis tool SonarQube2 allows to run continuous checks (or at least, on demand or at each build). Known by everyone, and often well implemented in the developers’ community, it detects software faults thanks to known rules integration (CERT, MITRE, OWASP, etc.).
This project, developed together with OWASP (via Advens support in terms of application security expertise) and SonarSource, already counts over 100 security rules for all the language plugins. It relies on benchmarks like MITRE-CWE, Cert Secure Coding, … New detection rules are added on a regular basis.
Integrating application security at the heart of the development cycle (and not only imposing big policies and non-developer tools) will allow you to improve application security along the way.
I welcome you to have a look at the OWASP project, and to contribute through the various means that you may have at your disposal.
Senior consultant in Information Systems Security.
1(on this topic, don’t hesitate to review the keynote from Advens at the Application Security Academy Season 2 http://www.advens.fr/news/application-security-academy-saison-2-episode-3)