Secure by Design

Last updated: 8 November 2026

SunDevs (Pvt) Ltd has signed the Secure by Design pledge of the US Cybersecurity and Infrastructure Security Agency (CISA) for SunLicense. The pledge is voluntary and not legally binding. Signers commit to a good-faith effort towards seven security goals over the following year and to publish their progress. CISA lists signers on its pledge signers page. Signing is a public commitment, not a certification: CISA doesn't audit or verify signers.

This page is our progress report. It says where SunLicense stands on each goal today, including what isn't done yet, and what we plan to do before the pledge's first anniversary in November 2027. We update it as things change.

Progress at a glance

Goal	Status
1. Multi-factor authentication	In progress
2. Default passwords	Met
3. Reducing entire classes of vulnerability	In progress
4. Security patches	Met for the hosted Service, in progress for the SDKs
5. Vulnerability disclosure policy	Met
6. CVEs	Not started
7. Evidence of intrusions	In progress

1. Multi-factor authentication

The goal: measurably increase the use of multi-factor authentication across our products.

Today:

• Every account can turn on two-factor sign-in with an authenticator app (TOTP), on every plan and at no extra cost. Once it's on, the code is asked for at every interactive sign-in: password sign-in, sign-in with Google, GitHub, Discord or Microsoft, joining an organization, the CLI's password sign-in, and connecting an AI assistant to the remote MCP server.
• Recovery codes are single-use and stored only as hashes, authenticator secrets are stored encrypted, and wrong codes count towards the sign-in lockout.
• SunLicense staff sign in to the system console with separate administrator accounts, and those accounts always require an authenticator-app code.

Not yet: an Owner can't yet require two-factor sign-in for everyone in their organization, the dashboard doesn't yet prompt members who haven't turned it on, and there is no phishing-resistant option (passkeys) or single sign-on with your own identity provider.

Next: a setting for Owners to require two-factor sign-in for all members, a reminder in the dashboard for members without it (starting with Owners and Admins), passkeys, and a published figure for the share of members and of Owners and Admins who use two-factor sign-in.

2. Default passwords

The goal: reduce default passwords across our products.

Today: SunLicense has no default passwords.

• Every member chooses their own password when they sign up or accept an invitation, or signs in with a provider account and has no password at all. Invitations and password-reset links are single-use and expire (7 days and 1 hour).
• API keys, personal access tokens, license keys and each organization's license-signing key are generated randomly for each organization when they are created. Keys and tokens are shown in full only once and stored as hashes.
• Our own system administrator account was given a random password when the Service was set up, and it also needs an authenticator-app code.
• The SDKs, templates and CLI ship with no built-in credentials: each product uses the API key its owner creates.

3. Reducing entire classes of vulnerability

The goal: a significant, measurable reduction in one or more classes of vulnerability across our products.

Today: we prevent these classes by design rather than case by case:

• Access to another organization's data (CWE-639, CWE-862). Every record that belongs to an organization carries its organization ID, and the data layer scopes every query to the caller's organization instead of leaving it to each endpoint. An automated cross-organization test suite runs on every change and blocks the release if one organization could read or change another's data. Every API route passes one gateway that denies any route without an explicit permission rule.
• Memory-safety bugs (CWE-119 and related). The Service, the CLI and every official SDK are written in memory-safe languages (Java, TypeScript and JavaScript, Go, Python, C#, PHP and Lua).
• SQL injection (CWE-89). Database access goes through parameterized queries, and organization-owned tables are never queried with hand-written SQL.
• Cross-site scripting (CWE-79). The dashboard and websites are built with a framework that escapes output by default, and every site sends an enforced Content Security Policy.

Next: automated static analysis on every change for injection and cross-site scripting, and publishing how many reported or found vulnerabilities fell into these classes over the year.

4. Security patches

The goal: measurably increase the installation of security patches by customers.

Today:

• The hosted Service (dashboard, API, license validation, customer portal) is patched for everyone at once. Customers have nothing to install: a fix reaches every organization when we deploy it, usually the same day.
• Our dependencies are monitored automatically, and security updates are applied within set deadlines by severity (Security).
• The CLI updates itself with sunlicense update, which installs a release only after verifying its signature. Installs through npm, Homebrew or Scoop are updated by those package managers.
• The SDKs are published to their usual package registries with versioned releases.

Not yet: organizations aren't told when the products they sell use an SDK version that has a newer security fix.

Next: the SDKs already report their own version with product analytics, so the dashboard will flag installs running an SDK version with a known security fix and link to the upgrade.

5. Vulnerability disclosure policy

The goal: publish a vulnerability disclosure policy.

Today: met. Our Vulnerability disclosure policy, based on the disclose.io Core Terms, authorizes good-faith testing of SunLicense by anyone, commits us not to take or support legal action against research that follows it, gives a clear reporting channel (also in our security.txt), and lets researchers disclose publicly once we have had reasonable time to fix the issue. We acknowledge reports within 3 business days.

6. CVEs

The goal: transparency in vulnerability reporting: CVE records with accurate CWE and CPE fields, issued in a timely manner for at least every critical or high-impact vulnerability that needs customer action to patch or is actively exploited.

Today: no CVE has been issued for SunLicense, and we haven't yet published a CVE policy.

Next: a published CVE policy. For a critical or high-impact vulnerability in something customers install (the SDKs, templates or CLI), or one that is exploited in the wild, we will request a CVE through a GitHub security advisory on the affected repository, with its CWE and CPE fields filled in. Vulnerabilities in the hosted Service that need no customer action will be described on our What's new page when they are fixed.

7. Evidence of intrusions

The goal: measurably increase customers' ability to gather evidence of intrusions affecting our products.

Today, on every plan:

• each license shows its recent checks (when, from which machine, and the result) and the machines using it;
• each license shows whether it was issued or last changed through an AI assistant or a personal access token, and with which token;
• each member sees their sign-in methods with when each was last used, and their personal access tokens with their last use;
• marketplace integrations keep a log of the store events they received;
• Sentinel reports tampered copies of your software and patterns such as shared keys or a machine guessing keys.

On Lite and Standard, automations can also send license events to your own systems by webhook.

Not yet: there is no organization-wide audit log of what members do (sign-ins, role changes, new API keys and tokens, settings changes) that an Owner can review and export.

Next: an audit log on every plan at no extra cost, covering sign-ins and security-relevant changes, with who made each change, from where, and an export.

Questions

Email [email protected] with "Security" in the subject. For everything else a security review usually asks for, see the Trust center.