Documentation.

This guide takes you from the first sign-in to a product that is watched, with alerts that reach the right people and a build pipeline that keeps the bill of materials current. It takes about an hour, most of it in your pipeline.

What the Reporting Desk does, and what it does not

A manufacturer of a product with digital elements that becomes aware of an actively exploited vulnerability in its product must report it through the single reporting platform operated by ENISA: an early warning within 24 hours, a vulnerability notification within 72 hours, and a final report no later than 14 days after a corrective or mitigating measure is available (Regulation (EU) 2024/2847, Article 14). A severe incident having an impact on the security of a product has the same first two stages, and its final report is due one month after the incident notification.

The Reporting Desk:

• keeps the software bill of materials (SBOM) of each of your products;
• runs hourly checks for actively exploited vulnerabilities (CISA KEV, ENISA EUVD), matched with OSV advisory data to npm, PyPI, Maven, Go and NuGet components;
• opens a case when a component of one of your products has a vulnerability either list names as exploited, runs its three deadlines, and sends alerts by e-mail to the contacts you name and to Slack, Microsoft Teams or a signed webhook;
• drafts each report from what it knows, as text you copy into ENISA's Single Reporting Platform, and records when you submitted it.

It does not submit reports for you: the Single Reporting Platform takes submissions by hand, from you. It does not look at your source code or your firmware, only the component list you give it. And it can only watch what it can identify: components in the npm, PyPI, Maven, Go and NuGet ecosystems, with a package URL. Everything else is reported as not monitored, never as safe; the product's coverage says which components those are.

1Sign in and accept the documents

Sign in with your work e-mail address. There is no password: you get a sign-in link by e-mail, which works once, for 10 minutes.

The first person of your company to sign in accepts the Terms of Service and the Data Processing Agreement on the company's behalf, and must be authorised to. Every person confirms once that they have read the privacy notice. The records name the version, where it is published, the time and the person, and cannot be changed. When a document changes, the new version is shown at the next sign-in; your API tokens keep working in the meantime.

2Name the people alerts go to

Open Alerts and contacts. Add at least two people; watching a product needs two. The primary contact gets the first alert when a case opens.

Use addresses people read at short notice, not a shared inbox nobody owns. Alerts come from alerts@bithive-it.com; add it to your mail filter's allowed senders.

Acknowledging tells the Reporting Desk that someone has the case in hand. Either open the case in the application, or press the button behind the link in the alert. The link works once, for seven days; opening it changes nothing, because mail filters open every link to check it, and only the button acknowledges. Acknowledging stops no deadline.

Other channels (optional, in every plan). Under the same page you can add an https address that alerts also go to, and say which alerts it should carry: every one, only the first alert of a case, or the urgent ones. Three kinds:

• Slack, with the address of an incoming webhook from your workspace (hooks.slack.com/services/...), made at api.slack.com/apps; a Workflow Builder address is refused. The message appears in the channel with a link to the case.
• Microsoft Teams (Workflows webhook): in Teams, create a Workflows webhook with the template "Send webhook alerts to a channel" and add its address (...environment.api.powerplatform.com/...). The message appears as a card with a button.
• Webhook, for PagerDuty, Opsgenie or a ticket system: JSON, signed as Standard Webhooks describes, with the secret shown once when you add it (it begins with whsec_); verify the signature before acting on a delivery.

Send the test message from the same page: you find out that the channel works before a case depends on it, and if it does not, the page says what to do. Every alert delivered to a channel, successful or not, is recorded on its case like an e-mail.

3Add your products

Open Products and add each product you place on the EU market, under the name you would use in a report. Your plan includes a number of products (3, 10, 25, or 26 to 5,000 on Enterprise); the page shows how many you have.

A product you add once the two contacts from step 2 exist starts with alerts on, and the page says so before you add it. A product added before them starts with alerts off: press Turn alerts on for it once the contacts are there. Until alerts are on, nobody is told about the product's cases.

4Upload a bill of materials

A bill of materials in CycloneDX or SPDX, as JSON, up to 10 MiB. Generate it in your build with an established open-source tool, for example:

syft dir:. -o cyclonedx-json > sbom.json      # Syft
cdxgen -o sbom.json .                         # cdxgen

