1. INTRODUCTION & COMMITMENT

Smackdab Inc. (“Smackdab,” “we,” “us,” or “our”) is committed to ensuring the security of our services and protecting our customers’ data. We value the contributions of the security research community in helping us maintain a high standard of security. This Responsible Disclosure Policy (also known as a Vulnerability Disclosure Policy or “VDP”) outlines the process for security researchers (“Researchers,” “you,” “your”) to report potential security vulnerabilities identified in Smackdab’s systems and services.

We encourage responsible reporting of vulnerabilities. If you believe you have found a security vulnerability in our systems, please notify us according to the guidelines below. We are committed to working with the community to verify and address potential vulnerabilities reported to us.

2. DEFINITIONS

For purposes of this Policy, the following terms shall have the meanings set forth below:

2.1. “Security Vulnerability” means a weakness in a system or its design that could be exploited to cause a breach of security, unauthorized access, data exposure, or disruption of service.

2.2. “Researcher” means an individual or organization that identifies and reports security vulnerabilities in accordance with this Policy.

2.3. “In-Scope Systems” means the systems, services, and applications specified in Section 3.1 that are covered by this Policy.

2.4. “Out-of-Scope Systems” means the systems, services, and activities specified in Section 3.2 that are not covered by this Policy.

2.5. “Responsible Disclosure” means the practice of privately reporting a security vulnerability to the affected organization, allowing them a reasonable time to investigate and remediate the issue before public disclosure.

2.6. “Vulnerability Severity” means the classification of a security vulnerability based on its potential impact and exploitability. We use the Common Vulnerability Scoring System (CVSS v3.1) to determine severity levels as follows:

3. SCOPE

3.1. In-Scope Systems

This Policy applies to security vulnerabilities found within the following Smackdab systems and services (“In-Scope Systems”):

3.2. Out-of-Scope Systems

The following systems, services, and activities are explicitly OUT OF SCOPE for this Policy:

Discovery of vulnerabilities in out-of-scope systems should not be reported under this Policy. If you are unsure whether a system or vulnerability is in scope, please contact us first at [email protected].

3.3. Testing Authorization

Before beginning security testing against any authenticated areas of Smackdab’s systems, you must:

  1. Create a legitimate account for testing purposes

  2. Only test against your own account

  3. Clearly label test accounts with “SECURITY_TEST_” as a prefix in any customizable fields

No prior explicit authorization is required for security testing against publicly accessible (unauthenticated) portions of our In-Scope Systems, provided you follow all other guidelines in this Policy.

For high-impact testing (such as testing that might affect system availability or integrity), please contact us at [email protected] to coordinate your testing activities before proceeding.

4. GUIDELINES & RULES OF ENGAGEMENT

We require that Researchers adhere to the following guidelines when investigating and reporting vulnerabilities:

4.1. General Guidelines

4.2. Permitted Testing Tools and Methods

The following security testing tools and methods are permitted when used responsibly:

All automated scanning tools must include your contact information in the User-Agent string or headers to help us identify your legitimate testing activity.

4.3. Prohibited Activities

In addition to the exclusions listed in Section 3.2, the following activities are strictly prohibited:

Violation of these guidelines may result in suspension of your access, legal action, or other remedies available to Smackdab under applicable law.

5. HOW TO REPORT A VULNERABILITY

If you believe you have discovered a vulnerability within the scope of this Policy, please report it to us promptly by sending an email to:

Email: [email protected]

Subject Line: “Vulnerability Report: [Brief Description]”

5.1. Report Content

Please include the following information in your report:

Please submit one vulnerability per report, unless multiple vulnerabilities are dependent on each other. Use encrypted communication if possible when submitting sensitive details.

5.2. Report Template

To ensure a complete report, consider using this structured format:

VULNERABILITY REPORT

Title: [Brief, descriptive title]

Date: [Discovery date]

Researcher: [Your name and contact information]

CVSS Score (if known): [Score and vector]

## Description

[Detailed explanation of the vulnerability]

## Affected System(s)

