December 25, 2016

Rails_admin Vulnerability Disclosure

Posted By: Jason Yeo

A few days ago, I found a CSRF vulnerability in rails_admin. rails_admin is a Ruby gem that generates administrative interfaces for your models automatically. Interestingly, this vulnerability is similar in nature to the one I found in administrate, a similar gem. Additionally, past Ruby gems affected in a similar fashion can be explored at this link.

November 30, 2016
The Ransomware in our Dependencies

Posted By: Darius Foo & Steve Ng

November 21, 2016
The biggest SourceClear release yet!

Posted By: Brian Doll

November 11, 2016

Abusing npm libraries for data exfiltration

Posted By: Asankhaya Sharma

Package and dependency managers like npm allow command execution as part of the build process. Command execution provides an easy and convenient mechanism for developers to script tasks during the build. For instance, npm allows developers to use pre-install and post-install hooks to execute tasks. A pre-install hook can be used to compile some dependent native library before starting the build. A post-install hook can be used for clean up after the build.

In this blog post, we demonstrate how an attacker can use npm to exfiltrate information from the developer’s machine. Although we show the attack scenarios for npm, similar attacks can also be done on other package managers like gradle.

November 10, 2016

Build Inspector - A forensic sandbox for Continuous Integration environments

Posted By: Brian Doll

Don’t trust user input. That’s a core security tenet for building secure software. In our web applications we sanitize text input to protect against XSS, and verify uploaded files are free of malware. But what happens when you take user-submitted software and execute whatever it tells you to do? That’s essentially what Continuous Integration environments are made for. If the tests say to count to 10, the system counts to 10. If it says to download software and start mining for Bitcoin, that’s exactly what it’ll do.

Misbehaving or even malicious builds are a difficult threat for CI environments to protect against. Continuous Integration services are essentially asked, every day, by every customer, to run random pieces of software. If you run a CI system at your company, you’re doing the same. To help identify these potentially dangerous builds, we’ve been working on a project called Build Inspector.

November 8, 2016

A deep dive into analyzing dynamic languages

Posted By: Darius Foo & Asankhaya Sharma

Analyzing programs written in dynamic languages presents some unique challenges. Here’s a bit of a deep dive into how we do it. First, what exactly is a dynamic language? For the purposes of this article, we will define a dynamic language as one where types are checked for safety only at runtime. Languages like Ruby, Python, and JavaScript follow this model, in contrast with static languages like Java and C#, where type safety is ensured at compile time.

October 25, 2016

A look at Vulnerabilities and Dependencies by Language

Posted By: Brian Wallace

As a Data Scientist at SourceClear I get to analyze lots of interesting vulnerability data as well as anonymized project data. New customers often ask us what “normal” looks like when it comes to vulnerabilities in their projects, so I thought I’d take a look and share a few insights.

October 12, 2016

Secure Continuous Delivery with SourceClear 1.0

Posted By: Brian Doll

Continuous Delivery is all about speed. Think fast, build fast, ship fast. But how do you ensure your software is safe when you’re so focused on speed?

By automating security checks with every build you can ship faster than ever, knowing you are delivering a safer product to your customers. That’s Continuous Delivery, Secured.

October 11, 2016

SourceClear brings Secure Continuous Delivery to the Atlassian Stack

Posted By: Brian Doll

Today we’re thrilled to announce that SourceClear is bringing automated security analysis to millions of developers building software with the Atlassian Stack. Continuous Delivery, Secured.

September 29, 2016

Comparing vulnerable methods with static analysis

Posted By: Darius Foo & Asankhaya Sharma

In this blog post, we will talk a bit about traditional static analysis - what it is, what it’s used for, and where our vulnerable methods analysis fits in amongst the other kinds of static analysis.

Wikipedia tells us:

Static program analysis is the analysis of computer software that is performed without actually executing programs

Why wouldn’t we want to execute a program in order to analyze it? The main reason is that we gain stronger guarantees about whether our analyses will terminate (modulo bugs in it). Testing a program by executing it can only ever reveal the presence of bugs in paths that are exercised during the execution, on the other hand, static analysis can reason about all possible paths in the program.

A static analysis tells us about the possible runtime behavior of programs. What it computes is essentially an approximation – it cannot have knowledge of the exact inputs a program receives at runtime, for example, so it can only operate based on abstractions of them. This may lead to false positives or false negatives, depending on how conservative or permissive an analysis is. Advancing the accuracy of current analysis techniques is an active area of research.

Static analyses are usually found in compilers, IDEs, linters, and standalone agents (like SourceClear’s CI agent) that run as part of a continuous integration pipeline. They detect errors, discover properties about programs, and help us write better programs in general.