Provetry vs Dependabot: is GitHub enough for the CRA?
On this page
If your code lives on GitHub, you probably already have Dependabot: it reads your manifests and lock files, warns you when a dependency has a known vulnerability, and can open the pull request that upgrades it. It costs nothing. So does a manufacturer need anything else for the Cyber Resilience Act? This page sets out what Dependabot and GitHub cover, what they leave to you, and where Provetry fits, as of November 2026. Provetry opens in November 2026; Dependabot is available today.
In one sentence
Dependabot keeps the dependencies of each repository up to date and warns you of known vulnerabilities in them. Provetry follows the products you sell, release by release, and the duties the CRA attaches to them: an SBOM per release, a watch on exploited vulnerabilities, the Article 14 reports to ENISA, the disclosure policy and the technical documentation.
Side by side
For Provetry, the plan that includes each feature is given in brackets. Prices exclude VAT.
| GitHub (Dependabot and the dependency graph) | Provetry | |
|---|---|---|
| Availability | Available | Opens in November 2026 |
| Price | Included with GitHub | Free for one product, then €49, €149 or €399 a month |
| Unit of work | A repository and its default branch | A product and each of its releases, possibly built from several repositories |
| Alerts | On reviewed advisories of the GitHub Advisory Database | On OSV.dev (which includes the GitHub advisories), with exploited vulnerabilities first; every day on paid plans, every week on Free |
| Upgrades | Security and version update pull requests | No automatic pull requests; tickets in GitHub, Jira or Linear (Pro and Consultant) |
| SBOM | Export of the dependency graph in SPDX, for the current state of the repository | CycloneDX 1.6 (all plans; up to 3 releases on Free); SPDX 2.3 and 3.0.1 (paid plans); one SBOM kept per release |
| Releases still in the field | Alerts follow the default branch | Every release you mark as supported is checked |
| Exploited vulnerabilities | EPSS scores on alerts | CISA KEV and ENISA’s EU list (EUVD), then EPSS |
| Assessments | Dismiss an alert with a reason | VEX assessments carried over to later releases and exported as OpenVEX (all plans); public VEX feed (paid plans) |
| Article 14 reporting to ENISA | No | Reporting case opened from the moment you became aware, deadlines counted down, drafts that follow the fields of ENISA’s platform (paid plans) |
| Disclosure | SECURITY.md security policy; private vulnerability reporting and repository advisories for public repositories; no CSAF |
Disclosure policy, contact address for reports (for example security.txt), CSAF advisories and a public security page per product (paid plans) |
| CRA technical documentation | No | Guided dossier and draft EU declaration of conformity (Pro and Consultant) |
Where Dependabot covers the need
- Your product is a single repository, you ship from the default branch, and only the latest version is in use. Dependabot then covers the tracking of vulnerable dependencies; if you are a manufacturer under the CRA, the reporting and documentation duties remain whatever tool you use.
- You are not a manufacturer under the CRA, for example because your product is a pure SaaS. Keeping dependencies current is then good hygiene, and Dependabot does it well.
- You maintain an open source project outside any commercial activity. The CRA does not, in general, treat you as a manufacturer, and GitHub’s security policy, private vulnerability reporting and advisories give you a clean disclosure channel. See The CRA and open source.
Where Provetry adds something
- Several versions are in the field. The CRA asks you to handle vulnerabilities for the whole support period you announced. Customers on version 2.1 are not protected by a fix merged into the main branch of version 3. Provetry keeps the SBOM of each release and checks every supported one, every day on paid plans.
- You need to know what is exploited, and act within 24 hours. An alert says a dependency is vulnerable. Article 14 sets deadlines from the moment you become aware that a vulnerability in your product is actively exploited. Provetry puts the CISA and ENISA lists first, lets you open a reporting case from that moment, counts down the deadlines and drafts the early warning, the notification and the final report.
- A product is more than one repository: a firmware, a mobile app and a backend, or a container image described by an SBOM from a tool such as Syft. Provetry describes the product, not the repository.
- You need the documents an authority will ask for: the technical documentation of Annex VII, an evidence journal of your decisions, a draft EU declaration of conformity.
Using both
This is the most common case. Keep Dependabot for what it does best, upgrading dependencies in the code you are writing. Use Provetry to keep the CRA file of each product and release you place on the market. GitHub’s SPDX export can be uploaded to Provetry instead of the lock files; it works best from a repository with lock files, since dependencies without an exact version are left out.
What to check before choosing
- Is your product in scope? The free check tells you in a few minutes.
- How many releases do you support at once? If the answer is more than one, a tool that only watches the default branch leaves gaps.
- Who will write the ENISA reports? That duty has applied since 11 September 2026, whatever tool you use.
GitHub and Dependabot are trademarks of GitHub, Inc. Provetry is not affiliated with GitHub. The facts above were checked in November 2026 against the sources below; if something has changed, tell us at hello@provetry.com and we will correct it.