@@ -43,9 +43,9 @@ determination of whether it is likely to fit the scope of issues the
43
43
team handles. General guidelines about how this is determined are
44
44
detailed in the L</WHAT ARE SECURITY ISSUES> section.
45
45
46
- If your report meets the team's criteria, an issue will be opened in the
47
- team's private issue tracker and you will be provided the issue's ID number.
48
- Issue identifiers have the form perl-security#NNN . Include this identifier
46
+ If your report meets the team's criteria, you will be provided the issue's
47
+ CVE ID(s). Issue identifiers have the form CVE-YYYY-NNNNN, where YYYY is the
48
+ year the CVE was reported, and NNNNN is a unique number . Include this identifier
49
49
with any subsequent messages you send.
50
50
51
51
The security team will send periodic updates about the status of your
@@ -317,16 +317,20 @@ If the security report cannot be reproduced or does not meet the team's
317
317
criteria for handling as a security issue, you will be notified by email
318
318
and given an opportunity to respond.
319
319
320
- =head3 Issue ID assignment
320
+ =head3 CVE assignment
321
321
322
- Security reports that pass initial triage analysis are turned into issues
323
- in the security team's private issue tracker. When a report progresses to
324
- this point you will be provided the issue ID for future reference. These
325
- identifiers have the format perl-security#NNN or Perl/perl-security#NNN.
322
+ Security reports that pass initial triage analysis are turned into CVEs.
323
+ When a report progresses to this point, one or more CVEs are reserved by
324
+ the security team. Issue identifiers have the form CVE-YYYY-NNNNN, where
325
+ YYYY is the year the CVE was reported, and NNNNN is a unique number. The
326
+ CVE will be used in any subsequent communications about the issue.
326
327
327
- The assignment of an issue ID does not confirm that a security report
328
- represents a vulnerability in Perl. Many reports require further analysis
329
- to reach that determination.
328
+ The assignment of these IDs do not confirm that a security report represents
329
+ a vulnerability in Perl. Many reports require further analysis to reach that
330
+ determination. The vulnerability should not be discussed publicly at this stage.
331
+
332
+ An internal ticket will also be opened. These identifiers have the format
333
+ perl-security#NNN or Perl/perl-security#NNN.
330
334
331
335
Issues in the security team's private tracker are used to collect details
332
336
about the problem and track progress towards a resolution. These notes and
@@ -344,32 +348,31 @@ criteria at this stage, you will be notified by email and given an
344
348
opportunity to respond before the issue is closed.
345
349
346
350
The team may discuss potential fixes with you or provide you with
347
- patches for testing purposes during this time frame. No information
348
- should be shared publicly at this stage.
351
+ patches for testing purposes during this time frame.
349
352
350
- =head3 CVE ID assignment
353
+ =head3 The CVE is drated
351
354
352
355
Once an issue is fully confirmed and a potential fix has been found,
353
- the security team will request a CVE identifier for the issue to use
354
- in public announcements .
356
+ the security team will communicate with the
357
+ L<CPAN Security Group CNA|https://security.metacpan.org/> .
355
358
356
359
Details like the range of vulnerable Perl versions and identities
357
- of the people that discovered the flaw need to be collected to submit
358
- the CVE ID request.
360
+ of the people that discovered the flaw need to be collected.
359
361
360
362
The security team may ask you to clarify the exact name we should use
361
363
when crediting discovery of the issue. The
362
364
L</Vulnerability credit and bounties> section of this document
363
365
explains our preferred format for this credit.
364
366
365
- Once a CVE ID has been assigned, you will be notified by email.
366
- The vulnerability should not be discussed publicly at this stage.
367
-
368
367
=head3 Pre-release notifications
369
368
370
369
When the security team is satisfied that the fix for a security issue
371
- is ready to release publicly, a pre-release notification
372
- announcement is sent to the major redistributors of Perl.
370
+ is ready to release publicly, a pre-release notification announcement
371
+ is sent to the L<Openwall Distros List|https://oss-security.openwall.org/wiki/mailing-lists/distros>.
372
+ Additional other repackagers are notified.
373
+
374
+ NOTE: Any embargoed information sent to the Openwall Distros List
375
+ expires within 2 weeks of disclosure to that location.
373
376
374
377
This pre-release announcement includes a list of Perl versions that
375
378
are affected by the flaw, an analysis of the risks to users, patches
@@ -381,8 +384,8 @@ The pre-release announcement will include a specific target date
381
384
when the issue will be announced publicly. The time frame between
382
385
the pre-release announcement and the release date allows redistributors
383
386
to prepare and test their own updates and announcements. During this
384
- period the vulnerability details and fixes are embargoed and should not
385
- be shared publicly. This embargo period may be extended further if
387
+ period the vulnerability details and fixes are embargoed (see L</Embargo Period> )
388
+ and should not be shared publicly. This L</Embargo Period> may be extended further if
386
389
problems are discovered during testing.
387
390
388
391
You will be sent the portions of pre-release announcements that are
@@ -401,22 +404,22 @@ rather than applying patches to an older release. The security
401
404
team works with Perl's release managers to make this possible.
402
405
403
406
New official releases of Perl are generally produced and tested
404
- on private systems during the pre-release embargo period .
407
+ on private systems during the pre-release L</Embargo Period> .
405
408
406
409
=head3 Release of fixes and announcements
407
410
408
- At the end of the embargo period the security fixes will be
409
- committed to Perl's public git repository and announcements will be
410
- sent to the L<perl5-porters|https://lists.perl.org/list/perl5-porters.html>
411
- and L<oss-security|https://oss-security.openwall.org/wiki/mailing-lists/oss-security>
411
+ The L</Embargo Period> ends when the security fixes are committed to Perl's
412
+ public git repository. Announcements will be sent to the
413
+ L<perl5-porters|https://lists.perl.org/list/perl5-porters.html> and
414
+ L<oss-security|https://oss-security.openwall.org/wiki/mailing-lists/oss-security>
412
415
mailing lists.
413
416
414
417
If official Perl releases are ready, they will be published at this time
415
418
and announced on the L<perl5-porters|https://lists.perl.org/list/perl5-porters.html>
416
419
mailing list.
417
420
418
421
The security team will send a follow-up notification to everyone that
419
- participated in the pre-release embargo period once the release process is
422
+ participated in the pre-release L</Embargo Period> once the release process is
420
423
finished. Vulnerability reporters and Perl redistributors should not publish
421
424
their own announcements or fixes until the Perl security team's release process
422
425
is complete.
@@ -455,12 +458,11 @@ request a CVE ID and send an announcement to inform users.
455
458
456
459
=head2 Vulnerability credit and bounties
457
460
458
- The Perl project appreciates the effort security researchers
459
- invest in making Perl safe and secure.
461
+ The Perl project appreciates the effort security researchers invest in making
462
+ Perl safe and secure.
460
463
461
- Since much of this work is hidden from the public, crediting
462
- researchers publicly is an important part of the vulnerability
463
- remediation process.
464
+ Since much of this work is hidden from the public, crediting researchers
465
+ publicly is an important part of the vulnerability remediation process.
464
466
465
467
=head3 Credits in vulnerability announcements
466
468
@@ -488,4 +490,144 @@ omitted from announcements.
488
490
The Perl project is a non-profit volunteer effort. We do not provide
489
491
any monetary rewards for reporting security issues in Perl.
490
492
493
+ =head2 Embargo Period
494
+
495
+ In the context of Perl's coordinated vulnerability disclosure process, an "embargo"
496
+ refers to the period of time during which information about a reported vulnerability
497
+ is kept confidential. This embargo begins when a security issue is reported to the
498
+ Perl security team and lasts until a fix has been developed and a fix is provided
499
+ in a public location.
500
+
501
+ The purpose of the embargo is to allow the security team to work on a fix
502
+ and prepare a coordinated release without the risk of the vulnerability being
503
+ exploited or disclosed prematurely. This helps ensure that users of Perl
504
+ and its modules are protected from potential attacks while the security
505
+ issue is being addressed.
506
+
507
+ Embargo lengths can vary depending on the complexity of the issue and the
508
+ time required to develop a fix. The security team will communicate
509
+ the expected duration of the embargo to the reporter and any other
510
+ parties involved in the process.
511
+
512
+ As a goal, the security team aims to keep the total embargo period to less
513
+ than 60 days. This may be extended due to the following factors:
514
+
515
+ =over 4
516
+
517
+ =item *
518
+
519
+ The complexity of the issue
520
+
521
+ =item *
522
+
523
+ The time required to develop a fix
524
+
525
+ =item *
526
+
527
+ The need for additional testing or validation
528
+
529
+ =item *
530
+
531
+ The availability of resources to address the issue
532
+
533
+ =item *
534
+
535
+ Public holidays which might affect the ability of end users to apply the fix.
536
+
537
+ =back
538
+
539
+ During this period:
540
+
541
+ =over 4
542
+
543
+ =item *
544
+
545
+ Details of the vulnerability are shared only with a restricted group of trusted contributors
546
+ (such as core maintainers, toolchain maintainers, and packagers), solely for the purpose
547
+ of preparing and testing a fix.
548
+
549
+ =item *
550
+
551
+ Reporters are asked not to disclose the issue publicly or share details with third parties
552
+ until the embargo is lifted.
553
+
554
+ =item *
555
+
556
+ The duration of the embargo may vary depending on the severity and complexity of the issue,
557
+ but typically lasts until the relevant security patch is released and announced.
558
+
559
+ =item *
560
+
561
+ Breaking the embargo — by prematurely disclosing details — undermines the coordinated
562
+ disclosure process and can hinder the coordinated effort to protect users effectively.
563
+
564
+ =back
565
+
566
+ The Perl security team strives to resolve vulnerabilities promptly and encourages all parties
567
+ to respect the embargo period to help protect users and downstream distributions.
568
+
569
+ =head2 Example Release Process
570
+
571
+ This section provides an example of how a security issue reported by a third
572
+ party might be handled by the Perl security team, from the initial report to
573
+ the final release.
574
+
575
+ =head3 Step 1: Reporting the Vulnerability
576
+
577
+ A security researcher discovers a vulnerability in the Perl interpreter that
578
+ allows an attacker to cause a denial of service under specific conditions. The
579
+ researcher emails the details of the issue to
580
+
581
+ proof-of-concept script and a description of the impact.
582
+
583
+ =head3 Step 2: Initial Response
584
+
585
+ Within 72 hours, the security team acknowledges receipt of the report and
586
+ confirms that the issue is under investigation. The researcher is informed of
587
+ the expected timeline for triage.
588
+
589
+ =head3 Step 3: Initial Triage
590
+
591
+ The security team reproduces the issue using the provided proof-of-concept and
592
+ determines that it meets the criteria for handling as a security issue. One or
593
+ more CVEs are reserved in coordination with the
594
+ L<CPAN Security Group CNA|https://security.metacpan.org/2025/02/25/cpansec-is-cna-for-perl-and-cpan.html>.
595
+ The team notifies the researcher referencing the CVE IDs.
596
+
597
+ =head3 Step 4: Development of a Fix
598
+
599
+ The security team analyzes the affected code and develops a patch to address
600
+ the vulnerability. The patch is tested against various scenarios to ensure it
601
+ resolves the issue without introducing regressions. The researcher is invited
602
+ to test the patch privately and provide feedback.
603
+
604
+ =head3 Step 5: Pre-Release Notification
605
+
606
+ The security team prepares a pre-release notification, including details of
607
+ the vulnerability, the affected Perl versions, and the patch. This notification
608
+ is sent to major redistributors of Perl under embargo, giving them time to
609
+ prepare their own updates.
610
+
611
+ =head3 Step 6: Pre-Release Testing
612
+
613
+ During the remaining embargo period, pre-notified redistributors prepare packages
614
+ for release and test the patch to ensure compatibility with their systems.
615
+
616
+ =head3 Step 7: Public Release
617
+
618
+ On the scheduled release date, the patch is committed to Perl's public git
619
+ repository. An official announcement is sent to the
620
+ L<perl5-porters|https://lists.perl.org/list/perl5-porters.html> and
621
+ L<oss-security|https://oss-security.openwall.org/wiki/mailing-lists/oss-security>
622
+ mailing lists. If applicable, a new Perl release containing the fix is
623
+ published.
624
+
625
+ The security team will notify CPAN Security Group CNA to publish the CVE.
626
+
627
+ =head3 Step 8: Vendor and Third-Party Updates
628
+
629
+ Vendors and third-party maintainers incorporate the patch or updated Perl
630
+ release into their distributions. The security team follows up with all
631
+ parties involved to ensure the issue is resolved and users are protected.
632
+
491
633
=cut
0 commit comments