Security at ChefStackZ.

1. Scope & hosting architecture

ChefStackZ publishes apps on the Atlassian Marketplace. This policy describes the security posture of every product we ship and where the boundaries of our responsibility sit. We are explicit about scope so customers, auditors, and procurement teams can map our controls to theirs.

Forge-hosted Jira Cloud apps

The following apps run end-to-end on Atlassian Forge — Atlassian-managed AWS compute, Atlassian-managed storage, and Atlassian-managed network egress:

• Project Planning for Jira
• Advanced Checklists
• Poker Planning Session
• Dependency Graph for Jira
• Scoring Tool for Methodologies
• PM Scoring for Jira

For these apps, customer data never leaves the customer's Atlassian tenant. We hold no shadow copy on any ChefStackZ-operated server because we do not operate any.

Hybrid: ChefStackZ Connector for Zammad

This product has two halves: a Forge app (Jira side, same model as above) and a Docker sidecar that customers install alongside their self-hosted Zammad helpdesk. The sidecar runs on customer-controlled infrastructure inside the customer's network. ChefStackZ is not a data processor for Zammad ticket content on the customer-hosted side — that data never reaches our infrastructure. See section 11 for the sidecar-specific security model.

2. Atlassian Forge shared responsibility

Forge is Atlassian's serverless app platform. By building on Forge we inherit large parts of the security model directly from Atlassian. We mirror Atlassian's published shared-responsibility breakdown rather than reinvent it.

What Atlassian handles

• Runtime sandboxing and per-tenant isolation
• TLS termination, HSTS, and certificate management
• Encryption at rest of Forge Key-Value Store, Custom Entity Store, and Forge SQL
• Egress proxy: outbound network calls go only to domains declared in our manifest
• Platform vulnerability patching and infrastructure incident response
• Atlassian Account identity, MFA, SSO, and customer-side admin controls

What ChefStackZ handles

• Secure-by-default code: input validation, output encoding, authorisation checks
• Minimised OAuth scopes — declared per app in manifest.yml and reviewed every release
• Secret handling via the Forge secret store; never embedded in source or logs
• Tenant-keyed in-memory state — no module-level globals that span installations
• App-level incident response, customer notification, and post-mortem
• Compliance with Atlassian's Bug Fix Policy and Ecoscanner SLAs

3. Data handling, storage & retention

We collect the minimum data each product needs to function. We do not sell, rent, or trade customer data. We do not use customer data to train AI models.

Where data lives

• App configuration, link caches, audit log entries, layout coordinates, and per-issue scoring data are persisted in Forge Key-Value Store, scoped per installation.
• Issue content (summaries, descriptions, comments, attachments) is read on demand from Jira via the Forge runtime and is not mirrored to a separate database.
• Forge KVS data is encrypted at rest by Atlassian and inherits the customer's data-residency setting.

Retention

• Operational data persists for the lifetime of the installation.
• TTL'd caches (e.g. ticket title in the Zammad Connector, search results) are bounded and self-expire — typically 24 hours or less.
• Audit logs are append-only and bounded to the most recent N entries per installation.

Deletion

When an admin uninstalls one of our apps, the Forge platform's lifecycle handlers trigger app-side cleanup. We delete configuration, layout coordinates, scoring data, identity mappings, and audit logs as part of that handler. Atlassian's platform additionally purges storage.app entries associated with the install. Customers may also exercise GDPR right-of-erasure ahead of uninstall — see section 9.

4. Encryption & secrets

• In transit: TLS 1.2+ on all traffic. HSTS enforced on chefstackz.com and on Forge endpoints.
• At rest: Forge Key-Value Store data is encrypted at rest by Atlassian (AES-256). Customers inherit the Atlassian region they have configured for their site.
• Secrets: API tokens, signing keys, and shared secrets are stored exclusively via the Forge secret store. We never bake secrets into source, container images, or marketing assets. Secret values are redacted from any application log path.
• Cryptographic primitives in use: HMAC-SHA256 for envelope signatures (Zammad sidecar ↔ Forge), SHA-256 body integrity, crypto.timingSafeEqual for comparison, crypto.randomBytes (32 bytes) for secret generation.

