Cy­ber­crime and en­ter­prise soft­ware

Sup­ply chain at­tacks via pub­lic repos­i­to­ries

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

This ar­ti­cle is our take on the ex­cel­lent Devoxx pre­sen­ta­tion by Steve Poole, where he ex­plains the chang­ing na­ture of cy­ber at­tacks, mov­ing up into the en­ter­prise soft­ware stack.

There are es­sen­tial­ly two main "at­tack vec­tors" that are avail­able to­day:

• Ma­li­cious source code be­ing com­mit­ted in your project
• Depen­den­cies on oth­er projects with ma­li­cious code (typ­i­cal­ly pulled in from pub­lic repos­i­to­ries)

Below we will go over each one in more de­tail.

Ma­li­cious source code be­ing com­mit­ted in your project

If you give com­mit rights to bad guys then you risk get­ting ma­li­cious code in your code base. That's why we don't give com­mit rights to just any­body: we oc­ca­sion­al­ly pull in con­tri­bu­tions from GitHub but only af­ter thor­ough­ly re­view­ing and rewrit­ing it our­selves. Our de­vel­op­ment hap­pens in pri­vate repos­i­to­ries, where we do pair pro­gram­ming and/or code re­views for each com­mit. Most or­gan­i­sa­tions will prob­a­bly do the same, but some open source projects may be less care­ful.

Depen­den­cies on oth­er projects with ma­li­cious code

If your code de­pends on (and pulls in) oth­er projects via pub­lic repos­i­to­ries then there are def­i­nite­ly risks in­volved. You don't nec­es­sar­i­ly know what you are pulling in. With 90% of to­day's ap­pli­ca­tions be­ing open source com­po­nents, this can be­come a sig­nif­i­cant se­cu­ri­ty haz­ard.

We can cat­e­gorise this type of at­tack in 2 ways:

Vul­ner­a­bil­i­ties in of­fi­cial re­leas­es

Re­mem­ber Log4J? That's the type of thing we mean here. If you pull in of­fi­cial code of a well-known project and there is a vul­ner­a­bil­i­ty then you risk be­ing ex­ploit­ed that way. This is prob­lem­at­ic be­cause to­day there are na­tion states that pay re­searchers a lot of mon­ey to keep such vul­ner­a­bil­i­ties se­cret. It's out there, but we don't know. Only the bad guys know.

We at Atomikos have al­ways strived for min­i­mal ex­ter­nal de­pen­den­cies in our builds. We don't use Log4J un­less you put it on your class­path and con­fig­ure it for your­self.

Unof­fi­cial fake re­leas­es in pub­lic repos­i­to­ries

At Sonatype they call this "de­pen­den­cy con­fu­sion", and a good ar­ti­cle about this can be found here. The idea is that your build en­vi­ron­ment may ac­ci­den­tal­ly use un­of­fi­cial re­leas­es de­signed for bad things, pro­vid­ed that:

• The bad guys know the name­space of the pack­ages you in­clude, and
• The bad guys man­age to pub­lish a bad re­lease in a repos­i­to­ry you use

This type of ex­ploit seems com­mon for Javascript, but not so much for maven projects. That's be­cause maven cen­tral only al­lows pub­lish­ing a li­brary if you prove that you own the name­space. Nev­er­the­less, it's good to be aware of this pos­si­bil­i­ty.

Our take

So what does this mean to you, as an Atomikos user / cus­tomer? Make sure to use only our of­fi­cial bi­na­ries (ei­ther signed on maven cen­tral or in our pri­vate cus­tomer repos­i­to­ry) and con­fig­ure your build in­fra­struc­ture to avoid pulling in code from 3rd par­ty pub­lic maven repos­i­to­ries.