Define what baseline applies to

[evankanderson]

The Security Baseline aims to measure and recommend controls for open source projects.

Unfortunately, we haven't defined what a "project" is anywhere, and we often conflate projects with source code repositories or specific released artifacts. Some projects consist of multiple repositories (e.g. projects with a separate repository for each plugin, or projects that separate website, automation), or produce multiple packages possibly in different distribution channels.

We need a definition of project which allows producers and consumers to understand what is in and out of scope of a particular assessment of baseline compliance, as well as to enable discovery of baseline maturity given a particular resource.

[eddie-knight]

While it was an intentional design decision to include a multi-technology scope (ie, not only source forges) — we have consistently refined each control to have a clear scope.

I anticipate that tightly-scoping a "project" definition may cost time and increase reputational risk more than it creates value.

If you see where we "conflate projects with source code repositories or specific released artifacts," that's a separate problem and we should address every case.

[evankanderson]

At the 10 June 2025 meeting, we discussed the definition that "a project is the set of things that the producer thinks are related" (without cardinality limits). Ben gave the example in the GUAC community that they might publish two projects from the perspective of baseline:

• the core "GUAC" project, which includes the documentation, automation, governance, etc
• the "GUAC Visualizer" project, which is less mature and more experimental in nature.

Evan has several other examples, though he's only a producer on one project, so he can't speak to how the others would work:

Knative
Knative has a modular extension-based architecture with separate extensions in separate repos. Some extensions are functionally required in a "pick one or more of N" model, while others are entirely optional. There are additional repositories for code-sharing, automation, documentation, and governance. If forced to match to baseline, this would end up with either a single baseline project covering 100+ repositories and 50+ artifacts, or two baseline projects for "core" and "experimental", where the first would cover about 50-60 repos, and the second would cover the remainder.

Babel
Babel is a Javascript transpiler, to allow using newer Javascript features on older implementations. Babel publishes ~1000 npm modules (each for specific functionality) from a monorepo. We are currently attempting to interview Babel to see how they would want to handle Baseline: #326

Note that one possible outcome is that Babel would want to split one repository to multiple projects (other monorepos may have the same outcome)

Spring
Spring is a collection of Java libraries to address common programming tasks. Spring releases a large number of libraries from a large number of repositories. I don't have a good sense as to exact numbers (other than that there are 85 repositories in GitHub), but I suspect there are more artifacts than repos, and that the project is probably large enough to correspond to multiple baseline projects. Engagement in #327

[evankanderson]

If you see where we "conflate projects with source code repositories or specific released artifacts," that's a separate problem and we should address every case.

I think external tooling (such as security insights, scorecard, and best practices) have all tended to make this simplifying assumption. I think baseline may have been determinedly coy about the definition, but I think a precise definition that makes it clear that the baseline permits multiple repositories and release lines[1] would be helpful.

[1] "Releases" may also need definition, as the word means both "a sequence of related artifact versions published over time", where each published artifact version is intended to replace the previous one, as well as to describe the publication of an individual artifact version (as defined in the baseline). If someone wants to point me to appropriate terminology, I'd be most appreciative. In its absence, I'd call the first thing a "release line" and the second thing a "release version".

[trumant]

There is perhaps a subtle extension of this issue which is - how can a project explicitly opt-out of baseline controls evaluation or otherwise clearly communicate that they do not view their project as in-scope for baseline controls

[evankanderson]

@funnelfiasco had thoughts about this in today's baseline meeting