Ian Cropper

developer

Someone else wrote most of your project

Any given Tuesday

Developer A: “Hey, can you take a look at this?”

Developer B: “Yeah"

Developer B: "…. hmm.....Have you tried using evil.js?”

Developer A: “No, what is it?”

Developer B: “It’s just a JavaScript library that will do exactly what you’re trying to do. It’s on GitHub. I’ll send you the link.”

***Later*** 

Developer A:

 > bower install evil.js --save

 

And that’s often all the scrutiny a third-party library would get.

A Case Study

In 2010, even a company as big as Twitter fell prey to the effects of poorly written or untested 3rd-party code.

Known as the “onmouseover attack", users were able to insert scripts into a submitted tweet as part of an href link that would later be run as script when loaded on the page.

It was easy and would look something like this:


<a href="http://thisisatest.com/@"onmouseover="alert('test xss')"rel/" target="_blank" ="">http://thisisatest.com/@"onmouseover="alert('test xss')"/>/a<>/span< 

The parser being used would choke on the "@" symbol and read the rest of the "URL" as executable script.

 The result was that hovering over a link opened up a user to inadvertently liking the post or even re-sharing the post. Within minutes, posts using the exploit received thousands and thousands of likes and shares.

Some developer, somewhere, at some point wrote a URL parser and may have thought: 

"Why would there ever be an '@' inside of an href?"

Then later, without much research, some developer at Twitter thought:

"Hey, I found a URL parser in the bower repo!"

3rd-Party Code is everywhere and is largely unassessed

A study conducted by Coverity that surveyed 336 American and European Software companies produced some stunning findings

  • 90% of all the companies use third-party code (it's probably actually more shocking that 10% of companies write everything from scratch)
  • 65% reported that customer satisfaction has been impacted by third-party code
  • 44% of the companies were testing third-party code compared to 69% of the companies saying they test internally produced code
  • 35% of the companies conducted risk assessments on third-party code compared to 70% saying the assess risk for internally produced code
  • 35% of the companies manually code review third-party code compared to 68% that perform manual code reviews on internally produced code.

It's not just JavaScript

Last year I wanted a way to easily give developers a foundation for unit testing in a .NET project. So I built a nuget package for it. It was very specific to the company's framework and would need a bit of extra work to get it working on someone else's framework. 

And all that's not even to mention the fact that it never really made it past version 1.0.1.

None the less, it's been downloaded from nuget.org 137 times.

Bottom line: It's not hard to get a package on a repository like npm, maven, nuget, or bower.

more than just security

Robustness

While security is a big risk of 3rd party code, it's not the only risk. Sometimes 3rd party code is just bad, or fragile. Or sometimes it depends on other 3rd-party code that's run by an open-source activist who may-or-may-not suddenly decided to remove all of his repositories

Frustrated after threats of a legal battle over the name of one of his modules, Azer Koçulu decided to remove his modules from the NPM repo entirely. In most cases no one would notice....in this case, thousands of apps stopped working because they depended on a module that was no longer there.

It's easy to assume that if 3rd-party code exists all nicely wrapped in a repository like Maven or Nuget, that the developer has thoroughly stress-tested their code (especially if they have a cool vector-graphic logo) but it's a risky assumption.

Speed / Bandwidth

There are plenty of tools out there that will help remove unnecessary code before prod, but just because something is necessary doesn't make it a good option, and at the very least, it's something developers should be aware of.

In a comedic example, Babel–the heavily used JavaScript transpiler–included an ASCII art image of Guy Fieri in the source code. While this is a fairly inert example, there are plenty more cases of 3rd-party code that, for example, will automatically run a whole host of expensive processes that will affect the end-user experience.

Are we supposed to write everything from scratch then?

Hell. No.

3rd-party code saves time, money, sanity, finger pads, keyboard expenses, marriages, children, baby animals,  .... It's great.

But...

you are expected to use discretion.

Are you including jQuery because you need to query the DOM once? Maybe you ought to rethink that.

Considering a library from online with 1.5 stars and is at version 1.0.5? Let's keep looking.

Found something that would totally work but hasn't been updated since 2012? You're asking for it.

Don't go and reinvent the wheel with every project, but use the same scrutiny, assessment, and discretion you would use if you had written that code yourself.