From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Thu, 07 Sep 2023 18:25:57 +0200 Received: from metis.whiteo.stw.pengutronix.de ([2a0a:edc0:2:b01:1d::104]) by lore.white.stw.pengutronix.de with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1qeHpO-007Go9-4s for lore@lore.pengutronix.de; Thu, 07 Sep 2023 18:25:57 +0200 Received: from localhost ([127.0.0.1] helo=metis.whiteo.stw.pengutronix.de) by metis.whiteo.stw.pengutronix.de with esmtp (Exim 4.92) (envelope-from ) id 1qeHpL-0002jo-TT; Thu, 07 Sep 2023 18:25:55 +0200 Received: from mail.thorsis.com ([92.198.35.195]) by metis.whiteo.stw.pengutronix.de with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1qeHp3-0002jf-Nc for ptxdist@pengutronix.de; Thu, 07 Sep 2023 18:25:38 +0200 Date: Thu, 7 Sep 2023 18:24:54 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thorsis.com; s=default; t=1694103937; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:content-type:content-type:in-reply-to:in-reply-to: references:references; bh=FC2GJwa5tqIrneKRUAcR+Z8n205e2PRihHv9E2ExKQA=; b=J2/dF8Sxd8h8bDT2Cz+A12dSr3m6+K7xfH28S++IJdDBm0OEpQfdpKtpsZpK7NQfZx08cO GZbkQIUywOOD8XYhiPcmBOozH4xEqQ3Nz4AgjVlDyoKbXZW1duC4ftHLz/V2TmJD2QoXF1 dJYaYXIt5w9FOXCX4FpZLLwpqbpDsIa00yTgUpMLKVyJ7tEj4c71Y5cpasx+SwG/CP1yps 0JibnOKqtKVGcruqc58+0mkt0F/2q/IsQg7LspPNcKMpGQFjTiFVDw6kngX6/5OHkqAtDQ LV1s5p3n0EKzdeiypC9kp6wbZj+79DGLqFZbF2JNEeZpAS3BD3vTZZqZhrZZOg== From: Alexander Dahl To: Simon Falsig Message-ID: <20230907-jockstrap-dreamily-124aa43b7c7e@ifak-system.com> Mail-Followup-To: Simon Falsig , "ptxdist@pengutronix.de" , =?utf-8?B?SmnFmWkgVmFuxJtr?= References: Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on metis.whiteo.stw.pengutronix.de X-Spam-Level: X-Spam-Status: No, score=-2.8 required=4.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.2 Subject: Re: [ptxdist] SBOM support X-BeenThere: ptxdist@pengutronix.de X-Mailman-Version: 2.1.29 Precedence: list List-Id: PTXdist Development Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: ptxdist@pengutronix.de Cc: =?utf-8?B?SmnFmWkgVmFuxJtr?= , "ptxdist@pengutronix.de" Sender: "ptxdist" X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: ptxdist-bounces@pengutronix.de X-SA-Exim-Scanned: No (on metis.whiteo.stw.pengutronix.de); SAEximRunCond expanded to false Hello Simon, Am Thu, Sep 07, 2023 at 03:03:47PM +0000 schrieb Simon Falsig: > Hi, > > I saw a post from 2021 to the mailing list on generating SBOMs from ptxdist. > Has there been any further work on this? > > We've been looking at implementing this internally - plan would be to generate > the SBOM in CycloneDX format, and consume it with Dependency-Track > (https://dependencytrack.org) for automatic vulnerability and license monitoring. > > Looks like we're quite close to having a working setup, but it'd make a lot more > sense to have it upstreamed rather than as local patches, so would like to get a > bit of input on the approach, and see if we can make that happen :) > > We've identified two main steps: > 1. Generate the SBOM itself. A minimal version of this can be created from the > output of the existing fast-bsp-report in 40 lines of Python, using the > CycloneDX library. > I'd assume that such a script would just go into the scripts folder in ptxdist? > Is there a common way of tracking / documenting dependencies of such scripts? > > 2. To track vulnerabilities, it's necessary to track the Common Platform > Enumeration (CPE) name of each package (from https://nvd.nist.gov/products/cpe). > This will allow matching packages to CVEs. > My suggestion would be to add a _CPE variable to each package (built from > whatever other variables make sense, typically _VERSION). I managed to add this > for the fast report (extracting it to pkg_cpe in rules/post/ptxd_make_world_common.make, > and adding it to the report in scripts/lib/ptxd_make_world_report.sh), but I > wouldn't be surprised if there are other places/report that need to track this > also for consistency? > Packages that specify _CPE would then have this included in their report, and > there'd be no change for the packages that don't specify it. As far as I know buildroot [1] already has support for this. They construct this from defaults and override it with several different variables if defaults are not sufficient for a particular project: _CPE_ID_VENDOR _CPE_ID_VERSION _CPE_ID_UPDATE _CPE_ID_PRODUCT And maybe more? Some quirks handling like this is probably necessary in ptxdist, too? Greets Alex [1] https://buildroot.org/ > > > I'd be happy to get a bit of initial feedback on the approach. I'll have a look > at putting up some initial patches in the coming days too. > > Thanks in advance and best regards, > Simon >