Bug Fixing Policy
Effective starting: September 11, 2017
SAVEMYGST.IN is a product by SavemyTax Business Solutions Private Ltd (called SAVEMYGST from here onwards).
Our Support team will help with workarounds and bug reporting
We schedule non-critical bugs according to a variety of considerations
SAVEMYGST Support is eager and happy to help verify bugs—we take pride in it! Create an issue in our support system, providing as much information as you can about how to replicate the problem you’re experiencing. We’ll replicate the bug to verify, then lodge the report for you. We’ll also try to construct workarounds if possible.
Search existing bug reports
Use our issue tracker to search for existing bugs, and watch the ones that are important to you. When you watch an issue, we’ll send you an e-mail notification when the issue’s updated.
How we approach bug fixing
Maintenance (bug fix) releases come out more frequently than major releases, and attempt to target the most critical bugs affecting our customers. The notation for a maintenance release is the final number in the version (the 1 in 6.0.1, for example).
If a bug is critical (production application down or major malfunction causing business revenue loss or high numbers of staff unable to perform their normal functions) we’ll fix it in the next maintenance release, provided that:
- The fix is technically feasible (it doesn’t require a major architectural change)
- It doesn’t impact the quality or integrity of a product
For non-critical bugs, the team assigned to fixing bugs prioritizes the bug according to these factors:
- How many of our supported configurations are affected by the problem
- Whether there is an effective workaround or patch
- How difficult the issue is to fix
- Whether many bugs in one area can be fixed at one time
Developers responsible for fixing bugs also monitor comments on existing and new bugs, so you can comment to provide feedback if you need to. We give high priority to security issues.
When considering the priority of a non-critical bug, we try to determine a value score for a bug. The score takes into account the severity of the bug from our customers’ perspective, how prevalent the bug is, and whether new features on our roadmap may render the bug obsolete. Our developers combine the value score with a complexity score (how difficult the bug is) when selecting issues to work on.
Security Bug Fix Policy
SAVEMYGST makes it a priority to ensure that customers’ systems cannot be compromised by exploiting vulnerabilities in SAVEMYGST products.
This page describes when and how we release security bug fixes for our products. It does not describe the complete disclosure process that we follow.
Security Bugfix Service Level Agreement (SLA)
We attempt to meet the following timeframes for fixing security issues.
Critical severity bugs (CVSS v2 score >= 8, CVSS v3 score >= 9) should be fixed in product within 4 weeks of being reported.
High severity bugs (CVSS v2 score >= 6, CVSS v3 score >= 7) should be fixed in product within 6 weeks of being reported.
Medium severity bugs (CVSS v2 score >= 3, CVSS v3 score >= 4) should be fixed in product within 8 weeks of being reported.
When a Critical security vulnerability is discovered by SAVEMYGST or reported by a third party, SAVEMYGST will do all of the following:
Issue a new, fixed release for the current version of the affected product as soon as possible.
When a security issue of a High, Medium or Low severity is discovered, SAVEMYGST will include the fix in the next scheduled maintenance release.
You should upgrade your installation in order to fix the vulnerability.
Severity level of vulnerabilities is calculated based on Severity Levels for Security Issues.
We will continuously evaluate our policies based on customer feedback and will provide any updates or changes on this page
Severity Levels for Security Issues.
This severity level is based on our self-calculated CVSS score for each specific vulnerability. CVSS is an industry standard vulnerability metric. You can learn more about CVSS at FIRST.org.
For CVSS v3 SAVEMYGST uses the following severity rating system:
|CVSS V3 SCORE RANGE||SEVERITY IN ADVISORY|
|0.1 – 3.9||Low|
|4.0 – 6.9||Medium|
|7.0 – 8.9||High|
|9.0 – 10.0||Critical|
Below are a few examples of vulnerabilities which may result in a given severity level. Please keep in mind that this rating does not take into account details of your installation and are to be used as a guide only.
Severity Level: Critical
Vulnerabilities that score in the critical range usually have most of the following characteristics:
- Exploitation of the vulnerability likely results in root-level compromise of servers or infrastructure devices.
- Exploitation is usually straightforward, in the sense that the attacker does not need any special authentication credentials or knowledge about individual victims, and does not need to persuade a target user, for example via social engineering, into performing any special functions.
- For critical vulnerabilities, is advised that you patch or upgrade as soon as possible, unless you have other mitigating measures in place. For example, a mitigating factor could be if your installation is not accessible from the Internet.
Severity Level: High
Vulnerabilities that score in the high range usually have some of the following characteristics:
- The vulnerability is difficult to exploit.
- Exploitation could result in elevated privileges.
- Exploitation could result in a significant data loss or downtime.
Severity Level: Medium
Vulnerabilities that score in the medium range usually have some of the following characteristics:
- Vulnerabilities that require the attacker to manipulate individual victims via social engineering tactics.
- Denial of service vulnerabilities that are difficult to set up.
- Exploits that require an attacker to reside on the same local network as the victim.
- Vulnerabilities where exploitation provides only very limited access.
- Vulnerabilities that require user privileges for successful exploitation.
Severity Level: Low
Vulnerabilities in the low range typically have very little impact on an organization’s business. Exploitation of such vulnerabilities usually requires local or physical system access.