gbtucker
commented
2 years ago Hi @giantcroc thanks for the post and thanks for integrating isa-l. Glad to know you found a fit in Envoy.
We take security seriously so we are always interested on how to improve. Let's look at each of these. Please let us know if this spurs any ideas.
Add security policy: This one we should be able to put into a file as we already have a policy of course as part of our security lifecycle.
Branch-Protection: I'll have to look into this one further. I think the org only has the permissions to change branch permissions on the main branch.
CI-Tests: We have two levels of CI testing and it looks like the ossf tool is not recognizing either of them. The first is internal and perhaps difficult to register even though every commit and PR goes through this stage. The second is with github actions but not getting detected I suspect because of necessary rebasing to get the gerrit ID added for the first stage. This also seems to be an issue with the next item
Code-Review: We have two levels of code review also and these also are not getting picked up. Looking at the first three commit ids listed, they were all PRs with multiple reviews in github but not detected by the ossf tool. Again I think this is because of the necessary rebase to get the gerrit ID added for the first review step. Perhaps we can promote PRs to add the gerrit ID and fewer will need to be rebased.
CII-Best-Practices: Looking at the list of criteria we should already comply so perhaps we can enroll.
Dependency-Update-Tool: isa-l is a library without any other runtime library dependencies so dependabot or renovatebot are probably not beneficial.
Fuzzing: We do employ fuzz tools where appropriate (compression and decompression) but they are not detected by the tool.
Maintained: Isa-l is actively maintained and not sure why we miss the activity trigger levels.
Token-Permissions: If I understand this correctly the only token we use in ci github actions is the main actions/checkout@v2.3.4. Is it better to pick a version in this case and perhaps get bug fixes or pin to a hash value?
Pinned-Dependencies: As before we really don't have any dependencies so nothing to pin.
SAST: We do run static analysis as part of CI testing just none of the tools that ossf detects.
Signed-Releases: We don't push any binaries ourselves so nothing to sign. Not sure how we get 10 on Binary-Artifacts for this same reason but not here.
giantcroc
rhpvorderman
Hi! I am very interested in using isa-l in open-source service mesh community like Envoy. And I have done benchmark of isa-l and zlib, the result looks great. So I want to integrate isa-l into envoy as a kind of gzip lib. I have ran OSSF scorecard against isa-l to see how it would behave as an envoy dependency. The result is as followed:
The score is a bit low. However, many of the issues could be easily improved in isa-l. For example, adding a security policy is easy and important. Also setting branch protection and token permissions should just be a github-level thing.
Can you help fix some very simple issues to improve isa-l's security score of ossf scorecard? Thanks!