1. Sources of vulnerabilities
| Source | Status |
|---|---|
Public vulnerability disclosure program (/security, /.well-known/security.txt) |
In place |
| Automatic OS security updates (unattended-upgrades) | In place |
| Hostinger's server malware scanner (Monarx) | In place (alert routing to be confirmed) |
| Security regression tests in the test suite | In place |
| GitHub Dependabot alerts and update pull requests (Composer, npm) | Commitment, target 2026-10-15 |
composer audit in deploy and CI |
Commitment, target 2026-11-30 |
| Monthly host scan (for example Lynis) with results in the register | Commitment, target 2026-11-30 |
| Security advisories feeds: CISA KEV, CERT.br, GitHub advisories, PHP, Laravel, PostgreSQL | Commitment, target 2026-10-31 (policy 00) |
| Independent penetration test | Commitment, before enforcing blocking for an external customer, target 2027-03-31 |
| Published threat model of the product | Commitment, target 2026-12-31 (listed as a next step on /secure-by-design) |
No bug bounty is offered.
2. Vulnerability disclosure program (public, in place)
As published on /security:
- Reports go to the contact in
security.txt. - Scope: the site and panel at semantiqwall.com, the API used by customers' agents, and the PHP and TypeScript SDKs. Out of scope: third-party services we use and customers' systems.
- We acknowledge receipt within 3 business days, keep the reporter informed until the fix and agree the disclosure date with them.
- Good-faith research within the rules is authorized; we will not take legal action and will credit the reporter if they wish.
Every report is recorded in the security register, even if rejected.
3. Prioritization
Each vulnerability is rated by:
- CVSS base score (v4.0 when available, otherwise v3.1), from the advisory or our own assessment;
- Known exploitation - listed in the CISA Known Exploited Vulnerabilities (KEV) catalog, or evidence of exploitation in the wild;
- Our exposure - is the vulnerable code reachable in our deployment, from the internet, before or after login?
The final priority can go up with known exploitation or exposure, and down only with a written reason (for example, the vulnerable function is not used).
4. Remediation deadlines
| Priority | Typical criteria | Fix or mitigate within |
|---|---|---|
| Critical | CVSS 9.0-10, or in CISA KEV and reachable | 7 days (72 hours if actively exploited against us) |
| High | CVSS 7.0-8.9 | 30 days |
| Medium | CVSS 4.0-6.9 | 90 days |
| Low | CVSS below 4.0 | Next planned update |
A deadline that cannot be met needs an exception (policy 00) with a mitigation in place. Fixes go through the normal change process or, if urgent, the emergency path (policy 03).
5. Patching cadence
- Operating system: security updates from Ubuntu install automatically every day; the Founder checks weekly whether a reboot is pending and reboots in a low-traffic window.
- Other server software (PHP, PostgreSQL, Caddy, Redis and packages from other repositories): checked and updated at least monthly, and within section 4 deadlines when an advisory applies.
- Application dependencies: reviewed at least monthly (policy 03).
- Founder's devices: automatic updates on (policy 10).
6. Malware protection
- Server: Hostinger's Monarx scanner; only code from the repository runs on the server; uploaded vendor evidence files are stored outside the public web folder and served as downloads with a restrictive content policy.
- Endpoints: operating-system anti-malware on (policy 10).
- Commitment: confirm who receives Monarx alerts and how often it updates (owner: Founder, target 2026-10-15).
7. Advisories and CVE
As committed on /security: when a critical or high vulnerability affected customers, we publish an advisory after the fix with the weakness type (CWE), what was affected, since when and what customers need to do. For vulnerabilities in something customers install (the SDKs), or when the CVE program rules call for it, we request a CVE identifier and supply the correct CWE and CPE data. Advisories published so far: none.
8. Tracking and metrics
The register tracks each vulnerability from discovery to closure. Reviewed monthly:
- open vulnerabilities by priority and age;
- share fixed within deadline;
- time from report to acknowledgement (target: 3 business days).