Safeguard is listed in OWASP's Component Analysis page: how to evaluate SCA tools

Safeguard is now listed among software composition analysis (SCA) tools on OWASP's Component Analysis page, the community reference that explains what component analysis is, which risk factors it covers and what an organization's open source policy should contain. The listing is a line in a table, not an endorsement: the same page states that OWASP does not endorse or recommend commercial products or services. What makes the page worth reading is everything above the table, because it is one of the clearest vendor neutral descriptions of what an SCA tool is supposed to do.

This post records the listing, then uses the OWASP page as a checklist: what component analysis covers, how to test an SCA tool against each risk factor, and how Safeguard handles each one according to docs.safeguard.sh. The evaluation sections work against any product, including ours.

Key takeaways

• The news. Safeguard (owner: Safeguard.sh Inc; licence: Commercial / Freemium; platforms: Cross Platform / SaaS) is listed in the Tools Listing table on OWASP's Component Analysis page.
• What the listing means. The page includes a table of tools. Its footer says OWASP does not endorse or recommend commercial products or services. Treat the list as a starting set for your own evaluation, which is what the rest of this post helps you run.
• What component analysis covers. OWASP defines component analysis as identifying potential areas of risk from third party and open source software and hardware components, a function within Cyber Supply Chain Risk Management (C-SCRM). SCA is the software only subset.
• What OWASP says matters most. An accurate component inventory comes first, because without it the other risk factors "become impractical to determine with high confidence." Known vulnerabilities, licenses, inherited (transitive) risk, provenance, SBOM standards and component identification with Package URL follow.
• How to evaluate. Compare inventory against what your package managers resolve, then test transitive paths, SBOM export and import, VEX, licenses and time from finding to merged fix.
• How Safeguard does it. Per its docs: direct and transitive resolution from manifests and lockfiles, CVE and GHSA matching with EPSS and KEV, full dependency paths, reachability, license policy, CycloneDX and SPDX SBOMs, CSAF and VEX upload, and fix pull requests.

What exactly was listed?

The Component Analysis page includes a section called Tools Listing. It is a four column table: Name, Owner, Licence and Platforms. Safeguard's row reads:

The name links to safeguard.sh. The table carries no rating, score or ranking. The page footer is explicit that "OWASP does not endorse or recommend commercial products or services, allowing our community to remain vendor neutral."

That is how we describe it too: Safeguard is listed among SCA tools on OWASP's Component Analysis page. The table gives readers names to evaluate; the rest of the page gives them the yardstick.

The "Commercial / Freemium" label reflects how Safeguard is offered: the platform is a commercial product, and parts of it are free to use. Gold Open Source gives free CVE intelligence with affected and fixed versions without a login, and the Safeguard plugin and skills repository at github.com/Safeguard-sh/safeguard is open source under Apache-2.0. The platform itself is commercial, not open source.

What does OWASP's Component Analysis page say component analysis is?

The page, authored by Steve Springett, opens with a premise most engineering leaders will recognise: modern software is "assembled using third-party and open source components, glued together in complex and unique ways, and integrated with original code." Its point is about responsibility: by using open source components, organizations "ultimately take responsibility for code they did not write."

From there it gives a definition worth quoting in full:

Component Analysis is the process of identifying potential areas of risk from the use of third-party and open-source software and hardware components. Component Analysis is a function within an overall Cyber Supply Chain Risk Management (C-SCRM) framework. A software-only subset of Component Analysis with limited scope is commonly referred to as Software Composition Analysis (SCA).

Three things follow for an evaluation.

First, it is about risk, not only vulnerabilities; matching versions to CVEs is one part of the job. Second, it sits inside C-SCRM, the discipline NIST describes in SP 800-161 Rev. 1, so procurement, legal and risk owners need to use the output too. Third, SCA is the software only subset, so hardware sits outside most SCA tools.

The page also states a simple rule of scope: "Any component that has the potential to adversely impact cyber supply-chain risk is a candidate for Component Analysis."

The risk factors OWASP lists, and what each means for an SCA tool

Most of the Component Analysis page is a list of "Common Risk Factors." Read together, they are a requirements list. Here is each one in plain terms; the test plan further down turns them into checks.

Component inventory

OWASP calls an accurate inventory "pivotal for risk identification" and warns that without it, other factors "become impractical to determine with high confidence." It names dependency management solutions and SBOMs as aids to building the inventory.

Component age and outdated components