5. Authentication & access

Customer-facing authentication

We do not handle passwords. Customer authentication is handled by Atlassian Account, including MFA, SSO, and customer-administered access policies.

OAuth scope minimisation

Each product declares the smallest set of Forge OAuth scopes required for its features. Scope additions are reviewed every release and require an explicit re-consent prompt to the customer admin. Read-only scopes are preferred wherever possible. None of our apps request manage:jira-configuration or any Confluence scope.

Multi-tenant isolation

Storage writes are scoped per installation by Forge's per-install namespace. Our schema validators additionally require an installId in every payload and reject mismatches. Cross-tenant test tiers in CI assert that install-A data never appears in install-B reads, including audit logs and caches.

Internal access

• Production deploys are gated through Forge environment promotion (development → staging → production) with peer-reviewed pull requests.
• MFA is required on all GitHub and Atlassian Marketplace partner accounts.
• Workstations enforce full-disk encryption and password-manager use.

6. Sub-processors & data residency

We keep our sub-processor list deliberately short. The current list:

We do not currently use third-party analytics, third-party error trackers, third-party CDNs for app code, or third-party LLM providers in any Forge-hosted product. If this changes we will update this list and notify existing customers before any new sub-processor begins processing customer data.

Data residency

Forge data residency follows your Atlassian site. Atlassian provides pinned regions including the European Union, United States, Australia, Canada, Germany, India, Japan, Singapore, South Korea, Switzerland, and the United Kingdom. Our apps store all in-scope data in Atlassian's hosted-storage tier — we do not move data out of region.

7. Vulnerability disclosure & bug-fix SLAs

We follow coordinated vulnerability disclosure. Report security issues to security@chefstackz.com. PGP key available on request.

Our commitments

• Acknowledge every report within two business days.
• Triage within ten business days.
• Honour a 90-day default coordinated-disclosure window before public disclosure, with extensions when a fix needs more time.
• Credit researchers in our release notes when they wish to be credited.

Atlassian Marketplace bug-fix SLAs

We commit to the published Atlassian Marketplace Cloud bug-fix policy:

Reports may also be submitted to Atlassian's Marketplace Security Bug Bounty programme via bugcrowd.com/atlassianapps. ChefStackZ is enrolling in the Marketplace Bug Bounty programme during 2026 in line with Atlassian's published timeline.

8. Incident response

We maintain a written incident-response plan covering detection, triage, containment, eradication, recovery, and post-incident review. The plan is reviewed at least annually and rehearsed via tabletop exercises.

In the event of a confirmed security incident affecting customer data, we will notify affected customers without undue delay and, where the incident concerns personal data, within 72 hours of becoming aware as required by GDPR Article 33. Notifications are sent to the technical contact registered on the Atlassian Marketplace listing and, where practical, an in-app notice and a status post at chefstackz.com.

We publish post-incident summaries for customer-impacting incidents once the root cause has been remediated.

9. Privacy, GDPR & DPA

For Forge-hosted apps, ChefStackZ acts as a data processor on behalf of the customer (the controller) for the limited operational data we persist in Forge storage. For the Zammad Connector sidecar, ChefStackZ is not a processor of Zammad ticket content because that data never crosses the customer's network boundary into our infrastructure.

Data Processing Addendum

A GDPR Article 28 DPA aligned with the European Commission's 2021 Standard Contractual Clauses is available on request. Email legal@chefstackz.com with your legal entity name and we will return a counter-signed copy.

Customer data rights

Customers and end users may exercise GDPR Articles 15–22 rights — access, rectification, erasure, restriction, portability, and objection — by writing to privacy@chefstackz.com. We will respond within 30 days. Authenticated bulk export and deletion are exposed via product resolvers; see each product's documentation for the specific endpoint.

