The question we get asked most is simple: why build another security company?
Fair question. The application security market is crowded. There are scanners for your code, scanners for your containers, scanners for your APIs. You can buy dashboards that aggregate findings from a dozen different tools. The surface-level problem -- finding vulnerabilities -- has been addressed by dozens of vendors.
But here is what we kept running into, across multiple organizations, across different industries: nobody actually knew what was in their software.
The Problem That Would Not Go Away
In 2023, we were working on software supply chain security at scale. The executive order on cybersecurity (EO 14028) had created urgency around SBOMs. Customers were being asked by their own customers to produce bills of materials. Government contracts started requiring them. The FDA began expecting them for medical device submissions.
The response from most of the industry was predictable. Tools that could generate an SBOM file. Check the box. Ship the XML or JSON document. Move on.
But when you actually tried to use those SBOMs for security decisions, everything fell apart. The SBOMs were incomplete. They missed transitive dependencies. They did not track across versions. There was no way to correlate them with known vulnerabilities in real time. And there was certainly no way to enforce policies against them in a CI/CD pipeline.
We watched organizations spend six figures on SBOM tooling and still not be able to answer basic questions: What version of Log4j is running in production? Which of our products ship OpenSSL 1.x? If CVE-2024-XXXX drops tomorrow, how many of our customers are affected?
That gap between generating an SBOM and actually operating a supply chain security program is what drove us to start Safeguard.
What We Saw Missing
Three things were fundamentally absent from the market.
First, lifecycle management. An SBOM is not a one-time artifact. Software changes. Dependencies update. Vulnerabilities are discovered months after a release ships. You need to manage SBOMs across their entire lifecycle: generation, storage, enrichment, querying, and retirement. Nobody was treating SBOMs as living documents that required the same operational rigor as the software they described.
Second, actionable intelligence. Producing a list of components is necessary but not sufficient. You need to correlate those components against vulnerability databases in real time. You need to understand reachability -- whether a vulnerable function is actually invoked in your code path. You need policy enforcement that can block a release if it contains a component that violates your risk tolerance. The tools that existed gave you data. They did not give you decisions.
Third, the supply chain view. Software does not exist in isolation. Your product depends on open-source libraries, which depend on other libraries, which are maintained by individuals you have never met. Understanding your risk means understanding that entire chain -- not just the first layer of your direct dependencies, but the transitive dependencies three, four, five levels deep. And it means understanding the health and trustworthiness of the projects you depend on, not just their vulnerability count.
The Principles We Started With
We wrote down four principles before we wrote a line of code.
SBOMs are infrastructure, not artifacts. We would build a platform that treats SBOMs as a core part of your security infrastructure, not a compliance artifact you generate and forget. That means storage, versioning, diffing, querying, and correlation -- all the things you would expect from a system of record.
Security decisions need context. A vulnerability with a CVSS score of 9.8 might be irrelevant if the vulnerable code path is not reachable in your application. A CVSS 5.0 might be critical if it is in a component that handles authentication. We would build intelligence that provides context, not just severity numbers.
Developers should not need to be security experts. The people writing code are the people closest to the supply chain decisions. They choose which libraries to use. They decide when to update. If we make security tooling that only security teams can operate, we have already lost. Every tool we build should fit into developer workflows -- IDEs, CLIs, CI/CD pipelines, pull requests.
Open standards matter. We would support CycloneDX and SPDX. We would not lock customers into a proprietary format. We would contribute to the standards we depend on. The software supply chain security ecosystem is too important to be fragmented by vendor lock-in.
What We Built
The first version of Safeguard shipped in March 2024. It was intentionally focused: SBOM lifecycle management with a platform called ESSCM (Enterprise Software Supply Chain Management). Upload SBOMs, store them, query them, track changes over time, correlate against vulnerabilities.
But even in that first release, the architecture reflected our principles. We built the data model to support the full lifecycle. We built the API to be programmable. We built the correlation engine to work in real time, not batch.
From there, we expanded based on what customers told us they needed. Vulnerability scanning with reachability analysis. Policy enforcement that could gate releases. A CLI tool that developers could use without leaving their terminal. IDE extensions for VS Code and JetBrains. An AI assistant -- Griffin -- that could answer natural-language questions about your supply chain posture.
Every feature we shipped answered the same question: does this help someone make a better security decision about their software supply chain?
What We Learned
Two years in, a few things have become clear.
The market is moving from "we need to generate SBOMs" to "we need to operationalize SBOMs." That shift is exactly what we anticipated, and it validates the platform approach. Generating an SBOM is a solved problem. Managing thousands of them across hundreds of products, tracking drift, enforcing policy, responding to new vulnerabilities in hours instead of weeks -- that is the hard problem.
AI changes the equation more than we expected. When we built Griffin, we thought it would be a convenience feature. It turned out to be transformational. Security teams that could previously query their SBOM data only through structured APIs can now ask questions in plain English. "Which of our products are affected by this CVE?" "Show me all components with licenses that are not in our approved list." "What changed between the last two releases of this product?" The speed of those interactions changed how teams operate.
Open-source health is the next frontier. Vulnerability scanning tells you about known problems. But the real risk in your supply chain is often in the unknowns: projects with a single maintainer, dependencies that have not been updated in years, libraries with no security response process. We are investing heavily in helping customers understand not just what is vulnerable, but what is risky.
Why This Matters
The SolarWinds attack. The Log4Shell vulnerability. The XZ Utils backdoor. The Codecov breach. These are not theoretical risks. They are things that happened, that caused real damage, that affected real organizations.
The software supply chain is the attack surface of this decade. Every application you build, every product you ship, every service you deploy is composed of components you did not write, maintained by people you do not know, hosted on infrastructure you do not control. Understanding and managing that risk is not optional.
We built Safeguard because we believe that understanding starts with visibility. Visibility starts with a comprehensive, accurate, continuously updated inventory of what is in your software. And that inventory needs to be operationalized -- connected to vulnerability intelligence, policy enforcement, and developer workflows -- to actually reduce risk.
That is the company we are building. If you are dealing with these problems, we would like to help.