The page notes that acceptable component age depends on the component type, its ecosystem and its purpose, and that older components "may have a higher probability of being passed over by security researchers." It says end of life and end of support components "also impact risk," and points out that with Semantic Versioning, API changes are expected between major versions and rare in minor and patch releases. Keeping components current "can reduce remediation time when a rapid response is warranted."

Known vulnerabilities

OWASP makes a point that many teams miss. Historically, known vulnerabilities meant CVE entries in the NVD, but "having a known vulnerability doesn't require the vulnerability information be present in one of these sources." Anything documented, in a defect tracker, a commit log or release notes, counts as known. The page adds that component analysis "will commonly identify known vulnerabilities from multiple sources of vulnerability intelligence."

Component type and component function

Frameworks and libraries carry different upgrade risk. The page contrasts swapping a logging library, which "can likely be automated," with replacing a web application framework, which "would likely be a high-risk endeavor." It also suggests looking at what each component does, because an application is unlikely to need "multiple XML parsers or cryptographic providers," and minimising duplicates reduces risk.

Component quantity

More components mean more operational and maintenance cost, and OWASP notes that the effect is larger in micro module ecosystems "when there are hundreds or thousands of applications in a given environment."

Repository trust

The page lists threats against public repositories: typosquatting, organization or group abuse (including dependency confusion and namespace confusion), malware through transfer of a project between maintainers, and cross build injection. It describes private repositories and "golden repositories containing vetted or permitted components" as a common response. Note the difference between a report written after an install and a gate that stops the install.

Provenance, pedigree and formulation

OWASP defines provenance as "the traceability of all authorship, build, release, packaging, and distribution across the entire supply chain," which in physical supply chains is the chain of custody. Pedigree describes lineage, including "the commits, patches, and diffs which make a component unique," and formulation describes how a component was built.

License

OWASP says component analysis "can identify the license(s) for a given component and may optionally provide guidance as to the nature of the license," and that conflicting licenses "can create serious risk to the business."

Inherited risk

This is where tools differ most. A transitive dependency exists when your application depends on a component that depends on another. Transitive dependencies "have their own risk which is inherited by every component and application that relies on them." The page also makes a practical point: in some ecosystems only direct dependencies can be changed (a pom.xml declares direct dependencies; lock files such as package-lock.json "may be more flexible"), so "it would be most impactful to focus on identifying the direct dependency fix."

Project health

OWASP lists quality controls and metrics, community engagement and vulnerability history as factors in deciding whether to trust an open source project.

External services

Applications and their components may rely on external services, and OWASP says "external services should be included in the overall inventory of components." CycloneDX has a services element for exactly this.

SBOM, component identification and software verification

The page names CycloneDX and SPDX as SBOM standards, each with "their own strengths and use-cases," and says evaluating which applies to your requirements "should be part of an overall C-SCRM strategy." On identity, it explains why CPE names often "do not reflect reality," mentions SWID tags, and recommends the Package URL (purl) specification as "a decentralized and uniform way to represent components," with the form scheme:type/namespace/name@version?qualifiers#subpath. For verification it names two standards: OWASP's Software Component Verification Standard (SCVS) and SLSA.

OWASP's recommendations, as a policy checklist

The page closes its main body with an "Open Source Policy" section and a list of recommendations. Paraphrased, with what a tool needs to support each:

If you take one thing from this post, take this table into your next tool evaluation. It starts from the outcome a policy owner needs, not from a vendor's feature list.

How to evaluate an SCA tool: a practical test plan

A trial on a demo repository tells you little. This plan takes about a week with one or two engineers and produces evidence you can compare across tools.

1. Inventory accuracy: compare against ground truth

Pick three repositories you know well: one JavaScript or TypeScript service with a lockfile and workspaces, one Java service built with Maven or Gradle, and one Python service. Add a container image you build yourself.

Build the ground truth with the ecosystem's own tools, which resolve exactly what installs:

# npm: the resolved tree, including transitive packages
npm ls --all --json > npm-tree.json

# Maven: the resolved dependency tree
mvn dependency:tree -DoutputType=text -DoutputFile=maven-tree.txt

# Python with pip: what is actually installed in the environment
python -m pip list --format=json > pip-installed.json

# Go: every module in the build list
go list -m all > go-modules.txt

Run each candidate and count matches, misses and extras. Misses usually come from unread lockfiles, ignored workspaces, vendored code or packages that exist only in the image. Extras usually come from reporting manifest ranges as if they were versions.

2. Transitive depth and path: can you trace why a package is there?

