Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [open-regulatory-compliance] OSS wish list disclosure information - possible consideration for EU-CRA technical standards work
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



On Fri, Feb 7, 2025 at 2:48 PM Dick Brooks via open-regulatory-compliance <open-regulatory-compliance@xxxxxxxxxxx> wrote:

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

Back to the top