Node.js Security on IBM i: Don’t Twist Your Melon (But Do Pay Attention)

A subscriber left a great comment on one of my recent vlogs. They’re worried that all this Node.js stuff that IBM is encouraging, means we’re opening up security holes! NPM Hackers caused a supply chain mess with Red Hat back in 2024, and now hundreds of packages with their own dependencies could be sitting on our systems? Is IBM i suddenly less secure? Are we giving attackers a bigger target in what used to be a pretty locked-down world?

“I’m concerned about security issues, because so much of the IBM software needs Node.js runtimes, and the npm files were recently hacked at Red Hat. I fear IBM is introducing security vulnerabilities, or at least providing a larger surface area to attack to the otherwise bulletproof mainframe ecosphere. Can I ignore those anxieties of mine?”

Your concerns are valid.

We should all be paying attention.

But should we be terrified and reaching for the antacids? No. Let’s sort the real risks from the unnecessary panic.

Why the Worries Are Legitimate

Node.js does increase the attack surface. IBM i has always been this contained, object-based fortress where security lives at a very deep level. Bringing in a JavaScript runtime that happily pulls packages from the public internet changes the game. One dodgy package in a long dependency chain can become a problem for everyone.

We’ve all seen how supply chain attacks work. That Red Hat compromise showed just how nasty a single weak link can get. On IBM i, where stability and “don’t touch it if it works” are practically a religion, this feels like we’re adding new doors that need proper locks.

Managing updates across hundreds of transitive dependencies can also clash with the way most IBM i shops like to operate. It’s extra work, and extra work means extra chances for something to slip through.

The Good News: IBM i Hasn’t Gone Soft

Here’s the bit that should stop you from twisting your melon too much.

Node.js runs inside PASE. That’s a separate subsystem, not the core IBM i engine room. It’s a bit like having a lively party in the guest house while the main house stays properly locked down.

Your object-level security, authority lists, and profile controls still apply exactly as before. If a Node.js process tries to do something it shouldn’t, IBM i security still steps in and says no.

IBM also supplies its own curated and security-scanned builds of Node.js. You’re not just grabbing whatever is floating around on the internet (and if you are, please stop that right now).

Even when your Node.js code talks to the database, it still needs proper IBM i credentials and authorities. No free passes through the back door.

Practical Steps to Stay Secure Without the Drama

So what should you actually do? Here are some sensible recommendations:

1. Only use Node.js where it genuinely helps. For plenty of integration or API work, a well-written RPGLE or SQLRPGLE program (or even the built-in SQL HTTP functions) might do the job without inviting the entire npm universe in for tea and biscuits.
2. Keep it compartmentalised. Run Node.js for specific web services or APIs. Don’t let it wander into core business logic unless you have a very good reason.
3. Audit your dependencies like it matters. Use npm audit as part of your regular process. Tools like Snyk or Dependabot can catch problems early. Make vulnerability scanning a habit, not a once-a-year panic.
4. Use a private registry. Vet packages once, approve them, and serve them internally. Much safer than pulling everything straight from the public npm every time.
5. Lock down the authorities. Give your Node.js jobs the minimum IBM i profile rights they need. No *ALLOBJ “just in case” nonsense unless you enjoy living dangerously.
6. Stay on top of patching and network controls. Keep things isolated where possible and apply IBM updates promptly.

Best Practice: Give PASE Workloads Their Own Dedicated Profiles

If you’re running Node.js services, Python scripts, SSH daemons, or anything else that lives in PASE, do not run them under QSECOFR, QSYSOPR, or your own daily driver profile with *ALLOBJ.

Create dedicated user profiles for these workloads instead. A sensible setup usually looks like this:

• Only the special authorities the job actually needs (often none at all)
• Private authorities granted only to the specific libraries, objects, and IFS paths it must touch
• A primary group profile so you can manage several related services together without granting rights to every single profile
• A sensible initial program or home directory if the profile will ever be used interactively

Running a Node.js API server under a high-authority profile is a bit like giving the cat the keys to the entire server room and hoping it only uses the litter tray. It works fine until the day it doesn’t, and then the audit log makes for very uncomfortable reading.

Practical Gotchas and Handy Tips

A few things worth knowing when you start setting this up:

• Long profile names: If your user profile name is longer than eight characters, some older PASE tools or SSH configurations can get grumpy. You can often work around it by setting the environment variable PASE_USRGRP_LIMITED=N in the relevant config file.
• Home directories: For interactive PASE use or sFTP-style access, make sure /home/yourprofile exists with the correct ownership and permissions. The system doesn’t always create it automatically.
• *IFS versus LIB security: PASE sees traditional Unix-style permissions on the IFS, but the underlying IBM i authorities on the *DIR and *STMF objects still apply. You usually need to manage both layers.
• Checking what’s what: From a green-screen session use DSPUSRPRF or WRKOBJ to inspect authorities. Inside a PASE shell, id, groups, and ls -l give you the Unix-style view.
• Node.js specific: The Node.js runtime inherits whatever user profile the job that started it is running under (often QTMHHTTP for web stuff, or whatever batch profile you chose). Make sure that profile has exactly the rights your application needs to the database, spool files, or IFS paths. Nothing more.

PASE security profiles aren’t some exotic new invention. They’re the same IBM i user profiles we’ve been using for decades, just viewed through a slightly more Unix-flavoured lens with UID and GID mappings added.

The rules for staying secure are exactly the same as they’ve always been on IBM i:

• Least privilege
• Dedicated accounts for different workloads
• Understand that PASE lives inside the IBM i security model. It doesn’t bypass it.

If you’re modernising with Node.js or any other PASE technology, spend a little time upfront creating proper profiles and authority setups. Your future self (and anyone who ever has to explain this to an auditor) will be very grateful.

At the End of the Day…

Your anxiety is justified. Real vulnerabilities exist, supply chain risks are genuine, and if you work in a regulated environment you’ll need to document how you’re handling this. Attackers will absolutely look for the weakest link, and a compromised npm package can be that link.

But IBM i’s core security architecture remains strong. Node.js adds a new layer that needs intentional, security-conscious implementation. It doesn’t break the existing model.

So don’t ignore the concerns. Use them to put proper controls, monitoring, and common sense in place. Then you can use Node.js where it adds real value without lying awake wondering whether a dodgy JavaScript package is about to ruin your weekend.

I’ve written before about getting Node.js up and running via PASE if you’re just starting out. The platform can handle this stuff safely when we treat it with the respect it deserves.

What’s your experience? Are you already running Node.js workloads on IBM i? Got your own security lessons or favourite tools for keeping things tidy? Drop them in the comments. I’d love to hear how other shops are handling this.

Stay safe out there, and keep those authority lists tight.