Write it in five parts: the problem in your own measured terms, the options considered, the recommendation, the risks and a review date. Keep it to one page and base every claim on something you counted, such as hours, repositories or open findings, never on borrowed statistics.
Why a memo helps
Moving off free tools is a budget and ownership decision, so someone outside engineering will ask why. A short written memo makes the reasoning reviewable and stops the decision from being rebuilt from memory in six months.
The five sections
1. The problem, in numbers you own. State what is not working today. Use counts from your own systems: repositories covered and not covered, findings open past your target, hours per month spent maintaining scanner configuration, number of audit or customer requests you could not answer quickly. If you do not have a number, say so and say how you will get it.
2. What we tried and what it costs. List the open source tools in use and what each covers. Include the people time to run them, since free software still has an owner. Our guide on how much engineer time open source scanners take shows one way to count it.
3. Options considered. At least three, one of them being to stay as you are.
| Option | What it gets us | What it leaves us with |
|---|---|---|
| Stay on current tools | No change | Gaps listed in section 1 |
| Add more open source tools | Wider coverage | More triage and config work |
| Move to a platform | One inventory and workflow | Vendor dependence, migration work |
4. Recommendation and plan. Say what you propose, who owns it, and the rollout in phases. Include a shadow period where the platform runs beside current tools, with an agreed measure of success such as parity on a sample of repositories.
5. Risks and exit. Name them honestly: data export, lock in, cost of switching later, and what happens if the pilot fails. Our note on exit plans and data portability helps here.
A worked skeleton
Copy and fill in:
Decision: Move dependency and container scanning to a platform
Owner: (name) Decision date: (date) Review date: (date)
Measured problem: (three counts from our systems)
Options: stay / add tools / platform (table above)
Recommendation: platform, pilot on N repositories, shadow for N weeks
Success test: (what must be true to proceed)
Risks: (export, lock in, migration effort)
Exit: (how we leave and what we keep)
Try it yourself
Click through the inventory demo to see what a single dependency view looks like. Look for what you would need to answer a customer question about one package.
Click through it at your own pace, or open it full screen.
Where Safeguard fits
If a platform is the outcome, Safeguard covers SBOM and dependency scanning, reachability analysis, policies and gates, and compliance evidence. A free scan at https://gold.safeguard.sh/scan on one of your repositories gives you real data for section 1 of the memo.
Quick check
Should the memo include a price comparison?
Include costs your finance team asks for, but keep this memo about the problem and the plan. Quote only figures you have in writing.
Who should sign it?
The budget owner and the person accountable for the risk, usually the head of engineering and security.
Last reviewed: 19 October 2026.
