Every couple of years, a major platform shift forces security leaders to revisit the buy-versus-build question. In 2016 it was cloud native. In 2019 it was developer-first tooling. In 2022 it was the SBOM mandate. In 2026, it is the convergence of autonomous remediation, AI-generated code, and provenance-level attestations, and the answer has changed again. My thesis: the right architecture in 2026 is neither pure vendor nor pure in-house. It is a hybrid with sharp opinions about which layers you own and which you do not, and most programs still do not have those opinions explicit.
The programs I see struggling are the ones that made a default choice five years ago — "we buy everything" or "we build everything" — and never revisited it. Both defaults are wrong now. The tooling economy has matured past the point where building your own SCA is sensible, and simultaneously the integration burden has grown past the point where buying end-to-end from one vendor is wise. You need a position, and the position needs to be deliberate.
Why Did "Just Buy It" Stop Working?
Because the end-to-end vendor promise does not survive contact with real environments. The vendors selling a single unified platform for code, cloud, runtime, supply chain, and identity are selling a slide. The product always has one or two strong modules and several weaker ones, and the weaker ones compete poorly with purpose-built specialists.
Five years ago, buying the bundle was defensible. The specialist market was thin, the integration cost of multiple tools was high, and CISOs valued the single throat to choke. Those conditions reversed. Specialist vendors are now excellent in their niches, open integration standards are better (OpenTelemetry, OCIF, SARIF, in-toto), and the single-pane-of-glass promise has been exposed as mostly marketing.
The other failure mode of "just buy it" is that the vendor's roadmap becomes your roadmap. When they deprioritize a capability you need, you have no recourse. When they are acquired — which happens constantly in security — you get to relearn their product direction, often in unfavorable ways. Vendor concentration risk in security is real and underappreciated.
Why Did "Just Build It" Stop Working Too?
Because the surface area is too large for any individual company's security engineering team, except in a handful of hyperscalers. Supply chain security in 2026 requires parsers for dozens of ecosystems, continuous feeds of vulnerability and provenance data, reachability engines, policy systems, attestation storage, and integrations with every CI/CD product on the market. Building all of that in-house consumes a team of 30 to 50 engineers and still produces a worse result than a vendor who specializes in it.
The exception is companies whose software supply chain is itself a product — Google, Microsoft, Apple, major cloud providers, some financial institutions with enormous internal platform teams. For everyone else, the build-it-all approach is a form of vanity spend. It feels like control; it is actually overhead.
Even at the companies that can afford to build, the smart pattern has shifted. They build the glue and the policy layer — the parts that are specific to their architecture and culture — and buy the commodity pieces. Nobody sensible is building their own vulnerability database in 2026.
What Layers Should You Own?
The short answer is: the parts that encode your decisions, not the parts that produce data.
Owning policy is non-negotiable. The rules for what blocks a merge, what triggers an incident, what requires executive sign-off — these are organizational statements and they need to be expressed in systems you control. A vendor's policy DSL that you cannot extend or audit is a liability.
Owning workflow is usually smart. The specific path a finding takes from detection to remediation to closure reflects your engineering culture, your team structure, and your risk appetite. Off-the-shelf workflow tools work for some shops but get in the way at others. If you have an opinionated engineering organization, you probably want to own workflow.
Owning data aggregation is worth it. A store of SBOMs, findings, attestations, and audit events that you control — even if the inputs come from vendors — gives you leverage when switching vendors, composing multiple tools, and answering questions the vendor's UI cannot answer.
What Layers Should You Buy?
Commodity data production. Running your own vulnerability database is silly. Running your own ecosystem parsers is tolerable but wasteful. Running your own static analysis engines for mainstream languages is almost always a mistake unless you have very specific needs.
Scanner-grade detection. SCA, SAST, container scanning, IaC scanning — these are commoditized. The vendors are good, the prices are reasonable, and the engineering cost of matching their quality is prohibitive.
Threat intelligence. Pay for it. The signal is worth the license fee, and the alternative is either poor coverage or a large in-house threat intel team that you likely cannot justify.
Integrations with managed services. If your CI/CD, cloud, or identity provider ships a security feature, turn it on before you build an equivalent. The managed feature has deeper integration than anything you can buy or build externally.
What Does a Good Hybrid Architecture Actually Look Like?
A pattern I have seen work in multiple organizations:
At the bottom is a layer of specialist vendors producing raw signal — scanner output, threat intel, provenance data, runtime telemetry. You buy these, you do not build them, and you pick best-of-breed rather than bundle.
Above that is a unification layer you own or control. This is where findings from different sources are deduplicated, enriched with business context, and stored in a format your team understands. The unification layer may be built on a platform (SIEM, data lake, purpose-built security data warehouse) but its schema and semantics are yours.
Above that is a policy and workflow layer. This is the heart of the program — the rules, the SLAs, the remediation playbooks, the audit trails. It integrates with the developer tools (GitHub, GitLab, Jira, Slack) that engineers already use. It is opinionated about what a "finding" means in your organization, what gets auto-fixed, what gets reviewed, and what pages a human.
At the top is a reporting and evidence layer for leadership and regulators. This is often built on top of the workflow data, not separate from it.
The specific products that fill each layer will change over time. The architecture — specialized data production, unified data semantics, owned policy and workflow, derived reporting — should be stable.
How Do You Evaluate Vendors Without Getting Locked In?
Start by assuming you will switch vendors in 36 months. That assumption clarifies the evaluation criteria.
Can you export your data in open formats? If the vendor stores SBOMs as proprietary blobs and cannot emit standard CycloneDX or SPDX, that is a red flag. Same for findings, attestations, and audit trails.
Does the vendor expose a rich API? If the primary interface is a web UI and the API is an afterthought, you will not be able to build the unification layer on top of it. Vendors serious about enterprise use treat the API as the primary surface.
Does the vendor integrate with your CI/CD and ticketing systems in a way you can extend? Read-only integrations are usually fine. Integrations that require the vendor to be in the critical path of every merge are a problem.
Is the pricing model sane at scale? Per-developer pricing scales well with the value of the tool; per-finding or per-scan pricing usually does not.
Can you turn off features you do not use? Bundled feature sets where every customer pays for every module, whether used or not, are a sign that the vendor's economics do not align with customer value.
How Do You Know You Have the Balance Wrong?
Several symptoms indicate an imbalanced portfolio.
Too much buy: security engineers spend their time writing vendor-specific glue code, policy changes take months because they live in a vendor's config UI, exporting data is painful, and migrating off any tool feels impossible.
Too much build: security engineers spend their time maintaining parsers and databases rather than responding to risk, internal tools lag the commercial state of the art, and onboarding new engineers takes forever because the tooling is idiosyncratic.
The correct balance is boring. Engineers work on policy, workflow, and response. Commodity data production happens in the background. Vendors are swapped when they underperform, without drama. The program's identity lives in its policies and playbooks, not in its product catalog.
How Safeguard.sh Helps
Safeguard.sh is designed as the middle layer of a hybrid architecture, not as a replacement for the whole stack. The platform ingests findings and attestations from the scanners and signal sources you already run, unifies them into a consistent model, and runs the policy, workflow, and remediation logic on top. Data is exportable, policies are expressible in your own terms, and integrations with CI/CD and ticketing are first-class. The goal is to give you the owned policy and workflow layer without making you build it, while leaving the commodity data production to the specialist vendors who are already good at it. Hybrid by design, because hybrid is what actually works.