Consider adding (and tracking) packages from the Civil Infrastructure Platform (CIP)

[bureado]

The cip-core project emits a package list comprising the minimal (core) CIP system. Several pieces of software in the list might already be in OpenSSF's critical projects list, but it'd be interested to assess the merits of using CIP's package list as a transitive criteria for addition, not unlike the rationale for #26, perhaps.

The list in question: https://gitlab.com/cip-project/cip-core/cip-pkglist/-/blob/master/pkglist_buster.yml.

It's possible there are newer or evergreen versions in other places, and that someone is actually creating an SPDX or similar SBOM version of this. It's possible we might also want to look into the tooling and any differential inputs to create the deby layers for the different boards listed in https://gitlab.com/cip-project/cip-core/deby, possibly related to #36.

(Note: I'm conscious this list overlaps significantly with the Debian base system. In addition to any software that might be missed, I'm asking a broader question of whether criteria for inclusion in other lists with software deemed critical by different sectors, groups and verticals might be helpful for updating the OpenSSF list.)

[bureado]

On a similarly inspired note, ELISA might have some detectable critical projects as well - right now it sounds like it's Yocto (not unlike #36 and this same issue): https://github.com/elisa-tech/meta-elisa/blob/f773e5ab2bdd860bf72b7a4dacb62fee1daa3c5a/README.md and smaller tools like: https://github.com/elisa-tech/workgroups/tree/fc885013855d92a9a053482b2367ebcd12c2e5b3/safety-architecture/tools/callgraph-tool

I wonder if there's an opportunity to run a dependency crawler across orgs working on safety/critical applications to detect high intensity software components for consideration.