Security Policy: Reporting Vulnerabilities

Security matters to me. SynthScript is a one-person company: I, Christoph Kretschmer, am behind every product. If you find a security vulnerability in one of my products, I'd be glad to hear about it. This page explains how to report it, what you can expect from me, and the rules for testing.

1. Scope

In scope

Software and cloud services

• PxlMonk: RAW editor for Windows, macOS and Linux, including installer, update and licensing features
• PxlShare: cloud service that lets photographers share their photos professionally with their clients
• Confluence apps on the Atlassian Marketplace: TileMenu for Confluence, Easy UML Editor for Confluence, Inline Notes for Confluence
• Mobile apps for iOS and Android: DevProCo, Easy Light Meter, EasyRow, Kroku, TrauerKompass, Wombatistan (once released)

Websites for my products, including download pages

• synthscript.de
• pxlmonk.com, docs.pxlmonk.com, downloads.pxlmonk.com
• pxlshare.com, wombatistan.de, trauerkompass-app.de

This policy covers versions that still receive security updates (see section 9). You're welcome to report issues in older versions too, but fixes only go into supported versions.

Out of scope

• Third-party platforms and services that distribute or run my products, e.g. Atlassian (the Marketplace and Confluence itself), Apple App Store, Google Play, hosting, CDN, payment and licensing providers. Please report issues there directly to the respective provider. If such an issue also affects my product, feel free to tell me as well.
• My eBay shop and merch shop. They run entirely on the eBay and Printful platforms.
• The server administration panel (customer.synthscript.de) as well as customer websites and services hosted on my infrastructure.
• Domains and services not listed above, even if they share the same infrastructure.
• These testing methods: social engineering and phishing (against me, customers or service providers), physical attacks, denial-of-service and load testing, and spam via contact or sign-up forms.

Usually not a vulnerability

I'm happy to receive these reports, but I only treat them as vulnerabilities if you demonstrate a concrete impact:

• missing security headers or cookie flags without demonstrated exploitability
• software version, banner or error message disclosure without further impact
• clickjacking on pages without security-relevant actions
• SPF, DKIM or DMARC configuration
• self-XSS and logout CSRF
• raw output of automated scanners without proof
• issues that require a rooted or jailbroken device, or physical access to an unlocked device
• issues that only affect outdated, unsupported browsers or operating systems

2. How to report a vulnerability

Email security@synthscript.de. These details help:

• affected product and version, or the URL for web services
• platform: operating system, device or browser
• description of the vulnerability and its type, e.g. XSS or insecure storage
• steps to reproduce
• impact: what could an attacker achieve?
• proof of concept, e.g. screenshots, a video or a script. Please keep it minimal and free of real third-party data.
• whether and under which name you'd like to be credited (see section 8)

It doesn't have to be complete. A short report is better than none.

Languages: English or German.

Encryption: I don't currently offer a PGP key. If you need to share particularly sensitive details, send me a short message without details first, and we'll agree on a secure channel.

Confidentiality: Please don't share the vulnerability with anyone else until the coordinated publication (section 4).

Your data: I only use your information to handle your report. See the privacy policy for details.

3. What you can expect from me

Business days are Monday to Friday, excluding public holidays in Baden-Württemberg, Germany.

Please bear with me: I work alone and can't offer round-the-clock availability. Vacations or illness may cause delays. If you haven't heard back within 5 business days, please follow up at security@synthscript.de, and additionally at info@synthscript.de in case your email got lost.

For apps, when an update reaches users also depends on review by Apple, Google or Atlassian.

If I see things differently from you, for example regarding severity or whether something is a vulnerability at all, I'll tell you openly and explain why.

4. Coordinated disclosure process

