Review of the Akrites SIRT CVD Policy against GCVE BCP-02

adulau · October 29, 2026, 9:33am

Review of the Akrites SIRT CVD Policy against GCVE BCP-02

Review date: 29 October 2026
Document type: Independent comparative policy review / discussion draft
Subject: Akrites SIRT Coordinated Vulnerability Disclosure Policy and its newly announced CVE Numbering Authority (CNA) role
Benchmark: GCVE BCP-02, Practical Guide to Vulnerability Handling and Disclosure, including Appendix B on multi-party CVD
Scope: Public documentation; this review does not audit actual case-handling practice or determine legal compliance.

Executive summary

Overall assessment: substantial alignment at the level of CVD principles, but important gaps and some explicit tensions in their implementation. Akrites offers a serious, structured approach to intake, triage, multi-party coordination, private patch preparation, public advisories, acknowledgement times, researcher credit, and safe-harbour language. Its distinction between Finder, Owner, Collaborator, and Consumer and its operational role as a clearinghouse broadly match the principles in GCVE BCP-02.

The most consequential differences are about who can report, who can participate before disclosure, who controls the disclosure clock, how confidential information is shared, and how public-interest obligations are protected from membership or institutional interests. The treatment of public AI services as automatically making an embargo unavailable is also more categorical than BCP-02’s evidence-based approach. Finally, Akrites’ recent CNA designation creates a need for a clearer, public CVE assignment policy and a separation between the SIRT’s coordination remit and its limited CVE assignment scope.

Headline recommendations:

Make good-faith public and non-member vulnerability intake available on clearly stated terms, even if full-scale coordination services remain phased or capacity-limited.
Define fair, documented, case-specific access criteria for independent downstream maintainers and repositories, including routes that do not require commercial membership or a member sponsor.
Preserve the original reporter’s agreed sharing terms and disclosure date; do not treat upstream or member schedules as automatically overriding a reporter’s rights.
Replace categorical AI-use = no embargo logic with a service-specific confidentiality and exposure assessment.
Add a CNA section addressing Akrites’ exact allocation scope, upstream Supplier CNA priority, allocation conflicts, duplicate handling, and record publication.
Clarify TLP, originator consent, safe harbour, regulatory reporting, early-warning exceptions, and independent dispute escalation.

None of these findings implies that Akrites has mishandled a real vulnerability; the assessment concerns the text and foreseeable governance consequences of published draft policies.

1. Sources, versions and methodology

The comparison uses the following sources as at the review date:

Source	Version/status reviewed	Reference
Akrites SIRT CVD Policy	Draft v0.4, last updated 2026-08-24	Akrites CVD Policy
Akrites Read-In Policy	Draft v0.3, dated 2026-09-23; states that it will supersede earlier read-in guidance on ratification	Akrites Read-In Policy
Akrites Embargo Handling Guidance	Draft v0.2	Embargo Handling Guidance
GCVE BCP-02 source	Version 2.0, dated 2026-10-28 in the repository	BCP-02 Markdown source
GCVE public rendered website	Version 1.9, dated 2026-10-15 when checked; temporarily lags the source	GCVE BCP-02 website
CVE Program announcement	27 October 2026, new Akrites SIRT CNA	Official CVE news, Akrites partner listing
CVE Program operational rules	Version 4.2.6, effective 2026-10-20	CNA Operational Rules

Version qualification: The GCVE repository source contains BCP-02 v2.0 (28 October), including Appendix B: Multi-Party Coordinated Vulnerability Disclosure in Open-Source Ecosystems. Its rendered website still presents v1.9 (15 October). This review uses the more recent source version and identifies it explicitly so that readers do not mistake a difference in publication pipelines for a substantive policy contradiction.

Evidence classification: Aligned means the cited policy makes a compatible commitment; Partially aligned means the commitment exists but omits material safeguards; Tension means the stated rule may conflict with BCP-02’s recommended practice; Not demonstrated means the documentation is insufficient to reach a conclusion. BCP-02 is best-current-practice guidance, not a CVE Program certification checklist; failure to follow an individual recommendation is not itself evidence of a CNA rules violation.

2. CNA status: a distinct authority from CVD coordination

The CVE Program announced on 27 October 2026 that Akrites SIRT is a CNA for:

projects directly attached to the Linux Foundation or any of its sub-foundations, unless the project has a Supplier CNA of its own.

This is a bounded CVE assignment scope, not a mandate to allocate CVEs to all vulnerabilities Akrites might coordinate, nor to every open-source project hosted on GitHub. A coordinator may assist projects outside its CNA scope without being the authority that allocates their CVE IDs.

