Disclosure Process
How brin handles threat disclosure and coordinates remediation with maintainers
Overview
brin scans every package published to supported registries. When a potential threat is detected, it goes through verification before findings are disclosed and published. This process protects users while giving maintainers time to respond.
Protection vs. Public Disclosure
Protection is immediate. As soon as brin detects a threat, users are protected. The CLI will block or warn when you try to install an affected package—no grace period, no delay.
Public disclosure follows a process. The grace period described below applies only to publishing findings publicly on the brin website (package pages, advisories, and AGENTS.md documentation). This gives maintainers time to respond before their package is publicly flagged.
This distinction matters: users are never left exposed while we wait for disclosure timelines.
Step 1: Initial Scan
An automated scan runs on every new or updated package. The scan checks for:
- Known CVEs from authoritative databases (OSV, GitHub Advisory, NVD)
- Agentic threats such as prompt injection, instruction overrides, and error message attacks
- Suspicious install scripts that run during package installation
- Capability analysis including network access, filesystem operations, and process spawning
Packages with potential threats are flagged and assigned a risk level:
- Warning — Patterns detected that warrant attention but don't indicate a confirmed threat. Warning-level findings are surfaced directly to users from automated scans and do not go through human review.
- Critical — High-confidence detections that indicate a likely threat. Critical findings proceed through the full verification and disclosure pipeline described below.
Critical packages are not publicly identified until their findings are verified and disclosed to maintainers. Until then, they appear anonymized on the brin website with their identity withheld. Warning-level packages are published immediately with full identity.
Step 2: Verification Scan
Critical-level findings go through deeper automated analysis:
- Pattern matching against known attack signatures
- Behavioral analysis of install scripts and runtime code
- Cross-referencing with threat intelligence databases
Findings that don't survive this pass are discarded. Those that do proceed to human review.
Step 3: Human Verification
A human reviewer validates critical findings. The reviewer confirms whether the detection is a genuine threat, assigns severity, and determines remediation guidance.
Findings use a three-state verification workflow:
| Status | Description | Risk Impact |
|---|---|---|
pending | Detected, awaiting review | None |
in_progress | Under human review | None |
verified | Confirmed by human review | Affects risk level |
Only verified critical threats affect package risk levels through this pipeline. Warning-level findings are automated-only and shown on package pages without entering the review process.
Step 4: Disclosure
Once a threat is verified, brin notifies the package maintainer with a disclosure report containing a summary of the threat, severity level, technical details, and recommended fix.
The maintainer has a 14-day grace period to respond or fix the issue before findings are published publicly.
If a threat is actively being exploited in the wild, brin may skip the grace period and publish findings immediately.
Step 5: Findings Update
After disclosure (or grace period expiry), the package identity is made public and brin updates the findings database:
- The package is de-anonymized — its real name replaces the withheld identifier on the website
- The package page reflects the verified threat and updated risk level
- Risk scores are recalculated across affected versions
- AGENTS.md guidance is updated with warnings and safe version recommendations
- A public advisory is published with full technical details
Maintainers can dispute findings through the brin review process at any time.
On this page