JupiterOne development team follows the latest security best practices when developing software, and automates security testing throughout the development lifecycle whenever possible.
Security is integrated into all phases of JupiterOne’s product development lifecycle, including:
Security testing that includes:
Details about the JupiterOne software application architecture and security are documented on the product development / engineering wiki.
JupiterOne policy requires that:
(a) JupiterOne software engineering and product development is required to follow security best practices. Product should be “Secure by Design” and “Secure by Default”.
(b) Quality assurance activities must be performed. This may include
(c) Risk assessment activities (i.e. threat modeling) must be performed for a new product or major changes to an existing product.
(d) Security requirements must be defined, tracked, and implemented.
(e) Security analysis must be performed for any open source software and/or third-party components and dependencies included in JupiterOne software products.
(f) Static application security testing (SAST) must be performed throughout development and prior to each release.
(g) All critical or high severity security findings must be remediated prior to each release.
(h) All critical or high severity vulnerabilities discovered post release must be remediated in the next release or within 30 days, whichever is sooner.
(j) Any exception to the remediation of a finding must be documented and approved by the security team.
Software development at JupiterOne follows a release strategy that provides traceability for production software changes. Features, enhancements, and bugs are written up as Issues in JIRA. An engineer on a small team proposes changes necessary and creates a “Pull Request” review for the team in GitHub . Continuous Integration (Jenkins) kicks off unit and functional tests which pass before changes are merged into the repository. Once the review is complete, the changes are now deployed to the development environment where regression and end-to-end tests are run before the new code replaces the existing in-service code (test then deploy model). Small teams can decide to follow a source-control branching strategy that makes sense: for example github-flow.
JupiterOne practices continuous delivery of code into production through multiple environments: development, testing, production. The deploy process and infrastructure roll-out are written as code (using technologies such as Terraform and AWS Cloudformation) and managed under source control.
JupiterOne’s multiple lower environments (dev, test) provide an ecosystem of sample data sets that exercise the application and services when test automation is run. The test environment is where the system is stressed for performance and scalability. Performance and scalability changes are driven by metric data captured through monitoring and logging (metrics before and after change – typically captured as part of the issue description/writeup).
Deployments to production are gated by change control process where an issue is opened which identify what is new/changed (JIRA). Sign-offs are recorded by development, testing, security, and product management. Production roll-outs happen on a regular basis without impact to service. This continuous process allows for security updates to roll out regularly and with urgency. If there is impact to production, a rollback is performed to restore service and whatever caused the problem is reverted from source. This restarts the re-proposal approval process of source changes. This process keeps the set of differences between the development environment and the production environment as low as possible.
In the continuous delivery mindset, features are not released by the deployment of code into production, instead features are enabled in production at the appropriate time (dark launching). Feature toggle enablement in production is gated by a change control ticket (JIRA) that follows the software roll-out approval process. Feature toggle enablement in production can have a few more dependencies than code. Those dependencies include things like external documentation, early access programs, and internal playbooks for supporting the feature.
Traceability of code changes allow for our software to be a living entity. Our current system for documenting changes is JIRA. Every commit and/or Pull-Request, should have an associated JIRA tracking item that describes contextually why this change is necessary and reasonable. These artifacts over time allow for one to trace the lineage of why our production software and services change over time.
git repositories have a company standard
configuration from a GitHub perspective. This standard is a
guideline and can be relaxed, but socialize when those exceptions are needed.
One example of an exception, is the
wiki repository, as editing a wiki and
always requiring a PR in this setting slows down ‘flow’.
Developers follow the branch strategy and code review process below:
All development uses feature branches based on the main branch used for the current release. Any changes required for a new feature or defect fix are committed to that feature branch.
Developers are strongly encouraged to follow the commit message conventions suggested by GitHub.
Once the feature and corresponding tests are complete, a pull request (PR) will be created using the GitHub or web interface. The pull request should indicate which feature or defect is being addressed and should provide a high-level description of the changes made.
Code reviews are performed as part of the pull request procedure. Once a change is ready for review, the author(s) will notify other engineers using an appropriate mechanism, typically by adding reviewers as PR approvers.
If the feature or change contains security/risky infrastructure changes to the target environment, the code changes must be reviewed by the Security team before the feature is marked as complete.
JupiterOne practices continuous delivery of code into production through multiple environments: development, testing, production. The deploy process and infrastructure roll-out are written as code (Terraform) and managed under source control.
JupiterOne’s multiple lower environments (dev, test) provide an ecosystem of sample data sets that can be used to exercise the application and services when test automation is run. The test environment is where the system is stressed for performance and scalability. Performance and scalability changes are driven by metric data captured through monitoring and logging (metrics before and after change - typically captured as part of the issue description/writeup).
Deployments to production are gated by §Change Management process where an issue is opened which identify what is new/changed (JIRA). Sign-offs are recorded by development, testing, security, and product management. Production roll-outs happen on a regular basis without impact to service. This continuous process allows for security updates to roll out regularly and with urgency. If there is impact to production, a rollback is performed to restore service and whatever caused the problem is reverted from source. This restarts the re-proposal approval process of source changes.
This process keeps set of differences between the development environment and the production environment as small as possible.
Features may be released via code deployments or features may be enabled in production at an appropriate time (dark launching). Feature toggle enablement in production is gated by the same change management ticket (JIRA) that follows the software roll-out approval process. Feature toggle enablement in production can have a few more dependencies than code. Those dependencies include things like external documentation, early access programs, and internal playbooks for supporting the feature.
Detailed process and procedures for code promotion and production release: See Configuration and Change Management.
JupiterOne development/engineering team uses
the hosted services GitHub and for source
The configuration standards defining access to
git hosted services include:
All developers must authenticate to gain access to JupiterOne
services and the code repos hosted on them according to standards and
procedures defined in the §Access Policy.
Access control to the
git service web interface MUST be enabled, via
SSO and/or MFA if applicable.
SSH public/private key access may be used for command line access to the code repos.
All code repos follow these configuration standards:
All repos must have an owner identified and listed.
All repos are by default
Certain branch restrictions are enabled, including:
Restrict direct commits into
Restrict history rewrites of
Restrict deletion of
Certain pull request (PR) requirements are enforced before merging, including:
Must have at least 1 review approval to merge.
Must have at least 1 successful build to merge.
All PR tasks must be completed.
All JupiterOne software must be developed to include the following general application security principles and requirements. Web applications must also protect against the OWASP Top 10 vulnerabilities.
Secure data in transit and customer communications via TLS. Communicate securely across application endpoints and between service consumers/producers.
Log all transactions and activities to be able to tell who did what, when, where, and how. Mask or remove sensitive data in logs.
Implement strong client security at application endpoints (e.g. browser, mobile app).
Use secure defaults to ensure security when in all error conditions.
Check and maintain the security of all third party and open source libraries/components/dependencies.
Deploy and configure applications securely to production.
Perform regular vulnerability analysis and apply security patches promptly.
Secure privileged access to production environments and ensure ongoing application monitoring.
All software code must complete a set of security scans/testing prior to being deployed to production, including open source dependency scanning and static application security testing. All services/features of the JupiterOne Platform undergo periodic penetration testing.
Software vulnerability identified through any of the above processes shall be reported and tracked as defined in §Vulnerability Management.
The JupiterOne Security Team in collaboration with the Development Team performs a full Application Threat Modeling and Risk Assessment on a per-application basis using a custom approach that relies on industry standards and best practices.
Major application updates are captured via an RFC process. The RFC template includes Security Consideration as a required section. This section is used to document abuse cases including:
Each RFC is required to capture sufficient details of the feature/component to be developed, including use cases, motivation and outcome, and the following design details as applicable:
The RFC MUST be approved prior to implementation. Security team is included in RFC reviews via the Pull Request process.
Documentation on the JupiterOne Engineering Wiki may include additional security specifications as well as the security design and implementation details of the JupiterOne Platform and its supporting operations.
The JupiterOne Platform, as well as any customer-facing application with access to customer-specific data (including sensitive information such as PII) implements strong access control, covering the Identification, Authentication, Authorization, and Accounting/Auditing (IAAA) of access and user activity.
The implementation ensures that
the user requesting access is the one claimed (Identification and Authentication);
only users authorized to access specific data (such as PII) may do so (Authorization); and
their access activities are logged (Accounting/Auditing) according to the JupiterOne auditing standards.
The current implementation leverages AWS Cognito for user identity management and access.
The backend platform implements granular Attribute-Based Access Control (ABAC), or IAM-like Policy-Based Access Control for granting access to specific services and data based on the policy or attribute(s) of a principal (i.e. user requesting access – an attribute could be the role or group membership or organization the user belongs to) and the attribute(s) of the requested resource (i.e. data or service – an attribute could be the project this data belongs to).
More implementation details are documented on the internal Engineering wiki.
JupiterOne Security and Development Teams leverage the JupiterOne Platform, in concert with other tooling and integrations, to implement a process to:
The current tool in use is Dependabot. Documentation can be found at the Dependabot website.
Dependabot also enables automatic license analysis for dependencies, and this
functionality is embedded into the
securityScan() Jenkins pipeline step.
In addition, other tools like
npm audit may be leveraged in local
development environments to scan dependencies and surface potentially vulnerable modules/packages.
JupiterOne Development Team members are expected to make a best effort to vet, and periodically re-examine their FOSS project choices, as these dependencies have a direct impact on the security of our production environments.
Specifically, FOSS projects should:
If you are in doubt about the safety of including a FOSS project in your code, please open an Issue via the Jira ServiceDesk to review the project together with Security Team.
GitHub CodeScan performs static code analysis against all JupiterOne Platform code hosted in .
Projects hosted in GitHub are periodically scanned with the AppThreat/sast-scan tool.
The findings generated by these SAST tools are surfaced for action by appropriate Development staff via the JupiterOne Platform, and these findings are remediated per the policies in §Vulnerability Management.
Manual code security reviews are periodically performed by the Security Team as follows:
An external penetration testing is performed at least once a year, either by a qualified security researcher / ethical hacker on the Security Team or with an external security consulting firm. SDLC2
All technology contains bugs, including both functional defects and security vulnerability.
JupiterOne uses a third party platform to maintain a public vulnerability disclosure / bug bounty program. This program takes advantage of crowd-sourced security researchers to perform penetration testing of JupiterOne’s platform and its public facing resources.
The current program provider is BugCrowd.
JupiterOne requires all outsourced software development to follow the same rigor and process as internal engineering. Outsourced developers must accept and follow our security policies and procedures, and comply with the same secure coding standards, including:
Receive regular OWASP or equivalent secure coding training.
Follow the same source control, code review, and security code scanning procedures as defined in this document.
Install an endpoint compliance agent that checks to make sure firewall, encryption, patching, password policy, screensaver password, and other required protection is properly configured.
Additionally, any third-party firm providing outsourced development services must demonstrate that they have conducted the appropriate screening during hiring.
Software and systems deployed in the production environment are monitored 24x7 for health check and other major/critical error conditions. The appropriate staff members are notified via Slack in the event an error or failure is detected.
Notifications via additional channels such as email are also configured.