Generate it from what you ship: the built artefact or its lockfiles, not a developer's checkout with test dependencies. The better the tool can see package URLs, the more of the product is watched.

The first time, upload it on the product's Bills of materials page. The product's Findings page shows, within seconds, which components have known vulnerabilities, which of those are being exploited, and the coverage: how many components are watched and which are not, and why.

5Keep it current from your pipeline

Every release changes the component list, so upload from the pipeline that builds the release. There is nothing to install: the pipeline calls the HTTPS API with curl.

1. Open API tokens and create a token with the scope sboms:write, limited to the product it uploads for, with an expiry (a year at most). The token is shown once; store it as a secret in your CI system, for example BITHIVE_TOKEN.
2. The product's identifier is in the address of its pages (/products/IDENTIFIER/findings). Store it as BITHIVE_PRODUCT.
3. After the build, generate the bill of materials and upload it:

curl --fail-with-body -sS -X POST \
  -H "Authorization: Bearer $BITHIVE_TOKEN" \
  -H "Content-Type: application/vnd.cyclonedx+json" \
  --data-binary @sbom.json \
  "https://app.bithive-it.com/v1/products/$BITHIVE_PRODUCT/sboms"

For an SPDX document, use Content-Type: application/spdx+json. The answer is 201 for a new upload and 200 when the same document was uploaded before, which does nothing, so a pipeline that runs twice is harmless. An error answers with a problem description (RFC 9457) that says what is wrong, readable in the CI log.

In a GitHub Actions workflow, the same as a step after the build:

- name: Upload the bill of materials
  env:
    BITHIVE_TOKEN: ${{ secrets.BITHIVE_TOKEN }}
    BITHIVE_PRODUCT: ${{ vars.BITHIVE_PRODUCT }}
  run: |
    curl --fail-with-body -sS -X POST \
      -H "Authorization: Bearer $BITHIVE_TOKEN" \
      -H "Content-Type: application/vnd.cyclonedx+json" \
      --data-binary @sbom.json \
      "https://app.bithive-it.com/v1/products/$BITHIVE_PRODUCT/sboms"

In GitLab CI and Jenkins, run the same curl command in a job step, with the token taken from a masked CI variable or a credential.

6When a case opens

A case opens when a component of one of your products has a vulnerability that CISA or ENISA lists as actively exploited. That happens when the list names a vulnerability your components already have, within the hour, or when you upload a component that has one, at the list's next reading, also within the hour. Your primary contact gets an alert with a link to the case.

On the case page:

• The clocks. The 24-hour and 72-hour deadlines run from when you became aware, which starts as the moment the Reporting Desk recorded the case. If you knew earlier, move it earlier and say why; it can never move later. The final report's clock starts when you record that a fix is available.
• Reports. Each stage has a form with the fields Article 14 asks for, drafted from what the Reporting Desk knows and completed by you. It gives you the text to copy into the Single Reporting Platform. After you submit there, record the time here; the record cannot be changed.
• Who was told. Every alert, to whom, and whether it was delivered, so that a failed delivery is visible, not silent.
• Dismissing. If the finding does not apply, for example because the vulnerable code is not in what you ship, dismiss the case with the reason. It stays in the record.

A severe incident affecting your product's security, which nothing can detect for you, is recorded under Cases with Record a severe incident. It runs the same clocks and reports.

7Your data, and taking it with you

The application and customer data are hosted in Germany. Alerts are sent by e-mail through an EU provider. The Reporting Desk keeps the bills of materials you upload, the findings, cases, reports and the audit log of your account, which records every change with who made it and when.

You can take all of it at any time: Settings → Your data → Download everything gives you one archive with the account, every document as it arrived, the findings, the cases with their deadlines and reports, and the whole audit log. Section 6.3 of the Terms gives you this in every plan, and downloading it changes nothing in the service.

8NIS2 and the GDPR: incident records

For accounts with the NIS2 module (Germany: BSIG, EnWG, § 168 TKG, eIDAS) or the GDPR breach module (Articles 33 and 34, § 169 TKG). An account without either sees none of these pages. The Owner and Administrators keep the legal entities, the contracts and who sees which module; Members record incidents and their reports; Viewers read.