Akrites’ CVD Policy §6 describes coordination across upstream projects; §10 still says that a CVE ID is requested via the appropriate CNA. That wording was reasonable before the CNA announcement, but now underspecifies Akrites’ own role. The policy should distinguish clearly:

Case coordination: a potentially broad service, undertaken by consent or agreement with the relevant parties.
CVE ID assignment: limited to the CNA scope approved by the CVE Program, subject to the most appropriate CNA’s right of first refusal, existing Supplier CNAs, and the published CVE rules.
Advisory publication: the responsibility of the actor publishing the relevant technical information; upstream and downstream participants may issue different product-specific advisories referring to the same vulnerability identifier.

Relevant CNA Rules v4.2.6: §3.1 on scope; §3.2.6 on public CVE assignment/disclosure guidance; §4.2.1 on first refusal; §4.2.16 on overlaps and duplicate assignments. The CVE Program does not prescribe one mandatory CVD disclosure model merely because an organisation becomes a CNA. Its rules do, however, govern allocation and record publication.

Finding C1 — Partially aligned, high priority. Publish a dedicated, current CNA-specific policy or add a clearly identified section to the CVD policy spelling out the approved scope, allocation workflow, what happens when a project has a Supplier CNA, escalation to the appropriate Root, and where publicly accessible CVE Records and advisories are published. Avoid making Akrites’ possession of a report appear to confer the right to issue a CVE ID for an unrelated project.

3. Comparative assessment matrix

Area	Akrites published approach	GCVE BCP-02 expectation	Assessment	Priority
Public disclosure policy	Named roles, nine-stage lifecycle, contact, acknowledgement and triage objectives (§§1–7)	Document an accessible, accountable CVD workflow	Aligned	Low
Secure intake	GitHub private reporting and encrypted email (§4)	Practical secure channels, accept imperfect reports and provide alternatives	Aligned / clarify availability	Medium
Universal reporting access	Member-first rollout, then clearinghouses, then unsolicited public and anonymous reporting (§12)	Accessible reporting independent of organisational status; avoid unnecessary barriers	Tension	High
Reporter communication and credit	Two-business-day acknowledgement, ten-business-day initial assessment, attribution by default (§§5, 11)	Acknowledge, update, consult about attribution and disclosure	Aligned	Low
Confidentiality	Need-to-know read-in, private workspaces, TLP-based case handling (§§3, 8)	Protect sensitive details; purpose-limited, documented sharing	Partially aligned	Medium
Multi-party ecosystem	Upstream/downstream bridging; common release planning (§§2, 6–8)	Include distributions, independent repositories, forks, vendors, integrators, and users (Appendix B)	Partially aligned	High
Access to early fixes	Contributions and read-in gates; affiliation/sponsor prerequisites (§12 and separate draft)	Fair and workable access for parties able to take protective action, not tied solely to membership/payment	Tension	High
Disclosure clock	Thirty-day planning target after validation; upstream policy takes precedence (§8 and Embargo Guidance)	Negotiate case-specific dates, respect reporter’s original date; don’t reset clock silently	Partially aligned / tension	High
Active exploitation	Accelerated track; actionable guidance targeted within seven days (§9)	Risk-driven early advice/mitigation, potentially immediate	Aligned in principle / clarify urgency	High
AI confidentiality	Public hosted LLM use deemed to eliminate the embargo option (§8)	Assess actual disclosure, processing terms, controls, and threat model, technology-neutrally (Appendix B)	Direct tension	High
Researcher safe harbour	Express non-litigation commitment for good-faith research (§14)	Clear good-faith assurances	Aligned / scope caveat	Medium
Disputes and governance	Coordinator, internal independent review, TOC, Governing Board (§15)	Transparent neutral escalation, reporter rights and accountability	Partially aligned	Medium
Identifiers and advisories	CVE, CVSS, CWE, OSV, CSAF, VEX (§§7, 10–11)	Stable, detailed, reusable, openly distributed advisories; downstream package specificity	Partially aligned	Medium
Regulatory notifications	No explicit CRA/mandatory-notification exception in primary CVD policy	Separate statutory confidential notification from CVD embargo (Appendices A/B)	Not demonstrated	High
Post-disclosure learning	Advisory publication and credit; lifecycle stops at disclosure (§§7, 11)	Monitor fixes, corrections, accessibility and actual user protection	Partially aligned	Medium

4. Findings in detail

