Posted on

Developers That Embrace Security Add Personal, Organizational Value

While the relationship between software development and security hasn't always been harmonious, recent research suggests the two are becoming much more aligned. In one study, almost half of developers said they had prioritized learning or improving AppSec/secure programming since the pandemic began. In another study, 79 percent said the importance of secure code is increasing in prominence.

This long-awaited meeting of the minds is being driven in large part by astronomical increases in cyberattacks, which are happening on average every 39 seconds. Meanwhile, 60 percent of developers are releasing code two times faster than before. So, while developers are primarily motivated by creating great software, increasingly they are making efforts to ensure that development is complementary to security. The alternative — creating insecure code that puts attackers in the headlines — makes it imperative for developers to incorporate security wherever possible.

Posted on

How Bokeh Secures Its Open-Source Repositories

Open-source is everywhere, it is one of the driving forces of software innovation from the academic to the enterprise world (75 percent of codebases audited by Synopsys in the 2021 OSSRA report rely on open-source components). Its prevalence in commercial software is reaching unprecedented levels, to the extent that the European Commission has recently identified it as a public good in a recent study assessing its impact on the region’s economy.

But the interstitial nature of open-source in modern software also makes it a subject of security and compliance concerns, as it is capable of exposing organizations that use it to a host of unknown risks and vulnerabilities. Most discussions we are hearing today around security in this space are focused on the identification, fixing, and remediation of vulnerabilities — all seen from the “consumer” perspective.

Posted on

New Analysis Reveals Etherpad 1.8.13 Code Execution Vulnerabilities

Etherpad is one of the most popular online text editors that allows collaborating on documents in real-time. It is customizable with more than 250 plugins available and features a version history as well as chat functionality. There are thousands of instances deployed worldwide with millions of users. The project is very popular within the open-source community as shown by the over 10,000 stars on GitHub. Etherpad instances are often publicly usable and can contain sensitive information.

As part of SonarSource's security research on open source projects we analyzed Etherpad's code and found 2 critical vulnerabilities. Both can be combined by an attacker to completely take over an Etherpad instance and its data. In this blog post, we cover the technical details of these code vulnerabilities, show how they were patched, and give advice on how to avoid these types of bugs during development.

Posted on

Developer-Led Code Security: Why False Positives Are Worse than False Negatives

Most SAST tools target security compliance auditors. Their goal is to raise an issue for anything even remotely suspicious. There's no fear of false positives for those tools because the auditors will figure it out; after all it's the auditors' job to sort the wheat from the chaff and the signal from the noise. But the industry should rally around efforts to kill all that noise. There's little tolerance among developers for crying wolf. SAST players should listen to developers and follow the guiding principle to prefer "reasonable" false negatives to raising false positives.

What does that mean in practical terms? Well, let's play with some numbers. Let's say you have a codebase with 12 Vulnerabilities. That's 12 things that absolutely need fixing. A typical SAST analysis might raise 500 issues in total, and then the auditors will spend X weeks sorting through that to bring you, the developer, the audit result maybe a month or so after you've moved on to other code. 

Posted on

For Secure Code, Maintainability Matters

Author Robert Collier said that "Success is the sum of small efforts repeated day in and day out." That's especially true when it comes to security. By now we all understand that securing your systems isn't as simple as installing a firewall and calling it a day. Instead, it's multiple actions and strategies in concert, implemented consistently over time. And believe it or not, one small but important strategy is simply writing code that's reliable (bug-free) and maintainable (easy to understand). Yes, I know that sounds too simple, and possibly even self-serving. So in this post, I'll lay out some of the evidence for how writing reliable and maintainable code means you're inherently writing more secure code.

Poor Maintainability Contributed To Heartbleed

To make the case for how maintainable code contributes to security, I'll start with the Heartbleed Bug. Remember that one? It was a serious vulnerability in OpenSSL that allowed attackers to steal sensitive information with a really trivial attack that XKCD illustrates beautifully. David A. Wheeler teaches a graduate course in secure development at George Mason University. He wrote an extensive analysis of the vulnerability. In it, he laid part of the blame on the difficulty of simply understanding the code involved: "Many of the static techniques for countering Heartbleed-like defects, including manual review, were thwarted because the OpenSSL code is just too complex. Code that is security-sensitive needs to be 'as simple as possible'."