Sonatype targets a more secure software supply chain (Image Credit: ThisisEngineering RAEng on Unsplash)Sonatype wants to improve the software supply chain making it more secure and fit for purpose. It has announced new products and an acquisition as part of its full-spectrum software supply chain management platform. It has acquired the MuseDev code analysis platform for an undisclosed amount. Sonatype has also launched its Nexus Container and Infrastructure as Code pack.

Wayne Jackson, CEO and co-founder, Sonatype (Image Credit: LinkedIn)
Wayne Jackson, CEO and co-founder, Sonatype

Wayne Jackson, CEO, Sonatype, said: “As software development teams race forward to deliver new digital innovations, software supply chain management and security has been ushered to center stage.

“Over the past six months, we’ve been working hard to expand our Nexus platform to deliver full-spectrum support to all application building blocks — not just open source — and truly enable developer productivity. As developers take on more responsibility for containers, code, and infrastructure, our mission is to make their lives easier while they make great software.”

A quick look at the announcements

There are five parts to the Sonatype announcement. This includes the Muse acquisition, three product updates and support for the Nexus community. In brief, these are:

  • Muse: A cloud-native source code analysis solution helping developers catch and fix performance, reliability, and security bugs during code review.
  • Nexus Container: A developer-friendly container security solution providing continuous visibility into the composition, and management of, containers from development, to delivery, to run time.
  • Infrastructure as Code Pack: Delivers out-of-the-box guidance to assist developers configuring cloud infrastructure and foster compliance with privacy and security standards (e.g., CIS Foundations Benchmarks, GDPR, HIPAA, ISO 27001, NIST 800-53, PCI, SOC 2). Integrated with Nexus Lifecycle, the pack will make it possible for developers to find and easily fix misconfigurations in Terraform plans before they are applied to production infrastructure.
  • Advanced Legal Pack: The forthcoming Advanced Legal Pack will improve visibility into open source license obligations for software development and legal teams.
  • Nexus Community: As part of Sonatype’s unwavering commitment to the open-source and developer communities, we’ve created advanced migration support for open source projects scrambling to find homes on the heels of Bintray and JCenter sunsetting. Open source projects can easily migrate their packages to a free Nexus Repository instance and/or Maven Central host.

A deeper dive into the Sonatype announcements

To get a closer look at what these announcements mean, Enterprise Times spoke with Brian Fox, CTO and Co-Founder at Sonatype.

One of the challenges of managing software is its complexity. It has never really been about a single developer. Instead, it’s about the tools and code they use, things they don’t own. In the case of the latter, almost no company knows what third-party code it is using. How do you begin to deal with that through your full-spectrum solution?

Brian Fox, CTO and Co-Founder at Sonatype (Image Credit: LinkedIn)
Brian Fox, CTO and Co-Founder at Sonatype

“We’ve architected the software and the lifecycle platform to take these things that different parts of the business care about and make it orderly and easy and actionable for development. What you see as part of the full spectrum is a widening of that platform. The information required to act upon TerraForm issues, infrastructure as code, how is that any different than fixing a dependency? It’s not.”

For Fox, this is not just about tracking all that third-party code and dependencies. It is also about knowing what you do with it. In most large projects, organisations leave checking the legal status of third-party code use last. It often gets lumped in with localisation. What Fox wants to do is change that.

“In 2010, there were around 200 different open source licences. Now there are 1,000s of them because everybody thinks it’s cute to create their own. It creates a nightmare for the legal teams to figure out what licences they should be afraid of. What we’ve done is decompose the licences into the obligations.”

One of the reasons Fox says legal teams dislike developers using GPL is because it says: “if you link it, your code has to be open source.”

Attribution and software manifests

Virtually every open source licence requires attribution, but this is often ignored by enterprise developers.

To solve this, Fox says: “By decomposing this entity obligation, we make it easier for people to understand which licences they really want to avoid. We also help them make sure they’ve met all of the obligations. If you require attribution and you’ve done it properly, it checks the box for all of the different licences that require it. There are at least 150 independent obligations that we track.”

This is not just about acknowledging where code has come from. As organisations increase the use of open-source, they quickly lose sight of where that code is used. Should a piece of code need patching, they don’t have manifests with the granularity of what is in a product. As such, you can’t be sure that you’ve patched all your vulnerabilities.