Pick a vulnerable package several levels deep. Does each tool find it, show every path from your project root, and name the direct dependency to change? In Maven that usually means a direct bump or a dependencyManagement override; in npm, a parent bump or an overrides entry. "Upgrade the vulnerable package" without a path leaves the hard part to the developer.

3. Ecosystem and artifact coverage

List the package managers, lockfile formats and artifact types you actually ship, including monorepos, private registries, container images and vendor SBOMs, and check each tool against that list rather than its marketing page.

4. SBOM formats: export, validate, import

Export CycloneDX and SPDX from each tool and validate both against the schema. Each component needs a purl, version, supplier where known and license, with dependency relationships, not a flat list. Check the fields against CISA's 2026 Minimum Elements for an SBOM. Then import an SBOM produced elsewhere and confirm it is analysed like a native one.

5. VEX: does it change the findings?

A Vulnerability Exploitability eXchange (VEX) document states whether a product is affected by a vulnerability (not affected, affected, fixed or under investigation), with a justification for "not affected." CISA publishes minimum requirements for VEX, and VEX can be written in CSAF, CycloneDX or OpenVEX. Import a statement for one of your findings and check that the status changes, the justification shows and the decision is kept with its history.

6. Prioritisation: what reaches the top?

OWASP says to update components "exploitable with high to moderate risk first." Useful ranking signals are CISA's Known Exploited Vulnerabilities catalog (has it been exploited), FIRST's EPSS (how likely is exploitation in the next 30 days) and reachability (does your code call the vulnerable function). Ask what happens when the analyzer cannot decide; the safe answer is that the finding stays visible. Measure noise reduction on your own repositories rather than taking any vendor's figure, ours included.

7. License data and policy

Pick a transitive dependency with a copyleft license and check that each tool finds it, names the license with an SPDX identifier, and can block or flag it by policy. Check how the tool handles packages with multiple licenses or no declared license.

8. Remediation: time from finding to merged fix

The test most evaluations skip. Take five real findings and measure the steps and time to a merged fix. Does the tool open a pull request that passes your tests, fix a transitive dependency through the right direct one, and offer anything when no fixed version exists?

9. Continuous monitoring and data handling

Scan once, then wait: check whether each tool re-evaluates existing projects when advisory data changes, without a new commit. Ask what leaves your machine or network, and read the vendor's security attestations.

How Safeguard handles each OWASP risk factor

This section maps the OWASP page to Safeguard using only what its documentation says, with links so you can check each statement.

Inventory: direct and transitive, from manifests and lockfiles

The SCA docs page describes the engine's job as inventorying "every open-source component you ship, direct and transitive," and resolving the complete dependency graph from manifests and lockfiles. Both are honoured, "so resolution matches what actually installs." The documented ecosystems are npm, pnpm and Yarn; PyPI; Maven and Gradle; Go modules; Cargo; NuGet; Composer; Ruby Bundler; and components discovered inside container image layers.

The Deep Dependency Scanning page lists the files resolved for each, from npm workspaces with peer and optional dependencies, through uv.lock and poetry.lock, to go.sum, Cargo.lock and Gemfile.lock, plus package metadata inside container layers.

SBOM generation is covered on the Generate SBOM page. Projects come from GitHub, GitLab, Bitbucket or any Git URL, from container registries, and from uploaded manifests and Android APKs. You choose the branch or tag and whether to include development dependencies.

From a laptop, the Safeguard CLI scans a directory locally. The Generate SBOM page notes that a scan run from the interactive terminal while signed in uploads the SBOM and findings to the platform, and that your source never leaves the machine.

# Install the CLI
curl -fsSL https://cli.safeguard.sh/install | bash

# Scan the current directory, resolving transitive dependencies to a chosen depth
safeguard scan --dir . --resolve-transitive --transitive-depth 100

Inherited risk: the full path, and the fix that goes with it

Each SCA finding, per the docs, carries the vulnerable component and version, the CVE or GHSA identifiers, severity with EPSS and KEV context, "the full transitive path from your project root to the vulnerable package," the reachability verdict where available, and the safe upgrade target.

The Deep Dependency Scanning page describes how the graph is walked. At each node, Safeguard resolves the purl and version against its vulnerability knowledge graph, computes license and provenance, feeds the node into reachability analysis and records the full path from root to leaf. Clicking a finding shows the chain that pulls in the vulnerable package, whether it is reachable, whether another path exists, and the safe version with the other transitive changes it would introduce. That last point is OWASP's: a transitive fix usually lands on a direct dependency, and you want to know what else moves.

