TRUST AND SECURITY
Vulnerability management and responsible disclosure
Qity scans continuously rather than annually, publishes the remediation targets it holds itself to, and accepts disclosure reports at security@qity.be without an NDA.
Code, dependencies, containers, and cloud configuration are scanned on every change, not on a schedule.
The Aikido audit report is generated on request and requires no NDA. It reflects the current state, not a point in the past.
Good-faith research reported to security@qity.be will not be met with legal action from Qity.
Where findings come from
A vulnerability management programme is only as good as its inputs. Qity draws on five, and every finding lands in the same triage queue regardless of source.
| Source | What it produces |
|---|---|
| Continuous scanning | Aikido runs static analysis, dependency and licence scanning, secrets detection, container scanning, infrastructure-as-code checks, and cloud posture monitoring across the Qity codebase and cloud environment. |
| Software bills of materials | Machine-readable SBOMs are produced per release, so a newly published CVE can be matched to affected versions rather than guessed at. Available to customers on request. |
| Atlassian | Atlassian Marketplace Security tickets, ECOHELP escalations, and platform advisories reach the named Qity security contact registered on the Atlassian ecosystem. |
| External reports | Customers, security researchers, penetration testers, and suppliers reporting to security@qity.be. |
| Threat intelligence | Collected and applied at strategic, tactical, and operational levels under the Threat Intelligence Policy. |
Remediation targets
Qity apps are distributed through the Atlassian Marketplace, so Qity holds itself to the Atlassian Security Bug Fix Policy timelines for cloud applications. These are maximum times to fix from the point a vulnerability is confirmed, not targets for a first response.
| Severity | Time to fix | Typical handling |
|---|---|---|
| CRITICAL | 10 days | Treated as an incident. Containment first, then a fix, with a customer advisory where there is customer impact or required customer action. |
| HIGH | 4 weeks | Scheduled into the next release cycle, with change control and verification evidence. |
| MEDIUM | 12 weeks | Planned remediation, tracked to closure. |
| LOW | 25 weeks | Planned remediation, tracked to closure. |
Where a vulnerability shows evidence of active exploitation, it stops being a vulnerability and enters the security incident procedure immediately, with the 24-hour Atlassian notification and the containment steps that follow.
How a fix reaches you
Remediation that affects released software, production configuration, customer environments, validation status, or controlled QMS records is managed through change control. That matters for a regulated customer: a security patch that arrives outside change control is a patch you cannot evidence to an auditor.
- The finding is triaged, given a severity, and linked to affected products and versions using the SBOM.
- The fix is implemented, reviewed, and verified with test and release evidence.
- Where the root cause or the recurrence risk warrants it, a CAPA is raised.
- Release notes on qity.support record what changed.
Reporting a vulnerability
Write to security@qity.be. There is no bug bounty and no NDA requirement. What helps a triage move quickly:
- The affected app or system, and the version if you have it.
- Steps to reproduce, and what you observed against what you expected.
- Whether you believe personal data or end user data is exposed.
- Whether you have shared the finding with anyone else, and any date by which you plan to publish.
Qity asks reporters to give a reasonable window for remediation before publishing, to avoid accessing or modifying data belonging to other customers, and to avoid degrading the service for others. Qity will acknowledge receipt, keep the reporter informed of triage and remediation, and credit the reporter in the release notes where they wish to be named.
Vulnerabilities in a Qity Marketplace app can also be reported to Atlassian, who will raise a Marketplace Security ticket against Qity. Both routes reach the same team.
Supporting controls
Vulnerability management is one of 28 subject policies beneath the Information Security Policy. The ones a security reviewer usually pairs with it are the Technical Vulnerability Management Policy, the Configuration Management Policy for secure baselines, the Network Security Policy for segregation and monitoring, the Access Control Policy for who can change what, the Information Security Policy for Supplier Relationships for third-party risk, and the Threat Intelligence Policy.