A1. Reporting must not become a membership privilege

Evidence: Akrites §4 presents low-friction intake, but §12 says the rollout starts with member reports, followed by clearinghouse reports, and only later unsolicited or anonymous reports. Reports from a category not yet opened may be deferred or manually handled. For member/working-group reports, the policy adds: “Technical contribution is the price of admission.”

A staged operational launch can be entirely legitimate, particularly for a new SIRT with limited capacity. The concern is what the published terms mean for a good-faith researcher, an unrepresented user, or a small project seeking help. Receiving a report should not require an ability to provide engineering work or a commercial relationship. Allocating scarce technical assistance and access to a confidential remediation workspace is a different question.

BCP-02’s Preparing for Vulnerability Handling, Receiving and Handling Vulnerability Reports, and Best Practices favour usable, welcoming reporting channels; Appendix B adds fairness toward smaller independent projects.

Recommendation: Explicitly separate universal receipt and initial triage of reports within Akrites’ stated remit from membership benefits, full case-management capacity, and case-specific read-in. Publish the active rollout status and a fallback referral to a suitable upstream security contact, CERT/CSIRT, or CNA when Akrites cannot take a case. Do not require evidence of contribution merely to acknowledge and route a vulnerability report.

A2. Read-in participation: useful safeguards, but inclusion requires attention

Akrites’ later Read-In Policy draft v0.3 is more specific than the main CVD policy. It states that Akrites membership alone does not satisfy need-to-know, and its Three-Gate Test includes a case-specific task, capacity to contribute, and a vetted identity/organisational sponsor. This is a meaningful safeguard against blanket early access for fee-paying members.

However, the same draft does not count merely receiving or acting on information for incident-response readiness or for one’s own products as sufficient contribution under Gate 2. Gate 3 ordinarily requires a member organisation, the relevant upstream security team, or nomination by a delegated authority. These criteria may exclude some independent packagers, volunteer repository operators, or downstream product maintainers who need time to test or deploy an update but cannot secure a qualifying sponsor.

Appendix B of BCP-02 endorses purpose-limited, actionable pre-disclosure sharing, explicitly warns against participation depending solely on company size, payment, or market position, and calls for workable channels for independent repositories and volunteer maintainers. BCP-02 does not create an entitlement for every consumer to see an embargoed report.

Recommendation: Offer a documented path for unaffiliated downstream maintainers to demonstrate a verifiable protective action (e.g. applying a backport, preparing repository publication, or deploying a mitigation), even without a member sponsor. Permit carefully restricted targeted pre-notification when full workspace access is unnecessary. Record rejected access requests and review criteria for unintended exclusion. Preserve the beneficial case-specific least-privilege approach.

A3. Upstream authority is important, but the original reporter’s clock also matters

Evidence: Akrites §8 starts from a 30-day disclosure target following validation, while Embargo Handling Guidance §2 describes a default 30 calendar days from validation and ownership assignment. The guidance orders precedence in favour of upstream policies and coordination-list caps. Its §4.1 also says that by reporting, a Finder accepts that upstream timelines may govern, even when not matching their desired schedule. Akrites §15 separately says a Finder retains the ability to disclose on their own timeline, subject to safe-harbour terms.

Respecting upstream maintainers’ release authority is sensible, and a short embargo can protect users. But the initial reporter’s disclosure deadline, permissions, and obligations cannot be silently reassigned to an upstream project or coordinator. There is also a practical clock issue: a validation-based default can start materially later than the original report date.

BCP-02 Appendix B, Respecting the original reporter and the disclosure timeline, says that adding downstream participants should not silently reset the reporter’s clock. It recommends agreeing information-sharing scope and negotiating extensions rather than simply asserting control.

Recommendation: Record report received, validated, upstream contacted, proposed public date, reporter’s original deadline, and agreed public date as distinct timestamps. When rules collide, identify the conflict, consult affected parties, negotiate a defensible outcome, and document any unresolvable disagreement. Explicitly state that reporting to Akrites does not automatically waive a pre-existing disclosure commitment or convert a proposed target into an irrevocable secrecy obligation.

A4. The TLP model needs clearer originator and cross-organisation handling

Akrites §8 applies TLP:RED during intake, TLP:AMBER+STRICT during remediation, and TLP:CLEAR at public disclosure. It says that redistributing material beyond its classification requires the Owner’s explicit consent.

