Proposed SECURITY.md file for veraPDF projects#727
Conversation
📝 WalkthroughWalkthroughAdds Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
🧹 Nitpick comments (1)
SECURITY.md (1)
64-64: Consider hyphenating "Denial of service" for consistency.The term is typically hyphenated as "Denial-of-service" when used as a compound modifier. This improves readability and follows standard technical writing conventions.
📝 Optional fix for hyphenation
-- Denial of service attacks +- Denial-of-service attacksAs per coding guidelines (static analysis hint from LanguageTool).
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@SECURITY.md` at line 64, Update the phrase "Denial of service attacks" to the hyphenated form "Denial-of-service attacks" for consistency; locate the exact string "Denial of service attacks" in SECURITY.md and replace it with "Denial-of-service attacks", and scan the document for other occurrences of "Denial of service" to standardize them to the hyphenated form.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Nitpick comments:
In `@SECURITY.md`:
- Line 64: Update the phrase "Denial of service attacks" to the hyphenated form
"Denial-of-service attacks" for consistency; locate the exact string "Denial of
service attacks" in SECURITY.md and replace it with "Denial-of-service attacks",
and scan the document for other occurrences of "Denial of service" to
standardize them to the hyphenated form.
There was a problem hiding this comment.
LGTM - this looks great I see no issues here, thanks for adding. As part of this you'll just need to enable vulnerability reporting in the repository settings as I'm sure you're aware.
|
hi @carlwilson can we get this one merged? |
|
Hi @acornall we're just dealing with the current release. We're quite a distributed group, with multiple commitments. This will be dealt with when we meet in 48 hours. |
MaximPlusov
force-pushed
the
propeosed-security-policy
branch
from
a78db16 to
4a4cb95
Compare
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (2)
SECURITY.md (2)
14-22: Consider adding a PGP key for encrypted email reporting.For highly sensitive vulnerability reports, security researchers may prefer to encrypt their communications. Consider adding a PGP public key or a link to one for the security@openpreservation.org address.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@SECURITY.md` around lines 14 - 22, Update the SECURITY.md entry for security@openpreservation.org to offer an optional PGP public key or a URL to a hosted PGP key for encrypted email reporting; specifically, add a short sentence under the contact bullet that provides a PGP public key fingerprint and either the full ASCII-armored public key block or a link to a hosted key (e.g., on a keyserver or repository) so researchers can encrypt sensitive reports before sending to security@openpreservation.org.
1-92: Consider documenting supported versions.Many security policies include a table or section clarifying which product versions receive security updates (e.g., "Security updates are provided for the current major version and the previous major version"). This helps researchers focus on relevant vulnerabilities and sets clear expectations for users.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@SECURITY.md` around lines 1 - 92, Add a short "Supported Versions" section to SECURITY.md that clearly states which product releases receive security updates (for example: "Security updates are provided for the current major version and the previous major version, and critical fixes for older supported LTS releases"), include per-product or repository guidance if needed, and give dates/criteria for when a version falls out of support; add this section near "Disclosure Timeline" or "Our Commitment" so it’s easy to find and reference when triaging reports.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@SECURITY.md`:
- Line 64: Replace the unhyphenated phrase "Denial of service attacks" in
SECURITY.md with the hyphenated compound adjective "Denial-of-service attacks";
locate the exact header or sentence containing "Denial of service attacks" and
change it to "Denial-of-service attacks", and scan nearby uses of "Denial of
service" to ensure consistent hyphenation when used adjectivally.
- Around line 83-85: The CRA timeline in the SECURITY.md paragraph beginning "As
part of our compliance with the EU Cyber Resilience Act (CRA), OPF reports
actively exploited vulnerabilities..." is incomplete and conflates phases;
update this statement to explicitly state the three distinct reporting steps
required by Article 14: an early warning to ENISA within 24 hours of becoming
aware, a full vulnerability notification with complete details within 72 hours,
and a final report within 14 days after corrective measures are available;
revise the paragraph text to list these three timelines clearly and
unambiguously so it replaces the current single 24-hour/14-day phrasing.
---
Nitpick comments:
In `@SECURITY.md`:
- Around line 14-22: Update the SECURITY.md entry for
security@openpreservation.org to offer an optional PGP public key or a URL to a
hosted PGP key for encrypted email reporting; specifically, add a short sentence
under the contact bullet that provides a PGP public key fingerprint and either
the full ASCII-armored public key block or a link to a hosted key (e.g., on a
keyserver or repository) so researchers can encrypt sensitive reports before
sending to security@openpreservation.org.
- Around line 1-92: Add a short "Supported Versions" section to SECURITY.md that
clearly states which product releases receive security updates (for example:
"Security updates are provided for the current major version and the previous
major version, and critical fixes for older supported LTS releases"), include
per-product or repository guidance if needed, and give dates/criteria for when a
version falls out of support; add this section near "Disclosure Timeline" or
"Our Commitment" so it’s easy to find and reference when triaging reports.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
|
|
||
| The following are outside the scope of this policy: | ||
|
|
||
| - Denial of service attacks |
There was a problem hiding this comment.
Fix hyphenation in compound adjective.
"Denial of service" should be hyphenated when used as a compound adjective before "attacks". As per static analysis hint, this improves grammatical correctness.
📝 Proposed fix
-- Denial of service attacks
+- Denial-of-service attacks📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| - Denial of service attacks | |
| - Denial-of-service attacks |
🧰 Tools
🪛 LanguageTool
[grammar] ~64-~64: Use a hyphen to join words.
Context: ...side the scope of this policy: - Denial of service attacks - Social engineering or ...
(QB_NEW_EN_HYPHEN)
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@SECURITY.md` at line 64, Replace the unhyphenated phrase "Denial of service
attacks" in SECURITY.md with the hyphenated compound adjective
"Denial-of-service attacks"; locate the exact header or sentence containing
"Denial of service attacks" and change it to "Denial-of-service attacks", and
scan nearby uses of "Denial of service" to ensure consistent hyphenation when
used adjectivally.
| As part of our compliance with the EU Cyber Resilience Act (CRA), OPF reports | ||
| actively exploited vulnerabilities to ENISA within 24 hours of becoming aware | ||
| of them, and submits full notifications within 14 days. This regulatory |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
EU Cyber Resilience Act vulnerability notification timeline requirements ENISA
💡 Result:
The EU Cyber Resilience Act (CRA, Regulation (EU) 2024/2847) requires manufacturers of products with digital elements to report actively exploited vulnerabilities and severe incidents via ENISA's Single Reporting Platform (SRP), starting 11 September 2026. For actively exploited vulnerabilities (Article 14(1-2)): - Early warning: within 24 hours of becoming aware. - Vulnerability notification: within 72 hours (unless already provided). - Final report: no later than 14 days after a corrective/mitigating measure is available. For severe incidents impacting product security (Article 14(3-4)): - Early warning: within 24 hours. - Incident notification: within 72 hours. - Final report: within 1 month after the incident notification. Reports are submitted once via the SRP to the relevant national CSIRT (based on manufacturer's main establishment) and simultaneously to ENISA, which distributes as needed. ENISA manages the SRP (Article 16) and will publish FAQs and operate a helpdesk.
Citations:
- 1: https://digital-strategy.ec.europa.eu/en/policies/cra-reporting
- 2: https://www.european-cyber-resilience-act.com/Cyber_Resilience_Act_Article_14.html
- 3: https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX%3A02024R2847-20241120
- 4: https://cyber-resilience-act.com/cra/chapter-2/article-14/
- 5: https://www.enisa.europa.eu/topics/product-security-and-certification/single-reporting-platform-srp
Clarify CRA notification timelines in compliance statement.
The CRA notification requirements are incomplete as stated. Per Article 14, manufacturers must report actively exploited vulnerabilities to ENISA with: early warning within 24 hours, full vulnerability notification within 72 hours (not mentioned), and final report within 14 days of corrective measures becoming available. The current phrasing conflates these distinct phases and omits the 72-hour window for complete vulnerability details, creating compliance ambiguity.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@SECURITY.md` around lines 83 - 85, The CRA timeline in the SECURITY.md
paragraph beginning "As part of our compliance with the EU Cyber Resilience Act
(CRA), OPF reports actively exploited vulnerabilities..." is incomplete and
conflates phases; update this statement to explicitly state the three distinct
reporting steps required by Article 14: an early warning to ENISA within 24
hours of becoming aware, a full vulnerability notification with complete details
within 72 hours, and a final report within 14 days after corrective measures are
available; revise the paragraph text to list these three timelines clearly and
unambiguously so it replaces the current single 24-hour/14-day phrasing.
3 participants
Adding a Security policy file, inspired by #725 thanks to @acornall. The proposed policy has been altered to take the EU's Cyber Resilience Act into consideration.
Summary by CodeRabbit