The Reporting Desk suggests which obligations an incident may trigger and runs their deadlines. Whether an obligation applies is your decision, and nothing on these pages is a legal assessment.

Your legal entities. Each company of your group that the duties can fall on is a legal entity.

1. Under Settings → Legal entities, press Add a legal entity. Give its name, country, register number, VAT ID, LEI and time zone, and tick the modules it is designated for. You see the entity's page.
2. On that page, answer the modules' questions about it: for NIS2, whether it is an important or particularly important entity, and whether it runs energy or telecommunications networks; for the GDPR, its supervisory authority. The answers apply to every incident that names the entity.
3. For NIS2, record its registration with the BSI and the date. Until you do, the page reminds you.

Each module's size covers a number of legal entities, as the price list states. When all of them are designated, a further designation is refused with the way out: a larger size under Plan and billing, or the module taken off another entity first. A legal entity that a record names cannot be removed.

Recording an incident.

1. Press New incident record on the Cases page. State when you became aware and, if known, when it happened, what happened, the legal entities and contracts it concerns, the Member States and services, and which definitions it meets (a significant incident, a personal data breach).
2. Press Record the incident. The record's page lists each obligation per party: the law, who owes it, whether it applies as the answers suggest, and each stage with its deadline. Why this deadline shows the rule, its version, the moment it counts from and the values it was computed from.
3. Answer the record's questions and decide each obligation: departing from the suggestion needs a reason. Every decision, answer and moment goes to the audit log.
4. Record moments as they happen: a request with the time an authority stated, or the end of handling. The deadlines move with them.

When you process personal data for others. With the GDPR module, of any size, a breach you handle as a processor opens your notice to each controller concerned (Art. 33(2) GDPR).

1. Under Settings → Contracts, press Add a contract: its kind is Controller you process personal data for (Art. 33(2) GDPR). Give the controller as the Counterparty, paste your agreement's clause on breach notices under The clause as written, add a Business address for notices if you like, and press Save the contract. A contract that a record names cannot be removed.
2. When you record the breach, name the controllers it concerns under Contracts, and answer the record's question on your role with A processor. The record opens Notifying the controller (Art. 33(2)) for each of them: the notice is due without undue delay from when you became aware, and you are reminded after 24 and after 72 hours. These reminders are not statutory deadlines.
3. The report page drafts the notice with what the controller needs (Art. 33(3) GDPR), and Record as submitted keeps when each controller was informed. Your controllers decide on notifying the supervisory authority and the data subjects.

Reports and their copy. Each stage links to its report page. Fill in the form (the fields are the authority's; a late report asks for its reasons), save it, submit it through the channel the page names (the BSI's portal, the authority's form, e-mail, a letter), then press Record as submitted with when, by whom, to which recipients over which channels, and the authority's reference. The page then keeps the submission copy: the text as submitted and its SHA-256, which the audit log also holds.

Who sees which module. Under Settings → Who sees each module, a module can be restricted to named users. The Owner always sees every module. A user who is not named sees nothing of a restricted module: no record, deadline, report, audit line, alert or export entry of it, and no legal entity or contract of it under Settings (of an entity shared with a module they see, only that module's designation and answers and, for NIS2, its BSI registration). Saving a shared entity keeps what they do not see; removing it is left to someone who sees all of it.

Alerts. A record's obligations alert like a case: an opening alert, reminders before each deadline and an overdue notice, by e-mail and to your Slack, Teams and webhook channels. A webhook receives them as events obligation.opened, obligation.reminder and obligation.overdue, with "version": 2. A restricted module's alerts go by e-mail only to the alert contacts who are users allowed to see it, or to the Owner where none is, and reach only the channels switched on for it under Settings → Who sees each module.

What the download holds. Download everything (section 7) includes each record with its obligations (the sources and decisions), its deadlines (the rule, its version and what it was computed from), its answers and the items it affects, and each report's draft and submission copy: the text as recorded and its SHA-256, the same as in the audit log. parties.json holds the legal entities (the modules each is designated for, its answers and its BSI registration) and the contracts. Where a module is restricted, the download holds only the modules of the person who downloads it.

Help

Write to contact@bithive-it.com. If an alert did not reach you, or a case seems to be missing, tell us at once: we treat it as an incident.