Posted by: Brian Doll - security

The biggest SourceClear release yet!

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:

Posted by: Asankhaya Sharma - security

Abusing npm libraries for data exfiltration

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.

Posted by: Brian Doll - security

Build Inspector - A forensic sandbox for Continuous Integration environments

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.

Posted by: Darius Foo & Asankhaya Sharma - security

A deep dive into analyzing dynamic languages

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.