Can you help improve isa-l's security score of ossf scorecard? about isa-l

[gbtucker]

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/[email protected]. 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]

@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.

1. Add security policy: the simplest one, just place a security policy file SECURITY.md in the root directory of the repository.
2. Branch-Protection: we can add some constraints on main branch like disabling force pushes and allow deletion.
3. Token-Permissions: I don't konw if it's possible to make token read-only. If it's ok, we can add permissions for the GITHUB_TOKEN as add permissions.

After finish fixing these items above, I think the score should be able to reach 5.0 or more. Thanks!

[rhpvorderman]

@giantcroc. I have integrated ISA-L as a dependency in some other projects and my experiences are as follows:

1. ISA-L not having dependencies is great. This means ISA-L never causes a dependency conflict.
2. ISA-L provides only one feature over zlib: speed. This means that functionally-wise, it is redundant. Which in turn means you can add the dependency by adding optional code path for speed instead of building your whole library on top of ISA-L.

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.

[giantcroc]

@rhpvorderman Thanks! Your sharing is very helpful to me.
And I think the most difficult thing is building nasm in bazel because envoy uses bazel as the build tool.
Do you have any experience to build isa-l using bazel?

[rhpvorderman]

1. I build nasm first: https://github.com/pycompression/python-isal/blob/develop/.github/workflows/ci.yml#L168
2. Then I simply use the commands as provided on the readme:

./autogen.sh
./configure --prefix /somewhere/in/build/directory
make
make install

You need to statically link isa-l_static.lib.

[gbtucker]

Added security policy file in 2bcbaf4.

[giantcroc]

1. I build nasm first: https://github.com/pycompression/python-isal/blob/develop/.github/workflows/ci.yml#L168
2. Then I simply use the commands as provided on the readme:

./autogen.sh
./configure --prefix /somewhere/in/build/directory
make
make install

You need to statically link isa-l_static.lib.

OK, thanks!

[giantcroc]

Added security policy file in 2bcbaf4.

@gbtucker Look good. Thanks!
I have ran the scorecard again and the score is already up to 4.6.
And I think it's easy to get to 5.0+ with more small improvements.

Aggregate score: 4.6 / 10