Security overview
Last updated
Was this helpful?
Last updated
Was this helpful?
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. The customers trust us with their software dependency data, and Debricked takes this responsibility seriously.
The task of handling data securely is based on trust, and Debricked takes several measures to earn this trust. This includes securing data at rest and in transit, being transparent in how Debricked reads repository information, separating pods, and running a vulnerability disclosure program.
This document serves to answer and clarify some questions that are received from customers on how and where their data is processed.
Debricked reads dependency information from your source code manager and matches the dependencies with our vulnerability, license, and health database. You can view the results in the CI/CD pipeline 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 such as 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. Debricked will not get read permission to your complete repository.
Dependency information is 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, that is, functions implemented by third-party code (for example, ‘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 allows Debricked to understand and optimize the service for improved customer experience. An effort is taken to anonymize possibly sensitive information. Debricked never sells 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. Debricked also supports 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 the Privacy Policy intends to convey all necessary information for customers to understand how Debricked treats 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 the internal security according to the requirements.
Debricked also has a SOC 2 report showing the compliance 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 the 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 the web page.
Debricked also performs penetration tests, both in-house and by third parties, to reveal possible weaknesses in the web service and its implementation.
Debricked’s security testing also includes regular SAST and DAST scanning with professional third-party tools.
Lastly, Debricked uses Software Composition Analysis (SCA), its 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.