How do you record forks and patched open source in an inventory?
Record the upstream project and version, the fork commit and a list of local changes. Without that, a patched library cannot be matched to advisories.
Deep dives, practical guides, and incident analyses from engineers who build Safeguard. No fluff, no vendor FUD — just what you need to ship secure software.
Record the upstream project and version, the fork commit and a list of local changes. Without that, a patched library cannot be matched to advisories.
Radio stacks and driver blobs arrive as binaries with no package manager. Here is a field by field way to record them so you can answer advisories later.
Source and image SBOMs for the same release rarely match exactly. Diff them, explain each gap, and publish one record that says which one you stand behind.
oss-security is a public list where projects, distributors and researchers discuss open source security issues. Here is what it carries and how to use it.
Publish exact version releases first, move the major tag only from a protected workflow, and know that immutable releases block force pushing tags.
SSDF PS.3.2 asks you to collect and share provenance data for each release, for example in an SBOM. A practical routine for producing and storing one.
Use your SBOM to list every product and service that uses a library, see which ones pull it in indirectly, and sequence a major upgrade by blast radius.
Pin a Hub model by passing a full commit hash as the revision, so your code stops picking up changed files. Steps, a code sample and a review habit.
Use npm overrides or Yarn resolutions to force a fixed version of a nested package before the parent updates. How to scope them and when to remove them.
Weekly insights on software supply chain security, delivered to your inbox.
Your first fix PR is minutes away.
No sales call required, even your agent can complete the purchase over MCP.