Security

Contact Dewiride through its website. Never report a security problem in public, such as on social media or in a public forum, before it is fixed. If your organization runs Techolm on its own servers, it can also report through its usual contact at Dewiride.

Please include:

• the page, tool or release that is affected;
• the steps to reproduce the problem, or a proof of concept: a small demonstration that shows it;
• the impact you expect;
• how we can reach you.

Test only with your own data. Do not degrade the site for other people: no denial-of-service attacks, no spam and no high-volume scanning. Give us time to release a fix before you publish any details.

We acknowledge your report, confirm whether it is a vulnerability and keep you updated until it is resolved. We rate its severity with the Common Vulnerability Scoring System (CVSS), a public standard for rating how serious a security problem is. Our targets for releasing a fix are:

• critical: within 7 days;
• high: within 30 days;
• medium and low: in a regularly planned release.

We tell you when the fix is released and, if you wish, credit you for the report.

Reports are welcome for the public website at https://techolm.com and for the latest release of Techolm that organizations run on their own servers. Older releases of those installations are not supported: Dewiride updates each installation to the latest release, and security fixes reach installations as new releases.

These protections are part of how Techolm is built:

• every software dependency of our code and container images is pinned to an exact version that has been public for at least 7 days, and security fixes are taken without that wait;
• the server that runs https://techolm.com installs its operating system's and Docker's updates every night, without that wait, and holds back new major versions of Docker until we have reviewed them;
• a known vulnerability of any severity in a dependency fails our automated checks;
• automated scans look for vulnerable packages, leaked secrets and unsafe settings in our build automation on every change and every day;
• automated browser tests fail if a page sends a request to any other website;
• files you give a tool are identified from their first bytes, never from their name alone;
• HTML that a tool previews from your file is cleaned first and shown in a sandboxed frame, an isolated area of the page where scripts cannot run.