What can be done to mitigate Node.js / JavaScript risks in WinCC OA?

The WinCC OA JavaScript Manager for Node.js and other Node.js-based managers bring the npm ecosystem into WinCC OA. They also bring the typical risks of a script runtime: compromised npm packages, manipulated updates, modified script files, and code running with more privileges than it needs. This FAQ explains how to mitigate these risks today, using WinCC OA features and standard operating system tools.

Supply-chain compromise

How are vulnerabilities in the npm packages shipped with WinCC OA handled?

ETM continuously monitors the third-party components shipped with WinCC OA for known vulnerabilities and is notified when a new one is discovered. For npm packages, the direct dependencies are monitored; all transitive dependencies are pinned to fixed versions and verified by hash. Affected components are updated with WinCC OA patches, so install patches promptly.

Which dependencies do I have to track myself?

Only the npm packages you add to your own project. Set up a vulnerability management process for them, similar to the one ETM applies to WinCC OA components.

Why do I need a Software Bill of Materials (SBOM)?

Vulnerability monitoring is based on the SBOM: a component that is not listed is not covered by the SBOM-based monitoring. WinCC OA provides an SBOM for its components. Create one for your own project as well.

How do I cover transitive dependencies?

A single npm package can pull in dozens of indirect dependencies, and vulnerabilities in these are easy to miss. To cover them:

• List your direct (top-level) dependencies from package.json in the SBOM (e.g. in CycloneDX format) and monitor them for vulnerabilities.
• Pin all versions, including transitive ones, with a committed package-lock.json and its integrity hashes (see next question).
• Run npm audit in your build to check the complete dependency tree.
• Pin a fixed version of a vulnerable transitive package with overrides in package.json.

How do I make sure the installed dependencies are the reviewed ones?

• Commit package-lock.json with its integrity hashes.
• Install with npm ci --ignore-scripts. npm ci installs exactly the versions and hashes from package-lock.json and fails on any mismatch; --ignore-scripts prevents package install scripts from running, a common way malware is spread. Allow scripts only for packages that need them (e.g. native add-ons).
• Build node_modules once in a controlled environment and ship it with your deployment. Do not run npm on the target system, so it needs no access to the npm registry and cannot pull other versions.

Manipulated updates

How do I make sure a WinCC OA update has not been manipulated?

Download WinCC OA software and patches only from the official sources: the WinCC OA download portal or Siemens Industry Online Support (SIOS). WinCC OA installation packages and patches are digitally signed. Verify every download before installing it:

• Windows: Check the digital signature and the checksum, see chapter 6.2.2.15.1 “Check digital signatures for Microsoft® Windows systems” of the WinCC OA Security Guideline.
• Linux: Check the hash and checksum, see chapter 6.2.2.15.2 “Check hash and checksum for Linux” of the WinCC OA Security Guideline.

The reference checksums are published in the download folder on the WinCC OA portal and in the patch notifications on SIOS (search for “WinCC OA Patch”). Comparing against SIOS gives you an independent second source.

How do Node.js components inside WinCC OA get updated?

Through the regular WinCC OA patches, which also update the bundled npm packages. Do not replace bundled packages in the installation directory by hand.

How should I update the npm packages of my own project?

Use trusted updates only. A minimum release age (min-release-age) of 7–14 days before a new package version is used means most malicious versions are found and removed before you take them. Review every change to package-lock.json before merging it.

Code tampering

How do I prevent installed JavaScript files from being modified?

Install WinCC OA in a read-only location and enforce this with file system ACLs. Use chapter 6.2.1.10 “Definition of Access Control List (ACL)” of the WinCC OA Security Guideline as a starting point.

Which permissions should the directories have?

WinCC OA separates product code from project data: the product code is in the installation directory, which is read-only for the runtime account; configuration and project code are in the project directory.

On Linux, the code belongs to root and the runtime user is neither the owner nor in a group with write access. On Windows, the runtime account gets Read & Execute only on the installation and project code directories.

Can I detect a modified file?

Yes:

