What should you record about how a monorepo SBOM was generated?
An SBOM is only as trustworthy as its method. Record the tool, version, scan root, lockfile state and date so a reader can judge how complete it is.
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.
An SBOM is only as trustworthy as its method. Record the tool, version, scan root, lockfile state and date so a reader can judge how complete it is.
Read the runs block first: it shows whether an action runs Node, a container, or shell steps. A short checklist for vetting a GitHub Action in minutes.
Renewal is a natural checkpoint. Ask for a current SBOM, any VEX statements, a summary of changes since last year, and the update commitment going forward.
Pin the interpreter, every package with hashes, JVM coordinates, OS packages, the base image digest and tool versions. A table of layers and what drifts.
An expired key is a planned event, not an emergency. Extend or replace it, publish the new fingerprint in several places, and tell users before the date.
No lockfile means versions float at build time. Inventory the built artifact instead, record the gap, and plan to pin dependencies after close.
A checklist for when an academic open source tool goes quiet: how to judge the risk, what signals to check, and when to fork, replace or isolate.
When a mobile SDK stops getting updates, decide between replace, fork, freeze or remove. Signals to watch, a decision table and a timeline you can follow.
Verifying provenance means more than a valid signature. The SLSA steps to follow and the fields to compare against expected values before deploying.
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.