← Back to Home

Security Statement

Samurai Labs

Effective Date: March 5, 2026

Last Updated: March 5, 2026

This Security Statement describes the security architecture, controls, and practices implemented across all Apps published by Samurai Labs on the Atlassian Marketplace:

• CostLens - FinOps for Jira
• GuardRail - Security Analytics for Jira
• SmartTag - AI Labeler for Jira
• SmartTag - AI Labeler for Confluence
• PagePulse - Content Health for Confluence
• ServiceCost - Cost Intelligence for Compass

1. Architecture Overview

1.1 Forge-Native Architecture

All Apps are built entirely on Atlassian Forge, Atlassian's next-generation cloud app development platform. This means:

• No external servers. Our Apps do not operate any servers, virtual machines, containers, or cloud infrastructure. All code executes within Atlassian's managed Forge runtime (Node.js 22.x).
• No external databases. All data is stored in Forge SQL (managed MySQL) and Forge Key-Value Storage, both fully managed by Atlassian.
• No external endpoints. Our Apps expose no APIs, webhooks, or publicly accessible endpoints.

1.2 "Runs on Atlassian" Eligibility

All Apps qualify for Atlassian's "Runs on Atlassian" trust designation. This certification confirms that:

• App code executes entirely within Atlassian's infrastructure
• Data storage is managed by Atlassian
• No customer data leaves Atlassian's environment (except the declared Sentry analytics integration, which carries no user data)

1.3 Data Residency Support

Because our Apps run entirely on Forge, data residency is managed by Atlassian's platform. Customer data resides in the same region as their Atlassian Cloud instance, in accordance with Atlassian's Data Residency policies.

2. Authentication and Authorization

2.1 Authentication Model

Our Apps use Forge-managed authentication exclusively. This means:

• No custom authentication mechanisms
• No storage of user credentials, tokens, or API keys
• No OAuth flows or external identity provider integrations
• User identity is provided by the Forge runtime context, verified by Atlassian

2.2 Authorization Controls

• Admin-only operations: Sensitive operations (configuration changes, data deletion, security rule management, compliance settings) require Jira/Confluence administrator permissions, verified at the resolver level.
• Scope-limited permissions: Each App requests only the minimum Atlassian API scopes required for its functionality. Permissions are declared in the App manifest and reviewed by Atlassian during marketplace approval.
• No cross-site access: Each App installation is isolated to its Atlassian site. There is no mechanism for data access across sites.

2.3 Permission Scopes by App

App	Scopes
CostLens	read:jira-work, read:jira-user, read:project:jira, storage:app, report:personal-data
GuardRail	read:jira-work, read:jira-user, read:audit-log:jira, storage:app, report:personal-data
SmartTag for Jira	read:jira-work, write:jira-work, storage:app, report:personal-data
SmartTag for Confluence	read:confluence-content.all, write:confluence-content, read:confluence-space.summary, storage:app, report:personal-data
PagePulse	read:confluence-content.all, read:confluence-content.summary, read:confluence-space.summary, read:page:confluence, read:space:confluence, read:confluence-user, storage:app, report:personal-data
ServiceCost	read:jira-work, read:jira-user, storage:app, report:personal-data

3. Data Protection Measures

3.1 SQL Injection Prevention

All database queries use parameterized bind parameters exclusively. No SQL query in any App concatenates user input into query strings.

```

// Example pattern used throughout all Apps

sql.prepare("SELECT * FROM table WHERE id = ?").execute([userInput]);

```

LIMIT clauses use parseInt() for safe inline integer casting. All DDL statements use executeDDL() and contain no user-supplied values.

3.2 JQL Injection Prevention

All Jira Query Language (JQL) queries use the escapeJql() utility function to sanitize user-supplied values before inclusion in queries. Atlassian's route tagged template literal is used for all REST API path construction.

3.3 CSV Formula Injection Prevention

All CSV export functionality uses the escapeCSV() utility function, which prefixes potentially dangerous characters (=, +, -, @, \t) to prevent formula injection attacks when exported files are opened in spreadsheet applications.

3.4 Input Validation and Sanitization

• Content truncation: User-supplied content is truncated to safe limits (500 characters for summaries, 2,000 characters for descriptions, 100,000 characters for full content) before processing.
• AI prompt safety: Apps using AI-based analysis (SmartTag) truncate all input before inclusion in prompts to prevent prompt injection and resource exhaustion.
• Regex safety: Regular expressions used for pattern matching (e.g., GuardRail's security rules, SmartTag's SSN detection) are hardened against ReDoS attacks with input length limits and pattern complexity constraints.
• IP address validation: GuardRail validates IP address formats before storage and comparison.

3.5 Cross-Site Scripting (XSS) Prevention

• All Apps use React 19 for frontend rendering, which escapes output by default
• Frontend content is rendered within Forge's sandboxed iframe
• Content Security Policy is enforced by the Forge platform

4. Error Tracking and Monitoring

4.1 Sentry Integration

All Apps use Sentry for error monitoring and performance analytics. This is the only external service any App communicates with.

