With the rise of malicious code polluting the supply chain for main scripted languages these days, i thought to rethink about how we should choose the right runtime + language base on application nature.
For example take the malicious code deployed in npm https://spaceraccoon.dev/supply-chain-pollution-hunting-a-16-million-download-week-npm-package and https://www.bleepingcomputer.com/news/security/npm-package-steals-chrome-passwords-on-windows-via-recovery-tool/ and https://blog.sonatype.com/malware-removed-from-maven-central
These attempts shows how venerable it is to pollute a supply chain and disrupt or steal information.
Now these things are inevitable, so what measures that can be taken to minimize the impact ? Before i start my take on this you should know that the points i bring up about nodejs and npm are solely based on what i find on internet.
Java
So lets take the maven central example first. The plugins that was made with same artifacts can be detected easily if you look at your dependencies. You could also use enforcer plugin to ban such plugins at your parent pom level. Since maven only allow to refer plugins with artifacts names for maven group ids and group ids that you have added in settings as plugin groups, its really hard you will miss this kind of a wrong plugin coordinates in your POM files.
Also there could be malicouse code added into your dependencies. May be a library which was orginally ment to implement some feature, might have taken over by a malicious developer to add some malicious code into it. This is were java security manager comes in handy. I know most of the apps i have seen rarly use this in its full potential. But you can control every aspect of what the written code can do using the security manager. You can even stop reflection attacks (which are know in web as prototype pollutions). You can find more about security manager here: https://docs.oracle.com/javase/8/docs/technotes/guides/security/permissions.html and https://www.baeldung.com/java-security-manager. All JVM languages (not only java) can benefit from this.
JS
Now lets have a look at JS world. When reading about all these malicouse libraries it seems there are motivated by the design of
- How npm install dependencies
- Javascript prototype pollution ability and runtime design
- Lack of proper review process of libraries.
Now there have been some discussions around to mitigate these things which might have gone side ways like https://npm.community/t/blacklist-entire-packages/9659/4 and https://github.com/npm/feedback/discussions/272. Of course there might be tools which you can use, such as running a commercial npm registry in proxy mode with blacklisting support. But what are the basic features you have as a developer that can be use to mitigate these things ?
How I see
So this leads me to think, Is some of these popular runtimes and languages are ready to be used in application development from a security stand point of view ? It doesn't mean we should reject these runtimes and languages, but may be we should use them in areas where a intruder can make least impact. As in good old golden days where we use JS on the client side. Also as developers we should try to improve these runtimes/languages and package registries to avoid such vunerabilities when these tools evolve from what they ment for in begining to what they are used for now.
Top comments (0)