Skip to main content

Last Call Review of draft-ietf-opsawg-sbom-access-14

Request Review of draft-ietf-opsawg-sbom-access
Requested revision No specific revision (document currently at 18)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2023-03-13
Requested 2023-02-27
Authors Eliot Lear , Scott Rose
I-D last updated 2023-03-08
Completed reviews Secdir Early review of -09 by Christian Huitema (diff)
Yangdoctors Early review of -02 by Ebben Aries (diff)
Genart Early review of -03 by Russ Housley (diff)
Opsdir Early review of -03 by Niclas Comstedt (diff)
Secdir Last Call review of -14 by Christian Huitema (diff)
Assignment Reviewer Christian Huitema
State Completed
Request Last Call review on draft-ietf-opsawg-sbom-access by Security Area Directorate Assigned
Posted at
Reviewed revision 14 (document currently at 18)
Result Ready
Completed 2023-03-08
I have reviewed the changes between draft-09, which I reviewed in September
2022, and draft-14, the most recent version.

The main concern expressed in my review was that "defense at scale" might also
enable "attack at scale". The authors were not entirely convinced that this
applies to their draft, because they "are discussing a discovery mechanism, and
that the mechanism itself does not provide access to the underlying data." The
authors reinforced this point by stating in the introduction that "the model is
a discovery mechanism, and on its own provides no access to the underlying

The other counter argument was that there is a lot do be gained by disclosing
vulnerabilities, and that for most devices vulnerabilities can be deduced from
very simple and well known properties, such as the version of OpenWRT that is
run by a Wi-Fi router. That is true, but  my main concern was that having
information available on the device itself was tantamount to flashing a "hack
me now" sign. And I was specially concerned by having that information
published by default by otherwise unconfigured devices. This, the author did
fix. The paragraph in the security section now says:

   SBOMs provide an inventory of software.  If software is available to
   an attacker, the attacker may well already be able to derive this
   very same software inventory.  When this information resides on the
   endpoint itself, the endpoint SHOULD NOT provide unrestricted access
   by default.  Other servers that offer the data MAY restrict access to
   SBOM information using appropriate authorization semantics within
   HTTP. (Followed by description of access control methods.)

The "SHOULD NOT" does address my recommendation, and also mitigates somewhat
the risk of having a server running on an open port on the device. I am also
happy that the ambiguous text about "some of the readable data nodes ...
considered sensitive or vulnerable in some network environments" has been

I am still concerned that the paragraph starting "SBOMs provide an inventory of
software", as written, only hints at the potential attack, without describing
it. But life is full of such little dissatisfaction...