Rules to reduce supply chain risks

Hi,
I’m wondering if you could add some rules for best practices to reduce risks of supply chain attacks. I’m searching for a way how to better enforce such policies in all teams.

Those could be flagged in CICD scripts, dockerfiles, bash scripts, package manager tool config files, etc.

Especially thinking about:

  1. Flag any usages of package installs without locked dependencies across ecosystems like npm, pypi, nuget, … (including corner cases like in nuget where restore is executed implicit by other nuget commands)
  2. (maybe an optionally addable rule, as not all might want this:) lack of defining a “cooldown” policy of x days before new package versions are pulled (e.g. npm: min-release-age=3, UV: exclude-newer = “3 days”, …)
  3. lack of configuring other security best practices like NPM ignore-scripts=true, …

Interestingly I found that for #1 you already have a rule for SWIFT, but not for any other ecosystem (swift:S7694: Using dependencies without locking resolved versions is security-sensitive). So I am wondering if you could add this for other ecosystems as well?

Thanks in advance!

Hi Ralf,

Thank you for the suggestions! We have actually recently added new rules to cover some of the cases you mentioned, namely:

  1. The approach in S7694 got extended to cover several package managers for Python. Java, Kotlin, PHP, Rust, JavaScript, Ruby, and Dart. We now detect if a lock file is not available and raise an issue. I created a note about NuGet support in the future, thanks for the idea!
  2. We added another set of rules to cover the same language ecosystems for using proper, lock-enforcing install commands (e.g., pip install -r requirements.txt --require-hashes) that makes sure the lock file is used.
  3. S6505 (JavaScript package manager scripts should not be executed during installation) got extended to cover python package managers.
  4. We added a rule to detecting piping to shells & interpreters.

If you are using SonarQube Cloud, you should already have these rules available!

There are some other rule ideas (e.g., enforcing release ages) and some forms of configuration are not yet implemented, but they are on our radar and I hope we can introduce more supply chain rules in the near future.

Best wishes,

Teemu R.

Thank you for the response, that sounds good. Except that we use SonarQube Server Enterprise and not the cloud solution. Can you say when this will be available for the on-prem solution?

Hi,

As a general rule, language changes hit SonarQube Cloud first, and then show up in the next Server release.

 
HTH,
Ann