Security
We hold what attackers want. We treat it that way.
A list of your components and their known vulnerabilities is a map for an attacker. These are the rules Provetry is built on.
Read-only, and only what we need
Provetry reads your dependency manifests, lock files and container images to build your SBOM. Repository access is read-only and limited to the repositories you choose, and you can revoke it at any time from your Git host.
Hosted in the European Union
Your data is stored and processed in the EU, in a database not exposed to the internet, with encrypted daily backups kept in the EU.
Encrypted, in transit and at rest
TLS everywhere, HSTS, and sensitive fields (repository tokens, report drafts) encrypted in the database with a key kept apart from it.
Accounts
Two-factor authentication, sessions you can see and end, and an audit log of every action on your workspace on the Pro and Consultant plans.
No trackers
No advertising or tracking cookies on this site, and none in the application. Visit statistics, if any, are cookieless and anonymous.
We practise what we check
This site already publishes a security.txt file and the disclosure policy below, as the CRA asks of you.
Report a vulnerability
Our coordinated vulnerability disclosure policy, the one the CRA asks every manufacturer to have. If you believe you have found a vulnerability in Provetry, please tell us: we will work with you to fix it before anything is published.
Scope
- This site,
provetry.com, and the application,app.provetry.com. - The open-source core, provetry-core: its command-line tool, its GitHub action and its GitLab template.
- Vulnerabilities in a component we use are in scope when they affect Provetry. We also report them to whoever maintains that component.
How to report
Write to security@provetry.com, in English or French. Where you can, include what is affected, the steps to reproduce it or a proof of concept, its possible impact, and whether you wish to be credited. Our contact details are also in security.txt.
What we commit to
- Acknowledge your report within two working days.
- Give you a first assessment within five working days, then keep you informed until it is fixed.
- Fix it without delay, and tell the customers concerned when their data may have been exposed.
- Agree the publication date with you: by default 90 days after the report, or earlier once the fix is deployed.
- Credit you in our changelog, if you wish.
What we ask of you
- Use your own account or a test workspace. Do not access, change or delete other customers’ data, and stop as soon as the vulnerability is demonstrated.
- Do not degrade the service: no denial of service, no automated scanning at volume, no social engineering of our staff or customers, no physical attacks.
- Do not disclose the vulnerability before the date agreed with us.
If you follow these rules in good faith, we will not take legal action against you over your research and, should a third party do so, we will make it known that you acted in line with this policy.
Usually not accepted
Reports from automated tools without a demonstrated impact, missing security headers or cookie flags with no exploitable consequence, self-XSS, clickjacking on pages with no sensitive action, rate limits on non-sensitive endpoints, and the version numbers of public software.
We do not offer financial rewards. Last updated 8 November 2026.