Classification may help convey expectations, but TLP alone is not a case-specific access-control system or a substitute for authorization to share another party’s material. A reporter may be the originator of specific evidence or personal information even when an upstream maintainer is the software Owner. Moreover, TLP:AMBER+STRICT does not itself authorize arbitrary redistribution among multiple separate companies; such recipients must be explicitly permitted under case-specific arrangements.

BCP-02 Appendix B recommends clear recipient lists, allowed purposes, onward-sharing rules, and reporter-aware sharing.

Recommendation: Define who originates each sensitive artefact, who may authorize its release or redistribution, whether targeted disclosures to named external organisations are permitted, how information is reclassified, and how required legal disclosures are handled. Restrict sharing using both TLP labels and concrete case permissions. Reconcile the main policy’s “no NDA” commitment with the separate read-in policy’s required acknowledgements or confidentiality agreements: written participation rules need not be an NDA, but this should be explicit.

A5. Automatic loss of embargo for public AI use is overly categorical

Evidence: Akrites §8 and Embargo Handling Guidance §4.3 state that a report developed using a public hosted LLM has no embargo available and should be handled on an accelerated or assume-exposed track. Akrites also requests disclosure of AI use at intake and human review of AI-assisted outputs (§§4, 13).

The threat is real: supplying unpatched vulnerability details to an unapproved third-party service may break a confidentiality agreement. But use of a hosted model is not proof that an exploitable finding became public, nor does it always establish the same risk. Relevant factors include precisely what was submitted, whether the service retained or exposed it, provider terms, deployment controls, disclosure to third parties, and whether the submitted content was already public. Conversely, an ordinary cloud issue tracker or CI system may create similar risks.

GCVE BCP-02 Appendix B, Confidentiality when using external services and AI-assisted tools, explicitly adopts a technology-neutral, risk-based approach. It rejects automatically treating all AI services as unsuitable while stressing that disabling training alone is insufficient. Its main text calls for qualified human review of AI-assisted advisory claims.

Recommendation: Replace an automatic “no embargo” rule with an exposure-assessment workflow: identify the precise material disclosed, service and contractual controls, credible exposure, and any affected parties; then decide whether to preserve, shorten, or terminate the embargo. Preserve a strict prohibition on sending sensitive case materials to unapproved external services and keep the human-review requirement.

A6. A coordinated release is a network, not only an upstream-to-user pipeline

Akrites §6 recognizes upstream/downstream coordination, and §7 prepares shared public disclosure. That is a strong starting point. The main workflow diagram, however, remains predominantly Finder → Akrites → Upstream Owner → Consumer; “downstream providers” are present but largely treated as pre-notified collaborators.

BCP-02 Appendix B considers the full ecosystem: Linux distributions and long-term support branches, independent RPM/DEB repositories, conda-forge, container images, forks, statically linked and vendored code, cloud integrations, and downstream-origin vulnerability reports. Each affected downstream supplier must check its own shipped or backported code and provide accurate fixed-version and mitigation information. Upstream patch release alone is not proof that users received a protective update.

Recommendation: Model case participants as a bidirectional graph, with an explicit downstream-origin path and nominated acting coordinator when upstream is unavailable. Maintain product/package-specific impact and fix status, not just a common CVE. Include a tested multi-channel release plan with build pipelines, mirrors, caches, packages, and potential premature artefacts.

A7. Active exploitation may require action sooner than seven days

Akrites §9 correctly overrides normal embargo assumptions when exploitation is confirmed and permits publication without unanimous agreement. Its stated target is actionable guidance within seven days. Seven days may be a reasonable outer operational target in some cases, but rapidly exploited vulnerabilities can justify warnings or mitigations immediately.

Recommendation: Characterize seven days as a maximum planning target, not a waiting period or universal service level; allow same-day or immediate release of available protective guidance whenever risk warrants. Distinguish a confirmed leak, publicly available exploit, actual exploitation evidence, and an accidental early package release. Avoid equating all four situations.

A8. Safe harbour should say whose systems Akrites can actually authorize

Akrites §14 promises not to pursue legal action for good-faith research and says it will consider compliant research “authorized.” This is welcome, but where Akrites is only a coordinator for a third-party upstream project, it generally cannot unilaterally authorize security testing against systems it does not own or control or bind third-party entities not party to its policy.

Recommendation: Clarify the safe harbour’s jurisdiction and scope: Akrites’ own systems and claims, applicable authorization from participating maintainers, and commitments Akrites can actually make. Provide a non-retaliation and good-faith communication commitment for third-party reports without suggesting an immunity Akrites cannot grant.

A9. Dispute escalation should visibly manage institutional conflicts