[Specific URLs, endpoints, or components affected]

## Steps to Reproduce

1. [First step]

2. [Second step]

3. [Continue as needed]

## Potential Impact

[Explanation of what an attacker could accomplish by exploiting this vulnerability]

## Supporting Evidence

[Screenshots, logs, or code snippets]

## Suggested Mitigation

[Optional: Your recommendations for addressing the issue]

## Disclosure Plans

[Your timeline or intentions regarding disclosure]

5.3. PGP Encryption

For encrypted communications, you may use our PGP key, which is available at https://smackdab.ai/security/pgp-key.asc or on public key servers. The key fingerprint is:

[PGP KEY FINGERPRINT TO BE INSERTED]

6. OUR COMMITMENTS & PROCESS

Upon receiving a vulnerability report that complies with this Policy, Smackdab commits to:

6.1. Acknowledgement

We will acknowledge receipt of your report within 3 business days. For critical severity vulnerabilities, we aim to provide same-day acknowledgment during business hours.

Our acknowledgment will include:

6.2. Triage & Validation

We will investigate and validate the reported vulnerability. This process may take time depending on complexity. We aim to confirm the validity of a report within 10 business days, though this may vary based on the nature and complexity of the reported issue.

Smackdab reserves the right to reclassify the severity of a vulnerability after our assessment. If we determine a different severity level than what was initially reported, we will provide a clear explanation for the reclassification based on our CVSS scoring methodology.

6.3. Vulnerability Management Process

We follow a structured process for managing reported vulnerabilities:

  1. Initial Assessment: Preliminary review by our security team to determine scope and validity

  2. Classification: Assignment of severity and priority based on CVSS scoring

  3. Tracking: Each valid vulnerability is assigned a unique identifier in our internal tracking system

  4. Development Planning: Remediation tasks are created and assigned to appropriate engineering teams

  5. Remediation: Implementation of fixes or mitigations

  6. Verification: Testing to confirm the vulnerability has been properly addressed

  7. Closure: Final communication with the reporter and internal documentation

For critical vulnerabilities, we may establish a dedicated incident response team to expedite the remediation process.

6.4. Communication

We will endeavor to maintain open communication, providing periodic updates on the status of the reported vulnerability as appropriate (e.g., when validated, when remediation is complete). We will notify you when the vulnerability has been validated and again when it has been remediated.

For significant vulnerabilities, we may request a confidential video call to discuss details or clarify certain aspects of the report. In such cases, we may request that you sign a Non-Disclosure Agreement (NDA) before sensitive information is shared.

6.5. Remediation

If the report is validated, we will assign resources to remediate the vulnerability in a timeframe appropriate to its severity and complexity. Our target timeframes for remediation are:

These timeframes may be adjusted based on technical complexity, operational constraints, or other factors.

6.6. Recognition

We appreciate the effort of security researchers. While Smackdab does not currently offer a formal bug bounty program, we may offer recognition (e.g., acknowledgment on a security researcher list) for valid and responsibly disclosed vulnerabilities at our discretion. Depending on the severity and impact of the vulnerability, we may also offer:

We evaluate each valid reported vulnerability on a case-by-case basis to determine appropriate recognition.

Eligibility Criteria for Recognition:

6.7. Vulnerability Re-testing

After we’ve notified you that a reported vulnerability has been fixed, you may wish to verify the fix. For re-testing:

6.8. Future Bug Bounty Program

While Smackdab does not currently operate a formal bug bounty program with monetary rewards, we are actively evaluating the implementation of such a program in the future. When launched, the program will be announced on our security page at https://smackdab.ai/security.

7. SAFE HARBOR

Smackdab will not initiate or support legal action against Researchers for security research activities that:

We consider activities conducted consistent with this Policy to constitute “authorized” conduct under the following laws and regulations:

If legal action is initiated by a third party against you in connection with activities conducted under this Policy, we will take steps to make it known that your actions were conducted in compliance with this Policy.

