Roman, You are describing CSAF profile 4 (Security Advisories); I agree, it is effective and necessary today This discussion is about CSAF profile 5 (VEX). Vulnerability Disclosure Reports (VDR) are product centric, where these other are vulnerability centric. A VDR provides a “product level vulnerability status” for all its SBOM components. A VDR is a living document, as seen with the Palo Alto example, that users can query any time to get the “product level vulnerability status”. Thanks, Dick Brooks   
Active Member of the CISA Critical Manufacturing Sector, Sector Coordinating Council – A Public-Private Partnership Never trust software, always verify and report! ™ Risk always exists, but trust must be earned and awarded.™ https://businesscyberguardian.com/ Email: dick@xxxxxxxxxxxxxxxxxxxxxxxxx Tel: +1 978-696-1788 From: Roman Zhukov <rzhukov@xxxxxxxxxx>
Sent: Friday, February 7, 2025 10:44 AM
To: dick@xxxxxxxxxxxxxxxxxxxxxxxxx
Cc: Open Regulatory Compliance Working Group <open-regulatory-compliance@xxxxxxxxxxx>
Subject: Re: [open-regulatory-compliance] OSS wish list disclosure information - possible consideration for EU-CRA technical standards work Sorry if I didn't get a point, Dick. Advisory in standardised format (CSAF) is exactly communicating the impact of vulnerability which could be from zero (not affected could be an option) to the Highest levels. And most importantly, the explanation "why". In your great example with Palo Alto https://security.paloaltonetworks.com/ - that would be NONE selector on the filter. We at Red Hat do it for quite a time and found it useful and flexible for customers (I was a customer some time ago). My point was about leveraging established industry specs, while adhering it to customers' wishes. So I don't see any contradictions with your points. -- Roman Zhukov Principal Security Community Architect Red Hat Reports from the trenches are that VEX is not viable for either manufacturers of devices or software consumers. Here is one comment regarding VEX concerns: Thanks Dick, I would think that sending “not affected” advisories would cause not only manufacturer fatigue, but, consumer fatigue resulting in the increased likelihood that an “affected” advisory would be missed/overlooked or automatically deleted when the filters are set. Security Advisories that indicate products that are affected by a new vulnerability are valuable to consumers, warning of increased risk. Palo Alto networks serves as a great model for vulnerability disclosure reporting for products which answers the question that consumers are asking: “Is my software product affected by any vulnerabilities as of right now” Thanks, Dick Brooks   Active Member of the CISA Critical Manufacturing Sector, Sector Coordinating Council – A Public-Private Partnership Never trust software, always verify and report! ™ Risk always exists, but trust must be earned and awarded.™ https://businesscyberguardian.com/ Email: dick@xxxxxxxxxxxxxxxxxxxxxxxxx Tel: +1 978-696-1788 Dick, thanks for sharing it! We need to make sure that existing established vulnerability reporting/enrichment standards like OpenVEX and CSAF are taken into account, as many vendors have already been using them. There is no contradiction with the wish list above (and compatible with SPDX of course), as current specs are flexible and can be appended by things like IOC, YARA, etc. -- Roman Zhukov Principal Security Community Architect Red Hat Just want to share some insights from colleagues working on the software consumer side with regard to transparency information that would be useful: OSS Vulnerability wish list would include: - Version(s) affected – what version(s) does the vulnerability affect.
- Fingerprinting (i.e., how to find) - what are the recommended ways to detect this vuln in a particular environment/what detection tools or mechanisms are most effective (they may not want to get into "endorsing" a particular detection tool which is totally fine but just general if possible).
- Severity - Give the actual CVSS calculator parameters you used to arrive at the severity chosen so if someone wanted to, they could plug them directly into the interface themselves and customize based on their environment. A completely standalone/air-gapped machine is likely not going to have to worry too much about a vulnerability or exposure that relies on a network-based attack vector (so the threat is much less severe)
- Mitigations - If for some reason a patch or update cannot be applied, are there any recommended mitigations that might be able to be made based on configuration of the software or even other components like network or operating system such as blocking a certain port to limit a particular exposure or changing the permissions of a certain file and locking it down, etc.
- Monitoring - What are the indicators of compromise (IoCs) that might be a sign the vulnerability is being exploited and what are the logging/audit recommendations for detecting them and monitoring for the vuln? E.g., YARA rules
The last item, Monitoring, is also discussed in the Vulnerability Disclosure Report interactions that are taking place. The SPDX V 2.3 SBOM spec currently supports discovery of online living Vulnerability Disclosure Reports (VDR) for a specific product SBOM: https://spdx.github.io/spdx-spec/v2.3/how-to-use/#k19-linking-to-an-sbom-vulnerability-report-for-a-software-product-per-nist-executive-order-14028 Thanks, Dick Brooks Active Member of the CISA Critical Manufacturing Sector, Sector Coordinating Council – A Public-Private Partnership Never trust software, always verify and report! ™ Risk always exists, but trust must be earned and awarded.™ https://businesscyberguardian.com/ Email: dick@xxxxxxxxxxxxxxxxxxxxxxxxx Tel: +1 978-696-1788 _______________________________________________
open-regulatory-compliance mailing list
open-regulatory-compliance@xxxxxxxxxxx
To unsubscribe from this list, visit https://accounts.eclipse.org
|
