Six events should start an open source review: a usage request from an engineer, a scheduled full scan, a change to a previously approved component, software from a third-party supplier, code downloaded from an unknown source, and a new proprietary component that may contain borrowed code. The TODO Group guide lists all six.
Why triggers matter
Most review programs only handle the first trigger, the request form. That catches the engineers who follow the process. It misses everything else. If a program depends on people volunteering information, the inventory slowly drifts away from what is actually in the product.
The TODO Group's guide on using open source code describes the factors that can trigger a source code scan. Treating that list as a set of triggers gives you a program that finds things as well as processes things.
The six triggers
| Trigger | What it catches | How to detect it |
|---|---|---|
| Usage request form | Planned, declared use | Form submission opens a ticket |
| Scheduled full scan | Open source added without a form | Periodic scan of the whole platform |
| Change to an approved component | A new version or modification of something already approved | Version or license change in the dependency list |
| Third-party supplier software | Open source inside software you received | Supplier SBOM or scan on receipt |
| Download from the web with unknown author or license | Code of unclear origin | Review of new sources in the build |
| New proprietary component | Borrowed open source inside your own code | Scan of new internal modules |
The guide notes that scheduled full platform scans are useful for uncovering open source that crept in without a usage form, and suggests running them every few weeks. It also points out that engineers often start testing one version of a component and later adopt a newer one, which is why a change to an approved component is its own trigger.
Setting up each trigger
Requests. Keep the form short. See open source intake request form fields.
Scheduled scans. Pick a cadence and a person who reads the output. A scan nobody reads is not a trigger.
Version changes. Treat a lockfile or manifest change as an event. A license change between versions deserves a closer look than a patch bump.
Third-party software. Ask suppliers for a bill of materials, and scan what you receive when they will not provide one.
Unknown sources. Make it a rule that code from an unidentified source stops at the review step until its license is known.
Proprietary code. The guide includes new proprietary components in the list because engineering may have borrowed open source without noticing. Scan internal modules too.
What happens after a trigger fires
A trigger should open a ticket with an owner and a due date, not just send a notification. Record the outcome so the next review of the same component can reuse it, but remember the guide's point that approval for one product does not carry over to another.
Try it yourself
Click through it at your own pace, or open it full screen. See how a recurring scan notices a change without anyone filing a request.
How Safeguard fits
Safeguard supports SBOM and dependency scanning and policies and gates, which can act as triggers on pull requests and on schedules. Start with the free scan at gold.safeguard.sh/scan.
Quick check
How often should a full scan run?
The guide says every few weeks. Choose a cadence your team can actually act on, then tighten it as your process matures.
Is a request form enough on its own?
No. It only captures declared use. Pair it with scheduled scans to find what was never declared.
Sources
Last reviewed: 19 October 2026.
