SBOMit Sandbox Project Application

[idunbarh]

The SBOMit project is seeking sandbox maturity level entry into the OpenSSF.

SBOMit was presented to the Security Tooling WG on 8/15/23 and the slides are available at ...

• https://docs.google.com/presentation/d/1l3dPqw67uf9VQ4yJEbhZkjhHhhhEYpjGdrWclmdTJFg/edit?usp=sharing

We believe we meet OpenSSF Sandbox requirements.

• Projects must have a minimum of two maintainers with different organization affiliations.
  • Project maintainers include
    • Justin Cappos, NYU, @JustinCappos
    • Ian Dunbar-Hall, Lockheed Martin, @idunbarh
    • Cole Kennedy, TestifySec, @colek42
    • Marina Moore, NYU, @mnm678
    • Trishank Kuppusamy, Datadog, @trishankatdatadog
• Projects must be aligned with the OpenSSF mission and either be a novel approach for existing areas or address an unfulfilled need. It is expected that the initial code needed for an OpenSSF WG to work be kept within their repository and will not function as a project in its own right. Should initial WG code grow and mature that it warrants its own Project status, then it is subject to Sandbox entry requirements. It is preferred that extensions of existing OpenSSF projects collaborate with the existing project rather than seek a new project.
  • Software Bills of Materials (SBOMs) often suffer from inaccuracy, primarily due to a retrospective approach to software analysis that fails to accurately track components. This challenge is becoming more pressing with the rise of sophisticated supply chain attacks requiring advanced technology and robust frameworks like the Secure Software Development Framework (SSDF) for comprehensive security.
• If contributing an existing Project to the OpenSSF, the contribution must undergo license and IP due diligence by the Linux Foundation (LF).
  • See issue requesting IP review

Remaining Actions

• Complete IP Review
• Security Tools WG support confirmation

SBOMit Links

• https://github.com/sbomit
• https://sbomit.dev/

SBOMit is licensed as CC-BY-4.0.

• https://github.com/SBOMit/specification/blob/main/LICENSE.md
• https://github.com/SBOMit/website/blob/main/LICENSE.md

[mlieberman85]

I read through what's currently there for the specification, and one big suggestion I have is an example, even if it's a contrived hello world example would be useful to really understand how SBOMit intends to solve the problem posed in the specification and presentation.

[idunbarh]

There is some discussion around licensing of the SBOMit specification on the LF License review issue. Initial discussion with the SBOMit maintainers is to accept a change to Community Specification License 1.0, OWFa or W3C on condition of Sandbox status being accepted.

Ideally the TAC can review our application and discuss at the next meeting. If the vote is to accept pending the license change, the SBOMit maintainers will work the license change in parallel.

I also updated slides (4 and 5) updated to detail the difference between SBOMit and signed SBOMs. This was a common question from TAC members.

• SBOMit Sandbox Application Presentation

[idunbarh]

Adding some updates since the TAC meeting on Tuesday.

• Added proof of concept sample reference implementation https://github.com/SBOMit/protobomit.
• Had agreement from maintainers to switch specification licensing to Community Specification License 1.0 and working on implementing the license change.

[idunbarh]

SBOMit lifecycle docs update to reflect change to using Community Specification License 1.0 as requested by LF IP Review.

[mlieberman85]

(starting the voting thread) +1 Binding from me.

[SecurityCRob]

voting - +1 for me to adopt based on reaction to feedback & adjustment of license (thanks!)

[steiza]

+1 for me - the project is in a early phase, but that's what the sandbox step is for!

[lehors]

As I explained multiple times in various places: under our current governance structure this cannot be brought in as a project. Because it is not primarily focused on producing code, it ought to be categorized as a SIG (for which there is no sandbox stage).
But I'm otherwise fine with bringing this work into OpenSSF.

[torgo]

+1 from me.

[bobcallaway]

+1 from me

[jsoref]

Assuming the other items are correctly spelled, can you try following the instructions in https://github.com/ossf/tac/actions/runs/6218203711?pr=192#summary-16874345424 ? (If they don't make sense, please let me know)

[JustinCappos]

I'm finding a bit ironic that the OpenSSF is asking me to curl and run a perl script from the Internet... 😃

To accept ✔️ these unrecognized words as correct, run the following commands
... in a clone of the [email protected]:SBOMit/tac.git repository
on the main branch (ℹ️ how do I use this?):

