Security Overview
Last updated
Last updated
© 2018-2024 | Open Text
This content was last updated in May 2024, and represents the status quo as of the time it was written.
At Debricked, security is a top priority. Debricked customers trust us with their software dependency data, and we take this responsibility seriously.
The task of handling data securely is based on trust, and we take several measures to earn this trust. This includes securing data at rest and in transit, being transparent in how we read repository information, separating pods, and running a vulnerability disclosure program.
This document serves to answer and clarify some questions that we often get from customers on how and where we process their data.
Debricked reads dependency information from your source code manager and matches the dependencies with our vulnerability, license, and health database. The results can be viewed in your CI/CD using the Debricked web application.
All data is transmitted in encrypted form to the database and the web application, using TLS 1.2 or higher, with ciphersuites supporting forward secrecy. When accessing the web application through a browser, HSTS (HTTP Strict Transport Security) with preload is used to ensure that no data is ever transmitted unencrypted. All communication with third-party services is also encrypted.
Debricked collects customer data from your source code manager, e.g., GitHub or GitLab. Debricked provides a GitHub app for simplicity of use, giving Debricked read and write access to the repository. The read access is required for reading metadata and dependency information. The write access is required to create pull requests for fixing vulnerabilities.
Debricked also provides a CLI (Command Line Interface), both standalone and embedded in a Docker image. The Docker image can access the repository as part of the CI/CD. In this way, Debricked will not get read permission to your complete repository.
Dependency information will be sent to Debricked's servers. This holds for the GitHub app and the CLI used in the CI/CD. With the CLI, source code is never sent to Debricked. For the GitHub app, source code is only sent for package managers where this is required for building the dependency trees. Still, in all such cases, the source code is immediately deleted after the dependency tree is built.
Additionally, Debricked supports file fingerprinting for detection of dependencies. Here, Debricked uploads and saves the name, path, and size of a file, together with a hash of the file content. The files themselves are never uploaded or saved on Debricked servers.
To perform reachability analysis for vulnerabilities, call graph information will be sent to Debricked so that reachability can be visualized and assessed by the customer.
For transparency, both the CLI and the Docker image are provided as open source. This will allow anyone to examine how Debricked code accesses the repository and source code and to verify that no source code leaves the repository. The source is available on Debricked’s GitHub account.
Debricked’s service is running on cloud computers hosted by GCP (Google Cloud Platform). All dependency data is stored and processed within the European Union (Netherlands).
The service, including the database, is hosted within a private network on GCP, using VPC peering. In particular, the database is not externally accessible and is deployed on two availability zones for added redundancy.
Debricked applies controlled invocation of the functionality through an authenticated API. Cloud infrastructure and direct database access are subject to the least privilege principle and are restricted to only very few employees.
The matching between dependency information and vulnerability/license/health data is performed on Kubernetes pods. When dealing with untrusted processing of dependency information, i.e., functions implemented by third-party code (e.g., ‘npm install’), such processing is performed in an ephemeral sandbox without multi-tenancy.
This ensures that there is no information leakage between customers as part of the processing.
Debricked also uses third parties to track and process how customers use the service. This will allow Debricked to understand and optimize the service for improved customer experience. An effort is taken to anonymize possibly sensitive information. Debricked will never sell any data to a third party.
From the customer’s perspective, password credentials are protected in several ways. Proactive password checking reduces the possibility of choosing weak passwords, and rate limits protect against brute-force attacks. We also support single sign-on login through GitHub and identity providers supporting the OpenID Connect protocol.
Account access in the web application supports two-factor authentication. Both email authentication and TOTP (Time-based one-time password) authentication with Google authenticator are supported.
Access is also granted through the CLI or directly through an API. Such access requires a JWT token. A long-lived refresh token with 20 years of validity can be generated and revoked in the web application or through the API using the account password. The refresh token can then be used to generate a JWT token that has about 1-hour validity.
With many EU-based customers, Debricked aligns with the GDPR (General Data Protection Regulation) requirements. Here, transparency is key, and our Privacy Policy intends to convey all necessary information for customers to understand how we treat PII (Personally Identifiable Information).
Debricked is part of OpenText Cybersecurity. The Debricked application has been certified as conforming to the ISO/IEC 27001:2013 requirements. Debricked continuously documents, updates, and assesses our internal security according to the requirements.
Debricked also has a SOC 2 report showing that we comply with the AICPA Trust Services Criteria.
To encourage and enable third-party vulnerability reports, Debricked runs a vulnerability disclosure program. The program is detailed on our website under “Report a vulnerability”. The program allows independent researchers to search for, investigate, and responsibly disclose any vulnerabilities found in the service without the risk of legal action from our side. High-severity vulnerabilities are handled immediately, within 1 business day.
Interesting findings are either rewarded with a place in the Debricked Hall of Fame or for more particularly useful disclosures, a monetary reward. Details can be found on our web page.
Debricked also performs penetration tests, both in-house and by third parties, to reveal possible weaknesses in our web service and its implementation.
Debricked’s security testing also includes regular SAST and DAST scanning with professional third-party tools.
Lastly, we of course, use our favourite tool for Software Composition Analysis (SCA), our own Debricked SaaS application.
Debricked is redefining the way developers select, evaluate, use and contribute to open source software. Debricked SCA and Select makes open source security, compliance and health simple, and helps companies use more open source in an efficient manner. Since 2022, Debricked is a part of OpenText.
