Enable Platform-Security GitHub Workflow

[casey-williams-rh]

Overview

Enabling the Platform Security GitHub Workflow - This workflow provides Red Hat ConsoleDot Teams with a way to scan the containers they create in a convenient, automated, and reliable manner within their GitHub repository. The Platform Security Github Workflow lets teams get security feedback as they open Pull Requests.

REF: https://github.com/RedHatInsights/platform-security-gh-workflow

Secure Coding Practices Checklist GitHub Link

• https://github.com/RedHatInsights/secure-coding-checklist

Secure Coding Checklist

• Input Validation
• Output Encoding
• Authentication and Password Management
• Session Management
• Access Control
• Cryptographic Practices
• Error Handling and Logging
• Data Protection
• Communication Security
• System Configuration
• Database Security
• File Management
• Memory Management
• General Coding Practices

[jira-linking]

Commits missing Jira IDs:
d5841a4

[psegedy]

@casey-williams-rh this security scan is not ideal. First of all, it uses ubi-8 repos while the image built for stage/prod is build with rhel-8 repos, which means that different packages could be installed. Shouldn't this job run on ci.int.devshift.net on a rhsm registered host?

Anchore-Grype-Vulnerability-San job reports that setuptool is in old version which is not true

setuptools              39.2.0                           65.5.1                                   python  GHSA-r9hx-vwmv-q579  High

this is the version used by platform-python which cannot be updated and it also cannot be removed because dnf depends on it. In fact our application uses python3.11 with setuptools>=69

Are there any plans to improve those jobs? It will always fail and when something always fails it will be ignored by people which I think is not what we want.

[casey-williams-rh]

@psegedy , I'm not sure that I follow on the "This workflow uses ubi-8 repos while the image built for stage/prod is build with rhel-8 repos". The images in quay have com.redhat.component="ubi8-minimal-container" name="ubi8-minimal" version="8.10" within their build layers, and appears to be based on UBI8. (e.g., 87addea)

Also we are working on a False Positive tracking integration, so when packages like setuptools are detect we can flag them to not report again after confirming they are a False Positive. For the time being, if you would prefer, we can set the job to not fail on vulnerability detection, but provide a warning within the job itself. However, this can also lead to people ignoring the job.

I do not think it will take too much time or effort to get the False Positive tracking integration up and running. I just need the cycles to do it, and there is a ticket currently in my queue to work on it.

Shouldn't this job run on ci.int.devshift.net on a rhsm registered host?

• We could, but we are currently leveraging Anchore's Syft and Grype GitHub Actions. At the time of this workflows creation, GitHub Actions provided us we the easy path forward to get the ball rolling for security scans.

[casey-williams-rh]

@psegedy, Upon further review of the Dockerfile, I understand what you mean regarding "This workflow uses ubi-8 repos while the image built for stage/prod is build with rhel-8 repos".

Because the job is not running on a registered RHEL system, alternative packages are being pulled in.

RUN FULL_RHEL=$(microdnf repolist --enabled | grep rhel-8) ; \
    if [ -z "$FULL_RHEL" ] ; then \
        rpm -Uvh http://mirror.centos.org/centos/8-stream/BaseOS/x86_64/os/Packages/centos-stream-repos-8-4.el8.noarch.rpm \
                 http://mirror.centos.org/centos/8-stream/BaseOS/x86_64/os/Packages/centos-gpg-keys-8-4.el8.noarch.rpm && \
        sed -i 's/^\(enabled.*\)/\1\npriority=200/;' /etc/yum.repos.d/CentOS*.repo ; \
    fi

[casey-williams-rh]

@psegedy , I'm closing this PR for now so my team and I can better evaluate how we can scan the VMAAS Container Image.