Tag: java

Our world runs on software that contains open source components. This places an increased burden on developers, as the primary consumers and deployers of those components, to use code that is fully up-to-date and secure. The vast majority of open source committers with write access to project repositories remain focused on maintaining and making positive improvements to that code, while also helping to benefit the open source community as a whole. However, the sheer complexity of many open source projects has opened the door to different, more insidious and concerted types of attacks which could cause widespread and serious harm.

Developers Have to Move Fast and Reuse Gives Them That Speed

One complicating factor is the prevalence of reuse of third-party open source elements across the majority of open source projects through two main types of dependencies. With direct dependencies, an open source component links straight to a third-party code library, while transitive dependencies occur when a component calls out to a library that is, in turn, communicating with another dependency.

Dependencies enable developers, under ever-increasing corporate pressure to deliver new software rapidly, to move faster by building on top of existing work by their peers. The downside is that those dependency foundations are vulnerable to attack, with some libraries perhaps under the aegis of a single committer for whom the code collection may be a side project and perhaps not attended to on a regular basis.

Sonatype research and that of other organizations tells us that developers working with a Java application may be dealing with a staggering 1,500 dependency changes every year, with the average Java application containing 148 dependencies and the average Java project being updated 10 times annually. While the number of open source projects isn’t ballooning, the amount of versions of those projects is skyrocketing. The majority of vulnerabilities today impacting open source projects result from transitive dependencies, the more complex type of dependency.

In an area where multiple projects may exist effectively solving the same issues, developers need to be aware of which projects are being actively maintained versus those that are either poorly nurtured or no longer in operation. On the other hand, successful open source projects may have tens or hundreds of committers with write repository access, which address a whole different set of issues, including reaching agreement on what a vulnerability consists of and how to fix or patch it.

Amid a Community for Good, Bad Actors and Incidents of Self-Sabotage Emerge

The reasons why individuals choose to commit to open source software are wide-ranging; a strong desire to give back to the community to a passionate and, perhaps very single-minded, hobby to an integral and paid part of a developer’s role and responsibilities at work. A few years ago, the concept of a malicious open source committer was an abstract theory. The thought back then was that perhaps a handful of ‘bad apples’ might exist within a community of millions of developers. However, since 2019, researchers’ tools and those of other organizations have identified over 100,000 malicious, suspicious or proof-of-concept packages, pointing to a much higher degree of behavior by cybercriminals.

Bad actors are deliberately taking advantage of the complexity of open source software to knowingly introduce exploitable vulnerabilities. These attacks are growing in sophistication particularly in relation to malicious code injections into the source code of an open source library. These attacks can often appear as harmless code changes and remain hidden before delivering a malware payload. There is the recent example of a crypto heist that stole over $3 million in cryptocurrency which leveraged compromised access to a private GitHub repository.

Protestware, where a code maintainer chooses to self-sabotage their open source project often to draw attention to a cause, whether geopolitical or specific to that individual, has become an issue over the past year. In this case, although the stated goal is not malicious hacking, real harm, in terms of major disruption, to developers using that code can occur.

To counter both the impact of bad actors and of self-sabotage on open source components, developers need to take advantage of release integrity features to help protect themselves and their organizations from harm. They must be able to have full visibility and control over the software they build and the open source components that they are sourcing as part of that development work. At the same time, governments around the world, including in the U.S., are weighing into issues related to the security of software supply chains, so increased regulations and penalties should also factor into how developers and their organizations behave moving forward.

We’re only one step away from the next potential Log4j attack, and every developer and organization needs to up their game and be ready to move fast on vulnerability identification and remediation. The gathering and sharing of data is what will help to increase everyone’s safety.