Define custom rules for Node.js build tools

Rules and Languages
1

Hi,

due to the recent NPM attacks we decided to have centralized configuration files for the Node.js build tools like NPM (.npmrc), Yarn (.yarnrc, .yarnrc.yml) and PNPM (pnpm-workspace.yaml). As these may be overridden on project level, we thought about defining custom rules for these files to make sure, certain settings are not changed.

Is there a way to define rules on yml-files? Is there any other way to check for such changes?

We are using SonarQube Server 2025.4.2, soon updating to 2025.6.1.

Thanks!

Regards,

Carsten

Sonar Community Roundup; Feb 7 - 13
Sonar Community Roundup; Feb 28 - March 6
2

Hi Carsten,

There are 3 rules for YAML, but nothing that would be helpful in this context.

I’m going to flag this need for the PMs.

 
Ann

1 Like
5

Hi Carsten, could you share some examples of the settings you would like to enforce in projects?

6

Hi @gab,

these are the settings we define in the central.yarnrc.yml:

httpTimeout: 500000

npmRegistryServer: "<internal-company-mirror>"

enableScripts: false

npmScopes:
  <internal-scope>:
    npmPublishRegistry: "<internal-registry>"
    npmRegistryServer: "<internal-registry>"

So we would like to check, whether a project overrides some of them. The other build tools are configured similarly.

Regards,

Carsten

7

Hi Gabriel,

I’m a coworker of Carsten. In light of recent Node.js supply chain attacks (e.g. Shai-Hulud), we are looking to restrict certain Node.js build features through a centrally managed configuration, distributed automatically by our IT department to the developer devices and CI/CD infrastructure.

Node.js build tools such as npm and (classic) Yarn allow projects to extend and override centralized configuration next to the package.json file in the source code repository - and that is exactly the challenge we are facing. For example, we want to disable the execution of scripts via centralized configuration and have SonarQube raise an issue if a project re-enables this setting locally.

The extending of the configuration files is not forbidden generally, but for certain options and we want to detect this.

Best regards,

Oliver

2 Likes
8

Thanks for sharing!

This sounds like something that could help many people with their npm security posture!

What do you think about Sonar having these rules out of the box? e.g.

1/ npm projects should not use the public npm registry / use internal registry
2/ npm projects should not enable npm scripts
3/ npm projects should have a sufficient http timeout
4/ npm scoped packages should use internal registry

These could be template rules so you can have finer control, e.g. your registry, the timeout value.

Would something like this work for you?

10

Hi Gabriel,

thank you for your suggestions. I shared them with our security team, and below is their feedback:

  1. npm projects should not use the public npm registry / should use an internal registry
    This would be very valuable for us. Our goal is for all software projects to use our internal registry as a mirror.
    If a project uses the public npm registry directly, we would like this to be reported as a major or critical security issue.
  2. npm projects should not enable npm scripts
    Similar to point 1, this would help us a lot. Disabling npm scripts significantly reduces the attack surface.
  3. npm projects should have a sufficient HTTP timeout
    A defined HTTP timeout is required due to internal infrastructure constraints. From a security perspective, however, there is no strong requirement for this and we don’t really need to detect this by SonarQube.
  4. npm scoped packages should use the internal registry
    This aligns closely with point 1 and would be equally important for us.

In addition, our security team recommends the use of npmMinimalAgeGates. This ensures that a package must have reached a minimum age before it can be used.
For example, npm packages can be unpublished within 72 hours (see Unpublishing packages from the registry | npm Docs ), which allows maintainers to remove corrupted or compromised artifacts. Enforcing a minimum age reduces the risk of consuming such artifacts.

We would need these rules to be available for Yarn, but it would also be very helpful to have them supported for npm and pnpm as well. I think these build-tools also allows such a configuration, but they might look different.

Best regards,

Oliver

2 Likes
11

Hi Carsten and Olivier,

We discussed with @Alexandre_Gigleux who leads SAST analysis, and this makes a lot of sense. Our appsec team will look into this as potentially something to have out of the box in SonarQube :fire:

2 Likes
19

Hi @Carsten_HB and @oliver.s,

Thanks a lot of your input on potential rule ideas! I just wanted to briefly let you know that we are currently working on specifying new rules to harden build pipelines (including those for the Node ecosystem), so stay tuned.

If you have any other ideas besides the ones discussed already in this thread, feel free to let us know and we will see what we can nicely integrate into our out-of-the-box rules.

Best wishes,

Teemu

2 Likes