Potential gaps to address prior to intial release & implemenation

[SecurityCRob]

In reviewing the current baseline(1) I've come across a few things that could be gaps, oversights, or perhaps were intentionally removed for some reason. I'd like the group to discuss if we want to included them so we better align with industry frameworks and the initial TAC proposal(2). I perhaps overlooked something we have already, but perhaps it was phrased in a way that didn't make it obvious to me the goals were the same.

• Generate SBOMs
• Only release signed artifacts
• Run automated tools and scanners to find defects and vulns
• Review dependencies for security & quality
• No hard-coded secrets or hard-coded accounts
• Data protections at rest, in use, and in transit
• Handling data/PII
• SLSA lvls?
• Logging enabled
• Documented project requirements, including security requirements
• Threat Modeling/Attack surface analysis

Thanks in advance for the group feedback.

(1) - https://github.com/ossf/security-baseline/blob/main/baseline.md (2) - https://github.com/ossf/tac/blob/main/process/security_baseline.md

[mlieberman85]

So, I had thought we simplified the baseline to get started with the plan to iterate, but it does seem like there's a lot less there than what I remember us discussing. With that said some of the ones you stated above don't necessarily make sense to me.

Here's my general thoughts on the stated requirements:

For generating SBOMS, I lumped it into the SCA requirements, but reading closer we have a requirement to deal with SCA results but nothing in there says SCA should be run.

I actually think we should go beyond signed releases. In general signed artifacts don't really say anything at least compared to SLSA or even a signed SBOM.

Not clear what Logging enabled means (logging on Github for the project?, logging in the app itself?)

---

A take away for me is if we start to go down this path does it make more sense to just adopt something like a subset of NIST 800-53, NIST 800-218, along with a few things specific to LF and then call it a day? If the idea is to align with existing stuff I think SSDF and associated NIST stuff already hits everything we want to hit, and then the baseline can focus on how to make that scalable for projects in the open source space.

[eddie-knight]

Application-related criteria can be moved to required values in Security Insights, which could then be made into automated checks (OR, in baseline we could require docs for these):

• Logging enabled by default
• Default handling of data/PII
• Data protections at rest, in use, and in transit

I propose we create a PR to add the following issues unless we can find them to be already covered:

• Only release signed artifacts
• Run automated tools and scanners to find defects and vulns (SAST)
• Review dependencies for security & quality (SCA)
• No hard-coded secrets or hard-coded accounts
• Threat Modeling
• Data flow analysis (modify actors and actions?)

The following items should be discussed further:

• Generate SBOM
• SLSA lvls
• Documented project requirements, including security requirements

[SecurityCRob]

So, I had thought we simplified the baseline to get started with the plan to iterate, but it does seem like there's a lot less there than what I remember us discussing. With that said some of the ones you stated above don't necessarily make sense to me.

Here's my general thoughts on the stated requirements:

For generating SBOMS, I lumped it into the SCA requirements, but reading closer we have a requirement to deal with SCA results but nothing in there says SCA should be run.

I actually think we should go beyond signed releases. In general signed artifacts don't really say anything at least compared to SLSA or even a signed SBOM.

Not clear what Logging enabled means (logging on Github for the project?, logging in the app itself?)

A take away for me is if we start to go down this path does it make more sense to just adopt something like a subset of NIST 800-53, NIST 800-218, along with a few things specific to LF and then call it a day? If the idea is to align with existing stuff I think SSDF and associated NIST stuff already hits everything we want to hit, and then the baseline can focus on how to make that scalable for projects in the open source space.

Thanks Mike, I appreciate the feedback. I started efforts to line up our Baseline with a few frameworks. Generally, I agree with the idea, and would prefer to pin on something like the SSDF rather than 800-53 (which is an operations standard for enterprises that has little to do with software development directly). Eddie and I are chatting today about these topics and will come back to the group with some suggestions on if we identify "must haves" we want to pull into the Baseline before it goes out the door.