Endo OpenSSF Security Scorecard

[AlbinHoxha]

Our organization is currently evaluating Endo/SES for integration into our production environment. As part of our internal security compliance, we require all core libraries to meet a minimum threshold on the OpenSSF Scorecard.

Currently, the Pinned-Dependencies and Token-Permissions scores are below our required safety baseline. Addressing these is essential for our security team to approve the use of this library in our stack.

Critical Requirements for Compliance:

1. Token-Permissions (Principle of Least Privilege)
   Our security policy prohibits workflows with broad write permissions.

Impact: This prevents a compromised third-party action from gaining write access to the Endo codebase or secrets.

2. Pinned-Dependencies (Immutable Infrastructure)
   To protect against supply-chain attacks (such as "tag-jacking"), our policy requires that all third-party GitHub Actions be pinned to a specific SHA-1 commit hash rather than a mutable version tag (e.g., @v4).

Why this is urgent for us:
While we recognize the high quality of the Endo codebase, our automated supply-chain scanners flag these specific Scorecard gaps as "High Risk." Resolving these will allow us to move forward with adopting Endo.

[kriskowal]

Thank you for reporting. We can at least verify these issues are present and germane and gather community resources to proactively address them.

[kriskowal]

Two down. #3066 I’ve added pinning for github actions and automation for keeping those up-to-date with reasonable defaults for mitigating supply chain attacks, but notably, no solution is perfect short of having a tool like LavaMoat (which is built on SES) that limits the blast of a dependency with principle-of-least-authority. We could go farther and vendor the actions and their transitive dependencies. Pinning does not reach that far.

I’ve also narrowed the permissions of each job.

More needed.

[kriskowal]

Evidently, to satisfy the recommendations of the OpenSSF scorecard, we would need to refrain from using any pull request workflows that can propose pull requests.

https://github.com/ossf/scorecard/blob/ac18bf8aefea92d408c736bdd3d60fd8e59dc969/docs/checks.md#token-permissions

We have workflows that propose pull requests for the purpose of improving our security stance. We may be able to improve these to effect a reduction exposure to our supply chain while we do this, with isolated lockfiles for the dependencies of the job, but probably not in a way that would convince the automated scorecard generation.

Tapping @boneskull since this may touch upon our release process. We could simply delete the new cron jobs for updating stale pins. I note that the recommendations are not even sufficient to their own ends, given that the pins are shallow and presume the transitive action dependencies are pinned as well, and that pinning increases the duration of exposure to a zero-day.

This exercise is worthwhile. We can certainly reduce our exposure. However, I do not think we can arrive at optimal reduction of exposure if we optimize for the scorecard.

[kriskowal]

Also, to wit, we do not currently publish to npm from Github CI actions. I expect to continue this policy even as we improve our release process. However, we do have ambitions to publish dev- prefixed and dev tagged releases from CI, and I don’t believe it is possible to scope npm publish authentication keys to limit their capability to publish new release versions in the latest tag. We might simply continue to refrain from this level of automation.

[kriskowal]

@AlbinHoxha We’ve addressed one of the specific considerations in your original post: pinned dependencies.

Regarding “write” permission in CI jobs, for this project, the optimal security stance may not be the maximal stance for purposes of compliance. We will need to periodically run automation to update pins. We have a CI job now that will propose new pins for Github CI actions. We require the versions to be published for a week before we adopt one, to mitigate zero-days. We also have a knob that will let us adopt new versions or major versions sooner, to mitigate long-undiscovered defects and to stay on the latest version train. This automation could be scheduled for a contributor to run locally on a schedule, but Github cron jobs are better at scheduling than we are, and furthermore our Github CI jobs don’t have the rights needed to publish to npm.

It may be that as long as we continue to not publish to npm from Github CI, it is actually the lower risk place to run CI jobs that propose pull requests for security maintenance like dependency management.

On the other hand, npm has considerably improved their own stance on publishing from developer workstations and now require developers to log in each time they publish, so an attack on a contributor’s workstation is considerably less likely to provide a path to automated publish. This in mind, the strongest case for using Github CI actions that propose pull requests is that we can be more certain that the job will get done.

Thank you for your consideration.