Repository navigation
Security scan failure: Private keys stored in image #557
Description
Issue description:
We are using security scanning tool and it is currently flagging this project due to it's inclusion of a private key in server.key and client.key.
I understand that this is a false positive as mentioned key are used for tests only. However it is pretty hard to tweak security tool to ignore this particular issue and keep ensuring people do not put actual keys to the image.
I've found similar ticket in nodejs node-gyp module nodejs/node-gyp#2037 where they ended up extracting keys to the js file certs.js. I understand that it does not solve the issue however it tricks security scan and resolves mentioned false-positive.
Do you think similar thing (e.g. inlining key to the code) can be done here?
Steps to reproduce:
Run security scanning tool on the image that contains python-ldap project.
Operating system:
RHEL8 (I doubt it matters)
Python version:
3.9 (I doubt it matters)
python-ldap version:
latest (as of 15 Feb 2024)
Activity
tiran commentedon Feb 15, 2024
Is your tool able to ignore files based on file patterns? We could rename the files to
test-client.keyandtest-server.keyif that helps.vitaliyatoptus commentedon Feb 19, 2024
Based on my information the tool does not allow to ignore based on patterns and even if it does in a corporate world it will be merely impossible to get this approved. I've asked the security team and I will update here once I get the answer.
kramar11 commentedon May 29, 2024
Same here. A trivy scan reports severity HIGH for the private keys included in the package:
Maybe best solution would be to not include slapdtest module with the python-ldap package, but rather make it optional or even a separate package?
tiran commentedon May 29, 2024
That would take a large, backwards incompatible change.
It's very common to have test keys and test certificates in a project. It would be more reasonable if you could work with your vendor and figure out a general solution that works for OSS project.
kramar11 commentedon Jun 25, 2024
Sorry for late reply!
I understand that this would be backwards incompatible. But as automatic security scans in CI/CD pipelines are very common these days, you should maybe considering putting slapdtest in a separate package in a next major release where backwards compatibility isn't strictly required.
My solution so far ist, to simply remove the slapdtest folder in my container, i.e. in Dockerfile I have:
Maybe this can help someone who has the same problem and finds this ticket.
fix: remove slapdtest from the image
fix: remove slapdtest from the image