Feedback Safety and security concerns around Unity's Package Manager and scoped registry?

So I'm sure by now many have heard of the malicious code attack that occurred with the Unity Hub 3.1.0 and its use of node-ipc as a dependency. Thankfully that explicit threat was dealt with ( you should update to Hub 3.1.1 if you have Hub 3.1.0 ), but it and a number of other threats in the past have illustrated just how exposed we developers are both to the use of development software and our own inclusion of packaged code into our projects.

What I would like to do in this thread is to bring the issue with regard to Unity packages to the attention of:

• Unity so they can be more pro-active in protecting their customers.
• Developers, to raise awareness
• Developers to discuss means and methods to protect ourselves.

To aid in this I've highlighted areas that require action with the header 'ACTION' - mostly aimed at Unity.


To understand the issue and the threat it poses you may want to familiar yourself with

• node-ipc situation, and specific breakdown wiping your drive.
• the 'Colors Attack'
• Microsoft white paper 'Dependency confusion'.
• LeftPad
• So many past warnings NPM Issues

The problem here is no longer limited to bad actors, the flood gate has been opened for social-political activism within the open-source community, as well as state sponsored attacks and everything else in-between. Its clear lessons were not learned in previous warnings so this has to be the wake up call for everyone involved, that includes Unity and us as developers.

In short trust at every level has been broken, trust that frankly should probably have never existed in the first place, and trust that was only 'secure' in terms of the faith put into the wisdom of crowdsourcing, hoping that someone else would spot the problem before it got into the wild.

It is therefore apparent that we must become pro-active in combatting this new vector of attack to mitigate its potential threat with regard to the Package Manager and packages in unity in general. Failure to do so means it can only be a matter of time before we succumb to an attack.

Finally whilst I'm focused on Unity Packages and the Package Manager here, I feel that asset-store packages should not be ignored from such a discussion. Granted it is assumed they are more secure because Unity 'vetted' them, and that the asset developers income relies on them, but I don't believe they are immune.

ACTION UNITY - There should be a concerted push from Unity to highlight asset-store packages that rely on third party code and maybe perform other risk assessments on them. Unity should provide additional avenues for the developers of such assets to provide their own security assessments of the third party code they use. Informing users and transparency are going to be key in building trust going forward.​

Unity Official Packages
Now you may be wondering what does this have to do with you? You might never touch the Unity Package Manager, you may only ever use Unity packages and even then only ones that have been 'verified'.

Well unfortunately this latest incident has shown that Unity apparently did little in the way to audit the dependencies that the Hub relied on, and whilst most Unity packages are not going to be using third party code, there is no way to be sure unless you go through each one and check. I mean have you seen the almost 1GB Burst library? Are all those dll's and exe's expressly written by Unity or are they third party or include third party code, or include third party code that is automatically updated through a package portal?

Hopefully I'm worrying about nothing here, but who knows and that's my point, does Unity even know? I still have trust in Unity, but it has been eroded somewhat and so I'd like to see them being pro-active here to rebuild that trust. Lets not forget that 'Verified' tag is only in regard to the package 'works' in a specific version of Unity, nothing more, its not a badge of safety or security!

Note - I'm assuming that Unity have at least some level of code review to prevent an internal bad actor from within the company inserting malicious code into official Unity packages.​

Now I strongly believe its highly unlikely we could or would see an attack through Unity packages, but it still a vector that needs to be explored and Unity is going to have audit them all and provide feedback to the community/customers that they are safe!

ACTION UNITY - Unity need to audit all their packages, at least those that are verified and provide a detailed breakdown of any that use third party libraries, executables, or code. They then need to provide assurances that such third party code is going to be checked and audited going forward so we as developers can assume they will be safe. Basically Unity need to provide transparent information and pro-actively inform us as users and customers as to the potential threat they might pose.​

Custom Packages and Scoped Registries
This is where things get more dicey and where we as developers are opening ourselves up to malicious code just like Unity did with the Hub. Whilst any malicious code in a package is likely to be only detrimental against our own machine/project, there is still the potential for it to get into any applications we deploy and thus become a threat to our clients/customers.

Sadly I feel the only level of security we currently have with third party packages is that of 'safety in numbers', whereby as long as you aren't the first one to update a package, you might be saved due to learning of an issue from others, much like what happened in Hub 3.1.0 case.

