Optiarms Inc., doing business as D.A.R.Y.L. Labs (“Daryl Labs”, “we”, “us” or “our”) builds Daryl Shield, a service that finds and fixes access-control problems in the databases behind its customers’ apps. We welcome help from the security community. This Vulnerability Disclosure Policy (the “Policy”) explains what systems and types of research it covers, how to send us a report, what we commit to in return, and how long we ask you to wait before talking about what you found publicly. It is based on the vulnerability disclosure policy template published by the US Cybersecurity and Infrastructure Security Agency (CISA).
Section 10 of this Policy covers a separate subject: what we do when Daryl itself comes across a security problem in an app that belongs to someone else.
Daryl Shield is in early access. Some systems and features named in this Policy, including parts of the scanning, proof and replay engines and the verify command-line tool, may not be available yet. Where this Policy describes how something works, it describes how it works when that feature is in use.
1. Authorization
If you make a good faith effort to comply with this Policy during your security research, we will consider your research to be authorized. We will work with you to understand and resolve the issue quickly, and Daryl Labs will not recommend or pursue legal action related to your research. Should legal action be initiated by a third party against you for activities that were conducted in accordance with this Policy, we will make this authorization known.
This authorization covers research directed at the systems listed as in scope in section 4, carried out under the guidelines in section 2 and without the methods listed in section 3. It does not authorize testing of any system that belongs to someone else, including our customers’ apps and databases and the third-party services listed in section 5, and we cannot grant permission on their behalf.
2. Guidelines
Under this Policy, “research” means activities in which you:
- Notify us as soon as possible after you discover a real or potential security issue.
- Make every effort to avoid privacy violations, degradation of user experience, disruption to production systems, and destruction or manipulation of data.
- Only use exploits to the extent necessary to confirm a vulnerability’s presence. Do not use an exploit to compromise or exfiltrate data, establish persistent command-line access, or use the exploit to pivot to other systems.
- Provide us a reasonable amount of time to resolve the issue before you disclose it publicly (see section 7).
- Do not submit a high volume of low-quality reports, such as unverified output from automated scanners.
Once you’ve established that a vulnerability exists or encounter any sensitive data (including personal information, financial information, access tokens, or proprietary information or trade secrets of any party), you must stop your test, notify us immediately, and not disclose this data to anyone else. Delete any copy of that data you hold once you have reported it, and tell us that you have done so.
Test only against accounts and organizations you created yourself. Connect them only to Supabase projects, GitHub repositories or deploy platform accounts that you own. Do not attempt to access, change or infer another customer’s organization, connected accounts, findings, policies, receipts or data. If a flaw would let you cross from one organization into another, demonstrate it between two organizations you control.
Do not attempt to sign in as anyone else, or use codes or sign-in links that were not issued to you.
3. Test methods that are not authorized
The following test methods are not authorized under this Policy:
- Network denial of service (DoS or DDoS) tests, load or stress testing, or other tests that impair access to or damage a system or its data, including deliberately exhausting rate limits for other people.
- Physical testing (for example office access, open doors or tailgating), social engineering (for example phishing or vishing), or any other non-technical vulnerability testing directed at our staff, contractors, customers or service providers.
- Sending unsolicited email, messages or notifications through the Service (for example using invitation, sign-in or alert features to send spam), or flooding our support and security inboxes.
- Running the Daryl Check, or causing Daryl to scan or connect to, any site or system you do not own or administer. Pointing Daryl at someone else’s app is governed by the Acceptable Use Policy, not this Policy.
- Attacks against our hosting, database, payment, email delivery, AI model or key management providers, or any other third party.
4. Scope
This Policy applies to the following systems and services:
getdaryl.comand any subdomain of it (*.getdaryl.com), including the Check and the sign-in pages.- The Daryl Shield dashboard, where customers manage organizations, apps, connections, findings and fixes.
- The Daryl API, including its webhooks and any endpoint the dashboard calls.
- The Daryl GitHub App, including the permissions it requests and the pull requests and checks it creates.
- The Daryl verify command-line tool, which lets anyone check a Daryl receipt independently, once it is published. Until we publish it, there is nothing to test; we will update this Policy when it is released.
- Daryl’s handling of access to customer systems, such as a flaw that could expose connection tokens or apply a change that widens access instead of narrowing it. Demonstrate these against systems you own.
The closing Daryl household assistant (see /sunset) is in scope on the same terms until it shuts down.
Any service not expressly listed above is excluded from scope and is not authorized for testing. If you aren’t sure whether a system is in scope, contact us at security@getdaryl.com before starting your research.
5. Out of scope
The following are out of scope, and this Policy does not authorize testing them:
- Our customers’ apps. The apps, websites, Supabase projects, databases, storage buckets, functions and repositories that our customers connect to Daryl belong to them. Finding a weakness in a customer’s app is not a vulnerability in Daryl, and testing it needs that customer’s permission. If you believe Daryl itself caused or hid a weakness in a customer app, report that to us.
- Third-party services. Services we rely on or integrate with, including Supabase, GitHub, Slack and our hosting, database, payment, email delivery, AI model and key management providers. Report issues in those services to the provider under its own program.
- Findings without a security impact, such as missing headers with no demonstrated exploit, self-cross-site scripting, visible software versions, and content that is public by design (published receipts, badges and transparency log entries).
- Rate-limit or brute-force reports that do not show a practical attack, and issues that require a compromised device or browser.
6. How to report a vulnerability
Send reports by email to security@getdaryl.com. Please do not open public issues, post on social media or contact our support channels about an unfixed vulnerability. Our security.txt file lists the same address. Reports may be submitted anonymously; if you share contact details, we will use them only to work with you on the report.
To help us triage and prioritize, a useful report includes:
- The system or URL affected, and where the vulnerability can be observed.
- A description of the vulnerability and its potential impact, including what an attacker could reach.
- Clear steps to reproduce it, with any proof-of-concept code, requests and responses, screenshots or a short video. Benign, non-destructive proof of concept is enough.
- The identifiers of the test organizations and accounts you used, so we can tell your activity apart from an attack.
- When you tested, and from which IP addresses if you can share them.
- Whether you would like to be credited, and the name or handle to use.
7. What you can expect from us
When you choose to share your contact information with us, we commit to coordinating with you as openly and as quickly as possible. We will:
- Acknowledge that your report has been received within 3 business days.
- To the best of our ability, confirm the existence of the vulnerability, and give you a status update, within 10 business days of receipt, and keep you updated as remediation progresses.
- Aim to fix confirmed vulnerabilities, and coordinate public disclosure with you, within 90 days of your report. Serious issues will be handled faster. If a fix needs longer, we will explain why and agree a revised date with you.
- Notify affected customers where a vulnerability put their data or connected systems at risk, as required by our agreements and by law, without identifying you unless you agree.
We want to resolve issues before they are discussed in public, and we ask that you do not share details of a vulnerability until it is fixed or 90 days have passed since your report, whichever comes first, unless we agree otherwise in writing. If a vulnerability is being actively exploited, we may need to disclose sooner, and will tell you before we do.
8. Safe harbor
For research carried out in line with this Policy, Daryl Labs:
- Considers your research authorized for the purposes of the Computer Fraud and Abuse Act and similar state laws, and will not bring a claim against you under those laws for accidental, good-faith violations of this Policy.
- Waives any restriction in our Terms of Service or Acceptable Use Policy that would otherwise prohibit that research, to the extent needed to carry it out.
- Will not pursue claims under the Digital Millennium Copyright Act for circumventing technical measures to carry out the research.
You remain responsible for complying with the law that applies to you, and this safe harbor cannot bind any third party, including our customers and providers. Research that breaks this Policy, such as accessing other customers’ data or keeping data after you report, is not covered.
9. Rewards and credit
Daryl Labs does not offer a paid bug bounty at launch, and nothing in this Policy promises payment. Demanding payment in exchange for details or silence is not research under this Policy. If we start a bounty program later, we will announce its terms separately; it will not apply retroactively unless it says so.
With your permission, we will thank you by name or handle on our security page once the issue is fixed, and in any advisory we publish about it. You may ask us to credit you differently or not at all, at any time.
10. When Daryl finds a problem in someone else’s app
Daryl’s job is to find security weaknesses in apps. Sometimes, while running the free Check for a user or while researching the AI-Built App Leak Report we plan to publish, Daryl may come across a weakness in an app that belongs to someone other than the person who asked, or to no customer at all. This section explains what we do then.
10.1 Passive methods only
When the Check is in use, before ownership of an app has been verified, it reads only what any web browser downloads when it visits a public page: the HTML, the JavaScript bundles, response headers, source maps and other files the page itself loads. It does not sign in, read database rows, list tables (even through an API’s schema endpoint) or send requests designed to change anything. It identifies itself in its user-agent, limits how often it fetches, and honors the opt-outs described in section 10.4. Leak Report research uses the same passive methods, together with aggregate data from customers who have opted in.
10.2 Private disclosure to the owner
If we incidentally learn of a weakness in a third party’s app, for example an exposed key or a publicly readable storage bucket, we will disclose it privately to the person or organization that appears to own the app, using the contact they publish (such as their own security.txt) or another reasonable channel. We tell them what we observed and how to fix it, without asking for payment. If we cannot find a contact, we may tell the platform the app is hosted on, privately.
10.3 Never published
We never publish a third party’s individual vulnerability, name an affected app or its owner, or use it in marketing. The Leak Report publishes aggregate statistics only, such as the share of a sample showing a type of weakness, in a form that cannot identify any app. We keep only what we need to notify the owner, and never the contents of anyone’s database.
10.4 How site owners opt out
Site owners can tell Daryl not to scan their site, through either of these:
- A file at
/.well-known/daryl-optouton the site. Its presence is enough; it may be empty. - A
robots.txtrule that disallows the Daryl user-agent, or all user-agents, for the paths concerned.
When an opt-out is present, the Check declines to scan the site, and it is excluded from Leak Report research. An owner who later verifies ownership of the site in Daryl can still scan their own site. You can also email hello@getdaryl.com to ask us to exclude a domain.
If you believe Daryl scanned your site in a way that does not match this section, write to security@getdaryl.com.
11. Changes to this Policy
We may update this Policy, for example when the verify command-line tool is published. The effective date at the top shows when it last changed. Research is governed by the version in effect when it was carried out. For our use of personal information in reports, see the Privacy Policy. You can reach us by post at the address at the end of this document.
Contact
Optiarms Inc., doing business as D.A.R.Y.L. Labs
6545 Market Ave N, Ste 100
Canton, OH 44721
hello@getdaryl.com
Other documents: Terms · Privacy · DPA · Acceptable use · Subprocessors · Cookies · Hardening terms · Affiliate terms