Fox replied: “That’s part of the mission that we’ve been on with the platform to be able to help. Even in cases where you don’t have a build manifest, and you’ve just assembled a collection of jars, we can fingerprint all those and build the manifest for you. If the manifest is missing stuff, we can highlight where you’ve missed or mislabeled it. It has to be part of the automation. We’ve been on that supply chain kind of rant, if you will, for 10 years.

“It’s part of every talk that I do, asking those sort of provocative questions. Hypothetically, if I told you about a vulnerability and a component right now, would you tell me are you using it? In which applications? Because if you can’t, you have no chance of patching.”

And that brings us back to Muse

Fox continued: “This is where the Muse stuff comes into play. We’ve seen organisations struggle to get developers involved in that. Application security tools produce a report that’s given to the developers, and often nothing really happens.

“What Muse has done is take 24 different analysers. Most of them are open source like Infer from Facebook. The challenge with those tools at scale is figuring out which tools to apply to a given codebase. The problem is then, at what threshold, do I decide what is important to fix? If you’ve got existing tech debt, when organisations turn on Muse, it spits out all the pre-existing findings. It’s no different to the security tool. You’re buried in a bunch of findings that you don’t know where to start.

“To solve this, Muse has built a feedback loop. They’ve integrated it into the pull request flow, a natural place for developers to collect feedback. It’s where their peers are providing conversational feedback on the thing that they just did. Muse is providing that same feedback and a conversational way that developers can interact with the bot.

“By collecting both the conversational feedback and the definitive feedback of, did they actually fix the thing that that was pointed out and did it go away before it was merged, we’re able to learn about the findings that matter, the findings that are most likely to get fixed at any given time. With that information, we can kind of drip it to them in the code they’re working on where it is highly likely to get fixed. Using that approach, they’ve observed that the items being surface are 70 times more likely to be fixed.”

Spotting behavioural anomalies in the software supply chain

One of the challenges today is that so much code is pulled from different places that tracking code veracity is a non-trivial problem. If a malicious actor releases good code but later swaps it out for bad code, detecting it can be very hard. Fox says that this is where the Nexus containers become important.

“The container with the runtime and the network analysis is designed to understand behavioural analysis. If a container starts talking to things it shouldn’t be, that is a flag which would maybe indicate something got into the supply chain that isn’t previously known. We can detect it based on the behaviour. This is just like antivirus tools when they moved from detecting fingerprints to detecting the behaviour. That’s what’s going on inside the firewall capabilities of Nexus runtime.

“We launched release integrity capabilities back in October. Since then, we’ve been catching malware, especially in npm, at a rate that nobody else has. Not even GitHub themselves, and they run the repository. This is because we build that model that can analyse the project and understand what is normal and what abnormal behaviours look like. When it appears as a new component, we can flag it right away. That was how we were able to protect against all of the dependency confusion attacks before it was even announced because the attributes of those were fishy based on lots of different things.”

One of the behaviours from the SolarWinds attack was unexpected DNS calls. Palo Alto says that their security software caught this unexpected behaviour. It allowed them to identify a problem and block attacks. In Sonatype’s case, Fox said they were particularly interested in new and unexpected dependencies.

Enterprise Times: What does this mean?

Securing the software supply chain is a grand aim that can be broken down into parts. The achievable part, according to Sonatype, is all the components that your developers use. It is now tracking all those elements, where they come from and the licence under which they can be used. For open source developers, this should significantly increase the attribution to their work.

There is a secondary gain here. It allows organisations to build proper software manifests. Without them, they cannot possibly know what components they are using that must be patched. With them, they can ensure they react to any patches and keep their software secure.

Where this problem gets most complicated is when the software is integrated into the business supply chain. This is where companies are dependent upon the API and code from its partners. Here, Sonatype is providing tools to help get to grips with the problem. The Nexus Container and the ability to detect any anomalous behaviour is one way to spot a potential third-party software issue.

This raft of releases by Sonatype and its promise of more to come for the community come at a time when software supply chain risks are not only higher than before but are finally on the agenda of everyone in the IT and security teams.


Please enter your comment!
Please enter your name here