1. Default deadline: 90 days from receipt of your report. I aim to fix the issue within this time.
2. Joint publication: Once an update is available, we agree on a date. I then publish a security advisory (section 6), and you're free to publish your findings.
3. Extensions only by agreement: If a fix is particularly complex, I'll ask you for more time and explain why. I won't extend the deadline unilaterally.
4. Earlier publication: If the vulnerability is already being actively exploited, I may inform affected users before a fix is available. Where possible, I'll let you know beforehand.
5. After the deadline: If the deadline passes without an agreement, you're free to publish. Please give me at least 7 days' notice, and don't publish third-party data.

5. Reporting to authorities and third parties

Legal reporting obligation: As a manufacturer, I'm required under the EU Cyber Resilience Act (Art. 14 of Regulation (EU) 2024/2847) to report actively exploited vulnerabilities and severe security incidents affecting my products within the legal deadlines. Reports go via ENISA's Single Reporting Platform to the BSI (Germany's Federal Office for Information Security) as the competent CSIRT and to ENISA. I inform affected users about what happened and what they can do. This obligation applies regardless of the agreed disclosure timeline. A report to the authorities is not a publication, though.

If a report to the authorities includes information from your report, I limit it to the necessary technical details. I only share your name with your consent.

Third-party components: If a vulnerability affects a library or other component I use, such as an open-source library, I forward it to its maintainers. I'll let you know, and on request I'll credit you there as the finder.

6. Security advisories

I publish security advisories for fixed vulnerabilities at synthscript.de/security/advisories. Each advisory includes:

• a description of the vulnerability
• the affected products and versions
• the severity (CVSS)
• the fix or a workaround
• credits, on request

CVE IDs: For relevant vulnerabilities, I request a CVE ID via MITRE. If you've already requested one or plan to, please coordinate with me to avoid duplicate entries.

7. Safe harbor for security researchers

If you act in good faith and follow the rules below, I commit to the following:

• I won't file a criminal complaint or request prosecution against you.
• I won't pursue civil claims against you, such as injunctions or damages.
• I won't pursue violations of my terms of use or license terms, as far as they were necessary for your research. This includes, for example, analysing PxlMonk for security research purposes.

What I can't promise: I can only speak for myself. I can't guarantee you immunity from prosecution. Under German law, some offences, e.g. under sections 202a–202c, 303a and 303b of the German Criminal Code (StGB), can be prosecuted by the public prosecutor without my complaint if there is a special public interest. This policy also doesn't bind third parties, such as Atlassian, Apple, Google, hosting providers or other users. If anyone takes action against you over research that complied with this policy, I'll confirm in writing on request that you acted in accordance with it.

The rules:

1. Test minimally. Do only what's needed to demonstrate the vulnerability.
2. Use only your own accounts and data. Use your own test accounts or accounts whose owners have explicitly agreed.
3. No third-party data. Don't access, copy or store personal or confidential data of other people. If you come across such data by accident, stop immediately, let me know, and delete whatever you have.
4. Don't delete or modify anything. Don't delete, modify or encrypt data, and don't leave persistent changes such as backdoors or web shells.
5. Don't exploit beyond proof. No pivoting to other systems and no privilege escalation beyond a plain demonstration.
6. Don't disrupt operations. No denial-of-service testing. Keep automated scans low-volume.
7. No social engineering, no phishing, no physical attacks.
8. Keep it confidential until coordinated publication (section 4).
9. No conditions. Don't tie your report to demands such as payment.

If you're unsure whether something is allowed, ask me first at security@synthscript.de.

8. Acknowledgements

There is no bug bounty program and no monetary rewards. On request, however, I'll credit you in the advisory for the vulnerability, by name or pseudonym and optionally with a link. If you'd rather stay anonymous, that's absolutely fine.

9. Support period

Which product versions receive security updates, and for how long, is listed at synthscript.de/security/support.

10. Policy versions

I may update this policy over time. For any report, the version published at the time of the report applies. If the German and English versions differ, the German version prevails.

Responsible: SynthScript, owner Christoph Kretschmer, Hornisgrindestraße 9, 77855 Achern, Germany. More details are in the legal notice.