Can you help improve isa-l's security score of ossf scorecard? #218
Comments
|
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 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. |
|
@gbtucker Hi, thanks for your help! I think it is enough to make the score bigger than 5.0, and there is no need to fix all items listed, so we can choose some eaiser one to improve the score.
After finish fixing these items above, I think the score should be able to reach 5.0 or more. Thanks! |
|
@giantcroc. I have integrated ISA-L as a dependency in some other projects and my experiences are as follows:
Reason 1 means ISA-L is very unlikely to become a liability in your project and reason 2 means that if for some reason it does, there is very little cost to removing the code that uses ISA-L. The speed benefits are non-trivial so integrating is worth it when compression/decompression is a bottleneck. |
|
@rhpvorderman Thanks! Your sharing is very helpful to me. |
./autogen.sh
./configure --prefix /somewhere/in/build/directory
make
make installYou need to statically link |
|
Added security policy file in 2bcbaf4. |
OK, thanks! |
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!
The text was updated successfully, but these errors were encountered: