Supply chain

Required

• Lock and audit dependencies

  APS-69

  Commit a lock file, install from it exactly, and fail the build on known holes in any dependency.

• Keep secrets out of builds from strangers

  APS-74

  Never give deploy keys or other secrets to builds that run code from outside contributors. Give each build job only the access it needs.

Recommended

• Review every new package

  APS-70

  Check every new dependency before adding it. Attackers publish packages with names close to popular ones, and take over abandoned ones.

• Keep the dependency tree small

  APS-71

  Count every package the app installs, including the dependencies of dependencies. Add a package only when the standard library or a few lines of your own cannot do the job.

• Wait a few days before taking new releases

  APS-72

  Install a new version of a dependency only after it has been public for at least 7 days. Security fixes you need now may skip the wait.

• Fetch private packages only from your own registry

  APS-73

  Install packages with internal names only from your private registry. The public registry must never be able to answer for them.

• Publish what is in each release

  APS-75

  Make a software bill of materials for every release, and sign where and how the build was made.

• Treat a machine that installed a bad package as breached

  APS-76

  When a package version you installed is reported malicious, treat every laptop and build server that installed it as breached. Rotate every credential those machines could read.

• Use models and data from trusted sources

  APS-77

  Load models, adapters and training or search data only from sources you have reviewed, pinned by version or hash.

• Build releases at SLSA Build Level 2 or higher

  APS-104

  Build every release on a hosted build platform that generates and signs its provenance, which is SLSA Build Level 2. Aim for Build Level 3 for software that other people install.

• Verify signatures and provenance before you install or deploy

  APS-105

  Check the signature or provenance of every package and container image before it runs, where the publisher offers one. Deploy only images signed by your own build.

• Say which known holes do not affect you with VEX

  APS-106

  A scanner may report a vulnerable package that cannot be exploited in your product. Record a VEX statement for it, with the status not affected and a justification. Suppress findings only through these statements.

Read this with

• Engineering playbook

  Lock, review and verify every package and build step, and publish what each release holds.

• Software choices playbook

  Every package you pick becomes code you run. Keep the tree small, and lock, audit and review each package before it ships.

• Desktop apps and extensions playbook

  Locked dependencies and safe publishing keep a bad package out of your installer.

• Connected devices playbook

  Firmware is built from many third-party parts. Lock and audit them, and keep a bill of materials for every release.

• Open source maintenance playbook

  Your project is someone else's dependency. Publish without stored tokens, keep secrets from fork builds and ship a bill of materials.