Before the first service ships in a new language, answer seven questions from its official documentation: how it locks versions, how it checks integrity, whether dependencies run code at install, which audit command exists, how to produce an SBOM, who owns it, and what the CI template is. Write the answers down once and reuse them.
Why do this up front
Adding a language usually starts as a prototype. By the time it is in production, the habits of the prototype are the habits of the service, including an ordinary install step that rewrites the lock and no one watching advisories. Fixing that later means retrofitting a pipeline under pressure.
A one page onboarding record, filled in before launch, costs an hour and spares you most of it.
The seven steps
1. Lock behavior
Find the lock mechanism and the locked install mode. Examples from the official docs: npm has a clean install that errors on drift, Cargo has a locked flag, NuGet has a locked restore mode that needs opting in, and Gradle needs locking activated per configuration. If the ecosystem has no equivalent, record that and choose a compensating control such as exact versions plus an internal mirror.
2. Integrity
Does the installer verify what it downloads? Go does by default against go.sum. pip does only when hashes are present. Record the answer and what you will enable.
3. Install and build time code
Can a dependency run code on a developer laptop or CI agent? npm lifecycle scripts and Cargo build scripts can. Record how to restrict it and which secrets are present in the job.
4. Audit command
Find the native advisory check, and note what it covers. For Go, govulncheck reports whether your code calls the vulnerable function. For npm, the audit command sends your dependency tree to the registry. Decide where it runs and whether it gates.
5. SBOM output
Pick the format, such as CycloneDX or SPDX, and confirm the tool you use can produce it for this language. Do not assume. Test on a real repo.
6. Owner
Name a person or team who answers for updates in that language. Without this, upgrades stall.
7. CI template
Create or extend the shared pipeline template: locked install, audit, SBOM, publish. New services in the language copy it rather than inventing their own.
The record
| Question | Answer to write down |
|---|---|
| Lock file and locked install command | |
| Integrity mechanism | |
| Code runs at install or build? | |
| Audit command and gate level | |
| SBOM tool and format | |
| Owner | |
| Template location |
When the answers are bad
Sometimes the honest answer to a question is "this ecosystem cannot do that". That does not forbid the language. It means the gap needs a named compensating control and a review date. What you should not do is leave the cell blank.
Safeguard can help here: it scans dependencies and generates SBOMs, applies reachability analysis so you can sort findings by what your code can actually call, and enforces policies and gates on pull requests. You can try a free scan on a repository to see what it finds.
Quick check
How long should onboarding a language take?
Much of it is reading the official docs and writing down answers. A first pass is often an afternoon, and the CI template is the longest part.
What if the language has no lockfile?
Record that, pin exact versions where you can, use an internal mirror, and set a review date for the gap.
Sources
- npm ci
- cargo build options
- NuGet PackageReference
- Gradle dependency locking
- Go modules reference
- Go govulncheck tutorial
- npm audit
Last reviewed: 19 October 2026.
