OSM: Knowing What Is In Your Software Before You Have To Explain It
Ask a security leader how many open-source packages their organization depends on, and you will usually get a shrug followed by a guess. Ask which of those packages have known vulnerabilities, which are unmaintained, which have a hardened alternative available, and the guess gets a lot less confident. That gap, between what a company assumes it knows about its open-source footprint and what is actually true, is where a surprising amount of supply-chain risk quietly accumulates.
OSM, Open Source Manager, is Safeguard's answer to that gap: a product for building and maintaining an accurate, continuously updated inventory of an organization's open-source dependencies, paired with security intelligence on every one of them.
OSM versus Gold: two related things that are easy to conflate
Because OSM and Gold both deal in open-source package data, it is worth being precise about the difference, since the two get confused constantly, even internally.
Gold, at gold.safeguard.sh and registry.safeguard.sh, is a public resource. Anyone can look up any package, free, with no login. It is the same intelligence layer available to the entire developer community, a shared reference point.
OSM is an organization's own product, sitting inside the Safeguard platform rather than in front of it. It holds your company's specific inventory: the actual packages your actual projects actually depend on, not packages in general. It is the "know before you install" layer for your organization specifically, and it is also the front door to Gold from inside your own workflow, surfacing which of your existing dependencies could be swapped for a hardened Gold equivalent.
Put simply: Gold answers "is this package, in general, safe?" OSM answers "what does my organization actually depend on, and which of it needs attention?" You use Gold to check a package before you add it. You use OSM to understand and manage everything you have already added.
What OSM actually shows you
For every package in an organization's inventory, OSM surfaces per-package detail: an attestation score (LCAL, scored 0 to 4), a broader risk score, known vulnerabilities with CVE identifiers, CVSS severity, EPSS exploitation probability, and the version range that fixes each issue, plus attestation and provenance data built on SLSA and Sigstore, a malicious-package scan, and the full dependency tree with version history. Today this spans eight or more ecosystems, including npm, PyPI, Maven, Go, RubyGems, NuGet, Cargo, and Packagist.
Sitting inside OSM is the Gold Directory: the subset of packages, curated from across those ecosystems, that already meet the Gold bar of high attestation, no critical or high severity vulnerabilities, active maintenance, and clean licensing. From inside OSM, a team can identify where a hardened variant already exists and install it directly through the Gold registry, without leaving the workflow to go research it separately.
How OSM connects to the rest of the platform
OSM does not operate in isolation. Projects and products that are actively scanned in ESSCM, Safeguard's flagship supply-chain platform, flow through into OSM for open-source specific analysis, meaning the inventory OSM builds reflects real, current scanning activity rather than a stale snapshot from onboarding. This matters because open-source inventories decay quickly: a dependency that was clean at the start of a quarter is not guaranteed to be clean at the end of it, and an inventory tool that only updates during initial setup is already out of date by the time anyone looks at it.
Why an accurate inventory matters more than it seems
There is a temptation to treat "know what's in your software" as a compliance checkbox, something you do once to satisfy an SBOM requirement and then forget about. That undersells what OSM is actually for. An accurate, current inventory is the foundation that everything else in supply-chain security depends on. You cannot prioritize a vulnerability you do not know you have. You cannot evaluate a hardened alternative for a package you have not identified as a dependency. You cannot answer a customer's or regulator's question about what your software contains if the honest answer is a guess.
OSM exists to replace that guess with an answer, and to keep that answer current as your dependencies change, not just accurate on the day someone ran a one-time audit.
Where this leads
An organization that gets serious about its open-source inventory through OSM naturally ends up asking the next question: for the packages that carry risk, is there already a hardened, zero-CVE replacement? That is exactly the connection OSM is built to make, pointing directly into the Gold Directory and, from there, into Gold Registry's hardened artifacts. For packages where no Gold equivalent exists yet, OSM is also the starting point for requesting one, though that specific fork-and-patch capability is still expanding and best evaluated case by case rather than assumed complete.
Get an honest answer to the question you've been guessing at
If your team has never had a single, current answer to "what open source do we actually depend on, and how much of it is a problem," that is precisely the gap OSM is built to close. Visit safeguard.sh to see what an accurate inventory of your own software actually looks like.
