Security and vulnerability disclosure

Last updated: 26 October 2026.

bomwerk reads repositories that it treats as hostile, and we sell evidence for the EU Cyber Resilience Act. We hold ourselves to the same standard: a published way to report a problem, and a published time we answer in.

How to report

Use either route. Please do not open a public issue for a suspected vulnerability.

  • GitHub private vulnerability reporting: the Security tab of bomwerk/bomwerk, then Report a vulnerability. This is the preferred route.
  • Email: info@bomwerk.com. Say in the subject that the message concerns a vulnerability.

Useful in a report: what you ran, what happened, what you expected, the version (bomwerk --version) and the platform. A repository or file that reproduces the behaviour is the fastest path to a fix; if it cannot be shared, a description of its shape usually gets us there too.

The same contact is machine-readable in security.txt (RFC 9116).

What to expect

bomwerk is a small team, so these are commitments we can keep, not aspirations.

  • Acknowledgement within 3 working days (Monday to Friday, Spanish time).
  • An assessment within 10 working days, with a fix or a plan and a target date.
  • Updates at least every 10 working days while the report is open.
  • Notice when a fix ships, and coordinated disclosure: we ask you to wait for the fix, or 90 days from your report, whichever comes first, before publishing details. If we need longer we will say why, and agree it with you.

Scope

bomwerk reads untrusted input by design. The following are vulnerabilities, not expected behaviour:

  • a crafted manifest, lockfile, archive or binary that crashes the scanner, hangs it, or makes it read or write outside the paths it was given;
  • anything that causes the scanner to execute code from the repository it is scanning, including through a build tool or a repository-local configuration;
  • a network request to a host that is not in the allowlist printed by bomwerk --endpoints, or any transmission of scanned source;
  • output that misrepresents what was checked, for example a component reported as clean when its data was never fetched;
  • a flaw in this website or in how we distribute releases.

Out of scope

  • A missed component, a wrong version, or an unmatched advisory. Those are accuracy bugs: please open a normal issue, they are just as welcome.
  • The absence of an SBOM for an ecosystem bomwerk does not parse yet.
  • Findings produced by scanning a deliberately malicious repository, when the scanner reported them and stayed within its own process and output paths.
  • Denial of service through volume, social engineering, and physical attacks.
  • Missing best-practice headers with no demonstrated impact.

Safe harbour

If you act in good faith and follow this policy, we will not pursue or support legal action against you for your research. Good faith means: you test only against your own systems and data, or against bomwerk itself within the scope above; you do not access, change or keep other people's data beyond what is needed to show the problem; you do not degrade the service for others; and you give us a reasonable chance to fix the issue before disclosing it.

This is our commitment as the operator of bomwerk. It cannot bind third parties, such as the maintainers of a repository you scan.

Credit

We credit reporters by name, or handle, in the release notes and in the advisory, unless you would rather stay anonymous. We do not run a paid bounty programme.

Supported versions

Until 1.0, only the latest release receives fixes.