Depth is also a policy signal. The docs show rules that act on how deep a vulnerable component sits, or warn when a change makes the tree much deeper than before.

The same page describes a reverse signal that maps to OWASP's "reduce the attack surface by excluding unnecessary direct and transitive dependencies": packages present in your dependency tree but never imported, flagged as candidates for removal.

Known vulnerabilities: multiple sources, continuously re-evaluated

The SCA engine matches every resolved package and version against CVE and GHSA advisories, enriched with FIRST EPSS and CISA KEV so exploited issues rise to the top. That covers OWASP's point that known vulnerabilities come from more than one source of intelligence.

Continuous Scanning handles the "scan once, then wait" test. Safeguard re-scores existing projects when its advisory feeds update, and the Generate SBOM page describes daily continuous scanning of all projects, plus triggers on push, on a schedule and on release.

For quick lookups outside the platform, Gold Open Source gives free CVE intelligence with affected and fixed versions, without a login.

Prioritisation: reachability, KEV and EPSS together

The Vulnerability Prioritization page describes signals that feed one priority score: reachability, exploitability (EPSS and KEV), runtime context and business context. The SCA page puts the reachability part simply: a CVE in code you never call is de-prioritized, not treated the same as a reachable sink.

Reachability is classified as reachable, conditional, unreachable or unknown. The unknown class matters most in an evaluation, and Safeguard's answer is the conservative one. When the analyzer cannot decide, for example because code runs through reflection, dynamic dispatch, eval or native code, the finding is "marked conservatively as potentially reachable" and is not suppressed. Unreachable findings drop to the backlog band of the priority score rather than disappearing. The docs list static and dynamic reachability as GA for JVM languages (Java, Kotlin, Scala), Python, and JavaScript and TypeScript, including CommonJS, ESM and webpack bundles.

How much the ranking reduces your queue depends on your codebase, so measure it on your own repositories during an evaluation. Record the raw count, record the top band, and check by hand whether the top band holds what your engineers would have chosen.

Licenses: across the whole graph

The SCA engine flags license obligations and incompatibilities across the graph, and the Deep Dependency Scanning page computes license data at every node, so transitive licenses are included.

The License Compliance page reconciles several sources: package metadata, SPDX identifiers, full text matching of LICENSE, COPYING and NOTICE files, source headers, and copyright files in container layers. When they disagree, for example package.json says MIT while the LICENSE file is AGPL, Safeguard raises a license discrepancy finding.

Licenses are classified by obligation (permissive, weak, strong and network copyleft, proprietary, public domain, unknown), and full SPDX expressions such as MIT OR Apache-2.0 are evaluated correctly. OWASP's allow list, deny list and ask counsel recommendation maps to a YAML policy with a require_review list, which can be scoped so a distributed SDK follows stricter rules than a service:

apiVersion: safeguard.sh/v1
kind: LicensePolicy
metadata:
  name: default
spec:
  allow: [MIT, BSD-2-Clause, BSD-3-Clause, Apache-2.0, ISC, MPL-2.0]
  deny: [GPL-3.0-or-later, AGPL-3.0-or-later, SSPL-1.0]
  require_review: [GPL-2.0-only, LGPL-3.0-or-later, "Custom/*"]

Policies are enforced in CI (a build fails if a denied license appears in the dependency tree), at admission (an image with a denied license cannot deploy to production) and at pull request time (a new direct dependency with a denied license gets a blocking check). For redistributed artifacts it generates NOTICE files and an SPDX document per release, and the same classification runs on vendor SBOMs. See also Suppliers and Licenses.

SBOMs: generate, explore, import and request

Safeguard generates SBOMs from source, containers and uploads, and lets you explore an SBOM with a dependency tree showing depth, and a table with license and last updated date. Exports include SPDX (JSON, XML, RDF) and CycloneDX (JSON, XML), plus CSV, Excel and PDF for people who do not read SBOMs.

Safeguard also imports SBOMs you already have. The docs list full support for CycloneDX 1.3 to 1.6 in JSON and XML, and SPDX 2.2 and 2.3 in JSON, tag-value and RDF. Imported SBOMs are validated for format and schema, enriched with vulnerability data, monitored for new vulnerabilities over time and can be converted between formats. That covers OWASP's recommendation to "import SBOMs into systems capable of tracking, analyzing, and proactively monitoring all components." For third party software, Third Party Risk Manager can request SBOMs from vendors, which is the "contractually require SBOMs from vendors" item turned into a workflow.