I guess the most obvious way to protect yourself would be to not use any non official Unity packages. Whilst that is a valid answer and one that I could have easily adhered to myself 6 months ago, I find today and I suspect going forward in the future is one that will become increasingly more difficult as it ignores the benefit and purpose of using packaged code in increasingly more complex and demanding software.

Further this 'solution' potentially does nothing to protect enterprise developers as shown by the Microsoft white paper above, though that is specifically with other package portals and I do not have the level of knowledge around Unity Package Manager to to know if similar threats exists within it.

ACTION UNITY & DEVELOPERS - Does the UPM suffer from the same security issue as shown by the Microsoft White Paper for a 'dependency confusion' such type attack?​

There are of courses levels of risk exposure here - as most if not all of the potential threats seen are due to dependency hell/confusion and poor practice of automatically updating packages without first auditing them. One might be tempted to limit the discussion, at least with regard to third party packages, as there are currently no ( that I know of ) essential third party packages needed for Unity, that outside of official Unity packages, dependency hell is likely not an issue either and that exposure in general is low as few developers probably use scoped registry feature. Obviously I disagree and think this is the perfect time to get ahead of the issue before it becomes a problem for Unity packages.

For example in most cases where I use third party packages I've audited the code to lesser/greater extent by learning to understand how it works and have yet to simply use a package in Unity for functionality without reading the entire code base, mostly as I'm obsessed with optimal code and optimising code.

The first problem then comes from trusting the source after the initial audit and blindly updating these third party packages but failing to auditing the updates! It is this blind updating of third party packages that is an area that Unity can and should invest some effort into, especially as I feel that Unity themselves have unfortunately conditioned users to keep packages up-to-date, both through the encouragement to update official packages ( due to bug fixes, missing features, progress, Unity version ) as well as subliminally via having all packages with a nice friendly green tick next to them.

ACTION UNITY - I feel an additional step to the UX could help, such as when trying to update a third party package you get a warning about blindly updating and the danger of failing to audit the new code. This is to put a 'break' on the unfortunate conditioning Unity has developed in encouraging users to keep packages up-to-date. It will be a little annoyance for developers to have to 'ok' a popup but it should at least give them pause for thought if the package really needs to be updated and to perform some due diligence.​

Potential Package Update Attack Vector?
Whilst writing this post it became evident that there is currently at least one potentially open attack vector for a compromised third party package. I've not had the time to test this, but I'm pretty sure when you update a package Unity will reload all scripts and the domain, thus automatically running any scripts in a package with the InitializeOnLoadMethod attribute. If true this is clearly a major issue as it means you cannot audit the package prior to install, unless the code is in a repro and that repro correctly represents the code in the package.

ACTION UNITY URGENT - If this is how packages work, then Unity need to find a way to address this concern. Ideally I'd like to see the code in a package prevented from being compiled until the user allows it. That way in theory a user could update a package and view the code first. Unfortunately I'm unsure if that is even possible. Maybe it would be possible to sandbox the code in some way, such that a user could view the code and the code is never ran until the user ok's it.​

What else can we do?
So what else can we do as developers to protect ourselves?

Honestly I'm not sure. I can think of plenty of cool things like setting up a company and paying them to validate your packages, but whose going to bother setting that up and can you then trust such a company to properly vet packages? Alternatively we could set up a crowd source version of the same thing, but that seems only slightly better than what we already have with npm and github.

The only 'good' idea I have is some sort of warning/discussion system to alert users to compromised packages. It doesn't solve the problem but it perhaps means the information could spread faster. This could perhaps be in the form of a forum, ideally here on Unity forums itself. A place where perhaps users can ask if other users have audited specific third party packages and versions, report suspicious packages etc. Again this is not a solution, just an additional mitigation factor that might just help in the future.

If such an idea has merit, perhaps it could be further developed and integrated into the Unity Package Manager itself. I mean does the existing Package Manager even have anything in place to deal with rogue or compromised third party ( or even official ) packages?

ACTION UNITY - Inform users as to whether the Package Manager currently has anything in place to deal with rogue or compromised packages ( official or third party ). If it does not, then that needs to be a priority, where by it can deal with such packages in some way - e.g. sandbox, delete, highlight, prevent specific version installation etc. ​

So what ideas do other developers have?