Security
Disclosure policy.
Working with the research community to keep our own systems honest.
ASEC appreciates investigative work into security vulnerabilities carried out by well-intentioned, ethical security researchers. We are committed to investigating and resolving security issues in our platform and services together with the security community. This page sets out how we work with researchers to improve our security.
Scope
A vulnerability in an ASEC product or service is in scope when:
- It has not been reported before or already found by our own researchers.
- It can be shown to have a real impact on ASEC, its users or its customers if a malicious actor exploited it. Theoretical impact is not considered in scope.
In-scope and out-of-scope assets. This list is not exhaustive and may change at any time.
asec.io(in scope)www.asec.io(in scope)shop.asec.io(out of scope, hosted by Shopify)
The following are not in scope. Please don't report them:
- Issues in third-party services that are not direct application dependencies and have no direct ASEC user impact. These are treated as informative.
- Open redirects without a demonstrated further impact, such as stealing auth tokens.
- Clickjacking on pages with no sensitive actions.
- Unauthenticated, logout or login CSRF.
- Attacks that require a MITM position or physical access to a user's device.
- Known vulnerable libraries without a working proof of concept.
- Volumetric denial of service, meaning simply overwhelming our services with requests.
- TLS configuration weaknesses, such as "weak" cipher suite support.
- Host header injection where the resulting impact is minimal.
Bug bounty
ASEC does not run a paid bug bounty. We still want to thank researchers who take the time to investigate and report issues under this policy, so reporters of qualifying vulnerabilities are offered an ASEC reward. Swag ships within North America only, and no monetary bounties are offered.
Reporting a vulnerability
If you believe you have found an in-scope vulnerability, emailsecurity@asec.io with as much detail as you can. The more you give us, the faster we can validate it. Please include:
- A short title for the vulnerability.
- The asset, website or page affected.
- The type or category of weakness, for example XSS or SQL injection.
- Estimated severity (low, medium, high, critical) using CVSS.
- A full description, including steps to reproduce.
- The impact an attacker could achieve.
- Time spent finding the vulnerability.
Encryption is not required. If your report needs it, say so in a first plain email (with no sensitive detail) and we will arrange a secure channel.
What to expect
After your first email to security@asec.io you will get an acknowledgement from the ASEC security team, usually within 24 hours. We then triage the report and reply as soon as we can to confirm whether we need more information, whether it qualifies under the scope above, or whether it is a duplicate. Fixes are prioritised by severity and complexity of exploitation.
Triage and remediation can take time. You are welcome to ask for a status update, but please keep it to once every 14 days so the team can stay focused on the reports.
We will tell you when the issue is resolved or the fix is scheduled, and ask you to confirm the fix covers it. We will also invite feedback on the process, which we keep in confidence, and ask how you would like to be credited on this page.
Guidance
Security researchers must not:
- Access more data than needed. Two or three records is enough to demonstrate most issues, such as enumeration or a direct object reference.
- Violate the privacy of ASEC users, staff, contractors or systems, for example by sharing, redistributing or not properly securing data retrieved from our systems.
- Discuss vulnerabilities or their details through any channel other than the one in this policy, or with anyone other than your ASEC security contact.
- Modify data in our systems or services that is not your own.
- Disrupt our services or systems.
- Disclose a vulnerability in ASEC systems to third parties or the public before ASEC confirms it has been fixed. You may notify a third party the issue directly concerns, for example the maintainer of an affected library, but do not reference ASEC's specific vulnerability. If you are unsure, email security@asec.io.
Please securely delete any data retrieved during research as soon as you no longer need it, and at the latest one month after the vulnerability is resolved.
If you are unsure whether something you plan to do is acceptable, ask the security team first at security@asec.io. Don't include sensitive details in that first message.
Legal
This policy follows common good practice among well-intentioned security researchers. It does not permit you to act in any way that breaks the law or puts ASEC in breach of its legal obligations. ASEC will not seek prosecution of any researcher who reports a vulnerability on an in-scope ASEC service in good faith and in line with this policy.
Feedback
Suggestions on this policy are welcome at security@asec.io. It will change over time, and your input helps keep it clear and useful.
Acknowledgements
Thank you to the researchers who have reported issues to us:
- Rock Pratap Singh