Refresh your open source inventory with every release, and on a fixed schedule between releases. An inventory is a snapshot. New dependencies get added, new advisories are published against old ones, and projects change their licenses. After a deal closes, the buyer inherits that drift unless someone is watching it.
What changes after the snapshot
- Dependencies move. Each merged change can add or upgrade a library.
- Advisories arrive. A version clean on Monday can have a known flaw on Friday.
- Licenses change. Projects sometimes relicense. See dependency changed its license.
- Upkeep fades. A project can be abandoned without notice.
Three triggers
| Trigger | Why |
|---|---|
| Every release | Records what shipped, for notices and for later questions |
| Every dependency change | Catches new licenses before they merge |
| A schedule such as weekly | Catches new advisories on code that has not changed |
The first two belong in CI. The third is a scheduled job that rescans stored inventories and alerts on new findings.
Gate at the pull request
The cheapest place to deal with a new license is before it merges. A rule that blocks denied licenses and flags review ones keeps the inventory clean as it grows. The effort is small compared with unpicking a library after release.
For the first ninety days after closing
A buyer integrating a new product usually wants a fresh inventory on day one, and a repeat once the team has been merged. Compare the two and look at what changed. See security integration plan after an acquisition.
Steps
- Generate an SBOM in CI on each release build and store it.
- Run a license check on pull requests that change dependency files.
- Schedule a rescan of stored SBOMs for new advisories.
- Route new findings to an owner with a due date.
- Keep a log of decisions so a later reviewer can see the history.
What not to do
Do not rely on a single pre deal audit as the record. Do not let alerts pile up without an owner. A short list with named owners beats a long list nobody reads.
Safeguard supports policies, gates and guardrails, so a team can decide which findings block a pull request and which only warn. A free scan is available if you want to see your own dependency list first.
Try it yourself
Open the continuous monitoring demo and watch how a new advisory appears against something already shipped. Look at how it is routed.
Click through it at your own pace, or open it full screen.
Quick check
Is weekly the right schedule?
It depends on your risk and how fast you ship. Choose a rhythm you can keep, and trigger extra scans for major advisories.
Do I need to rescan code that has not changed?
Yes for advisories, since new vulnerabilities are published against old versions.
Last reviewed: 19 October 2026.
