Re: [OPSAWG] draft-ietf-opsawg-sbom-access

Dick Brooks <dick@reliableenergyanalytics.com> Fri, 28 April 2023 13:39 UTC

Return-Path: <dick@reliableenergyanalytics.com>
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93A0BC13AE42 for <opsawg@ietfa.amsl.com>; Fri, 28 Apr 2023 06:39:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.094
X-Spam-Level:
X-Spam-Status: No, score=-2.094 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=reliableenergyanalytics.com header.b="JSjQ7ydc"; dkim=pass (2048-bit key) header.d=messagingengine.com header.b="Omvrivcc"
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SYr7cSu3Ck51 for <opsawg@ietfa.amsl.com>; Fri, 28 Apr 2023 06:38:58 -0700 (PDT)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5D4BC13AE3C for <opsawg@ietf.org>; Fri, 28 Apr 2023 06:38:52 -0700 (PDT)
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 13AA75C019F; Fri, 28 Apr 2023 09:38:52 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Fri, 28 Apr 2023 09:38:52 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= reliableenergyanalytics.com; h=cc:content-transfer-encoding :content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to :reply-to:sender:subject:subject:to:to; s=fm1; t=1682689132; x= 1682775532; bh=IyPNt+hIq6cE/JWp2jIfJzRnJaigCynQ2GenFmEPxfg=; b=J SjQ7ydcVhj0JSZzn/Cp37dd6AM09esnqM2OHpSlkAt0LcuLCK6DOmABrxQoX5m3c oW9ONTDu94zIDOlLkiLSp/KFML6bUnXZAbm9pLwGYLRDHVZkD/mJ9q7tdPPXXeta +ItgL+vSXw5zmN4CQ1lllftGxOElXmhHt1DQuABDbEp3bgUZ6RXY/xa7PcPgo8RK jbMKWvqgn9Ivepf1fGiV87UXu/nVqV751I8ufTtVGUpdpDue4CNP7k337v5jFhqL FPJJy6zJkLI/wgJrUZuq2teoG4TS9OsJN/zGuC6GPmWGalD/GJHmeQ16JFMLKIJy quvaMDTw/kAdn9r24O2Uw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:reply-to:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t= 1682689132; x=1682775532; bh=IyPNt+hIq6cE/JWp2jIfJzRnJaigCynQ2Ge nFmEPxfg=; b=OmvrivccgqkuPayrT8tBSignVK44boaGTgWFnyyAHUD1dgG5Odi Y4C1NLACzCTNpuCfpt3VCUh7U5v40Npbzxorimg5Qbl4H/FVFvOWFaG3bLjqep/E WZ/d4r6+TNFSAZzOvanKIfRZxVhH6Td1Raa0/klo6W6omtPQjCekRLIX1MsxDXCC d4N8E1tUa3GDuj/SBQC2PKlqRCzpn4L0wcVM7xtmA+vZDRzFJLhPPPod/ZWG2mZr t7vuQa/s4Zal9mjzoY7zEDR2tF3TB2URJkAqzf5loqEqFn3W53raDwl7qwpIbSsC dmcBaFyKU3FJr+sbo5BPUWIevtk9peNOg2A==
X-ME-Sender: <xms:a8xLZNyHrnfM9pzz-0ufrFZ4GWOudGaQ9gqks-evb4478Tzma2NofQ> <xme:a8xLZNScJRJJ4jNEOv4JvLlHRZ-cF8WlAmKJZgliGIr9tUv7cmH1moKcXSvZHqzL6 1yNPIJ7yE0KLp_TRA>
X-ME-Received: <xmr:a8xLZHWWuufoQWTJ30CTCeoDCDU8-ceXrTe53N3uMT9_05Gz5JkQ-5g>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrfedukedgieejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne goufhushhpvggtthffohhmrghinhculdegledmnecujfgurheprhfhvfhfjgfuffhokfgg tgfgofhtsehtqhhgtddvtdejnecuhfhrohhmpedfffhitghkuceurhhoohhkshdfuceoug hitghksehrvghlihgrsghlvggvnhgvrhhghigrnhgrlhihthhitghsrdgtohhmqeenucgg tffrrghtthgvrhhnpeeludefffeugfffffduieelgedvheefvdfhtdffjeefleefkedvhf ehjeffleevueenucffohhmrghinhepvghnvghrghihtggvnhhtrhgrlhdrtghomhdprhgv lhhirggslhgvvghnvghrghihrghnrghlhihtihgtshdrtghomhdpghhithhhuhgsrdhioh dprggssgdrtghomhenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhl fhhrohhmpeguihgtkhesrhgvlhhirggslhgvvghnvghrghihrghnrghlhihtihgtshdrtg homh
X-ME-Proxy: <xmx:a8xLZPiZXrw-kclC8pMVI8Konid0jIMQYok2fFjoAIn4t4aU7kQe4A> <xmx:a8xLZPAigG-QAwPN-V5AeXUR0cHlsRHYkRIJE3Q3PNjB29XBIvd4Mg> <xmx:a8xLZIIcGW-5Wa2zuDzVRUd5PL_0TEVCUBhrG2hG3wAIdWEEzeXExg> <xmx:bMxLZCottlTWsj710iZ7biLlG4tYDJiOos2el1Ovy8LCAYcTPJcQuw>
Feedback-ID: i57d944d0:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 28 Apr 2023 09:38:51 -0400 (EDT)
Reply-To: dick@reliableenergyanalytics.com
From: Dick Brooks <dick@reliableenergyanalytics.com>
To: 'Eliot Lear' <lear@lear.ch>, opsawg@ietf.org
References: <7aa5c179-1fab-77ff-123e-35562d84fa64@lear.ch> <3ed901d979d3$335e03c0$9a1a0b40$@reliableenergyanalytics.com> <bde4d63c-d71e-5c29-b01b-cde4297bd395@lear.ch>
In-Reply-To: <bde4d63c-d71e-5c29-b01b-cde4297bd395@lear.ch>
Date: Fri, 28 Apr 2023 09:38:49 -0400
Organization: Reliable Energy Analytics LLC
Message-ID: <3fe601d979d6$c5377ad0$4fa67070$@reliableenergyanalytics.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQFUy+c8kQay/ddhBdLNrZqoEa9XFQGI9yWjAp93S+iwKNC38A==
Content-Language: en-us
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/xTdmJWH0UCJUxmstoZZkQBz4Eug>
Subject: Re: [OPSAWG] draft-ietf-opsawg-sbom-access
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: OPSA Working Group Mail List <opsawg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsawg>, <mailto:opsawg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/opsawg/>
List-Post: <mailto:opsawg@ietf.org>
List-Help: <mailto:opsawg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsawg>, <mailto:opsawg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 28 Apr 2023 13:39:02 -0000

