Supply-Chain-Attacks: Configure mininumReleaseAge properly

[carlos-lehmann]

How are you running Renovate?

Self-hosted Renovate CLI

Which platform you running Renovate on?

GitLab (.com or self-hosted)

Which version of Renovate are you using?

43

Please tell us more about your question or problem

Supply-Chain-Attacks are increasing and I was wondering if we could get a best practice to set minimumReleaseAge for a centralized Renovate? What I've gathered from the docs is that I can set this globally but I should also enable it for every package manager that supports it, where I'm struggling to find the information. Ideally we have a list provided by Renovate or this gets added to config:best-practices?

Thank you!
Carlos

Logs (if relevant)

Logs

Replace this text with your logs, between the starting and ending triple backticks

[jamietanna]

A few things:

• Agreed, minimumReleaseAge is one area that can be used to prevent one type of supply chain attacks
• Provide an experimental preset for "compromised/malicious packages" #42069 covers some thinking we're doing around how to handle malicious packages and block them from being updated
• minimumReleaseAge only supports specific datasources and specific registries, so if you have minimumReleaseAgeBehaviour=timestamp-required, you'll not get any updates if they don't have a releaseTimestamp (which is a reasonable tradeoff)
• We're only going to add a minimumReleaseAge at a package manager/datasource level in config:best-practices (as we did in Renovate 43 for npm)
• We won't set a required value for all users unless they opt in
• You can see what's in config:best-practices
• When self-hosting, it's up to you to decide how you enforce this for your users - there are some organisations using 14 days, but then opting out some of their internal dependencies

Hope that helps, but happy to chat in more detail

[carlos-lehmann]

Thanks for your reply! I guess one thing I'm missing is a configuration example. We have config:best-practices in place so security:minimumReleaseAgeNpm is already in there.
Regarding the additional package managers... so this list is a good starting point? This is our current default.json5, so adding:

{
  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
  // This is the rate limiting function of open MRs done by Renovate
  "prConcurrentLimit": 5,
  "extends": [
    // This is the Renovate recommended default configuration that should be a good starting point
    "config:best-practices",
    ":enableVulnerabilityAlerts",
    ":gomod",
    ":includeNodeModules",
    ":npm",
    "docker:enableMajor",
    "customManagers:dockerfileVersions",
    "customManagers:gitlabPipelineVersions",
    "customManagers:helmChartYamlAppVersions",
    "replacements:all",
    "security:openssf-scorecard",
    "workarounds:all",
    ":enablePreCommit",
    "minimumReleaseAge": "7 days", # here
  ],
}

As a general configuration? And then add a package rule for additional manager matching?

  "packageRules": [
    {
      "matchPackagePatterns": ["^@angular", "^react"],
      "minimumReleaseAge": "7 days"
    }

Is that how we supposed to manage it?

Thank you!

[NVolcz]

I am using this config: #40553 (reply in thread)

[jamietanna]

Not quite @carlos-lehmann, it'd be:

{
  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
  // This is the rate limiting function of open MRs done by Renovate
  "prConcurrentLimit": 5,
  "extends": [
    // This is the Renovate recommended default configuration that should be a good starting point
    "config:best-practices",
    ":enableVulnerabilityAlerts",
    ":gomod",
    ":includeNodeModules",
    ":npm",
    "docker:enableMajor",
    "customManagers:dockerfileVersions",
    "customManagers:gitlabPipelineVersions",
    "customManagers:helmChartYamlAppVersions",
    "replacements:all",
    "security:openssf-scorecard",
    "workarounds:all",
    ":enablePreCommit",
  ],
  "minimumReleaseAge": "7 days", // NOTE that this isn't under `extends`
  "packageRules": [
    {
      "matchPackagePatterns": ["^@angular", "^react"],
      "minimumReleaseAge": "14 days"
    }
  ]
 }

[jamietanna]

I'd say that ☝️ from @NVolcz is a good, but I wouldn't recommend using minimumReleaseAgeBehaviour=timestamp-optional

[carlos-lehmann]

@jamietanna thank you very much...
Could we also do something like:

packageRules: [
    {
      // Wait 7 days after release for external packages to prevent malwaretised updates
      matchPackagePatterns: [".*"],
      excludePackagePatterns: ["some internal package nameing conventions"],
      minimumReleaseAge: "7 days",
    },

or would you advise not to? This is also tied to Discussion I just spotted: #42533

[NVolcz]

I'd say that ☝️ from @NVolcz is a good, but I wouldn't recommend using minimumReleaseAgeBehaviour=timestamp-optional

Could you please expand on why you dont recommend it? I believe I set it to make the configuration work with package managers that doesn't support timestamps, thinking that it will be honered for those that do support it.

[jamietanna]

Sure, I've replied over in the other thread!

[amai2012]

Even if minimumReleaseAge is set a merge request will be created and a pipeline has been run (using gitlab).
So a potential attack will have already taken place (e.g. running a compromised docker image), just that the new artifact doesn't get merged.
Can prCreation help to prevent this?

[carlos-lehmann]

@jamietanna would be great to have your advise here for this as well.

[jamietanna]

Yes, via you'll need to confirm your internalChecksFilter and prCreation settings

See what we're doing in security:minimumReleaseAgeNpm for example

(Note that we're not specifying prCreation, and are leaving that to the user's option / provided defaults)