Most modern codebases are dependent on open source libraries. In fact, a recent research report sponsored by Veracode and conducted by Enterprise Strategy Group (ESG) found that more than 96 percent of organizations use open source libraries in their codebase. But – shockingly – less than half of these organizations have invested in specific security controls to scan for open source vulnerabilities.

In 2019, the Black Duck® Audit Services team audited 1,253 codebases to identify open source components, their associated licenses, security vulnerabilities, and overall community activity. Our Audit Services team has extensive experience in not only identifying open source licenses, but also researching the more than 2,700 license permutations that exist in the open source world. But what happens when an open source component has no license at all?

Your open source usage is out of control. Sure, it’s helping you develop your product faster and getting new releases out the door in days instead of months, but now your code base is made up of 60% or more open source components. And that percentage is only growing. The application layer continues to be the most attacked, so you know you need to stay on top of vulnerabilities.

I was going through a row of photography books in an antique store when I got a call from Bucky Moore, our lead investor and a board member. “Let me know if you need anything from me. This is getting serious,” he said. He seemed concerned. It was Sunday, March 22nd, right after the shelter in place order went in effect here in California. The next day, COVID-19 was no longer just in the news, it was everywhere.

Free and open source software (FOSS) components have become the basic building blocks of our software products, helping today’s developers build and ship innovative products faster than ever before. Many developers tend to forget that while open source licenses are free, they still come with a set of terms and conditions that users must abide by.

You work hard to produce quality applications on tight deadlines, and like every other development team out there, that often means relying on open source code to keep projects on track. Having access to plug-and-go code is invaluable when you’re racing the clock, but the accessibility of open source libraries comes with a caveat: increased risk.

Open source components are a major part of the software products we create and use. Along with the many advantages that using open source projects brings to software development organizations, it also comes with obligations and added responsibilities. One of these requirements is open source licensing compliance.

Have you ever wondered whether it’s ok to copy and paste code from an open source project? If you have, you’re not alone. A quick look around several developer websites shows a number of variations on this age-old question. It is never ok to copy and paste code from an open source project directly into your proprietary code. Don’t do it. Just don’t. Even if you’re on a tight deadline. Even if it’s only one loop.

When we think of open source analysis, security is often the first thing that comes to mind. But open source analysis is so much more than just security. It gives you visibility into your codebase to help you understand and manage your open source components. In this blog, we’ll define open source analysis, look at why it’s important to your business, and describe the characteristics of an effective open source analysis framework.

We now live in an era where the security of all layers of the software stack is immensely important, and simply open sourcing a code base is not enough to ensure that security vulnerabilities surface and are addressed. At Gravitational, we see it as a necessity to engage a third party that specializes in acting as an adversary, and provide an independent analysis of our sources.