Vulnerability Management


Policy Statements

JupiterOne policy requires that:

(a) All product systems must be scanned for vulnerabilities at least quarterly and with each major change. VULN1

(b) All vulnerability findings must be reported and tracked to resolution. Records of findings must be retained for at least 3 years.

Controls and Procedures

Vulnerability Scanning and Infrastructure Penetration Testing

The scanning and identification of system vulnerabilities is performed by

  1. An automated security agent installed on all Linux servers.

    • This includes EC2 instances in AWS.
    • The agent automatically reports to a centralized management server/dashboard with details of the server instance and any vulnerability finding.
    • This assessment is performed on an ongoing basis.
  2. Penetration testing is performed regularly as part of the JupiterOne vulnerability management policy.

    • External penetration testing is performed continuously through a public vulnerability disclosure / bug bounty program.
    • Additional external penetration testing is performed at least annually by either a certified penetration tester on JupiterOne security team or an independent third party. SDLC2
    • White-box internal penetration testing is performed at least quarterly by the security team. VULN2
  3. JupiterOne tracks all system entities and associated vulnerabilities in the JupiterOne Platform.

  4. Findings from a vulnerability scan or penetration testing are analyzed by the Security Team, together with Development as needed, and reported following the process as defined in the next section. A written report may be generated in addition to creating the findings in the JupiterOne Platform.

  5. All security testing reports and findings records are retained for 3 years.

Security Findings Reporting, Tracking and Remediation

We follow a simple vulnerability tracking process using a JIRA SEC Project. The records of findings are retained for 3 years.

Reporting a finding

Priority/Severity Ratings and Service Level Agreements

In an effort to quickly remediate security vulnerabilities the following timelines have been put in place to drive resolution.

Priority Level Severity Rating SLA Definition Examples
P1 Critical 3 days Vulnerabilities that cause a privilege escalation on the platform from unprivileged to admin, allows remote code execution, financial theft, unauthorized access to/extraction of sensitive data, etc. Vulnerabilities that result in Remote Code Execution such as Vertical Authentication bypass, SSRF, XXE, SQL Injection, User authentication bypass
P2 High 14 days Vulnerabilities that affect the security of the platform including the processes it supports. Lateral authentication bypass, Stored XSS, some CSRF depending on impact.
P3 Medium 90 days Vulnerabilities that affect multiple users, and require little or no user interaction to trigger. Reflective XSS, Direct object reference, URL Redirect, some CSRF depending on impact.
P4 Low 360 days Issues that affect singular users and require interaction or significant prerequisites (MitM) to trigger. Common flaws, Debug information, Mixed Content.
P5 Informational N/A Non-exploitable weaknesses and “won’t fix” vulnerabilities. Best practices, mitigations, issues that are by design or acceptable business risk to the customer such as use of CAPTCHAS.

If a Severity Rating is updated after a vulnerability finding was originally created, the SLA is updated as follows:

Resolving a finding

Closing a finding


Priority Level Severity Rating Exception SLA Plus Exception
P1 Critical 3 days 6 days
P2 High 14 days 28 days
P3 Medium 90 days 180 days
P4 Low 360 days 720 days
Priority Level Severity Rating Exception Review Period
P1 Critical 2 days after exception is granted
P2 High 11 days after exception is granted
P3 Medium 72 days after exception is granted
P4 Low 288 days after exception is granted