Akrites §15 provides a case coordinator, a second SIRT coordinator, and a Technical Oversight Committee (TOC), with policy/legal matters ultimately referred to a Governing Board. Having an appeals path is positive. But a membership-funded coordination system must also demonstrate what happens when a large commercial participant, a maintainer, and a reporter want conflicting disclosure dates.

Recommendation: Document recusal, conflicts of interest, a genuinely independent external escalation option (such as an agreed CERT/CSIRT), appeals access for non-members, and the limits of TOC authority. The TOC may govern Akrites participation and operations; it should not claim to bind a researcher, unaffiliated upstream project, or regulator without an appropriate basis.

A10. CRA and other mandatory reporting must be outside embargo vetoes

The Akrites CVD Policy does not explicitly address the EU CRA’s confidential reporting obligations or state that an applicable statutory report is not a breach of a CVD embargo. GCVE BCP-02 Appendix A covers the parallel reporting track, and Appendix B adds multi-party handling.

As of the review date, applicable CRA Article 14 manufacturer reporting requirements have applied since 11 September 2026. Participants have to assess whether a vulnerability is actively exploited in their own product with digital elements or whether a qualifying severe incident exists, and track their applicable deadlines separately. The fact that Akrites is coordinating a shared vulnerability does not automatically make every participant a CRA manufacturer, nor does it transfer reporting obligations to Akrites. When Article 14 is triggered, early warning and notification deadlines can run independently of any embargo.

Recommendation: Add an explicit carve-out for legally mandated confidential notifications (including CRA SRP submissions when applicable), evidence-sharing alerts that support participants’ own regulatory assessments, and a statement that an SRP submission is not equivalent to public vulnerability disclosure.

A11. Advisory availability, licences, and post-disclosure outcomes deserve more emphasis

Akrites §10 supports OSV, CSAF and VEX, and §11 calls for public advisories and attribution. These are strengths. BCP-02 additionally recommends publicly reusable machine-readable advisory data under an open redistribution licence, stable references, updates when the affected scope changes, and evidence of whether users can actually obtain and deploy fixes. The new CNA role increases the importance of a persistent CVE Record publication channel.

Recommendation: Publish a stable advisory index, predictable machine-readable feeds, licence and retention policy, corrected records, affected-package/version/backport mappings, and post-release monitoring criteria. A CVE ID is a correlation key, not a substitute for each distribution or product’s real update status.

A12. Documentation links and authoritative-state hygiene

The reviewed Akrites CVD file resides under docs/ but references docs/ai-use-disclosure.md, docs/Embargo%20Handling%20Guidance.md, and docs/Read-in%20Tier%20Policy.md as relative paths. From that location these would normally resolve to docs/docs/...; the latter named read-in file is also not the current document name in the inspected docs/ directory. A later Read-In Policy draft explicitly says it will supersede the earlier tier policy upon ratification. The public CVD draft still refers to the old title.

Recommendation: Fix relative links, identify which read-in and embargo documents are currently in force versus proposed, publish a changelog and stable policy URL, and update the CVD/CNA policy following the 27 October announcement. This is a documentation consistency finding, not evidence that a policy is unavailable to Akrites operators.

5. What Akrites already does well

The following features are worth retaining and are compatible with the spirit of BCP-02:

A public, reviewable CVD process and named security contact.
Concrete acknowledgement and triage targets, with a commitment to communicate delays.
Respect for maintainer release authority and efforts to avoid duplicate downstream reports.
A deliberate need-to-know model rather than indiscriminate embargo distribution.
Explicit preparation of patches, tests, documentation and coordinated release material.
Safe-harbour language, credit and anonymity choices, and an appeals process.
An accelerated path for active exploitation and user-protective mitigations before a patch is ready.
Structured data formats and human accountability for AI-assisted output.
A later read-in draft that explicitly rejects membership alone as sufficient justification for case access.

There is no inherent conflict between a trusted confidential coordination group and an open CVD ecosystem. The tension arises if confidentiality becomes a mechanism for excluding stakeholders who need to protect users, shifting reporter deadlines without consent, or offering preferential access unrelated to an actionable security task.

6. Priority recommendations and proposed policy language

P0 / immediate: CNA scope and reporting separation

CVE assignment and coordination. Akrites SIRT may coordinate vulnerability cases beyond the scope of its CVE Numbering Authority designation. It assigns CVE identifiers only where permitted by its current CVE Program-approved scope, respects Supplier CNAs and applicable first-refusal/overlap rules, and routes out-of-scope cases to the appropriate CNA. The handling of a report by Akrites does not, by itself, establish authority to assign a CVE identifier.

