[Feature]: Implementations for 100% Security Compliance for CLOmonitor

[Salkimmich]

Requirement

To receive awards for compliance with CNCF best practices, Jaeger needs to implement SBOMs that will clear this check.

Problem

Software Bill of Materials (SBOM) - is a list of all the dependencies that went into your current build and deliverables. It contains more information about your project than an usual lockfile, also compiling individual dependencies license, security and origin information into one neat packet.
SBOMS are increasingly becoming a requirement to be provided with deliverables. For example the recent NSA, CISA, ODNI Software Supply Chain Guidance for Developers recommend that producers of open source projects provide a SBOM for every project as a mitigation and assurance of good development practice.
SBOMS can also be checked by users adopting software, creating visibility into what constituent dependencies were used to build a given package, creating more transparency and visibility into security issues, mitigations and footprint. This information can be used by them to assess the security, as well as provide feedback and contributions back to your project.
Adopting SBOMs is easy. There are two standards out today, CycloneDX and SPDX. CLOMonitor by CNCF can automatically check your project for the presence of these files and give you guidance on how to get started creating one.

Proposal

Adopting SBOMs is easy. There are two standards out today, CycloneDX and SPDX. CLOMonitor by CNCF can automatically check your project for the presence of these files and give you guidance on how to get started creating one.
To enable CLOMonitor with Sonatype Lift:

• Enable Sonatype Lift to run on your project’s repository. See Getting Started.
• Create a .lift.toml file in your projects root directory with the following to enable on demand CLOMonitor scans: customTools=["/extra-tools/clomonitor.sh"]
• If you would like to disable all additional scanning tools in Lift also add the following line: tools=[]
• To run a scan and check your progress on completing the CLOMonitor checks, select your repository on the Lift dashboard, select the appropriate branch from the drop down and hit “Analyze”.

Open questions

Two additional security compliance measures not detailed here but needed for 100% completion are:

1. Token permissions
2. Updating the docs for signing releases

[yurishkuro]

@jkowall anything still left to do here?

[jkowall]

@yurishkuro

1. We never put together the release signing we wanted to do, so that's the only open issue.
2. SBOM, we just to test when we do the next release.
3. For some reason, the checks are still not showing up as fixed for token permissions https://clomonitor.io/projects/cncf/jaeger

[yurishkuro]

[yurishkuro]

I don't know if the tokens report is stale or not. It complains about some perms, but the remediation is to run https://app.stepsecurity.io/secureworkflow/jaegertracing/jaeger/ci-all-in-one-build.yml/main?enable=permissions, which does not produce any changes/recommendations. Wonder if it's because of this error:

[jkowall]

This is the issue to track it step-security/secure-repo#1095

It looks like we have to change the yaml manually and set the permissions.
https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#permissions

I think I can try to make it read-all and see if the job runs in my fork. What do you think @yurishkuro?

[yurishkuro]

@jkowall looks like we regressed on the scorecard because there is no active enforcement, like requiring the harden-runner in all new workflows.

[jkowall]

When we enabled this before it broke the pipelines and we had to remove it. The scorecard checks have been enhanced and added since last year, so we have more hurdles to clear. I can link all the ongoing work back to this issue if you want. I do not see a way to lock this down without changing the way the CI scripts work today.

[yurishkuro]

@jkowall we could leverage the community more by creating issues for specific small tasks and tagging them good-first-issue (need to ensure description is clear what needs to be done).

As far as enforcement, I don't have a strong opinion. Some of the items on the checklist are "opinions", i.e. just because something is a good practice doesn't mean that the project is less secure if it's not following it (e.g. if I merge a PR fixing a typo in the README without a code review). Plus, as you said, the list keeps growing, so not straightforward to keep up. But ultimately it would be good to treat it as a linter and enforce especially for some categories if possible. It would be nice if there was a CLI we can run ourselves in CI and have a configured list of certain checks that should fail CI if they don't pass.

[jkowall]

We could do that, or just shore it up once a year. I was taking that approach versus making our CI slower. We have a slew of issues to address on the new OpenSSF scorecard which would be good first issues to handle: https://securityscorecards.dev/viewer/?uri=github.com/jaegertracing/jaeger