Re: [open-regulatory-compliance] OSS wish list disclosure information -

[Lars Francke <lars.francke@xxxxxxxxx>]

> Reports from the trenches are that VEX is not viable for either manufacturers of devices or software consumers.

We are using CSAF as a manufacturer and as a consumer and I disagree with that.

> 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. 

I wouldn't expect to look at these manually - I expect them to be automatically processed.

I do agree that tooling is not great yet but that's hopefully temporary.

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

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

 

 

From: Roman Zhukov <rzhukov@xxxxxxxxxx>
Sent: Friday, February 7, 2025 10:08 AM
To: dick@xxxxxxxxxxxxxxxxxxxxxxxxx; 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

 

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

@redhat   @red-hat  @redhatinc

 

 

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

_______________________________________________
open-regulatory-compliance mailing list
open-regulatory-compliance@xxxxxxxxxxx
To unsubscribe from this list, visit https://accounts.eclipse.org