Vulnerabilities #
Vulnerabilities in myOrbik are collected from several well-known vulnerability databases and other tools, including the NIST (National Institute of Standards and Technology), OSV (Open Source Vulnerability Database), and GitHub Advisory database.
- NIST: A government database that tracks vulnerabilities with detailed information, including CVE identifiers and metadata about affected products.
- OSV: A database focused on open-source vulnerabilities, providing information about vulnerabilities affecting open-source software projects.
- GitHub Advisory: A platform that allows open-source maintainers and security researchers to report vulnerabilities in code hosted on GitHub.
The vulnerability database in myOrbik is synchronized daily, ensuring that users have access to the latest information about vulnerabilities affecting their products.
Vulnerability Structure #
Each vulnerability in myOrbik includes the following key components:
CVSS3 Severity #
The CVSS3 Severity is a key metric for assessing the severity of a vulnerability. The possible severity levels are:
- None: No impact or risk identified.
- Low: Minimal impact, generally low risk to the system.
- Medium: Moderate impact, typically requiring some form of mitigation.
- High: Significant impact, likely to result in a critical issue if exploited.
- Critical: Extremely severe, the vulnerability must be addressed immediately.
- Unknown: Severity level is not identified or assessed.
Vulnerability State #
Each vulnerability can be in one of the following states:
- Detected: The vulnerability has been identified.
- Resolved: The vulnerability has been mitigated or addressed.
- Exploitable: The vulnerability can be exploited, posing a significant risk.
- In Triage: The vulnerability is under investigation to determine its impact and remediation steps.
- False Positive: The vulnerability was determined to be a false alarm.
- Not Affected: The product or system is not affected by the vulnerability.
Vulnerability Justification #
When a vulnerability is marked as “Not Affected” or “False Positive,” the justification for the decision is documented. Possible justifications include:
- Code Not Present: The affected code is not present in the product.
- Code Not Reachable: The vulnerability exists in code that cannot be reached or executed in the environment.
- Requires Configuration: Mitigation requires specific configuration changes.
- Requires Dependency: The vulnerability depends on other software or systems that are not present or used.
- Requires Environment: The vulnerability requires a specific runtime environment to be exploitable.
- Protected by Compiler: The vulnerability is mitigated by compiler-level protections.
- Protected at Runtime: The vulnerability is mitigated by runtime protections.
- Protected at Perimeter: The vulnerability is mitigated by perimeter security controls.
- Protected by Mitigating Control: There are other mitigating controls in place that prevent the exploitation of the vulnerability.
Vulnerability Response #
Once a vulnerability is identified, a response action must be defined. The possible responses are:
- Can Not Fix: The vulnerability cannot be fixed, often due to technical limitations.
- Will Not Fix: The decision is made not to fix the vulnerability, often for strategic or risk-related reasons.
- Update: A fix for the vulnerability is available through a software update.
- Rollback: A rollback to a previous, secure version of the software is required.
- Workaround Available: A temporary workaround exists to mitigate the vulnerability.
Vulnerabilities from Multiple Sources #
Vulnerabilities in myOrbik not only come from the aforementioned databases but also from third-party vulnerability scanning tools. For more details, refer to the Integrations section for information on how myOrbik integrates with other scanning solutions.
Vulnerability Mitigation Process #
The vulnerability mitigation process begins once a vulnerability is detected. The user of myOrbik will receive a system notification indicating that the scan report has finished. The user can then extract a list of components and view the identified vulnerabilities. Each vulnerability will be assigned an identifier and a CVSS score.
- CPE (Common Platform Enumeration): CPE is a standardized naming scheme for IT systems, platforms, and software, which helps identify affected systems and software.
- CVSS (Common Vulnerability Scoring System): CVSS is used to evaluate the severity of vulnerabilities. Each CVSS score reflects the potential impact of an exploit.
- CVE (Common Vulnerabilities and Exposures): CVE identifiers are unique identifiers assigned to known vulnerabilities, ensuring consistent tracking and sharing of security information.
The CVSS score must be contextualized and recalculated for each product, considering factors like the accessibility of the affected component and the required user permissions to exploit the vulnerability. To assist with this, myOrbik offers a CVSS Calculator to help users calculate an adjusted CVSS score for each product.
Prioritization of Vulnerabilities #
myOrbik prioritizes vulnerabilities based on two key parameters:
- EPSS (Exploit Prediction Scoring System): EPSS predicts the likelihood that a vulnerability will be exploited in the wild based on data from various sources. A higher EPSS score means a greater chance of exploitation.
- KEV (Known Exploited Vulnerabilities): KEV identifies vulnerabilities that are known to be actively exploited in real-world attacks.
Using these parameters, myOrbik calculates a Priority field for each vulnerability, rated on a scale of 1 to 5. The lower the number, the higher the priority for remediation. This allows users to focus on the most critical vulnerabilities first.
By providing detailed information, contextual scoring, and prioritized recommendations, myOrbik helps users effectively manage and mitigate vulnerabilities to maintain the security of their products.
Vulnerabilities rank By IA #
We use an external AI system to calculate our vulnerability ranking. The AI evaluates vulnerabilities based on factors such as epps (exploitation probability), percentile, priority, and score.