Hi Eliot,

I agree, both approaches are in order to support current practice in this area linking SBOM's and vulnerabilities. 

I wrote an article describing NIST's VDR:
https://energycentral.com/c/pip/what-nist-sbom-vulnerability-disclosure-report-vdr

Here is an excerpt from the summary:

In summary, a NIST Vulnerability Disclosure Report (VDR) is an attestation by a software vendor showing that the vendor has checked each component of a software product SBOM for vulnerabilities and reports on the details of any vulnerabilities reported by a NIST NVD search. The VDR is a living document which the software vendor updates as needed when new vulnerabilities have been discovered and reported. A VDR is published whenever a software vendor issues a new or updated SBOM, including initial product release, making it available online, all the time, to all customers of the product described in the VDR. This gives software consumers that ability to answer the question “What is the vulnerability status of my software product from Vendor V, as of 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! ™
http://www.reliableenergyanalytics.com
Email: dick@reliableenergyanalytics.com
Tel: +1 978-696-1788

-----Original Message-----
From: Eliot Lear <lear@lear.ch> 
Sent: Friday, April 28, 2023 9:32 AM
To: dick@reliableenergyanalytics.com; opsawg@ietf.org
Subject: Re: [OPSAWG] draft-ietf-opsawg-sbom-access

Hi Dick,

Thanks for your comments.  Please see below.

On 28.04.23 15:13, Dick Brooks wrote:
> SPDX V 2.3 provides guidance with regard to vulnerability reporting for SBOM's.
>
> A NIST Vulnerability Disclosure Report (VDR) is a single file that serves as an attestation showing the vulnerability status of each component listed in an SBOM.

Sure.  And that was the sort of model I had in mind, but I don't think it's the only one.


>
> SPDX also supports the listing of individual vulnerabilities which may affect a product, which is a set of entries pointing to Security Advisories:
> https://spdx.github.io/spdx-spec/v2.3/how-to-use/#k12-linking-to-a-csaf
> Here is a real world example:
> https://search.abb.com/library/Download.aspx?DocumentID=8DBD000150-CSAF&LanguageCode=en&DocumentPartId=&Action=Launch

Ok, that does indeed argue for a leaf-list.

Eliot