#Security Bulletin

NTC-GL-021 | Version 1.0.0 | Last Modified On 31 July 2026

---

#Purpose

A Security Bulletin is how Edsol Edtech Pvt. Ltd. tells the world, customers, prospective customers, researchers and the hospitals' own auditors, that a security defect existed in Pensieve or in something Pensieve depends on, what it could have done, and what has been done about it.

This document is two things at once:

1. The standard: when a bulletin is published, who decides, what it must contain, and what it must never contain (Sections 1 to 7).
2. The instrument: the fillable bulletin itself (Section 8), which is rendered per bulletin and published at https://trust.pensievelabs.org/security/bulletins.

Publishing bulletins is a net cost to Pensieve Labs in the short term and the reason a hospital's IT head will believe anything else Pensieve Labs says. A vendor with an empty bulletin page has either found nothing or published nothing, and the buyer cannot tell which.

---

#Applicability

Who must act on a bulletin differs by deployment model. Every bulletin carries this table with the model-specific action filled in.

The DM-4 line is the reason bulletins exist in this form. An on-premise hospital that is not told, in a citable document, that a fixed version is available has no way to become secure.

---

#1. When Pensieve Labs publishes a bulletin

A bulletin is published whether or not any customer was affected, and whether or not the defect was found internally. Pensieve Labs does not publish only the vulnerabilities other people found.

---

#2. Timing

Where a DM-4 deployment is affected, the bulletin is published when the fixed version is available for the Customer to install, and the fixed version is available no later than the timescale in ADD-GL-001 clause 8.4. Pensieve Labs does not hold a bulletin back because a DM-4 customer has not yet upgraded; the mitigation is stated instead.

Embargo. Pensieve Labs will hold publication where publishing before a co-ordinating party is ready would put others at risk: an upstream maintainer's own disclosure date, a co-ordinated disclosure through a national CERT, or a fix not yet available for a component Pensieve Labs does not control. The bulletin records the embargo and the reason when it is published. Pensieve Labs does not embargo a bulletin for a commercial reason, for a sales cycle, or for a funding, audit or renewal event.

---

#3. Bulletin identifiers

Format: PSB-YYYY-NNN. Pensieve Security Bulletin, calendar year of publication, zero-padded sequence within the year, allocated in order of publication and never reused. A withdrawn bulletin keeps its identifier and is marked Withdrawn with the reason.

Revisions. A bulletin is revised, never rewritten. Each revision increments a revision number (PSB-YYYY-NNN r2), carries its own date, and the revision history at the foot of the bulletin states what changed. Previous revisions remain retrievable. A bulletin whose content changed without a revision entry is a bulletin nobody can rely on.

#3.1 CVE identifiers: the honest position

Edsol Edtech Pvt. Ltd. is not a CVE Numbering Authority. It does not assign CVE identifiers and does not represent that it can.

A bulletin without a CVE is not a lesser bulletin. The PSB identifier is the citable reference for a hospital's own vulnerability register, and the bulletin states the CVSS v3.1 vector so the hospital can score it in its own framework.

---

#4. Severity

Bulletin severity is the classification in ADD-GL-001 clause 8.3: CVSS v3.1 base score adjusted for exploitability in Pensieve's actual configuration and for exposure. The bulletin publishes both: the raw CVSS vector, and Pensieve Labs's adjusted classification with the reason for any adjustment.

Where Pensieve Labs scores a vulnerability lower than the upstream vendor, the bulletin says so and says why, and states what would change the answer. Downgrading a score without publishing the reasoning is indistinguishable from downgrading it for convenience.

---

#5. What a bulletin never contains

1. No working exploit, proof-of-concept code, or step-by-step reproduction while any customer remains unpatched, and for DM-4, that means while any supported release remains vulnerable.
2. No customer name, tenant identifier, hospital name or patient-identifying detail. Ever. A bulletin describing a defect found in one hospital's tenancy names no hospital.
3. No internal hostname, IP range, credential, key identifier, bucket name or path that would assist an attacker. Architecture is described at the level of DIS-GL-006, not DIS-GL-007.
4. No blame directed at a researcher, a sub-processor, an employee or a customer.
5. No claim that the Platform is secure, or that this was the last such defect. State what was fixed.
6. No marketing. A bulletin does not link to a product page, does not mention a competitor and does not describe the fix as an improvement.

---

#6. A bulletin is not an incident notice

