We All Share Responsibility to Secure Code

We All Share Responsibility to Secure Code

It's indisputable that open source software is an essential element in application development worldwide. Its benefits in reducing dev costs, promoting innovation and accelerating time to market explain why open source often comprises more than 50% of an application's code.  

There is, however, an ongoing - and often very heated - debate about whether open source is more or less secure than commercial software. In my view there is no convincing argument that open source is any less secure, or any more secure than commercial software.

It's software, folks. There will always be bugs in open source and in commercial software.

Unfortunately, after some recent comments I made about open source security were published in adtmag.com, TechRepublic columnist Matt Asay took exception with them in an article headlined “Why it's time to stop blaming open source for ransomware attacks.”

Matt read my comments as blaming open source for having vulnerabilities. I would assign no such blame, and in fact I suspect that Matt and I are in full agreement on this subject.

Blaming Software?

Indeed “blaming software” would be a pretty silly. Software doesn’t write, deploy, or manage itself. Humans do and if there is any blaming to be done, it falls on us.

My argument isn’t that open source code is less secure code, nor “that open source is ultimately to blame for attacks.” Instead, my argument is that if you aren’t aware of what open source you’re using, or where it is in your code base (and code audit analysis reports released by Black Duck’s global Center for Open Source Research and Innovation consistently show most organizations do not) you simply cannot update the components when vulnerabilities are disclosed.  

As Matt stated in his piece, if companies keep careful track of both the code they are using, then “enterprises can also consult [the National Vulnerability Database] and plug the holes” as any new vulnerabilities are disclosed.

This is true, but not what we see in practice. Instead, we see mature organizations using more than twice as many open source components as they reported they have, with the average age of vulnerable components at more than five years. Lack of visibility means lack of control and the result, as we've seen in high profile, open source breaches, can be costly.

Secure Code

This isn’t because open source is less secure than commercial code – and I’m not “blaming open source.” This responsibility falls squarely on the organizations using the open source, but not securing and managing it effectively.

Regarding the attractiveness to vulnerabilities in open source as an attack vector, I stand by my comments. Again, this isn’t blaming the open source. It’s simply that hackers understand that companies do not track their open source carefully, and, as shown, that vulnerable components are not always addressed.

So Matt, I think we’re on the same side here. 

The State of Open Source Security

Sorry we missed you! We close comments for older posts, but we still want to hear from you. Tweet @black_duck_sw to continue the discussion.


Commercial Application Security: 6 Facts You Didn't Know

| May 4, 2017

Many people know Black Duck from our security and software license compliance business. However, we also have a very strong On-Demand business. Our On-Demand business performs one-time audits of software, typically as part of due diligence in an M&A transaction. In these engagements, the entities

| MORE >

Open Web Application Security Project Updated Top 10

| May 3, 2017

Late last month, the Open Web Application Security Project (OWASP) published a release candidate for the new OWASP Top 10 (T10).  I want to take a look at what has remained and what has changed since the last version. First of all, hats off to OWASP. They do a great job with their many projects

| MORE >

Vulnerability Remediation – You Only Have 4 Options

| Mar 29, 2017

In my previous post, I wrote about a simple process for triaging vulnerabilities across applications. Once you have the issues prioritized, the vulnerability remediation process is pretty straightforward. You don’t have a lot of options; either remediate the issue, ignore it, or apply other

| MORE >