The platform

Overview

ThreatBharat publishes cyber threat intelligence relevant to India. The public side of the platform is a reviewed, openly readable body of reporting. Behind it sits an editorial workflow that decides what gets published, how it is labelled, and what happens when we are wrong.

A separate, limited surface lets a reviewed organisation record what it needs watched so that published reporting can be matched against it. That surface is not open — it is reached by requesting access and being reviewed by a person.

Public threat intelligence

Everything in this section is readable by anyone, right now, without an account.

• Public threat feed

  ●Publicly available

  A chronological feed of published reports, filterable by category, sector and severity. Open to anyone, no account required.

• Reviewed intelligence publications

  ●Publicly available

  Full reports carrying a verification label, a confidence level, a structured assessment and defensive guidance. Nothing reaches this feed on one analyst’s word.

• Ransomware reporting

  ●Publicly available

  Reports of ransomware victim listings and group activity, presented as claims until corroborated. A listing is what an actor asserted, not a confirmed breach.

• Threat actor directory

  ●Publicly available

  Profiles built only from what we have observed — aliases, observed forums, targeted sectors — each with attribution caveats. Attribution is never presented as certain.

• Vulnerability intelligence

  ●Publicly available

  Published reporting on vulnerabilities being exploited against India-relevant targets, plus public advisories. This is not a CVE database and does not attempt to mirror one.

• India-focused reporting

  ●Publicly available

  A national view of published reporting, broken down by sector and state where the underlying reports support it.

• Correction and retraction history

  ●Publicly available

  When we get something wrong we correct it in public and leave the notice attached to the report. A retracted report keeps a visible record rather than disappearing.

Organisational monitoring

These capabilities exist and run, but they are not open. They are reached through a reviewed organisational access grant, and they describe an organisation’s own exposure — not anyone else’s.

• Organisation and asset profiles

  ◐Limited organisational access

  A reviewed organisation can record the domains, brands and infrastructure it wants watched, so reporting can be matched against something specific.

• Watchlists

  ◐Limited organisational access

  Standing watch terms for an organisation’s own names and assets, used to surface relevant published reporting.

• Priority intelligence requirements

  ◐Limited organisational access

  Recorded standing questions an organisation needs answered, so collection and review can be pointed at what actually matters to them.

• Candidate intelligence matching

  ◐Limited organisational access

  Proposed matches between published reporting and an organisation’s recorded assets. Matches are candidates for a human to confirm — never an automated verdict.

Analyst and publication workflow

This is staff tooling. It is described here because it is the reason to trust — or to question — what appears on the public side, not because it is a feature anyone else can use.

• Analyst authoring and review

  ◍Internal workflow

  Reports are drafted, reviewed and approved by different people. Authorship and publication authority are held by separate roles, so one account cannot take a claim from idea to public.

• Pre-publication checks

  ◍Internal workflow

  A report cannot be published until its pre-publication checks are satisfied and the publisher has recorded their attestations.

• Editorial correction and retraction

  ◍Internal workflow

  Changing or withdrawing a live report is a separate, permissioned action that writes an immutable revision record. Retraction sits with the two highest platform roles.

Evidence handling

We publish evidence to make reporting checkable, and we redact it so that publishing does not become redistribution. Read the source handling policy for the full position.

• Evidence-redacted publication

  ●Publicly available

  Screenshots published with a report are manually redacted derivatives, labelled as such. The original capture is never published and never linked.

• Reviewed evidence approval

  ◍Internal workflow

  Every published image passes an upload, redaction and approval chain. The person who uploads a derivative may not be the person who approves it.

• Malware scanning on upload

  ◍Internal workflow

  Uploaded evidence is scanned before it is stored. If the scanner is unreachable, uploads are refused rather than waved through.

Security and governance

Access to every internal surface is deny-by-default and permission-gated, and high-impact actions additionally require multi-factor and recent authentication. Actions that change the public record write an immutable audit event naming who did it and why.

Inbound requests submitted through this site are stored privately and are never exposed on any public surface. Submitter IP addresses are stored only as a keyed hash, never in the clear. See privacy and responsible publication.

Current availability

ThreatBharat is early. The public feed, the directories and the published reporting are live and readable today, and the volume of published reporting is still small — we would rather publish little and label it honestly than fill a page.

Some capabilities described on this page are marked limited organisational access or internal workflow. If a capability is not listed on this page, we do not have it. We do not describe planned work in the present tense, and nothing on this site should be read as an endorsement by, or an affiliation with, any government body.