Software Supply Chain Security Checklist

Chapter 2 of 9 · 5 checks · 3 min

Dependency updates and review

Checks that updates arrive regularly, wait long enough for bad releases to be caught, and are reviewed for known vulnerabilities before they merge.

Show
  1. An update bot covers every ecosystem in the repository, including GitHub ActionsMust

    Why it matters and how to check

    Pinning without updates turns into running old, vulnerable code. Scorecard's Dependency-Update-Tool check (rated High risk) looks for Dependabot or Renovate. The ecosystem list is easy to get wrong: a Dependabot file that covers npm but not github-actions or docker leaves those pins frozen forever.

    To verify: open .github/dependabot.yml or the Renovate config and list the ecosystems and directories it covers. Compare that with every manifest, Dockerfile and workflow directory in the repository. Then check the bot's recent pull requests: if the newest is months old, it is configured but not working.

    Example

    YAML
    version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
    cooldown:
      default-days: 3
    groups:
      minor-and-patch:
        update-types: ["minor", "patch"]
  - package-ecosystem: "github-actions"
    directory: "/"
    schedule:
      interval: "weekly"
  2. Routine version updates wait a few days after a releaseShould

    Why it matters and how to check

    Malicious versions are often found and pulled within days of being published. The OpenSSF Concise Guide recommends keeping dependencies up to date after a cooldown of roughly three days for updates that do not fix a known vulnerability. Dependabot's cooldown option delays version updates without delaying security updates, and npm's min-release-age setting refuses versions younger than a given number of days.

    To verify: check the update bot config for a cooldown (Dependabot cooldown, Renovate minimumReleaseAge). Open a recent bot pull request and compare its creation date with the release date of the version it proposes. Confirm security updates are not delayed by the same rule.

  3. Pull requests that change dependencies are blocked if they add known vulnerabilitiesMust

    Why it matters and how to check

    GitHub's dependency review action compares the dependency changes in a pull request and fails the check when it finds vulnerable versions. It can also enforce a licence allow or deny list. It is available for all public repositories, and for private ones with GitHub Code Security or Advanced Security. Other platforms have equivalents, such as OSV-Scanner run on the diff.

    To verify: confirm the check runs on pull requests and is a required status check on the default branch. Then open a test pull request that adds a package version with a published advisory and confirm the merge is blocked.

    Example

    YAML
    name: dependency-review
on: pull_request
permissions:
  contents: read
jobs:
  review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
      - uses: actions/dependency-review-action@a1d282b36b6f3519aa1f3fc636f609c47dddb294 # v5.0.0
        with:
          fail-on-severity: high
  4. Known vulnerabilities in direct and transitive dependencies are monitored and triagedMust

    Why it matters and how to check

    New advisories arrive for code you already ship. The OpenSSF Concise Guide says to monitor known vulnerabilities in direct and indirect dependencies and update quickly when one affects you. Scorecard's Vulnerabilities check looks for open, unfixed vulnerabilities using OSV data.

    To verify: open the alerts view for the repository (Dependabot alerts, or your scanner's dashboard). Check that someone owns it, that critical and high findings have a ticket or a recorded decision, and that the oldest open critical is not older than your own policy allows. Run npm audit, pip-audit or osv-scanner against the lockfile and compare the output with the dashboard.

  5. Update pull requests are reviewed and tested, not merged unseenShould

    Why it matters and how to check

    An update bot is a convenient way for a compromised release to reach production if its pull requests auto-merge on green. Grouping minor and patch updates keeps the volume manageable so a person can still look at the diff, especially lockfile changes that add new transitive packages or install scripts.

    To verify: read the auto-merge rules for bot pull requests. If any exist, confirm they apply only to low-risk updates (patch versions of development tools, for example), wait for the full test suite and still respect the cooldown. Spot check three merged bot pull requests for a human review.