Posted by: Brian Wallace - security

A look at Vulnerabilities and Dependencies by Language

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.

How many projects have vulnerabilities, and how many do they usually have?

I looked at projects analyzed with SourceClear and broke them out by language. Unsurprisingly most projects have a handful of vulnerabilities. 80% of JavaScript projects have vulnerabilities, with an average of 7 vulnerabilities per project, while almost 60% of Java projects, with a comparably more robust history with security tools, still have vulnerabilities.

Posted by: Brian Doll - security

Secure Continuous Delivery with SourceClear

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.

Today we’re announcing several new integrations that bring the power of SourceClear to the best CI/CD services around:

Travis CIHundreds of businesses and over 300k open-source projects are using Travis CI every day to build apps with confidence.
Bitbucket Pipelines Atlassian BambooSourceClear brings automated security analysis to the millions of developers building software with the Atlassian Stack.
CircleCICircleCI is helping over 20k teams ship better code, faster.
CodeshipWith their native Docker support, Codeship helps you ship apps with confidence.

By integrating SourceClear into your Continuous Delivery platform you get automated security analysis right in your daily workflow. You’ll get complete analysis of your open-source dependencies, including security vulnerabilities, out-of-date libraries, and license reports. Use our JIRA and GitHub Issues integrations to fix issues quickly.

Ship fast. Stay safe. Try SourceClear today.


Posted by: Darius Foo & Asankhaya Sharma - security

Comparing vulnerable methods with static analysis

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.

Posted by: Asankhaya Sharma - security

Vulnerability Disclosures in an Open Source World

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.