Where a vulnerability was exploited, both are issued, and the incident notice goes first. The bulletin follows once the affected hospitals have been notified and containment is complete. A bulletin is never the mechanism by which a hospital learns that its own data was affected.

---

#7. Acknowledgement

Pensieve Labs credits the person who reported a vulnerability, by the name and affiliation they ask for, in every bulletin arising from an external report. This is the operative practice under POL-GL-059.

1. The reporter chooses. Full name, handle, organisation, or anonymous. Pensieve Labs asks before publication and honours the answer.
2. The credit is in the bulletin, not only on a separate page, and it survives every revision.
3. A report that turns out not to be a vulnerability still gets a reply, within the timescales in POL-GL-059. It is not acknowledged in a bulletin, because there is no bulletin.
4. Pensieve Labs will not require a non-disclosure agreement as a condition of being credited, and will not condition credit on the reporter's silence about the report.
5. Where a reporter asks for a coordinated publication date, Pensieve Labs agrees it in writing and keeps it, unless the vulnerability is being actively exploited, in which case Pensieve Labs tells the reporter, and publishes.

---

#8. The bulletin: template

Render note. Everything below is the published instrument. Fields resolve from the bulletin.* token namespace registered in Section 9. A bulletin with an unresolved required field cannot transition from DRAFT to ISSUED (SPEC-003 Section B.7.3).

#Summary

Bulletin summary

One paragraph. What the defect was, what an attacker could have done, whether it was exploited, whether it is fixed, and whether the reader must do anything. A reader who stops after this paragraph must not be misinformed.

#Background

Bulletin background

What the affected component does and why it exists, in terms a hospital IT head who has never seen the code can follow. No more than a short paragraph.

#Details

Bulletin details

The technical description: the class of defect, the conditions required to exploit it, the privileges an attacker would need, what the attacker would obtain, and the limits of the impact. State explicitly whether cross-tenant access was possible. For DM-2 customers that is the only question that matters. State what authentication, network position or user interaction was required, because those determine whether the hospital's own controls already blocked it. No exploit code, no reproduction steps.

#Impact assessment

"No evidence of exploitation" is written only where the logs that would have shown it exist, were retained, and were examined. Where that is not the case, the answer is "Cannot be determined", followed by why. DIS-GL-013 and DIS-GL-034 state what is logged and for how long.

#Remediation

Bulletin remediation

Interim mitigation, where a fix is not yet available to you: Bulletin mitigation

How to confirm you are no longer affected: Bulletin verification

State a check the hospital can run itself: a version string, a configuration value, a response header, a log query. "Contact support to confirm" is not a verification step.

#Timeline

The timeline records, at minimum: when the defect was introduced (or "not determined"); when it was reported or detected, and by whom in general terms; when it was confirmed; when the fix was available; when each deployment model was remediated; when any affected customer was notified; and when this bulletin was published. Where a commitment in ADD-GL-001 clause 8.4 was missed, the timeline shows it and the bulletin says so, the same rule as DIS-GL-016 Section 5.

#Acknowledgement

Bulletin acknowledgement

Per Section 7. Where the defect was found internally, this reads: "Found by Pensieve Labs during Bulletin discovery activity." Where a researcher reported it and chose anonymity, it reads: "Reported by a researcher who has asked not to be named. Pensieve Labs thanks them."

#References

Bulletin references

#Revision history

#Contact

Questions about this bulletin: info@pensievelabs.org. Reporting a vulnerability: POL-GL-059 and https://trust.pensievelabs.org/.well-known/security.txt. Customers with a support agreement may raise a Ticket under SLA-GL-001; a bulletin-related Ticket is handled at the Severity Level the bulletin's severity implies.

---

#9. Token namespace registered by this document

Pensieve Labs registers the bulletin.* namespace under SPEC-003 Section B. Required fields cannot be blank at issue.

---

#10. Distribution

Publication is not notice for DM-4. Where a DM-4 Customer must install a release, the bulletin is sent to that Customer directly, and Pensieve Labs records the despatch. This is the same rule as POL-GL-064 clause 2.3.

---

#11. Roles

The decision to publish sits with Security, not with Commercial. No sales, commercial or investor consideration is a ground for withholding, delaying or softening a bulletin, and any request to do so is recorded in the Exception & Waiver Register (REG-GL-210) whether or not it is granted.

---

#12. Related documents

---

#Change history