DEVOPSdigest

Open source security is increasingly in the headlines, with a staggering 650% rise in open source supply chain attacks last year. New forms of attack, like "dependency confusion" are hurting organizations with alarming regularity.

Given how widespread open source is within enterprise tech, one insecure package can cause a ripple effect around the globe. Last year's Log4j vulnerability did exactly that, highlighting the need to improve open source security and the transparency of software supply chains.

Despite welcome interventions to address the situation, like Google's initiative to distribute security-vetted open-source, there is still a long way to go. If devs aren't aware of best practices to craft and maintain secure projects, all good intentions will fall flat.

So, how can developers keep their projects safe from today's cybercriminals?

With cybercriminals constantly innovating, project developers have the unenviable task of needing to audit and enhance processes to keep up with the latest attack vectors. Due to lack of resources, many open source projects don't have dedicated security teams to review every dependency, or resources to conduct audits from high-end security companies. However, there are a number of strategies available to turn the tide on the bad guys.

A Secure Core System

Selecting a language that lends itself to secure code is a must. The issue with many fast languages is that it's difficult to write secure code. For instance, C and C++ often have code issues and bugs that can lay dormant and become security issues years down the line. Buffer overflow and overreads can easily be leveraged by bad actors, as was the case with Heartbleed - which left hundreds of thousands of organisations at risk. Languages like Go, which feature automated memory management, make it far easier to write secure code, shrinking the attack surface.

Slash Dependencies to Cut Supply Chain Attacks

If developers can follow a general philosophy to remain independent and self-sufficient from other projects, policing their code for any potential vulnerabilities becomes a much easier task. For example, having a low number of dependencies, direct or indirect, that are isolated from each other vastly cuts down chances of attack.

However, this isn't always possible. In that case, it's better to make smaller copies of critical parts of external dependencies than importing big dependencies. If external libraries are too big, such as Kubernetes, developers should consider creating much smaller aspects of the library in house. Paying attention to the quality of dependencies and where they come from is also essential. If they are created from a reputable source, such as Google or Meta, the security risks are likely to be lower.

Clear Documentation, and a Strong Base

It's important that any project has clear, visible, and easy-to-find documentation that lays out everything security-related. Documentation has to be compact and concise, not bloated and difficult to search through, or people will lose interest.

However, even if people don't read documentation, having secure settings by default will keep users safe. This is down to the fact that no-one usually changes default settings unless out of necessity. If default activity exposes sensitive information, that's a security risk with real world implications. Striking the balance between usability, visibility and security is difficult, but the general rule for developers should be to hide all sensitive information unless it's absolutely critical to end users.

Mandatory Code Change Reviews

In open source environments, code changes should be heavily reviewed whenever an external contribution is made, whether that be from coworkers or community members. These reviews should be conducted from a security perspective as well as an architectural perspective. Building a team that is fond of security will help in making sure these reviews don't leave out security.

Automated Vulnerability Scanning

Finally, automated vulnerability scans are critical to constantly assess versions of dependencies and notify developers when they change, advising on whether to remove or upgrade them. Some developers running projects with many dependencies will hide or ignore these requests, treating them as unnecessary admin. In this case, reducing the frequency of these notifications will still allow developers to stay ahead of any potential vulnerabilities without impeding their work.

Today's hackers are dedicated to coming up with new and innovative ways to commit cybercrime. The above guidance will put developers in a strong position to create secure open source projects, but the sophistication of cybercriminals means staying abreast of security should be a vital part of any developer's day-to-day routine.