A dependency scanning PoC charter is a one page agreement written before the trial. It states the goal, repositories in scope, people and roles, pass marks, data and access rules, dates, and what happens at the end. If it does not fit on one page, the PoC is probably too big.
Why a charter helps
Trials drift. Scope grows, dates slip, and nobody remembers what "success" meant. A charter is cheap insurance. It also gives the vendor a clear target, which tends to make their support more useful.
Keep it plain. Nobody reads a ten page trial plan.
The outline
Copy this and fill it in.
1. Goal. One sentence. Example: decide whether this scanner should replace our current dependency checks for our three main services.
2. Scope. List repositories by name, languages and package managers, and anything explicitly out of scope, such as production deployment or auto merged changes.
3. People.
| Role | Name | Time expected |
|---|---|---|
| Owner | ||
| Developer reviewers | ||
| Security reviewer | ||
| Decision maker | ||
| Vendor contact |
4. Pass marks. Link to your criteria table. See success criteria for a PoC.
5. Data and access. What the scanner may read, what leaves the network, what permissions it holds, and who revokes them. Pair this with the questions in what data a scanner sends out.
6. Dates. Start date, mid point check, readout date, final decision date. Ten working days is a good default.
7. Findings handling. Who triages, where real issues go. See who owns what a PoC finds.
8. Exit. The three outcomes: adopt, extend for a named gap, stop. Plus what happens to data and access in each case.
What to leave out
Pricing and contract terms belong in a separate commercial conversation. Keep the technical test clean of them so the result is judged on evidence. Do not paste findings or secrets into the charter.
Who signs it
The decision maker and the owner, at minimum. A short email saying "agreed" counts. The point is a shared record, not a legal document. If your company requires a trial agreement or non disclosure terms for any outside tool, that is a separate step, and your legal team should handle it.
Using the charter during the trial
Open it at the mid point check. For each pass mark, write what you have measured so far. If something in scope turns out to be impossible, such as a repo that will not build, change the charter in writing and note why. That keeps the final comparison fair.
At the readout, the charter becomes the first page of your memo. Every claim in the memo should trace to a line in it.
A worked scope example
Three repositories: a Node API with a committed lockfile, a Java service with several modules, and a Python worker with a requirements file. Out of scope: container images, infrastructure code, and automatic fix pull requests. Dates: kickoff Monday, mid point on day five, readout on day ten. That alone is enough to start.
Try it yourself
Open the demo to see the kind of inventory a scan produces, then decide which of your repositories you would put in scope.
Click through it at your own pace, or open it full screen.
Quick check
Should the vendor see the charter?
Share sections 1 to 6 so they know the test. Keep your internal scoring notes private until the readout.
Can the charter change mid trial?
Yes, in writing, with the reason. Silent changes make results hard to trust.
Safeguard offers SBOM and dependency scanning with reachability analysis, and you can try a free scan at gold.safeguard.sh/scan before you plan a longer test. The CLI, desktop app and IDE extensions are listed on safeguard.sh/download.
Last reviewed: 19 October 2026.
