4

I'm currently reading "Software Security: Build Security In" by Gary McGraw, and he makes the distinction between security bugs and security flaws. Security bugs being implementation errors in code, and flaws being more on the architectural/design side of software. He writes how security defects tend to be around a 50/50 split between bugs and flaws.

However, this was written in 2006, and he mentions languages such as C and C++. There is a lot of talk of buffer overflows, for instance. My question is this: how pertinent is this to Scala? Obviously bugs in implementation still can cause security risks, but having a managed language on the JVM that does bounds checking seems like it would mitigate a large class of bugs that McGraw speaks of. Is it a reasonable statement that Software Security, in a language like Scala, has shifted more towards the architectural and logical side of things? Or, to be more specific, is static code analysis in Scala less important for security than it would be for languages like C and C++? If not, why not?

Nathan
  • 249
  • 1
  • 8

2 Answers2

4

As far as memory related issues go, there are still issues e.g. you can still stumble upon a null pointer, use an out of bounds collection index, accidentally share mutable data with other classes, make the application use all its allocated memory, or in some cases where almost all the memory is used and a lot of new temporary objects are created, the GC can take up almost all of the execution time - but most of these are exceptions/errors on the JVM, and can be handled, though they should be avoided with configuration and careful coding, if possible.

Additionally, in scala null is frowned upon in favour of Option, and mutable state in favour of immutable, so with an idiomatic functional style, null and mutability issues are reduced further.

There are a few scala static analysis tools (disclaimer: I'm the maintainer of Linter), but they aren't specialized for security. That said, they often find issues that would crash the application at runtime, make it run slower than necessary, or find code that logically doesn't make sense - all a potential source of security issues. I'd like to mention Wartremover which features checks that restrict the language to a more safe/pure subset.

You can also use the tools that run on the JVM bytecode, e.g. find-sec-bugs plugin for Findbugs. The default Findbugs checks work too, but are triggered by generated scala code, so there are a lot of false positives. The language authors do look at these results, and fix if they find anything, but unfortunately the false positives make Findbugs less useful to the rest of us.

(I'm very interested in hearing if anyone has used any other tools with Scala in the comments)

HairyFotr
  • 141
  • 4
  • Would you consider a language like Scala more vulnerable with regards to certain security aspects? There are things like fail fast and code clarity that may be more of an issue with Scala than with OO / imperative languages? Obviously the tool support is also an issue as you kinda implicitly implied. – Maarten Bodewes Jun 13 '15 at 20:21
3

Whilst it's fair to say that managed languages are less prone to certain classes of issue whem compared to languages like c/c++ there's still several classes of software bug which can apply to Java/Scala and other languages that run in managed environments.

This can vary from input validation issues like SQL injection and cross-site scripting to error handling issues and misuse of cryptography. One source of information is this taxonomy of security issues, which shows a wide range affecting Java. Obviously Scala won't suffer from all the same issues, but it give you the picture that Managed languages can still benefit from static analysis.

Rory McCune
  • 60,923
  • 14
  • 136
  • 217