Privacy information for Vulnerability-Lookup#

Scope#

Vulnerability-Lookup is self-hosted software. The project does not control every deployment, and installing the software does not make the project maintainers the operator or data controller for that instance. Each operator must publish privacy information appropriate to its configuration, jurisdiction, purpose, retention rules, and contact details.

The public instances linked from the README are independently operated. Direct questions or requests concerning an account or activity on an instance to the contact identified by that instance. This file documents what the software can process so operators and users can make informed decisions; it is not a substitute for an operator’s privacy notice.

Data the software can process#

Depending on enabled features and user input, an instance can store:

  • account and profile information, including login, name, email address, organisation, country code, biography, profile photo, social/profile links, account timestamps, and authentication data;

  • API and feed credentials, password hashes, two-factor-authentication secrets and recovery-code hashes;

  • user-created comments, bundles, sightings, watchlists, KEV subscriptions, disclosure reports, advisories, and associated authorship and timestamps;

  • organization membership, roles, and permission assignments;

  • notification destinations and delivery state; and

  • technical logs and request metadata selected by the operator’s web server, proxy, application, and logging configuration.

The service uses a session cookie when authentication is enabled. Operators can configure the cookie’s security attributes. Vulnerability-Lookup does not require third-party advertising or analytics; an operator may nevertheless add services outside this repository and must disclose them separately.

Public contributions may expose the selected profile identity and authored content through the web interface, feeds, API, dumps, or synchronization with other instances. Users should not submit personal or confidential information to public fields unless they intend it to be published. Vulnerability disclosure reports can contain sensitive information and must be handled under the operator’s disclosure policy.

Processing, retention, and sharing#

The software processes data to authenticate users, authorize actions, operate the vulnerability database and collaboration features, publish content, and send notifications requested by users or administrators. Feeders also retrieve public vulnerability information from the sources documented in the README.

Retention and deletion are controlled by each operator. Database backups, exports, logs, remote notifications, and content already synchronized to another instance may follow separate retention periods. Operators should define and document those periods, access controls, recipients, legal bases, backup practices, and procedures for access, correction, export, objection, or deletion requests.

Guidance for operators#

Before enabling public registration or collecting personal data, operators should:

  1. publish their identity, contact details, purposes and legal bases for processing, retention periods, recipients, and applicable user rights;

  2. configure HTTPS and secure session-cookie settings as described in docs/webservice.md;

  3. enable only necessary features, restrict access through the documented RBAC controls, protect secrets and backups, and review logging configuration;

  4. describe any mail provider, reverse proxy, monitoring, analytics, federation, or other external processor they add; and

  5. establish a process for privacy requests and security incidents.

Security vulnerabilities in the software should be reported according to SECURITY.md. Privacy requests about a deployment must instead go to that deployment’s operator.