4.2 No PII in Error Tracking

Our Sentry integration is specifically designed to exclude all personally identifiable information:

• Manifest declaration: All Apps declare Sentry with inScopeEUD: false, meaning End User Data is explicitly excluded
• Envelope-based transport: Error data is sent using Sentry's envelope format with only the plugin name as identifier
• No user context: Error reports do not include user IDs, email addresses, IP addresses, or any account information
• No request bodies: Request payloads and response bodies are not included in error reports
• Stack traces only: Error reports contain only stack traces, error messages, and app performance metrics

5. Privacy API Compliance

5.1 Implementation

All six Apps implement Atlassian's Privacy API with the following components:

• report:personal-data scope: Declared in every App manifest
• Weekly poll trigger: Runs weekly to check for pending data subject requests
• Daily processing trigger: Runs daily to process queued privacy actions (updates and deletions)
• Privacy queue: Database table for tracking and processing privacy requests

5.2 Data Subject Request Handling

When Atlassian receives a data access, rectification, or deletion request:

• The weekly poll identifies accounts requiring action
• Requests are queued in the App's privacy processing queue
• The daily trigger processes pending requests
• Update requests refresh stored references
• Deletion requests remove or anonymize all associated data

6. Performance and Availability Security

6.1 Resource Exhaustion Prevention

• Batch concurrency limits: All batch operations are limited to 10 concurrent requests
• SQL IN clause chunking: Large queries are chunked into groups of 200 to prevent query size limits
• Content size limits: Content processing is capped at 100,000 characters
• Graph computation caps: Knowledge graph and lifecycle computations are capped at 500 nodes to prevent O(n^2) resource exhaustion
• Timeout configuration: All scheduled triggers and background functions have explicit timeout values (300-600 seconds)

6.2 N+1 Query Prevention

All Apps use batch DAO methods to prevent N+1 query patterns, ensuring database performance remains stable as data volumes grow.

7. Secure Development Practices

7.1 Code Quality

• Comprehensive test coverage: 2,800+ automated tests across all Apps
• Unit test isolation: All tests use mock isolation with clearMocks, resetMocks, and restoreMocks
• Linting and static analysis: Code is subject to automated quality checks

7.2 Dependency Management

• Dependencies are regularly audited for known vulnerabilities
• Lock files (package-lock.json) are committed and used for deterministic builds
• Node.js runtime is managed by Atlassian (currently Node.js 22.x LTS)

7.3 Forge Security Review

All Apps undergo Atlassian's security review process as part of Marketplace publication, which includes:

• Permission scope review
• External egress verification
• Security best practice compliance

8. Vulnerability Management

8.1 Reporting Vulnerabilities

If you discover a security vulnerability in any of our Apps, please report it to:

Email: security@apps.szamuraj.com

Please include:

• A description of the vulnerability
• Steps to reproduce
• Potential impact assessment
• Your contact information for follow-up

8.2 Response Process

Upon receiving a vulnerability report:

• Acknowledgment: We will acknowledge receipt within 2 business days
• Assessment: We will assess the severity and impact within 5 business days
• Remediation: Critical vulnerabilities will be patched within 7 days; high-severity within 14 days; medium within 30 days
• Notification: Affected customers will be notified of material vulnerabilities and their resolution
• Disclosure: We support coordinated vulnerability disclosure

8.3 Severity Classification

Severity	Description	Target Resolution
Critical	Active exploitation possible, data breach risk	7 days
High	Exploitable with limited prerequisites	14 days
Medium	Exploitable under specific conditions	30 days
Low	Minimal impact, defense-in-depth concern	Next release

9. Incident Response

9.1 Incident Response Contact

Email: security@apps.szamuraj.com

Escalation: support@banhidy.hu

9.2 Incident Response Process

In the event of a security incident:

• Detection and Analysis: Identify scope and impact using Sentry monitoring and Forge logs
• Containment: If necessary, request Atlassian disable the affected App to prevent further impact
• Eradication: Deploy a patched version through Forge deployment
• Recovery: Verify the fix and restore normal operation
• Notification: Notify affected customers within 72 hours of confirmed incidents involving their data, in accordance with GDPR Article 33
• Post-Incident Review: Conduct a root cause analysis and implement preventive measures

10. Compliance

10.1 Data Protection

• GDPR: All Apps comply with GDPR requirements through Privacy API implementation, data minimization, and the absence of PII in stored data
• Data Residency: Managed by Atlassian's platform-level controls

10.2 Framework Support (GuardRail)

GuardRail specifically supports compliance monitoring for:

• HIPAA security rule controls
• PCI DSS requirements
• Custom compliance frameworks

Note: GuardRail helps monitor and report on compliance posture; it is not a compliance certification for your organization.

11. Contact Information

For security-related inquiries:

Samurai Labs

Security Team: security@apps.szamuraj.com

General Contact: support@banhidy.hu

Website: apps.szamuraj.com

*This Security Statement is reviewed and updated at least annually. The "Last Updated" date reflects the most recent review.*

Last updated: March 5, 2026