Re: [OPSAWG] I-D Action: draft-ietf-opsawg-sbom-access-10.txt

Eliot Lear <lear@lear.ch> Wed, 28 September 2022 12:58 UTC

Return-Path: <lear@lear.ch>
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 64FD0C15E41C for <opsawg@ietfa.amsl.com>; Wed, 28 Sep 2022 05:58:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, T_SPF_HELO_PERMERROR=0.01, 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 (1024-bit key) header.d=lear.ch
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 50_ZqnNQmnJd for <opsawg@ietfa.amsl.com>; Wed, 28 Sep 2022 05:58:22 -0700 (PDT)
Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43680C15E6C1 for <opsawg@ietf.org>; Wed, 28 Sep 2022 05:58:21 -0700 (PDT)
Received: from [IPV6:2001:420:c0f8:1004::ad] ([IPv6:2001:420:c0f8:1004:0:0:0:ad]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 28SCwG7c610896 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Wed, 28 Sep 2022 14:58:17 +0200
Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1664369898; bh=He4gzZM+LCFC7msva6uceikn6xY1f5oT9hNX16bGHqg=; h=Date:Subject:To:References:From:In-Reply-To:From; b=pkXXfofCoi2mytxXFT7nG5z0lfENAgG5cISEDDAg9IgxrekogFNudpvJ9X5hszO2j 2l3GJkf/1sbfbQCL3eIGJNEjUiJ1YcBReV4ooRMKUVHlbRUq8fbb0mEypUYJzJDd2n R/MFAcGkM3y7wra9HSUYKyE1WzGWHopvcI+5xlko=
Message-ID: <8251733f-73b7-b7c5-611b-500166c1fc39@lear.ch>
Date: Wed, 28 Sep 2022 14:58:13 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.13.1
Content-Language: en-US
To: dick@reliableenergyanalytics.com, opsawg@ietf.org
References: <166434857803.6098.2751952271384039583@ietfa.amsl.com> <458e01d8d330$6a04cca0$3e0e65e0$@reliableenergyanalytics.com> <3b4b58ff-9db6-89df-c76d-4bc086dac715@lear.ch> <464501d8d333$d184be00$748e3a00$@reliableenergyanalytics.com>
From: Eliot Lear <lear@lear.ch>
In-Reply-To: <464501d8d333$d184be00$748e3a00$@reliableenergyanalytics.com>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="------------YZlt1JMQa0z892GX9Lg8l3Oz"
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/5Bf1K4zSnWKOJI08HYW41Iwb47w>
Subject: Re: [OPSAWG] I-D Action: draft-ietf-opsawg-sbom-access-10.txt
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: Wed, 28 Sep 2022 12:58:27 -0000

On 28.09.22 14:14, Dick Brooks wrote:
> See response inline DB>
>
> 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: Wednesday, September 28, 2022 8:03 AM
> To:dick@reliableenergyanalytics.com;opsawg@ietf.org;i-d-announce@ietf.org
> Subject: Re: [OPSAWG] I-D Action: draft-ietf-opsawg-sbom-access-10.txt
>
> Hi Dick,
>
> On 28.09.22 13:49, Dick Brooks wrote:
>> I find this material misleading and incomplete.
>>
>> The title infers the ability to discover and retrieve vulnerability
>> information. However the text of this draft makes clear that retrieval
>> is not supported, ref Page 2:
>>
>>     "This memo does not specify how vulnerability information may be
>>      retrieved directly from the endpoint.  That's because vulnerability
>>      information changes occur at different rates to software updates.
>>      However, some SBOM formats may also contain vulnerability
>>      information."
> The information can be retrieved, but not from the endpoint. That's not misleading.
>
> DB> I agree vulnerability information can be retrieved and some SBOM formats, i.e. SPDX Version 2.3 provide retrieval information for vulnerabilities associated with SBOM's:
> 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  
>
> The draft could be more accurate and complete by indicating that access to vulnerability information at the SBOM component level may be indicated in an SBOM.

It says precisely that:

>     System vulnerabilities may similarly be described using several data
>     formats, including the aforementioned CycloneDX, Common Vulnerability
>     Reporting Framework [CVRF], the Common Security Advisory Format
>     [CSAF].  This information is typically used to report to
>     administrators the state of a system.

If SPDX 3.0 were out, I'd add that too.


>
>> The draft makes no mention of the NIST Vulnerability Disclosure Report (VDR)
>> that is used to inform consumers of the vulnerability status of a software
>> product at the SBOM component level, ref: NIST SP 800-161 RA-5.
>> https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-161r1.pdf
> A specification would be incomplete if the reference is necessary for
> implementation.  How is this reference necessary for implementation?
>
> DB> The NIST VDR is no different from other items you reference i.e. CDX VEX and CSAF. Also, parties in the US subject to Executive Order 14028 and OMB memo M 22-18 may need to implement NIST recommendations for SBOM and vulnerability reporting. If this draft guidance is not intended for use by the US Government with regard to these mandates, then you may have a point.

Those formats are mentioned because they are directly relevant to 
implementation.

Eliot