• Check on demand (Linux): rpm -V <package> compares the installed WinCC OA files with the checksums from the RPM package, see chapter 6.2.2.15.2 “Check hash and checksum for Linux” of the WinCC OA Security Guideline. This covers the installation directory, not your project files.
• Continuous detection: Turn on file system auditing for the code directories so that every write is logged: on Windows, enable auditing on the folder (Properties → Security → Advanced → Auditing; logged as event 4663) or use Sysmon; on Linux, use auditd rules (-w <path> -p wa). Forward these events to your Security Information and Event Management (SIEM) system (see Monitoring & detection).

Does WinCC OA check JavaScript files, CTRL scripts and panels for modifications?

Not directly. File integrity is ensured by the operating system and dedicated security tools:

• Prevent changes with read-only permissions (see above).
• Detect changes with file auditing or a file integrity monitoring (FIM) tool.
• Block modified files from being loaded with an application whitelisting tool that covers script files.

How do I prevent an older or modified version of a file from being loaded?

WinCC OA searches the project directory before the installation directory. A file placed in the project directory therefore overrides the read-only version from the installation, for example with an older, vulnerable version. To prevent this:

• Allow write access to the project code directories only for engineering/deployment accounts (see table above).
• Use application whitelisting on the project directory, so that only approved files are loaded.
• Pin your npm package versions with package-lock.json (see Supply-chain compromise).

Excessive privileges

How do I run Node.js-based managers without admin or root rights?

Run the managers with the least-privileged user your use case needs. Managers inherit the account of PMON, so restrict PMON:

• Windows: Install PMON as a service under a restricted account, e.g.:

  WCCILpmon -user NetworkService -install -set <proj_path>\config\config 1

  Choose “This account” instead of “Local system account” (Configuration of the service). From least to most privileged, the options are network service, local service, local system and a special user (Kerberos requirements).

• Linux: Set User=winccoa in /etc/systemd/system/winccoa@.service (WinCC OA as Linux Service). This user needs write access to <proj_path>/log and <proj_path>/db.

What should I check when using a restricted account?

Some internal WinCC OA data points may not be updated correctly when managers run without root rights. Test the project with the restricted account before going live.

Can I isolate a Node.js manager from the rest of the system?

Yes. Run a container that contains only the Node.js manager and connects to another container or host running the WinCC OA project (Docker Support). Harden the container with standard options:

• Non-root user
• --read-only root file system
• --cap-drop=ALL
• --security-opt=no-new-privileges
• A dedicated network

How do I restrict file system and network access?

With ACLs, the operating system firewall and WinCC OA user rights:

• File system: The manager's account gets write access only to the log and data directories (see Code tampering).
• Network: Allow outbound connections only to the WinCC OA event manager and the required external systems (e.g. an MQTT broker), and inbound only the required ports (Windows Firewall rule per program or service, nftables/firewalld on Linux).
• WinCC OA: Run each Node.js-based manager, or each group of managers with the same tasks, as its own WinCC OA user with write rights only on the data points it needs. In an SSA project this means: create a certificate containing that user name, start the manager with -user <name>, and set ssaCertificate and ssaPrivateKey in the manager-specific section of the config file (Server-side Authentication for Managers). Do not store the private keys in the project directory.

Monitoring & detection

How do I log and alert on security-relevant events?

Use the security event feature of WinCC OA. Security events extend the WinCC OA logging and can be monitored by external SIEM systems (Security Events in WinCC OA, Continuous Monitoring – Auditable Events).

Can I add my own security events?

Yes. Define custom events in SecurityEvents_initList.json and raise them from CTRL or the C++ API with securityEvent().

What should I monitor for Node.js-based managers?

• File changes in the code directories (operating system file auditing, see Code tampering)
• Unexpected manager restarts or crashes reported by PMON
• Manager connections to the event manager (covered by WinCC OA security events for communication and connections)

Forward all of these to one SIEM so they can be correlated.

Cyber Resilience Act

Which Cyber Resilience Act (CRA) requirements apply to Node.js-based WinCC OA solutions?

All essential cybersecurity requirements of Annex I of the CRA: 
Part I (security properties of the product) and Part II (vulnerability handling, including the SBOM). 
They apply to the manufacturer who places the solution on the EU market.

Further links