The TODO Group's guide describes a five-stage process for approving open source use: scan the code, identify and resolve issues, legal review, architecture review, and final review. Scanning and ticket routing automate well. Legal, architecture and the final decision still need people.
The five stages
The guide presents these as an illustration and says real life is more iterative. Here is each stage and our view on automation.
| Stage | What happens | Automate? |
|---|---|---|
| 1. Scan | A tool scans the code and reports components, licenses, conflicts and unidentified files | Yes |
| 2. Identify and resolve | The compliance officer works through flagged files and assigns subtasks to engineers | Partly |
| 3. Legal review | Counsel reviews scan reports and license files and decides on incoming and outgoing licenses | No |
| 4. Architecture review | Compliance and engineering examine how open source, proprietary and third-party code interact | Partly |
| 5. Final review | The review board approves or rejects using the full record | No |
Stage by stage
Scan. The guide says the scan usually starts when an engineer submits a usage form, which creates a ticket and a scan request. The report lists known components (effectively a bill of materials), licenses and obligations, conflicts for legal to check, file inventory and code matches. All of this is machine work.
Identify and resolve. If a scan flags conflicting licenses, the compliance officer creates subtasks with a description, a proposed fix and a deadline. A re-scan can confirm the issue is gone. Automation can open the tickets and track the deadlines, but someone still decides what counts as resolved.
Legal review. Counsel receives the scan report, the license files and engineer comments, and produces an opinion plus a decision on incoming and outgoing licenses. This is the stage to keep human. This post is not legal advice and your counsel decides how to apply it.
Architecture review. The guide describes examining a diagram that shows open source components, proprietary components, supplier components, dependencies and how they communicate, for example through sockets or linking. Tools can draw the dependency graph. People judge what the connections mean.
Final review. The guide says most components that reach this point are approved unless something has changed, such as the component no longer being used. After approval, the compliance officer lists obligations for other teams, such as updating the inventory and end-user notices.
What to build first
Start with stages one and two. A scan that runs on every pull request and opens a ticket for each flagged item removes the slowest manual work. Then add a simple request form so reviewers get the same fields every time. See open source intake request form fields.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how components, versions and licenses are listed, which is the raw material for stage one.
How Safeguard fits
Safeguard provides SBOM and dependency scanning, policies and gates, and compliance and evidence automation. That covers the scan and tracking work, while review decisions stay with your people. Try gold.safeguard.sh/scan for a free first look.
Quick check
Does every dependency need all five stages?
Not necessarily. The guide says the phases may be modified to fit your company. Many teams use a fast path for low-risk, common licenses and the full path for unusual cases.
Who runs the final review?
The guide describes the auditing team or open source review board, usually a meeting that approves or rejects use.
Sources
Last reviewed: 19 October 2026.