VEX: upload and act on exploitability statements

The CSAF and VEX upload page lists the supported formats: CSAF 2.0 (the OASIS standard), CycloneDX VEX, OpenVEX and the CSAF VEX profile, all as JSON. Uploads are validated against the schema and attached to a project and version. The documented uses: mark vulnerabilities as not affected, document mitigation status, track exploitability assessments and reduce false positives.

A minimal OpenVEX statement of the kind the docs show looks like this, with the component identified by its purl, which is the identifier OWASP recommends:

{
  "@context": "https://openvex.dev/ns/v0.2.0",
  "@id": "https://example.com/vex/2026/001",
  "author": "Example Corp",
  "timestamp": "2026-10-28T00:00:00Z",
  "statements": [
    {
      "vulnerability": { "name": "CVE-2026-00000" },
      "products": [ { "@id": "pkg:npm/example-package@1.0.0" } ],
      "status": "not_affected",
      "justification": "vulnerable_code_not_present"
    }
  ]
}

A Mitigations tab holds risk acceptances with expiry dates and false positive markings beside VEX decisions. The framework library includes a CycloneDX VEX framework and an internal VEX readiness framework for checking how well your exploitability statements cover your findings.

Component age and outdated components

Safeguard's framework library includes an internal Dependency Age framework, on by default in a workspace, which flags components older than two years as stale and older than four years as very old. Its controls include abandoned project detection, end of life tracking and major version lag, which line up with OWASP's age, outdated components and project health factors. OWASP suggests three years; set your policy to the limit you choose.

Component function and quantity: find the duplicates

OWASP suggests standardising on one component per function and reducing the number of components overall. The internal Duplicate Components framework identifies components present at more than one version, which usually means an unresolved dependency conflict or a stale transitive dependency. Together with the unused dependency signal from deep scanning, it gives you a list of components to consolidate or remove.

Repository trust: control what installs

The Package Firewall sits in the install path, evaluating each package as it is fetched, and may block malicious, typosquatted and dependency-confusion packages. That maps to OWASP's repository trust threats and its advice to cap the risk you accept from public repositories.

OWASP's "golden repositories containing vetted or permitted components" idea is the subject of the Gold section below.

Provenance and verification

The Deep Dependency Scanning page computes provenance at each node. On the project overview, a Provenance tab records the source repository, the build system, commit information and build timestamps for components, which is close to OWASP's description of provenance and formulation. Safeguard's Attestation and Signing capability covers signing artifacts and recording where they came from, the evidence SLSA formalises.

Remediation: from finding to pull request

The AI Remediate page covers how Safeguard turns a finding into a fix with Griffin, Safeguard's security model. It analyses the vulnerability and your code, picks the safest upgrade path, assesses breaking changes, opens a pull request and runs your tests. For dependencies that includes handling transitive conflicts and updating lock files, the direct dependency fix OWASP asks for. You can fix one vulnerability, batch several into one pull request per repository, or approve a plan for every fixable finding.

Each change is rated safe, minor, major or critical for breaking risk, and settings decide whether safe fixes open pull requests automatically, whether approval comes first and whether tests run before a pull request opens. The docs' advice suits an evaluation: enable tests, start with safe fixes and never auto-merge breaking ones.

CI, policy and where it runs

SCA runs as part of a project scan, from CI, the CLI or on a schedule. Policies and gates turn the OWASP open source policy into rules: block known vulnerable versions, deny licenses, warn on deep or old components. The CLI and the local runner let a team scan on its own machine first, which is useful in an evaluation before you grant repository access. For security attestations, Safeguard is SOC 2 Type I and Type II audited, with reports available on request through the Trust Center.

Side by side: OWASP risk factor, evaluation test, Safeguard docs

Common mistakes when choosing an SCA tool

Evaluating on a demo repository. Every tool looks good on its own sample. Use your repositories.

Ignoring the path. A finding without a dependency path turns a five minute fix into an afternoon of npm ls and mvn dependency:tree.

Treating SBOM export as a checkbox. An SBOM without purls, versions, licenses and relationships does not meet current minimum elements. Validate it.

Skipping VEX. Without VEX, every customer question about a CVE that does not affect you becomes a manual email thread. Check that VEX changes findings, not only that a file can be uploaded.

Accepting a vendor's noise reduction number. How much ranking helps depends on your code. Measure it.

