[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [openc2] RE: EXT :[openc2] Updates to SBOM sharing draft
Iâm guessing that WGLC is an IETF process term, Iâve got no idea what it means. More specifics on what they mean by us âcatch[ing] upâ would also be helpful. Who is Eliot Lear talking to?
Â
Do we know what IETF WG / charter this is under? And their plans for progressing what appears to be an ID to an RFC?
Â
Dave
Â
David Lemire
IA Systems Engineer
Technical Solutions
302 Sentinel Drive | Annapolis Junction, MD 20701
Work (301)Â575-5190 | MobileÂ(240)Â938-9350
Â
From: openc2@lists.oasis-open.org [mailto:openc2@lists.oasis-open.org] On Behalf Of duncan sfractal.com
Sent: Friday, July 9, 2021 9:05 AM
To: TC OpenC2 (openc2@lists.oasis-open.org) <openc2@lists.oasis-open.org>; David Kemp <d.kemp@cyber.nsa.gov>
Cc: Eliot Lear (elear) <elear@cisco.com>
Subject: EXT :[openc2] Updates to SBOM sharing draftÂ
CAUTION: This email originated from outside your organization. Exercise caution when opening attachments or clicking links, especially from unknown senders.
Â
IETF has an RFC that references using OpenC2. Attached is some work circulated to the SBOM crowd.Â
Â
According to IETF gurus we need to :
âOpenC2 needs to catch up to this work if they want to remain after WGLC (themâs the rules). Iâve reinitiated a discussion with those guys.â
Iâm not sure what the means but we should do it promptly.
Dave K (or L or anyone else) Iâd appreciate help in doing this.Â
Â
iPhone, iTypo, iApologize
Duncan
Â
From: ntia-sbom-framing-bounces+duncan=sfractal.com@cert.org <ntia-sbom-framing-bounces+duncan=sfractal.com@cert.org> on behalf of Eliot Lear via ntia-sbom-framing <ntia-sbom-framing@cert.org>
Sent: Friday, July 9, 2021 8:06 AM
To: ntia-sbom-framing
Cc: Rose, Scott W.
Subject: Re: [ntia-sbom-framing] Updates to SBOM sharing draftÂ
This time with the draft attached.
Â
On 9 Jul 2021, at 13:57, Eliot Lear <lear@cisco.com> wrote:
Â
Hi everyone,
Â
As discussed, Scott and I have updated the SBOM sharing draft. As agreed, it handles VEX and SBOMs independently. We need to get this posted by Monday for the draft deadline. A few of the more salient points:
Â
- The intro is rewritten a bit to make clear what the key questions are. We donât focus on licensing in this draft, though there is one sentence about them in formats and format neutrality.
- There are two independent âchoicesâ in terms of how the information is retrieved- one for SBOMs and one for VEXes. Each are roughly speaking the same.
- Each maintains format neutrality. There is also some text in there about what if the VEX and the SBOM file are the same. Thatâs to address (obliquely) CycloneDX.
- We managed to write the entire draft without using the term âVEXâ.
- OpenC2 needs to catch up to this work if they want to remain after WGLC (themâs the rules). Iâve reinitiated a discussion with those guys.
- Weâve taken Patâs feedback to create separate well-known suffixes rather than to establish a tree.
- Iâve updated https://mudmaker.org/test [mudmaker.org]Âwith a version that does All Of This.
Â
One question is just whether it should ever be expected that vulnerability information be kept on the box. That seems like a stretch, even though the draft supports it.
Â
Please see attached, and you can view the source atÂhttps://github.com/elear/mud-sbom/tree/vex [github.com]. This will probably get merged over the weekend into the âmasterâ branch (which at some point will be renamed âmainâ).
Â
Eliot
ChetÂEnsignChief Technical Community Steward OASIS Open | Â | Â | Â |
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]