action #87805
closedcoordination #87853: [epic][brainstorming]
Investigate security test cases for automation
Added by ybonatakis over 3 years ago. Updated about 1 year ago.
0%
Description
Main concern on Containers is the security.
We lack automation on this field against our base images.
Goal is to research common security concerns for sle base image and create the tasks for their automation
Updated by ybonatakis over 3 years ago
- Status changed from New to In Progress
- Assignee set to ybonatakis
Updated by ybonatakis over 3 years ago
i investigated two security scanners which both are open source,fast and easy to be used straight away.
With dockerbench[0] is provided by the docker's repo itself and it can scan not only the container images but also the host for configuration and enviroment best practices.
It can run as simple as a container (with extended priveleges) and can produces a log file(plain or json). Performs a variety of checks that we can include or exclude explicitylly. Some of the providing test are
- host configuration
- docker daemon configuration
- container runtime
- docker enterprise configuration
With dockerbench i did not found a way to run against a specific image. it scan all the container images it finds in the host. Another problem is that i found the documentation poor. Although it is very good as a smoke test of a container environment
I found trivy[1] an amazing tool. it is super simple and its results are more accurate than its opponents(look anchore-test, clair-test) based on some their resources. And the reason for it is that trivy uses multiple data sources (along with github advisory db) which the scanning will use.
The trivy can be used to identify packages and its versions in the image and cross-reference with the database. This is important as each distribution has fixes in different package version and the database is updated from the vendor of the distribution. And trivy supports opensuse and sle.
i run it in the standalone mode(ther is a server-client too) against sle15sp1, sle15sp2, sle15sp3 and sle12sp3.
[0] https://github.com/docker/docker-bench-security
[1] https://github.com/aquasecurity/trivy
Updated by jlausuch about 3 years ago
- Status changed from In Progress to Workable
Moving to workable as there is no activity on this and there are more urgent things to do now.
Updated by jlausuch almost 3 years ago
- Priority changed from High to Low
- Parent task deleted (
#87853)
Updated by jlausuch almost 3 years ago
- Related to action #94132: Test running container networking with firewall added
Updated by jlausuch over 2 years ago
- Status changed from New to Workable
- Parent task set to #87853
Updated by jlausuch over 2 years ago
- Subject changed from [timebox] Investigate security test cases for automation to Investigate security test cases for automation
Updated by jlausuch over 1 year ago
- Related to action #108233: container scanning services added
Updated by rbranco over 1 year ago
Some registries have security scanners for Docker images. Quay.io uses Clair and GitHub Actions allows to use any scanner.
Another tool is Dockle which also runs a CIS benchmark, much better than the dockerbench shell script:
https://github.com/goodwithtech/dockle
The deprecated https://github.com/Azure/container-scan used both Trivy and Dockle.
Updated by rbranco over 1 year ago
- Status changed from Workable to Rejected
- Assignee set to rbranco
I asked in #team-buildops about the issue of scanning containers and their approach is to release a new image when a new package is released, and that they tried NeuVector in IBS/OBS and failed. I also asked in #discuss-neuvector and they have their own team to test the product.
https://suse.slack.com/archives/C02BX1X92HM/p1676280368655279
Updated by pdostal over 1 year ago
- Status changed from Rejected to New
I asked in #team-buildops about the issue of scanning containers and their approach is to release a new image when a new package is released, and that they tried NeuVector in IBS/OBS and failed. I also asked in #discuss-neuvector and they have their own team to test the product.
That's why I would simple add those tests to our openQA.
Updated by rbranco over 1 year ago
pdostal wrote:
That's why I would simple add those tests to our openQA.
Fair point, but those tests are security checks and openQA is not the best tool for this, IMHO. I think this kind of security checks should be done by the Security team on every image, not just base images. It's also the BuildOps team's responsibility to finally integrate NeuVector in IBS/OBS.
Let's escalate this so a decision is made at a higher level. As the priority for this issue is low, I'd wait for BuildOps to see if they finally integrate NeuVector. Otherwise we'll have to decide which images to scan and which tool to use (and what to do with the false positives & false negatives inherent with these tools). Ideally, it should've been SUSE's NeuVector but I asked in #discuss-neuvector about their QE processes and repositories and didn't get an answer.
Updated by jsegitz over 1 year ago
If NeuVector gets integrated into IBS/OBS then duplicating this in openQA doesn't make sense. But if they didn't integrate it then this would be my first choice.
The security team doesn't scan every image. We mostly work on lower layers to ensure that the input for the images is proper. Having this scanning ability in openQA would be great from our POV
Updated by rbranco over 1 year ago
We would waste time doing it in openQA if IBS/OBS eventually implements it.
Updated by jlausuch about 1 year ago
- Status changed from New to Rejected
This has been hanging for too long without any progress. I am closing this with an action point on me to find out how we could do this. If applicable to us, I will create another ticket with concrete task.