A safe open source workflow has three stages: source a package using evidence about the project, secure it with checks before it enters your build, and fix quickly when an advisory lands. Each stage needs a rule your tooling can enforce, so it does not rely on memory.
Stage 1: how do you source a package well?
Before adding a dependency, ask whether you need it, and whether the project looks maintained. The OpenSSF Scorecard project automates checks on a repository's security posture and can run as a GitHub Action or from the command line, so you can assess a repository you do not own. Treat a low score as a prompt for a human look, not a verdict.
Also check what the package pulls in. A small library can bring in dozens of transitive dependencies. Record the decision: who added it, why, and which alternatives were considered.
Stage 2: how do you secure what enters the build?
Pin versions with a lock file so that a build tomorrow uses what you tested today. Prefer exact digests for container images over moving tags. This matters in practice: in the April 2026 KICS incident, reports say malicious Docker image tags such as latest and specific version tags were live for a short window, and a digest pin taken before then would not have moved.
Verify provenance when the ecosystem offers it. SLSA Build L2 means signed provenance generated by a hosted build platform, which lets you check that an artifact came from the expected build.
Generate an SBOM at every build, so you can later answer "where is this used?" The 2026 minimum elements recommend a new SBOM for each release.
Stage 3: how do you fix fast?
Fast does not mean everything. Sort by evidence. The CISA KEV catalog marks flaws seen exploited, and EPSS gives a daily probability of exploitation in the next 30 days. Add reachability: is the vulnerable code called in your application?
Then make the fix cheap. Dependency update pull requests with tests attached turn a day of work into a review.
What does it look like end to end?
Constructed example: a team wants a YAML parsing library. Scorecard on the candidate shows no branch protection and no signed releases, so the team picks the other candidate. The build pins both direct and transitive versions and writes an SBOM. Three weeks later an advisory names a transitive dependency. The SBOM search finds two services. Reachability shows one never calls the flawed function. The other gets a fix pull request, tests pass and a reviewer merges it that afternoon.
How do you keep the workflow from slowing developers down?
Put the checks where developers already work. A short intake form in the pull request template, a Scorecard run in CI, and a dependency review step that comments on the diff cost minutes. A separate approval board costs weeks, and people route around it.
Also allow fast paths. Adding a well known library already used by three other services needs less review than adopting a single maintainer project with no releases in two years. Write the rule down so the fast path is explicit, and developers stop guessing which path applies.
What to do
- Add a short intake checklist for new dependencies: need, maintenance, transitive count, Scorecard result.
- Commit lock files and pin container images by digest.
- Generate and store an SBOM on every build.
- Rank advisories by KEV, EPSS and reachability.
- Allow automated update pull requests, with tests and a human reviewer.
- Set a target time to fix reachable, exploited flaws and track it.
Safeguard covers SBOM and dependency scanning, reachability analysis, policies and gates, and autonomous remediation with fix pull requests off by default. Gold has a free in-browser scan at gold.safeguard.sh/scan for up to 100 dependencies.
What about packages you already use?
Run the same intake on your existing dependencies, starting with the ones that have the most transitive reach or sit on a sensitive path such as authentication, parsing untrusted input or build tooling. You will find abandoned projects and single maintainer libraries. Replace the worst few, and add the rest to a watch list with a named owner, so a change in maintenance status prompts a review instead of surprising you in an incident.
Quick check
Is a high Scorecard result a guarantee?
No. It reports on practices that can be checked automatically. It cannot see malicious intent or a compromised maintainer.
Should every update be applied immediately?
No. Apply urgent fixes for reachable, exploited flaws first and batch the rest.
Sources
- OpenSSF Scorecard
- SLSA specification v1.0: levels and tracks
- CISA, 2026 Minimum Elements for a Software Bill of Materials (SBOM)
- CISA Known Exploited Vulnerabilities Catalog
- FIRST: Exploit Prediction Scoring System (EPSS)
- Checkmarx KICS compromise analysis (Stéphane Robert, April 2026)
Last reviewed: 18 October 2026.
