November 21, 2016

The biggest SourceClear release yet!

Posted By: Brian Doll

We’ve got a present for you this week. This is the biggest release of SourceClear since we launched, and we can’t wait for you to dive in. Thanks to everyone who’s ideas and feedback have helped shape this release, and a special thank you to all of our beta testers who have shown us how crucial SourceClear is in helping teams build secure software.

If you’re not using SourceClear yet, today is a great day to sign up. Here is a rundown of all the new features being released today:

November 11, 2016
Abusing npm libraries for data exfiltration

Posted By: Asankhaya Sharma

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.

September 27, 2016

Vulnerability Disclosures in an Open Source World

Posted By: Asankhaya Sharma

Before open source software took over the world, people bought software from companies with cold hard cash. There were rolex watches involved, but there were also regular security updates, too. Crazy, right?

Vulnerability disclosure for commercial software typically goes like this:

  • A security researcher sends an email, encrypted with PGP, to the vendor’s security team letting them know that a security issue exists
  • Once they acknowledge receipt, a more detailed disclosure of the vulnerability is shared
  • The vendor will then establish a timeline for fixing the issue, validating that the fix actually works, and planning the release of the fix.
  • Once the fix is released, the vulnerability is disclosed publicly.

While this process usually works well for commercial software, there are many ways that it can fall apart when disclosing open source vulnerabilities.

September 26, 2016

Dynamic Analysis is the only way

Posted By: Mark Curphey

SourceClear helps you use open source software safely. In order to analyze the security of your projects, we need to solve two problems:

  • Identify the complete list of dependencies and versions in use.
  • Determine which vulnerabilities apply to those dependencies.

To solve the first problem, there are three typical approaches:

  • Static analysis - parsing a build file
  • Binary analysis - inspecting the compiled code
  • Dynamic analysis - inspecting the build process

We’ve been at this for a few years now, and our experience has taught us that only one of these methods actually works - dynamic analysis, running inside the build process.