P0 / immediate: fair intake and protective downstream access

Open reporting and proportionate access. Good-faith vulnerability reports may be received and appropriately routed irrespective of membership, sponsorship, payment, or the reporter’s ability to contribute a patch. Confidential case access is separately determined by case-specific necessity, verifiable ability to prepare protective action, and proportionate security controls. Independent maintainers and downstream repositories have an accessible route to request targeted pre-notification even without organisational membership.

P0 / immediate: reporter rights and disclosure clock

Reporter participation. Akrites records the original reporter’s planned disclosure date and agreed conditions for sharing, credit and confidentiality. Joining additional coordinators, member organisations, or downstream vendors does not reset that date. Extensions should be explicitly negotiated; disputes and necessary emergency protective disclosures are documented without assuming unilateral authority over third parties.

P1: replace the categorical AI rule

Use of external services. Submitting embargoed information to an external service, including an AI system, must be assessed against the case’s confidentiality requirements, service controls, contracts and actual exposure risk. Unauthorized transfers trigger review and, where warranted, accelerated disclosure; use of a particular technology category alone does not prove that information became public or that a confidential coordination period is impossible.

P1: mandatory notification exception

Regulatory and public-safety exceptions. Confidential notifications required by applicable law, including obligations under the EU Cyber Resilience Act where triggered, are not violations of a CVD embargo. Each party remains responsible for evaluating and meeting its own legal obligations. Regulatory notification does not in itself constitute public disclosure. Urgent guidance necessary to protect users may be issued through a documented risk-based escalation process.

P1: multi-party delivery and independence

Downstream coordination and conflicts. Akrites will seek to include actionable downstream stakeholders, including smaller distributions, independent repositories, forks and maintainers of vendored copies, using need-to-know criteria rather than commercial status. The coordinator documents conflicts of interest, recusal decisions, independent escalation routes, and readiness of product-specific fixes, backports, packages and advisories.

7. Questions to raise with Akrites

Is public/non-member reporting already accepted in practice? If not, where are out-of-scope or unsolicited reports referred, and when will public intake open?
Does the new CNA scope cover only directly affiliated Linux Foundation projects lacking their own Supplier CNA, as stated by the CVE Program? Where will this be documented in Akrites’ assignment policy?
How do independent downstream maintainers (including volunteer RPM/DEB repositories and conda-forge) obtain a targeted pre-notification if they do not have an Akrites member sponsor?
Does the Three-Gate Test allow preparing an emergency mitigation or patch deployment as sufficient protective contribution where the participant cannot work on the upstream source fix?
Is a Finder’s consent required before sensitive evidence is shared with members or read-in groups? What happens when the Finder’s disclosure date and a member’s release calendar conflict?
What factual criteria distinguish an AI-assisted report that may have exposed details from one demonstrably available to third parties?
Who can authorize TLP reclassification and cross-company sharing: the reporter, the upstream maintainer, Akrites, or an explicit agreement among them?
Can non-members request an independent review when the TOC or a commercial member has a conflict of interest?
Does the CVD policy explicitly allow relevant CRA SRP notifications and urgent defensive warnings without treating them as an embargo breach?
Where are Akrites’ machine-readable CVE records, advisories, correction policy and open data licence documented?
Which read-in and embargo documents are currently ratified, and where is the authoritative policy index?

8. Bottom line

Akrites and GCVE BCP-02 seek much the same outcome: fewer duplicated reports, faster remediation, credible coordination, and actionable public disclosure. Akrites’ contribution is an ambitious operational coordination service, particularly for critical open-source dependencies. GCVE BCP-02 provides a broader public-interest baseline spanning reporters, volunteer maintainers, large vendors, smaller distributors, independent coordinators, and the users who must deploy fixes.

The key issue is therefore not centralized versus decentralized coordination, nor embargo versus immediate disclosure. It is whether Akrites’ confidentiality and membership model remains a proportionate tool for protecting users and respecting reporters, rather than an unintended barrier to participation. The new CNA role makes explicit limits on identifier authority and public accountability particularly important.

Conclusion: Broadly aligned in purpose; partially aligned in implementation; important revisions advisable before treating the Akrites drafts as an exemplary CVD policy fully reflecting GCVE BCP-02 v2.0.

Reference links

The review reflects documents accessible on 29 October 2026 and can be revised if Akrites publishes ratified policies or clarifies operational practices.