This safe harbor applies only to activities focused on the In-Scope Systems and conducted strictly following the Guidelines and Reporting process outlined herein. It does not protect against actions violating laws or this Policy, nor does it apply to out-of-scope systems or activities.

Limitations: The safe harbor provision does not bind law enforcement, regulatory agencies, or other third parties who may take a different view of the activities. While we will advocate for you in such situations (provided you’ve complied with this Policy), we cannot guarantee protection from enforcement of applicable laws.

⚠️ ATTORNEY REVIEW NOTE: In addition to reviewing the safe harbor provisions as previously noted, please pay special attention to the list of specific laws covered by our safe harbor provision to ensure it accurately reflects current legal interpretations of security research protections and doesn’t create undue liability for Smackdab.

8. COORDINATED DISCLOSURE & PUBLICATION

8.1. Coordinated Disclosure

We request that you maintain confidentiality regarding any discovered vulnerability for a reasonable period, allowing us time to investigate and remediate the issue. Please refrain from publicly disclosing vulnerability details until we have confirmed remediation or mutually agreed upon a disclosure timeline.

8.2. Standard Publication Timeline

We ask for a minimum of 90 days of confidentiality after our initial acknowledgement of your report before any public disclosure, to allow for remediation. For complex vulnerabilities, we may request additional time.

8.3. Exceptional Timeline Cases

We recognize that standard timelines may not apply to all situations:

We are committed to addressing all vulnerabilities in good faith and as quickly as feasible, and will work with you to establish reasonable timelines for exceptional cases.

8.4. Coordinated Publication

If you wish to publish information about a vulnerability after the agreed embargo period:

8.5. Ongoing Vulnerabilities

For vulnerabilities that require longer remediation periods, we will work with you to establish a reasonable timeline for disclosure based on:

9. LEGAL CONSIDERATIONS

9.1. Compliance with Laws

All security research activities must comply with all applicable local, state, federal, and international laws. Nothing in this Policy is intended to grant permission to violate any applicable laws or regulations.

9.2. International Researchers

This Policy applies to researchers globally. However, we acknowledge that laws regarding security research vary by jurisdiction. If you are located outside the United States, please ensure your activities comply with both your local laws and United States laws before engaging in security research activities.

Relevant international cybersecurity and computer crime laws that may apply include:

In jurisdictions where no explicit security research exemptions exist, this Policy may not provide legal protection outside the United States. Researchers should consult local legal counsel if uncertain about legal implications in their jurisdiction.

9.3. Limitation of Liability

To the maximum extent permitted by law, Smackdab disclaims any liability for any damages or harm resulting from security research conducted in accordance with this Policy.

9.4. Modifications to this Policy

Smackdab reserves the right to modify this Policy at any time. Changes will be published on our website. Security research should be conducted according to the version of the Policy in effect at the time of the research.

10. QUESTIONS

If you have questions about this Policy or whether a particular system or activity is in scope, please contact us at [email protected] before starting your research.

11. CONTACT INFORMATION

Email: [email protected]
Mail:
 Smackdab Inc.
Attn: Security Team
372 Live Oak Ln
Marco Island, FL 34145
United States

We also support the security.txt standard (RFC 9116) to help security researchers locate our security policy and contact information. Our security.txt file is available at:

12. VERSION HISTORY

Version

Date

Description of Changes

1.0

[Initial Date]

Initial policy implementation

2.0

April 26, 2025

Comprehensive update including: addition of severity definitions, detailed reporting template, vulnerability management process, expanded safe harbor provisions, coordination timeline clarifications, international researcher guidance, and recognition criteria

Thank you for helping keep Smackdab and our users secure.

© 2025 Smackdab Inc. All rights reserved.

⚠️ ATTORNEY REVIEW NOTE: Please ensure the safe harbor provisions in Section 7 are sufficiently protective but do not overextend legal protections beyond what can be reasonably guaranteed. Consider having specialized cybersecurity counsel review this section to ensure it aligns with current interpretations of the CFAA and related regulations. Additionally, review the list of international laws in Section 9.2 to ensure accuracy and appropriate disclaimers regarding jurisdictional limitations.