VulnBeacon helps you understand the software your products are built from and the security decisions around it. This notice explains the personal information involved when you visit our website, use the service or write to us: what we collect, why, who else receives it, how long we keep it and what you can ask of us.
1. Who is responsible
VulnBeacon is operated by the company identified in our Legal notice. “VulnBeacon”, “we”, “us” and “our” mean that company.
For any privacy question or request, write to contact@vulnbeacon.com.
We are the controller of the personal information used for our website, for running accounts, for our communications and for keeping the service secure.
When an organisation submits personal information for processing on its behalf, that organisation is normally the controller, and we act as its processor under the data processing agreement between us. Its own privacy notice explains that processing. We may pass a request about it to the organisation, or help the organisation answer.
2. Information we handle
Account information. Your username, first and last name, e-mail address and whether it is verified, company, language, role and account status, the e-mails you chose to receive, and when the account was created and last signed in. Accounts are created by an administrator, who enters your first details when giving you access.
Access requests. When you fill in our Request access form, we receive your name, work e-mail address, organisation, and, if you give them, your role, the offer you have in mind, how many products you ship and your message, together with the network address the request came from.
Communications. When you write to us at access@vulnbeacon.com or elsewhere, we receive your contact details, your message and anything you include in it.
Product information. The SBOMs and dependency manifests you upload, and everything the service derives from them or records beside them: product details, component names and versions, dependency relationships, findings, decisions, VEX statements, release gate verdicts, compliance evidence, your policy, watch lists, alert settings and integrations, and the suppliers you record, with their contact address.
Most of this is technical. It can still contain names, e-mail addresses or comments about people, and it can reveal confidential details of a project. The upload workflow is built for SBOMs and dependency manifests, not for source code, and our Terms of service ask you to remove any personal information or secret the analysis does not need before you upload.
Sign-in and activity records. For each session, the network address it began from and when it began and ends; your sign-in attempts; and an audit record of the actions taken in the service, each naming the account, the action, the item concerned, the time and the network address. Settings › Profile shows you your own sessions with their addresses.
Server access logs. For every request, our servers log the caller’s network address, the requested path with its query, the response status and the time. The token in a shared report link is removed before the line is written.
E-mail delivery records. For each e-mail sent: its kind, its subject, its outcome, the account it was for and the domain of the recipient’s address, never the full address.
API keys and Supplier keys. For each API key: its name and kind, the products it names, its creation, expiry and last-use dates, its monthly usage, the network address it was created from and, once it is revoked, when and why. Settings › API keys shows you the address each of your keys was created from. For each Supplier key: its label, its product, its dates, how often it was used and the deliveries it made.
Shared report links. For each link you create: the report it opens, its label, its expiry, whether it has a password, how many times it was opened and when it was last opened.
Information from other sources. The administrator who creates or manages your account; the integrations you configure; the vulnerability data the service gathers from more than eighty public sources, whose advisories may name a researcher, a maintainer or an author; and the package services named in section 4.
3. Purposes and legal bases
Where the GDPR applies, we use personal information for these purposes:
- Providing the service you asked for: your account, your product information and the e-mails you chose, to perform our contract with you or to take the steps you asked for before entering into it.
- Running accounts for organisations: work contact details and account activity, for our legitimate interest in delivering and administering the service an organisation ordered.
- Protecting the service: sign-in, connection and audit records, server logs and, where it is switched on, the bot check at sign-in, for our legitimate interest in preventing abuse, protecting information and investigating incidents, and where a legal obligation requires it.
- Answering you: your correspondence, to perform a contract where one applies, and otherwise for our legitimate interest in answering questions and resolving issues.
- Keeping the service reliable: diagnostic information, for our legitimate interest in finding faults and running a dependable service.
- Meeting legal obligations: the records the law requires us to keep or produce.
- Legal claims: the records needed to establish, exercise or defend legal rights, for our legitimate interest in doing so.
Where we rely on legitimate interests, we have weighed them against their effect on you, and you can object (section 9). Processing on an organisation’s behalf follows its lawful instructions and the data processing agreement.
None of the processing in this notice relies on your consent. If a future feature needs it, we will explain that use and ask separately. Accepting the Terms of service is not consent to tracking or marketing.
An account needs a username and a password, and alert e-mails need a verified address. Every other detail is optional unless we tell you why it is needed.
4. Who receives information
Hosting. The website and the service are hosted by OVH and Hetzner in European Union datacentres. This notice describes the service we operate. An Enterprise instance installed on a customer’s own machines is hosted under that customer’s control, and the customer decides how the people using it are informed.
Network and security. Every connection to the website, the application and the API passes through Cloudflare, which protects the service against attacks. Cloudflare decrypts each request to do so, so it processes what the request carries while it is in transit: your address, your session cookie, API keys, what you type and the documents you upload. It may set a strictly necessary security cookie of its own. Cloudflare is established in the United States and acts under its data processing addendum, which provides the safeguards required for that transfer.
Other providers. Other providers that help us run it receive only what their task needs, under appropriate safeguards.
E-mail delivery. The e-mails you turn on in Settings › Alerts (after each corpus update, a daily summary, a weekly review, a monthly report) and account messages, such as the code that confirms an e-mail address, are sent through an e-mail delivery provider. It receives the recipient’s address and the message. Alert e-mails go only to a verified address.
Bot protection at sign-in and on the Request access form. When bot protection is switched on, those two pages load Cloudflare Turnstile. Cloudflare then processes connection information from your browser and issues a single-use challenge token, which our server sends back to Cloudflare with your network address to have it checked. While bot protection is off, neither page makes a request to Cloudflare.
Package-intelligence services. To judge the health of your dependencies and to run the pull-request check, the service sends package identifiers (ecosystem, namespace, name and version) to deps.dev and, for npm and PyPI packages, to the npm and PyPI registries. Where we have enabled it, the pull-request check also asks ReversingLabs about package versions it has never seen. These requests carry identifiers only, never a whole SBOM or source code. A private package’s name can still reveal something confidential: tell us before you upload such names if your use requires the lookups to be restricted.
Integrations you configure. An integration you connect (Slack, Microsoft Teams, PagerDuty, Jira, ServiceNow, Splunk, Elastic, Microsoft Sentinel, GitHub or GitLab) receives what you send it: alerts or tickets carrying product details, findings and links into the application. Nothing from your account reaches an integration you have not configured.
Connected assistants. An AI assistant connected through MCP acts with the API key you give it and can do only what that key allows. The hosted MCP endpoint, mcp.vulnbeacon.com, receives your key with each request, uses it for that request alone and neither stores nor logs it; it logs the network address, method, path, status and duration of each request. Before an answer leaves for the assistant, e-mail addresses and anything shaped like a VulnBeacon key are removed from it. The assistant’s provider processes your prompts, the information retrieved and the answers under its own terms. We do not use your information to train AI models.
Our administrators. To run and support the service, our administrators can see account details, sessions, the metadata and usage of API keys, the activity records, and a summary of each account’s products: their names, versions and latest grades. They can correct account details, reset a password, create an API key or adjust the policy for an account, block it, end its sessions and keys, and close it.
People you share a report with. Anyone who holds a shared report link, and its password where you set one, can open that report until the link expires or you revoke it. A copy they download stays with them.
Legal requirements and business transfers. We disclose information where the law requires it, or where disclosure is necessary and lawful to protect rights or respond to abuse. A merger, acquisition or similar transfer may involve sharing information under confidentiality and data-protection safeguards, with notice where it is required.
5. International transfers
Hosting in the European Union does not keep every flow inside it. The services named in section 4, the integrations you connect, an assistant’s provider and support arrangements may involve processing outside the European Economic Area.
When we are responsible for a transfer that the GDPR restricts, we rely on a mechanism it recognises, such as an adequacy decision or appropriate contractual safeguards, with additional measures where they are needed.
Ask us which destinations and safeguards apply to your use. Where the law gives you that right, we will send you a copy of the safeguards, with confidential details removed.
A service you connect yourself is governed by its own privacy notice; read it before you connect.
6. Cookies and browser storage
The public website sets no cookie of its own and uses no advertising or analytics tracker.
Signing in sets one cookie, sid, which holds your session. It is strictly necessary for the service you asked for, so it needs no consent. Its attributes protect it:
- HttpOnly: scripts on the page cannot read it.
- Secure: your browser sends it only over HTTPS.
- SameSite=Lax: when another site starts a request to us, your browser sends the cookie only if you followed a link.
- Path=/: it applies to the whole site.
A session ends after seven days without use, and in any case 30 days after you signed in. Signing out ends it at once; a password change, a revocation or a security measure can end it sooner.
The application keeps a few interface preferences in your browser’s local storage: your language, theme and table density, how the SLA ageing chart is drawn, the tabs and steps you chose in the documentation, and one flag noting that a session existed, so the sign-in page can tell you why you were signed out. These stay in your browser; your language is also saved with your account. Local storage never holds a password, a key or a session token: the only credential the application keeps in your browser is the sid cookie.
Clearing your browser’s data for the site signs you out and resets these preferences. Before we add any optional tracking, we will update this notice and ask for your consent where the law requires it.
7. Retention
We keep information only as long as its purpose needs. These are the periods that apply:
- Account information: kept while your account exists. When an account is closed, the account, its sessions and keys, and its products with everything recorded about them are deleted. Audit records that name the account remain until their own period ends.
- Products and SBOMs: kept until you delete the product or the account is closed. By default each product keeps its ten newest SBOM generations, together with the newest generation whose scan has finished; an older generation is deleted once a newer one has been assessed.
- Pull-request checks: the candidate SBOM and the result of a check expire 24 hours after the check and are then deleted. A check never changes the product’s own inventory.
- Audit records and history: audit records, and the change and patch history of vulnerability records, are kept for 730 days by default. Our administrators can set a period from 30 to 3,650 days, or keep them without limit. The newest change and patch entry of each vulnerability record is always kept, because the service compares against it. Your products’ daily risk and compliance snapshots are kept for 730 days by default.
- Access requests: kept for 12 months from the day you sent the request, answered or not, then deleted. If we create your account, section 2's account information follows its own period. You can ask us to erase a request sooner.
- Sessions: as described in section 6.
- Request limits: the counters that limit requests and sign-in attempts per network address or per username cover windows of one to fifteen minutes, then expire.
- E-mail codes: a code that confirms an e-mail address is valid for 15 minutes and is then deleted. The audit record of the change follows the audit period.
- Shared report links: a link lasts 7 days unless you choose another length, 30 days at most, and you can revoke it at any time. Its expiry deletes neither the report in the application nor a copy someone downloaded.
- API keys: a key lasts 90 days unless you choose another lifetime, 365 days at most. A key that is never used stops working 30 days after it was created. A Supplier key lasts 180 days by default, 365 at most, under the same 30-day rule.
- Server access logs: kept for a limited period, then deleted.
- Correspondence: kept as long as the matter and any follow-up, legal obligation or claim requires.
Deleting information from the service does not remove it from our backups at the same moment. Backups are kept only to restore the service and are replaced on their own cycle.
Ask us for the periods that apply to your account.
8. Security
Each account reaches only its own products, and connections to the service are encrypted. Passwords are stored only as bcrypt hashes; session tokens, API keys, Supplier keys and shared-link tokens only as one-way hashes, so they cannot be read back; the credentials an integration needs to reach another service are encrypted at rest. After ten wrong passwords within fifteen minutes, a shared report link refuses every attempt until those fifteen minutes have passed. Security events are logged.
Security also depends on you: protect your password and your keys, review the integrations you connect, and check a report before you share it.
Report a suspected security issue to contact@vulnbeacon.com; section 7 of our Website terms of use says what a report should contain.
9. Your rights
Depending on the law that applies and the circumstances, you can ask to access, correct or delete your personal information, to restrict its use or to receive a portable copy of it. You can also object to processing based on legitimate interests.
Much of this is already in your hands. In Settings › Profile you can correct your name, company and language, change your e-mail address (the new address applies once you enter the code sent to it) and sign out your other sessions. In Settings › API keys you can revoke a key. Each product’s pages let you download its inventory, findings and reports, and delete the product.
You cannot delete your account yourself. Write to us, or ask the administrator who gave you access, and the account is closed as described in section 7.
If we ever rely on your consent, you can withdraw it at any time; withdrawal does not affect what was done before.
Send requests to contact@vulnbeacon.com. We may ask for proportionate information to confirm your identity or understand the request. Under the GDPR we answer without undue delay and within one month; where the law allows us to extend that period, we tell you why within the first month.
These rights have legal limits. A record may have to stay to meet a legal obligation or defend a claim, for example; if a limit applies to your request, we will say which.
You may complain to the competent data-protection authority, in particular in the country where you live or work or where you believe the infringement took place. You do not have to contact us first.
10. Automated analysis
VulnBeacon automatically matches components against vulnerability records, computes grades and risk scores, and applies the rules of your policy.
These results concern software and releases, not people. The service makes no decision about a person that has legal or similarly significant effects, and its scores should not be used to make such decisions.
11. Children
VulnBeacon is built for people who assess software and manage security information. It is not directed at children.
If you believe a child has given us personal information without an authorisation the law requires, tell us so that we can look into it and act.
12. Changes to this notice
We update this notice when our features, practices or legal duties change, and the date at the top shows the version in force.
Before a material change takes effect, we tell you by appropriate means and, where the law requires it, ask for your consent before any new processing begins.