Stopping at detection. OWASP recommends automating component updates. A tool that leaves every fix to a ticket grows the backlog.

FAQ

Is Safeguard recommended by OWASP?

No. Safeguard is listed among SCA tools on OWASP's Component Analysis page. OWASP states that it does not endorse or recommend commercial products or services.

What is OWASP's Component Analysis page?

An OWASP community page, authored by Steve Springett, that defines component analysis, lists common risk factors and recommends an open source policy. It lives at community.owasp.org/Component_Analysis.

What is the difference between component analysis and SCA?

OWASP describes software composition analysis as the software only subset of component analysis, with limited scope. Component analysis also covers hardware.

How do I evaluate SCA tools?

Run each candidate on your own repositories, compare its inventory with what your package managers resolve, then test paths, SBOMs, VEX, licenses, ranking and time to a merged fix.

Which SBOM format should I use, CycloneDX or SPDX?

OWASP's page says both have their own strengths and use cases and that choosing should be part of your C-SCRM strategy. Many organizations need both. Pick a tool that exports both and uses Package URL identifiers.

What is VEX and why does it matter for SCA?

VEX is a machine readable statement of whether a product is affected by a vulnerability. It tells customers and your own tools, with a justification, that a CVE does not affect your product.

Why does transitive dependency depth matter?

OWASP notes that transitive dependencies carry their own risk, inherited by every component and application that relies on them. A tool must resolve the whole graph and show the path, so you can fix through the right direct dependency.

Does Safeguard support my package manager?

Per its docs, Safeguard's SCA supports npm, pnpm and Yarn, PyPI, Maven and Gradle, Go modules, Cargo, NuGet, Composer and Ruby Bundler, plus components inside container image layers. Check the CLI support matrix for local scans.

Why fixing still matters after the inventory is right

An accurate inventory and a well ranked queue tell you what is wrong. OWASP's recommendations go further: prohibit components with known vulnerabilities, automate updates and prefer vetted repositories over untrusted ones. That is remediation work, and it is where most SCA programs stall.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Griffin, Safeguard's security model, opens a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Safeguard Gold rebuilds patched versions of open-source packages and images from source, signs each build, attaches an SBOM, SLSA provenance and VEX, and serves them from registry.safeguard.sh to your organization. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

These demos show the SCA flow from inventory to fix.

The first demo shows every open source component in a project, direct and transitive, with its depth, license and vulnerabilities, and traces where each one comes from. It is the inventory accuracy, transitive path and license tests from this post, run on Safeguard, so you can see what the output looks like before you compare it against your own ground truth.

Click through it at your own pace, or open it full screen.

The second demo is a real Safeguard CLI session. A developer asks the assistant to fix a lodash CVE; it reads the finding and advisory, asks before any command that changes something, updates the dependency, runs the install and tests with approval, prints a summary and pushes nothing. It is the remediation test: time from finding to a working fix.

Click through it at your own pace, or open it full screen.

The third demo sets up the local runner on your own machine, approves it with its device code, then scans from the terminal. During an evaluation, it lets a team build Safeguard's inventory for the comparison against ground truth without granting repository access first.

Click through it at your own pace, or open it full screen.

To try Safeguard yourself, download the apps or start with the CLI documentation.

Quick check

Sources

• OWASP: Component Analysis
• Safeguard docs: Software Composition Analysis (SCA)
• Safeguard docs: Deep Dependency Scanning
• Safeguard docs: Generate SBOM
• Safeguard docs: Explore SBOM
• Safeguard docs: Existing SBOM import
• Safeguard docs: CSAF and VEX upload
• Safeguard docs: Vulnerability Prioritization (Reachability Analysis)
• Safeguard docs: AI Remediate
• Safeguard docs: License Compliance
• Safeguard docs: Continuous Scanning
• Safeguard docs: Package Firewall
• Safeguard docs: Safeguard CLI
• Safeguard docs: Dependency Age framework
• Safeguard docs: Duplicate Components framework
• OWASP: Software Component Verification Standard
• CycloneDX specification
• SPDX
• Package URL specification
• CISA: 2026 Minimum Elements for an SBOM
• CISA: Minimum Requirements for VEX
• OASIS: CSAF 2.0
• OpenVEX
• CISA: Known Exploited Vulnerabilities Catalog
• FIRST: EPSS
• NIST SP 800-161 Rev. 1
• SLSA
• Semantic Versioning
• npm: npm ls
• Apache Maven: dependency:tree

Last reviewed: 28 October 2026.