See our Privacy Policy for the full notice.

10. Secure development & operations

Secure development lifecycle

• Mandatory peer review on every pull request via GitHub branch protection.
• Automated dependency scanning (Dependabot) on every push, with weekly batch upgrades.
• Static analysis (CodeQL) covering JavaScript and TypeScript on every pull request.
• Atlassian Ecoscanner integration so platform-side detections are surfaced to us automatically.
• OWASP Top 10 review applied to every product feature touching authentication, authorisation, or data flow.

Change management

Releases follow Forge's environment promotion model: development → staging → production. Production deploys require a peer-approved pull request and a green CI run. Every release is tagged in Git and recorded in the Marketplace listing's version history.

Logging & monitoring

We use the Forge platform's built-in request, response, and exception logs. Application-level logs never include customer ticket content, comment bodies, attachment bytes, customer email addresses, OAuth tokens, or any field marked sensitive. A property test in CI asserts that secret-redaction holds even when inputs deliberately contain those substrings.

11. Self-hosted Zammad Connector sidecar

The ChefStackZ Connector for Zammad runs a Docker sidecar inside the customer's network alongside the customer's Zammad instance. The customer is the operator of that container; ChefStackZ does not have remote access to it.

What stays inside the customer's network

• All Zammad ticket bodies, comments, attachments, and customer PII.
• Zammad API tokens.
• Direct connections from agents' browsers to the linking UI.

Cross-boundary controls

• Every payload from the sidecar to Forge is signed with HMAC-SHA256 over install_id|timestamp|nonce|body_sha256 and verified in constant time.
• 5-minute timestamp window plus 6-minute nonce TTL block replay attacks.
• The Forge half declares no external.fetch.backend permission — the Forge runtime cannot reach into the customer network.
• Privacy mode (off by default) strips ticket titles, article bodies, and attachment bytes at the sidecar boundary before any payload is signed and posted to Forge.

Image distribution

Sidecar images are distributed as versioned tarballs from chefstackz.com. Image digests are published in the release notes so operators can verify integrity. The sidecar fails fast on missing or invalid environment configuration in production and never starts with an empty FORGE_SHARED_SECRET.

The full operator security model — including rate limits, security headers, input validation, and secret redaction — is documented at Connector security model.

12. AI / LLM use disclosure

None of our currently shipping Forge-hosted apps embed third-party LLM inference, send customer data to any AI provider, or use customer data to train AI models. Search and filtering inside our apps is implemented with deterministic algorithms.

If a future feature introduces AI inference we will publish an updated disclosure here ahead of release, name the provider, list the data categories sent, confirm the no-training contractual position, and classify the feature against the EU AI Act risk tiers (we expect "minimal risk" for any productivity-tooling use case).

13. Certifications & roadmap

We list only what we have today, plus a public roadmap for what we are working toward. We do not claim certifications we have not yet earned.

In place today

• Atlassian Marketplace Bug Fix Policy compliance (Cloud bug-fix SLAs above).
• Atlassian Ecoscanner enrolment for platform-side vulnerability detection.
• GDPR-aligned DPA available on request.

Roadmap

• Atlassian Marketplace Bug Bounty programme — enrolment in 2026.
• Atlassian Cloud Fortified — targeting H2 2026 once paid-listing prerequisites are met.
• SOC 2 Type 1 — scoping in 2026 with a target audit window thereafter.
• ISO/IEC 27001:2022 — under evaluation as a follow-on to SOC 2.

14. Contact

• Vulnerability reports: security@chefstackz.com (PGP available on request) or via bugcrowd.com/atlassianapps.
• Privacy / GDPR / DPA: privacy@chefstackz.com
• Legal: legal@chefstackz.com
• General support: support@chefstackz.com

This policy is reviewed at least annually and updated whenever a material change to our security or privacy posture warrants it. Material changes are communicated to existing customers ahead of taking effect.