Cybercrime and enterprise software

Supply chain attacks via public repositories

The bad guys are trying to get into your projects. What can you do to avoid pulling in bad code?

This article is our take on the excellent Devoxx presentation by Steve Poole, where he explains the changing nature of cyber attacks, moving up into the enterprise software stack.

There are essentially two main "attack vectors" that are available today:

• Malicious source code being committed in your project
• Dependencies on other projects with malicious code (typically pulled in from public repositories)

Below we will go over each one in more detail.

Malicious source code being committed in your project

If you give commit rights to bad guys then you risk getting malicious code in your code base. That's why we don't give commit rights to just anybody: we occasionally pull in contributions from GitHub but only after thoroughly reviewing and rewriting it ourselves. Our development happens in private repositories, where we do pair programming and/or code reviews for each commit. Most organisations will probably do the same, but some open source projects may be less careful.

Dependencies on other projects with malicious code

If your code depends on (and pulls in) other projects via public repositories then there are definitely risks involved. You don't necessarily know what you are pulling in. With 90% of today's applications being open source components, this can become a significant security hazard.

We can categorise this type of attack in 2 ways:

Vulnerabilities in official releases

Remember Log4J? That's the type of thing we mean here. If you pull in official code of a well-known project and there is a vulnerability then you risk being exploited that way. This is problematic because today there are nation states that pay researchers a lot of money to keep such vulnerabilities secret. It's out there, but we don't know. Only the bad guys know.

We at Atomikos have always strived for minimal external dependencies in our builds. We don't use Log4J unless you put it on your classpath and configure it for yourself.

Unofficial fake releases in public repositories

At Sonatype they call this "dependency confusion", and a good article about this can be found here. The idea is that your build environment may accidentally use unofficial releases designed for bad things, provided that:

• The bad guys know the namespace of the packages you include, and
• The bad guys manage to publish a bad release in a repository you use

This type of exploit seems common for Javascript, but not so much for maven projects. That's because maven central only allows publishing a library if you prove that you own the namespace. Nevertheless, it's good to be aware of this possibility.

Our take

So what does this mean to you, as an Atomikos user / customer? Make sure to use only our official binaries (either signed on maven central or in our private customer repository) and configure your build infrastructure to avoid pulling in code from 3rd party public maven repositories.