Unless you have been living under a rock you have heard all about the WannaCry ransomware. At SourceClear, we believe this week’s attacks were a preview of what could happen when (not if) ransomware moves from small-value targets (consumer desktops) to large-value targets (enterprise web applications). It’s where the big money is. This blog post demonstrates the technical feasibility with a working sample for the latest version of the Java Spring Framework. It’s not any one framework that’s vulnerable but the open-source ecosystem - we also have working examples for Apache Struts, Node.js, Ruby or many others.

Today we released vulnerable methods support for the Ruby language, adding to the existing support for Java and Python. Vulnerable methods analysis uses call-graph analysis to trace the actual use of the vulnerability in your projects. To understand the impact that vulnerable method support can have, we analyzed the top 1,000 starred Ruby projects on GitHub, and discovered that without vulnerable method detection, users would see a false-positive state of more than 85%! With vulnerable methods detection, users would see these false-positive rates decrease significantly. To get this feature, paid users can simply update their agents (i.e. brew upgrade srcclr) and free users can upgrade to a Pro trial.

Today we launched a new company web site and have changed the way we talk about what we do. This is important because we believe that application security is in the midst of a transformational change. The old model of security was slow, contentious and typically applied as a series of quick fixes at the end of a development cycle or even after shipping. Even in the past this approach was more of a necessary means to an end rather than the ideal. In today’s world of DevOps and Continuous Delivery it is just plain obsolete.

Today we released a new agent that supports scanning SBT, CocoaPods and Yarn projects, adding to the list of build systems and package managers that we already support. To get this feature users can simply update their agents (i.e. brew upgrade srcclr).

Four weeks ago, we blogged about the issue with Rails’ built-in anti-CSRF mechanism, protect_from_forgery, where we calculated that over 50,000 Ruby developers were impacted by Cross-site Request Forgery (CSRF) attacks.

In the 1990’s we saw viruses and worms proliferate across the Windows platform until the problem became so bad that Bill Gates had to stop shipping and fundamentally change the way Microsoft built software.

There’s been some buzz recently about protect_from_forgery, Rails’ built-in anti-CSRF mechanism, and how it’s not secure by default. Having found, evaluated, disclosed, and tried to fix issues with it in the past, we decided to perform a thorough evaluation of how severe the problem was.