curl -s -S -L 'https://raw.githubusercontent.com/check-spelling/check-spelling/v0.0.21/apply.pl' |
perl - 'https://github.com/ossf/tac/actions/runs/6218203711/attempts/1'

I'm not super conversant in Perl and I'm about to head to bed. The flagged items are actually spelled correctly, if someone else from the SBOMit group has a moment to sanity check what is happening and then tell the spellchecker to ignore these issues.

[jsoref]

You can manually add the items to
https://github.com/SBOMit/tac/blob/main/.github/actions/spelling/expect.txt if you're more comfortable w/ that. And https://github.com/ossf/tac/blob/main/.github/actions/spelling/advice.md can be adjusted to provide instructions to do that.

(Updated to be slightly more precise, sorry about the confusion)

[di]

+1

[JustinCappos]

Okay, I've submitted a PR with those words added. #200

[jsoref]

@JustinCappos You kind of want to do something like SBOMit/tac@main...JustinCappos:tac:patch-2 -- i.e. creating the PR from your repo into the SBOMit repo.

check-spelling will suggest deleting things that aren't needed, so those would be orphaned and reaped by the next person who followed its instructions.

[SecurityCRob]

6 of 7 TAC members voted to approve, with 1 not responding. Arnaud brings up good points that we need to have a spec-focused group entry in our governance, but that should not block this effort.

[mnm678]

6 of 7 TAC members voted to approve, with 1 not responding. Arnaud brings up good points that we need to have a spec-focused group entry in our governance, but that should not block this effort.

Thanks! So is this pr ready to merge?

[mlieberman85]

6 of 7 TAC members voted to approve, with 1 not responding. Arnaud brings up good points that we need to have a spec-focused group entry in our governance, but that should not block this effort.

Thanks! So is this pr ready to merge?

Yep just need to fix the merge conflicts and it's ready to go

[hythloda]

6 of 7 TAC members voted to approve, with 1 not responding. Arnaud brings up good points that we need to have a spec-focused group entry in our governance, but that should not block this effort.

Thanks! So is this pr ready to merge?

Yep just need to fix the merge conflicts and it's ready to go

I tried to resolve the conflicts but I don't have write permission on this branch to help :(

[idunbarh]

@hythloda rebased the SBOMit application changes and resolved the conflicts.

[hythloda]

@jsoref is the spelling workflow broken or something in the file?

[jsoref]

@hythloda unfortunately check-spelling is looking at files as a whole, it found these items in the files changed in this PR:

CRob
Roadmap
Sigstore
TUF

The reason it cares about TUF and not tuf is because there's a pattern that means that it won't see the url that contains tuf -- and it has no idea if tuf is used throughout the rest of the repository because it isn't checking the other files.

I just released a version last week which would have told you which lines it found each item in (which should have helped things a lot) and which files it was checking (which would have improved things a little).

I need to think about the logic of the only changed files feature (it exists for this sort of repository use case, but I rarely use it) -- I suspect the advice it gives should be to add items into allow.txt instead of into expect.txt (a distinction here is that allow.txt doesn't do any pruning, and doesn't have any case tolerance, so it wouldn't have promised that the presence of tuf meant that TUF was ok). I have a PR drafted to upgrade this repository to the version I just released, but in testing it, I realized that it wasn't offering advice.md at all, which isn't great, so I was thinking about what to do (the easiest thing here is to change the advice.md file to suggest using allow.txt instead...)

But basically, the goal here is for it to ask people if they're ok with the words that are used, if they are, the check isn't mandatory and once it merges, future PRs that don't change those files won't be asked about those items.

Oh..., there is a workflow change we could/should make which is adding quit_without_error: 1 to these two with blocks:

tac/.github/workflows/spelling.yml

Line 131 in aa5f070

with:

tac/.github/workflows/spelling.yml

Line 148 in aa5f070

with:

That'd result in you not seeing a ❌ but instead getting the ✅ .

So, long story short:

1. to get a ✅ here, add the four words to allow.txt or expect.txt (it won't care, I'd favor the former)
2. to get ❌s to stop appearing going forward, we'd want to copy quit_without_error: 1 to those two other with: blocks.

[idunbarh]

@hythloda I'll make @jsoref's recommended changes in our fork. Thanks @jsoref for the info!