Safeguard now appears on CISA's list of Secure by Design Pledge signers, listed as Safeguard.sh. The pledge asks a software maker to show measurable progress on seven security goals within a year of signing. This post sets out where Safeguard stands on each goal today and what we are committing to over the next twelve months, so customers can hold us to it.
CISA's list of Secure by Design Pledge signers, captured October 10, 2026. Source: cisa.gov.
Interactive demo: click through CISA's signers list to Safeguard's entry, then the sign-in and account security controls Safeguard customers can use today. The Safeguard part uses a sample workspace with test data only.
It is written for security teams who evaluate Safeguard, and for anyone weighing whether a vendor's pledge means anything. By the end you should know what the pledge asks for, what we already ship, and what we have not done yet.
What the Secure by Design Pledge is
The Secure by Design Pledge is a voluntary commitment run by the US Cybersecurity and Infrastructure Security Agency (CISA). It covers enterprise software: on-premises products, cloud services and SaaS. CISA launched it on May 8, 2024 with 68 initial signers.
Two points about it are easy to get wrong, so we will state them plainly:
- It is a commitment to progress, not a certification. CISA's pledge page says the pledge "is voluntary and not legally binding", and that CISA "does not enforce nor verify adherence to the pledge."
- It is not an endorsement. Appearing on the list does not mean CISA endorses Safeguard or any product.
The signers page listed 393 companies when we captured it on October 10, 2026.
What it does is set a public bar. Each signer says, in effect: within a year, here is the evidence that we moved on these seven things. The rest of this post is our starting position.
Goal 1: multi-factor authentication
The goal: measurably increase the use of multi-factor authentication across the product, ideally including phishing-resistant methods.
Where we are today. Every Safeguard user can turn on authenticator-app codes (TOTP) with backup codes from their own settings. Once it is on, sign-in asks for the code. Organizations can also sign in through their own identity provider over SAML or OIDC, including Okta, Microsoft Entra ID, ADFS, Ping, OneLogin and Auth0. That path means the MFA policy a company already enforces, phishing-resistant methods included, applies to Safeguard too. Users can also sign in with Google, Microsoft, GitHub or GitLab.
What we will do this year. Two gaps matter most. Passkeys (WebAuthn) are not yet available as a native sign-in method, and we will add them so phishing-resistant MFA does not depend on an external identity provider. And a workspace admin should be able to require MFA, or require SSO, for everyone in the workspace and have the platform enforce it at sign-in. We will ship that enforcement and report MFA adoption as the measure of progress.
Goal 2: default passwords
The goal: reduce default passwords across the product.
Where we are today. The products customers install do not ship with a shared default password. The first administrator of a workspace chooses their own password at sign-up, with a 12-character minimum and complexity rules, and email verification is on by default. Our Helm charts take credentials from an external secret store rather than from defaults in the chart.
What we will do this year. We will check new passwords against known breached-password lists, and we will audit every component we run, internal services included, so that no service falls back to a built-in credential when a secret is missing. A missing secret should stop a service from starting, not quietly weaken it.
Goal 3: reducing entire classes of vulnerability
The goal: show measurable progress in eliminating one or more whole classes of vulnerability.
Where we are today. Safeguard is written in memory-safe languages: Java, Python, TypeScript, Go, Kotlin and Swift, with no hand-written C or C++. That removes the memory-safety class (buffer overflows, use-after-free) from our own code by construction. Database access goes through bound parameters rather than strings assembled from user input, and the web front ends render through React, which escapes output by default.
What we will do this year. Memory safety is a class we avoided by choice of language, not one we eliminated through sustained work. For the pledge we are choosing two classes to drive down measurably:
- Cross-site scripting. A strict Content Security Policy with nonces across our web applications, and a single reviewed sanitizer for every place that renders rich content.
- Server-side request forgery. Every outbound request the platform makes on a customer's behalf goes through one guard that resolves and checks the destination, including after DNS resolution.
We will also run static analysis and secret scanning on our own code in CI, using our own scanners, and publish the before-and-after counts for both classes.
Goal 4: security patches
The goal: measurably increase customers' installation of security patches.
Where we are today. Safeguard is primarily SaaS. A fix ships to every customer as soon as it passes our release gate, with no action needed and no version a customer can be left behind on. Our VS Code and JetBrains extensions and our browser extension update through their marketplaces. The CLI checks for updates and verifies the signature and digest of an update before installing it.
What we will do this year. The CLI and desktop app tell you an update exists but leave the install to you. We will offer automatic installation for both, and a documented update channel for self-hosted and air-gapped deployments, where patching is hardest and matters most.
Goal 5: a vulnerability disclosure policy
The goal: publish a vulnerability disclosure policy that authorizes testing and offers a clear channel for reports.
Where we are today. Our responsible disclosure policy is published, and so is a security.txt pointing to it and to security@safeguard.sh. The scope covers the platform, our IDE extension, CLI and MCP server, model inference paths, the air-gapped appliance and our build and signing pipeline. It includes a safe-harbour commitment: we will not pursue civil or criminal action against researchers who act in good faith within the policy.
What we will do this year. We will review the policy against CISA's own vulnerability disclosure template, make sure every page that describes how we handle reports says the same thing, and credit researchers publicly in our hall of fame.
Goal 6: CVEs
The goal: show transparency in vulnerability reporting, with accurate CWE and CPE fields in every CVE and timely CVEs for critical issues.
Where we are today. We publish security advisories for our own products. None has been published to date.
What we will do this year. When a vulnerability in Safeguard needs a CVE, it will get one, and every advisory will carry the CWE and CPE fields the pledge asks for, alongside the CVSS vector, affected versions and timeline. We will also publish machine-readable advisories for our own products, so customers can feed them into the same tooling they use for everyone else's.
Goal 7: evidence of intrusions
The goal: give customers the means to gather evidence of intrusions affecting the product.
Where we are today. Every workspace has a security activity log under Settings. It records sign-ins and failed sign-ins, MFA steps, every write and export, and every request the API refused. Entries are hash-chained, so a gap or an altered entry shows. Workspace admins see activity across the organization, every user sees their own activity and devices, and anyone can review and end their active sessions. Entries are kept for 400 days.
What we will do this year. Evidence a customer cannot take out of the product is only half useful. We will add export of the activity log and streaming to the SIEM a customer already runs, so an investigation does not start with a support ticket.
Why a security vendor should sign this
The fair objection is that a voluntary pledge with no verification costs a signer nothing. That is true of the signature. It is not true of a public list of commitments with a date attached, which is why we have written ours down here rather than only adding a badge.
Safeguard's job is to help customers find and fix weaknesses in the software they build and buy. We ask our customers to account for the software they ship, and it would be odd to ask that without doing it ourselves. We will publish an update on each goal before the anniversary of signing, including the ones where we fall short.
Questions about any of this, or a vulnerability to report, go to security@safeguard.sh.
